ICN Research Group Prakash Suthar
Internet-Draft Milan Stolic
Intended status: Informational Anil Jangam
Cisco Systems Inc.
Expires: September 29, 2017 March 28 2017
Native Deployment of ICN in 3G, LTE, 4G Mobile Networks
draft-suthar-icnrg-icn-lte-4g-00
Abstract
Mobile networks using LTE, 4G are complex. Managing mobility and
content delivery using IP is complex and not optimized. IP unicast
routing from server to clients is used for delivery of multimedia
content to User Equipment (UE), where each user gets separate stream.
From bandwidth and routing perspective this approach is inefficient.
Multicast and broadcast technologies have emerged recently for mobile
networks, but their deployments are very limited or at an
experimental stage due to complex architecture and radio spectrum
issues. ICN is a rapidly evolving technology for efficient multimedia
content delivery, however majority of the work is focused either on
fixed networks or unlicensed WiFi-based wireless networks. The main
focus of this draft is on native deployment of ICN in cellular mobile
networks by embedding into 3GPP protocol stack at IP level or
replacing IP for non-IP datagrams. ICN has an inherent capability for
anchorless mobility, security and it is optimized for content
delivery using local caching at the edge. We believe that native or
dual stack (with IP) deployment will bring all inherent benefits of
ICN and help in optimizing mobile networks.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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".
Prakash, et.al. Expires September 29, 2017 [Page 1]
Internet-Draft Deploying ICN in 5G/LTE Mobile Networks March 28 2017
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License 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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. LTE, 4G Mobile Network . . . . . . . . . . . . . . . . . . . . 3
2.1 Typical Network Overview . . . . . . . . . . . . . . . . . 3
2.2 Virtualizing Mobile Networks . . . . . . . . . . . . . . . 5
3. Content Delivery using IP Transport . . . . . . . . . . . . . 5
4. Content Delivery using ICN Protocol . . . . . . . . . . . . . 6
5. ICN Deployment in LTE Mobile Networks . . . . . . . . . . . . 7
5.1 ICN Deployments for Mobility Management . . . . . . . . . . 8
5.2 Deploying ICN Protocol in Mobile Devices . . . . . . . . . 10
5.2.1 Dual stack or triple stack (IPv4, IPv6, IPv4v6, ICN) . 10
5.2.1 Native ICN deployment in UE . . . . . . . . . . . . . . 11
5.3 ICN Deployment in Base Station (BS) . . . . . . . . . . . . 12
5.3.1 ICN Deployment in SGW/PGW . . . . . . . . . . . . . . . 14
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1 Normative References . . . . . . . . . . . . . . . . . . . 17
7.2 Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Prakash, et.al. Expires September 29, 2017 [Page 2]
Internet-Draft Deploying ICN in 5G/LTE Mobile Networks March 28 2017
1 Introduction
Currently LTE, 4G and future 5G mobile networks use IP as payload for
content delivery, and standardized routing protocols such as OSPF,
ISIS, BGP etc. for transport. With LTE/4G technology mobile network
is all IP network. When UE is powered up, it establishes a radio link
with closest base station (BS). After radio link establishment, UE
performs attach procedures (as documented in 3GPP TS23.401) which
include authentication, authorization, mobility management and
session establishment with mobile core. For one successful attach
procedure, mobile gateway (PGW) creates one session per UE and
assigns IP address(es) based on how many services are created
[TS23.401].
One of the biggest challenges with IP routing is that it is not
optimized for content delivery even though it is the efficient
routing protocol. ICN offers an opportunity to re-architect mobile
networks by leveraging inherent capabilities of seamless anchorless
mobility, authentication and optimized signaling.
1.1 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 RFC 2119 [RFC2119].
2. LTE, 4G Mobile Network
2.1 Typical Network Overview
With the introduction of LTE/4G systems transport and signaling for
mobile networks are migrated to all-IP, covering all elements as
outlined in Figure-1. "IP Design for Mobile Networks"[GRAYSON]
provides detailed 3GPP interface design and call flows.
For each UE attached to the Base station (BS) and with successful
authentication with mobile core, there is a separate dedicated
overlay GTP (GPRS Tunneling Protocol) between BS and Serving Gateway
(SGW), Packet Data Network Gateway (PGW). For high level
understanding we can consider this architecture as hub (PGW) and
spoke (UE) because for each attached UE there is GTP tunnel between
BS to SGW/PGW.
Prakash, et.al. Expires September 29, 2017 [Page 3]
Internet-Draft Deploying ICN in 5G/LTE Mobile Networks March 28 2017
+-------+ Diameter +-------+
| HSS |------------| SPR |
+-------+ +-------+
| |
+------+ +------+ S4 | +-------+
|2G/3G |---| SGSN |----------------|------+ +------| PCRF |
^ | BS | | |---------+ +---+ | | +-------+
+-+ | +------+ +------+ S3 | | S6a | |Gxc |
| | | +-------+ | | |Gx
+-+ | +------------------| MME |------+ | | |
UE v | S1MME +-------+ S11 | | | |
+----+-+ +-------+ +-------+
|4G/LTE|------------------------------| SGW |-----| PGW |
| BS | S1U +-------+ +--| |
+------+ | +-------+
+---------------------+ | |
S1U GTP Tunnel traffic | +-------+ | |
S2a GRE Tunnel traffic |S2A | ePDG |-------+ |
S2b GRE Tunnel traffic | +-------+ S2B |SGi
SGi IP traffic | | |
+---------+ +---------+ +-----+
| Trusted | |Untrusted| | CDN |
|non-3GPP | |non-3GPP | +-----+
+---------+ +---------+
| |
+-+ +-+
| | | |
+-+ +-+
UE UE
Figure-1: LTE, 4G Mobile Network Overview
It is also important to understand the GTP tunnel overhead because
this has impact on bandwidth available for actual user traffic. For
average packet size of ~500 bytes GTP overhead is ~15%. Additionally,
if IPSec is used for security (which is often required if the Service
provider is using a 3rd party backhaul network), then it will add
~15-23% overhead based upon transport/tunneling model, and encryption
and authentication header algorithms used [IPSEC]. The content
delivered to mobile devices is unicast inside GTP tunnel. If the
impact of GTP, IPSec and unicast traffic is combined, the content
delivery is not efficient. For radio protocols we can use different
header compression mechanisms to reduce the overhead impact, but gain
is not significant. For example, by using some of the header
compression mechanisms like robust header compression (ROHC) and
enhanced compression of the real-time transport protocol (ECRTP),
impact of overhead created by GTP, IPsec etc. is reduced to some
extent [BROWER]. For commercial mobile networks 3GPP has adopted
Prakash, et.al. Expires September 29, 2017 [Page 4]
Internet-Draft Deploying ICN in 5G/LTE Mobile Networks March 28 2017
different header compression mechanism to achieve efficiency in
content delivery [TS23.323] which can also be used in ICN to further
improve efficiencies.
2.2 Virtualizing Mobile Networks
Typical mobile networks are built to support millions of subscribers,
however virtualization with network slicing provides a mechanism
where network can be segmented and personalized to provide specific
set of services for enterprise applications, Mobile Virtual Network
Operators (MVNO), public safety virtual networks etc. Virtual packet
cores are opening way for many innovative use cases applicable to
enterprise markets, however most of these use cases are for smaller
throughput but complex policy and specialized services.
Although virtualization is growing, the call flow is still the same,
therefore issues related to ICN are the same for traditional and
virtual mobile networks. There is also work underway to separate
control and user plane so that the network can scale better.
Virtualized mobile networks and network slicing with control and user
plane separation provide mechanism to evolve GTP-based architecture
to open-flow SDN-based signaling. Protocol evolution to open-flow is
still under study and research at 3GPP.
3. Content Delivery using IP Transport
As mentioned earlier, content delivery in today's mobile networks is
mostly unicast as described in 3GPP specification [TS23.401]. While
the technology exists to address the issue of possible multicast
delivery, there are many difficulties related to the implementation
in the core and radio access network (RAN). As shown in Figure-1,
user plane traffic is encapsulated inside GTP tunnel for UE attached
using 3GPP interface, and GRE tunnel for UE attached using non-3GPP
trusted and un-trusted interfaces. Tunneled traffic from UE gets de-
capsulated at PGW and forwarded as native IP datagram on SGi
interface towards Content Data Network (CDN).
Many Service Provides use CDN caching in their networks to optimize
content delivery, however caching servers are located in SGi network
which is at centralized location in the Service Provider's Data
Center. Distribution of caching servers at the edge is limited due
to deployment challenges and issues related to GTP tunnel termination
at PGW. This is a very inefficient concept because traffic has to
traverse the entire backhaul path for the content to be delivered to
the end-user. The issue of inefficient traffic path to deliver the
content has to be addressed from a different perspective, by
Prakash, et.al. Expires September 29, 2017 [Page 5]
Internet-Draft Deploying ICN in 5G/LTE Mobile Networks March 28 2017
considering caching at edge and
4. Content Delivery using ICN Protocol
Content delivery using ICN is different compared to the IP-based
systems because it uses two simple types of messages, namely Interest
and Data packet. Communication in ICN takes place between UE
(Consumer/publisher) and content provider (publisher), where
intermediate nodes facilitate delivery of content from the closest
edge location if it has been cached. Details of the message are given
in Figure-2 [ICN]
+------------------------------------+
Interest | +------+ +------+ +------+ | +-----+
+-+ ---->| CS |---->| PIT |---->| FIB |--------->| CDN |
| | | +------+ +------+ +------+ | +-----+
+-+ | | Add | Drop | | Forward
UE <--------+ Intf v Nack v |
Data | |
+------------------------------------+
+------------------------------------+
+-+ | Forward +------+ | +-----+
| | <-------------------------------------| PIT |<---------| CDN |
+-+ | | Cache +--+---+ | Data +-----+
UE | +--v---+ | |
| | CS | v |
| +------+ Discard |
+------------------------------------+
Figure-2: ICN Protocol Architecture
Every node in a physical path between a client and a content provider
is called ICN forwarder or router, and it has the ability to route
the request intelligently and also cache the content so that it can
be delivered locally for subsequent request from any client.
For mobile network, transport between a client and a content provider
consists of several hops e.g. RAN, BS, Mobile Backhaul (MBH), IP core
(CORE), Mobile Gateways (SGW/PGW) and CDN. Each of these elements are
further connected using routing and switching. In order to perform
mobile edge computing [MECSPEC] at base station, the MEC function is
introduced. MEC has the capability of processing client requests and
segregating control and user traffic at the BS rather than sending
all requests to the mobile gateways. MEC transforms radio into an
intelligent service edge that is capable of delivering highly
Prakash, et.al. Expires September 29, 2017 [Page 6]
Internet-Draft Deploying ICN in 5G/LTE Mobile Networks March 28 2017
personalized services from the edge of the network, while providing
the best possible performance to the UE. MEC can be an ideal
candidate for ICN forwarder in addition to its usual function. MEC
can be physical or virtual network function (VNF), and can be co-
hosted or integrated with either BS, cell site router or cloud RAN
(C-RAN) function. In addition to MEC other transport elements, such
as routers, can work as ICN forwarders as well.
ICN uses two types of packets called "interest packet" and "data
packet". Protocol architecture is defined but evolving based on
active research and adding more capabilities. There are two
variations of ICN implementations referred to as Content Centric
Networking [CCN] and Named Data Networking [NDN]. The implementation
difference between CCN and NDN is mainly related to the forwarding
strategy, name resolution and underlying security architecture.
Interest packet contains information such as Name of content,
selectors filter which contains information about the order in which
content is required, details of content provider or publisher(s) such
as exclude/include filters etc. Nonce field is used to sign the
packet where signature is put by a client. Guider field contains
information such as lifetime and scope for packet. First ICN router
will receive Interest packet and perform lookup if request for such
content has come earlier from any other client. If yes it is served
from the local cache, otherwise request is forwarded to the next-hop
ICN router. Each ICN router maintains three data structures, namely
Pending Interest Table (PIT), Forwarding Information Base (FIB), and
Content Store (CS). The Interest packet travels hop-by-hop towards
content provider. Once the Interest reaches the content provider it
will return a Data packet containing information such as content
name, signature, signed key and data itself. Data packet travels in
reverse direction following the same path taken by the interest
packet so routing symmetry is maintained. Details about algorithms
used in PIT, FIB, CS and security trust models are described in
different documents [CCN],[NDN]
5. ICN Deployment in LTE Mobile Networks
LTE Mobile Network is quite complex with many different
elements/functions, so it is important to analyze many different
options to gradually deploy ICN without impacting performance and
subscriber experience. Figure-3 provides high-level protocol level
description of different elements such as UE, BS, Serving Gateway
(SGW) and PDN Gateway (PGW).
LTE mobile networks contain control plane (to handle signaling for
mobility managements) and user plane (for delivery of contents). We
analyzed different options for deploying ICN without
Prakash, et.al. Expires September 29, 2017 [Page 7]
Internet-Draft Deploying ICN in 5G/LTE Mobile Networks March 28 2017
degrading/impacting performance.
+---------+ +---------+
| App | | CDN |
+---------+ +---------+
| ICN | | ICN |
|Forwarder|..|.................|................|..|Forwarder|
+---------+ | | | +---------+
|ICN | IP |..|.................|................|..|ICN | IP |
| | | | | | | | |
+---------+ | +-----------+ | +----------+ | +---------+
| | | | Relay | | | Relay | | | |
| PDCP | | |-----------| | |----------| | | PDCP |
| |..|..| | |..|..| | |..|..| |
| | | |PDCP|GTP-U | | |PDCP|GTP-U| | | |
+---------+ | +-----------+ | +----------+ | +---------+
| RLC |..|..|RLC |UDP/IP|..|..|UDP | UDP |..|..| RLC |
+---------+ | +-----------+ | +----------+ | +---------+
| MAC |..|..| MAC | L2 |..|..| L2 | L2 |..|..| MAC |
+---------+ | +-----------+ | +----------+ | +---------+
| L1 |..|..| L1 | L1 |..|..| L1 | L1 |..|..| L1 |
+---------+ | +-----------+ | +----------+ | +---------+
UE | BS(enodeB) | SGW | PGW
LTE-uu S1-U S5/S8
Figure-3: ICN Deployment in LTE Mobile Networks
5.1 ICN Deployments for Mobility Management
Mobility management includes signaling messages associated with Non-
Acess Stratum (NAS). In this section we analyzed different mobility
management messages and if there is any benefit to replace IP-based
protocols for NAS signaling in the current architecture. It is
important to understand a concept of point of attachment (POA)
because it provides session management from the initial attachment to
detachment (power off, handover, roaming to other network etc.). Also
it is important to understand UE identity mechanism because it is
used during the entire session management. Mobile devices have
identities parameters such as IMSI, MSISDN, IMEI, IP Address and
subscriber profiles. It is important to understand each parameter and
its impact on mobility and session management.
When UE connects to a network it has at least three points of
attachment: (1) Base Station (BS) managing location or physical POA,
(2) Authentication and Authorization (MME/SGSN, HSS/HLR, AAA etc.)
managing identity or authentication POA and (3) Mobile Gateways
Prakash, et.al. Expires September 29, 2017 [Page 8]
Internet-Draft Deploying ICN in 5G/LTE Mobile Networks March 28 2017
(SGW, PGW, GGSN, PDSN/HA) managing logical or session management POA.
Although most of ICN research documents state that it supports
seamless mobility for any device or that mobility is built into ICN
protocols, it might complicate cellular mobile networks [TS23.401].
We need to analyze impact of POA on mobility management because we
want to maintain uninterrupted content delivery when mobile device
changes physical locations or uses different access mechanism. For
mobile devices location and physical identity split is a fundamental
requirement at network layer (IP) to handle mobility. Unique and
stable identifiers of network hosts and information objects enable
uninterrupted content delivery irrespective of mobile device's
location. If the device is attached to one gateway then we can use IP
address, but research has shown that IP addressing does not satisfy
this property because for multiple PDN connections device is assigned
many IP addresses, and it is up to the application to choose which
PDN is used to fetch the content.
In order to understand the impact to the identity of authentication
POA, let us review mobility management (MM) messages and complexities
involved. When a UE is powered on it performs attach procedure by
initiating NAS, other MM messages. On an average there are 40+
messages exchanged between UE and different elements such as Mobility
Management Entity (MME), Home Subscriber System (HSS), PGW and Policy
Control Rule Function (PCRF). IP is embedded very deeply into these
messages as layer-3 transport and TLV carrying additional attributes.
+---------------------------+-------+-------+-------+-------+------+
| NAS Signaling Type | MME | HSS | SGW | PGW | PCRF |
+------------------------------------------------------------------+
| Attach | 10 | 2 | 3 | 2 | 1 |
| Additional default bearer | 4 | 0 | 3 | 2 | 1 |
| Dedicated bearer | 2 | 0 | 2 | 2 | 1 |
| Idle-to-connect | 3 | 0 | 1 | 0 | 0 |
| Connect-to-Idle | 3 | 0 | 1 | 0 | 0 |
| X2 handover | 2 | 0 | 1 | 0 | 0 |
| S1 handover | 8 | 0 | 3 | 0 | 0 |
| Tracking area update | 2 | 0 | 0 | 0 | 0 |
| Total | 34 | 2 | 14 | 6 | 3 |
+---------------------------+-------+-------+-------+-------+------+
Figure-4: Typical Mobility Management Messages
After analyzing message structure for the above messages and
complexities, their inter-dependencies, the conclusion was that it is
not beneficial to deploy ICN for control plane and mobility
management functions. It is important to note that even though we do
not implement ICN in control plane, we still need capabilities in
MME, HSS and PCRF to understand ICN functions.
Prakash, et.al. Expires September 29, 2017 [Page 9]
Internet-Draft Deploying ICN in 5G/LTE Mobile Networks March 28 2017
When UE initiates attach request using the identity as ICN, MME must
be able to parse that message and create a session. MME forwards UE
authentication to HSS so HSS must be capable of authenticating ICN-
capable UE and authorizing create session [TS23.401].
5.2 Deploying ICN Protocol in Mobile Devices
UE protocol stack is quite complex because it has to support multiple
access radio connectivity to the BS(s), authentication POA and
logical/session management POA to mobile gateways such as SGW/PGW.
High level protocol stack is given in Figure-6 below, however more
details are given in 3GPP specifications [TS23.323]. 3GPP Rel.13
onward specifications provides options for IP and non-IP PDN types.
We will leverage "Non-IP" PDN deploy ICN protocol stack in a mobile
device.
5.2.1 Dual stack or triple stack (IPv4, IPv6, IPv4v6, ICN)
Figure-5 provides high level protocol stack changes and new functions
in UE
+-----------------------------------+
| Applications/Contents (existing) |
+-----------------+-----------------+
|
+-----------------+-----------------+
| Forwarding Function (new) |
+------+---------------------+------+
| |
+------+------+ +------+------+
|ICN function +-------+ IP function |
| (New) | | (Existing) |
+------+------+ +---+---------+
| (native) | (overlay)
+------+------------------+---------+
| PDCP (updated to support ICN) |
+-----------------+-----------------+
|
+-----------------+-----------------+
| RLC (Existing) |
+-----------------+-----------------+
|
+-----------------+-----------------+
| MAC Layer (Existing) |
+-----------------+-----------------+
|
+-----------------+-----------------+
Prakash, et.al. Expires September 29, 2017 [Page 10]
Internet-Draft Deploying ICN in 5G/LTE Mobile Networks March 28 2017
| Physical L1 (Existing) |
+-----------------------------------+
Figure-5: Dual stack ICN Deployment in UE
The following new functions are added to support dual stack ICN
deployments
- Insert "Forwarding Function" between Applications/Contents
(existing) and network layer (IP function). Forwarding function
contains decisions algorithms to route the request from
Applications/Contents, based on criteria such as application
preference (ICN vs IP transport), content locations, content
types, publishers details, cost, network congestions, QoS and any
other customizable parameters. Network function can also provide
input for Forwarding Function for decision algorithms.
- Insert "ICN Function" by modifying existing PDCP and IP Function.
If "Forwarding Function" sends content request using ICN message
such as "Interest" then ICN function will be used to process. If
UE doesn't support ICN then it will be overlaid on top of IP.
- Modification in existing PDCP to support ICN in addition to IP.
There is no impact on lower layers except for ICN name size. If
ICN name is bigger then it will have impact on radio physical
layer resource blocks.
5.2.1 Native ICN deployment in UE
Figure-6 provides high level protocol stack changes and new functions
in UE
The following new functions are added to support dual stack ICN
deployments
- Insert "Forwarding Function" between Applications/Contents
(existing) and network layer (IP function). Forwarding function
contains decisions algorithms to route the request from
Applications/Contents, based on criteria such as application
preference (ICN vs IP transport), content locations, content
types, publishers details, cost, network congestions, QoS and any
other customizable parameters. Network function can also provide
input for Forwarding Function for decision algorithms.
- Insert "ICN Function" by modifying existing PDCP and replacing IP
Function. In this scenario UE will have native support for ICN
Prakash, et.al. Expires September 29, 2017 [Page 11]
Internet-Draft Deploying ICN in 5G/LTE Mobile Networks March 28 2017
- Modification in existing PDCP layer. Currently PDCP is configured
for IP transport and it uses header compression mechanism for IP.
When ICN is used, it will require changes in PDCP layer. Currently
PDCP uses Robust header compression (RoHC) Compression on air
interface. With ICN we will use the same RoHC (RFC3095) header
compression technique but update algorithms for ICN.
+-----------------------------------+
| Applications/Contents (existing) |
+-----------------+-----------------+
|
+-----------------+-----------------+
| Forwarding Function (new) |
+-----------------+-----------------+
|
+-----------------------------------+
| ICN function |
| (New) |
+------+----------------------------+
| (native)
+------+------------------+---------+
| PDCP (updated to support ICN) |
+-----------------+-----------------+
|
+-----------------+-----------------+
| RLC (Existing) |
+-----------------+-----------------+
|
+-----------------+-----------------+
| MAC Layer (Existing) |
+-----------------+-----------------+
|
+-----------------+-----------------+
| Physical L1 (Existing) |
+-----------------------------------+
Figure-6: Dual stack ICN Deployment in UE
5.3 ICN Deployment in Base Station (BS)
In order to deploy ICN in radio Base Station (a.k.a. as eNodeB) for
LTE/4G network in user plane (Figure-7:ICN Deployment in Base station
for User Plane), we need to modify existing Layer-3 (IP layer). At
layer-3 we need to incorporate ICN function in addition to the
existing IP function. The main goal of introduction of the ICN
function is to enable delivery of content using either ICN or IP or
both based on the preference of mobile device (UE). Description of
the required changes is as follows:
Prakash, et.al. Expires September 29, 2017 [Page 12]
Internet-Draft Deploying ICN in 5G/LTE Mobile Networks March 28 2017
+-------+ | +-------+ | +-------+
|GTP-U |..|..|GTP-U |..|..|GTP-U |
+-------+ | +-------+ | +-------+
+-----+ | +-----+ +-------+ | +-------+ | +-------+
|PDCP |.....|PDCP | | UDP |..|..| UDP |..|..| UDP |
+-----+ | +-----+ +-------+ | +-------+ | +-------+
+-----+ | +-----+ +-------+ | +-------+ | +-------+
| RLC |.....| RLC | |ICN|IP |..|..|ICN|IP |..|..|ICN|IP |
+-----+ | +-----+ +-------+ | +-------+ | +-------+
+-----+ | +-----+ +-------+ | +-------+ | +-------+
| MAC |.....| MAC | | MAC |..|..| MAC |..|..| MAC |
+-----+ | +-----+ +-------+ | +-------+ | +-------+
+-----+ | +-----+ +-------+ | +-------+ | +-------+
| PHY |.....| PHY | | ETH |..|..| ETH |..|..| ETH |
+-----+ | +-----+ +-------+ | +-------+ | +-------+
Uu S1U S5/S8
UE Base Station SGW PGW
Figure-7: ICN Deployment in Base station for User Plane
When a UE is powered up it will perform attach procedures, and on
successful attachment UE can have either ICN or IP or both ICN + IP
identity. When user initiates any application on UE, it sends a
content request to BS, the request is forwarded by to SGW/PGW using
the following order as per Figure-8: User Plane traffic forwarded by
Base station on S1U.
- UE sends ICN request, then BS can forward this request using ICN
transport (if transport exists) or ICN as overlay on IP (if
transport is IP)
- UE sends IP request, then BS forwards the request using IP
natively (if transport is IP). Transport is built either as dual
stack (IP +ICN) or native IP. More details about algorithms used
in BS are given in next section.
- UE sends ICN or IP request, then such request is received with
additional qualifiers such as weight, priority, cost etc. and BS
will use algorithms and built in logic to interpret priority to
forward request using either ICN or IP (If transport is IP).
Transport is built either as dual stack (IP +ICN) or native IP.
Prakash, et.al. Expires September 29, 2017 [Page 13]
Internet-Draft Deploying ICN in 5G/LTE Mobile Networks March 28 2017
Base Station
(eNodeB)
+---------------+
| UE request | ICN +---------+
+--->| content using |-- transport --> | |
| |ICN protocol | | |
| +---------------+ | |
| | |
| +---------------+ | |
+-+ | | UE request | IP |To mobile|
| | +------>| content using |-- transport --> | GW |
+-+ | | IP protocol | |(SGW/PGW)|
UE | +---------------+ | |
| | |
| +---------------+ | |
| | UE request | Dual stack | |
+--->| content using |-- IP+ICN --> | |
|IP/ICN protocol| transport +---------+
+---------------+
S1U
Figure-8: User Plane traffic forwarded by Base station on S1U
5.3.1 ICN Deployment in SGW/PGW
Mobile gateways a.k.a. Evolved Packet Core (EPC), which include SGW,
PGW, GGSN (For 3G) are hosting session management functions for UE
from initial attach to disconnection. When UE is powered on, it
performs NAS signaling and after successful authentication with HSS,
it attaches with PGW as per detailed 3GPP messages [TS23.401].
Details of changes required for deploying ICN are described in
Figure-9: Modified UE attach procedures for ICN Deployment.
1. Attach:- When UE sends attach request to BS, it contains
parameters called Protocol Configuration Option Information Element
Information Elements (PCO-IE) containing UE capabilities [TS23.401].
We can use PCO IE TLV to carry ICN related capabilities from UE
2. Attach:- BS forwards attach request to MME, with PCO-IE TLV
containing UE capabilities. MME performs authentication and on
successful authentication authorization with HSS and communicates to
UE using 5. Authentication/security
12.Create Session:- MME forwards Create Session request (CSR) to SGW
with PCO-IE capabilities.
13. Create Session request:- SGW forwards Create Session request
Prakash, et.al. Expires September 29, 2017 [Page 14]
Internet-Draft Deploying ICN in 5G/LTE Mobile Networks March 28 2017
(CSR) to PGW with PCO-IE capabilities.
14. IP-CAN Session:- PGW performs session creation function including
policy download from PCRF and quota from quota management server. On
successful attachment, PGW sends back response to SGW (15. CSR
Response)
18. UE Attach:- UE gets successful attachment to PGW with ICN
identity. Now it can send/receive content using ICN protocols.
+--+ +--+ +---+ +---+ +---+ +----+ +---+
|UE| |BS| |MME| |SGW| |PGW| |PCRF| |HSS|
+-++ +-++ +-+-+ +-+-+ +-+-+ +--+-+ +-+-+
| | | | | | |
|1.Attach| | | | | |
|------->| | | | | |
| |2.Attach| | | | |
| |------->| | | | |
+----------------------------------------------------------+
| | | | | | | | |
+----------------------------------------------------------+
| 5. Authentication/security | | |
+---------------------------------------------------->|
| | | | | | |
+----------------------------------------------------------+
| | | | | | | | |
+----------------------------------------------------------+
| | |12.Create | | |
| | | session+ | | |
| | |------->| | | |
| | | |13.Create | |
| | | | session| | |
| | | +------->| | |
| | | | |14.IP+CAN |
| | | | | session| |
| | | | +------->| |
| | | |15.Res | | |
| | |16.Res |<-------| | |
| | |<-------| | | |
| |17.Attach | | | |
| | accept | | | | |
| |<-------| | | | |
|18.UE | | | | | |
|attached| | | | | |
|<-------| | | | | |
| | | | | | |
Figure-9: Modified UE attach procedures for ICN Deployment
Prakash, et.al. Expires September 29, 2017 [Page 15]
Internet-Draft Deploying ICN in 5G/LTE Mobile Networks March 28 2017
6. Summary
We have discussed complexities of LTE network and key dependencies
for deploying ICN in control and user plane. Different deployment
options described cover different aspects such as interoperability
and multi-technology which is a reality for any mobile provider. The
ICN deployment options described in Section 3 are based on limited
simulation, however the concept works. We can definitely deploy ICN
for content delivery in user plane either as an overlay, dual stack
or natively (by integrating ICN with CDN, BS, SGW, PGW and routers
etc.) however actual deployment scenarios will be specific to a
mobile network.
As per Cisco Visual Networking Index [VNXIDX] by year 2020, over 80%
of mobile traffic will be video and if this can be delivered using
ICN from locally cached at BS/MEC, it will be a significant benefit.
In order to deploy ICN in LTE mobile gateways, further research is
necessary to add capabilities such as modification of PCO-IE field to
carry ICN-specific parameters and this has to be standardized by 3GPP
by updating TS23.401 attach procedures. Further research is also
required for understanding the ICN capability to support deep packet
inspection, lawful intercept, billing and mediation because in
current architecture all these functionalities are closely associated
with IP.
In addition, 5G architecture and possible use of ICN provides new
capabilities such as network slicing and separation of control and
forwarding plane, allowing eNodeB/MEC to function as forwarding plane
[CHENG]. Recent research for delivering real-time video content using
ICN also proved to be efficient [NDNRTC]. The key aspect for ICN is
its seamless integration in LTE and 5G networks with tangible
benefits so that we can optimize content delivery using simple and
scalable architecture.
Prakash, et.al. Expires September 29, 2017 [Page 16]
Internet-Draft Deploying ICN in 5G/LTE Mobile Networks March 28 2017
7 References
7.1 Normative References
[GRAYSON] Grayson M, Shatzkamer K, Wainner S.; Cisco Press book "IP
Design for Mobile Networks" by. page 108-112.
[IPSEC] Cisco IPSec overhead calculator tool
<https://cway.cisco.com/tools/ipsec-overhead-calc/ipsec-
overhead-calc.html>.
[BROWER] Brower, E.; Jeffress, L.; Pezeshki, J.; Jasani, R.;
Ertekin, E. "Integrating Header Compression with IPsec",
Military Communications Conference, 2006. MILCOM 2006.
IEEE, On page(s): 1 - 6.
[TS23.323] 3GPP TS25.323 Rel. 13 Packet Data Convergence Protocol
(PDCP) specification, 11 Dec 2015.
[TS23.203] 3GPP TS23.203 v13.7.0 (2016-03) Rel. 13, Policy and
charging control and QoS architecture, 15 March 2016
[TS23.401] 3GPP TS23.401 v13.7.0 (2016-03) Rel. 13, E-UTRAN Access
procedures architecture, 12 November 2015.
7.2 Informative References
[MECSPEC] European Telecommunication Standards Institute (ETSI) MEC
specification ETSI-GS-MEC-IEG-001 V1.1.1 (2015-11).
[ICN] draft-wissingh-icnrg-terminology-01
[NDNPUB] Named Data Networking <http://named-
data.net/publications/>.
[CCN] Content Centric Networking <http://www.ccnx.org and
http://blogs.parc.com/ccnx/documentation-guide/>.
[NDN] Lixia Z., Lan W. et al. SIGCOMM Named Data Networking,
<www.sigcomm.org/sites/.../0000000-0000010.pdf>.
[CARLOS] Carlos A., Torsten B. Vasilios S., Information-Centric
Networking in Mobile and Opportunistic Network, Springer
International Publishing Switzerland, LNCS 8611, pp 14-30,
2014.
Prakash, et.al. Expires September 29, 2017 [Page 17]
Internet-Draft Deploying ICN in 5G/LTE Mobile Networks March 28 2017
[RAVI] Ravishankar R., Samantha L., Wang G. Supporting seamless
mobility in named data networking IEEE ICC 10-15 June
2012, pages 5854-5869.
[VNIIDX] Cisco Visual Networking Index (VNI) dated 16 Feb 2016,
<http://www.cisco.com/c/en/us/solutions/service-
provider/visual-networking-index-vni/index.html>.
[CHENG] Chengchao L., F. Richard Yu, Information-centric network
fucntion virtualization over 5G mobile wireless networks,
IEEE network (Volume:29, Issue:3), page 68-74, 01 June
2015.
[NDNRTC] Peter Gusev,Zhehao Wang, Jeff Burke, Lixia Zhang et. All,
IEICE Trans Communication, RealtimeStreaming Data Delivery
over Named Data Networking, Vol E99-B, No.5 May 2016.
Authors' Addresses
Prakash Suthar
9501 Technology Blvd.
Rosemont, Illinois 50618
EMail: psuthar@cisco.com
Milan Stolic
9501 Technology Blvd.
Rosemont, Illinois 50618
EMail: mistolic@cisco.com
Anil Jangam
3625 Cisco Way
San Jose, CA 95134
USA
Email: anjangam@cisco.com
Prakash, et.al. Expires September 29, 2017 [Page 18]