<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<!-- control the table of contents (ToC) -->
<!-- generate a ToC -->
<?rfc toc="yes"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc tocdepth="4"?>
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc compact="yes" ?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="exp" docName="draft-irtf-icnrg-icn-lte-4g-12" number="9269" submissionType="IRTF" category="info" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.12.3 -->
  <!-- number="" obsoletes="" seriesNo="" updates="" -->
    <!-- Front section -->

<front>
    <title abbrev="draft-irtf-icnrg-icn-lte-4g-12">Experimental Scenarios abbrev="Scenarios of ICN Integration in 4G">Experimental Scenarios of Information-Centric Networking (ICN) Integration in 4G Mobile Networks</title>
    <seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-icn-lte-4g-12"/> name="RFC" value="9269"/>
    <author fullname="Prakash Suthar" initials="" surname="Prakash Suthar"> initials="P" surname="Suthar">
      <organization>Google Inc.</organization>
      <address>
        <postal>
          <street/>
          <city>Mountain View</city>
          <region>California</region>
          <code>94043</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>psuthar@google.com</email>
      </address>
    </author>
    <author fullname="Milan Stolic" initials="" surname="Milan Stolic"> initials="M" surname="Stolic">
      <organization>Cisco Systems Inc.</organization>
      <address>
        <postal>
          <street/>
          <city>Naperville</city>
          <region>Illinois</region>
          <code>60540</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>mistolic@cisco.com</email>
      </address>
    </author>
    <author fullname="Anil Jangam" initials="" surname="Anil Jangam" initials="A" surname="Jangam" role="editor">
      <organization>Cisco Systems Inc.</organization>
      <address>
        <postal>
          <street/>
          <city>San Jose</city>
          <region>California</region>
          <code>95134</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>anjangam@cisco.com</email>
      </address>
    </author>
    <author fullname="Dirk Trossen" initials="" surname="Dirk Trossen"> initials="D" surname="Trossen">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Riesstrasse 25</street>
          <city/>
          <city>Munich</city>
          <code>80992</code>
          <country>Germany</country>
        </postal>
        <email>dirk.trossen@huawei.com</email>
      </address>
    </author>
    <author fullname="Ravi Ravindran" initials="" surname="Ravi Ravindran"> initials="R" surname="Ravindran">
      <organization>F5 Networks</organization>
      <address>
        <postal>
          <street>3545 North First Street</street>
          <city/>
          <city>San Jose</city>
	   <region>California</region>
          <code>95134</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>r.ravindran@f5.com</email>
      </address>
    </author>
    <date day="21" month="March"  month="August" year="2022"/>
    <area>General</area>
    <workgroup>ICN Research Group</workgroup>
    <keyword/>
    <workgroup>Information-Centric Networking</workgroup>
    <keyword>LTE</keyword>
    <keyword>ICN</keyword>
    <keyword>ICN-4G</keyword>
    <keyword>ICNoIP</keyword>
    <keyword>IPoICN</keyword>
    <keyword>HybridICN</keyword>
    <keyword>Dual Transport</keyword>
    <abstract>
      <t>4G
      <t>A 4G mobile network uses IP-based transport for the control plane to establish the data session at the user plane for the actual data delivery. In the existing architecture, IP-based unicast is used for the delivery of multimedia content to a mobile terminal, where each user is receiving a separate stream from the server. From a bandwidth and routing perspective, this approach is inefficient. Evolved multimedia broadcast and multicast service (eMBMS) provides capabilities for delivering contents to multiple users simultaneously, but its deployment is very limited or at an experimental stage due to numerous challenges. The focus of this draft document is to list the options for use of Information centric technology using Information-Centric Networking (ICN) in 4G mobile networks and elaborate the experimental setups for its further evaluation. The experimental setups discussed provide guidance for using ICN either natively or with an existing mobility protocol stack. With further investigations based on the listed experiments, ICN with its inherent capabilities such as, as network-layer multicast, anchorless mobility, security, and optimized data delivery using local caching at the edge may provide a viable alternative to IP transport in 4G mobile networks.</t>
    </abstract>
  </front>
  <!-- Middle section -->

	<middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>4G mobile technology is built as an all-IP network using routing protocols (OSPF, ISIS, IS-IS, BGP, etc.) to establish network routes. Stickiness The stickiness of an IP address to a device is the key to get getting connected to a mobile network. The same IP address is maintained through the session until the device gets detached or moves to another network.
      </t>
      <t>Key protocols used in 4G networks are GPRS the General Packet Radio Service Tunneling protocol Protocol (GTP), DIAMETER, and other protocols that are built on top of IP. One of the biggest challenges with IP-based routing in 4G is that it is not optimized for data transport. As an alternative to IP routing, this draft document presents and list lists the possible options for integration of Information Centric Information-Centric Networking (ICN) in 3GPP 4G mobile network, networks, offering an opportunity to leverage inherent ICN capabilities such as in-network caching, multicast, anchorless mobility management, and authentication. This draft document also discuss discusses how those options affect mobile providers and end users.
      </t>
      <t>The goal of the proposed experiments is to present possibilities to create simulated environments for evaluation of the benefits of ICN protocol deployment in a 4G mobile network in different scenarios that have been analyzed in this document.
The consensus of the Information-Centric Networking Research Group (ICNRG) is to publish this document in order to facilitate experiments to show deployment options and qualitative and quantitative benefits of ICN protocol deployment in 4G mobile networks.
      </t>
    </section>

    <section anchor="terminology_concepts" numbered="true" toc="default">
      <name>3GPP Terminology and Concepts</name>
      <ol spacing="normal" type="1"><li>
          <t>Access
      <dl>

	<dt>Access Point Name </t>
          <t>The Name:
	</dt>
	<dd>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 GGSN, PGW.
          </t>
        </li>
        <li>
          <t>Control Plane </t>
          <t> The a Gateway General Packet Radio Service Support Node (GGSN) or a Packet Data Network Gateway (PGW).
	</dd>

		<dt>Control Plane:
	</dt>
	<dd>The control plane carries signaling traffic and is responsible for
    routing between the eNodeB and MME, the Mobile Management Entity (MME), the MME and HSS, the Home Subscriber Server (HSS), the MME and SGW, SGW and PGW, 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 Mobile Gateways (SGW/PGW). Control plane functions also include system
	configuration and management.
          </t>
        </li>
        <li>
          <t>Dual
	</dd>

        <dt>Dual Address PDN/PDP Type </t>
          <t> The Type:
	</dt>
	<dd>The dual address Packet Data Network/Packet 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.
          </t>
        </li>
        <li>
          <t>eNodeB </t>
          <t> The
	</dd>

		<dt>eNodeB:
	</dt>
	<dd>The eNodeB is a base station entity that supports the Long-Term Long Term
	Evolution (LTE) air interface.
          </t>
        </li>
        <li>
          <t>Evolved
	</dd>

		<dt>Evolved Packet Core </t>
          <t> The Core:
	</dt>
	<dd>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 sub components subcomponents of the EPS core such as Mobility Management Entity (MME), Serving Gateway (SGW), Packet Data Network Gateway (PDN-GW), MME, Mobile Gateways (SGW/PGW), and Home Subscriber Server (HSS).
          </t>
        </li>
        <li>
          <t>Evolved HSS.
	</dd>

		<dt>Evolved Packet System </t>
          <t> The System:
	</dt>
	<dd>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 the Evolved
	Universal Terrestrial Radio Access (E-UTRA) and the Evolved Universal
	Terrestrial Radio Access Network (E-UTRAN).
          </t>
        </li>
        <li>
          <t>Evolved
	</dd>

		<dt>Evolved UTRAN:
	</dt>
	<dd>The Evolved UTRAN </t>
          <t> The E-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.
          </t>
        </li>
        <li>
          <t>GPRS Tunneling Protocol </t>
          <t> The GPRS Tunneling Protocol (GTP) <xref target="TS29.060" format="default"/> <xref target="TS29.274" format="default"/> <xref target="TS29.281" format="default"/> is a tunneling protocol defined by 3GPP. It is a network-based mobility protocol, working similar to Proxy Mobile IPv6 (PMIPv6). However, GTP also provides functionality beyond mobility, such as in-band signaling related to QoS and charging, among others.
          </t>
        </li>
        <li>
          <t>Gateway
	</dd>

		<dt>Gateway GPRS Support Node </t>
          <t> The Node:
	</dt>
	<dd>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.
          </t>
        </li>
        <li>
          <t>General
	</dd>

    <dt>General Packet Radio Service </t>
          <t> The Service:
    </dt>
    <dd>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
    systems (the GSM) specified by 3GPP.
          </t>
        </li>
        <li>
          <t>Home
    </dd>

		<dt>GPRS Tunneling Protocol:
	</dt>
	<dd>The GPRS Tunneling Protocol (GTP) <xref target="TS29.060"
	format="default"/> <xref target="TS29.274" format="default"/> <xref
	target="TS29.281" format="default"/> 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.
	</dd>
<dt>Home Subscriber Server </t>
          <t> The Server:
</dt>

<dd>The Home Subscriber Server (HSS) <xref target="TS29.336" format="default"/>
is a database for a given subscriber and was introduced in 3GPP Release-5. Release 5.
It is the entity containing subscription-related information to support the network
entities that handle calls/sessions.
          </t>
        </li>
        <li>
          <t>Mobility Management Entity </t>
          <t>
</dd>

<dt>Mobile Terminal/User Equipment:
</dt>
<dd>The terms User Equipment (UE), Mobile Station (MS), Mobile Node (MN), and
mobile refer to the devices that are hosts with the ability to obtain Internet
connectivity via a 3GPP network. An MS comprises the Terminal Equipment (TE)
and an MT. The terms MT, MS, MN, and mobile are used
interchangeably within this document.
</dd>

<dt>Mobility Management Entity:
</dt>
<dd>The Mobility Management Entity (MME) is a network element responsible for
control plane functionalities, including authentication, authorization, bearer
management, layer-2 Layer 2 mobility, and so on. The MME is essentially the control
plane part of the SGSN in the GPRS. The user plane user-plane traffic bypasses the MME.
          </t>
        </li>
        <li>
          <t>Public Land Mobile Network </t>
          <t> The Public Land Mobile Network (PLMN) is a network operated by a single administration. A PLMN (and, therefore, also an operator) is identified by the Mobile Country Code (MCC) and the Mobile Network Code (MNC). Each (telecommunications) operator providing mobile services has its own PLMN.

          </t>
        </li>
        <li>
          <t>Policy and Charging Control </t>
          <t> The Policy and Charging Control (PCC) framework is used for QoS policy and charging control. It has two main functions: flow-based charging (including online credit control), and policy control (for example, gating control, QoS control, and QoS signaling). It is optional to 3GPP EPS but needed if dynamic policy and charging control by means of PCC rules based on user and services are desired.
          </t>
        </li>
        <li>
          <t>Packet
</dd>

<dt>Packet Data Network </t>
          <t> The Network:
</dt>
<dd>The Packet Data Network (PDN) is a packet-based network that either
belongs to the operator or is an external network such as the Internet or a
corporate intranet. The user eventually accesses services in one or more
PDNs. The operator's packet core networks are separated from packet data
networks either by either GGSNs or PDN Gateways (PGWs).
          </t>
        </li>
        <li>
          <t>Serving Gateway </t>
          <t> The Serving Gateway (SGW) is a gateway function in the EPS, which terminates the interface towards the E-UTRAN. The SGW is the Mobility Anchor point for layer-2 mobility (inter-eNodeB handovers). For each mobile terminal connected with the EPS, there is only one SGW at any given point in time. The SGW is essentially the user plane part of the GPRS's SGSN.
          </t>
        </li>
        <li>
          <t>Packet PGWs.
</dd>

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

<dt> Packet Data Protocol Context </t>
          <t> A Context:
</dt>
<dd>A Packet Data Protocol (PDP) context is the equivalent of a virtual
connection between the mobile terminal (MT) and a PDN using a specific
gateway.
          </t>
        </li>
        <li>
          <t>Packet
</dd>

<dt>Packet Data Protocol Type </t>
          <t> A Type:
</dt>
<dd>A Packet Data Protocol Type (PDP Type) identifies the used/allowed protocols within the PDP context. Examples are IPv4, IPv6, and IPv4v6 (dual-stack).
          </t>
        </li>
        <li>
          <t>Serving (dual stack).
</dd>

<dt>Policy and Charging Control:
</dt>
<dd>The Policy and Charging Control (PCC) framework is used for QoS policy and
charging control. It has two main functions: flow-based charging (including
online credit control) and policy control (for example, gating control, QoS
control, and QoS signaling). It is optional to 3GPP EPS but needed if dynamic
policy and charging control by means of PCC rules based on user and services
are desired.
</dd>

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

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

<dt>Serving GPRS Support Node </t>
          <t> The Node:
</dt>
<dd>The Serving GPRS Support Node (SGSN) is a network element located between
the radio access network Radio Access Network (RAN) and the gateway (GGSN). A per-MT point-to-point (p2p)
(P2P) tunnel between the GGSN and SGSN transports the packets between the
mobile terminal and the gateway.
          </t>
        </li>
        <li>
          <t>Mobile Terminal/User Equipment </t>
          <t> The terms User Equipment (UE), Mobile Station (MS), Mobile Node (MN), and mobile refer to the devices that are hosts with the ability to obtain Internet connectivity via a 3GPP network. An MS comprises the Terminal Equipment (TE) and a Mobile Terminal (MT). The terms MT, MS, MN, and mobile are used interchangeably within this document.
          </t>
        </li>
        <li>
          <t>User Plane </t>
          <t> The
</dd>

<dt>User Plane:
</dt>
<dd>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.
          </t>
        </li>
      </ol>
</dd>

</dl>

</section>
    <section anchor="_4G_mobile_network_architecture" numbered="true" toc="default">
      <name>4G Mobile Network Architecture</name>
      <t>This section provide provides a high-level overview of typical 4G mobile network architecture and their the key functions related to a the possibility of using of its use with ICN technology.</t>

      <section anchor="network_overview" numbered="true" toc="default">
        <name>Network Overview</name>
        <t>4G mobile networks are designed to use IP transport for communication among different elements such as the eNodeB, MME, SGW/PGW, SGW, PGW, HSS, PCRF, etc. <xref Policy and Charging Rule Function (PCRF), etc.&nbsp;<xref target="GRAYSON" format="default"/>. For backward compatibility with 3G, it has support for legacy Circuit Switch circuit switch features such as voice and SMS through transitional CS fallback and flexible IMS IP Multimedia Subsystems (IMS) deployment. For each mobile device attached to the radio (eNodeB), there is a separate overlay tunnel (GPRS Tunneling Protocol, GTP) (GTP) between the eNodeB and Mobile gateways Gateways (i.e., SGW, PGW). SGW/PGW).
        </t>

        <t>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 address addresses based on request and capabilities offered by mobile gateways.</t> Mobile Gateways.</t>
        <t>The GTP tunnel is used to carry user traffic between gateways and mobile terminal, terminals, therefore using the unicast delivery for any data transfer. It is also important to understand the overhead of GTP and IPSec IPsec protocols. All mobile backhaul traffic is encapsulated using a GTP tunnel, which has overhead of 8 bytes on top of IP and UDP <xref target="NGMN" format="default"/>. Additionally, if IPSec 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 IPsec tunneling model (tunnel or transport) as well as the encryption and authentication header algorithm used. If we consider as an example an Advanced Encryption Standard (AES) encryption, encryption as an example, the overhead can be significant <xref target="OLTEANU" format="default"/>, particularly for smaller payloads.
        </t>
        <figure anchor="fig_lte_4g_mobile_net_overview">
          <name>4G Mobile Network Overview</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
                                       +-------+  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
                    ]]></artwork>
        </figure>
        <t>If we consider the combined impact of GTP, IPSec 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 RObust Header Compression (ROHC) and enhanced compression of the real-time transport protocol Enhanced Compression RTP (ECRTP) so that the impact of overhead created by GTP, IPsec, etc., is reduced to some extent <xref target="BROWER" format="default"/>. For commercial mobile networks, 3GPP has adopted different mechanisms for header compression to achieve efficiency in data delivery <xref target="TS25.323" format="default"/>; those solutions can be adapted to other data protocols, protocols too such as ICN, too ICN <xref target="ICNLOWPAN" target="RFC9139" format="default"/> <xref target="TLVCOMP" format="default"/>.
        </t>

      </section>
      <section anchor="mobile_network_qos" numbered="true" toc="default">
        <name>Mobile Network Quality of Service</name>
        <t>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. Dedicated A dedicated bearer can be requested either by either a mobile terminal or mobile gateway a Mobile Gateway based on the direction of the first data flow. There are many bearers (logical paths) established between an eNodeB and mobile gateway a Mobile Gateway for each mobile terminal catering to a different data flow simultaneously.
        </t>
        <t>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 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, low latency, fair, and so on).
        </t>
        <t>Implementation of QoS for mobile networks is done at two stages: at 1) content prioritization/marking and transport marking, marking and 2) congestion management. From the transport perspective, QoS is defined at layer Layer 2 as class Class of service Service (CoS) and at layer Layer 3 as Differentiated Services (DS). The mapping of DSCP the Differentiated Services Code Point (DSCP) to CoS takes place at layer Layer 2/3 switching and routing elements. 3GPP has a specified a QoS Class Identifier (QCI), which represents different types of content and equivalent mappings to the DSCP at the transport layer <xref target="TS23.401" format="default"/>. However, this requires manual configuration at different elements and is therefore prone to possible misconfigurations.
        </t>
        <t>In summary, QoS configuration in mobile networks for user plane 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 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 <xref target="ICNQoS" format="default"/> at the ICN forwarder. Further investigation is underway to understand how QoS in ICN <xref target="I-D.anilj-icnrg-dnc-qos-icn" target="QoS-ICN" format="default"/> can be implemented with reference to the ICN QoS guidelines <xref target="RFC9064" format="default"/> to meet the QoS requirements <xref target="RFC4594" format="default"/>.
        </t>

      </section>
      <section anchor="data_transport_using_ip" numbered="true" toc="default">
        <name>Data Transport Using IP</name>
        <t>The data delivered to mobile devices is sent in unicast semantic inside the GTP tunnel from an eNodeB to a PDN gateway (PGW), (PGW) as described in 3GPP specifications <xref target="TS23.401" format="default"/>. 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 <xref target="EMBMS" format="default"/>, multicast routing can be enabled in mobile backhaul between an eNodeB and Mobile Gateways (SGW) however (SGW/PGW); however, for radio interface it requires broadcast 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 on-demand model.
        </t>
        <t>To ease the burden on the bandwidth of the SGi interface, Service Gateway interface (SGi), caching is introduced in a similar manner as with many Enterprises. 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 packet core locations with the PGW nodes close to the Internet and IP services access (SGi interface). (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.
        </t>

      </section>
      <section anchor="virtualized_mobile_networks" numbered="true" toc="default">
        <name>Virtualized Mobile Networks</name>
        <t>The Mobile gateways Gateways deployed in a major Service Provider network are either based on either dedicated hardware or, commercially off the shelf or commercial off-the-shelf (COTS) based x86 technology. With the adoption of Mobile Virtual Network Operators (MVNO), (MVNOs), public safety networks, and enterprise mobility networks, elastic mobile core architecture are is needed. By deploying the mobile packet core on a COTS platform, using a virtualized infrastructure Network Function Virtualization Infrastructure (NFVI) framework and end-to-end orchestration, new deployments can be simplified to provide optimized total cost of ownership (TCO).</t>
        <t>While virtualization is growing, and many mobile providers use a hybrid architecture that consists of dedicated and virtualized infrastructures, the control, control and data planes are still the same. There is also work under way 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 user-plane separation provide a mechanism to evolve the GTP-based architecture towards an OpenFlow SDN-based 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 user-plane separation and simplifies the mobility call flow by introducing OpenFlow-based signaling <xref target="ICN5G" format="default"/>. This has been considered by 3GPP <xref target="EPCCUPS" format="default"/> and is also described in <xref target="SDN5G" format="default"/>.
        </t>
      </section>
    </section>
    <section anchor="data_transport_using_icn" numbered="true" toc="default">
      <name>Data Transport Using ICN</name>
      <t>For mobile devices, the edge connectivity is between a mobile terminal and a router or mobile edge computing (MEC) <xref target="MECSPEC" format="default"/> element. Edge computing has the capability of processing client requests and segregating control and user traffic at the edge of radio, radio rather than sending all requests to the mobile gateway. Mobile Gateway.
      </t>
      <figure anchor="fig_icn_architecture">
        <name>ICN Architecture</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[
     +----------+
     | Content  +----------------------------------------+
     | Publisher|                                        |
     +---+---+--+                                        |
         |   |    +--+             +--+           +--+   |
         |   +--->|R1|------------>|R2|---------->|R4|   |
         |        +--+             +--+           +--+   |
         |                           |   Cached          |
         |                           v   content         |
         |                         +--+  at R3           |
         |                +========|R3|---+              |
         |                #        +--+   |              |
         |                #               |              |
         |                v               v              |
         |               +-+             +-+             |
         +---------------| |-------------| |-------------+
                         +-+             +-+
                      Consumer-1      Consumer-2
                   Mobile Terminal  Mobile Terminal

                 ===> Content flow from cache
                 ---> Content flow from publisher
                ]]></artwork>
      </figure>
      <t>Edge computing transforms radio access network a Radio Access Network into an intelligent service edge capable of delivering services directly from the edge of the network, network while providing the best possible performance to the client. Edge computing can be an ideal candidate for implementing ICN forwarders in addition to its usual function of managing mobile termination. In addition to edge computing, other transport elements, such as routers, can work as ICN forwarders.
      </t>

      <t>Data transport using ICN is different to than IP-based transport by introducing as it introduces uniquely named-data as a core design principle. Communication in ICN takes place between the content provider (producer) and the end user (consumer), as described in <xref target="fig_icn_architecture" format="default"/>.
      </t>
      <t>Every node in a physical path between a client and a content provider is called the ICN forwarder or router. It can route the request intelligently and cache content so it can be delivered locally for subsequent requests from any other client. For mobile networks, transport between a client and a content provider consists of a radio network + mobile backhaul and IP core transport + Mobile Gateways + Internet + content data network Content Delivery Network (CDN).
      </t>
      <t>To understand the suitability of ICN for mobile networks, we will discuss the ICN framework by describing its protocols protocol architecture and different types of messages to then consider messages; this will be helpful when considering how we can to use this ICN in mobile networks for delivering to deliver content more efficiently. ICN uses two types of packets called "interest packet" and "data packet" as described in <xref target="fig_icn_interest_data_fwd" format="default"/>.
      </t>
      <figure anchor="fig_icn_interest_data_fwd">
        <name>ICN Interest, Data Packet Packet, and Forwarder</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[
               +------------------------------------+
      Interest | +------+     +------+     +------+ |        +-----+
 +-+        ---->|  CS  |---->| PIT  |---->| FIB  |--------->| CDN |
 | |           | +------+     +------+     +------+ |        +-----+
 +-+           |     |      Add  |       Drop |     | Forward
 MT         <--------+      Intf v       Nack v     |
         Data  |                                    |
               +------------------------------------+

               +------------------------------------+
 +-+           |  Forward                  +------+ |        +-----+
 | | <-------------------------------------| PIT  |<---------| CDN |
 +-+           |                 | Cache   +--+---+ | Data   +-----+
 MT            |              +--v---+        |     |
               |              |  CS  |        v     |
               |              +------+      Discard |
               +------------------------------------+
                ]]></artwork>
      </figure>
      <t>In an a 4G network, when a mobile device wants to receive certain content, it will send an Interest message to the closest eNodeB. Interest packets follow the TLV format <xref target="RFC8609" format="default"/> and contain mandatory fields, fields such as the name of the content and content matching content-matching restrictions (KeyIdRestr and ContentObjectHashRestr), ContentObjectHashRestr) expressed as a tuple <xref target="RFC8569" format="default"/>. The content matching content-matching tuple uniquely identifies the matching data packet for the given Interest packet. Another attribute called HopLimit "HopLimit" is used to detect looping Interest messages.
      </t>
      <t>An ICN router will receive an Interest packet and lookup if a request for such content has arrived earlier from another client. If so, it may be served from the local cache; otherwise, the request is forwarded to the next-hop ICN router. Each ICN router maintains three data structures: Pending Interest Table (PIT), Forwarding Information Base (FIB), and Content Store (CS). The Interest packet travels hop-by-hop hop by hop towards the content provider. Once the Interest packet reaches the content provider, it will return a Data data packet containing information such as content name, signature, and the actual data.

      </t>
      <t>The data packet travels in reverse direction following the same path taken by the Interest packet, maintaining routing symmetry. Details about algorithms used in PIT, FIB, CS, and security trust models are described in various resources <xref target="CCN" format="default"/>; here, we have explained the concept and its applicability to the 4G network.
      </t>
    </section>

    <section anchor="icn_deploy_4g_networks" numbered="true" toc="default">
      <name>Experimental Scenarios for ICN Deployment</name>
      <t>In 4G mobile networks, both user and control plane traffic have to be transported from the edge to the mobile packet core via IP transport. The evolution of the existing mobile packet core using Control and User Plane Separation (CUPS) <xref target="TS23.714" format="default"/> enables flexible network networking and operations by distributed deployment and the independent scaling of control plane and user plane user-plane functions - while not affecting the functionality of existing nodes subject to this split.
      </t>
      <t>In this section, we analyze the potential impact of ICN on control and user plane user-plane traffic for centralized and disaggregated CUPS-based mobile network architecture. We list various experimental options and opportunities to study the feasibility of the deployment of ICN in 4G networks.
      The proposed experiments would help the network and OEM original equipment manufacturer (OEM) designers to understand various issues, optimizations, and advantages of the deployment of ICN in 4G networks.</t>
      <section anchor="general_icn_considerations" numbered="true" toc="default">
        <name>General Considerations</name>
        <t>In the CUPS architecture, there is an opportunity to shorten the path for user plane user-plane traffic by deploying offload nodes closer to the edge <xref target="OFFLOAD" format="default"/>. 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.
        </t>
      </section>
      <section anchor="icn_deployment_scenarios" numbered="true" toc="default">
        <name>Scenarios of ICN Integration</name>
        <t>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 <xref target="RFC6459" format="default"/> and analyzed the impact of ICN on control plane signaling and user plane user-plane data delivery. In general, ICN can be used natively by replacing IP transport (IPv4 and IPv6) or as an overlay protocol. <xref target="fig_icn_ip_convergence_deployments" format="default"/> describes a proposal to modify the existing transport protocol stack to support ICN in a 4G mobile network.
        </t>
        <figure anchor="fig_icn_ip_convergence_deployments">
          <name>IP/ICN Convergence Scenarios</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
 +----------------+ +-----------------+
 | ICN App (new)  | |IP App (existing)|
 +---------+------+ +-------+---------+
           |                |
 +---------+----------------+---------+
 | Transport Convergence Layer (new)  |
 +------+---------------------+-------+
        |                     |
 +------+------+       +------+-------+
 |ICN function |       | IP function  |
 |   (New)     |       | (Existing)   |
 +------+------+       +------+-------+
        |                     |
      (```).                (```).
    (  ICN  '`.           (  IP   '`.
    ( Cloud   )           ( Cloud   )
     ` __..'+'             ` __..'+'
]]></artwork>
        </figure>
        <t>As shown in <xref target="fig_icn_ip_convergence_deployments" format="default"/>, for applications - running (running either in the mobile terminal or in the content provider system - 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), IP) as well as the type of radio interface (LTE or WiFi (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).
        </t>

        <t>Combined with the existing IP function, the ICN function provides support for either native ICN and/or the dual transport (ICN/IP) transport functionality. See <xref target="dual_transport_icn_deploy_mt" format="default"/> for elaborate descriptions of these functional layers.
        </t>
        <t>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 WiFi. 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.
        </t>
        <t>Another potential application of TCL is in an implementation of network slicing, slicing with a local slice management capability locally or through an interface to an external slice manager via an API <xref target="GALIS" format="default"/>. 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'. Slicing The slicing policy can be obtained externally from the slice manager or configured locally on the mobile terminal.
        </t>
        <t>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.
        </t>
        <ol spacing="normal" type="1"><li>
            <t>IP

<dl>

<dt>IP over IP
            </t>
            <t> (IPoIP):
</dt>
<dd> 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.
            </t>
          </li>
          <li>
            <t>ICN
</dd>

<dt>ICN over ICN
            </t>
            <t> (ICNoICN):
</dt>
<dd> 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.
            </t>
          </li>
          <li>
            <t>ICN
</dd>

<dt>ICN over IP (ICNoIP)
            </t>
            <t>
                            In (ICNoIP):
</dt>
<dd> <t>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 either using either
IP or ICN, based on the mobile terminal request.
</t>
            <t>
                            One

<t>One of the approaches to implement ICN in mobile backhaul networks is
described in <xref target="MBICN" format="default"/>. It implements a GTP-U 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 SGW, 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, 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
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, edge to perform ICN data retrieval on behalf of a non-ICN end device.
            </t>
          </li>
          <li>
            <t>IP
device.</t>
</dd>

<dt>IP over ICN (IPoICN)
            </t> (IPoICN):
</dt>
<dd>
  <t><xref target="IPoICN" format="default"/> 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

  IPoICN, however, will require an inter-working interworking function (IWF/Border (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 <xref target="IPoICN"
format="default"/>, we understand and interpret that ICN is implemented in the
transport natively, natively; however, IP is implemented in MT, the eNodeB, and the Mobile gateway
  Gateway (SGW/PGW), which is also called as a network attach point (NAP).

            </t> (NAP).</t>

  <t> 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.
  </t>
          </li>
          <li>
            <t>Hybrid
</dd>

<dt>Hybrid ICN (hICN)
            </t>
            <t>
                            An (hICN):
</dt>
<dd>
<t>An alternative approach to implement ICN over IP is provided in Hybrid ICN
<xref target="HICN" format="default"/>. 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
components, name prefix and name suffix--that suffix, that identify the source of data and
the data segment within the scope of the name prefix, respectively.
</t>
            <t>
                            At

<t>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, in the eNodeB, in the mobile
backhaul, or in the mobile core. Finally, as hICN itself uses IPv6, it cannot
be considered as an alternative transport layer.
</t>
          </li>
        </ol>
</dd>
</dl>
</section>
      <section anchor="icn_deployment_in_4g_control_plane" numbered="true" toc="default">
        <name>Integration of ICN in 4G Control Plane</name>
        <t>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:
        </t>
        <ol spacing="normal" type="1"><li>eNodeB managing location or physical POA</li>
          <li>Authentication and Authorization (MME, HSS) managing identity or authentication POA</li>
          <li>Mobile Gateways (SGW, PGW) (SGW/PGW) managing logical or session management POA</li>
        </ol>
        <t>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 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 an a 4G network per the signaling procedure is shown in <xref target="tab_4g_messages" format="default"/>.
        </t>
        <t>Normally, two types of mobile terminals attach to the 4G network: SIM based (need (which needs a 3GPP mobility protocol for authentication) or non-SIM based (which connect connects to WiFi network). Wi-Fi networks). Both device types require authentication. For non-SIM based devices, AAA 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 messages, structures, and flows. We are merely analyzing the viability of implementing ICN as a transport for control plane messages.
        </t>
        <t>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 Create Session <xref target="TS23.401" format="default"/>.
        </t>
        <table anchor="tab_4g_messages" align="center">
          <name>Signaling Messages in 4G Gateways</name>
          <thead>
            <tr>
              <th align="left">4G Signaling Procedures</th>
              <th align="right">MME</th>
              <th align="right">HSS</th>
              <th align="right">SGW</th>
              <th align="right">PGW</th>
              <th align="right">PCRF</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">Attach</td>
              <td align="right">10</td>
              <td align="right">2</td>
              <td align="right">3</td>
              <td align="right">2</td>
              <td align="right">1</td>
            </tr>
            <tr>
              <td align="left">Additional default bearer</td>
              <td align="right">4</td>
              <td align="right">0</td>
              <td align="right">3</td>
              <td align="right">2</td>
              <td align="right">1</td>
            </tr>
            <tr>
              <td align="left">Dedicated bearer</td>
              <td align="right">2</td>
              <td align="right">0</td>
              <td align="right">2</td>
              <td align="right">2</td>
              <td align="right">0</td>
            </tr>
            <tr>
              <td align="left">Idle-to-connect</td>
              <td align="right">3</td>
              <td align="right">0</td>
              <td align="right">1</td>
              <td align="right">0</td>
              <td align="right">0</td>
            </tr>
            <tr>
              <td align="left">Connect-to-Idle</td>
              <td align="right">3</td>
              <td align="right">0</td>
              <td align="right">1</td>
              <td align="right">0</td>
              <td align="right">0</td>
            </tr>
            <tr>
              <td align="left">X2 handover</td>
              <td align="right">2</td>
              <td align="right">0</td>
              <td align="right">1</td>
              <td align="right">0</td>
              <td align="right">0</td>
            </tr>
            <tr>
              <td align="left">S1 handover</td>
              <td align="right">8</td>
              <td align="right">0</td>
              <td align="right">3</td>
              <td align="right">0</td>
              <td align="right">0</td>
            </tr>
            <tr>
              <td align="left">Tracking area update</td>
              <td align="right">2</td>
              <td align="right">2</td>
              <td align="right">0</td>
              <td align="right">0</td>
              <td align="right">0</td>
            </tr>
            <tr>
              <td align="left">Total</td>
              <td align="right">34</td>
              <td align="right">2</td>
              <td align="right">14</td>
              <td align="right">6</td>
              <td align="right">3</td>
            </tr>
          </tbody>
        </table>
        <t>Anchorless mobility <xref target="ALM" format="default"/> provides a fully decentralized, control- decentralized solution that is control plane agnostic solution to handle producer mobility in ICN.

	Mobility management at layer-3 level the Layer 3 makes it 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. (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.
        </t>
        <t>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 <xref target="TS23.401" format="default"/> and messages inter-dependencies message interdependencies (see <xref target="tab_4g_messages" format="default"/>), 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 applications, and they cannot be shared.
        </t>
      </section>
      <section anchor="icn_deployment_in_4g_user_plane" numbered="true" toc="default">
        <name>Integration of ICN in 4G User Plane</name>
        <t>We will consider <xref target="fig_lte_4g_mobile_net_overview" format="default"/> to discuss when discussing different mechanisms to integrate ICN in mobile networks. In <xref target="icn_deployment_scenarios" format="default"/>, 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. We consider the The following options: options are considered:
        </t>
        <ol spacing="normal" type="1"><li>Dual type="1"><li>Using Dual transport (IP/ICN) mode in Mobile Terminal</li> mobile terminal</li>
          <li>Using ICN in Mobile Terminal</li> mobile terminal</li>
          <li>Using ICN in eNodeB</li>
          <li>Using ICN in mobile gateways Mobile Gateways (SGW/PGW)</li>
        </ol>

        <section anchor="dual_transport_icn_deploy_mt" numbered="true" toc="default">
          <name>Dual Transport (IP/ICN) Mode in Mobile Terminal</name>
          <t>The control and user plane user-plane communications in 4G mobile networks are specified in 3GPP documents <xref target="TS23.203" format="default"> </xref> and <xref target="TS23.401" format="default"/>. It is important to understand that a mobile terminal can be either consumer (receiving content) or publisher (pushing content for other clients). The protocol stack inside the mobile terminal (MT) is complex because it must support multiple radio connectivity access to eNodeB(s).
          </t>
          <t><xref target="fig_dual_Stack_icn_deploy_mt" format="default"/> provides a high-level description of a protocol stack, where IP is used at two layers: (1) user plane user-plane communication and (2) UDP encapsulation. User plane User-plane communication takes place between the Packet Data Convergence Protocol (PDCP) and Application layer, whereas UDP encapsulation is at the GTP protocol stack.
          </t>

          <t>The protocol interactions and impact of supporting the tunneling of an ICN packet into IP or to support supporting ICN natively are described in Figures <xref target="fig_dual_Stack_icn_deploy_mt" format="default"/> format="counter"/> and <xref target="fig_dual_Stack_icn_protocol_interaction" format="default"/>, format="counter"/>, respectively.

          </t>
          <figure anchor="fig_dual_Stack_icn_deploy_mt">
            <name>Dual Transport (IP/ICN) mode Mode in a Mobile Terminal</name>

            <artwork align="center" name="" type="" alt=""><![CDATA[
+--------+                                               +--------+
|   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)  BS (eNodeB) |      SGW      |     PGW    |
          Uu             S1U            S5/S8         SGi
                        ]]></artwork>
          </figure>
          <t>The protocols and software stack used inside 4G capable 4G-capable mobile terminal
          terminals support both 3G and 4G software interworking and handover.
          3GPP Rel.13 onward specifications and onward describe the use of IP and
          non-IP protocols to establish logical/session connectivity. We can
          leverage the non-IP protocol-based mechanism to deploy an ICN protocol
          stack in the mobile terminal, terminal as well as in an eNodeB and mobile gateways (SGW, PGW). Mobile
          Gateways (SGW/PGW). The following paragraphs describe per-layer
          considerations of supporting the tunneling of ICN packet packets into IP or to support
          supporting ICN natively.

          </t>
          <ol spacing="normal" type="1"><li>
              <t>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.

              </t>
              <t>
                            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 <xref target="icn_deployment_scenarios" format="default"/>, the transport convergence layer (TCL) TCL function handles the interaction of applications with multiple transport options.
              </t>
            </li>
            <li>
              <t>The transport convergence layer helps determine the type of transport (such as ICN, hICN, or IP) and type of radio interface (LTE or WiFi, (LTE, Wi-Fi, or both) used to send and receive traffic. Application The application layer can make the decision to select a specific transport based on preference, preference such as content location, content type, content publisher, congestion, cost, QoS, and so on. There can be an Application Programming Interface (API) API to exchange parameters required for transport selection. Southbound interactions of Transport Convergence Layer (TCL) the TCL will be either to IP or to ICN at the network layer.

              </t>
              <t>
                            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, packet or the hash over the FQDN of the HTTP request for an HTTP packet).

              </t>
	      <t>
                            In the HTTP case, the TCL can maintain a pending request mapping table to map map, returning responses to the originating HTTP request. The common API will provide a 'connection' "connection" abstraction for this HTTP mode of operation, returning the response over said connection abstraction, akin abstraction (akin to the TCP socket interface, 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.

              </t>
              <figure anchor="fig_dual_Stack_icn_protocol_interaction">
                <name>Dual Stack ICN Protocol Interactions</name>
                <artwork align="center" name="" type="" alt=""><![CDATA[
+----------------+ +-----------------+
| 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)       |
+------------------------------------+
                                    ]]></artwork>
              </figure>
            </li>
            <li>The ICN function (forwarder) is proposed to run in parallel to the existing IP layer. The ICN forwarder forwards the ICN packets, packets such as an Interest packet to an eNodeB or a response "data packet" from an eNodeB to the application.
                            </li>
            <li>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 data, respectively. This interface can use the ICN overlay over IP.
                            </li>
            <li>
              <t>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 <xref target="TS36.323" format="default"/>:
              </t>

              <ol spacing="normal" type="1"><li>Data type="1">
		<li>Data transport by listening to the upper layer, formatting formatting, and pushing down to Radio Link Layer (RLC) the RLC
                                    </li>
                <li>Header compression and decompression using Robust Header Compression (ROHC) ROHC
                                    </li>
                <li>Security protections such as ciphering, deciphering, and integrity protection
                                    </li>
                <li>Radio layer messages associated with sequencing, packet drop detection and re-transmission, retransmission, and so on.
                                    </li>
              </ol>
            </li>
            <li>No changes are required for the lower layer such as RLC, MAC, Media Access Control (MAC), and Physical (L1) as they are not IP aware.
                            </li>
          </ol>
          <t>One key point to understand in this scenario is that ICN is deployed as an overlay on top of IP.
          </t>
        </section>
        <section anchor="native_icn_deployment_in_mt" numbered="true" toc="default">
          <name>Using ICN in Mobile Terminal</name>

          <t>We can implement ICN natively in the mobile terminal by modifying the PDCP layer in 3GPP protocols. <xref target="fig_native_icn_deployment_in_mt" format="default"/> provides a high-level protocol stack description where ICN can be used at the following different layers:

          </t>
          <ol spacing="normal" type="1"><li>User plane type="1"><li>User-plane communication</li>
            <li>Transport layer</li>
          </ol>
          <t>ICN transport would be a substitute of for the GTP protocol. The removal of the GTP protocol stack is a significant change in the mobile architecture and requires a thorough study mainly because it is used not just for routing but for mobility management functions, functions such as billing, mediation, and policy enforcement.
          </t>
          <t>The implementation of ICN natively in the mobile terminal leads to a changed communication model between the mobile terminal and eNodeB. Also, we can avoid tunneling the user plane user-plane traffic from an eNodeB to the mobile packet core (SGW, PGW) (SGW/PGW) through a GTP tunnel.
          </t>
          <t>For native ICN use, an application can be configured to use an ICN forwarder forwarder, and it does not need the TCL layer. Also, to support ICN at the network layer, the existing PDCP layer may need to be changed to be aware of ICN capabilities and parameters.
          </t>
          <t>The native implementation can provide new opportunities to develop new use cases leveraging ICN capabilities, capabilities such as seamless mobility, mobile terminal to mobile terminal content delivery using a radio network without traversing the mobile gateways, Mobile Gateways, and more.
          </t>
          <figure anchor="fig_native_icn_deployment_in_mt">
            <name>Using Native ICN in Mobile Terminal</name>
            <artwork align="center" name="" type="" alt=""><![CDATA[
+--------+                                                +--------+
|  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
                        ]]></artwork>
          </figure>
        </section>
        <section anchor="icn_deployment_in_enodeb" numbered="true" toc="default">
          <name>Using ICN in eNodeB</name>
          <t>The eNodeB is a physical point of attachment for the mobile terminal, terminal where radio protocols are converted into IP transport protocol protocols for dual transport/overlay and native ICN, respectively (see Figures <xref target="fig_dual_Stack_icn_protocol_interaction" format="default"/> format="counter"/> and <xref target="fig_native_icn_deployment_in_mt" format="default"/>). format="counter"/>). When a mobile terminal performs an attach procedure, it would will be assigned an identity either as either IP or dual transport (IP and ICN), ICN) or ICN endpoint. Mobile A mobile terminal can initiate data traffic using any of the following options:
          </t>
          <ol spacing="normal" type="1"><li>Native IP (IPv4 or IPv6)</li>
            <li>Native ICN</li>
            <li>Dual transport IP (IPv4/IPv6) and ICN</li>
</ol>

<t>The mobile terminal encapsulates a user data transport request into the PDCP layer and sends the information on the air interface to the eNodeB, which in turn receives the information and, using PDCP <xref target="TS36.323" format="default"/>, de-encapsulates the air-interface messages and converts them to forward to core mobile gateways (SGW, PGW). forward-to-core Mobile Gateways (SGW/PGW). As shown in <xref target="fig_native_icn_deployment_in_enodeb" format="default"/>, to support ICN natively in an eNodeB, it is proposed to provide transport convergence layer (TCL) TCL capabilities in an eNodeB (similar to as provided in MT), which provides the following functions:
          </t>
          <ol spacing="normal" type="1"><li>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.
                            </li>
            <li>
              <t>eNodeB
              <t>It uses an eNodeB to provide an open Application Programming Interface (API) API to external management systems, systems in order to provide capability to eNodeB the capability to program the forwarding strategies.
              </t>
              <figure anchor="fig_native_icn_deployment_in_enodeb">
                <name>Integration of Native ICN in eNodeB</name>
                <artwork align="center" name="" type="" alt=""><![CDATA[
              +---------------+  |
              | MT request    |  |    ICN          +---------+
        +---->| content using |--+--- transport -->|         |
        |     |ICN protocol   |  |                 |         |
        |     +---------------+  |                 |         |
        |                        |                 |         |
        |     +---------------+  |                 |         |
    +-+ |     | MT request    |  |    IP           |To mobile|
    | |-+---->| content using |--+--- transport -->|    GW   |
    +-+ |     | IP protocol   |  |                 |(SGW,PGW)|                 |(SGW/PGW)|
    MT  |     +---------------+  |                 |         |
        |                        |                 |         |
        |     +---------------+  |                 |         |
        |     | MT request    |  |    Dual stack   |         |
        +---->| content using |--+--- IP+ICN    -->|         |
              |IP/ICN protocol|  |    transport    +---------+
              +---------------+  |
                  eNodeB        S1u
                                    ]]></artwork>
              </figure>
            </li>
            <li>
              <t>eNodeB
              <t>The eNodeB can be upgraded to support three different types of transport: IP, ICN, and dual transport IP+ICN towards mobile gateways, Mobile Gateways, as depicted in <xref target="fig_native_icn_deployment_in_enodeb" format="default"/>. It is also proposed to deploy IP and/or ICN forwarding capabilities into eNodeB, an eNodeB for efficient transfer of data between the eNodeB and mobile gateways. Following Mobile Gateways. The following are choices for forwarding a data request towards mobile gateways: Mobile Gateways:
              </t>
              <ol spacing="normal" type="1"><li>Assuming type="1">
		<li>Assuming the eNodeB is IP enabled and the MT requests an IP transfer, the eNodeB forwards data over IP.
                                    </li>
                <li>Assuming the eNodeB is ICN enabled and the MT requests an ICN transfer, the eNodeB forwards data over ICN.
                                    </li>
                <li>Assuming the eNodeB is IP enabled and the MT requests an ICN transfer, the eNodeB overlays ICN on IP and forwards user plane user-plane traffic over IP.
                                    </li>
                <li>Assuming the eNodeB is ICN enabled and the MT requests an IP transfer, the eNodeB overlays IP on ICN and forwards user plane user-plane traffic over ICN <xref target="IPoICN" format="default"/>.
                                    </li>
              </ol>
            </li>
          </ol>
        </section>
        <section anchor="icn_deployment_in_packet_core" numbered="true" toc="default">

            <name>Using ICN in Packet Core (SGW, PGW) Gateways</name> Gateways (SGW/PGW)</name>
          <t>Mobile gateways (a.k.a. Evolved Gateways (a.k.a.&nbsp;Evolved Packet Core (EPC)) include SGW, SGW and PGW, which perform session management for MT from the initial attach to disconnection. When MT is powered on, it performs NAS Network-Access-Stratum (NAS) signaling and attaches to PGW after successful authentication. PGW is an anchoring point for MT and is responsible for service creations, authorization, maintenance, and so on. The Entire entire functionality is managed using an IP address(es) for MT.
          </t>
          <t>To implement ICN in EPC, the following functions are proposed:
          </t>

          <ol spacing="normal" type="1"><li>Insert ICN attributes in the session management layer as for additional functionality with IP stack. Session The session management layer is used for performing attach procedures and assigning logical identity to user. users. After successful authentication by HSS, MME sends a create session request Create Session Request (CSR) to SGW and SGW to PGW.
                            </li>
            <li>When MME sends a Create Session Request message (Step 12 in <xref target="TS23.401" format="default"/>) to SGW or PGW, it includes a Protocol Configuration Option (PCO) Information Element (PCO IE) (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 either native IP, ICN+IP, or native ICN. IP is referred to as both IPv4 and IPv6 protocols.
                            </li>
            <li>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.
                            </li>
            <li>To support ICN-capable attach procedures and use ICN for user plane 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) 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.
            </li>

            <li>
              <t>PCO IE as described in <xref target="TS24.008" format="default"/> (see Figure 10.5.136 on page 598) 656 and <xref target="TS24.008" format="default"/> (see Table 10.5.154 on page 599) provide 659) provides details for different fields.
              </t>
              <ol spacing="normal" type="1"><li>Octet 3 (configuration protocols define PDN types), which contains details about IPv4, IPv6, both IPv4 and IPv6, or ICN.
                                    </li>
                                    <li>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) Mobile Gateways (SGW/PGW) so they can be interpreted properly and the MT can attach successfully.
                                    </li>
              </ol>
            </li>
            <li>The ICN functionalities in SGW and PGW should be matched with MT and the eNodeB because they will exchange ICN protocols and parameters.</li>
            <li>Mobile gateways SGW, PGW 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.</li>
            <li>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 a an MT attached with an ICN identity, if PGW must communicate with an IP enabled 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.
                            </li>
          </ol>
        </section>
      </section>

      <section anchor="exp_test_setup" numbered="true" toc="default">
        <name>An Experimental Test Setup</name>
        <t>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 <xref target="fig_native_icn_deployment_lab_setup" format="default"/>.
        </t>
        <figure anchor="fig_native_icn_deployment_lab_setup">
          <name>Native ICN Deployment Lab Setup</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
 +------------------------------------------+
 | +-----+   +------+   (```).     +------+ |   (````).    +-----+
 | | SUB |-->| EMU  |--(x-haul'.-->| EPC  |--->(  PDN ).-->| CDN |
 | +-----+   +------+   `__..''    +------+ |   `__...'    +-----+
 +------------------------------------------+
               4G Mobile Network Functions
                    ]]></artwork>
        </figure>

	<t>The following test scenarios can be set up with VM-based deployment: deployment based on Virtual Machine (VM):
        </t>
        <ol spacing="normal" type="1"><li>SUB: ICN simulated

	<ol>
	  <li>SUB: An ICN-simulated client (using ndnSIM), ndnSIM) - a client application on a workstation requesting content.</li> content.
	  </li>

	  <li>EMU: test Test unit emulating an eNodeB. This will be is a test node allowing for UE
	  attachment and routing traffic subsequently from the Subscriber to
	  the Publisher.</li> Publisher.
	  </li>
	  <li>EPC: Evolved Packet Core in a single instance (such as 5GOpenCore Open5GCore <xref target="Open5GCore" format="default"/>).</li> format="default"/>).
	  </li>
	  <li>CDN: content Content delivery by a Publisher server.</li> server.
	  </li>
</ol>

<t>For the purpose of this testing, ICN emulating 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. Effect 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.
        </t>
        <t>Another option is to simulate the UE/eNodeB and EPC functions using NS3's LTE <xref target="NS3LTE" format="default"/> and EPC <xref target="NS3EPC" format="default"/> models 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 SGW, PGW Mobile Gateways (SGW/PGW), and MME nodes, nodes and partially within the eNodeB nodes.
        </t>
        <t>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 user-plane traffic should be tested independently according to the deployment model discussed in <xref target="icn_deployment_in_4g_user_plane" format="default"/>.
        </t>
      </section>
    </section>
    <section anchor="expected_experiment_outcome" numbered="true" toc="default">
      <name>Expected Outcomes from Experimentation</name>
      <t>The experimentations experimentation explained in <xref target="icn_deploy_4g_networks" format="default"/> can be categorized in three broader scopes as follows. Note that, a that further research and study is required to fully understand and document the impact.
      </t>
      <ol spacing="normal" type="1"><li>Architecture
      <dl>
	<dt>Architecture scope: to
	</dt>
	<dd>to study the aspect of use of ICN at the user
	plane to reduce the complexities in current transport protocols, protocols while
	also evaluating its use in the control plane.</li>
        <li>Performance plane.
	</dd>

		<dt>Performance scope: to
	</dt>
	<dd>to evaluate the gains through multicast, caching, and other
ICN features.</li>
        <li>Deployment features.
	</dd>

		<dt>Deployment scope: to
	</dt>
	<dd>to check the viability of the ICN inclusion in the 3GPP protocol
stack and its viability in real-world deployments.</li>
      </ol> deployments.
	</dd>
</dl>

      <section anchor="feeding_into_icn_research" numbered="true" toc="default">
        <name>Feeding into ICN Research</name>
        <t>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:
        </t>
        <ol spacing="normal" type="1"><li>Efficiency type="1">
	  <li>Efficiency gains in terms of the amount of traffic in multicast scenarios (i.e., quantify the possible gains along different use cases) and the efficiency gained in terms of latency for cached content, mainly in the CDN use case.</li>
          <li>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.).</li>
          <li>To what extent the simplification in the IP-based transport protocols will be achieved. The multiple overlays (e.g., the MPLS, VPN, VPLS, 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.</li>
          <li>How the new transport can become service-aware service aware such that it brings in more simplicity in the system.</li>

          <li>Confirm how (in)adequate would be ICN implementation would be in the control plane (which this draft document discourages). Given that the 5G system, as specified in <xref target="TS23.501" format="default"/> (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.</li>
        </ol>
      </section>
      <section anchor="beyond_research" numbered="true" toc="default">
        <name>Use of Results Beyond Research</name>
        <t>With the experiments and their outcomes outlined in this draft, document, we believe that this technology is ready for a wider use and adoption, providing additional insights. Specifically, we expect to study the following:
        </t>
        <ol spacing="normal" type="1"><li>Viability of ICN inclusion in the 3GPP protocol stack, i.e., investigate investigating how realistic it would be to modify the stack, considering the scenarios explained in <xref target="icn_deployment_in_4g_user_plane" format="default"/>, and complete completing the user session without feature degradation?</li> degradation.</li>
          <li>Viability of utilizing solutions in greenfield deployments, i.e., deploying the ICN-based extensions and solutions proposed in this draft document in greenfield 4G deployments in order to assess real-world benefits when doing so.</li>
        </ol>
      </section>
    </section>

    <section numbered="true">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.
      </t>
    </section>

    <section anchor="security_privacy_considerations" numbered="true" toc="default">
      <name>Security and Privacy Considerations</name>
      <t>This section will cover some security and privacy considerations in mobile and 4G network networks because of the introduction of ICN.</t>
      <section anchor="security_considerations" numbered="true" toc="default">
        <name>Security Considerations</name>

        <t>To ensure only authenticated mobile terminals are connected to the network, 4G mobile network implements networks implement various security mechanisms. From the perspective of using ICN in the user plane, it needs to take care of the following security aspects: aspects need to be taken care of:
        </t>
        <ol spacing="normal" type="1"><li>MT authentication and authorization</li>
          <li>Radio or air interface security</li>
          <li>Denial of service
          <li>Denial-of-service attacks on the mobile gateway, Mobile Gateway; services are either by the MT or by external entities in the Internet</li>
          <li>Content poisoning either in either transport or servers</li>
          <li>Content cache pollution attacks</li>
          <li>Secure naming, routing, and forwarding</li>
          <li>Application security</li>
        </ol>
        <t>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 USIM 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 protections protection messages are given in the 3GPP call flow <xref target="TS23.401" format="default"/>. With ICN 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. Mobile Gateways, e.g., MME, using the control plane, therefore plane; therefore, there is no adverse impact of ICN on MT.
        </t>
        <t>4G uses IP transport in its mobile backhaul (between an eNodeB and the core network). In case of provider-owned backhaul, service provider the Service Provider may require implementing a security mechanism in the backhaul network. The native IP transport continues to leverage security mechanism mechanisms such as Internet key exchange Key Exchange (IKE) and the IP security protocol (IPsec). Security (IPsec) protocol. More details of mobile backhaul security are provided in 3GPP network security specifications <xref target="TS33.310" format="default"/> and <xref target="TS33.320" format="default"/>. 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 <xref target="RFC7476" format="default"/> and <xref target="RFC7927" format="default"/>.
        </t>
        <t>4G mobile gateways (SGW, PGW) Mobile Gateways (SGW/PGW) perform some of key functions such as content based content-based online/offline billing and accounting, deep packet inspection (DPI), and lawful interception (LI). When ICN is deployed in the user plane , plane, we need to integrate ICN security for sessions between MT and the gateway. If we encrypt user plane user-plane payload metadata 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 charging, and accounting. </t>
      </section>
      <section anchor="privacyconsiderations" numbered="true" toc="default">
        <name>Privacy Considerations</name>
        <t>In 4G networks, there are two main privacy issues are <xref target="MUTHANA" format="default"/> format="default"/>:
        </t>

        <ol spacing="normal" type="1"><li>User Identity Privacy Issues. The main privacy issue within the 4G is the exposure of the IMSI. International Mobile Subscriber Identity (IMSI). The IMSI can be intercepted by adversaries. Such attacks are commonly referred to as "IMSI catching".</li>

          <li>Location Privacy Issues. IMSI Catching 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 breaches breach the user's location privacy.</li>
        </ol>
        <t>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 topology, and timing of the requests <xref target="RFC7945" format="default"/>. Privacy concerns are amplified by the introduction of new network functions such as Information information lookup and Network network storage, and different forms of communication <xref target="FOTIOU" format="default"/>. Privacy risks in ICN can be broadly divided in the following categories <xref target="TOURANI" format="default"/>:
        </t>
        <ol spacing="normal" type="1"><li>Timing attack</li>
          <li>Communication monitoring attack</li>
          <li>Censorship and anonymity attack</li>
          <li>Protocol attack</li>
          <li>Naming-signature privacy</li>
        </ol>
        <t>Introduction
        <t>The introduction of TCL effectively enables ICN at the application and/or transport layer, layer depending on the scenario described in section 5. <xref target="icn_deploy_4g_networks"/>. 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.
        </t>

        <ol spacing="normal" type="1"><li>IPoIP <xref (<xref target="icn_deployment_scenarios" format="default"/> format="default"/>) would not be affected as TCL has no role in it it, and ICN does not apply</li>
          <li>ICNoICN apply.</li>

          <li>The ICNoICN scenario <xref (<xref target="icn_deployment_scenarios" format="default"/> format="default"/>) 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</li>
          <li>ICNoIP attack.</li>
          <li>The ICNoIP scenario <xref (<xref target="icn_deployment_scenarios" format="default"/> format="default"/>) 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</li>
          <li>IPoICN served.</li>
          <li>The IPoICN scenario <xref (<xref target="icn_deployment_scenarios" format="default"/> format="default"/>) could have potentially increased risk due to possible vulnerability of the forwarders in the path of ICN transport</li> transport.</li>
        </ol>

        <t>Privacy issues already identified in 4G remain a concern if ICN is introduced in any of the scenarios described earlier and compound compounds to the new, new ICN-related privacy issues. Many research papers have been published proposing that propose solutions to the privacy issues listed above. For LTE-specific privacy issues, some of the proposed solutions <xref target="MUTHANA" format="default"/> are IMSI encryption by a MT, an MT; mutual authentication, 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; IMSI replacement with a changing pseudonym that only the HSS server can map it to the UE's IMSI, 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 <xref target="FOTIOU" format="default"/>:
        </t>

        <ul spacing="normal">
          <li>Delay for the first, or first k k, interests on edge routers (timing attack)</li>
          <li>Creating a secure tunnel or clients flagging the requests as non-cacheable for privacy (communication monitoring attack)</li>
          <li>Encoding interest by mixing the content and cover file or using a hierarchical DNS-based brokering model (censorship and anonymity attack)</li>
          <li>Use of rate-limiting requests for a specific namespace (protocol attack)</li>
          <li>Cryptographic content hash-based naming or digital identity in an overlay network (naming-signature privacy)</li>
        </ul>
        <t>Further research in this area is needed. Detailed discussion of privacy is beyond the scope of this document.</t>
      </section>
    </section>
    <section anchor="summary" numbered="true" toc="default">
      <name>Summary</name>
      <t>In this draft, document, we have discussed the 4G networks and the experimental setups to study the advantages of the potential use of ICN for efficient delivery of contents to mobile terminals. We have discussed different options to try and test the ICN and dependencies such as ICN functionalities and changes required in different 4G network elements. In order to further explore potential use of ICN ICN, one can devise an experimental set-up setup consisting of 4G network elements and deploy ICN data transport in the user plane. Different options can be either overlay, dual transport (IP + ICN), hICN, or natively (by integrating ICN with CDN, eNodeB, SGW, PGW PGW, and a transport network). Note that, for the scenarios discussed above, additional study is required for lawful interception, billing/mediation, network slicing, and provisioning APIs.
      </t>
      <t>Edge Computing <xref target="CHENG" format="default"/> provides capabilities to deploy functionalities such as Content Delivery Network (CDN) CDN caching and mobile user plane functions (UPF) (UPFs) <xref target="TS23.501" format="default"/>. Recent research for delivering real-time video content <xref target="MPVCICN" format="default"/> using ICN has also been proven to be efficient <xref target="NDNRTC" format="default"/> and can be used towards realizing the benefits of using ICN in an eNodeB, edge computing, mobile gateways (SGW, PGW) Mobile Gateways (SGW/PGW), and CDN. The key aspect for ICN is in its seamless integration in 4G and 5G networks with tangible benefits so we can optimize content delivery using a simple and scalable architecture. The authors will continue to explore how ICN forwarding in edge computing could be used for efficient data delivery from the mobile edge.
      </t>
      <t>Based on our study of control plane signaling, it is not beneficial to deploy ICN with existing protocols unless further changes are introduced in the control protocol stack itself.</t>
      <t>As a starting step towards use of ICN in the user plane, it is proposed to incorporate protocol changes in MT, an eNodeB, and SGW/PGW for data transport. ICN has inherent capabilities for mobility and content caching, which can improve the efficiency of data transport for unicast and multicast delivery. The authors welcome contributions and suggestions, including those related to further validations of the principles by implementing prototype prototypes and/or proof of concept concepts in the lab and in the production environment.</t>
    </section>
    <section anchor="ack" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>We thank all contributors, reviewers, and the chairs for the valuable time in providing comments and feedback that helped improve this draft. We specially want to mention the following members of the IRTF Information-Centric Networking Research Group (ICNRG), listed in alphabetical order: Kashif Islam, Thomas Jagodits, Luca Muscariello, David R. Oran, Akbar Rahman, Martin J. Reed, Thomas C. Schmidt, and Randy Zhang.</t>
      <t>The IRSG review was provided by Colin Perkins.</t>
    </section>
    <!--         <section anchor="iana" title="IANA Considerations">
            <t>This draft includes no request to IANA.</t>
        </section> -->

	</middle>
  <!-- Back section -->

	<back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <!--             <reference anchor="IPSEC1"
                    target="https://cway.cisco.com/tools/ipsec-overhead-calc/ipsec-overhead-calc.html">
                <front>
                    <title>Cisco IPSec overhead calculator tool</title>
                    <author initials="">
                    <organization></organization>
                    </author>
                    <date year=""/>
                </front>
            </reference> -->

            <reference anchor="TS25.323" target="http://www.3gpp.org/ftp/Specs/html-info/25323.htm"> target="https://www.3gpp.org/ftp/Specs/html-info/25323.htm">
          <front>
            <title>Packet Data Convergence Protocol (PDCP) specification</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date day="18" month="September" year="2002"/> month="April" year="2022"/>
          </front>
          <seriesInfo name="3GPP TS" value="25.323 3.10.0"/> 17.0.0"/>
        </reference>

        <reference anchor="TS24.008" target="http://www.3gpp.org/ftp/Specs/html-info/24008.htm"> target="https://www.3gpp.org/ftp/Specs/html-info/24008.htm">
          <front>
            <title>Mobile radio interface Layer 3 specification; Core network protocols; Stage 3</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date day="15" month="December" year="2005"/>
          </front>
          <seriesInfo name="3GPP TS" value="24.008 3.20.0"/>
        </reference>
        <!-- <reference anchor="TS23.214">
                <front>
                    <title>Architecture enhancements for control and user plane separation of EPC nodes</title>
                    <author>
                        <organization>3GPP</organization>
                    </author>
                    <date day="24"  month="June" year="2014"/> year="2022"/>
          </front>
          <seriesInfo name="3GPP TS" value="23.214 10.6.0"/>
                <format type="HTML" target="http://www.3gpp.org/ftp/Specs/html-info/23214.htm"/> value="24.008 17.7.0"/>
	  <refcontent></refcontent>
        </reference> -->

        <reference anchor="TS36.323" target="http://www.3gpp.org/ftp/Specs/html-info/36323.htm"> target="https://www.3gpp.org/ftp/Specs/html-info/36323.htm">
          <front>
            <title>Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date day="03" month="January" year="2013"/>  month="July" year="2022"/>
          </front>
          <seriesInfo name="3GPP TS" value="36.323 10.2.0"/> 17.1.0"/>
        </reference>

        <reference anchor="TS29.274" target="http://www.3gpp.org/ftp/Specs/html-info/29274.htm"> target="https://www.3gpp.org/ftp/Specs/html-info/29274.htm">
          <front>
            <title>3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunneling Tunnelling Protocol for Control plane (GTPv2-C); Stage 3</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date day="25" month="June" year="2013"/> year="2022"/>
          </front>
          <seriesInfo name="3GPP TS" value="29.274 10.11.0"/> 17.6.0"/>
        </reference>

        <reference anchor="TS29.281" target="http://www.3gpp.org/ftp/Specs/html-info/29281.htm"> target="https://www.3gpp.org/ftp/Specs/html-info/29281.htm">
          <front>
            <title>General Packet Radio System (GPRS) Tunneling Tunnelling Protocol User Plane (GTPv1-U)</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date day="26" month="September" year="2011"/> month="June" year="2022"/>
          </front>
          <seriesInfo name="3GPP TS" value="29.281 10.3.0"/> 17.3.0"/>
        </reference>
        <!--
            <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
                <front>
                    <title>
                        Key words for use in RFCs to Indicate Requirement Levels
                    </title>
                    <author initials="S." surname="Bradner" fullname="S. Bradner">
                        <organization/>
                    </author>
                    <date year="1997" month="March"/>
                    <abstract>
                        <t>
                            In many standards track documents several words are used to signify the
                            requirements in the specification. These words are often capitalized.
                            This document defines these words as they should be interpreted in IETF
                            documents. This document specifies an Internet Best Current Practices
                            for the Internet Community, and requests discussion and suggestions for
                            improvements.
                        </t>
                    </abstract>
                </front>
                <seriesInfo name="BCP" value="14"/>
                <seriesInfo name="RFC" value="2119"/>
                <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            </reference>
            -->

        </references>
      <references>
        <name>Informative References</name>
        <!-- Here we use entities that we defined at the beginning. -->
            <!--
            &RFC2629;
            &RFC3552;
            <reference anchor="IPSEC2" target="http://packetpushers.net/ipsec-bandwidth-overhead-using-aes/">
                <front>
                    <title>IPSec Bandwidth Overhead Using AES</title>
                    <author initials="" surname="Iveson" fullname="Steven Iveson">
                        <organization/>
                    </author>
                    <date day="7" month="October" year="2013"/>
                </front>
            </reference>
            -->

        <reference anchor="TS23.203" target="http://www.3gpp.org/ftp/Specs/html-info/23203.htm"> target="https://www.3gpp.org/ftp/Specs/html-info/23203.htm">
          <front>
            <title>Policy and charging control architecture</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date day="12" month="September" year="2013"/>  month="December" year="2021"/>
          </front>
          <seriesInfo name="3GPP TS" value="23.203 10.9.0"/> 17.2.0"/>
        </reference>

        <reference anchor="TS23.401" target="http://www.3gpp.org/ftp/Specs/html-info/23401.htm"> target="https://www.3gpp.org/ftp/Specs/html-info/23401.htm">
          <front>
            <title>General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date day="07" month="March" year="2013"/>  month="June" year="2022"/>
          </front>
          <seriesInfo name="3GPP TS" value="23.401 10.10.0"/> 17.5.0"/>
        </reference>

        <reference anchor="TS23.501" target="http://www.3gpp.org/ftp/Specs/html-info/23501.htm"> target="https://www.3gpp.org/ftp/Specs/html-info/23501.htm">
          <front>
            <title>System Architecture architecture for the 5G System</title> System (5GS)</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date day="15"  month="June" year="2018"/> year="2022"/>
          </front>
          <seriesInfo name="3GPP TS" value="23.501 15.2.0"/> 17.5.0"/>
        </reference>

	<reference anchor="TS23.714" target="http://www.3gpp.org/ftp/Specs/html-info/23714.htm"> target="https://www.3gpp.org/ftp/Specs/html-info/23714.htm">
          <front>
            <title>Technical Specification Group Services and System Aspects:
            <title>
Study on control Control Plane (CP) and user plane User Plane (UP) separation of EPC Evolved Packet Core (EPC) nodes</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date day="04"  month="June" year="2016"/>
          </front>
          <seriesInfo name="3GPP TS" value="23.714 0.2.2"/> 14.0.0"/>
        </reference>

        <reference anchor="TS29.060" target="http://www.3gpp.org/ftp/Specs/html-info/29060.htm"> target="https://www.3gpp.org/ftp/Specs/html-info/29060.htm">
          <front>
            <title>General Packet Radio Service (GPRS); GPRS Tunneling Protocol (GTP) across the Gn and Gp interface</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date day="24" month="March" year="2004"/>  month="June" year="2022"/>
          </front>
          <seriesInfo name="3GPP TS" value="29.060 3.19.0"/> 17.3.0"/>
        </reference>

        <reference anchor="TS29.336" target="https://www.3gpp.org/ftp/Specs/html-info/29336.htm">
          <front>
            <title>Home Subscriber Server (HSS) diameter interfaces for interworking with
                packet data networks and applications</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date  month="March" year="2022"/>
          </front>
          <seriesInfo name="3GPP TS" value="29.336 17.13.1"/>
        </reference>

        <reference anchor="TS33.310" target="http://www.3gpp.org/ftp/Specs/html-info/33310.htm"> target="https://www.3gpp.org/ftp/Specs/html-info/33310.htm">
          <front>
            <title>Network Domain Security (NDS); Authentication Framework (AF)</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date day="21" month="December" year="2012"/> month="June" year="2022"/>
          </front>
          <seriesInfo name="3GPP TS" value="33.310 10.7.0"/> 17.3.0"/>
        </reference>

<reference anchor="TS33.320" target="http://www.3gpp.org/ftp/Specs/html-info/33320.htm"> target="https://www.3gpp.org/ftp/Specs/html-info/33320.htm">
          <front>
            <title>Security of Home Node B (HNB) / Home evolved Node B (HeNB)</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date day="29" month="June" year="2012"/>  month="March" year="2022"/>
          </front>
          <seriesInfo name="3GPP TS" value="33.320 10.5.0"/>
        </reference>
        <!--
            <reference anchor="TS23.501" target="http://www.3gpp.org/ftp/Specs/html-info/23501.htm">
                <front>
                    <title>System architecture for the 5G System (5GS)</title>
                    <author>
                        <organization>3GPP</organization>
                    </author>
                    <date day="24" month="June" year="2021"/>
                </front>
                <seriesInfo name="3GPP TS" value="23.501 17.1.1"/>
                <format type="HTML" target="http://www.3gpp.org/ftp/Specs/html-info/23501.htm"/>
            </reference>
            -->

            <reference anchor="RFC7476" target="https://www.rfc-editor.org/info/rfc7476">
          <front>
            <title>Information-Centric Networking: Baseline Scenarios</title>
            <author initials="K." surname="Pentikousis" fullname="K. Pentikousis" role="editor">
              <organization/>
            </author>
            <author initials="B." surname="Ohlman" fullname="B. Ohlman">
              <organization/>
            </author>
            <author initials="D." surname="Corujo" fullname="D. Corujo">
              <organization/>
            </author>
            <author initials="G." surname="Boggia" fullname="G. Boggia">
              <organization/>
            </author>
            <author initials="G." surname="Tyson" fullname="G. Tyson">
              <organization/>
            </author>
            <author initials="E." surname="Davies" fullname="E. Davies">
              <organization/>
            </author>
            <author initials="A." surname="Molinaro" fullname="A. Molinaro">
              <organization/>
            </author>
            <author initials="S." surname="Eum" fullname="S. Eum">
              <organization/>
            </author>
            <date year="2015" month="March"/>
          </front>
          <seriesInfo name="RFC" value="7476"/>
          <seriesInfo name="DOI" value="10.17487/RFC7476"/>
        </reference>
        <reference anchor="RFC7927" target="https://www.rfc-editor.org/info/rfc7927">
          <front>
            <title>Information-Centric Networking (ICN) Research Challenges</title>
            <author initials="D." surname="Kutscher" fullname="D. Kutscher" role="editor">
              <organization/>
            </author>
            <author initials="S." surname="Eum" fullname="S. Eum">
              <organization/>
            </author>
            <author initials="K." surname="Pentikousis" fullname="K. Pentikousis">
              <organization/>
            </author>
            <author initials="I." surname="Psaras" fullname="I. Psaras">
              <organization/>
            </author>
            <author initials="D." surname="Corujo" fullname="D. Corujo">
              <organization/>
            </author>
            <author initials="D." surname="Saucez" fullname="D. Saucez">
              <organization/>
            </author>
            <author initials="T." surname="Schmidt" fullname="T. Schmidt">
              <organization/>
            </author>
            <author initials="M." surname="Waehlisch" fullname="M. Waehlisch">
              <organization/>
            </author>
            <date year="2016" month="July"/>
          </front>
          <seriesInfo name="RFC" value="7927"/>
          <seriesInfo name="DOI" value="10.17487/RFC7927"/>
        </reference>
        <reference anchor="RFC4594" target="https://www.rfc-editor.org/info/rfc4594">
          <front>
            <title>Configuration Guidelines for DiffServ Service Classes</title>
            <author initials="J." surname="Babiarz" fullname="J. Babiarz">
              <organization/>
            </author>
            <author initials="K." surname="Chan" fullname="K. Chan">
              <organization/>
            </author>
            <author initials="F." surname="Baker" fullname="F. Baker">
              <organization/>
            </author>
            <date year="2006" month="August"/>
          </front>
          <seriesInfo name="RFC" value="4594"/>
          <seriesInfo name="DOI" value="10.17487/RFC4594"/>
        </reference>
        <reference anchor="RFC6459" target="https://www.rfc-editor.org/info/rfc6459">
          <front>
            <title>IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)</title>
            <author initials="J." surname="Korhonen" fullname="J. Korhonen" role="editor">
              <organization/>
            </author>
            <author initials="J." surname="Soininen" fullname="J. Soininen">
              <organization/>
            </author>
            <author initials="B." surname="Patil" fullname="B. Patil">
              <organization/>
            </author>
            <author initials="T." surname="Savolainen" fullname="T. Savolainen">
              <organization/>
            </author>
            <author initials="G." surname="Bajko" fullname="G. Bajko">
              <organization/>
            </author>
            <author initials="K." surname="Iisakkila" fullname="K. Iisakkila">
              <organization/>
            </author>
            <date year="2012" month="January"/>
          </front>
          <seriesInfo name="RFC" value="6459"/>
          <seriesInfo name="DOI" value="10.17487/RFC6459"/> 17.0.0"/>
        </reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7476.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7927.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4594.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6459.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9139.xml"/>

        <reference anchor="GRAYSON" target="http://www.ciscopress.com/store/ip-design-for-mobile-networks-9781587058264"> target="https://www.ciscopress.com/store/ip-design-for-mobile-networks-9781587058264">
          <front>
            <title>
                        Cisco Press book "IP
            <title>IP Design for Mobile Networks" Networks
            </title>
            <author initials="M" surname="Grayson" fullname=""> fullname="Mark Grayson">
              <organization/>
            </author>
            <author initials="M" surname="Shatzkamer" fullname=""> fullname="Kevin Shatzkamer">
              <organization/>
            </author>
            <author initials="S" surname="Wainner" fullname=""> fullname="Scott Wainner">
              <organization/>
            </author>
            <date month="June" day="15" year="2009"/>
          </front>
          <seriesInfo name="Cisco Press" value="Networking
	  <refcontent>Cisco Press</refcontent>
	  <refcontent>Networking Technology series"/> series</refcontent>
<seriesInfo name="ISBN" value="1-58705-826-X"/>
        </reference>

        <reference anchor="BROWER" target="https://ieeexplore.ieee.org/document/4086687">
          <front>
            <title>
                        Integrating
            <title>Integrating Header Compression with IPsec
            </title> IPsec</title>
            <author initials="E" surname="Brower" fullname=""> fullname="Etzel Brower">
              <organization/>
            </author>
            <author initials="L" surname="Jeffress" fullname=""> fullname="LaTonya Jeffress">
              <organization/>
            </author>
            <author initials="J" surname="Pezeshki" fullname=""> fullname="Jonah Pezeshki">
              <organization/>
            </author>
            <author initials="R" surname="Jasani" fullname=""> fullname="Rohan Jasani">
              <organization/>
            </author>
            <author initials="E" surname="Ertekin" fullname=""> fullname="Emre Ertekin">
              <organization/>
            </author>
            <date month="October" day="23" year="2006"/>
          </front>
	  <seriesInfo name="MILCOM name="DOI" value="10.1109/MILCOM.2006.302503"/>
          <refcontent>MILCOM 2006 - 2006 IEEE Military Communications conference" value="IEEE Xplore DL, pp.1-6"/> conference, pp. 1-6</refcontent>
        </reference>

        <reference anchor="OLTEANU" target="http://dl.acm.org/citation.cfm?id=1817271.1817379"> target="https://dl.acm.org/doi/10.5555/1817271.1817379">
          <front>
            <title>
                        Fragmentation
            <title>Fragmentation and AES Encryption Overhead encryption overhead in Very High-speed Wireless very high-speed wireless LANs
            </title>
            <author initials="A" surname="Olteanu" fullname="Alina Olteanu">
              <organization/>
            </author>
            <author initials="P" surname="Xiao" fullname="Yang Xiao">
              <organization/>
            </author>
            <date month="June" day="14" year="2009"/>
          </front>
          <seriesInfo name="Proceedings
	  <refcontent>Proceedings of the 2009 IEEE International Conference on
Communications ICC'09," value="ACM DL, pp.575-579"/> ICC'09, pp. 575-579
	  </refcontent>
        </reference>

        <reference anchor="MECSPEC" target="https://www.etsi.org/deliver/etsi_gs/MEC/001_099/003/01.01.01_60/gs_MEC003v010101p.pdf">
          <front>
            <title>
                        Mobile Edge Computing (MEC); Framework and Reference Architecture
            </title>
            <author initials="" surname="" fullname="">
              <organization/>
            <author>
              <organization>ETSI
	      </organization>
            </author>
            <date month="March" day=""  year="2016"/>
          </front>
          <seriesInfo name="ETSI" value="European Telecommunication Standards Institute (ETSI)
	  <refcontent>ETSI GS MEC specification"/>
        </reference>
        <reference anchor="RFC8609" target="https://www.rfc-editor.org/info/rfc8609">
          <front>
            <title>
                        Content-Centric Networking (CCNx) Messages in TLV Format
            </title>
            <author initials="M." surname="Mosko" fullname="M. Mosko">
              <organization/>
            </author>
            <author initials="I." surname="Solis" fullname="I. Solis">
              <organization/>
            </author>
            <author initials="C." surname="Wood" fullname="C. Wood">
              <organization/>
            </author>
            <date year="2019" month="July"/>
            <abstract>
              <t>
                        Content-Centric Networking (CCNx) is a network protocol that uses a hierarchical name to forward requests and to match responses to requests. This document specifies the encoding of CCNx messages in a TLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification.
              </t>
              <t>
                        This document is a product of the Information Centric Networking research group (ICNRG). The document received wide review among ICNRG participants and has two full implementations currently in active use, which have informed the technical maturity of the protocol specification.
              </t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8609"/>
          <seriesInfo name="DOI" value="10.17487/RFC8609"/>
        </reference>
        <reference anchor="RFC8569" target="https://www.rfc-editor.org/info/rfc8569">
          <front>
            <title>Content-Centric Networking (CCNx) Semantics</title>
            <author initials="M." surname="Mosko" fullname="M. Mosko">
              <organization/>
            </author>
            <author initials="I." surname="Solis" fullname="I. Solis">
              <organization/>
            </author>
            <author initials="C." surname="Wood" fullname="C. Wood">
              <organization/>
            </author>
            <date year="2019" month="July"/>
            <abstract>
              <t>
                        This document describes the core concepts of the Content-Centric Networking (CCNx) architecture and presents a network protocol based on two messages: Interests and Content Objects. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding.
              </t>
              <t>
                        The protocol also uses a control message called an Interest Return, whereby one system can return an Interest message to the previous hop due to an error condition. This indicates to the previous hop that the current system will not respond to the Interest.
              </t>
              <t>
                        This document is a product of the Information-Centric Networking Research Group (ICNRG). The document received wide review among ICNRG participants. Two full implementations are in active use and have informed the technical maturity of the protocol specification.
              </t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8569"/>
          <seriesInfo name="DOI" value="10.17487/RFC8569"/>
        </reference>
        <reference anchor="RFC7945" target="https://www.rfc-editor.org/info/rfc7945">
          <front>
            <title>Information-Centric Networking: Evaluation and Security Considerations</title>
            <author initials="K." surname="Pentikousis" fullname="K. Pentikousis" role="editor">
              <organization/>
            </author>
            <author initials="B." surname="Ohlman" fullname="B. Ohlman">
              <organization/>
            </author>
            <author initials="E." surname="Davies" fullname="E. Davies">
              <organization/>
            </author>
            <author initials="S." surname="Spirou" fullname="S. Spirou">
              <organization/>
            </author>
            <author initials="G." surname="Boggia" fullname="G. Boggia">
              <organization/>
            </author>
            <date year="2016" month="September"/>
            <abstract>
              <t>This document presents a number of considerations regarding evaluating Information-Centric Networking (ICN) and sheds some light on the impact of ICN on network security. It also surveys the evaluation tools currently available to researchers in the ICN area and provides suggestions regarding methodology and metrics.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7945"/>
          <seriesInfo name="DOI" value="10.17487/RFC7945"/>
        </reference>
        <!--             <reference anchor="NDNPUB">
                <front>
                    <title>Named Data Networking</title>
                    <author initials="" surname="">
                    <organization>Cisco Systems</organization>
                    </author>
                    <date year="" />
                </front>
                <format type="HTML" target="http://named-data.net/publications/"/>
            </reference> --> 003</refcontent>
	  <refcontent>Version 1.1.1</refcontent>
        </reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8609.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8569.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7945.xml"/>

            <reference anchor="CCN" target="http://www.ccnx.org"> target="https://wiki.fd.io/index.php?title=Cicn&amp;oldid=10316">
          <front>
            <title>Content Centric Networking</title>
            <title>Cicn</title>
            <author initials="" surname="">
              <organization/>
              <organization>FD.io</organization>
            </author>
            <date year=""/> month="January" year="2020"/>
          </front>
            </reference>

<reference anchor="ICN5G" target="https://www.ietf.org/id/draft-irtf-icnrg-5gc-icn-04.txt"> anchor="ICN5G">
   <front>
            <title>
                        Enabling
      <title>Enabling ICN in 3GPP's 5G NextGen Core Architecture
            </title> Architecture</title>
      <author initials="R" initials="R." surname="Ravindran" fullname="Ravi Ravindran">
              <organization/>
         <organization>Corning Incorporated</organization>
      </author>
      <author initials="P" surname="suthar" initials="P." surname="Suthar" fullname="Prakash suthar">
              <organization/> Suthar">
         <organization>Cisco Systems</organization>
      </author>
      <author initials="D" initials="D." surname="Trossen" fullname="Dirk Trossen">
              <organization/>
         <organization>Huawei Technologies Duesseldorf GmbH</organization>
      </author>
      <author initials="G" initials="C." surname="Wang" fullname="Chonggang Wang">
         <organization>InterDigital Inc.</organization>
      </author>
      <author initials="G." surname="White" fullname="Greg White">
              <organization/>
         <organization>CableLabs</organization>
      </author>
      <date month="January" day="10" year="2021"/>
            <abstract>
              <t>
                            The proposed 3GPP's 5G core nextgen architecture (5GC) offers
                            flexibility to introduce new user and control plane function,
                            considering the support for network slicing functions, that allows
                            greater flexibility to handle heterogeneous devices and applications. In
                            this draft, we provide a short description of the proposed 5GC
                            architecture, followed by extensions to 5GC's control and user plane to
                            support packet data unit (PDU) sessions from information-centric
                            networks. The value of enabling ICN in 5GC is discussed using multiple
                            service scenarios in the context of mobile edge computing such as smart
                            mobility and VR use case, and to enable network services such as
                            seamless mobility for ICN sessions.
              </t>
            </abstract> year="2021" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ravi-icnrg-5gc-icn-04"/>
        </reference>
        <!--             <reference anchor="NDN">
                <front>
                    <title>SIGCOMM Named Data Networking</title>
                    <author surname="Lixia Z., Lan W. et al">
                        <organization></organization>
                    </author>
                    <date year=""/>
                </front> value="draft-irtf-icnrg-5gc-icn-04" />
</reference> -->

            <reference anchor="ALM" target="https://dl.acm.org/citation.cfm?id=2812601">
          <front>
            <title>
                        Anchor-Less
            <title>Anchor-Less Producer Mobility in ICN
            </title> ICN</title>
            <author initials="J" surname="Augé" fullname=""> fullname="Jordan Augé">
              <organization/>
            </author>
            <author initials="G" surname="Carofiglio" fullname=""> fullname="Giovanna Carofiglio">
              <organization/>
            </author>
            <author initials="G" surname="Grassi" fullname=""> fullname="Giulio Grassi">
              <organization/>
            </author>
            <author initials="L" surname="Muscariello" fullname=""> fullname="Luca Muscariello">
              <organization/>
            </author>
            <author initials="G" surname="Pau" fullname=""> fullname="Giovanni Pau">
              <organization/>
            </author>
            <author initials="X" surname="Zeng" fullname=""> fullname="Xuan Zeng">
              <organization/>
            </author>
            <date month="September" day="30" year="2013"/> year="2015"/>
          </front>
<seriesInfo name="Proceedings name="DOI" value="10.1145/2810156.2812601"/>
<refcontent>ACM-ICN '15: Proceedings of the 2Nd 2nd ACM Conference on Information-Centric Networking, ACM-ICN'15," value="ACM DL, pp.189-190"/>
        </reference>
        <!--            <reference anchor="VNIIDX">
                <front>
                    <title>Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2016-2021</title>
                    <author initials="" surname="">
                    <organization>Cisco Systems</organization>
                    </author>
                    <date year="" />
                </front>
                <format type="HTML" target="http://www.cisco.com/c/en/us/solutions/service-provider/visual-networking-index-vni/index.html"/> pp. 189-190</refcontent>
        </reference> -->

            <reference anchor="NDNRTC" target="https://doi.org/10.1587/transcom.2015AMI0002">
          <front>
            <title>
                        Real-time
                        Real-Time Streaming Data Delivery over Named Data Networking, Networking
            </title>
            <author initials="P" surname="Gusev" fullname=""> fullname="Peter Gusev">
              <organization/>
            </author>
            <author initials="Z" surname="Wang" fullname=""> fullname="Zhehao Wang">
              <organization/>
            </author>
            <author initials="J" surname="Burke" fullname=""> fullname="Jeff Burke">
              <organization/>
            </author>
            <author initials="L" surname="Zhang" fullname=""> fullname="Lixia Zhang">
              <organization/>
            </author>
            <author initials="T" surname="Yoneda" fullname=""> fullname="Takahiro Yonda">
              <organization/>
            </author>
            <author initials="R" surname="Ohnishi" fullname=""> fullname="Ryota Ohnishi">
              <organization/>
            </author>
            <author initials="E" surname="Muramoto" fullname=""> fullname="Eiichi Muramoto">
              <organization/>
            </author>
            <date month="May" day="1" year="2016"/>
          </front>
          <seriesInfo name="IEICE name="" value="10.5815/ijcnis.2017.01.07"/>
          <refcontent>IEICE Transactions on Communications" value="vol. Communications, Vol. E99.B, Issue 5, pp. 974-991"/> 974-991</refcontent>
        </reference>

        <reference anchor="CHENG" target="https://ieeexplore.ieee.org/document/7113228">
          <front>
            <title>
                        Information-centric
            <title>Information-centric network function virtualization over 5g mobile wireless networks
            </title>
            <author initials="C" surname="Liang" fullname=""> fullname="Chengchao Liang">
              <organization/>
            </author>
            <author initials="R" surname="Yu" fullname=""> fullname="F. Richard Yu">
              <organization/>
            </author>
            <author initials="X" surname="Zhang" fullname=""> fullname="Xi Zhang">
              <organization/>
            </author>
            <date month="June" day="1" year="2015"/>
          </front>
          <seriesInfo name="IEEE Network Journal" value="vol.
          <refcontent>IEEE Network, Vol. 29, number Issue 3, pp. 68-74"/> 68-74</refcontent>
        </reference>

        <reference anchor="NGMN" target="https://www.ngmn.org/wp-content/uploads/Publications/2015/150929_NGMN_P-SmallCells_Backhaul_for_LTE-Advanced_and_Small_Cells.pdf">
          <front>
            <title>
Backhaul Provisioning for LTE-Advanced and &amp; Small Cells
            </title>
            <author initials="J" surname="Robson" fullname=""> fullname="Julius Robson">
              <organization/>
            </author>
            <date month="October" day="20"  year="2015"/>
          </front>
          <seriesInfo name="Next
          <refcontent>Next Generation Mobile Networks, LTE-Advanced Networks</refcontent>
	  <refcontent>LTE-Advanced Transport Provisioning," value="V0.0.14"/> Provisioning</refcontent>
	  <refcontent>Version 0.0.14</refcontent>
        </reference>

        <reference anchor="IPoICN" target="https://ieeexplore.ieee.org/document/7194109">
          <front>
            <title>
                        IP
            <title>IP over ICN - The better IP?
            </title>
            <author initials="D" surname="Trossen" fullname=""> fullname="Dirk Trossen">
              <organization/>
            </author>
            <author initials="M J" initials="M. J." surname="Read" fullname=""> fullname="Martin J. Reed">
              <organization/>
            </author>
            <author initials="J" surname="Riihijarvi" fullname=""> fullname="Janne Riihijärvi">
              <organization/>
            </author>
            <author initials="M" surname="Georgiades" fullname=""> fullname="Michael Georgiades">
              <organization/>
            </author>
            <author initials="N" surname="Fotiou" fullname=""> fullname="Nikos Fotiou">
              <organization/>
            </author>
            <author initials="G" surname="Xylomenos" fullname=""> fullname="George Xylomenos">
              <organization/>
            </author>
            <date month="June" day="29" year="2015"/>
          </front>
          <seriesInfo name="2015
          <refcontent>2015 European Conference on Networks and Communications (EuCNC)" value="IEEE Xplore DL, (EuCNC), pp. 413-417"/> 413-417</refcontent>
	  <seriesInfo name="DOI" value="10.1109/EuCNC.2015.7194109"/>
        </reference>

        <reference anchor="HICN" target="https://www.ietf.org/id/draft-muscariello-intarea-hicn-04.txt"> anchor="HICN">
          <front>
            <title>Hybrid Information-Centric Networking</title>
            <author initials="L" surname="Muscariello" fullname="Luca Muscariello">
              <organization/>
            </author>
            <author initials="G" surname="Carofiglio" fullname="Giovanna Carofiglio">
              <organization/>
            </author>
            <author initials="J" surname="Auge" fullname="Jordan Auge">
              <organization/>
            </author>
            <author initials="M" surname="Papalini" fullname="Michele Papalini">
              <organization/>
            </author>
	    <date month="May" day="20" year="2020"/>
            <abstract>
              <t>
                            This documents describes the hybrid information-centric networking
                            (hICN) architecture for IPv6. The specifications describe a way to
                            implement information-networking functionalities into IPv6. The
                            objective is to use IPv6 without creating overlays with a new packet
                            format as an additional encapsulation. The intent of the present design
                            is to introduce some IPv6 routers in the network with additional packet
                            processing operations to implement ICN functions. Moreover, the current
                            design is tightly integrated into IPv6 to allow easy interconnection to
                            IPv6 networks with the additional design objective to exploit existing
                            IPv6 protocols as much as possible as they are, or extend them where
                            needed.
              </t>
            </abstract> year="2020" />
          </front>
          <seriesInfo name="Internet-Draft" value="draft-muscariello-intarea-hicn-04"/>
        </reference>

        <reference anchor="GALIS" target="http://www.ietf.org/internet-drafts/draft-galis-anima-autonomic-slice-networking-05.txt"> anchor="GALIS">
          <front>
            <title>Autonomic Slice Networking</title>
            <author initials="A" surname="Galis" fullname="A. Galis"> fullname="Alex Galis" role="editor">
              <organization/>
            </author>
            <author initials="K" surname="Makhijani" fullname="Kiran Makhijani">
              <organization/>
            </author>
            <author initials="D" surname="Yu" fullname="Delei Yu">
              <organization/>
            </author>
            <author initials="B" surname="Liu" fullname="Bing Liu">
              <organization/>
            </author>
	    <date month="September" day="26" year="2018"/>
            <abstract>
              <t>
                            This document describes the technical requirements and the related
                            reference model for the intercommunication and coordination among
                            devices in Autonomic Slicing Networking. The goal is to define how the
                            various elements in a network slicing context work and orchestrate
                            together, to describe their interfaces and relations. While the document
                            is written as generally as possible, the initial solutions are limited
                            to the chartered scope of the WG.
              </t>
            </abstract> year="2018" />
          </front>
          <seriesInfo name="Internet-Draft" value="draft-galis-anima-autonomic-slice-networking-05"/>
        </reference>

        <reference anchor="EPCCUPS" target="http://www.3gpp.org/news-events/3gpp-news/1882-cups"> target="https://www.3gpp.org/news-events/3gpp-news/1882-cups">
          <front>
            <title>
                        Control
            <title>Control and User Plane Separation of EPC nodes (CUPS)
            </title> (CUPS)</title>
	    <author initials="P" surname="Schmitt" fullname=""> fullname="Peter Schmitt">
              <organization/>
            </author>
            <author initials="B" surname="Landais" fullname=""> fullname="Bruno Landais">
              <organization/>
            </author>
            <author initials="F" surname="Yong Yang" fullname=""> fullname="Frank Yong Yang">
              <organization/>
            </author>
            <date month="July" day="3" year="2017"/>
          </front>
          <seriesInfo name="3GPP" value="The
	  <refcontent>3GPP, The Mobile Broadband Standard"/> Standard</refcontent>
        </reference>

        <reference anchor="SDN5G" target="https://ieeexplore.ieee.org/document/7496561">
          <front>
            <title>
                        Software-defined networking for low-latency 5G core network
            </title>
            <author initials="J" surname="Page" fullname="Jérémy Pagé">
              <organization/>
            </author>
            <author initials="J" surname="Dricot" fullname="Jean-Michel Dricot">
              <organization/>
            </author>
            <date month="May" day="" year="2016"/>
          </front>
          <seriesInfo name="2016
	  <refcontent>2016 International Conference on Military Communications and
Information Systems (ICMCIS)" value="IEEE Xplore DL, (ICMCIS), pp. 1-7"/> 1-7
	  </refcontent>
<seriesInfo name="DOI" value="10.1109/ICMCIS.2016.7496561"/>
        </reference>

        <reference anchor="ICNQoS" target="https://ieeexplore.ieee.org/document/7037079">
          <front>
            <title>
                        Quality of Service service in an Information-Centric Network information-centric network
            </title>
            <author initials="M.F." surname="Al-Naday" fullname=""> fullname="Mays F. Al-Naday">
              <organization/>
            </author>
            <author initials="A" surname="Bontozoglou" fullname=""> fullname="Andreas Bontozoglou">
              <organization/>
            </author>
            <author initials="G" surname="Vassilakis" fullname=""> fullname="Vassilios G. Vassilakis">
              <organization/>
            </author>
            <author initials="M. J." surname="Reed" fullname=""> fullname="Martin J. Reed">
              <organization/>
            </author>
            <date month="December" day="8" year="2014"/>
          </front>
          <seriesInfo name="2014
          <refcontent>2014 IEEE Global Communications Conference" value="IEEE Xplore DL, Conference, pp. 1861-1866"/> 1861-1866</refcontent>
	  <seriesInfo name="DOI" value="10.1109/GLOCOM.2014.7037079"/>
        </reference>

        <reference anchor="OFFLOAD" target="https://ieeexplore.ieee.org/document/6953022">
          <front>
            <title>
                        Data
            <title>Data Offloading Techniques in Cellular Networks: A Survey
            </title>
            <author initials="F" surname="Rebecchi" fullname=""> fullname="Filippo Rebecchi">
              <organization/>
            </author>
            <author initials="M" surname="Dias de Amorim" fullname=""> fullname="Marcelo Dias de Amorim">
              <organization/>
            </author>
            <author initials="V" surname="Conan" fullname=""> fullname="Vania Conan">
              <organization/>
            </author>
            <author initials="A" surname="Passarella" fullname=""> fullname="Andrea Passarella">
              <organization/>
            </author>
            <author initials="R" surname="Bruno" fullname=""> fullname="Raffaele Bruno">
              <organization/>
            </author>
            <author initials="M" surname="Conti" fullname=""> fullname="Marco Conti">
              <organization/>
            </author>
            <date month="November" day="11" year="2014"/>
          </front>
	  <seriesInfo name="IEEE name="DOI" value="10.1109/COMST.2014.2369742"/>
	  <refcontent>IEEE Communications Surveys and Tutorials," value="IEEE Xplore DL, vol:17, issue:2, pp.580-603"/>
        </reference>
        <!--
            <reference anchor="NS3LTE"
                target="https://www.nsnam.org/docs/models/html/lte-design.html#lte-model">
                <front>
                    <title>
                        The ns-3 LTE module
                    </title>
                    <author initials="N" surname="Baldo" fullname="">
                        <organization/>
                    </author>
                    <date month="" day="" year=""/>
                </front>
                <seriesInfo name="" value="NS3 LTE Model"/>
                <format type="HTML" target="https://www.nsnam.org/docs/models/html/lte-design.html#lte-model"/>
                <format type="PDF" target="https://www.nsnam.org/tutorials/consortium13/lte-tutorial.pdf"/>
            </reference>

            <reference anchor="NS3EPC"
                target="https://www.nsnam.org/docs/models/html/lte-design.html#epc-model">
                <front>
                    <title>
                        The ns-3 EPC module
                    </title>
                    <author initials="N" surname="Baldo" fullname="">
                        <organization/>
                    </author>
                    <date month="" day="" year=""/>
                </front>
                <seriesInfo name="" value="NS3 EPC Model"/>
                <format type="HTML" target="https://www.nsnam.org/docs/models/html/lte-design.html#epc-model"/>
                <format type="PDF" target="https://www.nsnam.org/tutorials/consortium13/lte-tutorial.pdf"/> Tutorials
	  </refcontent>
          <refcontent>Vol. 17, Issue 2, pp.580-603</refcontent>
        </reference>
            -->

            <reference anchor="MBICN" target="https://ieeexplore.ieee.org/document/7114719">
          <front>
            <title>
                        Scalable mobile backhauling via information-centric networking
            </title>
            <author initials="G" surname="Carofiglio" fullname=""> fullname="Giovanna Carofiglio">
              <organization/>
            </author>
            <author initials="M" surname="Gallo" fullname=""> fullname="Massimo Gallo">
              <organization/>
            </author>
            <author initials="L" surname="Muscariello" fullname=""> fullname="Luca Muscariello">
              <organization/>
            </author>
            <author initials="D" surname="Perino" fullname=""> fullname="Diego Perino">
              <organization/>
            </author>
            <date month="April" day="22" year="2015"/>
          </front>
          <seriesInfo name="The
          <refcontent>The 21st IEEE International Workshop on Local and Metropolitan Area Networks," value="Beijing, Networks, Beijing, pp. 1-6"/> 1-6</refcontent>
	  <seriesInfo name="DOI" value="10.1109/LANMAN.2015.7114719"/>
        </reference>

        <reference anchor="MPVCICN" target="https://ieeexplore.ieee.org/document/7169810">
          <front>
            <title>
                        Realtime multi-party video conferencing service over information centric network
            </title>
            <author initials="A" surname="Jangam" fullname=""> fullname="Anil Jangam">
              <organization/>
            </author>
            <author initials="R" surname="Ravindran" fullname=""> fullname="Ravishankar Ravindran">
              <organization/>
            </author>
            <author initials="A" surname="Chakraborti" fullname=""> fullname="Asit Chakraborti">
              <organization/>
            </author>
            <author initials="X" surname="Wan" fullname=""> fullname="Xili Wan">
              <organization/>
            </author>
            <author initials="G" surname="Wang" fullname=""> fullname="Guoqiang Wang">
              <organization/>
            </author>
            <date month="June" day="29"  year="2015"/>
          </front>
	  <seriesInfo name="IEEE name="DOI" value="10.1109/ICMEW.2015.7169810"/>
          <refcontent>IEEE International Conference on Multimedia and Expo Workshops (ICMEW)" value="Turin, (ICMEW), Turin, Italy, pp. 1-6"/> 1-6</refcontent>
        </reference>

        <reference anchor="FOTIOU" target="https://dl.acm.org/doi/10.1145/2660129.2666711">
          <front>
            <title>
                        ICN
            <title>ICN privacy and name based security
            </title> security</title>
            <author initials="N" surname="Fotiou" fullname="Nikos Fotiou">
              <organization/>
            </author>
            <author initials="G" surname="Polyzos" fullname="George C. Polyzos">
              <organization/>
            </author>
            <date month="September" day="" year="2014"/>
          </front>
	  <seriesInfo name="ACM-ICN name="DOI" value="10.1145/2660129.2666711"/>
          <refcontent>ACM-ICN '14: Proceedings of the 1st ACM Conference on Information-Centric Networking" value="ACM Digitial Library, Networking, pp. 5-6"/> 5-6</refcontent>
        </reference>

        <reference anchor="TOURANI" target="https://ieeexplore.ieee.org/document/8027034">
          <front>
            <title>
                        Security, Privacy, and Access Control in Information-Centric Networking: A Survey
            </title>
            <author initials="R" surname="Tourani" fullname="Reza Tourani">
              <organization/>
            </author>
            <author initials="S" surname="Misra" fullname="Satyajayant Misra">
              <organization/>
            </author>
            <author initials="T" surname="Mick" fullname="Travis Mick">
              <organization/>
            </author>
            <author initials="G" surname="Panwar" fullname="Gaurav Panwar">
              <organization/>
            </author>
            <date month="September" day="" year="2017"/>
          </front>
	  <seriesInfo name="IEEE name="DOI" value="10.1109/COMST.2017.2749508"/>
          <refcontent>IEEE Communications Surveys and Tutorials" value="Volume Tutorials, Vol. 20, Issue 1, pp 566-600"/> pp. 566-600</refcontent>
        </reference>

        <reference anchor="TLVCOMP" target="https://datatracker.ietf.org/meeting/interim-2016-icnrg-02/materials/slides-interim-2016-icnrg-2-7">
          <front>
            <title>Header Compression for TLV-based Packets</title>
            <author initials="M" surname="Mosko" fullname=""> fullname="Marc Mosko">
              <organization/>
            </author>
            <date month="April" day="3" year="2016"/>
          </front>
          <seriesInfo name="ICNRG
          <refcontent>ICNRG, Buenos Aires" value="IETF 95"/>
        </reference>
        <reference anchor="ICNLOWPAN" target="https://www.ietf.org/id/draft-irtf-icnrg-icnlowpan-10.txt">
          <front>
            <title>ICN Adaptation to LowPAN Networks (ICN LoWPAN)</title>
            <author initials="C" surname="Gundogan" fullname="Cenk Gundogan">
              <organization/>
            </author>
            <author initials="T" surname="Schmidt" fullname="Thomas Schmidt">
              <organization/>
            </author>
            <author initials="M" surname="Waehlisch" fullname="Matthias Waehlisch">
              <organization/>
            </author>
            <author initials="C" surname="Scherb" fullname="Christopher Scherb">
              <organization/>
            </author>
            <author initials="C" surname="Marxer" fullname="Claudio Marxer">
              <organization/>
            </author>
            <author initials="C" surname="Tschudin" fullname="Christian Tschudin">
              <organization/>
            </author>
            <date month="February" day="10" year="2021"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-icnlowpan-10"/> Aires, IETF 95</refcontent>
        </reference>

        <reference anchor="I-D.anilj-icnrg-dnc-qos-icn" target="http://www.ietf.org/internet-drafts/draft-anilj-icnrg-dnc-qos-icn-02.txt"> anchor="QoS-ICN">
          <front>
            <title>QoS Treatments in ICN using Disaggregated Name Components</title>
            <author initials="A" surname="Jangam" fullname="Anil Jangam"> Jangam" role="editor">
              <organization/>
            </author>
            <author initials="P" surname="suthar" surname="Suthar" fullname="Prakash suthar"> Suthar">
              <organization/>
            </author>
            <author initials="M" surname="Stolic" fullname="Milan Stolic">
              <organization/>
            </author>
	    <date month="March" day="9" year="2020"/>
            <abstract>
              <t>Mechanisms for specifying and implementing end-to-end Quality of service (QoS) treatments in Information-Centric Networks (ICN) has not been explored so far. There has been some work towards implementing QoS in ICN; however, the discussions are mainly centered around strategies used in efficient forwarding of Interest packets. Moreover, as ICN has been tested mainly as an IP overlay, its QoS is still governed by the IP QoS framework and there is a need for implementing QoS in ICN natively. This document describes mechanisms to classify and provide associated "name-based" extensions to identify QoS within the framework of ICN's core design principles. The name-based design provides a mechanism to carry QoS information and implement the treatments as ICN packets travel across different routers in the ICN network. Detailed discussion is provided for QoS specific procedures in each of the ICN network elements i.e. consumer, producer, and forwarder.</t>
            </abstract> year="2020" />
          </front>
          <seriesInfo name="Internet-Draft" value="draft-anilj-icnrg-dnc-qos-icn-02"/>
        </reference>

        <reference anchor="MUTHANA" target="http://www.mecs-press.org/ijcnis/ijcnis-v9-n1/v9n1-7.html"> target="https://www.mecs-press.org/ijcnis/ijcnis-v9-n1/v9n1-7.html">
          <front>
            <title>
                        Analysis of User Identity Privacy in LTE and Proposed Solution
            </title>
            <author initials="A" surname="Muthana" fullname="Abdulrahman A. Muthana">
              <organization/>
            </author>
            <author initials="M" surname="Saeed" fullname="Mamoon M. Saeed">
              <organization/>
            </author>
            <date month="January" day="" year="2017"/>
          </front>
	  <seriesInfo name="International name="DOI" value="10.5815/ijcnis.2017.01.07"/>
          <refcontent>International Journal of Computer Network and Information Security(IJCNIS)" value="MECS Press, Security(IJCNIS), Vol. 9, Issue 1, pp. 54-63"/> 54-63</refcontent>
        </reference>

        <reference anchor="EMBMS" target="https://ieeexplore.ieee.org/document/9105941">
          <front>
            <title>
                        Service-Less
            <title>Service-Less Video Multicast in 5G: Enablers and Challenges
            </title> Challenges</title>
            <author initials="K" surname="Zahoor" fullname="K. fullname="Kamran Zahoor">
              <organization/>
            </author>
            <author initials="K" surname="Bilal" fullname="K. fullname="Kashif Bilal">
              <organization/>
            </author>
            <author initials="A" surname="Erbad" fullname="A. fullname="Aiman Erbad">
              <organization/>
            </author>
            <author initials="A" surname="Mohamed" fullname="A. fullname="Amr Mohamed">
              <organization/>
            </author>
            <date month="May" day="" month="June" year="2020"/>
          </front>
<seriesInfo name="IEEE Network" value="vol. name="DOI" value="10.1109/MNET.001.1900435"/>
          <refcontent>IEEE Network, Vol. 34, no. Issue 3, pp. 270-276"/>
        </reference>
        <reference anchor="RFC9064" target="https://www.rfc-editor.org/info/rfc9064">
          <front>
            <title>Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols</title>
            <author initials="D." surname="Oran" fullname="D. Oran">
              <organization/>
            </author>
            <date year="2021" month="June"/>
            <abstract>
              <t>This is a position paper. It documents the author's personal views on how Quality of Service (QoS) capabilities ought to be accommodated in Information-Centric Networking (ICN) protocols like Content-Centric Networking (CCNx) or Named Data Networking (NDN), which employ flow-balanced Interest/Data exchanges and hop-by-hop forwarding state as their fundamental machinery. It argues that such protocols demand a substantially different approach to QoS from that taken in TCP/IP and proposes specific design patterns to achieve both classification and differentiated QoS treatment on both a flow and aggregate basis. It also considers the effect of caches in addition to memory, CPU, and link bandwidth as resources that should be subject to explicitly unfair resource allocation. The proposed methods are intended to operate purely at the network layer, providing the primitives needed to achieve transport- and higher-layer QoS objectives. It explicitly excludes any discussion of Quality of Experience (QoE), which can only be assessed and controlled at the application layer or above. </t>
              <t>This document is not a product of the IRTF Information-Centric Networking Research Group (ICNRG) but has been through formal Last Call and has the support of the participants in the research group for publication as an individual submission.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9064"/>
          <seriesInfo name="DOI" value="10.17487/RFC9064"/> 270-276</refcontent>
        </reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9064.xml"/>

        <reference anchor="NS3EPC" target="https://www.nsnam.org/docs/models/html/lte-design.html#epc-model">
          <front>
            <title>
                        The ns-3
            <title>The EPC module Model
            </title>
            <author initials="N" surname="Baldo" fullname="">
              <organization/>
            <author><organization>ns-3
            </organization>
            </author>
	    <date month="" day="" year=""/> month="July" year="2022"/>
          </front>
          <seriesInfo name="" value="NS3 EPC Model"/>
          <format type="PDF" target="https://www.nsnam.org/tutorials/consortium13/lte-tutorial.pdf"/>
        </reference>

        <reference anchor="NS3LTE" target="https://www.nsnam.org/docs/models/html/lte-design.html#lte-model">
          <front>
            <title>
                        The ns-3
            <title>The LTE module Model
            </title>
            <author initials="N" surname="Baldo" fullname="">
              <organization/>
            <author><organization>ns-3
            </organization>
            </author>
	   <date month="" day="" year=""/> month="July" year="2022"/>
          </front>
          <seriesInfo name="" value="NS3 LTE Model"/>
          <format type="PDF" target="https://www.nsnam.org/tutorials/consortium13/lte-tutorial.pdf"/>
          </reference>

        <reference anchor="Open5GCore" target="https://www.open5gcore.org">
          <front>
            <title>
                        Open5GCore
            <title>Open5GCore - Fundamental 4G 5G Core Network Functionality for Research, Testbeds and Trials
            </title>
            <author initials="M" surname="Open5GCore" fullname="">
              <organization/>
            <author>
              <organization>Open5GCore
	      </organization>
            </author>
            <date month="" day="" year=""/>
          </front>
          <seriesInfo name="" value="Open5GCore"/>
        </reference>
      </references>
    </references>
      <section anchor="ack" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>We thank all contributors, reviewers, and the chairs for their valuable time in providing comments and feedback that helped improve this document. We especially want to mention the following members of the IRTF Information-Centric Networking Research Group (ICNRG), listed in alphabetical order: <contact fullname="Kashif Islam"/>, <contact fullname="Thomas Jagodits"/>, <contact fullname="Luca Muscariello"/>, <contact fullname="David R. Oran"/>, <contact fullname="Akbar Rahman"/>, <contact fullname="Martin J. Reed"/>, <contact fullname="Thomas C. Schmidt"/>, and <contact fullname="Randy Zhang"/>.</t>
      <t>The IRSG review was provided by <contact fullname="Colin Perkins"/>.</t>
    </section>
  </back>
</rfc>