idnits 2.17.1 draft-irtf-icnrg-icn-lte-4g-05.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.) ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 04, 2019) is 1635 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-muscariello-intarea-hicn-01 == Outdated reference: A later version (-04) exists of draft-ravi-icnrg-5gc-icn-02 == Outdated reference: A later version (-11) exists of draft-irtf-icnrg-icnlowpan-02 Summary: 2 errors (**), 0 flaws (~~), 5 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 Milan Stolic 4 Intended status: Informational Anil Jangam, Ed. 5 Expires: May 7, 2020 Cisco Systems Inc. 6 Dirk Trossen 7 InterDigital Inc. 8 Ravishankar Ravindran 9 Huawei Technologies 10 November 04, 2019 12 Native Deployment of ICN in LTE, 4G Mobile Networks 13 draft-irtf-icnrg-icn-lte-4g-05 15 Abstract 17 LTE, 4G mobile networks use IP-based transport for control plane to 18 establish the data session and user plane for actual data delivery. 19 In existing architecture, IP transport used in the user plane is not 20 optimized for data transport, which leads to an inefficient data 21 delivery. IP unicast routing from server to clients is used for 22 delivery of multimedia content to User Equipment (UE), where each 23 user gets a separate stream. From a bandwidth and routing 24 perspective, this approach is inefficient. Multicast and broadcast 25 technologies have emerged recently for mobile networks, but their 26 deployments are very limited or at an experimental stage due to 27 complex architecture and radio spectrum issues. ICN is a rapidly 28 emerging technology with built-in features for efficient multimedia 29 data delivery. However much of the work is focused on fixed 30 networks. The focus of this draft is on native deployment of ICN in 31 cellular mobile networks by using ICN in a 3GPP protocol stack. ICN 32 has an inherent capability for multicast, anchorless mobility and 33 security, and it is optimized for data delivery using local caching 34 at the edge. The proposed approaches in this draft allow ICN to be 35 enabled natively over the current LTE stack comprising PDCP/RLC/MAC/ 36 PHY, or in a dual stack mode (along with IP). These approaches can 37 help optimize the mobile networks by leveraging the inherent benefits 38 of ICN. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on May 7, 2020. 57 Copyright Notice 59 Copyright (c) 2019 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 76 1.2. 3GPP Terminology and Concepts . . . . . . . . . . . . . . 3 77 2. LTE, 4G Mobile Network . . . . . . . . . . . . . . . . . . . 7 78 2.1. Network Overview . . . . . . . . . . . . . . . . . . . . 7 79 2.2. QoS Challenges . . . . . . . . . . . . . . . . . . . . . 9 80 2.3. Data Transport Using IP . . . . . . . . . . . . . . . . . 10 81 2.4. Virtualizing Mobile Networks . . . . . . . . . . . . . . 10 82 3. Data Transport Using ICN . . . . . . . . . . . . . . . . . . 11 83 4. ICN Deployment in 4G and LTE Networks . . . . . . . . . . . . 14 84 4.1. General ICN Deployment Considerations . . . . . . . . . . 14 85 4.2. ICN Deployment Scenarios . . . . . . . . . . . . . . . . 14 86 4.3. ICN Deployment in LTE Control Plane . . . . . . . . . . . 18 87 4.4. ICN Deployment in LTE User Plane . . . . . . . . . . . . 19 88 4.4.1. Dual stack ICN deployments in UE . . . . . . . . . . 20 89 4.4.2. Native ICN Deployments in UE . . . . . . . . . . . . 24 90 4.5. ICN Deployment in eNodeB . . . . . . . . . . . . . . . . 25 91 4.6. ICN Deployment in Packet Core (SGW, PGW) Gateways . . . . 27 92 4.7. Lab Testing . . . . . . . . . . . . . . . . . . . . . . . 29 93 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 94 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 95 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 97 8.1. Normative References . . . . . . . . . . . . . . . . . . 32 98 8.2. Informative References . . . . . . . . . . . . . . . . . 33 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 101 1. Introduction 103 LTE mobile technology is built as an all-IP network. It uses IP 104 routing protocols (OSPF, ISIS, BGP, etc.) to establish network routes 105 to route data traffic to the end user's device. Stickiness of an IP 106 address to a device is the key to get connected to a mobile network. 107 The same IP address is maintained through the session until the 108 device gets detached or moves to another network. 110 One of the key protocols used in 4G and LTE networks is GPRS 111 Tunneling protocol (GTP). GTP, DIAMETER and other protocols are 112 built on top of IP. One of the biggest challenges with IP-based 113 routing is that it is not optimized for data transport, although it 114 is the most efficient communication protocol. By native 115 implementation of Information Centric Networking (ICN) in 3GPP, we 116 can re-architect a mobile network and optimize its design for 117 efficient data transport by leveraging ICN's caching feature. ICN 118 also offers an opportunity to leverage inherent capabilities of 119 multicast, anchorless mobility management, and authentication. This 120 draft provides insight into options for deploying ICN in mobile 121 networks, and how they affect mobile providers and end users. 123 1.1. Conventions and Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 1.2. 3GPP Terminology and Concepts 131 1. Access Point Name 133 The Access Point Name (APN) is a Fully Qualified Domain Name 134 (FQDN) and resolves to a set of gateways in an operator's 135 network. APN identifies the packet data network (PDN) with 136 which a mobile data user wants to communicate. In addition to 137 identifying a PDN, an APN may also be used to define the type of 138 service, QoS, and other logical entities inside GGSN, PGW. 140 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 UE and establish a mobility session 146 with mobile gateways (SGW/PGW). Control plane functions also 147 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 188 The GPRS Tunneling Protocol (GTP) [TS29.060] [TS29.274] 189 [TS29.281] is a tunneling protocol defined by 3GPP. It is a 190 network-based mobility protocol and is like Proxy Mobile IPv6 191 (PMIPv6). However, GTP also provides functionality beyond 192 mobility, such as in-band signaling related to QoS and charging, 193 among others. 195 9. Gateway GPRS Support Node 197 The Gateway GPRS Support Node (GGSN) is a gateway function in 198 the GPRS and 3G network that provides connectivity to the 199 Internet or other PDNs. The host attaches to a GGSN identified 200 by an APN assigned to it by an operator. The GGSN also serves 201 as the topological anchor for addresses/prefixes assigned to the 202 User Equipment. 204 10. General Packet Radio Service 206 The General Packet Radio Service (GPRS) is a packet-oriented 207 mobile data service available to users of the 2G and 3G cellular 208 communication systems--the GSM--specified by 3GPP. 210 11. Home Subscriber Server 212 The Home Subscriber Server (HSS) is a database for a given 213 subscriber and was introduced in 3GPP Release-5. It is the 214 entity containing subscription-related information to support 215 the network entities that handle calls/sessions. 217 12. Mobility Management Entity 219 The Mobility Management Entity (MME) is a network element 220 responsible for control-plane functionalities, including 221 authentication, authorization, bearer management, layer-2 222 mobility, and so on. The MME is essentially the control-plane 223 part of the SGSN in the GPRS. The user-plane traffic bypasses 224 the MME. 226 13. Public Land Mobile Network 228 The Public Land Mobile Network (PLMN) is a network operated by a 229 single administration. A PLMN (and, therefore, also an 230 operator) is identified by the Mobile Country Code (MCC) and the 231 Mobile Network Code (MNC). Each (telecommunications) operator 232 providing mobile services has its own PLMN. 234 14. Policy and Charging Control 236 The Policy and Charging Control (PCC) framework is used for QoS 237 policy and charging control. It has two main functions: flow- 238 based charging (including online credit control), and policy 239 control (for example, gating control, QoS control, and QoS 240 signaling). It is optional to 3GPP EPS but needed if dynamic 241 policy and charging control by means of PCC rules based on user 242 and services are desired. 244 15. Packet Data Network 246 The Packet Data Network (PDN) is a packet-based network that 247 either belongs to the operator or is an external network such as 248 the Internet or a corporate intranet. The user eventually 249 accesses services in one or more PDNs. The operator's packet 250 core networks are separated from packet data networks either by 251 GGSNs or PDN Gateways (PGWs). 253 16. Serving Gateway 255 The Serving Gateway (SGW) is a gateway function in the EPS, 256 which terminates the interface towards the E-UTRAN. The SGW is 257 the Mobility Anchor point for layer-2 mobility (inter-eNodeB 258 handovers). For each UE connected with the EPS, there is only 259 one SGW at any given point in time. The SGW is essentially the 260 user-plane part of the GPRS's SGSN. 262 17. Packet Data Network Gateway 264 The Packet Data Network Gateway (PGW) is a gateway function in 265 the Evolved Packet System (EPS), which provides connectivity to 266 the Internet or other PDNs. The host attaches to a PGW 267 identified by an APN assigned to it by an operator. The PGW 268 also serves as the topological anchor for addresses/prefixes 269 assigned to the User Equipment. 271 18. Packet Data Protocol Context 273 A Packet Data Protocol (PDP) context is the equivalent of a 274 virtual connection between the User Equipment (UE) and a PDN 275 using a specific gateway. 277 19. Packet Data Protocol Type 279 A Packet Data Protocol Type (PDP Type) identifies the used/ 280 allowed protocols within the PDP context. Examples are IPv4, 281 IPv6, and IPv4v6 (dual-stack). 283 20. Serving GPRS Support Node 285 The Serving GPRS Support Node (SGSN) is a network element 286 located between the radio access network (RAN) and the gateway 287 (GGSN). A per-UE point-to-point (p2p) tunnel between the GGSN 288 and SGSN transports the packets between the UE and the gateway. 290 21. Terminal Equipment 291 The Terminal Equipment (TE) is any device/host connected to the 292 Mobile Terminal (MT) offering services to the user. A TE may 293 communicate to an MT, for example, over the Point-to-Point 294 Protocol (PPP). 296 22. UE, MS, MN, and Mobile 298 The terms User Equipment (UE), Mobile Station (MS), Mobile Node 299 (MN), and mobile refer to the devices that are hosts with the 300 ability to obtain Internet connectivity via a 3GPP network. An 301 MS comprises the Terminal Equipment (TE) and a Mobile 302 Terminal (MT). The terms UE, MS, MN, and mobile are used 303 interchangeably within this document. 305 23. User Plane 307 The user plane refers to data traffic and the required bearers 308 for the data traffic. In practice, IP is the only data traffic 309 protocol used in the user plane. 311 2. LTE, 4G Mobile Network 313 2.1. Network Overview 315 With the introduction of LTE, mobile networks moved to all-IP 316 transport for all elements such as eNodeB, MME, SGW/PGW, HSS, PCRF, 317 routing and switching, etc. Although LTE network is data-centric, it 318 has support for legacy Circuit Switch features such as voice and SMS 319 through transitional CS fallback and flexible IMS deployment 320 [GRAYSON]. For each mobile device attached to the radio (eNodeB), 321 there is a separate overlay tunnel (GPRS Tunneling Protocol, GTP) 322 between eNodeB and Mobile gateways (i.e., SGW, PGW). 324 The GTP tunnel is used to carry user traffic between gateways and 325 mobile devices. This forces data to be distributed only by using 326 unicast mechanism. It is also important to understand the overhead 327 of a GTP and IPSec protocols because it has impact on the carried 328 user data traffic. All mobile backhaul traffic is encapsulated using 329 GTP tunnel, which has overhead of 8 bytes on top of IP and UDP 330 [NGMN]. Additionally, if IPSec is used for security (which is often 331 required if the Service Provider is using a shared backhaul), it adds 332 overhead based on the IPSec tunneling model (tunnel or transport), 333 and the encryption and authentication header algorithm used. If we 334 factor Advanced Encryption Standard (AES) encryption with the packet 335 size, the overhead can be significant [OLTEANU], particularly for the 336 smaller payloads. 338 When any UE is powered up, it attaches to a mobile network based on 339 its configuration and subscription. After a successful attach 340 procedure, UE registers with the mobile core network, and an IPv4 341 and/or IPv6 address is assigned. A default bearer is created for 342 each UE and it is assigned to default Access Point Name (APN). 344 +-------+ Diameter +-------+ 345 | HSS |------------| SPR | 346 +-------+ +-------+ 347 | | 348 +------+ +------+ S4 | +-------+ 349 | 3G |---| SGSN |----------------|------+ +------| PCRF | 350 ^ |NodeB | | |---------+ +---+ | | +-------+ 351 +-+ | +------+ +------+ S3 | | S6a | |Gxc | 352 | | | +-------+ | | |Gx 353 +-+ | +------------------| MME |------+ | | | 354 UE v | S1MME +-------+ S11 | | | | 355 +----+-+ +-------+ +-------+ 356 |4G/LTE|------------------------------| SGW |-----| PGW | 357 |eNodeB| S1U +-------+ +--| | 358 +------+ | +-------+ 359 +---------------------+ | | 360 S1U GTP Tunnel traffic | +-------+ | | 361 S2a GRE Tunnel traffic |S2A | ePDG |-------+ | 362 S2b GRE Tunnel traffic | +-------+ S2B |SGi 363 SGi IP traffic | | | 364 +---------+ +---------+ +-----+ 365 | Trusted | |Untrusted| | CDN | 366 |non-3GPP | |non-3GPP | +-----+ 367 +---------+ +---------+ 368 | | 369 +-+ +-+ 370 | | | | 371 +-+ +-+ 372 UE UE 374 Figure 1: LTE, 4G Mobile Network Overview 376 The data delivered to mobile devices is unicast inside the GTP 377 tunnel. If we consider the combined impact of GTP, IPSec and unicast 378 traffic, the data delivery is not efficient. IETF has developed 379 various header compression algorithms to reduce overhead associated 380 with IP packets. Some techniques are robust header compression 381 (ROHC) and enhanced compression of the real-time transport protocol 382 (ECRTP) so that impact of overhead created by GTP, IPsec, etc., is 383 reduced to some extent [BROWER]. For commercial mobile networks, 384 3GPP has adopted different mechanisms for header compression to 385 achieve efficiency in data delivery [TS25.323], and can be adapted to 386 ICN, as well [ICNLOWPAN] [TLVCOMP]. 388 2.2. QoS Challenges 390 During the attach procedure, a default bearer is created for each UE 391 and it is assigned to the default Access Point Name (APN). The QoS 392 values that uplink and downlink bandwidth assigned during the initial 393 attach are minimal. Additional dedicated bearer(s) with enhanced QoS 394 parameters are established depending on specific application needs. 396 While all traffic within a certain bearer gets the same treatment, 397 QoS parameters supporting these requirements can be very granular in 398 different bearers. These values vary for the control, management and 399 user traffic, and can be very different depending on application key 400 parameters such as latency, jitter (important for voice and other 401 real-time applications), packet loss, and queuing mechanism (strict 402 priority, low-latency, fair, and so on). 404 Implementation of QoS for mobile networks is done at two stages: at 405 content prioritization/marking and transport marking, and congestion 406 management. From the transport perspective, QoS is defined at layer 407 2 as class of service (CoS) and at layer 3 either as DiffServ code 408 point (DSCP) or type of service (ToS). The mapping of DSCP to CoS 409 takes place at layer 2/3 switching and routing elements. 3GPP has a 410 specified QoS Class Identifier (QCI), which represents different 411 types of content and equivalent mapping to DSCP at transport layer 412 [TS23.401]. However, this requires manual configuration at different 413 elements and, if there are misconfigurations at any place in the 414 path, it will not work properly. 416 In summary, QoS configuration for mobile networks for user plane (for 417 user traffic) and transport in an IP-based mobile network is complex 418 requires synchronization of parameters among different platforms. 419 Normally, QoS in IP is implemented using DiffServ, which uses hop-by- 420 hop QoS configuration at each router. Any inconsistency in IP QoS 421 configuration at routers in the forwarding path can result in a poor 422 subscriber experience (e.g., packet classified as high-priority can 423 go to a lower priority queue). By deploying ICN, we intend to 424 enhance the subscriber experience using policy-based configuration, 425 which can be associated with the named contents [ICNQoS] at the ICN 426 forwarder. Further investigation is needed to understand how QoS in 427 ICN can be implemented to meet the IP QoS requirements [RFC4594]. 429 Research papers published so far explore the possibility of 430 classifications based on name prefixes (thus addressing the problem 431 of IP QoS not being information aware), or on popularity or placement 432 (looking at a distance of a content from a requester). However, 433 focus of these research efforts is on faster routing of Interest 434 requests towards the content rather than content delivery. 436 2.3. Data Transport Using IP 438 The data delivered to mobile devices is unicast inside GTP tunnel 439 from an eNodeB to a PDN gateway (PGW), as described in 3GPP 440 specifications [TS23.401]. While the technology exists to address 441 the issue of possible multicast delivery, there are many difficulties 442 related to multicast protocol implementation on the RAN side of the 443 network. Transport networks in the backhaul and core addressed the 444 multicast delivery long ago and have implemented it in most cases in 445 their multi-purpose integrated transport. But the RAN part of the 446 network is still lagging behind due to complexities related to client 447 mobility, handovers, and the fact that the potential gain to Service 448 Providers may not justify the investment. With that said, the data 449 delivery in the mobility remains greatly unicast. Techniques to 450 handle multicast (such as LTE-B or eMBMS) have been designed to 451 handle pre-planned content delivery, such as live content, which 452 contrasts user behavior today, largely based on content (or video) on 453 demand model. 455 To ease the burden on the bandwidth of the SGi interface, caching is 456 introduced in a similar manner as with many Enterprises. In the 457 mobile networks, whenever possible, cached data is delivered. 458 Caching servers are placed at a centralized location, typically in 459 the Service Provider's Data Center, or in some cases lightly 460 distributed in Packet Core locations with the PGW nodes close to the 461 Internet and IP services access (SGi interface). This is a very 462 inefficient concept because traffic must traverse the entire backhaul 463 path for the data to be delivered to the end user. Other issues, 464 such as out-of-order delivery, contribute to this complexity and 465 inefficiency, which needs to be addressed at the application level. 467 Data delivered to mobile devices is unicast inside a GTP tunnel. If 468 we consider the combined impact of GTP, IPSec, and unicast traffic, 469 the end-to-end data delivery is not efficient. By deploying ICN, we 470 intend to either terminate the GTP tunnel at the mobility anchoring 471 point by leveraging control and user-plane separation, or replace it 472 with native ICN protocols. 474 2.4. Virtualizing Mobile Networks 476 The Mobile packet core deployed in a major Service Provider network 477 is either based on dedicated hardware or, in some cases, large 478 capacity x86 platforms. With adoption of Mobile Virtual Network 479 Operators (MVNO), public safety network, and enterprise mobility 480 network, we need elastic mobile core architecture. By deploying 481 mobile packet core on a commercially off-the-shelf (COTS) platform 482 using virtualized infrastructure (NFVI) framework and end-to-end 483 orchestration, we can simplify new deployments and provide optimized 484 TCO. 486 While virtualization is growing, and many mobile providers use hybrid 487 architecture consisting of dedicated and virtualized infrastructures, 488 the control and data delivery planes are still the same. There is 489 also work under way to separate the control plane and user plane so 490 the network can scale better. Virtualized mobile networks and 491 network slicing with control and user plane separation provide 492 mechanism to evolve GTP-based architecture to open-flow SDN-based 493 signaling for LTE and proposed 5G core. Some early architecture work 494 for 5G mobile technologies provides a mechanism for control and user 495 plane separation and simplifies mobility call flow by introduction of 496 open-flow-based signaling [ICN5G]. This has been considered by 3GPP 497 [EPCCUPS] and is also described in [SDN5G]. 499 3. Data Transport Using ICN 501 For mobile devices, the edge connectivity to the network is between 502 radio and a router or mobile edge computing (MEC) [MECSPEC] element. 503 MEC has the capability of processing client requests and segregating 504 control and user traffic at the edge of radio, rather than sending 505 all requests to the mobile gateway. 507 +----------+ 508 | Content +----------------------------------------+ 509 | Publisher| | 510 +---+---+--+ | 511 | | +--+ +--+ +--+ | 512 | +--->|R1|------------>|R2|---------->|R4| | 513 | +--+ +--+ +--+ | 514 | | Cached | 515 | v content | 516 | +--+ at R3 | 517 | +========|R3|---+ | 518 | # +--+ | | 519 | # | | 520 | v v | 521 | +-+ +-+ | 522 +---------------| |-------------| |-------------+ 523 +-+ +-+ 524 Consumer-1 Consumer-2 525 UE UE 527 ===> Content flow from cache 528 ---> Content flow from publisher 530 Figure 2: ICN Architecture 532 MEC transforms radio into an intelligent service edge capable of 533 delivering services directly from the edge of the network, while 534 providing the best possible performance to the client. MEC can be an 535 ideal candidate for ICN forwarder in addition to its usual function 536 of managing mobile termination. In addition to MEC, other transport 537 elements, such as routers, can work as ICN forwarders. 539 Data transport using ICN is different compared to IP-based transport. 540 It evolves the Internet infrastructure by introducing uniquely named 541 data as a core Internet principle. Communication in ICN takes place 542 between the content provider (producer) and the end user (consumer), 543 as described in Figure 2. 545 Every node in a physical path between a client and a content provider 546 is called the ICN forwarder or router. It can route the request 547 intelligently and to cache the content so it can be delivered 548 locally for subsequent request from any other client. For mobile 549 network, transport between a client and a content provider consists 550 of radio network + mobile backhaul and IP core transport + Mobile 551 Gateways + Internet + content data network (CDN). 553 To understand the suitability of ICN for mobile networks, we will 554 discuss the ICN framework describing protocols architecture and 555 different types of messages, and then consider how we can use this in 556 a mobile network for delivering content more efficiently. ICN uses 557 two types of packets called "interest packet" and "data packet" as 558 described in Figure 3. 560 +------------------------------------+ 561 Interest | +------+ +------+ +------+ | +-----+ 562 +-+ ---->| CS |---->| PIT |---->| FIB |--------->| CDN | 563 | | | +------+ +------+ +------+ | +-----+ 564 +-+ | | Add | Drop | | Forward 565 UE <--------+ Intf v Nack v | 566 Data | | 567 +------------------------------------+ 569 +------------------------------------+ 570 +-+ | Forward +------+ | +-----+ 571 | | <-------------------------------------| PIT |<---------| CDN | 572 +-+ | | Cache +--+---+ | Data +-----+ 573 UE | +--v---+ | | 574 | | CS | v | 575 | +------+ Discard | 576 +------------------------------------+ 578 Figure 3: ICN Interest, Data Packet and Forwarder 580 In an LTE network, when a mobile device wants to get certain content, 581 it will send an Interest message to the closest eNodeB. Interest 582 packet follows the TLV format [RFC8609] and contains mandatory fields 583 such as name of the content and content matching restrictions 584 (KeyIdRestr and ContentObjectHashRestr) forming the tuple [RFC8569]. 585 The content matching tuple uniquely identifies the matching data 586 packet for the given Interest packet. Another attribute called 587 HopLimit is used to detect looping Interest messages. 589 An ICN router will receive an Interest packet and perform lookup if a 590 request for such content has come earlier from another client. If 591 yes, it is served from the local cache; otherwise, the request is 592 forwarded to the next-hop ICN router. Each ICN router maintains 593 three data structures: Pending Interest Table (PIT), Forwarding 594 Information Base (FIB), and Content Store (CS). The Interest packet 595 travels hop-by-hop towards the content provider. Once the Interest 596 reaches the content provider, it will return a Data packet containing 597 information such as content name, signature, and data. 599 Data packet travels in reverse direction following the same path 600 taken by the Interest packet, which maintains routing symmetry. 601 Details about algorithms used in PIT, FIB, CS, and security trust 602 models are described in various resources [CCN]; here, we have 603 explained the concept and its applicability to the LTE network. 605 4. ICN Deployment in 4G and LTE Networks 607 4.1. General ICN Deployment Considerations 609 In LTE/4G mobile networks, both user and control plane traffic have 610 to be transported from the edge to the mobile packet core via IP 611 transport. The evolution of existing mobile packet core using 612 Control and User Plane Separation (CUPS) [TS23.714] enables flexible 613 network deployment and operation, by distributed deployment and the 614 independent scaling between control plane and user plane functions - 615 while not affecting the functionality of existing nodes subject to 616 this split. 618 In the CUPS architecture, there is an opportunity to shorten the path 619 for user plane traffic by deploying offload nodes closer to the edge 620 [OFFLOAD]. With this major architecture change, a User Plane 621 Function (UPF) node is placed close to the edge so traffic no longer 622 needs to traverse the entire backhaul path to reach the EPC. In many 623 cases, where feasible, UPF can be collocated with the eNodeB, which 624 is also a business decision based on user demand. Placing a 625 Publisher close to the offload site, or at the offload site, provides 626 for a significant improvement in user experience, especially with 627 latency-sensitive applications. This optimization allows for the 628 introduction of ICN and amplifies its advantages. This section 629 analyzes the potential impact of ICN on control and user plane 630 traffic for centralized and disaggregate CUPS-based mobile network 631 architecture. 633 4.2. ICN Deployment Scenarios 635 Deployment of ICN provides an opportunity to further optimize the 636 existing data transport in LTE/4G mobile networks. The various 637 deployment options that ICN and IP provide are somewhat analogous to 638 the deployment scenarios when IPv6 was introduced to interoperate 639 with IPv4 except, with ICN, the whole IP stack is being replaced. We 640 have reviewed [RFC6459] and analyzed the impact of ICN on control 641 plane signaling and user plane data delivery. In general, ICN can be 642 deployed by natively replacing IP transport (IPv4 and IPv6) or as an 643 overlay protocol. Figure 4 describes a modified protocol stack to 644 support ICN deployment scenarios. 646 +----------------+ +-----------------+ 647 | ICN App (new) | |IP App (existing)| 648 +---------+------+ +-------+---------+ 649 | | 650 +---------+----------------+---------+ 651 | Transport Convergence Layer (new) | 652 +------+---------------------+-------+ 653 | | 654 +------+------+ +------+-------+ 655 |ICN function | | IP function | 656 | (New) | | (Existing) | 657 +------+------+ +------+-------+ 658 | | 659 (```). (```). 660 ( ICN '`. ( IP '`. 661 ( Cloud ) ( Cloud ) 662 ` __..'+' ` __..'+' 664 Figure 4: IP/ICN Convergence and Deployment Scenarios 666 As shown in Figure 4, for applications running either in UE or in 667 content provider system to use the new transport option, we propose a 668 new transport convergence layer (TCL). This transport convergence 669 layer helps determine the type of transport (such as ICN or IP), as 670 well as the type of radio interface (LTE or WiFi or both) used to 671 send and receive traffic based on preference (e.g., content location, 672 content type, content publisher, congestion, cost, QoS). It helps 673 configure and determine the type of connection, as well as the 674 overlay mode (ICNoIP or IPoICN) between application and the protocol 675 stack (IP or ICN), to be used. 677 Combined with the existing IP function, the ICN function provides 678 support for either native ICN and/or the dual stack (ICN/IP) 679 transport functionality. See Section 4.4.1 for elaborate 680 descriptions of these functional layers. 682 The TCL can use several mechanisms for transport selection . It can 683 use a per-application configuration through a management interface, 684 possibly even a user-facing setting realized through a user 685 interface, like those used today that select cellular over WiFi being 686 used for selected applications. In another option, it might use a 687 software API, which an adapted IP application could use to specify 688 (such as an ICN transport) for obtaining its benefits. 690 Another potential application of TCL is in implementation of network 691 slicing, where it can have a slice management capability locally or 692 it can interface to an external slice manager through an API [GALIS]. 694 This solution can enable network slicing for IP and ICN transport 695 selection from the UE itself. The TCL could apply slice settings to 696 direct certain traffic (or applications) over one slice and others 697 over another slice, determined by some form of 'slicing policy'. 698 Slicing policy can be obtained externally from the slice manager or 699 configured locally on UE. 701 From the perspective of applications either on UE or a content 702 provider, the following options are possible for ICN deployment 703 natively and/or with IP. 705 1. IP over IP 707 In this scenario, UE uses applications tightly integrated with 708 the existing IP transport infrastructure. In this option, the 709 TCL has no additional function because packets are forwarded 710 directly using an IP protocol stack, which sends packets over the 711 IP transport. 713 2. ICN over ICN 715 Similar to Case 1, ICN applications integrate tightly with the ICN 716 transport infrastructure. The TCL has no additional 717 responsibility because packets are forwarded directly using ICN 718 protocol stack, which sends packets over the ICN transport. 720 3. ICN over IP (ICNoIP) 722 In this scenario, the underlying IP transport infrastructure is 723 not impacted (that is, ICN is implemented as an IP overlay 724 between user equipment (UE) and content provider). IP routing is 725 used from Radio Access Network (eNodeB) to mobile backhaul, IP 726 core, and Mobile Gateway (SGW/PGW). UE attaches to Mobile 727 Gateway (SGW/PGW) using IP address. Also, the data transport 728 between Mobile Gateway (SGW/PGW) and content publisher uses IP. 729 Content provider can serve content either using IP or ICN, based 730 on the UE request. 732 An approach to implement ICN in mobile backhaul networks is 733 described in [MBICN]. It implements a GTP-U extension header 734 option to encapsulate ICN payload in GTP tunnel. However, as 735 this design runs ICN as an IP overlay, the mobile backhaul can be 736 deployed using native IP. The proposal describes a mechanism 737 where GTP-U tunnel can be terminated by hairpinning the packet 738 before it reaches SGW, if an ICN-enabled node is deployed in the 739 mobile backhaul (that is, between eNodeB and SGW). This could be 740 useful when an ICN data packet is stored in the ICN node (such as 741 repos, caches) in the tunnel path; it can reply right away 742 without going all the way through the mobile core. While GTP-U 743 extension header is used to carry UE specific ICN payload, they 744 are not visible to the transport, including SGW. On the other 745 hand, the PGW can use the UE-specific ICN header extension and 746 ICN payload to set up an uplink transport towards content 747 provider in the Internet. In addition, the design assumes a 748 proxy function at the edge, to perform ICN data retrieval on 749 behalf of a non-ICN end device. 751 4. IP over ICN (IPoICN) 753 H2020 project [H2020] provides an architectural framework for 754 deployment of IP as an overlay over ICN protocol [IPoICN]. 755 Implementing IP services over ICN provides an opportunity 756 leveraging benefit of ICN in the transport infrastructure and 757 there is no impact on end devices (UE and access network) as they 758 continue to use IP. IPoICN however, will require an inter- 759 working function (IWF/Border Gateway) to translate various 760 transport primitives. The IWF function will provide a mechanism 761 for protocol translation between IPoICN and native IP deployment 762 for mobile network. After reviewing [IPoICN], we understand and 763 interpret that ICN is implemented in the transport natively; 764 however, IP is implemented in UE, eNodeB, and Mobile gateway 765 (SGW/PGW), which is also called as a network attach point (NAP). 767 For this, said NAP receives an incoming IP or HTTP packet (the 768 latter through TCP connection termination) and publishes the 769 packet under a suitable ICN name (i.e., the hash over the 770 destination IP address for an IP packet or the hash over the FQDN 771 of the HTTP request for an HTTP packet) to the ICN network. In 772 the HTTP case, the NAP maintains a pending request mapping table 773 to map returning responses to the terminated TCP connection. 775 5. Hybrid ICN (hICN) 777 An alternative approach to implement ICN over IP is provided in 778 Hybrid ICN [HICN]. It describes a novel approach to integrate 779 ICN into IPv6 without creating overlays with a new packet format 780 as an encapsulation. hICN addresses the content by encoding a 781 location-independent name in an IPv6 address. It uses two name 782 components--name prefix and name suffix--that identify the source 783 of data and the data segment within the scope of the name prefix, 784 respectively. 786 At application layer, hICN maps the name into an IPv6 prefix and, 787 thus, uses IP as transport. As long as the name prefixes, which 788 are routable IP prefixes, point towards a mobile GW (PGW or local 789 breakout, such as CUPS), there are potentially no updates 790 required to any of the mobile core gateways (for example, SGW/ 791 PGW). The IPv6 backhaul routes the packets within the mobile 792 core. hICN can run in the UE, in the eNodeB, in the mobile 793 backhaul, or in the mobile core. Finally, as hICN itself uses 794 IPv6, it cannot be considered as an alternative transport layer. 796 4.3. ICN Deployment in LTE Control Plane 798 In this section, we analyze signaling messages that are required for 799 different procedures, such as attach, handover, tracking area update, 800 and so on. The goal of this analysis is to see if there are any 801 benefits to replacing IP-based protocols with ICN for LTE signaling 802 in the current architecture. It is important to understand the 803 concept of point of attachment (POA). When UE connects to a network, 804 it has the following POAs: 806 1. eNodeB managing location or physical POA 808 2. Authentication and Authorization (MME, HSS) managing identity or 809 authentication POA 811 3. Mobile Gateways (SGW, PGW) managing logical or session management 812 POA 814 In the current architecture, IP transport is used for all messages 815 associated with the control plane for mobility and session 816 management. IP is embedded very deeply into these messages and TLV, 817 carrying additional attributes such as a layer 3 transport. Physical 818 POA in eNodeB handles both mobility and session management for any UE 819 attached to 4G, LTE network. The number of mobility management 820 messages between different nodes in an LTE network per signaling 821 procedure are shown in Table 1. 823 Normally, two types of UE devices attach to the LTE network: SIM 824 based (need 3GPP mobility protocol for authentication) or non-SIM 825 based (which connect to WiFi network). Both device types require 826 authentication . For non-SIM based devices, AAA is used for 827 authentication. We do not propose to change UE authentication or 828 mobility management messaging for user data transport using ICN. A 829 separate study would be required to analyze the impact of ICN on 830 mobility management messages structures and flows. We are merely 831 analyzing the viability of implementing ICN as a transport for 832 control plane messages. 834 It is important to note that, if MME and HSS do not support ICN 835 transport, they still need to support UE capable of dual stack or 836 native ICN. When UE initiates an attach request using the identity 837 as ICN, MME must be able to parse that message and create a session. 839 MME forwards UE authentication to HSS, so HSS must be able to 840 authenticate an ICN-capable UE and authorize create session 841 [TS23.401]. 843 +---------------------------+-----+-----+-----+-----+------+ 844 | LTE Signaling Procedures | MME | HSS | SGW | PGW | PCRF | 845 +---------------------------+-----+-----+-----+-----+------+ 846 | Attach | 10 | 2 | 3 | 2 | 1 | 847 | Additional default bearer | 4 | 0 | 3 | 2 | 1 | 848 | Dedicated bearer | 2 | 0 | 2 | 2 | 0 | 849 | Idle-to-connect | 3 | 0 | 1 | 0 | 0 | 850 | Connect-to-Idle | 3 | 0 | 1 | 0 | 0 | 851 | X2 handover | 2 | 0 | 1 | 0 | 0 | 852 | S1 handover | 8 | 0 | 3 | 0 | 0 | 853 | Tracking area update | 2 | 2 | 0 | 0 | 0 | 854 | Total | 34 | 2 | 14 | 6 | 3 | 855 +---------------------------+-----+-----+-----+-----+------+ 857 Table 1: Signaling Messages in LTE Gateways 859 Anchorless mobility [ALM] provides a fully decentralized, control- 860 plane agnostic solution to handle producer mobility in ICN. Mobility 861 management at layer-3 level makes it access agnostic and transparent 862 to the end device or the application. The solution discusses 863 handling mobility without having to depend on core network functions 864 (e.g. MME); however, a location update to the core network may still 865 be required to support legal compliance requirements such as lawful 866 intercept and emergency services. These aspects are open for further 867 study. 869 One of the advantages of ICN is in the caching and reusing of the 870 content, which does not apply to the transactional signaling 871 exchange. After analyzing LTE signaling call flows [TS23.401] and 872 messages inter-dependencies (see Table 1), our recommendation is that 873 it is not beneficial to deploy ICN for control plane and mobility 874 management functions. Among the features of ICN design, Interest 875 aggregation and content caching are not applicable to control plane 876 signaling messages. Control plane messages are originated and 877 consumed by the applications and they cannot be shared. 879 4.4. ICN Deployment in LTE User Plane 881 We will consider Figure 1 to discuss different mechanisms to deploy 882 ICN in mobile networks. In Section 4.2, we discussed generic 883 deployment scenarios of ICN. In this section, we discuss the 884 specific use cases of native ICN deployment in LTE user plane. We 885 consider the following options: 887 1. Dual stack ICN deployment in UE 889 2. Native ICN deployments in UE 891 3. ICN deployment in eNodeB 893 4. ICN deployment in mobile gateways (SGW/PGW) 895 4.4.1. Dual stack ICN deployments in UE 897 The control and user plane communications in LTE, 4G mobile networks 898 are specified in 3GPP documents [TS23.203] and [TS23.401]. It is 899 important to understand that UE can be either consumer (receiving 900 content) or publisher (pushing content for other clients). The 901 protocol stack inside mobile device (UE) is complex because it has to 902 support multiple radio connectivity access to eNodeB(s). 904 Figure 5 provides a high-level description of a protocol stack, where 905 IP is defined at two layers: (1) user plane communication and (2) UDP 906 encapsulation. User plane communication takes place between Packet 907 Data Convergence Protocol (PDCP) and Application layer, whereas UDP 908 encapsulation is at GTP protocol stack. 910 The protocol interactions and impact of supporting tunneling of ICN 911 packet into IP or to support ICN natively are described in Figure 5 912 and Figure 6, respectively. 914 +--------+ +--------+ 915 | App | | CDN | 916 +--------+ +--------+ 917 |Transp. | | | | |Transp. | 918 |Converg.|.|..............|...............|............|.|Converge| 919 +--------+ | | | +--------+ | +--------+ 920 | |.|..............|...............|.| |.|.| | 921 | ICN/IP | | | | | ICN/IP | | | ICN/IP| 922 | | | | | | | | | | 923 +--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+ 924 | |.|.| | |.|.| | |.|.| | | | | | 925 | PDCP | | |PDCP|GTP-U| | |GTP-U|GTP-U| | |GTP-U| | | | L2 | 926 +--------+ | +----------+ | +-----------+ | +-----+ | | | | 927 | RLC |.|.|RLC | UDP |.|.| UDP | UDP |.|.|UDP |L2|.|.| | 928 +--------+ | +----------+ | +-----------+ | +-----+ | | | | 929 | MAC |.|.| MAC| L2 |.|.| L2 | L2 |.|.| L2 | | | | | 930 +--------+ | +----------+ | +-----------+ | +--------+ | +--------+ 931 | L1 |.|.| L1 | L1 |.|.| L1 | L1 |.|.| L1 |L1|.|.| L1 | 932 +--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+ 933 UE | BS(eNodeB) | SGW | PGW | 934 Uu S1U S5/S8 SGi 936 Figure 5: Dual Stack ICN Deployment in UE 938 The protocols and software stack used inside LTE capable UE support 939 both 3G and LTE software interworking and handover. Latest 3GPP 940 Rel.13 onward specification describes the use of IP and non-IP 941 protocols to establish logical/session connectivity. We intend to 942 leverage the non-IP protocol-based mechanism to deploy ICN protocol 943 stack in UE, as well as in eNodeB and mobile gateways (SGW, PGW). 945 1. Existing application layer can be modified to provide options for 946 a new ICN-based application and existing IP-based applications. 947 UE can continue to support existing IP-based applications or host 948 new applications developed to support native ICN as transport, 949 ICNoIP, or IPoICN-based transport. Application layer has the 950 option of selecting either ICN or IP transport, as well as radio 951 interface, to send and receive data traffic. 953 Our proposal is to provide an Application Programming Interface 954 (API) to the application developers so they can choose either ICN 955 or IP transport for exchanging the traffic with the network. As 956 mentioned in Section 4.2, the transport convergence layer (TCL) 957 function handles the interaction of applications with multiple 958 transport options. 960 2. The transport convergence layer helps determine the type of 961 transport (such as ICN, hICN, or IP) and type of radio interface 962 (LTE or WiFi, or both) used to send and receive traffic. 963 Application layer can make the decision to select a specific 964 transport based on preference, such as content location, content 965 type, content publisher, congestion, cost, QoS, and so on. There 966 can be an Application Programming Interface (API) to exchange 967 parameters required for transport selection. Southbound 968 interactions of Transport Convergence Layer (TCL) will be either 969 to IP or ICN at the network layer. 971 When selecting the IPoICN mode, the TCL is responsible for 972 receiving an incoming IP or HTTP packet and publishing the packet 973 to the ICN network under a suitable ICN name (that is, the hash 974 over the destination IP address for an IP packet, or the hash 975 over the FQDN of the HTTP request for an HTTP packet). In the 976 HTTP case, the TCL maintains a pending request mapping table to 977 map returning responses to the originating HTTP request. The 978 common API will provide a common 'connection' abstraction for 979 this HTTP mode of operation, returning the response over said 980 connection abstraction, akin to the TCP socket interface, while 981 implementing a reliable transport connection semantic over the 982 ICN from the UE to the receiving UE or the PGW. If the HTTP 983 protocol stack remains unchanged, therefore utilizing the TCP 984 protocol for transfer, the TCL operates in local TCP termination 985 mode, retrieving the HTTP packet through said local termination. 987 +----------------+ +-----------------+ 988 | ICN App (new) | |IP App (existing)| 989 +---------+------+ +-------+---------+ 990 | | 991 +---------+----------------+---------+ 992 | Transport Convergence Layer (new) | 993 +------+---------------------+-------+ 994 | | 995 +------+------+ +------+-------+ 996 |ICN function | | IP function | 997 | (New) | | (Existing) | 998 +------+------+ +------+-------+ 999 | | 1000 +------+---------------------+-------+ 1001 | PDCP (updated to support ICN) | 1002 +-----------------+------------------+ 1003 | 1004 +-----------------+------------------+ 1005 | RLC (Existing) | 1006 +-----------------+------------------+ 1007 | 1008 +-----------------+------------------+ 1009 | MAC Layer (Existing) | 1010 +-----------------+------------------+ 1011 | 1012 +-----------------+------------------+ 1013 | Physical L1 (Existing) | 1014 +------------------------------------+ 1016 Figure 6: Dual Stack ICN Protocol Interactions 1018 3. ICN function (forwarder) is introduced in parallel to the 1019 existing IP layer. ICN forwarder contains functional 1020 capabilities to forward ICN packets, such as Interest packet to 1021 eNodeB or response "data packet" from eNodeB to the application. 1023 4. For the dual-stack scenario, when UE is not supporting ICN as 1024 transport, we use IP underlay to transport ICN packets. ICN 1025 function will use IP interface to send Interest and Data packets 1026 for fetching or sending data using ICN protocol function. This 1027 interface will use ICN overlay over IP using any overlay 1028 tunneling mechanism. 1030 5. To support ICN at network layer in UE, PDCP layer has to be aware 1031 of ICN capabilities and parameters. PDCP is located in the Radio 1032 Protocol Stack in the LTE Air interface, between IP (Network 1033 layer) and Radio Link Control Layer (RLC). PDCP performs the 1034 following functions [TS36.323]: 1036 1. Data transport by listening to upper layer, formatting and 1037 pushing down to Radio Link Layer (RLC) 1039 2. Header compression and decompression using Robust Header 1040 Compression (ROHC) 1042 3. Security protections such as ciphering, deciphering, and 1043 integrity protection 1045 4. Radio layer messages associated with sequencing, packet drop 1046 detection and re-transmission, and so on. 1048 6. No changes are required for lower layer such as RLC, MAC, and 1049 Physical (L1) because they are not IP aware. 1051 One key point to understand in this scenario is that ICN is deployed 1052 as an overlay on top of IP. 1054 4.4.2. Native ICN Deployments in UE 1056 We propose to implement ICN natively in UE by modifying the PDCP 1057 layer in 3GPP protocols. Figure 7 provides a high-level protocol 1058 stack description where ICN is used at the following different 1059 layers: 1061 1. User plane communication 1063 2. Transport layer 1065 User plane communication takes place between PDCP and application 1066 layer, whereas ICN transport is a substitute of GTP protocol. 1067 Removal of GTP protocol stack is a significant change in mobile 1068 architecture because GTP is used not just for routing but for 1069 mobility management functions, such as billing, mediation, and policy 1070 enforcement. 1072 If we implement ICN natively in UE, communication between UE and 1073 eNodeB will change. Also, this will avoid tunneling the user plane 1074 traffic from eNodeB to the mobile packet core (SGW, PGW) using GTP 1075 tunnel. 1077 For native ICN deployment, an application will be configured to use 1078 ICN forwarder so there is no need for Transport Convergence. Also, 1079 to support ICN at the network layer in UE, we need to modify the 1080 existing PDCP layer. PDCP layer must be aware of ICN capabilities 1081 and parameters. 1083 Native implementation will also provide opportunities to develop new 1084 use cases leveraging ICN capabilities, such as seamless mobility, UE 1085 to UE content delivery using radio network without traversing the 1086 mobile gateways, and more. 1088 +--------+ +--------+ 1089 | App | | CDN | 1090 +--------+ +--------+ 1091 |Transp. | | | | | |Transp. | 1092 |Converge|.|..............|..............|..............|.|Converge| 1093 +--------+ | | | | +--------+ 1094 | |.|..............|..............|..............|.| | 1095 | ICN/IP | | | | | | | 1096 | | | | | | | | 1097 +--------+ | +----+-----+ | +----------+ | +----------+ | | ICN/IP | 1098 | |.|.| | | | | | | | | | | | 1099 | PDCP | | |PDCP| ICN |.|.| ICN |.|.| ICN |.|.| | 1100 +--------+ | +----+ | | | | | | | | | | 1101 | RLC |.|.|RLC | | | | | | | | | | | 1102 +--------+ | +----------+ | +----------+ | +----------+ | +--------+ 1103 | MAC |.|.| MAC| L2 |.|.| L2 |.|.| L2 |.|.| L2 | 1104 +--------+ | +----------+ | +----------+ | +----------+ | +--------+ 1105 | L1 |.|.| L1 | L1 |.|.| L1 |.|.| L1 |.|.| L1 | 1106 +--------+ | +----+-----+ | +----------+ | +----------+ | +--------+ 1107 UE | BS(eNodeB) | SGW | PGW | 1108 Uu S1u S5/S8 SGi 1110 Figure 7: Native ICN Deployment in UE 1112 4.5. ICN Deployment in eNodeB 1114 eNodeB is a physical point of attachment for UE, where radio 1115 protocols are converted into IP transport protocol for dual stack/ 1116 overlay and native ICN, respectively (see Figure 6 and Figure 7) When UE 1117 performs attach procedures, it is assigned an identity either as IP, 1118 dual stack (IP and ICN), or ICN. UE can initiate data traffic using any 1119 of the following options: 1121 1. Native IP (IPv4 or IPv6) 1123 2. Native ICN 1125 3. Dual stack IP (IPv4/IPv6) or ICN 1126 UE encapsulates user data transport request into PDCP layer and sends 1127 the information on air interface to eNodeB. eNodeB receives the 1128 information and, using PDCP [TS36.323], de-encapsulates air-interface 1129 messages and converts them to forward to core mobile gateways (SGW, 1130 PGW). As shown in Figure 8, to support ICN natively in eNodeB, it is 1131 proposed to provide transport convergence layer (TCL) capabilities in 1132 eNodeB (similar to as provided in UE), which provides the following 1133 functions: 1135 1. It decides the forwarding strategy for a user data request coming 1136 from UE. The strategy can decide based on preference indicated 1137 by the application, such as congestion, cost, QoS, and so on. 1139 2. eNodeB to provide open Application Programming Interface (API) to 1140 external management systems, to provide capability to eNodeB to 1141 program the forwarding strategies. 1143 +---------------+ | 1144 | UE request | | ICN +---------+ 1145 +---> | content using |--+--- transport -->| | 1146 | |ICN protocol | | | | 1147 | +---------------+ | | | 1148 | | | | 1149 | +---------------+ | | | 1150 +-+ | | UE request | | IP |To mobile| 1151 | |---+---> | content using |--+--- transport -->| GW | 1152 +-+ | | IP protocol | | |(SGW,PGW)| 1153 UE | +---------------+ | | | 1154 | | | | 1155 | +---------------+ | | | 1156 | | UE request | | Dual stack | | 1157 +---> | content using |--+--- IP+ICN -->| | 1158 |IP/ICN protocol| | transport +---------+ 1159 +---------------+ | 1160 eNodeB S1u 1162 Figure 8: Native ICN Deployment in eNodeB 1164 3. eNodeB can be upgraded to support three different types of 1165 transport: IP, ICN, and dual stack IP+ICN towards mobile 1166 gateways, as depicted in Figure 8. It is also recommended to 1167 deploy IP and/or ICN forwarding capabilities into eNodeB, for 1168 efficient transfer of data between eNodeB and mobile gateways. 1169 Following are choices for forwarding a data request towards 1170 mobile gateways: 1172 1. Assuming eNodeB is IP enabled and UE requests IP transfer, 1173 eNodeB forwards data over IP. 1175 2. Assuming eNodeB is ICN enabled and UE requests ICN transfer, 1176 eNodeB forwards data over ICN. 1178 3. Assuming eNodeB is IP enabled and UE requests ICN, eNodeB 1179 overlays ICN on IP and forwards user plane traffic over IP. 1181 4. Assuming eNodeB is ICN enabled and UE requests IP, eNodeB 1182 overlays IP on ICN and forwards user plane traffic over ICN 1183 [IPoICN]. 1185 4.6. ICN Deployment in Packet Core (SGW, PGW) Gateways 1187 Mobile gateways---also known as Evolved Packet Core (EPC)--include 1188 SGW, PGW, which perform session management for UE from the initial 1189 attach to disconnection. When UE is powered on, it performs NAS 1190 signaling and attaches to PGW after successful authentication. PGW 1191 is an anchoring point for UE and responsible for service creations, 1192 authorization, maintenance, and so on. The Entire functionality is 1193 managed using IP address(es) for UE. 1195 To implement ICN in EPC, the following functions are needed: 1197 1. Insert ICN attributes in session management layer as additional 1198 functionality with IP stack. Session management layer is used 1199 for performing attach procedures and assigning logical identity 1200 to user. After successful authentication by HSS, MME sends a 1201 create session request (CSR) to SGW and SGW to PGW. 1203 2. When MME sends Create Session Request message (Step 12 in 1204 [TS23.401]) to SGW or PGW, it includes a Protocol Configuration 1205 Option Information Element (PCO IE) containing UE capabilities. 1206 We can use PCO IE to carry ICN-related capabilities information 1207 from UE to PGW. This information is received from UE during the 1208 initial attach request in MME. Details of available TLV, which 1209 can be used for ICN, are given in subsequent sections. UE can 1210 support either native IP, ICN+IP, or native ICN. IP is referred 1211 to as both IPv4 and IPv6 protocols. 1213 3. For ICN+IP-capable UE, PGW assigns the UE both an IP address and 1214 ICN identity. UE selects either of the identities during the 1215 initial attach procedures and registers with the network for 1216 session management. For ICN-capable UE, it will provide only ICN 1217 attachment. For native IP-capable UE, there is no change. 1219 4. To support ICN-capable attach procedures and use ICN for user 1220 plane traffic, PGW needs to have full ICN protocol stack 1221 functionalities. Typical ICN capabilities include functions such 1222 as content store (CS), Pending Interest Table (PIT), Forwarding 1223 Information Base (FIB) capabilities, and so on. If UE requests 1224 ICN in PCO IE, then PGW registers UE with ICN names. For ICN 1225 forwarding, PGW caches content locally using CS functionality. 1227 5. PCO IE described in [TS24.008] (see Figure 10.5.136 on page 598) 1228 and [TS24.008] (see Table 10.5.154 on page 599) provide details 1229 for different fields. 1231 1. Octet 3 (configuration protocols define PDN types), which 1232 contains details about IPv4, IPv6, both or ICN. 1234 2. Any combination of Octet 4 to Z can be used to provide 1235 additional information related to ICN capability. It is most 1236 important that PCO IE parameters are matched between UE and 1237 mobile gateways (SGW, PGW) so they can be interpreted 1238 properly and the UE can attach successfully. 1240 6. Deployment of ICN functionalities in SGW and PGW should be 1241 matched with UE and eNodeB because they will exchange ICN 1242 protocols and parameters. 1244 7. Mobile gateways SGW, PGW will also need ICN forwarding and 1245 caching capability. This is especially important if CUPS is 1246 implemented. User Plane Function (UPF), comprising the SGW and 1247 PGW user plane, will be located at the edge of the network and 1248 close to the end user. ICN-enabled gateway means that this UPF 1249 would serve as a forwarder and should be capable of caching, as 1250 is the case with any other ICN-enabled node. 1252 8. The transport between PGW and CDN provider can be either IP or 1253 ICN. When UE is attached to PGW with ICN identity and 1254 communicates with an ICN-enabled CDN provider, it will use ICN 1255 primitives to fetch the data. On the other hand, for a UE 1256 attached with an ICN identity, if PGW has to communicate with an 1257 IP- enabled CDN provider, it will have to use an ICN-IP 1258 interworking gateway to perform conversion between ICN and IP 1259 primitives for data retrieval. In the case of CUPS 1260 implementation with an offload close to the edge, this 1261 interworking gateway can be collocated with the UPF at the 1262 offload site to maximize the path optimization. Further study is 1263 required to understand how this ICN-to-IP (and vice versa) 1264 interworking gateway would function. 1266 4.7. Lab Testing 1268 To further test the modifications proposed above in different 1269 scenarios, a simple lab can be set up, as shown in Figure 9. 1271 +------------------------------------------+ 1272 | +-----+ +------+ (```). +------+ | (````). +-----+ 1273 | | SUB |-->| EMU |--(x-haul'.-->| EPC |--->( PDN ).-->| CDN | 1274 | +-----+ +------+ `__..'' +------+ | `__...' +-----+ 1275 +------------------------------------------+ 1277 Figure 9: Native ICN Deployment Lab Setup 1279 The following test scenarios can be set up with VM-based deployment: 1281 1. SUB: ICN simulated client (using ndnSIM), a client application on 1282 workstation requesting content. 1284 2. EMU: test unit emulating eNodeB and UE. This will be a test node 1285 allowing for UE attachment and routing traffic subsequently from 1286 the Subscriber to the Publisher. 1288 3. EPC: Evolved Packet Core in a single instance (such as vPC-SI). 1290 4. CDN: content delivery by a Publisher server. 1292 For the purpose of this testing, ICN emulating code (when available) 1293 can be inserted in the test code in EMU to emulate ICN-capable UE 1294 and/or eNodeB. An example of the code to be used is NS3 in its LTE 1295 model. Effect of such traffic on EPC and CDN can be observed and 1296 documented. In a subsequent phase, EPC code supporting ICN can be 1297 tested when available. 1299 Another option is to simulate the UE/eNodeB and EPC functions using 1300 NS3's LTE [NS3LTE] and EPC [NS3EPC] models respectively. LTE model 1301 includes the LTE Radio Protocol stack, which resides entirely within 1302 the UE and the eNodeB nodes. This capability provides the simulation 1303 of UE and eNodeB deployment use cases. Similarly, EPC model includes 1304 core network interfaces, protocols and entities, which reside within 1305 the SGW, PGW and MME nodes, and partially within the eNodeB nodes. 1307 Even with its current limitations (such as IPv4 only, lack of 1308 integration with ndnSIM, no support for UE idle state), LTE 1309 simulation may be a very useful tool. In any case, both control and 1310 user plane traffic should be tested independently according to the 1311 deployment model discussed in Sections 4.4 through 4.6. 1313 5. Security Considerations 1315 To ensure only authenticated UEs are connected to the network, LTE 1316 mobile network implements various security mechanisms. From the 1317 perspective of ICN deployment in the user plane, it needs to take 1318 care of the following security aspects: 1320 1. UE authentication and authorization 1322 2. Radio or air interface security 1324 3. Denial of service attacks on mobile gateway, services 1326 4. Content positioning either in transport or servers 1328 5. Content cache pollution attacks 1330 6. Secure naming, routing, and forwarding 1332 7. Application security 1334 Security over the LTE air interface is provided through cryptographic 1335 technique. When UE is powered up, it performs key exchange between 1336 UE's USIM and HSS/Authentication Center using NAS messages, including 1337 ciphering and integrity protections between UE and MME. Details of 1338 secure UE authentication, key exchange, ciphering, and integrity 1339 protections messages are given in the 3GPP call flow [TS23.401]. 1341 LTE is an all-IP network and uses IP transport in its mobile backhaul 1342 (between eNodeB and core network). In case of provider-owned 1343 backhaul, it may not implement security mechanisms; however, they are 1344 necessary in case it uses a shared or leased network. The native IP 1345 transport continues to leverage security mechanism such as Internet 1346 key exchange (IKE) and the IP security protocol (IPsec). More 1347 details of mobile backhaul security are provided in 3GPP network 1348 security [TS33.310] and [TS33.320]. When mobile backhaul is upgraded 1349 to support dual stack (IP+ICN) or native ICN, it is required to 1350 implement security techniques that are deployed in mobile backhaul. 1351 When ICN forwarding is enabled on mobile transport routers, we need 1352 to deploy security practices based on [RFC7476] and [RFC7927]. 1354 Some key functions supported by LTE mobile gateway (SGW, PGW) are 1355 content based billing, deep packet inspection (DPI), and lawful 1356 intercept (LI). For ICN-based user plane traffic, it is required to 1357 integrate ICN security for sessions between UE and gateway. However, 1358 in the ICN network, some of the services provided by mobile gateways 1359 mentioned above may not work because only consumers who have 1360 decryption keys can access the content. Further research in this 1361 area is needed. 1363 6. Summary 1365 In this draft, we have discussed complexities of LTE network and key 1366 dependencies for deploying ICN in user plane data transport. 1367 Different deployment options described cover aspects such as inter 1368 operability and multi-technology, which is a reality for any Service 1369 Provider. In Section 4.7, we provide details of an experimental 1370 setup for evaluation of ICN deployment scenarios described in 1371 Section 4.2. One can use LTE gateway software and ICN simulator and 1372 deploy ICN data transport in user plane as an overlay, dual stack (IP 1373 + ICN), hICN, or natively (by integrating ICN with CDN, eNodeB, SGW, 1374 PGW and transport network). Notice that, for deployment scenarios 1375 discussed above, additional study is required for lawful 1376 interception, billing/mediation, network slicing, and provisioning 1377 APIs. 1379 Mobile Edge Computing (MEC) [CHENG] provides capabilities to deploy 1380 functionalities such as Content Delivery Network (CDN) caching and 1381 mobile user plane functions (UPF) [TS23.501]. Recent research for 1382 delivering real-time video content [MPVCICN] using ICN has also been 1383 proven to be efficient [NDNRTC] and can be used towards realizing the 1384 benefits of ICN deployment in eNodeB, MEC, mobile gateways (SGW, PGW) 1385 and CDN. The key aspect for ICN is in its seamless integration in 1386 LTE and 5G networks with tangible benefits so we can optimize content 1387 delivery using simple and scalable architecture. Authors will 1388 continue to explore how ICN forwarding in MEC could be used in 1389 efficient data delivery from the mobile edge. 1391 Based on our study of control plane signaling, it is not beneficial 1392 to deploy ICN with existing protocols unless further changes are 1393 introduced in the control protocol stack itself. As mentioned in 1394 [TS23.501], 5G network architecture proposes simplification of 1395 control plane messages and can be a candidate for use of ICN. 1397 As a starting step towards ICN user plane deployment, it is 1398 recommended to incorporate protocol changes in UE, eNodeB, SGW/PGW 1399 for data transport. ICN has inherent capabilities for mobility and 1400 content caching, which can improve the efficiency of data transport 1401 for unicast and multicast delivery. Authors welcome contributions 1402 and suggestions, including those related to further validations of 1403 the principles by implementing prototype and/or proof of concept in 1404 the lab and in the production environment. 1406 7. Acknowledgements 1408 We thank all contributors, reviewers, and the chairs for the valuable 1409 time in providing comments and feedback that helped improve this 1410 draft. 1412 8. References 1414 8.1. Normative References 1416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1417 Requirement Levels", BCP 14, RFC 2119, 1418 DOI 10.17487/RFC2119, March 1997, 1419 . 1421 [TS24.008] 1422 3GPP, "Mobile radio interface Layer 3 specification; Core 1423 network protocols; Stage 3", 3GPP TS 24.008 3.20.0, 1424 December 2005, 1425 . 1427 [TS25.323] 1428 3GPP, "Packet Data Convergence Protocol (PDCP) 1429 specification", 3GPP TS 25.323 3.10.0, September 2002, 1430 . 1432 [TS29.274] 1433 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 1434 Packet Radio Service (GPRS) Tunneling Protocol for Control 1435 plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0, June 1436 2013, . 1438 [TS29.281] 1439 3GPP, "General Packet Radio System (GPRS) Tunneling 1440 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, 1441 September 2011, 1442 . 1444 [TS36.323] 1445 3GPP, "Evolved Universal Terrestrial Radio Access 1446 (E-UTRA); Packet Data Convergence Protocol (PDCP) 1447 specification", 3GPP TS 36.323 10.2.0, January 2013, 1448 . 1450 8.2. Informative References 1452 [ALM] Auge, J., Carofiglio, G., Grassi, G., Muscariello, L., 1453 Pau, G., and X. Zeng, "Anchor-Less Producer Mobility in 1454 ICN", Proceedings of the 2Nd ACM Conference on 1455 Information-Centric Networking, ACM-ICN'15, ACM DL, 1456 pp.189-190, September 2013, 1457 . 1459 [BROWER] Brower, E., Jeffress, L., Pezeshki, J., Jasani, R., and E. 1460 Ertekin, "Integrating Header Compression with IPsec", 1461 MILCOM 2006 - 2006 IEEE Military Communications 1462 conference IEEE Xplore DL, pp.1-6, October 2006, 1463 . 1465 [CCN] "Content Centric Networking", . 1467 [CHENG] Liang, C., Yu, R., and X. Zhang, "Information-centric 1468 network function virtualization over 5g mobile wireless 1469 networks", IEEE Network Journal vol. 29, number 3, pp. 1470 68-74, June 2015, 1471 . 1473 [EPCCUPS] Schmitt, P., Landais, B., and F. Yong Yang, "Control and 1474 User Plane Separation of EPC nodes (CUPS)", 3GPP The 1475 Mobile Broadband Standard, July 2017, 1476 . 1478 [GALIS] Galis, A., Makhijani, K., Yu, D., and B. Liu, "Autonomic 1479 Slice Networking", draft-galis-anima-autonomic-slice- 1480 networking-05 (work in progress), September 2018. 1482 [GRAYSON] Grayson, M., Shatzkamer, M., and S. Wainner, "Cisco Press 1483 book "IP Design for Mobile Networks"", Cisco 1484 Press Networking Technology series, June 2009, 1485 . 1488 [H2020] H2020, "The POINT Project", . 1490 [HICN] Muscariello, L., Carofiglio, G., Auge, J., and M. 1491 Papalini, "Hybrid Information-Centric Networking", draft- 1492 muscariello-intarea-hicn-01 (work in progress), December 1493 2018. 1495 [ICN5G] Ravindran, R., suthar, P., Trossen, D., and G. White, 1496 "Enabling ICN in 3GPP's 5G NextGen Core Architecture", 1497 draft-ravi-icnrg-5gc-icn-02 (work in progress), July 2018. 1499 [ICNLOWPAN] 1500 Gundogan, C., Schmidt, T., Waehlisch, M., Scherb, C., 1501 Marxer, C., and C. Tschudin, "ICN Adaptation to LowPAN 1502 Networks (ICN LoWPAN)", draft-irtf-icnrg-icnlowpan-02 1503 (work in progress), March 2019. 1505 [ICNQoS] Al-Naday, M., Bontozoglou, A., Vassilakis, G., and M. 1506 Reed, "Quality of Service in an Information-Centric 1507 Network", 2014 IEEE Global Communications Conference IEEE 1508 Xplore DL, pp. 1861-1866, December 2014, 1509 . 1511 [IPoICN] Trossen, D., Read, M., Riihijarvi, J., Georgiades, M., 1512 Fotiou, N., and G. Xylomenos, "IP over ICN - The better 1513 IP?", 2015 European Conference on Networks and 1514 Communications (EuCNC) IEEE Xplore DL, pp. 413-417, June 1515 2015, . 1517 [MBICN] Carofiglio, G., Gallo, M., Muscariello, L., and D. Perino, 1518 "Scalable mobile backhauling via information-centric 1519 networking", The 21st IEEE International Workshop on Local 1520 and Metropolitan Area Networks, Beijing, pp. 1-6, April 1521 2015, . 1523 [MECSPEC] "Mobile Edge Computing (MEC); Framework and Reference 1524 Architecture", ETSI European Telecommunication Standards 1525 Institute (ETSI) MEC specification, March 2016, 1526 . 1529 [MPVCICN] Jangam, A., Ravindran, R., Chakraborti, A., Wan, X., and 1530 G. Wang, "Realtime multi-party video conferencing service 1531 over information centric network", IEEE International 1532 Conference on Multimedia and Expo Workshops (ICMEW) Turin, 1533 Italy, pp. 1-6, June 2015, 1534 . 1536 [NDNRTC] Gusev, P., Wang, Z., Burke, J., Zhang, L., Yoneda, T., 1537 Ohnishi, R., and E. Muramoto, "Real-time Streaming Data 1538 Delivery over Named Data Networking,", IEICE Transactions 1539 on Communications vol. E99.B, pp. 974-991, May 2016, 1540 . 1542 [NGMN] Robson, J., "Data Offloading Techniques in Cellular 1543 Networks: A Survey", Next Generation Mobile Networks, LTE- 1544 Advanced Transport Provisioning, V0.0.14, October 2015, 1545 . 1548 [NS3EPC] Baldo, N., "The ns-3 EPC module", NS3 EPC Model, 1549 . 1552 [NS3LTE] Baldo, N., "The ns-3 LTE module", NS3 LTE Model, 1553 . 1556 [OFFLOAD] Rebecchi, F., Dias de Amorim, M., Conan, V., Passarella, 1557 A., Bruno, R., and M. Conti, "Data Offloading Techniques 1558 in Cellular Networks: A Survey", IEEE Communications 1559 Surveys and Tutorials, IEEE Xplore DL, vol:17, issue:2, 1560 pp.580-603, November 2014, 1561 . 1563 [OLTEANU] Olteanu, A. and P. Xiao, "Fragmentation and AES Encryption 1564 Overhead in Very High-speed Wireless LANs", Proceedings of 1565 the 2009 IEEE International Conference on Communications 1566 ICC'09, ACM DL, pp.575-579, June 2009, 1567 . 1569 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 1570 Guidelines for DiffServ Service Classes", RFC 4594, 1571 DOI 10.17487/RFC4594, August 2006, 1572 . 1574 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 1575 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 1576 Partnership Project (3GPP) Evolved Packet System (EPS)", 1577 RFC 6459, DOI 10.17487/RFC6459, January 2012, 1578 . 1580 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 1581 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 1582 "Information-Centric Networking: Baseline Scenarios", 1583 RFC 7476, DOI 10.17487/RFC7476, March 2015, 1584 . 1586 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 1587 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 1588 "Information-Centric Networking (ICN) Research 1589 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 1590 . 1592 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 1593 Networking (CCNx) Semantics", RFC 8569, 1594 DOI 10.17487/RFC8569, July 2019, 1595 . 1597 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 1598 Networking (CCNx) Messages in TLV Format", RFC 8609, 1599 DOI 10.17487/RFC8609, July 2019, 1600 . 1602 [SDN5G] Page, J. and J. Dricot, "Software-defined networking for 1603 low-latency 5G core network", 2016 International 1604 Conference on Military Communications and Information 1605 Systems (ICMCIS) IEEE Xplore DL, pp. 1-7, May 2016, 1606 . 1608 [TLVCOMP] Mosko, M., "Header Compression for TLV-based Packets", 1609 ICNRG Buenos Aires IETF 95, April 2016, 1610 . 1613 [TS23.203] 1614 3GPP, "Policy and charging control architecture", 3GPP 1615 TS 23.203 10.9.0, September 2013, 1616 . 1618 [TS23.401] 1619 3GPP, "General Packet Radio Service (GPRS) enhancements 1620 for Evolved Universal Terrestrial Radio Access Network 1621 (E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013, 1622 . 1624 [TS23.501] 1625 3GPP, "System Architecture for the 5G System", 3GPP 1626 TS 23.501 15.2.0, June 2018, 1627 . 1629 [TS23.714] 1630 3GPP, "Technical Specification Group Services and System 1631 Aspects: Study on control and user plane separation of EPC 1632 nodes", 3GPP TS 23.714 0.2.2, June 2016, 1633 . 1635 [TS29.060] 1636 3GPP, "General Packet Radio Service (GPRS); GPRS Tunneling 1637 Protocol (GTP) across the Gn and Gp interface", 3GPP 1638 TS 29.060 3.19.0, March 2004, 1639 . 1641 [TS33.310] 1642 3GPP, "Network Domain Security (NDS); Authentication 1643 Framework (AF)", 3GPP TS 33.310 10.7.0, December 2012, 1644 . 1646 [TS33.320] 1647 3GPP, "Security of Home Node B (HNB) / Home evolved Node B 1648 (HeNB)", 3GPP TS 33.320 10.5.0, June 2012, 1649 . 1651 Authors' Addresses 1653 Prakash Suthar 1654 Cisco Systems Inc. 1655 Rosemont, Illinois 1656 USA 1658 Email: psuthar@cisco.com 1660 Milan Stolic 1661 Cisco Systems Inc. 1662 Rosemont, Illinois 1663 USA 1665 Email: mistolic@cisco.com 1667 Anil Jangam (editor) 1668 Cisco Systems Inc. 1669 San Jose, California 1670 USA 1672 Email: anjangam@cisco.com 1674 Dirk Trossen 1675 InterDigital Inc. 1676 London 1677 United Kingdom 1679 Email: Dirk.Trossen@InterDigital.com 1681 Ravishankar Ravindran 1682 Huawei Technologies 1683 Santa Clara, California 1684 USA 1686 Email: ravi.ravindran@huawei.com