Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.501  Word version:  18.5.0

Top   Top   Up   Prev   Next
1…   3…   4.2.3   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.2.15…   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.15.11…   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.32.6…   5.33…   5.34…   5.35…   5.38…   5.43…   6…   6.3…   6.3.8…   7…   7.2…   8…   8.2.4   8.2.5…   8.3…   A…   D…   E…   F   G…   G.3   G.4…   H…   J   K…   M…   N…   O…   P…

 

5.28  Support of integration with TSN, Time Sensitive Communications, Time Synchronization and Deterministic Networking |R16|p. 382

5.28.0  General |R18|p. 382

Clause 5.28 defines the 5GS integration in TSN DN as a 5GS bridge.
In this scenario, 5GS is deployed in a TSN DN to provide wireless connectivity. From the perspective of the TSN DN, the 5GS is modelled as a Layer 2 Ethernet Bridge of the TSN DN.
In addition to supporting interoperation with TSN, 5GS also supports Time Sensitive Communication, Time Synchronization and integration with Deterministic Networking.

5.28.1  5GS bridge management for TSNp. 382

5GS acts as a Layer 2 Ethernet Bridge. When integrated with IEEE TSN network, 5GS functions acts as one or more TSN Bridges of the TSN network. The 5GS Bridge is composed of the ports on a single UPF (i.e. PSA) side, the user plane tunnel between the UE and UPF, and the ports on the DS-TT side. For each 5GS Bridge of a TSN network, the port on NW-TT support the connectivity to the TSN network, the ports on DS-TT side are associated to the PDU Session providing connectivity to the TSN network.
The granularity of the 5GS TSN bridge is per UPF for each network instance or DNN/S-NSSAI. The bridge ID of the 5GS TSN bridge is bound to the UPF ID of the UPF as identified in TS 23.502. The TSN AF stores the binding relationship between a port on UE/DS-TT side and a PDU Session during reporting of 5GS TSN bridge information. The TSN AF also stores the information about ports on the UPF/NW-TT side. The UPF/NW-TT forwards traffic to the appropriate egress port based on the traffic forwarding information. From the TSN AF point of view, a 5GS TSN bridge has a single NW-TT entity within UPF and the NW-TT may have multiple ports that are used for traffic forwarding.
There is only one PDU Session per DS-TT port for a given UPF. All PDU Sessions which connect to the same TSN network via a specific UPF are grouped into a single 5GS bridge. The capabilities of each port on UE/DS-TT side and UPF/NW-TT side are integrated as part of the configuration of the 5GS Bridge and are notified to TSN AF and delivered to CNC for TSN bridge registration and modification.
Reproduction of 3GPP TS 23.501, Fig. 5.28.1-1: Per UPF based 5GS bridge
Up
In order to support IEEE 802.1Q features related to TSN, including TSN scheduled traffic (section 8.6.8.4 in IEEE Std 802.1Q [98]) over 5GS Bridge, the 5GS supports the following functions:
  • Configure the bridge information in 5GS.
  • Report the bridge information of 5GS Bridge to TSN network after PDU Session establishment.
  • Receiving the configuration from TSN network as defined in clause 5.28.2.
  • Map the configuration information obtained from TSN network into 5GS QoS information (e.g. 5QI, TSC Assistance Information) of a QoS Flow in corresponding PDU Session for efficient time-aware scheduling, as defined at clause 5.28.2.
The bridge information of 5GS Bridge is used by the TSN network to make appropriate management configuration for the 5GS Bridge. The bridge information of 5GS Bridge includes at least the following:
  • Information for 5GS Bridge:
    • Bridge ID
      Bridge ID is to distinguish between bridge instances within 5GS. The Bridge ID can be derived from the unique bridge MAC address as described in IEEE Std 802.1Q [98], or set by implementation specific means ensuring that unique values are used within 5GS;
    • Number of Ports;
    • list of port numbers.
  • Capabilities of 5GS Bridge as defined in IEEE Std 802.1Q [98]:
    • 5GS Bridge delay per port pair per traffic class, including 5GS Bridge delay (dependent and independent of frame size, and their maximum and minimum values: independentDelayMax, independentDelayMin, dependentDelayMax, dependentDelayMin), ingress port number, egress port number and traffic class.
    • Propagation delay per port (txPropagationDelay), including transmission propagation delay, egress port number.
    • VLAN Configuration Information.
  • Topology of 5GS Bridge as defined in IEEE Std 802.1AB [97]:
    • LLDP Configuration Information.
    • Chassis ID subtype and Chassis ID of the 5GS Bridge.
    • LLDP Discovery Information for each discovered neighbor of each NW-TT port and DS-TT port.
  • Traffic classes and their priorities per port as defined in IEEE Std 802.1Q [98].
  • Stream Parameters as defined in section 12.31.1 in IEEE Std 802.1Q [98], in order to support PSFP information:
    • MaxStreamFilterInstances: The maximum number of Stream Filter instances supported by the bridge;
    • MaxStreamGateInstances: The maximum number of Stream Gate instances supported by the bridge;
    • MaxFlowMeterInstances: The maximum number of Flow Meter instances supported by the bridge (optional);
    • SupportedListMax: The maximum value supported by the bridge of the AdminControlListLength and OperControlListLength parameters.
The following parameters: independentDelayMax and independentDelayMin, how to calculate them is left to implementation and not defined in this specification.
DS-TT and NW-TT report txPropagationDelay to the TSN AF relative to the time base of the TSN GM clock (identified by the TSN time domain number received in PMIC). If the TSN AF has subscribed for notifications on txPropagationDelay and if the difference to the previously reported txPropagationDelay is larger than the txPropagationDelayDeltaThreshold received in PMIC, the corresponding DS-TT or NW-TT informs the TSN AF about the updated txPropagationDelay using PMIC signalling.
Bridge ID of the 5GS Bridge, port number(s) of the Ethernet port(s) in NW-TT could be preconfigured on the UPF. The UPF is selected for a PDU Session serving TSC as described in clause 6.3.3.3.
This release of the specification requires that each DS-TT port is assigned with a globally unique MAC address.
When there are multiple network instances within a UPF, each network instance is considered logically separate. The network instance for the N6 interface (clause 5.6.12) may be indicated by the SMF to the UPF for a given PDU Session during PDU Session establishment. UPF allocates resources based on the Network Instance and S-NSSAI and it is supported according to TS 29.244. DNN/S-NSSAI may be indicated by the SMF together with the network instance to the UPF for a given PDU Session during PDU Session establishment procedure.
The TSN AF is responsible to receive the bridge information of 5GS Bridge from 5GS, as well as register or update this information to the CNC.
Up

5.28.2  5GS Bridge configuration for TSNp. 384

The configuration information of 5GS Bridge as defined in section 8.6.8.4 of IEEE Std 802.1Q [98], includes the following:
  • Bridge ID of 5GS Bridge.
  • Configuration information of scheduled traffic on ports of DS-TT and NW-TT:
    • Egress ports of 5GS Bridge, e.g. ports on DS-TT and NW-TT;
    • Traffic classes and their priorities.
The configuration information of 5GS Bridge as defined in IEEE Std 802.1Q [98], includes the following:
The SMF report the MAC address of the DS-TT port of the related PDU Session to TSN AF via PCF. The association between the DS-TT MAC address, 5GS Bridge ID and port number on DS-TT is maintained at TSN AF and further used to assist to bind the TSN traffic with the UE's PDU session.
Two models are supported to configure 5GS QoS for TSN traffic:
  • Based on the assumption that PSFP information is always provided by CNC: In this case the QoS Flows are setup based on the PSFP information provided by CNC;
  • Without requiring PSFP information provided by the CNC.: In this case, pre-configured QoS Flows are used and configured e.g. during PDU session establishment as described in clause 5.28.4. Additional QoS Flows are setup as necessary based on the PSFP, if available, as described in this clause.
When PSFP information is available, TSN AF identifies the ingress and egress port for the TSN stream as described in Annex I and determines the DS-TT port MAC address(es) identifying the corresponding PDU session(s) carrying the TSN stream. Flow direction of a TSN stream is determined as follows: if the ingress port is a DS-TT port, then the Flow direction is UL; otherwise if the ingress port(s) is (are) NW-TT port, the Flow direction is DL. Flow direction is part of the TSCAI as defined in clause 5.27.2.
The TSN AF uses the stream filter instances of PSFP information to derive the service data flow for TSN streams. The TSN AF uses the Priority values in the stream filter instances in PSFP information (if available) as defined in section 8.6.5.2.1 of IEEE Std 802.1Q [98], the 5GS bridge delay information (see clause 5.27.5) and may additionally use scheduled traffic information as defined in section 8.6.8.4 of IEEE Std 802.1Q [98], to derive the TSN QoS information (i.e. priority and delay) for a given TSN stream or flow of aggregated TSN streams as specified in clause 5.28.4.
The TSN AF identifies the egress port(s) for the TSN stream using local configuration or static filtering entry that matches the TSN stream. If the TSN AF determines that the TSN stream is for UE-UE communication (i.e. ingress and egress ports are in DS-TTs), the TSN AF divides the stream into one uplink stream and one or more downlink streams and provides the streams on AF Session basis to the PCF(s). The SMF applies local switching as specified in clause 5.8.2.13 or clause 5.8.2.5.3 in order to enable UPF locally forward uplink stream from one PDU session as downlink stream in another PDU session.
When CNC configures the PSFP information to the TSN AF, TSN AF determines the TSC Assistance Container as described in clause 5.27.2. The TSN AF associates the TSN QoS information and TSC Assistance Container (if available) with the corresponding service data flow description and provides to the PCF and the SMF as defined in clause 6.1.3.23 of TS 23.503.
If TSN AF provides PSFP and/or scheduled traffic information to DS-TT and NW-TT then DS-TT and NW-TT execute on this information relative to the time base of the TSN GM clock (identified by the TSN time domain number received in PMIC).
Up

5.28.3  Port and user plane node management information exchange in 5GSp. 386

5.28.3.1  Generalp. 386

Port number for the PDU Session is assigned by the UPF during PDU session establishment. The port number for a PDU Session shall be reported to the SMF from the UPF and further stored at the SMF. The SMF provides the port number via PCF to the TSN AF or TSCTSF. TSN AF or TSCTSF maintains an association between the port number for the PDU Session and the DS-TT port MAC address (with Ethernet type PDU session) or IP address (applicable for TSCTSF only, with IP type PDU Session) of the UE. If a PDU session for which SMF has reported a port number to TSN AF or TSCTSF is released, then SMF informs TSN AF or TSCTSF accordingly. The port number for the PDU Session corresponds to the device side port of the 5GS bridge/router. When the device supports the DS-TT functionality, the port number represents the DS-TT port number corresponding to the given PDU Session.
When the DS-TT or the NW-TT functions are used, the 5GS shall support transfer of standardized and deployment-specific port management information transparently between TSN AF or TSCTSF and DS-TT or NW-TT, respectively inside a Port Management Information Container. NW-TT may support one or more ports. In this case, each port uses separate Port Management Information Container. 5GS shall also support transfer of standardized and deployment-specific user plane node management information transparently between TSN AF or TSCTSF and NW-TT, respectively inside a User Plane Node Management Information Container. Clause K.1 lists standardized port management information and user plane node management information, respectively.
If TSN AF is deployed, i.e. if 5GS is integrated with an IEEE TSN network, the port and user plane node management information is exchanged between CNC and TSN AF. The port management information is related to ports located in DS-TT or NW-TT. The user plane node management information container is related to 5GS bridge management.
If TSN AF is not deployed, the port and user plane node management information is exchanged between TSCTSF and DS-TT/NW-TT.
Exchange of port and user plane node management information between TSN AF or TSCTSF and NW-TT or between TSN AF or TSCTSF and DS-TT allows TSN AF or TSCTSF to:
  1. retrieve port management information for a DS-TT or NW-TT port or user plane node management information;
  2. send port management information for a DS-TT or NW-TT port or user plane node management information;
  3. subscribe to and receive notifications if specific port management information for a DS-TT or NW-TT port changes or user plane node management information changes.
  4. delete selected entries in the following data structures:
    • "DS-TT port neighbour discovery configuration for DS-TT port" in UMIC using the DS-TT port number to reference the selected entry.
    • "Stream Filter Instance Table" in PMIC using the Stream Filter Instance ID to reference the selected entry.
    • "Stream Gate Instance Table" in PMIC using the Stream Gate Instance ID to reference the selected entry.
    • "Static Filtering Entries table" in UMIC using the (MAC address, VLAN ID) pair to reference the selected entry.
  5. delete PTP Instances in a DS-TT port or NW-TT port using the PTP Instance ID to reference the selected entry as described in clause K.2.2.1.
Exchange of port management information between TSN AF or TSCTSF and NW-TT or DS-TT is initiated by DS-TT or NW-TT to:
  • notify TSN AF or TSCTSF if user plane node management information has changed that TSN AF or TSCTSF has subscribed for.
  • notify TSCTSF if time synchronization status information of UPF has changed that the TSCTSF has subscribed for.
Exchange of user plane node management information between TSN AF or TSCTSF and NW-TT is initiated by NW-TT to:
  • notify TSN AF or NEF if bridge management information has changed that TSN AF or NEF has subscribed for.
Exchange of port management information is initiated by DS-TT to:
  • provide port management capabilities, i.e. provide information indicating which standardized and deployment-specific port management information is supported by DS-TT.
TSN AF or TSCTSF indicates inside the Port Management Information Container or user plane node Management Information Container whether it wants to retrieve or send port or user plane node management information or intends to (un-)subscribe for notifications. If the TSN AF or TSCTSF has requested to receive notification of TSC management information and both SMF and UPF support direct reporting, the UPF may directly report TSC management information to the TSN AF or TSCTSF using Nupf_EventExposure_Notify.
Up

5.28.3.2  Transfer of port or user plane node management informationp. 387

Port management information is transferred transparently via 5GS between TSN AF or TSCTSF and DS-TT or NW-TT, respectively, inside a Port Management Information Container (PMIC). User plane node management information is transferred transparently via 5GS between TSN AF or TSCTSF and NW-TT inside a user plane node Management Information Container (UMIC). The transfer of port or user plane node management information is as follows:
  • To convey port management information from DS-TT or NW-TT to TSN AF or TSCTSF:
    • DS-TT provides a PMIC and the DS-TT port MAC address (if available) to the UE, which includes the PMIC as an optional Information Element of an N1 SM container and triggers the UE requested PDU Session Establishment procedure or PDU Session Modification procedure to forward the PMIC to the SMF. SMF forwards the PMIC and the port number of the related DS-TT port to TSN AF or TSCTSF as described in clauses 4.3.2.2 and 4.3.3.2 of TS 23.502;
    • NW-TT provides PMIC(s) and/or UMIC to the UPF, which may trigger the N4 Session Level Reporting Procedure to forward the PMIC(s) and/or UMIC to SMF. UPF selects an N4 session corresponding to any of the N4 sessions for this NW-TT. SMF in turn forwards the PMIC(s) and the port number(s) of the related NW-TT port(s), or the UMIC, to TSN AF or TSCTSF as described in clause 4.16.5.1 of TS 23.502.
    • NW-TT may provide PMIC(s) and/or UMIC to the UPF, which may trigger UPF Event Exposure Notification to forward the PMIC(s) and/or UMIC to TSN AF or TSCTSF. UPF directly reports TSC management information event via Nupf_EventExposure_Notify service operation as described in clause 5.2.26.2 of TS 23.502.
  • To convey port management information from TSN AF or TSCTSF to DS-TT:
    • TSN AF or TSCTSF provides a PMIC, DS-TT port MAC address or UE IP address (applicable for TSCTSF only) reported for a PDU Session (i.e. MAC address of the DS-TT port or IP address related to the PDU session) and the port number of the DS-TT port to manage to the PCF by using the AF Session level Procedure, which forwards the information to SMF based on the MAC or IP address using the PCF initiated SM Policy Association Modification procedure as described in clause 4.16.5.2 of TS 23.502. SMF determines that the port number relates to a DS-TT port and based on this forwards the PMIC to DS-TT using the network requested PDU Session Modification procedure as described in clause 4.3.3.2 of TS 23.502.
  • To convey port or user plane node management information from TSN AF or TSCTSF to NW-TT:
    • TSN AF or TSCTSF selects a PCF-AF session corresponding to any of the DS-TT MAC or IP addresses (applicable for TSCTSF only) for the related PDU sessions of this bridge or router and provides a PMIC(s) and the related NW-TT port number(s) and/or UMIC to the PCF. The PCF uses the PCF initiated SM Policy Association Modification procedure to forward the information received from TSN AF or TSCTSF to SMF as described in clause 4.16.5.2 of TS 23.502. SMF determines that the included information needs to be delivered to the NW-TT either by determining that the port number(s) relate(s) to a NW-TT port(s) or based on the presence of UMIC, and forwards the container(s) and/or related port number(s) to NW-TT using the N4 Session Modification procedure described in clause 4.4.1.3 of TS 23.502.
Up

5.28.3.3  VLAN Configuration Information for TSNp. 388

The CNC obtains the 5GS bridge VLAN configuration from TSN AF according to section 12.10.1.1 of IEEE Std 802.1Q [98]. The TSN AF and UPF/NW-TT are pre-configured with same 5GS bridge VLAN configuration.

5.28.4  QoS mapping tables for TSNp. 388

The mapping tables between the traffic class and 5GS QoS Profile is provisioned and further used to find suitable 5GS QoS profile to transfer TSN traffic over the PDU Session. QoS mapping procedures are performed in two phases: (1) QoS capability report phase as described in clause 5.28.1, and (2) QoS configuration phase as in clause 5.28.2
  1. The TSN AF shall be pre-configured (e.g. via OAM) with a mapping table. The mapping table contains TSN traffic classes, pre-configured bridge delays (i.e. the preconfigured delay between UE and UPF/NW-TT) and priority levels. Once the PDU session has been setup and after retrieving the information related to UE-DS-TT residence time, the TSN AF deduces the port pair(s) in the 5GS bridge and determines the bridge delay per port pair per traffic class based on the pre-configured bridge delay and the UE-DS-TT residence time as described in clause 5.27.5. The TSN AF updates bridge delays per port pair and traffic class and reports the bridge delays and other relevant TSN information such as the Traffic Class Table (section 12.6.3 in IEEE Std 802.1Q [98]) for every port, according to the IEEE Std 802.1Q [98] to the CNC.
  2. CNC may distribute PSFP information and transmission gate scheduling parameters to 5GS Bridge via TSN AF, which can be mapped to TSN QoS requirements by the TSN AF.
The PCF mapping table provides a mapping from TSN QoS information (see clauses 6.2.1.2 and 6.1.3.23 of TS 23.503) to 5GS QoS profile. Based on trigger from TSN AF, the PCF may trigger PDU session modification procedure to establish a new 5G QoS Flow or use the pre-configured 5QI for 5G QoS Flow for the requested traffic class according to the selected QoS policies and the TSN AF traffic requirements.
Figure 5.28.4-1 illustrates the functional distribution of the mapping tables.
Reproduction of 3GPP TS 23.501, Fig. 5.28.4-1: QoS Mapping Function distribution between PCF and TSN AF
Up
The minimum set of TSN QoS-related parameters that are relevant for mapping the TSN QoS requirements are used by the TSN AF: traffic classes and their priorities per port, TSC Burst Size of TSN streams, 5GS bridge delays per port pair and traffic class (independentDelayMax, independentDelayMin, dependentDelayMax, dependentDelayMin), propagation delay per port (txPropagationDelay) and UE-DS-TT residence time.
Once the CNC retrieves the necessary information, it proceeds to calculate scheduling and paths. The configuration information is then set in the bridge as described in clauses 5.28.2 and 5.28.3. The most relevant information received is the PSFP information and the schedule of transmission gates for every traffic class and port of the bridge. At this point, it is possible to retrieve the TSN QoS requirements by identifying the traffic class of the TSN stream. The traffic class to TSN QoS and delay requirement (excluding the UE-DS-TT residence time) mapping can be performed using the QoS mapping table in the TSN AF as specified in TS 23.503. Subsequently in the PCF, the 5G QoS Flow can be configured by selecting a 5QI as specified in TS 23.503. This feedback approach uses the reported information to the CNC and the feedback of the configuration information coming from the CNC to perform the mapping and configuration in the 5GS.
If the Maximum Burst Size of the aggregated TSC streams in the traffic class is provided by CNC via TSN AF to PCF, PCF can derive the required MDBV taking the Maximum Burst Size as input. If the default MDBV associated with a standardized 5QI or a pre-configured 5QI in the QoS mapping table cannot satisfy the aggregated TSC Burst Size, the PCF provides the derived MDBV in the PCC rule and then the SMF performs QoS Flow binding as specified in clause 6.1.3.2.4 of TS 23.503.
Maximum Flow Bit Rate is calculated over StreamGateAdminCycleTime as described in Annex I and provided by the TSN AF to the PCF. The PCF sets the GBR and MBR values to the Maximum Flow Bitrate value.
The Maximum Flow Bit Rate is adjusted according to Averaging Window associated with a pre-configured 5QI in the QoS mapping table or another selected 5QI (as specified in TS 23.503) to obtain GBR of the 5GS QoS profile. GBR is then used by SMF to calculate the GFBR per QoS Flow. QoS mapping table in the PCF between TSN parameters and 5GS parameters should match the delay, aggregated TSC burst size and priority, while preserving the priorities in the 5GS. An operator enabling TSN services via 5GS can choose up to eight traffic classes to be mapped to 5GS QoS profiles.
Once the 5QIs to be used for TSN streams are identified by the PCF as specified in TS 23.503, then it is possible to enumerate as many bridge port traffic classes as the number of selected 5QIs.
When PSFP information is not available to the TSN AF for a given TSN stream (e.g. because of lack of PSFP support in the DS-TTs or the NW-TTs, or exceeding the number of supported table entries for PSFP functions, or because CNC does not provide PSFP information), the 5GS can support the TSN streams using pre-configured mapping from stream priority (i.e. PCP as defined in IEEE Std 802.1Q [98]) to QoS Flows.
Up

5.28.5  Support of integration with IETF Deterministic Networking |R18|p. 390

5.28.5.1  Generalp. 390

5GS acts as a DetNet Router according to the architecture defined in clause 4.4.8.4. When integrated with an IETF Deterministic Network, 5GS acts as one or more routers. A 5GS router is composed of the ports on a single UPF (i.e. PSA) network side, the user plane tunnel between the UE and UPF, and the ports on the device side. For each 5GS router of a deterministic network, the ports on the network side and the ports on device side that are associated to the PDU Sessions support connectivity to the deterministic network.
The granularity of the 5GS DetNet node is per UPF for each network instance or DNN/S-NSSAI. The TSCTSF stores the binding relationship between a device side port and a PDU Session identified by the UE address. The TSCTSF also stores information about ports on the UPF/NW-TT side.
The integration with IETF Deterministic Networking assumes the following.
  • The existing 3GPP routing mechanisms are re-used for DetNet.
  • The existing multicast capabilities can be re-used for DetNet communications.
  • The 5GS integration to IETF DetNet is based on DetNet for IP; DetNet for MPLS is not supported.
  • IPbased DetNet traffic is carried in IPtype PDU Sessions.
  • 5GS functions realize the DetNet forwarding sub-layer. For the IP case, according to Section 1 of RFC 8939, no service sub-layer function needs to be defined. The 5GS DetNet Router acts as a DetNet transit node as defined in RFC 8655.
The interface between the TSCTSF and the DetNet controller uses protocols defined in IETF. The DetNet configuration is carried in the YANG model [154] over Netconf [155] or Restconf [156].
Up

5.28.5.2  5GS DetNet node reportingp. 390

The TSCTSF may provide exposure information to the DetNet controller using information collected from the 5GS entities. The exposure information can be used by the DetNet controller to build up the network topology information. The exposure may be based on RFC 8343 and RFC 8344.
The TSCTSF may collect the information from the UPF/NW-TT via parameters in PMIC as defined in clause 5.28.3.1. For the device side ports, the TSCTSF collects information using parameters provided from SMF to TSCTSF via PCF as described in clause 6.1.3.23b of TS 23.503.
When the MTU size for IPv4 or IPv6 is not provided to TSCTSF for a port, the TSCTSF may use a pre-configured default value for IPv4 or IPv6.
In the case of network side ports, the TSCTSF may collect information on the type of the interface (defined in RFC 8343, with values defined in RFC 7224) associated with the port. In the case of device side ports, which correspond to the PDU Sessions that are reported to the TSCTSF, the default value of "3GPP WWAN" (wwanPP) for the interface type is assumed. The TSCTSF can differentiate network side ports as they are reported from the NW-TT within UMIC/PMIC, while device side ports correspond to the PDU Sessions, reported to the TSCTSF in the associated AF sessions.
For device side ports also information on IP addresses or IP prefixes not directly assigned to the port but reachable via the port may be provided. On the device side ports, these are related to Framed Routes, i.e. a range of IPv4 addresses or IPv6 prefixes reachable over a single PDU Session, as defined in clause 5.6.14, or prefixes delegated by IPv6 prefix delegation as defined in clause 5.8.2.2. This additional information helps both the TSCTSF and the DetNet controller to map flows to the correct UE address as described in clause 5.28.5.3. For the network side ports, the TSCTSF may also collect information on the link layer address and neighbor IP nodes.
The ports are identified by the port number within the 3GPP system. The port number may also be used to generate interface identifiers towards the DetNet controller that are unique within the 5GS node.
The TSCTSF may use the user-plane node ID provided by the UPF to generate an identifier of the 5GS node that is provided to the DetNet controller.
For network side ports, the information is transferred in PMIC between the NW-TT and the TSCTSF. For device side ports, the information is transferred without relying on PMIC, using parameters from the SMF via the PCF to the TSCTSF.
Up

5.28.5.3  DetNet node configuration mapping in 5GSp. 391

The TSCTSF maps the parameters in the DetNet YANG configuration to 5GS parameters as defined in clause 6.1.3.23b of TS 23.503.
The TSCTSF determines the UE address to bind the DetNet configuration as follows:
  • When available, the TSCTSF uses the identity of the incoming and outgoing interface to determine the affected UE address and whether the flow is uplink or downlink or UE-to-UE.
  • If there is no incoming interface for UL traffic, the TSCTSF may determine the UE address based on the source IP address of the UL traffic in the DetNet configuration, or using local configuration to map the DetNet flow information to the UE address. If there is no incoming interface for traffic with an outgoing interface on the device side, the TSCTSF may determine whether the flow is UE-to-UE based on the source IP address of the traffic in the DetNet configuration, or using local configuration.
  • When the information on IP addresses or IP prefixes not directly assigned to the port but reachable via the port is available as described in clause 5.28.5.2, the TSCTSF also takes such info into account.
  • If the flow is UE-to-UE, two PDU Sessions will be affected for the flow, and the TSCTSF breaks up the requirements to individual requirements for the PDU Sessions.
The TSCTSF provides a response to the DetNet controller regarding the success of the configuration setup. When both the TSCTSF and the DetNet controller support 3GPP extensions to the IETF draft-ietf-detnet-yang [154], the TSCTSF may provide 5GS specific status code information on the result of the configuration to the DetNet controller.
If the status of the flow changes later on for any reason, the TSCTSF notifies the DetNet controller. Upon release of a PDU Session that is part of the existing DetNet configuration, the PCF notifies the TSCTSF of the PDU Session release, and TSCTSF notifies the DetNet controller on the status of the flow.
The 5GS routing is not modified by the configuration received from the DetNet controller. Still the TSCTSF may verify whether the explicit routing information provided by the DetNet controller is in line with the 5GS mapping of IP addresses and prefixes to PDU sessions. The verification may be based on whether the source or destination IP address in the DetNet flow on the given port corresponds to the IP address or prefix associated with the given PDU Session. Based on operator configuration, the TSCTSF may use other criteria (not routing related) to determine whether to accept or reject a given DetNet configuration.
5GS DetNet Node can forward via its device side interface IP packets destined not only to the UE's IP address or prefix but also to a range of IPv4 addresses or IPv6 IP prefixes according to one or more Framed Routes or prefixes delegated to the UE by IPv6 prefix delegation. To facilitate this, the additional IP addresses used for framed routes and IPv6 prefix delegation are exposed by the SMF to the TSCTSF via the PCF and the TSCTSF may expose them to the DetNet controller, as defined in clause 5.28.5.2.
Up

5.28a  Support for TSN enabled Transport Network |R18|p. 392

5.28a.1  Generalp. 392

When the 5GS supports interworking with IEEE TSN deployed in the transport network, the CUC that is collocated with SMF interworks with the CNC in the transport network (TN CNC) as specified in section 46.2 of IEEE Std 802.1Q [98]. The SMF/CUC provides the stream requirements on QoS Flow basis (i.e. translated Talker group and Listener group information) via the User/Network-Interface (UNI) to the TN CNC. The TN CNC uses the stream requirements as input to configure respective path(s) and schedules in TN. Based on the results, the TN CNC provides a Status group that contains the end station communication-configuration back to the SMF/CUC.
When interworking with TSN deployed in the transport network is applied, the dynamic value for the CN PDB of a Delay-critical GBR 5QI shall be considered as described in clause 5.7.3.4. When the SMF setups a new QoS Flow, the SMF signals TSCAI for the QoS Flow to NG-RAN on QoS Flow basis as described in clause 5.27.2.
Upon receiving the TSCAI for a QoS Flow from the SMF, if the TSCAI includes a BAT in UL direction and the dynamic value for the CN PDB is configured in the NG-RAN (as described in clause 5.7.3.4), the NG-RAN shall provide the 5G-AN PDB in the response to the QoS Flow request. The SMF/CUC uses 5G-AN-PDB to generate EarliestTransmitOffset as described in Annex M, clause M.1.
The details of providing End Station related information to generate the stream requirements for the QoS Flow by the SMF/CUC are described in Annex M, clause M.1.
If the NG-RAN and UPF support the TSN Talker and Listener functionality (i.e. implement the AN-TL and CN-TL, respectively), the SMF/CUC can communicate with the AN-TL and CN-TL via TL-Container. The TL-Container conveys the data sets defined in IEEE P802.1Qdj [146] between the SMF/CUC and AN-TL and CN-TL.
The AN-TL and CN-TL enable the following functions:
  1. hold and buffer functionality in a case when the TSCAI contains a BAT in UL and/or DL direction.
  2. support of stream transformation functionality with respective information exchange with SMF/CUC.
  3. for SMF/CUC to retrieve the InterfaceCapabilities and/or EndStationInterfaces from the AN-TL or CN-TL.
  4. topology information exchange functionality via LLDP in the TN as described in clause 5.28a.3.
Up

5.28a.2  Transfer of TL-Container between SMF/CUC and AN-TL and CN-TLp. 392

If NG-RAN and UPF support AN-TL and CN-TL, the SMF/CUC may use the TL-Container to send a:
  1. get-request.
  2. set-request: submits the following information elements to the AN-TL or CN-TL:
    • InterfaceConfiguration as described in Annex M, clause M.1 (one InterfaceConfiguration is associated with each QFI in the N3 tunnel)
    • Interface ID Group.
    • TN Stream Identification Information for DataFrameSpecification.
    • TN Stream Identification Information for mask-and-match.
    • Interval (only provided together with TimeAwareOffset).
    • MaxFrameSize (only provided together with TimeAwareOffset).
    submits the following elements of Talker group to the AN-TL or CN-TL, as derived by the SMF/CUC:
    • Interval.
    • MaxFrameSize.
The AN-TL or CN-TL may use the TL-Container to send a:
  1. get-response: indicates the following elements of the Talker or Listener group from the AN-TL or CN-TL:
    • EndStationInterfaces: list of InterfaceIDs.
    • InterfaceCapabilities.
    • Buffer capability: maximum possible buffer duration for a packet of a stream with the maximum size of an Ethernet packet (1522 Bytes) that is supported by the AN-TL / CN-TL when acting as a Talker.
  2. set-response: reports the processing results for the corresponding set-request to the SMF/CUC.
Details on the TL-Container information are provided in Table M.2-1 of clause M.2.
The SMF/CUC may request the NG-RAN/UPF to report AN-TL or CN-TL information by including a TL-Container with a get-request to the AN-TL or CN-TL, respectively. The get-request is sent to AN-TL in the N2 SM information and to CN-TL in the N4 Session Establishment as described in clause 4.3.2.2 of TS 23.502.
If the NG-RAN/UPF supports AN-TL/CN-TL, the NG-RAN/AN-TL and UPF/CN-TL responds with a TL-Container including the elements defined for the get-response.
The SMF/CUC may submit TL-Container including a set-request the elements defined for the set-request to NG-RAN/AN-TL and UPF/CN-TL. The set-request is sent to AN-TL in the N2 SM information and to CN-TL in the N4 Session Modification request as described in clause 4.3.3.2 of TS 23.502. The SMF/CUC shall initiate to the CN-TL/AN-TL the deletion of TN stream configurations as described in 4.3.4.2 of TS 23.502.
The InterfaceConfiguration is associated with the corresponding QFI in the N3 tunnel in the NG-RAN or UPF, respectively. The AN-TL/CN-TL uses the provided configuration for the traffic in the QoS Flow of the given QFI as described in Annex M.
Up

5.28a.3  Topology Information for TSN TNp. 393

NG-RAN and UPF may support u-plane LLDP functionality to provide topology information to the TN. When LLDP is supported, AN-TL and CN-TL shall perform the LLDP functionality at the u-plane without the need to interact with the c-plane. Further there is no need for 5GS interaction with TN CNC directly. This is achieved with following measures:
Up

Up   Top   ToC