draft-ietf-dmm-5g-uplane-analysis-00.txt   draft-ietf-dmm-5g-uplane-analysis-01.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: July 10, 2019 KDDI Research Expires: September 12, 2019 KDDI Research
S. Matsushima S. Matsushima
SoftBank SoftBank
D. Voyer D. Voyer
Bell Canada Bell Canada
January 6, 2019 March 11, 2019
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-00 draft-ietf-dmm-5g-uplane-analysis-01
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 https://datatracker.ietf.org/drafts/current/. Drafts is at http://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 July 10, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (http://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 . . . . . . . . . . . . . . . . 3 1.2. Our Way of Analysis Work . . . . . . . . . . . . . . . . 3
2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4
3. GTP-U Specification and Observation . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . 10
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.2. Architectural Requirements for User Plane Protocols . 19 4.1.2. UP Traffic Detection . . . . . . . . . . . . . . . . 18
5. Evaluation Aspects . . . . . . . . . . . . . . . . . . . . . 22 4.2. Architectural Requirements for User Plane Protocols . 20
5.1. Supporting PDU Session Type Variations . . . . . . . . . 23 5. Evaluation Aspects . . . . . . . . . . . . . . . . . . . . . 24
5.2. Nature of Data Path . . . . . . . . . . . . . . . . . . . 23 5.1. Supporting PDU Session Type Variations . . . . . . . . . 25
5.3. Supporting Transport Variations . . . . . . . . . . . . . 24 5.2. Nature of Data Path . . . . . . . . . . . . . . . . . . . 25
5.4. Data Path Management . . . . . . . . . . . . . . . . . . 24 5.3. Supporting Transport Variations . . . . . . . . . . . . . 25
5.5. QoS Control . . . . . . . . . . . . . . . . . . . . . . . 25 5.4. Data Path Management . . . . . . . . . . . . . . . . . . 26
5.6. Traffic Detection and Flow Handling . . . . . . . . . . . 26 5.5. QoS Control . . . . . . . . . . . . . . . . . . . . . . . 27
5.7. Supporting Network Slicing Diversity . . . . . . . . . . 26 5.6. Traffic Detection and Flow Handling . . . . . . . . . . . 27
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.7. Supporting Network Slicing Diversity . . . . . . . . . . 28
7. Security Consideration . . . . . . . . . . . . . . . . . . . 27 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 29
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 28 7. Security Consideration . . . . . . . . . . . . . . . . . . . 29
9. Informative References . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 9. Informative References . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
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 4, line 22 skipping to change at page 4, line 22
Section 4. Section 4.
Based on the results of above, we identify some aspects where there Based on the results of above, we identify some aspects where there
might be gap between the current user plane protocol and the might be gap between the current user plane protocol and the
architectural requirements on which [TR.29.891-3GPP] does not architectural requirements on which [TR.29.891-3GPP] does not
discuss. That aspects are discussed Section 5. That's what we 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 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 utilize it as an input to evaluate the candidate protocols for user
plane to the 5G system including the current protocol. 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 2. Terms and Abbreviations
This section describes terms of functions and interfaces relevant to This section describes terms of functions and interfaces relevant to
user plane protocol which we extract from the 3GPP specifications user plane protocol which we extract from the 3GPP specifications
since this document focuses on user plane. since this document focuses on user plane.
In those specifications, there are so many unique terms and In those specifications, there are so many unique terms and
abbreviations in the 3GPP context which IETF community seems not abbreviations in the 3GPP context which IETF community seems not
familiar with. We will try to bring those terms with brief familiar with. We will try to bring those terms with brief
explanations to make sure common understanding for them. explanations to make sure common understanding for them.
skipping to change at page 5, line 43 skipping to change at page 5, line 41
UPF: User Plane Function UPF: User Plane Function
SMF: Session Management Function SMF: Session Management Function
SMF is a control plane function which provides session management SMF is a control plane function which provides session management
service that handling PDU sessions in the control plane. SMF service that handling PDU sessions in the control plane. SMF
allocates tunnels corresponding to the PDU sessions and configure allocates tunnels corresponding to the PDU sessions and configure
the tunnel to the UPF. the tunnel to the UPF.
RAN: Radio Access Network PFCP: Packet Forwarding Control Protocol
PFCP is used on N4 interface between SMF and UPF to configure the
rules of packet detection, forwarding action, QoS enforcement,
usage report and buffering for each PDU session.
PDR: Packet Detection Rule
FAR: Fowarding Action Rule
RAN: Radio Access Network
Noted that UP protocol provides a RAN to connect UPF. But the UP Noted that UP protocol provides a RAN to connect UPF. But the UP
protocol is not appeared on the air in the RAN. protocol is not appeared on the air in the RAN.
3. GTP-U Specification and Observation 3. GTP-U Specification and Observation
In this section we analyze the GTP-U specification and summarize In this section we analyze the GTP-U specification and summarize
clarified characteristic of GTP-U to see if GTP-U meets the clarified characteristic of GTP-U to see if GTP-U meets the
requirements of 5G architecture for user plane in later section. requirements of 5G architecture for user plane in later section.
3.1. GTP-U Tunnel 3.1. GTP-U Tunnel
skipping to change at page 17, line 17 skipping to change at page 17, line 17
independent scalability, evolution and flexible deployments. independent scalability, evolution and flexible deployments.
Network slicing is also one of the fundamental concepts of the 5G Network slicing is also one of the fundamental concepts of the 5G
system, and it provides logical network separation. In terms of user system, and it provides logical network separation. In terms of user
plane, multiple network slices can be comprised of UPFs on top of plane, multiple network slices can be comprised of UPFs on top of
same physical network resources. Allocated resources and structures same physical network resources. Allocated resources and structures
may be differentiated among the slices by which the required features may be differentiated among the slices by which the required features
or capabilities. or capabilities.
The architecture overview is shown in Figure 5. The details of The architecture overview is shown in Figure 5. The details of
functions are described in [TS.23.501-3GPP]. User plane path and functions are described in [TS.23.501-3GPP]. A UPF handles UP paths
applied functions for a tunnel will be manipulated based on on N3, N9 and N6 interface, and the setup is controlled by SMF via N4
application requirements that the PDU session corresponding to the interface. A UP path will be manipulated based on application
tunnel. These tunnels are available to be handled by other requirements for the PDU session corresponding to the path. An SMF
authorized functions through the control plane. is also capable to receive information regarding routing path with
API from AF via NEF, PCF, and SMF.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|NSSF | | NEF | | NRF | | PCF | | UDM | | AF | |NSSF | | NEF | | NRF | | PCF | | UDM | | AF |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
Nnssf| Nnef| Nnrf| Npcf| Nudm| |Naf Nnssf| Nnef| Nnrf| Npcf| Nudm| |Naf
---+--------+--+-----+--+--------+--+-----+--------+- ---+--------+--+-----+--+--------+--+-----+--------+-
Nausf| Namf| Nsmf| Nausf| Namf| Nsmf|
+--+--+ +--+--+ +--+-------+ +--+--+ +--+--+ +--+-------+
|AUSR | | AMF | | SMF | |AUSR | | AMF | | SMF |
+-----+ ++-+--+ +--+-----+-+ +-----+ ++-+--+ +--+-----+-+
skipping to change at page 18, line 10 skipping to change at page 18, line 10
Figure 5: 5GS Architecture and Service-based Interfaces Figure 5: 5GS Architecture and Service-based Interfaces
This document mainly focuses on requirements for N9 interface as This document mainly focuses on requirements for N9 interface as
relevant to UP protocol of 5G system. relevant to UP protocol of 5G system.
4.1.1. UPF Functionalities 4.1.1. UPF Functionalities
UPF has a role to handle UP traffic, and provides functionalities to UPF has a role to handle UP traffic, and provides functionalities to
look up user data traffic and enforce the appropriate policies to it. look up user data traffic and enforce the appropriate policies to it.
The followings are defined as UPF functionalities for traffic The followings are defined as UPF functionalities defined in the
handling: section 6.2.3 of [TS.23.501-3GPP]
o Anchor point for Intra-/Inter-RAT mobility (when applicable).
o External PDU Session point of interconnect to Data Network.
o Packet routing and forwarding (e.g. support of Uplink classifier
to route traffic flows to an instance of a data network, support
of Branching point to support multi-homed PDU Session).
o Packet inspection (e.g. Application detection based on service
data flow template and the optional PFDs received from the SMF in
addition).
o User Plane part of policy rule enforcement, e.g. Gating, o User Plane part of policy rule enforcement, e.g. Gating,
Redirection, Traffic steering) Redirection, Traffic steering).
o Lawful intercept (UP collection).
o Traffic usage reporting.
o QoS handling for user plane, e.g. UL/DL rate enforcement, o QoS handling for user plane, e.g. UL/DL rate enforcement,
Reflective QoS marking in DL Reflective QoS marking in DL.
o Transport level packet marking in the uplink and downlink o Uplink Traffic verification (SDF to QoS Flow mapping).
Other functionalities are described in the section 6.2.3 of o Transport level packet marking in the uplink and downlink.
[TS.23.501-3GPP]
UPF shall detect user plane traffic flow depending on information o Downlink packet buffering and downlink data notification
indicated by SMF. User data traffic is detected with combination of triggering.
the following information:
o Sending and forwarding of one or more "end marker" to the source
NG-RAN node.
o ARP proxying and / or IPv6 Neighbour Solicitation Proxying for the
Ethernet PDUs.
4.1.2. UP Traffic Detection
The traffic detection is described in the section 5.8.2.4 of
[TS.23.501-3GPP]. In 3GPP UP packet forwarding model, UPF detects UP
traffic flow which belong to a N4 session configured by SMF.
The protocol of N4 interface, PFCP, brings a set of traffic detection
information from SMF to UPF as Packet Detection Information (PDI) in
a PDR to establish/modify the N4 PFCP session. It is defined in
section 7.5.2.2 of [TS.29.244-3GPP].
Combination of the following information is used for the traffic
detection:
o For IPv4 or IPv6 PDU Session type o For IPv4 or IPv6 PDU Session type
* PDU Session * CN tunnel info (Tunnel ID and the endpoint IP address of 5G
Core)
* Network instance
* QFI * QFI
* IP Packet Filter Set
* Application Identifier: The Application ID is an index to a set * Application Identifier: The Application ID is an index to a set
of application detection rules configured in UPF of application detection rules configured in UPF
o For Ethernet PDU Session type o For Ethernet PDU Session type
* PDU Session * CN tunnel info(Tunnel ID and the endpoint IP address of 5G
Core)
* Network instance
* QFI * QFI
* Ethernet Packet Filter Set: * Ethernet Packet Filter Set
+ Source/destination MAC address It is noted that Network Instance is encoded as Octet String in PFCP,
and is NOT appeared in UP packet over the wire. It is expected like
an attribute of the receiving IP interface of the UPF. It supports
UPF to be able to connect to different IP domains of N3, N9 or N6,
which run each independent policy in routing and addressing. The UPF
detects traffic flow with Network Instance which the receiving
interface attributed to.
+ Ethertype as defined in IEEE 802.3 The IP Packet Filter Set and Ethernet Packet Filter Set defined in
clause 5.7.6 of [TS.23.501-3GPP] are following:
+ Customer-VLAN tag(C-TAG) and/or Service-VLAN tag(S-TAG) VID o IP Packet Filter Set:
fields as defined in IEEE 802.1Q
+ Customer-VLAN tag(C-TAG) and/or Service-VLAN tag(S-TAG) PCP/ * Source/destination IP address or IPv6 prefix
DEI fields as defined in IEEE 802.1Q * Source/destination port number
+ IP Packet Filter Set, in case Ethertype indicates IPv4/IPv6 * Protocol ID of the protocol above IP/Next header type
payload
+ Packet filter direction * Type of Service (TOS) (IPv4) / Traffic class (IPv6) and Mask.
Such information for traffic detection (Traffic Detection * Flow Label (IPv6)
Information) is described in the section 5.8.2.4 of [TS.23.501-3GPP].
* Security parameter index
* Packet filter direction
o 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
* 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
4.2. Architectural Requirements for User Plane Protocols 4.2. Architectural Requirements for User Plane Protocols
This section lists the requirements for the UP protocol on the 5G This section lists the requirements for the UP protocol on the 5G
system. The requirements are picked up from [TS.23.501-3GPP]. In system. The requirements are picked up from [TS.23.501-3GPP]. In
addition, some of service requirements described in [TS.22.261-3GPP] addition, some of service requirements described in [TS.22.261-3GPP]
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
skipping to change at page 20, line 20 skipping to change at page 21, line 37
and the UDP port numbers is pre-configured in the UPF and DN. This 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]. is described in the section 9.2 of [TS.29.561-3GPP].
ARCH-Req-3: Supporting deployment of multiple UPFs as anchors for a ARCH-Req-3: Supporting deployment of multiple UPFs as anchors for a
single PDU session single PDU session
The 5G system allows to deploy multiple UPFs as anchors for a single The 5G system allows to deploy multiple UPFs as anchors for a single
PDU session, and supports multihoming of a single PDU session for PDU session, and supports multihoming of a single PDU session for
such anchor UPFs. such anchor UPFs.
Multihoming is provided with Branching Point (BP) or Uplink Multihoming is provided with Branching Point (BP). BP provides
Classifier (UL CL) which are functionalities of UPF. BP provides
forwarding of UL traffic towards the different PDU Session Anchors forwarding of UL traffic towards the different PDU Session Anchors
based on the source IPv6 prefixes and merge of DL traffic to the UE. based on the source IPv6 prefixes and merge of DL traffic to the UE.
UL CL provides destination based multihoming for load balancing. UL CL provides destination based multihoming for load balancing.
Noted that, in 3GPP definition, IPv6 multihoming indicates only cases
where "multiple" source IPv6 prefixes are used, and it is different
from IETF definition. Actually, in the 5GS, Up link classifier (UL
CL) is capable to provide forwarding to multiple anchor for a PDU
session with a single source IPv6 prefix, but it is distinguished
from IPv6 multihoming.
On UL side, multihoming of a single PDU session is achieved by a 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 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 P2P paths are established from one source gNB or UPF to the multiple
destination anchor UPFs for the PDU session. destination anchor UPFs for the PDU session.
On DL side, one single multipoint-to-point (MP2P) path exists from 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 the anchor UPFs to the destination gNB or UPF for the PDU session in
multihoming case. It means that the paths from the anchor UPFs are this multihoming case. It means that the paths from the anchor UPFs
merged into just one tunnel state at the source gNB or UPF for the are merged into just one tunnel state at the source gNB or UPF for
PDU session. the PDU session.
Multiple P2P paths on DL could also be used for multihoming. However Multiple P2P paths on DL could also be used for multihoming. However
it should be the multiple PDU sessions multihoming case where the it should be the multiple PDU sessions multihoming case where the
destination gNB or UPF needs to maintain multiple tunnel states under destination gNB or UPF needs to maintain multiple tunnel states under
the one PDU session to one UP tunnel architectural principle. the one PDU session to one UP tunnel architectural principle. It
causes increase of load on tunnel states management in UPF due to
increment of the anchor UPF for the PDU session.
However, P2P tunneling could increase explosively the number of However, P2P tunneling could increase explosively the number of
states in UPF as the anchor UPF/DN incremented to the PDU session. states in UPF as the anchor UPF/DN incremented to the PDU session.
Thereby single PDU session multihoming with MP2P path should be a Thereby single PDU session multihoming with MP2P path should be a
better option for multihoming in terms of reducing total number of better option for multihoming in terms of reducing total number of
tunnel states. tunnel states.
SSC mode 3 for session continuity in hand-over case uses a single PDU 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 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]. in the section 5.6.4 and 5.6.9 of [TS.23.501-3GPP].
skipping to change at page 21, line 20 skipping to change at page 22, line 45
or steered to application in the local DN by UPF. This refers the or steered to application in the local DN by UPF. This refers the
section 5.13 of [TS.23.501-3GPP]. section 5.13 of [TS.23.501-3GPP].
ARCH-Req-4: Supporting flexible UPF selection for PDU ARCH-Req-4: Supporting flexible UPF selection for PDU
The appropriate UPFs are selected for a PDU session based on The appropriate UPFs are selected for a PDU session based on
parameters and information such as UPF's dynamic load or UE location parameters and information such as UPF's dynamic load or UE location
information. Examples of parameters and information are described in information. Examples of parameters and information are described in
the section 6.3.3 of [TS.23.501-3GPP]. the section 6.3.3 of [TS.23.501-3GPP].
This means that its possible to make routing on user plane more This means that it is possible to make routing on user plane more
efficient in the 5GS. For example, in case that UPFs are distributed efficient in the 5GS. For example, in case that UPFs are distributed
geographically, decision of the destination UPF based on locations of geographically, decision of the destination UPF based on locations of
end hosts (e.g., UE or NF in DN) enables to forward PDUs with a route end hosts (e.g., UE or NF in DN) enables to forward PDUs with a route
connecting between UPFs nearby the hosts directly. connecting between UPFs nearby the hosts directly. This would be
useful UE-to-UE or UE-to-local_DN communication, and such usage is
described in the section 6.5 of [TS.22.261-3GPP].
The 5GS allows operators to select parameters used for UPF selection. The 5GS allows operators to select parameters used for UPF selection.
(In other words, any specific schems on UPF selection are not defined (In other words, any specific schemes on UPF selection are not
in the current 3GPP documents.) defined in the current 3GPP documents.)
ARCH-Req-5: No limitation for number of UPFs in a data path 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 The number of UPF in the data path is not constrained by 3GPP
specifications. This specification is described in the section 8.3.1 specifications. This specification is described in the section 8.3.1
of [TS.23.501-3GPP]. of [TS.23.501-3GPP].
Putting multiple UPFs, which provides specific function, in a data Putting multiple UPFs, which provides specific function, in a data
path enables flexible function deployment to make sure load path enables flexible function deployment to make sure load
distribution optimizations, etc. 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].
Meanwhile, each UPF in a data path shall be controlled by an SMF via Meanwhile, each UPF in a data path shall be controlled by an SMF via
N4 interface. Thus putting an excess of UPF for data paths might N4 interface. Thus putting an excess of UPF for data paths might
cause increase of load of an SMF. Pragmatically, the number of UPF cause increase of load of an SMF. Pragmatically, the number of UPF
put in a data path is one or two (e.g., for MEC or roaming cases), put in a data path is one or two (e.g., for MEC or roaming cases),
and, at most, it would be three (e.g., for case where UE moves during and, at most, it would be three (e.g., for case where UE moves during
a session). a session).
It is expected that multiple UPFs with per session tunnel handling 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 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 increasing number of UPFs.
several PDU sessions into a tunnel or shall be a session-less tunnel.
ARCH-Req-6: Supporting aggregation of multiple QoS Flow indicated ARCH-Req-6: Supporting aggregation of multiple QoS Flow indicated
with QFI into a PDU Session with QFI into a PDU Session
Against to the previous generation, 5G enables UPF to multiplex QoS Against to the previous generation, 5G enables UPF to multiplex QoS
Flows, equivalent with IP-CAN bearers in the previous generation, Flows, equivalent with IP-CAN bearers in the previous generation,
into one single PDU session. That means that a single tunnel into one single PDU session. That means that a single tunnel
includes multiple QFIs contrast to just one QoS Flow (a bearer) to includes multiple QFIs contrast to just one QoS Flow (a bearer) to
one tunnel before 5G. one tunnel before 5G.
In even the 5GS, each flow is forwarded based on the appropriate QoS In even the 5GS, each flow is forwarded based on the appropriate QoS
rules. QoS rules are configured by SMF as QoS profiles to UP rules. QoS rules are configured by SMF as QoS profiles to UP
compoents and these components perform QoS controls to PDUs based on components and these components perform QoS controls to PDUs based on
rules. In downlink, a UPF pushes QFI into an extension header, and rules. In downlink, a UPF pushes QFI into an extension header, and
transmits the PDU to RAN or another UPF. Then, such UPF may perform transmits the PDU to RAN or another UPF. Then, such UPF may perform
transport level QoS packet marking (e.g., DSCP marking in the outer transport level QoS packet marking (e.g., DSCP marking in the outer
header). In uplink, each UE obtains the QoS rule from SMF, and header). In uplink, each UE obtains the QoS rule from SMF, and
transmit PDUs with QFI containing the QoS rules to the RAN. The transmit PDUs with QFI containing the QoS rules to the RAN. The
following RAN and UPFs perform enforcement of QoS control and following RAN and UPFs perform enforcement of QoS control and
charging based on the QFI. charging based on the QFI.
This specification is described in 5.7.1 of [TS.23.501-3GPP]. This specification is described in 5.7.1 of [TS.23.501-3GPP].
skipping to change at page 22, line 33 skipping to change at page 24, line 4
transmits the PDU to RAN or another UPF. Then, such UPF may perform transmits the PDU to RAN or another UPF. Then, such UPF may perform
transport level QoS packet marking (e.g., DSCP marking in the outer transport level QoS packet marking (e.g., DSCP marking in the outer
header). In uplink, each UE obtains the QoS rule from SMF, and header). In uplink, each UE obtains the QoS rule from SMF, and
transmit PDUs with QFI containing the QoS rules to the RAN. The transmit PDUs with QFI containing the QoS rules to the RAN. The
following RAN and UPFs perform enforcement of QoS control and following RAN and UPFs perform enforcement of QoS control and
charging based on the QFI. charging based on the QFI.
This specification is described in 5.7.1 of [TS.23.501-3GPP]. This specification is described in 5.7.1 of [TS.23.501-3GPP].
ARCH-Req-7: Supporting network slicing ARCH-Req-7: Supporting network slicing
The 5GS fundamentally supports network slicing for provision the The 5GS fundamentally supports network slicing for provision the
appropriate end-to-end communication to various services. In the appropriate end-to-end communication to various services. In the
relevant documents (e.g., [TS.23.501-3GPP], [TS.28.531-3GPP]), a relevant documents (e.g., [TS.23.501-3GPP], [TS.28.530-3GPP]), a
network slice is defined as virtual network and it is structured with network slice is defined as virtual network and it is structured with
SMF, RANs, UPFs and DNs. Each network slice is independent and its 5GS NF instances, such as SMF, UPF including IP transport
user plane (including network functions and links) should be connectivity between RANs and DNS. Each network slice is independent
and its user plane (including network functions and links) should be
noninteractive against the others. noninteractive against the others.
Note that 3GPP focuses on only mobility management and specifications The 5G architecture specification has been updated with that Network
to synchronize with other networks including transport networks is Instance is defined as the glue of network slice between 5G slice and
not clearly defined. corresponding IP transport slice in addition to the original role of
separating IP domains, which is described in Section 4.1.2.
It has been appeared from version 15.2.0 of [TS.23.501-3GPP] in
section 5.6.12.
UP underlay transport networks and UPFs may be shared by 5G slices,
as described in section 4 of [TS.28.530-3GPP]. The data model
defined in [TS.29.510-3GPP] allows that a Network Instance, a UPF and
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 slice lifecycle managements is described in the relevant
documents: [TS.28.531-3GPP], [TS.28.532-3GPP], and [TS.28.533-3GPP].
ARCH-Req-8: End Marker support
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
the payload stream on a given UP tunnel. PDU packets arrive after an
End Marker message on the tunnel may be silently discarded. For
example, End Maker is used for handover procedures, and it can
prevent reordering of arriving packets due to switch of anchor UPFs.
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
skipping to change at page 23, line 36 skipping to change at page 25, line 32
types. And how much it makes simple the system than deploying types. And how much it makes simple the system than deploying
original PDU session types. original PDU session types.
5.2. Nature of Data Path 5.2. Nature of Data Path
As it is described in Section 4.2, the single PDU session multi- As it is described in Section 4.2, the single PDU session multi-
homing case requires multipoint-to-point (MP2P) data path. It should homing case requires multipoint-to-point (MP2P) data path. It should
be much scalable than multi-homing with multiple PDU sessions because be much scalable than multi-homing with multiple PDU sessions because
number of required path states in the UPFs are reduced as closed to number of required path states in the UPFs are reduced as closed to
egress endpoint. Against that point-to-point (P2P) protocol requires egress endpoint. Against that point-to-point (P2P) protocol requires
same number of states in each UPF throughout the path. same number of states in each UPF throughout the path, and it could
increase explosively the load on management of tunnel states.
From this point of view, the expected evaluation points from this From this point of view, the expected evaluation points from this
aspect is whether the nature of candidate UP protocols are to utilize aspect is whether the nature of candidate UP protocols are to utilize
MP2P data path. Supporting MP2P data path by GTP-U could be a gap MP2P data path. Supporting MP2P data path by GTP-U could be a gap
since GTP-U is a point-to-point tunneling protocol as it is described since GTP-U is a point-to-point tunneling protocol as it is described
in Section 3. in Section 3.
Noted that 3GPP CT WG4 pointed out GTP-U was already required to Noted that 3GPP CT WG4 pointed out GTP-U was already required to
allow one single tunnel endpoint to receive packets from multiple allow one single tunnel endpoint to receive packets from multiple
source endpoints ([C4-185491-3GPP]). It was an architectural source endpoints ([C4-185491-3GPP]). It was an architectural
skipping to change at page 25, line 5 skipping to change at page 26, line 47
increasing. increasing.
5.4. Data Path Management 5.4. Data Path Management
As Section 4.2 described, the 5G systems allows user plane that As Section 4.2 described, the 5G systems allows user plane that
flexible UPF selection, multiple anchor UPFs, and no limit on how flexible UPF selection, multiple anchor UPFs, and no limit on how
many UPFs chained for the data path of the PDU session. UPF many UPFs chained for the data path of the PDU session. UPF
deployments in the field will thereby be distributed to be able to deployments in the field will thereby be distributed to be able to
optimize the data path based on various logics and service scenarios. optimize the data path based on various logics and service scenarios.
That powerful user plane capability could affect data path management That powerful user plane capability could make data path management
complicated and difficult to be managed through the control plane, or through the control plane, or operation support systems (OSS) be
operation support systems (OSS). Perhaps it could be the case where complicated and difficult. Perhaps it could be the case where the UP
the UP protocol nature is P2P and it only supports per session base protocol nature is P2P and it only supports per session base data
data path handling. path handling. Therefore it would be better that UP protocol could
support to aggregate several PDU sessions into a tunnel or shall be a
session-less tunnel.
Because it increases data path states by number of sessions, and Because it increases data path states by number of sessions, and
number of endpoints of UPFs that makes data path handling much hectic number of endpoints of UPFs that makes data path handling much hectic
and the control plane tend to be overloaded by not only usual and the control plane tend to be overloaded by not only usual
attach/detach/hand-over operations, but also existing session attach/detach/hand-over operations, but also existing session
manipulation triggered by UPF and transport nodes/paths restoration, manipulation triggered by UPF and transport nodes/paths restoration,
etc., etc.,
The expected evaluation points from this aspect should be that how The expected evaluation points from this aspect should be that how
much the candidate protocols can reduce data path management loads much the candidate protocols can reduce data path management loads
skipping to change at page 26, line 25 skipping to change at page 28, line 19
abstracts the detected flow into the packets. It enables following abstracts the detected flow into the packets. It enables following
UPFs just find the ID to detect the indicated flow from the packet. UPFs just find the ID to detect the indicated flow from the packet.
The expected evaluation points from this aspect should be whether the The expected evaluation points from this aspect should be whether the
candidate protocols can provide means to reduce that redundant flow candidate protocols can provide means to reduce that redundant flow
detection that could be enough bits space on stable ID space to put detection that could be enough bits space on stable ID space to put
abstracted detected flow identifier. abstracted detected flow identifier.
5.7. Supporting Network Slicing Diversity 5.7. Supporting Network Slicing Diversity
To embody network slicing, it is expected that various means should Network Instance has been defined as the glue of network slice
be available in case by case, or operator by operator, for their 5G between 5G and IP transport in addition to IP domain separation, as
systems while it follows the fundamental slicing concept, as described in Section 4.1.2. It is expected that SMF is able to
described in Section 4.1. configure UPF to send UP packet to corresponding transport slice by
indicating Network Instance in FAR so that UPF can determine outgoing
interface for the UP packet.
As [TS.28.530-3GPP] described in section 4, UP underlay transport It is assumed that IP transport networks are Network Instance
networks and UPFs are shared by network slices. The data model agnostic, i.e., transport slices are independently instantiated and
defined in [TS.29.510-3GPP] allows that a Network Instance, a UPF and not bound to specific IP address space in the 5GC, for preventing
its interfaces can belong to multiple slices as same as other type of increase of routing table size.
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 As a transport slice may be shared with multiple IP domains, Network
to each other through direct (virtual) link as Section 4.1 describes Instance could be instantiated for all combination of IP domains and
that UPFs compose a network slice on an UP. So IP routing and transport slice. To indicate those combination in UP packet over the
transport system underneath the UP are not visible from the 5G wire, the 5G architecture expects VPN solutions as described in
system. However some means need to indicate a slice on the shared section 5.6.12 of [TS.23.501-3GPP].
underlying networks of the UP over the wire.
That's just one way for network slicing, but it would help to reduce Binding Network Instance with corresponding VPN would be varied per
the operational burden. Even it depends on each operator's policy, VPN solutions and FAR is not able to do. Hence it is out of scope of
sharing network instances, UPFs, and the interfaces among slices 3GPP and it may be covered by IETF, or other SDOs.
makes operators relax and not to be much hustled on slice lifecycle
management., such as create, update, and delete operations for
slices.
By the way, the 3GPP specifications for slice lifecycle managements Apart from binding, if it is the case where MPLS based VPNs, such as
is described in the relevant documents: [TS.28.531-3GPP], [RFC4364] and [RFC4664] are expected as the existing VPN solution
[TS.28.532-3GPP], and [TS.28.533-3GPP]. which bound to Network Instance, there are some avaiable deployment
options, such as 1). PE router integrates UPF, 2). CE router
integrates UPF, 3). UPF connects to the VPN behind the CE router.
It could also make sense in case that each network slice requires Option 1 could work since all legacy MPLS or Segment Routing
different forwarding policies in the middle of the path. Some [RFC8402] based solution are available for both VPN and transport
identifier in the packets for a slice could be a glue between UP path slicing at the UPF integrated PE router. However it is hard to
and its underlying transport networks. For example, if a slice expect it in multi-vendor deployment case, where the PE routers
requires certain level of latency with dedicated route, traffic providing vendor is different from the vendor who provides UPFs, for
engineering (TE) embodies appropriate forwarding policy through the example.
underlay transport network.
Option 2 and 3 are expected as IP domain separation, but it is hard
to see that it is able to indicate transport slice in addition to the
IP domain. Other L2 and tunneling solutions should be same with
those options.
The expected evaluation points from this aspect should be whether the The expected evaluation points from this aspect should be whether the
candidate protocols can support to indicate a network slice in the UP candidate protocols can contain forwarding information associated to
packets that could be enough bits space on stable ID space to put the assigned IP domain and transport slice for all possible
slice identifier for the slice, or the forwarding policy within the deployment cases.
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 6. Conclusion
We analyzed the 3GPP specifications of the 5G architecture in terms We analyzed the 3GPP specifications of the 5G architecture in terms
of user plane and the current protocol adopted to the user plane. of user plane and the current protocol adopted to the user plane.
After the analysis work, we believe that the results described in After the analysis work, we believe that the results described in
this document shows that we reach at certain level of understanding this document shows that we reach at certain level of understanding
on the 5G systems and ready to provide our inputs to 3GPP. on the 5G systems and ready to provide our inputs to 3GPP.
We clarified GTP-U through the analysis and listed observed We clarified GTP-U through the analysis and listed observed
characteristics in Section 3.6. We also clarified the architectural characteristics in Section 3.6. We also clarified the architectural
requirements for UP protocol described in Section 4.2. requirements for UP protocol described in Section 4.2.
As we identified some potential gaps between the current UP protocol Our conclusion here is that it is hopefull if the evaluation aspects
and the architectural requirements even for Release 15, it is worth described in Section 5 help for the study progress. It is worth to
to study possible candidate UP protocols for the 5G system including study possible candidate UP protocols for the 5G system including
current one. Our conclusion here is that we suggest the UP protocol current one based from the aspects.
study work in 3GPP takes into account the evaluation aspects
described in Section 5.
7. Security Consideration 7. Security Consideration
TBD TBD
8. Acknowledgement 8. Acknowledgement
The authors would like to thank Tom Herbert, Takashi Ito, John Leddy, The authors would like to thank Tom Herbert, Takashi Ito, John Leddy,
Pablo Camarillo, Daisuke Yokota, Satoshi Watanabe, Koji Tsubouchi and Pablo Camarillo, Daisuke Yokota, Satoshi Watanabe, Koji Tsubouchi and
Miya Kohno for their detailed reviews, comments, and contributions. Miya Kohno for their detailed reviews, comments, and contributions.
skipping to change at page 28, line 37 skipping to change at page 30, line 23
on User Plane Protocol in 5GC", December 2017, on User Plane Protocol in 5GC", December 2017,
<http://www.3gpp.org/ftp/tsg_ct/TSG_CT/TSGC_78_Lisbon/ <http://www.3gpp.org/ftp/tsg_ct/TSG_CT/TSGC_78_Lisbon/
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>.
[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] [IAB-Statement]
Internet Architecture Board (IAB), "IAB Statement on Internet Architecture Board (IAB), "IAB Statement on
IPv6", November 2016, IPv6", November 2016, <https://www.iab.org/2016/11/07/iab-
<https://www.iab.org/2016/11/07/iab-statement-on-ipv6/>. statement-on-ipv6/>.
[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
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
2 Virtual Private Networks (L2VPNs)", RFC 4664,
DOI 10.17487/RFC4664, September 2006, <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, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc4861>. 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, DOI 10.17487/RFC6437, November 2011, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6437>. 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, DOI 10.17487/RFC6935, April 2013, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6935>. editor.org/info/rfc6935>.
[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, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc8200>. editor.org/info/rfc8200>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/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-15/29_series/29891-f00.zip>. Rel-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.4.0): Service requirements for 5G system stage 1", (V15.7.0): Service requirements for 5G system stage 1",
March 2018, <http://www.3gpp.org/FTP/Specs/2018-03/ December 2018, <http://www.3gpp.org/FTP/Specs/2018-03/
Rel-15/22_series/22261-f40.zip>. Rel-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
(V15.3.0): System Architecture for 5G System; Stage 2", (V15.4.0): System Architecture for 5G System; Stage 2",
September 2018, <http://www.3gpp.org/ftp//Specs/ December 2018, <http://www.3gpp.org/ftp//Specs/
archive/23_series/23.501/23501-f30.zip>. archive/23_series/23.501/23501-f40.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.1.0): Procedures for 5G System; Stage 2", March 2018, (V15.4.0): Procedures for 5G System; Stage 2", December
<http://www.3gpp.org/FTP/Specs/2018-03/ 2018, <http://www.3gpp.org/FTP/Specs/2018-03/
Rel-15/23_series/23502-f10.zip>. Rel-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.1.0): Policy and Charging Control System for 5G (V15.4.0): Policy and Charging Control System for 5G
Framework; Stage 2", March 2018, <http://www.3gpp.org/FTP/ Framework; Stage 2", December 2018,
Specs/2018-03/Rel-15/23_series/23503-f10.zip>. <http://www.3gpp.org/FTP/Specs/2018-03/
Rel-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
(V1.0.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)", June 2018, (work in progress)", December 2018,
<http://ftp.3gpp.org//Specs/ <http://ftp.3gpp.org//Specs/
archive/28_series/28.530/28530-100.zip>. archive/28_series/28.530/28530-f10.zip>.
[TS.28.531-3GPP] [TS.28.531-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 28.531 3rd Generation Partnership Project (3GPP), "3GPP TS 28.531
(V1.0.0): Management and orchestration of networks and (V15.1.0): Management and orchestration of networks and
network slicing; Provisioning; Stage 1 (Release 15)", June network slicing; Provisioning; Stage 1 (Release 15)",
2018, <http://ftp.3gpp.org//Specs/ December 2018, <http://ftp.3gpp.org//Specs/
archive/28_series/28.531/28531-100.zip>. archive/28_series/28.531/28531-f10.zip>.
[TS.28.532-3GPP] [TS.28.532-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 28.532 3rd Generation Partnership Project (3GPP), "3GPP TS 28.532
(V0.3.0): Management and orchestration of networks and (V15.1.0): Management and orchestration of networks and
network slicing; Provisioning; Stage 2 and stage 3 network slicing; Provisioning; Stage 2 and stage 3
(Release 15)", June 2018, <http://www.3gpp.org/ftp//Specs/ (Release 15)", Decempber 2018,
archive/28_series/28.532/28532-030.zip>. <http://www.3gpp.org/ftp//Specs/
archive/28_series/28.532/28532-f10.zip>.
[TS.28.533-3GPP] [TS.28.533-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 28.533 3rd Generation Partnership Project (3GPP), "3GPP TS 28.533
(V0.3.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)", June 2018, <http://www.3gpp.org/ftp//Specs/ (Release 15)", December 2018,
archive/28_series/28.533/28533-030.zip>. <http://www.3gpp.org/ftp//Specs/
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", March 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-15/29_series/29244-f10.zip>. Rel-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.4.0): GPRS Tunneling Protocol User Plane (GTPv1-U)", (V15.5.0): GPRS Tunneling Protocol User Plane (GTPv1-U)",
September 2018, <http://www.3gpp.org/ftp//Specs/ December 2018, <http://www.3gpp.org/ftp//Specs/
archive/29_series/29.281/29281-f40.zip>. archive/29_series/29.281/29281-f50.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.0.0): 5G System; Network Function Repository (V15.2.0): 5G System; Network Function Repository
Services; Stage 3", June 2018, <http://www.3gpp.org/FTP/ Services; Stage 3", December 2018,
Specs/2018-06/Rel-15/29_series/29510-f00.zip>. <http://www.3gpp.org/FTP/Specs/2018-06/
Rel-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.0.0): 5G System; Interworking between 5G Network and (V15.1.0): 5G System; Interworking between 5G Network and
external Data Networks; Stage 3", June 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-15/29_series/29561-f00.zip>. Rel-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.1.0): NR and NG-RAN Overall Description; Stage 2", (v15.4.0): NR and NG-RAN Overall Description; Stage 2",
March 2018, <http://www.3gpp.org/FTP/Specs/2018-03/ December 2018, <http://www.3gpp.org/FTP/Specs/2018-03/
Rel-15/38_series/38300-f10.zip>. Rel-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.1.0): NG-RAN; Architecture Description", March 2018, (v15.4.0): NG-RAN; Architecture Description", December
<http://www.3gpp.org/FTP/Specs/2018-03/ 2018, <http://www.3gpp.org/FTP/Specs/2018-03/
Rel-15/38_series/38401-f10.zip>. Rel-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.1.0): NG-RAN; PDU Session User Plane protocol", (v15.2.0): NG-RAN; PDU Session User Plane protocol",
September 2018, <http://www.3gpp.org/ftp//Specs/ December 2018, <http://www.3gpp.org/ftp//Specs/
archive/38_series/38.415/38415-f10.zip>. archive/38_series/38.415/38415-f20.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. 81 change blocks. 
195 lines changed or deleted 306 lines changed or added

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