ICNRG R. Ravindran
Internet-Draft Huawei
Intended status: Informational P. Suthar
Expires: May 2, 2018 Cisco
G. Wang
Huawei
October 29, 2017
Enabling ICN in 3GPP's 5G NextGen Core Architecture
draft-ravi-icnrg-5gc-icn-00
Abstract
The proposed 3GPP's 5G core nextgen architecture (5GC) offers
flexibility to introduce new user and control plane function within
the context of network slicing that allows greater flexibility to
handle heterogeneous devices and applications. In this draft, we
provide a short description of the proposed 5GC, followed by
extensions to 5GC's control and user plane to support packet data
unit (PDU) sessions from information-centric networks. The value of
enabling ICN in 5GC is discussed using two service scenarios which
include mobile edge computing and support for seamless mobility for
ICN sessions.
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 May 2, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
Ravindran, et al. Expires May 2, 2018 [Page 1]
Internet-Draft ICN in 5GC October 2017
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. 5G NextGen Core Design Principles . . . . . . . . . . . . . . 5
4. 5G NextGen Core Architecture . . . . . . . . . . . . . . . . 6
5. 5GC Architecture with ICN Support . . . . . . . . . . . . . . 8
5.1. Control Plane Extensions . . . . . . . . . . . . . . . . 10
5.1.1. Normative Interface Extensions . . . . . . . . . . . 12
5.2. User Plane Extensions . . . . . . . . . . . . . . . . . . 12
5.2.1. Normative Interface Extensions . . . . . . . . . . . 13
6. ICN Deployement Use Case Scenarios . . . . . . . . . . . . . 14
6.1. Mobile Edge Computing . . . . . . . . . . . . . . . . . . 14
6.1.1. IP-MEC Scenario . . . . . . . . . . . . . . . . . . . 14
6.1.2. ICN-MEC Scenario . . . . . . . . . . . . . . . . . . 15
6.2. ICN Session Mobility . . . . . . . . . . . . . . . . . . 16
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. Informative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
The objective of this draft is to propose an architecture to enable
information-centric networking (ICN) in the proposed 5G Next-
generation Core network architecture (5GC) by leveraging its
flexibility to allow new user and associated control plane functions.
The reference architectural discussions in three core 3GPP
specifications [TS23.501][TS23.502][TS23.799] form the basis of our
discussions. This draft also complements the discussions related to
various ICN deployment opportunities explored in
[I-D.rahman-icnrg-deployment-guidelines], where 5G technology is
considered as one of the promising alternatives.
Ravindran, et al. Expires May 2, 2018 [Page 2]
Internet-Draft ICN in 5GC October 2017
Though ICN is a general networking technology, it would benefit 5G
particularly from the perspective of mobile edge computing (MEC).
Following ICN features shall benefit MEC deployments in 5G:
o Edge Computing: Multi-access Edge Computing (MEC) is located at
edge of network and aids several latency sensitive applications
such as augmented and virtual reality (AR/VR) and ultra reliable
and low latency class (URLLC) of applications such as autonomous
vehicles. Enabling edge computing over an IP converged 5GC comes
with the challenge of application level reconfiguration required
to re-initialize a session whenever it is being served by a non-
optimal service instance. In contrast, named-based networking, as
considered by ICN, naturally supports service-centric networking,
which minimizes network related configuration for applications and
allows fast resolution for named service instances.
o Edge Storage and Caching : The principal entity for ICN is the
secured content (or named-data) object, which allows location
independent data replication at strategic storage points in the
network, or data dissemination through ICN routers by means of
opportunistic caching. These features benefit both realtime and
non-realtime applications, where a set of users share the same
content, thereby advantageous to both high-bandwidth and/or low-
latency applications such as Video-on-Demand (VOD), AR/VR or low
bandwidth IoT applications.
o Session Mobility: Existing long-term evolution (LTE) deployments
handle session mobility using IP anchor points at Packet Data
Network Gateway (PDN-GW) and service anchor point called Access
Point Name (APN) functionality hosted in PDN-GW, and uses a tunnel
between radio edge (eNodeB) and PDN-GW for each mobile device
attached to network. This design fails when service instances are
replicated close to radio access network (RAN) instances,
requiring new techniques to handle session mobility. In contrast,
application-bound identifier and name resolution split principle
considered for the ICN is shown to handle host mobility quite
efficiently [mas].
To summarize the draft, we first discuss 5GC's design principals that
allows the support of new network architectures. Then we summarily
discuss the 5GC proposal, followed by control and user plane
extensions required to support ICN PDU sessions. We then discuss
specific network services enabled using ICN data networks,
specifically MEC and ICN session mobility with aid from 5GC control
plane.
Ravindran, et al. Expires May 2, 2018 [Page 3]
Internet-Draft ICN in 5GC October 2017
2. Terminology
Following are terminologies relevant to this draft:
5G-NextGen Core (5GC) : Refers to the new 5G core network
architecture being developed by 3GPP, we specifically refer to the
architectural discussions in [TS23.501][TS23.502].
5G-New Radio (5G-NR): This refers to the new radio access
interface developed to support 5G wireless interface [TS-5GNR].
User Plane Function (UPF): UPF is the generalized logical data
plane function with context of the UE PDU session. UPFs can play
many role, such as, being an flow classifier (UL-CL) (defined
next), a PDU session anchoring point, or a branching point.
Uplink Classifier (UL-CL): This is a functionality supported by an
UPF that aims at diverting traffic (locally) to local data
networks based on traffic matching filters applied to the UE
traffic.
Packet Data Network (PDN or DN): This refers to service networks
that belong to the operator or third party offered as a service to
the UE.
Unified Data Management (UDM): Manages unified data management for
wireless, wireline and any other types of subscribers for M2M, IOT
application etc. UDM report subscriber related vital information
e.g. virtual edge region, list of location visits, sessions active
etc. UDM work as subscriber anchor point that means OSS/BSS
systems will have central monitoring/access of the system to get/
set subscriber information.
Authentication Server Function (AUSF): Provides mechanism for
unified authentication for subscribers related to wireless,
wireline and any other types of subscribers such as M2M and IOT
applications. The functions performed by AUSF are similar to HSS
with additional functionalities to related to 5G.
Session Management Function (SMF): Perform session management
functions for attached users equipment (UE) in 5G Core. SMF can
thus be formed by leveraging the CUPS (discussed in the next
section) feature with control plane session management.
Access Mobility Function (AMF): Perform access mobility management
for attached user equipment (UE) to the 5G core network. The
function includes, network access stratus (NAS) mobility functions
such as authentication and authorization.
Ravindran, et al. Expires May 2, 2018 [Page 4]
Internet-Draft ICN in 5GC October 2017
Application Function (AF): Helps with influencing the user plane
routing state in 5GC considering service requirements.
Network Slicing: This conceptualizes the grouping for a set of
logical or physical network functions with its own or shared
control, data and service plane to meet specific service
requirements.
3. 5G NextGen Core Design Principles
The 5GC architecture is based on the following design principles that
allow it to support new service networks like ICN efficiently
compared to LTE networks:.
o Control and User plane split (CUPS): This design principle moves
away from LTE's vertically integrated control/user plane design
(i.e., Serving Gateway, S-GW, and Packet Data Network Gateway,
P-GW) to one espousing an NFV framework with network functions
separated from the hardware for service-centricity, flexibility
and programmability. In doing so, network functions can be
implemented both physically and virtually, while allowing each to
be customized and scaled based on their individual requirements,
also allowing the realization of multi-slice co-existence. This
feature also allows the introduction of new user plane functions
(UPF). UPFs can play many roles, such as, being an uplink flow
classifier (UL-CL), a PDU session anchor point, a branching point
function, or one based on new network architectures like ICN with
new control functions, or re-using/extending the existing ones to
manage the new user plane realizations.
o Decoupling of RAT and Core Network : Unlike LTE's unified control
plane for access and the core, 5GC offers control plane separation
of the RAN from the core network. This allows the introduction of
new radio access technologies (RAT) along with slices based on new
network architectures, offering the ability to map heterogeneous
RAN flows to arbitrary core network slices based on service
requirements.
o Non-IP PDU Session Support : A PDU session is defined as the
logical connection between the UE and the data network (DN). 5GC
offers a scope to support both IP and non-IP PDU (termed as
"unstructured" payload), and this feature can potentially allow
the support for ICN PDUs by extending or re-using the existing
control functions.
o Service Centric Design: 5GC's service orchestration and control
functions, such as naming, addressing, registration/authentication
and mobility, will utilize cloud based service APIs. Doing so
Ravindran, et al. Expires May 2, 2018 [Page 5]
Internet-Draft ICN in 5GC October 2017
enables opening up interfaces for authorized service function
interaction and creating service level extensions to support new
network architectures. These APIs include the well accepted Get/
Response and Pub/Sub approaches, while not precluding the use of
procedural approach between functional units (where necessary).
4. 5G NextGen Core Architecture
In this section, for brevity purposes, we restrict the discussions to
the control and user plane functions relevant to an ICN deployment.
More exhaustive discussions on the various architecture functions,
such as registration, connection and subscription management, can be
found in[TS23.501][TS23.502].
+---------+ +--------+
+--------+ | PCF/UDM | +------+ | AF-2 |
| NSSF | | | | AF-1 | +-----+--+
+---+----+ +-----+---+ +--+---+ |
| | | +--+--------+
+---+------------+-+ +-----+------+ | |
| |N11| | | SMF-2 |
| AMF +---+ SMF-1 | | |
| | | | +---------+-+
+--------+-+-------+ +----+-------+ |
| | |-----------------------------------+
+------------------+ | | |N4 |N4
N1 | |N2 |N4 | +--------+-----------+
| | | +---------+ UPF | N6 +------+
+-------------+-+ +----------+------+ +---+-----------+ | | |(PDU Session Anchor)+----+ DN |
| | | | | | N9 | | | | | |
| UE | | RAN | N3 | UL-CL +----+ | +--------------------+ +------+
| +-------+ +-----+ | |
| | | | | +----+ +-----------------+
+---------------+ +-----------------+ +---------------+ N9 | |
| +----------+---------+
+---------+ | +--------+
| UPF | N6 | DN |
|(PDU Session Anchor)+----+ |
| | +--------+
+--------------------+
Figure 1: 5G Next Generation Core Architecture
In Figure 1, we show one variant of a 5GC architecture from
[TS23.501], for which the functions of UPF's branching point and PDU
Ravindran, et al. Expires May 2, 2018 [Page 6]
Internet-Draft ICN in 5GC October 2017
session anchoring are used to support inter-connection between a UE
and the related service or packet data networks (or PDNs) managed by
the signaling interactions with control plane functions. In 5GC,
control plane functions can be categorized as follows:
o Common control plane functions that are common to all slices and
which include the Authentication and Mobility Function (AMF),
Network Slice and Selection Function (NSSF), Policy Control
Function (PCF), and Unified Data Management (UDM) among others.
o Shared or slice specific control functions, which include the
Session and Management Function (SMF) and the Application Function
(AF).
AMF serves multiple purposes: (i) device authentication and
authorization; (ii) security and integrity protection to non-access
stratum (NAS) signaling; (iii) tracking UE registration in the
operator's network and mobility management functions as the UE moves
among different RANs, each of which might be using different radio
access technologies (RAT).
NSSF handles the selection of a particular slice for the PDU session
request from the user entity (UE) using the Network Slice Selection
Assistance Information (NSSAI) parameters provided by the UE and the
configured user subscription policies in PCF and UDM functions.
Compared to LTE's evolved packet core (EPC), where PDU session states
in RAN and core are synchronized with respect to management, 5GC
decouples this using NSSF by allowing PDU sessions to be defined
prior to a PDU session request by a UE (for other differences see
[lteversus5g] ). This de-coupling allows policy based inter-
connection of RAN flows with slices provisioned in the core network.
SMF handles session management functions including IP address
assignment functionality, policy and service capabilities.
Furthermore, it manages the data plane state in the user plane
through PDU session establishment, modification and termination, and
management of RAN (through the AMF) and UPF states related to a
particular service or slice.
In the data plane, UE's PDUs are sent to the RAN using the 5G RAN
protocol [TS-5GNR]. From the RAN, the PDU's five tuple header
information (IP source/destination, port, protocol etc.) is used to
map the flow to an appropriate tunnel from RAN to UPF. The UPF in
this case also offers flexibility as a flow classifier and a
branching point interconnecting PDUs from diverse services (within
UEs) to their respective DNs. Though [TS23.501] follows LTE on using
GTP tunnel from NR to the UPF to carry data PDU and another one for
Ravindran, et al. Expires May 2, 2018 [Page 7]
Internet-Draft ICN in 5GC October 2017
the control messages to serve the control plane functions; there are
ongoing discussions to arrive upon efficient alternatives to GTP.
5. 5GC Architecture with ICN Support
In this section, we focus on control and user plane enhancements
required to enable ICN within 5GC, and identify the interfaces that
require extensions to support ICN PDU sessions. Explicit support for
ICN PDU sessions within access and 5GC networks will enable
applications to leverage the core ICN features while offering it as a
service to 5G users.
Ravindran, et al. Expires May 2, 2018 [Page 8]
Internet-Draft ICN in 5GC October 2017
+------------+
| 5G |
| Services |
| (NEF) | +----------------+
+-------+----+ | ICN |
| +----------+ Service |
| | | Orchestrator |
| | +-----------+----++
+-------+ +---------+ Npcf++/Nudm++ ++------+ |
| NSSF | | PCF/UDM +---------------------------------+ ICN-AF| |
+----+--+ | | | | +---+--------------+
| +--+------+ +---+---+ | ICN |
| | | +------+ Service/Network |
+-+--------+--+ +---------------+ +------+-------+ | | Controller |
| | N11++ | |Naf++ | +----+ +------------+-----+
| AMF++ +-----------+ SMF++ +------+ ICN-SMF | |
| | | | | | |
+------+-+----+ +----+-----+----+ +------------+-+ |
| | | | NIcn |
+-----------------+ | | +----------+ |
| | | | |
| +------+ N4 | | |
N1++ | | | | |
| | N2 | +------------+-+ +----+-----+
| | | +----------+ | | |
| | | | N9 | ICN-AP +--------+ ICN-DN |
| | +-----+-----+ | | + UPF | N6 | |
+------+--+ +---------+--+ | | | +---+----------+ +----------+
| | |RAN | | UL-CL/ +-----+
| ICN-UE +-------------+ +-----------+ Branching |
| | | +-------+ | N3 | Point +-----+ +------------+
+---------+ | | UL-CL | | +-----------+ | | Local |
| +-------+ | | N9 | ICN-DN |
+------------+ +-----------+ |
+------------+
Figure 2: 5G Next Generation Core Architecture with ICN support
For an ICN-enabled 5GC network, the assumption is that the UE may
have applications that can run over ICN or IP, for instance, UE's
operating system offering applications to operate over ICN [Jacobson]
or IP-based networking sockets. There may also be cases where UE is
exclusively based on ICN. In either case, we identify an ICN enabled
UE as ICN-UE. Different options exist to implement ICN in UE as
described in [I-D.suthar-icnrg-icn-lte-4g] which is also applicable
Ravindran, et al. Expires May 2, 2018 [Page 9]
Internet-Draft ICN in 5GC October 2017
for 5G UE to enable formal ICN session handling, such as, using a
transport convergence layer above 5G-NR, through IP address
assignment from 5GC or using 5GC provision of using unstructured PDU
session mode during the PDU session establishment process. 5G UE can
also be non-mobile devices or an IOT device using radio specification
which can operate based on [TS-5GNR].
5GC will take advantage of network slicing function to instantiate
heterogeneous slices, the same framework can be extended to create
ICN slices as well [Ravindran]. This discussion also borrows ideas
from[TS23.799], which offers a wide range of architectural
discussions and proposals on enabling slices and managing multiple
PDU sessions with local networks (with MEC) and its associated
architectural support (in the service, control and data planes) and
procedures within the context of 5GC.
Figure 2 shows the proposed ICN-enabled 5GC architecture. In the
figure, new/modified functional components are identified to
interconnect an ICN-DN with 5GC. The interfaces and functions that
require extensions to enable ICN as a service in 5GC can be
identified in the figure with a '++' symbol. We next summarize the
control, user plane and normative interface extensions that help with
the formal ICN support.
5.1. Control Plane Extensions
To support interconnection between ICN UEs and the appropriate ICN DN
instances, we require five additional control plane extensions, which
are discussed as follows.
o Authentication and Mobility Function (AMF++) : Applications in the
UEs have to be authorized to access ICN DNs. For this purpose, as
in[TS23.501], operator enables ICN as a service-DN to support ICN
PDU session flows. As a network service, ICN-UE should also be
subscribed to it and this is imposed using the PCF and User Data
and Management (UDM) functions, which may interface with the ICN
Application Function (ICN-AF) for policy management of ICN PDU
sessions. Hence, if the UE policy profile in the UDM doesn't
enable this feature, then the ICN applications in the UE will not
be allowed to connect to ICN DNs. To enable ICN stack in the UE,
AMF function has to be modified to understand ICN type UE
registration request and handle authentication and registration
requests. AMF++ will support ICN specific bootstrapping and
forwarding functions (such as naming and security) to configure
UE's ICN applications. With appropriate enhancements, it should
also support forwarding rules for the name prefixes that bind the
flows to appropriate 5G-NR logical tunnel or slice interfaces.
These functions can also be handled by the ICN-AF after setting
Ravindran, et al. Expires May 2, 2018 [Page 10]
Internet-Draft ICN in 5GC October 2017
PDU session state in 5GC. Here, we are not recommending
modification of 5G UE attach procedures but use existing attach
procedures messages to carry ICN capabilities extensions in
addition to supporting existing IP based services. 5G UE can
request authentication for attaching to 5GC either in ICN, IP or
dual-stack (IP and ICN) modes.
o Session Management Function (SMF++) : Once a UE is authenticated
to access ICN service in network, SMF manages to connect UE's ICN
PDU sessions to the ICN DN. SMF++ capabilities should be able to
manage both IP, ICN or dual stack UE with IP and ICN capabilities.
SMF++ creates appropriate PDU session policies in the UPF, which
include UL-CL and ICN anchor point (ICN-AP). For centrally
delivered services, ICN-AP could also be an IP anchor point for IP
applications. If MEC is enabled, these two functions would be
distributed, as the UL-CL will re-route the flow to a local ICN-
DN. SMF++ interfaces with AMF over N11++ to enable ICN specific
user plane function, which includes IP address configuration and
associated traffic filter policy to inter-connect UE with the
appropriate radio slice. Furthermore, AMF++ sets appropriate
state in the RAN that directs ICN flows to chosen ICN UL-CL.
o ICN Session Management Function (ICN-SMF) : ICN-SMF serves as
control plane for the ICN state managed in ICN-AP. This function
interacts with SMF++ to obtain and also push ICN PDU session
management information for the creation, modification and deletion
of ICN PDU sessions in ICN-AP. For instance, when new ICN slices
are provisioned by the ICN service orchestrator, ICN-SMF requests
a new PDU session to the SMF++ that extends to the RAN and UE.
While SMF++ manages the tunnels to interconnect ICN-AP to UL-CL,
ICN-SMF creates the appropriate forwarding state in ICN (using the
forwarding information base or FIB) to enable ICN flows over
appropriate tunnel interfaces managed by the SMF++.
o ICN Application Function (ICN-AF) : ICN-AF represents the
application controller function that interfaces with ICN-SMF and
user data management (UDM) function in 5GC. In addition to
transferring ICN forwarding rules to ICN-SMF, ICN-AF also
interfaces with UDM to transfer user profile and subscription
policies required to map UE's ICN PDU session request to an
appropriate ICN slice through NSSF. ICN-AF is an extension of the
ICN service orchestration function, which can influence both ICN-
SMF and UPF to steer traffic based on UE (or changing service)
requirements. ICN-AP can also interact with the northbound 5G
operator's service functions, such as network exposure function
(NEF) that exposes network capabilities, for e.g. location based
services, that can be used by ICN-AF for proactive ICN PDU session
and slice management and offer additional capabilities to UE.
Ravindran, et al. Expires May 2, 2018 [Page 11]
Internet-Draft ICN in 5GC October 2017
5.1.1. Normative Interface Extensions
o N1++/N11++: This extension enables ICN specific control extensions
to support ICN programmability at the UE via AMF++, and also
impose QoS requirements to ICN PDU session in 5GC based on service
requirements.
o NIcn: This extension shall support two functions: (i) control
plane programmability to enable ICN PDU sessions applicable to 5GC
to map to name based forwarding rules in ICN-AP; (ii)control plane
extensions to enable ICN mobility anchoring at ICN-AP, in which
case it also acts as POA for ICN flows. Features such as ICN
mobility as a service can be supported with this extension [mas].
o Naf++: This extensions shall support 5GC control functions such as
(i.e. naming, addressing, registration/authentication and
mobility) for ICN UE and PDU sessions respectively with
interaction with the PCF and UDM functions. The PCF and UDM
functions interacts with ICN-AF function for service or slice
specific configuration.
o Npcf++/Nudm++: This extension creates an interface to push ICN PDU
session requirement to PCF and UDM functions, which is enforced
during ICN application registration, authentication, during ICN
slice mapping, and provisioning of resources for these PDU
sessions in the UPFs.
5.2. User Plane Extensions
As explained in detail in [TS23.501], UPFs are service agnostic
functions, hence extensions are not required to operate an ICN-DN.
The inter-connection of UE to ICN-DN comprises of two segments, one
from RAN to UL-CL and the other from UL-CL to ICN-AP. These segments
use IP tunneling constructs, where the service semantic check at UL-
CL and ICN-AP is performed using IP's five tuples to determine both
UL and DL tunnel mappings. We summarize the relevant UPFs and the
interfaces for handling ICN PDU sessions as follows.
o ICN Anchor Point (ICN-AP): ICN-AP shall host the 5GC PDU sessions
and offer inter-connection to the ICN-DNs. It manages multiple
logical interfaces with ICN capable UE and relays ICN packets to
the appropriate ICN PDU session instances in the DL. ICN-AP shall
be logical service anchor point and it should be capable of
serving different ICN services. ICN-AP also manages the mobility
state of ICN-UE after session is established such as in the case
of handover or roaming.
Ravindran, et al. Expires May 2, 2018 [Page 12]
Internet-Draft ICN in 5GC October 2017
o ICN Packet Data Network (ICN-(P)DN) : ICN-DN represents a set of
ICN nodes used for ICN networking and with heterogeneous service
resources such as storage and computing points. An ICN network
enables both network and application services, with network
services including caching, mobility, multicast, multi-path
routing (and possibly network layer computing), and application
services including network resources (such as cache, storage,
network state resources) dedicated to the application. This UPF
requires service, control and data plane mechanisms to understand
the application requirements and translate them to control
signaling to provision the required state in the data plane.
o Uplink Classifier (UL-CL) :UL-CL enables classification of flows
based on source or destination IP address and steers the traffic
to an appropriate network or service function anchor point.
Within the current context, with the assumption that ICN-AP is
identified based on service IP address associated with the UE's
flows, UL-CL checks the source or destination address to direct
traffic to an appropriate ICN-AP. As UL-CL is a logical function,
it can also reside in RAN, as shown in Figure 2, where traffic
classification rules can be applied to forward the ICN payload
towards the next ICN-AP, as an extension classification can also
be performed over 5G-NR or ICN protocol to determine the next
logical hop. For native ICN UE, ICN shall be deployed on layer-2
MAC, hence there may not be any IP association; for such packet
flow, new classification schema shall be required.
5.2.1. Normative Interface Extensions
o N3: Though the current architecture supports heterogeneous service
PDU handling, future extensions can include user plane interface
extensions to offer explicit support to ICN PDU session traffic,
for instance, an incremental caching and computing function in RAN
or UL-CL to aid with content distribution.
o N9: Extensions to this interface can consider UPFs to enable
richer service functions, for instance to aid context processing.
In addition extensions to enable ICN specific encapsulation to
piggyback ICN specific attributes such as traffic characteristics
between the UPF branching point and the ICN-AP. The intermediate
nodes between the UL-CL and the ICN-AP can also be other caching
points.
o N6: This interface is established between the ICN-AP and the ICN-
DN, whose networking elements in this segment can be deployed as
an overlay or as a native Layer-3 network.
Ravindran, et al. Expires May 2, 2018 [Page 13]
Internet-Draft ICN in 5GC October 2017
6. ICN Deployement Use Case Scenarios
Here we discuss two relevant network services enabled using ICN in
5G.
6.1. Mobile Edge Computing
We consider here a radio edge service requiring low latency, high
capacity and strict quality of service. For the discussion in this
draft, we analyze connected vehicle scenario, where the car's
navigation system (CNS) uses data from the edge traffic monitoring
(TM-E) service instance to offer rich and critical insights on the
road conditions (such as real-time congestion assisted with media
feeds). This is aided using traffic sensing (TS) information
collected through vehicle-to-vehicle (V2V) communication over
dedicated short-range communications (DSRC) radio by the TS-E, or
using road-side sensor units (RSU) from which this information can be
obtained. The TS-E instances then push this information to a central
traffic sensing instance (TS-C). This information is used by the
central traffic monitoring service (TM-C) to generate useable
navigation information, which can then be periodically pushed to or
pulled by the edge traffic monitoring service (TM-E) to respond to
requests from vehicle's CNS. For this scenario, our objective is to
compare advantages of offering this service over an IP based MEC
versus one based on ICN. We can generalize the following discussion
to other MEC applications as well.
6.1.1. IP-MEC Scenario
Considering the above scenario, when a vehicle's networking system
comes online, it first undergoes an attachment process with the 5G-
RAN, which includes authentication, IP address assignment and DNS
discovery. The attachment process is followed by PDU session
establishment, which is managed by SMF signaling to UL-CL and the UPF
instance. When the CNS application initializes, it assumes this IP
address as its own ID and tries to discover the closest service
instance. Local DNS then resolves the service name to a local MEC
service instance. Accordingly, CNS learns the IP service point
address and uses that to coordinate between traffic sensing and
monitoring applications.
CNS is a mission critical application requiring instant actions which
is accurate and reliable all the time. Delay of microsecond or non-
response could result in fatalities. Following are main challenges
with the IP-MEC design:
o At the CNS level, non-standardization of the naming schema results
in introducing an application level gateway to adapt the sensing
Ravindran, et al. Expires May 2, 2018 [Page 14]
Internet-Draft ICN in 5GC October 2017
data obtained from DSRC system to IP networks, which becomes
mandatory if the applications are from different vendors.
o As the mobility results in handover between RAN instances,
service-level or 5GC networking-level mechanisms need to be
initiated to discover a better TM-E instance, which may affect the
service continuity and result in session reestablishment that
introduces additional control/user plane overheads.
o Data confidentiality among multiple CNS attached 5G RAN,
authentication and privacy control are offered through an SSL/TLS
mechanism over the transport channel, which has to be re-
established whenever the network layer attributes are reset.
6.1.2. ICN-MEC Scenario
If the CNS application is developed over ICN either natively or as an
overlay over IP, ICN shall allows the same named data logic to
operate over heterogeneous interfaces (such as DSRC radio, and IP
transport-over-5G, unlicensed radio over WiFi etc. link), thereby
avoiding the need for application layer adaptations.
We can list the advantages of using ICN-based MEC as follows:
o As vehicles within a single road segment are likely to seek the
same data, ICN-based MEC allows to leverage opportunistic caching
and storage enabled at ICN-AP, thereby avoiding service level
unicast transmissions.
o Processed and stored traffic data can be easily contextualized to
different user requirements.
o Appropriate mobility handling functions can be used depending on
mobility type (as consumer or producer), specifically, when an
ICN-UE moves from one RAN instance to another, the next IP hop,
which identifies the ICN-AP function, has to be re-discovered.
Unlike the IP-MEC scenario, this association is not exposed to the
applications. As discussed earlier, control plane extensions to
AMF and SMF can enable re-programmability of the ICN layer in the
vehicle to direct it towards a new ICN-AP, or to remain with the
same ICN-AP, based on optimization requirements.
o As ICN offers content-based security, produced content can be
consumed while authenticating it at the same time (i.e., allowing
any data produced to diffuse to its point of use through named
data networking).
Ravindran, et al. Expires May 2, 2018 [Page 15]
Internet-Draft ICN in 5GC October 2017
6.2. ICN Session Mobility
Mobility scenario assumes a general ICN-UE handover from S-RAN to
T-RAN, where each of them is served by different UPFs, i.e., UL-CL-1
and UL-CL-2. We also assume that UL-CL-1 and UL-CL-2 use different
ICN-APs as gateways, referred to as ICN-AP-1 and ICN-AP-2. From an
ICN perspective, we discuss here the producer mobility case, which
can be handled in multiple ways, one of which is proposed in
[mas].However, the details of the ICN mobility solution are
orthogonal to this discussion. Here, ICN-UE refers to an application
producer (e.g., video conferencing application, from which ICN
consumers request real-time content. Here we also assume the absence
of any direct physical interface, Xn, between the two RANs. The
current scenario follows the handover procedures discussed in
[TS23.502], with focus here on integrating it with an ICN-AP and ICN-
DN, where mobility state of the ICN sessions are handled.
The overall signaling overhead to handle seamless mobility also
depends on the deployment models discussed in Section 4. Here we
consider the case when RAN, UL-CL and ICN-AP are physically disjoint;
however in the case where RAN and UL-CL are co-located then a part of
the signaling to manage the tunnel state between the RAN and UL-CL is
localized, which then improves the overall signaling efficiency.
This can be further extended to the case when ICN-APs are co-located
with the RAN and UL-CL, leading to further simplification of the
mobility signaling.
Next, we discuss the high-level steps involved during handover.
o Step 1: When the ICN-UE decides to handover from S-RAN to T-RAN,
ICN-UE signals the S-RAN with a handover-request indicating the
new T-RAN it is willing to connect. This message includes the
affected PDU session IDs from the 5GC perspective, along with the
ICN names that require mobility support.
o Step 2: S-RAN then signals the AMF serving the ICN-UE about the
handover request. The request includes the T-RAN details, along
with the affected ICN PDU sessions.
o Step 3: Here, when SMF receives the ICN-UE's and the T-RAN
information, it identifies UL-CL-2 as the better candidate to
handle the ICN PDU sessions to T-RAN. In addition, it also
identifies ICN-AP-2 as the appropriate gateway for the affected
ICN PDU sessions.
o Step 4: SMF signals the details of the affected PDU sessions along
with the traffic filter rules to switch the UL traffic from UL-
CL-2 to ICN-AP-2 and DL flows from UL-CL-2 to T-RAN.
Ravindran, et al. Expires May 2, 2018 [Page 16]
Internet-Draft ICN in 5GC October 2017
o Step 5: SMF then signals ICN-SMF about the PDU session mobility
change along with the information on UL-CL-2 for it to provision
the tunnel between ICN-AP-2 and UL-CL-2.
o Step 6: Based on the signaling received on the ICN PDU session,
ICN-SMF identifies the affected gateways, i.e., ICN-AP-1 and ICN-
AP-2: (i) ICN-SMF signals ICN-AP-2 about the affected PDU session
information to update its DL tunnel information to UL-CL-2. Then,
based on the ICN mobility solution, appropriate ICN mobility state
to switch the future incoming Interests from ICN-AP-1 to UL-CL-2;
(ii) ICN-SMF also signals ICN-AP-1 with the new forwarding
label[mas] to forward the incoming Interest traffic to ICN-AP-2.
This immediately causes the new Interest payload for the ICN-UE to
be send to the new ICN gateway in a proactive manner.
o Step 7: ICN-SMF then acknowledges SMF about the successful
mobility update. Upon this, the SMF then acknowledges AMF about
the state changes related to mobility request along with the
tunnel information that is required to inter-connect T-RAN with
UL-CL-2.
o Step 8: AMF then updates the T-RAN PDU session state in order to
tunnel ICN-UE's PDU sessions from T-RAN to UL-CL-2. This is
followed by initiating the RAN resource management functions to
reserve appropriate resources to handle the new PDU session
traffic from the ICN-UE.
o Step 9: AMF then signals the handover-ack message to the UE,
signaling it to handover to the T-RAN.
o Step 10: UE then issues a handover-confirm message to T-RAN. At
this point, all the states along the new path comprising the
T-RAN, UL-CL-2 and ICN-AP-2 is set to handle UL-DL traffic between
the ICN-UE and the ICN-DN.
o Step 11: T-RAN then signals the AMF on its successful connection
to the ICN-UE. AMF then signals S-RAN to remove the allocated
resources to the PDU session from the RAN and the tunnel state
between S-RAN and UL-CL-1.
o Step 12: AMF then signals SMF about the successful handover, upon
which SMF removes the tunnel states from UL-CL-1. SMF then
signals the ICN-SMF, which then removes the ICN mobility state
related to the PDU session from ICN-AP-1. Also at this point,
ICN-SMF can signal the ICN-NRS (directly or through ICN-AP-2) to
update the UE-ID resolution information, which now points to ICN-
AP-2 [mas].
Ravindran, et al. Expires May 2, 2018 [Page 17]
Internet-Draft ICN in 5GC October 2017
Note that, inter-RAN handover mapping to the same UL-CL represents a
special case of the above scenario.
7. Conclusion
In this draft, we explore the feasibility of realizing future
networking architectures like ICN within the proposed 3GPP's 5GC
architecture. Towards this, we summarized the design principles that
offer 5GC the flexibility to enable new network architectures. We
then discuss 5GC architecture along with the user/control plane
extensions required to handle ICN PDU sessions formally. We then
apply the proposed architecture to two relevant services that ICN
networks can enable: first, mobile edge computing over ICN versus the
traditional IP approach considering a connected car scenario, and
argue based on architectural benefits; second, handling ICN PDU
session mobility in ICN-DN rather than using IP anchor points, with
minimal support from 5GC.
8. IANA Considerations
This document requests no IANA actions.
9. Security Considerations
This draft proposes extensions to support ICN in 5G's next generation
core architecture. ICN being name based networking opens up new
security and privacy considerations which have to be studied in the
context of 5GC. This is in addition to other security considerations
of 5GC for IP or non-IP based services considered in [TS33.899].
10. Acknowledgments
...
11. Informative References
[I-D.rahman-icnrg-deployment-guidelines]
Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran,
"Deployment Considerations for Information-Centric
Networking (ICN)", draft-rahman-icnrg-deployment-
guidelines-04 (work in progress), October 2017.
[I-D.suthar-icnrg-icn-lte-4g]
suthar, P., Stolic, M., Jangam, A., and D. Trossen,
"Native Deployment of ICN in LTE, 4G Mobile Networks",
draft-suthar-icnrg-icn-lte-4g-03 (work in progress),
September 2017.
Ravindran, et al. Expires May 2, 2018 [Page 18]
Internet-Draft ICN in 5GC October 2017
[IEEE_Communications]
Trossen, D. and G. Parisis, "Designing and Realizing an
Information-Centric Internet", Information-Centric
Networking, IEEE Communications Magazine Special Issue,
2012.
[Jacobson]
Jacobson, V. and et al., "Networking Named Content",
Proceedings of ACM Context, , 2009.
[lteversus5g]
Kim, J., Kim, D., and S. Choi, "3GPP SA2 architecture and
functions for 5G mobile communication system.", ICT
Express 2017, 2017.
[mas] Azgin, A., Ravidran, R., Chakraborti, A., and G. Wang,
"Seamless Producer Mobility as a Service in Information
Centric Networks.", 5G/ICN Workshop, ACM ICN Sigcomm 2016,
2016.
[Ravindran]
Ravindran, R., Chakraborti, A., Amin, S., Azgin, A., and
G. Wang, "5G-ICN : Delivering ICN Services over 5G using
Network Slicing", IEEE Communication Magazine, May, 2016.
[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
"Information-Centric Networking (ICN) Research
Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
<https://www.rfc-editor.org/info/rfc7927>.
[TS-5GNR] 3GPP-38-xxx, "Technical Specification series on 5G-NR
(Rel.15)", 3GPP , 2017.
[TS23.501]
3gpp-23.501, "Technical Specification Group Services and
System Aspects; System Architecture for the 5G System
(Rel.15)", 3GPP , 2017.
[TS23.502]
3gpp-23.502, "Technical Specification Group Services and
System Aspects; Procedures for the 5G System(Rel. 15)",
3GPP , 2017.
Ravindran, et al. Expires May 2, 2018 [Page 19]
Internet-Draft ICN in 5GC October 2017
[TS23.799]
3gpp-23.799, "3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects;
Study on Architecture for Next Generation System (Rel.
14)", 3GPP , 2017.
[TS33.899]
3gpp-33.899, "Study on the security aspects of the next
generation system", 3GPP , 2017.
[VSER] Ravindran, R., Liu, X., Chakraborti, A., Zhang, X., and G.
Wang, "Towards software defined ICN based edge-cloud
services", CloudNetworking(CloudNet), IEEE Internation
Conference on, IEEE Internation Conference on
CloudNetworking(CloudNet), 2013.
Authors' Addresses
Ravi Ravindran
Huawei Research Center
2330 Central Expressway
Santa Clara 95050
USA
Email: ravi.ravindran@huawei.com
URI: http://www.Huawei.com/
Prakash Suthar
Cisco Systems
9501 Technology Blvd.
Rosemont 50618
USA
Email: psuthar@cisco.com
URI: http://www.cisco.com/
Guoqiang Wang
Huawei Research Center
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: gq.wang@huawei.com
Ravindran, et al. Expires May 2, 2018 [Page 20]