Content for TS 23.501 Word version: 18.0.0

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…

G.4 An SCP deployment example based on name-based routing H.1 General H.2 Signalling of ingress time for time synchronization H.4 Path and Link delay measurements I.1 Determination of traffic pattern information

G.4 An SCP deployment example based on name-based routing p. 544

G.4.0 General Information p. 544

This clause provides a deployment example for the SCP which is based on a name-based routing mechanism that provides IP over ICN capabilities such as those described in Xylomenos, George, et al. [G1].

The scenario describes an SCP offering based on an SBA-platform to interconnect 5GC Services (or a subset of the respective services). The Name-based Routing mechanism, described in this deployment example, is realized through a Path Computation Element which is the core part of the SCP. The 5GC Services are running as microservices on cloud/deployment units (clusters). A Service Router is the communication node (access node/gateway) between the SCP and the 5GC Services and resides as a single unit within a Service Deployment Cluster. The Service Router acts as communication proxy and it is responsible for mapping IP based messages onto ICN publication and subscriptions. The Service Router serves multiple 5GC Service Endpoints within that cluster. For direct communication the Service Router is not used.

5GC Functionalities communicate with the Service Router using standardized 3GPP SBIs.

The Functionalities within the Service Deployment Cluster are containerized Service Functions.

Depicted in Figure G.4-1, the Service Router act as SCP termination point and offer the SBI to the respective 5GC Service Functionalities. In this example, Service Routers and 5GC functionality, although co-located, are separate components within the Service Deployment Cluster. Multiple Functionalities can exist within the Service Deployment Cluster, all served by the respective Service Router when needed to communicate to other Service Functionalities within different clusters.

Reproduction of 3GPP TS 23.501, Fig. G.4-1: Deployment unit: 5GC functionality and co-located Service Agent(s) implementing peripheral tasks

Figure G.4-1: Deployment unit: 5GC functionality and co-located Service Agent(s) implementing peripheral tasks

In Figure G.4-1, the two depicted 5GC Service Functionalities (realized as Network Function Service Instances) may communicate in two ways. However, before the communication can be established between two 5GC Functionalities, Service Registration and Service Discovery need to take place, as described in Figure G.4.1-1. Service Registration and Service Discovery are provided in a standardized manner using 3GPP Service Based Interfaces.

G.4.1 Service Registration and Service Discovery p. 545

Service registration can be done in several ways. One option is that ready 5GC Service Functions may register themselves with their service profile via the Nnrf interface. The registration request is forwarded to the internal Registry as well as forwarded to the operator's NRF. The internal registration is used to store the address to identifier relationship and the Service Deployment Cluster location. The external registration (NRF) is used to expose the Service Functionality to Services outside the depicted SCP.

Service discovery entails Function A requesting a resolvable identifier for Functionality B. This resolve request is received by the Service Router which performs the task with the help of the SCP. After the resolve is done, the 5GC Functionalities may communicate either directly without any further interaction through the SCP, when the targeted address is resolved within the same Service Deployment Cluster; or via the Service Router when the Functionality resides outside of the originator's Service Deployment Cluster. The Service Router then acts as gateway towards the underlying SCP platform.

Reproduction of 3GPP TS 23.501, Fig. G.4.1-1: Registering 5GC Functionalities in the SCP

Figure G.4.1-1: Registering 5GC Functionalities in the SCP

G.4.2 Overview of Deployment Scenario p. 546

Figure G.4.2-1 shows an overview of this deployment scenario. For SBI-based interactions with other 5GC functionalities, a consumer entity (e.g. 5GC functionality B in the cluster on the left side) communicates through the cluster's Service Router with other entities in other clusters (e.g. 5GC Functionality D in the cluster on the right side). The target selection is performed through the platform's Discovery Service. From the client's perspective, the Service Router is the first and only contact point to the SCP. The platform resolves the requested Service identifier and aligns the results with the platform's policies. The Path Computation Element calculates a path between the consumer and the producer (e.g. the shortest path between the nodes).

Reproduction of 3GPP TS 23.501, Fig. G.4.2-1: (NbR-) SCP interconnects multiple deployment clusters with external NRF

Figure G.4.2-1: (NbR-) SCP interconnects multiple deployment clusters with external NRF

G.4.3 References p. 546

[G1]

Xylomenos, George, et al.: "IP over ICN goes live", 2018 European Conference on Networks and Communications (EuCNC). IEEE, 2018.

H (Normative) PTP usage guidelines |R16| p. 547

H.1 General p. 547

This Annex provides guidelines on the use of certain specific IEEE parameters and protocol messages in the case of TSN as described in clause 5.27.

H.2 Signalling of ingress time for time synchronization p. 547

The ingress timestamp (TSi) of the PTP event (e.g. Sync) message is provided from the ingress TT (NW-TT/UPF or DS-TT/UE) to the egress TT, if supported in the PTP messages as described in clauses 5.27.1.2.2.1 and 5.27.1.2.2.2 using the Suffix field defined in clause 13.4 of IEEE Std 1588 [126]. The structure of the Suffix field follows the recommendation of clause 14.3 of IEEE Std 1588 [126], with an organizationId specific to 3GPP, an organizationSubType referring to an ingress timestamp, and data field that carries the ingress timestamp encoded as specified in clause 5.3.3 of IEEE Std 1588 [126]. TS 24.535 specifies the coding of the ingress timestamp in the (g)PTP messages between a DS-TT and a NW-TT.

H.3 Void

H.4 Path and Link delay measurements |R17| p. 547

The procedure described in this clause is applicable if DS-TT and NW-TT support operating as a boundary clock or as a time-aware system or as peer to peer Transparent Clock or end to end Transparent Clock, and when the PTP instance in 5GS is configured to operate as a time-aware system or as a Boundary Clock or as peer to peer Transparent Clock or as end to end Transparent Clock. Whether DS-TT/NW-TT support operating as a boundary clock or peer to peer Transparent Clock or end to end Transparent Clock or as a time-aware system (support of the IEEE Std 802.1AS [104] PTP profile) may be determined as described in clause K.2.1.

PTP ports in DS-TT and NW-TT may support the following delay measurement mechanisms:

Delay request-response mechanism as described in clause 11.3 of IEEE Std 1588 [126];
Peer-to-peer delay mechanism as defined in clause 11.4 of IEEE Std 1588 [126];
Common Mean Link Delay Service.

Depending on the measurement mechanisms supported by DS-TT and NW-TT as well as the configured clock mode of 5GS, the PTP ports in DS-TT and NW-TT are configured as follows:

PTP ports configured to operate as a time-aware system according to IEEE Std 802.1AS [104] may be configured to use the peer-to-peer delay mechanism or Common Mean Link Delay Service;
PTP ports configured to operate as a Boundary Clock according to IEEE Std 1588 [126] may be configured to use the delay request-response mechanism, the peer-to-peer delay mechanism or Common Mean Link Delay Service.

PTP ports in 5GS configured to operate as a peer-to-peer Transparent Clock according to IEEE Std 1588 [126] shall use the peer-to-peer delay mechanism.

PTP ports in 5GS configured to operate as an end-to-end Transparent Clock according to IEEE Std 1588 [126] do not actively participate in path and link measurements mechanisms but shall calculate and add residence time and delay asymmetry information to PTP messages as defined in clause 10.2.2 of IEEE Std 1588 [126].

If DS-TT and NW-TT support operating as an end-to-end Transparent Clock, then the residence time for one-step operation as an end-to-end Transparent Clock for the path and link measurements is calculated as follows:

Upon reception of a PTP Delay_Req/Pdelay_Req/Pdely_Resp message from the upstream PTP instance, the ingress TT (i.e. NW-TT or DS-TT) makes an ingress timestamping (TSi) for the message.
The ingress timestamp is conveyed to the egress TT via the PDU Session as described in clause H.2.
The PTP port in the egress TT then creates egress timestamping (TSe) for the PTP message for external PTP network. The difference between TSi and TSe is considered as the calculated residence time spent within the 5G system for this PTP message expressed in 5GS time. If needed, the PTP port in the egress TT convert the calculated resident time in 5GS into the residence time expressed in PTP GM time e.g. by means of the factor as specified in Equation (6) of clause 12.2.2 of IEEE Std 1588 [126].
The PTP port in the egress TT modifies the payload of the PTP Delay_Req/Pdelay_Req/Pdelay_Resp message that it sends towards the downstream PTP instance as follows:
- Adds the calculated residence time to the correction field.
- Removes Suffix field that contains TSi.

If DS-TT and NW-TT support operating as an end-to-end Transparent Clock, then the residence time for two-step operation as an end-to-end Transparent Clock for the path and link measurements is calculated as follows:

Upon reception of a PTP Delay_Req/Pdelay_Req/Pdelay_Resp message from the upstream PTP instance, the ingress TT (i.e. NW-TT or DS-TT) makes an ingress timestamping (TSi) for the message.
If the ingress TT receives a Pdelay_Resp message with the twoStepFlag set to FALSE, then the ingress TT modifies the twoStepFlag to TRUE and creates a PTP Pdelay_Resp_Follow_Up message.
The ingress timestamp is conveyed to the egress TT via the PDU Session as described in clause H.2.
The PTP port in the egress TT then creates egress timestamping (TSe) for the PTP message for external PTP network. The difference between TSi and TSe is considered as the calculated residence time spent within the 5G system for this PTP message expressed in 5GS time. If needed, the PTP port in the egress TT converts the calculated residence time in 5GS into the residence time expressed in PTP GM time, e.g. by means of the factor as specified in Equation (6) of clause 12.2.2 of IEEE Std 1588 [126]. The egress TT then stores the calculated residence time expressed in PTP GM time and removes Suffix field that contains TSi before sending the PTP Delay_Req/Pdelay_Req/Pdelay_Resp message towards the downstream PTP instance.
Upon reception of the PTP Delay_Resp message associated with the PTP Delay_Req, the egress TT for the PTP Delay_Req message (i.e. the ingress TT for the PTP Delay_Resp message) modifies the payload of the PTP Delay_Resp message that it sends towards the ingress TT of the PTP Delay_Req message (i.e. egress TT for the PTP Delay_Resp message) as follows:
Adds the (previously stored) calculated residence time to the correction field.
Upon reception (or local creation) of the PTP Pdelay_Resp_Follow_Up message associated with the previously received PTP Pdelay_Resp message, the ingress TT for the PTP Pdelay_Resp_Follow_Up message modifies the payload of the PTP Pdelay_Resp_Follow_Up message that it sends towards the egress TT for the PTP Pdelay_Resp_Follow_Up message as follows:
- Adds the (previously stored) calculated residence time of the associated PTP Pdelay_Req message to the correction field.
Upon reception of the PTP Pdelay_Resp_Follow_Up message associated with the PTP Pdelay_Resp, the egress TT for PTP Pdelay_Resp_Follow_Up message modifies the payload of the PTP Pdelay_Resp_Follow_Up message that it sends towards the downstream PTP instance as follows:
- Adds the (previously stored) calculated residence time of the associated PTP Pdelay_Resp messages to the correction field.

I (Normative) TSN usage guidelines |R16| p. 549

I.1 Determination of traffic pattern information p. 549

As described in clause 5.27.2, the calculation of the TSCAI relies upon mapping of information for the TSN stream(s) based upon certain IEEE standard information.

Additional traffic pattern parameters such as maximum burst size and maximum flow bitrate can be mapped to MDBV and GFBR.

The traffic pattern parameter determination based on PSFP (IEEE Std 802.1Q [98]), when available, is as follows:

Periodicity of a TSN stream is set equal to PSFPAdminCycleTime if there is only one PSFPGateControlEntry with a PSFPgateStatesValue set to Open in the PSFPAdminControlList. If there is more than one PSFPGateControlEntry with a PSFPgateStatesValue set to Open in the PSFPAdminControlList, then the Periodicity of the TSN Stream is set equal to sum of the timeIntervalValues from the first gate open instance to a next gate open instance in the PSFPAdminControlList. For aggregated TSN streams with same periodicity and compatible Burst Arrival Times, the periodicity of the aggregated flow of these TSN Streams is set equal to PSFPAdminCycleTime received from CNC for one of the TSN streams that are aggregated.

NOTE 1:
Given that only TSN streams that have the same periodicity and compatible Burst Arrival Time can be aggregated, the PSFPAdminCycleTime for those TSN streams is assumed to be the same.
Burst Arrival time of a TSN stream at the ingress port is determined based on the following conditions:
- The Burst Arrival Time of a TSN Stream should be set to PSFPAdminBaseTime plus the sum of the timeIntervalValues for which the PSFPgateStatesValue is Closed in the PSFP AdminControlList until the first gate open time (i.e. until PSFPgateStatesValue set to Open is found). If the PSFPgateStatesValue is Open for the first timeIntervalValue, then the Burst Arrival time is set to PSFPAdminBaseTime. For aggregated TSN streams, the arrival time is calculated similarly, but using the time interval to the first PSFPgateStatesValue that is Open from the aggregated TSN streams.
Burst Size of a TSN stream at the ingress port (which is useful to map to MDBV) is determined based on the following conditions:
- The Burst Size may be determined from TSN Stream gate control operations in the PSFPAdminControlList. If in the PSFPAdminControlList, IntervalOctetMax is provided for a PSFPGateControlEntry with an "open" PSFPgateStatesValue, the Burst Size is set to the IntervalOctetMax for that control list entry. If IntervalOctetMax is not provided, the Burst Size is set to the timeIntervalValue (converted from ns to s) of the PSFPGateControlEntry with an "open" PSFPgateStatesValue multiplied by the port bitrate.
- When multiple compatible TSN Streams are aggregated, the Burst Size is set to the sum of the Burst Sizes for each TSN stream as determined above.
Maximum Flow Bitrate of a TSN stream (which is useful to map to GBR) is determined as follows:
- The Maximum Flow Bitrate of a TSN Stream is equal to the summation of all timeIntervalValue (converted from ns to s) with PSFPgateStatesValue = Open, multiplied by the bitrate of the corresponding port, and divided by PSFPAdminCycleTime. For aggregated TSN streams, the same calculation is performed over the burst of aggregated streams (calculated using superposition, i.e. timeIntervalValue with PSFPgateStatesValue = Open of every stream is summed up, as they are assumed to have same periodicity, compatible Burst arrival time, and same traffic class if they are to be aggregated.
  When CNC configures the PSFP information to the TSN AF, the TSN AF may use local information (e.g. local configuration) to map the PSFP information to an ingress port and/or egress port of the 5GS bridge.
  
  NOTE 2:
  As an example, for the local configuration, the PSFP can use either the destination MAC address and VLAN identifier, or the source MAC address and VLAN identifier for stream identification. The TSN AF is pre-configured with either the MAC address of Ethernet hosts behind a given DS-TT port (identified by the DS-TT port MAC address), or the VLAN identifier used over a given DS-TT port, or both. When the TSN AF determines that one of the known Ethernet host's MAC address appears as a source or destination MAC address, it can identify that the ingress or egress port is the associated DS-TT port.