Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.501  Word version:  17.6.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 |R16|p. 532

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
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. 534

K.1  Standardized port and user plane node management informationp. 534

K.2  Port and user plane node management information exchange for time synchronizationp. 534

K.2.1  Capability exchangep. 534

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 configurationp. 534

K.2.2.1  Generalp. 534

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 timeoutsp. 536

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 statesp. 536

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 functionp. 536

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 intervalsp. 537

The TSN AF or TSCTSF uses the values in portDS.log­SyncInterval (for Boundary Clock) or portDS.initialLog­SyncInterval, portDS.useMgtSettableLog­SyncInterval and portDS.mgtSettableLog­SyncInterval (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 protocolsp. 537

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. 539

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

$  Change historyp. 540


Up   Top