Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.501  Word version:   16.4.0

Top   Up   Prev   Next
1…   3…   4…   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 routingWord-p. 404
G.4.0  General Information
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.
Up
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.
Up
G.4.1  Service Registration and Service DiscoveryWord-p. 405
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.
Up
G.4.2  Overview of Deployment ScenarioWord-p. 406
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).
Up
G.4.3  References
[G1]  Xylomenos, George, et al.: "IP over ICN goes live", 2018 European Conference on Networks and Communications (EuCNC). IEEE, 2018.
H (Normative)  TSN usage guidelines [R16]Word-p. 407
H.1  General
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
The ingress time is provided from the NW-TT/UPF to the DS-TT/UE as part of a gPTP Sync or Follow_up message using the Suffix field defined in clause 13.4 of IEEE 1588-2008 [107]. The structure of the Suffix field follows the recommendation of clause 14.3 of IEEE 1588-2008 [107], 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 1588-2008 [107]. TS 24.535 specifies the fields in the gPTP Sync message.
Up
I (Normative)  TSN usage guidelines [R16]Word-p. 408
I.1  Determination of traffic pattern information
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 P802.1Q [98]) 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:
    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. If the PSFPgateStatesValue is Closed for the first timeIntervalValue, then the Arrival time is set to PSFPAdminBaseTime plus the first timeIntervalValue. 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.
  • Flow direction of a TSN stream is determined based on the following conditions:
    • If the ingress port PSFP information is targeted for a DS-TT port, the Flow direction is UL. If the ingress port PSFP information is targeted for a NW-TT port, the Flow direction is DL.
  • 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 size of a TSN stream (which is useful to map to GFBR) 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.
Up

Up   Top   ToC