[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 draft-irtf-icnrg-icn-lte-4g

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/