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

ICN Research Group                                        Prakash Suthar
Internet-Draft                                              Milan Stolic
Intended status: Informational                               Anil Jangam
                                                           Cisco Systems
                                                            Dirk Trossen
                                                       InterDigital Inc.
Expires: March 23, 2018                                September 19 2017


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

Abstract

   LTE, 4G mobile networks use IP based transport for control plane to
   establish the data session and user plane for actual data delivery.
   In existing architecture, IP transport used in user plane is not
   optimized for data transport, which leads to an inefficient data
   delivery. IP unicast routing from server to clients is used for
   delivery of multimedia content to User Equipment (UE), where each
   user gets a 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 data delivery, however
   majority of the work is focused on fixed networks. The main focus of
   this draft is on native deployment of ICN in cellular mobile networks
   by using ICN in 3GPP protocol stack. ICN has an inherent capability
   for multicast, anchorless mobility, security and it is optimized for
   data delivery using local caching at the edge. The native ICN (it
   runs directly on cellular layer 2 protocols like PDCP/RLC/MAC/L1) or
   dual stack (along 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



Prakash, et.al.          Expires March 23, 2018                 [Page 1]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


   material or to cite them other than as "work in progress".

   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  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2  3GPP Terminology and Concepts . . . . . . . . . . . . . . .  4
   2.  LTE, 4G Mobile Network . . . . . . . . . . . . . . . . . . . .  8
     2.1  Network Overview  . . . . . . . . . . . . . . . . . . . . .  8
     2.2  QoS Challenges  . . . . . . . . . . . . . . . . . . . . . . 10
     2.3  Data Transport Using IP . . . . . . . . . . . . . . . . . . 11
     2.4  Virtualizing Mobile Networks  . . . . . . . . . . . . . . . 11
   3.  Data Transport Using ICN . . . . . . . . . . . . . . . . . . . 12
   4.  ICN Deployment in 4G and LTE Networks  . . . . . . . . . . . . 14
     4.1 General ICN Deployment Considerations  . . . . . . . . . . . 14
     4.2 ICN Deployment Scenarios . . . . . . . . . . . . . . . . . . 14
     4.3  ICN Deployment in LTE Control Plane . . . . . . . . . . . . 17
     4.4  ICN Deployment in LTE User Plane  . . . . . . . . . . . . . 18
       4.4.1  Dual stack ICN Deployments in UE  . . . . . . . . . . . 19
       4.4.2  Native ICN Deployments in UE  . . . . . . . . . . . . . 22
     4.5  ICN Deployment in eNodeB  . . . . . . . . . . . . . . . . . 23
     4.6  ICN Deployment in Packet Core (SGW, PGW) Gateways . . . . . 24
   5. Security Considerations . . . . . . . . . . . . . . . . . . . . 26
   6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27



Prakash, et.al.          Expires March 23, 2018                 [Page 2]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


   7  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     7.1  Normative References  . . . . . . . . . . . . . . . . . . . 29
     7.2  Informative References  . . . . . . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31















































Prakash, et.al.          Expires March 23, 2018                 [Page 3]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


1  Introduction

   LTE mobile technology is built as all-IP network. It uses IP routing
   protocols such as OSPF, ISIS, BGP etc. to establish network routes to
   route the data traffic to end user's device. Stickiness of IP address
   to a device is the key to get connected to a mobile network and the
   same IP address is maintained through the session until the device
   gets detached or moves to another network.

   One of the key protocols 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 data transport although it is the most
   efficient communication protocol. By native implementation of
   Information Centric Networking (ICN) in 3GPP, we can re-architect
   mobile network and optimize its design for efficient data transport
   by leveraging the caching feature of ICN. ICN also offers an
   opportunity to leverage inherent capabilities of multicast,
   anchorless mobility management, and authentication. This draft
   provides insight into different options for deploying ICN in mobile
   networks and how they impact mobile providers and end-users.

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

1.2  3GPP Terminology and Concepts

   Access Point Name

      The Access Point Name (APN) is a Fully Qualified Domain Name
      (FQDN) and resolves to a set of gateways in an operator's network.
      APN identifies the packet data network (PDN) that a mobile data
      user wants to communicate with. In addition to identifying a PDN,
      an APN may also be used to define the type of service, QoS and
      other logical entities inside GGSN, PGW.

   Control Plane

      The control plane carries signaling traffic and is responsible for
      routing between eNodeB and MME, MME and HSS, MME and SGW, SGW and
      PGW etc. Control plane signaling is required to authenticate and
      authorize UE and establish mobility session with mobile gateways
      (SGW/PGW). Functions of the control plane also include system
      configuration and management.




Prakash, et.al.          Expires March 23, 2018                 [Page 4]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


   Dual Address PDN/PDP Type

      The dual address Packet Data Network/Packet Data Protocol
      (PDN/PDP) Type (IPv4v6) is used in 3GPP context in many cases as a
      synonym for dual-stack, i.e. a connection type capable of serving
      both IPv4 and IPv6 simultaneously.

   eNodeB

      The eNodeB is a base station entity that supports the Long-Term
      Evolution (LTE) air interface.

   Evolved Packet Core

      The Evolved Packet Core (EPC) is an evolution of the 3GPP GPRS
      system characterized by a higher-data-rate, lower-latency, packet-
      optimized system. The EPC comprises some of the sub components of
      the EPS core such as Mobility Management Entity (MME), Serving
      Gateway (SGW), Packet Data Network Gateway (PDN-GW), and Home
      Subscriber Server (HSS).

   Evolved Packet System

      The Evolved Packet System (EPS) is an evolution of the 3GPP
      GPRSsystem characterized by a higher-data-rate, lower-latency,
      packet-optimized system that supports multiple Radio Access
      Technologies (RATs).  The EPS comprises the EPC together with the
      Evolved Universal Terrestrial Radio Access (E-UTRA) and the
      Evolved Universal Terrestrial Radio Access Network (E-UTRAN).


   Evolved UTRAN The Evolved UTRAN (E-UTRAN) is a communications
      network, sometimes referred to as 4G, and consists of eNodeBs (4G
      base stations). The E-UTRAN allows connectivity between the User
      Equipment and the core network.

   GPRS Tunnelling Protocol

      The GPRS Tunnelling Protocol (GTP) [TS.29060] [TS.29274]
      [TS.29281] is a tunnelling protocol defined by 3GPP.  It is a
      network-based mobility protocol and is similar to Proxy Mobile
      IPv6 (PMIPv6) [RFC5213].  However, GTP also provides functionality
      beyond mobility, such as in-band signaling related to Quality of
      Service (QoS) and charging, among others.

   Gateway GPRS Support Node

      The Gateway GPRS Support Node (GGSN) is a gateway function in the



Prakash, et.al.          Expires March 23, 2018                 [Page 5]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


      GPRS and 3G network that provides connectivity to the Internet or
      other PDNs. The host attaches to a GGSN identified by an APN
      assigned to it by an operator. The GGSN also serves as the
      topological anchor for addresses/prefixes assigned to the User
      Equipment.

   General Packet Radio Service

      The General Packet Radio Service (GPRS) is a packet-oriented
      mobile data service available to users of the 2G and 3G cellular
      communication systems -- the GSM -- specified by 3GPP.

   Home Location Register

      The Home Location Register (HLR) is a pre-Release-5 database (but
      is also used in Release-5 and later networks in real deployments)
      that contains subscriber data and information related to call
      routing. All subscribers of an operator, and the subscribers'
      enabled services, are provisioned in the HLR.

   Home Subscriber Server

      The Home Subscriber Server (HSS) is a database for a given
      subscriber and was introduced in 3GPP Release-5.  It is the entity
      containing the subscription-related information to support the
      network entities actually handling calls/sessions.

   Mobility Management Entity

      The Mobility Management Entity (MME) is a network element that is
      responsible for control-plane functionalities, including
      authentication, authorization, bearer management, layer-2
      mobility, etc.  The MME is essentially the control-plane part of
      the SGSN in the GPRS. The user-plane traffic bypasses the MME.

   Public Land Mobile Network

      The Public Land Mobile Network (PLMN) is a network that is
      operated by a single administration. A PLMN (and therefore also an
      operator) is identified by the Mobile Country Code (MCC) and the
      Mobile Network Code (MNC). Each (telecommunications) operator
      providing mobile services has its own PLMN.

   Policy and Charging Control

      The Policy and Charging Control (PCC) framework is used for QoS
      policy and charging control.  It has two main functions: flow-
      based charging, including online credit control and policy control



Prakash, et.al.          Expires March 23, 2018                 [Page 6]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


      (e.g., gating control, QoS control, and QoS signaling). It is
      optional to 3GPP EPS but needed if dynamic policy and charging
      control by means of PCC rules based on user and services are
      desired.

   Packet Data Network

      The Packet Data Network (PDN) is a packet-based network that
      either belongs to the operator or is an external network such as
      the Internet or a corporate intranet. The user eventually accesses
      services in one or more PDNs. The operator's packet core networks
      are separated from packet data networks either by GGSNs or PDN
      Gateways (PGWs).

   Serving Gateway

      The Serving Gateway (SGW) is a gateway function in the EPS, which
      terminates the interface towards the E-UTRAN.  The SGW is the
      Mobility Anchor point for layer-2 mobility (inter-eNodeB
      handovers).  For each UE connected with the EPS, at any given
      point in time, there is only one SGW. The SGW is essentially the
      user-plane part of the GPRS's SGSN.

   Packet Data Network Gateway

      The Packet Data Network Gateway (PGW) is a gateway function in the
      Evolved Packet System (EPS), which provides connectivity to the
      Internet or other PDNs. The host attaches to a PGW identified by
      an APN assigned to it by an operator. The PGW also serves as the
      topological anchor for addresses/prefixes assigned to the User
      Equipment.

   Packet Data Protocol Context

      A Packet Data Protocol (PDP) context is the equivalent of a
      virtual connection between the User Equipment (UE) and a PDN using
      a specific gateway.

   Packet Data Protocol Type

      A Packet Data Protocol Type (PDP Type) identifies the used/allowed
      protocols within the PDP context. Examples are IPv4, IPv6, and
      IPv4v6 (dual-stack).

   Serving GPRS Support Node

      The Serving GPRS Support Node (SGSN) is a network element that is
      located between the radio access network (RAN) and the gateway



Prakash, et.al.          Expires March 23, 2018                 [Page 7]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


      (GGSN). A per-UE point-to-point (p2p) tunnel between the GGSN and
      SGSN transports the packets between the UE and the gateway.

   Terminal Equipment

      The Terminal Equipment (TE) is any device/host connected to the
      Mobile Terminal (MT) offering services to the user.  A TE may
      communicate to an MT, for example, over the Point to Point
      Protocol (PPP).

   UE, MS, MN, and Mobile

      The terms UE (User Equipment), MS (Mobile Station), MN (Mobile
      Node), and mobile refer to the devices that are hosts with the
      ability to obtain Internet connectivity via a 3GPP network. A MS
      is comprised of the Terminal Equipment (TE) and a Mobile Terminal
      (MT). The terms UE, MS, MN, and mobile are used interchangeably
      within this document.

   UMTS Terrestrial Radio Access Network

      The Universal Mobile Telecommunications System (UMTS) Terrestrial
      Radio Access Network (UTRAN) is a communications network, commonly
      referred to as 3G, and consists of NodeBs (3G base stations) and
      Radio Network Controllers (RNCs), which make up the UMTS radio
      access network.  The UTRAN allows connectivity between the UE and
      the core network.  The UTRAN is comprised of WCDMA, HSPA, and
      HSPA+ radio technologies.

   User Plane

      The user plane refers to data traffic and the required bearers for
      the data traffic.  In practice, IP is the only data traffic
      protocol used in the user plane.

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




Prakash, et.al.          Expires March 23, 2018                 [Page 8]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


   The GTP tunnel is used to carry user traffic between gateways and
   mobile devices so the data can only be distributed using unicast
   mechanism. It is also important to understand the overhead of a GTP
   and IPSec protocols because it has impact on the carried user data
   traffic. All mobile backhaul traffic is encapsulated using GTP
   tunnel, which has overhead of 8 bytes on top of IP and UDP [NGMN].
   Additionally, if IPSec is used for security (which is often required
   if the Service provider is using a shared backhaul), it adds overhead
   based upon IPSec tunneling model (tunnel or transport), and
   encryption and authentication header algorithm used. If we factor
   Advanced Encryption Standard (AES) encryption with packet size the
   overhead can vary significantly [IPSEC2].

                                          +-------+  Diameter  +-------+
                                          |  HSS  |------------|  SPR  |
                                          +-------+            +-------+
                                              |                    |
           +------+   +------+      S4        |                +-------+
           |  3G  |---| SGSN |----------------|------+  +------| PCRF  |
        ^  |NodeB |   |      |---------+  +---+      |  |      +-------+
   +-+  |  +------+   +------+   S3    |  |  S6a     |  |Gxc       |
   | |  |                          +-------+         |  |          |Gx
   +-+  |       +------------------|  MME  |------+  |  |          |
   UE   v       |       S1MME      +-------+  S11 |  |  |          |
           +----+-+                              +-------+     +-------+
           |4G/LTE|------------------------------|  SGW  |-----|  PGW  |
           |eNodeB|            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

   When any UE is powered up, it attaches to a mobile network based on
   its configuration and subscription. After successful attach
   procedure, UE registers with the mobile core network and IPv4 and/or



Prakash, et.al.          Expires March 23, 2018                 [Page 9]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


   IPv6 address is assigned. A default bearer is created for each UE and
   it is assigned to default Access Point Name (APN).

   The data delivered to mobile devices is unicast inside GTP tunnel. If
   we consider combined impact of GTP, IPSec and unicast traffic, the
   data 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
   different mechanisms for header compression to achieve efficiency in
   data delivery [TS25.323], and can be used in ICN as well.

2.2  QoS Challenges

   During attach procedure, default bearer is created for each UE and it
   is assigned to the default Access Point Name (APN). The QoS values
   uplink and downlink bandwidth assigned during initial attach are
   minimal. Additional dedicated bearer(s) with enhanced QoS parameters
   is established depending on the specific application needs.

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

   In summary QoS configuration for mobile network for user plane (for
   user traffic) and transport in IP based mobile network is complex and
   it require synchronization of parameters among different platforms.
   Any misconfiguration in IP QoS can result in poor subscriber
   experience. By deploying ICN, we intend to enhance the subscriber
   experience using its inherent capabilities.



Prakash, et.al.          Expires March 23, 2018                [Page 10]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


2.3  Data Transport Using IP

   The data delivered to mobile devices is unicast inside GTP tunnel
   from a eNodeB to a PDN gateway (PGW), 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 multicast protocol 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 data 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 data 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 data to be delivered to the end-user. Other
   issues, such as out-of-order delivery contribute to this complexity
   and inefficiency but could be addressed at the IP transport level.

   The data delivered to mobile devices is unicast inside a GTP tunnel.
   If we consider combined impact of GTP, IPSec and unicast traffic, the
   data delivery is not efficient. By deploying ICN, we intend to either
   terminate GTP tunnel at the edge by leveraging control and user plane
   separation or replace it with the native ICN protocols.

2.4  Virtualizing Mobile Networks

   The Mobile packet core deployed in a major service provider network
   is either based on dedicated hardware or large capacity x86 platforms
   in some cases. With adoption of Mobile Virtual Network Operators
   (MVNO), public safety network, and enterprise mobility network, we
   need elastic mobile core architecture. By deploying mobile packet
   core on a commercially off the shelf (COTS) platform using
   virtualized infrastructure (NFVI) framework and end-to-end
   orchestration, we can simplify new deployments and provide optimized
   total cost of ownership (TCO).

   While virtualization is growing and many mobile providers use hybrid
   architecture consisting of dedicated and virtualized infrastructures,
   the control and data delivery planes are still the same. There is



Prakash, et.al.          Expires March 23, 2018                [Page 11]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


   also work underway to separate control plane 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 for
   LTE and proposed 5G. Some of early architecture work for 5G mobile
   technologies provides mechanism for control and user plane separation
   and simplifies mobility call flow by introduction of open-flow based
   signaling is described in [TS23.501] and [TS23.214].

3.  Data Transport Using ICN

   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.

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

   MEC transforms radio into an intelligent service edge that is capable
   of delivering 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.



Prakash, et.al.          Expires March 23, 2018                [Page 12]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


   Data transport using ICN is different compared to IP-based transport.
   It evolves the Internet infrastructure by introducing uniquely named
   data as a core Internet principle. Communication in ICN takes place
   between content provider (producer) and end user (consumer) as
   described in figure 2.

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

   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
   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 eNodeB. Interest
   packet follows the TLV format [CCNxTLV] 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



Prakash, et.al.          Expires March 23, 2018                [Page 13]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


   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.

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

4.  ICN Deployment in 4G and LTE Networks

4.1 General ICN Deployment Considerations

   In LTE/4G mobile networks, both user and control plane traffic have
   to be transported from the edge to the mobile packet core via IP
   transport. The evolution of existing mobile packet core using CUPS
   [TS23.714] enables flexible network deployment and operation, by
   distributed deployment and the independent scaling between control
   plane and user plane functions - while not affecting the
   functionality of the existing nodes subject to this split.

   In the CUPS architecture, there is an opportunity to shorten the path
   for user plane traffic by deploying offload nodes closer to the edge.
   This optimization allows for the introduction of ICN and amplifies
   its advantages. This section analyzes the potential impact of ICN on
   control and user plane traffic for centralized and disaggregate CUPS
   based mobile network architecture.

4.2 ICN Deployment Scenarios

   Deployment of ICN provides an opportunity to further optimize the
   existing data transport in LTE/4G mobile networks. The various
   deployment options that ICN and IP provide are somewhat analogous to
   the deployment scenarios when IPv6 was introduced to inter operate
   with IPv4, except with ICN the whole IP stack is being replaced.



Prakash, et.al.          Expires March 23, 2018                [Page 14]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


   Authors in [RFC6459] have described the deployment scenarios for
   LTE/4G mobile network using IP (IPv4 and IPv6) transport and analyzed
   the impact of ICN for control plane signaling and user plane data
   delivery. In general ICN can be deployed natively replacing IP
   transport (IPv4 and IPv6) or as an overlay protocol. Figure 4
   describes a modified protocol stack to support ICN deployment
   scenarios.

                 +----------------+ +-----------------+
                 | ICN App (new)  | |IP App (existing)|
                 +---------+------+ +-------+---------+
                           |                |
                 +---------+----------------+---------+
                 | Transport Convergence Layer (new)  |
                 +------+---------------------+-------+
                        |                     |
                 +------+------+       +------+-------+
                 |ICN function |       | IP function  |
                 |   (New)     |       | (Existing)   |
                 +------+------+       +------+-------+
                        |                     |
                      (```).                (```).
                    (  ICN  '`.           (  IP   '`.
                    ( Cloud   )           ( Cloud   )
                     ` __..'+'             ` __..'+'


           Fig. 4. IP/ICN Convergence and Deployment Scenarios

   As shown in figure 4, for applications running either in UE or in
   content provider system to use the new transport option, we propose a
   new transport convergence layer (TCL). This transport convergence
   layer helps determine what type of transport (e.g. ICN or IP), as
   well as type of radio interface (e.g. LTE or WiFi or both), is used
   to send and receive the traffic based on preference e.g. content
   location, content type, content publisher, congestion, cost, quality
   of service etc. It helps to configure and decide the type of
   connection as well as the overlay mode (ICNoIP or IPoICN) between
   application and the protocol stack (IP or ICN) to be used.

   TCL can use a number of mechanisms for the selection of transport. It
   can use a per application configuration through a management
   interface, possibly even a user-facing setting realized through a
   user interface, similar to those used today that select cellular over
   WiFi being used for selected applications. In another option, it
   might use a software API, which an adapted IP application could use
   to specify e.g. an ICN transport for obtaining its benefits.




Prakash, et.al.          Expires March 23, 2018                [Page 15]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


   Another potential application of TCL is in implementation of network
   slicing, where it can have a slice management capability locally or
   it can interface to an external slice manager through an API [GALIS].
   This solution can enable network slicing for IP and ICN transport
   selection from the UE itself. The TCL could apply slice settings to
   direct certain traffic (or applications) over one slice and others
   over another slice, determined by some form of 'slicing policy'.
   Slicing policy can be obtained externally from slice manager or
   configured locally on UE.

   From the perspective of the applications either on UE or content
   provider, four different options are possible for the deployment of
   ICN natively and/or with IP.

      1. IP over IP

         In this scenario UE uses applications tightly integrated with
         the existing IP transport infrastructure. In this option, the
         TCL has no additional function since the packets are directly
         forwarded using IP protocol stack, which in turn sends the
         packets over the IP transport.

      2. ICN over ICN

         Similar to case 1 above, ICN applications tightly integrate
         with the ICN transport infrastructure. The TCL has no
         additional responsibility since the packets are directly
         forwarded using ICN protocol stack, which in turn sends the
         packets over the ICN transport.

      3. ICN over IP (ICNoIP)

         In ICN over IP scenario, the underlying IP transport
         infrastructure is not impacted; however, ICN is implemented
         between user equipment (UE), the Radio Access Network (eNodeB)
         and Mobile Gateway (SGW/PGW) for user plane data communication.

         An alternative approach to implement ICN over IP is provided in
         Hybrid ICN [HICN], which implements ICN over IP by mapping of
         ICN names to the IPv4/IPv6 addresses.

         Detailed deployment of use cases is described in section 4.4.
         Application conveys the preference to the TCL, which in turn
         sends the ICN data packets using the IP transport.

      4. IP over ICN (IPoICN)

         H2020 project [H2020] provides an architectural framework for



Prakash, et.al.          Expires March 23, 2018                [Page 16]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


         deployment of IP as an overlay over ICN protocol [IPICN].
         Implementing IP services over ICN provides an opportunity
         leveraging benefit of ICN in the transport infrastructure and
         there is no impact on end devices (UE and access network) as
         they continue to use IP. IPoICN however, will require an inter-
         working function (IWF/Border Gateway) to translate various
         transport primitives such as transport of tunnel mode. IWF
         function will provide a mechanism for protocol translation
         between IPoICN and native IP deployment for mobile network.
         After reviewing [IPICN], we understand and interpret that ICN
         is implemented in the transport natively; however, IP is
         implemented in UE, eNodeB, and Mobile gateway (SGW/PGW), which
         is also called as network attach point (NAP).

4.3  ICN Deployment in LTE Control Plane

   In this section we analyze signaling messages which are required for
   different procedures, such as attach, handover, tracking area update
   etc. The goal of analysis is to see if there is any benefit to
   replace IP-based protocols with ICN for LTE 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. 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.

   In current architecture IP transport is used for all the messages
   associated with Control Plane for mobility and session management. IP
   is embedded very deeply into these messages and TLV carrying
   additional attributes as a layer 3 transport . Physical POA in eNodeB
   handles both mobility and session management for any UE attached to
   4G, LTE network. The number of mobility management messages between
   different nodes in an LTE network per signaling procedure are given
   below in figure 5.

   Normally two types of UE devices attach to LTE network: SIM based
   (need 3GPP mobility protocol for authentication) or non-SIM based
   (which connect to WiFi network), and authentication is required for
   both of these device types. For non-SIM based devices, AAA is used
   for authentication. We do not propose to change UE authentication
   procedures for user data transport using ICN, or any other mobility
   management messaging. A separate study would be required to analyze



Prakash, et.al.          Expires March 23, 2018                [Page 17]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


   impact of ICN on mobility management messages structures and flows.
   We are merely analyzing the viability of implementing ICN as a
   transport for Control plane messages.

   +---------------------------+-------+-------+-------+-------+------+
   | LTE Signaling Procedures  |  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. 5. Signaling Messages in LTE Gateways

   It is important to note that even if we don't 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 to
   authenticate an ICN capable UE and authorize create session
   [TS23.401].

   Anchorless mobility [ALM] has made some important comments on how
   mobility management is done in ICN. Author comments about handling
   mobility without having a dependency on the core network function
   e.g. MME. However, location update to the core network would still be
   required to support some of the legal compliance requirements such as
   lawful intercept and emergency services.

   The main advantage of ICN is in caching and reusing the content,
   which does not apply to the transactional signaling exchange. After
   analyzing LTE signaling call flows [TS23.401] and messages inter-
   dependencies [Fig 4], our recommendation is that it is not beneficial
   to deploy ICN for control plane and mobility management functions.

4.4  ICN Deployment in LTE 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




Prakash, et.al.          Expires March 23, 2018                [Page 18]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


      2. Native ICN Deployments in UE

      3. ICN Deployment in eNodeB

      4. ICN Deployment in mobile gateways (SGW/PGW)

4.4.1  Dual stack ICN Deployments in UE

   The control and user plane communications in LTE, 4G mobile networks
   are specified in 3GPP documents [TS23.323] [TS23.203] [TS23.401]. 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 complex as it has to
   support multiple radio connectivity access to eNodeB(s).

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

   +--------+                                               +--------+
   |   App  |                                               |  CDN   |
   +--------+                                  +--------+   +--------+
   |Transp. | |              |               | |Transp. | | |Transp. |
   |Converg.| |..............|...............|.|Converge|.|.|Converge|
   +--------+ |              |               | +--------+ | +--------+
   |        |.|..............|...............|.|        |.|.|        |
   | 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. 6. Dual stack ICN Deployment in UE

   The protocol interactions and impact of supporting tunneling of ICN
   packet into IP or to support ICN natively are described in figure 6
   and figure 7 respectively.



Prakash, et.al.          Expires March 23, 2018                [Page 19]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


   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 describes the use of IP and non-IP
   protocols to establish logical/session connectivity. We intend to
   leverage the non-IP protocol based mechanism to deploy ICN protocol
   stack in UE as well as in eNodeB and mobile gateways (SGW, PGW).

                      +----------------+ +-----------------+
                      | ICN App (new)  | |IP App (existing)|
                      +---------+------+ +-------+---------+
                                |                |
                      +---------+----------------+---------+
                      | Transport Convergence Layer (new)  |
                      +------+---------------------+-------+
                             |                     |
                      +------+------+       +------+-------+
                      |ICN function |       | IP function  |
                      |   (New)     |       | (Existing)   |
                      +------+------+       +------+-------+
                             |                     |
                      +------+---------------------+-------+
                      | PDCP (updated to support ICN)      |
                      +-----------------+------------------+
                                        |
                      +-----------------+------------------+
                      |          RLC (Existing)            |
                      +-----------------+------------------+
                                        |
                      +-----------------+------------------+
                      |        MAC Layer (Existing)        |
                      +-----------------+------------------+
                                        |
                      +-----------------+------------------+
                      |       Physical L1 (Existing)       |
                      +------------------------------------+

                   Fig. 7. Dual stack ICN protocol interactions

      1. Existing application layer can be modified to provide options
         for new ICN based application and existing IP based
         applications. UE can continue to support existing IP based
         applications or host new applications developed either to
         support native ICN as transport, ICNoIP or IPoICN based
         transport. Application layer has the option of selecting either
         ICN or IP transport layer as well as radio interface to send
         and receive data traffic.

         Our proposal is to provide a common Application Programming



Prakash, et.al.          Expires March 23, 2018                [Page 20]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


         Interface (API) to the application developers such that there
         is no impact on the application development when they choose
         either ICN or IP transport for exchanging the traffic with the
         network. As mentioned in section 4.2, the transport convergence
         layer (TCL) function handles the interaction of application
         with the multiple transport options.

      2. The transport convergence layer helps determine what type of
         transport (e.g. ICN or IP) as well as type of radio interface
         (e.g. LTE or WiFi or both), is used to send and receive the
         traffic. Application layer can make the decision to select a
         specific transport based on preference e.g. content location,
         content type, content publisher, congestion, cost, quality of
         service etc. There can be an Application Programming Interface
         (API) to exchange parameters required for transport selection.
         The southbound interactions of Transport Convergence Layer
         (TCL) will be either to IP or ICN at the network layer.

      3. ICN function (forwarder) is introduced in parallel to the
         existing IP layer. ICN forwarder contains functional
         capabilities to forward ICN packets, e.g. Interest packet to
         eNodeB or response "data packet" from eNodeB to the
         application.

      4. For dual stack scenario, when UE is not supporting ICN at
         transport layer, we use IP underlay to transport ICN packets.
         ICN function will use IP interface to send Interest and Data
         packets for fetching or sending data using ICN protocol
         function. This interface will use ICN overlay over IP using any
         overlay tunneling mechanism.

      5. To support ICN at network layer in UE, PDCP layer has to be
         aware of ICN capabilities and parameters. PDCP is located in
         the Radio Protocol Stack in the LTE Air interface, between IP
         (Network layer) and Radio Link Control Layer (RLC). PDCP
         performs following functions [TS36.323]:

         a) Data transport by listening to upper layer, formatting and
            pushing down to Radio Link Layer (RLC)

         b) Header compression and decompression using ROHC (Robust
            Header Compression)

         c) Security protections such as ciphering, deciphering and
            integrity protection

         d) Radio layer messages associated with sequencing, packet drop
            detection and re-transmission etc.



Prakash, et.al.          Expires March 23, 2018                [Page 21]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


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

4.4.2  Native ICN Deployments in UE

   We propose to implement ICN natively in UE by modifying PDCP layer in
   3GPP protocols. Figure 7 below provides a high-level protocol stack
   description where ICN is used at two different 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. |
   |Converge|.|..............|..............|..............|.|COnverge|
   +--------+ |              |              |              | +--------+
   |        |.|..............|..............|..............|.|        |
   | 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. 8. Native ICN Deployment in UE

   If we implement ICN natively in UE, communication between UE and



Prakash, et.al.          Expires March 23, 2018                [Page 22]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


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

4.5  ICN Deployment in eNodeB

   eNodeB is physical point of attachment for UE, where radio protocols
   are converted into IP transport protocol as depicted in figure 7 and
   figure 8 for dual stack/overlay and native ICN respectively. When UE
   performs attach procedures, it is assigned an identity either as IP,
   dual stack (IP and ICN), or ICN. UE can initiate data traffic using
   any of three different options:

      1. Native IP (IPv4 or IPv6)

      2. Native ICN

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

   UE encapsulates user data transport request into PDCP layer and sends
   the information on air interface to eNodeB. eNodeB receives the
   information and using PDCP [TS 36.323], de-encapsulates air-interface
   messages and converts them to forward to core mobile gateways (SGW,
   PGW). In order to support ICN natively in eNodeB, it is proposed to
   provide transport convergence layer (TCL) capabilities in eNodeB
   (similar as provided in UE), which provides following functions:

      1. It decides the forwarding strategy for user data request coming
         from UE. The strategy can make decision based on preference
         indicated by the application such as congestion, cost, quality
         of service, etc.

      2. eNodeB to provide open Application Programming Interface (API)
         to external management systems, to provide capability to eNodeB
         to program the forwarding strategies.

      3. eNodeB shall be upgraded to support three different types of
         transport: IP, ICN, and dual stack IP+ICN towards mobile



Prakash, et.al.          Expires March 23, 2018                [Page 23]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


         gateways, as depicted in figure 9. It is also recommended to
         deploy IP and/or ICN forwarding capabilities into eNodeB for
         efficient transfer of data between eNodeB and mobile gateways.
         There can be four choices for forwarding data request towards
         mobile gateways:

         a) Assuming eNodeB is IP-enabled and UE requests IP transfer,
            eNodeB forwards data over IP.

         b) Assuming eNodeB is ICN-enabled and UE requests ICN transfer,
            eNodeB forwards data over ICN.

         c) Assuming eNodeB is IP-enabled and UE requests ICN, eNodeB
            overlays ICN on IP and forwards the user plane traffic over
            IP.

         d) Assuming eNodeB is ICN-enabled and UE requests IP, eNodeB
            overlays IP on ICN and forwards the user plane traffic over
            ICN [IPoICN].

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

                   Fig. 9. Native ICN Deployment in eNodeB

4.6  ICN Deployment in Packet Core (SGW, PGW) Gateways

   Mobile gateways a.k.a. Evolved Packet Core (EPC) include SGW, PGW,
   which 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,



Prakash, et.al.          Expires March 23, 2018                [Page 24]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


   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 or PGW, it contains Protocol Configuration
         Option Information Element (PCO IE) containing UE capabilities.
         We can use PCO IE to carry ICN related capabilities information
         from UE to PGW. This information is received from UE during the
         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 assigns the UE both IP address and
         ICN identity. UE selects either of the identities during the
         initial attach procedures and registers with network 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) provide 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
           mobile gateways (SGW, PGW) so that they can be interpreted



Prakash, et.al.          Expires March 23, 2018                [Page 25]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


           properly and UE can attach successfully.

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

      7. Mobile gateways SGW, PGW will also need ICN forwarding and
         caching capability.

      8. The transport between PGW and CDN provider can be either IP or
         ICN. When UE is attached to PGW with ICN identity and
         communicates with an ICN-enabled CDN provider, it will use ICN
         primitives to fetch the data. On other hand, for an UE attached
         with an ICN identity, if PGW has to communicate with an IP-
         enabled CDN provider, it will have to use an ICN-IP
         interworking gateway to perform conversion between ICN and IP
         primitives for data retrieval. Further study is required to
         understand how this ICN to IP (and vice versa) interworking
         gateway would function.

5. Security Considerations

   To ensure only authenticated UEs are connected to the network, LTE
   mobile network implements various security mechanisms. From
   perspective of ICN deployment in user plane, it needs to take care of
   the following security aspects:

      1. UE authentication and authorization

      2. Radio or air interface security

      3. Denial of service attacks on mobile gateway, services

      4. Content positioning either in transport or servers

      5. Content cache pollution attacks

      6. Secure naming, routing, and forwarding

      7. Application security

   Security over the LTE air interface is provided through cryptographic
   technique. When UE is powered up, it performs key exchange between
   UE's USIM and HSS/Authentication Center using NAS messages including
   ciphering and integrity protections between UE and MME. Details of
   secure UE authentication, key exchange, ciphering and integrity
   protections messages are given in 3GPP call flow [TS23.401].




Prakash, et.al.          Expires March 23, 2018                [Page 26]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


   LTE is an all-IP network and uses IP transport in its mobile backhaul
   (e.g. between eNodeB and core network). In case of provider owned
   backhaul, it may not implement security mechanisms; however, they are
   necessary in case it uses shared or a leased network. The native IP
   transport continues to leverage security mechanism such as Internet
   key exchange (IKE) and the IP security protocol (IPsec). More details
   of mobile backhaul security are provided in 3GPP network security
   [TS33.310] and [TS33.320]. When mobile backhaul is upgraded to
   support dual stack (IP+ICN) or native ICN, it is required to
   implement security techniques which are deployed in mobile backhaul.
   When ICN forwarding is enabled on mobile transport routers, we need
   to deploy security practices based on RFC7476 and RFC7927.

   Some of the key functions supported by LTE mobile gateway (SGW, PGW)
   are content based billing, deep packet inspection (DPI), and lawful
   intercept (LI). For ICN-based user plane traffic, it is required to
   integrate ICN security for session between UE and gateway; however,
   in ICN network, since only consumers who are in possession of
   decryption keys can access the content, some of the services provided
   by mobile gateways mentioned above may not work. Further research in
   this area is needed.

6. Summary

   In this draft, we have discussed complexities of LTE network and key
   dependencies for deploying ICN in user plane data transport.
   Different deployment options described cover aspects such as inter-
   operability and multi-technology, which is a reality for any service
   provider. We are currently evaluating the ICN deployment options,
   described in section 4, using LTE gateway software and ICN simulator.
   One can deploy ICN for data transport in user plane either as an
   overlay, dual stack (IP + ICN) or natively (by integrating ICN with
   CDN, eNodeB, SGW, PGW and transport network etc.). It is important to
   understand that for above discussed deployment scenarios, additional
   study is required for lawful interception, billing/mediation, network
   slicing, and provisioning APIs.

   Based on our study of control plane signaling it is not beneficial to
   deploy ICN with existing protocols unless further changes are
   introduced in the control protocol stack itself. As mentioned in
   [TS23.501], 5G network architecture proposes simplification of
   control plane messages and can be a candidate for use of ICN.

   As a starting step towards ICN user plane deployment, it is
   recommended to incorporate protocol changes in UE, eNodeB, SGW/PGW
   for data transport. ICN has inherent capabilities for mobility and
   content caching, which can improve the efficiency of data transport
   for unicast and multicast delivery.



Prakash, et.al.          Expires March 23, 2018                [Page 27]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


   Mobile Edge Computing (MEC) [CHENG] provides capabilities to deploy
   functionalities such as Content Delivery Network (CDN) caching and
   mobile user plane functions (UPF) [TS23.501]. Recent research for
   delivering real-time video content using ICN has also been proven to
   be efficient [NDNRTC] and can be used towards realizing the benefits
   of ICN deployment in eNodeB, MEC, mobile gateways (SGW, PGW) and CDN.
   The key aspect for ICN is in its seamless integration in LTE and 5G
   networks with tangible benefits so that we can optimize content
   delivery using simple and scalable architecture. Authors will
   continue to explore how ICN forwarding in MEC could be used in
   efficient data delivery from mobile edge.








































Prakash, et.al.          Expires March 23, 2018                [Page 28]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 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.

   [IPSEC1]   Cisco IPSec overhead calculator tool
              <https://cway.cisco.com/tools/ipsec-overhead-calc/ipsec-
              overhead-calc.html>.

   [IPSEC2]   IPSec Bandwidth Overhead Using AES
              <http://packetpushers.net/ipsec-bandwidth-overhead-using-
              aes/>.

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

   [TS25.323] 3GPP TS25.323 Rel. 14 (2017-03) Packet Data Convergence
              Protocol (PDCP) specification.

   [TS23.501] 3GPP TS23.501 Rel. 15 (2017-06) System Architecture for
              the 5G System.

   [TS23.203] 3GPP TS23.203 Rel. 14 (2017-03) Policy and charging
              control and QoS architecture

   [TS23.401] 3GPP TS23.401 Rel. 14 (2017-03) E-UTRAN Access procedures
              architecture

   [TS33.310] 3GPP TS33.310 Rel. 14 (2016-12) LTE Network Domain
              Security (NDS); Authentication Framework (AF)

   [TS33.320] 3GPP TS33.320 Rel. 14 (2016-12) Security of Home Node B
              (HNB) / Home evolved Node B (HeNB)

   [TS24.008] 3GPP TS24.008 Rel. 14 (2017-06) Mobile radio interface
              Layer 3 specification.

   [TS23.501] 3GPP TS23.501 Rel. 14 (2017-06) System Architecture for
              the 5G System

   [TS23.214] 3GPP TS23.214 Rel. 14 (2017-06) Architecture enhancements
              for control and user plane separation of EPC nodes

   [TS36.323] 3GPP TS36.323 Rel. 14 (2017-06) Evolved Universal



Prakash, et.al.          Expires March 23, 2018                [Page 29]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


              Terrestrial Radio Access (E-UTRA); Packet Data Convergence
              Protocol (PDCP) specification

   [TS23.714] 3GPP TS23.714 Rel. 14 (2016-06) Technical Specification
              Group Services and System Aspects: Study on control and
              user plane separation of EPC nodes

   [RFC7476]  Information-Centric Networking: Baseline Scenarios

   [RFC7927]  Information-Centric Networking (ICN) Research Challenges

   [RFC6459]  IPv6 in 3GPP Evolved Packet System (EPS)


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.

   [CCNxTLV]   CCNx Messages in TLV Format
              https://datatracker.ietf.org/doc/draft-irtf-icnrg-
              ccnxmessages/

   [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. Aug'e, 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.

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




Prakash, et.al.          Expires March 23, 2018                [Page 30]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


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

   [NGMN]     Backhaul Provisioning for LTE-Advanced & Small Cells
              <https://www.ngmn.org/uploads/media/150929_NGMN_P-
              SmallCells_Backhaul_for_LTE-Advanced_and_Small_Cells.pdf>

   [IPoICN]   IP Over ICN - The Better IP?
              <http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7194109>

   [HICN]     Cisco Hybrid ICN <http://blogs.cisco.com/sp/cisco-
              announces-important-steps-toward-adoption-of-information-
              centric-networking>

   [GALIS]    Autonomic Slice Networking-Requirements and Reference
              Model <https://www.ietf.org/id/draft-galis-anima-
              autonomic-slice-networking-02.txt>



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


   Dirk Trossen



Prakash, et.al.          Expires March 23, 2018                [Page 31]


Internet-Draft  Deploying ICN in 4G, LTE Mobile Networks    Sept 19 2017


   InterDigital Inc.
   64 Great Eastern Street, 1st Floor
   London  EC2A 3QR
   United Kingdom

   Email: Dirk.Trossen@InterDigital.com













































Prakash, et.al.          Expires March 23, 2018                [Page 32]