Tech-invite  3GPPspace  IETF RFCs  SIP
index  21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.501  Word version:  18.0.0

Top   Top   Up   Prev   None
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.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… 
J Link MTU considerations  K Port and user plane node management information exchange  K.1 Standardized port and user plane node management information  K.2 Port and user plane node management information exchange for time synchronization  L Support of GERAN/UTRAN access  M Interworking with TSN deployed in the Transport Network  M.1 Mapping of the parameters between 5GS and TSN UNI  $ Change history 

 

J  Link MTU considerations |R16|  p. 551

According to clause 5.6.10.4 networks can provide link MTU size for UEs. A purpose of the link MTU size provisioning is to limit the size of the packets sent by the UE to avoid packet fragmentation in the backbone network between the UE and the UPF acting as PSA (and/or across the N6 reference point). Fragmentation within the backbone network creates a significant overhead. Therefore operators might desire to avoid it. This Annex presents an overhead calculation that can be used by operators to set the link MTU size provided by the network. A UE might not employ the provided link MTU size, e.g. when the MT and TE are separated, as discussed in clause 5.6.10.4. Therefore, providing an MTU size does not guarantee that there will be no packets larger than the provided value. However, if UEs follow the provided link MTU value operators will benefit from reduced transmission overhead within backbone networks.
One of the worst-case scenarios is when GTP packets, e.g. between a NG-RAN node and the 5GC, are transferred over IPSec tunnel in an IPv6 deployment. In that case the user packet first encapsulated in a GTP tunnel which results in the following overhead:
  • IPv6 header, which is 40 octets;
  • UDP overhead, which is 8 octets;
  • Extended GTP-U header, which is 16 octets.
In this scenario the GTP packet then further encapsulated into an IPSec tunnel. The actual IPSec tunnel overhead depends on the used encryption and integrity protection algorithms. TS 33.210 mandates the support of AES-GMAC with a key length of 128 bits and the use of HMAC_SHA-1 for integrity protection. Therefore, the overhead with those algorithms is calculated as:
  • IPv6 header, which is 40 octets;
  • IPSec Security Parameter Index and Sequence Number overhead, which is 4+4 octets;
  • Initialization Vector for the encryption algorithm, which is 16 octets;
  • Padding to make the size of the encrypted payload a multiple of 16;
  • Padding Length and Next Header octets (2 octets);
  • Integrity Check Value, which is 12 octets.
In order to make the user packet size as large as possible a padding of 0 octet is assumed. With this zero padding assumption the total overhead is 142 octets, which results a maximum user packet size of transport MTU minus 142 octets. Note that in the case of transport MTU=1500, this user packet size will result in a 1424 octets payload length to be ciphered, which is a multiple of 16, thus the assumption that no padding is needed is correct (see Figure J-1). Similar calculations can be done for networks with transport that supports larger MTU sizes.
Reproduction of 3GPP TS 23.501, Fig. J-1: Overhead calculation for transport MTU=1500 octet
Figure J-1: Overhead calculation for transport MTU=1500 octet
Up
The link MTU value that can prevent fragmentation in the backbone network between the UE and the UPF acting as PSA depends on the actual deployment. Based on the above calculation a link MTU value of 1358 is small enough in most of the network deployments. However for network deployments where the transport uniformly supports for example ethernet jumbo frames, transport MTU≤9216 octets can provide a much larger UE MTU and hence more efficient transfer of user data. One example of when it can be ensured that all links support larger packet sizes, is when the UE uses a specific Network Slice with a limited coverage area.
Note that using a link MTU value smaller than necessary would decrease the efficiency in the network. Moreover, a UE might also apply some tunnelling (e.g. VPN). It is desirable to use a link MTU size that assures at least MTU minus 220 octets within the UE tunnel to avoid the fragmentation of the user packets within the tunnel applied in the UE. In the case transport MTU is 1500 octets, this results a link MTU of 1280 octets (for the transport), which is the minimum MTU size in the case of IPv6.
The above methodology can be modified for calculation of the UE's link MTU when a UPF has MTU limits on the N6 reference point and is offering a PDU Session with Ethernet or Unstructured PDU Session type between the UPF and the UE.
Up

K (Normative)  Port and user plane node management information exchange |R17|  p. 553

K.1  Standardized port and user plane node management information  p. 553

K.2  Port and user plane node management information exchange for time synchronization  p. 553

K.2.1  Capability exchange  p. 553

DS-TT and NW-TT indicate time synchronization information they support inside the Port management capabilities (see Table 5.28.3.1-1).
TSN AF and TSCTSF may determine the PTP functionalities supported by DS-TT and NW-TT by retrieving the following port management information or user plane node management information, respectively:
  • Supported PTP instance types;
  • Supported transport types;
  • Supported PTP delay mechanisms;
  • Grandmaster capability;
  • Supported PTP profiles;
  • Number of supported PTP instances.
If DS-TT and NW-TT support the PTP Relay instance type as defined by IEEE 802.1AS [104] then DS-TT and NW-TT shall include the IEEE 802.1AS [104] PTP profile in the "Supported PTP profiles" in PMIC and UMIC, respectively.
The TSN AF or TSCTSF may retrieve the "Number of supported PTP instances" from NW-TT via UMIC and from DS-TT via PMIC.
Up

K.2.2  PTP Instance configuration  p. 553

K.2.2.1  General  p. 553

Based on input received from external applications (CNC in case of TSN AF or any AF in case of TSCTSF), TSN AF or TSCTSF may configure PTP instances (identified by PTP Instance ID) in a DS-TT or NW-TT by sending port management information (PMIC, see Table 5.28.3.1-1) and user plane node management information (UMIC, see Table 5.28.3.1-2) to DS-TT or NW-TT as described below:
  • use PMIC "PTP instance specification" for configuring DS-TT(s) for PTP instance data sets common for all PTP ports (i.e. defaultDS and TimePropertiesDS), and PTP instance data sets specific for each PTP port (i.e. portDS data set);
  • use UMIC "PTP instance specification" for configuring NW-TT for PTP instance data sets common for all PTP ports;
  • use PMIC "PTP instance specification" for configuring NW-TT for PTP instance data sets specific for each PTP port;
  • use UMIC "Time synchronization information for DS-TT ports" for configuring NW-TT for PTP instance data sets specific for each PTP port for the PTP ports in DS-TT(s).
TSN AF or TSCTSF may also configure PTP instances for DS-TT ports in NW-TT by sending UMIC (see Table 5.28.3.1-2) to NW-TT to enable NW-TT to operate as a grandmaster on behalf of DS-TT (see clause K.2.2.4 for more details).
For each PTP instance the TSN AF or TSCTSF may provide individual PTP configuration parameters or may provide a PTP profile ID to DS-TT or NW-TT. The DS-TT and NW-TT use the default values as defined in the corresponding PTP Profile, if individual PTP configuration parameters that are covered by the PTP profile are not provided.
To configure DS-TT and NW-TT to operate as a PTP relay instance, TSN AF or TSCTSF shall set the PTP profile (see Table 5.28.3.1-1) to IEEE Std 802.1AS [104].
DS-TT may operate as a PTP relay instance with the gPTP GM connected on N6 until the first PTP instance is configured in the DS-TT by TSN AF or TSCTSF.
To initialize a PTP instance in 5GS, TSN AF or TSCTSF creates a new PTP instance in NW-TT by assigning a new PTP Instance ID and indicating it to the NW-TT in "PTP instance specification" in UMIC and PMIC(s) for each NW-TT port that is part of the PTP instance. TSN AF or TSCTSF then retrieves the "defaultDS.clockIdentity" of the PTP instance in NW-TT via UMIC. NW-TT ensures that the clockIdentity in defaultDS in UMIC matches with the clockIdentity in the portDS.portIdentity in PMIC(s) for a particular PTP Instance ID.
To add a DS-TT port into an existent PTP instance in 5GS, the TSN AF or TSCTSF indicates the PTP Instance ID (to which the DS-TT port is being added) to the DS-TT in "PTP instance specification" in PMIC, and indicating the PTP Instance ID to the NW-TT in "Time synchronization information for DS-TT ports" in UMIC for the corresponding DS-TT port.
For a particular PTP instance in NW-TT, the same PTP Instance ID shall be used in "PTP instance specification" in PMIC, in "PTP instance specification" in UMIC, and in "Time synchronization information for DS-TT ports" in UMIC.
The TSN AF or TSCTSF then initializes the PTP instance in the DS-TT by setting the applicable PTP instance data sets common for all PTP ports (i.e. defaultDS and TimePropertiesDS), (including"defaultDS.clockIdentity") via "PTP instance specification" in PMIC to the same value as retrieved from the NW-TT via "PTP instance specification" in UMIC. The TSN AF or TSCTSF also enables the PTP instance by setting the defaultDS.instanceEnable = TRUE to DS-TT via PMIC and to NW-TT via UMIC (if applicable). The TSN AF or TSCTSF can initialize any number of PTP instances:
  1. among the DS-TT(s) and NW-TT that are part of the same set of PTP instances in 5GS; up to the maximum number of supported PTP instances by the NW-TT or DS-TT that supports the lowest number of supported PTP instances; and
  2. in the NW-TT; up to the maximum number of supported PTP instances by the NW-TT.
To remove a DS-TT port from a PTP instance in 5GS, the TSN AF or TSCTSF deletes the PTP instance in DS-TT using PMIC and in NW-TT using UMIC as specified in TS 24.539. To remove a NW-TT port from a PTP instance in 5GS, the TSN AF or TSCTSF deletes the PTP instance in NW-TT using PMIC as specified in TS 24.539. If a PTP instance in 5GS is no more needed the TSN AF or TSCTSF may delete the PTP instance in NW-TT using UMIC as specified in TS 24.539.
Up

K.2.2.2  Configuration for Sync and Announce reception timeouts  p. 555

The NW-TT shall be able to determine the timeout of the reception of (g)PTP Announce (when the 5GS operates as a time-aware system or Boundary Clock) and gPTP Sync messages (when the 5GS operates as time-aware system). To enable this, the TSCTSF or TSN AF shall configure the NW-TT for the following information via PMIC for each PTP port in NW-TT and "Time synchronization information for each DS-TT port" element in UMIC for each PTP port in DS-TT:
  • portDS.announceReceiptTimeout (for time-aware system and Boundary Clock);
  • portDS.syncReceiptTimeout (for time-aware system);
  • portDS.logAnnounceInterval (for Boundary Clock);
  • portDS.initialLogAnnounceInterval, portDS.useMgtSettableLogAnnounceInterval, and
  • portDS.mgtSettableLogAnnounceInterval (for time-aware system).
Up

K.2.2.3  Configuration for PTP port states  p. 555

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 TSN AF or TSCTSF sets the defaultDS.externalPortConfigurationEnabled (per PTP instance) in UMIC to TRUE, and sets the value of externalPortConfigurationPortDS.desiredState (per PTP port) in UMIC for each DS-TT port and in PMIC for each NW-TT port for the (g)PTP domain.

K.2.2.4  Configuration for PTP grandmaster function  p. 555

The following options may be supported (per DS-TT) for the 5GS to generate the Sync, Follow_Up and Announce messages for the Leader 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).
  2. DS-TT generates the Sync, Follow_Up and Announce messages in this DS-TT.
TSN AF and TSCTSF may use the elements in port and user plane node management information container to determine the PTP grandmaster functionality supported by DS-TT and NW-TT and may configure the DS-TT and NW-TT ports to operate as in option a) or b) as follows:
  • The "PTP grandmaster capable" element and the "gPTP grandmaster capable" element in PMIC are used to indicate the support for PTP or gPTP grandmaster capability, respectively, in each DS-TT. If the TSN AF or TSCTSF determines the DS-TT supports grandmaster capability (PTP or gPTP grandmaster capable is TRUE), then either option a) or b) can be used for the PTP instance(s) in the DS-TT. Otherwise, only option a) can be used for the PTP instance(s) in the DS-TT.
  • To enable option a) for PTP ports in DS-TT, the TSN AF or TSCTSF sets the element "Grandmaster on behalf of DS-TT enabled" TRUE (per PTP instance per DS-TT) in UMIC for the respective DS-TT port, and the TSN AF or TSCTSF sets the element "Grandmaster enabled" FALSE (per PTP instance per DS-TT) in PMIC to the respective DS-TT port.
  • To enable option b) for PTP ports in DS-TT, the TSN AF or TSCTSF sets the element "Grandmaster on behalf of DS-TT enabled" FALSE in UMIC (per PTP instance per DS-TT) for the respective port, and the TSN AF or TSCTSF sets the element "Grandmaster enabled" TRUE (per PTP instance per DS-TT) in PMIC to the respective DS-TT port.
  • To enable either option a) or option b) for a PTP instance, the TSN AF or TSCTSF sets the element "Grandmaster candidate enabled" TRUE (per PTP instance) in UMIC.
  • When option b) is used for one or more PTP ports in DS-TT(s), the TSN AF or TSCTSF shall use the elements in defaultDS in PMIC for the respective DS-TT(s) and in UMIC for NW-TT to ensure that all PTP ports in the DS-TT(s) and NW-TT in particular PTP instance are distributing the same values of grandmasterPriority1, grandmasterClockQuality, grandmasterPriority2, grandmasterIdentity, and timeSource message fields in Announce messages.
Up

K.2.2.5  Configuration for Sync and Announce intervals  p. 556

The TSN AF or TSCTSF uses the values in portDS.logSyncInterval (for Boundary Clock) or portDS.initialLogSyncInterval, portDS.useMgtSettableLogSyncInterval and portDS.mgtSettableLogSyncInterval (for time-aware system) to configure the interval for the Sync messages (per PTP port) as described in IEEE Std 1588 [126] or IEEE Std 802.1AS [104], respectively. The TSCTSF or TSN AF configures those values as follows:
  • TSCTSF or TSN AF use PMIC to configure the values for the PTP ports in NW-TT.
  • TSCTSF or TSN AF use the "Time synchronization information for each DS-TT port" element in UMIC to configure the values for PTP ports in DS-TT(s) if NW-TT acts as GM on behalf of those DS-TTs.
  • TSCTSF or TSN AF use PMIC to configure the values for the PTP ports in DS-TT if the DS-TT is capable of acting as a GM.
When the NW-TT generates the (g)PTP Sync messages on behalf of the DS-TT, the NW-TT uses the values in the element "Time synchronization information for each DS-TT port" in UMIC to determine the Sync interval for the PTP ports the respective DS-TT. When DS-TT generates the (g)PTP Sync messages, the DS-TT uses the values in PMIC to determine the Sync interval for the PTP ports in this DS-TT.
The TSN AF or TSCTSF uses the values in portDS.logAnnounceInterval (for Boundary Clock) or portDS.initialLogAnnounceInterval, portDS.useMgtSettableLogAnnounceInterval and portDS.mgtSettableLogAnnounceInterval (for time-aware system) to configure the interval for the Announce messages (per PTP port) as described in IEEE Std 1588 [126] and IEEE Std 802.1AS [104], respectively. The TSCTSF or TSN AF configures those values as follows:
  • TSCTSF or TSN AF use PMIC to configure the values for the PTP ports in NW-TT.
  • TSCTSF or TSN AF use the "Time synchronization information for each DS-TT port" element in UMIC to configure the values for PTP ports in DS-TT(s) if NW-TT acts as GM on behalf of those DS-TTs.
  • TSCTSF or TSN AF use PMIC to configure the values for the PTP ports in DS-TT if the DS-TT is capable of acting as a GM.
When the NW-TT generates the (g)PTP Announce messages on behalf of the DS-TT, the NW-TT uses the values in the element "Time synchronization information for each DS-TT port" in UMIC to determine the Announce interval for the PTP ports the respective DS-TT. When DS-TT generates the (g)PTP Announce messages, the DS-TT uses the values in PMIC to determine the Announce interval for the PTP ports in this DS-TT.
Up

K.2.2.6  Configuration for transport protocols  p. 556

The procedure described in this clause is applicable when the PTP Profile that is used for the PTP instance in 5GS defines multiple permitted transport protocols.
TSN AF or TSCTSF may use the element "Supported transport types" in port management information container (per DS-TT) to determine the supported transport types in the DS-TT. TSN AF or TSCTSF may use the element "Supported transport types" in UMIC (per NW-TT) to determine the supported transport types in the NW-TT.
The TSN AF or TSCTSF may use the element "Transport type" (per PTP instance) in PMIC to configure the transport protocol in use for the PTP instance in DS-TT. The TSN AF or TSCTSF may use the element "Transport type" (per PTP instance) in UMIC to configure the transport protocol in use for the PTP instance in NW-TT.
The PTP instance shall be configured to use one of the following transport protocols:
  1. Ethernet as described in Annex E of IEEE Std 1588 [126]. The Ethertype as defined for PTP shall be used. The related Ethernet frames carry the PTP multicast Ethernet destination MAC address.
  2. UDP over IPv4 as described in Annex C of IEEE Std 1588 [126],
  3. UDP over IPv6 as described in Annex D of IEEE Std 1588 [126].
Option 1 applies to Ethernet PDU Session type. Options 2 and 3 apply to IP PDU Session type or Ethernet PDU Session type with IP payload.
Up

L (Normative)  Support of GERAN/UTRAN access |R17|  p. 558

This Annex applies when the SMF+PGW-C is enhanced to support UE accessing the network via GERAN/UTRAN over Gn/Gp interface. For this scenario, the SMF+PGW-C uses N7 interface to interact with PCF and the N40 interface to interact with CHF.
SMF+PGW-C selection by SGSN is specified in Annex G of TS 23.502.
The SMF+PGW-C interacting with PCF for GERAN/UTRAN access is specified in Annex G of TS 23.502.
The functional description for SMF+PGW-C interacting with PCF to support GERAN/UTRAN access is specified in TS 23.503.
The charging services on SMF+PGW-C interactions with CHF for GERAN/UTRAN access are specified in TS 32.255.
Up

M (Normative)  Interworking with TSN deployed in the Transport Network |R18|  p. 559

M.1  Mapping of the parameters between 5GS and TSN UNI  p. 559

The details of the parameters in the TSN UNI are specified in IEEE Std 802.1Qcc [95]) and IEEE P802.1Qdj [146].
The SMF/CUC derives the End Station related information for the stream requirements towards the TN CNC for the QoS Flow as follows:
  1. For the Talker group:
    • StreamID: can be generated by the SMF/CUC based on the End Station MAC address acting as Talker, and PDU Session ID and QFI. The MAC address is either pre-configured at the SMF/CUC or provided by the AN-TL or CN-TL to the SMF/CUC (e.g., as part of the EndStationInterfaces information).
    • StreamRank: set to zero for ARP priority values 1-8; set to one for other ARP values.
    • EndStationInterfaces: If the AN-TL and CN-TL are supported, the SMF/CUC receives the EndStationInterfaces (MacAddress, InterfaceName) from the AN-TL and CN-TL via TL-Container. If the AN-TL and CN-TL are not supported the SMF/CUC sets the information based on pre-configuration.
    • DataFrameSpecification (optional): When it is present it specifies how the TN can identify packets of the TN stream in order to apply the required TSN configuration. If the AN-TL and CN-TL are supported, the SMF/CUC does not include the DataFrameSpecification to the TN CNC.
      If the AN-TL and CN-TL are not supported, the SMF/CUC derives the DataFrameSpecification based on the N3 tunnel end point addresses/ports that are used for the QoS Flow. The SMF/CUC instruct the UPF and NG-RAN to assign a separate N3 tunnel end point address for each QoS Flow. This ensures the TN can distinguish the QoS Flows based on the N3 tunnel destination IP addresses.
      If the DataFrameSpecification is provided to the TN CNC, the TN CNC configures the edge bridge to perform the stream transformation based on the provided the DataFrameSpecification
    • TrafficSpecification elements:
    • Interval: derived from the Periodicity of the traffic as indicated in the TSCAI.
    • MaxFramesPerInterval: specifies the algorithm that the Talker uses to transmit the Stream's traffic class. If no algorithm is known, the value zero (strict priority) is used.
    • MaxFrameSize: derived from the Burst Size of the QoS Flow. The PCF transfers the Burst Size to the SMF/CUC. The SMF/CUC sets MaxFrameSize based on the following formula: Burst Size of the QoS Flow - the framing bits which is not used for transferring in 5GS, (e.g. CRC + the GTP-U tunnel overhead).
    • TransmissionSelection: is set to zero.
    • TSpecTimeAware group (optional, present only if the traffic in the QoS Flow is time-synchronized):
    • EarliestTransmitOffset: the earliest offset within the Interval.
      For uplink, EarliestTransmitOffset should be set based on the following formula:
      TSCAC BAT in UL direction (presented in TAI time and corrected for clock drifting as specified in TS 23.501) + UE-DS-TT Residence Time + 5G-AN PDB - M x Interval, where M is the largest integer for which the relation:
      TSCAC BAT in UL direction + UE-DS-TT Residence Time + 5G-AN PDB > M x Interval duration.
      would be true.
      For downlink, EarliestTransmitOffset should be set based on the following formula:
      TSCAC BAT in DL direction (presented in TAI time and corrected for clock drifting as specified in TS 23.501) + UPF Residence Time - M x Interval, where M is the largest integer for which the relation:
      TSCAC BAT in DL direction + UPF Residence Time > M x Interval duration.
      would be true.
    • LatestTransmitOffset: the last chance within an interval should leave enough time to transfer a packet with MaxFrameSize. Derived from the end of the interval, subtracted by the sum of Jitter and the time to transfer a packet with MaxFrameSize.
    • Jitter: derived based on local configuration.
    • UserToNetworkRequirements:
      • NumSeamlessTrees: set to one (no redundancy) or other value (if redundancy is required).
      • MaxLatency: set to CN PDB subtracted by UPF Residence Time and maximum possible buffer duration in Talker. Maximum possible buffer duration is set to LatestTransmitOffset subtracted by EarliestTransmitOffset up to Buffer capability sent by the Talker.
    • InterfaceCapabilities (optional): If the AN-TL and CN-TL are supported, the SMF/CUC collects InterfaceCapabilities from AN-TL and CN-TL via TL-Container. If the AN-TL and CN-TL are not supported, the SMF/CUC leaves the InterfaceCapabilities empty.
  2. For the Listener group:
    • Stream ID and Stream Rank: that were generated for the Talker of the TN stream are also used by the SMF/CUC for the Listener.
    • EndStationInterfaces: derived as with the corresponding information for the Talker group.
    • UserToNetworkRequirements:
      • NumSeamlessTrees: set to one.
      • MaxLatency: derived as with the corresponding information for the Talker group.
    • InterfaceCapabilities: derived as with the corresponding information for the Talker group.
  3. For the Status group: The Status group contains the end station communication-configuration provided by TN CNC to the SMF/CUC:
    • Stream ID.
    • StatusInfo.
    • AccumulatedLatency: If the AccumulatedLatency is included from TN CNC to SMF/CUC for a stream in DL direction, the SMF/CUC may use the AccumulatedLatency to update the TSCAI BAT to the NG-RAN; the SMF sets the TSCAI Burst Arrival Time in downlink direction as the sum of the TSCAC BAT value in downlink direction and AccumulatedLatency, and UPF Residence Time and the buffer duration in Talker in CN-TL. The buffer duration in CN-TL is zero if TimeAwareOffset for the Talker group is not present, and TimeAwareOffset - EarliestTransmitOffset if the TimeAwareOffset is present for the Talker group.
    • InterfaceConfiguration (optional):
    • MAC Address (optional, present only if the respective InterfaceCapability contains a value for Active Destination MAC and VLAN Stream identification in CB-StreamIdenTypeList, and stream transformation is performed in AN-TL and CN-TL).
    • VLAN Tag (optional, present only if the respective InterfaceCapability contains that it is VlanTagCapable and a value for Active Destination MAC and VLAN Stream identification in CB-StreamIdenTypeList, and the stream transformation is performed in AN-TL and CN-TL).
    • IPv4/IPv6 Tuples (optional, but not supported in this release of the specification).
    • TimeAwareOffset (optional, present only if the traffic is time-synchronized, AN-TL and CN-TL is supported, and TSpecTimeAware elements were provided in the stream requirements).
      If the InterfaceConfiguration is included from TN CNC to SMF/CUC, and if the AN-TL/CN-TL are supported, and AL-TL/CN-TL support the Stream Transformation as described in IEEE Std 802.1Qcc [95], the SMF/CUC can instruct the UPF and NG-RAN to assign for each QoS Flow an individual TSN Transport address by providing the InterfaceConfiguration to the AN-TL/CN-TL via TL-Container. The Talker in AN-TL/CN-TL shall use the indicated InterfaceConfiguration, e.g. source MAC address, multicast destination MAC address, VLAN ID, as assigned by the TN CNC for the data stream in a QoS Flow. The TN can identify the streams based on the Stream Transformation that is applied in the Talker in the AN-TL/CN-TL. This allows to use a single GTP-U tunnel as defined for non-TSN Transport networks.
      If the TimeAwareOffset is included from TN CNC to SMF/CUC, the SMF/CUC should derive input information based on the TimeAwareOffset, which allows to configure Gate Control information as defined in IEEE Std 802.1Q [98] at the AN-TL (for streams in UL direction) and the CN-TL port (for streams in the DL direction), i.e., AdminBaseTime, AdminCycleTime, AdminControlListLength, and AdminControlList). The AN-TL or CN-TL acting as Talker buffers the data burst until the time indicated in the TimeAwareOffset is reached.
      If the SMF/CUC receives a TimeAwareOffset from TN CNC for a downlink stream (i.e. for a Talker in the UPF/CN-TL), the SMF/CUC adds the received TimeAwareOffset value to the TSCAI BAT in the DL direction in the TSCAI and updates the NG-RAN for the new TSCAI.
    • FailedInterfaces (optional) provides a list of one or more physical ports of failed end stations or bridges to locate the interfaces in the physical topology that caused the failure.
Up

$  Change history  p. 562

Up   Top