Skip to main content

Native Deployment of ICN in LTE, 4G Mobile Networks
draft-suthar-icnrg-icn-lte-4g-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Prakash Suthar , Milan Stolic , Anil Jangam
Last updated 2017-05-18
Replaced by draft-irtf-icnrg-icn-lte-4g, draft-irtf-icnrg-icn-lte-4g, RFC 9269
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-suthar-icnrg-icn-lte-4g-01
ICN Research Group                                        Prakash Suthar
Internet-Draft                                              Milan Stolic
Intended status: Informational                               Anil Jangam
                                                           Cisco Systems
Expires: November 17, 2017                                   May 16 2017

          Native Deployment of ICN in LTE, 4G Mobile Networks
                    draft-suthar-icnrg-icn-lte-4g-01

Abstract

   Mobile networks using LTE, 4G technologies are complex. Managing
   mobility and content delivery using IP transport is challenging and
   not optimized for content delivery. 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
   emerging technology with built in features 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 document is on native deployment of ICN in cellular
   mobile networks by embedding ICN into 3GPP protocol stack at IP
   datagram 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 ICN
   native or dual stack (with IP) deployment will bring all inherent
   benefits 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".

   The list of current Internet-Drafts can be accessed at
 

Prakash, et.al.        Expires November 17, 2017                [Page 1]
Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks     May 16 2017

   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  Network Overview  . . . . . . . . . . . . . . . . . . . . .  3
     2.2  Virtualizing Mobile Networks  . . . . . . . . . . . . . . .  5
     2.3  Key characteristics of Mobile Networks  . . . . . . . . . .  5
   3.  Content Delivery using IP  . . . . . . . . . . . . . . . . . .  6
   4.  Content Delivery using ICN . . . . . . . . . . . . . . . . . .  6
   5.  ICN Deployment in 4G and LTE Networks  . . . . . . . . . . . .  9
     5.1  Recommendations in the Mobility Management  . . . . . . . .  9
     5.2  Recommendations in the User Plane . . . . . . . . . . . . . 10
       5.2.1  Dual stack ICN Deployments in UE  . . . . . . . . . . . 10
       5.2.2  Native ICN Deployments in UE  . . . . . . . . . . . . . 13
       5.2.3  ICN Deployment in Base Station (eNodeB) . . . . . . . . 14
       5.2.4  ICN Deployment in Packet Core (SGW/PGW) Gateways  . . . 15
   6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   7  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     7.1  Normative References  . . . . . . . . . . . . . . . . . . . 18
     7.2  Informative References  . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19

 

Prakash, et.al.        Expires November 17, 2017                [Page 2]
Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks     May 16 2017

1  Introduction

   Mobile networks in 4G and LTE use IP routing and protocols such as
   OSPF, ISIS, BGP etc. for transport of IP packet data to end user's
   device. LTE technology is built as all IP network. Stickiness of IP
   address to a device is the key to get connected to mobile network and
   this same IP address is maintained through the session until the
   device gets detached or moves to other networks. Some of legacy and
   hybrid networks still use legacy protocols such as frame relay, ATM
   etc. but they are being replaced.

   Key protocol used in 4G and LTE networks is GPRS Tunneling protocol
   (GTP). GTP, DIAMETER and other protocols are built on top of IP. One
   of the biggest challenges with IP based routing is that it is not
   optimized for content delivery although it is the most efficient
   routing protocol. By natively implementing Information Centric
   Networking (ICN) in 3GPP, we can re-architect mobile networks and
   optimize design for efficient content delivery. ICN also offers an
   opportunity to leverage inherent capabilities of anchorless mobility,
   authentication and optimized signaling.

   This draft provides insight into different options for deploying ICN
   in mobile networks and how they impact mobile providers and end-
   users. We also discuss potential issues related to IP based mobile
   networks content delivery and how we can leverage ICN to overcome
   some of the bottlenecks.

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  Network Overview

   With the introduction of LTE, mobile networks moved to all-IP
   transport for all elements such as eNodeB, MME, SGW/PGW, HSS, PCRF,
   routing and switching etc. Although LTE network is data-centric, it
   has support for legacy Circuit Switch features like voice and SMS
   through transitional CS fallback and flexible IMS deployment
   [GRAYSON]. For each mobile device attached to the radio (eNodeB)
   there is a separate overlay tunnel (GPRS Tunneling Protocol, GTP)
   between eNodeB and Mobile gateways (i.e. SGW, PGW). This tunnel is
   used to carry user traffic between gateways and mobile devices so the
   content is distributed using unicast mechanism. 

 

Prakash, et.al.        Expires November 17, 2017                [Page 3]
Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks     May 16 2017

   It is also important to understand the overhead of a GTP tunnel
   because this has impact on the carried 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 provider), then it will add ~15-23
   overhead based upon transport/tunneling model, and encryption and
   authentication header algorithms used [IPSEC].  

                                          +-------+  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

   The content delivered to mobile devices is unicast inside GTP tunnel.
   If we consider combined impact of GTP, IPSec and unicast traffic, the
   content delivery is not efficient. IETF has developed various header
   compression algorithms to reduce the overhead associated with IP
   packets. Some of techniques are robust header compression (ROHC) and
   enhanced compression of the real-time transport protocol (ECRTP) so
   that 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 November 17, 2017                [Page 4]
Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks     May 16 2017

   different mechanisms for header compression to achieve efficiency in
   content delivery [TS23.323], which can be used in ICN.

2.2  Virtualizing Mobile Networks

   As the adoption of LTE grew beyond traditional major Service
   providers and penetrated Mobile Virtual Network Operators (MVNO),
   public safety entities and often larger enterprises, the need for
   smaller-scale packet core became obvious. In addition to the
   requirement for a smaller scale, many operators showed tendency to do
   away with dedicated hardware and simplify their operations at a
   reduced cost by deploying the same mobility applications on the
   Commercially off the shelf x86 based hardware. Using common servers
   in a virtualized environment simplifies new deployments and provides
   optimized TCO. Virtual packet cores are opening way for many
   innovative use cases applicable to enterprise markets, however most
   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 IP 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.

2.3  Key characteristics of Mobile Networks

   Major benefit of the core network, with support from the underlying
   transport, is predictability of the traffic parameters required for
   the expected subscribers Quality of Service (QoS). A default bearer
   is always established upon subscriber's attachment to the chosen
   Access Point Name (APN). Additional dedicated bearer(s), real-time or
   non-real-time, can be established depending on the specific
   application requirements.

   While all traffic within a certain bearer gets the same treatment,
   QoS parameters supporting these requirements can be very granular in
   different bearers. These values vary for the control, management and
   user traffic, and depending on the application key parameters, such
   as latency, jitter (important for voice and other real-time
   applications), packet loss and queuing mechanism (strict priority,
   low-latency, fair etc.) can be very different. 

   Implementation of QoS for mobile networks is done at two stages: at
   content prioritization/marking and transport marking, and congestion
 

Prakash, et.al.        Expires November 17, 2017                [Page 5]
Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks     May 16 2017

   management. From the transport perspective, QoS is defined at layer-2
   as class of service (CoS) and at layer-3 either as DiffServ code
   point (DSCP) or type of service (ToS). The mapping of CoS to DSCP
   takes place at layer-2/3 switching and routing elements. 3GPP has
   specified QoS Class Identifier (QCI) which represents different types
   of content and equivalent mapping to DSCP at transport layer
   [TS23.203] [TS23.401]; however, this again requires manual
   configuration at different elements and if there is misconfiguration
   at any place in the path it will not work properly.

3.  Content Delivery using IP

   As described earlier, content delivery in today's mobile networks is
   mostly unicast as described in 3GPP specifications [TS23.401]. While
   the technology exists to address the issue of possible multicast
   delivery, there are many difficulties related to the implementation
   on the RAN side of the network. Transport networks in the backhaul
   and core have addressed the multicast delivery long time ago and have
   implemented it in most cases in their multi-purpose integrated
   transport, but the RAN part of the network is still lagging behind
   due to complexities related to mobility of the clients, handovers,
   and the fact that the potential gain to the Service Providers may not
   justify the investment. With that said, the delivery in the mobility
   remains greatly unicast. 

   To ease the burden on the bandwidth of the SGi interface, caching is
   introduced in a similar manner as with many Enterprises. In the
   mobile networks, whenever possible, a cached content is delivered.
   Caching servers are placed at a centralized location, typically in
   the Service Provider's Data Center, or in some cases lightly
   distributed in the Packet Core locations with the PGW nodes close to
   the Internet and IP services access (SGi interface). 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. Other
   issues, such as out-of-order delivery due to ECMP or other reasons,
   contribute to this complexity and inefficiency but could be addressed
   at the IP transport level. However, the issue of inefficient traffic
   path to deliver the content has to be addressed from a different
   perspective, by considering a change in the approach to caching.

4.  Content Delivery using ICN

   Content delivery using ICN is quite different compared to IP-based
   systems because it follows publish-subscribe paradigm using two
   simple types of messages, namely Interest and Data. Communication in
   ICN takes place between content provider (producer) and end user
   (consumer) as described in figure 2. 

 

Prakash, et.al.        Expires November 17, 2017                [Page 6]
Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks     May 16 2017

     +----------+
     | Content  +----------------------------------------+
     | Publisher|                                        |
     +---+---+--+                                        |
         |   |    +--+             +--+           +--+   |
         |   +--->|R1|------------>|R2|---------->|R4|   |
         |        +--+             +--+           +--+   |
         |                           |   Cached          |
         |                           v   content         |
         |                         +--+  at R3           |
         |                +========|R3|---+              |
         |                #        +--+   |              |
         |                #               |              |
         |                v               v              |
         |               +-+             +-+             |
         +---------------| |-------------| |-------------+
                         +-+             +-+
                      Consumer-1      Consumer-2
                          UE              UE

                 ===> Content flow from cache
                 ---> Content flow from publisher

                    Fig. 2. ICN 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 other client.
   For mobile network, transport between a client and a content provider
   consists of radio network + mobile backhaul and IP core transport +
   Mobile Gateways + Internet + content data network (CDN). 

   For mobile devices, the edge connectivity to the network is between
   radio and a router or mobile edge computing (MEC) [MECSPEC] element.
   MEC has the capability of processing client requests and segregating
   control and user traffic at the edge of radio rather than sending all
   requests to the mobile gateway. MEC transforms radio into an
   intelligent service edge that is capable of delivering highly
   personalized services directly from the edge of the network, while
   providing the best possible performance to the client. MEC can be an
   ideal candidate for ICN forwarder in addition to its usual function
   of managing mobile termination. In addition to MEC, other transport
   elements, such as routers, can work as ICN forwarders.

   In order to understand suitability of ICN for mobile networks, we
   will discuss the ICN framework describing protocols architecture and
   different types of messages, and then consider how we can use this in
 

Prakash, et.al.        Expires November 17, 2017                [Page 7]
Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks     May 16 2017

   a mobile network for delivering content more efficiently. ICN uses
   two types of packets called "interest packet" and "data packet" as
   described in figure 3.

                   +------------------------------------+
          Interest | +------+     +------+     +------+ |        +-----+
     +-+        ---->|  CS  |---->| PIT  |---->| FIB  |--------->| CDN |
     | |           | +------+     +------+     +------+ |        +-----+
     +-+           |     |      Add  |       Drop |     | Forward
     UE         <--------+      Intf v       Nack v     |
             Data  |                                    |
                   +------------------------------------+

                   +------------------------------------+
     +-+           |  Forward                  +------+ |        +-----+
     | | <-------------------------------------| PIT  |<---------| CDN |
     +-+           |                 | Cache   +--+---+ | Data   +-----+
     UE            |              +--v---+        |     |
                   |              |  CS  |        v     |
                   |              +------+      Discard |
                   +------------------------------------+

              Fig. 3. ICN Interest, Data Packet and Forwarder

   For LTE network, when a mobile device wants to get certain content,
   it will send an Interest message to the closest base station/eNodeB.

   Interest packet follows the TLV format [NDNTLV] and contains
   mandatory fields such as name of the content and nonce. Name and
   nonce together uniquely identify an Interest packet. Nonce is also
   used to detect looping Interest messages. Interest packet also
   contains optional fields such as selector and guider fields.
   Selectors provides a specific filtering action during matching and
   selection of the name prefixes. Guiders provides specific set of
   rules on how the Interest packet can be processed at the forwarder.

   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.

 

Prakash, et.al.        Expires November 17, 2017                [Page 8]
Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks     May 16 2017

   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 various resources  [NDNPUB] [CCN] [NDN], here
   we explained the concept and its applicability to the LTE network.

5.  ICN Deployment in 4G and LTE Networks

5.1  Recommendations in the 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 the concept of point of attachment (POA).
   When UE connects to a network it has at least three POAs:

      1. Base Station (eNodeb) managing location or physical POA

      2. Authentication and Authorization (MME, HSS) managing identity
         or authentication POA

      3. Mobile Gateways (SGW, PGW) managing logical or session
         management POA.

   Physical POA in eNodeB handle both mobility and session management
   for any UE attached to 4G, LTE network. Details of mobility
   management messages between UE, eNodeB, MME, HSS, SGW, PGW are given
   below in figure 4.

   +---------------------------+-------+-------+-------+-------+------+
   | 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   |
   +---------------------------+-------+-------+-------+-------+------+

                Fig. 4. NAS Signaling Messages in LTE Gateways

   In current architecture IP transport is used for all the messages
   associated with Control Plane for mobility and session management
 

Prakash, et.al.        Expires November 17, 2017                [Page 9]
Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks     May 16 2017

   messages. IP is embedded very deeply into these messages as layer-3
   transport and TLV carrying additional attributes.

   After analyzing above message structures and their inter
   dependencies, our recommendation is that it may not be beneficial to
   deploy ICN for control plane and mobility management functions. It is
   important to note that even though we may not implement ICN in MME
   and HSS, they still need to support either dual stack or native ICN
   UE capabilities. 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 able of
   authenticating ICN capable UE and authorizing create session
   [TS23.401]. Author [ALM] has made some important comments on mobility
   management in ICN.

5.2  Recommendations in the User Plane

   We will consider figure 1 to discuss different mechanisms to deploy
   ICN in mobile networks. We consider the following options:

      1. Dual stack ICN deployment in UE

      2. Native ICN Deployments in UE

      3. ICN Deployment in Base Station (eNodeB) 

      4. ICN Deployment in Packet Core (SGW/PGW) Gateways

5.2.1  Dual stack ICN Deployments in UE

   All control and user plane communications in LTE, 4G mobile networks
   are specified in 3GPP documents [TS23.323] [TS23.203] [TS23.401] and
   many other documents. It is important to understand that UE can be
   either consumer (receiving content) or publisher (pushing content for
   other clients). The protocol stack inside mobile device (UE) is quite
   complex because it has to support multiple radio connectivity access
   to base station(s). There are three points of attachments for UE.

   Figure 5 below provides high level protocol stacks description where
   IP is defined at two layers: (1) at user plane communication, (2)
   Transport layer. User plane communication takes place between PDCP
   and Application layer, whereas transport layer is at GTP protocol
   stack.

 

Prakash, et.al.        Expires November 17, 2017               [Page 10]
Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks     May 16 2017

   +--------+                                               +--------+
   |   App  |                                               |  CDN   |
   +--------+                                  +--------+   +--------+
   |Transp. | |              |               | |Transp. | | |Transp. |
   |Selector|.|..............|...............|.|Selector|.|.|Selector|
   +--------+ |              |               | +--------+ | +--------+
   |        |.|..............|...............|.|        |.|.|        |
   | ICN/IP | |              |               | | ICN/IP | | |  ICN/IP|
   |        | |              |               | |        | | |        |
   +--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+
   |        |.|.|    |     |.|.|     |     |.|.|     |  | | |        |
   |  PDCP  | | |PDCP|GTP-U| | |GTP-U|GTP-U| | |GTP-U|  | | |   L2   |
   +--------+ | +----------+ | +-----------+ | +-----+  | | |        |
   |   RLC  |.|.|RLC | UDP |.|.| UDP | UDP |.|.|UDP  |L2|.|.|        |
   +--------+ | +----------+ | +-----------+ | +-----+  | | |        |
   |   MAC  |.|.| MAC|  L2 |.|.| L2  | L2  |.|.|  L2 |  | | |        |
   +--------+ | +----------+ | +-----------+ | +--------+ | +--------+
   |   L1   |.|.| L1 |  L1 |.|.| L1  | L1  |.|.|  L1 |L1|.|.|   L1   |
   +--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+
       UE     |  BS(enodeB)  |      SGW      |     PGW    |
             Uu             S1U            S5/S8         SGi

                 Fig. 5. Dual stack ICN Deployment in UE

   The protocol interactions for tunneling ICN packet on top of IP or
   natively and how it changes the stack are described in figure 6
   below.

   UE is a basic entity (referred to as any type of device which
   attaches to cellular network using 3G/UMTS or LTE technologies). The
   protocols and software stack used inside LTE capable UE support both
   3G and LTE software interworking and handover. Latest 3GPP Rel.13
   onward specification describe the use of IP and non-IP protocols to
   establish logical/session connectivity. We will leverage these
   techniques to deploy ICN protocol stack in UE.

      1. Insert Transport Selector function between Application and
         network layer (consisting of ICN + IP function). Transport
         Selector interface with Application layer on top of it
         determines how traffic is routed to the lower layers. The
         decision can be based on preference indicated by the
         application, or other parameters such as congestion, cost,
         quality of service or any additional parameter. There can be an
         open Application Programmable Interface (API) to exchange
         additional parameters required for transport selection. The
         southbound interactions of Transport Selector will be either to
         IP or ICN at network layer.

 

Prakash, et.al.        Expires November 17, 2017               [Page 11]
Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks     May 16 2017

                       +-----------------------------------+
                       |     Applications (existing)       |
                       +-----------------------------------+
                                         |
                       +-----------------------------------+
                       |     Transport Selector (new)      |
                       +-----------------------------------+
                              |                     |
                       +-------------+       +-------------+
                       |ICN function +-------+ IP function |
                       |   (New)     |       | (Existing)  |
                       +-------------+       +-------------+
                              | (native)         | (overlay)
                       +-----------------------------------+
                       | PDCP (updated to support ICN)     |
                       +-----------------------------------+
                                         |
                       +-----------------------------------+
                       |          RLC (Existing)           |
                       +-----------------------------------+
                                         |
                       +-----------------------------------+
                       |        MAC Layer (Existing)       |
                       +-----------------------------------+
                                         |
                       +-----------------------------------+
                       |       Physical L1 (Existing)      |
                       +-----------------------------------+

                   Fig. 6. Dual stack ICN protocol interactions

      2. ICN forwarding protocol stack is introduced in parallel to
         existing IP layer. ICN forwarder contains functional
         capabilities to route ICN packets e.g. Interest packet to base
         station or response "data packet" from base station to
         Application.

      3. For dual stack scenario when UE is not supporting ICN at
         transport layers, we need to overlay ICN packets on top of IP.
         For such scenario, we need to introduce an interface function
         between ICN function and IP function. ICN function will use
         this interface to send ICN Interest and Data packets for
         fetching or sending content using ICN protocol function. This
         interface will use ICN overlay over IP using any overlay
         tunneling mechanism.

      4. To support ICN at network layer in UE, we need to modify
         existing PDCP layer. PDCP layer has to be aware of ICN
 

Prakash, et.al.        Expires November 17, 2017               [Page 12]
Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks     May 16 2017

         capabilities and parameters.

      5. No changes are required for lower layer such as RLC, MAC and
         Physical (L1) because they are not IP aware.

   One key point to understand in this scenario is that ICN is deployed
   as an overlay on top of IP.

5.2.2  Native ICN Deployments in UE

   There is possibility to implement ICN natively in UE by modifying
   3GPP protocols. Figure 7 below provides high level protocol stacks
   description where ICN is defined at two layers:

      1. at user plane communication

      2. at transport layer

   User plane communication takes place between PDCP and application
   layer, whereas transport layer is a substitute of GTP protocol.
   Removal of GTP protocol stack is significant change in mobile
   architecture because GTP is used not just for routing but for
   mobility management functions such as billing, mediation, policy
   enforcement etc.

   +--------+                                                +--------+
   |  App   |                                                |   CDN  |
   +--------+                                                +--------+
   |Transp. | |              |              |              | |Transp. |
   |Selector|.|..............|..............|..............|.|Selector|
   +--------+ |              |              |              | +--------+
   |        |.|..............|..............|..............|.|        |
   | ICN/IP | |              |              |              | |        |
   |        | |              |              |              | |        |
   +--------+ | +----+-----+ | +----------+ | +----------+ | | ICN/IP |
   |        |.|.|    |     | | |          | | |          | | |        |
   |  PDCP  | | |PDCP| ICN |.|.|    ICN   |.|.|    ICN   |.|.|        |
   +--------+ | +----+     | | |          | | |          | | |        |
   |   RLC  |.|.|RLC |     | | |          | | |          | | |        |
   +--------+ | +----------+ | +----------+ | +----------+ | +--------+
   |   MAC  |.|.| MAC|  L2 |.|.|     L2   |.|.|    L2    |.|.|    L2  |
   +--------+ | +----------+ | +----------+ | +----------+ | +--------+
   |   L1   |.|.| L1 |  L1 |.|.|     L1   |.|.|    L1    |.|.|    L1  |
   +--------+ | +----+-----+ | +----------+ | +----------+ | +--------+
       UE     |  BS(enodeB)  |      SGW     |      PGW     |
              Uu            S1u           S5/S8           SGi

                         Fig. 7. Native ICN Deployment in UE
 

Prakash, et.al.        Expires November 17, 2017               [Page 13]
Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks     May 16 2017

   If we implement ICN natively in UE, communication between UE and base
   station (eNodeB) will change and also we will not need to tunnel user
   plane traffic from eNodeB to mobile packet core (SGW, PGW) using GTP
   tunnel.

   For native ICN deployment, Application is configured to use ICN
   forwarder so there is no need for Transport Selector. Also to support
   ICN at network layer in UE, we need to modify existing PDCP layer.
   PDCP layer has to be aware of ICN capabilities and parameters.

   Native implementation will also provide opportunities to develop new
   use cases leveraging ICN capabilities such as seamless mobility, UE
   to UE content delivery using radio network without interactions with
   mobile gateways, etc.

5.2.3  ICN Deployment in Base Station (eNodeB)

   The physical point of attachment for UE is base station(s), where
   radio protocols are converted or interfaced with transport protocol
   as depicted in figure 5 and figure 7 for dual stack/overlay and
   native ICN attach respectively.

   When UE performs attach procedures and it has identity either as
   native IP, dual stack (IP and ICN), or native ICN, it starts sending
   data requests using user plane messages. UE can request using any of
   three different options:

      1. Native IP (IPv4 or IPv6)

      2. Native ICN

      3. Dual stack IP (IPv4/IPv6) or ICN

   Protocol interactions between UE and Base Station (figure 5 and
   figure 7) at PDCP layer and UE provide information to Base station.

   As depicted in figure 8 below, Base Station contains algorithms to
   compare request coming from UE and also availability of transport on
   S1u interface. If the base station has all three types of transport
   e.g. Native ICN, Dual Stack (ICN, IP) and native IP, then it can
   forward the request as it is. If S1u interface transport is only IP,
   then it will overlay ICN on IP and forward the user plane traffic on
   it.

 

Prakash, et.al.        Expires November 17, 2017               [Page 14]
Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks     May 16 2017

               +---------------+  |
               | 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    +---------+
               +---------------+  |
                 Base Station    S1u
                  (eNodeB)

          Fig. 8. Native ICN Deployment in Base Station (eNodeB)

   At the base station, transport selection on S1u interface can be
   based on preference indicated by application or other parameters such
   as congestion, cost, quality of service or any additional parameter.
   There can be open Application Programmable Interface (API) to
   exchange additional parameters required for transport selection.

5.2.4  ICN Deployment in Packet Core (SGW/PGW) Gateways Mobile gateways
   a.k.a. Evolved Packet Core (EPC) include SGW, PGW, GGSN, perform
   session management for UE from the initial attach to disconnection.
   When UE is powered on, it performs NAS signaling and after successful
   authentication it attaches to PGW. PGW is an anchoring point for UE
   and responsible for service creations, authorization, maintenance
   etc. Entire functionality is managed using IP address(es) for UE.

   In order to implement ICN in EPC, the following functions are needed.

      1. Insert ICN function at session management layer as additional
         functionality with IP stack. Session management layer is used
         for performing attach procedures and assigning logical identity
         to user. After successful authentication by HSS, MME sends
         create session request (CSR) to SGW and SGW to PGW.

      2. When MME sends Create Session Request message (step-12 in
         [TS23.401]) to SGW/PGW, it contains Protocol Configuration
         Option Information Element (PCO IE) containing UE capabilities.
         We can use PCO IE to carry ICN related capabilities information
 

Prakash, et.al.        Expires November 17, 2017               [Page 15]
Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks     May 16 2017

         from UE to PGW/GGSN. This information is received from UE
         during initial attach request in MME. Details of available TLV
         which can be used for ICN are given in subsequent sections. UE
         can support either native IP, or ICN+IP, or native ICN. IP is
         referred to as both IPv4 and IPv6 protocols.

      3. For ICN+IP capable UE, PGW will assign attachment using both IP
         address and ICN identity. During initial attach procedures, UE
         name is registered and used for session management. For ICN
         capable UE it will provide only ICN attachment. For native IP
         capable UE there is no change.

      4. In order to support ICN capable attach procedures and use ICN
         for user plane traffic, PGW needs to have full ICN protocol
         stack functionalities. Typical ICN capabilities include
         functions such as content store (CS), Pending Interest Table
         (PIT), Forwarding Information Base (FIB) capabilities etc. If
         UE requests ICN in PCO IE, then PGW registers UE with ICN
         names. For ICN forwarding, PGW caches content locally using CS
         functionality.

      5. Protocol configuration options information elements described
         in [TS24.008] (see Figure 10.5.136 on page 598) and [TS24.008]
         (see Table 10.5.154 on page 599) provides details for different
         fields.

         - Octet 3 (configuration protocols defines PDN types) which
           contains details about IPv4, IPv6, both or ICN.

         - Any combination of Octet 4 to Z can be used to provide
           additional information related to ICN capability. It is most
           important that PCO IE parameters are matched between UE and
           EPC gateways (MME, SGW, PGW) so that they can be interpreted
           properly and UE can attach successfully.

      6. Deployment of ICN functionalities in SGW/PGW should be matched
         with UE and Base station because they will exchange ICN
         protocols and parameters.

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 inter-operability
   and multitechnology, which is a reality for any mobile provider. The
   ICN deployment options described in section 5 are derived using LTE
   gateway software and ICN simulator. We can definitely deploy ICN for
   content delivery in user plane either as an overlay, dual stack or
 

Prakash, et.al.        Expires November 17, 2017               [Page 16]
Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks     May 16 2017

   natively (by integrating ICN with CDN, eNodeB, SGW, PGW and routers
   etc.); however, actual deployment scenarios will be specific to a
   mobile network. 

   After analysing different control plane signaling messages, our
   observation is that the benefit of using ICN for control plane
   messages is possible only after native deployment of ICN in UE.

   To implement ICN in LTE mobile gateways, we are working to add
   capabilities such as modification of PCO-IE field to carry ICN-
   specific parameters for attach procedures. Further study is underway
   to understand capability in ICN to support deep packet inspection,
   lawful intercept, billing and mediation.

   As per Cisco Visual Networking Index (VNI) Feb 2016 report [VNIIDX]
   over 70% of mobile traffic is video and if this can be delivered
   using ICN from eNodeB/MEC, it will be significant benefit. Recent
   research for delivering real-time video content using ICN has also
   been proven 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.

   In addition, 5G architecture and possible use of ICN provides new
   capabilities such as network slicing and separation of control and
   forwarding plane allowing MEC to function as forwarding plane [CHENG]
   and software define radio (SDR) aspects. We will continue to explore
   how the ICN forwarding in MEC could be used in efficient delivery of
   unicast and multicast traffic.  

 

Prakash, et.al.        Expires November 17, 2017               [Page 17]
Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks     May 16 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).

   [NDNTLV]   NDN Interest Packet Format Specification 0.2-2.
              https://named-data. net/doc/ndn-tlv/interest.html.

   [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

   [ALM]      J. Auge, G. Carofiglio et al. "Anchor-less producer
              mobility in icn," in Proceedings of the 2Nd ACM Conference
              on Information-Centric Networking, ACM-ICN '15, pp. 189-
              190, ACM, 2015.

 

Prakash, et.al.        Expires November 17, 2017               [Page 18]
Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks     May 16 2017

   [TS24.008] 3GPP TS 24.008 Rel 13 Mobile radio interface Layer 3
              specification.

   [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>.

   [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.

   [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.

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 November 17, 2017               [Page 19]