Network Working Group D. von Hugo
Internet-Draft Deutsche Telekom - Technology Innovation
Intended status: Informational B. Sarikaya
Expires: November 3, 2017 Huawei
T. Herbert
Quantonium
K. Satish
Nokia
R. Schott
Deutsche Telekom
May 2, 2017
5G IP Access Mobility and Session Management Protocols
draft-xyx-5gip-ps-00
Abstract
This document builds upon 5G IP issues work and - based on a
simplified 5G system architecture - attempts to make the case for a
possible set of new protocols that need to be developed to be used
among various virtualized functions in a 5G network.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 3, 2017.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
von Hugo, et al. Expires November 3, 2017 [Page 1]
Internet-Draft 5G IP Problem Statements May 2017
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Converged Access-Agnostic Core Network . . . . . . . . . . . 3
4. Access Management Protocols . . . . . . . . . . . . . . . . 6
5. Mobility Management Protocols . . . . . . . . . . . . . . . . 8
6. Session Management Protocols . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
Current networking infrastructure is moving towards a converged
common core network serving wireline and wireless access networks to
which the end users are connected. Such a network if realized in
terms of 5G project being undertaken worldwide is expected to meet
the stringent requirements discussed in
[I-D.vonhugo-5gangip-ip-issues].
In this document we elaborate upon 5G system architecture which is
composed of modularised adaptable network functions of control plane
and data plane and their interconnections. Much of this
functionality is expected to be implemented as virtualized functions
running in central and/or distributed computation environment (cloud)
as well as traditional physical entities in parallel.
We discuss IP level protocols that need to be developed. The
discussion is based on and builds upon our existing documents on
mobility management and access management. Identifier Locator
Addressing (ILA) protocol is designed as a data plane protocol for
task communication and migration in L3 based data center networks
[I-D.herbert-nvo3-ila]. ILA can also be used in user mobility. This
aspect of ILA is investigated in [I-D.mueller-ila-mobility] by
von Hugo, et al. Expires November 3, 2017 [Page 2]
Internet-Draft 5G IP Problem Statements May 2017
attempting to apply it directly to 4G 3GPP Evolved Packet System
(EPS).
Regarding access management, a framework allowing clients and
networks in a multi-network scenario to negotiate combination of
uplink and downlink paths taking into account client's application
needs and network conditions has been developed in
[I-D.kanugovi-intarea-mams-protocol]. A control plane protocol for
configuring the user plane in a multi access management framework
that can be used to flexibly select the combination of uplink and
downlink access and core network paths is described in
[I-D.zhu-intarea-mams-control-protocol]. A data plane protocol for
multiplexing end to end connections is described in
[I-D.zhu-intarea-mams-user-protocol] using trailer approach.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Converged Access-Agnostic Core Network
Key principles and concepts in 5G system architecture include
separation of User Plane (UP) functions from the Control Plane (CP)
functions, allowing independent scalability, evolution, and a
flexible deployment at e.g. centralised location or distributed
(remote) locations; the concept relies on a new definition of the
network functions, e.g. to enable flexible and efficient provision of
logically separated network slices. Network slicing with slice
instantiations that may include components served by fixed networks
is another innovation in 3GPP 5G system architecture as well as the
definition of a common core network which is access agnostic.
Wherever applicable, procedures (i.e. the set of interactions between
network functions) are defined as services, so that their re-use is
possible. Each Network Function can interact with the other NF
directly if required. The architecture does not preclude the use of
an intermediate function to help route control plane messages. On
the other hand, the architecture shall be flexible enough to allow
for hassle-free introduction of newly specified network services if
required by a specific network slice for a prospective new use case.
Currently network infrastructure is being transformed into two-layer
data center or cloud as Core Network (CN) and the Access Network (AN)
which mainly accommodates 5G radio access network on the wireless
side and central office on the wireline network closer to the user.
This new architecture enables us to flexibly deploy 5G Virtual
Network Functions (VNFs) based on the service scenarios. The
von Hugo, et al. Expires November 3, 2017 [Page 3]
Internet-Draft 5G IP Problem Statements May 2017
division of work in this case is to deploy 5G control plane VNFs and
5G data plane VNFs with related applications in both the central core
cloud and distributed local edge clouds.
Especially for new ultra low latency services offering vehicular
communications a placement of both user data plane functions (e.g.
caches or anchors) and corresponding control plane tasks (e.g.
activating and monitoring them) near the points of attachment (e.g.
road side radio antennas) may be required.
These Network Function names as defined in current version of draft
3GPP specifications are given here exemplarily and shall serve for
illustrative purposes. The final version of the architecture is
still under discussion.
5G system architecture is based on a complete system operation
including policy control, authentication, quality of service (QoS),
subscriber profiles and charging which are not of interest to us in
this document. Based on this abstraction we can simplify the
architecture with the elimination of the corresponding network
functions and their interconnections. The resulting simplified
system architecture is shown in Figure 1. The rectangles are the
network functions and the lines are their interconnections. Network
Function names are given on the right hand side.
+---+ +---+
________|AMF|-----|SMF|
/ +---+ +---+
/ / /
/ / / Access and Mobility
/ / / Function (AMF)
/ / / Session Management
/ / / Function (SMF)
/ / / Data Network, e.g.
/ / / Internet (DN)
+--+ +-----+ +---+ /---\ User Equipment(UE)
|UE|-----|(R)AN|--------|UPF|------ | DN | (Radio)Access Network ((R)AN)
+--+ +-----+ +---+ \---/ User Plane Function (UPF)
Figure 1: Simplified 5G System Architecture
Access and Mobility Management Function (AMF) is in charge of
registration management, connection management, reachability
management, mobility management. It does access authentication and
access authorization.
Session Management Function (SMF) is in charge of session
establishment, modify and release, including tunnel maintenance
von Hugo, et al. Expires November 3, 2017 [Page 4]
Internet-Draft 5G IP Problem Statements May 2017
between UPF and the access network (AN) node (if applicable). UE IP
address allocation and management (incl. optional authorization),
selection and control of the user plane (UP), i.e. data plane
function. SMF configures traffic steering at UPF to route traffic to
proper destination (i.e. the corresponding Data Network, DN);
initiator of AN specific SM information, sent via AMF to AN; support
for interaction with external DN for transport of signalling for PDU
session authorization/authentication by external DN.
User Plane Function (UPF) is anchor point for mobility; external PDU
session point of interconnect to Data Network; Packet routing and
forwarding; Packet inspection and User plane part of Policy rule
enforcement; uplink classifier to support routing traffic flows to a
data network; branching point to support multi-homed PDU session;
transport level packet marking in the uplink and downlink; downlink
packet buffering and downlink data notification triggering.
The reference points in the original 5G system architecture
[TR23.501], [TR23.502] usually carry a specific protocol such as GTP
(GTP-C for control plane, e.g. over N2 or GTP-U for data plane, e.g.
over N3) or Non-Access Stratum (NAS) of 3GPP. Access and Mobility
Management Function (AMF) is the Network Function (NF) that
terminates N1 and N2. User Plane Function (UPF) is the NF that
terminates N3. N1 which is the reference point between UE and AMF
represents interactions going over (R)AN but these interactions are
transparently relayed by (R)AN. That is the difference between N1
and N2 which is the reference point between (R)AN and AMF.
According to 5G architecture, 5G UE is expected to use Non-Access
Stratum (as opposed to Access-Stratum (AS) which is used between
access network and UE) signaling for establishment of communication
sessions and for maintaining continuous communications with the user
equipment as it moves in 5G core network even when UE is connected to
5G core network via a non-3GPP access network, e.g. over Wi-Fi,
oftentimes simultaneously to the wireless radio access network (RAN).
Some of the procedures for the 5G system being defined in [TR23.502]
are to be used in establishing an IP link, like Non-Access Stratum
signaling. Such link layer aspects of 5G System Architecture are out
of scope.
In the simplified 5G system architecture, our interest in this
document is to use IETF protocols in the interconnection points shown
in Figure 1. The goals of the work will involve:
o Align with the identifier usage, e.g. 64-bit identifier for UE,
e.g. International Mobile Subscriber Identity (IMSI)
von Hugo, et al. Expires November 3, 2017 [Page 5]
Internet-Draft 5G IP Problem Statements May 2017
o Adopt the same network functions, e.g. Access and mobility
Management Function, Session Management Function (SMF), User Plane
Function (UPF)
o Address multiple access issue in the access management and also
session management
o Adopt the identifier locator addressing protocol which does not
involve tunneling for mobility management
o Define address allocation function of the session management as
part of the mobility management protocol
o Define session and service continuity as part of the session
management
One of the challenges in 5G FMC is how to provide seamless mobility
when 5G UE while in a 5G radio access network later moves to an area
of served by a Wi-Fi access point connected to a central office
within the fixed network while both access networks are served by a
converged common core. Another challenge is to enable flexible and
seamless management of the user sessions while accessing the network
sometimes simultaneously over UE's multiple interfaces, e.g. 5G and
Wi-Fi.
In the next sections, we discuss access (Section 4) and mobility
(Section 5) and session (Section 6) management protocols that need to
be developed in order to satisfy the key features and requirements of
the upcoming 5G networks described in
[I-D.vonhugo-5gangip-ip-issues]. These protocols will be defined to
be potentially used in the interconnections of the virtualized
network functions shown in Figure 1.
4. Access Management Protocols
An investigation of multiple access management for a UE that
simultaneously connects to multiple data networks is presented in
[I-D.kanugovi-intarea-mams-protocol].
[I-D.kanugovi-intarea-mams-protocol] sets forward the requirements
such as enabling connectivity using different access networks. The
network path selection and user data distribution should work
transparently. Access path selection should be independent for
Uplink and Downlink. A common core network independent of the access
networks should be accessed by the UE. Network path selection should
be adaptive to the link quality. Distribution and aggregation of
user data across multiple network paths at the IP layer should be
von Hugo, et al. Expires November 3, 2017 [Page 6]
Internet-Draft 5G IP Problem Statements May 2017
supported. Heterogeneous access networks, which may have different
MTU sizes should be supported using concatenation and fragmentation.
Based on these requirements, control and data plane functions for
connection management can be determined. Network Connection Manager
(NCM) is the control plane function. There is a data plane component
for user data traffic forwarding called Network Multi-Access Data
Proxy (MADP) which is part of the User Plane Function (UPF) in
Figure 1. It can be argued that we also need corresponding client
side counter part of NCM, called CCM and MADP hosted on the UE.
Network Multi-Access Data Proxy (MADP), i.e. hosted in AMF in the
core network handles the user data traffic forwarding across multiple
network paths, as well as other user-plane functionalities, e.g.
encapsulation, fragmentation, concatenation, reordering,
retransmission, etc. N-MADP is the distribution node for uplink and
downlink data with visibility of packets at the IP layer.
Network Connection Manager (NCM) in the core network configures
identification and distribution rules for different user data traffic
type at the N-MADP. The NCM configures the routing in the MADP based
on signaling exchanged with the CCM in UE. In the uplink, NCM
specifies the core network path to be used by MADP to route uplink
user data at the MADP. In the downlink, NCM specifies the access
links to be used for delivery of data to the client at the MADP.
At the UE, MADP handles encapsulation, fragmentation, concatenation,
reordering, retransmissions, etc. C-MADP is configured by CCM based
on signaling exchange with NCM and local policies at the UE.
At the UE, CCM manages the multiple network connections. CCM is
responsible for exchange of MAMS signaling messages with the NCM for
supporting functions like configuring uplink and downlink user
network paths for transporting user data packets, link sounding and
reporting to support adaptive network path selection by NCM. In the
downlink, for the user data received by UE, it configures IP layer
forwarding for application data packets received over any of the
accesses to reach the appropriate application module on the client.
In the uplink, for the data transmitted by UE, it configures the
routing table to determine the best access to be used for uplink data
based on a combination of local policy and network policy delivered
by the NCM.
IP level protocols need to be developed supporting connection
management in a 5G IP network. An example is the trailer based
approach integrating multiple connections into a single end to end IP
connection. A multiplexing trailer is added to the end of IP payload
to flexibly support concatenation and fragmentation.
von Hugo, et al. Expires November 3, 2017 [Page 7]
Internet-Draft 5G IP Problem Statements May 2017
[I-D.zhu-intarea-mams-user-protocol] gives an earlier 4G approach,
there could possibly be other similar approaches.
5. Mobility Management Protocols
Next, we discuss mobility management. Anchor-less mobility in a 5G
fixed mobile convergence network with a converged core network
possibly based on identifier and locator separation should be the
preferred approach as opposed to tunneling approaches with fixed
anchors, e.g. or with distributed anchors.
The prospective approach is to overcome tunneling and encapsulation
overhead explained in detail in [I-D.vonhugo-5gangip-ip-issues] by
simplified routing in the edge network according to identifiers not
bound to locations and thus allowing for relocation within underlying
infrastructure. Such an approach should also incorporate session
management in support of session and service continuity in the 5G
architecture with a common core enabling mobility in multiple access
networks.
Anchor points perform important duties such as policy, accounting
etc. as well as mapping that cannot be ignored. In anchor-less
mobility, without anchor points, UE is the only common device in the
path to perform these functions. When anchors are removed then it
becomes a challenge to provide functions like security and trust.
One option is to use the UE as the only remaining single anchor point
to perform its own accounting and policy and other functions.
There are secure execution environments/processors in UE's these
days, where all the finger print recognition, password encryption
etc. is done and perhaps it is possible to extend these to run secure
network functions on behalf of the slices. However, a trusted
federation between any UE and the corresponding/accessible network
entities cannot be assumed without doubt in any case. In view of
this, virtualizing and distributing anchor point functions, e.g.
mapping identifiers to the most recent locators, security
associations (SA), etc. so they can run in the network at the points
of attachment close to the UE will need to be investigated.
Transport protocol level independence is a strong requirement in
identifier locator separation based mobility protocols. This means
that UE can have a locator or address but it should not be used as
connection end point. The identifier which may not be routable
should be used as the connection end point. This enables no
modifications at the transport layer in the host stack.
Based on the requirements, Identifier Locator Addressing (ILA)
protocol [I-D.herbert-nvo3-ila] qualifies to be used as the base
von Hugo, et al. Expires November 3, 2017 [Page 8]
Internet-Draft 5G IP Problem Statements May 2017
protocol. IPv6 operation in the current ILA need to be improved in
order to be used by the end nodes such as the UEs. Mobility
procedures in the control plane need to be defined. ILA design is
influenced by UE prefix/address allocation and management which is
part of Session Management function. Therefore the two functions
need to be designed in an integrated fashion.
Multihoming, UEs with more than one network interfaces should be
supported including simultaneous usage of the interfaces to connect
to multiple access networks. ILNP [RFC6740] supports multihoming.
ILA support could be similarly designed.
6. Session Management Protocols
Session management responsible for the setup of the connectivity for
the UE as well as managing the user plane for that connectivity is
identified as one of the key issues in 5G system architecture in
[TR23.799]. Session management design issues include managing
multiple access, multiple connectivity, multiple transport paths,
e.g. to RAN and to non-3GPP access network (AN), sometimes
simultaneously and how to efficiently transmit and receive infrequent
small amounts of data and short data bursts, e.g. for Narrow Band
Internet of Things (NB-IoT).
The challenges of this kind of session management design include if
such a design can be simplified so that NB-IoT type of very simple
sessions can also be handled. Regarding SMF and AMF, identifying the
correlation between session management and mobility management,
identifying the interactions between session management and the
mobility framework required to enable the various mobility scenarios
while minimizing any negative impact on the user experience
investigating solutions to coordinate the relocation of user-plane
flows with the relocation of applications (hosted close to the point
of attachment of the UE) due to the mobility of users can be
considered as the challenges of 5G architecture.
Network layer or IP session normally has two components: source IP
address and destination IP address. In case identifier locator
separation protocol is used IP session has four components source
locator, source identifier, destination locator and destination
identifier. With transport layer independence IP session should be
composed of source identifier and destination identifier only.
Session management deals with IP address management. SMF performs IP
address allocation. Both IPv4 and IPv6 should be supported. In an
identifier locator separation system, IPv4 can be supported
transparently by keeping the communication in IPv6 and converting the
addresses at the end points.
von Hugo, et al. Expires November 3, 2017 [Page 9]
Internet-Draft 5G IP Problem Statements May 2017
Session continuity in the case of UE mobility should be provided. In
an anchorless system, UE mobility incurs changes to the locators.
Session management should maintain the established sessions when the
UE moves. This also involves informing the destinations of the
locator change. This is done in the control plane of the mobility
management.
7. IANA Considerations
None.
8. Security Considerations
Security considerations related to the 5G systems are discussed in
[NGMN]. Due to the request for intrinsic realization of security
such aspects have to be considered by design for architecture and
protocols.
Especially as a joint usage of resources and network functions by
different separate logical network slices (e.g. in terms of virtual
network functions) seems to be inevitable in the framework of 5G the
need for strong security measures in such an environment is a major
challenge.
9. Privacy Considerations
Support of full privacy of the users (customers and tenants / end
service providers) is a basic feature of the next generation trusted
and reliable communications offering system. Such a high degree of
ensured privacy shall be reflected in the proposed architecture and
protocol solutions (details have to be added).
Especially as Identifiers and mapping of locators to them are
addressed the discussion on identifier and privacy should consider
existing solutions such as 3GPP Globally Unique Temporary UE Identity
(GUTI) which is a temporary identity obfuscating the permanent
identity in the mobile network and specified in [TS23.003].
10. Acknowledgements
This work has been partially performed in the framework of the
cooperation Config. Contributions of the project partners are
gratefully acknowledged. The project consortium is not liable for
any use that may be made of any of the information contained therein.
von Hugo, et al. Expires November 3, 2017 [Page 10]
Internet-Draft 5G IP Problem Statements May 2017
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
11.2. Informative References
[I-D.arkko-ietf-trends-and-observations]
Arkko, J., Atlas, A., Doria, A., Gondrom, T., Kolkman, O.,
olshansky@isoc.org, o., Schliesser, B., Sparks, R., and R.
White, "IETF Trends and Observations", draft-arkko-ietf-
trends-and-observations-00 (work in progress), February
2016.
[I-D.farinacci-lisp-predictive-rlocs]
Farinacci, D. and P. Pillay-Esnault, "LISP Predictive
RLOCs", draft-farinacci-lisp-predictive-rlocs-01 (work in
progress), November 2016.
[I-D.herbert-nvo3-ila]
Herbert, T. and P. Lapukhov, "Identifier-locator
addressing for IPv6", draft-herbert-nvo3-ila-04 (work in
progress), March 2017.
[I-D.ietf-dmm-4283mnids]
Perkins, C. and V. Devarapalli, "MN Identifier Types for
RFC 4283 Mobile Node Identifier Option", draft-ietf-dmm-
4283mnids-04 (work in progress), January 2017.
[I-D.kanugovi-intarea-mams-protocol]
Kanugovi, S., Vasudevan, S., Baboescu, F., Zhu, J., Peng,
S., Mueller, J., and S. Seo, "Multiple Access Management
Services", draft-kanugovi-intarea-mams-protocol-04 (work
in progress), March 2017.
[I-D.mueller-ila-mobility]
Mueller, J. and T. Herbert, "Mobility Management Using
Identifier Locator Addressing", draft-mueller-ila-
mobility-03 (work in progress), February 2017.
von Hugo, et al. Expires November 3, 2017 [Page 11]
Internet-Draft 5G IP Problem Statements May 2017
[I-D.portoles-lisp-eid-mobility]
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
Unified Control Plane", draft-portoles-lisp-eid-
mobility-02 (work in progress), April 2017.
[I-D.vonhugo-5gangip-ip-issues]
Hugo, D. and B. Sarikaya, "Review on issues in discussion
of next generation converged networks (5G) from an IP
point of view", draft-vonhugo-5gangip-ip-issues-03 (work
in progress), March 2017.
[I-D.zhu-intarea-mams-control-protocol]
Kanugovi, S., Vasudevan, S., Zhu, J., Baboescu, F., Peng,
S., and S. Seo, "Control Plane Protocols and Procedures
for Multiple Access Management Services", draft-zhu-
intarea-mams-control-protocol-01 (work in progress), March
2017.
[I-D.zhu-intarea-mams-user-protocol]
Zhu, J. and S. Seo, "User-Plane Protocols for Multiple
Access Management Service", draft-zhu-intarea-mams-user-
protocol-01 (work in progress), March 2017.
[M.2083] ITU-R, "Rec. ITU-R M.2083-0, IMT Vision-Framework and
overall objectives of the future development of IMT for
2020 and beyond", September 2015.
[METIS] Elayoubi, S. and et al., "5G Service Requirements and
Operational Use Cases: Analysis and METIS II Vision",
Proc. euCNC, 2016.
[NGMN] NGMN Alliance, "NGMN White Paper", February 2015.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516,
February 1999, <http://www.rfc-editor.org/info/rfc2516>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>.
[RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network
Protocol (ILNP) Architectural Description", RFC 6740,
DOI 10.17487/RFC6740, November 2012,
<http://www.rfc-editor.org/info/rfc6740>.
von Hugo, et al. Expires November 3, 2017 [Page 12]
Internet-Draft 5G IP Problem Statements May 2017
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>.
[RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G.,
Tyson, G., Davies, E., Molinaro, A., and S. Eum,
"Information-Centric Networking: Baseline Scenarios",
RFC 7476, DOI 10.17487/RFC7476, March 2015,
<http://www.rfc-editor.org/info/rfc7476>.
[TR23.501]
"3GPP TR23.501, System Architecture for the 5G System
(Release 15)", December 2017.
[TR23.502]
"3GPP TR23.502, Procedures for the 5G System (Release
15)", December 2017.
[TR23.799]
"3GPP TR23.799, Study on Architecture for Next Generation
System (Release 14)", December 2016.
[TS23.003]
"3GPP TS23.003, Numbering, addressing and identification
(Release 14)", September 2016.
Authors' Addresses
Dirk von Hugo
Deutsche Telekom - Technology Innovation
Deutsche-Telekom-Allee 7
D-64295 Darmstadt
Germany
Email: Dirk.von-Hugo@telekom.de
Behcet Sarikaya
Huawei
5340 Legacy Dr.
Plano, TX 75024
Email: sarikaya@ieee.org
von Hugo, et al. Expires November 3, 2017 [Page 13]
Internet-Draft 5G IP Problem Statements May 2017
Tom Herbert
Quantonium
Email: tom@herbertland.com
K Satish
Nokia
Email: satish.k@nokia.com
Roland Schott
Deutsche Telekom
Email: roland.schott@telekom.de
von Hugo, et al. Expires November 3, 2017 [Page 14]