Network Working Group T. Miyasaka
Internet-Draft KDDI Research
Intended status: Informational K. Kumaki
Expires: December 28, 2018 T. Niwa
KDDI
June 26, 2018
Analysis and Problem Statements for Interworking between 5G Network
Slicing and Transport Network
draft-mink-5g-ns-transport-ps-00
Abstract
This document describes problem statements for realizing an end-to-
end network slicing that is expected to provide service-oriented
communications between users and applications. 3GPP introduced the
network slicing concept in the 5G architecture (3GPP Release 15),
however, it mainly focuses on mobile access and core domains. In
order to reap the benefit of the concept, a network slicing needs to
be designed across multiple domains of the network including non-3GPP
parts. This document analyzes the current 3GPP 5G network slicing
architecture and summarizes problem statements for the interworking
between the 5G network slicing and the transport 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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 28, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
Miyasaka, et al. Expires December 28, 2018 [Page 1]
Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope of this document . . . . . . . . . . . . . . . . . 3
2. 5G Network Slicing and Transport Network . . . . . . . . . . 5
2.1. 5G Network Slicing . . . . . . . . . . . . . . . . . . . 5
2.2. Transport Network for End-to-End 5G Communication . . . . 6
2.2.1. Transport Network inside 5G System . . . . . . . . . 6
2.2.2. Transport Network outside 5G System . . . . . . . . . 6
2.2.3. Management and Orchestration of 5G Network Slicing . 7
3. General Procedure for Interworking between 5G Network Slicing
and Transport Network . . . . . . . . . . . . . . . . . . . . 7
4. Analysis on Interworking . . . . . . . . . . . . . . . . . . 10
4.1. Analysis Assumption . . . . . . . . . . . . . . . . . . . 10
4.2. Analysis inside 5G Core Network . . . . . . . . . . . . . 11
4.3. Analysis outside 5G Core Network . . . . . . . . . . . . 13
5. Problem Statement Summary . . . . . . . . . . . . . . . . . . 14
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Consideration . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15
10. Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
An End-to-End(E2E) network slicing is expected to cater to much
greater diversity of requirements for wide variety of services such
as V2X services and factory automation. Here, the E2E means that a
network slicing penetrates all network domains: mobile networks,
transport networks and so forth. Network operators anticipate that
it is possible to tailor the network to fit for service-oriented
demands in a timely and cost-effective way, which in turn reduces
OPEX and CAPEX.
3GPP is leading a network slicing concept in the 5G system (3GPP
Release 15). The 3GPP network slicing is defined as a logical
network that provides specific network capabilities and network
Miyasaka, et al. Expires December 28, 2018 [Page 2]
Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018
characteristics. However, it covers a limited domains and mainly
focuses on an isolation for the 5G network functions. In order to
achieve the goal, the network slicing needs to be designed from the
E2E perspectives, not only 3GPP but also non-3GPP including transport
networks.
The way to map transport networks to the 5G system for a network
slicing can be classified into two parts: inside and outside 5G
system. Inside 5G system, network connections between UE, RAN, UPF
and DN can be identified as network slice with one or more QoS Flow
rules, and thus its underlying transport network should also be aware
of the network slice. Outside 5G system, the E2E network slicing
shall concatenate the network slicing whthin 5G systems with that of
the following transport networks. To this end, a method to stitch
user plane traffic to/from UPF and logical tunnels in transport
networks (e.g. MPLS-TE) is required.
Therefore, in terms of the E2E network slicing, the transport network
shall accommodate to the 5G system. This document analyzes the
current 5G network slicing architecture and summarizes problem
statements for the interworking between the 5G network slicing and
the transport network.
1.1. Scope of this document
The scope of this document is to analyze an interworking between the
5G network slicing and the transport network and summarize problem
statements for the interworking. Figure 1 shows an E2E communication
between UE and CP(Content Provider Server) on 5G network slicing
environment. We define each term used in the scope with Figure 1 as
follows.
Miyasaka, et al. Expires December 28, 2018 [Page 3]
Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018
+ - - - - - - - - - - - - - - - - - - +
| Network Slice Instance(NS1) |
+--+ +---+ +---+ +---+
|UE+--|-+RAN| |UPF|----------|DN | |
+--+ +-|-+ +-|-+ +-|-+
+ - + - - - - - - -+- - - - - - - + - +
| | |
+ - - + - - - - - - -|- - + + - - + - - - - - - - - - +
| | | | | | |
| +----+ | | +----+
| | | R2 | | | | | | R6 | |
| +----+ | | +----+
| | / \ | | | | / \ |
+--|-+/ \+--|-+ +--|-+/ \+----+ +--+
| | R1 | | R4 | | | | R5 | | R8 |--+--|CP|
+--|-+\ /+--|-+ +--|-+\ /+----+ +--+
| | \ / | | | | \ / |
| +----+ | | +----+
| | | R3 | | | | | | R7 | |
| +----+ | | +----+
| | Transport | | | | Transport |
| Network | | Network
| | Inside 5GC | | | | Outside 5GC |
+ - - + - - - - - - -|- - + + - - + - - - - - - - - - +
| | |
+ - + - - - - - - -+- - - - - - - + - +
+--+ +-|-+ +-|-+ +-|-+
|UE+--|-+RAN| |UPF|----------|DN | |
+--+ +---+ +---+ +---+
| Network Slice Instance(NS2) |
+ - - - - - - - - - - - - - - - - - - +
Figure 1: E2E communication between UE and CP
o Network slice instance
The network slice instance is defined as "A set of Network Function
instances and the required resources (e.g. compute, storage and
networking resources) which form a deployed Network Slice" in
[TS.23.501-3GPP].
o Transport network
The definition of the transport network in this document is a network
which provides a network connectivity to the 5G network functions
such as UPF. The scope of the the transport network in this document
is limited to layer-3 network, thus IPv4 and IPv6. This is because
3GPP adopted IPv4/IPv6 as a transport network of the 5G user plane.
Miyasaka, et al. Expires December 28, 2018 [Page 4]
Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018
There are two different transport networks in Figure 1: the transport
network inside 5G core network consists of R1, R2, R3, and R4 and the
transport network outside 5G core network consists of R5, R6, R7, and
R8. Both inside and outside networks are within the scope of this
document.
o Traffic engineering
The definition of traffic engineering in this document is to control
the traffic path of IPv4/IPv6 packet in order to fulfill each network
slice instance's requirements. (e.g. bandwidth and latency)
For example, there are two network slice instance in Figure 1: NS1
and NS2. Suppose NS1 provides latency sensitive service such as V2X
(in this case, UE is an automotive vehicle and CP is a control/
monitoring server operated by a car vendor), an operator needs to
perform traffic engineering in transport network to select a path
that total latency between UE and CP is minimum. If one-way latency
is measured as follows,
o R1->R2->R4 : 1msec
o R1->R3->R4 : 2msec
o R5->R6->R8 : 9msec
o R5->R7->R8 : 6msec
the traffic path of NS1 in the transport network inside 5G core
network is R1->R2->R4 and the traffic path of NS1 in the transport
network outside 5G core network is R5->R7->R8. Therefore, the E2E
communication from UE to CP is
"UE->RAN->R1->R2->R4->UPF->DN->R5->R7->R8->CP".
o Interworking
The definition of an interworking in this document is that the
network slice instance and the transport network collaborate in order
to perform the traffic engineering which fulfills requirements of the
network slice instance.
2. 5G Network Slicing and Transport Network
2.1. 5G Network Slicing
The 5G system architecture introduced the following key features:
Miyasaka, et al. Expires December 28, 2018 [Page 5]
Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018
o Separate the user plane (UP) functions from the control plane (CP)
functions, allowing independent scalability and flexible
deployments.
o Modularize the network function to enable the flexible and
efficient network slicing.
Thanks to the features, the deployed network slicing is comprised of
a network slice instance that indicates a set of network
functions(e.g. UPF) and the required resources. S-NSSAI(Single
Network Slice Selection Assistance Information) is used to identify a
network slice and assists the selection of a particular network slice
instance corresponding to the slice. A network slice instance can be
associated with one or more S-NSSAIs, and an S-NSSAI can be
associated with one or more network slice instances. NSI ID(Network
Slice Instance Identifier) may identify a network slice instance
corresponding to a certain S-NSSAI.
2.2. Transport Network for End-to-End 5G Communication
An E2E network slicing needs a cross-domain technology that covers
3GPP, transport networks and others (e.g. optical networks, data
center networks). For the 5G system, the transport networks are
classifled two parts; inside and outside 5G systems.
2.2.1. Transport Network inside 5G System
A PDU session belongs to one and only one specific network slice
instance in the 5G system. The 5G QoS model is based on the QoS
Flows that is the finest granularity of QoS differentiation in the
PDU session. The QoS Flow is characterised by QoS profiles for RAN,
QoS rules for UE and PDR(Packet Detection Rule) for UPF. DSCP can be
optinally utilized to support the QoS Flow, however, the QoS Flow
does not correspond to the network slice one by one. Therefore, a
network slice can not be identified from the transport network
perspective. Regarding the transport connectivity between different
3GPP nodes in the network slice instance, transport networks shall
take 3GPP link requirements (e.g. NSI ID, topology, QoS parameters,
etc.) from the network slice into account.
2.2.2. Transport Network outside 5G System
The S-NSSAI instructs which a PDU session is associated with a DN and
a network slice instance. In the current 3GPP specification,
transport networks cannot recognize the S-NSSAI or the NSI ID from UP
directly and thus cannot map the network slicing in the 3GPP system
to that of transport networks.
Miyasaka, et al. Expires December 28, 2018 [Page 6]
Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018
2.2.3. Management and Orchestration of 5G Network Slicing
The management and orchestration of the 5G network slicing is studied
in 3GPP SA5. This study includes creation, modification, and
elimination of the network slice instance from the 3GPP management
system.
In this 3GPP management system, the coordination with the management
system of non-3GPP parts also has been taken into account and the
transport network management is included in the scope of the
management system. Figure 2 shows a concept of the 3GPP management
system and a coordination with the transport network management
system, which is described in section 4.7 of [TS.28.530-3GPP]
However, the detailed analysis for the coordination with the
transport network management system is not studied.
+------------------------+
| 3GPP Management System |
+------------------------+
/|\
|
|
\|/
+-------------------+
| Transport Network |
| Management System |
+-------------------+
/|\ /|\ /|\
| | |
+----------+ | +------------+
| | |
\|/ \|/ \|/
+---+ ---- +---+ ---- +---+ ---- +----------+
|RAN|----( TN )----|UPF|----( TN )----|DN |----( TN )----|App Server|
+---+ ---- +---+ ---- +---+ ---- +----------+
* TN = Transport Network
Figure 2: E2E communication between UE and CP
3. General Procedure for Interworking between 5G Network Slicing and
Transport Network
Figure 3 illustrates a general procedure for an interworking between
5G Network Slicing and Transport Network and we use following
terminology in this figure
Miyasaka, et al. Expires December 28, 2018 [Page 7]
Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018
o 5G User Plane Function : A function which is related to 5G user
plane. RAN, UPF, and DN are current 5G User Plane Fucntion
defined by 3GPP.
o NS Forwarding Policy DB : A database which maintains a forwarding
policy which needs to be applied to each NS instance.
o TE Indicator : An indicator which instructs an adequate forwarding
policy to router for the NS instance and encoded in an incoming
packet. MPLS label and SRv6 SRH are an example for TE indicator.
o 5G IP Packet : An IPv4/IPv6 packet sents from 5G network function.
The 5G network function performs the following procedures for an
interworking.
1. Recognize the NSI ID of an outgoing packet at 5G User Plane
Function
2. Decide an adequate forwarding policy which is performed on this
network slice instance by inquiring to the NS Forwarding Policy
DB.
3. Encapsulate an outgoing 5G IP Packet with an adequate TE
indicator for the forwarding policy of a network slice instance
4. Send the encapsulated packet to the transport network
Miyasaka, et al. Expires December 28, 2018 [Page 8]
Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018
5G Network Function
+-----------------+
|+---------------+|
|| NS Forwarding ||
|| Policy DB ||
|+---------------+|
| /|\ | |
| | | |
| | | |
| | \|/ |
| +-------------+ |
| |5G User Plane| |
| | Function | | +------------+ +------------+
| +-------------+ | |TE Indicator| |TE Indicator|
| | | +------------+ Router +------------+
| \|/ | |5G IP Packet| +--------------+ |5G IP Packet|
| +----------+ | +------------+ | +----------+ | +------------+
| |Data Plane|---+----------------+>|Data Plane|-|-------------->
| +----------+ | | +----------+ | Next Router
+-----------------+ +--------------+
Figure 3: Interworking Procedure
Figure 4 shows an example of interworking procedure. In this
example, the 5G network function uses MPLS-TE for traffic engineering
in transport network and encapsulated with MPLS label which
represents an adequate MPLS-TE tunnel which fulfills requirements of
a network slice instance. The following list describes the detailed
procedure in this example.
1. 5G Network Function recognizes that the NSI ID of the outgoing
packet is 123
2. 5G Network Function resolves the required traffic engineering
policy is the MPLS-TE tunnel 123 for the network slice instance
3. 5G Network Function encapsulated the outgoing 5G IP packet with
MPLS label of 123 which is the outgoing label of the MPLS-TE
tunnel 123
4. 5G Network Function sends the encapsulated packet to the
transport network
Miyasaka, et al. Expires December 28, 2018 [Page 9]
Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018
5G Network Function
+-------------------+
|+-----------------+|
|| NS Forwarding ||
|| Policy DB ||
|| ||
||NSI ID:Policy ||
|| 111:MPLS-TE ||
|| tunnel 111||
|| (HighBW) ||
|| 123:MPLS-TE ||
|| tunnel 123||
|| (LowLatency)||
|+-----------------+|
| /|\ | |
| | | |
| | | |
| +-------------+ | +------------+ +------------+
| |5G User Plane| | | MPLS label | | MPLS label |
| | Function | | | 123 | | 234 |
| +-------------+ | |(tunnel 123)| |(tunnel 123)|
| | | +------------+ Router +------------+
| \|/ | |5G IP Packet| +--------------+ |5G IP Packet|
| +----------+ | +------------+ | +----------+ | +------------+
| |Data Plane|-----+----------------+>|Data Plane|-|-------------->
| +----------+ | | +----------+ | Next Router
+-------------------+ +--------------+
Figure 4: Example of Interworking Procedure
4. Analysis on Interworking
This section describes an analysis on an interworking between the 5G
network slicing and the transport network both outside and inside 5G
core networks.
4.1. Analysis Assumption
Figure 5 and the following list illustrates an assumption on the 5G
network slicing for our analysis. Sharing of network function (UPF
and DN) among different network slice instances is suggested in
section 4.5 of [TS.28.530-3GPP].
o UE can connect to the multiple network slice instances.
o RAN is a common network function to select adequate network slice
instance's UPF.
Miyasaka, et al. Expires December 28, 2018 [Page 10]
Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018
o UPF may be shared between different network slice instances. The
shared UPF has a common IP address/prefix for an endpoint.
o DN may be shared between different network slice instances. The
shared DN has a common IP address/prefix for an endpoint.
+ - - - - - - - - - - - - - - - - +
| NS1 |
+-----+ +-----+ +---+
+-----|---| UPF |-----| UPF |-----| |-|
| +-----+ +-----+ | |
| + - - - - - - - - - - - - - |DN | +
| + - - - - - - - - - - - - - | | +
| | NS2 | | |
+--+ +-+-+ +-----+ | |
|UE+----+RAN+---|---------------| |-----| |-|
+--+ +-+-+ | | +---+
| + - - - - - - - | | - - - - - +
| + - - - - - - - | UPF | - - - - - +
| | NS3 | | |
| +-----+ | | +---+
+-----|---| UPF |-----| |-----|DN |-|
+-----+ +-----+ +---+
+ - - - - - - - - - - - - - - - - +
Figure 5: Analysis Assumption
4.2. Analysis inside 5G Core Network
This section describes an analysis on an interworking between the 5G
network slicing and the transport network inside 5G core network
based on the procedure described in Section 3. The problem statement
in this analysis is emphasized as [PS-Interwork-X].
[PS-Interwork-1]: 5G Network Function cannot recognize the NSI ID of
an established PDU session. Therefore, statically
configured Policy Based Routing(PBR) based traffic
engineering is required.
5G Network Function cannot recognize the NSI ID of an established PDU
session due to the following two reasons.
1. From the user plane perspective, the NSI ID is not encoded in any
header including GTP-U extension header. New PDU Session
Container GTP-U extension header is introduced for the 5G user
plane in [TS.29.281-3GPP], but the extension header only includes
QFI information.
Miyasaka, et al. Expires December 28, 2018 [Page 11]
Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018
2. From the control plane perspective, the NSI ID is not signaled to
the user plane function such as UPF. PFCP is extended for the 5G
control plane protocol in [TS.29.244-3GPP], however, the NSI ID
is not signaled to the user plane function.
For this problem statement, we have to statically configure a policy
based routing(PBR) based traffic engineering in the 5G network
function. In Figure 6, an example for statically configured PBR in
UPFb and UPFd is described in Figure 7.
+ - - - - - - - - - - - - - - - - - - - +
| NS1 (NSI ID=1) |
+------+ +------+ +-----+
+-----|-----| UPFa |-----| UPFb |-----| DNa | |
| +------+ +------+ +-----+
| + - - - - - - - - - - - - - - - - - - - +
| + - - - - - - - - - - - - - - - - - - - +
| | NS2 (NSI ID=2) |
+--+ +-+-+ +------+ +------+ +-----+
|UE+----+RAN+---|-----| |-----| |-----| DNb | |
+--+ +---+ | | | | +-----+
| + - - | |- - -| | - - - - - - +
| + - - | UPFc |- - -| UPFd | - - - - - - +
| | | | | | |
| | | | | +-----+
+-----|-----| |-----| |-----| DNc | |
+------+ +------+ +-----+
| NS3 (NSI ID=3) |
+ - - - - - - - - - - - - - - - - - - - +
Figure 6: Example for PBR based traffic engineering
In case of UPFd in Figure 6, statically configured PBR needs to
include a source IP address classification because a destination IP
address of next UPF (UPFc) is common as UPFc is shared between NS2
and NS3 as described in Section 4.1.
Miyasaka, et al. Expires December 28, 2018 [Page 12]
Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018
+------------------------------------------------------------+
| Routing Table for UPFb |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|
| IF: Subsequent Node IP address is <IP address of UPFa> |
| THEN: Nexthop is <MPLS-TE tunnel 1> (for NS1) |
| |
| IF: Subsequent Node IP address is <IP address of DNa> |
| THEN: Nexthop is <MPLS-TE tunnel 2> (for NS2) |
+------------------------------------------------------------+
+------------------------------------------------------------+
|Routing Table for UPFd |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|
| IF: Subsequent Node IP address is <IP address of UPFc> |
| AND Previous Node IP address is <IP address of DNb> |
| THEN: Nexthop is <MPLS-TE tunnel 1> (for NS2) |
| |
| IF: Subsequent Node IP address is <IP address of DNb> |
| THEN: Nexthop is <MPLS-TE tunnel 2> (for NS2) |
| |
| IF: Subsequent Node IP address is <IP address of UPFc> |
| AND Previous Node IP address is <IP address of DNc> |
| THEN: Nexthop is <MPLS-TE tunnel 3> (for NS3) |
| |
| IF: Subsequent Node IP address is <IP address of DNc> |
| THEN: Nexthop is <MPLS-TE tunnel 4> (for NS3) |
+------------------------------------------------------------+
Figure 7: PBR based traffic engineering
[PS-Interwork-2]: 5G network function cannot classify a network
slice instance by using PBR If both previous node
and subsequent node are shared between different
network slice instances.
For example, a routing table for UPFc in Figure 6 toward RAN node
cannot classify NS2 and NS3, because previous node is UPFb which is
shared NS2 and NS3 and the subsequent node is RAN which is a common
network function among network slice instances as described in
Section 4.1. Therefore, the source IP address and the destination IP
address are common among NS2 and NS3, so we cannot create an adequate
PBR rule for each network slice instance.
4.3. Analysis outside 5G Core Network
TBD
Miyasaka, et al. Expires December 28, 2018 [Page 13]
Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018
5. Problem Statement Summary
The following list summarizes problem statements for the interworking
inside 5G core network.
[PS-Interwork-1]: 5G Network Function cannot recognize the NSI ID of
the established PDU session. Therefore,
statically configured Policy Based Routing(PBR)
based traffic engineering is required
[PS-Interwork-2]: 5G network function cannot classify the network
slice instance by using PBR If both previous node
and subsequent node are shared between different
network slice instances.
The following list summarizes problem statements for the interworking
outside 5G core network.
[PS-Interwork-3]: TBD
6. Conclusion
This document summarizes problem statements for an interworking
between 5G network slicing and transport network. Our analysis shows
the traffic engineering for a 5G network slicing is achieved by using
a policy based routing. However, if the 5G network function (e.g.,
UPF) is shared among different network slice instances, there is a
case that the traffic engineering is not achieved because the 5G
network function cannot distinguish a network slice instance [PS-
Interwork-2]. This issue is inevitable under the current 5G
specification and we need to give the feedback to 3GPP to solve the
issue.
From the IETF perspective, "transport network management system" is
required from 3GPP SA5 WG as described in Section 2.2.3. This
transport network management system needs to serve a transport
network related request sent from a 3GPP management system, which
means the transport network management system needs to provide API to
the 3GPP management system to control the transport network from the
3GPP side. Therefore, IETF needs to collaborate with 3GPP,
specifically for 3GPP SA5 WG, and examine if the current standardized
technology and framework in the IETF activity fulfills requirements
from 3GPP.
Miyasaka, et al. Expires December 28, 2018 [Page 14]
Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018
7. Security Consideration
TBD
8. IANA Considerations
This document does not require any action from IANA.
9. Acknowledgement
The author would like to thank Takeshi Usui, Satoru Matsushima,
Shunsuke Homma for their useful comments.
10. Informative References
[TS.23.501-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 23.501
(V15.1.0): System Architecture for 5G System; Stage 2",
March 2018, <http://www.3gpp.org/FTP/Specs/2018-03/
Rel-15/23_series/23501-f10.zip>.
[TS.28.530-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 28.530
(V1.0.0): Telecommunication management; Management and
orchestration of networks and network slicing; Concepts,
use cases and requirements", June 2018,
<http://ftp.3gpp.org//Specs/
archive/28_series/28.530/28530-100.zip>.
[TS.29.244-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 29.244
(V15.1.0): Interface between the Control Plane and the
User Plane Nodes; Stage 3", March 2018,
<http://www.3gpp.org/FTP/Specs/2018-03/
Rel-15/29_series/29244-f10.zip>.
[TS.29.281-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 29.281
(V15.2.0): GPRS Tunneling Protocol User Plane (GTPv1-U)",
March 2018, <http://www.3gpp.org/FTP/Specs/2018-03/
Rel-15/29_series/29281-f20.zip>.
Authors' Addresses
Miyasaka, et al. Expires December 28, 2018 [Page 15]
Internet-Draft draft-mink-5g-ns-transport-ps-00 June 2018
Takuya Miyasaka
KDDI Research
2-1-15, Ohara, Fujimino-shi
Saitama 356-8502
JP
Email: ta-miyasaka@kddi-research.jp
Kenji Kumaki
KDDI
3-22-7, Yoyogi, Shibuya-ku
Tokyo 151-0053
JP
Email: ke-kumaki@kddi.com
Tomonobu Niwa
KDDI
3-22-7, Yoyogi, Shibuya-ku
Tokyo 151-0053
JP
Email: to-niwa@kddi.com
Miyasaka, et al. Expires December 28, 2018 [Page 16]