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