rfc9269.original.xml   rfc9269.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<!-- control the table of contents (ToC) -->
<!-- generate a ToC --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<?rfc toc="yes"?> -irtf-icnrg-icn-lte-4g-12" number="9269" submissionType="IRTF" category="info" c
<!-- the number of levels of subsections in ToC. default: 3 --> onsensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth
<?rfc tocdepth="4"?> ="4" symRefs="true" sortRefs="true" version="3">
<!-- control references -->
<?rfc symrefs="yes"?> <front>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] --> <title abbrev="Scenarios of ICN Integration in 4G">Experimental Scenarios of
<?rfc sortrefs="yes" ?> Information-Centric Networking (ICN) Integration in 4G Mobile Networks</title>
<!-- do not start each main section on a new page --> <seriesInfo name="RFC" value="9269"/>
<?rfc compact="yes" ?> <author fullname="Prakash Suthar" initials="P" surname="Suthar">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="exp"
docName="draft-irtf-icnrg-icn-lte-4g-12" obsoletes="" updates="" submissionType
="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="tr
ue" 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 of ICN
Integration in 4G Mobile Networks</title>
<seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-icn-lte-4g-12"/>
<author fullname="Prakash Suthar" initials="" surname="Prakash Suthar">
<organization>Google Inc.</organization> <organization>Google Inc.</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city>Mountain View</city> <city>Mountain View</city>
<region>California</region> <region>California</region>
<code>94043</code> <code>94043</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>psuthar@google.com</email> <email>psuthar@google.com</email>
</address> </address>
</author> </author>
<author fullname="Milan Stolic" initials="" surname="Milan Stolic"> <author fullname="Milan Stolic" initials="M" surname="Stolic">
<organization>Cisco Systems Inc.</organization> <organization>Cisco Systems Inc.</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city>Naperville</city> <city>Naperville</city>
<region>Illinois</region> <region>Illinois</region>
<code>60540</code> <code>60540</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>mistolic@cisco.com</email> <email>mistolic@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Anil Jangam" initials="" surname="Anil Jangam" role="edito r"> <author fullname="Anil Jangam" initials="A" surname="Jangam" role="editor">
<organization>Cisco Systems Inc.</organization> <organization>Cisco Systems Inc.</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city>San Jose</city> <city>San Jose</city>
<region>California</region> <region>California</region>
<code>95134</code> <code>95134</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>anjangam@cisco.com</email> <email>anjangam@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Dirk Trossen" initials="" surname="Dirk Trossen"> <author fullname="Dirk Trossen" initials="D" surname="Trossen">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>Riesstrasse 25</street> <street>Riesstrasse 25</street>
<city/> <city/>
<city>Munich</city> <city>Munich</city>
<code>80992</code> <code>80992</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>dirk.trossen@huawei.com</email> <email>dirk.trossen@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Ravi Ravindran" initials="" surname="Ravi Ravindran"> <author fullname="Ravi Ravindran" initials="R" surname="Ravindran">
<organization>F5 Networks</organization> <organization>F5 Networks</organization>
<address> <address>
<postal> <postal>
<street>3545 North First Street</street> <street>3545 North First Street</street>
<city/> <city/>
<city>San Jose</city> <city>San Jose</city>
<region>California</region>
<code>95134</code> <code>95134</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>r.ravindran@f5.com</email> <email>r.ravindran@f5.com</email>
</address> </address>
</author> </author>
<date day="21" month="March" year="2022"/> <date month="August" year="2022"/>
<area>General</area> <workgroup>Information-Centric Networking</workgroup>
<workgroup>ICN Research Group</workgroup> <keyword>LTE</keyword>
<keyword/> <keyword>ICN</keyword>
<keyword>ICN-4G</keyword>
<keyword>ICNoIP</keyword>
<keyword>IPoICN</keyword>
<keyword>HybridICN</keyword>
<keyword>Dual Transport</keyword>
<abstract> <abstract>
<t>4G mobile network uses IP-based transport for the control plane to esta blish the data session at the user plane for the actual data delivery. In the ex isting architecture, IP-based unicast is used for the delivery of multimedia con tent to a mobile terminal, where each user is receiving a separate stream from t he server. From a bandwidth and routing perspective, this approach is inefficien t. Evolved multimedia broadcast and multicast service (eMBMS) provides capabilit ies for delivering contents to multiple users simultaneously, but its deployment is very limited or at an experimental stage due to numerous challenges. The foc us of this draft is to list the options for use of Information centric technolog y (ICN) in 4G mobile networks and elaborate the experimental setups for its furt her evaluation. The experimental setups discussed provide for using ICN either n atively or with existing mobility protocol stack. With further investigations ba sed on the listed experiments, ICN with its inherent capabilities such as, netwo rk-layer multicast, anchorless mobility, security, and optimized data delivery u sing local caching at the edge may provide a viable alternative to IP transport in 4G mobile networks.</t> <t>A 4G mobile network uses IP-based transport for the control plane to es tablish 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 c ontent to a mobile terminal, where each user is receiving a separate stream from the server. From a bandwidth and routing perspective, this approach is ineffici ent. Evolved multimedia broadcast and multicast service (eMBMS) provides capabil ities for delivering contents to multiple users simultaneously, but its deployme nt is very limited or at an experimental stage due to numerous challenges. The f ocus of this document is to list the options for using Information-Centric Netwo rking (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 i nvestigations based on the listed experiments, ICN with its inherent capabilitie s such as network-layer multicast, anchorless mobility, security, and optimized data delivery using local caching at the edge may provide a viable alternative t o IP transport in 4G mobile networks.</t>
</abstract> </abstract>
</front> </front>
<!-- Middle section -->
<middle> <middle>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>4G mobile technology is built as an all-IP network using routing protoc ols (OSPF, ISIS, BGP, etc.) to establish network routes. Stickiness of an IP add ress to a device is the key to get connected to a mobile network. The same IP ad dress is maintained through the session until the device gets detached or moves to another network. <t>4G mobile technology is built as an all-IP network using routing protoc ols (OSPF, IS-IS, BGP, etc.) to establish network routes. The stickiness of an I P address to a device is the key to getting connected to a mobile network. The s ame IP address is maintained through the session until the device gets detached or moves to another network.
</t> </t>
<t>Key protocols used in 4G networks are GPRS Tunneling protocol (GTP), DI AMETER, and other protocols that are built on top of IP. One of the biggest chal lenges with IP-based routing in 4G is that it is not optimized for data transpor t. As an alternative to IP routing, this draft presents and list the possible op tions for integration of Information Centric Networking (ICN) in 3GPP 4G mobile network, offering an opportunity to leverage inherent ICN capabilities such as i n-network caching, multicast, anchorless mobility management, and authentication . This draft also discuss how those options affect mobile providers and end user s. <t>Key protocols used in 4G networks are the General Packet Radio Service Tunneling 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 document pr esents and lists the possible options for integration of Information-Centric Net working (ICN) in 3GPP 4G mobile networks, offering an opportunity to leverage in herent ICN capabilities such as in-network caching, multicast, anchorless mobili ty management, and authentication. This document also discusses how those option s affect mobile providers and end users.
</t> </t>
<t>The goal of the proposed experiments is to present possibilities to cre ate simulated environments for evaluation of the benefits of ICN protocol deploy ment in a 4G mobile network in different scenarios that have been analyzed in th is document. <t>The goal of the proposed experiments is to present possibilities to cre ate simulated environments for evaluation of the benefits of ICN protocol deploy ment in a 4G mobile network in different scenarios that have been analyzed in th is document.
The consensus of the Information-Centric Networking Research Group (ICNRG) is to publish this document in order to facilitate experiments to show deployment opt ions and qualitative and quantitative benefits of ICN protocol deployment in 4G mobile networks. The consensus of the Information-Centric Networking Research Group (ICNRG) is to publish this document in order to facilitate experiments to show deployment opt ions and qualitative and quantitative benefits of ICN protocol deployment in 4G mobile networks.
</t> </t>
</section> </section>
<section anchor="terminology_concepts" numbered="true" toc="default"> <section anchor="terminology_concepts" numbered="true" toc="default">
<name>3GPP Terminology and Concepts</name> <name>3GPP Terminology and Concepts</name>
<ol spacing="normal" type="1"><li> <dl>
<t>Access Point Name </t>
<t>The Access Point Name (APN) is a Fully Qualified Domain Name (FQDN)
and resolves to a set of gateways in an operator's network. APN identifies the
packet data network (PDN) 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 se
rvice, QoS, and other logical entities inside GGSN, PGW.
</t>
</li>
<li>
<t>Control Plane </t>
<t> The control plane carries signaling traffic and is responsible for
routing between eNodeB and MME, MME and HSS, MME and SGW, SGW and PGW, etc. Con
trol plane signaling is required to authenticate and authorize the mobile termin
al and establish a mobility session with mobile gateways (SGW/PGW). Control plan
e functions also include system configuration and management.
</t>
</li>
<li>
<t>Dual Address PDN/PDP Type </t>
<t> The dual address Packet Data Network/Packet Data Protocol (PDN/PDP
) Type (IPv4v6) is used in 3GPP context, in many cases as a synonym for dual sta
ck, i.e., a connection type capable of serving IPv4 and IPv6 simultaneously.
</t>
</li>
<li>
<t>eNodeB </t>
<t> The eNodeB is a base station entity that supports the Long-Term Ev
olution (LTE) air interface.
</t>
</li>
<li>
<t>Evolved Packet Core </t>
<t> The Evolved Packet Core (EPC) is an evolution of the 3GPP GPRS sys
tem characterized by a higher-data-rate, lower-latency, packet-optimized system.
The EPC comprises some sub components of the EPS core such as Mobility Manageme
nt Entity (MME), Serving Gateway (SGW), Packet Data Network Gateway (PDN-GW), an
d Home Subscriber Server (HSS).
</t>
</li>
<li>
<t>Evolved Packet System </t>
<t> The Evolved Packet System (EPS) is an evolution of the 3GPP GPRS s
ystem characterized by a higher-data-rate, lower-latency, packet-optimized syste
m that supports multiple Radio Access Technologies (RATs). The EPS comprises the
EPC together with the Evolved Universal Terrestrial Radio Access (E-UTRA) and t
he Evolved Universal Terrestrial Radio Access Network (E-UTRAN).
</t>
</li>
<li>
<t>Evolved UTRAN </t>
<t> The E-UTRAN is a communications network sometimes referred to as 4
G, and consists of eNodeB (4G base stations). The E-UTRAN allows connectivity be
tween 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" fo
rmat="default"/> is a tunneling protocol defined by 3GPP. It is a network-based
mobility protocol, working similar to Proxy Mobile IPv6 (PMIPv6). However, GTP a
lso provides functionality beyond mobility, such as in-band signaling related to
QoS and charging, among others.
</t>
</li>
<li>
<t>Gateway GPRS Support Node </t>
<t> 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. Th
e host attaches to a GGSN identified by an APN assigned to it by an operator. Th
e GGSN also serves as the topological anchor for addresses/prefixes assigned to
the User Equipment.
</t>
</li>
<li>
<t>General Packet Radio Service </t>
<t> The General Packet Radio Service (GPRS) is a packet-oriented mobil
e data service available to users of the 2G and 3G cellular communication system
s--the GSM--specified by 3GPP.
</t>
</li>
<li>
<t>Home Subscriber Server </t>
<t> The Home Subscriber Server (HSS) is a database for a given subscri
ber and was introduced in 3GPP Release-5. It is the entity containing subscripti
on-related information to support the network entities that handle calls/session
s.
</t>
</li>
<li>
<t>Mobility Management Entity </t>
<t> The Mobility Management Entity (MME) is a network element responsi
ble for control plane functionalities, including authentication, authorization,
bearer management, layer-2 mobility, and so on. The MME is essentially the contr
ol plane part of the SGSN in the GPRS. The 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 s
ingle administration. A PLMN (and, therefore, also an operator) is identified by
the Mobile Country Code (MCC) and the Mobile Network Code (MNC). Each (telecomm
unications) operator providing mobile services has its own PLMN.
</t> <dt>Access Point Name:
</li> </dt>
<li> <dd>The Access Point Name (APN) is a Fully Qualified Domain Name
<t>Policy and Charging Control </t> (FQDN) and resolves to a set of gateways in an operator's network. An APN
<t> The Policy and Charging Control (PCC) framework is used for QoS po identifies the packet data network (PDN) with which a mobile data user
licy and charging control. It has two main functions: flow-based charging (inclu wants to communicate. In addition to identifying a PDN, an APN may
ding online credit control), and policy control (for example, gating control, Qo also be used to define the type of service, QoS, and other logical
S control, and QoS signaling). It is optional to 3GPP EPS but needed if dynamic entities inside a Gateway General Packet Radio Service Support Node (GGSN
policy and charging control by means of PCC rules based on user and services are ) or a Packet Data Network Gateway (PGW).
desired. </dd>
</t>
</li> <dt>Control Plane:
<li> </dt>
<t>Packet Data Network </t> <dd>The control plane carries signaling traffic and is responsible for
<t> The Packet Data Network (PDN) is a packet-based network that eithe routing between the eNodeB and the Mobile Management Entity (MME), the MME a
r belongs to the operator or is an external network such as the Internet or a co nd the Home Subscriber Server (HSS), the MME and the Mobile Gateways (SGW/PGW),
rporate intranet. The user eventually accesses services in one or more PDNs. The etc. Control plane signaling is required to authenticate and authorize
operator's packet core networks are separated from packet data networks either the mobile terminal and establish a mobility session with Mobile Gateways
by GGSNs or PDN Gateways (PGWs). (SGW/PGW). Control plane functions also include system
</t> configuration and management.
</li> </dd>
<li>
<t>Serving Gateway </t> <dt>Dual Address PDN/PDP Type:
<t> The Serving Gateway (SGW) is a gateway function in the EPS, which </dt>
terminates the interface towards the E-UTRAN. The SGW is the Mobility Anchor poi <dd>The dual address Packet Data Network / Packet Data Protocol
nt for layer-2 mobility (inter-eNodeB handovers). For each mobile terminal conne (PDN/PDP) Type (IPv4v6) is used in 3GPP context, in many cases as a
cted with the EPS, there is only one SGW at any given point in time. The SGW is synonym for dual stack, i.e., a connection type capable of serving
essentially the user plane part of the GPRS's SGSN. IPv4 and IPv6 simultaneously.
</t> </dd>
</li>
<li> <dt>eNodeB:
<t>Packet Data Network Gateway </t> </dt>
<t> The Packet Data Network Gateway (PGW) is a gateway function in the <dd>The eNodeB is a base station entity that supports the Long Term
Evolved Packet System (EPS), which provides connectivity to the Internet or oth Evolution (LTE) air interface.
er PDNs. The host attaches to a PGW identified by an APN assigned to it by an op </dd>
erator. The PGW also serves as the topological anchor for addresses/prefixes ass
igned to the User Equipment. <dt>Evolved Packet Core:
</t> </dt>
</li> <dd>The Evolved Packet Core (EPC) is an evolution of the 3GPP GPRS system
<li> characterized by a
<t>Packet Data Protocol Context </t> higher-data-rate, lower-latency, packet-optimized system. The EPC
<t> A Packet Data Protocol (PDP) context is the equivalent of a virtua comprises some subcomponents of the EPS core such as MME, Mobile Gateways
l connection between the mobile terminal (MT) and a PDN using a specific gateway (SGW/PGW), and HSS.
. </dd>
</t>
</li> <dt>Evolved Packet System:
<li> </dt>
<t>Packet Data Protocol Type </t> <dd>The Evolved Packet System (EPS) is an evolution of the 3GPP GPRS
<t> A Packet Data Protocol Type (PDP Type) identifies the used/allowed system characterized by a higher-data-rate, lower-latency,
protocols within the PDP context. Examples are IPv4, IPv6, and IPv4v6 (dual-sta packet-optimized system that supports multiple Radio Access
ck). Technologies (RATs). The EPS comprises the EPC together with Evolved
</t> Universal Terrestrial Radio Access (E-UTRA) and the Evolved Universal
</li> Terrestrial Radio Access Network (E-UTRAN).
<li> </dd>
<t>Serving GPRS Support Node </t>
<t> The Serving GPRS Support Node (SGSN) is a network element located <dt>Evolved UTRAN:
between the radio access network (RAN) and the gateway (GGSN). A per-MT point-to </dt>
-point (p2p) tunnel between the GGSN and SGSN transports the packets between the <dd>The Evolved UTRAN (E-UTRAN) is a communications network sometimes ref
mobile terminal and the gateway. erred to as
</t> 4G, and it consists of an eNodeB (4G base stations). The E-UTRAN allows
</li> connectivity between the User Equipment and the core network.
<li> </dd>
<t>Mobile Terminal/User Equipment </t>
<t> The terms User Equipment (UE), Mobile Station (MS), Mobile Node (M <dt>Gateway GPRS Support Node:
N), and mobile refer to the devices that are hosts with the ability to obtain In </dt>
ternet connectivity via a 3GPP network. An MS comprises the Terminal Equipment ( <dd>The Gateway GPRS Support Node (GGSN) is a gateway function in
TE) and a Mobile Terminal (MT). The terms MT, MS, MN, and mobile are used interc the GPRS and 3G network that provides connectivity to the
hangeably within this document. Internet or other PDNs. The host attaches to a GGSN identified
</t> by an APN that is assigned to it by an operator. The GGSN also serves
</li> as the topological anchor for addresses/prefixes assigned to the
<li> User Equipment.
<t>User Plane </t> </dd>
<t> 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 <dt>General Packet Radio Service:
user plane. </dt>
</t> <dd>The General Packet Radio Service (GPRS) is a packet-oriented mobile data
</li> service available to users of the 2G and 3G cellular communication
</ol> systems (the GSM) specified by 3GPP.
</section> </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:
</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.
It is the entity containing subscription-related information to support the netw
ork
entities that handle calls/sessions.
</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 mobility, and so on. The MME is essentially the control
plane part of the SGSN in the GPRS. The user-plane traffic bypasses the MME.
</dd>
<dt>Packet Data 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 by either GGSNs or PGWs.
</dd>
<dt>Packet Data Network Gateway:
</dt>
<dd>The Packet Data Network Gateway (PGW) is a gateway function in the EPS, whic
h 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.
</dd>
<dt> Packet Data Protocol 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.
</dd>
<dt>Packet Data Protocol 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).
</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:
</dt>
<dd>The Serving GPRS Support Node (SGSN) is a network element located between
the Radio Access Network (RAN) and the gateway (GGSN). A per-MT point-to-point
(P2P) tunnel between the GGSN and SGSN transports the packets between the
mobile terminal and the gateway.
</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 plan
e.
</dd>
</dl>
</section>
<section anchor="_4G_mobile_network_architecture" numbered="true" toc="defau lt"> <section anchor="_4G_mobile_network_architecture" numbered="true" toc="defau lt">
<name>4G Mobile Network Architecture</name> <name>4G Mobile Network Architecture</name>
<t>This section provide a high-level overview of typical 4G mobile network <t>This section provides a high-level overview of typical 4G mobile networ
architecture and their key functions related to a possibility of using of ICN t k architecture and the key functions related to the possibility of its use with
echnology.</t> ICN technology.</t>
<section anchor="network_overview" numbered="true" toc="default"> <section anchor="network_overview" numbered="true" toc="default">
<name>Network Overview</name> <name>Network Overview</name>
<t>4G mobile networks are designed to use IP transport for communication among different elements such as eNodeB, MME, SGW/PGW, HSS, PCRF, etc. <xref ta rget="GRAYSON" format="default"/>. For backward compatibility with 3G, it has su pport for legacy Circuit Switch features such as voice and SMS through transitio nal CS fallback and flexible IMS deployment. For each mobile device attached to the radio (eNodeB), there is a separate overlay tunnel (GPRS Tunneling Protocol, GTP) between eNodeB and Mobile gateways (i.e., SGW, PGW). <t>4G mobile networks are designed to use IP transport for communication among different elements such as the eNodeB, MME, SGW, PGW, HSS, Policy and Cha rging Rule Function (PCRF), etc.&nbsp;<xref target="GRAYSON" format="default"/>. For backward compatibility with 3G, it has support for legacy circuit switch fe atures such as voice and SMS through transitional CS fallback and flexible IP Mu ltimedia Subsystems (IMS) deployment. For each mobile device attached to the rad io (eNodeB), there is a separate overlay tunnel (GTP) between the eNodeB and Mob ile Gateways (i.e., SGW/PGW).
</t> </t>
<t>When any mobile terminal is powered up, it attaches to a mobile netwo
rk based on its configuration and subscription. After a successful attachment pr <t>When any mobile terminal is powered up, it attaches to a mobile netwo
ocedure, the mobile terminal registers with the mobile core network using IPv4 a rk based on its configuration and subscription. After a successful attachment pr
nd/or IPv6 address based on request and capabilities offered by mobile gateways. ocedure, the mobile terminal registers with the mobile core network using IPv4 a
</t> nd/or IPv6 addresses based on request and capabilities offered by Mobile Gateway
<t>The GTP tunnel is used to carry user traffic between gateways and mob s.</t>
ile terminal, therefore using the unicast delivery for any data transfer. It is <t>The GTP tunnel is used to carry user traffic between gateways and mob
also important to understand the overhead of GTP and IPSec protocols. All mobile ile terminals, therefore using the unicast delivery for any data transfer. It is
backhaul traffic is encapsulated using a GTP tunnel, which has overhead of 8 by also important to understand the overhead of GTP and IPsec protocols. All mobil
tes on top of IP and UDP <xref target="NGMN" format="default"/>. Additionally, i e backhaul traffic is encapsulated using a GTP tunnel, which has overhead of 8 b
f IPSec is used for security (which is often required if the Service Provider is ytes on top of IP and UDP <xref target="NGMN" format="default"/>. Additionally,
using a shared backhaul), it adds overhead based on the IPSec tunneling model ( if IPsec is used for security (which is often required if the Service Provider i
tunnel or transport) as well as the encryption and authentication header algorit s using a shared backhaul), it adds overhead based on the IPsec tunneling model
hm used. If we consider as an example an Advanced Encryption Standard (AES) encr (tunnel or transport) as well as the encryption and authentication header algori
yption, the overhead can be significant <xref target="OLTEANU" format="default"/ thm used. If we consider an Advanced Encryption Standard (AES) encryption as an
>, particularly for smaller payloads. example, the overhead can be significant <xref target="OLTEANU" format="default"
/>, particularly for smaller payloads.
</t> </t>
<figure anchor="fig_lte_4g_mobile_net_overview"> <figure anchor="fig_lte_4g_mobile_net_overview">
<name>4G Mobile Network Overview</name> <name>4G Mobile Network Overview</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+-------+ Diameter +-------+ +-------+ Diameter +-------+
| HSS |------------| SPR | | HSS |------------| SPR |
+-------+ +-------+ +-------+ +-------+
| | | |
+------+ +------+ S4 | +-------+ +------+ +------+ S4 | +-------+
| 3G |---| SGSN |----------------|------+ +------| PCRF | | 3G |---| SGSN |----------------|------+ +------| PCRF |
skipping to change at line 268 skipping to change at line 337
SGi IP traffic | | | SGi IP traffic | | |
+---------+ +---------+ +-----+ +---------+ +---------+ +-----+
| Trusted | |Untrusted| | CDN | | Trusted | |Untrusted| | CDN |
|non-3GPP | |non-3GPP | +-----+ |non-3GPP | |non-3GPP | +-----+
+---------+ +---------+ +---------+ +---------+
| | | |
+-+ +-+ +-+ +-+
| | | | | | | |
+-+ +-+ +-+ +-+
MT MT MT MT
]]></artwork> ]]></artwork>
</figure> </figure>
<t>If we consider the combined impact of GTP, IPSec and unicast traffic, the data delivery is not efficient because of overhead. The IETF has developed various header compression algorithms to reduce the overhead associated with IP packets. Some techniques are robust header compression (ROHC) and enhanced compr ession of the real-time transport protocol (ECRTP) so that the impact of overhea d created by GTP, IPsec, etc., is reduced to some extent <xref target="BROWER" f ormat="default"/>. For commercial mobile networks, 3GPP has adopted different me chanisms for header compression to achieve efficiency in data delivery <xref tar get="TS25.323" format="default"/>; those solutions can be adapted to other data protocols, such as ICN, too <xref target="ICNLOWPAN" format="default"/> <xref ta rget="TLVCOMP" format="default"/>. <t>If we consider the combined impact of GTP, IPsec, and unicast traffic , the data delivery is not efficient because of overhead. The IETF has developed various header compression algorithms to reduce the overhead associated with IP packets. Some techniques are RObust Header Compression (ROHC) and Enhanced Comp ression RTP (ECRTP) so that the impact of overhead created by GTP, IPsec, etc., is reduced to some extent <xref target="BROWER" format="default"/>. For commerci al 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 too such as ICN <xref target="RFC9139" format="default"/> <xref target="TLVCOMP" format="default"/>.
</t> </t>
</section> </section>
<section anchor="mobile_network_qos" numbered="true" toc="default"> <section anchor="mobile_network_qos" numbered="true" toc="default">
<name>Mobile Network Quality of Service</name> <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 eNodeB and Mobile Gat eway. Dedicated bearer can be requested either by mobile terminal or mobile gate way based on direction of first data flow. There are many bearers (logical paths ) established between eNodeB and mobile gateway for each mobile terminal caterin g to different data flow simultaneously. <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 Mobil e Gateway. A dedicated bearer can be requested by either a mobile terminal or a Mobile Gateway based on the direction of the first data flow. There are many bea rers (logical paths) established between an eNodeB and a Mobile Gateway for each mobile terminal catering to a different data flow simultaneously.
</t> </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 and user traffic, and ca n be very different depending on application key parameters such as latency, jit ter (important for voice and other real-time applications), packet loss, and que uing mechanism (strict priority, low-latency, fair, and so on). <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, and user traffic, and c an be very different depending on application key parameters such as latency, ji tter (important for voice and other real-time applications), packet loss, and qu euing mechanism (strict priority, low latency, fair, and so on).
</t> </t>
<t>Implementation of QoS for mobile networks is done at two stages: at c ontent prioritization/marking and transport marking, and congestion management. From the transport perspective, QoS is defined at layer 2 as class of service (C oS) and at layer 3 as Differentiated Services (DS). The mapping of DSCP to CoS t akes place at layer 2/3 switching and routing elements. 3GPP has a specified a Q oS Class Identifier (QCI), which represents different types of content and equiv alent mappings to the DSCP at transport layer <xref target="TS23.401" format="de fault"/>. However, this requires manual configuration at different elements and is therefore prone to possible misconfigurations. <t>Implementation of QoS for mobile networks is done at two stages: 1) c ontent prioritization/marking and transport marking and 2) congestion management . From the transport perspective, QoS is defined at Layer 2 as Class of Service (CoS) and at Layer 3 as Differentiated Services (DS). The mapping of the Differe ntiated Services Code Point (DSCP) to CoS takes place at Layer 2/3 switching and routing elements. 3GPP has a specified QoS Class Identifier (QCI), which repres ents different types of content and equivalent mappings to the DSCP at the trans port layer <xref target="TS23.401" format="default"/>. However, this requires ma nual configuration at different elements and is therefore prone to possible misc onfigurations.
</t> </t>
<t>In summary, QoS configuration in mobile networks for user plane traff ic requires synchronization of parameters among different platforms. Normally, Q oS 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 forw arding path can result in a poor subscriber experience (e.g., packet classified as high priority can go to a lower priority queue). By deploying ICN, we intend to enhance the subscriber experience using policy-based configuration, which can be associated with the named contents <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" format="default"/> can be implem ented with reference to the ICN QoS guidelines <xref target="RFC9064" format="de fault"/> to meet the QoS requirements <xref target="RFC4594" format="default"/>. <t>In summary, QoS configuration in mobile networks for user-plane traff ic requires synchronization of parameters among different platforms. Normally, Q oS 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 forw arding path can result in a poor subscriber experience (e.g., a packet classifie d as high priority can go to a lower-priority queue). By deploying ICN, we inten d to enhance the subscriber experience using policy-based configuration, which c an 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="QoS-ICN" format="default"/> can be implemented with referen ce to the ICN QoS guidelines <xref target="RFC9064" format="default"/> to meet t he QoS requirements <xref target="RFC4594" format="default"/>.
</t> </t>
</section> </section>
<section anchor="data_transport_using_ip" numbered="true" toc="default"> <section anchor="data_transport_using_ip" numbered="true" toc="default">
<name>Data Transport Using IP</name> <name>Data Transport Using IP</name>
<t>The data delivered to mobile devices is sent in unicast semantic insi de the GTP tunnel from an eNodeB to a PDN gateway (PGW), as described in 3GPP sp ecifications <xref target="TS23.401" format="default"/>. While the technology ex ists to address the issue of possible multicast delivery, there are many difficu lties related to multicast protocol implementations on the RAN side of the netwo rk. By using eMBMS <xref target="EMBMS" format="default"/>, multicast routing ca n be enabled in mobile backhaul between eNodeB and Mobile Gateways (SGW) however for radio interface it requires broadcast which implies that we need dedicated radio channel. Implementation of eMBMS in RAN is still lagging behind due to com plexities related to client mobility, handovers, and the fact that the potential gain to Service Providers may not justify the investment, which explains the pr evalence of unicast delivery in mobile networks. Techniques to handle multicast (such as LTE-B or eMBMS) have been designed to handle pre-planned content delive ry, such as live content, which contrasts user behavior today, largely based on content (or video) on demand model. <t>The data delivered to mobile devices is sent in unicast semantic insi de the GTP tunnel from an eNodeB to a PDN gateway (PGW) as described in 3GPP spe cifications <xref target="TS23.401" format="default"/>. While the technology exi sts to address the issue of possible multicast delivery, there are many difficul ties related to multicast protocol implementations on the RAN side of the networ k. By using eMBMS <xref target="EMBMS" format="default"/>, multicast routing can be enabled in mobile backhaul between an eNodeB and Mobile Gateways (SGW/PGW); however, for radio interface it requires broadcast, which implies that we need a dedicated radio channel. Implementation of eMBMS in RAN is still lagging behind due to complexities related to client mobility, handovers, and the fact that th e potential gain to Service Providers may not justify the investment, which expl ains 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 con tent delivery, such as live content, which contrasts user behavior today, largel y based on a content (or video) on-demand model.
</t> </t>
<t>To ease the burden on the bandwidth of the SGi interface, caching is introduced in a similar manner as with many Enterprises. In mobile networks, whe never possible, cached data is delivered. Caching servers are placed at a centra lized location, typically in the Service Provider's Data Center, or in some case s lightly distributed in Packet Core locations with the PGW nodes close to the I nternet and IP services access (SGi interface). This is a very inefficient conce pt because traffic must traverse the entire backhaul path for the data to be del ivered 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 applicat ion level. <t>To ease the burden on the bandwidth of the Service Gateway interface (SGi), caching is introduced in a similar manner as with many enterprises. In mo bile networks, whenever possible, cached data is delivered. Caching servers are placed at a centralized location, typically in the Service Provider's Data Cente r, or in some cases lightly distributed in packet core locations with the PGW no des close to the Internet and IP services access (SGi). This is a very inefficie nt concept because traffic must traverse the entire backhaul path for the data t o be delivered to the end user. Other issues, such as out-of-order delivery, con tribute to this complexity and inefficiency, which needs to be addressed at the application level.
</t> </t>
</section> </section>
<section anchor="virtualized_mobile_networks" numbered="true" toc="default "> <section anchor="virtualized_mobile_networks" numbered="true" toc="default ">
<name>Virtualized Mobile Networks</name> <name>Virtualized Mobile Networks</name>
<t>The Mobile gateways deployed in a major Service Provider network are <t>The Mobile Gateways deployed in a major Service Provider network are
either based on dedicated hardware or, commercially off the shelf (COTS) based x based on either dedicated hardware or commercial off-the-shelf (COTS) x86 techno
86 technology. With the adoption of Mobile Virtual Network Operators (MVNO), pub logy. With the adoption of Mobile Virtual Network Operators (MVNOs), public safe
lic safety networks, and enterprise mobility networks, elastic mobile core archi ty networks, and enterprise mobility networks, elastic mobile core architecture
tecture are needed. By deploying the mobile packet core on COTS platform, using is needed. By deploying the mobile packet core on a COTS platform, using a Netwo
a virtualized infrastructure (NFVI) framework and end-to-end orchestration, new rk Function Virtualization Infrastructure (NFVI) framework and end-to-end orches
deployments can be simplified to provide optimized total cost of ownership (TCO) tration, new deployments can be simplified to provide optimized total cost of ow
.</t> nership (TCO).</t>
<t>While virtualization is growing, and many mobile providers use a hybr <t>While virtualization is growing, and many mobile providers use a hybr
id architecture that consists of dedicated and virtualized infrastructures, the id architecture that consists of dedicated and virtualized infrastructures, the
control, and data planes are still the same. There is also work under way to sep control and data planes are still the same. There is also work underway to separ
arate the control and user plane for the network to scale better. Virtualized mo ate the control and user plane for the network to scale better. Virtualized mobi
bile networks and network slicing with control and user plane separation provide le networks and network slicing with control and user-plane separation provide a
a mechanism to evolve the GTP-based architecture towards an OpenFlow SDN-based mechanism to evolve the GTP-based architecture towards an OpenFlow with signali
signaling for 4G and proposed 5G core. Some early architecture work for 5G mobil ng based on Software-Defined Networking (SDN) for 4G and proposed 5G core. Some
e technologies provides a mechanism for control and user plane separation and si early architecture work for 5G mobile technologies provides a mechanism for cont
mplifies the mobility call flow by introducing OpenFlow-based signaling <xref ta rol and user-plane separation and simplifies the mobility call flow by introduci
rget="ICN5G" format="default"/>. This has been considered by 3GPP <xref target=" ng OpenFlow-based signaling <xref target="ICN5G" format="default"/>. This has be
EPCCUPS" format="default"/> and is also described in <xref target="SDN5G" format en considered by 3GPP <xref target="EPCCUPS" format="default"/> and is also desc
="default"/>. ribed in <xref target="SDN5G" format="default"/>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="data_transport_using_icn" numbered="true" toc="default"> <section anchor="data_transport_using_icn" numbered="true" toc="default">
<name>Data Transport Using ICN</name> <name>Data Transport Using ICN</name>
<t>For mobile devices, the edge connectivity is between mobile terminal an d 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, rather than sending all requests to the mobile gateway. <t>For mobile devices, the edge connectivity is between a mobile terminal and a router or mobile edge computing (MEC) <xref target="MECSPEC" format="defau lt"/> element. Edge computing has the capability of processing client requests a nd segregating control and user traffic at the edge of radio rather than sending all requests to the Mobile Gateway.
</t> </t>
<figure anchor="fig_icn_architecture"> <figure anchor="fig_icn_architecture">
<name>ICN Architecture</name> <name>ICN Architecture</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+----------+ +----------+
| Content +----------------------------------------+ | Content +----------------------------------------+
| Publisher| | | Publisher| |
+---+---+--+ | +---+---+--+ |
| | +--+ +--+ +--+ | | | +--+ +--+ +--+ |
| +--->|R1|------------>|R2|---------->|R4| | | +--->|R1|------------>|R2|---------->|R4| |
skipping to change at line 328 skipping to change at line 399
| # | | | # | |
| v v | | v v |
| +-+ +-+ | | +-+ +-+ |
+---------------| |-------------| |-------------+ +---------------| |-------------| |-------------+
+-+ +-+ +-+ +-+
Consumer-1 Consumer-2 Consumer-1 Consumer-2
Mobile Terminal Mobile Terminal Mobile Terminal Mobile Terminal
===> Content flow from cache ===> Content flow from cache
---> Content flow from publisher ---> Content flow from publisher
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Edge computing transforms radio access network into an intelligent serv ice edge capable of delivering services directly from the edge of the network, w hile providing the best possible performance to the client. Edge computing can b e an ideal candidate for implementing ICN forwarders in addition to its usual fu nction of managing mobile termination. In addition to edge computing, other tran sport elements, such as routers, can work as ICN forwarders. <t>Edge computing transforms a Radio Access Network into an intelligent se rvice edge capable of delivering services directly from the edge of the 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 f unction of managing mobile termination. In addition to edge computing, other tra nsport elements, such as routers, can work as ICN forwarders.
</t> </t>
<t>Data transport using ICN is different to IP-based transport by introduc
ing uniquely named-data as a core design principle. Communication in ICN takes p <t>Data transport using ICN is different than IP-based transport as it int
lace between the content provider (producer) and the end user (consumer), as des roduces uniquely named-data as a core design principle. Communication in ICN tak
cribed in <xref target="fig_icn_architecture" format="default"/>. es place between the content provider (producer) and the end user (consumer), as
described in <xref target="fig_icn_architecture" format="default"/>.
</t> </t>
<t>Every node in a physical path between a client and a content provider i s 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 o ther client. For mobile networks, transport between a client and a content provi der consists of radio network + mobile backhaul and IP core transport + Mobile G ateways + Internet + content data network (CDN). <t>Every node in a physical path between a client and a content provider i s 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 o ther client. For mobile networks, transport between a client and a content provi der consists of a radio network + mobile backhaul and IP core transport + Mobile Gateways + Internet + Content Delivery Network (CDN).
</t> </t>
<t>To understand the suitability of ICN for mobile networks, we will discu ss the ICN framework by describing its protocols architecture and different type s of messages to then consider how we can use this in mobile networks for delive ring content more efficiently. ICN uses two types of packets called "interest pa cket" and "data packet" as described in <xref target="fig_icn_interest_data_fwd" format="default"/>. <t>To understand the suitability of ICN for mobile networks, we will discu ss the ICN framework by describing its protocol architecture and different types of messages; this will be helpful when considering how to use ICN in mobile net works to deliver content more efficiently. ICN uses two types of packets called "interest packet" and "data packet" as described in <xref target="fig_icn_intere st_data_fwd" format="default"/>.
</t> </t>
<figure anchor="fig_icn_interest_data_fwd"> <figure anchor="fig_icn_interest_data_fwd">
<name>ICN Interest, Data Packet and Forwarder</name> <name>ICN Interest, Data Packet, and Forwarder</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+------------------------------------+ +------------------------------------+
Interest | +------+ +------+ +------+ | +-----+ Interest | +------+ +------+ +------+ | +-----+
+-+ ---->| CS |---->| PIT |---->| FIB |--------->| CDN | +-+ ---->| CS |---->| PIT |---->| FIB |--------->| CDN |
| | | +------+ +------+ +------+ | +-----+ | | | +------+ +------+ +------+ | +-----+
+-+ | | Add | Drop | | Forward +-+ | | Add | Drop | | Forward
MT <--------+ Intf v Nack v | MT <--------+ Intf v Nack v |
Data | | Data | |
+------------------------------------+ +------------------------------------+
skipping to change at line 359 skipping to change at line 430
+------------------------------------+ +------------------------------------+
+------------------------------------+ +------------------------------------+
+-+ | Forward +------+ | +-----+ +-+ | Forward +------+ | +-----+
| | <-------------------------------------| PIT |<---------| CDN | | | <-------------------------------------| PIT |<---------| CDN |
+-+ | | Cache +--+---+ | Data +-----+ +-+ | | Cache +--+---+ | Data +-----+
MT | +--v---+ | | MT | +--v---+ | |
| | CS | v | | | CS | v |
| +------+ Discard | | +------+ Discard |
+------------------------------------+ +------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>In an 4G network, when a mobile device wants to receive certain content , it will send an Interest message to the closest eNodeB. Interest packets follo w the TLV format <xref target="RFC8609" format="default"/> and contain mandatory fields, such as name of the content and content matching restrictions (KeyIdRes tr and ContentObjectHashRestr), expressed as a tuple <xref target="RFC8569" form at="default"/>. The content matching tuple uniquely identifies the matching data packet for the given Interest packet. Another attribute called HopLimit is used to detect looping Interest messages. <t>In 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 such as the name of the content and content-matching restrictions (KeyIdR estr and ContentObjectHashRestr) expressed as a tuple <xref target="RFC8569" for mat="default"/>. The content-matching tuple uniquely identifies the matching dat a packet for the given Interest packet. Another attribute called "HopLimit" is u sed to detect looping Interest messages.
</t> </t>
<t>An ICN router will receive an Interest packet and lookup if a request f or 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 r outer. Each ICN router maintains three data structures: Pending Interest Table ( PIT), Forwarding Information Base (FIB), and Content Store (CS). The Interest pa cket travels hop-by-hop towards the content provider. Once the Interest packet r eaches the content provider, it will return a Data packet containing information such as content name, signature, and the actual data. <t>An ICN router will receive an Interest packet and lookup if a request f or 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 r outer. Each ICN router maintains three data structures: Pending Interest Table ( PIT), Forwarding Information Base (FIB), and Content Store (CS). The Interest pa cket travels hop by hop towards the content provider. Once the Interest packet r eaches the content provider, it will return a data packet containing information such as content name, signature, and the actual data.
</t> </t>
<t>The data packet travels in reverse direction following the same path ta ken by the Interest packet, maintaining routing symmetry. Details about algorith ms used in PIT, FIB, CS, and security trust models are described in various reso urces <xref target="CCN" format="default"/>; here, we have explained the concept and its applicability to the 4G network. <t>The data packet travels in reverse direction following the same path ta ken by the Interest packet, maintaining routing symmetry. Details about algorith ms used in PIT, FIB, CS, and security trust models are described in various reso urces <xref target="CCN" format="default"/>; here, we have explained the concept and its applicability to the 4G network.
</t> </t>
</section> </section>
<section anchor="icn_deploy_4g_networks" numbered="true" toc="default"> <section anchor="icn_deploy_4g_networks" numbered="true" toc="default">
<name>Experimental Scenarios for ICN Deployment</name> <name>Experimental Scenarios for ICN Deployment</name>
<t>In 4G mobile networks, both user and control plane traffic have to be t ransported from the edge to the mobile packet core via IP transport. The evoluti on of the existing mobile packet core using Control and User Plane Separation (C UPS) <xref target="TS23.714" format="default"/> enables flexible network and ope rations by distributed deployment and the independent scaling of control plane a nd user plane functions - while not affecting the functionality of existing node s subject to this split. <t>In 4G mobile networks, both user and control plane traffic have to be t ransported from the edge to the mobile packet core via IP transport. The evoluti on of the existing mobile packet core using Control and User Plane Separation (C UPS) <xref target="TS23.714" format="default"/> enables flexible networking and operations by distributed deployment and the independent scaling of control plan e and user-plane functions while not affecting the functionality of existing nod es subject to this split.
</t> </t>
<t>In this section, we analyze the potential impact of ICN on control and <t>In this section, we analyze the potential impact of ICN on control and
user plane traffic for centralized and disaggregated CUPS-based mobile network a user-plane traffic for centralized and disaggregated CUPS-based mobile network a
rchitecture. We list various experimental options and opportunities to study the rchitecture. We list various experimental options and opportunities to study the
feasibility of the deployment of ICN in 4G networks. The proposed experiments w feasibility of the deployment of ICN in 4G networks.
ould help the network and OEM designers to understand various issues, optimizati The proposed experiments would help the network and original equipment man
ons, and advantages of deployment of ICN in 4G networks.</t> ufacturer (OEM) designers to understand various issues, optimizations, and advan
tages of the deployment of ICN in 4G networks.</t>
<section anchor="general_icn_considerations" numbered="true" toc="default" > <section anchor="general_icn_considerations" numbered="true" toc="default" >
<name>General Considerations</name> <name>General Considerations</name>
<t>In the CUPS architecture, there is an opportunity to shorten the path for user plane traffic by deploying offload nodes closer to the edge <xref targ et="OFFLOAD" format="default"/>. With this major architecture change, a User Pla ne 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 feasib le, 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, especia lly with latency-sensitive applications. This capability allows for the introduc tion of ICN and amplifies its advantages. <t>In the CUPS architecture, there is an opportunity to shorten the path for user-plane traffic by deploying offload nodes closer to the edge <xref targ et="OFFLOAD" format="default"/>. With this major architecture change, a User Pla ne 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 feasib le, 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, especia lly with latency-sensitive applications. This capability allows for the introduc tion of ICN and amplifies its advantages.
</t> </t>
</section> </section>
<section anchor="icn_deployment_scenarios" numbered="true" toc="default"> <section anchor="icn_deployment_scenarios" numbered="true" toc="default">
<name>Scenarios of ICN Integration</name> <name>Scenarios of ICN Integration</name>
<t>The integration of ICN provides an opportunity to further optimize th e existing data transport in 4G mobile networks. The various opportunities from the coexistence of ICN and IP transport in the mobile network are somewhat analo gous to the deployment scenarios when IPv6 was introduced to interoperate with I Pv4 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 p lane signaling and user plane data delivery. In general, ICN can be used nativel y by replacing IP transport (IPv4 and IPv6) or as an overlay protocol. <xref tar get="fig_icn_ip_convergence_deployments" format="default"/> describes a proposal to modify the existing transport protocol stack to support ICN in 4G mobile net work. <t>The integration of ICN provides an opportunity to further optimize th e existing data transport in 4G mobile networks. The various opportunities from the coexistence of ICN and IP transport in the mobile network are somewhat analo gous to the deployment scenarios when IPv6 was introduced to interoperate with I Pv4 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 p lane signaling and user-plane data delivery. In general, ICN can be used nativel y by replacing IP transport (IPv4 and IPv6) or as an overlay protocol. <xref tar get="fig_icn_ip_convergence_deployments" format="default"/> describes a proposal to modify the existing transport protocol stack to support ICN in a 4G mobile n etwork.
</t> </t>
<figure anchor="fig_icn_ip_convergence_deployments"> <figure anchor="fig_icn_ip_convergence_deployments">
<name>IP/ICN Convergence Scenarios</name> <name>IP/ICN Convergence Scenarios</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+----------------+ +-----------------+ +----------------+ +-----------------+
| ICN App (new) | |IP App (existing)| | ICN App (new) | |IP App (existing)|
+---------+------+ +-------+---------+ +---------+------+ +-------+---------+
| | | |
+---------+----------------+---------+ +---------+----------------+---------+
| Transport Convergence Layer (new) | | Transport Convergence Layer (new) |
skipping to change at line 404 skipping to change at line 476
| | | |
+------+------+ +------+-------+ +------+------+ +------+-------+
|ICN function | | IP function | |ICN function | | IP function |
| (New) | | (Existing) | | (New) | | (Existing) |
+------+------+ +------+-------+ +------+------+ +------+-------+
| | | |
(```). (```). (```). (```).
( ICN '`. ( IP '`. ( ICN '`. ( IP '`.
( Cloud ) ( Cloud ) ( Cloud ) ( Cloud )
` __..'+' ` __..'+' ` __..'+' ` __..'+'
]]></artwork>
]]></artwork>
</figure> </figure>
<t>As shown in <xref target="fig_icn_ip_convergence_deployments" format= "default"/>, for applications - running either in the mobile terminal or in the content provider system - to use the ICN transport option, we propose a new tran sport convergence layer (TCL). The TCL helps determine the type of transport (su ch as ICN or IP), as well as the type of radio interface (LTE or WiFi or both) u sed to send and receive traffic based on preference (e.g., content location, con tent type, content publisher, congestion, cost, QoS). It helps configure and det ermine 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>As shown in <xref target="fig_icn_ip_convergence_deployments" format= "default"/>, for applications (running either in the mobile terminal or in the c ontent provider system) to use the ICN transport option, we propose a new transp ort convergence layer (TCL). The TCL helps determine the type of transport (such as ICN or IP) as well as the type of radio interface (LTE, Wi-Fi, or both) used to send and receive traffic based on preference (e.g., content location, conten t type, content publisher, congestion, cost, or QoS). It helps configure and det ermine 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>
<t>Combined with the existing IP function, the ICN function provides sup
port for either native ICN and/or the dual transport (ICN/IP) transport function <t>Combined with the existing IP function, the ICN function provides sup
ality. See <xref target="dual_transport_icn_deploy_mt" format="default"/> for el port for native ICN and/or the dual transport (ICN/IP) functionality. See <xref
aborate descriptions of these functional layers. target="dual_transport_icn_deploy_mt" format="default"/> for elaborate descripti
ons of these functional layers.
</t> </t>
<t>The TCL can use several mechanisms for transport selection. It can us e a per-application configuration through a management interface, possibly a use r-facing setting realized through a user interface, like those used to select ce llular over WiFi. In another option, it might use a software API, which an adapt ed IP application could use to specify the type of transport option (such as ICN ) to take advantage of its benefits. <t>The TCL can use several mechanisms for transport selection. It can us e a per-application configuration through a management interface, possibly a use r-facing setting realized through a user interface, like those used to select ce llular over Wi-Fi. In another option, it might use a software API, which an adap ted IP application could use to specify the type of transport option (such as IC N) to take advantage of its benefits.
</t> </t>
<t>Another potential application of TCL is in implementation of network slicing, with a slice management capability locally or through an interface to a n external slice manager via an API <xref target="GALIS" format="default"/>. Thi s solution can enable network slicing for IP and ICN transport selection from th e mobile terminal itself. The TCL could apply slice settings to direct certain a pplications traffic over one slice and others over another slice, determined by some form of 'slicing policy'. Slicing policy can be obtained externally from th e slice manager or configured locally on the mobile terminal. <t>Another potential application of TCL is in an implementation of netwo rk slicing with a local slice management capability or through an interface to a n external slice manager via an API <xref target="GALIS" format="default"/>. Thi s solution can enable network slicing for IP and ICN transport selection from th e mobile terminal itself. The TCL could apply slice settings to direct certain a pplications traffic over one slice and others over another slice, determined by some form of a 'slicing policy'. The slicing policy can be obtained externally f rom the slice manager or configured locally on the mobile terminal.
</t> </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>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> </t>
<ol spacing="normal" type="1"><li>
<t>IP over IP
</t>
<t>
In this scenario, the mobile terminal applications a
re tightly integrated with the existing IP transport infrastructure. The TCL has
no additional function because packets are forwarded directly using an IP proto
col stack, which sends packets over the IP transport.
</t>
</li>
<li>
<t>ICN over ICN
</t>
<t>
Similar to case 1, ICN applications tightly integrat
e with the ICN transport infrastructure. The TCL has no additional responsibilit
y because packets are forwarded directly using the native ICN protocol stack, wh
ich sends packets over the ICN transport.
</t>
</li>
<li>
<t>ICN over IP (ICNoIP)
</t>
<t>
In this scenario, the underlying IP transport infras
tructure is not impacted (that is, ICN is implemented as an IP overlay between m
obile terminal and content provider). IP routing is used from the Radio Access N
etwork (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 p
ublisher uses IP. The content provider can serve content either using IP or ICN,
based on the mobile terminal request.
</t> <dl>
<t>
One of the approaches to implement ICN in mobile bac
khaul networks is described in <xref target="MBICN" format="default"/>. It imple
ments a 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 tun
nel can be terminated by hairpinning the packet before it reaches SGW, if an ICN
-enabled node is deployed in the mobile backhaul (that is, between eNodeB and SG
W). This could be useful when an ICN data packet is stored in the ICN node (such
as repositories, caches) in the tunnel path so that the ICN node can reply with
out going all the way through the mobile core. While a GTP-U extension header is
used to carry mobile terminal specific ICN payload, they are not visible to the
transport, including SGW. On the other hand, the PGW can use the mobile termina
l-specific ICN header extension and ICN payload to set up an uplink transport to
wards a content provider in the Internet. In addition, the design assumes a prox
y function at the edge, to perform ICN data retrieval on behalf of a non-ICN end
device.
</t>
</li>
<li>
<t>IP over ICN (IPoICN)
</t>
<t><xref target="IPoICN" format="default"/> provides an architectura
l framework for running IP as an overlay over ICN protocol. Implementing IP serv
ices over ICN provides an opportunity to leverage the benefits of ICN in the tra
nsport infrastructure while there is no impact on end devices (MT and access net
work) as they continue to use IP. IPoICN however, will require an inter-working
function (IWF/Border Gateway) to translate various transport primitives. The IWF
function will provide a mechanism for protocol translation between IPoICN and t
he native IP. After reviewing <xref target="IPoICN" format="default"/>, we under
stand and interpret that ICN is implemented in the transport natively, however,
IP is implemented in MT, eNodeB, and Mobile gateway (SGW/PGW), which is also cal
led as a network attach point (NAP).
</t> <dt>IP over IP (IPoIP):
<t> </dt>
For this, said NAP receives an incoming IP or HTTP p <dd> In this scenario, the mobile terminal applications are tightly integrated
acket (the latter through TCP connection termination) and publishes the packet u with the existing IP transport infrastructure. The TCL has no additional
nder a suitable ICN name (i.e., the hash over the destination IP address for an function because packets are forwarded directly using an IP protocol stack,
IP packet or the hash over the FQDN of the HTTP request for an HTTP packet) to t which sends packets over the IP transport.
he ICN network. In the HTTP case, the NAP maintains a pending request mapping ta </dd>
ble to map returning responses to the terminated TCP connection.
</t> <dt>ICN over ICN (ICNoICN):
</li> </dt>
<li> <dd> Similar to case 1, ICN applications tightly integrate with the ICN
<t>Hybrid ICN (hICN) transport infrastructure. The TCL has no additional responsibility because
</t> packets are forwarded directly using the native ICN protocol stack, which
<t> sends packets over the ICN transport.
An alternative approach to implement ICN over IP is </dd>
provided in Hybrid ICN <xref target="HICN" format="default"/>. It describes a no
vel approach to integrate ICN into IPv6 without creating overlays with a new pac <dt>ICN over IP (ICNoIP):
ket format as an encapsulation. hICN addresses the content by encoding a locatio </dt>
n-independent name in an IPv6 address. It uses two name components--name prefix <dd> <t>In this scenario, the underlying IP transport infrastructure is not
and name suffix--that identify the source of data and the data segment within th impacted (that is, ICN is implemented as an IP overlay between mobile terminal
e scope of the name prefix, respectively. and content provider). IP routing is used from the Radio Access Network
</t> (eNodeB) to the mobile backhaul, the IP core, and the Mobile Gateway
<t> (SGW/PGW). The mobile terminal attaches to the Mobile Gateway (SGW/PGW) using
At application layer, hICN maps the name into an IPv an IP address. Also, the data transport between Mobile Gateway (SGW/PGW) and
6 prefix and, thus, uses IP as transport. As long as the name prefixes, which ar content publisher uses IP. The content provider can serve content using either
e routable IP prefixes, point towards a mobile GW (PGW or local breakout, such a IP or ICN, based on the mobile terminal request.
s CUPS), there are potentially no updates required to any of the mobile core gat </t>
eways (for example, SGW/PGW). The IPv6 backhaul routes the packets within the mo
bile core. hICN can run in the mobile terminal, in the eNodeB, in the mobile bac <t>One of the approaches to implement ICN in mobile backhaul networks is
khaul, or in the mobile core. Finally, as hICN itself uses IPv6, it cannot be co described in <xref target="MBICN" format="default"/>. It implements a General
nsidered as an alternative transport layer. Tunneling Protocol - User Plane (GTP-U) extension header option to encapsulate
</t> ICN payload in a GTP tunnel. However, as this design runs ICN as an IP
</li> overlay, the mobile backhaul can be deployed using native IP. The proposal
</ol> describes a mechanism where the GTP-U tunnel can be terminated by hairpinning
</section> the packet before it reaches the SGW if an ICN-enabled node is deployed in the
mobile backhaul (that is, between eNodeB and SGW). This could be useful when
an ICN data packet is stored in the ICN node (such as repositories and caches) i
n
the tunnel path so that the ICN node can reply without going all the way
through the mobile core. While a GTP-U extension header is used to carry
mobile-terminal-specific ICN payload, they are not visible to the transport,
including the SGW. On the other hand, the PGW can use the mobile terminal-specif
ic
ICN header extension and ICN payload to set up an uplink transport towards a
content provider in the Internet. In addition, the design assumes a proxy
function at the edge to perform ICN data retrieval on behalf of a non-ICN end
device.</t>
</dd>
<dt>IP over ICN (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, however, will require an interworking function (IWF) (and Border Gatew
ay)
to translate various transport primitives. The IWF function will provide a
mechanism for protocol translation between IPoICN and the native IP. After rev
iewing <xref target="IPoICN"
format="default"/>, we understand and interpret that ICN is implemented in the
transport natively; however, IP is implemented in MT, the eNodeB, and the Mobile
Gateway (SGW/PGW), which is also called a network attach point (NAP).</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>
</dd>
<dt>Hybrid ICN (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 prefix and name suffix, that identify the source of data and
the data segment within the scope of the name prefix, respectively.
</t>
<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, the eNodeB, the mobile
backhaul, or the mobile core. Finally, as hICN itself uses IPv6, it cannot
be considered as an alternative transport layer.
</t>
</dd>
</dl>
</section>
<section anchor="icn_deployment_in_4g_control_plane" numbered="true" toc=" default"> <section anchor="icn_deployment_in_4g_control_plane" numbered="true" toc=" default">
<name>Integration of ICN in 4G Control Plane</name> <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-b ased protocols with ICN for 4G signaling in the current architecture. It is impo rtant to understand the concept of point of attachment (POA). When mobile termin al connects to a network, it has the following POAs: <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-b ased protocols with ICN for 4G signaling in the current architecture. It is impo rtant to understand the concept of point of attachment (POA). When a mobile term inal connects to a network, it has the following POAs:
</t> </t>
<ol spacing="normal" type="1"><li>eNodeB managing location or physical P OA</li> <ol spacing="normal" type="1"><li>eNodeB managing location or physical P OA</li>
<li>Authentication and Authorization (MME, HSS) managing identity or a uthentication POA</li> <li>Authentication and Authorization (MME, HSS) managing identity or a uthentication POA</li>
<li>Mobile Gateways (SGW, PGW) managing logical or session management POA</li> <li>Mobile Gateways (SGW/PGW) managing logical or session management P OA</li>
</ol> </ol>
<t>In the current architecture, IP transport is used for all messages as sociated with the control plane for mobility and session management. IP is embed ded very deeply into these messages utilizing TLV syntax for carrying additional attributes such as a layer 3 transport. The physical POA in the eNodeB handles both mobility and session management for any mobile terminal attached to 4G netw ork. The number of mobility management messages between different nodes in an 4G network per signaling procedure is shown in <xref target="tab_4g_messages" form at="default"/>. <t>In the current architecture, IP transport is used for all messages as sociated with the control plane for mobility and session management. IP is embed ded very deeply into these messages utilizing TLV syntax for carrying additional attributes such as a Layer 3 transport. The physical POA in the eNodeB handles both mobility and session management for any mobile terminal attached to a 4G ne twork. The number of mobility management messages between different nodes in a 4 G network per the signaling procedure is shown in <xref target="tab_4g_messages" format="default"/>.
</t> </t>
<t>Normally, two types of mobile terminals attach to the 4G network: SIM based (need 3GPP mobility protocol for authentication) or non-SIM based (which connect to WiFi network). Both device types require authentication. For non-SIM based devices, AAA is used for authentication. We do not propose to change mobil e terminal authentication or mobility management messaging for user data transpo rt using ICN. A separate study would be required to analyze the impact of ICN on mobility management messages structures and flows. We are merely analyzing the viability of implementing ICN as a transport for control plane messages. <t>Normally, two types of mobile terminals attach to the 4G network: SIM based (which needs a 3GPP mobility protocol for authentication) or non-SIM base d (which connects to Wi-Fi networks). Both device types require authentication. For non-SIM based devices, Authentication, Authorization, and Accounting (AAA) i s used for authentication. We do not propose to change mobile terminal authentic ation or mobility management messaging for user data transport using ICN. A sepa rate study would be required to analyze the impact of ICN on mobility management messages, structures, and flows. We are merely analyzing the viability of imple menting ICN as a transport for control plane messages.
</t> </t>
<t>It is important to note that if MME and HSS do not support ICN transp ort, they still need to support mobile terminal capable of dual transport or nat ive ICN. When 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 m obile terminal authentication to HSS, so HSS must be able to authenticate an ICN -capable mobile terminal and authorize create session <xref target="TS23.401" fo rmat="default"/>. <t>It is important to note that if MME and HSS do not support ICN transp ort, they still need to support a mobile terminal capable of dual transport or n ative 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 forwar ds mobile terminal authentication to HSS, so HSS must be able to authenticate an ICN-capable mobile terminal and authorize Create Session <xref target="TS23.401 " format="default"/>.
</t> </t>
<table anchor="tab_4g_messages" align="center"> <table anchor="tab_4g_messages" align="center">
<name>Signaling Messages in 4G Gateways</name> <name>Signaling Messages in 4G Gateways</name>
<thead> <thead>
<tr> <tr>
<th align="left">4G Signaling Procedures</th> <th align="left">4G Signaling Procedures</th>
<th align="right">MME</th> <th align="right">MME</th>
<th align="right">HSS</th> <th align="right">HSS</th>
<th align="right">SGW</th> <th align="right">SGW</th>
<th align="right">PGW</th> <th align="right">PGW</th>
skipping to change at line 565 skipping to change at line 689
<tr> <tr>
<td align="left">Total</td> <td align="left">Total</td>
<td align="right">34</td> <td align="right">34</td>
<td align="right">2</td> <td align="right">2</td>
<td align="right">14</td> <td align="right">14</td>
<td align="right">6</td> <td align="right">6</td>
<td align="right">3</td> <td align="right">3</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Anchorless mobility <xref target="ALM" format="default"/> provides a <t>Anchorless mobility <xref target="ALM" format="default"/> provides a
fully decentralized, control- plane agnostic solution to handle producer mobilit fully decentralized solution that is control plane agnostic to handle producer m
y in ICN. Mobility management at layer-3 level makes it access agnostic and tran obility in ICN.
sparent to the end device or the application. The solution discusses handling mo
bility without having to depend on core network functions (e.g. MME); however, a Mobility management at the Layer 3 makes its access agnostic and transpar
location update to the core network may still be required to support legal comp ent to the end device or the application. The solution discusses handling mobili
liance requirements such as lawful intercept and emergency services. These aspec ty without having to depend on core network functions (e.g., MME); however, a lo
ts are open for further study. cation update to the core network may still be required to support legal complia
nce requirements such as lawful intercept and emergency services. These aspects
are open for further study.
</t> </t>
<t>One of the advantages of ICN is in the caching and reusing of the con tent, which does not apply to the transactional signaling exchange. After analyz ing 4G signaling call flows <xref target="TS23.401" format="default"/> and messa ges inter-dependencies (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 aggre gation and content caching are not applicable to control plane signaling message s. Control plane messages are originated and consumed by the applications and th ey cannot be shared. <t>One of the advantages of ICN is in the caching and reusing of the con tent, which does not apply to the transactional signaling exchange. After analyz ing 4G signaling call flows <xref target="TS23.401" format="default"/> and messa ge interdependencies (see <xref target="tab_4g_messages" format="default"/>), ou r recommendation is that it is not beneficial to use ICN for control plane and m obility management functions. Among the features of ICN design, Interest aggrega tion and content caching are not applicable to control plane signaling messages. Control plane messages are originated and consumed by the applications, and the y cannot be shared.
</t> </t>
</section> </section>
<section anchor="icn_deployment_in_4g_user_plane" numbered="true" toc="def ault"> <section anchor="icn_deployment_in_4g_user_plane" numbered="true" toc="def ault">
<name>Integration of ICN in 4G User Plane</name> <name>Integration of ICN in 4G User Plane</name>
<t>We will consider <xref target="fig_lte_4g_mobile_net_overview" format <t>We will consider <xref target="fig_lte_4g_mobile_net_overview" format
="default"/> to discuss different mechanisms to integrate ICN in mobile networks ="default"/> when discussing different mechanisms to integrate ICN in mobile net
. In <xref target="icn_deployment_scenarios" format="default"/>, we discussed ge works. In <xref target="icn_deployment_scenarios" format="default"/>, we discuss
neric ed generic
experimental setups of ICN integration. In this section, we discuss the specifi experimental setups of ICN integration. In this section, we discuss the specifi
c options of possible use of native ICN in 4G user plane. We consider the follow c options of possible use of native ICN in the 4G user plane. The following opti
ing options: ons are considered:
</t> </t>
<ol spacing="normal" type="1"><li>Dual transport (IP/ICN) mode in Mobile <ol spacing="normal" type="1"><li>Using Dual transport (IP/ICN) mode in
Terminal</li> mobile terminal</li>
<li>Using ICN in Mobile Terminal</li> <li>Using ICN in mobile terminal</li>
<li>Using ICN in eNodeB</li> <li>Using ICN in eNodeB</li>
<li>Using ICN in mobile gateways (SGW/PGW)</li> <li>Using ICN in Mobile Gateways (SGW/PGW)</li>
</ol> </ol>
<section anchor="dual_transport_icn_deploy_mt" numbered="true" toc="defa ult"> <section anchor="dual_transport_icn_deploy_mt" numbered="true" toc="defa ult">
<name>Dual Transport (IP/ICN) Mode in Mobile Terminal</name> <name>Dual Transport (IP/ICN) Mode in Mobile Terminal</name>
<t>The control and user plane communications in 4G mobile networks are specified in 3GPP documents <xref target="TS23.203" format="default"> </xref> a nd <xref target="TS23.401" format="default"/>. It is important to understand tha t mobile terminal can be either consumer (receiving content) or publisher (pushi ng content for other clients). The protocol stack inside the mobile terminal (MT ) is complex because it must support multiple radio connectivity access to eNode B(s). <t>The control and user-plane communications in 4G mobile networks are specified in 3GPP documents <xref target="TS23.203" format="default"> </xref> a nd <xref target="TS23.401" format="default"/>. It is important to understand tha t a mobile terminal can be either consumer (receiving content) or publisher (pus hing content for other clients). The protocol stack inside the mobile terminal ( MT) is complex because it must support multiple radio connectivity access to eNo deB(s).
</t> </t>
<t><xref target="fig_dual_Stack_icn_deploy_mt" format="default"/> prov ides a high-level description of a protocol stack, where IP is used at two layer s: (1) user plane communication and (2) UDP encapsulation. User plane communicat ion takes place between Packet Data Convergence Protocol (PDCP) and Application layer, whereas UDP encapsulation is at GTP protocol stack. <t><xref target="fig_dual_Stack_icn_deploy_mt" format="default"/> prov ides a high-level description of a protocol stack, where IP is used at two layer s: (1) user-plane communication and (2) UDP encapsulation. User-plane communicat ion takes place between the Packet Data Convergence Protocol (PDCP) and Applicat ion layer, whereas UDP encapsulation is at the GTP protocol stack.
</t> </t>
<t>The protocol interactions and impact of supporting tunneling of ICN
packet into IP or to support ICN natively are described in <xref target="fig_du <t>The protocol interactions and impact of supporting the tunneling of
al_Stack_icn_deploy_mt" format="default"/> and <xref target="fig_dual_Stack_icn_ an ICN packet into IP or supporting ICN natively are described in Figures <xref
protocol_interaction" format="default"/>, respectively. target="fig_dual_Stack_icn_deploy_mt" format="counter"/> and <xref target="fig_
dual_Stack_icn_protocol_interaction" format="counter"/>, respectively.
</t> </t>
<figure anchor="fig_dual_Stack_icn_deploy_mt"> <figure anchor="fig_dual_Stack_icn_deploy_mt">
<name>Dual Transport (IP/ICN) mode in Mobile Terminal</name> <name>Dual Transport (IP/ICN) Mode in a Mobile Terminal</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+--------+ +--------+ +--------+ +--------+
| App | | CDN | | App | | CDN |
+--------+ +--------+ +--------+ +--------+
|Transp. | | | | |Transp. | |Transp. | | | | |Transp. |
|Converg.|.|..............|...............|............|.|Converge| |Converg.|.|..............|...............|............|.|Converge|
+--------+ | | | +--------+ | +--------+ +--------+ | | | +--------+ | +--------+
| |.|..............|...............|.| |.|.| | | |.|..............|...............|.| |.|.| |
| ICN/IP | | | | | ICN/IP | | | ICN/IP| | ICN/IP | | | | | ICN/IP | | | ICN/IP|
| | | | | | | | | | | | | | | | | | | |
+--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+ +--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+
| |.|.| | |.|.| | |.|.| | | | | | | |.|.| | |.|.| | |.|.| | | | | |
| PDCP | | |PDCP|GTP-U| | |GTP-U|GTP-U| | |GTP-U| | | | L2 | | PDCP | | |PDCP|GTP-U| | |GTP-U|GTP-U| | |GTP-U| | | | L2 |
+--------+ | +----------+ | +-----------+ | +-----+ | | | | +--------+ | +----------+ | +-----------+ | +-----+ | | | |
| RLC |.|.|RLC | UDP |.|.| UDP | UDP |.|.|UDP |L2|.|.| | | RLC |.|.|RLC | UDP |.|.| UDP | UDP |.|.|UDP |L2|.|.| |
+--------+ | +----------+ | +-----------+ | +-----+ | | | | +--------+ | +----------+ | +-----------+ | +-----+ | | | |
| MAC |.|.| MAC| L2 |.|.| L2 | L2 |.|.| L2 | | | | | | MAC |.|.| MAC| L2 |.|.| L2 | L2 |.|.| L2 | | | | |
+--------+ | +----------+ | +-----------+ | +--------+ | +--------+ +--------+ | +----------+ | +-----------+ | +--------+ | +--------+
| L1 |.|.| L1 | L1 |.|.| L1 | L1 |.|.| L1 |L1|.|.| L1 | | L1 |.|.| L1 | L1 |.|.| L1 | L1 |.|.| L1 |L1|.|.| L1 |
+--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+ +--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+
MT | BS(eNodeB) | SGW | PGW | MT | BS (eNodeB) | SGW | PGW |
Uu S1U S5/S8 SGi Uu S1U S5/S8 SGi
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The protocols and software stack used inside 4G capable mobile term <t>The protocols and software stack used inside 4G-capable mobile
inal support both 3G and 4G software interworking and handover. 3GPP Rel.13 onw terminals support both 3G and 4G software interworking and handover.
ard specifications describe the use of IP and non-IP protocols to establish logi 3GPP Rel.13 specifications and onward describe the use of IP and
cal/session connectivity. We can leverage the non-IP protocol-based mechanism to non-IP protocols to establish logical/session connectivity. We can
deploy ICN protocol stack in the mobile terminal, as well as in eNodeB and mobi leverage the non-IP protocol-based mechanism to deploy an ICN protocol
le gateways (SGW, PGW). The following paragraphs describe per-layer consideratio stack in the mobile terminal as well as in an eNodeB and Mobile
ns of supporting tunneling of ICN packet into IP or to support ICN natively. Gateways (SGW/PGW). The following paragraphs describe per-layer
considerations of supporting the tunneling of ICN packets into IP or
supporting ICN natively.
</t> </t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>An existing application layer can be modified to provide option s 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 a pplication layer can be provided with an option of selecting either ICN or IP tr ansport, as well as radio interface, to send and receive data traffic. <t>An existing application layer can be modified to provide option s 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 a pplication layer can be provided with an option of selecting either ICN or IP tr ansport, as well as radio interface, to send and receive data traffic.
</t> </t>
<t> <t>
Our proposal is to provide an Application Programmin g 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) function handles the interaction of applications with multiple tran sport options. Our proposal is to provide an Application Programmin g 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 TCL function handles the interaction of applications with multiple transport options.
</t> </t>
</li> </li>
<li> <li>
<t>The transport convergence layer helps determine the type of tra nsport (such as ICN, hICN, or IP) and type of radio interface (LTE or WiFi, or b oth) used to send and receive traffic. Application layer can make the decision t o select a specific transport based on preference, such as content location, con tent type, content publisher, congestion, cost, QoS, and so on. There can be an Application Programming Interface (API) to exchange parameters required for tran sport selection. Southbound interactions of Transport Convergence Layer (TCL) wi ll be either to IP or ICN at the network layer. <t>The transport convergence layer helps determine the type of tra nsport (such as ICN, hICN, or IP) and type of radio interface (LTE, Wi-Fi, or bo th) used to send and receive traffic. The application layer can make the decisio n to select a specific transport based on preference such as content location, c ontent type, content publisher, congestion, cost, QoS, and so on. There can be a n API to exchange parameters required for transport selection. Southbound intera ctions of the TCL will be either to IP or to ICN at the network layer.
</t> </t>
<t> <t>
When selecting the IPoICN mode, the TCL is responsib le for receiving an incoming IP or HTTP packet and publishing the packet to the ICN network under a suitable ICN name (that is, the hash over the destination IP address for an IP packet, or the hash over the FQDN of the HTTP request for an HTTP packet). When selecting the IPoICN mode, the TCL is responsib le for receiving an incoming IP or HTTP packet and publishing the packet to the ICN network under a suitable ICN name (that is, the hash over the destination IP address for an IP packet or the hash over the FQDN of the HTTP request for an H TTP packet).
</t> </t>
<t> <t>
In the HTTP case, the TCL can maintain a pending req In the HTTP case, the TCL can maintain a pending req
uest mapping table to map returning responses to the originating HTTP request. T uest mapping table to map, returning responses to the originating HTTP request.
he common API will provide a 'connection' abstraction for this HTTP mode of oper The common API will provide a "connection" abstraction for this HTTP mode of ope
ation, returning the response over said connection abstraction, akin to the TCP ration, returning the response over said connection abstraction (akin to the TCP
socket interface, while implementing a reliable transport connection semantic ov socket interface) while implementing a reliable transport connection semantic o
er the ICN from the mobile terminal to the receiving mobile terminal or the PGW. ver 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 proto . If the HTTP protocol stack remains unchanged, therefore utilizing the TCP prot
col for transfer, the TCL operates in local TCP termination mode, retrieving the ocol for transfer, the TCL operates in local TCP termination mode, retrieving th
HTTP packet through said local termination. e HTTP packet through said local termination.
</t> </t>
<figure anchor="fig_dual_Stack_icn_protocol_interaction"> <figure anchor="fig_dual_Stack_icn_protocol_interaction">
<name>Dual Stack ICN Protocol Interactions</name> <name>Dual Stack ICN Protocol Interactions</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+----------------+ +-----------------+ +----------------+ +-----------------+
| ICN App (new) | |IP App (existing)| | ICN App (new) | |IP App (existing)|
+---------+------+ +-------+---------+ +---------+------+ +-------+---------+
| | | |
+---------+----------------+---------+ +---------+----------------+---------+
skipping to change at line 669 skipping to change at line 806
| RLC (Existing) | | RLC (Existing) |
+-----------------+------------------+ +-----------------+------------------+
| |
+-----------------+------------------+ +-----------------+------------------+
| MAC Layer (Existing) | | MAC Layer (Existing) |
+-----------------+------------------+ +-----------------+------------------+
| |
+-----------------+------------------+ +-----------------+------------------+
| Physical L1 (Existing) | | Physical L1 (Existing) |
+------------------------------------+ +------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
</li> </li>
<li>The ICN function (forwarder) is proposed to run in parallel to t he existing IP layer. The ICN forwarder forwards the ICN packets, such as an Int erest packet to eNodeB or a response "data packet" from eNodeB to the applicatio n. <li>The ICN function (forwarder) is proposed to run in parallel to t he existing IP layer. The ICN forwarder forwards the ICN packets such as an Inte rest packet to an eNodeB or a response "data packet" from an eNodeB to the appli cation.
</li> </li>
<li>For the dual-transport scenario, when mobile terminal is not sup porting ICN as transport, the TCL can use the IP underlay to tunnel the ICN pack ets. The ICN function can use the IP interface to send Interest and Data packets for fetching or sending data respectively. This interface can use the ICN overl ay over IP. <li>For the dual-transport scenario, when a mobile terminal is not s upporting ICN as transport, the TCL can use the IP underlay to tunnel the ICN pa ckets. The ICN function can use the IP interface to send Interest and Data packe ts for fetching or sending data, respectively. This interface can use the ICN ov erlay over IP.
</li> </li>
<li> <li>
<t>To support ICN at network layer in mobile terminal, the PDCP la <t>To support ICN at the network layer in the mobile terminal, the
yer should be aware of ICN capabilities and parameters. PDCP is located in the R PDCP layer should be aware of ICN capabilities and parameters. PDCP is located
adio Protocol Stack in the LTE Air interface, between IP (Network layer) and Rad in the Radio Protocol Stack in the LTE Air interface, between the IP (Network la
io Link Control Layer (RLC). PDCP performs the following functions <xref target= yer) and Radio Link Control Layer (RLC). PDCP performs the following functions <
"TS36.323" format="default"/>: xref target="TS36.323" format="default"/>:
</t> </t>
<ol spacing="normal" type="1"><li>Data transport by listening to u
pper layer, formatting and pushing down to Radio Link Layer (RLC) <ol spacing="normal" type="1">
<li>Data transport by listening to the upper layer, formatting, a
nd pushing down to the RLC
</li> </li>
<li>Header compression and decompression using Robust Header Com pression (ROHC) <li>Header compression and decompression using ROHC
</li> </li>
<li>Security protections such as ciphering, deciphering, and int egrity protection <li>Security protections such as ciphering, deciphering, and int egrity protection
</li> </li>
<li>Radio layer messages associated with sequencing, packet drop detection and re-transmission, and so on. <li>Radio layer messages associated with sequencing, packet drop detection and retransmission, and so on.
</li> </li>
</ol> </ol>
</li> </li>
<li>No changes are required for lower layer such as RLC, MAC, and Ph ysical (L1) as they are not IP aware. <li>No changes are required for the lower layer such as RLC, Media A ccess Control (MAC), and Physical (L1) as they are not IP aware.
</li> </li>
</ol> </ol>
<t>One key point to understand in this scenario is that ICN is deploye d as an overlay on top of IP. <t>One key point to understand in this scenario is that ICN is deploye d as an overlay on top of IP.
</t> </t>
</section> </section>
<section anchor="native_icn_deployment_in_mt" numbered="true" toc="defau lt"> <section anchor="native_icn_deployment_in_mt" numbered="true" toc="defau lt">
<name>Using ICN in Mobile Terminal</name> <name>Using ICN in Mobile Terminal</name>
<t>We can implement ICN natively in mobile terminal by modifying the P
DCP layer in 3GPP protocols. <xref target="fig_native_icn_deployment_in_mt" form <t>We can implement ICN natively in the mobile terminal by modifying t
at="default"/> provides a high-level protocol stack description where ICN can be he PDCP layer in 3GPP protocols. <xref target="fig_native_icn_deployment_in_mt"
used at the following different layers: format="default"/> provides a high-level protocol stack description where ICN ca
n be used at the following different layers:
</t> </t>
<ol spacing="normal" type="1"><li>User plane communication</li> <ol spacing="normal" type="1"><li>User-plane communication</li>
<li>Transport layer</li> <li>Transport layer</li>
</ol> </ol>
<t>ICN transport would be a substitute of the GTP protocol. The remova l of the GTP protocol stack is a significant change in the mobile architecture a nd requires a thorough study mainly because it is used not just for routing but for mobility management functions, such as billing, mediation, and policy enforc ement. <t>ICN transport would be a substitute for the GTP protocol. The remov al 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 such as billing, mediation, and policy enforc ement.
</t> </t>
<t>The implementation of ICN natively in the mobile terminal leads to a changed communication model between mobile terminal and eNodeB. Also, we can a void tunneling the user plane traffic from eNodeB to the mobile packet core (SGW , PGW) through a GTP tunnel. <t>The implementation of ICN natively in the mobile terminal leads to a changed communication model between the mobile terminal and eNodeB. Also, we c an avoid tunneling the user-plane traffic from an eNodeB to the mobile packet co re (SGW/PGW) through a GTP tunnel.
</t> </t>
<t>For native ICN use, an application can be configured to use ICN for warder and it does not need the TCL layer. Also, to support ICN at the network l ayer, the existing PDCP layer may need to be changed to be aware of ICN capabili ties and parameters. <t>For native ICN use, an application can be configured to use an ICN forwarder, and it does not need the TCL layer. Also, to support ICN at the netwo rk layer, the existing PDCP layer may need to be changed to be aware of ICN capa bilities and parameters.
</t> </t>
<t>The native implementation can provide new opportunities to develop new use cases leveraging ICN capabilities, such as seamless mobility, mobile ter minal to mobile terminal content delivery using radio network without traversing the mobile gateways, and more. <t>The native implementation can provide new opportunities to develop new use cases leveraging ICN capabilities such as seamless mobility, mobile term inal to mobile terminal content delivery using a radio network without traversin g the Mobile Gateways, and more.
</t> </t>
<figure anchor="fig_native_icn_deployment_in_mt"> <figure anchor="fig_native_icn_deployment_in_mt">
<name>Using Native ICN in Mobile Terminal</name> <name>Using Native ICN in Mobile Terminal</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+--------+ +--------+ +--------+ +--------+
| App | | CDN | | App | | CDN |
+--------+ +--------+ +--------+ +--------+
|Transp. | | | | | |Transp. | |Transp. | | | | | |Transp. |
|Converge|.|..............|..............|..............|.|Converge| |Converge|.|..............|..............|..............|.|Converge|
+--------+ | | | | +--------+ +--------+ | | | | +--------+
skipping to change at line 737 skipping to change at line 875
| PDCP | | |PDCP| ICN |.|.| ICN |.|.| ICN |.|.| | | PDCP | | |PDCP| ICN |.|.| ICN |.|.| ICN |.|.| |
+--------+ | +----+ | | | | | | | | | | +--------+ | +----+ | | | | | | | | | |
| RLC |.|.|RLC | | | | | | | | | | | | RLC |.|.|RLC | | | | | | | | | | |
+--------+ | +----------+ | +----------+ | +----------+ | +--------+ +--------+ | +----------+ | +----------+ | +----------+ | +--------+
| MAC |.|.| MAC| L2 |.|.| L2 |.|.| L2 |.|.| L2 | | MAC |.|.| MAC| L2 |.|.| L2 |.|.| L2 |.|.| L2 |
+--------+ | +----------+ | +----------+ | +----------+ | +--------+ +--------+ | +----------+ | +----------+ | +----------+ | +--------+
| L1 |.|.| L1 | L1 |.|.| L1 |.|.| L1 |.|.| L1 | | L1 |.|.| L1 | L1 |.|.| L1 |.|.| L1 |.|.| L1 |
+--------+ | +----+-----+ | +----------+ | +----------+ | +--------+ +--------+ | +----+-----+ | +----------+ | +----------+ | +--------+
MT | BS(eNodeB) | SGW | PGW | MT | BS(eNodeB) | SGW | PGW |
Uu S1u S5/S8 SGi Uu S1u S5/S8 SGi
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="icn_deployment_in_enodeb" numbered="true" toc="default" > <section anchor="icn_deployment_in_enodeb" numbered="true" toc="default" >
<name>Using ICN in eNodeB</name> <name>Using ICN in eNodeB</name>
<t>The eNodeB is a physical point of attachment for the mobile termina l, where radio protocols are converted into IP transport protocol for dual trans port/overlay and native ICN, respectively (see <xref target="fig_dual_Stack_icn_ protocol_interaction" format="default"/> and <xref target="fig_native_icn_deploy ment_in_mt" format="default"/>). When a mobile terminal performs an attach proce dure, it would be assigned an identity either as IP or dual transport (IP and IC N), or ICN endpoint. Mobile terminal can initiate data traffic using any of the following options: <t>The eNodeB is a physical point of attachment for the mobile termina l where radio protocols are converted into IP transport protocols for dual trans port/overlay and native ICN, respectively (see Figures <xref target="fig_dual_St ack_icn_protocol_interaction" format="counter"/> and <xref target="fig_native_ic n_deployment_in_mt" format="counter"/>). When a mobile terminal performs an atta ch procedure, it will be assigned an identity as either IP or dual transport (IP and ICN) or ICN endpoint. A mobile terminal can initiate data traffic using any of the following options:
</t> </t>
<ol spacing="normal" type="1"><li>Native IP (IPv4 or IPv6)</li> <ol spacing="normal" type="1"><li>Native IP (IPv4 or IPv6)</li>
<li>Native ICN</li> <li>Native ICN</li>
<li>Dual transport IP (IPv4/IPv6) and ICN</li> <li>Dual transport IP (IPv4/IPv6) and ICN</li>
</ol> </ol>
<t>The mobile terminal encapsulates a user data transport request into
PDCP layer and sends the information on the air interface to eNodeB, which in t <t>The mobile terminal encapsulates a user data transport request into the PDCP
urn receives the information and, using PDCP <xref target="TS36.323" format="def layer and sends the information on the air interface to the eNodeB, which in tur
ault"/>, de-encapsulates the air-interface messages and converts them to forward n receives the information and, using PDCP <xref target="TS36.323" format="defau
to core mobile gateways (SGW, PGW). As shown in <xref target="fig_native_icn_de lt"/>, de-encapsulates the air-interface messages and converts them to forward-t
ployment_in_enodeb" format="default"/>, to support ICN natively in eNodeB, it is o-core Mobile Gateways (SGW/PGW). As shown in <xref target="fig_native_icn_deplo
proposed to provide transport convergence layer (TCL) capabilities in eNodeB (s yment_in_enodeb" format="default"/>, to support ICN natively in an eNodeB, it is
imilar to as provided in MT), which provides the following functions: proposed to provide TCL capabilities in an eNodeB (similar to as provided in MT
), which provides the following functions:
</t> </t>
<ol spacing="normal" type="1"><li>It decides the forwarding strategy f or a user data request coming from mobile terminal. The strategy can decide base d on preference indicated by the application, such as congestion, cost, QoS, and so on. <ol spacing="normal" type="1"><li>It decides the forwarding strategy f or 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>
<li> <li>
<t>eNodeB to provide open Application Programming Interface (API) to external management systems, to provide capability to eNodeB to program the f orwarding strategies. <t>It uses an eNodeB to provide an open API to external management systems in order to provide eNodeB the capability to program the forwarding str ategies.
</t> </t>
<figure anchor="fig_native_icn_deployment_in_enodeb"> <figure anchor="fig_native_icn_deployment_in_enodeb">
<name>Integration of Native ICN in eNodeB</name> <name>Integration of Native ICN in eNodeB</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+---------------+ | +---------------+ |
| MT request | | ICN +---------+ | MT request | | ICN +---------+
+---->| content using |--+--- transport -->| | +---->| content using |--+--- transport -->| |
| |ICN protocol | | | | | |ICN protocol | | | |
| +---------------+ | | | | +---------------+ | | |
| | | | | | | |
| +---------------+ | | | | +---------------+ | | |
+-+ | | MT request | | IP |To mobile| +-+ | | MT request | | IP |To mobile|
| |-+---->| content using |--+--- transport -->| GW | | |-+---->| content using |--+--- transport -->| GW |
+-+ | | IP protocol | | |(SGW,PGW)| +-+ | | IP protocol | | |(SGW/PGW)|
MT | +---------------+ | | | MT | +---------------+ | | |
| | | | | | | |
| +---------------+ | | | | +---------------+ | | |
| | MT request | | Dual stack | | | | MT request | | Dual stack | |
+---->| content using |--+--- IP+ICN -->| | +---->| content using |--+--- IP+ICN -->| |
|IP/ICN protocol| | transport +---------+ |IP/ICN protocol| | transport +---------+
+---------------+ | +---------------+ |
eNodeB S1u eNodeB S1u
]]></artwork> ]]></artwork>
</figure> </figure>
</li> </li>
<li> <li>
<t>eNodeB can be upgraded to support three different types of tran <t>The eNodeB can be upgraded to support three different types of
sport: IP, ICN, and dual transport IP+ICN towards mobile gateways, as depicted i transport: IP, ICN, and dual transport IP+ICN towards Mobile Gateways, as depict
n <xref target="fig_native_icn_deployment_in_enodeb" format="default"/>. It is a ed in <xref target="fig_native_icn_deployment_in_enodeb" format="default"/>. It
lso proposed to deploy IP and/or ICN forwarding capabilities into eNodeB, for ef is also proposed to deploy IP and/or ICN forwarding capabilities into an eNodeB
ficient transfer of data between eNodeB and mobile gateways. Following are choic for efficient transfer of data between the eNodeB and Mobile Gateways. The follo
es for forwarding a data request towards mobile gateways: wing are choices for forwarding a data request towards Mobile Gateways:
</t> </t>
<ol spacing="normal" type="1"><li>Assuming eNodeB is IP enabled an <ol spacing="normal" type="1">
d the MT requests an IP transfer, eNodeB forwards data over IP. <li>Assuming the eNodeB is IP enabled and the MT requests an IP t
ransfer, the eNodeB forwards data over IP.
</li> </li>
<li>Assuming eNodeB is ICN enabled and the MT requests an ICN tr ansfer, eNodeB forwards data over ICN. <li>Assuming the eNodeB is ICN enabled and the MT requests an IC N transfer, the eNodeB forwards data over ICN.
</li> </li>
<li>Assuming eNodeB is IP enabled and the MT requests an ICN tra nsfer, eNodeB overlays ICN on IP and forwards user plane traffic over IP. <li>Assuming the eNodeB is IP enabled and the MT requests an ICN transfer, the eNodeB overlays ICN on IP and forwards user-plane traffic over IP .
</li> </li>
<li>Assuming eNodeB is ICN enabled and the MT requests an IP tra nsfer, eNodeB overlays IP on ICN and forwards user plane traffic over ICN <xref target="IPoICN" format="default"/>. <li>Assuming the eNodeB is ICN enabled and the MT requests an IP transfer, the eNodeB overlays IP on ICN and forwards user-plane traffic over IC N <xref target="IPoICN" format="default"/>.
</li> </li>
</ol> </ol>
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="icn_deployment_in_packet_core" numbered="true" toc="def ault"> <section anchor="icn_deployment_in_packet_core" numbered="true" toc="def ault">
<name>Using ICN in Packet Core (SGW, PGW) Gateways</name>
<t>Mobile gateways (a.k.a. Evolved Packet Core (EPC)) include SGW, PGW <name>Using ICN in Packet Core Gateways (SGW/PGW)</name>
, which perform session management for MT from the initial attach to disconnecti <t>Mobile Gateways (a.k.a.&nbsp;Evolved Packet Core (EPC)) include SGW
on. When MT is powered on, it performs NAS signaling and attaches to PGW after s and PGW, which perform session management for MT from the initial attach to dis
uccessful authentication. PGW is an anchoring point for MT and responsible for s connection. When MT is powered on, it performs Network-Access-Stratum (NAS) sign
ervice creations, authorization, maintenance, and so on. The Entire functionalit aling and attaches to PGW after successful authentication. PGW is an anchoring p
y is managed using IP address(es) for MT. oint for MT and is responsible for service creations, authorization, maintenance
, and so on. The entire functionality is managed using an IP address(es) for MT.
</t> </t>
<t>To implement ICN in EPC, the following functions are proposed: <t>To implement ICN in EPC, the following functions are proposed:
</t> </t>
<ol spacing="normal" type="1"><li>Insert ICN attributes in session man
agement layer as additional functionality with IP stack. Session management laye <ol spacing="normal" type="1"><li>Insert ICN attributes in the session
r is used for performing attach procedures and assigning logical identity to use management layer for additional functionality with IP stack. The session manage
r. After successful authentication by HSS, MME sends a create session request (C ment layer is used for performing attach procedures and assigning logical identi
SR) to SGW and SGW to PGW. ty to users. After successful authentication by HSS, MME sends a Create Session
Request (CSR) to SGW and SGW to PGW.
</li> </li>
<li>When MME sends Create Session Request message (Step 12 in <xref target="TS23.401" format="default"/>) to SGW or PGW, it includes a Protocol Conf iguration Option Information Element (PCO IE) containing MT capabilities. We can use PCO IE to carry ICN-related capabilities information from MT to PGW. This i nformation 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 bot h IPv4 and IPv6 protocols. <li>When MME sends a Create Session Request message (Step 12 in <xre f target="TS23.401" format="default"/>) to SGW or PGW, it includes a Protocol Co nfiguration Option (PCO) Information Element (IE) containing MT capabilities. We can use PCO IE to carry ICN-related capabilities information from MT to PGW. Th is information is received from MT during the initial attach request in MME. Det ails of available TLV, which can be used for ICN, are given in subsequent sectio ns. MT can support native IP, ICN+IP, or native ICN. IP is referred to as both I Pv4 and IPv6 protocols.
</li> </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 pro cedures and registers with the network for session management. For ICN-capable M T, it will provide only ICN attachment. For native IP-capable MT, there is no ch ange. <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 pro cedures and registers with the network for session management. For ICN-capable M T, it will provide only ICN attachment. For native IP-capable MT, there is no ch ange.
</li> </li>
<li>To support ICN-capable attach procedures and use ICN for user pl <li>To support ICN-capable attach procedures and use ICN for user-pl
ane traffic, PGW needs to have full ICN protocol stack functionalities. Typical ane traffic, PGW needs to have full ICN protocol stack functionalities. Typical
ICN capabilities include functions such as content store (CS), Pending Interest ICN capabilities include functions such as CS, PIT, FIB capabilities, and so on.
Table (PIT), Forwarding Information Base (FIB) capabilities, and so on. If MT re If MT requests ICN in PCO IE, then PGW registers MT with ICN names. For ICN for
quests ICN in PCO IE, then PGW registers MT with ICN names. For ICN forwarding, warding, PGW caches content locally using CS functionality.
PGW caches content locally using CS functionality. </li>
</li>
<li> <li>
<t>PCO IE described in <xref target="TS24.008" format="default"/> (see Figure 10.5.136 on page 598) and <xref target="TS24.008" format="default"/> (see Table 10.5.154 on page 599) provide details for different fields. <t>PCO IE as described in <xref target="TS24.008" format="default" /> (see Figure 10.5.136 on page 656 and Table 10.5.154 on page 659) provides det ails for different fields.
</t> </t>
<ol spacing="normal" type="1"><li>Octet 3 (configuration protocols define PDN types), which contains details about IPv4, IPv6, both or ICN. <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>
<li>Any combination of Octet 4 to Z can be used to provide addit ional information related to ICN capability. It is most important that PCO IE pa rameters are matched between MT and mobile gateways (SGW, PGW) so they can be in terpreted properly and the MT can attach successfully. <li>Any combination of Octet 4 to Z can be u sed to provide additional information related to ICN capability. It is most impo rtant that PCO IE parameters are matched between MT and Mobile Gateways (SGW/PGW ) so they can be interpreted properly and the MT can attach successfully.
</li> </li>
</ol> </ol>
</li> </li>
<li>The ICN functionalities in SGW and PGW should be matched with MT <li>The ICN functionalities in SGW and PGW should be matched with MT
and eNodeB because they will exchange ICN protocols and parameters.</li> and the eNodeB because they will exchange ICN protocols and parameters.</li>
<li>Mobile gateways SGW, PGW will also need ICN forwarding and cachi <li>Mobile Gateways (SGW/PGW) will also need ICN forwarding and cach
ng capability. This is especially important if CUPS is implemented. User Plane F ing capability. This is especially important if CUPS is implemented. User Plane
unction (UPF), comprising the SGW and PGW user plane, will be located at the edg Function (UPF), comprising the SGW and PGW user plane, will be located at the ed
e of the network and close to the end user. ICN-enabled gateway means that this ge 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 UPF would serve as a forwarder and should be capable of caching, as is the case
with any other ICN-enabled node.</li> with any other ICN-enabled node.</li>
<li>The transport between PGW and CDN provider can be either IP or I <li>The transport between PGW and CDN provider can be either IP or I
CN. When MT is attached to PGW with ICN identity and communicates with an ICN-en CN. When MT is attached to PGW with ICN identity and communicates with an ICN-en
abled CDN provider, it will use ICN primitives to fetch the data. On the other h abled CDN provider, it will use ICN primitives to fetch the data. On the other h
and, for a MT attached with an ICN identity, if PGW must communicate with an IP and, for an MT attached with an ICN identity, if PGW must communicate with an IP
enabled CDN provider, it will have to use an ICN-IP interworking gateway to perf -enabled CDN provider, it will have to use an ICN-IP interworking gateway to per
orm conversion between ICN and IP primitives for data retrieval. In the case of form 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 CUPS implementation with an offload close to the edge, this interworking gatewa
can be collocated with the UPF at the offload site to maximize the path optimiz y can be collocated with the UPF at the offload site to maximize the path optimi
ation. Further study is required to understand how this ICN-to-IP (and vice vers zation. Further study is required to understand how this ICN-to-IP (and vice ver
a) interworking gateway would function. sa) interworking gateway would function.
</li> </li>
</ol> </ol>
</section> </section>
</section> </section>
<section anchor="exp_test_setup" numbered="true" toc="default"> <section anchor="exp_test_setup" numbered="true" toc="default">
<name>An Experimental Test Setup</name> <name>An Experimental Test Setup</name>
<t>This section proposes an experimental lab setup and discusses the ope n issues and questions that use of ICN protocol is intended to address. To furth er test the modifications proposed in different scenarios, a simple lab can be s et up, as shown in <xref target="fig_native_icn_deployment_lab_setup" format="de fault"/>. <t>This section proposes an experimental lab setup and discusses the ope n issues and questions that use of the ICN protocol is intended to address. To f urther 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> </t>
<figure anchor="fig_native_icn_deployment_lab_setup"> <figure anchor="fig_native_icn_deployment_lab_setup">
<name>Native ICN Deployment Lab Setup</name> <name>Native ICN Deployment Lab Setup</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+------------------------------------------+ +------------------------------------------+
| +-----+ +------+ (```). +------+ | (````). +-----+ | +-----+ +------+ (```). +------+ | (````). +-----+
| | SUB |-->| EMU |--(x-haul'.-->| EPC |--->( PDN ).-->| CDN | | | SUB |-->| EMU |--(x-haul'.-->| EPC |--->( PDN ).-->| CDN |
| +-----+ +------+ `__..'' +------+ | `__...' +-----+ | +-----+ +------+ `__..'' +------+ | `__...' +-----+
+------------------------------------------+ +------------------------------------------+
4G Mobile Network Functions 4G Mobile Network Functions
skipping to change at line 840 skipping to change at line 981
</t> </t>
<figure anchor="fig_native_icn_deployment_lab_setup"> <figure anchor="fig_native_icn_deployment_lab_setup">
<name>Native ICN Deployment Lab Setup</name> <name>Native ICN Deployment Lab Setup</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+------------------------------------------+ +------------------------------------------+
| +-----+ +------+ (```). +------+ | (````). +-----+ | +-----+ +------+ (```). +------+ | (````). +-----+
| | SUB |-->| EMU |--(x-haul'.-->| EPC |--->( PDN ).-->| CDN | | | SUB |-->| EMU |--(x-haul'.-->| EPC |--->( PDN ).-->| CDN |
| +-----+ +------+ `__..'' +------+ | `__...' +-----+ | +-----+ +------+ `__..'' +------+ | `__...' +-----+
+------------------------------------------+ +------------------------------------------+
4G Mobile Network Functions 4G Mobile Network Functions
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The following test scenarios can be set up with VM-based deployment:
<t>The following test scenarios can be set up with deployment based on Vi
rtual Machine (VM):
</t> </t>
<ol spacing="normal" type="1"><li>SUB: ICN simulated client (using ndnSI
M), a client application on workstation requesting content.</li> <ol>
<li>EMU: test unit emulating eNodeB. This will be a test node allowing <li>SUB: An ICN-simulated client (using ndnSIM) - a client application
for UE attachment and routing traffic subsequently from the Subscriber to the P on a workstation requesting content.
ublisher.</li> </li>
<li>EPC: Evolved Packet Core in a single instance (such as 5GOpenCore
<xref target="Open5GCore" format="default"/>).</li> <li>EMU: Test unit emulating an eNodeB. This is a test node allowing fo
<li>CDN: content delivery by a Publisher server.</li> r UE
</ol> attachment and routing traffic subsequently from the Subscriber to
<t>For the purpose of this testing, ICN emulating code can be inserted i the Publisher.
n the test code in EMU to emulate ICN-capable eNodeB. An example of the code to </li>
be used is NS3 in its LTE model. Effect of such traffic on EPC and CDN can be ob <li>EPC: Evolved Packet Core in a single instance (such as Open5GCore <
served and documented. In a subsequent phase, EPC code supporting ICN can be te xref target="Open5GCore" format="default"/>).
sted when available. </li>
<li>CDN: Content delivery by a Publisher server.
</li>
</ol>
<t>For the purpose of this testing, ICN-emulating code can be inserted in the te
st code in EMU to emulate an ICN-capable eNodeB. An example of the code to be us
ed is NS3 in its LTE model. The effect of such traffic on EPC and CDN can be obs
erved and documented. In a subsequent phase, EPC code supporting ICN can be tes
ted when available.
</t> </t>
<t>Another option is to simulate the UE/eNodeB and EPC functions using N S3's LTE <xref target="NS3LTE" format="default"/> and EPC <xref target="NS3EPC" format="default"/> models respectively. LTE model includes the LTE Radio Protoco l stack, which resides entirely within the UE and the eNodeB nodes. This capabil ity provides the simulation of UE and eNodeB deployment use cases. Similarly, EP C model includes core network interfaces, protocols, and entities, which reside within the SGW, PGW and MME nodes, and partially within the eNodeB nodes. <t>Another option is to simulate the UE/eNodeB and EPC functions using N S3's LTE <xref target="NS3LTE" format="default"/> and EPC <xref target="NS3EPC" format="default"/> models, respectively. The LTE model includes the LTE Radio Pr otocol stack, which resides entirely within the UE and the eNodeB nodes. This ca pability provides the simulation of UE and eNodeB deployment use cases. Similarl y, the EPC model includes core network interfaces, protocols, and entities, whic h reside within the Mobile Gateways (SGW/PGW), and MME nodes and partially withi n the eNodeB nodes.
</t> </t>
<t>Even with its current limitations (such as IPv4 only, lack of integra tion with ndnSIM, no support for UE idle state), LTE simulation may be a very us eful tool. In any case, both control and user plane traffic should be tested in dependently according to the deployment model discussed in <xref target="icn_dep loyment_in_4g_user_plane" format="default"/>. <t>Even with its current limitations (such as IPv4 only, lack of integra tion with ndnSIM, and no support for UE idle state), LTE simulation may be a ver y useful tool. In any case, both control and user-plane traffic should be teste d independently according to the deployment model discussed in <xref target="icn _deployment_in_4g_user_plane" format="default"/>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="expected_experiment_outcome" numbered="true" toc="default"> <section anchor="expected_experiment_outcome" numbered="true" toc="default">
<name>Expected Outcomes from Experimentation</name> <name>Expected Outcomes from Experimentation</name>
<t>The experimentations explained in <xref target="icn_deploy_4g_networks" format="default"/> can be categorized in three broader scopes as follows. Note that, a further research and study is required to fully understand and document the impact. <t>The experimentation explained in <xref target="icn_deploy_4g_networks" format="default"/> can be categorized in three broader scopes as follows. Note t hat further research and study is required to fully understand and document the impact.
</t> </t>
<ol spacing="normal" type="1"><li>Architecture scope: to study the aspect <dl>
of use of ICN at user plane to reduce the complexities in current transport prot <dt>Architecture scope:
ocols, while also evaluating its use in the control plane.</li> </dt>
<li>Performance scope: to evaluate the gains through multicast, caching, <dd>to study the aspect of use of ICN at the user
and other ICN features.</li> plane to reduce the complexities in current transport protocols while
<li>Deployment scope: to check the viability of the ICN inclusion in 3GP also evaluating its use in the control plane.
P protocol stack and its viability in real-world deployments.</li> </dd>
</ol>
<dt>Performance scope:
</dt>
<dd>to evaluate the gains through multicast, caching, and other
ICN features.
</dd>
<dt>Deployment scope:
</dt>
<dd>to check the viability of ICN inclusion in the 3GPP protocol
stack and in real-world deployments.
</dd>
</dl>
<section anchor="feeding_into_icn_research" numbered="true" toc="default"> <section anchor="feeding_into_icn_research" numbered="true" toc="default">
<name>Feeding into ICN Research</name> <name>Feeding into ICN Research</name>
<t>Specifically, we have identified the following open questions, from t he architectural and performance perspective, that the proposed experiments with ICN implementation scenarios in 4G mobile networks could address in further res earch: <t>Specifically, we have identified the following open questions, from t he architectural and performance perspective, that the proposed experiments with ICN implementation scenarios in 4G mobile networks could address in further res earch:
</t> </t>
<ol spacing="normal" type="1"><li>Efficiency gains in terms of the amoun <ol spacing="normal" type="1">
t of traffic in multicast scenarios (i.e., quantify the possible gains along dif <li>Efficiency gains in terms of the amount of traffic in multicast sce
ferent use cases) and the efficiency gained in terms of latency for cached conte narios (i.e., quantify the possible gains along different use cases) and latency
nt, mainly in the CDN use case.</li> for cached content, mainly in the CDN use case.</li>
<li>How the new transport would coexist or replace the legacy transpor t protocols (e.g., IPv4, IPv6, MPLS, RSVP, etc.) and related services (e.g., ban dwidth management, QoS handling, etc.).</li> <li>How the new transport would coexist or replace the legacy transpor t protocols (e.g., IPv4, IPv6, MPLS, RSVP, etc.) and related services (e.g., ban dwidth management, QoS handling, etc.).</li>
<li>To what extent the simplification in the IP-based transport protoc <li>To what extent the simplification in the IP-based transport protoc
ols will be achieved. The multiple overlays (e.g., the MPLS, VPN, VPLS, Ethernet ols will be achieved. The multiple overlays (e.g., the MPLS, VPN, Virtual Privat
VPN, etc.) of services in the current IP-based transport adds to the complexity e LAN Service (VPLS), Ethernet VPN, etc.) of services in the current IP-based tr
on top of basic IP transport. This makes the troubleshooting extremely challeng ansport adds to the complexity on top of basic IP transport. This makes the trou
ing.</li> bleshooting extremely challenging.</li>
<li>How the new transport can become service-aware such that it brings <li>How the new transport can become service aware such that it brings
in more simplicity in the system.</li> in more simplicity in the system.</li>
<li>Confirm how (in)adequate would be ICN implementation in control pl
ane (which this draft discourages). Given that the 5G system, as specified in <x <li>Confirm how (in)adequate ICN implementation would be in the contro
ref target="TS23.501" format="default"/> (Appendix G.4), encourages the use of n l plane (which this document discourages). Given that the 5G system, as specifie
ame-based routing in (5G) control plane for realizing the 5G-specific service-ba d in <xref target="TS23.501" format="default"/> (Appendix G.4), encourages the u
sed architecture for control plane services (so-called network function service) se of name-based routing in the (5G) control plane for realizing the 5G-specific
, it would be worthwhile to investigate whether the 4G control plane would benef service-based architecture for control plane services (so-called network functi
it similarly from such use or whether specific 4G architectural constraints woul on service), it would be worthwhile to investigate whether the 4G control plane
d prevent ICN from providing any notable benefit.</li> would benefit similarly from such use or whether specific 4G architectural const
raints would prevent ICN from providing any notable benefit.</li>
</ol> </ol>
</section> </section>
<section anchor="beyond_research" numbered="true" toc="default"> <section anchor="beyond_research" numbered="true" toc="default">
<name>Use of Results Beyond Research</name> <name>Use of Results Beyond Research</name>
<t>With the experiments and their outcomes outlined in this draft, we be lieve that this technology is ready for a wider use and adoption, providing addi tional insights. Specifically, we expect to study the following: <t>With the experiments and their outcomes outlined in this document, we believe that this technology is ready for a wider use and adoption, providing a dditional insights. Specifically, we expect to study the following:
</t> </t>
<ol spacing="normal" type="1"><li>Viability of ICN inclusion in the 3GPP <ol spacing="normal" type="1"><li>Viability of ICN inclusion in the 3GPP
protocol stack, i.e., investigate how realistic it would be to modify the stack protocol stack, i.e., investigating how realistic it would be to modify the sta
, considering the scenarios explained in <xref target="icn_deployment_in_4g_user ck, considering the scenarios explained in <xref target="icn_deployment_in_4g_us
_plane" format="default"/>, and complete the user session without feature degrad er_plane" format="default"/>, and completing the user session without feature de
ation?</li> gradation.</li>
<li>Viability of utilizing solutions in greenfield deployments, i.e., <li>Viability of utilizing solutions in greenfield deployments, i.e.,
deploying the ICN-based extensions and solutions proposed in this draft in green deploying the ICN-based extensions and solutions proposed in this document in gr
field 4G deployments in order to assess real-world benefits when doing so.</li> eenfield 4G deployments in order to assess real-world benefits when doing so.</l
i>
</ol> </ol>
</section> </section>
</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="defau lt"> <section anchor="security_privacy_considerations" numbered="true" toc="defau lt">
<name>Security and Privacy Considerations</name> <name>Security and Privacy Considerations</name>
<t>This section will cover some security and privacy considerations in mob ile and 4G network because of introduction of ICN.</t> <t>This section will cover some security and privacy considerations in mob ile and 4G networks because of the introduction of ICN.</t>
<section anchor="security_considerations" numbered="true" toc="default"> <section anchor="security_considerations" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>To ensure only authenticated mobile terminals are connected to the ne twork, 4G mobile network implements various security mechanisms. From the perspe ctive of using ICN in the user plane, it needs to take care of the following sec urity aspects:
<t>To ensure only authenticated mobile terminals are connected to the ne twork, 4G mobile networks implement various security mechanisms. From the perspe ctive of using ICN in the user plane, the following security aspects need to be taken care of:
</t> </t>
<ol spacing="normal" type="1"><li>MT authentication and authorization</l i> <ol spacing="normal" type="1"><li>MT authentication and authorization</l i>
<li>Radio or air interface security</li> <li>Radio or air interface security</li>
<li>Denial of service attacks on the mobile gateway, services either b <li>Denial-of-service attacks on the Mobile Gateway; services are eith
y the MT or by external entities in the Internet</li> er by the MT or by external entities in the Internet</li>
<li>Content poisoning either in transport or servers</li> <li>Content poisoning in either transport or servers</li>
<li>Content cache pollution attacks</li> <li>Content cache pollution attacks</li>
<li>Secure naming, routing, and forwarding</li> <li>Secure naming, routing, and forwarding</li>
<li>Application security</li> <li>Application security</li>
</ol> </ol>
<t>Security over the LTE air interface is provided through cryptographic techniques. When MT is powered up, it performs a key exchange between MT's USIM and HSS/Authentication Center using NAS messages, including ciphering and integ rity protections between MT and MME. Details for secure MT authentication, key e xchange, ciphering, and integrity protections messages are given in the 3GPP cal l flow <xref target="TS23.401" format="default"/>. With ICN we are modifying pro tocol stack for user plane and not control plane. The NAS signaling is exchanged between MT and mobile gateways e.g. MME, using control plane, therefore there i s no adverse impact of ICN on MT. <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 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 excha nge, ciphering, and integrity protection messages are given in the 3GPP call flo w <xref target="TS23.401" format="default"/>. With ICN, we are modifying the pro tocol stack for the user plane and not the control plane. The NAS signaling is e xchanged between MT and Mobile Gateways, e.g., MME, using the control plane; the refore, there is no adverse impact of ICN on MT.
</t> </t>
<t>4G uses IP transport in its mobile backhaul (between eNodeB and core network). In case of provider-owned backhaul, service provider may require imple menting a security mechanism in the backhaul network. The native IP transport co ntinues to leverage security mechanism such as Internet key exchange (IKE) and t he IP security protocol (IPsec). More details of mobile backhaul security are pr ovided in 3GPP network security specifications <xref target="TS33.310" format="d efault"/> and <xref target="TS33.320" format="default"/>. When mobile backhaul i s upgraded to support dual transport (IP+ICN) or native ICN, it is required to i mplement security techniques that are deployed in the mobile backhaul. When ICN forwarding is enabled on mobile transport routers, we need to deploy security pr actices based on <xref target="RFC7476" format="default"/> and <xref target="RFC 7927" format="default"/>. <t>4G uses IP transport in its mobile backhaul (between an eNodeB and th e core network). In case of provider-owned backhaul, the Service Provider may re quire implementing a security mechanism in the backhaul network. The native IP t ransport continues to leverage security mechanisms such as Internet Key Exchange (IKE) and the IP Security (IPsec) protocol. More details of mobile backhaul sec urity are provided in 3GPP network security specifications <xref target="TS33.31 0" format="default"/> and <xref target="TS33.320" format="default"/>. When a mob ile 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 backh aul. When ICN forwarding is enabled on mobile transport routers, we need to depl oy security practices based on <xref target="RFC7476" format="default"/> and <xr ef target="RFC7927" format="default"/>.
</t> </t>
<t>4G mobile gateways (SGW, PGW) perform some of key functions such as c ontent based online/offline billing and accounting, deep packet inspection (DPI) , and lawful interception (LI). When ICN is deployed in user plane , we need to integrate ICN security for sessions between MT and gateway. If we encrypt user p lane payload metadata then it might be difficult to perform routing based on con tents 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 con sumer to ensure privacy. Only the user with right decryption key shall be able t o access the content. We need further research for ICN impact on LI, online/offl ine charging and accounting. </t> <t>4G Mobile Gateways (SGW/PGW) perform some key functions such as conte nt-based online/offline billing and accounting, deep packet inspection (DPI), an d lawful interception (LI). When ICN is deployed in the user plane, we need to i ntegrate ICN security for sessions between MT and the gateway. If we encrypt use r-plane payload metadata, then it might be difficult to perform routing based on contents and it may not work because we need decryption keys at every forwarder to route the content. The content itself can be encrypted between publisher and consumer to ensure privacy. Only the user with the right decryption key shall b e able to access the content. We need further research for ICN impact on LI, onl ine/offline charging, and accounting. </t>
</section> </section>
<section anchor="privacyconsiderations" numbered="true" toc="default"> <section anchor="privacyconsiderations" numbered="true" toc="default">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>In 4G networks, two main privacy issues are <xref target="MUTHANA" fo rmat="default"/> <t>In 4G networks, there are two main privacy issues <xref target="MUTHA NA" format="default"/>:
</t> </t>
<ol spacing="normal" type="1"><li>User Identity Privacy Issues. The main
privacy issue within the 4G is the exposure of the IMSI. The IMSI can be interc <ol spacing="normal" type="1"><li>User Identity Privacy Issues. The main
epted by adversaries. Such attacks are commonly referred to as "IMSI catching".< privacy issue within 4G is the exposure of the International Mobile Subscriber
/li> Identity (IMSI). The IMSI can be intercepted by adversaries. Such attacks are co
<li>Location Privacy Issues. IMSI Catching is closely related to the i mmonly referred to as "IMSI catching".</li>
ssue of location privacy. Knowing IMSI of user allows the attacker to track the
user's movements and create profile about the user and thus breaches the user's <li>Location Privacy Issues. IMSI catching is closely related to the i
location privacy.</li> ssue of location privacy. Knowing the IMSI of a user allows the attacker to trac
k the user's movements and create a profile about the user and thus breach the u
ser's location privacy.</li>
</ol> </ol>
<t>In any network, caching implies a trade-off between network efficienc y 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 transactio ns, an attacker could obtain significant information related to the objects acce ssed, 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 lookup and Network storage, and different forms of communic ation <xref target="FOTIOU" format="default"/>. Privacy risks in ICN can be broa dly divided in the following categories <xref target="TOURANI" format="default"/ >: <t>In any network, caching implies a trade-off between network efficienc y 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 transactio ns, an attacker could obtain significant information related to the objects acce ssed, topology, and timing of the requests <xref target="RFC7945" format="defaul t"/>. Privacy concerns are amplified by the introduction of new network function s such as information lookup and network storage, and different forms of communi cation <xref target="FOTIOU" format="default"/>. Privacy risks in ICN can be bro adly divided in the following categories <xref target="TOURANI" format="default" />:
</t> </t>
<ol spacing="normal" type="1"><li>Timing attack</li> <ol spacing="normal" type="1"><li>Timing attack</li>
<li>Communication monitoring attack</li> <li>Communication monitoring attack</li>
<li>Censorship and anonymity attack</li> <li>Censorship and anonymity attack</li>
<li>Protocol attack</li> <li>Protocol attack</li>
<li>Naming-signature privacy</li> <li>Naming-signature privacy</li>
</ol> </ol>
<t>Introduction of TCL effectively enables ICN at the application and/or transport layer, depending on the scenario described in section 5. Enabling ICN in 4G networks is expected to increase efficiency by taking advantage of ICN's inherent characteristics. This approach would potentially leave some of the abov e-mentioned privacy concerns open as a consequence of using ICN transport and IC N inherent privacy vulnerabilities. <t>The introduction of TCL effectively enables ICN at the application an d/or transport layer depending on the scenario described in <xref target="icn_de ploy_4g_networks"/>. Enabling ICN in 4G networks is expected to increase efficie ncy by taking advantage of ICN's inherent characteristics. This approach would p otentially leave some of the above-mentioned privacy concerns open as a conseque nce of using ICN transport and ICN inherent privacy vulnerabilities.
</t> </t>
<ol spacing="normal" type="1"><li>IPoIP <xref target="icn_deployment_sce
narios" format="default"/> would not be affected as TCL has no role in it and IC <ol spacing="normal" type="1"><li>IPoIP (<xref target="icn_deployment_sc
N does not apply</li> enarios" format="default"/>) would not be affected as TCL has no role in it, and
<li>ICNoICN scenario <xref target="icn_deployment_scenarios" format="d ICN does not apply.</li>
efault"/> has increased risk of a privacy attack, and that risk is applicable to
ICN protocol in general rather than specifically to the 4G implementation. Sinc <li>The ICNoICN scenario (<xref target="icn_deployment_scenarios" form
e this scenario describes communication over ICN transport, every forwarder in t at="default"/>) has increased risk of a privacy attack, and that risk is applica
he path could be a potential risk for privacy attack</li> ble to the ICN protocol in general rather than specifically to the 4G implementa
<li>ICNoIP scenario <xref target="icn_deployment_scenarios" format="de tion. Since this scenario describes communication over ICN transport, every forw
fault"/> uses IP for transport, so the only additional ICN-related potential pri arder in the path could be a potential risk for a privacy attack.</li>
vacy risk areas are the endpoints (consumer and publisher) where, at the applica <li>The ICNoIP scenario (<xref target="icn_deployment_scenarios" forma
tion layer, content is being served</li> t="default"/>) uses IP for transport, so the only additional ICN-related potenti
<li>IPoICN scenario <xref target="icn_deployment_scenarios" format="de al privacy risk areas are the endpoints (consumer and publisher) where, at the a
fault"/> could have potentially increased risk due to possible vulnerability of pplication layer, content is being served.</li>
the forwarders in the path of ICN transport</li> <li>The IPoICN scenario (<xref target="icn_deployment_scenarios" forma
t="default"/>) could have potentially increased risk due to possible vulnerabili
ty of the forwarders in the path of ICN transport.</li>
</ol> </ol>
<t>Privacy issues already identified in 4G remain a concern if ICN is in
troduced in any of the scenarios described earlier and compound to the new, ICN- <t>Privacy issues already identified in 4G remain a concern if ICN is in
related privacy issues. Many research papers have been published proposing solut troduced in any of the scenarios described earlier and compounds to the new ICN-
ions to the privacy issues listed above. For LTE-specific privacy issues, some o related privacy issues. Many research papers have been published that propose so
f the proposed solutions <xref target="MUTHANA" format="default"/> are IMSI encr lutions to the privacy issues listed above. For LTE-specific privacy issues, som
yption by a MT, mutual authentication, concealing the real IMSI within a random e of the proposed solutions <xref target="MUTHANA" format="default"/> are IMSI e
bit stream of certain size where only the subscriber and HSS could extract the r ncryption by an MT; mutual authentication; concealing the real IMSI within a ran
espective IMSI, IMSI replacement with a changing pseudonym that only the HSS ser dom bit stream of certain size where only the subscriber and HSS could extract t
ver can map it the UE's IMSI, and others. Similarly, some of the proposed ICN-sp he respective IMSI; IMSI replacement with a changing pseudonym that only the HSS
ecific privacy concerns mitigation methods, applicable where ICN transport is in server can map to the UE's IMSI; and others. Similarly, some of the proposed IC
troduced as specified earlier in this section, include <xref target="FOTIOU" for N-specific privacy concerns mitigation methods, applicable where ICN transport i
mat="default"/>: s introduced as specified earlier in this section, include the following <xref t
arget="FOTIOU" format="default"/>:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>Delay for the first, or first k interests on edge routers (timing attack)</li> <li>Delay for the first, or first k, interests on edge routers (timing attack)</li>
<li>Creating a secure tunnel or clients flagging the requests as non-c acheable for privacy (communication monitoring attack)</li> <li>Creating a secure tunnel or clients flagging the requests as non-c acheable for privacy (communication monitoring attack)</li>
<li>Encoding interest by mixing content and cover file or using hierar chical DNS-based brokering model (censorship and anonymity 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 a ttack)</li> <li>Use of rate-limiting requests for a specific namespace (protocol a ttack)</li>
<li>Cryptographic content hash-based naming or digital identity in an overlay network (naming-signature privacy)</li> <li>Cryptographic content hash-based naming or digital identity in an overlay network (naming-signature privacy)</li>
</ul> </ul>
<t>Further research in this area is needed. Detailed discussion of priva cy is beyond the scope of this document.</t> <t>Further research in this area is needed. Detailed discussion of priva cy is beyond the scope of this document.</t>
</section> </section>
</section> </section>
<section anchor="summary" numbered="true" toc="default"> <section anchor="summary" numbered="true" toc="default">
<name>Summary</name> <name>Summary</name>
<t>In this draft, we have discussed the 4G networks and the experimental s etups to study the advantages of potential use of ICN for efficient delivery of contents to mobile terminals. We have discussed different options to try and tes t the ICN and dependencies such as ICN functionalities and changes required in d ifferent 4G network elements. In order to further explore potential use of ICN o ne can devise an experimental set-up consisting of 4G network elements and deplo y ICN data transport in user plane. Different options can be either overlay, dua l transport (IP + ICN), hICN, or natively (by integrating ICN with CDN, eNodeB, SGW, PGW and transport network). Note that, for the scenarios discussed above, a dditional study is required for lawful interception, billing/mediation, network slicing, and provisioning APIs. <t>In this document, we have discussed 4G networks and the experimental se tups 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 ICN and dependencies such as ICN functionalities and changes required in di fferent 4G network elements. In order to further explore potential use of ICN, o ne can devise an experimental setup consisting of 4G network elements and deploy ICN data transport in the user plane. Different options can be overlay, dual tr ansport (IP + ICN), hICN, or natively (by integrating ICN with CDN, eNodeB, SGW, PGW, and a transport network). Note that, for the scenarios discussed above, ad ditional study is required for lawful interception, billing/mediation, network s licing, and provisioning APIs.
</t> </t>
<t>Edge Computing <xref target="CHENG" format="default"/> provides capabil ities to deploy functionalities such as Content Delivery Network (CDN) caching a nd mobile user plane functions (UPF) <xref target="TS23.501" format="default"/>. Recent research for delivering real-time video content <xref target="MPVCICN" f ormat="default"/> using ICN has also been proven to be efficient <xref target="N DNRTC" format="default"/> and can be used towards realizing the benefits of usin g ICN in eNodeB, edge computing, mobile gateways (SGW, PGW) and CDN. The key asp ect for ICN is in its seamless integration in 4G and 5G networks with tangible b enefits so we can optimize content delivery using a simple and scalable architec ture. The authors will continue to explore how ICN forwarding in edge computing could be used for efficient data delivery from the mobile edge. <t>Edge Computing <xref target="CHENG" format="default"/> provides capabil ities to deploy functionalities such as CDN caching and mobile user plane functi ons (UPFs) <xref target="TS23.501" format="default"/>. Recent research for deliv ering real-time video content <xref target="MPVCICN" format="default"/> using IC N 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 c omputing, Mobile Gateways (SGW/PGW), and CDN. The key aspect for ICN is in its s eamless integration in 4G and 5G networks with tangible benefits so we can optim ize content delivery using a simple and scalable architecture. The authors will continue to explore how ICN forwarding in edge computing could be used for effic ient data delivery from the mobile edge.
</t> </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>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 user plane, it is proposed to <t>As a starting step towards use of ICN in the user plane, it is proposed
incorporate protocol changes in MT, eNodeB, SGW/PGW for data transport. ICN has to incorporate protocol changes in MT, an eNodeB, and SGW/PGW for data transpor
inherent capabilities for mobility and content caching, which can improve the ef t. ICN has inherent capabilities for mobility and content caching, which can imp
ficiency of data transport for unicast and multicast delivery. The authors welco rove the efficiency of data transport for unicast and multicast delivery. The au
me contributions and suggestions, including those related to further validations thors welcome contributions and suggestions, including those related to further
of the principles by implementing prototype and/or proof of concept in the lab validations of the principles by implementing prototypes and/or proof of concept
and in the production environment.</t> s 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 t
ime in providing comments and feedback that helped improve this draft. We specia
lly want to mention the following members of the IRTF Information-Centric Networ
king 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>
<!-- <section anchor="iana" title="IANA Considerations">
<t>This draft includes no request to IANA.</t>
</section> -->
</middle> </middle>
<!-- Back section -->
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<!-- <reference anchor="IPSEC1"
target="https://cway.cisco.com/tools/ipsec-overhead-calc/ips
ec-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/h tml-info/25323.htm"> <reference anchor="TS25.323" target="https://www.3gpp.org/ftp/Specs/ html-info/25323.htm">
<front> <front>
<title>Packet Data Convergence Protocol (PDCP) specification</title> <title>Packet Data Convergence Protocol (PDCP) specification</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date day="18" month="September" year="2002"/> <date month="April" year="2022"/>
</front> </front>
<seriesInfo name="3GPP TS" value="25.323 3.10.0"/> <seriesInfo name="3GPP TS" value="25.323 17.0.0"/>
</reference> </reference>
<reference anchor="TS24.008" target="http://www.3gpp.org/ftp/Specs/html-
info/24008.htm"> <reference anchor="TS24.008" target="https://www.3gpp.org/ftp/Specs/html
-info/24008.htm">
<front> <front>
<title>Mobile radio interface Layer 3 specification; Core network pr otocols; Stage 3</title> <title>Mobile radio interface Layer 3 specification; Core network pr otocols; Stage 3</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date day="15" month="December" year="2005"/> <date month="June" year="2022"/>
</front> </front>
<seriesInfo name="3GPP TS" value="24.008 3.20.0"/> <seriesInfo name="3GPP TS" value="24.008 17.7.0"/>
<refcontent></refcontent>
</reference> </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"/>
</front>
<seriesInfo name="3GPP TS" value="23.214 10.6.0"/>
<format type="HTML" target="http://www.3gpp.org/ftp/Specs/html-i
nfo/23214.htm"/>
</reference> -->
<reference anchor="TS36.323" target="http://www.3gpp.org/ftp/Specs/h tml-info/36323.htm"> <reference anchor="TS36.323" target="https://www.3gpp.org/ftp/Specs/html -info/36323.htm">
<front> <front>
<title>Evolved Universal Terrestrial Radio Access (E-UTRA); Packet D ata Convergence Protocol (PDCP) specification</title> <title>Evolved Universal Terrestrial Radio Access (E-UTRA); Packet D ata Convergence Protocol (PDCP) specification</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date day="03" month="January" year="2013"/> <date month="July" year="2022"/>
</front> </front>
<seriesInfo name="3GPP TS" value="36.323 10.2.0"/> <seriesInfo name="3GPP TS" value="36.323 17.1.0"/>
</reference> </reference>
<reference anchor="TS29.274" target="http://www.3gpp.org/ftp/Specs/html-
info/29274.htm"> <reference anchor="TS29.274" target="https://www.3gpp.org/ftp/Specs/html
-info/29274.htm">
<front> <front>
<title>3GPP Evolved Packet System (EPS); Evolved General Packet Radi o Service (GPRS) Tunneling Protocol for Control plane (GTPv2-C); Stage 3</title> <title>3GPP Evolved Packet System (EPS); Evolved General Packet Radi o Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3</title >
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date day="25" month="June" year="2013"/> <date month="June" year="2022"/>
</front> </front>
<seriesInfo name="3GPP TS" value="29.274 10.11.0"/> <seriesInfo name="3GPP TS" value="29.274 17.6.0"/>
</reference> </reference>
<reference anchor="TS29.281" target="http://www.3gpp.org/ftp/Specs/html-
info/29281.htm"> <reference anchor="TS29.281" target="https://www.3gpp.org/ftp/Specs/html
-info/29281.htm">
<front> <front>
<title>General Packet Radio System (GPRS) Tunneling Protocol User Pl ane (GTPv1-U)</title> <title>General Packet Radio System (GPRS) Tunnelling Protocol User P lane (GTPv1-U)</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date day="26" month="September" year="2011"/> <date month="June" year="2022"/>
</front> </front>
<seriesInfo name="3GPP TS" value="29.281 10.3.0"/> <seriesInfo name="3GPP TS" value="29.281 17.3.0"/>
</reference> </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 o
ften 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>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<!-- Here we use entities that we defined at the beginning. -->
<!-- <reference anchor="TS23.203" target="https://www.3gpp.org/ftp/Specs/html
&RFC2629; -info/23203.htm">
&RFC3552;
<reference anchor="IPSEC2" target="http://packetpushers.net/ipsec-ba
ndwidth-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/h
tml-info/23203.htm">
<front> <front>
<title>Policy and charging control architecture</title> <title>Policy and charging control architecture</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date day="12" month="September" year="2013"/> <date month="December" year="2021"/>
</front> </front>
<seriesInfo name="3GPP TS" value="23.203 10.9.0"/> <seriesInfo name="3GPP TS" value="23.203 17.2.0"/>
</reference> </reference>
<reference anchor="TS23.401" target="http://www.3gpp.org/ftp/Specs/html-
info/23401.htm"> <reference anchor="TS23.401" target="https://www.3gpp.org/ftp/Specs/html
-info/23401.htm">
<front> <front>
<title>General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access</title> <title>General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date day="07" month="March" year="2013"/> <date month="June" year="2022"/>
</front> </front>
<seriesInfo name="3GPP TS" value="23.401 10.10.0"/> <seriesInfo name="3GPP TS" value="23.401 17.5.0"/>
</reference> </reference>
<reference anchor="TS23.501" target="http://www.3gpp.org/ftp/Specs/html-
info/23501.htm"> <reference anchor="TS23.501" target="https://www.3gpp.org/ftp/Specs/html
-info/23501.htm">
<front> <front>
<title>System Architecture for the 5G System</title> <title>System architecture for the 5G System (5GS)</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date day="15" month="June" year="2018"/> <date month="June" year="2022"/>
</front> </front>
<seriesInfo name="3GPP TS" value="23.501 15.2.0"/> <seriesInfo name="3GPP TS" value="23.501 17.5.0"/>
</reference> </reference>
<reference anchor="TS23.714" target="http://www.3gpp.org/ftp/Specs/html-
info/23714.htm"> <reference anchor="TS23.714" target="https://www.3gpp.org/ftp/Specs/html-
info/23714.htm">
<front> <front>
<title>Technical Specification Group Services and System Aspects: St <title>
udy on control and user plane separation of EPC nodes</title> Study on Control Plane (CP) and User Plane (UP) separation of Evolved Packet Cor
e (EPC) nodes</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date day="04" month="June" year="2016"/> <date month="June" year="2016"/>
</front> </front>
<seriesInfo name="3GPP TS" value="23.714 0.2.2"/> <seriesInfo name="3GPP TS" value="23.714 14.0.0"/>
</reference> </reference>
<reference anchor="TS29.060" target="http://www.3gpp.org/ftp/Specs/html-
info/29060.htm"> <reference anchor="TS29.060" target="https://www.3gpp.org/ftp/Specs/html
-info/29060.htm">
<front> <front>
<title>General Packet Radio Service (GPRS); GPRS Tunneling Protocol (GTP) across the Gn and Gp interface</title> <title>General Packet Radio Service (GPRS); GPRS Tunneling Protocol (GTP) across the Gn and Gp interface</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date day="24" month="March" year="2004"/> <date month="June" year="2022"/>
</front> </front>
<seriesInfo name="3GPP TS" value="29.060 3.19.0"/> <seriesInfo name="3GPP TS" value="29.060 17.3.0"/>
</reference> </reference>
<reference anchor="TS33.310" target="http://www.3gpp.org/ftp/Specs/html-
info/33310.htm"> <reference anchor="TS29.336" target="https://www.3gpp.org/ftp/Specs/html
-info/29336.htm">
<front> <front>
<title>Network Domain Security (NDS); Authentication Framework (AF)< <title>Home Subscriber Server (HSS) diameter interfaces for interwor
/title> king with
packet data networks and applications</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date day="21" month="December" year="2012"/> <date month="March" year="2022"/>
</front> </front>
<seriesInfo name="3GPP TS" value="33.310 10.7.0"/> <seriesInfo name="3GPP TS" value="29.336 17.13.1"/>
</reference> </reference>
<reference anchor="TS33.320" target="http://www.3gpp.org/ftp/Specs/html-
info/33320.htm"> <reference anchor="TS33.310" target="https://www.3gpp.org/ftp/Specs/html
-info/33310.htm">
<front> <front>
<title>Security of Home Node B (HNB) / Home evolved Node B (HeNB)</t itle> <title>Network Domain Security (NDS); Authentication Framework (AF)< /title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date day="29" month="June" year="2012"/> <date month="June" year="2022"/>
</front> </front>
<seriesInfo name="3GPP TS" value="33.320 10.5.0"/> <seriesInfo name="3GPP TS" value="33.310 17.3.0"/>
</reference> </reference>
<!--
<reference anchor="TS23.501" target="http://www.3gpp.org/ftp/Specs/h
tml-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-i
nfo/23501.htm"/>
</reference>
-->
<reference anchor="RFC7476" target="https://www.rfc-editor.org/info/ <reference anchor="TS33.320" target="https://www.3gpp.org/ftp/Specs/html-info/33
rfc7476"> 320.htm">
<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/rfc7
927">
<front>
<title>Information-Centric Networking (ICN) Research Challenges</tit
le>
<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/rfc4
594">
<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/rfc6
459">
<front> <front>
<title>IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Pac <title>Security of Home Node B (HNB) / Home evolved Node B (HeNB)</t
ket System (EPS)</title> itle>
<author initials="J." surname="Korhonen" fullname="J. Korhonen" role <author>
="editor"> <organization>3GPP</organization>
<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> </author>
<date year="2012" month="January"/> <date month="March" year="2022"/>
</front> </front>
<seriesInfo name="RFC" value="6459"/> <seriesInfo name="3GPP TS" value="33.320 17.0.0"/>
<seriesInfo name="DOI" value="10.17487/RFC6459"/>
</reference> </reference>
<reference anchor="GRAYSON" target="http://www.ciscopress.com/store/ip-d
esign-for-mobile-networks-9781587058264"> <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="https://www.ciscopress.com/store/ip-
design-for-mobile-networks-9781587058264">
<front> <front>
<title> <title>IP Design for Mobile Networks
Cisco Press book "IP Design for Mobile Networks"
</title> </title>
<author initials="M" surname="Grayson" fullname=""> <author initials="M" surname="Grayson" fullname="Mark Grayson">
<organization/> <organization/>
</author> </author>
<author initials="M" surname="Shatzkamer" fullname=""> <author initials="M" surname="Shatzkamer" fullname="Kevin Shatzkamer ">
<organization/> <organization/>
</author> </author>
<author initials="S" surname="Wainner" fullname=""> <author initials="S" surname="Wainner" fullname="Scott Wainner">
<organization/> <organization/>
</author> </author>
<date month="June" day="15" year="2009"/> <date month="June" year="2009"/>
</front> </front>
<seriesInfo name="Cisco Press" value="Networking Technology series"/> <refcontent>Cisco Press</refcontent>
<refcontent>Networking Technology series</refcontent>
<seriesInfo name="ISBN" value="1-58705-826-X"/>
</reference> </reference>
<reference anchor="BROWER" target="https://ieeexplore.ieee.org/document/ 4086687"> <reference anchor="BROWER" target="https://ieeexplore.ieee.org/document/ 4086687">
<front> <front>
<title> <title>Integrating Header Compression with IPsec</title>
Integrating Header Compression with IPsec <author initials="E" surname="Brower" fullname="Etzel Brower">
</title>
<author initials="E" surname="Brower" fullname="">
<organization/> <organization/>
</author> </author>
<author initials="L" surname="Jeffress" fullname=""> <author initials="L" surname="Jeffress" fullname="LaTonya Jeffress">
<organization/> <organization/>
</author> </author>
<author initials="J" surname="Pezeshki" fullname=""> <author initials="J" surname="Pezeshki" fullname="Jonah Pezeshki">
<organization/> <organization/>
</author> </author>
<author initials="R" surname="Jasani" fullname=""> <author initials="R" surname="Jasani" fullname="Rohan Jasani">
<organization/> <organization/>
</author> </author>
<author initials="E" surname="Ertekin" fullname=""> <author initials="E" surname="Ertekin" fullname="Emre Ertekin">
<organization/> <organization/>
</author> </author>
<date month="October" day="23" year="2006"/> <date month="October" year="2006"/>
</front> </front>
<seriesInfo name="MILCOM 2006 - 2006 IEEE Military Communications conf <seriesInfo name="DOI" value="10.1109/MILCOM.2006.302503"/>
erence" value="IEEE Xplore DL, pp.1-6"/> <refcontent>MILCOM 2006 - 2006 IEEE Military Communications conference
, pp. 1-6</refcontent>
</reference> </reference>
<reference anchor="OLTEANU" target="http://dl.acm.org/citation.cfm?id=18
17271.1817379"> <reference anchor="OLTEANU" target="https://dl.acm.org/doi/10.5555/18172
71.1817379">
<front> <front>
<title> <title>Fragmentation and AES encryption overhead in very high-speed
Fragmentation and AES Encryption Overhead in Very High-s wireless LANs
peed Wireless LANs
</title> </title>
<author initials="A" surname="Olteanu" fullname="Alina Olteanu"> <author initials="A" surname="Olteanu" fullname="Alina Olteanu">
<organization/> <organization/>
</author> </author>
<author initials="P" surname="Xiao" fullname="Yang Xiao"> <author initials="P" surname="Xiao" fullname="Yang Xiao">
<organization/> <organization/>
</author> </author>
<date month="June" day="14" year="2009"/> <date month="June" year="2009"/>
</front> </front>
<seriesInfo name="Proceedings of the 2009 IEEE International Conferenc <refcontent>Proceedings of the 2009 IEEE International Conference on
e on Communications ICC'09," value="ACM DL, pp.575-579"/> Communications ICC'09, pp. 575-579
</refcontent>
</reference> </reference>
<reference anchor="MECSPEC" target="https://www.etsi.org/deliver/etsi_gs /MEC/001_099/003/01.01.01_60/gs_MEC003v010101p.pdf"> <reference anchor="MECSPEC" target="https://www.etsi.org/deliver/etsi_gs /MEC/001_099/003/01.01.01_60/gs_MEC003v010101p.pdf">
<front> <front>
<title> <title>
Mobile Edge Computing (MEC); Framework and Reference Arc hitecture Mobile Edge Computing (MEC); Framework and Reference Arc hitecture
</title> </title>
<author initials="" surname="" fullname=""> <author>
<organization/> <organization>ETSI
</author> </organization>
<date month="March" day="" year="2016"/>
</front>
<seriesInfo name="ETSI" value="European Telecommunication Standards In
stitute (ETSI) MEC specification"/>
</reference>
<reference anchor="RFC8609" target="https://www.rfc-editor.org/info/rfc8
609">
<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 requ
ests. This document specifies the encoding of CCNx messages in a TLV packet form
at, including the TLV types used by each message element and the encoding of eac
h value. The semantics of CCNx messages follow the encoding-independent CCNx Sem
antics specification.
</t>
<t>
This document is a product of the Information Centric Ne
tworking research group (ICNRG). The document received wide review among ICNRG p
articipants 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/rfc8
569">
<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 inter
pretation. This architecture and protocol specification is independent of a spec
ific wire encoding.
</t>
<t>
The protocol also uses a control message called an Inter
est Return, whereby one system can return an Interest message to the previous ho
p 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 Ne
tworking Research Group (ICNRG). The document received wide review among ICNRG p
articipants. Two full implementations are in active use and have informed the te
chnical 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/rfc7
945">
<front>
<title>Information-Centric Networking: Evaluation and Security Consi
derations</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> </author>
<date year="2016" month="September"/> <date month="March" year="2016"/>
<abstract>
<t>This document presents a number of considerations regarding eva
luating Information-Centric Networking (ICN) and sheds some light on the impact
of ICN on network security. It also surveys the evaluation tools currently avail
able to researchers in the ICN area and provides suggestions regarding methodolo
gy and metrics.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="7945"/> <refcontent>ETSI GS MEC 003</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC7945"/> <refcontent>Version 1.1.1</refcontent>
</reference> </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> -->
<reference anchor="CCN" target="http://www.ccnx.org"> <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="https://wiki.fd.io/index.php?title=C
icn&amp;oldid=10316">
<front> <front>
<title>Content Centric Networking</title> <title>Cicn</title>
<author initials="" surname=""> <author initials="" surname="">
<organization/> <organization>FD.io</organization>
</author>
<date year=""/>
</front>
</reference>
<reference anchor="ICN5G" target="https://www.ietf.org/id/draft-irtf-icn
rg-5gc-icn-04.txt">
<front>
<title>
Enabling ICN in 3GPP's 5G NextGen Core Architecture
</title>
<author initials="R" surname="Ravindran" fullname="Ravi Ravindran">
<organization/>
</author>
<author initials="P" surname="suthar" fullname="Prakash suthar">
<organization/>
</author>
<author initials="D" surname="Trossen" fullname="Dirk Trossen">
<organization/>
</author>
<author initials="G" surname="White" fullname="Greg White">
<organization/>
</author> </author>
<date month="January" day="10" year="2021"/> <date month="January" year="2020"/>
<abstract>
<t>
The proposed 3GPP's 5G core nextgen architecture (5G
C) offers
flexibility to introduce new user and control plane
function,
considering the support for network slicing function
s, that allows
greater flexibility to handle heterogeneous devices
and applications. In
this draft, we provide a short description of the pr
oposed 5GC
architecture, followed by extensions to 5GC's contro
l and user plane to
support packet data unit (PDU) sessions from informa
tion-centric
networks. The value of enabling ICN in 5GC is discus
sed using multiple
service scenarios in the context of mobile edge comp
uting such as smart
mobility and VR use case, and to enable network serv
ices such as
seamless mobility for ICN sessions.
</t>
</abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ravi-icnrg-5gc-icn-04"/ </reference>
>
</reference> <reference anchor="ICN5G">
<!-- <reference anchor="NDN"> <front>
<front> <title>Enabling ICN in 3GPP's 5G NextGen Core Architecture</title>
<title>SIGCOMM Named Data Networking</title> <author initials="R." surname="Ravindran" fullname="Ravi Ravindran">
<author surname="Lixia Z., Lan W. et al"> <organization>Corning Incorporated</organization>
<organization></organization> </author>
</author> <author initials="P." surname="Suthar" fullname="Prakash Suthar">
<date year=""/> <organization>Cisco Systems</organization>
</front> </author>
</reference> --> <author initials="D." surname="Trossen" fullname="Dirk Trossen">
<organization>Huawei Technologies Duesseldorf GmbH</organization>
</author>
<author initials="C." surname="Wang" fullname="Chonggang Wang">
<organization>InterDigital Inc.</organization>
</author>
<author initials="G." surname="White" fullname="Greg White">
<organization>CableLabs</organization>
</author>
<date month="January" day="10" year="2021" />
</front>
<seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-5gc-icn-04" />
</reference>
<reference anchor="ALM" target="https://dl.acm.org/citation.cfm?id=2 812601"> <reference anchor="ALM" target="https://dl.acm.org/citation.cfm?id=2 812601">
<front> <front>
<title> <title>Anchor-Less Producer Mobility in ICN</title>
Anchor-Less Producer Mobility in ICN <author initials="J" surname="Augé" fullname="Jordan Augé">
</title>
<author initials="J" surname="Augé" fullname="">
<organization/> <organization/>
</author> </author>
<author initials="G" surname="Carofiglio" fullname=""> <author initials="G" surname="Carofiglio" fullname="Giovanna Carofig lio">
<organization/> <organization/>
</author> </author>
<author initials="G" surname="Grassi" fullname=""> <author initials="G" surname="Grassi" fullname="Giulio Grassi">
<organization/> <organization/>
</author> </author>
<author initials="L" surname="Muscariello" fullname=""> <author initials="L" surname="Muscariello" fullname="Luca Muscariell o">
<organization/> <organization/>
</author> </author>
<author initials="G" surname="Pau" fullname=""> <author initials="G" surname="Pau" fullname="Giovanni Pau">
<organization/> <organization/>
</author> </author>
<author initials="X" surname="Zeng" fullname=""> <author initials="X" surname="Zeng" fullname="Xuan Zeng">
<organization/> <organization/>
</author> </author>
<date month="September" day="30" year="2013"/> <date month="September" year="2015"/>
</front> </front>
<seriesInfo name="Proceedings of the 2Nd ACM Conference on Information <seriesInfo name="DOI" value="10.1145/2810156.2812601"/>
-Centric Networking, ACM-ICN'15," value="ACM DL, pp.189-190"/> <refcontent>ACM-ICN '15: Proceedings of the 2nd ACM Conference on Information-Ce
ntric Networking, pp. 189-190</refcontent>
</reference> </reference>
<!-- <reference anchor="VNIIDX">
<front>
<title>Cisco Visual Networking Index: Global Mobile Data Tra
ffic 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/solutio
ns/service-provider/visual-networking-index-vni/index.html"/>
</reference> -->
<reference anchor="NDNRTC" target="https://doi.org/10.1587/transcom. 2015AMI0002"> <reference anchor="NDNRTC" target="https://doi.org/10.1587/transcom. 2015AMI0002">
<front> <front>
<title> <title>
Real-time Streaming Data Delivery over Named Data Networ king, Real-Time Streaming Data Delivery over Named Data Networ king
</title> </title>
<author initials="P" surname="Gusev" fullname=""> <author initials="P" surname="Gusev" fullname="Peter Gusev">
<organization/> <organization/>
</author> </author>
<author initials="Z" surname="Wang" fullname=""> <author initials="Z" surname="Wang" fullname="Zhehao Wang">
<organization/> <organization/>
</author> </author>
<author initials="J" surname="Burke" fullname=""> <author initials="J" surname="Burke" fullname="Jeff Burke">
<organization/> <organization/>
</author> </author>
<author initials="L" surname="Zhang" fullname=""> <author initials="L" surname="Zhang" fullname="Lixia Zhang">
<organization/> <organization/>
</author> </author>
<author initials="T" surname="Yoneda" fullname=""> <author initials="T" surname="Yoneda" fullname="Takahiro Yonda">
<organization/> <organization/>
</author> </author>
<author initials="R" surname="Ohnishi" fullname=""> <author initials="R" surname="Ohnishi" fullname="Ryota Ohnishi">
<organization/> <organization/>
</author> </author>
<author initials="E" surname="Muramoto" fullname=""> <author initials="E" surname="Muramoto" fullname="Eiichi Muramoto">
<organization/> <organization/>
</author> </author>
<date month="May" day="1" year="2016"/> <date month="May" year="2016"/>
</front> </front>
<seriesInfo name="IEICE Transactions on Communications" value="vol. E9 <seriesInfo name="" value="10.5815/ijcnis.2017.01.07"/>
9.B, pp. 974-991"/> <refcontent>IEICE Transactions on Communications, Vol. E99.B, Issue 5,
pp. 974-991</refcontent>
</reference> </reference>
<reference anchor="CHENG" target="https://ieeexplore.ieee.org/document/7 113228"> <reference anchor="CHENG" target="https://ieeexplore.ieee.org/document/7 113228">
<front> <front>
<title> <title>Information-centric network function virtualization over 5g m
Information-centric network function virtualization over obile wireless networks
5g mobile wireless networks
</title> </title>
<author initials="C" surname="Liang" fullname=""> <author initials="C" surname="Liang" fullname="Chengchao Liang">
<organization/> <organization/>
</author> </author>
<author initials="R" surname="Yu" fullname=""> <author initials="R" surname="Yu" fullname="F. Richard Yu">
<organization/> <organization/>
</author> </author>
<author initials="X" surname="Zhang" fullname=""> <author initials="X" surname="Zhang" fullname="Xi Zhang">
<organization/> <organization/>
</author> </author>
<date month="June" day="1" year="2015"/> <date month="June" year="2015"/>
</front> </front>
<seriesInfo name="IEEE Network Journal" value="vol. 29, number 3, pp. 68-74"/> <refcontent>IEEE Network, Vol. 29, Issue 3, pp. 68-74</refcontent>
</reference> </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"> <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> <front>
<title> <title>
Backhaul Provisioning for LTE-Advanced and Small Cells Backhaul Provisioning for LTE-Advanced &amp; Small Cells
</title> </title>
<author initials="J" surname="Robson" fullname=""> <author initials="J" surname="Robson" fullname="Julius Robson">
<organization/> <organization/>
</author> </author>
<date month="October" day="20" year="2015"/> <date month="October" year="2015"/>
</front> </front>
<seriesInfo name="Next Generation Mobile Networks, LTE-Advanced Transp <refcontent>Next Generation Mobile Networks</refcontent>
ort Provisioning," value="V0.0.14"/> <refcontent>LTE-Advanced Transport Provisioning</refcontent>
<refcontent>Version 0.0.14</refcontent>
</reference> </reference>
<reference anchor="IPoICN" target="https://ieeexplore.ieee.org/document/ 7194109"> <reference anchor="IPoICN" target="https://ieeexplore.ieee.org/document/ 7194109">
<front> <front>
<title> <title>IP over ICN - The better IP?
IP over ICN - The better IP?
</title> </title>
<author initials="D" surname="Trossen" fullname=""> <author initials="D" surname="Trossen" fullname="Dirk Trossen">
<organization/> <organization/>
</author> </author>
<author initials="M J" surname="Read" fullname=""> <author initials="M. J." surname="Read" fullname="Martin J. Reed">
<organization/> <organization/>
</author> </author>
<author initials="J" surname="Riihijarvi" fullname=""> <author initials="J" surname="Riihijarvi" fullname="Janne Riihijärvi ">
<organization/> <organization/>
</author> </author>
<author initials="M" surname="Georgiades" fullname=""> <author initials="M" surname="Georgiades" fullname="Michael Georgiad es">
<organization/> <organization/>
</author> </author>
<author initials="N" surname="Fotiou" fullname=""> <author initials="N" surname="Fotiou" fullname="Nikos Fotiou">
<organization/> <organization/>
</author> </author>
<author initials="G" surname="Xylomenos" fullname=""> <author initials="G" surname="Xylomenos" fullname="George Xylomenos" >
<organization/> <organization/>
</author> </author>
<date month="June" day="29" year="2015"/> <date month="June" year="2015"/>
</front> </front>
<seriesInfo name="2015 European Conference on Networks and Communicati <refcontent>2015 European Conference on Networks and Communications (E
ons (EuCNC)" value="IEEE Xplore DL, pp. 413-417"/> uCNC), pp. 413-417</refcontent>
<seriesInfo name="DOI" value="10.1109/EuCNC.2015.7194109"/>
</reference> </reference>
<reference anchor="HICN" target="https://www.ietf.org/id/draft-muscariel
lo-intarea-hicn-04.txt"> <reference anchor="HICN">
<front> <front>
<title>Hybrid Information-Centric Networking</title> <title>Hybrid Information-Centric Networking</title>
<author initials="L" surname="Muscariello" fullname="Luca Muscariell o"> <author initials="L" surname="Muscariello" fullname="Luca Muscariell o">
<organization/> <organization/>
</author> </author>
<author initials="G" surname="Carofiglio" fullname="Giovanna Carofig lio"> <author initials="G" surname="Carofiglio" fullname="Giovanna Carofig lio">
<organization/> <organization/>
</author> </author>
<author initials="J" surname="Auge" fullname="Jordan Auge"> <author initials="J" surname="Auge" fullname="Jordan Auge">
<organization/> <organization/>
</author> </author>
<author initials="M" surname="Papalini" fullname="Michele Papalini"> <author initials="M" surname="Papalini" fullname="Michele Papalini">
<organization/> <organization/>
</author> </author>
<date month="May" day="20" year="2020"/> <date month="May" day="20" year="2020" />
<abstract>
<t>
This documents describes the hybrid information-cent
ric networking
(hICN) architecture for IPv6. The specifications des
cribe a way to
implement information-networking functionalities int
o IPv6. The
objective is to use IPv6 without creating overlays w
ith a new packet
format as an additional encapsulation. The intent of
the present design
is to introduce some IPv6 routers in the network wit
h additional packet
processing operations to implement ICN functions. Mo
reover, the current
design is tightly integrated into IPv6 to allow easy
interconnection to
IPv6 networks with the additional design objective t
o exploit existing
IPv6 protocols as much as possible as they are, or e
xtend them where
needed.
</t>
</abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-muscariello-intarea-hic n-04"/> <seriesInfo name="Internet-Draft" value="draft-muscariello-intarea-hic n-04"/>
</reference> </reference>
<reference anchor="GALIS" target="http://www.ietf.org/internet-drafts/dr
aft-galis-anima-autonomic-slice-networking-05.txt"> <reference anchor="GALIS">
<front> <front>
<title>Autonomic Slice Networking</title> <title>Autonomic Slice Networking</title>
<author initials="A" surname="Galis" fullname="A. Galis"> <author initials="A" surname="Galis" fullname="Alex Galis" role="edi tor">
<organization/> <organization/>
</author> </author>
<author initials="K" surname="Makhijani" fullname="Kiran Makhijani"> <author initials="K" surname="Makhijani" fullname="Kiran Makhijani">
<organization/> <organization/>
</author> </author>
<author initials="D" surname="Yu" fullname="Delei Yu"> <author initials="D" surname="Yu" fullname="Delei Yu">
<organization/> <organization/>
</author> </author>
<author initials="B" surname="Liu" fullname="Bing Liu"> <author initials="B" surname="Liu" fullname="Bing Liu">
<organization/> <organization/>
</author> </author>
<date month="September" day="26" year="2018"/> <date month="September" day="26" year="2018" />
<abstract>
<t>
This document describes the technical requirements a
nd the related
reference model for the intercommunication and coord
ination among
devices in Autonomic Slicing Networking. The goal is
to define how the
various elements in a network slicing context work a
nd orchestrate
together, to describe their interfaces and relations
. While the document
is written as generally as possible, the initial sol
utions are limited
to the chartered scope of the WG.
</t>
</abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-galis-anima-autonomic-s lice-networking-05"/> <seriesInfo name="Internet-Draft" value="draft-galis-anima-autonomic-s lice-networking-05"/>
</reference> </reference>
<reference anchor="EPCCUPS" target="http://www.3gpp.org/news-events/3gpp
-news/1882-cups"> <reference anchor="EPCCUPS" target="https://www.3gpp.org/news-events/3gp
p-news/1882-cups">
<front> <front>
<title> <title>Control and User Plane Separation of EPC nodes (CUPS)</title>
Control and User Plane Separation of EPC nodes (CUPS) <author initials="P" surname="Schmitt" fullname="Peter Schmitt">
</title>
<author initials="P" surname="Schmitt" fullname="">
<organization/> <organization/>
</author> </author>
<author initials="B" surname="Landais" fullname=""> <author initials="B" surname="Landais" fullname="Bruno Landais">
<organization/> <organization/>
</author> </author>
<author initials="F" surname="Yong Yang" fullname=""> <author initials="F" surname="Yong Yang" fullname="Frank Yong Yang">
<organization/> <organization/>
</author> </author>
<date month="July" day="3" year="2017"/> <date month="July" year="2017"/>
</front> </front>
<seriesInfo name="3GPP" value="The Mobile Broadband Standard"/> <refcontent>3GPP, The Mobile Broadband Standard</refcontent>
</reference> </reference>
<reference anchor="SDN5G" target="https://ieeexplore.ieee.org/document/7 496561"> <reference anchor="SDN5G" target="https://ieeexplore.ieee.org/document/7 496561">
<front> <front>
<title> <title>
Software-defined networking for low-latency 5G core netw ork Software-defined networking for low-latency 5G core netw ork
</title> </title>
<author initials="J" surname="Page" fullname="Jérémy Pagé"> <author initials="J" surname="Page" fullname="Jérémy Pagé">
<organization/> <organization/>
</author> </author>
<author initials="J" surname="Dricot" fullname="Jean-Michel Dricot"> <author initials="J" surname="Dricot" fullname="Jean-Michel Dricot">
<organization/> <organization/>
</author> </author>
<date month="May" day="" year="2016"/> <date month="May" year="2016"/>
</front> </front>
<seriesInfo name="2016 International Conference on Military Communicat <refcontent>2016 International Conference on Military Communications an
ions and Information Systems (ICMCIS)" value="IEEE Xplore DL, pp. 1-7"/> d
Information Systems (ICMCIS), pp. 1-7
</refcontent>
<seriesInfo name="DOI" value="10.1109/ICMCIS.2016.7496561"/>
</reference> </reference>
<reference anchor="ICNQoS" target="https://ieeexplore.ieee.org/document/ 7037079"> <reference anchor="ICNQoS" target="https://ieeexplore.ieee.org/document/ 7037079">
<front> <front>
<title> <title>
Quality of Service in an Information-Centric Network Quality of service in an information-centric network
</title> </title>
<author initials="M.F." surname="Al-Naday" fullname=""> <author initials="M.F." surname="Al-Naday" fullname="Mays F. Al-Nada y">
<organization/> <organization/>
</author> </author>
<author initials="A" surname="Bontozoglou" fullname=""> <author initials="A" surname="Bontozoglou" fullname="Andreas Bontozo glou">
<organization/> <organization/>
</author> </author>
<author initials="G" surname="Vassilakis" fullname=""> <author initials="G" surname="Vassilakis" fullname="Vassilios G. Vas silakis">
<organization/> <organization/>
</author> </author>
<author initials="M. J." surname="Reed" fullname=""> <author initials="M. J." surname="Reed" fullname="Martin J. Reed">
<organization/> <organization/>
</author> </author>
<date month="December" day="8" year="2014"/> <date month="December" year="2014"/>
</front> </front>
<seriesInfo name="2014 IEEE Global Communications Conference" value="I <refcontent>2014 IEEE Global Communications Conference, pp. 1861-1866<
EEE Xplore DL, pp. 1861-1866"/> /refcontent>
<seriesInfo name="DOI" value="10.1109/GLOCOM.2014.7037079"/>
</reference> </reference>
<reference anchor="OFFLOAD" target="https://ieeexplore.ieee.org/document /6953022"> <reference anchor="OFFLOAD" target="https://ieeexplore.ieee.org/document /6953022">
<front> <front>
<title> <title>Data Offloading Techniques in Cellular Networks: A Survey
Data Offloading Techniques in Cellular Networks: A Surve
y
</title> </title>
<author initials="F" surname="Rebecchi" fullname=""> <author initials="F" surname="Rebecchi" fullname="Filippo Rebecchi">
<organization/> <organization/>
</author> </author>
<author initials="M" surname="Dias de Amorim" fullname=""> <author initials="M" surname="Dias de Amorim" fullname="Marcelo Dias de Amorim">
<organization/> <organization/>
</author> </author>
<author initials="V" surname="Conan" fullname=""> <author initials="V" surname="Conan" fullname="Vania Conan">
<organization/> <organization/>
</author> </author>
<author initials="A" surname="Passarella" fullname=""> <author initials="A" surname="Passarella" fullname="Andrea Passarell a">
<organization/> <organization/>
</author> </author>
<author initials="R" surname="Bruno" fullname=""> <author initials="R" surname="Bruno" fullname="Raffaele Bruno">
<organization/> <organization/>
</author> </author>
<author initials="M" surname="Conti" fullname=""> <author initials="M" surname="Conti" fullname="Marco Conti">
<organization/> <organization/>
</author> </author>
<date month="November" day="11" year="2014"/> <date month="November" year="2014"/>
</front> </front>
<seriesInfo name="IEEE Communications Surveys and Tutorials," value="I <seriesInfo name="DOI" value="10.1109/COMST.2014.2369742"/>
EEE Xplore DL, vol:17, issue:2, pp.580-603"/> <refcontent>IEEE Communications Surveys and Tutorials
</refcontent>
<refcontent>Vol. 17, Issue 2, pp.580-603</refcontent>
</reference> </reference>
<!--
<reference anchor="NS3LTE"
target="https://www.nsnam.org/docs/models/html/lte-design.html#l
te-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/ht
ml/lte-design.html#lte-model"/>
<format type="PDF" target="https://www.nsnam.org/tutorials/conso
rtium13/lte-tutorial.pdf"/>
</reference>
<reference anchor="NS3EPC"
target="https://www.nsnam.org/docs/models/html/lte-design.html#e
pc-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/ht
ml/lte-design.html#epc-model"/>
<format type="PDF" target="https://www.nsnam.org/tutorials/conso
rtium13/lte-tutorial.pdf"/>
</reference>
-->
<reference anchor="MBICN" target="https://ieeexplore.ieee.org/docume nt/7114719"> <reference anchor="MBICN" target="https://ieeexplore.ieee.org/docume nt/7114719">
<front> <front>
<title> <title>
Scalable mobile backhauling via information-centric netw orking Scalable mobile backhauling via information-centric netw orking
</title> </title>
<author initials="G" surname="Carofiglio" fullname=""> <author initials="G" surname="Carofiglio" fullname="Giovanna Carofig lio">
<organization/> <organization/>
</author> </author>
<author initials="M" surname="Gallo" fullname=""> <author initials="M" surname="Gallo" fullname="Massimo Gallo">
<organization/> <organization/>
</author> </author>
<author initials="L" surname="Muscariello" fullname=""> <author initials="L" surname="Muscariello" fullname="Luca Muscariell o">
<organization/> <organization/>
</author> </author>
<author initials="D" surname="Perino" fullname=""> <author initials="D" surname="Perino" fullname="Diego Perino">
<organization/> <organization/>
</author> </author>
<date month="April" day="22" year="2015"/> <date month="April" year="2015"/>
</front> </front>
<seriesInfo name="The 21st IEEE International Workshop on Local and Me <refcontent>The 21st IEEE International Workshop on Local and Metropol
tropolitan Area Networks," value="Beijing, pp. 1-6"/> itan Area Networks, Beijing, pp. 1-6</refcontent>
<seriesInfo name="DOI" value="10.1109/LANMAN.2015.7114719"/>
</reference> </reference>
<reference anchor="MPVCICN" target="https://ieeexplore.ieee.org/document /7169810"> <reference anchor="MPVCICN" target="https://ieeexplore.ieee.org/document /7169810">
<front> <front>
<title> <title>
Realtime multi-party video conferencing service over inf ormation centric network Realtime multi-party video conferencing service over inf ormation centric network
</title> </title>
<author initials="A" surname="Jangam" fullname=""> <author initials="A" surname="Jangam" fullname="Anil Jangam">
<organization/> <organization/>
</author> </author>
<author initials="R" surname="Ravindran" fullname=""> <author initials="R" surname="Ravindran" fullname="Ravishankar Ravin dran">
<organization/> <organization/>
</author> </author>
<author initials="A" surname="Chakraborti" fullname=""> <author initials="A" surname="Chakraborti" fullname="Asit Chakrabort i">
<organization/> <organization/>
</author> </author>
<author initials="X" surname="Wan" fullname=""> <author initials="X" surname="Wan" fullname="Xili Wan">
<organization/> <organization/>
</author> </author>
<author initials="G" surname="Wang" fullname=""> <author initials="G" surname="Wang" fullname="Guoqiang Wang">
<organization/> <organization/>
</author> </author>
<date month="June" day="29" year="2015"/> <date month="June" year="2015"/>
</front> </front>
<seriesInfo name="IEEE International Conference on Multimedia and Expo <seriesInfo name="DOI" value="10.1109/ICMEW.2015.7169810"/>
Workshops (ICMEW)" value="Turin, Italy, pp. 1-6"/> <refcontent>IEEE International Conference on Multimedia and Expo Works
hops (ICMEW), Turin, Italy, pp. 1-6</refcontent>
</reference> </reference>
<reference anchor="FOTIOU" target="https://dl.acm.org/doi/10.1145/266012 9.2666711"> <reference anchor="FOTIOU" target="https://dl.acm.org/doi/10.1145/266012 9.2666711">
<front> <front>
<title> <title>ICN privacy and name based security</title>
ICN privacy and name based security
</title>
<author initials="N" surname="Fotiou" fullname="Nikos Fotiou"> <author initials="N" surname="Fotiou" fullname="Nikos Fotiou">
<organization/> <organization/>
</author> </author>
<author initials="G" surname="Polyzos" fullname="George C. Polyzos"> <author initials="G" surname="Polyzos" fullname="George C. Polyzos">
<organization/> <organization/>
</author> </author>
<date month="September" day="" year="2014"/> <date month="September" year="2014"/>
</front> </front>
<seriesInfo name="ACM-ICN '14: Proceedings of the 1st ACM Conference o <seriesInfo name="DOI" value="10.1145/2660129.2666711"/>
n Information-Centric Networking" value="ACM Digitial Library, pp. 5-6"/> <refcontent>ACM-ICN '14: Proceedings of the 1st ACM Conference on Info
rmation-Centric Networking, pp. 5-6</refcontent>
</reference> </reference>
<reference anchor="TOURANI" target="https://ieeexplore.ieee.org/document /8027034"> <reference anchor="TOURANI" target="https://ieeexplore.ieee.org/document /8027034">
<front> <front>
<title> <title>
Security, Privacy, and Access Control in Information-Cen tric Networking: A Survey Security, Privacy, and Access Control in Information-Cen tric Networking: A Survey
</title> </title>
<author initials="R" surname="Tourani" fullname="Reza Tourani"> <author initials="R" surname="Tourani" fullname="Reza Tourani">
<organization/> <organization/>
</author> </author>
<author initials="S" surname="Misra" fullname="Satyajayant Misra"> <author initials="S" surname="Misra" fullname="Satyajayant Misra">
<organization/> <organization/>
</author> </author>
<author initials="T" surname="Mick" fullname="Travis Mick"> <author initials="T" surname="Mick" fullname="Travis Mick">
<organization/> <organization/>
</author> </author>
<author initials="G" surname="Panwar" fullname="Gaurav Panwar"> <author initials="G" surname="Panwar" fullname="Gaurav Panwar">
<organization/> <organization/>
</author> </author>
<date month="September" day="" year="2017"/> <date month="September" year="2017"/>
</front> </front>
<seriesInfo name="IEEE Communications Surveys and Tutorials" value="Vo <seriesInfo name="DOI" value="10.1109/COMST.2017.2749508"/>
lume 20, Issue 1, pp 566-600"/> <refcontent>IEEE Communications Surveys and Tutorials, Vol. 20, Issue
1, pp. 566-600</refcontent>
</reference> </reference>
<reference anchor="TLVCOMP" target="https://datatracker.ietf.org/meeting /interim-2016-icnrg-02/materials/slides-interim-2016-icnrg-2-7"> <reference anchor="TLVCOMP" target="https://datatracker.ietf.org/meeting /interim-2016-icnrg-02/materials/slides-interim-2016-icnrg-2-7">
<front> <front>
<title>Header Compression for TLV-based Packets</title> <title>Header Compression for TLV-based Packets</title>
<author initials="M" surname="Mosko" fullname=""> <author initials="M" surname="Mosko" fullname="Marc Mosko">
<organization/>
</author>
<date month="April" day="3" year="2016"/>
</front>
<seriesInfo name="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 Waehlisc
h">
<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/> <organization/>
</author> </author>
<date month="February" day="10" year="2021"/> <date month="April" year="2016"/>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-icnlowpan-10 "/> <refcontent>ICNRG, Buenos Aires, IETF 95</refcontent>
</reference> </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"> <reference anchor="QoS-ICN">
<front> <front>
<title>QoS Treatments in ICN using Disaggregated Name Components</ti tle> <title>QoS Treatments in ICN using Disaggregated Name Components</ti tle>
<author initials="A" surname="Jangam" fullname="Anil Jangam"> <author initials="A" surname="Jangam" fullname="Anil Jangam" role="e ditor">
<organization/> <organization/>
</author> </author>
<author initials="P" surname="suthar" fullname="Prakash suthar"> <author initials="P" surname="Suthar" fullname="Prakash Suthar">
<organization/> <organization/>
</author> </author>
<author initials="M" surname="Stolic" fullname="Milan Stolic"> <author initials="M" surname="Stolic" fullname="Milan Stolic">
<organization/> <organization/>
</author> </author>
<date month="March" day="9" year="2020"/> <date month="March" day="9" year="2020" />
<abstract>
<t>Mechanisms for specifying and implementing end-to-end Quality o
f service (QoS) treatments in Information-Centric Networks (ICN) has not been ex
plored so far. There has been some work towards implementing QoS in ICN; however
, the discussions are mainly centered around strategies used in efficient forwar
ding of Interest packets. Moreover, as ICN has been tested mainly as an IP overl
ay, its QoS is still governed by the IP QoS framework and there is a need for im
plementing QoS in ICN natively. This document describes mechanisms to classify a
nd provide associated "name-based" extensions to identify QoS within the framewo
rk of ICN's core design principles. The name-based design provides a mechanism t
o carry QoS information and implement the treatments as ICN packets travel acros
s 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>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-anilj-icnrg-dnc-qos-icn -02"/> <seriesInfo name="Internet-Draft" value="draft-anilj-icnrg-dnc-qos-icn -02"/>
</reference> </reference>
<reference anchor="MUTHANA" target="http://www.mecs-press.org/ijcnis/ijc
nis-v9-n1/v9n1-7.html"> <reference anchor="MUTHANA" target="https://www.mecs-press.org/ijcnis/ij
cnis-v9-n1/v9n1-7.html">
<front> <front>
<title> <title>
Analysis of User Identity Privacy in LTE and Proposed So lution Analysis of User Identity Privacy in LTE and Proposed So lution
</title> </title>
<author initials="A" surname="Muthana" fullname="Abdulrahman A. Muth ana"> <author initials="A" surname="Muthana" fullname="Abdulrahman A. Muth ana">
<organization/> <organization/>
</author> </author>
<author initials="M" surname="Saeed" fullname="Mamoon M. Saeed"> <author initials="M" surname="Saeed" fullname="Mamoon M. Saeed">
<organization/> <organization/>
</author> </author>
<date month="January" day="" year="2017"/> <date month="January" year="2017"/>
</front> </front>
<seriesInfo name="International Journal of Computer Network and Inform <seriesInfo name="DOI" value="10.5815/ijcnis.2017.01.07"/>
ation Security(IJCNIS)" value="MECS Press, pp. 54-63"/> <refcontent>International Journal of Computer Network and Information
Security(IJCNIS), Vol. 9, Issue 1, pp. 54-63</refcontent>
</reference> </reference>
<reference anchor="EMBMS" target="https://ieeexplore.ieee.org/document/9 105941"> <reference anchor="EMBMS" target="https://ieeexplore.ieee.org/document/9 105941">
<front> <front>
<title> <title>Service-Less Video Multicast in 5G: Enablers and Challenges</
Service-Less Video Multicast in 5G: Enablers and Challen title>
ges <author initials="K" surname="Zahoor" fullname="Kamran Zahoor">
</title>
<author initials="K" surname="Zahoor" fullname="K. Zahoor">
<organization/>
</author>
<author initials="K" surname="Bilal" fullname="K. Bilal">
<organization/> <organization/>
</author> </author>
<author initials="A" surname="Erbad" fullname="A. Erbad"> <author initials="K" surname="Bilal" fullname="Kashif Bilal">
<organization/> <organization/>
</author> </author>
<author initials="A" surname="Mohamed" fullname="A. Mohamed"> <author initials="A" surname="Erbad" fullname="Aiman Erbad">
<organization/> <organization/>
</author> </author>
<date month="May" day="" year="2020"/> <author initials="A" surname="Mohamed" fullname="Amr Mohamed">
</front>
<seriesInfo name="IEEE Network" value="vol. 34, no. 3, pp. 270-276"/>
</reference>
<reference anchor="RFC9064" target="https://www.rfc-editor.org/info/rfc9
064">
<front>
<title>Considerations in the Development of a QoS Architecture for C
CNx-Like Information-Centric Networking Protocols</title>
<author initials="D." surname="Oran" fullname="D. Oran">
<organization/> <organization/>
</author> </author>
<date year="2021" month="June"/> <date month="June" year="2020"/>
<abstract>
<t>This is a position paper. It documents the author's personal vi
ews on how Quality of Service (QoS) capabilities ought to be accommodated in Inf
ormation-Centric Networking (ICN) protocols like Content-Centric Networking (CCN
x) or Named Data Networking (NDN), which employ flow-balanced Interest/Data exch
anges and hop-by-hop forwarding state as their fundamental machinery. It argues
that such protocols demand a substantially different approach to QoS from that t
aken in TCP/IP and proposes specific design patterns to achieve both classificat
ion 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 a
s 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 on
ly 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 indi
vidual submission.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="9064"/> <seriesInfo name="DOI" value="10.1109/MNET.001.1900435"/>
<seriesInfo name="DOI" value="10.17487/RFC9064"/> <refcontent>IEEE Network, Vol. 34, Issue 3, pp. 270-276</refcontent>
</reference> </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/htm l/lte-design.html#epc-model"> <reference anchor="NS3EPC" target="https://www.nsnam.org/docs/models/htm l/lte-design.html#epc-model">
<front> <front>
<title> <title>The EPC Model
The ns-3 EPC module
</title> </title>
<author initials="N" surname="Baldo" fullname=""> <author><organization>ns-3
<organization/> </organization>
</author> </author>
<date month="" day="" year=""/> <date month="July" year="2022"/>
</front> </front>
<seriesInfo name="" value="NS3 EPC Model"/>
<format type="PDF" target="https://www.nsnam.org/tutorials/consortium1
3/lte-tutorial.pdf"/>
</reference> </reference>
<reference anchor="NS3LTE" target="https://www.nsnam.org/docs/models/htm l/lte-design.html#lte-model"> <reference anchor="NS3LTE" target="https://www.nsnam.org/docs/models/htm l/lte-design.html#lte-model">
<front> <front>
<title> <title>The LTE Model
The ns-3 LTE module
</title> </title>
<author initials="N" surname="Baldo" fullname=""> <author><organization>ns-3
<organization/> </organization>
</author> </author>
<date month="" day="" year=""/> <date month="July" year="2022"/>
</front> </front>
<seriesInfo name="" value="NS3 LTE Model"/> </reference>
<format type="PDF" target="https://www.nsnam.org/tutorials/consortium1
3/lte-tutorial.pdf"/>
</reference>
<reference anchor="Open5GCore" target="https://www.open5gcore.org"> <reference anchor="Open5GCore" target="https://www.open5gcore.org">
<front> <front>
<title> <title>Open5GCore - 5G Core Network for Research, Testbeds and Trial
Open5GCore - Fundamental 4G Core Network Functionality s
</title> </title>
<author initials="M" surname="Open5GCore" fullname=""> <author>
<organization/> <organization>Open5GCore
</organization>
</author> </author>
<date month="" day="" year=""/>
</front> </front>
<seriesInfo name="" value="Open5GCore"/>
</reference> </reference>
</references> </references>
</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 e
specially want to mention the following members of the IRTF Information-Centric
Networking Research Group (ICNRG), listed in alphabetical order: <contact fullna
me="Kashif Islam"/>, <contact fullname="Thomas Jagodits"/>, <contact fullname="L
uca Muscariello"/>, <contact fullname="David R. Oran"/>, <contact fullname="Akba
r 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> </back>
</rfc> </rfc>
 End of changes. 355 change blocks. 
1471 lines changed or deleted 1068 lines changed or added

This html diff was produced by rfcdiff 1.48.