Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.501  Word version:   16.4.0

Top   Up   Prev   Next
1…   3…   4…   4.2.4   4.2.5…   4.2.8…   4.2.8.2.2   4.2.8.2.3…   4.2.8.4…   4.2.9…   4.3…   4.3.3   4.3.4   4.3.5   4.4…   4.4.6…   4.4.8   5…   5.3…   5.3.3…   5.4…   5.5…   5.6…   5.6.7…   5.7…   5.7.2…   5.7.3…   5.7.4   5.7.5…   5.8…   5.8.2.11…   5.9…   5.10…   5.11…   5.15…   5.16…   5.17…   5.18…   5.19…   5.21…   5.22…   5.27…   5.28…   5.29…   5.30…   5.31…   5.32…   5.33…   5.34…   5.35…   6…   6.3…   7…   7.2…   8…   8.2.4   8.2.5…   8.3…   A…   D…   E…   F   G…   G.3   G.4…   J…

 

5.27  Time Sensitive Communications [R16]
5.27.0  General
This clause describes 5G System features that support TSC and allow the 5G System to be integrated transparently as a bridge in an IEEE TSN network.
During the PDU Session establishment, the UE shall request to establish a PDU Session as an always-on PDU Session, and the PDU Sessions used for TSC are established as Always-on PDU session as described in clause 5.6.13. In this release of the specification:
  • Home Routed PDU Sessions are not supported for TSC services;
  • TSC PDU Sessions are supported only with PDU Session type Ethernet and SSC mode 1;
  • Service continuity for TSC PDU Sessions is not supported when the UE moves from 5GS to EPS.
Up
5.27.1  TSN Time Synchronization
5.27.1.1  General
For supporting TSN time synchronization, the 5GS is integrated with the external network as a TSN bridge as described in clauses 4.4.8 and 5.28.1. It shall be modelled as an IEEE 802.1AS [104] compliant entity according to TS 22.104. For TSN Synchronization, the entire E2E 5G system can be considered as an IEEE 802.1AS [104] "time-aware system". Only the TSN Translators (TTs) at the edges of the 5G system need to support the IEEE 802.1AS [104] operations. UE, gNB, UPF, NW-TT and DS- TTs are synchronized with the 5G GM (i.e. the 5G internal system clock) which shall serve to keep these network elements synchronized. The TTs located at the edge of 5G system fulfil all functions related to IEEE 802.1AS [104], e.g. (g)PTP support, timestamping, Best Master Clock Algorithm (BMCA), rateRatio. Figure 5.27.1-1 illustrates the 5G and TSN clock distribution model via 5GS.
Up
Figure 5.27.1-1 depicts the two synchronizations systems considered: the 5GS synchronization and the TSN domain synchronization, as well as the Master (M) and Slave (S) ports considered when the TSN GM is located at TSN working domain.
  • 5GS synchronization: Used for NG RAN synchronization. 5G RAN synchronization is specified in TS 38.331.
  • TSN domain synchronization: Provides synchronization service to TSN network. This process follows IEEE 802.1AS [104].
The two synchronization processes can be considered independent from each other and the gNB only needs to be synchronized to the 5G GM clock.
To enable TSN synchronization, the 5GS calculates and adds the measured residence time between the TTs into the Correction Field (CF) of the synchronization packets of the TSN working domain.
Up
5.27.1.2  Distribution of timing informationWord-p. 262
5.27.1.2.1  Distribution of 5G internal system clock
The 5G internal system clock shall be made available to all user plane nodes in the 5G system. The UPF and NW-TT may get the 5G internal system clock via the underlying PTP compatible transport network with mechanisms outside the scope of 3GPP. The 5G internal system clock shall be made available to UE with signaling of time information related to absolute timing of radio frames as described in TS 38.331. The 5G internal system clock shall be made available to DS-TT by the UE.
Up
5.27.1.2.2  Distribution of TSN clock and time-stamping
The mechanisms for distribution of TSN clock and time-stamping described in this clause are according to IEEE 802.1AS [104].
Upon reception of a downlink gPTP message the NW-TT makes an ingress timestamping (TSi) for each gPTP event (Sync) message and uses the cumulative rateRatio received inside the gPTP message payload (carried within Sync message for one-step operation or Follow_up message for two-step operation) to calculate the link delay from the upstream TSN node (gPTP entity) expressed in TSN GM time as specified in IEEE 802.1AS [104]. NW-TT then calculates the new cumulative rateRatio (i.e. the cumulative rateRatio of the 5GS) as specified in IEEE 802.1AS [104] and modifies the gPTP message payload (carried within Sync message for one-step operation or Follow_up message for two-step operation) as follows:
  • Adds the link delay from the upstream TSN node in TSN GM time to the correction field.
  • Replaces the cumulative rateRatio received from the upstream TSN node with the new cumulative rateRatio.
  • Adds TSi in the Suffix field of the gPTP packet as described in Annex H.
UPF then forwards the gPTP message from TSN network to the UEs via all PDU sessions terminating in this UPF that the UEs have established to the TSN network. All gPTP messages are transmitted on a QoS Flow that complies with the residence time upper bound requirement specified in IEEE 802.1AS [104].
NOTE:
The sum of the UE-DS-TT residence time and the PDB of the QoS Flow needs to be lower than the residence time upper bound requirement for a time-aware system specified in IEEE 802.1AS [104].
A UE receives the gPTP messages and forwards them to the DS-TT. The DS-TT then creates egress timestamping (TSe) for the gPTP event (Sync) messages for external TSN working domains. The difference between TSi and TSe is considered as the calculated residence time spent within the 5G system for this gPTP message expressed in 5GS time. The DS-TT then uses the rateRatio contained inside the gPTP message payload (carried within Sync message for one-step operation or Follow_up message for two-step operation) to convert the residence time spent within the 5GS in TSN GM time and modifies the payload of the gPTP message that it sends towards the downstream TSN node as follows:
  • Adds the calculated residence time expressed in TSN GM time to the correction field.
  • Removes TSi from the Suffix field.
Up
5.27.1.3  Support for multiple TSN working domainsWord-p. 263
Each TSN working domain sends its own gPTP messages. The related Ethernet frames carry the gPTP multicast Ethernet destination MAC address and the gPTP message carries a specific PTP "domainNumber" that indicates the time domain they are referring to. The NW-TT makes ingress timestamping (TSi) for the gPTP event messages of all domains and forwards the gPTP messages of all domains to the UEs as specified in clause 5.27.1.2.2.
A UE receives gPTP messages and forwards them all to the DS-TT. The DS-TT receives the original TSN clock timing information and the corresponding TSi via gPTP messages for one or more TSN working domains. The DS-TT then makes egress timestamping (TSe) for the gPTP event messages for every external TSN working domain. Ingress and egress time stamping is based on the 5G system clock at NW-TT and DS-TT.
NOTE 1:
An end-station can select TSN timing information of interest based on the "domainNumber" in the gPTP message.
The process described in "Distribution of TSN clock and time-stamping" is thus repeated for each TSN working domain between a DS-TT and the NW-TT it is connected to.
NOTE 2:
If all TSN working domains can be made synchronous and the synchronization can be provided by the 5G clock, the NW-TT output ports towards the connected TSN networks propagate the 5G clock using the 802.1AS profile (i.e. the 5G system as an IEEE 802.1AS [104] compliant time-aware system).
NOTE 3:
In this Release of specification, support for multiple TSN working domains is limited related to IEEE 802.1AS [104] for time synchronization procedure but it does not apply to interaction involving TSN AF and CNC. The corresponding IEEE specifications (i.e. IEEE 802.1Q [98]) are supported only for one specific gPTP Domain and it is assumed that specific gPTP Domain is associated with IEEE 802.1Q [98].
Up
5.27.1a  Periodic deterministic QoS
This feature allows the 5GS to support periodic deterministic communication where the traffic characteristics are known a-priori, and a schedule for transmission from the UE to a downstream node, or from the UPF to an upstream node is provided via external protocols outside the scope of 3GPP (e.g. IEEE TSN).
The features include the following:
  • Providing TSC Assistance Information (TSCAI) that describe TSC flow traffic patterns at the gNB ingress and UE egress interfaces for traffic in downlink and uplink direction, respectively;
  • Support for hold & forward buffering mechanism in DS-TT and NW-TT to de-jitter flows that have traversed the 5G System.
Up
5.27.2  TSC Assistance Information (TSCAI)Word-p. 264
TSC assistance information describes TSC traffic characteristics for use in the 5G System. The knowledge of TSN traffic pattern is useful for the gNB to allow it to more efficiently schedule periodic, deterministic traffic flows either via Configured Grants, Semi-Persistent Scheduling or with dynamic grants. TSC assistance information, as defined in Table 5.27.2-1, is provided from SMF to 5G-AN, e.g. upon QoS Flow establishment. The TSCAI parameters are set according to corresponding parameters obtained from the TSN AF. The TSN AF gets per TSN stream traffic characteristics according to IEEE 802.1Q [98] clause 8.6.5.1 for 5GS bridge to identify the PDU session for the UL traffic.
The TSN AF is responsible for obtaining PSFP (IEEE 802.1Q [98]) parameters and use them to calculate traffic pattern parameters (such as burst arrival time with reference to the ingress port, periodicity, and flow direction) and responsible of forwarding these parameters in TSN QoS container to the SMF (via PCF). TSN AF may enable aggregation of TSN streams if the TSN streams belong to the same traffic class, terminate in the same egress port and have the same periodicity and compatible Burst arrival time. One set of parameters and one container are being calculated by the AF for multiple TSN streams to enable aggregation of TSN streams to the same QoS Flow.
Annex I describe how the traffic pattern information is determined.
NOTE 1:
Further details of aggregation of TSN streams (including determination of burst arrival times that are compatible so that TSN streams can be aggregated) are left for implementation.
In this case, TSN AF creates one TSN QoS container for the aggregated TSN streams. The SMF will bind PCC rules with a TSN QoS Container as described in clause 6.1.3.2.4 of TS 23.503. The SMF derives TSCAI on a per QoS Flow basis and send it to 5G-AN. The Burst Arrival Time and Periodicity component of the TSCAI that the SMF signals to the 5G-AN are specified with respect to the 5G clock. The SMF is responsible for mapping the Burst Arrival Time and Periodicity from a TSN clock to the 5G clock based on the time offset and cumulative rateRatio between TSN time and 5GS time as measured and reported by the UPF.
The TSCAI parameter determination in SMF is done as follows:
  • The SMF sets the DL TSCAI Burst Arrival Time as the sum of TSN QoS Burst Arrival Time and CN PDB as described in clause 5.7.3.4, and corrects this value by the previously received time offset measurement from the UPF.
  • The SMF sets the UL TSCAI Burst Arrival Time as the sum of TSN QoS Burst Arrival Time and UE-DS-TT Residence Time, and corrects this value by the previously received time offset measurement from the UPF.
  • The SMF sets the Periodicity as the TSN QoS Periodicity, and corrects this value by the previously received cumulative rateRatio measurement from the UPF.
NOTE 2:
In order to get Burst Arrival Time, Periodicity on a per TSN stream basis, support for IEEE 802.1Q [98] (as stated in clause 4.4.8.2) Per-Stream Filtering and Policing (PSFP) with stream gate operation is a prerequisite.
In the case of drift between TSN time and 5G time, the UPF updates the offset to SMF using the N4 Report Procedure as defined in TS 23.502, clause 4.4.3.4. In the case of change of cumulative rateRatio between TSN time and 5G time, the UPF updates the cumulative rateRatio to SMF using the N4 Report Procedure as defined in TS 23.502, clause 4.4.3.4. The SMF may then trigger a PDU Session Modification as defined in TS 23.502, clause 4.3.3 in order to update the TSCAI parameter to the NG-RAN without requiring AN or N1 specific signalling exchange with the UE.
NOTE 3:
In order to prevent frequent updates from the UPF, the UPF sends the offset or the cumulative rateRatio only when the difference between the current measurement and the previously reported measurement is larger than a threshold as described in TS 23.502, clause 4.4.3.4.
Assistance Information
Description

Flow Direction
The direction of the TSC flow (uplink or downlink).
Periodicity
It refers to the time period between start of two bursts.
Burst Arrival time
The arrival time of the data burst at either the ingress of the RAN (downlink flow direction) or egress interface of the UE (uplink flow direction).

Up
5.27.3  Support for TSC QoS FlowsWord-p. 265
TSC QoS Flows use a Delay Critical GBR resource type and TSC Assistance Information. TSC QoS Flows may use standardized 5QIs, pre-configured 5QIs or dynamically assigned 5QI values (which requires signalling of QoS characteristics as part of the QoS profile) as specified in clause 5.7.2. For each instance of Periodicity, within each Period (defined by periodicity value), TSC QoS Flows are required to transmit only one burst of maximum size MDBV within the 5G-AN PDB. Known QoS Flow traffic characteristics provided in the TSCAI may be used to optimize scheduling in the 5GS.
The following is applicable for the 5QI defined for TSC QoS Flows:
  1. The TSC Burst Size may be used to set the MDBV as follows:
  2. The maximum TSC Burst Size is considered as the largest amount of data within a time period that is equal to the value of 5G-AN PDB of the 5QI that was set for this traffic class. The maximum value of TSC Burst Size should be mapped to a 5QI with MDBV that is equal or higher. This 5QI also shall have a PDB value that satisfies the bridge delay capabilities reported for the corresponding traffic class. For TSC QoS Flows, the Maximum Burst Size of the aggregated TSC streams to be allocated to this QoS Flow can be similarly mapped to a 5QI with MDBV value that is equal or higher, and the PDB of this 5QI shall also satisfy the bridge delay capabilities reported.
  3. The PDB is explicitly divided into 5G-AN PDB and CN PDB as described in clause 5.7.3.4. Separate delay budgets are necessary for calculation of expected packet transmit times on 5G System interfaces. For the TSC QoS Flow, the5G-AN PDB is set to value of 5QI PDB minus the CN PDB as described in clause 5.7.3.4. The CN PDB may be static value or dynamic value and is up to the implementation of 5GS bridge.
Up
5.27.4  Hold and Forward Buffering mechanism
DS-TT and NW-TT support a hold and forward mechanism to schedule traffic as defined in IEEE 802.1Q [98] if 5GS is to participate transparently as a bridge in a TSN network. The Hold and Forward buffering mechanism allows PDB based 5GS QoS to be used for TSC traffic since packets need only arrive at NW-TT or DS-TT egress prior to their scheduled transmission time.
5GS provides AdminControlList and AdminBaseTime as defined in IEEE 802.1Q [98] on a per Ethernet port basis to DS-TT and NW-TT for the hold and forward buffer as described in clause 5.28.3.
NOTE:
How Hold and Forward buffer is supported by the TSN Translator is up to implementation.
Up
5.27.5  5G System Bridge delay
In order for the 5G System to participate as a TSN bridge according to gate schedules specified, the 5GS Bridge is required to provide Bridge Delays as defined in IEEE 802.1Qcc [95] for each port pair and traffic class of the 5GS bridge to an IEEE TSN system. In order to determine 5GS Bridge Delays, the following components are needed:
  1. UE-DS-TT Residence Time: the time taken within the UE and DS-TT to forward a packet between the UE and DS-TT port. UE-DS-TT Residence Time is provided at the time of PDU Session Establishment by the UE to the network.
  2. NOTE 1:
    UE-DS-TT Residence Time is the same for uplink and downlink traffic and applies to all traffic classes.
  3. Per traffic class delay between the UE and the UPF/NW-TT that terminates the N6 interface (including UPF and NW-TT residence times), independent of frame length that a given 5GS deployment supports. The per-traffic class delay between the UE and the UPF/NW-TT is pre-configured in the TSN AF (see clause 5.28.4).
The TSN AF calculates the 5GS independentDelayMin and independentDelayMax values for each port pair and for each traffic class using the above components.
NOTE 2:
With supporting the hold and forward buffering mechanism in UE-DS-TT and NW-TT, the values of independentDelayMax and independentDelayMin for 5GS Bridge can be the same.
The dependentDelayMin and dependentDelayMax for 5GS Bridge specify the time range for a single octet of an Ethernet frame to transfer from ingress to egress and include the time to receive and store each octet of the frame, which depends on the link speed of the ingress Port as per IEEE 802.1Qcc [95].
NOTE 3:
Further details how TSN AF determines dependentDelayMin and dependentDelayMax and is up to implementation.
Since Residence times may vary among UEs and among UPFs, the 5GS Bridge Delay is determined after the PDU Session Establishment for the corresponding UPF and the UE by the TSN AF. The TSN AF deduces the related port pair(s) from the port number of the DS-TT Ethernet port and port number of the serving NW-TT Ethernet port(s) when the TSN AF receives the 5GS Bridge information for a newly established PDU Session and caculates the bridge delays per port pair.
Up

Up   Top   ToC