3.1. Network Overview

4G mobile networks are designed to use IP transport for communication among different elements such as the eNodeB, MME, SGW, PGW, HSS, Policy and Charging Rule Function (PCRF), etc. [GRAYSON]. For backward compatibility with 3G, it has support for legacy circuit switch features such as voice and SMS through transitional CS fallback and flexible IP Multimedia Subsystems (IMS) deployment. For each mobile device attached to the radio (eNodeB), there is a separate overlay tunnel (GTP) between the eNodeB and Mobile Gateways (i.e., SGW/PGW).¶

When any mobile terminal is powered up, it attaches to a mobile network based on its configuration and subscription. After a successful attachment procedure, the mobile terminal registers with the mobile core network using IPv4 and/or IPv6 addresses based on request and capabilities offered by Mobile Gateways.¶

The GTP tunnel is used to carry user traffic between gateways and mobile terminals, therefore using the unicast delivery for any data transfer. It is also important to understand the overhead of GTP and IPsec protocols. All mobile backhaul traffic is encapsulated using a 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 on the IPsec tunneling model (tunnel or transport) as well as the encryption and authentication header algorithm used. If we consider an Advanced Encryption Standard (AES) encryption as an example, the overhead can be significant [OLTEANU], particularly for smaller payloads.¶

                                       +-------+  Diameter  +-------+
                                       |  HSS  |------------|  SPR  |
                                       +-------+            +-------+
                                           |                    |
        +------+   +------+      S4        |                +-------+
        |  3G  |---| SGSN |----------------|------+  +------| PCRF  |
     ^  |NodeB |   |      |---------+  +---+      |  |      +-------+
+-+  |  +------+   +------+   S3    |  |  S6a     |  |Gxc       |
| |  |                          +-------+         |  |          |Gx
+-+  |       +------------------|  MME  |------+  |  |          |
MT   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 |       +-----+
                             +---------+   +---------+
                                  |             |
                                 +-+           +-+
                                 | |           | |
                                 +-+           +-+
                                 MT            MT

If we consider the combined impact of GTP, IPsec, and unicast traffic, the data delivery is not efficient because of overhead. The IETF has developed various header compression algorithms to reduce the overhead associated with IP packets. Some techniques are RObust Header Compression (ROHC) and Enhanced Compression RTP (ECRTP) so that the 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]; those solutions can be adapted to other data protocols too such as ICN [RFC9139] [TLVCOMP].¶

3.2. Mobile Network Quality of Service

During the mobile terminal attachment procedure, a default bearer is created for each mobile terminal and it is assigned to the default Access Point Name (APN), which provides the default transport. For any QoS-aware application, one or more new dedicated bearers are established between an eNodeB and a Mobile Gateway. A dedicated bearer can be requested by either a mobile terminal or a Mobile Gateway based on the direction of the first data flow. There are many bearers (logical paths) established between an eNodeB and a Mobile Gateway for each mobile terminal catering to a different data flow simultaneously.¶

While all traffic within a certain bearer receives 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 can be very different depending on 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, and so on).¶

Implementation of QoS for mobile networks is done at two stages: 1) content prioritization/marking and transport marking and 2) congestion management. From the transport perspective, QoS is defined at Layer 2 as Class of Service (CoS) and at Layer 3 as Differentiated Services (DS). The mapping of the Differentiated Services Code Point (DSCP) to CoS takes place at Layer 2/3 switching and routing elements. 3GPP has a specified QoS Class Identifier (QCI), which represents different types of content and equivalent mappings to the DSCP at the transport layer [TS23.401]. However, this requires manual configuration at different elements and is therefore prone to possible misconfigurations.¶

In summary, QoS configuration in mobile networks for user-plane traffic 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 a poor subscriber experience (e.g., a packet classified as high priority can go to a 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 the ICN forwarder. Further investigation is underway to understand how QoS in ICN [QoS-ICN] can be implemented with reference to the ICN QoS guidelines [RFC9064] to meet the QoS requirements [RFC4594].¶

3.3. Data Transport Using IP

The data delivered to mobile devices is sent in unicast semantic inside the 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 implementations on the RAN side of the network. By using eMBMS [EMBMS], multicast routing can be enabled in mobile backhaul between an eNodeB and Mobile Gateways (SGW/PGW); however, for radio interface it requires broadcast, which implies that we need a dedicated radio channel. Implementation of eMBMS in RAN is still lagging behind due to complexities related to client mobility, handovers, and the fact that the potential gain to Service Providers may not justify the investment, which explains the prevalence of unicast delivery in mobile networks. 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 a content (or video) on-demand model.¶

To ease the burden on the bandwidth of the Service Gateway interface (SGi), caching is introduced in a similar manner as with many enterprises. In mobile networks, whenever possible, 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 packet core locations with the PGW nodes close to the Internet and IP services access (SGi). This is a very inefficient concept because traffic must 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.¶

3.4. Virtualized Mobile Networks

The Mobile Gateways deployed in a major Service Provider network are based on either dedicated hardware or commercial off-the-shelf (COTS) x86 technology. With the adoption of Mobile Virtual Network Operators (MVNOs), public safety networks, and enterprise mobility networks, elastic mobile core architecture is needed. By deploying the mobile packet core on a COTS platform, using a Network Function Virtualization Infrastructure (NFVI) framework and end-to-end orchestration, new deployments can be simplified to provide optimized total cost of ownership (TCO).¶

While virtualization is growing, and many mobile providers use a hybrid architecture that consists of dedicated and virtualized infrastructures, the control and data planes are still the same. There is also work underway to separate the control and user plane for the network to scale better. Virtualized mobile networks and network slicing with control and user-plane separation provide a mechanism to evolve the GTP-based architecture towards an OpenFlow with signaling based on Software-Defined Networking (SDN) for 4G and proposed 5G core. Some early architecture work for 5G mobile technologies provides a mechanism for control and user-plane separation and simplifies the mobility call flow by introducing OpenFlow-based signaling [ICN5G]. This has been considered by 3GPP [EPCCUPS] and is also described in [SDN5G].¶

5.1. General Considerations

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, a 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, the UPF can be collocated with the eNodeB, which is also a business decision based on 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 latency-sensitive applications. This capability allows for the introduction of ICN and amplifies its advantages.¶

5.2. Scenarios of ICN Integration

The integration of ICN provides an opportunity to further optimize the existing data transport in 4G mobile networks. The various opportunities from the coexistence of ICN and IP transport in the mobile network are somewhat analogous to the deployment scenarios when IPv6 was introduced to interoperate with IPv4 except, with ICN, the whole IP stack can be 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 used natively by replacing IP transport (IPv4 and IPv6) or as an overlay protocol. Figure 4 describes a proposal to modify the existing transport protocol stack to support ICN in a 4G mobile network.¶

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

As shown in Figure 4, for applications (running either in the mobile terminal or in the content provider system) to use the ICN transport option, we propose a new transport convergence layer (TCL). The TCL helps determine the type of transport (such as ICN or IP) as well as the type of radio interface (LTE, Wi-Fi, or both) used to send and receive traffic based on preference (e.g., content location, content type, content publisher, congestion, cost, or QoS). It helps configure and determine the type of connection (native IP or ICN) or the overlay mode (ICNoIP or IPoICN) between application and the protocol stack (IP or ICN).¶

Combined with the existing IP function, the ICN function provides support for native ICN and/or the dual transport (ICN/IP) functionality. See Section 5.4.1 for elaborate descriptions of these functional layers.¶

The TCL can use several mechanisms for transport selection. It can use a per-application configuration through a management interface, possibly a user-facing setting realized through a user interface, like those used to select cellular over Wi-Fi. In another option, it might use a software API, which an adapted IP application could use to specify the type of transport option (such as ICN) to take advantage of its benefits.¶

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

From the perspective of applications either on the mobile terminal or at a content provider, the following options are possible for potential use of ICN natively and/or with IP.¶

IP over IP (IPoIP):

In this scenario, the mobile terminal applications are tightly integrated with the existing IP transport infrastructure. The TCL has no additional function because packets are forwarded directly using an IP protocol stack, which sends packets over the IP transport.¶

ICN over ICN (ICNoICN):

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

ICN over IP (ICNoIP):

In this scenario, the underlying IP transport infrastructure is not impacted (that is, ICN is implemented as an IP overlay between mobile terminal and content provider). IP routing is used from the Radio Access Network (eNodeB) to the mobile backhaul, the IP core, and the Mobile Gateway (SGW/PGW). The mobile terminal attaches to the Mobile Gateway (SGW/PGW) using an IP address. Also, the data transport between Mobile Gateway (SGW/PGW) and content publisher uses IP. The content provider can serve content using either IP or ICN, based on the mobile terminal request.¶

One of the approaches to implement ICN in mobile backhaul networks is described in [MBICN]. It implements a General Tunneling Protocol - User Plane (GTP-U) extension header option to encapsulate ICN payload in a GTP tunnel. However, as this design runs ICN as an IP overlay, the mobile backhaul can be deployed using native IP. The proposal describes a mechanism where the GTP-U tunnel can be terminated by hairpinning the packet before it reaches the SGW if an ICN-enabled node is deployed in the mobile backhaul (that is, between eNodeB and SGW). This could be useful when an ICN data packet is stored in the ICN node (such as repositories and caches) in the tunnel path so that the ICN node can reply without going all the way through the mobile core. While a GTP-U extension header is used to carry mobile-terminal-specific ICN payload, they are not visible to the transport, including the SGW. On the other hand, the PGW can use the mobile terminal-specific ICN header extension and ICN payload to set up an uplink transport towards a content provider in the Internet. In addition, the design assumes a proxy function at the edge to perform ICN data retrieval on behalf of a non-ICN end device.¶

IP over ICN (IPoICN):

[IPoICN] provides an architectural framework for running IP as an overlay over the ICN protocol. Implementing IP services over ICN provides an opportunity to leverage the benefits of ICN in the transport infrastructure while there is no impact on end devices (MT and access network) as they continue to use IP. IPoICN, however, will require an interworking function (IWF) (and Border Gateway) to translate various transport primitives. The IWF function will provide a mechanism for protocol translation between IPoICN and the native IP. After reviewing [IPoICN], we understand and interpret that ICN is implemented in the transport natively; however, IP is implemented in MT, the eNodeB, and the Mobile Gateway (SGW/PGW), which is also called a 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.¶

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 addresses the content by encoding a location-independent name in an IPv6 address. It uses two name components, name prefix and name suffix, that identify the source of data and the data segment within the scope of the name prefix, respectively.¶

At the application layer, hICN maps the name into an IPv6 prefix and, thus, uses IP as transport. As long as the name prefixes, which are routable IP prefixes, point towards a mobile GW (PGW or local breakout, such as CUPS), there are potentially no updates required to any of the mobile core gateways (for example, SGW/PGW). The IPv6 backhaul routes the packets within the mobile core. hICN can run in the mobile terminal, the eNodeB, the mobile backhaul, or the mobile core. Finally, as hICN itself uses IPv6, it cannot be considered as an alternative transport layer.¶

5.3. Integration of ICN in 4G Control Plane

In this section, we analyze signaling messages that are required for different procedures, such as attach, handover, tracking area update, and so on. The goal of this analysis is to see if there are any benefits to replacing IP-based protocols with ICN for 4G signaling in the current architecture. It is important to understand the concept of point of attachment (POA). When a mobile terminal connects to a network, it has the 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 the current architecture, IP transport is used for all messages associated with the control plane for mobility and session management. IP is embedded very deeply into these messages utilizing TLV syntax for carrying additional attributes such as a Layer 3 transport. The physical POA in the eNodeB handles both mobility and session management for any mobile terminal attached to a 4G network. The number of mobility management messages between different nodes in a 4G network per the signaling procedure is shown in Table 1.¶

Normally, two types of mobile terminals attach to the 4G network: SIM based (which needs a 3GPP mobility protocol for authentication) or non-SIM based (which connects to Wi-Fi networks). Both device types require authentication. For non-SIM based devices, Authentication, Authorization, and Accounting (AAA) is used for authentication. We do not propose to change mobile terminal authentication or mobility management messaging for user data transport using ICN. A separate study would be required to analyze the 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 if MME and HSS do not support ICN transport, they still need to support a mobile terminal capable of dual transport or native ICN. When a mobile terminal initiates an attach request using the identity as ICN, MME must be able to parse that message and create a session. MME forwards mobile terminal authentication to HSS, so HSS must be able to authenticate an ICN-capable mobile terminal and authorize Create Session [TS23.401].¶

Anchorless mobility [ALM] provides a fully decentralized solution that is control plane agnostic to handle producer mobility in ICN. Mobility management at the Layer 3 makes its access agnostic and transparent to the end device or the application. The solution discusses handling mobility without having to depend on core network functions (e.g., MME); however, a 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.¶

One of the advantages of ICN is in the caching and reusing of the content, which does not apply to the transactional signaling exchange. After analyzing 4G signaling call flows [TS23.401] and message interdependencies (see Table 1), our recommendation is that it is not beneficial to use ICN for control plane and mobility management functions. Among the features of ICN design, Interest aggregation and content caching are not applicable to control plane signaling messages. Control plane messages are originated and consumed by the applications, and they cannot be shared.¶

5.4. Integration of ICN in 4G User Plane

We will consider Figure 1 when discussing different mechanisms to integrate ICN in mobile networks. In Section 5.2, we discussed generic experimental setups of ICN integration. In this section, we discuss the specific options of possible use of native ICN in the 4G user plane. The following options are considered:¶

1. Using Dual transport (IP/ICN) mode in mobile terminal¶
2. Using ICN in mobile terminal¶
3. Using ICN in eNodeB¶
4. Using ICN in Mobile Gateways (SGW/PGW)¶

+--------+                                               +--------+
|   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   |
+--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+
    MT     |  BS (eNodeB) |      SGW      |     PGW    |
          Uu             S1U            S5/S8         SGi

+--------+                                                +--------+
|  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  |
+--------+ | +----+-----+ | +----------+ | +----------+ | +--------+
    MT     |  BS(eNodeB)  |      SGW     |      PGW     |
           Uu            S1u           S5/S8           SGi

5.5. An Experimental Test Setup

This section proposes an experimental lab setup and discusses the open issues and questions that use of the ICN protocol is intended to address. To further test the modifications proposed in different scenarios, a simple lab can be set up, as shown in Figure 9.¶

 +------------------------------------------+
 | +-----+   +------+   (```).     +------+ |   (````).    +-----+
 | | SUB |-->| EMU  |--(x-haul'.-->| EPC  |--->(  PDN ).-->| CDN |
 | +-----+   +------+   `__..''    +------+ |   `__...'    +-----+
 +------------------------------------------+
               4G Mobile Network Functions

The following test scenarios can be set up with deployment based on Virtual Machine (VM):¶

1. SUB: An ICN-simulated client (using ndnSIM) - a client application on a workstation requesting content.¶
2. EMU: Test unit emulating an eNodeB. This is a test node allowing for UE attachment and routing traffic subsequently from the Subscriber to the Publisher.¶
3. EPC: Evolved Packet Core in a single instance (such as Open5GCore [Open5GCore]).¶
4. CDN: Content delivery by a Publisher server.¶

For the purpose of this testing, ICN-emulating code can be inserted in the test code in EMU to emulate an ICN-capable eNodeB. An example of the code to be used is NS3 in its LTE model. The 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. The LTE model includes the LTE Radio Protocol stack, which resides entirely within the UE and the eNodeB nodes. This capability provides the simulation of UE and eNodeB deployment use cases. Similarly, the EPC model includes core network interfaces, protocols, and entities, which reside within the Mobile Gateways (SGW/PGW), and MME nodes and partially within the eNodeB nodes.¶

Even with its current limitations (such as IPv4 only, lack of integration with ndnSIM, and no support for UE idle state), 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 Section 5.4.¶

6.1. Feeding into ICN Research

Specifically, we have identified the following open questions, from the architectural and performance perspective, that the proposed experiments with ICN implementation scenarios in 4G mobile networks could address in further research:¶

1. Efficiency gains in terms of the amount of traffic in multicast scenarios (i.e., quantify the possible gains along different use cases) and latency for cached content, mainly in the CDN use case.¶
2. How the new transport would coexist or replace the legacy transport protocols (e.g., IPv4, IPv6, MPLS, RSVP, etc.) and related services (e.g., bandwidth management, QoS handling, etc.).¶
3. To what extent the simplification in the IP-based transport protocols will be achieved. The multiple overlays (e.g., the MPLS, VPN, Virtual Private LAN Service (VPLS), Ethernet VPN, etc.) of services in the current IP-based transport adds to the complexity on top of basic IP transport. This makes the troubleshooting extremely challenging.¶
4. How the new transport can become service aware such that it brings in more simplicity in the system.¶
5. Confirm how (in)adequate ICN implementation would be in the control plane (which this document discourages). Given that the 5G system, as specified in [TS23.501] (Appendix G.4), encourages the use of name-based routing in the (5G) control plane for realizing the 5G-specific service-based architecture for control plane services (so-called network function service), it would be worthwhile to investigate whether the 4G control plane would benefit similarly from such use or whether specific 4G architectural constraints would prevent ICN from providing any notable benefit.¶

6.2. Use of Results Beyond Research

With the experiments and their outcomes outlined in this document, we believe that this technology is ready for a wider use and adoption, providing additional insights. Specifically, we expect to study the following:¶

1. Viability of ICN inclusion in the 3GPP protocol stack, i.e., investigating how realistic it would be to modify the stack, considering the scenarios explained in Section 5.4, and completing the user session without feature degradation.¶
2. Viability of utilizing solutions in greenfield deployments, i.e., deploying the ICN-based extensions and solutions proposed in this document in greenfield 4G deployments in order to assess real-world benefits when doing so.¶

8.1. Security Considerations

To ensure only authenticated mobile terminals are connected to the network, 4G mobile networks implement various security mechanisms. From the perspective of using ICN in the user plane, the following security aspects need to be taken care of:¶

1. MT authentication and authorization¶
2. Radio or air interface security¶
3. Denial-of-service attacks on the Mobile Gateway; services are either by the MT or by external entities in the Internet¶
4. Content poisoning in either 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 techniques. When MT is powered up, it performs a key exchange between the MT's Universal Mobile Telecommunications System Subscriber Identity Module (USIM) and HSS/Authentication Center using NAS messages, including ciphering and integrity protections between MT and MME. Details for secure MT authentication, key exchange, ciphering, and integrity protection messages are given in the 3GPP call flow [TS23.401]. With ICN, we are modifying the protocol stack for the user plane and not the control plane. The NAS signaling is exchanged between MT and Mobile Gateways, e.g., MME, using the control plane; therefore, there is no adverse impact of ICN on MT.¶

4G uses IP transport in its mobile backhaul (between an eNodeB and the core network). In case of provider-owned backhaul, the Service Provider may require implementing a security mechanism in the backhaul network. The native IP transport continues to leverage security mechanisms such as Internet Key Exchange (IKE) and the IP Security (IPsec) protocol. More details of mobile backhaul security are provided in 3GPP network security specifications [TS33.310] and [TS33.320]. When a mobile backhaul is upgraded to support dual transport (IP+ICN) or native ICN, it is required to implement security techniques that are deployed in the mobile backhaul. When ICN forwarding is enabled on mobile transport routers, we need to deploy security practices based on [RFC7476] and [RFC7927].¶

4G Mobile Gateways (SGW/PGW) perform some key functions such as content-based online/offline billing and accounting, deep packet inspection (DPI), and lawful interception (LI). When ICN is deployed in the user plane, we need to integrate ICN security for sessions between MT and the gateway. If we encrypt user-plane payload metadata, then it might be difficult to perform routing based on contents and it may not work because we need decryption keys at every forwarder to route the content. The content itself can be encrypted between publisher and consumer to ensure privacy. Only the user with the right decryption key shall be able to access the content. We need further research for ICN impact on LI, online/offline charging, and accounting.¶

8.2. Privacy Considerations

In 4G networks, there are two main privacy issues [MUTHANA]:¶

1. User Identity Privacy Issues. The main privacy issue within 4G is the exposure of the International Mobile Subscriber Identity (IMSI). The IMSI can be intercepted by adversaries. Such attacks are commonly referred to as "IMSI catching".¶
2. Location Privacy Issues. IMSI catching is closely related to the issue of location privacy. Knowing the IMSI of a user allows the attacker to track the user's movements and create a profile about the user and thus breach the user's location privacy.¶

In any network, caching implies a trade-off between network efficiency and privacy. The activity of users is exposed to the scrutiny of cache owners with whom they may not have any relationship. By monitoring the cache transactions, an attacker could obtain significant information related to the objects accessed, topology, and timing of the requests [RFC7945]. Privacy concerns are amplified by the introduction of new network functions such as information lookup and network storage, and different forms of communication [FOTIOU]. Privacy risks in ICN can be broadly divided in the following categories [TOURANI]:¶

1. Timing attack¶
2. Communication monitoring attack¶
3. Censorship and anonymity attack¶
4. Protocol attack¶
5. Naming-signature privacy¶

The introduction of TCL effectively enables ICN at the application and/or transport layer depending on the scenario described in Section 5. Enabling ICN in 4G networks is expected to increase efficiency by taking advantage of ICN's inherent characteristics. This approach would potentially leave some of the above-mentioned privacy concerns open as a consequence of using ICN transport and ICN inherent privacy vulnerabilities.¶

1. IPoIP (Section 5.2) would not be affected as TCL has no role in it, and ICN does not apply.¶
2. The ICNoICN scenario (Section 5.2) has increased risk of a privacy attack, and that risk is applicable to the ICN protocol in general rather than specifically to the 4G implementation. Since this scenario describes communication over ICN transport, every forwarder in the path could be a potential risk for a privacy attack.¶
3. The ICNoIP scenario (Section 5.2) uses IP for transport, so the only additional ICN-related potential privacy risk areas are the endpoints (consumer and publisher) where, at the application layer, content is being served.¶
4. The IPoICN scenario (Section 5.2) could have potentially increased risk due to possible vulnerability of the forwarders in the path of ICN transport.¶

Privacy issues already identified in 4G remain a concern if ICN is introduced in any of the scenarios described earlier and compounds to the new ICN-related privacy issues. Many research papers have been published that propose solutions to the privacy issues listed above. For LTE-specific privacy issues, some of the proposed solutions [MUTHANA] are IMSI encryption by an MT; mutual authentication; concealing the real IMSI within a random bit stream of certain size where only the subscriber and HSS could extract the respective IMSI; IMSI replacement with a changing pseudonym that only the HSS server can map to the UE's IMSI; and others. Similarly, some of the proposed ICN-specific privacy concerns mitigation methods, applicable where ICN transport is introduced as specified earlier in this section, include the following [FOTIOU]:¶

• Delay for the first, or first k, interests on edge routers (timing attack)¶
• Creating a secure tunnel or clients flagging the requests as non-cacheable for privacy (communication monitoring attack)¶
• Encoding interest by mixing the content and cover file or using a hierarchical DNS-based brokering model (censorship and anonymity attack)¶
• Use of rate-limiting requests for a specific namespace (protocol attack)¶
• Cryptographic content hash-based naming or digital identity in an overlay network (naming-signature privacy)¶

Further research in this area is needed. Detailed discussion of privacy is beyond the scope of this document.¶