ICN Research Group Prakash Suthar Internet-Draft Milan Stolic Intended status: Informational Anil Jangam Cisco Systems Expires: January 3, 2018 July 02 2017 Native Deployment of ICN in LTE, 4G Mobile Networks draft-suthar-icnrg-icn-lte-4g-02 Abstract LTE, 4G mobile networks use IP transport which is not optimized for data transport. IP unicast routing from server to clients is used for delivery of multimedia content to User Equipment (UE), where each user gets separate stream. From bandwidth and routing perspective this approach is inefficient. Multicast and broadcast technologies have emerged recently for mobile networks, but their deployments are very limited or at an experimental stage due to complex architecture and radio spectrum issues. ICN is a rapidly emerging technology with built in features for efficient multimedia 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 into 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 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 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 Prakash, et.al. Expires January 3, 2018 [Page 1] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 2017 http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. LTE, 4G Mobile Network . . . . . . . . . . . . . . . . . . . . 3 2.1 Network Overview . . . . . . . . . . . . . . . . . . . . . 3 2.2 QoS Challenges . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Data Transport Using IP . . . . . . . . . . . . . . . . . . 5 2.4 Virtualizing Mobile Networks . . . . . . . . . . . . . . . 6 4. Data Transport Using ICN . . . . . . . . . . . . . . . . . . . 7 5. ICN Deployment in 4G and LTE Networks . . . . . . . . . . . . 9 5.1 Recommendations in LTE Signaling . . . . . . . . . . . . . 9 5.2 Recommendations in the User Plane . . . . . . . . . . . . . 10 5.2.1 Dual stack ICN Deployments in UE . . . . . . . . . . . 11 5.2.2 Native ICN Deployments in UE . . . . . . . . . . . . . 14 5.2.3 ICN Deployment in eNodeB . . . . . . . . . . . . . . . 15 5.2.4 ICN Deployment in Packet Core (SGW, PGW) Gateways . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 18 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1 Normative References . . . . . . . . . . . . . . . . . . . 21 7.2 Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Prakash, et.al. Expires January 3, 2018 [Page 2] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 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, 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]. 2. LTE, 4G Mobile Network 2.1 Network Overview With the introduction of LTE, mobile networks moved to all-IP transport for all elements such as eNodeB, MME, SGW/PGW, HSS, PCRF, routing and switching etc. Although LTE network is data-centric, it has support for legacy Circuit Switch features like voice and SMS through transitional CS fallback and flexible IMS deployment [GRAYSON]. For each mobile device attached to the radio (eNodeB) there is a separate overlay tunnel (GPRS Tunneling Protocol, GTP) between eNodeB and Mobile gateways (i.e. SGW, PGW). This tunnel is used to carry user traffic between gateways and mobile devices so the 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 Prakash, et.al. Expires January 3, 2018 [Page 3] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 2017 provider is using a shared backhaul), it adds additional 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 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 Prakash, et.al. Expires January 3, 2018 [Page 4] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 2017 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 also be used in ICN as well. 2.2 QoS Challenges During the attach procedure, default bearer is created for each UE and it is assigned to the default Access Point Name (APN). The QoS parameters such as uplink/downlink bandwidth assigned during initial attach are minimal. Additional dedicated bearer(s) with enhanced QoS parameters can be established depending on the specific application requirements. While all traffic within a certain bearer gets the same treatment, QoS parameters supporting these requirements can be very granular in different bearers. These values vary for the control, management and user traffic, and depending on the application key parameters, such as latency, jitter (important for voice and other real-time applications), packet loss and queuing mechanism (strict priority, low-latency, fair etc.) can be very different. Implementation of QoS for mobile networks is done at two stages: at content prioritization/marking and transport marking, and congestion 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. 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 Prakash, et.al. Expires January 3, 2018 [Page 5] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 2017 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 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 Prakash, et.al. Expires January 3, 2018 [Page 6] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 2017 technologies provide 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]. 4. 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. MEC transforms radio into an intelligent service edge that is capable of delivering highly personalized services directly from the edge of the network, while providing the best possible performance to the client. MEC can be an ideal candidate for ICN forwarder in addition to its usual function of managing mobile termination. In addition to MEC, other transport elements, such as routers, can work as ICN forwarders. 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. +----------+ | 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 Prakash, et.al. Expires January 3, 2018 [Page 7] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 2017 Fig. 2. ICN Architecture Every node in a physical path between a client and a content provider is called ICN forwarder or router, and it has the ability to route the request intelligently and also cache the content so that it can be delivered locally for subsequent request from any other client. For mobile network, transport between a client and a content provider consists of radio network + mobile backhaul and IP core transport + Mobile Gateways + Internet + content data network (CDN). 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 looping Interest messages. Interest packet also contains optional fields such as selector and guider fields. Selectors provides a specific filtering action during matching and Prakash, et.al. Expires January 3, 2018 [Page 8] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 2017 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. 5. ICN Deployment in 4G and LTE Networks 5.1 Recommendations in LTE Signaling 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 4. Prakash, et.al. Expires January 3, 2018 [Page 9] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 2017 Normally two types of UE devices attach to LTE network: SIM based (need 3GPP mobility protocol for authentications) 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 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. 4. 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 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. 5.2 Recommendations in the User Plane Prakash, et.al. Expires January 3, 2018 [Page 10] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 2017 We will consider figure 1 to discuss different mechanisms to deploy ICN in mobile networks. We consider the following options: 1. Dual stack ICN deployment in UE 2. Native ICN Deployments in UE 3. ICN Deployment in eNodeB 4. ICN Deployment in mobile gateways (SGW/PGW) 5.2.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 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. | |Selector|.|..............|...............|.|Selector|.|.|Selector| +--------+ | | | +--------+ | +--------+ | |.|..............|...............|.| |.|.| | | ICN/IP | | | | | ICN/IP | | | ICN/IP| | | | | | | | | | | +--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+ | |.|.| | |.|.| | |.|.| | | | | | | PDCP | | |PDCP|GTP-U| | |GTP-U|GTP-U| | |GTP-U| | | | L2 | +--------+ | +----------+ | +-----------+ | +-----+ | | | | | RLC |.|.|RLC | UDP |.|.| UDP | UDP |.|.|UDP |L2|.|.| | +--------+ | +----------+ | +-----------+ | +-----+ | | | | | MAC |.|.| MAC| L2 |.|.| L2 | L2 |.|.| L2 | | | | | +--------+ | +----------+ | +-----------+ | +--------+ | +--------+ | L1 |.|.| L1 | L1 |.|.| L1 | L1 |.|.| L1 |L1|.|.| L1 | +--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+ UE | BS(enodeB) | SGW | PGW | Uu S1U S5/S8 SGi Prakash, et.al. Expires January 3, 2018 [Page 11] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 2017 Fig. 5. 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. The protocols and software stack used inside LTE capable UE support both 3G and LTE software interworking and handover. Latest 3GPP Rel.13 onward specification describe the use of IP and non-IP protocols to establish logical/session connectivity. We 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). +-----------------------------------+ | Applications (existing) | +-----------------------------------+ | +-----------------------------------+ | Transport Selector (new) | +-----------------------------------+ | | +-------------+ +-------------+ |ICN function +-------+ IP function | | (New) | | (Existing) | +-------------+ +-------------+ | (native) | (overlay) +-----------------------------------+ | PDCP (updated to support ICN) | +-----------------------------------+ | +-----------------------------------+ | RLC (Existing) | +-----------------------------------+ | +-----------------------------------+ | MAC Layer (Existing) | +-----------------------------------+ | +-----------------------------------+ | Physical L1 (Existing) | +-----------------------------------+ Fig. 6. Dual stack ICN protocol interactions 1. Application layer has the option of selecting either ICN or IP transport layer as well as the radio interface to send and receive data traffic. Our proposal is to provide a common Application Programming Interface (API) to the application Prakash, et.al. Expires January 3, 2018 [Page 12] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 2017 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. We introduce a transport selector function to handle the interaction of application with the multiple transport options. 2. The transport selector 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 Selector will be either to IP or ICN at 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 January 3, 2018 [Page 13] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 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. 5.2.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. | |Selector|.|..............|..............|..............|.|Selector| +--------+ | | | | +--------+ | |.|..............|..............|..............|.| | | ICN/IP | | | | | | | | | | | | | | | +--------+ | +----+-----+ | +----------+ | +----------+ | | ICN/IP | | |.|.| | | | | | | | | | | | | PDCP | | |PDCP| ICN |.|.| ICN |.|.| ICN |.|.| | +--------+ | +----+ | | | | | | | | | | | RLC |.|.|RLC | | | | | | | | | | | +--------+ | +----------+ | +----------+ | +----------+ | +--------+ | MAC |.|.| MAC| L2 |.|.| L2 |.|.| L2 |.|.| L2 | +--------+ | +----------+ | +----------+ | +----------+ | +--------+ | L1 |.|.| L1 | L1 |.|.| L1 |.|.| L1 |.|.| L1 | +--------+ | +----+-----+ | +----------+ | +----------+ | +--------+ UE | BS(enodeB) | SGW | PGW | Uu S1u S5/S8 SGi Fig. 7. Native ICN Deployment in UE If we implement ICN natively in UE, communication between UE and Prakash, et.al. Expires January 3, 2018 [Page 14] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 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 Selector. Also to support ICN at network layer in UE, we need to modify existing PDCP layer. PDCP layer has to be aware of ICN capabilities and parameters. Native implementation will also provide opportunities to develop new use cases leveraging ICN capabilities such as seamless mobility, UE to UE content delivery using radio network without interactions with mobile gateways, etc. 5.2.3 ICN Deployment in 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 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 as described in section 5.2.1 and send the information on air interface to eNodeB. eNodeB receives the information and using PDCP [TS 36.323], de-encapsulate air-interface messages and convert them to forward to core mobile gateways (SGW, PGW). In order to support ICN natively in eNodeB, it is proposed to provide transport selector 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 programming capability to eNodeB to program the forwarding strategies. 3. eNodeB shall be upgraded to support three different types of Prakash, et.al. Expires January 3, 2018 [Page 15] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 2017 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 can be four choices for forwarding data request towards mobile gateways: a) Assuming eNodeB is IP enabled and UE requests for IP transfer, eNodeB forwards data over IP. b) Assuming eNodeB is ICN enabled and UE request for ICN transfer, eNodeB forwards data over ICN. c) Assuming eNodeB is IP enabled and UE request ICN, eNodeB overlays ICN on IP and forwards the user plane traffic over IP. d) Assuming eNodeB is ICN enabled and UE request 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. 8. Native ICN Deployment in eNodeB 5.2.4 ICN Deployment in Packet Core (SGW, PGW) Gateways Mobile gateways a.k.a. Evolved Packet Core (EPC) include SGW, PGW, which performs 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 Prakash, et.al. Expires January 3, 2018 [Page 16] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 2017 anchoring point for UE and responsible for service creations, authorization, maintenance etc. Entire functionality is managed using IP address(es) for UE. In order to implement ICN in EPC, the following functions are needed. 1. Insert ICN function at session management layer as additional functionality with IP stack. Session management layer is used for performing attach procedures and assigning logical identity to user. After successful authentication by HSS, MME sends create session request (CSR) to SGW and SGW to PGW. 2. When MME sends Create Session Request message (step-12 in [TS23.401]) to SGW 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 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 the either of the identities during 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 Prakash, et.al. Expires January 3, 2018 [Page 17] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 2017 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. 6. 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 need to take care of 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 security UE authentication, key exchange, ciphering and integrity protections message 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 continue 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. Prakash, et.al. Expires January 3, 2018 [Page 18] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 2017 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), 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 are in possession of decryption keys can access the content, some of the services provided mobile gateway mentioned above may not work. Further research in this area is needed. 7. Summary Authors have discussed complexities of LTE network and key dependencies for deploying ICN in user plane data transport. Different deployment options described covers aspects such as inter- operability and multi-technology, which is a reality for any service provider. The ICN deployment options described in section 5, we currently evaluating 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 the actual deployment scenarios, additional research study is required to identify dependencies specific to a mobile network. As far as control plane signaling is concerned, our observation is that further research is required to understand the benefits of using ICN to complement or replace traditional control plane signaling. As a starting step towards ICN deployment, it is recommended that the focus should be on enhancement of user data plane. Mobile Edge Computing (MEC) [CHENG] provides capabilities to deploy functionalities such as content data 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 we 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 the ICN forwarding in MEC could be used in efficient delivery of unicast and multicast traffic. Prakash, et.al. Expires January 3, 2018 [Page 19] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 2017 Prakash, et.al. Expires January 3, 2018 [Page 20] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 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 . [IPSEC2] 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 January 3, 2018 [Page 21] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 2017 Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification [RFC7476] Information-Centric Networking: Baseline Scenarios [RFC7927] Information-Centric Networking (ICN) Research Challenges 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 . [CCN] Content Centric Networking . [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, . [NDNRTC] Peter Gusev,Zhehao Wang, Jeff Burke, Lixia Zhang et. All, IEICE Trans Communication, RealtimeStreaming Data Delivery over Named Data Networking, Vol E99-B, No.5 May 2016. [CHENG] Chengchao L., F. Richard Yu, Information-centric network fucntion virtualization over 5G mobile wireless networks, IEEE network (Volume:29, Issue:3), page 68-74, 01 June 2015. [NGMN] Backhaul Provisioning for LTE-Advanced & Small Cells Prakash, et.al. Expires January 3, 2018 [Page 22] Internet-Draft Deploying ICN in 4G, LTE Mobile Networks July 02 2017 [IPoICN] IP Over ICN - The Better IP? Authors' Addresses Prakash Suthar 9501 Technology Blvd. Rosemont, Illinois 50618 EMail: psuthar@cisco.com Milan Stolic 9501 Technology Blvd. Rosemont, Illinois 50618 EMail: mistolic@cisco.com Anil Jangam 3625 Cisco Way San Jose, CA 95134 USA Email: anjangam@cisco.com Prakash, et.al. Expires January 3, 2018 [Page 23]