DetNet YANG Model Extension for 5GS as a Logical DetNet Node

Recently the 3GPP Rel-18 has completed the working item (WID) of the DetNet, i.e., the Deterministic Network. This WID defines and standardizes how a 5G system (5GS) may behave as a logical DetNet node, as well as how a 5GS DetNet node may integrate into the IP-domain deterministic network. As of now, the Rel-18 has only realized the functionalities of the DetNet forwarding sub-layer .

5GS – A Logical DetNet Transit Node As shown in the , the 5G system or 5GS is a logical DetNet transit node that are comprised of various 5G network functions or NFs, e.g. AMF, SMF, UPF, PCF, etc. It behaves holistically as a transparent box to external networks (as demarcated by the dotted box in the ), and can be integrated with the IP deterministic network as defined in IETF RFC 8655 . The 5G NF TSCTSF performs mappings in the control plane between the 5GS internal NFs and the DetNet controller in the IP domain. As a black box-like transit node, the 5GS specific procedures in both the 5G core (i.e., 5GC) and the radio access network (i.e., RAN) remain hidden from the IP DetNet controller.

The 5GS logical DetNet node, as a whole, has two types of external-facing interfaces, i.e., the device-side ports or DS-TT, and the network-side ports or NW-TT. On the device side, a UE via its DS-TT ports connects with external DetNet entities, which might be DetNet end systems or full-fledged IP DetNet nodes (e.g., IP DetNet routers). This scenario would be a typical deployment for small businesses to achieve deterministic network connectivity via 5G wireless services. On the network side, the NW-TT functionalities could co-exist with the 5G NF UPF, though it is not mandatory. A NW-TT port is connected via the 5G data-plane to external DetNet domain (most likely, the IP deterministic network). Note that there is a need of coordination between the 5GS mobile operator and the IP-domain service provider to support various functionalities, e.g., AAA, signaling exchange, etc. This is currently based on the assumption of the existence of a pre-determined business agreement between the two parties to support the interactions between the 5GS TSCTSF and the IP DetNet controller . The interface between the TSCTSF and the DetNet controller uses protocols defined in IETF. The DetNet configuration is carried in the YANG model

Composite Architecture of a 5GS Logical DetNet Node As shown in the , a 5GS (composite) node (or so-tagged ‘bridge’ in the figure) is composed of the ports on the UPF network side (i.e., NW-TT), the user plane tunnels between the UE and UPF (i.e., PDU sessions), and the ports on the device side (i.e., DS-TT). For a 5GS DetNet node, the NW-TT ports, the DS-TT ports and the correspondingly associated PDU Sessions together support the 5GS connectivity to the deterministic network.

According to 3GPP TS 23.501 , a 5GS logical DetNet node bears the ‘composite’ architecture in that it could act as one or more DetNet routers upon the integration into the IP-domain deterministic network. The granularity of determining a 5GS DetNet node is per UPF for each network instance, or per DNN/S-NSSAI in 3GPP term. For example, in the , there are two 5GS DetNet nodes corresponding respectively to two UPFs, i.e., the UPF-A matching to the DetNet node ‘Bridge-A’ and the UPF-B matching to the DetNet node ‘Bridge B’, respectively. A 5GS DetNet node may be identified by the corresponding UPF node ID.

YANG Configuration Provisioning of 5GS Logical DetNet Node The 5GS NF TSCTSF maps the configuration parameters in the format of DetNet YANG model, e.g., DetNet flow attributes, DnTrafficSpec, DnFlowReqs, DnMaxLatency, DnMaxLoss, etc., that are provided from the IP-domain DetNet controller (so-tagged as ‘CPF:DetNet Conoller’ in the ), to 5GS parameters as defined in TS 23.503 . Once the provisioning is completed, the TSCTSF provides a response to the (IP-domain) DetNet controller regarding the (success or failure) status of the configuration setup. As of the completion of the 3GPP Rel-18 work, the IETF DetNet YANG model draft has been identified and referenced for the purpose of provisioning the DetNet traffic parameters to a 5GS logical DetNet node. This IETF draft standardizes the specification of the DetNet YANG model for configuration and operational data of a DetNet flow so as to provision the end-to-end service on devices along the path. However, from the perspective of 5GS-being-a-logical-DetNet-node, the QoS requirements, e.g., max-latency, max-loss, etc., have to be (5GS) node-specific. As such, this discrepancy led to liaison exchanges between the 3GPP SA2 and the IETF DetNet working groups . Due to unfavourable comments by the IETF DetNet WG, 3GPP decided to pursue the 3GPP-centric extension to the IETF draft , and plan to define a YANG model by importing with the addition of 3GPP related DetNet specific parameters. The 3GPP defined YANG model will use the 3GPP namespace as defined in IETF RFC 5279 . However, this special 3GPP-extension handling bears a limited scope and will be tailored only for 3GPP and 5GS DetNet node. The per-(logical)-node DetNet traffic parameters are general traffic characteristics that should be standardized best in the IETF DetNet WG. Fortunately, there is an IETF DetNet WG draft that works on defining a YANG data model for DetNet topology discovery and capability configuration on the per-(logical)-node basis . We have presented and discussed the draft in the IETF-116, and authors of the draft have been revising it since then. As a consequence, the 3GPP SA2 DetNet team have thus discussed this draft and agreed to improve the 5GS standards once the draft matures.

Apart from the lack of configuring per-(logical)-node parameters as mentioned in the , we also believe that, based on the requirements of 3GPP extension, the standardized operations of a 5GS DetNet node shall be improved with the definition of certain new DetNet YANG parameters, e.g., the type of a (composite) DetNet node, the composite node ID, and the flow direction within a 5GS logical node.

Type of a DetNet node The 3GPP document TR 23.700-46 concludes to define the type of a 5GS DetNet node. It claims to be useful for the IP-domain DetNet controller to identify that the 5GS node is a 3GPP defined 5GS system, rather than a router with fixed interfaces only. This knowledge can be useful for the DetNet controller to consider for the QoS that can be provided for a flow. Further, the node-type parameter can be generalized to other non-5GS scenarios. For example, the application of some advanced features, e.g., network slicing, virtual-router setting, etc., would divide a single physical node into multiple logical nodes, for which the node-type parameter will help a DetNet controller do better provisioning.

Composite node ID & DetNet node ID As we have explained in the , a 5GS logical DetNet node bears the ‘composite’ architecture in that it could act as one or more DetNet routers to the IP-domain Deterministic Network. The granularity of the 5GS DetNet node (or router) is per UPF, and a 5GS DetNet node may be identified by the corresponding UPF node ID. Thus, it would be better to define a new parameter to differentiate the higher-level composite nature of a 5GS node.

Directions of 5GS DetNet parameters: Uplink vs. Downlink The illustrates that a 5GS DetNet router can be comprised of the NW-TT ports, the user plane (UP) tunnels between the UE and UPF, and the DS-TT ports. This corresponds roughly to directional, i.e., either Uplink/UL or Downlink/DL, associations among ports and tunnels. TS 23.501 specifies that the 5GS NF TSCTSF uses the identities of the incoming and outgoing interfaces, i.e., DS-TT and NW-TT ports, to determine whether the direction is uplink or downlink. For DetNet related parameters, e.g., per-node max-loss, per-node max-latency, etc., they might have asymmetric settings between the UL and DL directions. So, we propose to define a 'direction' parameter in the enhanced YANG model.

YANG Model for 5GS Information Exposure The spec. 3GPP TS 23.501 also standardizes the reporting scheme of a 5GS DetNet node to the IP-domain DetNet controller. Basically, a 5GS DetNet node may provide exposure information to the IP-domain 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 (of a holistic DetNet domain). The exposure may be based on IETF RFC 8343 and IETF RFC 8344 . Note that while the configuration provisioning and the information reporting involve the opposite directions of data flow between a 5GS and a DetNet controller, there is no material difference in term of the YANG model definition in either direction. Therefore, we do not need to differentiate them in our YANG model enhancement.

Based on the proposed enhancements in , this section defines how to reuse the existing IETF Yang model in the scenario of 5GS as a logical DetNet node. As described in RFC 8340 , topology Yang model allows the configuration of overlay networks on top of the underlay networks, through supporting network, supporting nodes, supporting links, etc. The 5GS could be treated as an underlay network and used as a logical node in the layer 3 DetNet system. [Editor's Notes]: This version just provides the basic idea of what attributes are requested. The formal yang model will be defined in the following version.

5GS as a logical DetNet node: Augment Composite-Node-Type and Direction in IETF YANG Model

5GS as a logical DetNet node: Composite-Node-ID in YANG Model Reuse the attribute of “node-id” defined in RFC 8340.

There are some complicated 5GS related DetNet scenarios that would be considered for future extensions.

DetNet YANG for the Binding Relationship As explained in the , a 5GS DetNet router champions the binding relationships that consist of DS-TT ports, user-plane tunnels between UEs and UPF, and NW-TT ports. The binding information is stored in the 5GS NF TSCTSF (see the ). Evidently, this ‘binding’ is not restricted to a standalone, fixed port or an individual UP tunnel. Instead, it indicates an integrated ‘association’ among multiple entities to provide the DetNet service as a whole. Accordingly, the corresponding definition of the YANG model in this scenario should not be independent for each entity, but be considered holistically. This is different from how the normal DetNet (topology) YANG model defines for a node, a port and a Link Termination Point .

DetNet YANG for Framed-route A 5GS (logical) DetNet node as specified in the Rel-18 can transport 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 that have been allocated to end devices which can be reached via their DS-TT ports. That is, as shown in the , those end devices are located in the DetNet system beyond DS-TT ports (toward the left). This advanced scenario is termed as ‘Framed Route’ in TS 23.501 . In field, this is a very useful deployment case in which enterprise-based customers, connected via 5GS DS-TT ports, could achieve deterministic network services provisioned by a 5GS (logical) DetNet node. As per 5GS standard, for DS-TT ports, the framed-route information, i.e., the additional IP addresses or IP prefixes, are not directly assigned to but reachable via the ports. The 5GS NF TSCTSF has to expose the information to and also coordinate with the IP-domain DetNet controller in order to correctly map flows beyond the UE. This is a unique scenario for YANG modelling since the YANG definitions in this situation have to embrace the entities that are not within the physical boundary of, but being controllable by, a (5GS) DetNet node.

5GS DetNet Extension for Future 3GPP Release As we have mentioned previously, the 3GPP Rel-18 has so far only realized the functionalities of the DetNet forwarding sub-layer, without supporting the DetNet service sub-layer functions. Along with the recent maturity and then the adoption of service-layer drafts in the IETF DetNet WG, 3GPP may pursue extensions in future release to align with the IETF DetNet work by standardizing the service-layer functions in a 5GS (logical) DetNet node. E.g., those proposals may apply either multi-UE devices or multi-UE multi-connection schemes with redundancy paths to achieve the PREOF.

Generally, this function will not incur additional security issues.

This document makes no request of IANA.