DMM Working Group S. Homma Internet-Draft NTT Intended status: Informational T. Miyasaka Expires: December 31, 2018 KDDI Research S. Matsushima SoftBank D. Voyer Bell Canada June 29, 2018 User Plane Protocol and Architectural Analysis on 3GPP 5G System draft-hmm-dmm-5g-uplane-analysis-00 Abstract This document analyzes the mobile user plane protocol and the architecture specified in 3GPP 5G documents. The analysis work is to clarify those specifications, extract protocol and architectural requirements and derive evaluation aspects for user plane protocols on IETF side. This work is corresponding to the User Plane Protocol Study work on 3GPP side. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 31, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of Homma, et al. Expires December 31, 2018 [Page 1] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Current Status of Mobile User Plane for 5G . . . . . . . 3 1.2. Our Way of Analysis Work . . . . . . . . . . . . . . . . 3 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 3. GTP-U Specification and Observation . . . . . . . . . . . . . 5 3.1. GTP-U Tunnel . . . . . . . . . . . . . . . . . . . . . . 6 3.2. GTP-U Header Format . . . . . . . . . . . . . . . . . . . 9 3.3. Control Plane Protocol for GTP-U . . . . . . . . . . . . 12 3.4. GTP-U message . . . . . . . . . . . . . . . . . . . . . . 12 3.5. Packet Format . . . . . . . . . . . . . . . . . . . . . . 13 3.6. Observations Summary . . . . . . . . . . . . . . . . . . 15 4. 5GS Architectural Requirements for User Plane Protocols . . . 15 4.1. Overview of 5G System Architecture . . . . . . . . . . . 15 4.1.1. UPF Functionalities . . . . . . . . . . . . . . . . . 17 4.2. Architectural Requirements for User Plane Protocols . . . 18 5. Evaluation Aspects . . . . . . . . . . . . . . . . . . . . . 20 5.1. Supporting PDU Session Type Variations . . . . . . . . . 21 5.2. Nature of Data Path . . . . . . . . . . . . . . . . . . . 21 5.3. Supporting Transport Variations . . . . . . . . . . . . . 21 5.4. Data Path Management . . . . . . . . . . . . . . . . . . 22 5.5. QoS Control . . . . . . . . . . . . . . . . . . . . . . . 23 5.6. Traffic Detection and Flow Handling . . . . . . . . . . . 23 5.7. Supporting Network Slicing Diversity . . . . . . . . . . 23 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Security Consideration . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 25 9. Informative References . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction This document analyzes the mobile user plane protocol and the architecture specified by 3GPP 5G documents. The background of the work is that 3GPP requests through a liaison statement that the IETF to provide any information for the User Plane Protocol Study work in 3GPP [CP-180116-3GPP]. Justification and the objectives of the study can be found from [CP-173160-3GPP]. Homma, et al. Expires December 31, 2018 [Page 2] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 We understand that the current user plane protocol, GTP-U [TS.29.281-3GPP], has been well developed in 3GPP, and deployed very widely as the successor of legacy network technologies, such as TDM circuit, or ATM virtual circuit. That GTP-U success seems based on IP overlay technique that is dramatically scaled compare to the previous ones because it successfully isolates mobile session states from the user plane transport network. Even after that big success, it is definitely worth that 3GPP has decided to revisit user plane which seems to response to IPv6 deployment growth and [IAB-Statement] that encourages the industry to develop strategies for IPv6-only operation. It can be seen from the justification section in [CP-173160-3GPP]. The study description mentions that the study would be based on Release 16 requirement while only Release 15 specifications has been available now. However we believe that to provide adequate information for 3GPP, we need to clearly understand what the current user plane protocol is in Release 15, and architectural requirements for the user plane. As the liaison statement indicates 3GPP specifications related to user plane, those documents should be a good start point to clarify their specifications and to extract protocol and architectural requirements from them. 1.1. Current Status of Mobile User Plane for 5G 3GPP RAN and CT4 decided to use GTP-U as the 5G user plane encapsulation protocol over N3 and N9 that respectively described in[TS.38.300-3GPP] and [TR.29.891-3GPP]. N3 is an interface between RAN and UPF and N9 is an interface between different UPFs [TS.23.501-3GPP]. In [TR.29.891-3GPP], it captured user plane requirements and concluded that GTP-U is adopted for the user plane protocol. It seems that GTP-U was only option to be chose and it focused on how to carry 5G specific QoS information between UPF and access networks. That is described in section 5.2 and 11.2 of [TR.29.891-3GPP]. Another aspects of user plane requirements couldn't be found. 1.2. Our Way of Analysis Work First, we analyze [TS.29.281-3GPP] for clarifying it as the current user plane protocol in the 5G system. [TR.29.891-3GPP] describes how GTP-U is selected as the user plane protocol for 5G in 3GPP. Clarified characteristics of the protocol are described in Section 3. Homma, et al. Expires December 31, 2018 [Page 3] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 Then, to clarify what are required to the user plane protocol in architecture level, we analyze [TS.23.501-3GPP] as the 5G system architecture specification. [TS.23.502-3GPP] is the specification of system procedures that helps us to understand how the system works in the architecture. [TS.23.503-3GPP] is also helpful to find the role of user plane in the architecture that influences user plane protocol. Extracted architectural requirements are described in Section 4. Based on the results of above, we identify some aspects where there might be gap between the current user plane protocol and the architectural requirements on which [TR.29.891-3GPP] does not discuss. That aspects are discussed Section 5. That's what we intend to be as a part of the reply to 3GPP. CT4 WG in 3GPP can utilize it as an input to evaluate the candidate protocols for user plane to the 5G system including the current protocol. [I-D.bogineni-dmm-optimized-mobile-user-plane] will provide the candidate protocols on IETF side to the 3GPP study. 2. Terms and Abbreviations This section describes terms of functions and interfaces relevant to user plane protocol which we extract from the 3GPP specifications since this document focuses on user plane. In those specifications, there are so many unique terms and abbreviations in the 3GPP context which IETF community seems not familiar with. We will try to bring those terms with brief explanations to make sure common understanding for them. GTP: GPRS Tunneling Protocol GTP-U User Plane part of GTP Noted that GTP version 1 (GTPv1-U) is the user-plane protocol specification which is defined in [TS.29.281-3GPP]. Unless there is no specific annotation, we refer GTP-U to GTPv1-U in this document. PDU: Protocol Data Unit of end-to-end user protocol packet. Noted that the PDU in 3GPP includes IP header in case that PDU session type is IPv4 or IPv6. In contrast, in IETF it is supposed that PDU is the payload of IP packet so that it doesn't include IP/TCP/UDP header in end-to-end. T-PDU: Transport PDU. Homma, et al. Expires December 31, 2018 [Page 4] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 G-PDU: GTP encapsulated user Plane Data Unit. GTP-U has above two notions on PDU. T-PDU is a PDU that GTP-U header encapsulates. G-PDU is a PDU that includes GTP-U header. A G-PDU may include a T-PDU. G-PDU can be sent without T-PDU, but just with extension headers or TLV elements. It can be used for OAM related operations. PDU session: Association between the UE and a Data Network that provides a PDU connectivity service. Data Network (DN): The network of operator services, Internet access or 3rd party services. User Plane (UP): Encapsulating user end-to-end PDU. In fact, we can't find exact text that defines UP in the architecture specification. However when we see the figure 8.3.1-1 in [TS.23.501-3GPP], we specify UP as the layer right under PDU that directly encapsulates PDU. Underneath layers of UP are UP transport, such as IP/UDP, L2 and L1. However 3GPP is consistent to use the term user plane when they indicate that layer. In IETF, we can see the terms data plane, or forwarding plane as variations which often makes us tend to be confused in terminology. QFI: QoS Flow Identifier UPF: User Plane Function SMF: Session Management Function SMF is a control plane function which provides session management service that handling PDU sessions in the control plane. SMF allocates tunnels corresponding to the PDU sessions and configure the tunnel to the UPF. RAN: Radio Access Network Noted that UP protocol provides a RAN to connect UPF. But the UP protocol is not appeared on the air in the RAN. 3. GTP-U Specification and Observation In this section we analyze the GTP-U specification and summarize clarified characteristic of GTP-U to see if GTP-U meets the requirements of 5G architecture for user plane in later section. Homma, et al. Expires December 31, 2018 [Page 5] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 3.1. GTP-U Tunnel GTP-U is a tunneling protocol between GTP-U tunnel endpoint nodes and encapsulates T-PDU from UE on top of IP/UDP. TEID value allocated on each end point which tunnel indicates particular T-PDU belongs to. That is described in section 4.2.1 of [TS.29.281-3GPP]. [GTP-U-1]: GTP-U is a Point-to-Point tunneling protocol. Point-to-Multipoint (P2MP) tunneling enables one sender tunnel endpoint node to multiple receiver tunnel endpoint nodes. The P2MP tunneling is used for MBMS (Multimedia Broadcast Multicast Service) through GTP-U described in section 4.2.6 of [TS.29.281-3GPP]. [GTP-U-2]: GTP-U supports Point-to-Multipoint tunneling. Figure 1 and Figure 2 show examples of GTP-U protocol stack for uplink (UL) and downlink (DL) traffic respectively. Sender tunnel endpoint node encapsulates the IP packet from UE with GTP-U header, IPv4 or IPv6, and UDP. GTP-U tunnel is a uni-directional tunnel so that two directions comprise one bi-directional tunnel: UL: From RAN to UPF1 (TEID=1), and from UPF1 to UPF2 (TEID=2) DL: From UPF2 to UPF1 (TEID=3), and from UPF1 to RAN (TEID=4) Homma, et al. Expires December 31, 2018 [Page 6] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 GTP-U Tunnel (TEID=1) (TEID=2) -------------> -------------> +-----+ N3 +------+ N9 +------+ | RAN |------------| UPF1 |------------| UPF2 | +-----+ +------+ +------+ +---------+ +---------+ | L1 | | L1 | +---------+ +---------+ | L2 | | L2 | +---------+ +---------+ |IPv4/IPv6| |IPv4/IPv6| +---------+ +---------+ | UDP | | UDP | +---------+ +---------+ +---------+ | L1 | |GTP-U Hdr| |GTP-U Hdr| +---------+ |(TEID=1) | |(TEID=2) | | L2 | +---------+ +---------+ +---------+ |IPv4/IPv6| |IPv4/IPv6| |IPv4/IPv6| +---------+ +---------+ +---------+ | PDU | -----> | PDU | -----> | PDU | -----> +---------+ +---------+ +---------+ Figure 1: Protocol Stack by GTPv1-U for Uplink Traffic Flow Homma, et al. Expires December 31, 2018 [Page 7] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 GTP-U Tunnel (TEID=4) (TEID=3) <------------- <------------- +-----+ N3 +------+ N9 +------+ | RAN |------------| UPF1 |------------| UPF2 | +-----+ +------+ +------+ +---------+ +---------+ | L1 | | L1 | +---------+ +---------+ | L2 | | L2 | +---------+ +---------+ |IPv4/IPv6| |IPv4/IPv6| +---------+ +---------+ | UDP | | UDP | +---------+ +---------+ +---------+ | L1 | |GTP-U Hdr| |GTP-U Hdr| +---------+ |(TEID=4) | |(TEID=3) | | L2 | +---------+ +---------+ +---------+ |IPv4/IPv6| |IPv4/IPv6| |IPv4/IPv6| +---------+ +---------+ +---------+ <----- | PDU | <----- | PDU | <----- | PDU | +---------+ +---------+ +---------+ Figure 2: Protocol Stack by GTPv1-U for Downlink Traffic Flow [GTP-U-3]: GTP-U supports load balancing by using dynamic UDP source port allocation. UDP is utilized for GTP-U encapsulation and UDP destination port is 2152 which is assigned by IANA. Allocation of UDP source port depends on sender tunnel endpoint node and GTP-U supports dynamic allocation of UDP source port for load balancing objective. The specification of this dynamic allocation is described 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]: UDP zero checksum is not available in case of IPv6 transport. GTP-U supports both IPv4 and IPv6 as underlying transport layer protocol. As for IPv6, GTP-U specification refers [RFC2460], which is described in section 4.2.3 of [TS.29.281-3GPP]. As [RFC2460] does not allow the tunnel protocols on top of UDP to set the checksum value to zero, the GTP-U specification inherits it while the IPv4 transport for GTP-U case allows UDP zero checksum. It is noted that the IPv6 specification in IETF has been updated to [RFC8200] which allows UDP zero checksum for the tunnel. [RFC6935] describes Homma, et al. Expires December 31, 2018 [Page 8] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 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]: GTP-U does not support to response ICMP PTB for Path MTU Discovery. "Unnecessary fragmentation should be avoided" is recommended and to avoid the fragmentation operator should configure MTU size at UE [TS.29.281-3GPP]. However, there's no reference and specification of Path MTU Discovery for IPv6 transport. If encapsulated IPv6 packet is too big on a network link between tunnel endpoint nodes, UE may not receive ICMPv6 Packet Too Big message and causes Path MTU Discovery black hole. 3.2. GTP-U Header Format Figure 3 shows general and mandatory GTP-U header and Figure 4 shows extension GTP-U header. [GTP-U-6]: GTP-U supports sequence number option in the header, but it is not recommended to be used by almost GTP-U entities. GTP-U header has Sequence Number field to reorder incoming packets based on the sequence number. If Sequence Number Flag is set to '1' it indicates that Sequence Number Filed exists in GTP-U header and examined at receiving tunnel endpoint node to reorder incoming packets. However, the sequence number flag is set to '1' only for RAT HO procedure and sequence number flag should be set to '0' in normal case. Therefore, in normal case receiver tunnel endpoint node doesn't examine sequence number and can't reorder GTP-U packets based on the sequence number. This specification is described in section 5.1 of [TS.29.281-3GPP]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver |P|R|E|S|N| Message Type| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Endpoint Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | N-PDU Number | Next-Ext-Hdr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: GTP-U Header Homma, et al. Expires December 31, 2018 [Page 9] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 o Ver: Version field (Set to '1') o P: Protocol Type (Set to '1') o R: Reserved bit (Set to '0') o E: Extension Header Flag (Set to '1' if extension header exists) o S: Sequence Number Flag (Set to '1' if sequence number exists) o N: N-PDU Number Flag (Set to '1' if N-PDU number exists) o Message Type: Indicates the type of GTP-U message o Length: Indicates the length in octets of the payload o Tunnel Endpoint Identifier (TEID) o Sequence Number: Indicates increasing sequence number for T-PDUs is transmitted via GTP-U tunnels o N-PDU Number: It is used only for inter SGSN, 2G-3G handover case, etc. o Next-Ext-Hdr: Indicates following extension header type 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext-Hdr Length| | +-+-+-+-+-+-+-+-+ | | Extension Header Content | . . . +-+-+-+-+-+-+-+-+ | | Next-Ext-Hdr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Extension GTP-U Header o Ext-Hdr Length: Represents the length of the Extension header in units of 4 octets o Extension Header Content: Contains 3GPP related information o Next-Ext-Hdr: Indicates following extension header type The extension GTP-U header is a variable-length and extendable header and contains 3GPP specific information. Following list summarizes Homma, et al. Expires December 31, 2018 [Page 10] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 every extension header which is used for user plane protocol. These extension headers are defined in [TS.29.281-3GPP]. In this list Next-Ext-Hdr is represented in binary. o No more extension headers (Next-Ext-Hdr = 00000000) o Service Class Indicator (Next-Ext-Hdr = 00100000) o UDP Port (Next-Ext-Hdr = 01000000) o RAN Container (Next-Ext-Hdr = 10000001) o Long PDCP PDU Number (Next-Ext-Hdr = 10000010) o Xw RAN Container (Next-Ext-Hdr = 10000011) o NR RAN Container (Next-Ext-Hdr = 10000100) o PDU Session Container (Next-Ext-Hdr = 10000101) o PDCP PDU Number (Next-Ext-Hdr = 11000000) [GTP-U-7]: GTP-U supports carrying QoS Identifiers transparently for Access Networks in an extension header. GTP-U is designed to carry 3GPP specific information with extension headers. 3GPP creates PDU Session Container extension header for NGRAN of 5G to carry QFI. It is described in section 5.2.2.7 of [TS.29.281-3GPP]. [GTP-U-8]: GTP-U supports DSCP marking based on the QFI. DSCP marking on outer IPv4 or IPv6 shall be set by sender tunnel endpoint node based on the QFI. This specification is described in section 4.4.1 of [TS.29.281-3GPP]. However in [TS.29.281-3GPP] "DSCP marking based on QCI" is specified but "DSCP marking based on QFI" has not been noted. To support QFI of 5G QoS framework, it seems to need to update [TS.29.281-3GPP]. [GTP-U-9]: GTP-U does not specify extension header order. Multiple GTP-U extension headers are able to contained in one GTP-U packet, however the order of extension header order is not specified in this document. Thereby the receiving endpoint can't predict exact position where the target extension headers are. This could impact on header lookup performance on the node. [GTP-U-10]: GTP-U does not support to indicate next protocol type. Homma, et al. Expires December 31, 2018 [Page 11] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 When Next-Ext-Hdr is set to 0x00 it indicates that no more extension headers follow. As GTP is designed to indicate protocol types for T-PDU by control-plane signaling, GTP-U doesn't have Next-Protocol- Header field to indicate the T-PDU type in the header. 3.3. Control Plane Protocol for GTP-U Control plane protocol for GTP-U signals TEID between tunnel endpoint nodes. GTPv2-C [TS.29.274-3GPP] is the original control plane protocol tied with GTP-U in previous generation architectures before CUPS (Control and User Plane Separation). 3GPP decided to use extended PFCP (Packet Forwarding Control Protocol) [TS.29.244-3GPP] for N4 interface [TR.29.891-3GPP] to signal tunnel states from SMF to UPF. 3.4. GTP-U message GTP-U supports in-band messaging to signal OAM. Currently GTP-U supports following messages [TS.29.281-3GPP]. o Echo Request o Echo Response o Supported Extension Headers Notification o Error Indication o End Marker [GTP-U-11]: GTP-U supports active OAM as a path management message "Echo Request/Response". A GTP-U tunnel endpoint node sends a Echo Request message to another nodes for keep-alive and received node sends a Echo Response message to sender node as acknowledgment. Echo Request message and Echo Response message are described in section 7.2.1 and section 7.2.2 of [TS.29.281-3GPP] respectively. [TR.29.891-3GPP] recommends not to send Echo Request message more often than 60s on each path. Supported Extension Headers Notification message indicates a list of supported that tunnel endpoint node can support. This message is sent only in case a tunnel endpoint node receives GTP-U packet with unsupported extension header. [GTP-U-12]: GTP-U supports tunnel management messages "Error Indication". Homma, et al. Expires December 31, 2018 [Page 12] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 GTP-U has Error Indication message to notify that the receiving endpoint discard packets of which no session exist to the sending endpoint. Error Indication message is described in section 7.3.1 of [TS.29.281-3GPP]. [GTP-U-13]: GTP-U supports tunnel management messages "End Marker". GTP-U has End Marker message to indicate the end of the payload stream that needs to be sent on a GTP-U tunnel. End Marker message is described in section 7.3.2 of [TS.29.281-3GPP]. 3.5. Packet Format Figure 5 shows a packet format example of GTP-U over IPv6 that carries an extension header for QFI and an IPv6 PDU. All values in the example are illustration purpose only. The encoding of PDU Session Container for QFI refers to [TS.38.415-3GPP]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Outer IPv6 Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| DSCP=EF | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | NxtHdr=17(UDP)| Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source IPv6 Address + | 2001:db8:1:1::1 | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination IPv6 Address + | 2001:db8:1:2::1 | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Outer UDP Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port = xxxx | Dest Port = 2152 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP Length | UDP Checksum (Non-zero) | Homma, et al. Expires December 31, 2018 [Page 13] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GTP-U header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x1 |1|0|1|0|0| 0xff | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TEID = 1654 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number = 0 |N-PDU Number=0 |NextExtHdr=0x85| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GTP-U Extension Header (PDU Session Container) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ExtHdrLen=1 |Type=0 | Spare |0| QFI |NextExtHdr=0x0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Inner IPv6 Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| DSCP=0 | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | NexttHdr | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source IPv6 Address + | 2001:db8:2:1::1 | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination IPv6 Address + | 2001:db8:3:1::1 | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | . TCP/UDP/etc., Data . . . | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Homma, et al. Expires December 31, 2018 [Page 14] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 Figure 5: GTP-U Protocol Stack Example 3.6. Observations Summary [GTP-U-1]: A Point-to-Point tunneling protocol. [GTP-U-2]: Supports Point-to-Multipoint tunneling. [GTP-U-3]: Supports load balancing by using dynamic UDP port allocation. [GTP-U-4]: UDP zero checksum is not available in case of IPv6 transport. [GTP-U-5]: Does not support to response ICMP PTB for Path MTU Discovery. [GTP-U-6]: Supports sequence number option and sequence number flag in the header, but it is not recommended to be used by almost GTP-U entities. [GTP-U-7]: Supports carrying QoS Identifiers transparently for Access Networks in extension headers. [GTP-U-8]: Supports DSCP marking based on the QFI. [GTP-U-9]: Does not specify the rule for the extension header order. [GTP-U-10]: Does not support an indication of next-header type. [GTP-U-11]: Supports active OAM as a path management message "Echo Request/Response". [GTP-U-12]: Supports tunnel management messages "Error Indication". [GTP-U-13]: Supports tunnel management messages "End Marker". 4. 5GS Architectural Requirements for User Plane Protocols 4.1. Overview of 5G System Architecture The 5G system is designed for applying to diverse devices and services such, and the UP protocol is required to have capabilities for satisfying their requirements. As a principle of the 5G system, User Plane (UP) functions are separated from the Control Plane (CP) functions for allowing independent scalability, evolution and flexible deployments. Homma, et al. Expires December 31, 2018 [Page 15] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 Network slicing, one of the fundamental concepts of the 5G system, provides logical network separation. In terms of user plane, multiple network slices can be comprised of UPFs on top of same physical network resources. Allocated resources and structures may be differentiated among the slices by which the required features or capabilities. The architecture overview is shown in Figure 6. The details of functions are described in [TS.23.501-3GPP]. User plane path and applied functions for a tunnel will be manipulated based on application requirements that the PDU session corresponding to the tunnel is available to be handled by other authorized functions through the control plane. +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ |NSSF | | NEF | | NRF | | PCF | | UDM | | AF | +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ Nnssf| Nnef| Nnrf| Npcf| Nudm| |Naf ---+--------+--+-----+--+--------+--+-----+--------+- Nausf| Namf| Nsmf| +--+--+ +--+--+ +--+-------+ |AUSR | | AMF | | SMF | +-----+ ++-+--+ +--+-----+-+ / | | \ Control Plane N1/ |N2 |N4 \N4 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ User Plane / | | \ +--++ +--+--+ N3 +--+--+ N9 +-+---+ N6 +-----+ |UE +--+(R)AN+-----+ UPF +-----+ UPF +----+ DN | +---+ +-----+ +--+--+ +-----+ +-----+ |N6 +--+--+ | DN | +-----+ Figure 6: 5GS Architecture and Service-based Interfaces This document mainly focuses on requirements for N9 interface as relevant to UP protocol of 5G system. Homma, et al. Expires December 31, 2018 [Page 16] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 4.1.1. UPF Functionalities UPF has a role to handle UP traffic, and provides functionalities to look up user data traffic and enforce the appropriate policies to it. The followings are defined as UPF functionalities for traffic handling: o User Plane part of policy rule enforcement, e.g. Gating, Redirection, Traffic steering) o QoS handling for user plane, e.g. UL/DL rate enforcement, Reflective QoS marking in DL o Transport level packet marking in the uplink and downlink Other functionalities are described in the section 6.2.3 of [TS.23.501-3GPP] UPF shall detect user plane traffic flow depending on information indicated by SMF. User data traffic is detected with combination of the following information: o For IPv4 or IPv6 PDU Session type * PDU Session * QFI * Application Identifier: The Application ID is an index to a set of application detection rules configured in UPF o For Ethernet PDU Session type * PDU Session * QFI * Ethernet Packet Filter Set: + Source/destination MAC address + Ethertype as defined in IEEE 802.3 + Customer-VLAN tag(C-TAG) and/or Service-VLAN tag(S-TAG) VID fields as defined in IEEE 802.1Q Homma, et al. Expires December 31, 2018 [Page 17] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 + Customer-VLAN tag(C-TAG) and/or Service-VLAN tag(S-TAG) PCP/ DEI fields as defined in IEEE 802.1Q + IP Packet Filter Set, in case Ethertype indicates IPv4/IPv6 payload + Packet filter direction Such information for traffic detection (Traffic Detection Information) is described in the section 5.8.2.4 of [TS.23.501-3GPP]. 4.2. Architectural Requirements for User Plane Protocols This section lists the requirements for the UP protocol on the 5G system. The requirements are picked up from [TS.23.501-3GPP]. In addition, some of service requirements described in [TS.22.261-3GPP] are referred to clarify the originations of architectural requirements. According to [TS.23.501-3GPP], the specifications potentially have assumptions that the user plane protocol is a tunnel representing a single 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 be managed under per PDU session handling. Also, it should be a stateful tunnel in the UPFs along with the PDU session. The requirements for UP protocols are described below: ARCH-Req-1: Supporting IPv4, IPv6, Ethernet and Unstructured PDU The 5G system defines four types of PDU session as IPv4, IPv6, Ethernet, and Unstructured. Therefore, UP protocol must support to convey all of these PDU session types. This is described in [TS.23.501-3GPP]. Note: In TS 23.501 v15.2.0, IPv4v6 is added as a PDU session type. ARCH-Req-2: Supporting IP connectivity for N3, N6, and N9 interfaces The 5G system requires IP connectivity for N3, N6, and N9 interfaces. The IP connectivity is assumed that it comprises of IP routing and L1/L2 transport networks which are outside of 3GPP specifications. On N6 interface, point-to-point tunneling based on UDP/IPv6 may be used to deliver unstructured PDU type data. Then, the content information of the PDU may be mapped into UDP port number, and the UDP port numbers is pre-configured in the UPF and DN. This is described in the section 9.2 of [TS.29.561-3GPP]. Homma, et al. Expires December 31, 2018 [Page 18] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 ARCH-Req-3: Supporting deployment of multiple UPFs as anchors for a single PDU session The 5G system allows to deploy multiple UPFs as anchors for a single PDU session, and supports multihoming of a single PDU session for such anchor UPFs. Multihoming is provided with Branching Point (BP) or Uplink Classifier (UL CL) which are functionalities of UPF. BP provides forwarding of UL traffic towards the different PDU Session Anchors based on the source IPv6 prefixes and merge of DL traffic to the UE. UL CL provides destination based multihoming for load balancing. On UL side, multihoming of a single PDU session is achieved by a point-to-point (P2P) tunnel per anchor UPF. It means that multiple P2P paths are established from one source gNB or UPF to the multiple destination anchor UPFs for the PDU session. On DL side, one single multipoint-to-point (MP2P) path exists from the anchor UPFs to the source gNB or UPF for the PDU session in this multihoming case. It means that the paths from the anchor UPFs are merged into just one tunnel state at the source gNB or UPF for the PDU session. Multiple P2P paths on DL could also be used for multihoming. However it should be the multiple PDU sessions multihoming case where the destination gNB or UPF needs to maintain multiple tunnel states under the one PDU session to one UP tunnel architectural principle. However, P2P tunneling could increase explosively the number of states in UPF as the anchor UPF/DN incremented to the PDU session. Thereby single PDU session multihoming with MP2P path should be a better option for multihoming in terms of reducing total number of tunnel states. SSC mode 3 for session continuity in hand-over case uses a single PDU multihoming with BP to make sure make-before-break. It is described in the section 5.6.4 and 5.6.9 of [TS.23.501-3GPP]. Multihoming is also assumed to be used for edge computing scenario. Edge computing enables some services to be hosted close to the UE's access point of attachment, and achieves an efficient service delivery through the reduced end-to-end latency and load on the transport network. In edge computing, local user's traffic is routed or steered to application in the local DN by UPF. This refers the section 5.13 of [TS.23.501-3GPP]. ARCH-Req-4: Supporting flexible UPF selection for PDU Homma, et al. Expires December 31, 2018 [Page 19] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 The appropriate UPFs are selected for a PDU session based on parameters and information such as UPF's dynamic load or UE location information. Examples of parameters and information are described in the section 6.3.3 of [TS.23.501-3GPP]. ARCH-Req-5: No limitation for number of UPFs in a data path The number of UPF in the data path is not constrained by 3GPP specifications. This specification is described in the section 8.3.1 of [TS.23.501-3GPP]. Putting multiple UPFs, which provides specific function, in a data path enables flexible function deployment to make sure load distribution optimizations, etc. In addition, deployment of multiple UPFs as anchors closed to UEs' site and connecting them without extra anchor points enable to make data path more efficient. This usage is described in the section 6.5 of [TS.22.261-3GPP]. It is expected that multiple UPFs with per session tunnel handling for a PDU session becomes complicated task more and more for a SMF by increasing number of UPFs, and UP protocol shall support to aggregate several PDU sessions into a tunnel or shall be a session-less tunnel. ARCH-Req-6: Supporting aggregation of multiple QoS Flow indicated with QFI into a PDU Session Against to the previous generation, 5G enables UPF to multiplex QoS Flows, equivalent with IP-CAN bearers in the previous generation, into one single PDU session. That means that a single tunnel includes multiple QFIs contrast to just one QoS Flow (a bearer) to one tunnel before 5G. This specification is described in 5.7.1 of [TS.23.501-3GPP]. 5. Evaluation Aspects This section provides UP protocol evaluation aspects that are mainly we derived from the architectural requirements described in Section 4. Those aspects are not prioritized by the order here. Expected deployment scenarios explain the evaluations purpose in the corresponding aspects. As we were noticed that the gaps between GTP-U specifications and 5G architectural requirements through the analysis, those each gap are briefly described in the evaluation aspect associated to it. Homma, et al. Expires December 31, 2018 [Page 20] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 Since it is obvious that 5G system should be able to interwork with existing previous generation based systems, any aspects from coexisting and interworking point of view are not particularly articulated here. It may be described in a next version. 5.1. Supporting PDU Session Type Variations Given that UP protocol is required to support all PDU session types: IPv4, IPv6, Ethernet, and Unstructured. However, it is expected that some deployment cases allow candidate protocol to adopt only one or few PDU session type(s) for simplicity of operations. As we can expect that IPv4 connectivity services will be available through IPv6-only PDU session that enabled by bunch of IPv6 transition solutions already available in the field. For this, the expected evaluation points from this aspect should be whether there is substitutional means to cover other PDU session types. And how much it makes simple the system than deploying original PDU session types. 5.2. Nature of Data Path As it is described in Section 4.2, the single PDU session multi- homing case requires multipoint-to-point (MP2P) data path. It should be much scalable than multi-homing with multiple PDU sessions because number of required path states in the UPFs are reduced as closed to egress endpoint. Against that point-to-point (P2P) protocol requires same number of states in each UPF throughout the path. Supporting MP2P data path by GTP-U could be a gap in terms of single PDU session multi-homing, since GTP-U is a point-to-point tunneling protocol as it is described in Section 3. Therefore the expected evaluation points from this aspect is whether the nature of candidate UP protocols are to utilize MP2P data path. 5.3. Supporting Transport Variations 5G system will be expected that the new radio spectrums in high frequency bands require operators to deploy their base stations much dense for much wider areas compare to previous generation footprints. To make sure that density and coverage, all available types of transport in the field must be employed between RAN to UPF, or UPF to UPF. It is also expected that MTU size of each transport could be varied. Because one could be own fiber which the operator configure the MTU size as they like while others are third-party provided L2/L3 VPN Homma, et al. Expires December 31, 2018 [Page 21] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 lines which MTU size can't be controlled by the operators. So it is recommended MTU size discovery for each data path and dynamic MTU size adjustment mechanisms, while GTP-U does not support those mechanisms. As the study item in 3GPP mentioned, IPv6 is preferable address family not only for UEs, but also for the UP transport, in terms of size of available address space to support dense and wide footprint of base stations. However it increases header size from 20bytes to 40bytes compare to IPv4. It could be a problem if the MTU size is uncontrollable, or only limited MTU size available to carry committed PDU size on the user plane. The expected evaluation points from this aspect should be that the candidate protocols are able to dynamically adjust path MTU size with appropriate MTU size discovery mechanism. It also should be that how the candidate protocols leverage IPv6 to deal with header size increasing. 5.4. Data Path Management As Section 4.2 described, the 5G systems allows user plane that flexible UPF selection, multiple anchor UPFs, and no limit on how many UPFs chained for the data path of the PDU session. UPF deployments in the field will thereby be distributed to be able to optimize the data path based on various logics and service scenarios. That powerful user plane capability could affect data path management complicated and difficult to be managed through the control plane, or operation support systems (OSS). Perhaps it could be the case where the UP protocol nature is P2P and it only supports per session base data path handling. Because it increases data path states by number of sessions, and number of endpoints of UPFs that makes data path handling much hectic and the control plane tend to be overloaded by not only usual attach/detach/hand-over operations, but also existing session manipulation triggered by UPF and transport nodes/paths restoration, etc., The expected evaluation points from this aspect should be that how much the candidate protocols can reduce data path management loads both on the control plane NFs and UPFs compare to the per session based handling for P2P paths. It could possibly include N3 and N6 in addition to N9 while it supports flexible user plane data path optimizations for some example scenarios. Homma, et al. Expires December 31, 2018 [Page 22] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 5.5. QoS Control The QoS model is based on QoS flows to which QFI indicates in the 5G system that allows multiple QoS flows are aggregated into a single PDU session. So that it is given that the UP protocol should convey QFIs for a PDU session and the UPF needs to lookup them. It makes sure that reflects QoS policy in the 5G system to corresponding forwarding policy in the user plane IP transports. As we pointed out in Section 3.2, the lookup process could impact UPF performance if the QFI container position in the header is unpredictable. It could happen many times along the path because the each UPFs should do it again and again in case that various different QoS policies are deployed in the networks under the UP as we discussed in Section 5.3. The expected evaluation points from this aspect should be whether the candidate protocols can provide stable ID space for QFI which shouldn't be a big deal since QFI just requires 6-bits space. 5.6. Traffic Detection and Flow Handling As described in Section 4.1.1, UPF need to detect traffic flow specified by SMF within a PDU session, and enforce some processes to the PDU based on the pre-configured policy rule. As similar with QoS flow lookup described in Section 5.5, UPFs along the path are repeatedly detecting an specified traffic flow in inner PDU. It could increase redundant flow detection load on every UPFs that could be avoided if the upstream UPF put some identifier which abstracts the detected flow into the packets. It enables following UPFs just find the ID to detect the indicated flow from the packet. The expected evaluation points from this aspect should be whether the candidate protocols can provide means to reduce that redundant flow detection that could be enough bits space on stable ID space to put abstracted detected flow identifier. 5.7. Supporting Network Slicing Diversity To embody network slicing, it is expected that various means should be available in case by case, or operator by operator, for their 5G systems while it follows the fundamental slicing concept, as described in Section 4.1. As [TS.28.530-3GPP] described in section 4, UP underlay transport networks and UPFs are shared by network slices. The data model defined in [TS.29.510-3GPP] allows that a Network Instance, a UPF and Homma, et al. Expires December 31, 2018 [Page 23] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 its interfaces can belong to multiple slices as same as other type of NFs. UP endpoint IP prefix/address of an interface can also be shared with multiple interfaces on the UPF as the model doesn't make them slice unique. The assumed slice operation in 5G architecture is that UPFs connect to each other through direct (virtual) link as Section 4.1 describes that UPFs compose a network slice on an UP. So IP routing and transport system underneath the UP are not visible from the 5G system. However some means need to indicate a slice on the shared underlying networks of the UP over the wire. That's just one way for network slicing, but it helps to reduce the operational burden while there's no 3GPP specification for slice lifecycle managements, such as create, update, and delete operations for slices. Even it depends on each operator's policy, sharing Network Instance, UPFs and the interfaces among slices makes operators relax and not to be much hustled on slice lifecycle management. It could also make sense in case that each network slice requires different forwarding policies in the middle of the path. Some identifier in the packets for a slice could be a glue between UP path and its underlying transport networks. For example, if a slice requires certain level of latency with dedicated route, traffic engineering (TE) embodies appropriate forwarding policy through the underlay transport network. The expected evaluation points from this aspect should be whether the candidate protocols can support to indicate a network slice in the UP packets that could be enough bits space on stable ID space to put slice identifier for the slice, or the forwarding policy within the slice. Since 5G control plane is not designed to handle transport resources, such as VLAN, MPLS Label, Tunnel ID except GTP-U, less impact to the control plane protocol and the APIs should be much preferable. 6. Conclusion We analyzed the 3GPP specifications of 5G architecture in terms of user plane and the current protocol adopted to the user plane. After the analysis work, we believe that the results described in this document shows that we reach at certain level of understanding on 5G systems and ready to provide our inputs to 3GPP. We clarified GTP-U through the analysis and listed observed characteristics in Section 3.6. We also clarified the architectural requirements for UP protocol described in Section 4.2. Homma, et al. Expires December 31, 2018 [Page 24] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 As we identified some potential gaps between the current UP protocol and the architectural requirements even for Release 15, it is worth to study possible candidate UP protocols for the 5G system including current one. Our conclusion here is that we suggest the UP protocol study work in 3GPP takes into account the evaluation aspects described in Section 5. 7. Security Consideration TBD 8. Acknowledgement The authors would like to thank Tom Herbert, Takashi Ito, John Leddy, Pablo Camarillo, Daisuke Yokota, Satoshi Watanabe, Koji Tsubouchi and Miya Kohno for their detailed reviews, comments, and contributions. A special thank you goes to Arashmid Akhavain for his technical review and feedback. 9. Informative References [CP-173160-3GPP] 3rd Generation Partnership Project (3GPP), "New Study Item on User Plane Protocol in 5GC", December 2017, . [CP-180116-3GPP] 3rd Generation Partnership Project (3GPP), "LS on user plane protocol study", March 2018, . [I-D.bogineni-dmm-optimized-mobile-user-plane] Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D., Rodriguez-Natal, A., Carofiglio, G., Auge, J., Muscariello, L., Camarillo, P., and S. Homma, "Optimized Mobile User Plane Solutions for 5G", draft-bogineni-dmm- optimized-mobile-user-plane-01 (work in progress), June 2018, . [IAB-Statement] Internet Architecture Board (IAB), "IAB Statement on IPv6", November 2016, . Homma, et al. Expires December 31, 2018 [Page 25] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [TR.29.891-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TR 29.891 (V15.0.0): 5G System Phase 1, CT WG4 Aspects", December 2017, . [TS.22.261-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 22.261 (V15.4.0): Service requirements for 5G system stage 1", March 2018, . [TS.23.501-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 23.501 (V15.1.0): System Architecture for 5G System; Stage 2", March 2018, . [TS.23.502-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 23.502 (V15.1.0): Procedures for 5G System; Stage 2", March 2018, . [TS.23.503-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 23.503 (V15.1.0): Policy and Charging Control System for 5G Framework; Stage 2", March 2018, . Homma, et al. Expires December 31, 2018 [Page 26] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 [TS.28.530-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 28.530 (V1.0.0): Management and orchestration of networks and network slicing; Concepts, use cases and requirements (work in progress)", June 2018, . [TS.29.244-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 29.244 (V15.1.0): Interface between the Control Plane and the User Plane Nodes; Stage 3", March 2018, . [TS.29.274-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 29.274 (V15.4.0): 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunneling Protocol for Control plane (GTPv2-C); Stage 3", June 2018, . [TS.29.281-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 29.281 (V15.2.0): GPRS Tunneling Protocol User Plane (GTPv1-U)", March 2018, . [TS.29.510-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 29.510 (V15.0.0): 5G System; Network Function Repository Services; Stage 3", June 2018, . [TS.29.561-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 29.561 (V15.0.0): 5G System; Interworking between 5G Network and external Data Networks; Stage 3", June 2018, . [TS.38.300-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 38.300 (v15.1.0): NR and NG-RAN Overall Description; Stage 2", March 2018, . Homma, et al. Expires December 31, 2018 [Page 27] Internet-Draft draft-hmm-dmm-5g-uplane-analysis-00 June 2018 [TS.38.401-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 38.401 (v15.1.0): NG-RAN; Architecture Description", March 2018, . [TS.38.415-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 38.415 (v1.0.0): NG-RAN; PDU Session User Plane protocol (work in progress)", June 2018, . Authors' Addresses Shunsuke Homma NTT Email: homma.shunsuke@lab.ntt.co.jp Takuya Miyasaka KDDI Research Email: ta-miyasaka@kddi-research.jp Satoru Matsushima SoftBank Email: satoru.matsushima@g.softbank.co.jp Daniel Voyer Bell Canada Email: daniel.voyer@bell.ca Homma, et al. Expires December 31, 2018 [Page 28]