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