5.28.5.3 DetNet node configuration mapping in 5GS

The TSCTSF maps the parameters in the DetNet YANG configuration to 5GS parameters as defined in clause 6.1.3.23b of TS 23.503 [45].

The TSCTSF determines the UE address to bind the DetNet configuration as follows:

• When available, the TSCTSF uses the identity of the incoming and outgoing interface to determine the affected UE address and whether the flow is uplink or downlink or UE-to-UE.
• If there is no incoming interface for UL traffic, the TSCTSF may determine the UE address based on the source IP address of the UL traffic in the DetNet configuration, or using local configuration to map the DetNet flow information to the UE address. If there is no incoming interface for traffic with an outgoing interface on the device side, the TSCTSF may determine whether the flow is UE-to-UE based on the source IP address of the traffic in the DetNet configuration, or using local configuration.

NOTE 1: The incoming interface is optional in the DetNet YANG configuration. It is assumed that any IP prefix on the device side is reachable via, at most, a single device side interface. Thus if the flow source IP address is available and belongs to a prefix associated with a device side interface, that interface can be uniquely determined as the incoming interface for the flow.

NOTE 2: If there is no incoming interface for the UL traffic or no incoming interface for traffic with outgoing interface on the device side, the details on how the TSCTSF uses local configuration are not specified.

• When the information on IP addresses or IP prefixes not directly assigned to the port but reachable via the port is available as described in clause 5.28.5.2, the TSCTSF also takes such info into account.
• If the flow is UE-to-UE, two PDU Sessions will be affected for the flow and the TSCTSF breaks up the requirements to individual requirements for the PDU Sessions.

The TSCTSF provides a response to the DetNet controller regarding the success of the configuration setup. When both the TSCTSF and the DetNet controller support 3GPP extensions to the IETF RFC 9633 [154], the TSCTSF may provide 5GS specific status code information on the result of the configuration to the DetNet controller.

NOTE 3: The 3GPP extension to the IETF RFC 9633 [154] is defined in 3GPP as a YANG model which imports IETF RFC 9633 [154] and adds the 3GPP specific parameters. The 3GPP defined YANG model uses the 3GPP namespace as defined in IETF RFC 5279 [158].

If the status of the flow changes later on for any reason, the TSCTSF notifies the DetNet controller. Upon release of a PDU Session that is part of the existing DetNet configuration, the PCF notifies the TSCTSF of the PDU Session release and TSCTSF notifies the DetNet controller on the status of the flow.

The 5GS routing is not modified by the configuration received from the DetNet controller. Still the TSCTSF may verify whether the explicit routing information provided by the DetNet controller is in line with the 5GS mapping of IP addresses and prefixes to PDU sessions. The verification may be based on whether the source or destination IP address in the DetNet flow on the given port corresponds to the IP address or prefix associated with the given PDU Session. Based on operator configuration, the TSCTSF may use other criteria (not routing related) to determine whether to accept or reject a given DetNet configuration.

5GS DetNet Node can forward via its device side interface 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 according to one or more Framed Routes or prefixes delegated to the UE by IPv6 prefix delegation. To facilitate this, the additional IP addresses used for framed routes and IPv6 prefix delegation are exposed by the SMF to the TSCTSF via the PCF and the TSCTSF may expose them to the DetNet controller, as defined in clause 5.28.5.2.