ICN Research Group Prakash Suthar
Internet-Draft Milan Stolic
Intended status: Informational Anil Jangam, Ed.
Expires: November 26, 2020 Cisco Systems Inc.
Dirk Trossen
Huawei Technologies
Ravishankar Ravindran
Sterlite Technologies
May 25, 2020
Native Deployment of ICN in LTE, 4G Mobile Networks
draft-irtf-icnrg-icn-lte-4g-07
Abstract
LTE, 4G mobile networks use IP-based transport for control plane to
establish the data session and user plane for actual data delivery.
In existing architecture, IP transport used in the user plane is not
optimized for data transport, which leads to an inefficient data
delivery. IP unicast routing from server to clients is used for
delivery of multimedia content to User Equipment (UE), where each
user gets a separate stream. From a bandwidth and routing
perspective, this approach is inefficient. Multicast and broadcast
technologies have emerged recently for mobile networks, but their
deployments are very limited or at an experimental stage due to
complex architecture and radio spectrum issues. ICN is a rapidly
emerging technology with built-in features for efficient multimedia
data delivery. However much of the work is focused on fixed
networks. The focus of this draft is on native deployment of ICN in
cellular mobile networks by using ICN in a 3GPP protocol stack. ICN
has an inherent capability for multicast, anchorless mobility and
security, and it is optimized for data delivery using local caching
at the edge. The proposed approaches in this draft allow ICN to be
enabled natively over the current LTE stack comprising PDCP/RLC/MAC/
PHY, or in a dual stack mode (along with IP). These approaches can
help optimize the mobile networks by leveraging the inherent benefits
of ICN. This document is a product of the Information-Centric
Networking Research Group (ICNRG).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
Prakash Suthar, et al. Expires November 26, 2020 [Page 1]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 26, 2020.
Copyright Notice
Copyright (c) 2020 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, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. 3GPP Terminology and Concepts . . . . . . . . . . . . . . . . 3
3. LTE, 4G Mobile Network . . . . . . . . . . . . . . . . . . . 7
3.1. Network Overview . . . . . . . . . . . . . . . . . . . . 7
3.2. QoS Challenges . . . . . . . . . . . . . . . . . . . . . 9
3.3. Data Transport Using IP . . . . . . . . . . . . . . . . . 10
3.4. Virtualizing Mobile Networks . . . . . . . . . . . . . . 10
4. Data Transport Using ICN . . . . . . . . . . . . . . . . . . 11
5. ICN Deployment in 4G and LTE Networks . . . . . . . . . . . . 14
5.1. General ICN Deployment Considerations . . . . . . . . . . 14
5.2. ICN Deployment Scenarios . . . . . . . . . . . . . . . . 14
5.3. ICN Deployment in LTE Control Plane . . . . . . . . . . . 18
5.4. ICN Deployment in LTE User Plane . . . . . . . . . . . . 19
5.4.1. Dual stack ICN deployments in UE . . . . . . . . . . 20
5.4.2. Native ICN Deployments in UE . . . . . . . . . . . . 24
5.5. ICN Deployment in eNodeB . . . . . . . . . . . . . . . . 25
5.6. ICN Deployment in Packet Core (SGW, PGW) Gateways . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
Prakash Suthar, et al. Expires November 26, 2020 [Page 2]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
9.1. Normative References . . . . . . . . . . . . . . . . . . 31
9.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction
LTE mobile technology is built as an all-IP network. It uses IP
routing protocols (OSPF, ISIS, BGP, etc.) to establish network routes
to route data traffic to the end user's device. Stickiness of an IP
address to a device is the key to get connected to a mobile network.
The same IP address is maintained through the session until the
device gets detached or moves to another network.
One of the key protocols used in 4G and LTE networks is GPRS
Tunneling protocol (GTP). GTP, DIAMETER and other protocols are
built on top of IP. One of the biggest challenges with IP-based
routing is that it is not optimized for data transport, although it
is the most efficient communication protocol. By native
implementation of Information Centric Networking (ICN) in 3GPP, we
can re-architect a mobile network and optimize its design for
efficient data transport by leveraging ICN's caching feature. ICN
also offers an opportunity to leverage inherent capabilities of
multicast, anchorless mobility management, and authentication. This
draft proposes options for deploying ICN in mobile networks, and how
they affect mobile providers and end users.
This document represents the consensus of the Information-Centric
Networking Research Group (ICNRG). It has been reviewed extensively
by the Research Group (RG) members active in the specific areas of
work covered by the document.
2. 3GPP Terminology and Concepts
1. Access Point Name
The Access Point Name (APN) is a Fully Qualified Domain Name
(FQDN) and resolves to a set of gateways in an operator's
network. APN identifies the packet data network (PDN) with
which a mobile data user wants to communicate. In addition to
identifying a PDN, an APN may also be used to define the type of
service, QoS, and other logical entities inside GGSN, PGW.
2. Control Plane
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. Control plane signaling is required to
authenticate and authorize UE and establish a mobility session
Prakash Suthar, et al. Expires November 26, 2020 [Page 3]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
with mobile gateways (SGW/PGW). Control plane functions also
include system configuration and management.
3. Dual Address PDN/PDP Type
The dual address Packet Data Network/Packet Data Protocol (PDN/
PDP) Type (IPv4v6) is used in 3GPP context, in many cases as a
synonym for dual stack; i.e., a connection type capable of
serving IPv4 and IPv6 simultaneously.
4. eNodeB
The eNodeB is a base station entity that supports the Long-Term
Evolution (LTE) air interface.
5. Evolved Packet Core
The Evolved Packet Core (EPC) is an evolution of the 3GPP GPRS
system characterized by a higher-data-rate, lower-latency,
packet-optimized system. The EPC comprises some sub components
of the EPS core such as Mobility Management Entity (MME),
Serving Gateway (SGW), Packet Data Network Gateway (PDN-GW), and
Home Subscriber Server (HSS).
6. Evolved Packet System
The Evolved Packet System (EPS) is an evolution of the 3GPP GPRS
system characterized by a higher-data-rate, lower-latency,
packet-optimized system that supports multiple Radio Access
Technologies (RATs). The EPS comprises the EPC together with
the Evolved Universal Terrestrial Radio Access (E-UTRA) and the
Evolved Universal Terrestrial Radio Access Network (E-UTRAN).
7. Evolved UTRAN
The E-UTRAN is a communications network sometimes referred to as
4G, and consists of eNodeB (4G base stations). The E-UTRAN
allows connectivity between the User Equipment and the core
network.
8. GPRS Tunneling Protocol
The GPRS Tunneling Protocol (GTP) [TS29.060] [TS29.274]
[TS29.281] is a tunneling protocol defined by 3GPP. It is a
network-based mobility protocol and is like Proxy Mobile IPv6
(PMIPv6). However, GTP also provides functionality beyond
mobility, such as in-band signaling related to QoS and charging,
among others.
Prakash Suthar, et al. Expires November 26, 2020 [Page 4]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
9. Gateway GPRS Support Node
The Gateway GPRS Support Node (GGSN) is a gateway function in
the GPRS and 3G network that provides connectivity to the
Internet or other PDNs. The host attaches to a GGSN identified
by an APN assigned to it by an operator. The GGSN also serves
as the topological anchor for addresses/prefixes assigned to the
User Equipment.
10. General Packet Radio Service
The General Packet Radio Service (GPRS) is a packet-oriented
mobile data service available to users of the 2G and 3G cellular
communication systems--the GSM--specified by 3GPP.
11. Home Subscriber Server
The Home Subscriber Server (HSS) is a database for a given
subscriber and was introduced in 3GPP Release-5. It is the
entity containing subscription-related information to support
the network entities that handle calls/sessions.
12. Mobility Management Entity
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.
13. 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). Each (telecommunications) operator
providing mobile services has its own PLMN.
14. 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 needed if dynamic
policy and charging control by means of PCC rules based on user
and services are desired.
Prakash Suthar, et al. Expires November 26, 2020 [Page 5]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
15. Packet Data Network
The Packet Data Network (PDN) is a packet-based network that
either belongs to the operator or is an external network such as
the Internet or a corporate intranet. The user eventually
accesses services in one or more PDNs. The operator's packet
core networks are separated from packet data networks either by
GGSNs or PDN Gateways (PGWs).
16. Serving Gateway
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 UE 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.
17. Packet Data Network Gateway
The Packet Data Network Gateway (PGW) is a gateway function in
the Evolved Packet System (EPS), which provides connectivity to
the Internet or other PDNs. The host attaches to a PGW
identified by an APN assigned to it by an operator. The PGW
also serves as the topological anchor for addresses/prefixes
assigned to the User Equipment.
18. Packet Data Protocol Context
A Packet Data Protocol (PDP) context is the equivalent of a
virtual connection between the User Equipment (UE) and a PDN
using a specific gateway.
19. Packet Data Protocol Type
A Packet Data Protocol Type (PDP Type) identifies the used/
allowed protocols within the PDP context. Examples are IPv4,
IPv6, and IPv4v6 (dual-stack).
20. Serving GPRS Support Node
The Serving GPRS Support Node (SGSN) is a network element
located between the radio access network (RAN) and the gateway
(GGSN). A per-UE point-to-point (p2p) tunnel between the GGSN
and SGSN transports the packets between the UE and the gateway.
21. Terminal Equipment
Prakash Suthar, et al. Expires November 26, 2020 [Page 6]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
The Terminal Equipment (TE) is any device/host connected to the
Mobile Terminal (MT) offering services to the user. A TE may
communicate to an MT, for example, over the Point-to-Point
Protocol (PPP).
22. UE, MS, MN, and Mobile
The terms User Equipment (UE), Mobile Station (MS), Mobile Node
(MN), and mobile refer to the devices that are hosts with the
ability to obtain Internet connectivity via a 3GPP network. An
MS comprises the Terminal Equipment (TE) and a Mobile Terminal
(MT). The terms UE, MS, MN, and mobile are used interchangeably
within this document.
23. User Plane
The user plane refers to data traffic and the required bearers
for the data traffic. In practice, IP is the only data traffic
protocol used in the user plane.
3. LTE, 4G Mobile Network
3.1. Network Overview
With the introduction of LTE, mobile networks moved to all-IP
transport for all elements such as eNodeB, MME, SGW/PGW, HSS, PCRF,
routing and switching, etc. Although LTE network is data-centric, it
has support for legacy Circuit Switch features such as voice and SMS
through transitional CS fallback and flexible IMS deployment
[GRAYSON]. 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).
The GTP tunnel is used to carry user traffic between gateways and
mobile devices. This forces data to be distributed only by using
unicast mechanism. It is also important to understand the overhead
of a GTP and IPSec protocols because it has impact on the carried
user data traffic. All mobile backhaul traffic is encapsulated using
GTP tunnel, which has overhead of 8 bytes on top of IP and UDP
[NGMN]. Additionally, if IPSec is used for security (which is often
required if the Service Provider is using a shared backhaul), it adds
overhead based on the IPSec tunneling model (tunnel or transport),
and the encryption and authentication header algorithm used. If we
factor Advanced Encryption Standard (AES) encryption with the packet
size, the overhead can be significant [OLTEANU], particularly for the
smaller payloads.
Prakash Suthar, et al. Expires November 26, 2020 [Page 7]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
When any UE is powered up, it attaches to a mobile network based on
its configuration and subscription. After a successful attach
procedure, UE registers with the mobile core network, and an IPv4
and/or IPv6 address is assigned. A default bearer is created for
each UE and it is assigned to default Access Point Name (APN).
+-------+ Diameter +-------+
| HSS |------------| SPR |
+-------+ +-------+
| |
+------+ +------+ S4 | +-------+
| 3G |---| SGSN |----------------|------+ +------| PCRF |
^ |NodeB | | |---------+ +---+ | | +-------+
+-+ | +------+ +------+ S3 | | S6a | |Gxc |
| | | +-------+ | | |Gx
+-+ | +------------------| MME |------+ | | |
UE 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 | +-----+
+---------+ +---------+
| |
+-+ +-+
| | | |
+-+ +-+
UE UE
Figure 1: LTE, 4G Mobile Network Overview
The data delivered to mobile devices is unicast inside the GTP
tunnel. If we consider the combined impact of GTP, IPSec and unicast
traffic, the data delivery is not efficient. IETF has developed
various header compression algorithms to reduce overhead associated
with IP packets. Some techniques are robust header compression
(ROHC) and enhanced compression of the real-time transport protocol
(ECRTP) so that impact of overhead created by GTP, IPsec, etc., is
reduced to some extent [BROWER]. For commercial mobile networks,
3GPP has adopted different mechanisms for header compression to
Prakash Suthar, et al. Expires November 26, 2020 [Page 8]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
achieve efficiency in data delivery [TS25.323], and can be adapted to
ICN, as well [ICNLOWPAN] [TLVCOMP].
3.2. QoS Challenges
During the attach procedure, a default bearer is created for each UE
and it is assigned to the default Access Point Name (APN). The QoS
values that uplink and downlink bandwidth assigned during the initial
attach are minimal. Additional dedicated bearer(s) with enhanced QoS
parameters are established depending on specific application needs.
While all traffic within a certain bearer gets the same treatment,
QoS parameters supporting these requirements can be very granular in
different bearers. These values vary for the control, management and
user traffic, and can be very different depending on application key
parameters such as latency, jitter (important for voice and other
real-time applications), packet loss, and queuing mechanism (strict
priority, low-latency, fair, and so on).
Implementation of QoS for mobile networks is done at two stages: at
content prioritization/marking and transport marking, and congestion
management. From the transport perspective, QoS is defined at layer
2 as class of service (CoS) and at layer 3 either as DiffServ code
point (DSCP) or type of service (ToS). The mapping of DSCP to CoS
takes place at layer 2/3 switching and routing elements. 3GPP has a
specified QoS Class Identifier (QCI), which represents different
types of content and equivalent mapping to DSCP at transport layer
[TS23.401]. However, this requires manual configuration at different
elements and, if there are misconfigurations at any place in the
path, it will not work properly.
In summary, QoS configuration for mobile networks for user plane (for
user traffic) and transport in an IP-based mobile network is complex
requires synchronization of parameters among different platforms.
Normally, QoS in IP is implemented using DiffServ, which uses hop-by-
hop QoS configuration at each router. Any inconsistency in IP QoS
configuration at routers in the forwarding path can result in a poor
subscriber experience (e.g., packet classified as high-priority can
go to a lower priority queue). By deploying ICN, we intend to
enhance the subscriber experience using policy-based configuration,
which can be associated with the named contents [ICNQoS] at the ICN
forwarder. Further investigation is needed to understand how QoS in
ICN can be implemented to meet the IP QoS requirements [RFC4594].
Research papers published so far explore the possibility of
classifications based on name prefixes (thus addressing the problem
of IP QoS not being information aware), or on popularity or placement
(looking at a distance of a content from a requester). However,
Prakash Suthar, et al. Expires November 26, 2020 [Page 9]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
focus of these research efforts is on faster routing of Interest
requests towards the content rather than content delivery.
3.3. Data Transport Using IP
The data delivered to mobile devices is unicast inside GTP tunnel
from an eNodeB to a PDN gateway (PGW), as described in 3GPP
specifications [TS23.401]. While the technology exists to address
the issue of possible multicast delivery, there are many difficulties
related to multicast protocol implementation on the RAN side of the
network. Transport networks in the backhaul and core addressed the
multicast delivery long ago and have implemented it in most cases in
their multi-purpose integrated transport. But the RAN part of the
network is still lagging behind due to complexities related to client
mobility, handovers, and the fact that the potential gain to Service
Providers may not justify the investment. With that said, the data
delivery in the mobility remains greatly unicast. Techniques to
handle multicast (such as LTE-B or eMBMS) have been designed to
handle pre-planned content delivery, such as live content, which
contrasts user behavior today, largely based on content (or video) on
demand model.
To ease the burden on the bandwidth of the SGi interface, caching is
introduced in a similar manner as with many Enterprises. In the
mobile networks, whenever possible, cached data is delivered.
Caching servers are placed at a centralized location, typically in
the Service Provider's Data Center, or in some cases lightly
distributed in Packet Core locations with the PGW nodes close to the
Internet and IP services access (SGi interface). This is a very
inefficient concept because traffic must traverse the entire backhaul
path for the data to be delivered to the end user. Other issues,
such as out-of-order delivery, contribute to this complexity and
inefficiency, which needs to be addressed at the application level.
Data delivered to mobile devices is unicast inside a GTP tunnel. If
we consider the combined impact of GTP, IPSec, and unicast traffic,
the end-to-end data delivery is not efficient. By deploying ICN, we
intend to either terminate the GTP tunnel at the mobility anchoring
point by leveraging control and user-plane separation, or replace it
with native ICN protocols.
3.4. Virtualizing Mobile Networks
The Mobile packet core deployed in a major Service Provider network
is either based on dedicated hardware or, in some cases, large
capacity x86 platforms. With adoption of Mobile Virtual Network
Operators (MVNO), public safety network, and enterprise mobility
network, we need elastic mobile core architecture. By deploying
Prakash Suthar, et al. Expires November 26, 2020 [Page 10]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
mobile packet core on a commercially off-the-shelf (COTS) platform
using virtualized infrastructure (NFVI) framework and end-to-end
orchestration, we can simplify new deployments and provide optimized
TCO.
While virtualization is growing, and many mobile providers use hybrid
architecture consisting of dedicated and virtualized infrastructures,
the control and data delivery planes are still the same. There is
also work under way to separate the control plane and user plane so
the network can scale better. Virtualized mobile networks and
network slicing with control and user plane separation provide
mechanism to evolve GTP-based architecture to open-flow SDN-based
signaling for LTE and proposed 5G core. Some early architecture work
for 5G mobile technologies provides a mechanism for control and user
plane separation and simplifies mobility call flow by introduction of
open-flow-based signaling [ICN5G]. This has been considered by 3GPP
[EPCCUPS] and is also described in [SDN5G].
4. Data Transport Using ICN
For mobile devices, the edge connectivity to the network is between
radio and a router or mobile edge computing (MEC) [MECSPEC] element.
MEC 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.
Prakash Suthar, et al. Expires November 26, 2020 [Page 11]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
+----------+
| Content +----------------------------------------+
| Publisher| |
+---+---+--+ |
| | +--+ +--+ +--+ |
| +--->|R1|------------>|R2|---------->|R4| |
| +--+ +--+ +--+ |
| | Cached |
| v content |
| +--+ at R3 |
| +========|R3|---+ |
| # +--+ | |
| # | |
| v v |
| +-+ +-+ |
+---------------| |-------------| |-------------+
+-+ +-+
Consumer-1 Consumer-2
UE UE
===> Content flow from cache
---> Content flow from publisher
Figure 2: ICN Architecture
MEC transforms radio into an intelligent service edge capable of
delivering services directly from the edge of the network, while
providing the best possible performance to the client. MEC can be an
ideal candidate for ICN forwarder in addition to its usual function
of managing mobile termination. In addition to MEC, other transport
elements, such as routers, can work as ICN forwarders.
Data transport using ICN is different compared to IP-based transport.
It evolves the Internet infrastructure by introducing uniquely named
data as a core Internet principle. Communication in ICN takes place
between the content provider (producer) and the end user (consumer),
as described in Figure 2.
Every node in a physical path between a client and a content provider
is called the ICN forwarder or router. It can route the request
intelligently and to cache the content so it can be delivered locally
for subsequent request from any other client. For mobile network,
transport between a client and a content provider consists of radio
network + mobile backhaul and IP core transport + Mobile Gateways +
Internet + content data network (CDN).
Prakash Suthar, et al. Expires November 26, 2020 [Page 12]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
To understand the suitability of ICN for mobile networks, we will
discuss the ICN framework describing protocols architecture and
different types of messages, and then consider how we can use this in
a mobile network for delivering content more efficiently. ICN uses
two types of packets called "interest packet" and "data packet" as
described in Figure 3.
+------------------------------------+
Interest | +------+ +------+ +------+ | +-----+
+-+ ---->| CS |---->| PIT |---->| FIB |--------->| CDN |
| | | +------+ +------+ +------+ | +-----+
+-+ | | Add | Drop | | Forward
UE <--------+ Intf v Nack v |
Data | |
+------------------------------------+
+------------------------------------+
+-+ | Forward +------+ | +-----+
| | <-------------------------------------| PIT |<---------| CDN |
+-+ | | Cache +--+---+ | Data +-----+
UE | +--v---+ | |
| | CS | v |
| +------+ Discard |
+------------------------------------+
Figure 3: ICN Interest, Data Packet and Forwarder
In an LTE network, when a mobile device wants to get certain content,
it will send an Interest message to the closest eNodeB. Interest
packet follows the TLV format [RFC8609] and contains mandatory fields
such as name of the content and content matching restrictions
(KeyIdRestr and ContentObjectHashRestr) forming the tuple [RFC8569].
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.
An ICN router will receive an Interest packet and perform lookup if a
request for such content has come earlier from another client. If
yes, it is served from the local cache; otherwise, the request is
forwarded to the next-hop ICN router. Each ICN router maintains
three data structures: Pending Interest Table (PIT), Forwarding
Information Base (FIB), and Content Store (CS). The Interest packet
travels hop-by-hop towards the content provider. Once the Interest
reaches the content provider, it will return a Data packet containing
information such as content name, signature, and data.
Prakash Suthar, et al. Expires November 26, 2020 [Page 13]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
Data packet travels in reverse direction following the same path
taken by the Interest packet, which maintains routing symmetry.
Details about algorithms used in PIT, FIB, CS, and security trust
models are described in various resources [CCN]; here, we have
explained the concept and its applicability to the LTE network.
5. ICN Deployment in 4G and LTE Networks
5.1. General ICN Deployment Considerations
In LTE/4G mobile networks, both user and control plane traffic have
to be transported from the edge to the mobile packet core via IP
transport. The evolution of existing mobile packet core using
Control and User Plane Separation (CUPS) [TS23.714] enables flexible
network deployment and operation, by distributed deployment and the
independent scaling between control plane and user plane functions -
while not affecting the functionality of existing nodes subject to
this split.
In the CUPS architecture, there is an opportunity to shorten the path
for user plane traffic by deploying offload nodes closer to the edge
[OFFLOAD]. With this major architecture change, a User Plane
Function (UPF) node is placed close to the edge so traffic no longer
needs to traverse the entire backhaul path to reach the EPC. In many
cases, where feasible, UPF can be collocated with the eNodeB, which
is also a business decision based on user demand. Placing a
Publisher close to the offload site, or at the offload site, provides
for a significant improvement in user experience, especially with
latency-sensitive applications. This optimization allows for the
introduction of ICN and amplifies its advantages. This section
analyzes the potential impact of ICN on control and user plane
traffic for centralized and disaggregate CUPS-based mobile network
architecture.
5.2. ICN Deployment Scenarios
Deployment of ICN provides an opportunity to further optimize the
existing data transport in LTE/4G mobile networks. The various
deployment options that ICN and IP provide are somewhat analogous to
the deployment scenarios when IPv6 was introduced to interoperate
with IPv4 except, with ICN, the whole IP stack is being replaced. We
have reviewed [RFC6459] and analyzed the impact of ICN on control
plane signaling and user plane data delivery. In general, ICN can be
deployed by natively replacing IP transport (IPv4 and IPv6) or as an
overlay protocol. Figure 4 describes a modified protocol stack to
support ICN deployment scenarios.
Prakash Suthar, et al. Expires November 26, 2020 [Page 14]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
+----------------+ +-----------------+
| 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 and Deployment Scenarios
As shown in Figure 4, for applications running either in UE or in
content provider system to use the new transport option, we propose a
new transport convergence layer (TCL). This transport convergence
layer helps determine the type of transport (such as ICN or IP), as
well as the type of radio interface (LTE or WiFi or both) used to
send and receive traffic based on preference (e.g., content location,
content type, content publisher, congestion, cost, QoS). It helps
configure and determine the type of connection, as well as the
overlay mode (ICNoIP or IPoICN) between application and the protocol
stack (IP or ICN), to be used.
Combined with the existing IP function, the ICN function provides
support for either native ICN and/or the dual stack (ICN/IP)
transport functionality. See Section 5.4.1 for elaborate
descriptions of these functional layers.
The TCL can use several mechanisms for transport selection . It can
use a per-application configuration through a management interface,
possibly even a user-facing setting realized through a user
interface, like those used today that select cellular over WiFi being
used for selected applications. In another option, it might use a
software API, which an adapted IP application could use to specify
(such as an ICN transport) for obtaining its benefits.
Another potential application of TCL is in implementation of network
slicing, where it can have a slice management capability locally or
it can interface to an external slice manager through an API [GALIS].
Prakash Suthar, et al. Expires November 26, 2020 [Page 15]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
This solution can enable network slicing for IP and ICN transport
selection from the UE itself. The TCL could apply slice settings to
direct certain traffic (or applications) over one slice and others
over another slice, determined by some form of 'slicing policy'.
Slicing policy can be obtained externally from the slice manager or
configured locally on UE.
From the perspective of applications either on UE or a content
provider, the following options are possible for ICN deployment
natively and/or with IP.
1. IP over IP
In this scenario, UE uses applications tightly integrated with
the existing IP transport infrastructure. In this option, the
TCL has no additional function because packets are forwarded
directly using an IP protocol stack, which sends packets over the
IP transport.
2. ICN over ICN
Similar to case 1, ICN applications integrate tightly with the
ICN transport infrastructure. The TCL has no additional
responsibility because packets are forwarded directly using ICN
protocol stack, which sends packets over the ICN transport.
3. ICN over IP (ICNoIP)
In this scenario, the underlying IP transport infrastructure is
not impacted (that is, ICN is implemented as an IP overlay
between user equipment (UE) and content provider). IP routing is
used from Radio Access Network (eNodeB) to mobile backhaul, IP
core, and Mobile Gateway (SGW/PGW). UE attaches to Mobile
Gateway (SGW/PGW) using IP address. Also, the data transport
between Mobile Gateway (SGW/PGW) and content publisher uses IP.
Content provider can serve content either using IP or ICN, based
on the UE request.
An approach to implement ICN in mobile backhaul networks is
described in [MBICN]. It implements a GTP-U extension header
option to encapsulate ICN payload in 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 GTP-U tunnel 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 SGW). This could be
useful when an ICN data packet is stored in the ICN node (such as
repos, caches) in the tunnel path; it can reply right away
Prakash Suthar, et al. Expires November 26, 2020 [Page 16]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
without going all the way through the mobile core. While GTP-U
extension header is used to carry UE specific ICN payload, they
are not visible to the transport, including SGW. On the other
hand, the PGW can use the UE-specific ICN header extension and
ICN payload to set up an uplink transport towards 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.
4. IP over ICN (IPoICN)
H2020 project [H2020] provides an architectural framework for
deployment of IP as an overlay over ICN protocol [IPoICN].
Implementing IP services over ICN provides an opportunity
leveraging benefit of ICN in the transport infrastructure and
there is no impact on end devices (UE and access network) 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 native IP deployment
for mobile network. After reviewing [IPoICN], we understand and
interpret that ICN is implemented in the transport natively;
however, IP is implemented in UE, eNodeB, and Mobile gateway
(SGW/PGW), which is also called as a network attach point (NAP).
For this, said NAP receives an incoming IP or HTTP packet (the
latter through TCP connection termination) and publishes the
packet under a suitable ICN name (i.e., the hash over the
destination IP address for an IP packet or the hash over the FQDN
of the HTTP request for an HTTP packet) to the ICN network. In
the HTTP case, the NAP maintains a pending request mapping table
to map returning responses to the terminated TCP connection.
5. Hybrid ICN (hICN)
An alternative approach to implement ICN over IP is provided in
Hybrid ICN [HICN]. It describes a novel approach to integrate
ICN into IPv6 without creating overlays with a new packet format
as an encapsulation. hICN addresses the content by encoding a
location-independent name in an IPv6 address. It uses two name
components--name prefix and name suffix--that identify the source
of data and the data segment within the scope of the name prefix,
respectively.
At 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
Prakash Suthar, et al. Expires November 26, 2020 [Page 17]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
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 UE, in the eNodeB, in the mobile
backhaul, or in the mobile core. Finally, as hICN itself uses
IPv6, it cannot be considered as an alternative transport layer.
5.3. ICN Deployment in LTE Control Plane
In this section, we analyze signaling messages that are required for
different procedures, such as attach, handover, tracking area update,
and so on. The goal of this analysis is to see if there are any
benefits to replacing IP-based protocols with ICN for LTE signaling
in the current architecture. It is important to understand the
concept of point of attachment (POA). When UE connects to a network,
it has the following POAs:
1. eNodeB managing location or physical POA
2. Authentication and Authorization (MME, HSS) managing identity or
authentication POA
3. Mobile Gateways (SGW, PGW) managing logical or session management
POA
In the current architecture, IP transport is used for all messages
associated with the control plane for mobility and session
management. IP is embedded very deeply into these messages and TLV,
carrying additional attributes such as a layer 3 transport. Physical
POA in eNodeB handles both mobility and session management for any UE
attached to 4G, LTE network. The number of mobility management
messages between different nodes in an LTE network per signaling
procedure are shown in Table 1.
Normally, two types of UE devices attach to the LTE 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 UE authentication or
mobility management messaging for user data transport using ICN. A
separate study would be required to analyze the impact of ICN on
mobility management messages structures and flows. We are merely
analyzing the viability of implementing ICN as a transport for
control plane messages.
It is important to note that, if MME and HSS do not support ICN
transport, they still need to support UE capable of dual stack or
native ICN. When UE initiates an attach request using the identity
as ICN, MME must be able to parse that message and create a session.
Prakash Suthar, et al. Expires November 26, 2020 [Page 18]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
MME forwards UE authentication to HSS, so HSS must be able to
authenticate an ICN-capable UE and authorize create session
[TS23.401].
+---------------------------+-----+-----+-----+-----+------+
| LTE 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 LTE Gateways
Anchorless mobility [ALM] provides a fully decentralized, control-
plane agnostic solution to handle producer mobility in ICN. Mobility
management at layer-3 level makes it access agnostic and transparent
to the end device or the application. The solution discusses
handling mobility without having to depend on core network functions
(e.g. MME); however, a location update to the core network may still
be required to support legal compliance requirements such as lawful
intercept and emergency services. These aspects are open for further
study.
One of the advantages of ICN is in the caching and reusing of the
content, which does not apply to the transactional signaling
exchange. After analyzing LTE signaling call flows [TS23.401] and
messages inter-dependencies (see Table 1), our recommendation is that
it is not beneficial to deploy ICN for control plane and mobility
management functions. Among the features of ICN design, Interest
aggregation and content caching are not applicable to control plane
signaling messages. Control plane messages are originated and
consumed by the applications and they cannot be shared.
5.4. ICN Deployment in LTE User Plane
We will consider Figure 1 to discuss different mechanisms to deploy
ICN in mobile networks. In Section 5.2, we discussed generic
deployment scenarios of ICN. In this section, we discuss the
specific use cases of native ICN deployment in LTE user plane. We
consider the following options:
Prakash Suthar, et al. Expires November 26, 2020 [Page 19]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
1. Dual stack ICN deployment in UE
2. Native ICN deployments in UE
3. ICN deployment in eNodeB
4. ICN deployment in mobile gateways (SGW/PGW)
5.4.1. Dual stack ICN deployments in UE
The control and user plane communications in LTE, 4G mobile networks
are specified in 3GPP documents [TS23.203] and [TS23.401]. It is
important to understand that UE can be either consumer (receiving
content) or publisher (pushing content for other clients). The
protocol stack inside mobile device (UE) is complex because it has to
support multiple radio connectivity access to eNodeB(s).
Figure 5 provides a high-level description of a protocol stack, where
IP is defined at two layers: (1) user plane communication and (2) UDP
encapsulation. User plane communication takes place between Packet
Data Convergence Protocol (PDCP) and Application layer, whereas UDP
encapsulation is at GTP protocol stack.
The protocol interactions and impact of supporting tunneling of ICN
packet into IP or to support ICN natively are described in Figure 5
and Figure 6, respectively.
Prakash Suthar, et al. Expires November 26, 2020 [Page 20]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
+--------+ +--------+
| 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 |
+--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+
UE | BS(eNodeB) | SGW | PGW |
Uu S1U S5/S8 SGi
Figure 5: Dual Stack ICN Deployment in UE
The protocols and software stack used inside LTE capable UE support
both 3G and LTE software interworking and handover. Latest 3GPP
Rel.13 onward specification describes the use of IP and non-IP
protocols to establish logical/session connectivity. We intend to
leverage the non-IP protocol-based mechanism to deploy ICN protocol
stack in UE, as well as in eNodeB and mobile gateways (SGW, PGW).
1. Existing application layer can be modified to provide options for
a new ICN-based application and existing IP-based applications.
UE can continue to support existing IP-based applications or host
new applications developed to support native ICN as transport,
ICNoIP, or IPoICN-based transport. Application layer has the
option of selecting either ICN or IP transport, as well as radio
interface, to send and receive data traffic.
Our proposal is to provide an Application Programming Interface
(API) to the application developers so they can choose either ICN
or IP transport for exchanging the traffic with the network. As
mentioned in Section 5.2, the transport convergence layer (TCL)
function handles the interaction of applications with multiple
transport options.
Prakash Suthar, et al. Expires November 26, 2020 [Page 21]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
2. The transport convergence layer helps determine the type of
transport (such as ICN, hICN, or IP) and type of radio interface
(LTE or WiFi, or both) used to send and receive traffic.
Application layer can make the decision to select a specific
transport based on preference, such as content location, content
type, content publisher, congestion, cost, QoS, and so on. There
can be an Application Programming Interface (API) to exchange
parameters required for transport selection. Southbound
interactions of Transport Convergence Layer (TCL) will be either
to IP or 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 maintains a pending request mapping table to
map returning responses to the originating HTTP request. The
common API will provide a common 'connection' abstraction for
this HTTP mode of operation, returning the response over said
connection abstraction, akin to the TCP socket interface, while
implementing a reliable transport connection semantic over the
ICN from the UE to the receiving UE or the PGW. If the HTTP
protocol stack remains unchanged, therefore utilizing the TCP
protocol for transfer, the TCL operates in local TCP termination
mode, retrieving the HTTP packet through said local termination.
Prakash Suthar, et al. Expires November 26, 2020 [Page 22]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
+----------------+ +-----------------+
| ICN App (new) | |IP App (existing)|
+---------+------+ +-------+---------+
| |
+---------+----------------+---------+
| Transport Convergence Layer (new) |
+------+---------------------+-------+
| |
+------+------+ +------+-------+
|ICN function | | IP function |
| (New) | | (Existing) |
+------+------+ +------+-------+
| |
+------+---------------------+-------+
| PDCP (updated to support ICN) |
+-----------------+------------------+
|
+-----------------+------------------+
| RLC (Existing) |
+-----------------+------------------+
|
+-----------------+------------------+
| MAC Layer (Existing) |
+-----------------+------------------+
|
+-----------------+------------------+
| Physical L1 (Existing) |
+------------------------------------+
Figure 6: Dual Stack ICN Protocol Interactions
3. ICN function (forwarder) is introduced in parallel to the
existing IP layer. ICN forwarder contains functional
capabilities to forward ICN packets, such as Interest packet to
eNodeB or response "data packet" from eNodeB to the application.
4. For the dual-stack scenario, when UE is not supporting ICN as
transport, we use IP underlay to transport ICN packets. ICN
function will use IP interface to send Interest and Data packets
for fetching or sending data using ICN protocol function. This
interface will use ICN overlay over IP using any overlay
tunneling mechanism.
5. To support ICN at network layer in UE, PDCP layer has to be aware
of ICN capabilities and parameters. PDCP is located in the Radio
Protocol Stack in the LTE Air interface, between IP (Network
Prakash Suthar, et al. Expires November 26, 2020 [Page 23]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
layer) and Radio Link Control Layer (RLC). PDCP performs the
following functions [TS36.323]:
1. Data transport by listening to upper layer, formatting and
pushing down to Radio Link Layer (RLC)
2. Header compression and decompression using Robust Header
Compression (ROHC)
3. Security protections such as ciphering, deciphering, and
integrity protection
4. Radio layer messages associated with sequencing, packet drop
detection and re-transmission, and so on.
6. No changes are required for lower layer such as RLC, MAC, and
Physical (L1) because they are not IP aware.
One key point to understand in this scenario is that ICN is deployed
as an overlay on top of IP.
5.4.2. Native ICN Deployments in UE
We propose to implement ICN natively in UE by modifying the PDCP
layer in 3GPP protocols. Figure 7 provides a high-level protocol
stack description where ICN is used at the following different
layers:
1. User plane communication
2. Transport layer
User plane communication takes place between PDCP and application
layer, whereas ICN transport is a substitute of GTP protocol.
Removal of GTP protocol stack is a significant change in mobile
architecture because GTP is used not just for routing but for
mobility management functions, such as billing, mediation, and policy
enforcement.
If we implement ICN natively in UE, communication between UE and
eNodeB will change. Also, this will avoid tunneling the user plane
traffic from eNodeB to the mobile packet core (SGW, PGW) using GTP
tunnel.
For native ICN deployment, an application will be configured to use
ICN forwarder so there is no need for Transport Convergence. Also,
to support ICN at the network layer in UE, we need to modify the
Prakash Suthar, et al. Expires November 26, 2020 [Page 24]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
existing PDCP layer. PDCP layer must be aware of ICN capabilities
and parameters.
Native implementation will also provide opportunities to develop new
use cases leveraging ICN capabilities, such as seamless mobility, UE
to UE content delivery using 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 |
+--------+ | +----+-----+ | +----------+ | +----------+ | +--------+
UE | BS(eNodeB) | SGW | PGW |
Uu S1u S5/S8 SGi
Figure 7: Native ICN Deployment in UE
5.5. ICN Deployment in eNodeB
eNodeB is a physical point of attachment for UE, where radio
protocols are converted into IP transport protocol for dual stack/
overlay and native ICN, respectively (see Figure 6 and Figure 7).
When UE performs attach procedures, it is assigned an identity either
as IP or dual stack (IP and ICN), or ICN. UE can initiate data
traffic using any of the following options:
1. Native IP (IPv4 or IPv6)
2. Native ICN
3. Dual stack IP (IPv4/IPv6) or ICN
Prakash Suthar, et al. Expires November 26, 2020 [Page 25]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
UE encapsulates user data transport request into PDCP layer and sends
the information on air interface to eNodeB. eNodeB receives the
information and, using PDCP [TS36.323], de-encapsulates air-interface
messages and converts them to forward to core mobile gateways (SGW,
PGW). As shown in Figure 8, to support ICN natively in eNodeB, it is
proposed to provide transport convergence layer (TCL) capabilities in
eNodeB (similar to as provided in UE), which provides the following
functions:
1. It decides the forwarding strategy for a user data request coming
from UE. The strategy can decide based on preference indicated
by the application, such as congestion, cost, QoS, and so on.
2. eNodeB to provide open Application Programming Interface (API) to
external management systems, to provide capability to eNodeB to
program the forwarding strategies.
+---------------+ |
| UE request | | ICN +---------+
+---> | content using |--+--- transport -->| |
| |ICN protocol | | | |
| +---------------+ | | |
| | | |
| +---------------+ | | |
+-+ | | UE request | | IP |To mobile|
| |---+---> | content using |--+--- transport -->| GW |
+-+ | | IP protocol | | |(SGW,PGW)|
UE | +---------------+ | | |
| | | |
| +---------------+ | | |
| | UE request | | Dual stack | |
+---> | content using |--+--- IP+ICN -->| |
|IP/ICN protocol| | transport +---------+
+---------------+ |
eNodeB S1u
Figure 8: Native ICN Deployment in eNodeB
3. eNodeB can be upgraded to support three different types of
transport: IP, ICN, and dual stack IP+ICN towards mobile
gateways, as depicted in Figure 8. It is also proposed to deploy
IP and/or ICN forwarding capabilities into eNodeB, for efficient
transfer of data between eNodeB and mobile gateways. Following
are choices for forwarding a data request towards mobile
gateways:
Prakash Suthar, et al. Expires November 26, 2020 [Page 26]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
1. Assuming eNodeB is IP enabled and UE requests IP transfer,
eNodeB forwards data over IP.
2. Assuming eNodeB is ICN enabled and UE requests ICN transfer,
eNodeB forwards data over ICN.
3. Assuming eNodeB is IP enabled and UE requests ICN, eNodeB
overlays ICN on IP and forwards user plane traffic over IP.
4. Assuming eNodeB is ICN enabled and UE requests IP, eNodeB
overlays IP on ICN and forwards user plane traffic over ICN
[IPoICN].
5.6. ICN Deployment in Packet Core (SGW, PGW) Gateways
Mobile gateways---also known as Evolved Packet Core (EPC)--include
SGW, PGW, which perform session management for UE from the initial
attach to disconnection. When UE is powered on, it performs NAS
signaling and attaches to PGW after successful authentication. PGW
is an anchoring point for UE and responsible for service creations,
authorization, maintenance, and so on. The Entire functionality is
managed using IP address(es) for UE.
To implement ICN in EPC, the following functions are proposed:
1. Insert ICN attributes in session management layer as additional
functionality with IP stack. Session management layer is used
for performing attach procedures and assigning logical identity
to user. After successful authentication by HSS, MME sends a
create session request (CSR) to SGW and SGW to PGW.
2. When MME sends Create Session Request message (Step 12 in
[TS23.401]) to SGW or PGW, it includes a Protocol Configuration
Option Information Element (PCO IE) containing UE capabilities.
We can use PCO IE to carry ICN-related capabilities information
from UE to PGW. This information is received from UE during the
initial attach request in MME. Details of available TLV, which
can be used for ICN, are given in subsequent sections. UE can
support either native IP, ICN+IP, or native ICN. IP is referred
to as both IPv4 and IPv6 protocols.
3. For ICN+IP-capable UE, PGW assigns the UE both an IP address and
ICN identity. UE selects either of the identities during the
initial attach procedures and registers with the network for
session management. For ICN-capable UE, it will provide only ICN
attachment. For native IP-capable UE, there is no change.
Prakash Suthar, et al. Expires November 26, 2020 [Page 27]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
4. To support ICN-capable attach procedures and use ICN for user
plane traffic, PGW needs to have full ICN protocol stack
functionalities. Typical ICN capabilities include functions such
as content store (CS), Pending Interest Table (PIT), Forwarding
Information Base (FIB) capabilities, and so on. If UE requests
ICN in PCO IE, then PGW registers UE with ICN names. For ICN
forwarding, PGW caches content locally using CS functionality.
5. PCO IE described in [TS24.008] (see Figure 10.5.136 on page 598)
and [TS24.008] (see Table 10.5.154 on page 599) provide details
for different fields.
1. Octet 3 (configuration protocols define PDN types), which
contains details about IPv4, IPv6, both or ICN.
2. Any combination of Octet 4 to Z can be used to provide
additional information related to ICN capability. It is most
important that PCO IE parameters are matched between UE and
mobile gateways (SGW, PGW) so they can be interpreted
properly and the UE can attach successfully.
6. Deployment of ICN functionalities in SGW and PGW should be
matched with UE and eNodeB because they will exchange ICN
protocols and parameters.
7. Mobile gateways SGW, PGW will also need ICN forwarding and
caching capability. This is especially important if CUPS is
implemented. User Plane Function (UPF), comprising the SGW and
PGW user plane, will be located at the edge of the network and
close to the end user. ICN-enabled gateway means that this UPF
would serve as a forwarder and should be capable of caching, as
is the case with any other ICN-enabled node.
8. The transport between PGW and CDN provider can be either IP or
ICN. When UE is attached to PGW with ICN identity and
communicates with an ICN-enabled CDN provider, it will use ICN
primitives to fetch the data. On the other hand, for a UE
attached with an ICN identity, if PGW has to 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.
Prakash Suthar, et al. Expires November 26, 2020 [Page 28]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
6. Security Considerations
To ensure only authenticated UEs are connected to the network, LTE
mobile network implements various security mechanisms. From the
perspective of ICN deployment in the user plane, it needs to take
care of the following security aspects:
1. UE authentication and authorization
2. Radio or air interface security
3. Denial of service attacks on mobile gateway, services
4. Content positioning either in transport or servers
5. Content cache pollution attacks
6. Secure naming, routing, and forwarding
7. Application security
Security over the LTE air interface is provided through cryptographic
technique. When UE is powered up, it performs key exchange between
UE's USIM and HSS/Authentication Center using NAS messages, including
ciphering and integrity protections between UE and MME. Details of
secure UE authentication, key exchange, ciphering, and integrity
protections messages are given in the 3GPP call flow [TS23.401].
LTE is an all-IP network and uses IP transport in its mobile backhaul
(between eNodeB and core network). In case of provider-owned
backhaul, it may not implement security mechanisms; however, they are
necessary in case it uses a shared or leased network. The native IP
transport continues to leverage security mechanism such as Internet
key exchange (IKE) and the IP security protocol (IPsec). More
details of mobile backhaul security are provided in 3GPP network
security [TS33.310] and [TS33.320]. When mobile backhaul is upgraded
to support dual stack (IP+ICN) or native ICN, it is required to
implement security techniques that are deployed in mobile backhaul.
When ICN forwarding is enabled on mobile transport routers, we need
to deploy security practices based on [RFC7476] and [RFC7927].
Some key functions supported by LTE mobile gateway (SGW, PGW) are
content based billing, deep packet inspection (DPI), and lawful
intercept (LI). For ICN-based user plane traffic, it is required to
integrate ICN security for sessions between UE and gateway. However,
in the ICN network, some of the services provided by mobile gateways
mentioned above may not work because only consumers who have
Prakash Suthar, et al. Expires November 26, 2020 [Page 29]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
decryption keys can access the content. Further research in this
area is needed.
7. Summary
In this draft, we have discussed complexities of LTE network and key
dependencies for deploying ICN in user plane data transport.
Different deployment options described cover aspects such as inter
operability and multi-technology, which is a reality for any Service
Provider. One can use LTE gateway software and ICN simulator and
deploy ICN data transport in user plane as an overlay, dual stack (IP
+ ICN), hICN, or natively (by integrating ICN with CDN, eNodeB, SGW,
PGW and transport network). Notice that, for deployment scenarios
discussed above, additional study is required for lawful
interception, billing/mediation, network slicing, and provisioning
APIs.
Mobile Edge Computing (MEC) [CHENG] provides capabilities to deploy
functionalities such as Content Delivery Network (CDN) caching and
mobile user plane functions (UPF) [TS23.501]. Recent research for
delivering real-time video content [MPVCICN] using ICN has also been
proven to be efficient [NDNRTC] and can be used towards realizing the
benefits of ICN deployment in eNodeB, MEC, mobile gateways (SGW, PGW)
and CDN. The key aspect for ICN is in its seamless integration in
LTE and 5G networks with tangible benefits so we can optimize content
delivery using simple and scalable architecture. Authors will
continue to explore how ICN forwarding in MEC could be used in
efficient data delivery from the mobile edge.
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. As mentioned in
[TS23.501], 5G network architecture proposes simplification of
control plane messages and can be a candidate for use of ICN.
As a starting step towards ICN user plane deployment, it is proposed
to incorporate protocol changes in UE, eNodeB, SGW/PGW for data
transport. ICN has inherent capabilities for mobility and content
caching, which can improve the efficiency of data transport for
unicast and multicast delivery. Authors welcome contributions and
suggestions, including those related to further validations of the
principles by implementing prototype and/or proof of concept in the
lab and in the production environment.
Prakash Suthar, et al. Expires November 26, 2020 [Page 30]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
8. Acknowledgements
We thank all contributors, reviewers, and the chairs for the valuable
time in providing comments and feedback that helped improve this
draft. We specially want to mention the following members of the
IRTF Information-Centric Networking Research Group (ICNRG), listed in
alphabetical order: Thomas Jagodits, Luca Muscariello, David R.
Oran, Akbar Rahman, Martin J. Reed, and Thomas C. Schmidt.
The IRSG review was provided by Colin Perkins.
9. References
9.1. Normative References
[TS24.008]
3GPP, "Mobile radio interface Layer 3 specification; Core
network protocols; Stage 3", 3GPP TS 24.008 3.20.0,
December 2005,
<http://www.3gpp.org/ftp/Specs/html-info/24008.htm>.
[TS25.323]
3GPP, "Packet Data Convergence Protocol (PDCP)
specification", 3GPP TS 25.323 3.10.0, September 2002,
<http://www.3gpp.org/ftp/Specs/html-info/25323.htm>.
[TS29.274]
3GPP, "3GPP Evolved Packet System (EPS); Evolved General
Packet Radio Service (GPRS) Tunneling Protocol for Control
plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0, June
2013, <http://www.3gpp.org/ftp/Specs/html-info/29274.htm>.
[TS29.281]
3GPP, "General Packet Radio System (GPRS) Tunneling
Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0,
September 2011,
<http://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 10.2.0, January 2013,
<http://www.3gpp.org/ftp/Specs/html-info/36323.htm>.
Prakash Suthar, et al. Expires November 26, 2020 [Page 31]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
9.2. Informative References
[ALM] Auge, J., Carofiglio, G., Grassi, G., Muscariello, L.,
Pau, G., and X. Zeng, "Anchor-Less Producer Mobility in
ICN", Proceedings of the 2Nd ACM Conference on
Information-Centric Networking, ACM-ICN'15, ACM DL,
pp.189-190, September 2013,
<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 IEEE Xplore DL, pp.1-6, October 2006,
<https://ieeexplore.ieee.org/document/4086687>.
[CCN] "Content Centric Networking", <http://www.ccnx.org>.
[CHENG] Liang, C., Yu, R., and X. Zhang, "Information-centric
network function virtualization over 5g mobile wireless
networks", IEEE Network Journal vol. 29, number 3, pp.
68-74, June 2015,
<https://ieeexplore.ieee.org/document/7113228>.
[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,
<http://www.3gpp.org/news-events/3gpp-news/1882-cups>.
[GALIS] Galis, A., Makhijani, K., Yu, D., and B. Liu, "Autonomic
Slice Networking", draft-galis-anima-autonomic-slice-
networking-05 (work in progress), September 2018.
[GRAYSON] Grayson, M., Shatzkamer, M., and S. Wainner, "Cisco Press
book "IP Design for Mobile Networks"", Cisco
Press Networking Technology series, June 2009,
<http://www.ciscopress.com/store/
ip-design-for-mobile-networks-9781587058264>.
[H2020] H2020, "The POINT Project", <https://www.point-h2020.eu/>.
[HICN] Muscariello, L., Carofiglio, G., Auge, J., and M.
Papalini, "Hybrid Information-Centric Networking", draft-
muscariello-intarea-hicn-01 (work in progress), December
2018.
[ICN5G] Ravindran, R., suthar, P., Trossen, D., and G. White,
"Enabling ICN in 3GPP's 5G NextGen Core Architecture",
draft-ravi-icnrg-5gc-icn-02 (work in progress), July 2018.
Prakash Suthar, et al. Expires November 26, 2020 [Page 32]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
[ICNLOWPAN]
Gundogan, C., Schmidt, T., Waehlisch, M., Scherb, C.,
Marxer, C., and C. Tschudin, "ICN Adaptation to LowPAN
Networks (ICN LoWPAN)", draft-irtf-icnrg-icnlowpan-02
(work in progress), March 2019.
[ICNQoS] Al-Naday, M., Bontozoglou, A., Vassilakis, G., and M.
Reed, "Quality of Service in an Information-Centric
Network", 2014 IEEE Global Communications Conference IEEE
Xplore DL, pp. 1861-1866, December 2014,
<https://ieeexplore.ieee.org/document/7037079>.
[IPoICN] Trossen, D., Read, M., Riihijarvi, J., Georgiades, M.,
Fotiou, N., and G. Xylomenos, "IP over ICN - The better
IP?", 2015 European Conference on Networks and
Communications (EuCNC) IEEE Xplore DL, pp. 413-417, 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, April
2015, <https://ieeexplore.ieee.org/document/7114719>.
[MECSPEC] "Mobile Edge Computing (MEC); Framework and Reference
Architecture", ETSI European Telecommunication Standards
Institute (ETSI) MEC specification, 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, June 2015,
<https://ieeexplore.ieee.org/document/7169810>.
[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, pp. 974-991, May 2016,
<https://doi.org/10.1587/transcom.2015AMI0002>.
[NGMN] Robson, J., "Data Offloading Techniques in Cellular
Networks: A Survey", Next Generation Mobile Networks, LTE-
Advanced Transport Provisioning, V0.0.14, October 2015,
<https://www.ngmn.org/fileadmin/user_upload/150929_NGMN_P-
SmallCells_Backhaul_for_LTE-Advanced_and_Small_Cells.pdf>.
Prakash Suthar, et al. Expires November 26, 2020 [Page 33]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
[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, IEEE Xplore DL, vol:17, issue:2,
pp.580-603, 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, ACM DL, pp.575-579, June 2009,
<http://dl.acm.org/citation.cfm?id=1817271.1817379>.
[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>.
[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>.
[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>.
Prakash Suthar, et al. Expires November 26, 2020 [Page 34]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
[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) IEEE Xplore DL, pp. 1-7, 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>.
[TS23.203]
3GPP, "Policy and charging control architecture", 3GPP
TS 23.203 10.9.0, September 2013,
<http://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 10.10.0, March 2013,
<http://www.3gpp.org/ftp/Specs/html-info/23401.htm>.
[TS23.501]
3GPP, "System Architecture for the 5G System", 3GPP
TS 23.501 15.2.0, June 2018,
<http://www.3gpp.org/ftp/Specs/html-info/23501.htm>.
[TS23.714]
3GPP, "Technical Specification Group Services and System
Aspects: Study on control and user plane separation of EPC
nodes", 3GPP TS 23.714 0.2.2, June 2016,
<http://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 3.19.0, March 2004,
<http://www.3gpp.org/ftp/Specs/html-info/29060.htm>.
[TS33.310]
3GPP, "Network Domain Security (NDS); Authentication
Framework (AF)", 3GPP TS 33.310 10.7.0, December 2012,
<http://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 10.5.0, June 2012,
<http://www.3gpp.org/ftp/Specs/html-info/33320.htm>.
Prakash Suthar, et al. Expires November 26, 2020 [Page 35]
Internet-Draft draft-irtf-icnrg-icn-lte-4g-07 May 2020
Authors' Addresses
Prakash Suthar
Cisco Systems Inc.
Rosemont, Illinois 60018
USA
Email: psuthar@cisco.com
Milan Stolic
Cisco Systems Inc.
Rosemont, Illinois 60018
USA
Email: mistolic@cisco.com
Anil Jangam (editor)
Cisco Systems Inc.
San Jose, California 95134
USA
Email: anjangam@cisco.com
Dirk Trossen
Huawei Technologies
Riesstrasse 25
Munich 80992
Germany
Email: dirk.trossen@huawei.com
Ravishankar Ravindran
Sterlite Technologies
5201 Greatamerica Pkwy
Santa Clara, California 95054
USA
Email: ravishankar.ravindran@sterlite.com
Prakash Suthar, et al. Expires November 26, 2020 [Page 36]