draft-ietf-dmm-5g-uplane-analysis-01.txt   draft-ietf-dmm-5g-uplane-analysis-02.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: September 12, 2019 KDDI Research Expires: January 9, 2020 KDDI Research
S. Matsushima S. Matsushima
SoftBank SoftBank
D. Voyer D. Voyer
Bell Canada Bell Canada
March 11, 2019 July 8, 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-01 draft-ietf-dmm-5g-uplane-analysis-02
Abstract Abstract
This document analyzes the mobile user plane protocol and the This document analyzes the mobile user plane protocol and the
architecture specified in 3GPP 5G documents. The analysis work is to architecture specified in 3GPP 5G documents. The analysis work is to
clarify those specifications, extract protocol and architectural clarify those specifications, extract protocol and architectural
requirements and derive evaluation aspects for user plane protocols requirements and derive evaluation aspects for user plane protocols
on IETF side. This work is corresponding to the User Plane Protocol on IETF side. This work is corresponding to the User Plane Protocol
Study work on 3GPP side. Study work on 3GPP side.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on January 9, 2020.
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
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Current Status of Mobile User Plane for 5G . . . . . . . 3 1.1. Current Status of Mobile User Plane for 5G . . . . . . . 3
1.2. Our Way of Analysis Work . . . . . . . . . . . . . . . . 3 1.2. Our Way of Analysis Work . . . . . . . . . . . . . . . . 4
2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4
3. GTP-U Specification and Observation . . . . . . . . . . . . . 6 3. GTP-U Specification and Observation . . . . . . . . . . . . . 6
3.1. GTP-U Tunnel . . . . . . . . . . . . . . . . . . . . . . 6 3.1. GTP-U Tunnel . . . . . . . . . . . . . . . . . . . . . . 6
3.2. GTP-U Header Format . . . . . . . . . . . . . . . . . . . 10 3.2. GTP-U Header Format . . . . . . . . . . . . . . . . . . . 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.1.2. UP Traffic Detection . . . . . . . . . . . . . . . . 18 4.1.2. UP Traffic Detection . . . . . . . . . . . . . . . . 19
4.2. Architectural Requirements for User Plane Protocols . 20 4.1.3. User Plane Configuration . . . . . . . . . . . . . . 21
5. Evaluation Aspects . . . . . . . . . . . . . . . . . . . . . 24 4.2. Architectural Requirements for User Plane Protocols . 22
5.1. Supporting PDU Session Type Variations . . . . . . . . . 25 5. Evaluation Aspects . . . . . . . . . . . . . . . . . . . . . 28
5.2. Nature of Data Path . . . . . . . . . . . . . . . . . . . 25 5.1. Supporting PDU Session Type Variations . . . . . . . . . 29
5.3. Supporting Transport Variations . . . . . . . . . . . . . 25 5.2. Nature of Data Path . . . . . . . . . . . . . . . . . . . 29
5.4. Data Path Management . . . . . . . . . . . . . . . . . . 26 5.3. Supporting Transport Variations . . . . . . . . . . . . . 30
5.5. QoS Control . . . . . . . . . . . . . . . . . . . . . . . 27 5.4. Data Path Management . . . . . . . . . . . . . . . . . . 30
5.6. Traffic Detection and Flow Handling . . . . . . . . . . . 27 5.5. QoS Control . . . . . . . . . . . . . . . . . . . . . . . 31
5.7. Supporting Network Slicing Diversity . . . . . . . . . . 28 5.6. Traffic Detection and Flow Handling . . . . . . . . . . . 32
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.7. Supporting Network Slicing Diversity . . . . . . . . . . 32
7. Security Consideration . . . . . . . . . . . . . . . . . . . 29 5.8. Reliable Communication support . . . . . . . . . . . . . 33
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 29 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 33
9. Informative References . . . . . . . . . . . . . . . . . . . 29 7. Security Consideration . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 34
9. Informative References . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
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 17, line 16 skipping to change at page 17, line 16
separated from the Control Plane (CP) functions for allowing separated from the Control Plane (CP) functions for allowing
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 3GPP 5G architecture [TS.23.501-3GPP] defines slice types which
are eMBB, URLLC and MIoT from Rel-15. In addition to that, V2X slice
type is defined from Rel-16.
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]. A UPF handles UP paths functions are described in [TS.23.501-3GPP]. A UPF handles UP paths
on N3, N9 and N6 interface, and the setup is controlled by SMF via N4 on N3, N9 and N6 interface, and the setup is controlled by SMF via N4
interface. A UP path will be manipulated based on application interface. A UP path will be manipulated based on application
requirements for the PDU session corresponding to the path. An SMF requirements for the PDU session corresponding to the path. An SMF
is also capable to receive information regarding routing path with is also capable to receive information regarding routing path with
API from AF via NEF, PCF, and SMF. API from AF via NEF, PCF, and SMF.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|NSSF | | NEF | | NRF | | PCF | | UDM | | AF | |NSSF | | NEF | | NRF | | PCF | | UDM | | AF |
skipping to change at page 18, line 48 skipping to change at page 19, line 28
o Downlink packet buffering and downlink data notification o Downlink packet buffering and downlink data notification
triggering. triggering.
o Sending and forwarding of one or more "end marker" to the source o Sending and forwarding of one or more "end marker" to the source
NG-RAN node. NG-RAN node.
o ARP proxying and / or IPv6 Neighbour Solicitation Proxying for the o ARP proxying and / or IPv6 Neighbour Solicitation Proxying for the
Ethernet PDUs. Ethernet PDUs.
o Packet duplication in downlink direction and elimination in uplink
direction in UP protocol layer.
o TSN Translator functionality to hold and forward user plane
packets for de-jittering when 5G System is integrated as a bridge
with the TSN network.
4.1.2. UP Traffic Detection 4.1.2. UP Traffic Detection
The traffic detection is described in the section 5.8.2.4 of 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 [TS.23.501-3GPP]. In 3GPP UP packet forwarding model, UPF detects UP
traffic flow which belong to a N4 session configured by SMF. traffic flow which belong to a N4 session configured by SMF.
The protocol of N4 interface, PFCP, brings a set of traffic detection The protocol of N4 interface, PFCP, brings a set of traffic detection
information from SMF to UPF as Packet Detection Information (PDI) in information from SMF to UPF as Packet Detection Information (PDI) in
a PDR to establish/modify the N4 PFCP session. It is defined in a PDR to establish/modify the N4 PFCP session. It is defined in
section 7.5.2.2 of [TS.29.244-3GPP]. section 7.5.2.2 of [TS.29.244-3GPP].
skipping to change at page 20, line 33 skipping to change at page 21, line 20
fields as defined in IEEE 802.1Q fields as defined in IEEE 802.1Q
* Customer-VLAN tag(C-TAG) and/or Service-VLAN tag(S-TAG) PCP/DEI * Customer-VLAN tag(C-TAG) and/or Service-VLAN tag(S-TAG) PCP/DEI
fields as defined in IEEE 802.1Q fields as defined in IEEE 802.1Q
* IP Packet Filter Set, in case Ethertype indicates IPv4/IPv6 * IP Packet Filter Set, in case Ethertype indicates IPv4/IPv6
payload payload
* Packet filter direction * Packet filter direction
4.1.3. User Plane Configuration
User Plane configuration on a UPF is managed by an SMF through PFCP
[TS.29.244-3GPP]. The SMF establishes PFCP sessions on the UPF per
PDU session basis. The UPF maintains each configured PFCP session
states during the sessions exist.
A PFCP session consists of the rules of packet detection, forwarding
action, QoS enforcement, usage reporting and buffering action.
Figure 6 depicts overview of the PFCP session state structure.
The listed information in Section 4.1.2 indicates packet detection
information of packet detection rule for that the rest of related
rules within the PFCP session to be derived. All rules are per
session unique and no rules are shared with other sessions.
PFCP-Session* [F-SEID]
+- F-SEID(Full Qualified Session Endpoint ID) uint64
+- PDU-Session-Type [IPv4|IPv6|IPv4v6|Ether|Unstrct]
+- DNN(Data Network Name)
+- PDR(Packet Detection Rule)* [PDR-ID]
| +- PDR-ID uint16
| +- PDI (Packet Detection Information)
| | +- Traffic-Endpoint-ID? -> Traffic-Endpoint-ID reference
| | +- ....
| +- FAR/URR/QER-ID -> FAR/URR/QER-ID references
+- FAR(Forwarding Action Rule)* [FAR-ID]
| +- FAR-ID uint32
| +- Forwarding-Parameters
| | +- Network-Instance? Octet String
| | +- Outer-Header-Creation
| | | +- Outer-Hdr-Creation-Desc [GTPoUDP/IPv4|IPv6, etc.,]
| | | +- TEID, outer IP-Address for N3/N9
| | | +- C/S-TAG, UDP Port-number for N6
| | +- Forwarding-Policy-ID? Octet String
| | +- ....
| +- Duplicating-Parameters
| | +- ....
| +- BAR-ID? -> BAR-ID reference
+- QER(QoS Enforcement Rule)* [QER-ID]
| +- QER-ID uint32
| +- MBR(Maximum Bit Rate)
| | +- UL/DL-MBR? bitrate_in_kbps (0..10000000)
| +- GBR(Guaranteed Bit Rate)
| | +- UL/DL-GBR? bitrate_in_kbps (0..10000000)
| +- QoS-flow-identifier? QFI value(6-bits)
| +- Reflective-QoS? boolean
| +- Paging-Policy-Indicator? PPI value(3-bits)
| +- ....
+- URR(Usage Reporting Rule)* [URR-ID]
| +- URR-ID uint32
| +- Measurement-Method, Period, Reporting-Triggers?
| +- Volume/Event/Time Threshold, Quota?
| +- Quota-Holding-Time?
| +- FAR-ID for Quota action? -> FAR-ID reference
| +- ....
+- BAR(Buffering Action Rule)* [BAR-ID]
| +- BAR-ID uint8
| +- Suggested-Buffering-Packets-Count
+- Traffic-Endpoint* [Traffic-Endpoint-ID]
+- Traffic-Endpoint-ID uint8
+- TEID, Tunnle IP Address, UE Address...?
Figure 6: User Plane Configuration Model
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
assumptions that the UP protocol is a tunnel representing a single assumptions that the UP protocol is a tunnel representing a single
skipping to change at page 21, line 40 skipping to change at page 23, line 45
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). BP provides Multihoming is provided with Branching Point (BP). 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. IPv6 multihoming only means multiple source IPv6 prefixes are used
for a PDU session. It is identical to one classified as scenario 1
in [RFC7157].
Noted that, in 3GPP definition, IPv6 multihoming indicates only cases Up link classifier (UL CL) is to forward uplink packets to multiple
where "multiple" source IPv6 prefixes are used, and it is different anchor UPFs based on the destination IP of the T-PDU regardless of
from IETF definition. Actually, in the 5GS, Up link classifier (UL the source IP address. Noted that single source IP address/prefix
CL) is capable to provide forwarding to multiple anchor for a PDU PDU session is not defined as multihoming PDU session in 5GCS even
session with a single source IPv6 prefix, but it is distinguished though a PDU session has multiple anchor UPFs.
from IPv6 multihoming.
On UL side, multihoming of a single PDU session is achieved by a On UL side, P2P tunnels are established per destination anchor UPFs
point-to-point (P2P) tunnel per anchor UPF. It means that multiple basis from one UL CL UPF to the anchor UPFs for the PDU session.
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 On DL side, one single multipoint-to-point (MP2P) tunnel exists from
the anchor UPFs to the destination gNB or UPF for the PDU session in the source anchor UPFs to the destination BP UPF for the PDU session.
this multihoming case. It means that the paths from the anchor UPFs It means that the paths from the anchor UPFs are merged into just one
are merged into just one tunnel state at the source gNB or UPF for tunnel state at the destination BP UPF.
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. It the one PDU session to one UP tunnel architectural principle. It
causes increase of load on tunnel states management in UPF due to causes increase of load on tunnel states management in UPF due to
increment of the anchor UPF for the PDU session. 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.
skipping to change at page 24, line 41 skipping to change at page 26, line 46
ARCH-Req-8: End Marker support ARCH-Req-8: End Marker support
The construction of End Marker packets specified in [TS.23.501-3GPP] The construction of End Marker packets specified in [TS.23.501-3GPP]
may either be done in the CP/UP functions for indicating the end of may either be done in the CP/UP functions for indicating the end of
the payload stream on a given UP tunnel. PDU packets arrive after an the payload stream on a given UP tunnel. PDU packets arrive after an
End Marker message on the tunnel may be silently discarded. For End Marker message on the tunnel may be silently discarded. For
example, End Maker is used for handover procedures, and it can example, End Maker is used for handover procedures, and it can
prevent reordering of arriving packets due to switch of anchor UPFs. prevent reordering of arriving packets due to switch of anchor UPFs.
ARCHI-Req-9: Supporting URLLC
The 5G is expected to support services which are latency sensitive
and require high reliability. Communication to realize such services
is called Ultra-Reliable and Low-Latency Communication or URLLC. In
URLLC, redundancy of QoS flows is required for providing highly
reliable communication. For instance, a set of UP NFs (e.g., UPF or
gNB) and interfaces between UE and DN are redundant, and packets are
replicated and forwarded via each route. UEs and DN support dual
connectivity and drop duplicated received packets. The scheme of
packet dropping at UE is out of responsibility of 3GPP. The overview
is shown in Figure 7.
---+-----------+----------+---
Namf| Nsmf| Nsmf|
+--+--+ +--+--+ +--+--+
| AMF | | SMF1| | SMF3|
+-+---+ +--+--+ +-+---+
/ / /
N2/ N4/ N4/
/ / /
+----++ N3 +--+---+ / N6 +----+
|M-RAN+--------+ UPF1 +--------------+ |
++-+--+ +-+--+-+ / | |
/ | | | / | |
+----+ / | +--+ / | |
| UE +< |Xn N9 / | DN |
+----+ \ | / | |
\ | / | |
++-+--+ N3 +----+-+ N6 | |
|S-RAN+--------+ UPF2 +--------------+ |
+-----+ +-+--+-+ +----+
| |
+--+
N9
*Legends
M-RAN: Master RAN
S-RAN: Secondary RAN
Figure 7: Redundant UP paths using dual connectivity
Otherwise, in case that RAN nodes and UPFs have enough reliability
and they are not redundant by dual devices, reliable connectivity of
QoS flows is provided by dual N3 tunnels between RAN and UPFs. Such
tunnels are treated as individual ones, but they have the same
sequence number. UP NFs identifies the duplication of PDU packets
based on sequence number content in the UP tunnel headers. For
uplink packets, a RAN node replicates each packet from a UE. An
anchor UPF receives the duplicated packets, and drops ones which
reach later in each duplicated packet pare. On the other hand, for
downlink packets, a UPF replicates packets received from DN, and a
RAN node drops the duplicated packets as well. The overviews of the
ways are shown in Figure 8.
----+-----------+-----------+---
Namf| Nsmf| Npcf|
+--+--+ +--+--+ +--+--+
| AMF | | SMF | | PCF |
+-+---+ +--+--+ +-----+
/ |
N2/ N4|
/ N3 Tunnel1 |
+----+ +--+--+__________+--+--+ N6 +----+
| UE +----+ RAN |__________| UPF |-----+ DN |
+----+ +-----+ +-----+ +----+
N3 Tunnel2
Figure 8: Redundant UP transmission with two N3 tunnels
In addition, there is a case that two intermediate UPFs (I-UPFs)
between anchor UPF and RAN are used to support the redundant
transmission based on two N3 and N9 tunnels between single anchor UPF
and RAN node. The RAN node and anchor UPF support the packet
replication and dropping of duplicated packets as described above.
As described above, anchor UPF and RAN node detect packet duplication
with sequence number of UP tunnels, and thus I-UPFs would forward the
packets with the same sequence number on N3 and N9 tunnels. The
overview is shown in Figure 9.
----+-------------+--------------+---
Namf| Nsmf| Npcf|
+--+--+ +---+---+ +--+--+
| AMF | | SMF + | PCF |
+--+--+ +-+-+-+-+ +-----+
/ | | |
N2 / N4| | +----------------+
/ | | |
/ N3 Tunnel1 +-+-+---+ N9 Tunnel1 |
/ +-----+I-UPF1 +----+ |
+----+ +--+--+______| +-------+ |______+--+--+ N6 +----+
| UE +---+ RAN |______ | ______| UPF +-----+ DN |
+----+ +-----+ N3 | +---+---+ | N9 +-----+ +----+
+-----+I-UPF2 +----+
N3 Tunnel2 +-------+ N9 Tunnel2
Figure 9: Redundant UP transmission with two I-UPF and N3/N9 tunnels
5. Evaluation Aspects 5. Evaluation Aspects
This section provides UP protocol evaluation aspects that are mainly This section provides UP protocol evaluation aspects that are mainly
we derived from the architectural requirements described in we derived from the architectural requirements described in
Section 4. Those aspects are not prioritized by the order here. Section 4. Those aspects are not prioritized by the order here.
Expected deployment scenarios explain the evaluations purpose in the Expected deployment scenarios explain the evaluations purpose in the
corresponding aspects. corresponding aspects.
As we were noticed that the gaps between GTP-U specifications and 5G As we were noticed that the gaps between GTP-U specifications and 5G
architectural requirements through the analysis, those each gap are architectural requirements through the analysis, those each gap are
briefly described in the evaluation aspect associated to it. briefly described in the evaluation aspect associated to it.
Since it is obvious that 5G system should be able to interwork with Since it is obvious that 5G system should be able to interwork with
existing previous generation based systems, any aspects from existing previous generation based systems, any aspects from
coexisting and interworking point of view are not particularly coexisting and interworking point of view are not particularly
skipping to change at page 29, line 15 skipping to change at page 33, line 22
Option 2 and 3 are expected as IP domain separation, but it is hard 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 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 IP domain. Other L2 and tunneling solutions should be same with
those options. 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 contain forwarding information associated to candidate protocols can contain forwarding information associated to
the assigned IP domain and transport slice for all possible the assigned IP domain and transport slice for all possible
deployment cases. deployment cases.
5.8. Reliable Communication support
As Section 4.2 described, more than two UP paths are required for a
QoS flow of a PDU session between the anchor UPF and gNB. Those UP
paths are to convey redundant duplicated packets.
To support reliable communication with above requirements, UPF and
gNB must replicate the sending UP packets and eliminate the received
duplicated UP packets. Not to mention that UP protocol should be
able to make sure that the paths are not in fate sharing, the UP
packet must have sequence number to indicate duplicate packets per
QoS flow basis.
The expected evaluation points from this aspect should be whether the
candidate protocols can indicate packet sequence and diversed paths
in the context of QoS flow, not in UP tunnel context. The packet
sequence information should be transparent through I-UPF(s) exist in
the middle of the path even in case that the UP tunnels are
terminated at the I-UPF(s).
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
skipping to change at page 30, line 25 skipping to change at page 34, line 48
Docs/CP-173160.zip>. Docs/CP-173160.zip>.
[CP-180116-3GPP] [CP-180116-3GPP]
3rd Generation Partnership Project (3GPP), "LS on user 3rd Generation Partnership Project (3GPP), "LS on user
plane protocol study", March 2018, plane protocol study", March 2018,
<http://www.3gpp.org/ftp/tsg_ct/TSG_CT/TSGC_79_Chennai/ <http://www.3gpp.org/ftp/tsg_ct/TSG_CT/TSGC_79_Chennai/
Docs/CP-180116.zip>. Docs/CP-180116.zip>.
[IAB-Statement] [IAB-Statement]
Internet Architecture Board (IAB), "IAB Statement on Internet Architecture Board (IAB), "IAB Statement on
IPv6", November 2016, <https://www.iab.org/2016/11/07/iab- IPv6", November 2016,
statement-on-ipv6/>. <https://www.iab.org/2016/11/07/iab-statement-on-ipv6/>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
2 Virtual Private Networks (L2VPNs)", RFC 4664, 2 Virtual Private Networks (L2VPNs)", RFC 4664,
DOI 10.17487/RFC4664, September 2006, <https://www.rfc- DOI 10.17487/RFC4664, September 2006,
editor.org/info/rfc4664>. <https://www.rfc-editor.org/info/rfc4664>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, <https://www.rfc- DOI 10.17487/RFC4861, September 2007,
editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437, "IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011, <https://www.rfc- DOI 10.17487/RFC6437, November 2011,
editor.org/info/rfc6437>. <https://www.rfc-editor.org/info/rfc6437>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>. <https://www.rfc-editor.org/info/rfc6438>.
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", RFC 6935, UDP Checksums for Tunneled Packets", RFC 6935,
DOI 10.17487/RFC6935, April 2013, <https://www.rfc- DOI 10.17487/RFC6935, April 2013,
editor.org/info/rfc6935>. <https://www.rfc-editor.org/info/rfc6935>.
[RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T.,
and D. Wing, "IPv6 Multihoming without Network Address
Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014,
<https://www.rfc-editor.org/info/rfc7157>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, <https://www.rfc- DOI 10.17487/RFC8200, July 2017,
editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[TR.29.891-3GPP] [TR.29.891-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TR 29.891 3rd Generation Partnership Project (3GPP), "3GPP TR 29.891
(V15.0.0): 5G System Phase 1, CT WG4 Aspects", December (V15.0.0): 5G System Phase 1, CT WG4 Aspects", December
2017, <http://www.3gpp.org/FTP/Specs/2017-12/ 2017, <http://www.3gpp.org/FTP/Specs/2017-12/
skipping to change at page 31, line 46 skipping to change at page 36, line 26
[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.4.0): System Architecture for 5G System; Stage 2", (V16.1.0): System Architecture for 5G System; Stage 2",
December 2018, <http://www.3gpp.org/ftp//Specs/ June 2019, <http://www.3gpp.org/ftp//Specs/
archive/23_series/23.501/23501-f40.zip>. archive/23_series/23.501/23501-g10.zip>.
[TS.23.502-3GPP] [TS.23.502-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 23.502 3rd Generation Partnership Project (3GPP), "3GPP TS 23.502
(V15.4.0): Procedures for 5G System; Stage 2", December (V15.4.0): Procedures for 5G System; Stage 2", December
2018, <http://www.3gpp.org/FTP/Specs/2018-03/ 2018, <http://www.3gpp.org/FTP/Specs/2018-03/
Rel-15/23_series/23502-f40.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.4.0): Policy and Charging Control System for 5G (V15.4.0): Policy and Charging Control System for 5G
 End of changes. 25 change blocks. 
53 lines changed or deleted 252 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/