idnits 2.17.1 draft-irtf-icnrg-icn-lte-4g-01.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 2 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 (July 2, 2018) is 2118 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IPICN' is mentioned on line 757, but not defined == Missing Reference: 'Fig 4' is mentioned on line 832, but not defined == Unused Reference: 'IPSEC1' is defined on line 1342, but no explicit reference was found in the text == Unused Reference: 'NDNPUB' is defined on line 1431, but no explicit reference was found in the text == Unused Reference: 'NDN' is defined on line 1441, but no explicit reference was found in the text == Unused Reference: 'VNIIDX' is defined on line 1448, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 8 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 5 Cisco Systems 6 Dirk Trossen 7 InterDigital Inc. 8 Ravishankar Ravindran 9 Huawei Technologies 11 Expires: January 3, 2019 July 2, 2018 13 Native Deployment of ICN in LTE, 4G Mobile Networks 14 draft-irtf-icnrg-icn-lte-4g-01 16 Abstract 18 LTE, 4G mobile networks use IP based transport for control plane to 19 establish the data session and user plane for actual data delivery. 20 In existing architecture, IP transport used in user plane is not 21 optimized for data transport, which leads to an inefficient data 22 delivery. IP unicast routing from server to clients is used for 23 delivery of multimedia content to User Equipment (UE), where each 24 user gets a separate stream. From bandwidth and routing perspective 25 this approach is inefficient. Multicast and broadcast technologies 26 have emerged recently for mobile networks, but their deployments are 27 very limited or at an experimental stage due to complex architecture 28 and radio spectrum issues. ICN is a rapidly emerging technology with 29 built-in features for efficient multimedia data delivery, however 30 majority of the work is focused on fixed networks. The main focus of 31 this draft is on native deployment of ICN in cellular mobile networks 32 by using ICN in 3GPP protocol stack. ICN has an inherent capability 33 for multicast, anchorless mobility, security and it is optimized for 34 data delivery using local caching at the edge. The proposed 35 approaches in this draft allow ICN to be enabled natively over the 36 current LTE stack comprising of PDCP/RLC/MAC/PHY or in a dual stack 37 mode (along with IP) help optimize the mobile networks by leveraging 38 the inherent benefits of ICN. 40 Status of this Memo 42 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 47 other groups may also distribute working documents as 48 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 56 http://www.ietf.org/1id-abstracts.html 58 The list of Internet-Draft Shadow Directories can be accessed at 59 http://www.ietf.org/shadow.html 61 Copyright and License Notice 63 Copyright (c) 2017 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.2 3GPP Terminology and Concepts . . . . . . . . . . . . . . . 4 81 2. LTE, 4G Mobile Network . . . . . . . . . . . . . . . . . . . . 8 82 2.1 Network Overview . . . . . . . . . . . . . . . . . . . . . 8 83 2.2 QoS Challenges . . . . . . . . . . . . . . . . . . . . . . 9 84 2.3 Data Transport Using IP . . . . . . . . . . . . . . . . . . 11 85 2.4 Virtualizing Mobile Networks . . . . . . . . . . . . . . . 11 86 3. Data Transport Using ICN . . . . . . . . . . . . . . . . . . . 12 87 4. ICN Deployment in 4G and LTE Networks . . . . . . . . . . . . 14 88 4.1 General ICN Deployment Considerations . . . . . . . . . . . 14 89 4.2 ICN Deployment Scenarios . . . . . . . . . . . . . . . . . . 15 90 4.3 ICN Deployment in LTE Control Plane . . . . . . . . . . . . 17 91 4.4 ICN Deployment in LTE User Plane . . . . . . . . . . . . . 19 92 4.4.1 Dual stack ICN Deployments in UE . . . . . . . . . . . 19 93 4.4.2 Native ICN Deployments in UE . . . . . . . . . . . . . 22 94 4.5 ICN Deployment in eNodeB . . . . . . . . . . . . . . . . . 23 95 4.6 ICN Deployment in Packet Core (SGW, PGW) Gateways . . . . . 25 96 4.7 Lab Testing . . . . . . . . . . . . . . . . . . . . . . . . 27 97 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 27 98 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 99 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 100 7.1 Normative References . . . . . . . . . . . . . . . . . . . 30 101 7.2 Informative References . . . . . . . . . . . . . . . . . . 31 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 104 1 Introduction 106 LTE mobile technology is built as all-IP network. It uses IP routing 107 protocols such as OSPF, ISIS, BGP etc. to establish network routes to 108 route the data traffic to end user's device. Stickiness of IP address 109 to a device is the key to get connected to a mobile network and the 110 same IP address is maintained through the session until the device 111 gets detached or moves to another network. 113 One of the key protocols used in 4G and LTE networks is GPRS 114 Tunneling protocol (GTP). GTP, DIAMETER and other protocols are built 115 on top of IP. One of the biggest challenges with IP based routing is 116 that it is not optimized for data transport although it is the most 117 efficient communication protocol. By native implementation of 118 Information Centric Networking (ICN) in 3GPP, we can re-architect 119 mobile network and optimize its design for efficient data transport 120 by leveraging the caching feature of ICN. ICN also offers an 121 opportunity to leverage inherent capabilities of multicast, 122 anchorless mobility management, and authentication. This draft 123 provides insight into different options for deploying ICN in mobile 124 networks and how they impact mobile providers and end-users. 126 1.1 Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 1.2 3GPP Terminology and Concepts 134 Access Point Name 136 The Access Point Name (APN) is a Fully Qualified Domain Name 137 (FQDN) and resolves to a set of gateways in an operator's network. 138 APN identifies the packet data network (PDN) that a mobile data 139 user wants to communicate with. In addition to identifying a PDN, 140 an APN may also be used to define the type of service, QoS and 141 other logical entities inside GGSN, PGW. 143 Control Plane 145 The control plane carries signaling traffic and is responsible for 146 routing between eNodeB and MME, MME and HSS, MME and SGW, SGW and 147 PGW etc. Control plane signaling is required to authenticate and 148 authorize UE and establish mobility session with mobile gateways 149 (SGW/PGW). Functions of the control plane also include system 150 configuration and management. 152 Dual Address PDN/PDP Type 154 The dual address Packet Data Network/Packet Data Protocol 155 (PDN/PDP) Type (IPv4v6) is used in 3GPP context in many cases as a 156 synonym for dual-stack, i.e. a connection type capable of serving 157 both IPv4 and IPv6 simultaneously. 159 eNodeB 161 The eNodeB is a base station entity that supports the Long-Term 162 Evolution (LTE) air interface. 164 Evolved Packet Core 166 The Evolved Packet Core (EPC) is an evolution of the 3GPP GPRS 167 system characterized by a higher-data-rate, lower-latency, packet- 168 optimized system. The EPC comprises some of the sub components of 169 the EPS core such as Mobility Management Entity (MME), Serving 170 Gateway (SGW), Packet Data Network Gateway (PDN-GW), and Home 171 Subscriber Server (HSS). 173 Evolved Packet System 175 The Evolved Packet System (EPS) is an evolution of the 3GPP 176 GPRSsystem characterized by a higher-data-rate, lower-latency, 177 packet-optimized system that supports multiple Radio Access 178 Technologies (RATs). The EPS comprises the EPC together with the 179 Evolved Universal Terrestrial Radio Access (E-UTRA) and the 180 Evolved Universal Terrestrial Radio Access Network (E-UTRAN). 182 Evolved UTRAN The Evolved UTRAN (E-UTRAN) is a communications 183 network, sometimes referred to as 4G, and consists of eNodeBs (4G 184 base stations). The E-UTRAN allows connectivity between the User 185 Equipment and the core network. 187 GPRS Tunnelling Protocol 189 The GPRS Tunnelling Protocol (GTP) [TS.29060] [TS.29274] 190 [TS.29281] is a tunnelling protocol defined by 3GPP. It is a 191 network-based mobility protocol and is similar to Proxy Mobile 192 IPv6 (PMIPv6). However, GTP also provides functionality beyond 193 mobility, such as in-band signaling related to Quality of Service 194 (QoS) and charging, among others. 196 Gateway GPRS Support Node 198 The Gateway GPRS Support Node (GGSN) is a gateway function in the 199 GPRS and 3G network that provides connectivity to the Internet or 200 other PDNs. The host attaches to a GGSN identified by an APN 201 assigned to it by an operator. The GGSN also serves as the 202 topological anchor for addresses/prefixes assigned to the User 203 Equipment. 205 General Packet Radio Service 207 The General Packet Radio Service (GPRS) is a packet-oriented 208 mobile data service available to users of the 2G and 3G cellular 209 communication systems -- the GSM -- specified by 3GPP. 211 Home Subscriber Server 213 The Home Subscriber Server (HSS) is a database for a given 214 subscriber and was introduced in 3GPP Release-5. It is the entity 215 containing the subscription-related information to support the 216 network entities actually handling calls/sessions. 218 Mobility Management Entity 220 The Mobility Management Entity (MME) is a network element that is 221 responsible for control-plane functionalities, including 222 authentication, authorization, bearer management, layer-2 223 mobility, etc. The MME is essentially the control-plane part of 224 the SGSN in the GPRS. The user-plane traffic bypasses the MME. 226 Public Land Mobile Network 228 The Public Land Mobile Network (PLMN) is a network that is 229 operated by a 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 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 control 239 (e.g., gating control, QoS control, and QoS signaling). It is 240 optional to 3GPP EPS but needed if dynamic policy and charging 241 control by means of PCC rules based on user and services are 242 desired. 244 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 accesses 249 services in one or more PDNs. The operator's packet core networks 250 are separated from packet data networks either by GGSNs or PDN 251 Gateways (PGWs). 253 Serving Gateway 255 The Serving Gateway (SGW) is a gateway function in the EPS, which 256 terminates the interface towards the E-UTRAN. The SGW is the 257 Mobility Anchor point for layer-2 mobility (inter-eNodeB 258 handovers). For each UE connected with the EPS, at any given 259 point in time, there is only one SGW. The SGW is essentially the 260 user-plane part of the GPRS's SGSN. 262 Packet Data Network Gateway 264 The Packet Data Network Gateway (PGW) is a gateway function in the 265 Evolved Packet System (EPS), which provides connectivity to the 266 Internet or other PDNs. The host attaches to a PGW identified by 267 an APN assigned to it by an operator. The PGW also serves as the 268 topological anchor for addresses/prefixes assigned to the User 269 Equipment. 271 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 using 275 a specific gateway. 277 Packet Data Protocol Type 279 A Packet Data Protocol Type (PDP Type) identifies the used/allowed 280 protocols within the PDP context. Examples are IPv4, IPv6, and 281 IPv4v6 (dual-stack). 283 Serving GPRS Support Node 285 The Serving GPRS Support Node (SGSN) is a network element that is 286 located between the radio access network (RAN) and the gateway 287 (GGSN). A per-UE point-to-point (p2p) tunnel between the GGSN and 288 SGSN transports the packets between the UE and the gateway. 290 Terminal Equipment 292 The Terminal Equipment (TE) is any device/host connected to the 293 Mobile Terminal (MT) offering services to the user. A TE may 294 communicate to an MT, for example, over the Point to Point 295 Protocol (PPP). 297 UE, MS, MN, and Mobile 299 The terms UE (User Equipment), MS (Mobile Station), MN (Mobile 300 Node), and mobile refer to the devices that are hosts with the 301 ability to obtain Internet connectivity via a 3GPP network. A MS 302 is comprised of the Terminal Equipment (TE) and a Mobile Terminal 303 (MT). The terms UE, MS, MN, and mobile are used interchangeably 304 within this document. 306 User Plane 308 The user plane refers to data traffic and the required bearers for 309 the data traffic. In practice, IP is the only data traffic 310 protocol used in the user plane. 312 2. LTE, 4G Mobile Network 314 2.1 Network Overview 316 With the introduction of LTE, mobile networks moved to all-IP 317 transport for all elements such as eNodeB, MME, SGW/PGW, HSS, PCRF, 318 routing and switching etc. Although LTE network is data-centric, it 319 has support for legacy Circuit Switch features like voice and SMS 320 through transitional CS fallback and flexible IMS deployment 321 [GRAYSON]. For each mobile device attached to the radio (eNodeB) 322 there is a separate overlay tunnel (GPRS Tunneling Protocol, GTP) 323 between eNodeB and Mobile gateways (i.e. SGW, PGW). 325 The GTP tunnel is used to carry user traffic between gateways and 326 mobile devices, this forces data to be only distributed using unicast 327 mechanism. It is also important to understand the overhead of a GTP 328 and IPSec protocols because it has impact on the carried user data 329 traffic. All mobile backhaul traffic is encapsulated using GTP 330 tunnel, which has overhead of 8 bytes on top of IP and UDP [NGMN]. 331 Additionally, if IPSec is used for security (which is often required 332 if the Service provider is using a shared backhaul), it adds overhead 333 based upon IPSec tunneling model (tunnel or transport), and 334 encryption and authentication header algorithm used. If we factor 335 Advanced Encryption Standard (AES) encryption with the packet size, 336 the overhead can be significant, particularly for the smaller 337 payloads [IPSEC2]. 339 When any UE is powered up, it attaches to a mobile network based on 340 its configuration and subscription. After successful attach 341 procedure, UE registers with the mobile core network and IPv4 and/or 342 IPv6 address is assigned. A default bearer is created for each UE and 343 it is assigned to default Access Point Name (APN). 345 +-------+ Diameter +-------+ 346 | HSS |------------| SPR | 347 +-------+ +-------+ 348 | | 349 +------+ +------+ S4 | +-------+ 350 | 3G |---| SGSN |----------------|------+ +------| PCRF | 351 ^ |NodeB | | |---------+ +---+ | | +-------+ 352 +-+ | +------+ +------+ S3 | | S6a | |Gxc | 353 | | | +-------+ | | |Gx 354 +-+ | +------------------| MME |------+ | | | 355 UE v | S1MME +-------+ S11 | | | | 356 +----+-+ +-------+ +-------+ 357 |4G/LTE|------------------------------| SGW |-----| PGW | 358 |eNodeB| S1U +-------+ +--| | 359 +------+ | +-------+ 360 +---------------------+ | | 361 S1U GTP Tunnel traffic | +-------+ | | 362 S2a GRE Tunnel traffic |S2A | ePDG |-------+ | 363 S2b GRE Tunnel traffic | +-------+ S2B |SGi 364 SGi IP traffic | | | 365 +---------+ +---------+ +-----+ 366 | Trusted | |Untrusted| | CDN | 367 |non-3GPP | |non-3GPP | +-----+ 368 +---------+ +---------+ 369 | | 370 +-+ +-+ 371 | | | | 372 +-+ +-+ 373 UE UE 375 Figure-1: LTE, 4G Mobile Network Overview 377 The data delivered to mobile devices is unicast inside GTP tunnel. If 378 we consider combined impact of GTP, IPSec and unicast traffic, the 379 data delivery is not efficient. IETF has developed various header 380 compression algorithms to reduce the overhead associated with IP 381 packets. Some of techniques are robust header compression (ROHC) and 382 enhanced compression of the real-time transport protocol (ECRTP) so 383 that impact of overhead created by GTP, IPsec etc. is reduced to some 384 extent [BROWER]. For commercial mobile networks, 3GPP has adopted 385 different mechanisms for header compression to achieve efficiency in 386 data delivery [TS25.323], and can be adapted to ICN as well. 388 2.2 QoS Challenges 390 During attach procedure, default bearer is created for each UE and it 391 is assigned to the default Access Point Name (APN). The QoS values 392 uplink and downlink bandwidth assigned during initial attach are 393 minimal. Additional dedicated bearer(s) with enhanced QoS parameters 394 is established depending on the 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 depending on the application key parameters, such 400 as latency, jitter (important for voice and other real-time 401 applications), packet loss and queuing mechanism (strict priority, 402 low-latency, fair etc.) can be very different. 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 2 407 as class of service (CoS) and at layer 3 either as DiffServ code 408 point (DSCP) or type of service (ToS). The mapping of CoS to DSCP 409 takes place at layer 2/3 switching and routing elements. 3GPP has 410 specified QoS Class Identifier (QCI) which represents different types 411 of content and equivalent mapping to DSCP at transport layer 412 [TS23.203] [TS23.401]; however, this again requires manual 413 configuration at different elements and if there is misconfiguration 414 at any place in the path it will not work properly. 416 In summary QoS configuration for mobile network for user plane (for 417 user traffic) and transport in IP based mobile network is complex and 418 it 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 poor 422 subscriber experience (e.g. packet classified as high-priority can go 423 to lower priority queue). By deploying ICN, we intend to enhance the 424 subscriber experience using policy based configuration, which can be 425 associated with the named contents [ICNQoS] at ICN forwarder. Further 426 investigation is needed to understand how QoS in ICN can be 427 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 (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 a eNodeB to a PDN gateway (PGW), as described in 3GPP 443 specifications [TS23.401]. While the technology exists to address the 444 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 but they could be addressed at the IP transport 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 network 495 slicing with control and user plane separation provide mechanism to 496 evolve GTP-based architecture to open-flow SDN-based signaling for 497 LTE and proposed 5G core. Some of early architecture work for 5G 498 mobile technologies provides mechanism for control and user plane 499 separation and simplifies mobility call flow by introduction of open- 500 flow based signaling [5GICN]. This has been considered by 3GPP 501 [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 Fig. 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 also cache the content so that it can 552 be delivered locally for subsequent request from any other client. 553 For 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 Fig. 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 [CCNxTLV] and contains mandatory fields 587 such as name of the content and content matching restrictions 588 (KeyIdRestr and ContentObjectHashRestr) forming the tuple [CCNxSem]. 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 First 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 three 599 data structures, namely Pending Interest Table (PIT), Forwarding 600 Information Base (FIB), and Content Store (CS). The Interest packet 601 travels hop-by-hop towards content provider. Once the Interest 602 reaches the content provider it will return a Data packet containing 603 information such as content name, signature, signed key and data. 605 Data packet travels in reverse direction following the same path 606 taken by the interest packet so routing symmetry is maintained. 607 Details about algorithms used in PIT, FIB, CS and security trust 608 models are described in various resources [CCN], here we explained 609 the concept and its applicability to the LTE network. 611 4. ICN Deployment in 4G and LTE Networks 613 4.1 General ICN Deployment Considerations 615 In LTE/4G mobile networks, both user and control plane traffic have 616 to be transported from the edge to the mobile packet core via IP 617 transport. The evolution of existing mobile packet core using CUPS 618 [TS23.714] enables flexible network deployment and operation, by 619 distributed deployment and the independent scaling between control 620 plane and user plane functions - while not affecting the 621 functionality of the existing nodes subject to this split. 623 In the CUPS architecture, there is an opportunity to shorten the path 624 for user plane traffic by deploying offload nodes closer to the edge 625 [OFFLOAD]. With this major architecture change, User Plane Function 626 (UPF) node is placed close to the edge so traffic no longer needs to 627 traverse the entire backhaul path to reach the EPC. In many cases, 628 where feasible, UPF can be collocated with the eNodeB, which is also 629 a business decision based on the user demand. Placing a Publisher 630 close to the offload site, or at the offload site, provides for a 631 significant improvement in user experience, especially with the 632 latency-sensitive applications. This optimization allows for the 633 introduction of ICN and amplifies its advantages. This section 634 analyzes the potential impact of ICN on control and user plane 635 traffic for centralized and disaggregate CUPS based mobile network 636 architecture. 638 4.2 ICN Deployment Scenarios 640 Deployment of ICN provides an opportunity to further optimize the 641 existing data transport in LTE/4G mobile networks. The various 642 deployment options that ICN and IP provide are somewhat analogous to 643 the deployment scenarios when IPv6 was introduced to inter operate 644 with IPv4, except with ICN the whole IP stack is being replaced. We 645 have reviewed [RFC6459] and analyzed the impact of ICN on control 646 plane signaling and user plane data delivery. In general ICN can be 647 deployed natively replacing IP transport (IPv4 and IPv6) or as an 648 overlay protocol. Figure 4 describes a modified protocol stack to 649 support ICN deployment scenarios. 651 +----------------+ +-----------------+ 652 | ICN App (new) | |IP App (existing)| 653 +---------+------+ +-------+---------+ 654 | | 655 +---------+----------------+---------+ 656 | Transport Convergence Layer (new) | 657 +------+---------------------+-------+ 658 | | 659 +------+------+ +------+-------+ 660 |ICN function | | IP function | 661 | (New) | | (Existing) | 662 +------+------+ +------+-------+ 663 | | 664 (```). (```). 665 ( ICN '`. ( IP '`. 666 ( Cloud ) ( Cloud ) 667 ` __..'+' ` __..'+' 669 Fig. 4. IP/ICN Convergence and Deployment Scenarios 671 As shown in figure 4, for applications running either in UE or in 672 content provider system to use the new transport option, we propose a 673 new transport convergence layer (TCL). This transport convergence 674 layer helps determine what type of transport (e.g. ICN or IP), as 675 well as type of radio interface (e.g. LTE or WiFi or both), is used 676 to send and receive the traffic based on preference e.g. content 677 location, content type, content publisher, congestion, cost, quality 678 of service etc. It helps to configure and decide the type of 679 connection as well as the overlay mode (ICNoIP or IPoICN) between 680 application and the protocol stack (IP or ICN) to be used. 682 The ICN function together with existing IP function provides the 683 support for either native ICN and/or the dual stack (ICN/IP) 684 transport functionality. More elaborate description on these 685 functional layers is provided in Section 4.4.1. 687 TCL can use a number of mechanisms for the selection of transport. It 688 can use a per application configuration through a management 689 interface, possibly even a user-facing setting realized through a 690 user interface, similar to those used today that select cellular over 691 WiFi being used for selected applications. In another option, it 692 might use a software API, which an adapted IP application could use 693 to specify e.g. an ICN transport for obtaining its benefits. 695 Another potential application of TCL is in implementation of network 696 slicing, where it can have a slice management capability locally or 697 it can interface to an external slice manager through an API [GALIS]. 698 This solution can enable network slicing for IP and ICN transport 699 selection from the UE itself. The TCL could apply slice settings to 700 direct certain traffic (or applications) over one slice and others 701 over another slice, determined by some form of 'slicing policy'. 702 Slicing policy can be obtained externally from slice manager or 703 configured locally on UE. 705 From the perspective of the applications either on UE or content 706 provider, four different options are possible for the deployment of 707 ICN natively and/or with IP. 709 1. IP over IP 711 In this scenario UE uses applications tightly integrated with 712 the existing IP transport infrastructure. In this option, the 713 TCL has no additional function since the packets are directly 714 forwarded using IP protocol stack, which in turn sends the 715 packets over the IP transport. 717 2. ICN over ICN 719 Similar to case 1 above, ICN applications tightly integrate 720 with the ICN transport infrastructure. The TCL has no 721 additional responsibility since the packets are directly 722 forwarded using ICN protocol stack, which in turn sends the 723 packets over the ICN transport. 725 3. ICN over IP (ICNoIP) 727 In ICN over IP scenario, the underlying IP transport 728 infrastructure is not impacted (i.e. ICN is implemented, as an 729 IP overlay, between user equipment (UE) and content provider). 730 IP routing is used from Radio Access Network (eNodeB) to mobile 731 backhaul, IP core and Mobile Gateway (SGW/PGW). UE attaches to 732 Mobile Gateway (SGW/PGW) using IP address. Also, the data 733 transport between Mobile Gateway (SGW/PGW) and content 734 publisher uses IP. Content provider is capable of serving 735 content either using IP or ICN, based on UE request. 737 An alternative approach to implement ICN over IP is provided in 738 Hybrid ICN [HICN], which implements ICN over IP by mapping of 739 ICN names to the IPv4/IPv6 addresses. 741 Detailed deployment of use cases is described in section 4.4. 742 Application conveys the preference to the TCL, which in turn 743 sends the ICN data packets using the IP transport. 745 4. IP over ICN (IPoICN) 747 H2020 project [H2020] provides an architectural framework for 748 deployment of IP as an overlay over ICN protocol [IPoICN]. 749 Implementing IP services over ICN provides an opportunity 750 leveraging benefit of ICN in the transport infrastructure and 751 there is no impact on end devices (UE and access network) as 752 they continue to use IP. IPoICN however, will require an inter- 753 working function (IWF/Border Gateway) to translate various 754 transport primitives such as transport of tunnel mode. IWF 755 function will provide a mechanism for protocol translation 756 between IPoICN and native IP deployment for mobile network. 757 After reviewing [IPICN], we understand and interpret that ICN 758 is implemented in the transport natively; however, IP is 759 implemented in UE, eNodeB, and Mobile gateway (SGW/PGW), which 760 is also called as network attach point (NAP). 762 4.3 ICN Deployment in LTE Control Plane 764 In this section we analyze signaling messages which are required for 765 different procedures, such as attach, handover, tracking area update 766 etc. The goal of analysis is to see if there is any benefit to 767 replace IP-based protocols with ICN for LTE signaling in the current 768 architecture. It is important to understand the concept of point of 769 attachment (POA). When UE connects to a network it has at least three 770 POAs: 772 1. eNodeb managing location or physical POA 773 2. Authentication and Authorization (MME, HSS) managing identity 774 or authentication POA 776 3. Mobile Gateways (SGW, PGW) managing logical or session 777 management POA. 779 In current architecture IP transport is used for all the messages 780 associated with Control Plane for mobility and session management. IP 781 is embedded very deeply into these messages and TLV carrying 782 additional attributes as a layer 3 transport . Physical POA in eNodeB 783 handles both mobility and session management for any UE attached to 784 4G, LTE network. The number of mobility management messages between 785 different nodes in an LTE network per signaling procedure are given 786 below in figure 5. 788 Normally two types of UE devices attach to LTE network: SIM based 789 (need 3GPP mobility protocol for authentication) or non-SIM based 790 (which connect to WiFi network), and authentication is required for 791 both of these device types. For non-SIM based devices, AAA is used 792 for authentication. We do not propose to change UE authentication or 793 mobility management messaging for user data transport using ICN. A 794 separate study would be required to analyze impact of ICN on mobility 795 management messages structures and flows. We are merely analyzing the 796 viability of implementing ICN as a transport for Control plane 797 messages. 799 It is important to note that even if MME and HSS do not support ICN 800 transport, they still need to support UE capable of dual stack or 801 native ICN. When UE initiates attach request using the identity as 802 ICN, MME must be able to parse that message and create a session. MME 803 forwards UE authentication to HSS so HSS must be able to authenticate 804 an ICN capable UE and authorize create session [TS23.401]. 806 +---------------------------+-------+-------+-------+-------+------+ 807 | LTE Signaling Procedures | MME | HSS | SGW | PGW | PCRF | 808 +------------------------------------------------------------------+ 809 | Attach | 10 | 2 | 3 | 2 | 1 | 810 | Additional default bearer | 4 | 0 | 3 | 2 | 1 | 811 | Dedicated bearer | 2 | 0 | 2 | 2 | 1 | 812 | Idle-to-connect | 3 | 0 | 1 | 0 | 0 | 813 | Connect-to-Idle | 3 | 0 | 1 | 0 | 0 | 814 | X2 handover | 2 | 0 | 1 | 0 | 0 | 815 | S1 handover | 8 | 0 | 3 | 0 | 0 | 816 | Tracking area update | 2 | 0 | 0 | 0 | 0 | 817 | Total | 34 | 2 | 14 | 6 | 3 | 818 +---------------------------+-------+-------+-------+-------+------+ 820 Fig. 5. Signaling Messages in LTE Gateways 822 Anchorless mobility [ALM] has made some important comments on how 823 mobility management is done in ICN. Author comments about handling 824 mobility without having a dependency on the core network function 825 e.g. MME. However, location update to the core network would still be 826 required to support some of the legal compliance requirements such as 827 lawful intercept and emergency services. 829 The main advantage of ICN is in caching and reusing the content, 830 which does not apply to the transactional signaling exchange. After 831 analyzing LTE signaling call flows [TS23.401] and messages inter- 832 dependencies [Fig 4], our recommendation is that it is not beneficial 833 to deploy ICN for control plane and mobility management functions. 835 4.4 ICN Deployment in LTE User Plane 837 We will consider figure 1 to discuss different mechanisms to deploy 838 ICN in mobile networks. In section 4.2 we discussed generic 839 deployment scenarios of ICN. In this section, we shall see the 840 specific use cases of native ICN deployment in LTE user plane. We 841 consider the following options: 843 1. Dual stack ICN deployment in UE 845 2. Native ICN Deployments in UE 847 3. ICN Deployment in eNodeB 849 4. ICN Deployment in mobile gateways (SGW/PGW) 851 4.4.1 Dual stack ICN Deployments in UE 853 The control and user plane communications in LTE, 4G mobile networks 854 are specified in 3GPP documents [TS23.203] [TS23.401]. It is 855 important to understand that UE can be either consumer (receiving 856 content) or publisher (pushing content for other clients). The 857 protocol stack inside mobile device (UE) is complex as it has to 858 support multiple radio connectivity access to eNodeB(s). 860 Figure 6 provides high level description of a protocol stack, where 861 IP is defined at two layers: (1) at user plane communication, (2) 862 Transport layer. User plane communication takes place between Packet 863 Data Convergence Protocol (PDCP) and Application layer, whereas 864 transport layer is at GTP protocol stack. 866 The protocol interactions and impact of supporting tunneling of ICN 867 packet into IP or to support ICN natively are described in figure 6 868 and figure 7 respectively. 870 +--------+ +--------+ 871 | App | | CDN | 872 +--------+ +--------+ 873 |Transp. | | | | |Transp. | 874 |Converg.| |..............|...............|............|.|Converge| 875 +--------+ | | | +--------+ | +--------+ 876 | |.|..............|...............|.| |.|.| | 877 | ICN/IP | | | | | ICN/IP | | | ICN/IP| 878 | | | | | | | | | | 879 +--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+ 880 | |.|.| | |.|.| | |.|.| | | | | | 881 | PDCP | | |PDCP|GTP-U| | |GTP-U|GTP-U| | |GTP-U| | | | L2 | 882 +--------+ | +----------+ | +-----------+ | +-----+ | | | | 883 | RLC |.|.|RLC | UDP |.|.| UDP | UDP |.|.|UDP |L2|.|.| | 884 +--------+ | +----------+ | +-----------+ | +-----+ | | | | 885 | MAC |.|.| MAC| L2 |.|.| L2 | L2 |.|.| L2 | | | | | 886 +--------+ | +----------+ | +-----------+ | +--------+ | +--------+ 887 | L1 |.|.| L1 | L1 |.|.| L1 | L1 |.|.| L1 |L1|.|.| L1 | 888 +--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+ 889 UE | BS(enodeB) | SGW | PGW | 890 Uu S1U S5/S8 SGi 892 Fig. 6. Dual stack ICN Deployment in UE 894 The protocols and software stack used inside LTE capable UE support 895 both 3G and LTE software interworking and handover. Latest 3GPP 896 Rel.13 onward specification describes the use of IP and non-IP 897 protocols to establish logical/session connectivity. We intend to 898 leverage the non-IP protocol based mechanism to deploy ICN protocol 899 stack in UE as well as in eNodeB and mobile gateways (SGW, PGW). 901 1. Existing application layer can be modified to provide options 902 for new ICN based application and existing IP based 903 applications. UE can continue to support existing IP based 904 applications or host new applications developed either to 905 support native ICN as transport, ICNoIP or IPoICN based 906 transport. Application layer has the option of selecting either 907 ICN or IP transport layer as well as radio interface to send 908 and receive data traffic. 910 Our proposal is to provide a common Application Programming 911 Interface (API) to the application developers such that there 912 is no impact on the application development when they choose 913 either ICN or IP transport for exchanging the traffic with the 914 network. As mentioned in section 4.2, the transport convergence 915 layer (TCL) function handles the interaction of application 916 with the multiple transport options. 918 2. The transport convergence layer helps determine what type of 919 transport (e.g. ICN or IP) as well as type of radio interface 920 (e.g. LTE or WiFi or both), is used to send and receive the 921 traffic. Application layer can make the decision to select a 922 specific transport based on preference e.g. content location, 923 content type, content publisher, congestion, cost, quality of 924 service etc. There can be an Application Programming Interface 925 (API) to exchange parameters required for transport selection. 926 The southbound interactions of Transport Convergence Layer 927 (TCL) will be either to IP or ICN at the network layer. 929 +----------------+ +-----------------+ 930 | ICN App (new) | |IP App (existing)| 931 +---------+------+ +-------+---------+ 932 | | 933 +---------+----------------+---------+ 934 | Transport Convergence Layer (new) | 935 +------+---------------------+-------+ 936 | | 937 +------+------+ +------+-------+ 938 |ICN function | | IP function | 939 | (New) | | (Existing) | 940 +------+------+ +------+-------+ 941 | | 942 +------+---------------------+-------+ 943 | PDCP (updated to support ICN) | 944 +-----------------+------------------+ 945 | 946 +-----------------+------------------+ 947 | RLC (Existing) | 948 +-----------------+------------------+ 949 | 950 +-----------------+------------------+ 951 | MAC Layer (Existing) | 952 +-----------------+------------------+ 953 | 954 +-----------------+------------------+ 955 | Physical L1 (Existing) | 956 +------------------------------------+ 958 Fig. 7. Dual stack ICN protocol interactions 960 3. ICN function (forwarder) is introduced in parallel to the 961 existing IP layer. ICN forwarder contains functional 962 capabilities to forward ICN packets, e.g. Interest packet to 963 eNodeB or response "data packet" from eNodeB to the 964 application. 966 4. For dual stack scenario, when UE is not supporting ICN at 967 transport layer, we use IP underlay to transport ICN packets. 968 ICN function will use IP interface to send Interest and Data 969 packets for fetching or sending data using ICN protocol 970 function. This interface will use ICN overlay over IP using any 971 overlay tunneling mechanism. 973 5. To support ICN at network layer in UE, PDCP layer has to be 974 aware of ICN capabilities and parameters. PDCP is located in 975 the Radio Protocol Stack in the LTE Air interface, between IP 976 (Network layer) and Radio Link Control Layer (RLC). PDCP 977 performs following functions [TS36.323]: 979 a) Data transport by listening to upper layer, formatting and 980 pushing down to Radio Link Layer (RLC) 982 b) Header compression and decompression using ROHC (Robust 983 Header Compression) 985 c) Security protections such as ciphering, deciphering and 986 integrity protection 988 d) Radio layer messages associated with sequencing, packet drop 989 detection and re-transmission etc. 991 6. No changes are required for lower layer such as RLC, MAC and 992 Physical (L1) because they are not IP aware. 994 One key point to understand in this scenario is that ICN is deployed 995 as an overlay on top of IP. 997 4.4.2 Native ICN Deployments in UE 999 We propose to implement ICN natively in UE by modifying PDCP layer in 1000 3GPP protocols. Figure 8 provides a high-level protocol stack 1001 description where ICN is used at two different layers: 1003 1. at user plane communication 1005 2. at transport layer 1007 User plane communication takes place between PDCP and application 1008 layer, whereas transport layer is a substitute of GTP protocol. 1009 Removal of GTP protocol stack is significant change in mobile 1010 architecture because GTP is used not just for routing but for 1011 mobility management functions such as billing, mediation, policy 1012 enforcement etc. 1014 If we implement ICN natively in UE, communication between UE and 1015 eNodeB will change. Also, this will avoid tunneling the user plane 1016 traffic from eNodeB to mobile packet core (SGW, PGW) using GTP 1017 tunnel. 1019 For native ICN deployment, an application will be configured to use 1020 ICN forwarder so there is no need for Transport Convergence. Also to 1021 support ICN at network layer in UE, we need to modify existing PDCP 1022 layer. PDCP layer has to be aware of ICN capabilities and parameters. 1024 Native implementation will also provide opportunities to develop new 1025 use cases leveraging ICN capabilities such as seamless mobility, UE 1026 to UE content delivery using radio network without traversing the 1027 mobile gateways, etc. 1029 +--------+ +--------+ 1030 | App | | CDN | 1031 +--------+ +--------+ 1032 |Transp. | | | | | |Transp. | 1033 |Converge|.|..............|..............|..............|.|Converge| 1034 +--------+ | | | | +--------+ 1035 | |.|..............|..............|..............|.| | 1036 | ICN/IP | | | | | | | 1037 | | | | | | | | 1038 +--------+ | +----+-----+ | +----------+ | +----------+ | | ICN/IP | 1039 | |.|.| | | | | | | | | | | | 1040 | PDCP | | |PDCP| ICN |.|.| ICN |.|.| ICN |.|.| | 1041 +--------+ | +----+ | | | | | | | | | | 1042 | RLC |.|.|RLC | | | | | | | | | | | 1043 +--------+ | +----------+ | +----------+ | +----------+ | +--------+ 1044 | MAC |.|.| MAC| L2 |.|.| L2 |.|.| L2 |.|.| L2 | 1045 +--------+ | +----------+ | +----------+ | +----------+ | +--------+ 1046 | L1 |.|.| L1 | L1 |.|.| L1 |.|.| L1 |.|.| L1 | 1047 +--------+ | +----+-----+ | +----------+ | +----------+ | +--------+ 1048 UE | BS(enodeB) | SGW | PGW | 1049 Uu S1u S5/S8 SGi 1051 Fig. 8. Native ICN Deployment in UE 1053 4.5 ICN Deployment in eNodeB 1055 eNodeB is physical point of attachment for UE, where radio protocols 1056 are converted into IP transport protocol as depicted in figure 7 and 1057 figure 8 for dual stack/overlay and native ICN respectively. When UE 1058 performs attach procedures, it is assigned an identity either as IP, 1059 dual stack (IP and ICN), or ICN. UE can initiate data traffic using 1060 any of three different options: 1062 1. Native IP (IPv4 or IPv6) 1064 2. Native ICN 1066 3. Dual stack IP (IPv4/IPv6) or ICN 1068 UE encapsulates user data transport request into PDCP layer and sends 1069 the information on air interface to eNodeB. eNodeB receives the 1070 information and using PDCP [TS36.323], de-encapsulates air-interface 1071 messages and converts them to forward to core mobile gateways (SGW, 1072 PGW). As shown in figure 9, in order to support ICN natively in 1073 eNodeB, it is proposed to provide transport convergence layer (TCL) 1074 capabilities in eNodeB (similar to as provided in UE), which provides 1075 following functions: 1077 1. It decides the forwarding strategy for user data request coming 1078 from UE. The strategy can make decision based on preference 1079 indicated by the application such as congestion, cost, quality 1080 of service, etc. 1082 2. eNodeB to provide open Application Programming Interface (API) 1083 to external management systems, to provide capability to eNodeB 1084 to program the forwarding strategies. 1086 +---------------+ | 1087 | UE request | | ICN +---------+ 1088 +---> | content using |--+--- transport -->| | 1089 | |ICN protocol | | | | 1090 | +---------------+ | | | 1091 | | | | 1092 | +---------------+ | | | 1093 +-+ | | UE request | | IP |To mobile| 1094 | |---+---> | content using |--+--- transport -->| GW | 1095 +-+ | | IP protocol | | |(SGW,PGW)| 1096 UE | +---------------+ | | | 1097 | | | | 1098 | +---------------+ | | | 1099 | | UE request | | Dual stack | | 1100 +---> | content using |--+--- IP+ICN -->| | 1101 |IP/ICN protocol| | transport +---------+ 1102 +---------------+ | 1103 eNodeB S1u 1105 Fig. 9. Native ICN Deployment in eNodeB 1107 3. eNodeB shall be upgraded to support three different types of 1108 transport: IP, ICN, and dual stack IP+ICN towards mobile 1109 gateways, as depicted in figure 9. It is also recommended to 1110 deploy IP and/or ICN forwarding capabilities into eNodeB for 1111 efficient transfer of data between eNodeB and mobile gateways. 1112 There can be four choices for forwarding data request towards 1113 mobile gateways: 1115 a) Assuming eNodeB is IP-enabled and UE requests IP transfer, 1116 eNodeB forwards data over IP. 1118 b) Assuming eNodeB is ICN-enabled and UE requests ICN transfer, 1119 eNodeB forwards data over ICN. 1121 c) Assuming eNodeB is IP-enabled and UE requests ICN, eNodeB 1122 overlays ICN on IP and forwards the user plane traffic over 1123 IP. 1125 d) Assuming eNodeB is ICN-enabled and UE requests IP, eNodeB 1126 overlays IP on ICN and forwards the user plane traffic over 1127 ICN [IPoICN]. 1129 4.6 ICN Deployment in Packet Core (SGW, PGW) Gateways 1131 Mobile gateways a.k.a. Evolved Packet Core (EPC) include SGW, PGW, 1132 which perform session management for UE from the initial attach to 1133 disconnection. When UE is powered on, it performs NAS signaling and 1134 after successful authentication it attaches to PGW. PGW is an 1135 anchoring point for UE and responsible for service creations, 1136 authorization, maintenance etc. Entire functionality is managed using 1137 IP address(es) for UE. 1139 In order to implement ICN in EPC, the following functions are needed. 1141 1. Insert ICN function at session management layer as additional 1142 functionality with IP stack. Session management layer is used 1143 for performing attach procedures and assigning logical identity 1144 to user. After successful authentication by HSS, MME sends 1145 create session request (CSR) to SGW and SGW to PGW. 1147 2. When MME sends Create Session Request message (step 12 in 1148 [TS23.401]) to SGW or PGW, it contains Protocol Configuration 1149 Option Information Element (PCO IE) containing UE capabilities. 1150 We can use PCO IE to carry ICN related capabilities information 1151 from UE to PGW. This information is received from UE during the 1152 initial attach request in MME. Details of available TLV, which 1153 can be used for ICN are given in subsequent sections. UE can 1154 support either native IP, or ICN+IP, or native ICN. IP is 1155 referred to as both IPv4 and IPv6 protocols. 1157 3. For ICN+IP capable UE, PGW assigns the UE both IP address and 1158 ICN identity. UE selects either of the identities during the 1159 initial attach procedures and registers with network for 1160 session management. For ICN-capable UE it will provide only ICN 1161 attachment. For native IP-capable UE there is no change. 1163 4. In order to support ICN-capable attach procedures and use ICN 1164 for user plane traffic, PGW needs to have full ICN protocol 1165 stack functionalities. Typical ICN capabilities include 1166 functions such as content store (CS), Pending Interest Table 1167 (PIT), Forwarding Information Base (FIB) capabilities etc. If 1168 UE requests ICN in PCO IE, then PGW registers UE with ICN 1169 names. For ICN forwarding, PGW caches content locally using CS 1170 functionality. 1172 5. Protocol configuration options information elements described 1173 in [TS24.008] (see Figure 10.5.136 on page 598) and [TS24.008] 1174 (see Table 10.5.154 on page 599) provide details for different 1175 fields. 1177 - Octet 3 (configuration protocols defines PDN types) which 1178 contains details about IPv4, IPv6, both or ICN. 1180 - Any combination of Octet 4 to Z can be used to provide 1181 additional information related to ICN capability. It is most 1182 important that PCO IE parameters are matched between UE and 1183 mobile gateways (SGW, PGW) so that they can be interpreted 1184 properly and UE can attach successfully. 1186 6. Deployment of ICN functionalities in SGW and PGW should be 1187 matched with UE and eNodeB because they will exchange ICN 1188 protocols and parameters. 1190 7. Mobile gateways SGW, PGW will also need ICN forwarding and 1191 caching capability. This is especially important if CUPS is 1192 implemented. User Plane Function (UPF), comprising the S-GW and 1193 PGW user plane, will be located at the edge of the network and 1194 close to the end-user. ICN-enabled gateway means that this UPF 1195 would serve as a forwarder and should be capable of caching, as 1196 is the case with any other ICN-enabled node. 1198 8. The transport between PGW and CDN provider can be either IP or 1199 ICN. When UE is attached to PGW with ICN identity and 1200 communicates with an ICN-enabled CDN provider, it will use ICN 1201 primitives to fetch the data. On other hand, for an UE attached 1202 with an ICN identity, if PGW has to communicate with an IP- 1203 enabled CDN provider, it will have to use an ICN-IP 1204 interworking gateway to perform conversion between ICN and IP 1205 primitives for data retrieval. In the case of CUPS 1206 implementation with an offload close to the edge, this 1207 Interworking gateway can be collocated with the UPF at the 1208 offload site to maximize the path optimization. Further study 1209 is required to understand how this ICN to IP (and vice versa) 1210 interworking gateway would function. 1212 4.7 Lab Testing 1214 To further test the modifications proposed above in different 1215 scenarios, the following simple lab has been set up. 1217 +------------------------------------------+ 1218 | +-----+ +------+ (```). +------+ | (````). +-----+ 1219 | | SUB |-->| EMU |--(x-haul'.-->| EPC |--->( PDN ).-->| CDN | 1220 | +-----+ +------+ `__..'' +------+ | `__...' +-----+ 1221 +------------------------------------------+ 1223 Fig. 10. Native ICN deployment lab setup 1225 In a single server, we are setting up the following virtual machines: 1227 - SUB: ICN simulated client (using ndnSIM), an client application 1228 on workstation requesting content 1230 - EMU: test unit emulating eNodeB and UE. This will be a test node 1231 allowing for UE attachment and routing the traffic subsequently 1232 from the Subscriber to the Publisher 1234 - EPC: Cisco evolved Packet Core in a single instance (vPC-SI) 1236 - CDN: content delivery by a Publisher server 1238 For the purpose of this testing, ICN emulating code will be 1239 inserted in the test code in EMU to emulate ICN-capable UE 1240 and/or eNodeB. Effect of such traffic on EPC and CDN will be 1241 observed and documented. In a subsequent phase, EPC code 1242 supporting ICN will be tested when available. 1244 5. Security Considerations 1246 To ensure only authenticated UEs are connected to the network, LTE 1247 mobile network implements various security mechanisms. From 1248 perspective of ICN deployment in user plane, it needs to take care of 1249 the following security aspects: 1251 1. UE authentication and authorization 1253 2. Radio or air interface security 1254 3. Denial of service attacks on mobile gateway, services 1256 4. Content positioning either in transport or servers 1258 5. Content cache pollution attacks 1260 6. Secure naming, routing, and forwarding 1262 7. Application security 1264 Security over the LTE air interface is provided through cryptographic 1265 technique. When UE is powered up, it performs key exchange between 1266 UE's USIM and HSS/Authentication Center using NAS messages including 1267 ciphering and integrity protections between UE and MME. Details of 1268 secure UE authentication, key exchange, ciphering and integrity 1269 protections messages are given in 3GPP call flow [TS23.401]. 1271 LTE is an all-IP network and uses IP transport in its mobile backhaul 1272 (e.g. between eNodeB and core network). In case of provider owned 1273 backhaul, it may not implement security mechanisms; however, they are 1274 necessary in case it uses shared or a leased network. The native IP 1275 transport continues to leverage security mechanism such as Internet 1276 key exchange (IKE) and the IP security protocol (IPsec). More details 1277 of mobile backhaul security are provided in 3GPP network security 1278 [TS33.310] and [TS33.320]. When mobile backhaul is upgraded to 1279 support dual stack (IP+ICN) or native ICN, it is required to 1280 implement security techniques which are deployed in mobile backhaul. 1281 When ICN forwarding is enabled on mobile transport routers, we need 1282 to deploy security practices based on [RFC7476] and [RFC7927]. 1284 Some of the key functions supported by LTE mobile gateway (SGW, PGW) 1285 are content based billing, deep packet inspection (DPI), and lawful 1286 intercept (LI). For ICN-based user plane traffic, it is required to 1287 integrate ICN security for session between UE and gateway; however, 1288 in ICN network, since only consumers who are in possession of 1289 decryption keys can access the content, some of the services provided 1290 by mobile gateways mentioned above may not work. Further research in 1291 this area is needed. 1293 6. Summary 1295 In this draft, we have discussed complexities of LTE network and key 1296 dependencies for deploying ICN in user plane data transport. 1297 Different deployment options described cover aspects such as inter- 1298 operability and multi-technology, which is a reality for any service 1299 provider. We are currently evaluating the ICN deployment options, 1300 described in section 4, using LTE gateway software and ICN simulator. 1301 One can deploy ICN for data transport in user plane either as an 1302 overlay, dual stack (IP + ICN) or natively (by integrating ICN with 1303 CDN, eNodeB, SGW, PGW and transport network etc.). It is important to 1304 understand that for above discussed deployment scenarios, additional 1305 study is required for lawful interception, billing/mediation, network 1306 slicing, and provisioning APIs. 1308 Mobile Edge Computing (MEC) [CHENG] provides capabilities to deploy 1309 functionalities such as Content Delivery Network (CDN) caching and 1310 mobile user plane functions (UPF) [TS23.501]. Recent research for 1311 delivering real-time video content using ICN has also been proven to 1312 be efficient [NDNRTC] and can be used towards realizing the benefits 1313 of ICN deployment in eNodeB, MEC, mobile gateways (SGW, PGW) and CDN. 1314 The key aspect for ICN is in its seamless integration in LTE and 5G 1315 networks with tangible benefits so that we can optimize content 1316 delivery using simple and scalable architecture. Authors will 1317 continue to explore how ICN forwarding in MEC could be used in 1318 efficient data delivery from mobile edge. 1320 Based on our study of control plane signaling it is not beneficial to 1321 deploy ICN with existing protocols unless further changes are 1322 introduced in the control protocol stack itself. As mentioned in 1323 [TS23.501], 5G network architecture proposes simplification of 1324 control plane messages and can be a candidate for use of ICN. 1326 As a starting step towards ICN user plane deployment, it is 1327 recommended to incorporate protocol changes in UE, eNodeB, SGW/PGW 1328 for data transport. ICN has inherent capabilities for mobility and 1329 content caching, which can improve the efficiency of data transport 1330 for unicast and multicast delivery. Authors welcome the contributions 1331 and suggestions including those related to further validations of the 1332 principles by implementing prototype and/or proof of concept in the 1333 lab and in production environment. 1335 7 References 1337 7.1 Normative References 1339 [GRAYSON] Grayson M, Shatzkamer K, Wainner S.; Cisco Press book "IP 1340 Design for Mobile Networks" by. page 108-112. 1342 [IPSEC1] Cisco IPSec overhead calculator tool 1343 . 1346 [IPSEC2] IPSec Bandwidth Overhead Using AES 1347 . 1350 [BROWER] Brower, E.; Jeffress, L.; Pezeshki, J.; Jasani, R.; 1351 Ertekin, E. "Integrating Header Compression with IPsec", 1352 Military Communications Conference, 2006. MILCOM 2006. 1353 IEEE, On page(s): 1 - 6. 1355 [TS25.323] 3GPP TS25.323 Rel. 14 (2017-03) Packet Data Convergence 1356 Protocol (PDCP) specification. 1358 [TS23.501] 3GPP TS23.501 Rel. 15 (2017-06) System Architecture for 1359 the 5G System. 1361 [TS23.203] 3GPP TS23.203 Rel. 14 (2017-03) Policy and charging 1362 control and QoS architecture 1364 [TS23.401] 3GPP TS23.401 Rel. 14 (2017-03) E-UTRAN Access procedures 1365 architecture 1367 [TS33.310] 3GPP TS33.310 Rel. 14 (2016-12) LTE Network Domain 1368 Security (NDS); Authentication Framework (AF) 1370 [TS33.320] 3GPP TS33.320 Rel. 14 (2016-12) Security of Home Node B 1371 (HNB) / Home evolved Node B (HeNB) 1373 [TS24.008] 3GPP TS24.008 Rel. 14 (2017-06) Mobile radio interface 1374 Layer 3 specification. 1376 [TS23.501] 3GPP TS23.501 Rel. 14 (2017-06) System Architecture for 1377 the 5G System 1379 [TS23.214] 3GPP TS23.214 Rel. 14 (2017-06) Architecture enhancements 1380 for control and user plane separation of EPC nodes 1382 [TS36.323] 3GPP TS36.323 Rel. 14 (2017-06) Evolved Universal 1383 Terrestrial Radio Access (E-UTRA); Packet Data Convergence 1384 Protocol (PDCP) specification 1386 [TS23.714] 3GPP TS23.714 Rel. 14 (2016-06) Technical Specification 1387 Group Services and System Aspects: Study on control and 1388 user plane separation of EPC nodes 1390 [TS29.060] 3GPP TS29.060 Rel. 14 (2017-03) General Packet Radio 1391 Service (GPRS); GPRS Tunnelling Protocol (GTP) across the 1392 Gn and Gp interface 1394 [TS29.274] 3GPP TS29.274 Rel. 14 (2017-09) 3GPP Evolved Packet System 1395 (EPS); Evolved General Packet Radio Service (GPRS) 1396 Tunnelling Protocol for Control plane (GTPv2-C) 1398 [TS29.281] 3GPP TS29.281 Rel. 14 (2017-05) General Packet Radio 1399 System (GPRS) Tunnelling Protocol User Plane (GTPv1-U) 1401 [RFC7476] Information-Centric Networking: Baseline Scenarios 1402 1404 [RFC7927] Information-Centric Networking (ICN) Research Challenges 1405 1407 [RFC6459] IPv6 in 3rd Generation Partnership Project (3GPP) Evolved 1408 Packet System (EPS) 1409 1411 7.2 Informative References 1413 [RFC2119] Key words for use in RFCs to Indicate Requirement Levels 1414 1416 [RFC4594] Configuration Guidelines for DiffServ Service Classes 1417 1419 [H2020] The POINT Project 1421 [MECSPEC] European Telecommunication Standards Institute (ETSI) MEC 1422 specification ETSI-GS-MEC-IEG-001 V1.1.1 (2015-11). 1424 [CCNxTLV] CCNx Messages in TLV Format 1425 1428 [CCNxSem] mmCCNx Semantics 1431 [NDNPUB] Named Data Networking 1434 [CCN] Content Centric Networking and 1435 1437 [5GICN] Enabling ICN in 3GPP's 5G NextGen Core 1438 Architecturehttps://datatracker.ietf.org/doc/draft-ravi- 1439 icnrg-5gc-icn/ 1441 [NDN] Lixia Z., Lan W. et al. SIGCOMM Named Data Networking 1443 [ALM] J. Aug'e, G. Carofiglio et al. "Anchor-less producer 1444 mobility in icn," in Proceedings of the 2Nd ACM Conference 1445 on Information-Centric Networking, ACM-ICN '15, pp. 189- 1446 190, ACM, 2015. 1448 [VNIIDX] Cisco Visual Networking Index (VNI) dated 16 Feb 2016, 1449 . 1452 [NDNRTC] Peter Gusev,Zhehao Wang, Jeff Burke, Lixia Zhang et. All, 1453 IEICE Trans Communication, RealtimeStreaming Data Delivery 1454 over Named Data Networking, Vol E99-B, No.5 May 2016. 1456 [CHENG] Chengchao L., F. Richard Yu, Information-centric network 1457 function virtualization over 5G mobile wireless networks, 1458 IEEE network (Volume:29, Issue:3), page 68-74, 01 June 1459 2015. 1461 [NGMN] Backhaul Provisioning for LTE-Advanced & Small Cells 1462 1465 [IPoICN] IP Over ICN - The Better IP? 1466 1468 [HICN] Cisco Hybrid ICN 1472 [GALIS] Autonomic Slice Networking-Requirements and Reference 1473 Model 1476 [EPCCUPS] Control and User Plane Separation of EPC nodes (CUPS). 1478 1480 [SDN5G] Software-defined networking for low-latency 5G core 1481 network. 1483 [ICNQoS] Quality of Service in an Information-Centric Network 1484 1486 [OFFLOAD] Data Offloading Techniques in Cellular Networks: A Survey 1487 1489 Authors' Addresses 1491 Prakash Suthar 1492 9501 Technology Blvd. 1493 Rosemont, Illinois 60018 1495 EMail: psuthar@cisco.com 1497 Milan Stolic 1498 9501 Technology Blvd. 1499 Rosemont, Illinois 60018 1501 EMail: mistolic@cisco.com 1503 Anil Jangam 1504 3625 Cisco Way 1505 San Jose, CA 95134 1506 USA 1508 Email: anjangam@cisco.com 1510 Dirk Trossen 1511 InterDigital Inc. 1512 64 Great Eastern Street, 1st Floor 1513 London EC2A 3QR 1514 United Kingdom 1516 Email: Dirk.Trossen@InterDigital.com 1517 Ravishankar Ravindran 1518 Huawei Technologies 1519 2330 Central Expressway 1520 Santa Clara, CA 95050 1521 USA 1523 Email: ravi.ravindran@huawei.com