Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.501  Word version:  17.0.0

Top   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  Enablers for Time Sensitive Communications and Time Synchronization |R16|Word‑p. 274

5.27.0  General

This clause describes 5G System features that can be independently used to enable time-sensitive communication and time synchronization:
  • Delay-critical GBR;
  • A hold and forward mechanism to schedule traffic as defined in IEEE Std 802.1Q-2018 [98] for Ethernet PDU sessions if 5GS is to participate transparently as a bridge in a TSN network;
  • TSC Assistance Information: describes traffic characteristics that may be provided optionally for use by the gNB, to allow more efficiently schedule radio resources for periodic traffic and applies to PDU session type Ethernet and IP.
  • Time Synchronization: describes how 5GS can operate as a PTP Relay (IEEE 802.1AS [104]), as a Boundary Clock or as Transparent Clock (IEEE 1588 [X]) for PDU session type Ethernet and IP.
The 5G System integration as a bridge in an IEEE 802.1 TSN network as described in clause 5.28 can make use of all features listed above.
To support any of the above features to enable time-sensitive communication and time synchronization, during the PDU Session establishment, the UE shall request to establish a PDU Session as an always-on PDU Session, and the PDU Sessions are established as Always-on PDU session as described in clause 5.6.13. In this release of the specification, to use any of the above features to enable time-sensitive communication and time synchronization:
  • Home Routed PDU Sessions are not supported;
  • PDU Sessions are supported only for SSC mode 1;
  • Service continuity is not supported when the UE moves from 5GS to EPS.
Up

5.27.1  Time Synchronization

5.27.1.1  General

For supporting time synchronization service, the 5GS is configured to operate in one of the following modes (if supported):
  1. as time-aware system as described in IEEE Std 802.1AS [104],
  2. as Boundary Clock as described in another IEEE Std 1588-2019 [126] profile,
  3. as peer-to-peer Transparent Clock as described in another IEEE Std 1588-2019 [126] profile, or
  4. as end-to-end Transparent Clock as described in another IEEE Std 1588-2019 [126] profile.
The configuration of the time synchronization service in 5GS for option 1 by TSN AF and CNC is described in clause 5.28.3, and for options 1-4 by AF and NEF in clause 5.27.1.z.
The 5GS shall be modelled as an IEEE Std 802.1AS [104] or IEEE Std 1588-2019 [126] compliant entitybased on the above configuration.
The TSN Translators (TTs) at the edges of the 5G system may support the IEEE Std 802.1AS [104] or other IEEE Std 1588-2019 [126] profiles' operations respective to the configured mode of operation. The 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 some functions related to IEEE Std 802.1AS [104] and may fulfill some functions related to other IEEE Std 1588-2019 [126] profiles, e.g. (g)PTP support and timestamping. Figure 5.27.1-1 illustrates the 5G and PTP grandmaster (GM) clock distribution model via 5GS.
Reproduction of 3GPP TS 23.501, Figure 5.27.1-1: 5G system is modelled as PTP instance for supporting time synchronization
Up
Figure 5.27.1-1 depicts the two synchronizations systems considered: the 5GS synchronization and the (g)PTP domain synchronization, as well as the Master (M) and Slave (S) ports considered when the PTP GM is located at (g)PTP network outside of 5GS.
  • 5GS synchronization: Used for NG RAN synchronization. 5G RAN synchronization is specified in TS 38.331.
  • (g)PTP domain synchronization: Provides synchronization service to (g)PTP network. This process follows IEEE Std 802.1AS [104] or IEEE Std 1588-2019 [126].
For the case of 5G system modelled as a Transparent clock or as an IEEE 802.1AS Boundary Clock, the two synchronization processes can be considered independent from each other and the gNB only needs to be synchronized to the 5G GM clock.
The 5GS supports two methods for determining the grandmaster PTP Instance and the time-synchronization spanning tree.
  • Method a), BMCA procedure.
  • Method b), local configuration.
This is further described in clause 5.27.1.6.
Up

5.27.1.2  Distribution of timing informationWord‑p. 275
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 signalling 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 grandmaster clock and time-stamping
5.27.1.2.2.1  Distribution of gPTP Sync and Follow_Up messages |R17|
The mechanisms for distribution of TSN GM clock and time-stamping described in this clause are according to IEEE Std 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 Std 802.1AS [104]. NW-TT then calculates the new cumulative rateRatio (i.e. the cumulative rateRatio of the 5GS) as specified in IEEE Std 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 Std 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 Suffix field that contains TSi.
Up
5.27.1.2.2.2  Distribution of PTP Sync and Follow_Up messages |R17|Word‑p. 276
This clause applies if DS-TT and NW-TT support distribution of PTP Sync and Follow_Up messages. PTP support by DS-TT and NW-TT may be determined as described in clause K.2.1.
The mechanisms for distribution of PTP GM clock and time-stamping described in this clause are according to Transparent clock as defined in IEEE Std 1588-2019 [126].
Upon reception of a PTP event message from the upstream PTP instance, the ingress TT (i.e. NW-TT or DS-TT) makes an ingress timestamping (TSi) for each PTP event (i.e. Sync) message.
The PTP port in the ingress TT measures the link delay from the upstream PTP instance as described in clause H.4.
If the 5GS is configured to operate as a peer-to-peer Transparent Clock in a PTP domain and the corresponding PTP profile uses rateRatio, where rateRatio is measured, then the PTP port in the ingress TT uses the cumulative rateRatio received inside the PTP message payload (carried within Sync message for one-step operation or Follow_Up message for two-step operation) to correct the measured link delay to be expressed in PTP GM time as specified in IEEE Std 1588-2019 [126]. The PTP port in the ingress TT then calculates the new cumulative rateRatio (i.e. the cumulative rateRatio of the 5GS) as specified in IEEE Std 1588-2019 [126].
The PTP port in the ingress TT modifies the PTP message payload (carried within Sync message for one-step operation or Follow_Up message for two-step operation) as follows:
  • (if the PTP port in the ingress TT has measured the link delay) Adds the measured link delay from the upstream PTP instance in PTP GM time to the correction field.
  • (if the PTP port in the ingress TT has measured the link delay and rateRatio is used) Replaces the cumulative rateRatio received from the upstream PTP instance with the new cumulative rateRatio.
  • Adds TSi in the Suffix field of the PTP message as described in clause H.2.
The PTP port in the ingress TT then forwards the PTP message to the UPF/NW-TT. The UPF/NW-TT further distributes the PTP message as follows:
  • If the 5GS is configured to operate as Boundary Clock as described in IEEE Std 1588-2019 [126], the UPF/NW-TT regenerates the Sync messages based on the received Sync messages for the Master ports in NW-TT and DS-TT(s). The NW-TT/UPF forwards the regenerated Sync messages to the PDU session(s) related to the Master ports in the DS-TT(s).
  • If the 5GS is configured to operate as a Transparent Clock as described in IEEE Std 1588-2019 [126], the UPF/NW-TT forwards the received Sync messages to DS-TT(s) via all PDU Sessions terminating to this UPF, and to NW-TT ports, except toward the ingress PTP port in the ingress TT.
The PTP port in the egress TT then creates egress timestamping (TSe) for the PTP event (i.e. Sync) messages for external PTP network. The difference between TSi and TSe is considered as the calculated residence time spent within the 5G system for this PTP message expressed in 5GS time.
The PTP port in the egress TT then uses the rateRatio contained inside the PTP message payload (if available, 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 PTP GM time.
The PTP port in the egress TT modifies the payload of the PTP message that it sends towards the downstream PTP instance as follows:
  • Adds the calculated residence time to the correction field (Sync message for one-step operation or Follow_Up message for two-step operation).
  • Removes Suffix field of the gPTP message that contains TSi.
Up

5.27.1.3  Support for multiple TSN working domainsWord‑p. 277
This clause describes support for multiple domains for gPTP and PTP and for GM clocks connected to DS-TT and NW-TT and only applies if DS-TT and NW-TT support the related functionality. PTP support and support of gPTP for GM clocks connected to DS-TT by DS-TT and NW-TT may be determined as described in clause K.2.1.
Each (g)PTP domain sends its own gPTP messages. The (g)PTP message carries a specific PTP "domainNumber" that indicates the time domain they are referring to. The PTP port in ingress TT makes ingress timestamping (TSi) for the (g)PTP event messages of all domains and forwards the (g)PTP messages of all domains to the egress TT as specified in clause 5.27.1.2.2.
The PTP port in the egress TT receives the original PTP GM clock timing information and the corresponding TSi via (g)PTP messages for one or more (g)PTP domains. The PTP port in the egress TT then makes egress timestamping (TSe) for the gPTP event messages for every (g)PTP domain. Ingress and egress time stamping are based on the 5G system clock at NW-TT and DS-TT.
The process described in clause 5.27.1.2.2 is thus repeated for each (g)PTP domain between a DS-TT and the NW-TT it is connected to.
Up

5.27.1.4  DS-TT and NW-TT Time Synchronization functionality |R17|Word‑p. 278
DS-TT and NW-TT may support the following PTP instance types:
  • Boundary Clock as defined in IEEE Std 1588-2019 [126];
  • End-to-End Transparent Clock as defined in IEEE Std 1588-2019 [126];
  • Peer-to-Peer Transparent Clock as defined in IEEE Std 1588-2019 [126];
  • PTP Relay instance (i.e. time-aware system) as defined in IEEE Std 802.1AS [104].
DS-TT and NW-TT may support the following transports for PTP:
  • IPv4 as defined in IEEE Std 1588-2019 [126] Annex C;
  • IPv6 as defined in IEEE Std 1588-2019 [126] Annex D;
  • IEEE 802.3 (Ethernet) as defined in IEEE Std 1588-2019 [126] Annex E.
For operation as a Boundary clock or as a Transparent Clock, DS-TT and NW-TT may support the following path and link delay measurement methods:
  • Delay request-response mechanism as described in IEEE Std 1588-2019 [126] clause 11.3;
  • Peer-to-peer delay mechanism as defined in IEEE Std 1588-2019 [126] clause 11.4.
DS-TT and NW-TT may support acting as a PTP grandmaster, i.e. may support generating (g)PTP Announce, Sync and Follow_Up messages.
DS-TT and NW-TT may also support PTP profiles as described in IEEE Std 1588-2019 [126] clause 20.3, i.e.:
  • IEEE Std 802.1AS [104] PTP profile for transport of timing as defined in IEEE Std 802.1AS [104] Annex F;
  • SMPTE Profile for Use of IEEE Std 1588 [126] Precision Time Protocol in Professional Broadcast Applications [127].
TSN AF and NEF may determine the PTP functionalities supported by DS-TT and NW-TT and may configure PTP instances in DS-TT and NW-TT using port and bridge management information exchange as described in Annex K, clause K.2.
Up

5.27.1.5  Detection of (g)PTP Sync and Announce timeouts |R17|

The procedure described in this clause is applicable when the PTP instance in 5GS is configured to operate as a time-aware system or as a Boundary Clock, and the PTP grandmaster is external to the 5GS, and the BMCA procedure (Method a) is used as described in clause 5.27.1.6.
The configuration of PTP instances in DS-TT and NW-TT for Sync and Announce timeouts is described in clause K.2.
The NW-TT shall compute and maintain the time when the Announce and Sync timeout events occur for the PTP port in a Slave state. When the 5GS is configured to operate as a time-aware system, the NW-TT shall determine the Sync and Announce message interval for the PTP Port at the other end of the link to which the Slave PTP Port in 5GS is attached, as described in IEEE Std 802.1AS [104]. When the 5GS is configured to operate as a Boundary Clock, the NW-TT shall determine Announce interval based on the configuration of the Slave port in 5GS, as described in IEEE Std 1588-2019 [126].
Upon detection of the Sync or Announce timeout event, the NW-TT shall re-evaluate the DS-TT and NW-TT port states as described in clause 5.27.1.6.
The TSN AF or NEF may subscribe for changes of the DS-TT and NW-TT PTP port states via BMIC.
Up

5.27.1.6  Distribution of Announce messages and best master clock selection |R17|Word‑p. 279
The procedure described in this clause is applicable if DS-TT and NW-TT support operating as a Boundary Clock or as a time-aware system and when the PTP instance in 5GS is configured to operate as a time-aware system or as a Boundary Clock. Whether DS-TT/NW-TT support operating as a Boundary Clock or as a time-aware system (support of the IEEE Std 802.1AS [104] PTP profile) may be determined as described in clause K.2.1.
The externally-observable behaviour of the Announce message handling by 5GS needs to comply with IEEE Std 802.1AS [104] or IEEE Std 1588-2019 [126], respective to the configured mode of operation.
The DS-TT forwards the received Announce messages to NW-TT over User plane. The NW-TT port forwards the received Announce messages from N6 interface to NW-TT.
The NW-TT maintains the PTP port state for each DS-TT port and NW-TT port. The PTP port states may be determined by NW-TT either via:
  • Method a), BMCA procedure.
  • Method b), local configuration.
When Method b) is used, the following applies:
  • When the PTP GM is external to the 5GS and when using IEEE Std 802.1AS [104] profile, for one of the NW-TT or DS-TT ports (per each PTP domain) the PTP port state is Slave and for all other NW-TT and DS-TT ports of the same PTP domain the PTP port state is set either to Passive or Master (depending on implementation).
  • When the 5GS is configured as a grandmaster for a (g)PTP domain for the connected networks, all NW-TT ports and DS-TT ports are set to Master state for that (g)PTP domain.
The local configuration of PTP port states in DS-TT and NW-TT for Method b is described in clause K.2.
When the Method a) is used (PTP port states are determined by BMCA procedure), the NW-TT needs to process the received Announce messages (from NW-TT port(s) and over user plane from the DS-TT(s)) for BMCA procedure, determine port states within the 5GS, and maintain the Master-Slave hierarchy.
When the 5GS Clock is determined as a grandmaster for a (g)PTP domain, the Announce messages are distributed as described in clause 5.27.1.7.
In the case of using IEEE Std 802.1AS [104] profile, when the grandmaster is external to the 5GS, the NW-TT regenerates the Announce messages based on the received Announce messages for the Master ports in NW-TT and DS-TT(s). The NW-TT/UPF forwards the regenerated Announce messages to the PDU session(s) related to the Master ports in the DS-TT(s).
Up

5.27.1.7  Support for PTP grandmaster function in 5GS |R17|Word‑p. 280
The 5GS that is configured to operate as a time-aware system or Boundary Clock may support acting as a PTP grandmaster for a (g)PTP domain.
The configuration of PTP instances in DS-TT and NW-TT for PTP grandmaster function is described in clause K.2.
The following options may be supported (per DS-TT) for the 5GS to generate the Sync, Follow_Up and Announce messages for the Master ports on the DS-TT:
  1. NW-TT generates the Sync, Follow_Up and Announce messages on behalf of DS-TT (e.g. if DS-TT does not support this).
    The NW-TT/UPF forwards the generated Sync, Follow_Up and Announce messages to the PDU session(s) related to the Master ports on the DS-TT(s). The NW-TT timestamps the (g)PTP event message when the event message is sent to the PDU Session, and adds TSi corresponding to the timestamp to the Sync message and the preciseOriginTimestamp to correspond to the timestamp to Sync message (if one-step operation is used) or to Follow_Up message (if two-step operation is used), and sets the cumulative rateRatio value with 1.
    When DS-TT(s) receive the Sync, Follow_Up messages, it modifies the payload of the Sync, Follow_Up message as described for the PTP port in the egress TT in clause 5.27.1.2.2.2.
  2. DS-TT generates the Sync, Follow_Up and Announce messages in this DS-TT.
In both options, the NW-TT generates the Sync, Follow_Up and Announce messages for the Master ports on the NW-TT.
Up

5.27.1.8  Exposure of Time Synchronization |R17|

5G System supports time synchronization service that can be activated and deactivated by AF. Exposure of time synchronization comprises the following capabilities:
  • The AF may learn 5GS capabilities to support time synchronization.
  • The AF may request time synchronization service with specific requirements and supply information that can be used to configure time synchronization distribution for targeted UE(s). The AF controls activation and deactivation of the time synchronization service for the target UE(s).
The NEF exposes the 5GS capabilities to support time synchronization service to the AF. The exposed information may include the supported time synchronization distribution methods (i.e. supported IEEE Std 1588 [126] or IEEE Std 802.1AS [104] operation modes or Access Stratum-based 5G clock sync).
The AF requests sent to the NEF may target a UE or multiple UEs. The request may include the following information:
  • Target UE(s) Identification. This may correspond to:
    • Individual UEs identified using GPSI, or an IP address/Prefix or a MAC address. Any UE accessing the combination of DNN, S-NSSAI and DNAI(s).
  • Requested time synchronization distribution method:
    • IEEE Std 1588 [126] or IEEE Std 802.1AS [104] operation (i.e. as a Boundary Clock, peer-to-peer Transparent Clock, or end-to-end Transparent Clock or as a PTP relay instance).
    • Access Stratum-based 5G clock sync. In this case, the time source is provided by the 5GS. 5G-AN provides a 5GS reference time to the UE via 3GPP radio access; UE/DS-TT may provide 5G reference timing information to end stations using implementation specific means. This method is applicable for both IP and ETH PDU Sessions.
  • For IEEE Std 1588 [126] or IEEE Std 802.1AS [104] operation, information to be used by NEF to configure IEEE Std 1588 or IEEE Std 802.1AS functionality in DS-TT or NW-TT, if applicable.
  • Spatial Validity Condition on the UE(s) location as described in clause 5.6.7.1.
    The NEF uses the Time Synchronization parameters received from AF. When IEEE Std 1588 [126] or IEEE Std \endul
    802.1AS [104] operation have been selected, the NEF determines the necessary (g)PTP parameters to activate and control the service in DS-TT(s) and NW-TTs. For this purpose, the NEF uses the PMIC or BMIC to manage the IEEE Std 1588 [126] or IEEE Std 802.1AS [104] operation in the DS-TT or NW-TT, respectively (see clause 5.27.1.4).
  • FFS the time synchronization information provided by the AF that may be stored in the UDR and how the NEF may update or revoke information at the UDR for existing or future PDU Sessions.
    For handling (g)PTP traffic, the PCF, according to PCC rule authorization, chooses a 5QI and dynamically set the PDB and/or MDBV according to requirements for (g)PTP protocol. The PCF provides the SMF with a PCC rule generated based on the AF request. The SMF may take the information in the PCC rule to may decide to modify or establish a PDU Session to create or modify or release a QoS flow for transmitting the (g)PTP messages. The PCF acknowledges the time synchronization service request to the NEF and the NEF replies to the AF with the result.
Up

5.27.1a  Periodic deterministic QoSWord‑p. 281
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 802.1 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 (see clause 5.27.4) in DS-TT and NW-TT to de-jitter flows that have traversed the 5G System.
Up

5.27.2  TSC Assistance Information (TSCAI)

5.27.2.1  General |R17|

TSC Assistance Information (TSCAI) describes TSC traffic characteristics for use in the 5G System. TSCAI may optionally be used by 5G-AN if provided by SMF. The knowledge of TSC traffic pattern is useful for 5G-AN to allow it to more efficiently schedule periodic, deterministic traffic flows either via Configured Grants, Semi-Persistent Scheduling or with Dynamic Grants.
NEF may determine TSC Assistance Container based on information provided by an AF as in clause 5.27.2.3 and may provide it to PCF for IP type and Ethernet type PDU sessions. In case of integration with IEEE TSN network, TSN AF may determine TSC Assistance Container as described in clause 5.27.2.2 and provide it to PCF for Ethernet PDU sessions in case of integration with IEEE TSN. PCF provides the TSC Assistance Container to SMF as part of PCC rules.
For TSC, the AF provides the traffic pattern parameters such as Burst Arrival Time with reference to the ingress port, Periodicity, Flow Direction and Survival Time to the NEF. The NEF is responsible for forwarding these parameters in TSC Assistance Container to the SMF (via PCF).
SMF binds PCC rules with a TSC Assistance Container as described in clause 6.1.3.2.4 of TS 23.503. SMF uses the TSC Assistance Container to derive TSCAI as defined in Table 5.27.2-1 on a per QoS Flow basis and sends it to NG-RAN. The Periodicity, Burst Arrival Time, and Survival Time components of the TSCAI that the SMF signals to the NG-RAN are specified with respect to the 5G clock. The SMF may update the TSCAI to NG-RAN as part of handover procedure as defined in TS 23.502, clauses 4.9.1.2.2 and 4.9.1.3.2. The SMF is responsible for mapping the Burst Arrival Time and Periodicity from an external clock (when available) to the 5G clock based on the time offset and cumulative rateRatio between the external clock time and 5GS time as measured and reported by the UPF. The SMF may correct the TSCAI based on the UPF report for time offset and cumulative rateRatio between external PTP time and 5GS time as measured and reported by the UPF.
Survival Time may be provided by TSN AF/AF either in terms of maximum number of messages or in time units, where a time unit is equivalent to the Periodicity. During a single period, single burst is expected. If Survival Time is provided in terms of maximum number of messages, the SMF coverts it into time units by multiplying its value by the Periodicity provided in the TSCAI Container. The SMF corrects the Survival Time in time units by the previously received cumulative rateRatio from the UPF and sets the TSCAI Survival Time to the corrected value.
Assistance Information Description
Flow DirectionThe direction of the TSC flow (uplink or downlink).
PeriodicityIt refers to the time period between start of two bursts.
Burst Arrival time (Optional)The latest possible time when the first packet of the data burst arrives at either the ingress of the RAN (downlink flow direction) or egress interface of the UE (uplink flow direction).
Survival Time (Optional)It refers to the time period an application can survive without any burst, as defined in clause C.2.3 of TS 22.104.
Up

5.27.2.2  TSC Assistance Container determination based on PSFP |R17|Word‑p. 282
The determination of TSC Assistance Container based on Per-Stream Filtering and Policing (PSFP) information applies only to Ethernet type PDU Sessions.
The TSCAI parameters are set according to corresponding parameters obtained from the TSN AF, when available. The TSN AF may be able to identify the ingress port and thereby the PDU session as described in clause 5.28.2.
The TSN AF interfaces towards the CNC for the PSFP (IEEE Std 802.1Q [98]) managed objects that correspond to the PSFP functionality implemented by the DS-TT and the NW-TT. Thus, when PSFP information is provided by the CNC, the TSN AF may extract relevant parameters from the PSFP configuration. The TSN AF calculates traffic pattern parameters (such as burst arrival time with reference to the ingress port and periodicity). TSN AF also obtains the flow direction as specified in clause 5.28.2. Survival time may be pre-configured in TSN AF. TSN AF is responsible for forwarding these parameters in TSC Assistance 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. When Survival Time information is provided for a TSN stream, then it should not be aggregated with other TSN streams into a single QoS flow, or if they are aggregated, then the Survival Time parameter shall not be provided. One set of parameters and one container are calculated by the TSN 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.
In this case, TSN AF creates one TSC Assistance Container for the aggregated TSN streams. 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.
For UE-UE TSC stream, the (TSN) AF divides the stream into one uplink stream and one or more downlink streams as defined in clause 5.28.2. The TSN AF binds the uplink and downlink streams to the PDU Sessions, and provides the streams on PDU Session basis to the PCF(s). The TSN AF calculates traffic pattern parameters for the UL and the DL stream using the PSFP configuration (if provided) respectively:
  • For the uplink stream, the Flow Direction is set to uplink and traffic pattern parameters (such as burst arrival time with reference to the ingress port and periodicity) is determined as described in Annex I.
  • For downlink stream, the Flow Direction is set to downlink, the burst arrival time is set to sum of burst arrival time of the UL stream and 5GS Bridge delay of PDU session carrying the UL stream, and the periodicity is determined as described in Annex I.
Up

5.27.2.3  TSC Assistance Container determination by NEF |R17|Word‑p. 283
The NEF constructs TSC Assistance Container based on information provided by the AF for IP or Ethernet type PDU Sessions.
The AF may provide Flow Direction, Burst Arrival Time at the UE/DS-TT (uplink) or UPF/NW-TT (downlink), Burst Size, Periodicity, Survival Time, and a Time Domain to the NEF. Based on these parameters, the NEF constructs a TSC Assistance Container and provides it to PCF.
The NEF sends the TSC Assistance Container to PCF as follows:
  • The NEF uses the UE IP address/MAC address to identify the PCF and N5 association related to the PDU Session of UE/DS-TT.
Up

5.27.2.4  TSCAI determination based on TSC Assistance Container |R17|

This clause is applicable when TSC Assistance Container is determined either by TSN AF or by the NEF.
The SMF is responsible for mapping the Burst Arrival Time and Periodicity in the TSC Assistance Container from an external clock to the 5G clock based on the time offset and cumulative rateRatio between external time and 5GS time as measured and reported by the UPF.
The TSCAI parameter determination in SMF is done as follows:
  • For traffic in downlink direction, the SMF corrects the Burst Arrival Time in the TSC Assistance Container based on the latest received time offset measurement from the UPF and sets the TSCAI Burst Arrival Time as the sum of the corrected value and CN PDB as described in clause 5.7.3.4, representing the latest possible time when the first packet of the data burst arrives at the AN.
  • For traffic in uplink direction, the SMF corrects the Burst Arrival Time in the TSC Assistance Container based on the latest received time offset measurement from the UPF and sets the TSCAI Burst Arrival Time as the sum of the corrected value and UE-DS-TT Residence Time, representing the latest possible time when the first packet of the data burst arrives at the egress of the UE.
  • The SMF corrects the Periodicity in the TSC Assistance Container by the previously received cumulative rateRatio from the UPF and sets the TSCAI Periodicity as the corrected value.
  • The SMF sets the TSCAI Flow Direction as the Flow Direction in the TSC Assistance Container.
If the SMF has clock drift information for the Time Domain in the TSC Assistance Container (i.e. clock drift between 5G timing and AF supplied Time Domain determined based on UPF reporting), then 5GS may adjust the TSCAI information so that it reflects the 5GS Clock as described in clause 5.27.2.1. If Time Domain information is not provided or the SMF does not have synchronization information for a requested Time Domain, then the TSCAI information will be used without adjustment.
In the case of drift between external GM clock and 5G clock, 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 external PTP 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 to the NG-RAN without requiring AN or N1 specific signalling exchange with the UE.
Up

5.27.3  Support for TSC QoS FlowsWord‑p. 284
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 QoS profile defined for TSC QoS Flows:
  1. The TSC Burst Size may be used to set the MDBV as follows:
    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 (see clause 5.27.5 for more details) 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.
  2. 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.
  3. The Maximum Flow Bitrate calculated by the TSN AF as per Annex I.1 may be used to set GBR. In this case, MBR is set equal to GBR.
  4. ARP is set to a pre-configured value.
Up

5.27.4  Hold and Forward Buffering mechanism

DS-TT ports and NW-TT ports support a hold and forward mechanism to schedule traffic as defined in IEEE Std 802.1Q-2018 [98] if 5GS is to participate transparently as a bridge in a TSN network. That is, the hold and forward buffering mechanism in this release of the specification provides externally observable behavior identical to scheduled traffic with up to eight queues (clause 8.6.8.4 in IEEE Std 802.1Q-2018 [98]) and with protected windows (Annex Q.2 in IEEE Std 802.1Q-2018 [98]). Frames are only transmitted from a given buffer according to the open time interval of the corresponding transmission gate; otherwise, frames are hold back (which corresponds to a closed transmission gate). The protected windows scheme implies that only a single transmission gate is open at any single time. Thus, the Hold and Forward buffering mechanism allows PDB based 5GS QoS to be used for TSC traffic.
To achieve externally observable behavior according to the protected windows scheme, 5GS provides AdminControlList, AdminBaseTime, AdminCycleTime and TickGranularity as defined in IEEE Std 802.1Q [98] on a per Ethernet port basis to DS-TT and NW-TT for the hold and forward buffering mechanism as described in clause 5.28.3.
Up

5.27.5  5G System Bridge delay

This clause applies if 5GS is integrated as a bridge into an IEEE TSN network.
In order for the 5G System to participate as a TSN bridge according to transmission gate schedules specified, the 5GS Bridge is required to provide Bridge Delays as defined in IEEE Std 802.1Qcc [95] for each port pair and traffic class of the 5GS bridge to an IEEE 802.1 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. Per traffic class minimum and maximum delays 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 delays between the UE and the UPF/NW-TT are 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.
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 Std 802.1Qcc [95].
Since Residence times may vary among UEs and per traffic class delay between the UE and the UPF/NW-TT may vary 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 NW-TT Ethernet port(s) of the same 5GS Bridge when the TSN AF receives the 5GS Bridge information for a newly established PDU Session and calculates the bridge delays per port pair. Additionally, TSN AF deduces the port pair(s) consisting of two DS-TT ports connecting to the same 5GS bridge and determines the 5GS bridge delay as sum of bridge delays related to PDU Sessions of two DS-TT ports.
Up


Up   Top   ToC