Special Articles on 3GPP Release 17 Standardization Activities
Advanced Technologies for Deterministic Communications in 3GPP Releases 16 and 17

5GS TSN Time Synchronization

Jari Mutikainen and Riccardo Guerzoni
DOCOMO Communications Laboratories Europe GmbH

Atsushi Minokuchi
Core Network Development Department

Abstract
5GS supports deterministic communications to guarantee bounded delay, no packet collisions, and high reliability. In 3GPP Rel-16, 5GS is integrated with IEEE 802.1Q bridged networks to support Ethernet-based deterministic communications for the manufacturing industry and related industrial applications. In addition, 5GS extended in Rel-17 also supports IP-based deterministic communications.

01. Introduction

  • The 3rd Generation Partnership Project (3GPP)*1 has ...

    Open

    The 3rd Generation Partnership Project (3GPP)*1 has established the main requirements of deterministic communications in 3GPP Release 16 (Rel-16) for the 5G System (5GS)*2 to support the manufacturing industry and related industrial applications.

    Today’s industrial applications ordinarily use various types of Ethernet systems. This situation has generated a need for unifying industrial Ethernet specifications, and studies for this purpose have been progressing. The Institute of Electrical and Electronics Engineers Time-Sensitive Networking (IEEE TSN)*3 is a series of standards to provide deterministic communications in IEEE 802 networks. These standards are expected to be applied in common to industrial Ethernet systems in the future.

    At 3GPP, Rel-16 specifies system architecture and procedures that enable 5GS to be a virtual IEEE 802.1Q*4 bridge*5 having TSN functions and to integrate seamlessly with an IEEE TSN network. A 5GS bridge also supports time synchronization specified by IEEE 802.1AS*6. This is an essential constituent element in IEEE TSN for providing TSN stream*7 bounded delay*8 by time-aware scheduling.

    To provide bounded delay, no collisions, and high reliability in communications, it is necessary to grasp traffic characteristics before initiating actual communications and prepare the network accordingly.

    In Rel-16, central control equipment, that is, a Central Network Controller (CNC)*9 defined in IEEE 802.1Qcc [1] controls 5GS. The CNC presents 5GS with traffic characteristics using IEEE 802.1Q managed objects*10, and based on that traffic, 5GS prepares necessary resources for mobile communications and the core network.

    In Rel-17, deterministic communications was extended and a 3GPP original service interface for reserving resources was specified. With this interface, an external network can present traffic characteristics to 5GS as part of the 3GPP Quality of Service (QoS)*11 resource reservation procedure. This capability is useful for a network not deploying IEEE TSN or a network that cannot deploy IEEE TSN such as IP-based networks.

    In addition to supporting Ethernet-based time synchronization [2], Rel-17 adds support for IP-based time synchronization based on IEEE 1588 specifications [3]. Along with the importance placed on Ethernet-based time synchronization in the field of manufacturing, IP-based time synchronization is needed by an even greater variety of use cases as can be found in the professional audio/visual production industry. In addition, Rel-17 specifies a service interface that enables 5GS time synchronization functions to be controlled by an external network.

    This article provides an overview of 5GS deterministic communications functions specified in Rel-16 and Rel-17.

    1. 3GPP: An organization that creates standards for mobile communications systems.
    2. 5GS: A 5G network system comprised of a core network, radio access network, and communications devices (UE).
    3. IEEE TSN: A series of standards prescribed by IEEE or a network constructed on the basis of those standards for handling data streams that must be transmitted without exceeding allowable values for delay and jitter (see *13).
    4. IEEE 802.1Q: A standard related to networks based on bridges (see *5) and bridge configurations in local and metropolitan area networks.
    5. Bridge: Network equipment having multiple ports for relaying Ethernet frames between those ports in line with the IEEE 802.1Q standard.
    6. IEEE 802.1AS: A standard related to time synchronization control in local and metropolitan area networks.
    7. Stream: A sequence of data for which the network is requested to perform specific and identical processing.
    8. Bounded delay: The ability to predict maximum delay and fluctuation in maximum delay.
    9. CNC: A component that controls a TSN bridge in TSN.
    10. Managed objects: A series of information that express specific constituent elements of the network.
    11. QoS: Network quality set for each service. Controlling bandwidth, delay, or packet-loss rate.

    • 02. Use Cases of Deterministic Communications

  • Deterministic communications is a network function provided for ...

    Open

    Deterministic communications is a network function provided for Time-Sensitive Communication (TSC)*12 that guarantees maximum delay, maximum jitter*13, and no packet collisions. Use cases that can be envisioned in deterministic communications are described below.

    2.1 Manufacturing Industry

    A major application field of deterministic communications is the manufacturing industry. In the past, achieving communications with tight time constraints was achieved through the use of industrial protocols based on a field bus*14, but this approach eventually evolved into the use of industrial Ethernet (such as PROFINET, Ethernet/IP, and CC-Link IE). Industrial Ethernet is a specialized form of Ethernet that guarantees low delay and bandwidth for real-time communications required in automation and control systems.

    Since IEEE specifications did not support such real-time communications by Ethernet, a variety of forums in the industrial world came to define original solutions to this issue. However, applying such original solutions to an IEEE Ethernet network required hardware changes to Ethernet bridges conforming to IEEE standards.

    To make up for this deficiency, IEEE decided to standardize TSN to make it possible to support real-time communications in an Ethernet network conforming to IEEE standards. The main advantage of IEEE TSN is that it can provide deterministic communications for industrial data having tight time constraints using a general-purpose Ethernet bridge while providing best-effort services for other types of data.

    Some industrial Ethernet-based protocols such as PROFINET and CC-Link IE have been recently updated to include support for IEEE TSN. The goal of supporting IEEE TSN in Rel-16 5GS was to support such industrial protocols.

    Although some industrial protocols do not require deterministic real-time communications functions provided by IEEE TSN, they do require IEEE TSN time synchronization functions [3]. For example, since time stamps*15 are passed in Ethernet/IP applications, times in the applications on the transmitting and receiving sides must be synchronized.

    2.2 Real-time Media Applications

    Another use case of deterministic communications is real-time media applications such as real-time audio/video, cloud-based games, Augmented Reality (AR)*16, Mixed Reality (MR)*17, and Virtual Reality (VR). Traffic in such applications often exhibits patterns in periodicity, burst size*18, etc. Such traffic must be efficiently transmitted, combined, and played back without exceeding allowable values for delay and jitter.

    In contrast to industrial applications, these types of application protocols are ordinarily transmitted using User Datagram Protocol (UDP)*19/IP. These application protocols transmit time stamps enabling the listener to synchronize data frames. In audio/video production, for example, an audio/video mixer that obtains streams from multiple sources such as microphones and cameras is one example of a listener. Here, each data source adds time stamps to transmitted streams and the listener must be able to synchronize multiple received streams. In other words, this use case must synchronize time between each data source and listener.

    Today, time synchronization is provided by deploying a Global Navigation Satellite System (GNSS)*20 receiver near data sources and listener. GNSS is used as a time source, in which a common reference time is distributed to applications participating in communications from a GNSS receiver. In the audio/video production industry, the Society of Motion Picture and Television Engineers (SMPTE) Profile*21 [4] is ordinarily used as an IEEE 1588 Precision Time Protocol (PTP)*22 for time synchronization between a GNSS receiver and application.

    This technique, however, requires many GNSS receivers if data sources and listeners are scattered across a wide area, and using GNSS receivers indoors has been a problem from the start. In Rel-17, a focus was placed on 5GS support of IEEE 1588 PTP and on more flexible use of 5GS as a time source with the aim of solving this problem.

    1. TSC: A communications service specified by 3GPP for handling data streams that must be transmitted without exceeding allowable values for delay and jitter (see *13).
    2. Jitter: Fluctuations in delay time and misalignments along the time axis in signals.
    3. Field bus: A generic term for multiple types of industrial network technologies that evolved independently for use in real-time control.
    4. Time stamps: Information indicating the time.
    5. AR: Technology for superimposing digital information on real-world video in such a way that it appears to the user to be an actual part of that scene.
    6. MR: Technology for superimposing digital information on real-world video and presenting the result to the user. In contrast to AR, MR makes information appear as if it’s actually there in the real world from any viewpoint.
    7. Burst size: Maximum amount of data transmitted within allowable delay on a wireless access network specified for each QoS flow.
    8. UDP: A protocol on the transport layer featuring light processing by virtue of performing no delivery confirmation, congestion control, etc. It is used in communications for which a loss of data during transmission is not a major problem.
    9. GNSS: Refers to a global navigation system using satellites such as GPS, GLONASS, and Galileo.
    10. SMPTE Profile: One of the protocol profiles of IEEE 1588 PTP (see *22) specified by SMPTE.
    11. PTP: A protocol for achieving high-accuracy time synchronization among equipment connected to a network.

    • 03. Integration of 5GS and IEEE TSN

  • In Rel-16, 5GS can be integrated with IEEE TSN. As specified ...

    Open

    In Rel-16, 5GS can be integrated with IEEE TSN. As specified in TS23.501 [5], 5GS is modeled as a virtual IEEE 802.1Q bridge that supports some TSN functions. In particular, 5GS supports time-aware scheduling and Per-Stream Filtering and Policing (PSFP)*23.

    The IEEE TSN functions of a 5GS bridge are managed by an external CNC based on the fully centralized configuration model [1][6]. In addition, the 5GS bridge supports basic IEEE 802.1Q bridge functions such as learning the source MAC address*24 and Virtual LAN ID (VLAN ID)*25 and updating the dynamic filtering*26 entry based on that information. The CNC, in turn, can read bridge information (such as number of ports and link layer topology*27 discovered via Link Layer Discovery Protocol (LLDP)*28) from 5GS and set the static filtering entry*29 in the 5GS bridge. The static filtering entry specifies rules for frame transfers and filtering within the 5GS bridge.

    3.1 Architecture

    The internal architecture of a virtual IEEE 802.1Q bridge within 5GS is shown in Figure 1.

    Figure 1 IEEE TSN support in 5GS

    Figure 1  IEEE TSN support in 5GS

    In this architecture, CNC communicates with 5GS via the TSN Application Function (AF)*30. An interface between CNC and TSN AF has not been specified by 3GPP, but CNC and TSN AF can communicate using, for example, managed objects specified by IEEE 802.1Q and Simple Network Management Protocol (SNMP)*31. The TSN AF exposes 5GS to CNC as a managed bridge and takes on the role of distributing control messages between CNC and the Device-Side TSN Translator (DS-TT)*32 and NetWork-side TSN Translator (NW-TT)*33, which are functions within the 5GS bridge.

    DS-TT connects to User Equipment (UE)*34 while NW-TT connects to the User Plane Function (UPF)*35. These two translator functions incorporate most 5GS bridge functions such as time-aware scheduling and PSFP. A single 5GS can have multiple virtual bridges each of which comprise a TSN AF, UPF/NW-TT, and multiple DS-TT/UE units. Both DS-TT and NW-TT expose Ethernet ports to external networks. DS-TT/UE connects to UPF via an Ethernet-type Protocol Data Unit (PDU) session*36. Traffic routing within the 5GS bridge is executed based on the destination MAC address and VLAN ID of the Ethernet frame*37.

    3.2 Function for Reading Bridge Delay and Propagation Delay

    One important function of CNC is reading bridge delay and propagation delay from the 5GS bridge. “Bridge delay” means the internal residence time spent by a data frame in passing from an ingress port to an egress port inside the bridge. This delay is presented to CNC for each port pair and each supported traffic class. Propagation delay, meanwhile, is the delay from a 5GS-bridge egress port to an ingress port of a neighboring device. A 5GS-bridge egress port (within DS-TT or NW-TT) measures the propagation delay using generalized PTP (gPTP)*38 and TSN AF reports this measurement value to CNC.

    3.3 Flow of Bridge Configuration

    The CNC determines scheduling and explicit paths in relation to TSN streams within the network using bridge delay, propagation delay, and other bridge information (such as link layer topology). On obtaining bridge information from bridges in the network, CNC makes preparations for configuring those bridges. TSN AF then receives those configurations from CNC and distributes that information to the corresponding DS-TT and NW-TT. If TSN-stream PSFP information is included in those settings, TSN AF uses that information to determine TSC QoS information such as required 5GS delay, maximum burst size, and priority. It also uses PSFP information to determine the TSC Assistance Container (TSCAC)*39. The TSCAC defines traffic patterns of a TSN stream, that is, Burst Arrival Time (BAT)*40 and periodicity in the UpLink (UL) and DownLink (DL) directions. Finally, TSN AF provides TSC QoS information and TSCAC to the Policy Control Function (PCF)*41.

    The Session Management Function (SMF)*42 establishes the QoS flow*43 using the QoS information determined by PCF. It derives TSC Assistance Information (TSCAI)*44 using TSCAC transferred by PCF and provides that information to gNodeB (gNB)*45 along with QoS-flow requirements. The gNB references TSCAI and allocates radio resources*46 such as a configured grant in the UL direction and semi-persistent scheduling*47 in the DL direction.

    1. PSFP: A bridge function for performing filtering, policing, and queuing of each received data stream.
    2. MAC address: A 12-digit fixed physical address allocated to each Ethernet board.
    3. VLAN ID: An Ethernet technology that enables the construction of a logical network independent of the physical connection configuration. VLAN ID is the identifier of that logical network.
    4. Filtering: The process of comparing input messages with a filter and sorting them accordingly to differentiate subsequent processes.
    5. Topology: Positional relationship of equipment and devices and network configuration.
    6. LLDP: An agent using this protocol obtains connection information and port information with respect to neighboring equipment.
    7. Static filtering entry: An entry that can be statically set from the management side with information for determining at which bridge port a received Ethernet frame having one or a group of MAC addresses as its destination should be output.
    8. TSN AF: Part of the 5G core network providing a control-plane translator function for integrating 5GS and an IEEE TSN network. It enables 5GS and CNC to engage in cooperative operations.
    9. SNMP: Protocol that establishes an information communications method for monitoring and controlling network equipment on an IP network.
    10. DS-TT: A TSN translator on the device side that provides TSN input/output ports and PTP ports for interconnected devices behind the UE.
    11. NW-TT: A TSN translator on the network side that provides TSN input/output ports and PTP ports for interconnected devices on the Data Network (DN).
    12. UE: A user terminal enabling user access to network services via a radio interface in accordance with 3GPP specifications.
    13. UPF: A transmit/receive processing function for user data in a 5G core network.
    14. PDU session: A logical connection between the UE and data network.
    15. Ethernet frame: Data format used for Ethernet LAN communications.
    16. gPTP: One protocol profile of IEEE 1588 (PTP) standardized by IEEE 802.1AS.
    17. TSCAC: Information defining BAT (see *40) and periodicity in the UL and DL directions of a TSN stream. This information is reported to SMF (see *42) from TSN AF or TSCTSF (see *63).
    18. BAT: The time that a data burst will arrive. When used by TSCAC, it is the arrival time at DS-TT in the UL direction and at NW-TT in the DL direction. When used by TSCAI (see *44), it is the arrival time at UE in the UL direction and at gNB in the DL direction.
    19. PCF: A function in the 5G core network that determines QoS, policy, etc. and provides that information to SMF (see *42).
    20. SMF: A function within the 5G core network that manages a PDU session and controls UPF to execute QoS, policies, etc.
    21. QoS flow: Finest granularity in QoS transfer processing in 5GS.
    22. TSCAI: Information that defines BAT and periodicity in the UL and DL directions in QoS flow. TSCAI is passed from SMF to gNB.
    23. gNB: A radio base station that supports the 5G radio system.
    24. Radio resources: Generic term for resources deemed necessary to allocate a radio channel (frequencies). Here, this refers to time and frequencies allocated to each user for communications.
    25. Semi-persistent scheduling: The periodic allocation of DL radio resources by the gNB to UE.

    • 04. Support of Time Synchronization in 5GS

  • 4.1 Overview

    Open

    As described above, one mechanism for achieving deterministic communications is to apply time-aware scheduling in the network. This type of scheduling requires that the clocks held by individual bridges in the network be mutually synchronized. The time stamps in application traffic must also be synchronized with those clocks.

    Time synchronization is normally carried out by using PTP and distributing a time stamp from the Grand Master (GM)*48 to other clocks in the network. On using PTP, IEEE 1588 specifies that multiple transport protocols may be used including Ethernet and UDP/IP version 4 (IPv4)*49 or UDP/IPv6*50. Time synchronization in IEEE TSN specifications is provided by gPTP specified in IEEE 802.1AS. The gPTP is one type of PTP protocol profile that uses Ethernet, which can be implemented in IEEE 802.1Q bridges, for transport.

    4.2 (g)PTP Message Processing in Rel-16/17

    The Rel-16 specifications support integration with an external IEEE TSN network and gPTP in relation to time synchronization. On integrating 5GS with an external IEEE TSN network, 5GS operates as a PTP relay*51 [3]. Here, DS-TT and NW-TT each installs a PTP-relay PTP port and exposes an Ethernet port to the external IEEE TSN network. In this case, an Ethernet-type PDU session is used between the DS-TT/UE and UPF/NW-TT.

    In Rel-17, support is added for a network configuration that does not integrate with IEEE TSN. In this case, 5GS operates as a boundary clock*52 [2] or as an end-to-end or peer-to-peer transparent clock*53 [2], and a PTP message can be conveyed directly on UDP/IP using an IP-type PDU session.

    Whether using gPTP that runs on Ethernet as a PTP protocol profile or using another PTP protocol profile (e.g., SMPTE profile) that runs on UDP/IP, NW-TT and DS-TT process a gPTP or a PTP message within 5GS in the same way. The following describes the above in detail while referring to Figure 2. Note that (g)PTP in the figure and in the following description refers to either gPTP or PTP.

    Figure 2 Time synchronization support in 5GS

    Figure 2  Time synchronization support in 5GS

    1) GM Location and PTP Port States

    In Rel-16, 5GS supports a GM in an external network connected to an N6*54 interface and a GM internal to NW-TT. A PTP port that sends PTP messages outside the bridge is in a master state while a PTP port that receives and processes PTP messages from outside the bridge is in a slave state. As a result, an NW-TT PTP port is in a slave state for an external GM and in a master state for an internal GM. A DS-TT PTP port, meanwhile, is always in a master state. In Rel-17, support is also provided for a GM in an external network connected to DS-TT, so there are situations in which the DS-TT PTP port is also in a slave state.

    In Rel-16, the PTP port state in DS-TT or NW-TT must be configured locally in 5GS beforehand, while Rel-17 also supports Best Master Clock Algorithm (BMCA)*55 in addition to configurations made beforehand. The BMCA is a procedure that selects the most optimal GM in the network and automatically configures the state of each PTP port by an appropriate method

    2) Measurement of Residence Time

    One major cause of errors in time information is thought to be the residence time spent within a bridge when delivering a (g)PTP Sync message*56 from an ingress port to an egress port. Here, an ingress/egress port can be a DS-TT port or NW-TT port. When considering residence time, it must be kept in mind that a (g)PTP Sync message must pass through a wireless interface between the gNB and UE, which is an important consideration in a 5GS in which message transfers have a relatively large delay. Consequently, to take residence time into account, the ingress port adds a receive-time time stamp to the (g)PTP Sync message before sending it to the egress port via the 5GS user plane*57. The egress port then calculates the residence time using that time stamp and adds the result of that calculation to the (g)PTP Sync message before sending it outside the 5GS.

    Measuring residence time accurately requires that the internal reference clocks of DS-TT/UE, gNB, and UPF be synchronized. This can be accomplished by setting up a transport network*58 that supports a PTP telecom profile*59 (e.g., ITU-T G.8265.1) between gNB and UPF or by using a local GNSS as a gNB and UPF time source. The gNB delivers its internal reference clock to DS-TT/UE via broadcast or unicast Radio Resource Control (RRC) signaling*60 defined in 3GPP TS 38.331 [7]. The time delivered here indicates the time transmitted by gNB, so UE must add the propagation delay between gNB and UE to obtain the correct time. In Rel-16, UE applies timing advance*61 that it itself measures to locally correct the 5G reference time received from gNB.

    3) More Accurate Correction Taking Propagation Delay into Account

    The accuracy of correction taking propagation delay into account has been improved in Rel-17. Specifically, gNB measures the difference in transmit/receive times on its own and provides that value to UE, which also measures the difference in transmit/receive times on its own. The UE then uses those two transmit/receive time differences to measure propagation delay.

    4) Adjustment of Residence Time Taking Differences in Clock Progressions Inside/Outside the Bridge into Account

    For the case that GM is located outside 5GS, the 5GS internal clock and the external GM are not synchronized. This means that the possibility exists of a difference in the way that time progresses between these two clocks, which requires that the measured residence time within the 5GS bridge must be adjusted. For this reason, the DS-TT and NW-TT PTP ports measure the ratio of clock progressions between the clock that the ports rely on, i.e., the 5GS internal clock, and the external GM, and 5GS then uses that ratio to adjust the residence time measured using the 5GS internal clock.

    5) Remote Configuration of PTP Instance

    The Rel-17 specifications support remote configuration of a PTP instance*62 in the DS-TT and NW-TT.

    For the case that 5GS is integrated with an external IEEE TSN network, the 5GS PTP instance is managed through TSN AF. Although an actual interface from TSN AF to the external controller is not specified by 3GPP, it is possible to use a data model specified, for example, by IEEE 802.1AS and SNMP.

    In a network configuration not integrated with IEEE TSN, the TSC Time Synchronization Function (TSCTSF)*63 takes on the role of the TSN AF in managing the 5GS PTP instance (Fig.2). For this type of network configuration, Rel-17 defines a 3GPP-specific service interface in which an external AF controls the 5GS PTP instance via a Network Exposure Function (NEF)*64 and TSCTSF as specified in TS 29.522 [8]. In this way, an external AF can configure NW-TT and DS-TT with a variety of configurations such as PTP domain number, PTP instance type (PTP relay, border clock, transparent clock), PTP profile (SMPTE, etc.), transport protocol*65, and (g)PTP Sync message transmission interval for the case of GM within 5GS. In addition, the external AF can configure gNB using the service interface and can deliver the 5G internal reference clock to a group of UEs, in which case 5GS does not generate a (g)PTP Sync message. The UE can then deliver 5GS reference time to its own applications in an implementation-specific manner.

    1. GM: A clock that provides time information so that other clocks can be synchronized with each other.
    2. IPv4: The Internet protocol that is currently used. Address resources are managed as 32-bit numbers.
    3. IPv6: A communications protocol used on the Internet. It enables the use of far more IP addresses (unique numbers) than IPv4, the widely used Internet protocol at present.
    4. PTP relay: Equipment for achieving high-precision time synchronization by using gPTP, a type of PTP profile.
    5. Boundary clock: A clock that serves as a GM with the capability of providing time information to other clocks.
    6. Transparent clock: Equipment that can measure residence time, write it in PTP-related messages, and transfer those messages.
    7. N6: A reference point between UPF and DN.
    8. BMCA: A procedure that selects the most optimal GM in the network and automatically configures the state of each PTP port.
    9. Sync message: A PTP protocol message that is exchanged for performing time synchronization.
    10. User plane: The part of the signal sent and received in communications, which contains the data sent and received by the user.
    11. Transport network: The network connecting the access network with the core network or the network interconnecting equipment within each of those networks.
    12. Telecom profile: One type of PTP profile used mainly in the transport network of the public network.
    13. RRC signaling: A Layer 3 protocol that controls radio resources in a radio network.
    14. Timing advance: Value to set the UL-frame transmit timing from a UE to be earlier relative to the DL-frame receive timing at the UE.
    15. PTP instance: Entity configured with necessary settings to process PTP.
    16. TSCTSF: A network function for time-sensitive communications and time synchronization. In a network configuration in which 5GS is not integrated with IEEE TSN, TSCTSF manages 5GS time synchronization and deterministic communications services.
    17. NEF: A function that enables a function or event to be exposed to a third-party AF, etc.
    18. Transport protocol: A protocol used on the transport layer. Main transport protocols on the Internet are connection-oriented Transmission Control Protocol (TCP) and connectionless UDP.

    • 05. Support for Deterministic Communications in a Network Configuration Independent of IEEE TSN

  • In Rel-17, support can be provided for deterministic communications in 5GS ...

    Open

    In Rel-17, support can be provided for deterministic communications in 5GS even for a network configuration independent of IEEE TSN, or in other words, the case of no CNC for controlling a bridge from an external network. In this case, 5GS operates as a set of multiple PDU sessions of the IP or Ethernet type without being modeled as a virtual IEEE 802.1Q bridge. The 5GS internal architecture for supporting deterministic communications in such a network configuration is shown in Figure 3.

    Figure 3 Support for deterministic communications not integrated with IEEE TSN

    Figure 3  Support for deterministic communications not integrated with IEEE TSN

    Here, an external AF provides QoS information for a PDU session to 5GS via the service interface specified by TS 29.522 [8].

    In an Ethernet-type PDU session, the UPF on receiving an Ethernet frame from the UE associates the source MAC address of that Ethernet frame with the PDU session. In an IP-type PDU session, the PDU session is associated with the IP address allocated to the UE by the network.

    The AF can indicate that a request message is for a specific PDU session by presenting the MAC address associated with an Ethernet-type PDU session or the IP address of an IP-type PDU session to NEF.

    A request message sent from AF to 5GS includes required QoS parameters (required 5GS delay, guaranteed bit rate, maximum bit rate, maximum burst size, etc.) and the flow description (IP tuple*66, priority value of an Ethernet frame, etc.) of a traffic filter used to compare with traffic. There are also cases in which a request message from AF to 5GS includes attributes describing a traffic pattern (BAT in the UL direction and DL direction, periodicity). A QoS request is transmitted via NEF to TSCTSF, which invokes the PCF managing the PDU session. The PCF instructs the SMF to establish the delay-critical Guaranteed Bit Rate (GBR)*67 QoS flow. In the case that a traffic pattern is provided by AF, SMF determines TSCAI and provides it to gNB. For the case that an application requests time synchronization when application traffic flow is periodic, AF can also initiate time synchronization for the PDU session via a time-synchronization service interface.

    1. IP tuple: Source IP address, source port number, destination IP address, destination port number, and protocol number.
    2. Delay-critical GBR: One type of QoS-flow resource introduced to support QoS flows with severe delay requirements. In addition to specifying GBR attributes, it also specifies Maximum Data Burst Volume (MDBV).

    • 06. Conclusion

  • This article provided an overview of 5GS procedures that support deterministic ...

    Open

    This article provided an overview of 5GS procedures that support deterministic communications and time synchronization specified in Rel-16 and Rel-17. The specifications in Rel-16 enable 5GS to support main IEEE TSN functions for industrial applications while those in Rel-17 enable 5GS to support IP-based deterministic communications and time synchronization in a network configuration not integrated with IEEE TSN. Going forward, the plan is to support Internet Engineering Task Force (IETF) DetNet*68, and in addition, to strengthen coordination between 5GS and the transport network and improve scheduling coordination between a Radio Access Network (RAN) and AF with the goal of improving low-latency characteristics.

    1. IETF DetNet: Specifications for deterministic communications under study at IETF.

  • REFERENCES

    Open
    1. [1] IEEE Std 802.1Qcc-2018: “IEEE Standard for Local and metropolitan area networks - Bridges and Bridged Networks – Amendment: Stream Reservation Protocol (SRP) Enhancements and Performance Improvements,” Oct. 2018.
    2. [2] IEEE Std 802.1AS-2020: “IEEE Standard for Local and metropolitan area networks-Timing and Synchronization for Time-Sensitive Applications,” Jun. 2020.
    3. [3] IEEE Std 1588-2008: “IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems,” Jul. 2008.
    4. [4] SMPTE ST 2059-2: 2015: “SMPTE Standard - SMPTE Profile for Use of IEEE-1588 Precision Time Protocol in Professional Broadcast Applications,” Apr. 2015.
    5. [5] 3GPP TS23.501 V17.5.0: “System architecture for the 5G System (5GS); Stage 2,” Jun. 2022.
    6. [6] IEEE Std 802.1Q-2018: “IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks,” Sep. 2018.
    7. [7] 3GPP TS 38.331 V17.1.0: “NR; Radio Resource Control (RRC); Protocol Specification,” Jun. 2022.
    8. [8] 3GPP TS 29.522 V17.6.0: “5G System; Network Exposure Function Northbound APIs; Stage 3,” Jun. 2022.

VOL.24 NO.3

Go to top of the page