RFC 9269
Experimental Scenarios of Information-Centric Networking (ICN) Integration in 4G Mobile Networks
Experimental Scenarios of Information-Centric Networking (ICN) Integration in 4G Mobile Networks π¦
RFC 9269 π is an Informational doc from the Internet Research Task Force (IRTF), published in August 2022. Its ISSN is 2070-1721.
The authors are P. Suthar (Google Inc.), M. Stolic (no affiliation listed in the title block π€·ββοΈ), A. Jangam, Ed. (Cisco Systems Inc.), D. Trossen (Huawei Technologies), and R. Ravindran (F5 Networks). The title block doesn't list any RFCs that this one obsoletes or updates, so it's a standalone vibe β¨.
Abstract πΈ
Okay so, a 4G mobile network uses IP-based transport for the control plane to set up the data session on the user plane, which is where the actual data gets delivered. In the current setup, multimedia content goes to a phone through IP-based unicast, which means every user gets their own separate stream from the server. Bestie, that's super inefficient for bandwidth and routing π.
Evolved multimedia broadcast and multicast service (eMBMS) can deliver content to lots of users at once, but it's barely deployed or still experimental because of a bunch of challenges π.
This doc lists the ways you could use Information-Centric Networking (ICN) in 4G mobile networks, and it walks through experimental setups so people can keep evaluating them. These setups give guidance for using ICN natively or alongside an existing mobility protocol stack. With more investigation based on the listed experiments, ICN could be a real alternative to IP transport in 4G, thanks to its built-in strengths: network-layer multicast, anchorless mobility, security, and optimized data delivery using local caching at the edge. It's giving potential π₯.
Status of This Memo π
This document is not an Internet Standards Track specification. It's published for informational purposes only π§.
It's a product of the Internet Research Task Force (IRTF), which publishes the results of Internet-related research and development. Those results might not be suitable for deployment. This RFC represents the consensus of the Information-Centric Networking Research Group of the IRTF. Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841 π.
You can find info about this document's current status, any errata, and how to give feedback at https://www.rfc-editor.org/info/rfc9269 π.
Copyright Notice Β©οΈ
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document π.
Table of Contents ποΈ
1. Introduction
2. 3GPP Terminology and Concepts
3. 4G Mobile Network Architecture
3.1. Network Overview
3.2. Mobile Network Quality of Service
3.3. Data Transport Using IP
3.4. Virtualized Mobile Networks
4. Data Transport Using ICN
5. Experimental Scenarios for ICN Deployment
5.1. General Considerations
5.2. Scenarios of ICN Integration
5.3. Integration of ICN in 4G Control Plane
5.4. Integration of ICN in 4G User Plane
5.4.1. Dual Transport (IP/ICN) Mode in Mobile Terminal
5.4.2. Using ICN in Mobile Terminal
5.4.3. Using ICN in eNodeB
5.4.4. Using ICN in Packet Core Gateways (SGW/PGW)
5.5. An Experimental Test Setup
6. Expected Outcomes from Experimentation
6.1. Feeding into ICN Research
6.2. Use of Results Beyond Research
7. IANA Considerations
8. Security and Privacy Considerations
8.1. Security Considerations
8.2. Privacy Considerations
9. Summary
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Authors' Addresses1. Introduction β¨
Let's start with the basics π . 4G mobile tech is built as an all-IP network, and it uses routing protocols (OSPF, IS-IS, BGP, etc.) to set up network routes. The thing that makes a device connect to a mobile network is its IP address sticking to it. That same IP address stays with the device for the whole session, until the device detaches or moves to another network π¦.
The key protocols in 4G networks are the General Packet Radio Service Tunneling Protocol (GTP), DIAMETER, and other protocols built on top of IP. The biggest problem with IP-based routing in 4G is that it isn't optimized for data transport π€. So this document is looking at a different option: it presents and lists the possible ways to integrate Information-Centric Networking (ICN) into 3GPP 4G mobile networks. ICN brings some seriously iconic capabilities to the table, like in-network caching, multicast, anchorless mobility management, and authentication π. It also talks about how each option affects mobile providers and end users π.
The goal of the proposed experiments is to set up simulated environments where people can evaluate the benefits of deploying ICN in a 4G mobile network, across the different scenarios analyzed in this document π§. The Information-Centric Networking Research Group (ICNRG) reached consensus to publish this document, so that experiments can show deployment options and both qualitative and quantitative benefits of ICN in 4G mobile networks. Main character energy, honestly π«Ά.
2. 3GPP Terminology and Concepts β¨
okay bestie, this section is the glossary for all the 3GPP lingo π we'll be throwing around, so grab a snack and let's go π
Access Point Name: The Access Point Name (APN) is a Fully Qualified Domain Name (FQDN) π and it resolves to a set of gateways in an operator's network. An APN tells you which packet data network (PDN) a mobile data user wants to talk to π¬. On top of naming a PDN, an APN can also be used to define the type of service, QoS, and other logical entities inside a Gateway General Packet Radio Service Support Node (GGSN) or a Packet Data Network Gateway (PGW) π.
Control Plane: The control plane carries signaling traffic π£ and handles routing between the eNodeB and the Mobile Management Entity (MME), between the MME and the Home Subscriber Server (HSS), between the MME and the Mobile Gateways (SGW/PGW), and so on. Control plane signaling is required to authenticate and authorize the mobile terminal and to set up a mobility session with Mobile Gateways (SGW/PGW) π. Control plane functions also cover system configuration and management βοΈ.
Dual Address PDN/PDP Type: The dual address Packet Data Network / Packet Data Protocol (PDN/PDP) Type (IPv4v6) is used in the 3GPP context, and in a lot of cases it's just a synonym for dual stack π¦. That means a connection type that can serve IPv4 and IPv6 at the same time π.
eNodeB: The eNodeB is a base station entity that supports the Long Term Evolution (LTE) air interface π‘.
Evolved Packet Core: The Evolved Packet Core (EPC) is an evolution of the 3GPP GPRS system π§. It's higher-data-rate, lower-latency, and packet-optimized π¨. The EPC includes some subcomponents of the EPS core, such as the MME, Mobile Gateways (SGW/PGW), and the HSS π«Ά.
Evolved Packet System: The Evolved Packet System (EPS) is also an evolution of the 3GPP GPRS system, and it's higher-data-rate, lower-latency, and packet-optimized too β¨. The big difference is that it supports multiple Radio Access Technologies (RATs) π. The EPS is made up of the EPC together with Evolved Universal Terrestrial Radio Access (E-UTRA) and the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) π§©.
Evolved UTRAN: The Evolved UTRAN (E-UTRAN) is a communications network that's sometimes called 4G πΆ, and it consists of eNodeBs (4G base stations) πΌ. The E-UTRAN allows connectivity between the User Equipment and the core network π.
Gateway GPRS Support Node: The Gateway GPRS Support Node (GGSN) is a gateway function in the GPRS and 3G network π. It provides connectivity to the Internet or other PDNs πΈ. The host attaches to a GGSN that's identified by an APN, and that APN is assigned to it by an operator ποΈ. The GGSN also acts as the topological anchor for the addresses/prefixes assigned to the User Equipment π.
General Packet Radio Service: The General Packet Radio Service (GPRS) is a packet-oriented mobile data service π±. It's available to users of the 2G and 3G cellular communication systems (the GSM) specified by 3GPP π .
GPRS Tunneling Protocol: The GPRS Tunneling Protocol (GTP) [TS29.060] [TS29.274] [TS29.281] is a tunneling protocol defined by 3GPP π. It's a network-based mobility protocol that works similarly to Proxy Mobile IPv6 (PMIPv6) πͺ. GTP also does more than mobility, though, like in-band signaling related to QoS and charging, among other things π°.
Home Subscriber Server: The Home Subscriber Server (HSS) [TS29.336] is a database for a given subscriber ποΈ, and it was introduced in 3GPP Release 5 π. It's the entity that holds the subscription-related information used to support the network entities that handle calls/sessions π.
Mobile Terminal/User Equipment: The terms User Equipment (UE), Mobile Station (MS), Mobile Node (MN), and mobile all refer to devices that are hosts with the ability to get Internet connectivity via a 3GPP network π². An MS is made up of the Terminal Equipment (TE) and an MT π§Έ. In this document, the terms MT, MS, MN, and mobile are used interchangeably π.
Mobility Management Entity: The Mobility Management Entity (MME) is a network element in charge of control plane functionalities ποΈ. Those include authentication, authorization, bearer management, Layer 2 mobility, and so on π. The MME is basically the control plane part of the SGSN in GPRS π§ . User-plane traffic bypasses the MME π.
Packet Data Network: The Packet Data Network (PDN) is a packet-based network π¦. It either belongs to the operator or it's an external network, like 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 π§.
Packet Data Network Gateway: The Packet Data Network Gateway (PGW) is a gateway function in the EPS π·. It provides connectivity to the Internet or other PDNs π«. The host attaches to a PGW that's identified by an APN, and that APN is assigned to it by an operator π«. The PGW also acts as the topological anchor for the addresses/prefixes assigned to the User Equipment π§.
Packet Data Protocol Context: 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 π.
Packet Data Protocol Type: A Packet Data Protocol Type (PDP Type) identifies the protocols that are used or allowed within the PDP context π. Examples are IPv4, IPv6, and IPv4v6 (dual stack) π¦.
Policy and Charging Control: The Policy and Charging Control (PCC) framework is used for QoS policy 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 it's needed if you want dynamic policy and charging control through PCC rules based on users and services πͺ©.
Public Land Mobile Network: 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) π’. Every (telecommunications) operator that provides mobile services has its own PLMN π.
Serving Gateway: The Serving Gateway (SGW) is a gateway function in the EPS, and it 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 basically the user-plane part of the GPRS's SGSN π©·.
Serving GPRS Support Node: The Serving GPRS Support Node (SGSN) is a network element that sits between the Radio Access Network (RAN) and the gateway (GGSN) π§. A per-MT point-to-point (P2P) tunnel between the GGSN and the SGSN carries the packets between the mobile terminal and the gateway π.
User Plane: The user plane refers to data traffic and the bearers that the data traffic requires π¨. In practice, IP is the only data traffic protocol used in the user plane π.
3. 4G Mobile Network Architecture π
This section gives a high-level overview of a typical 4G mobile network architecture πΊοΈ, plus the key functions related to whether it can be used with ICN technology π¦.
3.1. Network Overview β¨
okay so 4G mobile networks are built to use IP transport for talking between the eNodeB, MME, SGW, PGW, HSS, Policy and Charging Rule Function (PCRF), etc. [GRAYSON] π For backward compatibility with 3G, they still support legacy circuit switch features like voice and SMS through transitional CS fallback and flexible IP Multimedia Subsystems (IMS) deployment π. For each mobile device attached to the radio (eNodeB), there's a separate overlay tunnel (GTP) between the eNodeB and the Mobile Gateways (i.e., SGW/PGW) π¦
When any mobile terminal powers up, it attaches to a mobile network based on its configuration and subscription π±. After a successful attachment procedure, the mobile terminal registers with the mobile core network using IPv4 and/or IPv6 addresses, based on the request and the capabilities the Mobile Gateways offer πΈ
The GTP tunnel carries user traffic between the gateways and mobile terminals, so any data transfer uses unicast delivery π It's also important to understand the overhead from GTP and IPsec π All mobile backhaul traffic is encapsulated in a GTP tunnel, which adds 8 bytes on top of IP and UDP [NGMN] π Then, if IPsec is used for security (which is often required when the Service Provider is using a shared backhaul), it adds overhead based on the IPsec tunneling model (tunnel or transport), plus whatever encryption and authentication header algorithm is used π If we take Advanced Encryption Standard (AES) encryption as an example, the overhead can be significant [OLTEANU], especially for smaller payloads π
+-------+ Diameter +-------+
| HSS |------------| SPR |
+-------+ +-------+
| |
+------+ +------+ S4 | +-------+
| 3G |---| SGSN |----------------|------+ +------| PCRF |
^ |NodeB | | |---------+ +---+ | | +-------+
+-+ | +------+ +------+ S3 | | S6a | |Gxc |
| | | +-------+ | | |Gx
+-+ | +------------------| MME |------+ | | |
MT v | S1MME +-------+ S11 | | | |
+----+-+ +-------+ +-------+
|4G/LTE|------------------------------| SGW |-----| PGW |
|eNodeB| S1U +-------+ +--| |
+------+ | +-------+
+---------------------+ | |
S1U GTP Tunnel traffic | +-------+ | |
S2a GRE Tunnel traffic |S2A | ePDG |-------+ |
S2b GRE Tunnel traffic | +-------+ S2B |SGi
SGi IP traffic | | |
+---------+ +---------+ +-----+
| Trusted | |Untrusted| | CDN |
|non-3GPP | |non-3GPP | +-----+
+---------+ +---------+
| |
+-+ +-+
| | | |
+-+ +-+
MT MT
Figure 1: 4G Mobile Network OverviewIf we look at GTP, IPsec, and unicast traffic together, data delivery isn't very efficient because of all that overhead π© The IETF has developed various header compression algorithms to shrink the overhead on IP packets β¨ Some techniques are RObust Header Compression (ROHC) and Enhanced Compression RTP (ECRTP), so the overhead created by GTP, IPsec, etc. gets reduced to some extent [BROWER] π§ For commercial mobile networks, 3GPP has adopted different header compression mechanisms to get better delivery efficiency [TS25.323] π«Ά Those solutions can be adapted to other data protocols too, such as ICN [RFC9139] [TLVCOMP] π
3.2. Mobile Network Quality of Service π
During the mobile terminal attachment procedure, a default bearer is created for each mobile terminal and assigned to the default Access Point Name (APN), which gives it the default transport π For any QoS-aware application, one or more new dedicated bearers are set up between an eNodeB and a Mobile Gateway π₯ A dedicated bearer can be requested by either the mobile terminal or a Mobile Gateway, depending on the direction of the first data flow π¦ There are lots of bearers (logical paths) between an eNodeB and a Mobile Gateway for each mobile terminal, each catering to a different data flow at the same time β¨
Traffic inside one bearer gets the same treatment, but the QoS parameters that support these requirements can be super granular across different bearers π These values vary for control, management, and user traffic, and they can be really different depending on application key parameters like latency, jitter (important for voice and other real-time applications), packet loss, and queuing mechanism (strict priority, low latency, fair, and so on) π
QoS for mobile networks is implemented in two stages: 1) content prioritization/marking and transport marking, and 2) congestion management π From the transport perspective, QoS is defined at Layer 2 as Class of Service (CoS) and at Layer 3 as Differentiated Services (DS) πΈ The mapping of the Differentiated Services Code Point (DSCP) to CoS happens at Layer 2/3 switching and routing elements π«Ά 3GPP has a specified QoS Class Identifier (QCI), which represents different types of content and equivalent mappings to the DSCP at the transport layer [TS23.401] π§ However, this needs manual configuration at different elements, so it's prone to possible misconfigurations π¬
In summary, QoS configuration in mobile networks for user-plane traffic requires synchronization of parameters across different platforms π Normally, QoS in IP is implemented using DiffServ, which uses hop-by-hop QoS configuration at each router π Any inconsistency in IP QoS configuration at routers along the forwarding path can lead to a poor subscriber experience (e.g., a packet classified as high priority can end up in a lower-priority queue) π By deploying ICN, we intend to improve the subscriber experience with policy-based configuration, which can be associated with the named contents [ICNQoS] at the ICN forwarder π₯ Further investigation is underway to understand how QoS in ICN [QoS-ICN] can be implemented with reference to the ICN QoS guidelines [RFC9064], to meet the QoS requirements [RFC4594] π
3.3. Data Transport Using IP π¦
The data delivered to mobile devices is sent with unicast semantics inside the GTP tunnel, from an eNodeB to a PDN gateway (PGW) as described in 3GPP specifications [TS23.401] π Multicast delivery is technically possible, but there are a lot of difficulties with multicast protocol implementations on the RAN side of the network π΅ By using eMBMS [EMBMS], multicast routing can be enabled in the mobile backhaul between an eNodeB and the Mobile Gateways (SGW/PGW) π However, the radio interface requires broadcast, which means we'd need a dedicated radio channel π‘ Implementing eMBMS in the RAN is still lagging behind because of complexities around client mobility and handovers, and because the potential gain for Service Providers may not justify the investment π€ That's why unicast delivery is so common in mobile networks π«Ά Techniques for multicast (such as LTE-B or eMBMS) were designed for pre-planned content delivery, like live content, which contrasts with how users behave today, largely following a content (or video) on-demand model πΊ
To ease the bandwidth burden on the Service Gateway interface (SGi), caching is introduced in a similar way to many enterprises π In mobile networks, cached data gets delivered whenever possible πΈ Caching servers are placed at a centralized location, typically in the Service Provider's Data Center, or in some cases spread lightly across packet core locations, with the PGW nodes close to the Internet and IP services access (SGi) π§ This is a very inefficient concept, because traffic has to traverse the entire backhaul path for the data to reach the end user π Other issues, such as out-of-order delivery, add to this complexity and inefficiency, and they need to be addressed at the application level π
3.4. Virtualized Mobile Networks π
The Mobile Gateways deployed in a major Service Provider network are based on either dedicated hardware or commercial off-the-shelf (COTS) x86 technology π» With the rise of Mobile Virtual Network Operators (MVNOs), public safety networks, and enterprise mobility networks, an elastic mobile core architecture is needed π By deploying the mobile packet core on a COTS platform, using a Network Function Virtualization Infrastructure (NFVI) framework and end-to-end orchestration, new deployments can be simplified to provide an optimized total cost of ownership (TCO) π«Ά
Virtualization is growing, and many mobile providers use a hybrid architecture made of dedicated and virtualized infrastructures, but the control and data planes are still the same π¦ There's also work underway to separate the control and user plane so the network can scale better π Virtualized mobile networks and network slicing with control and user-plane separation provide a way to evolve the GTP-based architecture toward OpenFlow, with signaling based on Software-Defined Networking (SDN) for 4G and the proposed 5G core β¨ Some early 5G architecture work provides a mechanism for control and user-plane separation and simplifies the mobility call flow by introducing OpenFlow-based signaling [ICN5G] π This has been considered by 3GPP [EPCCUPS] and is also described in [SDN5G] π
4. Data Transport Using ICN β¨
Okay so, for mobile devices, the edge connectivity is between a mobile terminal and a router or mobile edge computing (MEC) [MECSPEC] element. Edge computing can process client requests and split control traffic from user traffic right at the edge of the radio, instead of sending every request all the way to the Mobile Gateway. The main character energy is real π πΈ
+----------+
| Content +----------------------------------------+
| Publisher| |
+---+---+--+ |
| | +--+ +--+ +--+ |
| +--->|R1|------------>|R2|---------->|R4| |
| +--+ +--+ +--+ |
| | Cached |
| v content |
| +--+ at R3 |
| +========|R3|---+ |
| # +--+ | |
| # | |
| v v |
| +-+ +-+ |
+---------------| |-------------| |-------------+
+-+ +-+
Consumer-1 Consumer-2
Mobile Terminal Mobile Terminal
===> Content flow from cache
---> Content flow from publisher
Figure 2: ICN ArchitectureEdge computing turns a Radio Access Network into an intelligent service edge π§ that can deliver services directly from the edge of the network while still giving the client the best possible performance. β¨ Edge computing can be a really good fit for running ICN forwarders, on top of its usual job of managing mobile termination. Other transport elements, like routers, can also work as ICN forwarders. Iconic, honestly π
Data transport using ICN is different from IP-based transport because it makes uniquely named data a core design principle π Communication in ICN happens between the content provider (producer) and the end user (consumer), as shown in Figure 2.
Every node on a physical path between a client and a content provider is called an ICN forwarder or router π«Ά It can route requests intelligently and cache content, so it can be delivered locally for later requests from any other client. For mobile networks, transport between a client and a content provider is made up of a radio network + mobile backhaul, IP core transport + Mobile Gateways, the Internet, and a Content Delivery Network (CDN). Lots of moving parts, bestie π
To understand how well ICN suits mobile networks, we'll go through the ICN framework by looking at its protocol architecture and its different message types. This helps when we think about using ICN in mobile networks to deliver content more efficiently π ICN uses two types of packets: the "interest packet" and the "data packet", as shown in Figure 3.
+------------------------------------+
Interest | +------+ +------+ +------+ | +-----+
+-+ ---->| CS |---->| PIT |---->| FIB |--------->| CDN |
| | | +------+ +------+ +------+ | +-----+
+-+ | | Add | Drop | | Forward
MT <--------+ Intf v Nack v |
Data | |
+------------------------------------+
+------------------------------------+
+-+ | Forward +------+ | +-----+
| | <-------------------------------------| PIT |<---------| CDN |
+-+ | | Cache +--+---+ | Data +-----+
MT | +--v---+ | |
| | CS | v |
| +------+ Discard |
+------------------------------------+
Figure 3: ICN Interest, Data Packet, and ForwarderIn a 4G network, when a mobile device wants certain content, it sends an Interest message to the closest eNodeB π Interest packets follow the TLV format [RFC8609] and contain mandatory fields, such as the content's name and content-matching restrictions (KeyIdRestr and ContentObjectHashRestr) expressed as a tuple [RFC8569]. That content-matching tuple uniquely identifies the matching data packet for a given Interest packet. There's also an attribute called "HopLimit" that's used to detect looping Interest messages π
An ICN router receives an Interest packet and checks whether a request for that content has already come in from another client. If it has, the packet may be served from the local cache; otherwise, the request is forwarded to the next-hop ICN router. Each ICN router maintains three data structures: the Pending Interest Table (PIT), the Forwarding Information Base (FIB), and the Content Store (CS). The Interest packet travels hop by hop towards the content provider. Once it reaches the content provider, a data packet comes back containing information such as the content name, a signature, and the actual data π
The data packet travels in the reverse direction, following the same path the Interest packet took, which keeps routing symmetry π¦ Details about the algorithms used in the PIT, FIB, and CS, and about security trust models, are described in various resources [CCN]. Here, we've covered the concept and how it applies to the 4G network. Bookmark those resources, bestie πβ¨
5. Experimental Scenarios for ICN Deployment
In 4G mobile networks, both user and control plane traffic have to be carried from the edge to the mobile packet core over IP transport π The evolution of the existing mobile packet core using Control and User Plane Separation (CUPS) [TS23.714] makes networking and operations more flexible. It does this through distributed deployment and by letting control plane and user-plane functions scale independently, without affecting the functionality of existing nodes subject to this split π·
In this section, we look at the potential impact of ICN on control and user-plane traffic for centralized and disaggregated CUPS-based mobile network architectures. We list various experimental options and opportunities for studying whether ICN can be deployed in 4G networks π¬ These proposed experiments would help network designers and original equipment manufacturer (OEM) designers understand the various issues, optimizations, and advantages of deploying ICN in 4G networks. It's giving research era π§ͺπ
5.1. General Considerations
In the CUPS architecture, there's an opportunity to shorten the path for user-plane traffic by deploying offload nodes closer to the edge [OFFLOAD]. With this major architecture change, a User Plane Function (UPF) node is placed close to the edge, so traffic no longer has to traverse the entire backhaul path to reach the EPC. In many cases, where it's feasible, the UPF can be collocated with the eNodeB, which is also a business decision based on user demand π Placing a Publisher close to the offload site, or at the offload site, gives a significant improvement in user experience, especially for latency-sensitive applications. This capability allows for the introduction of ICN and amplifies its advantages. Main character update, no cap πβ
5.2. Scenarios of ICN Integration β¨
Okay bestie, ICN integration is where things get spicy πΆοΈ Putting ICN into 4G mobile networks gives us a chance to make the existing data transport even better π Honestly, it's giving the same vibe as when IPv6 was rolled out to play nice with IPv4. The big difference is that with ICN, the whole IP stack can be swapped out entirely π We went through [RFC6459] and looked at how ICN would affect control plane signaling and user-plane data delivery π§ Generally speaking, ICN can be used natively by replacing IP transport (IPv4 and IPv6), or it can run as an overlay protocol π¦ Figure 4 shows one idea for changing the existing transport protocol stack so ICN works in a 4G mobile network π
+----------------+ +-----------------+
| ICN App (new) | |IP App (existing)|
+---------+------+ +-------+---------+
| |
+---------+----------------+---------+
| Transport Convergence Layer (new) |
+------+---------------------+-------+
| |
+------+------+ +------+-------+
|ICN function | | IP function |
| (New) | | (Existing) |
+------+------+ +------+-------+
| |
(```). (```).
( ICN '`. ( IP '`.
( Cloud ) ( Cloud )
` __..'+' ` __..'+'Figure 4: IP/ICN Convergence Scenarios
So as Figure 4 shows, if apps (whether they're on the mobile terminal or in the content provider's system) want to use the ICN transport option, we're proposing a brand new transport convergence layer (TCL) π The TCL is the one that decides which transport to use (ICN or IP) and which radio interface to use (LTE, Wi-Fi, or both) for sending and receiving traffic π That decision is based on preferences like content location, content type, content publisher, congestion, cost, or QoS π It also helps set up the type of connection (native IP or ICN) or the overlay mode (ICNoIP or IPoICN) between the app and the protocol stack (IP or ICN) π«Ά
Together with the existing IP function, the ICN function supports native ICN and/or dual transport (ICN/IP) functionality π₯ See Section 5.4.1 for the full tea on these functional layers β¨
The TCL has a few ways to pick a transport π It can use per-application configuration through a management interface, or maybe a user-facing setting in a user interface, kind of like how people pick cellular over Wi-Fi π± Another option is a software API, which an adapted IP application could call to choose the transport type (such as ICN) and get its benefits π
Another cute use for the TCL is network slicing, with local slice management or through an interface to an external slice manager via an API [GALIS] πΈ This setup can let the mobile terminal itself handle network slicing for IP and ICN transport selection π¦ The TCL could apply slice settings so certain application traffic goes over one slice and other traffic goes over a different one, based on some kind of 'slicing policy' π That slicing policy can come from the slice manager externally or be configured locally on the mobile terminal π«§
From the point of view of applications, whether on the mobile terminal or at a content provider, these are the options for using ICN natively and/or with IP π
- IP over IP (IPoIP): Here the mobile terminal's applications are tightly integrated with the existing IP transport infrastructure π· The TCL doesn't need any extra function, because packets are forwarded directly using an IP protocol stack, which sends them over the IP transport π§
- ICN over ICN (ICNoICN): This is like case 1, except the ICN applications are tightly integrated with the ICN transport infrastructure π The TCL has no extra responsibility, because packets are forwarded directly using the native ICN protocol stack, which sends them over the ICN transport β¨
- ICN over IP (ICNoIP): In this scenario, the underlying IP transport infrastructure isn't affected at all. ICN runs as an IP overlay between the mobile terminal and the content provider π¦ IP routing is used from the Radio Access Network (eNodeB) to the mobile backhaul, the IP core, and the Mobile Gateway (SGW/PGW) π The mobile terminal attaches to the Mobile Gateway (SGW/PGW) using an IP address π Data transport between the Mobile Gateway (SGW/PGW) and the content publisher also uses IP πΈ The content provider can serve content using either IP or ICN, depending on what the mobile terminal asks for π
One approach to implementing ICN in mobile backhaul networks is described in [MBICN] π It uses a General Tunneling Protocol - User Plane (GTP-U) extension header option to put the ICN payload inside a GTP tunnel π«Ά But since this design runs ICN as an IP overlay, the mobile backhaul can still be deployed with native IP π The proposal describes a mechanism where the GTP-U tunnel can be terminated by hairpinning the packet before it reaches the SGW, if there's an ICN-enabled node deployed in the mobile backhaul (that is, between eNodeB and SGW) π₯ This can be handy when an ICN data packet is stored in an ICN node (like repositories and caches) on the tunnel path, so that the ICN node can reply without the packet having to go all the way through the mobile core π A GTP-U extension header carries the mobile-terminal-specific ICN payload, and that payload isn't visible to the transport, including the SGW π The PGW, on the other hand, can use the mobile-terminal-specific ICN header extension and ICN payload to set up an uplink transport toward a content provider on the Internet π The design also assumes a proxy function at the edge that does ICN data retrieval on behalf of a non-ICN end device π§
- IP over ICN (IPoICN): [IPoICN] provides an architectural framework for running IP as an overlay over the ICN protocol π· Running IP services over ICN gives us a way to get the benefits of ICN in the transport infrastructure, and there's no impact on end devices (MT and access network) because they keep using IP π IPoICN does need an interworking function (IWF) (and a Border Gateway) to translate the various transport primitives π«Ά The IWF will provide a mechanism for protocol translation between IPoICN and native IP π After reviewing [IPoICN], we understand and interpret that ICN is implemented natively in the transport, while IP is implemented in the MT, the eNodeB, and the Mobile Gateway (SGW/PGW), which is also called a network attach point (NAP) π
So the NAP takes in an incoming IP or HTTP packet (for HTTP, the TCP connection gets terminated first) and publishes the packet under a suitable ICN name π¦ For an IP packet, that name is a hash over the destination IP address, and for an HTTP packet it's a hash over the FQDN of the HTTP request π Then it publishes the packet to the ICN network β¨ In the HTTP case, the NAP keeps a pending request mapping table so it can map returning responses back to the terminated TCP connection π
- Hybrid ICN (hICN): There's another way to run ICN over IP, called Hybrid ICN [HICN] π It integrates ICN into IPv6 without making overlays with a new packet format as encapsulation π§ hICN addresses content by encoding a location-independent name in an IPv6 address π It uses two name components, a name prefix and a name suffix, which identify the source of data and the data segment within the scope of the name prefix, respectively π
At the application layer, hICN maps the name into an IPv6 prefix, so it uses IP as transport π¦ As long as the name prefixes (which are routable IP prefixes) point toward 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 π«Ά Lastly, since hICN itself uses IPv6, it can't be considered an alternative transport layer π
5.3. Integration of ICN in 4G Control Plane β¨
Okay so this part is all about the control plane, which is the bundle of signaling messages behind things like attach, handover, tracking area update, and so on π‘. The big question is whether swapping IP-based protocols for ICN in 4G signaling would actually help in the current architecture π€. Spoiler: you'll see the answer below π. First, you need the concept of point of attachment (POA) π . When a mobile terminal connects to a network, it has these POAs:
- eNodeB managing location or physical POA
- Authentication and Authorization (MME, HSS) managing identity or authentication POA
- Mobile Gateways (SGW/PGW) managing logical or session management POA
Right now, IP transport carries every control plane message for mobility and session management π«Ά. IP is baked in really deep here. The messages use TLV syntax to carry extra attributes, like a Layer 3 transport. The physical POA in the eNodeB handles both mobility and session management for any mobile terminal attached to a 4G network π¦. Table 1 shows how many mobility management messages go between the different nodes for each signaling procedure π.
Two kinds of mobile terminal usually attach to a 4G network. There are SIM based ones, which need a 3GPP mobility protocol for authentication, and non-SIM based ones, which connect to Wi-Fi networks π±. Both types need authentication. For non-SIM based devices, Authentication, Authorization, and Accounting (AAA) is used π. We do not propose changing mobile terminal authentication or mobility management messaging for user data transport using ICN, not even a little bit π . A separate study would be needed to look at how ICN affects mobility management messages, structures, and flows π. For now we're only checking whether ICN is viable as a transport for control plane messages π§.
Here's the important bit π¨. If MME and HSS don't support ICN transport, they still need to support a mobile terminal that's capable of dual transport or native ICN. When a mobile terminal sends an attach request using the identity as ICN, the MME must be able to parse that message and create a session. The MME passes the mobile terminal's authentication along to HSS, so HSS must be able to authenticate an ICN-capable mobile terminal and authorize Create Session [TS23.401] π.
+===========================+=====+=====+=====+=====+======+
| 4G Signaling Procedures | MME | HSS | SGW | PGW | PCRF |
+===========================+=====+=====+=====+=====+======+
| Attach | 10 | 2 | 3 | 2 | 1 |
+---------------------------+-----+-----+-----+-----+------+
| Additional default bearer | 4 | 0 | 3 | 2 | 1 |
+---------------------------+-----+-----+-----+-----+------+
| Dedicated bearer | 2 | 0 | 2 | 2 | 0 |
+---------------------------+-----+-----+-----+-----+------+
| Idle-to-connect | 3 | 0 | 1 | 0 | 0 |
+---------------------------+-----+-----+-----+-----+------+
| Connect-to-Idle | 3 | 0 | 1 | 0 | 0 |
+---------------------------+-----+-----+-----+-----+------+
| X2 handover | 2 | 0 | 1 | 0 | 0 |
+---------------------------+-----+-----+-----+-----+------+
| S1 handover | 8 | 0 | 3 | 0 | 0 |
+---------------------------+-----+-----+-----+-----+------+
| Tracking area update | 2 | 2 | 0 | 0 | 0 |
+---------------------------+-----+-----+-----+-----+------+
| Total | 34 | 2 | 14 | 6 | 3 |
+---------------------------+-----+-----+-----+-----+------+
Table 1: Signaling Messages in 4G GatewaysAnchorless mobility [ALM] is a fully decentralized solution that doesn't care which control plane it sits on, and it handles producer mobility in ICN π. Mobility management at Layer 3 makes it access agnostic and transparent to the end device or the application β¨. The solution covers handling mobility without depending on core network functions (e.g., MME) π§. Still, a location update to the core network may be required to support legal compliance requirements such as lawful intercept and emergency services βοΈ. Those aspects are open for further study π.
Here's the tea π΅. One of the big advantages of ICN is caching and reusing content, and that doesn't apply to transactional signaling exchanges at all π. After analyzing 4G signaling call flows [TS23.401] and message interdependencies (see Table 1), our recommendation is that it is not beneficial to use ICN for control plane and mobility management functions π. Interest aggregation and content caching, which are among the features of ICN design, aren't applicable to control plane signaling messages π ββοΈ. Control plane messages are originated and consumed by the applications, and they cannot be shared π«Ά.
5.4. Integration of ICN in 4G User Plane πΈ
Time to look at the user plane! π We'll be using Figure 1 as we go through the different ways to bring ICN into mobile networks πΊοΈ. Back in Section 5.2 we covered the generic experimental setups for ICN integration π§ͺ. This section gets specific about the options for using native ICN in the 4G user plane π . The following options are considered:
- Using Dual transport (IP/ICN) mode in mobile terminal
- Using ICN in mobile terminal
- Using ICN in eNodeB
- Using ICN in Mobile Gateways (SGW/PGW)
5.4.1. Dual Transport (IP/ICN) Mode in Mobile Terminal π¦
okay so the control and user-plane comms in 4G networks are spelled out in 3GPP docs [TS23.203] and [TS23.401] π. super important detail: a mobile terminal can be a consumer (receiving content) or a publisher (pushing content out for other clients) π²β¨. the protocol stack inside the mobile terminal (MT) is kinda complex, ngl, because it has to support multiple radio connectivity access to eNodeB(s) π .
Figure 5 gives a high-level picture of that stack, where IP shows up at two layers: (1) user-plane communication and (2) UDP encapsulation πΈ. the user-plane comms happen between the Packet Data Convergence Protocol (PDCP) and the Application layer, while UDP encapsulation lives in the GTP protocol stack π§.
The protocol interactions and the impact of supporting the tunneling of an ICN packet into IP, or supporting ICN natively, are described in Figures 5 and 6, respectively π.
+--------+ +--------+
| App | | CDN |
+--------+ +--------+
|Transp. | | | | |Transp. |
|Converg.|.|..............|...............|............|.|Converge|
+--------+ | | | +--------+ | +--------+
| |.|..............|...............|.| |.|.| |
| ICN/IP | | | | | ICN/IP | | | ICN/IP|
| | | | | | | | | |
+--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+
| |.|.| | |.|.| | |.|.| | | | | |
| PDCP | | |PDCP|GTP-U| | |GTP-U|GTP-U| | |GTP-U| | | | L2 |
+--------+ | +----------+ | +-----------+ | +-----+ | | | |
| RLC |.|.|RLC | UDP |.|.| UDP | UDP |.|.|UDP |L2|.|.| |
+--------+ | +----------+ | +-----------+ | +-----+ | | | |
| MAC |.|.| MAC| L2 |.|.| L2 | L2 |.|.| L2 | | | | |
+--------+ | +----------+ | +-----------+ | +--------+ | +--------+
| L1 |.|.| L1 | L1 |.|.| L1 | L1 |.|.| L1 |L1|.|.| L1 |
+--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+
MT | BS (eNodeB) | SGW | PGW |
Uu S1U S5/S8 SGi
Figure 5: Dual Transport (IP/ICN) Mode in a Mobile TerminalThe protocols and software stack inside 4G-capable mobile terminals support both 3G and 4G software interworking and handover π₯. 3GPP Rel.13 specifications and onward describe the use of IP and non-IP protocols to establish logical/session connectivity. we can leverage that non-IP mechanism to deploy an ICN protocol stack in the mobile terminal, as well as in an eNodeB and the Mobile Gateways (SGW/PGW) π. the following paragraphs walk through per-layer considerations of supporting the tunneling of ICN packets into IP, or supporting ICN natively π.
- An existing application layer can be modified to provide options for a new ICN-based application and existing IP-based applications. The mobile terminal can keep supporting existing IP-based applications, or develop new ones to support native ICN, ICNoIP, or IPoICN-based transport. The application layer can be given an option to select either ICN or IP transport, as well as the radio interface, to send and receive data traffic π·.
Our proposal is to provide an Application Programming Interface (API) to application developers so they can choose either ICN or IP transport for exchanging traffic with the network π. As mentioned in Section 5.2, the TCL function handles the interaction of applications with multiple transport options.
- The transport convergence layer helps determine the type of transport (such as ICN, hICN, or IP) and the type of radio interface (LTE, Wi-Fi, or both) used to send and receive traffic π¦. The application layer can make the decision to select a specific transport based on preferences such as content location, content type, content publisher, congestion, cost, QoS, and so on. There can be an API to exchange parameters required for transport selection. Southbound interactions of the TCL will be either to IP or to ICN at the network layer β¨.
When selecting the IPoICN mode, the TCL is responsible for receiving an incoming IP or HTTP packet and publishing the packet to the ICN network under a suitable ICN name (that is, the hash over the destination IP address for an IP packet, or the hash over the FQDN of the HTTP request for an HTTP packet) π§.
In the HTTP case, the TCL can maintain a pending request mapping table to map returning responses to the originating HTTP request. The common API will provide a "connection" abstraction for this HTTP mode of operation, returning the response over that connection abstraction (akin to the TCP socket interface) while implementing a reliable transport connection semantic over the ICN from the mobile terminal to the receiving mobile terminal or the PGW π«Ά. If the HTTP protocol stack remains unchanged, and therefore utilizes the TCP protocol for transfer, the TCL operates in local TCP termination mode, retrieving the HTTP packet through said local termination π.
+----------------+ +-----------------+
| ICN App (new) | |IP App (existing)|
+---------+------+ +-------+---------+
| |
+---------+----------------+---------+
| Transport Convergence Layer (new) |
+------+---------------------+-------+
| |
+------+------+ +------+-------+
|ICN function | | IP function |
| (New) | | (Existing) |
+------+------+ +------+-------+
| |
+------+---------------------+-------+
| PDCP (updated to support ICN) |
+-----------------+------------------+
|
+-----------------+------------------+
| RLC (Existing) |
+-----------------+------------------+
|
+-----------------+------------------+
| MAC Layer (Existing) |
+-----------------+------------------+
|
+-----------------+------------------+
| Physical L1 (Existing) |
+------------------------------------+
Figure 6: Dual Stack ICN Protocol Interactions- The ICN function (forwarder) is proposed to run in parallel to the existing IP layer π. The ICN forwarder forwards ICN packets, such as an Interest packet to an eNodeB, or a response "data packet" from an eNodeB to the application.
- For the dual-transport scenario, when a mobile terminal is not supporting ICN as transport, the TCL can use the IP underlay to tunnel the ICN packets π. The ICN function can use the IP interface to send Interest and Data packets for fetching or sending data, respectively. This interface can use the ICN overlay over IP.
- To support ICN at the network layer in the mobile terminal, the PDCP layer should be aware of ICN capabilities and parameters π₯. PDCP is located in the Radio Protocol Stack in the LTE Air interface, between the IP (Network layer) and the Radio Link Control Layer (RLC). PDCP performs the following functions [TS36.323]:
- Data transport by listening to the upper layer, formatting, and pushing down to the RLC
- Header compression and decompression using ROHC
- Security protections such as ciphering, deciphering, and integrity protection
- Radio layer messages associated with sequencing, packet drop detection and retransmission, and so on
- No changes are required for the lower layers such as RLC, Media Access Control (MAC), and Physical (L1), as they are not IP aware π.
One key point to understand in this scenario: ICN is deployed as an overlay on top of IP π«Ά.
5.4.2. Using ICN in Mobile Terminal π
We can implement ICN natively in the mobile terminal by modifying the PDCP layer in 3GPP protocols π. Figure 7 gives a high-level protocol stack description where ICN can be used at the following different layers:
- User-plane communication
- Transport layer
ICN transport would be a substitute for the GTP protocol. Removing the GTP protocol stack is a significant change to the mobile architecture and requires a thorough study π. It's mainly because GTP is used not just for routing but also for mobility management functions such as billing, mediation, and policy enforcement.
Implementing ICN natively in the mobile terminal leads to a changed communication model between the mobile terminal and the eNodeB π¦. We can also avoid tunneling the user-plane traffic from an eNodeB to the mobile packet core (SGW/PGW) through a GTP tunnel π.
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 network layer, the existing PDCP layer may need to be changed to be aware of ICN capabilities and parameters.
The native implementation can provide new opportunities to develop new use cases leveraging ICN capabilities, such as seamless mobility, mobile terminal to mobile terminal content delivery using a radio network without traversing the Mobile Gateways, and more β¨.
+--------+ +--------+
| App | | CDN |
+--------+ +--------+
|Transp. | | | | | |Transp. |
|Converge|.|..............|..............|..............|.|Converge|
+--------+ | | | | +--------+
| |.|..............|..............|..............|.| |
| ICN/IP | | | | | | |
| | | | | | | |
+--------+ | +----+-----+ | +----------+ | +----------+ | | ICN/IP |
| |.|.| | | | | | | | | | | |
| PDCP | | |PDCP| ICN |.|.| ICN |.|.| ICN |.|.| |
+--------+ | +----+ | | | | | | | | | |
| RLC |.|.|RLC | | | | | | | | | | |
+--------+ | +----------+ | +----------+ | +----------+ | +--------+
| MAC |.|.| MAC| L2 |.|.| L2 |.|.| L2 |.|.| L2 |
+--------+ | +----------+ | +----------+ | +----------+ | +--------+
| L1 |.|.| L1 | L1 |.|.| L1 |.|.| L1 |.|.| L1 |
+--------+ | +----+-----+ | +----------+ | +----------+ | +--------+
MT | BS(eNodeB) | SGW | PGW |
Uu S1u S5/S8 SGi
Figure 7: Using Native ICN in Mobile TerminalOkay so this is the part where the eNodeB and the packet core get their glow-up, bestie πβ¨ Let's go!
5.4.3. Using ICN in eNodeB π
okay so the eNodeB is the physical point where the mobile terminal actually plugs into the network πβ¨ it's the spot where radio protocols get turned into IP transport protocols (for dual transport/overlay) or native ICN (see Figures 6 and 7) π¦. when a mobile terminal does its attach procedure, it gets an identity as either IP, dual transport (IP and ICN), or an ICN endpoint πΈ. and the mobile terminal can start sending data traffic using any of these options:
- Native IP (IPv4 or IPv6) π
- Native ICN π§
- Dual transport IP (IPv4/IPv6) and ICN π
the mobile terminal wraps a user data transport request into the PDCP layer and sends it over the air to the eNodeB π‘. the eNodeB receives it and, using PDCP [TS36.323], unwraps the air-interface messages and converts them so they can head on forward to the core Mobile Gateways (SGW/PGW) π. as shown in Figure 8, to support ICN natively in an eNodeB, the proposal is to give the eNodeB TCL capabilities (similar to what the MT has) π , and those give it these functions:
- It decides the forwarding strategy for a user data request coming from the mobile terminal. The strategy can decide based on preference indicated by the application, such as congestion, cost, QoS, and so on. π
- It uses an eNodeB to provide an open API to external management systems in order to provide eNodeB the capability to program the forwarding strategies. π₯
+---------------+ |
| MT request | | ICN +---------+
+---->| content using |--+--- transport -->| |
| |ICN protocol | | | |
| +---------------+ | | |
| | | |
| +---------------+ | | |
+-+ | | MT request | | IP |To mobile|
| |-+---->| content using |--+--- transport -->| GW |
+-+ | | IP protocol | | |(SGW/PGW)|
MT | +---------------+ | | |
| | | |
| +---------------+ | | |
| | MT request | | Dual stack | |
+---->| content using |--+--- IP+ICN -->| |
|IP/ICN protocol| | transport +---------+
+---------------+ |
eNodeB S1u
Figure 8: Integration of Native ICN in eNodeB- The eNodeB can be upgraded to support three different types of transport: IP, ICN, and dual transport IP+ICN towards Mobile Gateways, as depicted in Figure 8. It is also proposed to deploy IP and/or ICN forwarding capabilities into an eNodeB for efficient transfer of data between the eNodeB and Mobile Gateways. The following are choices for forwarding a data request towards Mobile Gateways: π
- Assuming the eNodeB is IP enabled and the MT requests an IP transfer, the eNodeB forwards data over IP.
- Assuming the eNodeB is ICN enabled and the MT requests an ICN transfer, the eNodeB forwards data over ICN.
- 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.
- Assuming the eNodeB is ICN enabled and the MT requests an IP transfer, the eNodeB overlays IP on ICN and forwards user-plane traffic over ICN [IPoICN].
5.4.4. Using ICN in Packet Core Gateways (SGW/PGW) π§
Mobile Gateways (a.k.a. Evolved Packet Core (EPC)) are made up of SGW and PGW, and they run session management for the MT from the initial attach all the way to disconnection π«Ά. when the MT powers on, it does Network-Access-Stratum (NAS) signaling and attaches to the PGW after successful authentication π. the PGW is the anchor point for the MT and handles service creation, authorization, maintenance, and so on π. the whole thing is managed using IP address(es) for the MT πΈ.
to bring ICN into the EPC, here's what's proposed π:
- Insert ICN attributes in the session management layer for additional functionality with IP stack. The session management layer is used for performing attach procedures and assigning logical identity to users. After successful authentication by HSS, MME sends a Create Session Request (CSR) to SGW and SGW to PGW. β¨
- When MME sends a Create Session Request message (Step 12 in [TS23.401]) to SGW or PGW, it includes a Protocol Configuration Option (PCO) Information Element (IE) containing MT capabilities. We can use PCO IE to carry ICN-related capabilities information from MT to PGW. This information is received from MT during the initial attach request in MME. Details of available TLV, which can be used for ICN, are given in subsequent sections. MT can support native IP, ICN+IP, or native ICN. IP is referred to as both IPv4 and IPv6 protocols. π¦
- For ICN+IP-capable MT, PGW assigns the MT both an IP address and ICN identity. MT selects either of the identities during the initial attach procedures and registers with the network for session management. For ICN-capable MT, it will provide only ICN attachment. For native IP-capable MT, there is no change. π
- To support ICN-capable attach procedures and use ICN for user-plane traffic, PGW needs to have full ICN protocol stack functionalities. Typical ICN capabilities include functions such as CS, PIT, FIB capabilities, and so on. If MT requests ICN in PCO IE, then PGW registers MT with ICN names. For ICN forwarding, PGW caches content locally using CS functionality. π₯
- PCO IE as described in [TS24.008] (see Figure 10.5.136 on page 656 and Table 10.5.154 on page 659) provides details for different fields. π
- Octet 3 (configuration protocols define PDN types), which contains details about IPv4, IPv6, both IPv4 and IPv6, or ICN. π
- Any combination of Octet 4 to Z can be used to provide additional information related to ICN capability. It is most important that PCO IE parameters are matched between MT and Mobile Gateways (SGW/PGW) so they can be interpreted properly and the MT can attach successfully. π
- The ICN functionalities in SGW and PGW should be matched with MT and the eNodeB because they will exchange ICN protocols and parameters. π«Ά
- Mobile Gateways (SGW/PGW) will also need ICN forwarding and caching capability. This is especially important if CUPS is implemented. User Plane Function (UPF), comprising the SGW and PGW user plane, will be located at the edge of the network and close to the end user. ICN-enabled gateway means that this UPF would serve as a forwarder and should be capable of caching, as is the case with any other ICN-enabled node. π§
- The transport between PGW and CDN provider can be either IP or ICN. When MT is attached to PGW with ICN identity and communicates with an ICN-enabled CDN provider, it will use ICN primitives to fetch the data. On the other hand, for an MT attached with an ICN identity, if PGW must communicate with an IP-enabled CDN provider, it will have to use an ICN-IP interworking gateway to perform conversion between ICN and IP primitives for data retrieval. In the case of CUPS implementation with an offload close to the edge, this interworking gateway can be collocated with the UPF at the offload site to maximize the path optimization. Further study is required to understand how this ICN-to-IP (and vice versa) interworking gateway would function. πΈ
5.5. An Experimental Test Setup π§ͺ
this section proposes an experimental lab setup and talks through the open issues and questions that using the ICN protocol is meant to address π. to further test the modifications in different scenarios, a simple lab can be set up, as shown in Figure 9 π.
+------------------------------------------+
| +-----+ +------+ (```). +------+ | (````). +-----+
| | SUB |-->| EMU |--(x-haul'.-->| EPC |--->( PDN ).-->| CDN |
| +-----+ +------+ `__..'' +------+ | `__...' +-----+
+------------------------------------------+
4G Mobile Network Functions
Figure 9: Native ICN Deployment Lab Setupthe following test scenarios can be set up with deployment based on Virtual Machine (VM) π»:
- SUB: An ICN-simulated client (using ndnSIM) - a client application on a workstation requesting content. π¦
- EMU: Test unit emulating an eNodeB. This is a test node allowing for UE attachment and routing traffic subsequently from the Subscriber to the Publisher. π
- EPC: Evolved Packet Core in a single instance (such as Open5GCore [Open5GCore]). π
- CDN: Content delivery by a Publisher server. π
for the purpose of this testing, ICN-emulating code can be inserted in the test code in EMU to emulate an ICN-capable eNodeB. an example of the code to be used is NS3 in its LTE model π§. the effect of that traffic on EPC and CDN can be observed and documented. in a later phase, EPC code supporting ICN can be tested when it's available β¨.
another option is to simulate the UE/eNodeB and EPC functions using NS3's LTE [NS3LTE] and EPC [NS3EPC] models, respectively. the LTE model includes the LTE Radio Protocol stack, which lives entirely inside the UE and eNodeB nodes, so it can simulate UE and eNodeB deployment use cases π. similarly, the EPC model includes core network interfaces, protocols, and entities, which live within the Mobile Gateways (SGW/PGW) and MME nodes and partially within the eNodeB nodes π«Ά.
even with its current limitations (such as IPv4 only, lack of integration with ndnSIM, and no support for UE idle state), LTE simulation may be a very useful tool π. either way, both control-plane and user-plane traffic should be tested independently according to the deployment model discussed in Section 5.4 π₯.
6. Expected Outcomes from Experimentation π
the experimentation explained in Section 5 can be sorted into three broader scopes. further research and study is required to fully understand and document the impact π .
Architecture scope: to study the aspect of use of ICN at the user plane to reduce the complexities in current transport protocols while also evaluating its use in the control plane π¦.
Performance scope: to evaluate the gains through multicast, caching, and other ICN features π.
Deployment scope: to check the viability of ICN inclusion in the 3GPP protocol stack and in real-world deployments π.
6.1. Feeding into ICN Research π§
okay bestie, this is the juicy part π₯ these are the open questions we still need answers to, from both the architecture side and the performance side. The experiments with ICN in 4G mobile networks could help answer them in future research:
- Efficiency gains π how much traffic can we actually save in multicast scenarios? (quantify the possible gains along different use cases) and how much faster does cached content show up, mainly in the CDN use case? π
- Coexistence drama π how would the new transport get along with the legacy transport protocols (e.g., IPv4, IPv6, MPLS, RSVP, etc.) and related services (e.g., bandwidth management, QoS handling, etc.)? would it coexist or replace them? π
- Simplification π§Ή to what extent can the IP-based transport protocols get simpler? the multiple overlays (e.g., the MPLS, VPN, Virtual Private LAN Service (VPLS), Ethernet VPN, etc.) stacked on top of current IP-based transport add complexity on top of basic IP transport, and that makes troubleshooting extremely challenging π
- Service awareness π§ how can the new transport become service aware so the whole system gets simpler?
- Control plane check π€ confirm how (in)adequate an ICN implementation would be in the control plane (which this document discourages). the 5G system, as specified in [TS23.501] (Appendix G.4), encourages name-based routing in the (5G) control plane to realize the 5G-specific service-based architecture for control plane services (so-called network function service). so it would be worthwhile to check whether the 4G control plane would benefit similarly, or whether specific 4G architectural constraints would stop ICN from providing any notable benefit. π
6.2. Use of Results Beyond Research π
with the experiments and outcomes outlined in this document, we believe this technology is ready for wider use and adoption, and it gives us extra insights β¨ specifically, we expect to study the following:
- Viability of ICN inclusion in the 3GPP protocol stack 𧩠i.e., how realistic it would be to modify the stack, considering the scenarios explained in Section 5.4, and completing the user session without feature degradation.
- Viability of utilizing solutions in greenfield deployments π± i.e., deploying the ICN-based extensions and solutions proposed in this document in greenfield 4G deployments, to assess the real-world benefits of doing so.
7. IANA Considerations π¦
zero registry drama here π«Ά this document has no IANA actions.
8. Security and Privacy Considerations π
okay, this section covers some security and privacy considerations in mobile and 4G networks because of the introduction of ICN. it's a lot, but it's important, so let's gooo π€
8.1. Security Considerations π‘οΈ
to make sure only authenticated mobile terminals connect to the network, 4G mobile networks use a bunch of security mechanisms. from the perspective of using ICN in the user plane, these security aspects need to be taken care of:
- MT authentication and authorization
- Radio or air interface security
- Denial-of-service attacks on the Mobile Gateway; services are either by the MT or by external entities in the Internet
- Content poisoning in either transport or servers
- Content cache pollution attacks
- Secure naming, routing, and forwarding
- Application security
security over the LTE air interface is handled with cryptographic techniques π when the MT powers up, it does a key exchange between the MT's Universal Mobile Telecommunications System Subscriber Identity Module (USIM) and the HSS/Authentication Center, using NAS messages, including ciphering and integrity protections between MT and MME. the details for secure MT authentication, key exchange, ciphering, and integrity protection messages are in the 3GPP call flow [TS23.401]. with ICN, we're modifying the protocol stack for the user plane and not the control plane π the NAS signaling is exchanged between the MT and Mobile Gateways (e.g., MME) using the control plane, so there's no adverse impact of ICN on the MT. no drama there β¨
4G uses IP transport in its mobile backhaul (between an eNodeB and the core network) π for provider-owned backhaul, the Service Provider may require implementing a security mechanism in the backhaul network. the native IP transport keeps leaning on security mechanisms like Internet Key Exchange (IKE) and the IP Security (IPsec) protocol. more details on mobile backhaul security are in the 3GPP network security specifications [TS33.310] and [TS33.320]. when a mobile backhaul gets upgraded to support dual transport (IP+ICN) or native ICN, it is required to implement the security techniques deployed in the mobile backhaul. and when ICN forwarding is enabled on mobile transport routers, we need to deploy security practices based on [RFC7476] and [RFC7927] π
heads up π¨ backhaul upgrades to dual transport or native ICN come with a security checklist, so don't skip it!
4G Mobile Gateways (SGW/PGW) do some key jobs like content-based online/offline billing and accounting, deep packet inspection (DPI), and lawful interception (LI) π when ICN is deployed in the user plane, we need to integrate ICN security for sessions between the MT and the gateway. if we encrypt the user-plane payload metadata, routing based on content might get tricky, 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 protect privacy. only the user with the right decryption key shall be able to access the content π we need further research on the ICN impact on LI, online/offline charging, and accounting.
8.2. Privacy Considerations π«£
in 4G networks, there are two main privacy issues [MUTHANA]:
- User Identity Privacy Issues. the main privacy issue in 4G is the exposure of the International Mobile Subscriber Identity (IMSI). adversaries can intercept it, and these attacks are commonly called "IMSI catching" π΅οΈ
- Location Privacy Issues. IMSI catching is closely related to location privacy. knowing a user's IMSI lets an attacker track their movements, build a profile about them, and breach their location privacy π
in any network, caching is a trade-off between network efficiency and privacy βοΈ users' activity is exposed to the scrutiny of cache owners they may have no relationship with. by monitoring cache transactions, an attacker could learn a lot about the objects accessed, the topology, and the timing of requests [RFC7945]. privacy concerns get amplified by new network functions like information lookup and network storage, and by different forms of communication [FOTIOU]. privacy risks in ICN can be broadly divided into these categories [TOURANI]:
- Timing attack
- Communication monitoring attack
- Censorship and anonymity attack
- Protocol attack
- Naming-signature privacy
introducing 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 boost efficiency by taking advantage of ICN's inherent characteristics π but this approach could leave some of the privacy concerns above open, because of ICN transport and ICN's inherent privacy vulnerabilities. here's how the scenarios shake out π
- IPoIP (Section 5.2) would not be affected, since TCL has no role in it and ICN doesn't apply π
- ICNoICN (Section 5.2) has an increased risk of a privacy attack. that risk applies to the ICN protocol in general rather than specifically to the 4G implementation. since this scenario describes communication over ICN transport, every forwarder in the path could be a potential privacy risk π¬
- ICNoIP (Section 5.2) uses IP for transport, so the only extra ICN-related privacy risk areas are the endpoints (consumer and publisher) where content gets served at the application layer π
- IPoICN (Section 5.2) could have increased risk because of possible vulnerability of the forwarders in the ICN transport path β οΈ
privacy issues already identified in 4G stay a concern if ICN is introduced in any of the scenarios above, and they stack up with the new ICN-related privacy issues π lots of research papers propose solutions to the privacy issues listed above. for LTE-specific privacy issues, some of the proposed solutions [MUTHANA] are: IMSI encryption by an MT; mutual authentication; concealing the real IMSI within a random bit stream of a certain size, where only the subscriber and HSS could extract the respective IMSI; IMSI replacement with a changing pseudonym that only the HSS server can map to the UE's IMSI; and others. similarly, some proposed mitigations for ICN-specific privacy concerns, applicable wherever ICN transport is introduced as specified earlier in this section, include the following [FOTIOU]:
- Delay for the first, or first k, interests on edge routers (timing attack) β³
- Creating a secure tunnel, or clients flagging the requests as non-cacheable for privacy (communication monitoring attack) π
- Encoding interest by mixing the content and cover file, or using a hierarchical DNS-based brokering model (censorship and anonymity attack) π
- Use of rate-limiting requests for a specific namespace (protocol attack) π¦
- Cryptographic content hash-based naming, or digital identity in an overlay network (naming-signature privacy) π
further research in this area is needed πΈ detailed discussion of privacy is beyond the scope of this document.
9. Summary β¨
okay bestie, let's recap π In this doc we talked about 4G networks and the experimental setups for checking how much ICN could help deliver content to mobile terminals π± We went through different ways to try and test ICN, plus the dependencies that come with it, like ICN functionalities and the changes each 4G network element would need π§
If you want to dig deeper, you can build an experimental setup with 4G network elements and deploy ICN data transport in the user plane π§ͺ The options are overlay, dual transport (IP + ICN), hICN, or going fully native by integrating ICN with CDN, eNodeB, SGW, PGW, and a transport network π Heads up though: for all of these scenarios, we still need more study on lawful interception, billing/mediation, network slicing, and provisioning APIs π
Now the Edge Computing part is giving main character energy π It [CHENG] lets you deploy stuff like CDN caching and mobile user plane functions (UPFs) [TS23.501] right at the edge πΈ Recent research on real-time video [MPVCICN] over ICN has also been proven to be efficient [NDNRTC], so it can help us get the benefits of ICN in an eNodeB, edge computing, Mobile Gateways (SGW/PGW), and CDN π The big vibe is that ICN fits seamlessly into both 4G and 5G networks with real, tangible benefits, so we can optimize content delivery with a simple and scalable architecture π«Ά The authors are going to keep exploring how ICN forwarding in edge computing could deliver data efficiently from the mobile edge π¦
Here's the tea β After studying control plane signaling, it is not beneficial to deploy ICN with existing protocols unless we introduce further changes into the control protocol stack itself π
As a starting step toward ICN in the user plane, the plan is to add protocol changes to the MT, an eNodeB, and the SGW/PGW for data transport π§ ICN has built-in mobility and content caching, which can make data transport more efficient for both unicast and multicast delivery π The authors would love contributions and suggestions, including validating these principles by building prototypes and/or proofs of concept in the lab and in production environments π Bring your ideas, we're here for it β¨
10. References π
Here's the full reading list, kept exactly as it appears in the original so nothing gets lost in translation π€
10.1. Normative References
[TS24.008] 3GPP, "Mobile radio interface Layer 3 specification; Core
network protocols; Stage 3", 3GPP TS 24.008 17.7.0, June
2022,
<https://www.3gpp.org/ftp/Specs/html-info/24008.htm>.
[TS25.323] 3GPP, "Packet Data Convergence Protocol (PDCP)
specification", 3GPP TS 25.323 17.0.0, April 2022,
<https://www.3gpp.org/ftp/Specs/html-info/25323.htm>.
[TS29.274] 3GPP, "3GPP Evolved Packet System (EPS); Evolved General
Packet Radio Service (GPRS) Tunnelling Protocol for
Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 17.6.0,
June 2022,
<https://www.3gpp.org/ftp/Specs/html-info/29274.htm>.
[TS29.281] 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 17.3.0,
June 2022,
<https://www.3gpp.org/ftp/Specs/html-info/29281.htm>.
[TS36.323] 3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); Packet Data Convergence Protocol (PDCP)
specification", 3GPP TS 36.323 17.1.0, July 2022,
<https://www.3gpp.org/ftp/Specs/html-info/36323.htm>.10.2. Informative References
[ALM] AugΓ©, J., Carofiglio, G., Grassi, G., Muscariello, L.,
Pau, G., and X. Zeng, "Anchor-Less Producer Mobility in
ICN", ACM-ICN '15: Proceedings of the 2nd ACM Conference
on Information-Centric Networking, pp. 189-190,
DOI 10.1145/2810156.2812601, September 2015,
<https://dl.acm.org/citation.cfm?id=2812601>.
[BROWER] Brower, E., Jeffress, L., Pezeshki, J., Jasani, R., and E.
Ertekin, "Integrating Header Compression with IPsec",
MILCOM 2006 - 2006 IEEE Military Communications
conference, pp. 1-6, DOI 10.1109/MILCOM.2006.302503,
October 2006,
<https://ieeexplore.ieee.org/document/4086687>.
[CCN] FD.io, "Cicn", January 2020,
<https://wiki.fd.io/index.php?title=Cicn&oldid=10316>.
[CHENG] Liang, C., Yu, R., and X. Zhang, "Information-centric
network function virtualization over 5g mobile wireless
networks", IEEE Network, Vol. 29, Issue 3, pp. 68-74, June
2015, <https://ieeexplore.ieee.org/document/7113228>.
[EMBMS] Zahoor, K., Bilal, K., Erbad, A., and A. Mohamed,
"Service-Less Video Multicast in 5G: Enablers and
Challenges", IEEE Network, Vol. 34, Issue 3, pp. 270-276,
DOI 10.1109/MNET.001.1900435, June 2020,
<https://ieeexplore.ieee.org/document/9105941>.
[EPCCUPS] Schmitt, P., Landais, B., and F. Yong Yang, "Control and
User Plane Separation of EPC nodes (CUPS)", 3GPP, The
Mobile Broadband Standard, July 2017,
<https://www.3gpp.org/news-events/3gpp-news/1882-cups>.
[FOTIOU] Fotiou, N. and G. Polyzos, "ICN privacy and name based
security", ACM-ICN '14: Proceedings of the 1st ACM
Conference on Information-Centric Networking, pp. 5-6,
DOI 10.1145/2660129.2666711, September 2014,
<https://dl.acm.org/doi/10.1145/2660129.2666711>.
[GALIS] Galis, A., Ed., Makhijani, K., Yu, D., and B. Liu,
"Autonomic Slice Networking", Work in Progress, Internet-
Draft, draft-galis-anima-autonomic-slice-networking-05, 26
September 2018, <https://datatracker.ietf.org/doc/html/
draft-galis-anima-autonomic-slice-networking-05>.
[GRAYSON] Grayson, M., Shatzkamer, M., and S. Wainner, "IP Design
for Mobile Networks", Cisco Press, Networking Technology
series, ISBN 1-58705-826-X, June 2009,
<https://www.ciscopress.com/store/ip-design-for-mobile-
networks-9781587058264>.
[HICN] Muscariello, L., Carofiglio, G., Auge, J., and M.
Papalini, "Hybrid Information-Centric Networking", Work in
Progress, Internet-Draft, draft-muscariello-intarea-hicn-
04, 20 May 2020, <https://datatracker.ietf.org/doc/html/
draft-muscariello-intarea-hicn-04>.
[ICN5G] Ravindran, R., Suthar, P., Trossen, D., Wang, C., and G.
White, "Enabling ICN in 3GPP's 5G NextGen Core
Architecture", Work in Progress, Internet-Draft, draft-
irtf-icnrg-5gc-icn-04, 10 January 2021,
<https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-
5gc-icn-04>.
[ICNQoS] Al-Naday, M.F., Bontozoglou, A., Vassilakis, G., and M. J.
Reed, "Quality of service in an information-centric
network", 2014 IEEE Global Communications Conference, pp.
1861-1866, DOI 10.1109/GLOCOM.2014.7037079, December 2014,
<https://ieeexplore.ieee.org/document/7037079>.
[IPoICN] Trossen, D., Read, M. J., Riihijarvi, J., Georgiades, M.,
Fotiou, N., and G. Xylomenos, "IP over ICN - The better
IP?", 2015 European Conference on Networks and
Communications (EuCNC), pp. 413-417,
DOI 10.1109/EuCNC.2015.7194109, June 2015,
<https://ieeexplore.ieee.org/document/7194109>.
[MBICN] Carofiglio, G., Gallo, M., Muscariello, L., and D. Perino,
"Scalable mobile backhauling via information-centric
networking", The 21st IEEE International Workshop on Local
and Metropolitan Area Networks, Beijing, pp. 1-6,
DOI 10.1109/LANMAN.2015.7114719, April 2015,
<https://ieeexplore.ieee.org/document/7114719>.
[MECSPEC] ETSI, "Mobile Edge Computing (MEC); Framework and
Reference Architecture", ETSI GS MEC 003, Version 1.1.1,
March 2016, <https://www.etsi.org/deliver/etsi_gs/
MEC/001_099/003/01.01.01_60/gs_MEC003v010101p.pdf>.
[MPVCICN] Jangam, A., Ravindran, R., Chakraborti, A., Wan, X., and
G. Wang, "Realtime multi-party video conferencing service
over information centric network", IEEE International
Conference on Multimedia and Expo Workshops (ICMEW),
Turin, Italy, pp. 1-6, DOI 10.1109/ICMEW.2015.7169810,
June 2015, <https://ieeexplore.ieee.org/document/7169810>.
[MUTHANA] Muthana, A. and M. Saeed, "Analysis of User Identity
Privacy in LTE and Proposed Solution", International
Journal of Computer Network and Information
Security(IJCNIS), Vol. 9, Issue 1, pp. 54-63,
DOI 10.5815/ijcnis.2017.01.07, January 2017,
<https://www.mecs-press.org/ijcnis/ijcnis-v9-n1/
v9n1-7.html>.
[NDNRTC] Gusev, P., Wang, Z., Burke, J., Zhang, L., Yoneda, T.,
Ohnishi, R., and E. Muramoto, "Real-Time Streaming Data
Delivery over Named Data Networking", IEICE Transactions
on Communications, Vol. E99.B, Issue 5, pp.
974-991, 10.5815/ijcnis.2017.01.07, May 2016,
<https://doi.org/10.1587/transcom.2015AMI0002>.
[NGMN] Robson, J., "Backhaul Provisioning for LTE-Advanced &
Small Cells", Next Generation Mobile Networks, LTE-
Advanced Transport Provisioning, Version 0.0.14, October
2015, <https://www.ngmn.org/wp-content/uploads/
Publications/2015/150929_NGMN_P-
SmallCells_Backhaul_for_LTE-Advanced_and_Small_Cells.pdf>.
[NS3EPC] ns-3, "The EPC Model", July 2022,
<https://www.nsnam.org/docs/models/html/lte-
design.html#epc-model>.
[NS3LTE] ns-3, "The LTE Model", July 2022,
<https://www.nsnam.org/docs/models/html/lte-
design.html#lte-model>.
[OFFLOAD] Rebecchi, F., Dias de Amorim, M., Conan, V., Passarella,
A., Bruno, R., and M. Conti, "Data Offloading Techniques
in Cellular Networks: A Survey", IEEE Communications
Surveys and Tutorials, Vol. 17, Issue 2, pp.580-603,
DOI 10.1109/COMST.2014.2369742, November 2014,
<https://ieeexplore.ieee.org/document/6953022>.
[OLTEANU] Olteanu, A. and P. Xiao, "Fragmentation and AES encryption
overhead in very high-speed wireless LANs", Proceedings of
the 2009 IEEE International Conference on Communications
ICC'09, pp. 575-579, June 2009,
<https://dl.acm.org/doi/10.5555/1817271.1817379>.
[Open5GCore]
Open5GCore, "Open5GCore - 5G Core Network for Research,
Testbeds and Trials", <https://www.open5gcore.org>.
[QoS-ICN] Jangam, A., Ed., Suthar, P., and M. Stolic, "QoS
Treatments in ICN using Disaggregated Name Components",
Work in Progress, Internet-Draft, draft-anilj-icnrg-dnc-
qos-icn-02, 9 March 2020,
<https://datatracker.ietf.org/doc/html/draft-anilj-icnrg-
dnc-qos-icn-02>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006,
<https://www.rfc-editor.org/info/rfc4594>.Okay bestie, the reference list is still going, so let's finish it up π§
[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, DOI 10.17487/RFC6459, January 2012, <https://www.rfc-editor.org/info/rfc6459>.
[RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., Tyson, G., Davies, E., Molinaro, A., and S. Eum, "Information-Centric Networking: Baseline Scenarios", RFC 7476, DOI 10.17487/RFC7476, March 2015, <https://www.rfc-editor.org/info/rfc7476>.
[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, "Information-Centric Networking (ICN) Research Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, <https://www.rfc-editor.org/info/rfc7927>.
[RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., and G. Boggia, "Information-Centric Networking: Evaluation and Security Considerations", RFC 7945, DOI 10.17487/RFC7945, September 2016, <https://www.rfc-editor.org/info/rfc7945>.
[RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019, <https://www.rfc-editor.org/info/rfc8569>.
[RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, July 2019, <https://www.rfc-editor.org/info/rfc8609>.
[RFC9064] Oran, D., "Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols", RFC 9064, DOI 10.17487/RFC9064, June 2021, <https://www.rfc-editor.org/info/rfc9064>.
[RFC9139] GΓΌndoΔan, C., Schmidt, T., WΓ€hlisch, M., Scherb, C., Marxer, C., and C. Tschudin, "Information-Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs)", RFC 9139, DOI 10.17487/RFC9139, November 2021, <https://www.rfc-editor.org/info/rfc9139>.
[SDN5G] Page, J. and J. Dricot, "Software-defined networking for low-latency 5G core network", 2016 International Conference on Military Communications and Information Systems (ICMCIS), pp. 1-7, DOI 10.1109/ICMCIS.2016.7496561, May 2016, <https://ieeexplore.ieee.org/document/7496561>.
[TLVCOMP] Mosko, M., "Header Compression for TLV-based Packets", ICNRG, Buenos Aires, IETF 95, April 2016, <https://datatracker.ietf.org/meeting/interim-2016-icnrg-02/materials/slides-interim-2016-icnrg-2-7>.
[TOURANI] Tourani, R., Misra, S., Mick, T., and G. Panwar, "Security, Privacy, and Access Control in Information-Centric Networking: A Survey", IEEE Communications Surveys and Tutorials, Vol. 20, Issue 1, pp. 566-600, DOI 10.1109/COMST.2017.2749508, September 2017, <https://ieeexplore.ieee.org/document/8027034>.
[TS23.203] 3GPP, "Policy and charging control architecture", 3GPP TS 23.203 17.2.0, December 2021, <https://www.3gpp.org/ftp/Specs/html-info/23203.htm>.
[TS23.401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401 17.5.0, June 2022, <https://www.3gpp.org/ftp/Specs/html-info/23401.htm>.
[TS23.501] 3GPP, "System architecture for the 5G System (5GS)", 3GPP TS 23.501 17.5.0, June 2022, <https://www.3gpp.org/ftp/Specs/html-info/23501.htm>.
[TS23.714] 3GPP, "Study on Control Plane (CP) and User Plane (UP) separation of Evolved Packet Core (EPC) nodes", 3GPP TS 23.714 14.0.0, June 2016, <https://www.3gpp.org/ftp/Specs/html-info/23714.htm>.
[TS29.060] 3GPP, "General Packet Radio Service (GPRS); GPRS Tunneling Protocol (GTP) across the Gn and Gp interface", 3GPP TS 29.060 17.3.0, June 2022, <https://www.3gpp.org/ftp/Specs/html-info/29060.htm>.
[TS29.336] 3GPP, "Home Subscriber Server (HSS) diameter interfaces for interworking with packet data networks and applications", 3GPP TS 29.336 17.13.1, March 2022, <https://www.3gpp.org/ftp/Specs/html-info/29336.htm>.
[TS33.310] 3GPP, "Network Domain Security (NDS); Authentication Framework (AF)", 3GPP TS 33.310 17.3.0, June 2022, <https://www.3gpp.org/ftp/Specs/html-info/33310.htm>.
[TS33.320] 3GPP, "Security of Home Node B (HNB) / Home evolved Node B (HeNB)", 3GPP TS 33.320 17.0.0, March 2022, <https://www.3gpp.org/ftp/Specs/html-info/33320.htm>.
Acknowledgements π«Ά
We thank all contributors, reviewers, and the chairs for their valuable time in providing comments and feedback that helped improve this document. We especially want to mention the following members of the IRTF Information-Centric Networking Research Group (ICNRG), listed in alphabetical order: Kashif Islam, Thomas Jagodits, Luca Muscariello, David R. Oran, Akbar Rahman, Martin J. Reed, Thomas C. Schmidt, and Randy Zhang.
The IRSG review was provided by Colin Perkins. π
Authors' Addresses π
Prakash Suthar Google Inc. Mountain View, California 94043 United States of America Email: psuthar@google.com
Milan Stolic Cisco Systems Inc. Naperville, Illinois 60540 United States of America Email: mistolic@cisco.com
Anil Jangam (editor) Cisco Systems Inc. San Jose, California 95134 United States of America Email: anjangam@cisco.com
Dirk Trossen Huawei Technologies Riesstrasse 25 80992 Munich Germany Email: dirk.trossen@huawei.com
Ravi Ravindran F5 Networks 3545 North First Street San Jose, California 95134 United States of America Email: r.ravindran@f5.com
And that's the whole RFC, bestie! π¦ Every one of these people helped make ICN a real thing, so go give them some love πΈ
π¦ where this page comes from
- ietf: rfc9269 2022-08
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms