ICN Research Group                                        Prakash Suthar
Internet-Draft                                              Milan Stolic
Intended status: Informational                          Anil Jangam, Ed.
Expires: September 12, 2019                           Cisco Systems Inc.
                                                            Dirk Trossen
                                                       InterDigital Inc.
                                                   Ravishankar Ravindran
                                                     Huawei Technologies
                                                          March 11, 2019


          Native Deployment of ICN in LTE, 4G Mobile Networks
                     draft-irtf-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 proposed
   approaches in this draft allow ICN to be enabled natively over the
   current LTE stack comprising of PDCP/RLC/MAC/PHY or in a dual stack
   mode (along with IP) help optimize the mobile networks by leveraging
   the inherent benefits of ICN.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.




Prakash Suthar, et al. Expires September 12, 2019               [Page 1]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 12, 2019.

Copyright Notice

   Copyright (c) 2019 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
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Conventions and Terminology . . . . . . . . . . . . . . .   3
     1.2.  3GPP Terminology and Concepts . . . . . . . . . . . . . .   3
   2.  LTE, 4G Mobile Network  . . . . . . . . . . . . . . . . . . .   7
     2.1.  Network Overview  . . . . . . . . . . . . . . . . . . . .   7
     2.2.  QoS Challenges  . . . . . . . . . . . . . . . . . . . . .   9
     2.3.  Data Transport Using IP . . . . . . . . . . . . . . . . .  10
     2.4.  Virtualizing Mobile Networks  . . . . . . . . . . . . . .  11
   3.  Data Transport Using ICN  . . . . . . . . . . . . . . . . . .  11
   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 . . . . . . . . . . .  18
     4.4.  ICN Deployment in LTE User Plane  . . . . . . . . . . . .  19
       4.4.1.  Dual stack ICN Deployments in UE  . . . . . . . . . .  20
       4.4.2.  Native ICN Deployments in UE  . . . . . . . . . . . .  23
     4.5.  ICN Deployment in eNodeB  . . . . . . . . . . . . . . . .  24
     4.6.  ICN Deployment in Packet Core (SGW, PGW) Gateways . . . .  26
     4.7.  Lab Testing . . . . . . . . . . . . . . . . . . . . . . .  28
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  29
   6.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  30
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  31
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  31
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  31



Prakash Suthar, et al. Expires September 12, 2019               [Page 2]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


     8.2.  Informative References  . . . . . . . . . . . . . . . . .  32
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  36

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.  Conventions and 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 [RFC2119].

1.2.  3GPP Terminology and Concepts

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

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



Prakash Suthar, et al. Expires September 12, 2019               [Page 3]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


        with mobile gateways (SGW/PGW).  Functions of the control plane
        also include system configuration and management.

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

   4.   eNodeB

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

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

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

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

   8.   GPRS Tunnelling Protocol

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



Prakash Suthar, et al. Expires September 12, 2019               [Page 4]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


   9.   Gateway GPRS Support Node

        The Gateway GPRS Support Node (GGSN) is a gateway function in
        the 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.

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

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

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

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

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




Prakash Suthar, et al. Expires September 12, 2019               [Page 5]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


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

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

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

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

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

   20.  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 (GGSN).  A per-UE point-to-point (p2p) tunnel between
        the GGSN and SGSN transports the packets between the UE and the
        gateway.

   21.  Terminal Equipment



Prakash Suthar, et al. Expires September 12, 2019               [Page 6]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


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

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

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

   The GTP tunnel is used to carry user traffic between gateways and
   mobile devices, this forces data to be only 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 the packet size,
   the overhead can be significant [OLTEANU], particularly for the
   smaller payloads.





Prakash Suthar, et al. Expires September 12, 2019               [Page 7]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


   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
   IPv6 address is assigned.  A default bearer is created for each UE
   and it is assigned to default Access Point Name (APN).

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

   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



Prakash Suthar, et al. Expires September 12, 2019               [Page 8]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


   data delivery [TS25.323], and can be adapted to ICN as well
   [ICNLOWPAN] [TLVCOMP].

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.401]; however, this requires manual configuration at different
   elements and if there are misconfigurations 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 requires synchronization of parameters among different platforms.
   Normally QoS in IP is implemented using DiffServ, which uses hop-by-
   hop QoS configuration at each router.  Any inconsistency in IP QoS
   configuration at routers in the forwarding path can result in poor
   subscriber experience (e.g. packet classified as high-priority can go
   to lower priority queue).  By deploying ICN, we intend to enhance the
   subscriber experience using policy-based configuration, which can be
   associated with the named contents [ICNQoS] at ICN forwarder.
   Further investigation is needed to understand how QoS in ICN can be
   implemented to meet the IP QoS requirements [RFC4594].

   Research papers published so far explore the possibility of
   classifications based on name prefixes (thus addressing the problem
   of IP QoS not being information-aware), or on popularity or placement
   (basically, looking at a distance of a content from a requester).



Prakash Suthar, et al. Expires September 12, 2019               [Page 9]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


   However, a common limitation of these research efforts is that they
   focus on faster routing of Interest request towards the content
   rather than the quality of experience based on actual content
   delivery.  For that to happen, QoS should be implemented and enforced
   on the Data packet path.

2.3.  Data Transport Using IP

   The data delivered to mobile devices is unicast inside GTP tunnel
   from an 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.
   Techniques to handle multicast such as LTE-B or eMBMS have been
   designed to handle pre-planned content delivery such as live content,
   which contrasts user behavior today, largely based on content (or
   video) on demand model.

   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, which needs to be addressed at the application
   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
   end-to-end data delivery is not efficient.  By deploying ICN, we
   intend to either terminate GTP tunnel at the mobility anchoring point
   by leveraging control and user plane separation or replace it with
   the native ICN protocols.







Prakash Suthar, et al. Expires September 12, 2019              [Page 10]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


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
   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 core.  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 [ICN5G].  This has been
   considered by 3GPP [EPCCUPS] and is also described in [SDN5G].

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.



















Prakash Suthar, et al. Expires September 12, 2019              [Page 11]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


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


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

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





Prakash Suthar, et al. Expires September 12, 2019              [Page 12]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


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


             Figure 3: ICN Interest, Data Packet and Forwarder

   In an 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 content matching restrictions
   (KeyIdRestr and ContentObjectHashRestr) forming the tuple [CCNxSem].
   The content matching tuple uniquely identifies the correlation
   between an Interest and data packet.  Another attribute called
   HopLimit is used to detect looping Interest messages.  Interest
   looping is not prevented, and looped Interest packets are eventually
   discarded at the expiry of HopLimit.

   An 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



Prakash Suthar, et al. Expires September 12, 2019              [Page 13]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


   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
   [OFFLOAD].  With this major architecture change, User Plane Function
   (UPF) node is placed close to the edge so traffic no longer needs to
   traverse the entire backhaul path to reach the EPC.  In many cases,
   where feasible, UPF can be collocated with the eNodeB, which is also
   a business decision based on the user demand.  Placing a Publisher
   close to the offload site, or at the offload site, provides for a
   significant improvement in user experience, especially with the
   latency-sensitive applications.  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.  We
   have reviewed [RFC6459] and analyzed the impact of ICN on control
   plane signaling and user plane data delivery.  In general, ICN can be
   deployed by natively replacing IP transport (IPv4 and IPv6) or as an




Prakash Suthar, et al. Expires September 12, 2019              [Page 14]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


   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   )
                       ` __..'+'             ` __..'+'


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

   The ICN function together with existing IP function provides the
   support for either native ICN and/or the dual stack (ICN/IP)
   transport functionality.  More elaborate description on these
   functional layers are provided in Section 4.4.1.

   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 Suthar, et al. Expires September 12, 2019              [Page 15]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


   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, following 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 (i.e.  ICN is implemented, as an
       IP overlay, between user equipment (UE) and content provider).
       IP routing is used from Radio Access Network (eNodeB) to mobile
       backhaul, IP core and Mobile Gateway (SGW/PGW).  UE attaches to
       Mobile Gateway (SGW/PGW) using IP address.  Also, the data
       transport between Mobile Gateway (SGW/PGW) and content publisher
       uses IP.  Content provider is capable of serving content either
       using IP or ICN, based on UE request.

       An approach to implement ICN in mobile backhaul networks is
       described in [MBHICN].  It implements a GTP-U extension header
       option to encapsulate ICN payload in GTP tunnel.  However, as
       this design runs ICN as an overlay over IP, it would complement
       only ICNoIP use case scenario described in this draft.  In




Prakash Suthar, et al. Expires September 12, 2019              [Page 16]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


       addition, the design assumes a proxy function at the edge, to
       perform ICN data retrieval on behalf of a non-ICN end device.

       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
       deployment of IP as an overlay over ICN protocol [IPoICN].
       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.  IWF function will provide a mechanism for
       protocol translation between IPoICN and native IP deployment for
       mobile network.  After reviewing [IPoICN], 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).

       For this, said NAP receives an incoming IP or HTTP packet (the
       latter through TCP connection termination) and publishes the
       packet under a suitable ICN name (i.e. the hash over the
       destination IP address for an IP packet or the hash over the FQDN
       of the HTTP request for an HTTP packet) to the ICN network.  In
       the HTTP case, the NAP maintains a pending request mapping table
       to map returning responses to the terminated TCP connection.

   5.  Hybrid ICN (hICN)

       An alternative approach to implement ICN over IP is provided in
       Hybrid ICN [HICN].  It describes a novel approach to integrate
       ICN into IPv6 without creating overlays with a new packet format
       as an encapsulation.  HICN address the content by encoding a
       location independent name in an IPv6 address.  It uses two name
       components, namely name prefix and name suffix, which identify
       the source of data and the data segment within the scope of name
       prefix respectively.

       From the perspective of this draft, HICN provides an alternative
       transport layer, to be used by the UE and mobile core network
       nodes, which can be selected by the TCL.






Prakash Suthar, et al. Expires September 12, 2019              [Page 17]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


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 following
   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 shown
   in Table 1.

   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 or
   mobility management messaging for user data transport using ICN.  A
   separate study would be required to analyze 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.

   It is important to note that even if MME and HSS do not support ICN
   transport, they still need to support UE capable of dual stack or
   native ICN.  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].






Prakash Suthar, et al. Expires September 12, 2019              [Page 18]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


       +---------------------------+-----+-----+-----+-----+------+
       | 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 |    0 |
       | 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 |   2 |   0 |   0 |    0 |
       | Total                     |  34 |   2 |  14 |   6 |    3 |
       +---------------------------+-----+-----+-----+-----+------+

                Table 1: Signaling Messages in LTE Gateways

   Anchorless mobility [ALM] provides a fully decentralized, control-
   plane agnostic solution to handle producer mobility in ICN.  Mobility
   management at layer-3 level makes it access agnostic and transparent
   to the end device or the application.  The solution discusses about
   handling of mobility without having to depend on the core network
   functions (e.g.  MME); however, location update to the core network
   may still be required to support legal compliance requirements such
   as lawful intercept and emergency services.  These aspects are open
   for further study.

   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 Table 1, our recommendation is that it is not beneficial
   to deploy ICN for control plane and mobility management functions.
   Among the features of ICN design such as, Interest aggregation and
   content caching is not applicable to control plane signaling
   messages.  Control plane messages are originated and consumed by the
   applications and they canot be shared.

4.4.  ICN Deployment in LTE User Plane

   We will consider Figure 1 to discuss different mechanisms to deploy
   ICN in mobile networks.  In section 4.2 we discussed generi
   deployment scenarios of ICN.  In this section, we shall see the
   specific use cases of native ICN deployment in LTE user plane.  We
   consider the following options:

   1.  Dual stack ICN deployment in UE

   2.  Native ICN Deployments in UE




Prakash Suthar, et al. Expires September 12, 2019              [Page 19]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


   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.203] and [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 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.

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

    +--------+                                               +--------+
    |   App  |                                               |  CDN   |
    +--------+                                               +--------+
    |Transp. | |              |               |              |Transp. |
    |Converg.|.|..............|...............|............|.|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


                 Figure 5: Dual stack ICN Deployment in UE




Prakash Suthar, et al. Expires September 12, 2019              [Page 20]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


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

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

       When selecting the IPoICN mode, the TCL is responsible for
       receiving an incoming IP or HTTP packet and publishing the packet
       under a suitable ICN name (i.e. the hash over the destination IP
       address for an IP packet or the hash over the FQDN of the HTTP
       request for an HTTP packet) to the ICN network.  In the HTTP
       case, the TCL maintains a pending request mapping table to map
       returning responses to the originating HTTP request.  The common
       API will provide a common 'connection' abstraction for this HTTP
       mode of operation, returning the response over said connection
       abstraction, akin to the TCP socket interface, while implementing
       a reliable transport connection semantic over the ICN from the UE
       to the receiving UE or the PGW.  If the HTTP protocol stack
       remains unchanged, therefore utilizing the TCP protocol for




Prakash Suthar, et al. Expires September 12, 2019              [Page 21]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


       transfer, the TCL operates in local TCP termination mode,
       retrieving the HTTP packet through said local termination.

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


              Figure 6: Dual stack ICN protocol interactions

   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.





Prakash Suthar, et al. Expires September 12, 2019              [Page 22]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


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

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

       2.  Header compression and decompression using ROHC (Robust
           Header Compression)

       3.  Security protections such as ciphering, deciphering and
           integrity protection

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

   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 provides a high-level protocol stack
   description where ICN is used at following 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.

   If we implement ICN natively in UE, communication between UE and
   eNodeB will change.  Also, this will avoid tunneling the user plane
   traffic from eNodeB to mobile packet core (SGW, PGW) using GTP
   tunnel.

   For native ICN deployment, an application will be configured to use
   ICN forwarder so there is no need for Transport Convergence.  Also,



Prakash Suthar, et al. Expires September 12, 2019              [Page 23]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


   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 traversing the
   mobile gateways, 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


                   Figure 7: Native ICN Deployment in UE

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 6 and
   Figure 7 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 the follwing options:

   1.  Native IP (IPv4 or IPv6)

   2.  Native ICN

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



Prakash Suthar, et al. Expires September 12, 2019              [Page 24]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


   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 [TS36.323], de-encapsulates air-interface
   messages and converts them to forward to core mobile gateways (SGW,
   PGW).  As shown in Figure 8, in order to support ICN natively in
   eNodeB, it is proposed to provide transport convergence layer (TCL)
   capabilities in eNodeB (similar to 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.

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


                 Figure 8: Native ICN Deployment in eNodeB

   3.  eNodeB shall be upgraded to support three different types of
       transport: IP, ICN, and dual stack IP+ICN towards mobile
       gateways, as depicted in Figure 8.  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 are following choices for forwarding data request towards
       mobile gateways:




Prakash Suthar, et al. Expires September 12, 2019              [Page 25]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


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

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

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

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

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,
   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 attributes in 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.




Prakash Suthar, et al. Expires September 12, 2019              [Page 26]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


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

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

       2.  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
           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.  This is especially important if CUPS is
       implemented.  User Plane Function (UPF), comprising the SGW and
       PGW user plane, will be located at the edge of the network and
       close to the end-user.  ICN-enabled gateway means that this UPF
       would serve as a forwarder and should be capable of caching, as
       is the case with any other ICN-enabled node.

   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 a 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.  In the case of CUPS implementation with an
       offload close to the edge, this interworking gateway can be
       collocated with the UPF at the offload site to maximize the path
       optimization.  Further study is required to understand how this
       ICN to IP (and vice versa) interworking gateway would function.






Prakash Suthar, et al. Expires September 12, 2019              [Page 27]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


4.7.  Lab Testing

   To further test the modifications proposed above in different
   scenarios, a simple lab has been set up as shown in Figure 9.

     +------------------------------------------+
     | +-----+   +------+   (```).     +------+ |   (````).    +-----+
     | | SUB |-->| EMU  |--(x-haul'.-->| EPC  |--->(  PDN ).-->| CDN |
     | +-----+   +------+   `__..''    +------+ |   `__...'    +-----+
     +------------------------------------------+


                 Figure 9: Native ICN deployment lab setup

   The following test scenarios can be set up with VM-based deployment:

   1.  SUB: ICN simulated client (using ndnSIM), a client application on
       workstation requesting content.

   2.  EMU: test unit emulating eNodeB and UE.  This will be a test node
       allowing for UE attachment and routing the traffic subsequently
       from the Subscriber to the Publisher.

   3.  EPC: Cisco evolved Packet Core in a single instance (vPC-SI).

   4.  CDN: content delivery by a Publisher server.

   For the purpose of this testing, ICN emulating code (when available)
   can be inserted in the test code in EMU to emulate ICN-capable UE
   and/or eNodeB.  An example of the code to be used is NS3 in its LTE
   model.  Effect of such traffic on EPC and CDN can be observed and
   documented.  In a subsequent phase, EPC code supporting ICN can be
   tested when available.

   Another option is to simulate the UE/eNodeB and EPC functions using
   NS3's LTE [NS3LTE] and EPC [NS3EPC] models respectively.  LTE model
   includes the LTE Radio Protocol stack, which resides entirely within
   the UE and the eNB nodes.  This capability shall provide the
   simulation of UE and eNodeB deployment use cases.  Similarly, EPC
   model includes core network interfaces, protocols and entities, which
   resides within the SGW, PGW and MME nodes, and partially within the
   eNB nodes.

   Even with its current limitations (i.e.  IPv4 only, lack of
   integration with ndnSIM, no support for UE idle state etc.)  LTE
   simulation may be a very useful tool.  In any case, both control and
   user plane traffic should be tested independently according to the
   deployment model discussed in sections 4.4 through 4.6.



Prakash Suthar, et al. Expires September 12, 2019              [Page 28]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


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

   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




Prakash Suthar, et al. Expires September 12, 2019              [Page 29]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


   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.  In section Section 4.7, we provide details of an
   experimental setup for evaluation of ICN deployment scenarios,
   described in section 4.  One can use LTE gateway software and ICN
   simulator and deploy ICN data transport in user plane either as an
   overlay, dual stack (IP + ICN), hICN, or natively (by integrating ICN
   with CDN, eNodeB, SGW, PGW and transport network etc.).  Notice that
   for above discussed deployment scenarios, additional study is
   required for lawful interception, billing/mediation, network slicing,
   and provisioning APIs.

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

   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.  Authors welcome the
   contributions and suggestions including those related to further
   validations of the principles by implementing prototype and/or proof
   of concept in the lab and in production environment.






Prakash Suthar, et al. Expires September 12, 2019              [Page 30]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


7.  Acknowledgements

   We thank all contributors, reviewers and the chairs for the valuable
   time in providing the comments and feedback, which has helped to
   improve this draft.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [TS24.008]
              3GPP, "Mobile radio interface Layer 3 specification; Core
              network protocols; Stage 3", 3GPP TS 24.008 3.20.0,
              December 2005,
              <http://www.3gpp.org/ftp/Specs/html-info/24008.htm>.

   [TS25.323]
              3GPP, "Packet Data Convergence Protocol (PDCP)
              specification", 3GPP TS 25.323 3.10.0, September 2002,
              <http://www.3gpp.org/ftp/Specs/html-info/25323.htm>.

   [TS29.274]
              3GPP, "3GPP Evolved Packet System (EPS); Evolved General
              Packet Radio Service (GPRS) Tunnelling Protocol for
              Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0,
              June 2013,
              <http://www.3gpp.org/ftp/Specs/html-info/29274.htm>.

   [TS29.281]
              3GPP, "General Packet Radio System (GPRS) Tunnelling
              Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0,
              September 2011,
              <http://www.3gpp.org/ftp/Specs/html-info/29281.htm>.

   [TS36.323]
              3GPP, "Evolved Universal Terrestrial Radio Access
              (E-UTRA); Packet Data Convergence Protocol (PDCP)
              specification", 3GPP TS 36.323 10.2.0, January 2013,
              <http://www.3gpp.org/ftp/Specs/html-info/36323.htm>.







Prakash Suthar, et al. Expires September 12, 2019              [Page 31]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


8.2.  Informative References

   [ALM]      Auge, J., Carofiglio, G., Grassi, G., Muscariello, L.,
              Pau, G., and X. Zeng, "Anchor-Less Producer Mobility in
              ICN", Proceedings of the 2Nd ACM Conference on
              Information-Centric Networking, ACM-ICN'15, ACM DL,
              pp.189-190, September 2013,
              <https://dl.acm.org/citation.cfm?id=2812601>.

   [BROWER]   Brower, E., Jeffress, L., Pezeshki, J., Jasani, R., and E.
              Ertekin, "Integrating Header Compression with IPsec",
              MILCOM 2006 - 2006 IEEE Military Communications
              conference IEEE Xplore DL, pp.1-6, October 2006,
              <https://ieeexplore.ieee.org/document/4086687>.

   [CCN]      "Content Centric Networking", <http://www.ccnx.org>.

   [CCNxSem]  Mosko, M., Solis, I., and C. Wood, "CCNx Semantics",
              draft-irtf-icnrg-ccnxsemantics-09 (work in progress), June
              2018.

   [CCNxTLV]  Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV
              Format", draft-irtf-icnrg-ccnxmessages-08 (work in
              progress), July 2018.

   [CHENG]    Liang, C., Yu, R., and X. Zhang, "Information-centric
              network function virtualization over 5g mobile wireless
              networks", IEEE Network Journal vol. 29, number 3, pp.
              68-74, June 2015,
              <https://ieeexplore.ieee.org/document/7113228>.

   [EPCCUPS]  Schmitt, P., Landais, B., and F. Yong Yang, "Control and
              User Plane Separation of EPC nodes (CUPS)", 3GPP The
              Mobile Broadband Standard, July 2017,
              <http://www.3gpp.org/news-events/3gpp-news/1882-cups>.

   [GALIS]    Galis, A., Makhijani, K., Yu, D., and B. Liu, "Autonomic
              Slice Networking", draft-galis-anima-autonomic-slice-
              networking-05 (work in progress), September 2018.

   [GRAYSON]  Grayson, M., Shatzkamer, M., and S. Wainner, "Cisco Press
              book "IP Design for Mobile Networks"", Cisco
              Press Networking Technology series, June 2009,
              <http://www.ciscopress.com/store/
              ip-design-for-mobile-networks-9781587058264>.

   [H2020]    H2020, "The POINT Project", <https://www.point-h2020.eu/>.




Prakash Suthar, et al. Expires September 12, 2019              [Page 32]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


   [HICN]     Muscariello, L., Carofiglio, G., Auge, J., and M.
              Papalini, "Hybrid Information-Centric Networking", draft-
              muscariello-intarea-hicn-01 (work in progress), December
              2018.

   [ICN5G]    Ravindran, R., suthar, P., Trossen, D., and G. White,
              "Enabling ICN in 3GPP's 5G NextGen Core Architecture",
              draft-ravi-icnrg-5gc-icn-02 (work in progress), July 2018.

   [ICNLOWPAN]
              Gundogan, C., Schmidt, T., Waehlisch, M., Scherb, C.,
              Marxer, C., and C. Tschudin, "ICN Adaptation to LowPAN
              Networks (ICN LoWPAN)", draft-irtf-icnrg-icnlowpan-02
              (work in progress), March 2019.

   [ICNQoS]   Al-Naday, M., Bontozoglou, A., Vassilakis, G., and M.
              Reed, "Quality of Service in an Information-Centric
              Network", 2014 IEEE Global Communications Conference IEEE
              Xplore DL, pp. 1861-1866, December 2014,
              <https://ieeexplore.ieee.org/document/7037079>.

   [IPoICN]   Trossen, D., Read, M., Riihijarvi, J., Georgiades, M.,
              Fotiou, N., and G. Xylomenos, "IP over ICN - The better
              IP?", 2015 European Conference on Networks and
              Communications (EuCNC) IEEE Xplore DL, pp. 413-417, June
              2015, <https://ieeexplore.ieee.org/document/7194109>.

   [MBHICN]   Carofiglio, G., Gallo, M., Muscariello, L., and D. Perino,
              "Scalable mobile backhauling via information-centric
              networking", The 21st IEEE International Workshop on Local
              and Metropolitan Area Networks, Beijing, pp. 1-6, April
              2015, <https://ieeexplore.ieee.org/document/7114719>.

   [MECSPEC]  "Mobile Edge Computing (MEC); Framework and Reference
              Architecture", ETSI European Telecommunication Standards
              Institute (ETSI) MEC specification, March 2016,
              <https://www.etsi.org/deliver/etsi_gs/
              MEC/001_099/003/01.01.01_60/gs_MEC003v010101p.pdf>.

   [MPVCICN]  Jangam, A., Ravindran, R., Chakraborti, A., Wan, X., and
              G. Wang, "Realtime multi-party video conferencing service
              over information centric network", IEEE International
              Conference on Multimedia and Expo Workshops (ICMEW) Turin,
              Italy, pp. 1-6, June 2015,
              <https://ieeexplore.ieee.org/document/7169810>.






Prakash Suthar, et al. Expires September 12, 2019              [Page 33]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


   [NDNRTC]   Gusev, P., Wang, Z., Burke, J., Zhang, L., Yoneda, T.,
              Ohnishi, R., and E. Muramoto, "Real-time Streaming Data
              Delivery over Named Data Networking,", IEICE Transactions
              on Communications vol. E99.B, pp. 974-991, May 2016,
              <https://doi.org/10.1587/transcom.2015AMI0002>.

   [NGMN]     Robson, J., "Data Offloading Techniques in Cellular
              Networks: A Survey", Next Generation Mobile Networks, LTE-
              Advanced Transport Provisioning, V0.0.14, October 2015,
              <https://www.ngmn.org/fileadmin/user_upload/150929_NGMN_P-
              SmallCells_Backhaul_for_LTE-Advanced_and_Small_Cells.pdf>.

   [NS3EPC]   Baldo, N., "The ns-3 EPC module",  NS3 EPC Model,
              <https://www.nsnam.org/docs/models/html/
              lte-design.html#epc-model>.

   [NS3LTE]   Baldo, N., "The ns-3 LTE module",  NS3 LTE Model,
              <https://www.nsnam.org/docs/models/html/
              lte-design.html#lte-model>.

   [OFFLOAD]  Rebecchi, F., Dias de Amorim, M., Conan, V., Passarella,
              A., Bruno, R., and M. Conti, "Data Offloading Techniques
              in Cellular Networks: A Survey", IEEE Communications
              Surveys and Tutorials, IEEE Xplore DL, vol:17, issue:2,
              pp.580-603, November 2014,
              <https://ieeexplore.ieee.org/document/6953022>.

   [OLTEANU]  Olteanu, A. and P. Xiao, "Fragmentation and AES Encryption
              Overhead in Very High-speed Wireless LANs", Proceedings of
              the 2009 IEEE International Conference on Communications
              ICC'09, ACM DL, pp.575-579, June 2009,
              <http://dl.acm.org/citation.cfm?id=1817271.1817379>.

   [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration
              Guidelines for DiffServ Service Classes", RFC 4594,
              DOI 10.17487/RFC4594, August 2006,
              <https://www.rfc-editor.org/info/rfc4594>.

   [RFC6459]  Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen,
              T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
              Partnership Project (3GPP) Evolved Packet System (EPS)",
              RFC 6459, DOI 10.17487/RFC6459, January 2012,
              <https://www.rfc-editor.org/info/rfc6459>.








Prakash Suthar, et al. Expires September 12, 2019              [Page 34]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


   [RFC7476]  Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G.,
              Tyson, G., Davies, E., Molinaro, A., and S. Eum,
              "Information-Centric Networking: Baseline Scenarios",
              RFC 7476, DOI 10.17487/RFC7476, March 2015,
              <https://www.rfc-editor.org/info/rfc7476>.

   [RFC7927]  Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
              Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
              "Information-Centric Networking (ICN) Research
              Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
              <https://www.rfc-editor.org/info/rfc7927>.

   [SDN5G]    Page, J. and J. Dricot, "Software-defined networking for
              low-latency 5G core network", 2016 International
              Conference on Military Communications and Information
              Systems (ICMCIS) IEEE Xplore DL, pp. 1-7, May 2016,
              <https://ieeexplore.ieee.org/document/7496561>.

   [TLVCOMP]  Mosko, M., "Header Compression for TLV-based Packets",
              ICNRG Buenos Aires IETF 95, April 2016,
              <https://datatracker.ietf.org/meeting/interim-2016-icnrg-
              02/materials/slides-interim-2016-icnrg-2-7>.

   [TS23.203]
              3GPP, "Policy and charging control architecture", 3GPP
              TS 23.203 10.9.0, September 2013,
              <http://www.3gpp.org/ftp/Specs/html-info/23203.htm>.

   [TS23.401]
              3GPP, "General Packet Radio Service (GPRS) enhancements
              for Evolved Universal Terrestrial Radio Access Network
              (E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013,
              <http://www.3gpp.org/ftp/Specs/html-info/23401.htm>.

   [TS23.501]
              3GPP, "System Architecture for the 5G System", 3GPP
              TS 23.501 15.2.0, June 2018,
              <http://www.3gpp.org/ftp/Specs/html-info/23501.htm>.

   [TS23.714]
              3GPP, "Technical Specification Group Services and System
              Aspects: Study on control and user plane separation of EPC
              nodes", 3GPP TS 23.714 0.2.2, June 2016,
              <http://www.3gpp.org/ftp/Specs/html-info/23714.htm>.







Prakash Suthar, et al. Expires September 12, 2019              [Page 35]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


   [TS29.060]
              3GPP, "General Packet Radio Service (GPRS); GPRS
              Tunnelling Protocol (GTP) across the Gn and Gp interface",
              3GPP TS 29.060 3.19.0, March 2004,
              <http://www.3gpp.org/ftp/Specs/html-info/29060.htm>.

   [TS33.310]
              3GPP, "Network Domain Security (NDS); Authentication
              Framework (AF)", 3GPP TS 33.310 10.7.0, December 2012,
              <http://www.3gpp.org/ftp/Specs/html-info/33310.htm>.

   [TS33.320]
              3GPP, "Security of Home Node B (HNB) / Home evolved Node B
              (HeNB)", 3GPP TS 33.320 10.5.0, June 2012,
              <http://www.3gpp.org/ftp/Specs/html-info/33320.htm>.

Authors' Addresses

   Prakash Suthar
   Cisco Systems Inc.
   Rosemont, Illinois
   USA

   Email: psuthar@cisco.com


   Milan Stolic
   Cisco Systems Inc.
   Rosemont, Illinois
   USA

   Email: mistolic@cisco.com


   Anil Jangam (editor)
   Cisco Systems Inc.
   San Jose, California
   USA

   Email: anjangam@cisco.com


   Dirk Trossen
   InterDigital Inc.
   London
   United Kingdom

   Email: Dirk.Trossen@InterDigital.com



Prakash Suthar, et al. Expires September 12, 2019              [Page 36]


Internet-Draft       draft-irtf-icnrg-icn-lte-4g-03           March 2019


   Ravishankar Ravindran
   Huawei Technologies
   Santa Clara, California
   USA

   Email: ravi.ravindran@huawei.com













































Prakash Suthar, et al. Expires September 12, 2019              [Page 37]