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. An APN identifies the packet data network (PDN) with which a mobile data user wants to communicate. In addition to identifying a PDN, an APN may also be used to define the type of service, QoS, and other logical entities inside a Gateway General Packet Radio Service Support Node (GGSN) or a Packet Data Network Gateway (PGW).

Control Plane:

The control plane carries signaling traffic and is responsible for routing between the eNodeB and the Mobile Management Entity (MME), the MME and the Home Subscriber Server (HSS), the MME and the Mobile Gateways (SGW/PGW), etc. Control plane signaling is required to authenticate and authorize the mobile terminal and establish a mobility session with Mobile Gateways (SGW/PGW). Control plane functions also include system configuration and management.

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 IPv4 and IPv6 simultaneously.

eNodeB:

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

Evolved Packet Core:

The Evolved Packet Core (EPC) is an evolution of the 3GPP GPRS system characterized by a higher-data-rate, lower-latency, packet-optimized system. The EPC comprises some subcomponents of the EPS core such as MME, Mobile Gateways (SGW/PGW), and HSS.

Evolved Packet System:

The Evolved Packet System (EPS) is an evolution of the 3GPP GPRS system 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 Evolved Universal Terrestrial Radio Access (E-UTRA) and the Evolved Universal Terrestrial Radio Access Network (E-UTRAN).

Evolved UTRAN:

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

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 that is assigned to it by an operator. The GGSN also serves as the topological anchor for addresses/prefixes assigned to the User Equipment.

General Packet Radio Service:

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

GPRS Tunneling Protocol:

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

Home Subscriber Server:

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

Mobile Terminal/User Equipment:

The terms User Equipment (UE), Mobile Station (MS), Mobile Node (MN), andmobile refer to the devices that are hosts with the ability to obtain Internetconnectivity via a 3GPP network. An MS comprises the Terminal Equipment (TE)and an MT. The terms MT, MS, MN, and mobile are usedinterchangeably within this document.

Mobility Management Entity:

The Mobility Management Entity (MME) is a network element responsible forcontrol plane functionalities, including authentication, authorization, bearermanagement, Layer 2 mobility, and so on. The MME is essentially the controlplane part of the SGSN in the GPRS. The user-plane traffic bypasses the MME.

Packet Data Network:

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

Packet Data Network Gateway:

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

Packet Data Protocol Context:

A Packet Data Protocol (PDP) context is the equivalent of a virtualconnection between the mobile terminal (MT) and a PDN using a specificgateway.

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

Policy and Charging Control:

The Policy and Charging Control (PCC) framework is used for QoS policy andcharging control. It has two main functions: flow-based charging (includingonline credit control) and policy control (for example, gating control, QoScontrol, and QoS signaling). It is optional to 3GPP EPS but needed if dynamicpolicy and charging control by means of PCC rules based on user and servicesare desired.

Public Land Mobile Network:

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

Serving Gateway:

The Serving Gateway (SGW) is a gateway function in the EPS, whichterminates the interface towards the E-UTRAN. The SGW is the Mobility Anchorpoint for Layer 2 mobility (inter-eNodeB handovers). For each mobile terminalconnected with the EPS, there is only one SGW at any given point in time. TheSGW is essentially the user-plane part of the GPRS's SGSN.

Serving GPRS Support Node:

The Serving GPRS Support Node (SGSN) is a network element located betweenthe Radio Access Network (RAN) and the gateway (GGSN). A per-MT point-to-point(P2P) tunnel between the GGSN and SGSN transports the packets between themobile terminal and the gateway.

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.

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

IP over IP (IPoIP):

In this scenario, the mobile terminal applications are tightly integratedwith the existing IP transport infrastructure. The TCL has no additionalfunction 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 ICNtransport infrastructure. The TCL has no additional responsibility becausepackets are forwarded directly using the native ICN protocol stack, whichsends 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.

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

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                
                        

1. An existing application layer can be modified to provide options for a new ICN-based application and existing IP-based applications. The mobile terminal can continue to support existing IP-based applications or can develop new applications to support native ICN, ICNoIP, or IPoICN-based transport. The application layer can be provided with an option of selecting either ICN or IP transport, as well as radio interface, to send and receive data traffic. Our proposal is to provide an Application Programming Interface (API) to the application developers so they can choose either ICN or IP transport for exchanging the traffic with the network. As mentioned in Section 5.2, the TCL function handles the interaction of applications with multiple transport options.
2. The transport convergence layer helps determine the type of transport (such as ICN, hICN, or IP) and type of radio interface (LTE, Wi-Fi, or both) used to send and receive traffic. The application layer can make the decision to select a specific transport based on preference such as content location, content type, content publisher, congestion, cost, QoS, and so on. There can be an API to exchange parameters required for transport selection. Southbound interactions of the TCL will be either to IP or to 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 to the ICN network under a suitable ICN name (that is, 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). In the HTTP case, the TCL can maintain a pending request mapping table to map, returning responses to the originating HTTP request. The common API will provide a "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 mobile terminal to the receiving mobile terminal or the PGW. If the HTTP protocol stack remains unchanged, therefore utilizing the TCP protocol for 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. The ICN function (forwarder) is proposed to run in parallel to the existing IP layer. The ICN forwarder forwards the ICN packets such as an Interest packet to an eNodeB or a response "data packet" from an eNodeB to the application.
4. For the dual-transport scenario, when a mobile terminal is not supporting ICN as transport, the TCL can use the IP underlay to tunnel the ICN packets. The ICN function can use the IP interface to send Interest and Data packets for fetching or sending data, respectively. This interface can use the ICN overlay over IP.
5. To support ICN at the network layer in the mobile terminal, the PDCP layer should be aware of ICN capabilities and parameters. PDCP is located in the Radio Protocol Stack in the LTE Air interface, between the IP (Network layer) and Radio Link Control Layer (RLC). PDCP performs the following functions [TS36.323]:
   1. Data transport by listening to the upper layer, formatting, and pushing down to the RLC
   2. Header compression and decompression using ROHC
   3. Security protections such as ciphering, deciphering, and integrity protection
   4. Radio layer messages associated with sequencing, packet drop detection and retransmission, and so on.
6. No changes are required for the lower layer such as RLC, Media Access Control (MAC), and Physical (L1) as they are not IP aware.

1. User-plane communication
2. Transport layer

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

1. Native IP (IPv4 or IPv6)
2. Native ICN
3. Dual transport IP (IPv4/IPv6) and ICN

1. It decides the forwarding strategy for a user data request coming from the mobile terminal. The strategy can decide based on preference indicated by the application, such as congestion, cost, QoS, and so on.
2. It uses an eNodeB to provide an open API to external management systems in order to provide eNodeB the capability to program the forwarding strategies.

                 +---------------+  |
                 | MT request    |  |    ICN          +---------+
           +---->| content using |--+--- transport -->|         |
           |     |ICN protocol   |  |                 |         |
           |     +---------------+  |                 |         |
           |                        |                 |         |
           |     +---------------+  |                 |         |
       +-+ |     | MT request    |  |    IP           |To mobile|
       | |-+---->| content using |--+--- transport -->|    GW   |
       +-+ |     | IP protocol   |  |                 |(SGW/PGW)|
       MT  |     +---------------+  |                 |         |
           |                        |                 |         |
           |     +---------------+  |                 |         |
           |     | MT request    |  |    Dual stack   |         |
           +---->| content using |--+--- IP+ICN    -->|         |
                 |IP/ICN protocol|  |    transport    +---------+
                 +---------------+  |
                     eNodeB        S1u                            
                                       

   Figure 8: Integration of Native ICN in eNodeB
3. The eNodeB can be upgraded to support three different types of transport: IP, ICN, and dual transport IP+ICN towards Mobile Gateways, as depicted in Figure 8. It is also proposed to deploy IP and/or ICN forwarding capabilities into an eNodeB for efficient transfer of data between the eNodeB and Mobile Gateways. The following are choices for forwarding a data request towards Mobile Gateways:
   1. Assuming the eNodeB is IP enabled and the MT requests an IP transfer, the eNodeB forwards data over IP.
   2. Assuming the eNodeB is ICN enabled and the MT requests an ICN transfer, the eNodeB forwards data over ICN.
   3. Assuming the eNodeB is IP enabled and the MT requests an ICN transfer, the eNodeB overlays ICN on IP and forwards user-plane traffic over IP.
   4. Assuming the eNodeB is ICN enabled and the MT requests an IP transfer, the eNodeB overlays IP on ICN and forwards user-plane traffic over ICN [IPoICN].

1. Insert ICN attributes in the session management layer for additional functionality with IP stack. The session management layer is used for performing attach procedures and assigning logical identity to users. After successful authentication by HSS, MME sends a Create Session Request (CSR) to SGW and SGW to PGW.
2. When MME sends a Create Session Request message (Step 12 in [TS23.401]) to SGW or PGW, it includes a Protocol Configuration Option (PCO) Information Element (IE) containing MT capabilities. We can use PCO IE to carry ICN-related capabilities information from MT to PGW. This information is received from MT during the initial attach request in MME. Details of available TLV, which can be used for ICN, are given in subsequent sections. MT can support native IP, ICN+IP, or native ICN. IP is referred to as both IPv4 and IPv6 protocols.
3. For ICN+IP-capable MT, PGW assigns the MT both an IP address and ICN identity. MT selects either of the identities during the initial attach procedures and registers with the network for session management. For ICN-capable MT, it will provide only ICN attachment. For native IP-capable MT, there is no change.
4. 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 CS, PIT, FIB capabilities, and so on. If MT requests ICN in PCO IE, then PGW registers MT with ICN names. For ICN forwarding, PGW caches content locally using CS functionality.
5. PCO IE as described in [TS24.008] (see Figure 10.5.136 on page 656 and Table 10.5.154 on page 659) provides details for different fields.
   1. Octet 3 (configuration protocols define PDN types), which contains details about IPv4, IPv6, both IPv4 and IPv6, 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 MT and Mobile Gateways (SGW/PGW) so they can be interpreted properly and the MT can attach successfully.
6. The ICN functionalities in SGW and PGW should be matched with MT and the 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 MT 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 the other hand, for an MT attached with an ICN identity, if PGW must 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.

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

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.

Architecture scope:

to study the aspect of use of ICN at the user plane to reduce the complexities in current transport protocols while also evaluating its use in the control plane.

Performance scope:

to evaluate the gains through multicast, caching, and other ICN features.

Deployment scope:

to check the viability of ICN inclusion in the 3GPP protocol stack and in real-world deployments.

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.

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.

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

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.

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

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.

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

[TS24.008]

3GPP, "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3", 3GPP TS 24.008 17.7.0, June 2022,
<https://www.3gpp.org/ftp/Specs/html-info/24008.htm>.

[TS25.323]

3GPP, "Packet Data Convergence Protocol (PDCP) specification", 3GPP TS 25.323 17.0.0, April 2022,
<https://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 17.6.0, June 2022,
<https://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 17.3.0, June 2022,
<https://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 17.1.0, July 2022,
<https://www.3gpp.org/ftp/Specs/html-info/36323.htm>.

[ALM]

J Augé, G Carofiglio, G Grassi, L Muscariello, G Pau, and X Zeng, "Anchor-Less Producer Mobility in ICN", DOI 10.1145/2810156.2812601, September 2015,
<https://dl.acm.org/citation.cfm?id=2812601>.

[BROWER]

E Brower, L Jeffress, J Pezeshki, R Jasani, and E Ertekin, "Integrating Header Compression with IPsec", DOI 10.1109/MILCOM.2006.302503, October 2006,
<https://ieeexplore.ieee.org/document/4086687>.

[CCN]

FD.io, , "Cicn", January 2020,
<https://wiki.fd.io/index.php?title=Cicn&oldid=10316>.

[CHENG]

C Liang, R Yu, and X Zhang, "Information-centric network function virtualization over 5g mobile wireless networks", June 2015,
<https://ieeexplore.ieee.org/document/7113228>.

[EMBMS]

K Zahoor, K Bilal, A Erbad, and A Mohamed, "Service-Less Video Multicast in 5G: Enablers and Challenges", DOI 10.1109/MNET.001.1900435, June 2020,
<https://ieeexplore.ieee.org/document/9105941>.

[EPCCUPS]

P Schmitt, B Landais, and F Yong Yang, "Control and User Plane Separation of EPC nodes (CUPS)", July 2017,
<https://www.3gpp.org/news-events/3gpp-news/1882-cups>.

[FOTIOU]

N Fotiou, and G Polyzos, "ICN privacy and name based security", DOI 10.1145/2660129.2666711, September 2014,
<https://dl.acm.org/doi/10.1145/2660129.2666711>.

[GALIS]

A Galis, K Makhijani, D Yu, and B Liu, "Autonomic Slice Networking", Internet-Draft draft-galis-anima-autonomic-slice-networking-05, September 2018,
<https://datatracker.ietf.org/doc/html/draft-galis-anima-autonomic-slice-networking-05>.

[GRAYSON]

M Grayson, M Shatzkamer, and S Wainner, "IP Design for Mobile Networks", ISBN 1-58705-826-X, June 2009,
<https://www.ciscopress.com/store/ip-design-for-mobile-networks-9781587058264>.

[HICN]

L Muscariello, G Carofiglio, J Auge, and M Papalini, "Hybrid Information-Centric Networking", Internet-Draft draft-muscariello-intarea-hicn-04, May 2020,
<https://datatracker.ietf.org/doc/html/draft-muscariello-intarea-hicn-04>.

[ICN5G]

CableLabs, R. Ravindran, P. Suthar, D. Trossen, C. Wang, and G. White, "Enabling ICN in 3GPP's 5G NextGen Core Architecture", Internet-Draft draft-irtf-icnrg-5gc-icn-04, January 2021,
<https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-5gc-icn-04>.

[ICNQoS]

M.F. Al-Naday, A Bontozoglou, G Vassilakis, and M. J. Reed, "Quality of service in an information-centric network", DOI 10.1109/GLOCOM.2014.7037079, December 2014,
<https://ieeexplore.ieee.org/document/7037079>.

[IPoICN]

D Trossen, M. J. Read, J Riihijarvi, M Georgiades, N Fotiou, and G Xylomenos, "IP over ICN - The better IP?", DOI 10.1109/EuCNC.2015.7194109, June 2015,
<https://ieeexplore.ieee.org/document/7194109>.

[MBICN]

G Carofiglio, M Gallo, L Muscariello, and D Perino, "Scalable mobile backhauling via information-centric networking", DOI 10.1109/LANMAN.2015.7114719, April 2015,
<https://ieeexplore.ieee.org/document/7114719>.

[MECSPEC]

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

[MPVCICN]

A Jangam, R Ravindran, A Chakraborti, X Wan, and G Wang, "Realtime multi-party video conferencing service over information centric network", DOI 10.1109/ICMEW.2015.7169810, June 2015,
<https://ieeexplore.ieee.org/document/7169810>.

[MUTHANA]

A Muthana, and M Saeed, "Analysis of User Identity Privacy in LTE and Proposed Solution", DOI 10.5815/ijcnis.2017.01.07, January 2017,
<https://www.mecs-press.org/ijcnis/ijcnis-v9-n1/v9n1-7.html>.

[NDNRTC]

P Gusev, Z Wang, J Burke, L Zhang, T Yoneda, R Ohnishi, and E Muramoto, "Real-Time Streaming Data Delivery over Named Data Networking", 10.5815/ijcnis.2017.01.07, May 2016,
<https://doi.org/10.1587/transcom.2015AMI0002>.

[NGMN]

J Robson, "Backhaul Provisioning for LTE-Advanced & Small Cells", October 2015,
<https://www.ngmn.org/wp-content/uploads/Publications/2015/150929_NGMN_P-SmallCells_Backhaul_for_LTE-Advanced_and_Small_Cells.pdf>.

[NS3EPC]

ns-3, "The EPC Model", July 2022,
<https://www.nsnam.org/docs/models/html/lte-design.html#epc-model>.

[NS3LTE]

ns-3, "The LTE Model", July 2022,
<https://www.nsnam.org/docs/models/html/lte-design.html#lte-model>.

[OFFLOAD]

F Rebecchi, M Dias de Amorim, V Conan, A Passarella, R Bruno, and M Conti, "Data Offloading Techniques in Cellular Networks: A Survey", DOI 10.1109/COMST.2014.2369742, November 2014,
<https://ieeexplore.ieee.org/document/6953022>.

[OLTEANU]

A Olteanu, and P Xiao, "Fragmentation and AES encryption overhead in very high-speed wireless LANs", June 2009,
<https://dl.acm.org/doi/10.5555/1817271.1817379>.

[Open5GCore]

Open5GCore, "Open5GCore - 5G Core Network for Research, Testbeds and Trials",
<https://www.open5gcore.org>.

[QoS-ICN]

A Jangam, P Suthar, and M Stolic, "QoS Treatments in ICN using Disaggregated Name Components", Internet-Draft draft-anilj-icnrg-dnc-qos-icn-02, March 2020,
<https://datatracker.ietf.org/doc/html/draft-anilj-icnrg-dnc-qos-icn-02>.

[RFC4594]

J Babiarz, K Chan, 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]

J Korhonen, J Soininen, B Patil, T Savolainen, G Bajko, 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>.

[RFC7476]

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

[RFC7927]

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

[RFC7945]

K Pentikousis, B Ohlman, E Davies, S Spirou, and G Boggia, "Information-Centric Networking: Evaluation and Security Considerations", RFC 7945, DOI 10.17487/RFC7945, September 2016,
<https://www.rfc-editor.org/info/rfc7945>.

[RFC8569]

M Mosko, I Solis, and C Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019,
<https://www.rfc-editor.org/info/rfc8569>.

[RFC8609]

M Mosko, I Solis, and C Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, July 2019,
<https://www.rfc-editor.org/info/rfc8609>.

[RFC9064]

D Oran, "Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols", RFC 9064, DOI 10.17487/RFC9064, June 2021,
<https://www.rfc-editor.org/info/rfc9064>.

[RFC9139]

C Gündoğan, T Schmidt, M Wählisch, C Scherb, C Marxer, and C Tschudin, "Information-Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs)", RFC 9139, DOI 10.17487/RFC9139, November 2021,
<https://www.rfc-editor.org/info/rfc9139>.

[SDN5G]

J Page, and J Dricot, "Software-defined networking for low-latency 5G core network", DOI 10.1109/ICMCIS.2016.7496561, May 2016,
<https://ieeexplore.ieee.org/document/7496561>.

[TLVCOMP]

M Mosko, "Header Compression for TLV-based Packets", April 2016,
<https://datatracker.ietf.org/meeting/interim-2016-icnrg-02/materials/slides-interim-2016-icnrg-2-7>.

[TOURANI]

R Tourani, S Misra, T Mick, and G Panwar, "Security, Privacy, and Access Control in Information-Centric Networking: A Survey", DOI 10.1109/COMST.2017.2749508, September 2017,
<https://ieeexplore.ieee.org/document/8027034>.

[TS23.203]

3GPP, "Policy and charging control architecture", 3GPP TS 23.203 17.2.0, December 2021,
<https://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 17.5.0, June 2022,
<https://www.3gpp.org/ftp/Specs/html-info/23401.htm>.

[TS23.501]

3GPP, "System architecture for the 5G System (5GS)", 3GPP TS 23.501 17.5.0, June 2022,
<https://www.3gpp.org/ftp/Specs/html-info/23501.htm>.

[TS23.714]

3GPP, "Study on Control Plane (CP) and User Plane (UP) separation of Evolved Packet Core (EPC) nodes", 3GPP TS 23.714 14.0.0, June 2016,
<https://www.3gpp.org/ftp/Specs/html-info/23714.htm>.

[TS29.060]

3GPP, "General Packet Radio Service (GPRS); GPRS Tunneling Protocol (GTP) across the Gn and Gp interface", 3GPP TS 29.060 17.3.0, June 2022,
<https://www.3gpp.org/ftp/Specs/html-info/29060.htm>.

[TS29.336]

3GPP, "Home Subscriber Server (HSS) diameter interfaces for interworking with packet data networks and applications", 3GPP TS 29.336 17.13.1, March 2022,
<https://www.3gpp.org/ftp/Specs/html-info/29336.htm>.

[TS33.310]

3GPP, "Network Domain Security (NDS); Authentication Framework (AF)", 3GPP TS 33.310 17.3.0, June 2022,
<https://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 17.0.0, March 2022,
<https://www.3gpp.org/ftp/Specs/html-info/33320.htm>.

Prakash Suthar

Milan Stolic

Anil Jangam

Dirk Trossen

Ravi Ravindran