draft-ietf-dmm-5g-uplane-analysis-03.txt   draft-ietf-dmm-5g-uplane-analysis-04.txt 
DMM Working Group S. Homma DMM Working Group S. Homma
Internet-Draft NTT Internet-Draft NTT
Intended status: Informational T. Miyasaka Intended status: Informational T. Miyasaka
Expires: May 7, 2020 KDDI Research Expires: May 6, 2021 KDDI Research
S. Matsushima S. Matsushima
SoftBank SoftBank
D. Voyer D. Voyer
Bell Canada Bell Canada
November 4, 2019 November 2, 2020
User Plane Protocol and Architectural Analysis on 3GPP 5G System User Plane Protocol and Architectural Analysis on 3GPP 5G System
draft-ietf-dmm-5g-uplane-analysis-03 draft-ietf-dmm-5g-uplane-analysis-04
Abstract Abstract
This document analyzes the mobile user plane protocol and the This document analyzes the mobile user plane protocol and the
architecture specified in 3GPP 5G documents. The analysis work is to architecture specified in 3GPP 5G documents. The analysis work is to
clarify those specifications, extract protocol and architectural clarify those specifications, extract protocol and architectural
requirements and derive evaluation aspects for user plane protocols requirements and derive evaluation aspects for user plane protocols
on IETF side. This work is corresponding to the User Plane Protocol on IETF side. This work is corresponding to the User Plane Protocol
Study work on 3GPP side. Study work on 3GPP side.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 7, 2020. This Internet-Draft will expire on May 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Current Status of Mobile User Plane for 5G . . . . . . . 3 1.1. Current Status of Mobile User Plane for 5G . . . . . . . 3
1.2. Our Way of Analysis Work . . . . . . . . . . . . . . . . 4 1.2. Our Way of Analysis Work . . . . . . . . . . . . . . . . 4
2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4
3. GTP-U Specification and Observation . . . . . . . . . . . . . 6 3. GTP-U Specification and Observation . . . . . . . . . . . . . 6
3.1. GTP-U Tunnel . . . . . . . . . . . . . . . . . . . . . . 6 3.1. GTP-U Tunnel . . . . . . . . . . . . . . . . . . . . . . 6
3.2. GTP-U Header Format . . . . . . . . . . . . . . . . . . . 10 3.2. GTP-U Header Format . . . . . . . . . . . . . . . . . . . 9
3.3. Control Plane Protocol for GTP-U . . . . . . . . . . . . 12 3.3. Control Plane Protocol for GTP-U . . . . . . . . . . . . 12
3.4. GTP-U message . . . . . . . . . . . . . . . . . . . . . . 13 3.4. GTP-U message . . . . . . . . . . . . . . . . . . . . . . 13
3.5. Packet Format . . . . . . . . . . . . . . . . . . . . . . 14 3.5. Packet Format . . . . . . . . . . . . . . . . . . . . . . 14
3.6. Observations Summary . . . . . . . . . . . . . . . . . . 16 3.6. Observations Summary . . . . . . . . . . . . . . . . . . 16
4. 5GS Architectural Requirements for User Plane Protocols . . . 16 4. 5GS Architectural Requirements for User Plane Protocols . . . 16
4.1. Overview of 5G System Architecture . . . . . . . . . . . 16 4.1. Overview of 5G System Architecture . . . . . . . . . . . 16
4.1.1. UPF Functionalities . . . . . . . . . . . . . . . . . 18 4.1.1. UPF Functionalities . . . . . . . . . . . . . . . . . 18
4.1.2. UP Traffic Detection . . . . . . . . . . . . . . . . 19 4.1.2. UP Traffic Detection . . . . . . . . . . . . . . . . 19
4.1.3. User Plane Configuration . . . . . . . . . . . . . . 21 4.1.3. User Plane Configuration . . . . . . . . . . . . . . 21
4.2. Architectural Requirements for User Plane Protocols . 22 4.2. Architectural Requirements for User Plane Protocols . 22
5. Evaluation Aspects . . . . . . . . . . . . . . . . . . . . . 29 4.2.1. Fundamental Functionalities . . . . . . . . . . . . . 23
5.1. Supporting PDU Session Type Variations . . . . . . . . . 29 4.2.2. Supporting 5G Services . . . . . . . . . . . . . . . 26
5.2. Nature of Data Path . . . . . . . . . . . . . . . . . . . 30 5. Evaluation Aspects . . . . . . . . . . . . . . . . . . . . . 32
5.3. Supporting Transport Variations . . . . . . . . . . . . . 30 5.1. Supporting PDU Session Type Variations . . . . . . . . . 32
5.4. Data Path Management . . . . . . . . . . . . . . . . . . 31 5.2. Nature of Data Path . . . . . . . . . . . . . . . . . . . 33
5.5. QoS Control . . . . . . . . . . . . . . . . . . . . . . . 32 5.3. Supporting Transport Variations . . . . . . . . . . . . . 33
5.6. Traffic Detection and Flow Handling . . . . . . . . . . . 32 5.4. Data Path Management . . . . . . . . . . . . . . . . . . 34
5.7. Supporting Network Slicing Diversity . . . . . . . . . . 32 5.5. QoS Control . . . . . . . . . . . . . . . . . . . . . . . 35
5.8. Reliable Communication support . . . . . . . . . . . . . 33 5.6. Traffic Detection and Flow Handling . . . . . . . . . . . 35
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.7. Supporting Network Slicing Diversity . . . . . . . . . . 35
7. Security Consideration . . . . . . . . . . . . . . . . . . . 34 5.8. Reliable Communication support . . . . . . . . . . . . . 36
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 34 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 37
9. Informative References . . . . . . . . . . . . . . . . . . . 35 7. Security Consideration . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 37
9. Informative References . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
This document analyzes the mobile user plane protocol and the This document analyzes the mobile user plane protocol and the
architecture specified by 3GPP 5G documents. The background of the architecture specified by 3GPP 5G documents. The background of the
work is that 3GPP requests through a liaison statement that the IETF work is that 3GPP requests through a liaison statement that the IETF
to provide any information for the User Plane Protocol Study work in to provide any information for the User Plane Protocol Study work in
3GPP [CP-180116-3GPP]. Justification and the objectives of the study 3GPP [CP-180116-3GPP]. Justification and the objectives of the study
can be found from [CP-173160-3GPP]. can be found from [CP-173160-3GPP].
skipping to change at page 9, line 6 skipping to change at page 9, line 6
<=============== Traffic Direction ======================== <=============== Traffic Direction ========================
+-----+ N3 +------+ N9 +------+ N6 +-----+ N3 +------+ N9 +------+ N6
-----+ RAN +-----------+ UPF1 +------------+ UPF2 +---------- -----+ RAN +-----------+ UPF1 +------------+ UPF2 +----------
+-----+ +------+ +------+ +-----+ +------+ +------+
Figure 1: Protocol Stack by GTPv1-U for Uplink and Downlink Traffic Figure 1: Protocol Stack by GTPv1-U for Uplink and Downlink Traffic
Flow Flow
IPv6 flow label [RFC6437] is also candidate method for load balancing IPv6 flow label [RFC6437] is also candidate method for load balancing
especially for IP-in-IPv6 tunnel [RFC6438] like GTP-U. However, how especially for IP-in-IPv6 tunnel [RFC6438] like GTP-U. GTP-U also
to use IPv6 flow label of GTP-U is not described in [TS.29.281-3GPP]. supports dynamic allocation of IPv6 flow label for load balancing
Though this method is limited to a case of IPv6 encapsulated GTP-U objective. The specification of this dynamic allocation is described
tunnel, it is worth to study usage of IPv6 flow label in 3GPP. in section 4.4.2.0 of [TS.29.281-3GPP], however specific procedure,
e.g., 5-tuple hashing, is not described in the document and depends
on the implementation of GTP-U tunnel endpoint node.
[GTP-U-4]: GTP-U does not support IPv6 flow label for load balancing [GTP-U-4]: GTP-U supports load balancing by using dynamic IPv6 flow
in case of IPv6 transport. label allocation.
GTP-U supports both IPv4 and IPv6 as underlying transport layer GTP-U supports both IPv4 and IPv6 as the underlying network layer
protocol. As for IPv6, GTP-U specification refers [RFC2460], which protocol. From Release 16, GTP-U updates their reference to IPv6
is described in section 4.2.3 of [TS.29.281-3GPP]. As [RFC2460] does specification from [RFC2460] to [RFC8200] which allows UDP zero
not allow the tunnel protocols on top of UDP to set the checksum checksum for the protocols that use UDP as a tunnel encapsulation,
value to zero, the GTP-U specification inherits it while the IPv4 such as GTP-U. As a result of the update, GTP-U over IPv6 also
transport for GTP-U case allows UDP zero checksum. It is noted that supports the UDP zero checksum if the sender and receiver tunnel
the IPv6 specification in IETF has been updated to [RFC8200] which endpoint node support the UDP zero checksum, which is described in
allows UDP zero checksum for the tunnel. [RFC6935] describes section 4.4.2.0 of [TS.29.281-3GPP].
benefits of zero checksum for tunnel protocol over UDP. If GTP-U
support UFP zero checksum in future version, possible
interoperability issue between previous generations which does not
support zero checksum may raise.
[GTP-U-5]: UDP zero checksum is not available in case of IPv6 [GTP-U-5]: GTP-U supports UDP zero checksum.
transport.
"Unnecessary fragmentation should be avoided" is recommended and to "Unnecessary fragmentation should be avoided" is recommended and to
avoid the fragmentation operator should configure MTU size at UE avoid the fragmentation operator should configure MTU size at UE
[TS.29.281-3GPP]. However, there's no reference and specification of [TS.29.281-3GPP]. However, there's no reference and specification of
Path MTU Discovery for IPv6 transport. If encapsulated IPv6 packet Path MTU Discovery for IPv6 transport. If encapsulated IPv6 packet
is too big on a network link between tunnel endpoint nodes, UE may is too big on a network link between tunnel endpoint nodes, UE may
not receive ICMPv6 Packet Too Big message and causes Path MTU not receive ICMPv6 Packet Too Big message and causes Path MTU
Discovery black hole. Discovery black hole.
[GTP-U-6]: GTP-U does not support to response ICMP PTB for Path MTU [GTP-U-6]: GTP-U does not support to response ICMP PTB for Path MTU
skipping to change at page 15, line 14 skipping to change at page 15, line 10
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x1 |1|0|1|0|0| 0xff | Length | | 0x1 |1|0|1|0|0| 0xff | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TEID = 1654 | | TEID = 1654 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number = 0 |N-PDU Number=0 |NextExtHdr=0x85| | Sequence Number = 0 |N-PDU Number=0 |NextExtHdr=0x85|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GTP-U Extension Header (PDU Session Container) GTP-U Extension Header (PDU Session Container)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ExtHdrLen=2 |Type=0 | Spare |0|0| QFI | PPI | Spare | | ExtHdrLen=2 |Type=0 |0|0| |0|0| QFI | PPI | Spare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding |NextExtHdr=0x0 | | Padding |NextExtHdr=0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inner IPv6 Header Inner IPv6 Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| DSCP=0 | Flow Label | |Version| DSCP=0 | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | NexttHdr | Hop Limit | | Payload Length | NexttHdr | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 5 skipping to change at page 23, line 5
are referred to clarify the originations of architectural are referred to clarify the originations of architectural
requirements. requirements.
According to [TS.23.501-3GPP], the specifications potentially have According to [TS.23.501-3GPP], the specifications potentially have
assumptions that the UP protocol is a tunnel representing a single assumptions that the UP protocol is a tunnel representing a single
TEID between a pair of UPFs and it is corresponding to a single PDU TEID between a pair of UPFs and it is corresponding to a single PDU
session. In short, the UP protocol is a tunnel and it is assumed to session. In short, the UP protocol is a tunnel and it is assumed to
be managed under per PDU session handling. Also, it should be a be managed under per PDU session handling. Also, it should be a
stateful tunnel in the UPFs along with the PDU session. stateful tunnel in the UPFs along with the PDU session.
The requirements for UP protocols are described below: 4.2.1. Fundamental Functionalities
The fundamental requirements for UP protocols are described below:
ARCH-Req-1: Supporting IPv4, IPv6, Ethernet and Unstructured PDU ARCH-Req-1: Supporting IPv4, IPv6, Ethernet and Unstructured PDU
The 5G system defines four types of PDU session as IPv4, IPv6, The 5G system defines four types of PDU session as IPv4, IPv6,
Ethernet, and Unstructured. Therefore, UP protocol must support to Ethernet, and Unstructured. Therefore, UP protocol must support to
convey all of these PDU session types. This is described in convey all of these PDU session types. This is described in
[TS.23.501-3GPP]. [TS.23.501-3GPP].
Note: In TS 23.501 v15.2.0, IPv4v6 is added as a PDU session type. Note: In TS 23.501 v15.2.0, IPv4v6 is added as a PDU session type.
skipping to change at page 26, line 46 skipping to change at page 26, line 46
ARCH-Req-8: End Marker support ARCH-Req-8: End Marker support
The construction of End Marker packets specified in [TS.23.501-3GPP] The construction of End Marker packets specified in [TS.23.501-3GPP]
may either be done in the CP/UP functions for indicating the end of may either be done in the CP/UP functions for indicating the end of
the payload stream on a given UP tunnel. PDU packets arrive after an the payload stream on a given UP tunnel. PDU packets arrive after an
End Marker message on the tunnel may be silently discarded. For End Marker message on the tunnel may be silently discarded. For
example, End Maker is used for handover procedures, and it can example, End Maker is used for handover procedures, and it can
prevent reordering of arriving packets due to switch of anchor UPFs. prevent reordering of arriving packets due to switch of anchor UPFs.
ARCHI-Req-9: Supporting Redundant UP transmission for URLLC 4.2.2. Supporting 5G Services
In the release 16 [TS.23.501-3GPP], some specifications have been
added to support 5G specific services and communications. This
section describes overviews of the specifications relevant to use
plane functionalities.
ARCHI-Req-9: URLLC Support
The 5GS supports Ultra-Reliable Low Latency Communication (URLLC) for
mission critical applications. The User Plane features are described
below.
o Redundant UP transmission for URLLC
The 5G is expected to support services which are latency sensitive The 5G is expected to support services which are latency sensitive
and require high reliability. Communication to realize such services and require high reliability. Communication to realize such services
is called Ultra-Reliable and Low-Latency Communication or URLLC. In is called Ultra-Reliable and Low-Latency Communication or URLLC. In
URLLC, redundancy of QoS flows is required for providing highly URLLC, redundancy of QoS flows is required for providing highly
reliable communication. For instance, a set of UP NFs (e.g., UPF or reliable communication. For instance, a set of UP NFs (e.g., UPF or
gNB) and interfaces between UE and DN are redundant, and packets are gNB) and interfaces between UE and DN are redundant, and packets are
replicated and forwarded via each route. UEs and DN support dual replicated and forwarded via each route. UEs and DN support dual
connectivity and drop duplicated received packets. The scheme of connectivity and drop duplicated received packets. The scheme of
packet dropping at UE is out of responsibility of 3GPP. The overview packet dropping at UE is out of responsibility of 3GPP. The overview
skipping to change at page 28, line 48 skipping to change at page 29, line 23
/ N3 Tunnel1 +-+-+---+ N9 Tunnel1 | / N3 Tunnel1 +-+-+---+ N9 Tunnel1 |
/ +-----+I-UPF1 +----+ | / +-----+I-UPF1 +----+ |
+----+ +--+--+______| +-------+ |______+--+--+ N6 +----+ +----+ +--+--+______| +-------+ |______+--+--+ N6 +----+
| UE +---+ RAN |______ | ______| UPF +-----+ DN | | UE +---+ RAN |______ | ______| UPF +-----+ DN |
+----+ +-----+ N3 | +---+---+ | N9 +-----+ +----+ +----+ +-----+ N3 | +---+---+ | N9 +-----+ +----+
+-----+I-UPF2 +----+ +-----+I-UPF2 +----+
N3 Tunnel2 +-------+ N9 Tunnel2 N3 Tunnel2 +-------+ N9 Tunnel2
Figure 9: Redundant UP transmission with two I-UPF and N3/N9 tunnels Figure 9: Redundant UP transmission with two I-UPF and N3/N9 tunnels
ARCHI-Req-10: Supporting QoS Monitoring for URLLC o Supporting QoS Monitoring for URLLC
QoS monitoring is also required for URLLC. It means that the user QoS monitoring is also required for URLLC. It means that the user
plane should be able to measure packet delay between anchor UPF and plane should be able to measure packet delay between anchor UPF and
UE. The measurement would be in various granularities, in the basis UE. The measurement would be in various granularities, in the basis
of per QoS Flow per UE, or per UP path for example. of per QoS Flow per UE, or per UP path for example.
To help the measurement at anchor UPF and RAN, UP protocol requires To help the measurement at anchor UPF and RAN, UP protocol requires
to have capability to convey necessary information to do that; such to have capability to convey necessary information to do that; such
as time information at sending or reception of a measurement packet. as time information at sending or reception of a measurement packet.
That information should exist in per F-TEID and QFI basis which That information should exist in per F-TEID and QFI basis which
indicates QoS Flow of the packet. UP protocol should also be able to indicates QoS Flow of the packet. UP protocol should also be able to
indicate which packets include the corresponding information for each indicate which packets include the corresponding information for each
measurement. measurement.
The QoS monitoring requirement has been appeared in section 5.33.3 of The QoS monitoring requirement has been appeared in section 5.33.3 of
[TS.23.501-3GPP] from Rel-16, version 16.2.0. [TS.23.501-3GPP] from Rel-16, version 16.2.0.
ARCHI-Req-10: Time Sensitive Communication Support
The 5GS supports Time Sensitive Communications (TSC) for realtime
applications, and it can be integrated transparently as a bridge in
an IEEE 802.1 TSN network. For TSN time synchronization, the E2E 5GS
can be considered as a "time-aware system (ref [IEEE-Std-802.1AS])".
The TSN Translators (TTs) at the edges of the 5GS need to support the
[IEEE-Std-802.1AS] operations. For instance, UE, gNB, NW-TT
(Network-side TSN Translator) and DS-TTs (Device-side TSN
Translators) are synchronized with the Grandmaster (GM) located in
the 5GS. In addition, the TTs fulfill some functions related to
[IEEE-Std-802.1AS] (e.g., gPTP support, timestamping, rateRatio,
etc.). An overview of the 5G and TSN GM clock distribution model via
the 5GS is shown in Figure 10.
<-TSN-D-> <---- 5G Time Domain ----> <-TSN-D->
+-----+ +------+
|5G GM| |TSN GM|
+-----+ +------+
|M |M
| +---+-----+ VS
+----+ VS ,--------. | |NW-TT| ,-----.
|End | +-----+ +--+ Uu +---+ / PTP \ | +-----+ / TSN \
|Sta.|<==|DS-TT|<-|UE|<----|gNB|--|Compatible|-->|UPF |<==|Working|
+----+S M+-----+ +--+S M+---+M \ 5G TN / S+---------+S M\ Domain/
`--------' `-----'
Legend
TSN-D : Non-3GPP TSN Domain
TN : Transport Network
End Sta.: End Station
<-- : 5GS timing direction
<== : TSN timing direction
M : Master
S : Slave
Figure 10: An overview of the 5G and TSN GM clock distribution model
In this model, two independent synchronizations are processing, and
gNB only needs to be synchronized to the 5G GM clock. To enable TSN
domain synchronization, the 5GS calculates and adds the measured
residence time between the DS-TT and NW-TT into the Correction Field
(CF) of the synchronization packet of the TSN working domain. The
details are described in section 5.27 in [TS.23.501-3GPP].
From this feature, UP functions and protocol are needed to support
TSN specified in [IEEE-Std-802.1AS] .
ARCHI-Req-11: Cellular IoT Support
For supporting Cellular IoT (CIoT) (ref. [TS.22.261-3GPP]),
optimizations of functionalities of the 5GS is needed. CIoT is in
earlier 3GPP release also referred to as Machine Type Communication
(MTC). Some of CIoT functionalities relevant to user plane are
described in this section. The details of CIoT support is described
in section 5.31 in [TS.23.501-3GPP].
o Non-IP Data Delivery (NIDD)
The 5GS may support Non-IP Data Delivery (NIDD) to handle Mobile
Originated (MO) and Mobile Terminated (MT) communication for
unstructured data. Thus, User Plane Protocol should be conveyable
such unstructured data units.
o Reliable Data Service (RDS)
Reliable Data Service (RDS) may be used for a PDU session of
unstructured type. The service provides a mechanism for the NEF or
UPF to determine if the data was successfully delivered to the UE and
for the UE to determine if the data was successfully delivered to the
NEF or UPF.
When the service is enabled, a protocol that uses a packet header to
identify the requested acknowledgement from peered end-point may be
used between end-points of the PDU session. In addition, port
numbers in the header are used to identify the applications on the
originator and receiver. The UE, NEF and the UPF may support
reservation of the source and destination port numbers for their use
and subsequent release of the reserved port numbers.
Therefore, UP protocol is required to have fields for containing
information to determine normality of unstructured PDU sessions and
used applications.
o High Latency Communication
Functions for High Latency Communication may be used to handle mobile
terminated (MT) communication with UEs being unreachable while using
power saving functions. "High latency" refers to the initial
response time before normal exchange of packets is established. High
latency communication is supported by extended buffering of downlink
data in the UPF, SMF or NEF when a UE is using power saving functions
in CM-IDL state and the UE is not reachable.
o Small Data Rate Control
The SMF may apply Small Data Rate Control for PDU sessions based on,
for example, operator policy, DNN, S-NSSAI, RAT type etc. The rate
control may indicate following parameters in each of uplink and
downlink.
- an integer number of packets per time unit
- an integer number of additional allowed exception report packets
per time unit once the rate control limit has been reached
The UE shall comply with this uplink rate control instruction. If
the UE exceeds the uplink number of packet per time, the UE may still
send uplink exception report if allowed and the number exception
reports per time unit has not been exceeded.
For the UPF and NEF, Small Data Rate Control is based on a maximum
allowed rate per direction. The UPF or NEF may enforce the uplink
rate by discarding or delaying packets that exceed the maximum
allowed rate. The UPF or NEF shall enforce the downlink rate by
discarding or delaying packets that exceed the downlink part of the
maximum allowed rate.
o User Plane CIoT 5GS Optimisation
User Plane CIoT 5GS Optimization enables transfer of user plane data
from CM-IDLE without the need for using the Service Request procedure
by negotiation between UE and AMF in advance. In case that there are
many devices being CM-IDLE state for long time, it would be better
that User Plane Protocol i s session less.
5. Evaluation Aspects 5. Evaluation Aspects
This section provides UP protocol evaluation aspects that are mainly This section provides UP protocol evaluation aspects that are mainly
we derived from the architectural requirements described in we derived from the architectural requirements described in
Section 4. Those aspects are not prioritized by the order here. Section 4. Those aspects are not prioritized by the order here.
Expected deployment scenarios explain the evaluations purpose in the Expected deployment scenarios explain the evaluations purpose in the
corresponding aspects. corresponding aspects.
As we were noticed that the gaps between GTP-U specifications and 5G As we were noticed that the gaps between GTP-U specifications and 5G
architectural requirements through the analysis, those each gap are architectural requirements through the analysis, those each gap are
skipping to change at page 35, line 27 skipping to change at page 38, line 27
Docs/CP-173160.zip>. Docs/CP-173160.zip>.
[CP-180116-3GPP] [CP-180116-3GPP]
3rd Generation Partnership Project (3GPP), "LS on user 3rd Generation Partnership Project (3GPP), "LS on user
plane protocol study", March 2018, plane protocol study", March 2018,
<http://www.3gpp.org/ftp/tsg_ct/TSG_CT/TSGC_79_Chennai/ <http://www.3gpp.org/ftp/tsg_ct/TSG_CT/TSGC_79_Chennai/
Docs/CP-180116.zip>. Docs/CP-180116.zip>.
[IAB-Statement] [IAB-Statement]
Internet Architecture Board (IAB), "IAB Statement on Internet Architecture Board (IAB), "IAB Statement on
IPv6", November 2016, <https://www.iab.org/2016/11/07/iab- IPv6", November 2016,
statement-on-ipv6/>. <https://www.iab.org/2016/11/07/iab-statement-on-ipv6/>.
[IEEE-Std-802.1AS]
Institute of Electrical and Electronics Engineers (IEEE),
"Timing and Synchronization for Time-Sensitive
Applications in Bridged Local Area Networks", March 2011,
<https://www.ieee802.org/1/pages/802.1as.html>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
2 Virtual Private Networks (L2VPNs)", RFC 4664, 2 Virtual Private Networks (L2VPNs)", RFC 4664,
DOI 10.17487/RFC4664, September 2006, <https://www.rfc- DOI 10.17487/RFC4664, September 2006,
editor.org/info/rfc4664>. <https://www.rfc-editor.org/info/rfc4664>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, <https://www.rfc- DOI 10.17487/RFC4861, September 2007,
editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437, "IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011, <https://www.rfc- DOI 10.17487/RFC6437, November 2011,
editor.org/info/rfc6437>. <https://www.rfc-editor.org/info/rfc6437>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>. <https://www.rfc-editor.org/info/rfc6438>.
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", RFC 6935, UDP Checksums for Tunneled Packets", RFC 6935,
DOI 10.17487/RFC6935, April 2013, <https://www.rfc- DOI 10.17487/RFC6935, April 2013,
editor.org/info/rfc6935>. <https://www.rfc-editor.org/info/rfc6935>.
[RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T.,
and D. Wing, "IPv6 Multihoming without Network Address and D. Wing, "IPv6 Multihoming without Network Address
Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014,
<https://www.rfc-editor.org/info/rfc7157>. <https://www.rfc-editor.org/info/rfc7157>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, <https://www.rfc- DOI 10.17487/RFC8200, July 2017,
editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[TR.29.891-3GPP] [TR.29.891-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TR 29.891 3rd Generation Partnership Project (3GPP), "3GPP TR 29.891
(V15.0.0): 5G System Phase 1, CT WG4 Aspects", December (V15.0.0): 5G System Phase 1, CT WG4 Aspects", December
2017, <http://www.3gpp.org/FTP/Specs/2017-12/ 2017, <http://www.3gpp.org/FTP/Specs/2017-12/Rel-
Rel-15/29_series/29891-f00.zip>. 15/29_series/29891-f00.zip>.
[TS.22.261-3GPP] [TS.22.261-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 22.261 3rd Generation Partnership Project (3GPP), "3GPP TS 22.261
(V15.7.0): Service requirements for 5G system stage 1", (V15.7.0): Service requirements for 5G system stage 1",
December 2018, <http://www.3gpp.org/FTP/Specs/2018-03/ December 2018, <http://www.3gpp.org/FTP/Specs/2018-03/Rel-
Rel-15/22_series/22261-f70.zip>. 15/22_series/22261-f70.zip>.
[TS.23.060-3GPP] [TS.23.060-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 23.060 3rd Generation Partnership Project (3GPP), "3GPP TS 23.060
(V15.3.0): General Packet Radio Service (GPRS); Service (V15.3.0): General Packet Radio Service (GPRS); Service
description; Stage 2", June 2018, description; Stage 2", June 2018,
<http://www.3gpp.org/ftp//Specs/ <http://www.3gpp.org/ftp//Specs/
archive/23_series/23.060/23060-f30.zip>. archive/23_series/23.060/23060-f30.zip>.
[TS.23.501-3GPP] [TS.23.501-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 23.501 3rd Generation Partnership Project (3GPP), "3GPP TS 23.501
(V16.2.0): System Architecture for 5G System; Stage 2", (V16.2.0): System Architecture for 5G System; Stage 2",
September 2019, <http://www.3gpp.org/ftp//Specs/ September 2019, <http://www.3gpp.org/ftp//Specs/
archive/23_series/23.501/23501-g20.zip>. archive/23_series/23.501/23501-g20.zip>.
[TS.23.502-3GPP] [TS.23.502-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 23.502 3rd Generation Partnership Project (3GPP), "3GPP TS 23.502
(V15.4.0): Procedures for 5G System; Stage 2", December (V15.4.0): Procedures for 5G System; Stage 2", December
2018, <http://www.3gpp.org/FTP/Specs/2018-03/ 2018, <http://www.3gpp.org/FTP/Specs/2018-03/Rel-
Rel-15/23_series/23502-f40.zip>. 15/23_series/23502-f40.zip>.
[TS.23.503-3GPP] [TS.23.503-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 23.503 3rd Generation Partnership Project (3GPP), "3GPP TS 23.503
(V15.4.0): Policy and Charging Control System for 5G (V15.4.0): Policy and Charging Control System for 5G
Framework; Stage 2", December 2018, Framework; Stage 2", December 2018,
<http://www.3gpp.org/FTP/Specs/2018-03/ <http://www.3gpp.org/FTP/Specs/2018-03/Rel-
Rel-15/23_series/23503-f40.zip>. 15/23_series/23503-f40.zip>.
[TS.28.530-3GPP] [TS.28.530-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 28.530 3rd Generation Partnership Project (3GPP), "3GPP TS 28.530
(V15.1.0): Management and orchestration of networks and (V15.1.0): Management and orchestration of networks and
network slicing; Concepts, use cases and requirements network slicing; Concepts, use cases and requirements
(work in progress)", December 2018, (work in progress)", December 2018,
<http://ftp.3gpp.org//Specs/ <http://ftp.3gpp.org//Specs/
archive/28_series/28.530/28530-f10.zip>. archive/28_series/28.530/28530-f10.zip>.
[TS.28.531-3GPP] [TS.28.531-3GPP]
skipping to change at page 38, line 17 skipping to change at page 41, line 17
(V15.1.0): Management and orchestration of networks and (V15.1.0): Management and orchestration of networks and
network slicing; Management and orchestration architecture network slicing; Management and orchestration architecture
(Release 15)", December 2018, (Release 15)", December 2018,
<http://www.3gpp.org/ftp//Specs/ <http://www.3gpp.org/ftp//Specs/
archive/28_series/28.533/28533-f10.zip>. archive/28_series/28.533/28533-f10.zip>.
[TS.29.244-3GPP] [TS.29.244-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 29.244 3rd Generation Partnership Project (3GPP), "3GPP TS 29.244
(V15.1.0): Interface between the Control Plane and the (V15.1.0): Interface between the Control Plane and the
User Plane Nodes; Stage 3", December 2018, User Plane Nodes; Stage 3", December 2018,
<http://www.3gpp.org/FTP/Specs/2018-03/ <http://www.3gpp.org/FTP/Specs/2018-03/Rel-
Rel-15/29_series/29244-f40.zip>. 15/29_series/29244-f40.zip>.
[TS.29.274-3GPP] [TS.29.274-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 29.274 3rd Generation Partnership Project (3GPP), "3GPP TS 29.274
(V15.4.0): 3GPP Evolved Packet System (EPS); Evolved (V15.4.0): 3GPP Evolved Packet System (EPS); Evolved
General Packet Radio Service (GPRS) Tunneling Protocol for General Packet Radio Service (GPRS) Tunneling Protocol for
Control plane (GTPv2-C); Stage 3", June 2018, Control plane (GTPv2-C); Stage 3", June 2018,
<http://www.3gpp.org/ftp//Specs/ <http://www.3gpp.org/ftp//Specs/
archive/29_series/29.274/29274-f40.zip>. archive/29_series/29.274/29274-f40.zip>.
[TS.29.281-3GPP] [TS.29.281-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 29.281 3rd Generation Partnership Project (3GPP), "3GPP TS 29.281
(V15.5.0): GPRS Tunneling Protocol User Plane (GTPv1-U)", (V16.1.0): GPRS Tunneling Protocol User Plane (GTPv1-U)",
December 2018, <http://www.3gpp.org/ftp//Specs/ September 2020, <https://www.3gpp.org/ftp//Specs/
archive/29_series/29.281/29281-f50.zip>. archive/29_series/29.281/29281-g10.zip>.
[TS.29.510-3GPP] [TS.29.510-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 29.510 3rd Generation Partnership Project (3GPP), "3GPP TS 29.510
(V15.2.0): 5G System; Network Function Repository (V15.2.0): 5G System; Network Function Repository
Services; Stage 3", December 2018, Services; Stage 3", December 2018,
<http://www.3gpp.org/FTP/Specs/2018-06/ <http://www.3gpp.org/FTP/Specs/2018-06/Rel-
Rel-15/29_series/29510-f20.zip>. 15/29_series/29510-f20.zip>.
[TS.29.561-3GPP] [TS.29.561-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 29.561 3rd Generation Partnership Project (3GPP), "3GPP TS 29.561
(V15.1.0): 5G System; Interworking between 5G Network and (V15.1.0): 5G System; Interworking between 5G Network and
external Data Networks; Stage 3", September 2018, external Data Networks; Stage 3", September 2018,
<http://www.3gpp.org/FTP/Specs/2018-06/ <http://www.3gpp.org/FTP/Specs/2018-06/Rel-
Rel-15/29_series/29561-f10.zip>. 15/29_series/29561-f10.zip>.
[TS.38.300-3GPP] [TS.38.300-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 38.300 3rd Generation Partnership Project (3GPP), "3GPP TS 38.300
(v15.4.0): NR and NG-RAN Overall Description; Stage 2", (v15.4.0): NR and NG-RAN Overall Description; Stage 2",
December 2018, <http://www.3gpp.org/FTP/Specs/2018-03/ December 2018, <http://www.3gpp.org/FTP/Specs/2018-03/Rel-
Rel-15/38_series/38300-f40.zip>. 15/38_series/38300-f40.zip>.
[TS.38.401-3GPP] [TS.38.401-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 38.401 3rd Generation Partnership Project (3GPP), "3GPP TS 38.401
(v15.4.0): NG-RAN; Architecture Description", December (v15.4.0): NG-RAN; Architecture Description", December
2018, <http://www.3gpp.org/FTP/Specs/2018-03/ 2018, <http://www.3gpp.org/FTP/Specs/2018-03/Rel-
Rel-15/38_series/38401-f40.zip>. 15/38_series/38401-f40.zip>.
[TS.38.415-3GPP] [TS.38.415-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 38.415 3rd Generation Partnership Project (3GPP), "3GPP TS 38.415
(v15.2.0): NG-RAN; PDU Session User Plane protocol", (v16.2.0): NG-RAN; PDU Session User Plane protocol",
December 2018, <http://www.3gpp.org/ftp//Specs/ October 2020, <https://www.3gpp.org/ftp//Specs/
archive/38_series/38.415/38415-f20.zip>. archive/38_series/38.415/38415-g20.zip>.
Authors' Addresses Authors' Addresses
Shunsuke Homma Shunsuke Homma
NTT NTT
Email: homma.shunsuke@lab.ntt.co.jp Email: homma.shunsuke@lab.ntt.co.jp
Takuya Miyasaka Takuya Miyasaka
KDDI Research KDDI Research
 End of changes. 35 change blocks. 
82 lines changed or deleted 228 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/