Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TR 23.700-46  Word version:  18.0.0

Top   Top   None   None   Next
1…   5…   6…   7… 
1 Scope  2 References  3 Definitions of terms and abbreviations  3.1 Terms  3.2 Abbreviations  4 Architecture Assumptions 
...

 

1  Scope  p. 7

The objective of this Technical Report is to study whether and how to enable 3GPP support for DetNet such that a mapping is provided between the central DetNet controller entity (as defined in IETF) and the 5G system. Mapping involves translation of DetNet traffic profile and flow specification to 5GS QoS parameters and TSCAI. The study also considers which information needs to be exposed from the 5G system to the DetNet controller.
The study scope assumes the following:
  • Only IP based DetNet is in the scope of the work; MPLS based DetNet is out of scope.
  • DetNet over Ethernet TSN is not in the scope of the work as it can be supported based on existing 3GPP and IETF standards.
  • It is out of scope to support for edge DetNet node functions in the 3GPP network.
Up

2  References  p. 7

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
RFC 8655:  "Deterministic Networking Architecture".
[3]
RFC 8939:  "Deterministic Networking (DetNet) Data Plane: IP".
[4]
RFC 9016:  "Flow and Service Information Model for Deterministic Networking (DetNet)".
[5]
draft-ietf-detnet-yang-17  "Deterministic Networking (DetNet) YANG Model".
[6]
RFC 8344:  "A YANG Data Model for IP Management".
[7]
RFC 8343:  "A YANG Data Model for Interface Management".
[8]
RFC 6241:  "Network Configuration Protocol (NETCONF) ".
[9]
RFC 8040:  "RESTCONF Protocol".
[10]
RFC 6021:  "Common YANG Data Types".
[11]
RFC 8349:  "A YANG Data Model for Routing Management (NMDA Version)".
[12]
TS 23.501: "System architecture for the 5G System (5GS); Stage 2".
[13]
TS 23.502: "Procedures for the 5G System; Stage 2".
[14]
TS 23.503: "Policy and charging control framework for the 5G System (5GS); Stage 2".
[15]
TS 29.514: "5G System; Policy Authorization Service; Stage 3".
Up

3  Definitions of terms and abbreviations  p. 8

3.1  Terms  p. 8

For the purposes of the present document, the terms given in TR 21.905 apply.

3.2  Abbreviations  p. 8

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
DetNet
Deterministic Networking

4  Architecture Assumptions  p. 8

The study has the following architecture assumptions:
  • DetNet may be used in combination with time synchronization mechanisms as defined in Rel-17 but does not require usage of these mechanisms.
  • Since synchronization mechanisms that can be used are out of the scope in IETF DetNet specifications, the time synchronization framework in Release 17 is not modified for this study.
  • Existing 3GPP routing mechanisms can be re-used for DetNet; no new routing function in the 3GPP system is to be defined.
  • The existing filtering mechanisms can be re-used in the UE and in the UPF to identify the traffic for QoS differentiation.
  • It is out of scope to extend 3GPP multicast mechanisms, but the existing multicast capabilities can be re-used for DetNet communications.
  • IP based DetNet traffic is carried in PDU Sessions of IP type.
  • The mapping functionality for DetNet is realized in the TSCTSF.
  • The solutions should reuse the functionality of the TSC framework defined in Release 17 where applicable.
  • The study considers 5GS acting as a DetNet node in the DetNet domain. Use cases where the 5GS acts as a sub-network (see Section 4.1.2 of RFC 8655) are also possible but do not require additional 3GPP standardization. A special case where the 5GS can act as a sub-network is when the 5GS acts as a TSN network, which is already supported based on 3GPP Release 16-17.
  • The study considers the DetNet forwarding sub-layer related functions that are applicable to the 5GS. For the IP case according to Section 1 of RFC 8939, no service sub-layer function needs to be defined.
  • The granularity of the 5GS DetNet node is per UPF for each network instance.
  • The solutions shall not have any 5G AN and UE impacts
The 5G System is extended to support the following:
  • The UE is part of the 5GS logical DetNet Node, thus is not a DetNet Node or End System on its own
The reference architecture is shown as below:
Up

Up   Top   ToC