idnits 2.17.1 draft-irtf-icnrg-icn-lte-4g-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (21 March 2022) is 766 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-irtf-icnrg-icnlowpan-10 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group Prakash Suthar 3 Internet-Draft Google Inc. 4 Intended status: Experimental Milan Stolic 5 Expires: 22 September 2022 Anil Jangam, Ed. 6 Cisco Systems Inc. 7 Dirk Trossen 8 Huawei Technologies 9 Ravi Ravindran 10 F5 Networks 11 21 March 2022 13 Experimental Scenarios of ICN Integration in 4G Mobile Networks 14 draft-irtf-icnrg-icn-lte-4g-12 16 Abstract 18 4G mobile network uses IP-based transport for the control plane to 19 establish the data session at the user plane for the actual data 20 delivery. In the existing architecture, IP-based unicast is used for 21 the delivery of multimedia content to a mobile terminal, where each 22 user is receiving a separate stream from the server. From a 23 bandwidth and routing perspective, this approach is inefficient. 24 Evolved multimedia broadcast and multicast service (eMBMS) provides 25 capabilities for delivering contents to multiple users 26 simultaneously, but its deployment is very limited or at an 27 experimental stage due to numerous challenges. The focus of this 28 draft is to list the options for use of Information centric 29 technology (ICN) in 4G mobile networks and elaborate the experimental 30 setups for its further evaluation. The experimental setups discussed 31 provide for using ICN either natively or with existing mobility 32 protocol stack. With further investigations based on the listed 33 experiments, ICN with its inherent capabilities such as, network- 34 layer multicast, anchorless mobility, security, and optimized data 35 delivery using local caching at the edge may provide a viable 36 alternative to IP transport in 4G mobile networks. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on 22 September 2022. 55 Copyright Notice 57 Copyright (c) 2022 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 62 license-info) in effect on the date of publication of this document. 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. Code Components 65 extracted from this document must include Revised BSD License text as 66 described in Section 4.e of the Trust Legal Provisions and are 67 provided without warranty as described in the Revised BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. 3GPP Terminology and Concepts . . . . . . . . . . . . . . . . 3 73 3. 4G Mobile Network Architecture . . . . . . . . . . . . . . . 7 74 3.1. Network Overview . . . . . . . . . . . . . . . . . . . . 7 75 3.2. Mobile Network Quality of Service . . . . . . . . . . . . 9 76 3.3. Data Transport Using IP . . . . . . . . . . . . . . . . . 10 77 3.4. Virtualized Mobile Networks . . . . . . . . . . . . . . . 11 78 4. Data Transport Using ICN . . . . . . . . . . . . . . . . . . 11 79 5. Experimental Scenarios for ICN Deployment . . . . . . . . . . 14 80 5.1. General Considerations . . . . . . . . . . . . . . . . . 14 81 5.2. Scenarios of ICN Integration . . . . . . . . . . . . . . 15 82 5.3. Integration of ICN in 4G Control Plane . . . . . . . . . 18 83 5.4. Integration of ICN in 4G User Plane . . . . . . . . . . . 20 84 5.4.1. Dual Transport (IP/ICN) Mode in Mobile Terminal . . . 20 85 5.4.2. Using ICN in Mobile Terminal . . . . . . . . . . . . 24 86 5.4.3. Using ICN in eNodeB . . . . . . . . . . . . . . . . . 25 87 5.4.4. Using ICN in Packet Core (SGW, PGW) Gateways . . . . 27 88 5.5. An Experimental Test Setup . . . . . . . . . . . . . . . 29 89 6. Expected Outcomes from Experimentation . . . . . . . . . . . 30 90 6.1. Feeding into ICN Research . . . . . . . . . . . . . . . . 30 91 6.2. Use of Results Beyond Research . . . . . . . . . . . . . 31 92 7. Security and Privacy Considerations . . . . . . . . . . . . . 31 93 7.1. Security Considerations . . . . . . . . . . . . . . . . . 32 94 7.2. Privacy Considerations . . . . . . . . . . . . . . . . . 33 95 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 96 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 98 10.1. Normative References . . . . . . . . . . . . . . . . . . 36 99 10.2. Informative References . . . . . . . . . . . . . . . . . 37 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 102 1. Introduction 104 4G mobile technology is built as an all-IP network using routing 105 protocols (OSPF, ISIS, BGP, etc.) to establish network routes. 106 Stickiness of an IP address to a device is the key to get connected 107 to a mobile network. The same IP address is maintained through the 108 session until the device gets detached or moves to another network. 110 Key protocols used in 4G networks are GPRS Tunneling protocol (GTP), 111 DIAMETER, and other protocols that are built on top of IP. One of 112 the biggest challenges with IP-based routing in 4G is that it is not 113 optimized for data transport. As an alternative to IP routing, this 114 draft presents and list the possible options for integration of 115 Information Centric Networking (ICN) in 3GPP 4G mobile network, 116 offering an opportunity to leverage inherent ICN capabilities such as 117 in-network caching, multicast, anchorless mobility management, and 118 authentication. This draft also discuss how those options affect 119 mobile providers and end users. 121 The goal of the proposed experiments is to present possibilities to 122 create simulated environments for evaluation of the benefits of ICN 123 protocol deployment in a 4G mobile network in different scenarios 124 that have been analyzed in this document. The consensus of the 125 Information-Centric Networking Research Group (ICNRG) is to publish 126 this document in order to facilitate experiments to show deployment 127 options and qualitative and quantitative benefits of ICN protocol 128 deployment in 4G mobile networks. 130 2. 3GPP Terminology and Concepts 132 1. Access Point Name 134 The Access Point Name (APN) is a Fully Qualified Domain Name 135 (FQDN) and resolves to a set of gateways in an operator's 136 network. APN identifies the packet data network (PDN) with 137 which a mobile data user wants to communicate. In addition to 138 identifying a PDN, an APN may also be used to define the type of 139 service, QoS, and other logical entities inside GGSN, PGW. 141 2. Control Plane 142 The control plane carries signaling traffic and is responsible 143 for routing between eNodeB and MME, MME and HSS, MME and SGW, 144 SGW and PGW, etc. Control plane signaling is required to 145 authenticate and authorize the mobile terminal and establish a 146 mobility session with mobile gateways (SGW/PGW). Control plane 147 functions also include system configuration and management. 149 3. Dual Address PDN/PDP Type 151 The dual address Packet Data Network/Packet Data Protocol (PDN/ 152 PDP) Type (IPv4v6) is used in 3GPP context, in many cases as a 153 synonym for dual stack, i.e., a connection type capable of 154 serving IPv4 and IPv6 simultaneously. 156 4. eNodeB 158 The eNodeB is a base station entity that supports the Long-Term 159 Evolution (LTE) air interface. 161 5. Evolved Packet Core 163 The Evolved Packet Core (EPC) is an evolution of the 3GPP GPRS 164 system characterized by a higher-data-rate, lower-latency, 165 packet-optimized system. The EPC comprises some sub components 166 of the EPS core such as Mobility Management Entity (MME), 167 Serving Gateway (SGW), Packet Data Network Gateway (PDN-GW), and 168 Home Subscriber Server (HSS). 170 6. Evolved Packet System 172 The Evolved Packet System (EPS) is an evolution of the 3GPP GPRS 173 system characterized by a higher-data-rate, lower-latency, 174 packet-optimized system that supports multiple Radio Access 175 Technologies (RATs). The EPS comprises the EPC together with 176 the Evolved Universal Terrestrial Radio Access (E-UTRA) and the 177 Evolved Universal Terrestrial Radio Access Network (E-UTRAN). 179 7. Evolved UTRAN 181 The E-UTRAN is a communications network sometimes referred to as 182 4G, and consists of eNodeB (4G base stations). The E-UTRAN 183 allows connectivity between the User Equipment and the core 184 network. 186 8. GPRS Tunneling Protocol 187 The GPRS Tunneling Protocol (GTP) [TS29.060] [TS29.274] 188 [TS29.281] is a tunneling protocol defined by 3GPP. It is a 189 network-based mobility protocol, working similar to Proxy Mobile 190 IPv6 (PMIPv6). However, GTP also provides functionality beyond 191 mobility, such as in-band signaling related to QoS and charging, 192 among others. 194 9. Gateway GPRS Support Node 196 The Gateway GPRS Support Node (GGSN) is a gateway function in 197 the GPRS and 3G network that provides connectivity to the 198 Internet or other PDNs. The host attaches to a GGSN identified 199 by an APN assigned to it by an operator. The GGSN also serves 200 as the topological anchor for addresses/prefixes assigned to the 201 User Equipment. 203 10. General Packet Radio Service 205 The General Packet Radio Service (GPRS) is a packet-oriented 206 mobile data service available to users of the 2G and 3G cellular 207 communication systems--the GSM--specified by 3GPP. 209 11. Home Subscriber Server 211 The Home Subscriber Server (HSS) is a database for a given 212 subscriber and was introduced in 3GPP Release-5. It is the 213 entity containing subscription-related information to support 214 the network entities that handle calls/sessions. 216 12. Mobility Management Entity 218 The Mobility Management Entity (MME) is a network element 219 responsible for control plane functionalities, including 220 authentication, authorization, bearer management, layer-2 221 mobility, and so on. The MME is essentially the control plane 222 part of the SGSN in the GPRS. The user plane traffic bypasses 223 the MME. 225 13. Public Land Mobile Network 227 The Public Land Mobile Network (PLMN) is a network operated by a 228 single administration. A PLMN (and, therefore, also an 229 operator) is identified by the Mobile Country Code (MCC) and the 230 Mobile Network Code (MNC). Each (telecommunications) operator 231 providing mobile services has its own PLMN. 233 14. Policy and Charging Control 234 The Policy and Charging Control (PCC) framework is used for QoS 235 policy and charging control. It has two main functions: flow- 236 based charging (including online credit control), and policy 237 control (for example, gating control, QoS control, and QoS 238 signaling). It is optional to 3GPP EPS but needed if dynamic 239 policy and charging control by means of PCC rules based on user 240 and services are desired. 242 15. Packet Data Network 244 The Packet Data Network (PDN) is a packet-based network that 245 either belongs to the operator or is an external network such as 246 the Internet or a corporate intranet. The user eventually 247 accesses services in one or more PDNs. The operator's packet 248 core networks are separated from packet data networks either by 249 GGSNs or PDN Gateways (PGWs). 251 16. Serving Gateway 253 The Serving Gateway (SGW) is a gateway function in the EPS, 254 which terminates the interface towards the E-UTRAN. The SGW is 255 the Mobility Anchor point for layer-2 mobility (inter-eNodeB 256 handovers). For each mobile terminal connected with the EPS, 257 there is only one SGW at any given point in time. The SGW is 258 essentially the user plane part of the GPRS's SGSN. 260 17. Packet Data Network Gateway 262 The Packet Data Network Gateway (PGW) is a gateway function in 263 the Evolved Packet System (EPS), which provides connectivity to 264 the Internet or other PDNs. The host attaches to a PGW 265 identified by an APN assigned to it by an operator. The PGW 266 also serves as the topological anchor for addresses/prefixes 267 assigned to the User Equipment. 269 18. Packet Data Protocol Context 271 A Packet Data Protocol (PDP) context is the equivalent of a 272 virtual connection between the mobile terminal (MT) and a PDN 273 using a specific gateway. 275 19. Packet Data Protocol Type 277 A Packet Data Protocol Type (PDP Type) identifies the used/ 278 allowed protocols within the PDP context. Examples are IPv4, 279 IPv6, and IPv4v6 (dual-stack). 281 20. Serving GPRS Support Node 282 The Serving GPRS Support Node (SGSN) is a network element 283 located between the radio access network (RAN) and the gateway 284 (GGSN). A per-MT point-to-point (p2p) tunnel between the GGSN 285 and SGSN transports the packets between the mobile terminal and 286 the gateway. 288 21. Mobile Terminal/User Equipment 290 The terms User Equipment (UE), Mobile Station (MS), Mobile Node 291 (MN), and mobile refer to the devices that are hosts with the 292 ability to obtain Internet connectivity via a 3GPP network. An 293 MS comprises the Terminal Equipment (TE) and a Mobile Terminal 294 (MT). The terms MT, MS, MN, and mobile are used interchangeably 295 within this document. 297 22. User Plane 299 The user plane refers to data traffic and the required bearers 300 for the data traffic. In practice, IP is the only data traffic 301 protocol used in the user plane. 303 3. 4G Mobile Network Architecture 305 This section provide a high-level overview of typical 4G mobile 306 network architecture and their key functions related to a possibility 307 of using of ICN technology. 309 3.1. Network Overview 311 4G mobile networks are designed to use IP transport for communication 312 among different elements such as eNodeB, MME, SGW/PGW, HSS, PCRF, 313 etc. [GRAYSON]. For backward compatibility with 3G, it has support 314 for legacy Circuit Switch features such as voice and SMS through 315 transitional CS fallback and flexible IMS deployment. For each 316 mobile device attached to the radio (eNodeB), there is a separate 317 overlay tunnel (GPRS Tunneling Protocol, GTP) between eNodeB and 318 Mobile gateways (i.e., SGW, PGW). 320 When any mobile terminal is powered up, it attaches to a mobile 321 network based on its configuration and subscription. After a 322 successful attachment procedure, the mobile terminal registers with 323 the mobile core network using IPv4 and/or IPv6 address based on 324 request and capabilities offered by mobile gateways. 326 The GTP tunnel is used to carry user traffic between gateways and 327 mobile terminal, therefore using the unicast delivery for any data 328 transfer. It is also important to understand the overhead of GTP and 329 IPSec protocols. All mobile backhaul traffic is encapsulated using a 330 GTP tunnel, which has overhead of 8 bytes on top of IP and UDP 331 [NGMN]. Additionally, if IPSec is used for security (which is often 332 required if the Service Provider is using a shared backhaul), it adds 333 overhead based on the IPSec tunneling model (tunnel or transport) as 334 well as the encryption and authentication header algorithm used. If 335 we consider as an example an Advanced Encryption Standard (AES) 336 encryption, the overhead can be significant [OLTEANU], particularly 337 for smaller payloads. 339 +-------+ Diameter +-------+ 340 | HSS |------------| SPR | 341 +-------+ +-------+ 342 | | 343 +------+ +------+ S4 | +-------+ 344 | 3G |---| SGSN |----------------|------+ +------| PCRF | 345 ^ |NodeB | | |---------+ +---+ | | +-------+ 346 +-+ | +------+ +------+ S3 | | S6a | |Gxc | 347 | | | +-------+ | | |Gx 348 +-+ | +------------------| MME |------+ | | | 349 MT v | S1MME +-------+ S11 | | | | 350 +----+-+ +-------+ +-------+ 351 |4G/LTE|------------------------------| SGW |-----| PGW | 352 |eNodeB| S1U +-------+ +--| | 353 +------+ | +-------+ 354 +---------------------+ | | 355 S1U GTP Tunnel traffic | +-------+ | | 356 S2a GRE Tunnel traffic |S2A | ePDG |-------+ | 357 S2b GRE Tunnel traffic | +-------+ S2B |SGi 358 SGi IP traffic | | | 359 +---------+ +---------+ +-----+ 360 | Trusted | |Untrusted| | CDN | 361 |non-3GPP | |non-3GPP | +-----+ 362 +---------+ +---------+ 363 | | 364 +-+ +-+ 365 | | | | 366 +-+ +-+ 367 MT MT 369 Figure 1: 4G Mobile Network Overview 371 If we consider the combined impact of GTP, IPSec and unicast traffic, 372 the data delivery is not efficient because of overhead. The IETF has 373 developed various header compression algorithms to reduce the 374 overhead associated with IP packets. Some techniques are robust 375 header compression (ROHC) and enhanced compression of the real-time 376 transport protocol (ECRTP) so that the impact of overhead created by 377 GTP, IPsec, etc., is reduced to some extent [BROWER]. For commercial 378 mobile networks, 3GPP has adopted different mechanisms for header 379 compression to achieve efficiency in data delivery [TS25.323]; those 380 solutions can be adapted to other data protocols, such as ICN, too 381 [ICNLOWPAN] [TLVCOMP]. 383 3.2. Mobile Network Quality of Service 385 During the mobile terminal attachment procedure, a default bearer is 386 created for each mobile terminal and it is assigned to the default 387 Access Point Name (APN), which provides the default transport. For 388 any QoS-aware application, one or more new dedicated bearers are 389 established between eNodeB and Mobile Gateway. Dedicated bearer can 390 be requested either by mobile terminal or mobile gateway based on 391 direction of first data flow. There are many bearers (logical paths) 392 established between eNodeB and mobile gateway for each mobile 393 terminal catering to different data flow simultaneously. 395 While all traffic within a certain bearer receives the same 396 treatment, QoS parameters supporting these requirements can be very 397 granular in different bearers. These values vary for the control, 398 management and user traffic, and can be very different depending on 399 application key parameters such as latency, jitter (important for 400 voice and other real-time applications), packet loss, and queuing 401 mechanism (strict priority, low-latency, fair, and so on). 403 Implementation of QoS for mobile networks is done at two stages: at 404 content prioritization/marking and transport marking, and congestion 405 management. From the transport perspective, QoS is defined at layer 406 2 as class of service (CoS) and at layer 3 as Differentiated Services 407 (DS). The mapping of DSCP to CoS takes place at layer 2/3 switching 408 and routing elements. 3GPP has a specified a QoS Class Identifier 409 (QCI), which represents different types of content and equivalent 410 mappings to the DSCP at transport layer [TS23.401]. However, this 411 requires manual configuration at different elements and is therefore 412 prone to possible misconfigurations. 414 In summary, QoS configuration in mobile networks for user plane 415 traffic requires synchronization of parameters among different 416 platforms. Normally, QoS in IP is implemented using DiffServ, which 417 uses hop-by-hop QoS configuration at each router. Any inconsistency 418 in IP QoS configuration at routers in the forwarding path can result 419 in a poor subscriber experience (e.g., packet classified as high 420 priority can go to a lower priority queue). By deploying ICN, we 421 intend to enhance the subscriber experience using policy-based 422 configuration, which can be associated with the named contents 423 [ICNQoS] at the ICN forwarder. Further investigation is underway to 424 understand how QoS in ICN [I-D.anilj-icnrg-dnc-qos-icn] can be 425 implemented with reference to the ICN QoS guidelines [RFC9064] to 426 meet the QoS requirements [RFC4594]. 428 3.3. Data Transport Using IP 430 The data delivered to mobile devices is sent in unicast semantic 431 inside the GTP tunnel from an eNodeB to a PDN gateway (PGW), as 432 described in 3GPP specifications [TS23.401]. While the technology 433 exists to address the issue of possible multicast delivery, there are 434 many difficulties related to multicast protocol implementations on 435 the RAN side of the network. By using eMBMS [EMBMS], multicast 436 routing can be enabled in mobile backhaul between eNodeB and Mobile 437 Gateways (SGW) however for radio interface it requires broadcast 438 which implies that we need dedicated radio channel. Implementation 439 of eMBMS in RAN is still lagging behind due to complexities related 440 to client mobility, handovers, and the fact that the potential gain 441 to Service Providers may not justify the investment, which explains 442 the prevalence of unicast delivery in mobile networks. Techniques to 443 handle multicast (such as LTE-B or eMBMS) have been designed to 444 handle pre-planned content delivery, such as live content, which 445 contrasts user behavior today, largely based on content (or video) on 446 demand model. 448 To ease the burden on the bandwidth of the SGi interface, caching is 449 introduced in a similar manner as with many Enterprises. In mobile 450 networks, whenever possible, cached data is delivered. Caching 451 servers are placed at a centralized location, typically in the 452 Service Provider's Data Center, or in some cases lightly distributed 453 in Packet Core locations with the PGW nodes close to the Internet and 454 IP services access (SGi interface). This is a very inefficient 455 concept because traffic must traverse the entire backhaul path for 456 the data to be delivered to the end user. Other issues, such as out- 457 of-order delivery, contribute to this complexity and inefficiency, 458 which needs to be addressed at the application level. 460 3.4. Virtualized Mobile Networks 462 The Mobile gateways deployed in a major Service Provider network are 463 either based on dedicated hardware or, commercially off the shelf 464 (COTS) based x86 technology. With the adoption of Mobile Virtual 465 Network Operators (MVNO), public safety networks, and enterprise 466 mobility networks, elastic mobile core architecture are needed. By 467 deploying the mobile packet core on COTS platform, using a 468 virtualized infrastructure (NFVI) framework and end-to-end 469 orchestration, new deployments can be simplified to provide optimized 470 total cost of ownership (TCO). 472 While virtualization is growing, and many mobile providers use a 473 hybrid architecture that consists of dedicated and virtualized 474 infrastructures, the control, and data planes are still the same. 475 There is also work under way to separate the control and user plane 476 for the network to scale better. Virtualized mobile networks and 477 network slicing with control and user plane separation provide a 478 mechanism to evolve the GTP-based architecture towards an OpenFlow 479 SDN-based signaling for 4G and proposed 5G core. Some early 480 architecture work for 5G mobile technologies provides a mechanism for 481 control and user plane separation and simplifies the mobility call 482 flow by introducing OpenFlow-based signaling [ICN5G]. This has been 483 considered by 3GPP [EPCCUPS] and is also described in [SDN5G]. 485 4. Data Transport Using ICN 487 For mobile devices, the edge connectivity is between mobile terminal 488 and a router or mobile edge computing (MEC) [MECSPEC] element. Edge 489 computing has the capability of processing client requests and 490 segregating control and user traffic at the edge of radio, rather 491 than sending all requests to the mobile gateway. 493 +----------+ 494 | Content +----------------------------------------+ 495 | Publisher| | 496 +---+---+--+ | 497 | | +--+ +--+ +--+ | 498 | +--->|R1|------------>|R2|---------->|R4| | 499 | +--+ +--+ +--+ | 500 | | Cached | 501 | v content | 502 | +--+ at R3 | 503 | +========|R3|---+ | 504 | # +--+ | | 505 | # | | 506 | v v | 507 | +-+ +-+ | 508 +---------------| |-------------| |-------------+ 509 +-+ +-+ 510 Consumer-1 Consumer-2 511 Mobile Terminal Mobile Terminal 513 ===> Content flow from cache 514 ---> Content flow from publisher 516 Figure 2: ICN Architecture 518 Edge computing transforms radio access network into an intelligent 519 service edge capable of delivering services directly from the edge of 520 the network, while providing the best possible performance to the 521 client. Edge computing can be an ideal candidate for implementing 522 ICN forwarders in addition to its usual function of managing mobile 523 termination. In addition to edge computing, other transport 524 elements, such as routers, can work as ICN forwarders. 526 Data transport using ICN is different to IP-based transport by 527 introducing uniquely named-data as a core design principle. 528 Communication in ICN takes place between the content provider 529 (producer) and the end user (consumer), as described in Figure 2. 531 Every node in a physical path between a client and a content provider 532 is called the ICN forwarder or router. It can route the request 533 intelligently and cache content so it can be delivered locally for 534 subsequent requests from any other client. For mobile networks, 535 transport between a client and a content provider consists of radio 536 network + mobile backhaul and IP core transport + Mobile Gateways + 537 Internet + content data network (CDN). 539 To understand the suitability of ICN for mobile networks, we will 540 discuss the ICN framework by describing its protocols architecture 541 and different types of messages to then consider how we can use this 542 in mobile networks for delivering content more efficiently. ICN uses 543 two types of packets called "interest packet" and "data packet" as 544 described in Figure 3. 546 +------------------------------------+ 547 Interest | +------+ +------+ +------+ | +-----+ 548 +-+ ---->| CS |---->| PIT |---->| FIB |--------->| CDN | 549 | | | +------+ +------+ +------+ | +-----+ 550 +-+ | | Add | Drop | | Forward 551 MT <--------+ Intf v Nack v | 552 Data | | 553 +------------------------------------+ 555 +------------------------------------+ 556 +-+ | Forward +------+ | +-----+ 557 | | <-------------------------------------| PIT |<---------| CDN | 558 +-+ | | Cache +--+---+ | Data +-----+ 559 MT | +--v---+ | | 560 | | CS | v | 561 | +------+ Discard | 562 +------------------------------------+ 564 Figure 3: ICN Interest, Data Packet and Forwarder 566 In an 4G network, when a mobile device wants to receive certain 567 content, it will send an Interest message to the closest eNodeB. 568 Interest packets follow the TLV format [RFC8609] and contain 569 mandatory fields, such as name of the content and content matching 570 restrictions (KeyIdRestr and ContentObjectHashRestr), expressed as a 571 tuple [RFC8569]. The content matching tuple uniquely identifies the 572 matching data packet for the given Interest packet. Another 573 attribute called HopLimit is used to detect looping Interest 574 messages. 576 An ICN router will receive an Interest packet and lookup if a request 577 for such content has arrived earlier from another client. If so, it 578 may be served from the local cache; otherwise, the request is 579 forwarded to the next-hop ICN router. Each ICN router maintains 580 three data structures: Pending Interest Table (PIT), Forwarding 581 Information Base (FIB), and Content Store (CS). The Interest packet 582 travels hop-by-hop towards the content provider. Once the Interest 583 packet reaches the content provider, it will return a Data packet 584 containing information such as content name, signature, and the 585 actual data. 587 The data packet travels in reverse direction following the same path 588 taken by the Interest packet, maintaining routing symmetry. Details 589 about algorithms used in PIT, FIB, CS, and security trust models are 590 described in various resources [CCN]; here, we have explained the 591 concept and its applicability to the 4G network. 593 5. Experimental Scenarios for ICN Deployment 595 In 4G mobile networks, both user and control plane traffic have to be 596 transported from the edge to the mobile packet core via IP transport. 597 The evolution of the existing mobile packet core using Control and 598 User Plane Separation (CUPS) [TS23.714] enables flexible network and 599 operations by distributed deployment and the independent scaling of 600 control plane and user plane functions - while not affecting the 601 functionality of existing nodes subject to this split. 603 In this section, we analyze the potential impact of ICN on control 604 and user plane traffic for centralized and disaggregated CUPS-based 605 mobile network architecture. We list various experimental options 606 and opportunities to study the feasibility of the deployment of ICN 607 in 4G networks. The proposed experiments would help the network and 608 OEM designers to understand various issues, optimizations, and 609 advantages of deployment of ICN in 4G networks. 611 5.1. General Considerations 613 In the CUPS architecture, there is an opportunity to shorten the path 614 for user plane traffic by deploying offload nodes closer to the edge 615 [OFFLOAD]. With this major architecture change, a User Plane 616 Function (UPF) node is placed close to the edge so traffic no longer 617 needs to traverse the entire backhaul path to reach the EPC. In many 618 cases, where feasible, the UPF can be collocated with the eNodeB, 619 which is also a business decision based on user demand. Placing a 620 Publisher close to the offload site, or at the offload site, provides 621 for a significant improvement in user experience, especially with 622 latency-sensitive applications. This capability allows for the 623 introduction of ICN and amplifies its advantages. 625 5.2. Scenarios of ICN Integration 627 The integration of ICN provides an opportunity to further optimize 628 the existing data transport in 4G mobile networks. The various 629 opportunities from the coexistence of ICN and IP transport in the 630 mobile network are somewhat analogous to the deployment scenarios 631 when IPv6 was introduced to interoperate with IPv4 except, with ICN, 632 the whole IP stack can be replaced. We have reviewed [RFC6459] and 633 analyzed the impact of ICN on control plane signaling and user plane 634 data delivery. In general, ICN can be used natively by replacing IP 635 transport (IPv4 and IPv6) or as an overlay protocol. Figure 4 636 describes a proposal to modify the existing transport protocol stack 637 to support ICN in 4G mobile network. 639 +----------------+ +-----------------+ 640 | ICN App (new) | |IP App (existing)| 641 +---------+------+ +-------+---------+ 642 | | 643 +---------+----------------+---------+ 644 | Transport Convergence Layer (new) | 645 +------+---------------------+-------+ 646 | | 647 +------+------+ +------+-------+ 648 |ICN function | | IP function | 649 | (New) | | (Existing) | 650 +------+------+ +------+-------+ 651 | | 652 (```). (```). 653 ( ICN '`. ( IP '`. 654 ( Cloud ) ( Cloud ) 655 ` __..'+' ` __..'+' 657 Figure 4: IP/ICN Convergence Scenarios 659 As shown in Figure 4, for applications - running either in the mobile 660 terminal or in the content provider system - to use the ICN transport 661 option, we propose a new transport convergence layer (TCL). The TCL 662 helps determine the type of transport (such as ICN or IP), as well as 663 the type of radio interface (LTE or WiFi or both) used to send and 664 receive traffic based on preference (e.g., content location, content 665 type, content publisher, congestion, cost, QoS). It helps configure 666 and determine the type of connection (native IP or ICN) or the 667 overlay mode (ICNoIP or IPoICN) between application and the protocol 668 stack (IP or ICN). 670 Combined with the existing IP function, the ICN function provides 671 support for either native ICN and/or the dual transport (ICN/IP) 672 transport functionality. See Section 5.4.1 for elaborate 673 descriptions of these functional layers. 675 The TCL can use several mechanisms for transport selection. It can 676 use a per-application configuration through a management interface, 677 possibly a user-facing setting realized through a user interface, 678 like those used to select cellular over WiFi. In another option, it 679 might use a software API, which an adapted IP application could use 680 to specify the type of transport option (such as ICN) to take 681 advantage of its benefits. 683 Another potential application of TCL is in implementation of network 684 slicing, with a slice management capability locally or through an 685 interface to an external slice manager via an API [GALIS]. This 686 solution can enable network slicing for IP and ICN transport 687 selection from the mobile terminal itself. The TCL could apply slice 688 settings to direct certain applications traffic over one slice and 689 others over another slice, determined by some form of 'slicing 690 policy'. Slicing policy can be obtained externally from the slice 691 manager or configured locally on the mobile terminal. 693 From the perspective of applications either on the mobile terminal or 694 at a content provider, the following options are possible for 695 potential use of ICN natively and/or with IP. 697 1. IP over IP 699 In this scenario, the mobile terminal applications are tightly 700 integrated with the existing IP transport infrastructure. The 701 TCL has no additional function because packets are forwarded 702 directly using an IP protocol stack, which sends packets over the 703 IP transport. 705 2. ICN over ICN 707 Similar to case 1, ICN applications tightly integrate with the 708 ICN transport infrastructure. The TCL has no additional 709 responsibility because packets are forwarded directly using the 710 native ICN protocol stack, which sends packets over the ICN 711 transport. 713 3. ICN over IP (ICNoIP) 715 In this scenario, the underlying IP transport infrastructure is 716 not impacted (that is, ICN is implemented as an IP overlay 717 between mobile terminal and content provider). IP routing is 718 used from the Radio Access Network (eNodeB) to the mobile 719 backhaul, the IP core, and the Mobile Gateway (SGW/PGW). The 720 mobile terminal attaches to the Mobile Gateway (SGW/PGW) using an 721 IP address. Also, the data transport between Mobile Gateway 722 (SGW/PGW) and content publisher uses IP. The content provider 723 can serve content either using IP or ICN, based on the mobile 724 terminal request. 726 One of the approaches to implement ICN in mobile backhaul 727 networks is described in [MBICN]. It implements a GTP-U 728 extension header option to encapsulate ICN payload in a GTP 729 tunnel. However, as this design runs ICN as an IP overlay, the 730 mobile backhaul can be deployed using native IP. The proposal 731 describes a mechanism where the GTP-U tunnel can be terminated by 732 hairpinning the packet before it reaches SGW, if an ICN-enabled 733 node is deployed in the mobile backhaul (that is, between eNodeB 734 and SGW). This could be useful when an ICN data packet is stored 735 in the ICN node (such as repositories, caches) in the tunnel path 736 so that the ICN node can reply without going all the way through 737 the mobile core. While a GTP-U extension header is used to carry 738 mobile terminal specific ICN payload, they are not visible to the 739 transport, including SGW. On the other hand, the PGW can use the 740 mobile terminal-specific ICN header extension and ICN payload to 741 set up an uplink transport towards a content provider in the 742 Internet. In addition, the design assumes a proxy function at 743 the edge, to perform ICN data retrieval on behalf of a non-ICN 744 end device. 746 4. IP over ICN (IPoICN) 748 [IPoICN] provides an architectural framework for running IP as an 749 overlay over ICN protocol. Implementing IP services over ICN 750 provides an opportunity to leverage the benefits of ICN in the 751 transport infrastructure while there is no impact on end devices 752 (MT and access network) as they continue to use IP. IPoICN 753 however, will require an inter-working function (IWF/Border 754 Gateway) to translate various transport primitives. The IWF 755 function will provide a mechanism for protocol translation 756 between IPoICN and the native IP. After reviewing [IPoICN], we 757 understand and interpret that ICN is implemented in the transport 758 natively, however, IP is implemented in MT, eNodeB, and Mobile 759 gateway (SGW/PGW), which is also called as a network attach point 760 (NAP). 762 For this, said NAP receives an incoming IP or HTTP packet (the 763 latter through TCP connection termination) and publishes the 764 packet under a suitable ICN name (i.e., the hash over the 765 destination IP address for an IP packet or the hash over the FQDN 766 of the HTTP request for an HTTP packet) to the ICN network. In 767 the HTTP case, the NAP maintains a pending request mapping table 768 to map returning responses to the terminated TCP connection. 770 5. Hybrid ICN (hICN) 772 An alternative approach to implement ICN over IP is provided in 773 Hybrid ICN [HICN]. It describes a novel approach to integrate 774 ICN into IPv6 without creating overlays with a new packet format 775 as an encapsulation. hICN addresses the content by encoding a 776 location-independent name in an IPv6 address. It uses two name 777 components--name prefix and name suffix--that identify the source 778 of data and the data segment within the scope of the name prefix, 779 respectively. 781 At application layer, hICN maps the name into an IPv6 prefix and, 782 thus, uses IP as transport. As long as the name prefixes, which 783 are routable IP prefixes, point towards a mobile GW (PGW or local 784 breakout, such as CUPS), there are potentially no updates 785 required to any of the mobile core gateways (for example, SGW/ 786 PGW). The IPv6 backhaul routes the packets within the mobile 787 core. hICN can run in the mobile terminal, in the eNodeB, in the 788 mobile backhaul, or in the mobile core. Finally, as hICN itself 789 uses IPv6, it cannot be considered as an alternative transport 790 layer. 792 5.3. Integration of ICN in 4G Control Plane 794 In this section, we analyze signaling messages that are required for 795 different procedures, such as attach, handover, tracking area update, 796 and so on. The goal of this analysis is to see if there are any 797 benefits to replacing IP-based protocols with ICN for 4G signaling in 798 the current architecture. It is important to understand the concept 799 of point of attachment (POA). When mobile terminal connects to a 800 network, it has the following POAs: 802 1. eNodeB managing location or physical POA 804 2. Authentication and Authorization (MME, HSS) managing identity or 805 authentication POA 807 3. Mobile Gateways (SGW, PGW) managing logical or session management 808 POA 810 In the current architecture, IP transport is used for all messages 811 associated with the control plane for mobility and session 812 management. IP is embedded very deeply into these messages utilizing 813 TLV syntax for carrying additional attributes such as a layer 3 814 transport. The physical POA in the eNodeB handles both mobility and 815 session management for any mobile terminal attached to 4G network. 816 The number of mobility management messages between different nodes in 817 an 4G network per signaling procedure is shown in Table 1. 819 Normally, two types of mobile terminals attach to the 4G network: SIM 820 based (need 3GPP mobility protocol for authentication) or non-SIM 821 based (which connect to WiFi network). Both device types require 822 authentication. For non-SIM based devices, AAA is used for 823 authentication. We do not propose to change mobile terminal 824 authentication or mobility management messaging for user data 825 transport using ICN. A separate study would be required to analyze 826 the impact of ICN on mobility management messages structures and 827 flows. We are merely analyzing the viability of implementing ICN as 828 a transport for control plane messages. 830 It is important to note that if MME and HSS do not support ICN 831 transport, they still need to support mobile terminal capable of dual 832 transport or native ICN. When mobile terminal initiates an attach 833 request using the identity as ICN, MME must be able to parse that 834 message and create a session. MME forwards mobile terminal 835 authentication to HSS, so HSS must be able to authenticate an ICN- 836 capable mobile terminal and authorize create session [TS23.401]. 838 +===========================+=====+=====+=====+=====+======+ 839 | 4G Signaling Procedures | MME | HSS | SGW | PGW | PCRF | 840 +===========================+=====+=====+=====+=====+======+ 841 | Attach | 10 | 2 | 3 | 2 | 1 | 842 +---------------------------+-----+-----+-----+-----+------+ 843 | Additional default bearer | 4 | 0 | 3 | 2 | 1 | 844 +---------------------------+-----+-----+-----+-----+------+ 845 | Dedicated bearer | 2 | 0 | 2 | 2 | 0 | 846 +---------------------------+-----+-----+-----+-----+------+ 847 | Idle-to-connect | 3 | 0 | 1 | 0 | 0 | 848 +---------------------------+-----+-----+-----+-----+------+ 849 | Connect-to-Idle | 3 | 0 | 1 | 0 | 0 | 850 +---------------------------+-----+-----+-----+-----+------+ 851 | X2 handover | 2 | 0 | 1 | 0 | 0 | 852 +---------------------------+-----+-----+-----+-----+------+ 853 | S1 handover | 8 | 0 | 3 | 0 | 0 | 854 +---------------------------+-----+-----+-----+-----+------+ 855 | Tracking area update | 2 | 2 | 0 | 0 | 0 | 856 +---------------------------+-----+-----+-----+-----+------+ 857 | Total | 34 | 2 | 14 | 6 | 3 | 858 +---------------------------+-----+-----+-----+-----+------+ 860 Table 1: Signaling Messages in 4G Gateways 862 Anchorless mobility [ALM] provides a fully decentralized, control- 863 plane agnostic solution to handle producer mobility in ICN. Mobility 864 management at layer-3 level makes it access agnostic and transparent 865 to the end device or the application. The solution discusses 866 handling mobility without having to depend on core network functions 867 (e.g. MME); however, a location update to the core network may still 868 be required to support legal compliance requirements such as lawful 869 intercept and emergency services. These aspects are open for further 870 study. 872 One of the advantages of ICN is in the caching and reusing of the 873 content, which does not apply to the transactional signaling 874 exchange. After analyzing 4G signaling call flows [TS23.401] and 875 messages inter-dependencies (see Table 1), our recommendation is that 876 it is not beneficial to use ICN for control plane and mobility 877 management functions. Among the features of ICN design, Interest 878 aggregation and content caching are not applicable to control plane 879 signaling messages. Control plane messages are originated and 880 consumed by the applications and they cannot be shared. 882 5.4. Integration of ICN in 4G User Plane 884 We will consider Figure 1 to discuss different mechanisms to 885 integrate ICN in mobile networks. In Section 5.2, we discussed 886 generic experimental setups of ICN integration. In this section, we 887 discuss the specific options of possible use of native ICN in 4G user 888 plane. We consider the following options: 890 1. Dual transport (IP/ICN) mode in Mobile Terminal 892 2. Using ICN in Mobile Terminal 894 3. Using ICN in eNodeB 896 4. Using ICN in mobile gateways (SGW/PGW) 898 5.4.1. Dual Transport (IP/ICN) Mode in Mobile Terminal 900 The control and user plane communications in 4G mobile networks are 901 specified in 3GPP documents [TS23.203] and [TS23.401]. It is 902 important to understand that mobile terminal can be either consumer 903 (receiving content) or publisher (pushing content for other clients). 904 The protocol stack inside the mobile terminal (MT) is complex because 905 it must support multiple radio connectivity access to eNodeB(s). 907 Figure 5 provides a high-level description of a protocol stack, where 908 IP is used at two layers: (1) user plane communication and (2) UDP 909 encapsulation. User plane communication takes place between Packet 910 Data Convergence Protocol (PDCP) and Application layer, whereas UDP 911 encapsulation is at GTP protocol stack. 913 The protocol interactions and impact of supporting tunneling of ICN 914 packet into IP or to support ICN natively are described in Figure 5 915 and Figure 6, respectively. 917 +--------+ +--------+ 918 | App | | CDN | 919 +--------+ +--------+ 920 |Transp. | | | | |Transp. | 921 |Converg.|.|..............|...............|............|.|Converge| 922 +--------+ | | | +--------+ | +--------+ 923 | |.|..............|...............|.| |.|.| | 924 | ICN/IP | | | | | ICN/IP | | | ICN/IP| 925 | | | | | | | | | | 926 +--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+ 927 | |.|.| | |.|.| | |.|.| | | | | | 928 | PDCP | | |PDCP|GTP-U| | |GTP-U|GTP-U| | |GTP-U| | | | L2 | 929 +--------+ | +----------+ | +-----------+ | +-----+ | | | | 930 | RLC |.|.|RLC | UDP |.|.| UDP | UDP |.|.|UDP |L2|.|.| | 931 +--------+ | +----------+ | +-----------+ | +-----+ | | | | 932 | MAC |.|.| MAC| L2 |.|.| L2 | L2 |.|.| L2 | | | | | 933 +--------+ | +----------+ | +-----------+ | +--------+ | +--------+ 934 | L1 |.|.| L1 | L1 |.|.| L1 | L1 |.|.| L1 |L1|.|.| L1 | 935 +--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+ 936 MT | BS(eNodeB) | SGW | PGW | 937 Uu S1U S5/S8 SGi 939 Figure 5: Dual Transport (IP/ICN) mode in Mobile Terminal 941 The protocols and software stack used inside 4G capable mobile 942 terminal support both 3G and 4G software interworking and handover. 943 3GPP Rel.13 onward specifications describe the use of IP and non-IP 944 protocols to establish logical/session connectivity. We can leverage 945 the non-IP protocol-based mechanism to deploy ICN protocol stack in 946 the mobile terminal, as well as in eNodeB and mobile gateways (SGW, 947 PGW). The following paragraphs describe per-layer considerations of 948 supporting tunneling of ICN packet into IP or to support ICN 949 natively. 951 1. An existing application layer can be modified to provide options 952 for a new ICN-based application and existing IP-based 953 applications. The mobile terminal can continue to support 954 existing IP-based applications or can develop new applications to 955 support native ICN, ICNoIP, or IPoICN-based transport. The 956 application layer can be provided with an option of selecting 957 either ICN or IP transport, as well as radio interface, to send 958 and receive data traffic. 960 Our proposal is to provide an Application Programming Interface 961 (API) to the application developers so they can choose either ICN 962 or IP transport for exchanging the traffic with the network. As 963 mentioned in Section 5.2, the transport convergence layer (TCL) 964 function handles the interaction of applications with multiple 965 transport options. 967 2. The transport convergence layer helps determine the type of 968 transport (such as ICN, hICN, or IP) and type of radio interface 969 (LTE or WiFi, or both) used to send and receive traffic. 970 Application layer can make the decision to select a specific 971 transport based on preference, such as content location, content 972 type, content publisher, congestion, cost, QoS, and so on. There 973 can be an Application Programming Interface (API) to exchange 974 parameters required for transport selection. Southbound 975 interactions of Transport Convergence Layer (TCL) will be either 976 to IP or ICN at the network layer. 978 When selecting the IPoICN mode, the TCL is responsible for 979 receiving an incoming IP or HTTP packet and publishing the packet 980 to the ICN network under a suitable ICN name (that is, the hash 981 over the destination IP address for an IP packet, or the hash 982 over the FQDN of the HTTP request for an HTTP packet). 984 In the HTTP case, the TCL can maintain a pending request mapping 985 table to map returning responses to the originating HTTP request. 986 The common API will provide a 'connection' abstraction for this 987 HTTP mode of operation, returning the response over said 988 connection abstraction, akin to the TCP socket interface, while 989 implementing a reliable transport connection semantic over the 990 ICN from the mobile terminal to the receiving mobile terminal or 991 the PGW. If the HTTP protocol stack remains unchanged, therefore 992 utilizing the TCP protocol for transfer, the TCL operates in 993 local TCP termination mode, retrieving the HTTP packet through 994 said local termination. 996 +----------------+ +-----------------+ 997 | ICN App (new) | |IP App (existing)| 998 +---------+------+ +-------+---------+ 999 | | 1000 +---------+----------------+---------+ 1001 | Transport Convergence Layer (new) | 1002 +------+---------------------+-------+ 1003 | | 1004 +------+------+ +------+-------+ 1005 |ICN function | | IP function | 1006 | (New) | | (Existing) | 1007 +------+------+ +------+-------+ 1008 | | 1009 +------+---------------------+-------+ 1010 | PDCP (updated to support ICN) | 1011 +-----------------+------------------+ 1012 | 1013 +-----------------+------------------+ 1014 | RLC (Existing) | 1015 +-----------------+------------------+ 1016 | 1017 +-----------------+------------------+ 1018 | MAC Layer (Existing) | 1019 +-----------------+------------------+ 1020 | 1021 +-----------------+------------------+ 1022 | Physical L1 (Existing) | 1023 +------------------------------------+ 1025 Figure 6: Dual Stack ICN Protocol Interactions 1027 3. The ICN function (forwarder) is proposed to run in parallel to 1028 the existing IP layer. The ICN forwarder forwards the ICN 1029 packets, such as an Interest packet to eNodeB or a response "data 1030 packet" from eNodeB to the application. 1032 4. For the dual-transport scenario, when mobile terminal is not 1033 supporting ICN as transport, the TCL can use the IP underlay to 1034 tunnel the ICN packets. The ICN function can use the IP 1035 interface to send Interest and Data packets for fetching or 1036 sending data respectively. This interface can use the ICN 1037 overlay over IP. 1039 5. To support ICN at network layer in mobile terminal, the PDCP 1040 layer should be aware of ICN capabilities and parameters. PDCP 1041 is located in the Radio Protocol Stack in the LTE Air interface, 1042 between IP (Network layer) and Radio Link Control Layer (RLC). 1043 PDCP performs the following functions [TS36.323]: 1045 1. Data transport by listening to upper layer, formatting and 1046 pushing down to Radio Link Layer (RLC) 1048 2. Header compression and decompression using Robust Header 1049 Compression (ROHC) 1051 3. Security protections such as ciphering, deciphering, and 1052 integrity protection 1054 4. Radio layer messages associated with sequencing, packet drop 1055 detection and re-transmission, and so on. 1057 6. No changes are required for lower layer such as RLC, MAC, and 1058 Physical (L1) as they are not IP aware. 1060 One key point to understand in this scenario is that ICN is deployed 1061 as an overlay on top of IP. 1063 5.4.2. Using ICN in Mobile Terminal 1065 We can implement ICN natively in mobile terminal by modifying the 1066 PDCP layer in 3GPP protocols. Figure 7 provides a high-level 1067 protocol stack description where ICN can be used at the following 1068 different layers: 1070 1. User plane communication 1072 2. Transport layer 1074 ICN transport would be a substitute of the GTP protocol. The removal 1075 of the GTP protocol stack is a significant change in the mobile 1076 architecture and requires a thorough study mainly because it is used 1077 not just for routing but for mobility management functions, such as 1078 billing, mediation, and policy enforcement. 1080 The implementation of ICN natively in the mobile terminal leads to a 1081 changed communication model between mobile terminal and eNodeB. 1082 Also, we can avoid tunneling the user plane traffic from eNodeB to 1083 the mobile packet core (SGW, PGW) through a GTP tunnel. 1085 For native ICN use, an application can be configured to use ICN 1086 forwarder and it does not need the TCL layer. Also, to support ICN 1087 at the network layer, the existing PDCP layer may need to be changed 1088 to be aware of ICN capabilities and parameters. 1090 The native implementation can provide new opportunities to develop 1091 new use cases leveraging ICN capabilities, such as seamless mobility, 1092 mobile terminal to mobile terminal content delivery using radio 1093 network without traversing the mobile gateways, and more. 1095 +--------+ +--------+ 1096 | App | | CDN | 1097 +--------+ +--------+ 1098 |Transp. | | | | | |Transp. | 1099 |Converge|.|..............|..............|..............|.|Converge| 1100 +--------+ | | | | +--------+ 1101 | |.|..............|..............|..............|.| | 1102 | ICN/IP | | | | | | | 1103 | | | | | | | | 1104 +--------+ | +----+-----+ | +----------+ | +----------+ | | ICN/IP | 1105 | |.|.| | | | | | | | | | | | 1106 | PDCP | | |PDCP| ICN |.|.| ICN |.|.| ICN |.|.| | 1107 +--------+ | +----+ | | | | | | | | | | 1108 | RLC |.|.|RLC | | | | | | | | | | | 1109 +--------+ | +----------+ | +----------+ | +----------+ | +--------+ 1110 | MAC |.|.| MAC| L2 |.|.| L2 |.|.| L2 |.|.| L2 | 1111 +--------+ | +----------+ | +----------+ | +----------+ | +--------+ 1112 | L1 |.|.| L1 | L1 |.|.| L1 |.|.| L1 |.|.| L1 | 1113 +--------+ | +----+-----+ | +----------+ | +----------+ | +--------+ 1114 MT | BS(eNodeB) | SGW | PGW | 1115 Uu S1u S5/S8 SGi 1117 Figure 7: Using Native ICN in Mobile Terminal 1119 5.4.3. Using ICN in eNodeB 1121 The eNodeB is a physical point of attachment for the mobile terminal, 1122 where radio protocols are converted into IP transport protocol for 1123 dual transport/overlay and native ICN, respectively (see Figure 6 and 1124 Figure 7). When a mobile terminal performs an attach procedure, it 1125 would be assigned an identity either as IP or dual transport (IP and 1126 ICN), or ICN endpoint. Mobile terminal can initiate data traffic 1127 using any of the following options: 1129 1. Native IP (IPv4 or IPv6) 1131 2. Native ICN 1132 3. Dual transport IP (IPv4/IPv6) and ICN 1134 The mobile terminal encapsulates a user data transport request into 1135 PDCP layer and sends the information on the air interface to eNodeB, 1136 which in turn receives the information and, using PDCP [TS36.323], 1137 de-encapsulates the air-interface messages and converts them to 1138 forward to core mobile gateways (SGW, PGW). As shown in Figure 8, to 1139 support ICN natively in eNodeB, it is proposed to provide transport 1140 convergence layer (TCL) capabilities in eNodeB (similar to as 1141 provided in MT), which provides the following functions: 1143 1. It decides the forwarding strategy for a user data request coming 1144 from mobile terminal. The strategy can decide based on 1145 preference indicated by the application, such as congestion, 1146 cost, QoS, and so on. 1148 2. eNodeB to provide open Application Programming Interface (API) to 1149 external management systems, to provide capability to eNodeB to 1150 program the forwarding strategies. 1152 +---------------+ | 1153 | MT request | | ICN +---------+ 1154 +---->| content using |--+--- transport -->| | 1155 | |ICN protocol | | | | 1156 | +---------------+ | | | 1157 | | | | 1158 | +---------------+ | | | 1159 +-+ | | MT request | | IP |To mobile| 1160 | |-+---->| content using |--+--- transport -->| GW | 1161 +-+ | | IP protocol | | |(SGW,PGW)| 1162 MT | +---------------+ | | | 1163 | | | | 1164 | +---------------+ | | | 1165 | | MT request | | Dual stack | | 1166 +---->| content using |--+--- IP+ICN -->| | 1167 |IP/ICN protocol| | transport +---------+ 1168 +---------------+ | 1169 eNodeB S1u 1171 Figure 8: Integration of Native ICN in eNodeB 1173 3. eNodeB can be upgraded to support three different types of 1174 transport: IP, ICN, and dual transport IP+ICN towards mobile 1175 gateways, as depicted in Figure 8. It is also proposed to deploy 1176 IP and/or ICN forwarding capabilities into eNodeB, for efficient 1177 transfer of data between eNodeB and mobile gateways. Following 1178 are choices for forwarding a data request towards mobile 1179 gateways: 1181 1. Assuming eNodeB is IP enabled and the MT requests an IP 1182 transfer, eNodeB forwards data over IP. 1184 2. Assuming eNodeB is ICN enabled and the MT requests an ICN 1185 transfer, eNodeB forwards data over ICN. 1187 3. Assuming eNodeB is IP enabled and the MT requests an ICN 1188 transfer, eNodeB overlays ICN on IP and forwards user plane 1189 traffic over IP. 1191 4. Assuming eNodeB is ICN enabled and the MT requests an IP 1192 transfer, eNodeB overlays IP on ICN and forwards user plane 1193 traffic over ICN [IPoICN]. 1195 5.4.4. Using ICN in Packet Core (SGW, PGW) Gateways 1197 Mobile gateways (a.k.a. Evolved Packet Core (EPC)) include SGW, PGW, 1198 which perform session management for MT from the initial attach to 1199 disconnection. When MT is powered on, it performs NAS signaling and 1200 attaches to PGW after successful authentication. PGW is an anchoring 1201 point for MT and responsible for service creations, authorization, 1202 maintenance, and so on. The Entire functionality is managed using IP 1203 address(es) for MT. 1205 To implement ICN in EPC, the following functions are proposed: 1207 1. Insert ICN attributes in session management layer as additional 1208 functionality with IP stack. Session management layer is used 1209 for performing attach procedures and assigning logical identity 1210 to user. After successful authentication by HSS, MME sends a 1211 create session request (CSR) to SGW and SGW to PGW. 1213 2. When MME sends Create Session Request message (Step 12 in 1214 [TS23.401]) to SGW or PGW, it includes a Protocol Configuration 1215 Option Information Element (PCO IE) containing MT capabilities. 1216 We can use PCO IE to carry ICN-related capabilities information 1217 from MT to PGW. This information is received from MT during the 1218 initial attach request in MME. Details of available TLV, which 1219 can be used for ICN, are given in subsequent sections. MT can 1220 support either native IP, ICN+IP, or native ICN. IP is referred 1221 to as both IPv4 and IPv6 protocols. 1223 3. For ICN+IP-capable MT, PGW assigns the MT both an IP address and 1224 ICN identity. MT selects either of the identities during the 1225 initial attach procedures and registers with the network for 1226 session management. For ICN-capable MT, it will provide only ICN 1227 attachment. For native IP-capable MT, there is no change. 1229 4. To support ICN-capable attach procedures and use ICN for user 1230 plane traffic, PGW needs to have full ICN protocol stack 1231 functionalities. Typical ICN capabilities include functions such 1232 as content store (CS), Pending Interest Table (PIT), Forwarding 1233 Information Base (FIB) capabilities, and so on. If MT requests 1234 ICN in PCO IE, then PGW registers MT with ICN names. For ICN 1235 forwarding, PGW caches content locally using CS functionality. 1237 5. PCO IE described in [TS24.008] (see Figure 10.5.136 on page 598) 1238 and [TS24.008] (see Table 10.5.154 on page 599) provide details 1239 for different fields. 1241 1. Octet 3 (configuration protocols define PDN types), which 1242 contains details about IPv4, IPv6, both or ICN. 1244 2. Any combination of Octet 4 to Z can be used to provide 1245 additional information related to ICN capability. It is most 1246 important that PCO IE parameters are matched between MT and 1247 mobile gateways (SGW, PGW) so they can be interpreted 1248 properly and the MT can attach successfully. 1250 6. The ICN functionalities in SGW and PGW should be matched with MT 1251 and eNodeB because they will exchange ICN protocols and 1252 parameters. 1254 7. Mobile gateways SGW, PGW will also need ICN forwarding and 1255 caching capability. This is especially important if CUPS is 1256 implemented. User Plane Function (UPF), comprising the SGW and 1257 PGW user plane, will be located at the edge of the network and 1258 close to the end user. ICN-enabled gateway means that this UPF 1259 would serve as a forwarder and should be capable of caching, as 1260 is the case with any other ICN-enabled node. 1262 8. The transport between PGW and CDN provider can be either IP or 1263 ICN. When MT is attached to PGW with ICN identity and 1264 communicates with an ICN-enabled CDN provider, it will use ICN 1265 primitives to fetch the data. On the other hand, for a MT 1266 attached with an ICN identity, if PGW must communicate with an IP 1267 enabled CDN provider, it will have to use an ICN-IP interworking 1268 gateway to perform conversion between ICN and IP primitives for 1269 data retrieval. In the case of CUPS implementation with an 1270 offload close to the edge, this interworking gateway can be 1271 collocated with the UPF at the offload site to maximize the path 1272 optimization. Further study is required to understand how this 1273 ICN-to-IP (and vice versa) interworking gateway would function. 1275 5.5. An Experimental Test Setup 1277 This section proposes an experimental lab setup and discusses the 1278 open issues and questions that use of ICN protocol is intended to 1279 address. To further test the modifications proposed in different 1280 scenarios, a simple lab can be set up, as shown in Figure 9. 1282 +------------------------------------------+ 1283 | +-----+ +------+ (```). +------+ | (````). +-----+ 1284 | | SUB |-->| EMU |--(x-haul'.-->| EPC |--->( PDN ).-->| CDN | 1285 | +-----+ +------+ `__..'' +------+ | `__...' +-----+ 1286 +------------------------------------------+ 1287 4G Mobile Network Functions 1289 Figure 9: Native ICN Deployment Lab Setup 1291 The following test scenarios can be set up with VM-based deployment: 1293 1. SUB: ICN simulated client (using ndnSIM), a client application on 1294 workstation requesting content. 1296 2. EMU: test unit emulating eNodeB. This will be a test node 1297 allowing for UE attachment and routing traffic subsequently from 1298 the Subscriber to the Publisher. 1300 3. EPC: Evolved Packet Core in a single instance (such as 5GOpenCore 1301 [Open5GCore]). 1303 4. CDN: content delivery by a Publisher server. 1305 For the purpose of this testing, ICN emulating code can be inserted 1306 in the test code in EMU to emulate ICN-capable eNodeB. An example of 1307 the code to be used is NS3 in its LTE model. Effect of such traffic 1308 on EPC and CDN can be observed and documented. In a subsequent 1309 phase, EPC code supporting ICN can be tested when available. 1311 Another option is to simulate the UE/eNodeB and EPC functions using 1312 NS3's LTE [NS3LTE] and EPC [NS3EPC] models respectively. LTE model 1313 includes the LTE Radio Protocol stack, which resides entirely within 1314 the UE and the eNodeB nodes. This capability provides the simulation 1315 of UE and eNodeB deployment use cases. Similarly, EPC model includes 1316 core network interfaces, protocols, and entities, which reside within 1317 the SGW, PGW and MME nodes, and partially within the eNodeB nodes. 1319 Even with its current limitations (such as IPv4 only, lack of 1320 integration with ndnSIM, no support for UE idle state), LTE 1321 simulation may be a very useful tool. In any case, both control and 1322 user plane traffic should be tested independently according to the 1323 deployment model discussed in Section 5.4. 1325 6. Expected Outcomes from Experimentation 1327 The experimentations explained in Section 5 can be categorized in 1328 three broader scopes as follows. Note that, a further research and 1329 study is required to fully understand and document the impact. 1331 1. Architecture scope: to study the aspect of use of ICN at user 1332 plane to reduce the complexities in current transport protocols, 1333 while also evaluating its use in the control plane. 1335 2. Performance scope: to evaluate the gains through multicast, 1336 caching, and other ICN features. 1338 3. Deployment scope: to check the viability of the ICN inclusion in 1339 3GPP protocol stack and its viability in real-world deployments. 1341 6.1. Feeding into ICN Research 1343 Specifically, we have identified the following open questions, from 1344 the architectural and performance perspective, that the proposed 1345 experiments with ICN implementation scenarios in 4G mobile networks 1346 could address in further research: 1348 1. Efficiency gains in terms of the amount of traffic in multicast 1349 scenarios (i.e., quantify the possible gains along different use 1350 cases) and the efficiency gained in terms of latency for cached 1351 content, mainly in the CDN use case. 1353 2. How the new transport would coexist or replace the legacy 1354 transport protocols (e.g., IPv4, IPv6, MPLS, RSVP, etc.) and 1355 related services (e.g., bandwidth management, QoS handling, 1356 etc.). 1358 3. To what extent the simplification in the IP-based transport 1359 protocols will be achieved. The multiple overlays (e.g., the 1360 MPLS, VPN, VPLS, Ethernet VPN, etc.) of services in the current 1361 IP-based transport adds to the complexity on top of basic IP 1362 transport. This makes the troubleshooting extremely challenging. 1364 4. How the new transport can become service-aware such that it 1365 brings in more simplicity in the system. 1367 5. Confirm how (in)adequate would be ICN implementation in control 1368 plane (which this draft discourages). Given that the 5G system, 1369 as specified in [TS23.501] (Appendix G.4), encourages the use of 1370 name-based routing in (5G) control plane for realizing the 5G- 1371 specific service-based architecture for control plane services 1372 (so-called network function service), it would be worthwhile to 1373 investigate whether the 4G control plane would benefit similarly 1374 from such use or whether specific 4G architectural constraints 1375 would prevent ICN from providing any notable benefit. 1377 6.2. Use of Results Beyond Research 1379 With the experiments and their outcomes outlined in this draft, we 1380 believe that this technology is ready for a wider use and adoption, 1381 providing additional insights. Specifically, we expect to study the 1382 following: 1384 1. Viability of ICN inclusion in the 3GPP protocol stack, i.e., 1385 investigate how realistic it would be to modify the stack, 1386 considering the scenarios explained in Section 5.4, and complete 1387 the user session without feature degradation? 1389 2. Viability of utilizing solutions in greenfield deployments, i.e., 1390 deploying the ICN-based extensions and solutions proposed in this 1391 draft in greenfield 4G deployments in order to assess real-world 1392 benefits when doing so. 1394 7. Security and Privacy Considerations 1396 This section will cover some security and privacy considerations in 1397 mobile and 4G network because of introduction of ICN. 1399 7.1. Security Considerations 1401 To ensure only authenticated mobile terminals are connected to the 1402 network, 4G mobile network implements various security mechanisms. 1403 From the perspective of using ICN in the user plane, it needs to take 1404 care of the following security aspects: 1406 1. MT authentication and authorization 1408 2. Radio or air interface security 1410 3. Denial of service attacks on the mobile gateway, services either 1411 by the MT or by external entities in the Internet 1413 4. Content poisoning either in transport or servers 1415 5. Content cache pollution attacks 1417 6. Secure naming, routing, and forwarding 1419 7. Application security 1421 Security over the LTE air interface is provided through cryptographic 1422 techniques. When MT is powered up, it performs a key exchange 1423 between MT's USIM and HSS/Authentication Center using NAS messages, 1424 including ciphering and integrity protections between MT and MME. 1425 Details for secure MT authentication, key exchange, ciphering, and 1426 integrity protections messages are given in the 3GPP call flow 1427 [TS23.401]. With ICN we are modifying protocol stack for user plane 1428 and not control plane. The NAS signaling is exchanged between MT and 1429 mobile gateways e.g. MME, using control plane, therefore there is no 1430 adverse impact of ICN on MT. 1432 4G uses IP transport in its mobile backhaul (between eNodeB and core 1433 network). In case of provider-owned backhaul, service provider may 1434 require implementing a security mechanism in the backhaul network. 1435 The native IP transport continues to leverage security mechanism such 1436 as Internet key exchange (IKE) and the IP security protocol (IPsec). 1437 More details of mobile backhaul security are provided in 3GPP network 1438 security specifications [TS33.310] and [TS33.320]. When mobile 1439 backhaul is upgraded to support dual transport (IP+ICN) or native 1440 ICN, it is required to implement security techniques that are 1441 deployed in the mobile backhaul. When ICN forwarding is enabled on 1442 mobile transport routers, we need to deploy security practices based 1443 on [RFC7476] and [RFC7927]. 1445 4G mobile gateways (SGW, PGW) perform some of key functions such as 1446 content based online/offline billing and accounting, deep packet 1447 inspection (DPI), and lawful interception (LI). When ICN is deployed 1448 in user plane , we need to integrate ICN security for sessions 1449 between MT and gateway. If we encrypt user plane payload metadata 1450 then it might be difficult to perform routing based on contents and 1451 it may not work because we need decryption keys at every forwarder to 1452 route the content. The content itself can be encrypted between 1453 publisher and consumer to ensure privacy. Only the user with right 1454 decryption key shall be able to access the content. We need further 1455 research for ICN impact on LI, online/offline charging and 1456 accounting. 1458 7.2. Privacy Considerations 1460 In 4G networks, two main privacy issues are [MUTHANA] 1462 1. User Identity Privacy Issues. The main privacy issue within the 1463 4G is the exposure of the IMSI. The IMSI can be intercepted by 1464 adversaries. Such attacks are commonly referred to as "IMSI 1465 catching". 1467 2. Location Privacy Issues. IMSI Catching is closely related to the 1468 issue of location privacy. Knowing IMSI of user allows the 1469 attacker to track the user's movements and create profile about 1470 the user and thus breaches the user's location privacy. 1472 In any network, caching implies a trade-off between network 1473 efficiency and privacy. The activity of users is exposed to the 1474 scrutiny of cache owners with whom they may not have any 1475 relationship. By monitoring the cache transactions, an attacker 1476 could obtain significant information related to the objects accessed, 1477 topology and timing of the requests [RFC7945]. Privacy concerns are 1478 amplified by the introduction of new network functions such as 1479 Information lookup and Network storage, and different forms of 1480 communication [FOTIOU]. Privacy risks in ICN can be broadly divided 1481 in the following categories [TOURANI]: 1483 1. Timing attack 1485 2. Communication monitoring attack 1487 3. Censorship and anonymity attack 1489 4. Protocol attack 1491 5. Naming-signature privacy 1492 Introduction of TCL effectively enables ICN at the application and/or 1493 transport layer, depending on the scenario described in section 5. 1494 Enabling ICN in 4G networks is expected to increase efficiency by 1495 taking advantage of ICN's inherent characteristics. This approach 1496 would potentially leave some of the above-mentioned privacy concerns 1497 open as a consequence of using ICN transport and ICN inherent privacy 1498 vulnerabilities. 1500 1. IPoIP Section 5.2 would not be affected as TCL has no role in it 1501 and ICN does not apply 1503 2. ICNoICN scenario Section 5.2 has increased risk of a privacy 1504 attack, and that risk is applicable to ICN protocol in general 1505 rather than specifically to the 4G implementation. Since this 1506 scenario describes communication over ICN transport, every 1507 forwarder in the path could be a potential risk for privacy 1508 attack 1510 3. ICNoIP scenario Section 5.2 uses IP for transport, so the only 1511 additional ICN-related potential privacy risk areas are the 1512 endpoints (consumer and publisher) where, at the application 1513 layer, content is being served 1515 4. IPoICN scenario Section 5.2 could have potentially increased risk 1516 due to possible vulnerability of the forwarders in the path of 1517 ICN transport 1519 Privacy issues already identified in 4G remain a concern if ICN is 1520 introduced in any of the scenarios described earlier and compound to 1521 the new, ICN-related privacy issues. Many research papers have been 1522 published proposing solutions to the privacy issues listed above. 1523 For LTE-specific privacy issues, some of the proposed solutions 1524 [MUTHANA] are IMSI encryption by a MT, mutual authentication, 1525 concealing the real IMSI within a random bit stream of certain size 1526 where only the subscriber and HSS could extract the respective IMSI, 1527 IMSI replacement with a changing pseudonym that only the HSS server 1528 can map it the UE's IMSI, and others. Similarly, some of the 1529 proposed ICN-specific privacy concerns mitigation methods, applicable 1530 where ICN transport is introduced as specified earlier in this 1531 section, include [FOTIOU]: 1533 * Delay for the first, or first k interests on edge routers (timing 1534 attack) 1536 * Creating a secure tunnel or clients flagging the requests as non- 1537 cacheable for privacy (communication monitoring attack) 1539 * Encoding interest by mixing content and cover file or using 1540 hierarchical DNS-based brokering model (censorship and anonymity 1541 attack) 1543 * Use of rate-limiting requests for a specific namespace (protocol 1544 attack) 1546 * Cryptographic content hash-based naming or digital identity in an 1547 overlay network (naming-signature privacy) 1549 Further research in this area is needed. Detailed discussion of 1550 privacy is beyond the scope of this document. 1552 8. Summary 1554 In this draft, we have discussed the 4G networks and the experimental 1555 setups to study the advantages of potential use of ICN for efficient 1556 delivery of contents to mobile terminals. We have discussed 1557 different options to try and test the ICN and dependencies such as 1558 ICN functionalities and changes required in different 4G network 1559 elements. In order to further explore potential use of ICN one can 1560 devise an experimental set-up consisting of 4G network elements and 1561 deploy ICN data transport in user plane. Different options can be 1562 either overlay, dual transport (IP + ICN), hICN, or natively (by 1563 integrating ICN with CDN, eNodeB, SGW, PGW and transport network). 1564 Note that, for the scenarios discussed above, additional study is 1565 required for lawful interception, billing/mediation, network slicing, 1566 and provisioning APIs. 1568 Edge Computing [CHENG] provides capabilities to deploy 1569 functionalities such as Content Delivery Network (CDN) caching and 1570 mobile user plane functions (UPF) [TS23.501]. Recent research for 1571 delivering real-time video content [MPVCICN] using ICN has also been 1572 proven to be efficient [NDNRTC] and can be used towards realizing the 1573 benefits of using ICN in eNodeB, edge computing, mobile gateways 1574 (SGW, PGW) and CDN. The key aspect for ICN is in its seamless 1575 integration in 4G and 5G networks with tangible benefits so we can 1576 optimize content delivery using a simple and scalable architecture. 1577 The authors will continue to explore how ICN forwarding in edge 1578 computing could be used for efficient data delivery from the mobile 1579 edge. 1581 Based on our study of control plane signaling, it is not beneficial 1582 to deploy ICN with existing protocols unless further changes are 1583 introduced in the control protocol stack itself. 1585 As a starting step towards use of ICN in user plane, it is proposed 1586 to incorporate protocol changes in MT, eNodeB, SGW/PGW for data 1587 transport. ICN has inherent capabilities for mobility and content 1588 caching, which can improve the efficiency of data transport for 1589 unicast and multicast delivery. The authors welcome contributions 1590 and suggestions, including those related to further validations of 1591 the principles by implementing prototype and/or proof of concept in 1592 the lab and in the production environment. 1594 9. Acknowledgements 1596 We thank all contributors, reviewers, and the chairs for the valuable 1597 time in providing comments and feedback that helped improve this 1598 draft. We specially want to mention the following members of the 1599 IRTF Information-Centric Networking Research Group (ICNRG), listed in 1600 alphabetical order: Kashif Islam, Thomas Jagodits, Luca Muscariello, 1601 David R. Oran, Akbar Rahman, Martin J. Reed, Thomas C. Schmidt, 1602 and Randy Zhang. 1604 The IRSG review was provided by Colin Perkins. 1606 10. References 1608 10.1. Normative References 1610 [TS24.008] 3GPP, "Mobile radio interface Layer 3 specification; Core 1611 network protocols; Stage 3", 3GPP TS 24.008 3.20.0, 15 1612 December 2005, 1613 . 1615 [TS25.323] 3GPP, "Packet Data Convergence Protocol (PDCP) 1616 specification", 3GPP TS 25.323 3.10.0, 18 September 2002, 1617 . 1619 [TS29.274] 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 1620 Packet Radio Service (GPRS) Tunneling Protocol for Control 1621 plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0, 25 June 1622 2013, . 1624 [TS29.281] 3GPP, "General Packet Radio System (GPRS) Tunneling 1625 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, 26 1626 September 2011, 1627 . 1629 [TS36.323] 3GPP, "Evolved Universal Terrestrial Radio Access 1630 (E-UTRA); Packet Data Convergence Protocol (PDCP) 1631 specification", 3GPP TS 36.323 10.2.0, 3 January 2013, 1632 . 1634 10.2. Informative References 1636 [ALM] Augé, J., Carofiglio, G., Grassi, G., Muscariello, L., 1637 Pau, G., and X. Zeng, "Anchor-Less Producer Mobility in 1638 ICN", Proceedings of the 2Nd ACM Conference on 1639 Information-Centric Networking, ACM-ICN'15, ACM DL, 1640 pp.189-190, 30 September 2013, 1641 . 1643 [BROWER] Brower, E., Jeffress, L., Pezeshki, J., Jasani, R., and E. 1644 Ertekin, "Integrating Header Compression with IPsec", 1645 MILCOM 2006 - 2006 IEEE Military Communications 1646 conference IEEE Xplore DL, pp.1-6, 23 October 2006, 1647 . 1649 [CCN] "Content Centric Networking", . 1651 [CHENG] Liang, C., Yu, R., and X. Zhang, "Information-centric 1652 network function virtualization over 5g mobile wireless 1653 networks", IEEE Network Journal vol. 29, number 3, pp. 1654 68-74, 1 June 2015, 1655 . 1657 [EMBMS] Zahoor, K., Bilal, K., Erbad, A., and A. Mohamed, 1658 "Service-Less Video Multicast in 5G: Enablers and 1659 Challenges", IEEE Network vol. 34, no. 3, pp. 270-276, May 1660 2020, . 1662 [EPCCUPS] Schmitt, P., Landais, B., and F. Yong Yang, "Control and 1663 User Plane Separation of EPC nodes (CUPS)", 3GPP The 1664 Mobile Broadband Standard, 3 July 2017, 1665 . 1667 [FOTIOU] Fotiou, N. and G. Polyzos, "ICN privacy and name based 1668 security", ACM-ICN '14: Proceedings of the 1st ACM 1669 Conference on Information-Centric Networking ACM Digitial 1670 Library, pp. 5-6, September 2014, 1671 . 1673 [GALIS] Galis, A., Makhijani, K., Yu, D., and B. Liu, "Autonomic 1674 Slice Networking", Work in Progress, Internet-Draft, 1675 draft-galis-anima-autonomic-slice-networking-05, 26 1676 September 2018, . 1679 [GRAYSON] Grayson, M., Shatzkamer, M., and S. Wainner, "Cisco Press 1680 book "IP Design for Mobile Networks"", Cisco 1681 Press Networking Technology series, 15 June 2009, 1682 . 1685 [HICN] Muscariello, L., Carofiglio, G., Auge, J., and M. 1686 Papalini, "Hybrid Information-Centric Networking", Work in 1687 Progress, Internet-Draft, draft-muscariello-intarea-hicn- 1688 04, 20 May 2020, . 1691 [I-D.anilj-icnrg-dnc-qos-icn] 1692 Jangam, A., suthar, P., and M. Stolic, "QoS Treatments in 1693 ICN using Disaggregated Name Components", Work in 1694 Progress, Internet-Draft, draft-anilj-icnrg-dnc-qos-icn- 1695 02, 9 March 2020, . 1698 [ICN5G] Ravindran, R., suthar, P., Trossen, D., and G. White, 1699 "Enabling ICN in 3GPP's 5G NextGen Core Architecture", 1700 Work in Progress, Internet-Draft, draft-ravi-icnrg-5gc- 1701 icn-04, 10 January 2021, 1702 . 1704 [ICNLOWPAN] 1705 Gundogan, C., Schmidt, T., Waehlisch, M., Scherb, C., 1706 Marxer, C., and C. Tschudin, "ICN Adaptation to LowPAN 1707 Networks (ICN LoWPAN)", Work in Progress, Internet-Draft, 1708 draft-irtf-icnrg-icnlowpan-10, 10 February 2021, 1709 . 1712 [ICNQoS] Al-Naday, M.F., Bontozoglou, A., Vassilakis, G., and M. J. 1713 Reed, "Quality of Service in an Information-Centric 1714 Network", 2014 IEEE Global Communications Conference IEEE 1715 Xplore DL, pp. 1861-1866, 8 December 2014, 1716 . 1718 [IPoICN] Trossen, D., Read, M J., Riihijarvi, J., Georgiades, M., 1719 Fotiou, N., and G. Xylomenos, "IP over ICN - The better 1720 IP?", 2015 European Conference on Networks and 1721 Communications (EuCNC) IEEE Xplore DL, pp. 413-417, 29 1722 June 2015, . 1724 [MBICN] Carofiglio, G., Gallo, M., Muscariello, L., and D. Perino, 1725 "Scalable mobile backhauling via information-centric 1726 networking", The 21st IEEE International Workshop on Local 1727 and Metropolitan Area Networks, Beijing, pp. 1-6, 22 April 1728 2015, . 1730 [MECSPEC] "Mobile Edge Computing (MEC); Framework and Reference 1731 Architecture", ETSI European Telecommunication Standards 1732 Institute (ETSI) MEC specification, March 2016, 1733 . 1736 [MPVCICN] Jangam, A., Ravindran, R., Chakraborti, A., Wan, X., and 1737 G. Wang, "Realtime multi-party video conferencing service 1738 over information centric network", IEEE International 1739 Conference on Multimedia and Expo Workshops (ICMEW) Turin, 1740 Italy, pp. 1-6, 29 June 2015, 1741 . 1743 [MUTHANA] Muthana, A. and M. Saeed, "Analysis of User Identity 1744 Privacy in LTE and Proposed Solution", International 1745 Journal of Computer Network and Information 1746 Security(IJCNIS) MECS Press, pp. 54-63, January 2017, 1747 . 1750 [NDNRTC] Gusev, P., Wang, Z., Burke, J., Zhang, L., Yoneda, T., 1751 Ohnishi, R., and E. Muramoto, "Real-time Streaming Data 1752 Delivery over Named Data Networking,", IEICE Transactions 1753 on Communications vol. E99.B, pp. 974-991, 1 May 2016, 1754 . 1756 [NGMN] Robson, J., "Backhaul Provisioning for LTE-Advanced and 1757 Small Cells", Next Generation Mobile Networks, LTE- 1758 Advanced Transport Provisioning, V0.0.14, 20 October 2015, 1759 . 1763 [NS3EPC] Baldo, N., "The ns-3 EPC module", NS3 EPC Model, 1764 . 1767 [NS3LTE] Baldo, N., "The ns-3 LTE module", NS3 LTE Model, 1768 . 1771 [OFFLOAD] Rebecchi, F., Dias de Amorim, M., Conan, V., Passarella, 1772 A., Bruno, R., and M. Conti, "Data Offloading Techniques 1773 in Cellular Networks: A Survey", IEEE Communications 1774 Surveys and Tutorials, IEEE Xplore DL, vol:17, issue:2, 1775 pp.580-603, 11 November 2014, 1776 . 1778 [OLTEANU] Olteanu, A. and P. Xiao, "Fragmentation and AES Encryption 1779 Overhead in Very High-speed Wireless LANs", Proceedings of 1780 the 2009 IEEE International Conference on Communications 1781 ICC'09, ACM DL, pp.575-579, 14 June 2009, 1782 . 1784 [Open5GCore] 1785 Open5GCore, M., "Open5GCore - Fundamental 4G Core Network 1786 Functionality", Open5GCore, . 1788 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 1789 Guidelines for DiffServ Service Classes", RFC 4594, 1790 DOI 10.17487/RFC4594, August 2006, 1791 . 1793 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 1794 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 1795 Partnership Project (3GPP) Evolved Packet System (EPS)", 1796 RFC 6459, DOI 10.17487/RFC6459, January 2012, 1797 . 1799 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 1800 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 1801 "Information-Centric Networking: Baseline Scenarios", 1802 RFC 7476, DOI 10.17487/RFC7476, March 2015, 1803 . 1805 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 1806 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 1807 "Information-Centric Networking (ICN) Research 1808 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 1809 . 1811 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 1812 and G. Boggia, "Information-Centric Networking: Evaluation 1813 and Security Considerations", RFC 7945, 1814 DOI 10.17487/RFC7945, September 2016, 1815 . 1817 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 1818 Networking (CCNx) Semantics", RFC 8569, 1819 DOI 10.17487/RFC8569, July 2019, 1820 . 1822 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 1823 Networking (CCNx) Messages in TLV Format", RFC 8609, 1824 DOI 10.17487/RFC8609, July 2019, 1825 . 1827 [RFC9064] Oran, D., "Considerations in the Development of a QoS 1828 Architecture for CCNx-Like Information-Centric Networking 1829 Protocols", RFC 9064, DOI 10.17487/RFC9064, June 2021, 1830 . 1832 [SDN5G] Page, J. and J. Dricot, "Software-defined networking for 1833 low-latency 5G core network", 2016 International 1834 Conference on Military Communications and Information 1835 Systems (ICMCIS) IEEE Xplore DL, pp. 1-7, May 2016, 1836 . 1838 [TLVCOMP] Mosko, M., "Header Compression for TLV-based Packets", 1839 ICNRG Buenos Aires IETF 95, 3 April 2016, 1840 . 1843 [TOURANI] Tourani, R., Misra, S., Mick, T., and G. Panwar, 1844 "Security, Privacy, and Access Control in Information- 1845 Centric Networking: A Survey", IEEE Communications Surveys 1846 and Tutorials Volume 20, Issue 1, pp 566-600, September 1847 2017, . 1849 [TS23.203] 3GPP, "Policy and charging control architecture", 3GPP 1850 TS 23.203 10.9.0, 12 September 2013, 1851 . 1853 [TS23.401] 3GPP, "General Packet Radio Service (GPRS) enhancements 1854 for Evolved Universal Terrestrial Radio Access Network 1855 (E-UTRAN) access", 3GPP TS 23.401 10.10.0, 7 March 2013, 1856 . 1858 [TS23.501] 3GPP, "System Architecture for the 5G System", 3GPP 1859 TS 23.501 15.2.0, 15 June 2018, 1860 . 1862 [TS23.714] 3GPP, "Technical Specification Group Services and System 1863 Aspects: Study on control and user plane separation of EPC 1864 nodes", 3GPP TS 23.714 0.2.2, 4 June 2016, 1865 . 1867 [TS29.060] 3GPP, "General Packet Radio Service (GPRS); GPRS Tunneling 1868 Protocol (GTP) across the Gn and Gp interface", 3GPP 1869 TS 29.060 3.19.0, 24 March 2004, 1870 . 1872 [TS33.310] 3GPP, "Network Domain Security (NDS); Authentication 1873 Framework (AF)", 3GPP TS 33.310 10.7.0, 21 December 2012, 1874 . 1876 [TS33.320] 3GPP, "Security of Home Node B (HNB) / Home evolved Node B 1877 (HeNB)", 3GPP TS 33.320 10.5.0, 29 June 2012, 1878 . 1880 Authors' Addresses 1882 Prakash Suthar 1883 Google Inc. 1884 Mountain View, California 94043 1885 United States of America 1886 Email: psuthar@google.com 1888 Milan Stolic 1889 Cisco Systems Inc. 1890 Naperville, Illinois 60540 1891 United States of America 1892 Email: mistolic@cisco.com 1894 Anil Jangam (editor) 1895 Cisco Systems Inc. 1896 San Jose, California 95134 1897 United States of America 1898 Email: anjangam@cisco.com 1900 Dirk Trossen 1901 Huawei Technologies 1902 Riesstrasse 25 1903 80992 Munich 1904 Germany 1905 Email: dirk.trossen@huawei.com 1906 Ravi Ravindran 1907 F5 Networks 1908 3545 North First Street 1909 San Jose, 95134 1910 United States of America 1911 Email: r.ravindran@f5.com