idnits 2.17.1 draft-aranda-sfc-dp-mobile-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: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-aranda-sfc-dp-mobile-02', but the file name used is 'draft-aranda-sfc-dp-mobile-01' Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [4], [I-D.ietf-sfc-use-case-mobility], [RFC7498], [RFC7665], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (June 13, 2016) is 2864 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 540 -- Looks like a reference, but probably isn't: '2' on line 543 -- Looks like a reference, but probably isn't: '3' on line 545 -- Looks like a reference, but probably isn't: '4' on line 547 -- Looks like a reference, but probably isn't: '5' on line 549 == Missing Reference: 'SFC-Mobile-UC' is mentioned on line 379, but not defined == Missing Reference: 'HSS' is mentioned on line 243, but not defined == Missing Reference: 'UE-C' is mentioned on line 247, but not defined == Missing Reference: 'S-GW-C' is mentioned on line 247, but not defined == Missing Reference: 'P-GW-C' is mentioned on line 247, but not defined == Missing Reference: 'UE-U' is mentioned on line 250, but not defined == Missing Reference: 'S-GW-U' is mentioned on line 250, but not defined == Missing Reference: 'P-GW-U' is mentioned on line 250, but not defined == Missing Reference: 'SGi-LAN' is mentioned on line 250, but not defined == Missing Reference: '5GPPP' is mentioned on line 291, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-sfc-use-case-mobility-05 Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC P. Aranda Gutierrez 3 Internet-Draft TID 4 Intended status: Informational M. Gramaglia 5 Expires: December 15, 2016 IMDEA 6 DRL. Lopez 7 TID 8 W. Haeffner 9 Vodafone 10 June 13, 2016 12 Service Function Chaining Dataplane Elements in Mobile Networks 13 draft-aranda-sfc-dp-mobile-02 15 Abstract 17 The evolution of the network towards 5G implies a challenge for the 18 infrastructure. The targeted services and the full deployment of 19 virtualization in all segments of the network will need service 20 function chains that previously resided in the(local and remote) 21 infrastructure of the Network operators to extend to the radio access 22 network (RAN). 24 In this draft we provide a non-exhaustive but representative list of 25 service functions in 4G and 5G networks, and explore different 26 scenarios for service-aware orchestration. 28 We base on the problem statement [RFC7498] and architecture framework 29 [RFC7665] of the SFC working group, as well on the existing mobile 30 networks use cases [I-D.ietf-sfc-use-case-mobility] and the 31 requirement gathering process of the ITU-R IMT 2020 [1] and different 32 initiatives in Europe [2], Korea [3] and China [4] to anticipate 33 network elements that will be needed in 5G networks. 35 We then explore service-aware orchestration scenarios identifying 36 where different network functions con be deployed in a fully 37 virtualised future network, where both the core and the edge provide 38 advanced virtualisation capabilities. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on December 15, 2016. 57 Copyright Notice 59 Copyright (c) 2016 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Terminology and abbreviations . . . . . . . . . . . . . . 3 76 1.2. General scope of mobile service chains . . . . . . . . . 4 77 1.3. Requirements for 5G networks . . . . . . . . . . . . . . 5 78 1.3.1. Evolution of the end-to-end carrier network . . . . . 5 79 2. Mobile network overview . . . . . . . . . . . . . . . . . . . 5 80 2.1. Building blocks of 4G and 5G networks . . . . . . . . . . 6 81 2.1.1. Classification schemes for 5G networks . . . . . . . 7 82 2.2. Control plane considerations . . . . . . . . . . . . . . 7 83 2.3. Operator requirements . . . . . . . . . . . . . . . . . . 7 84 3. New concepts for virtualized mobile networks . . . . . . . . 7 85 3.1. Service-aware orchestration . . . . . . . . . . . . . . . 8 86 3.2. Combining Access and Core . . . . . . . . . . . . . . . . 10 87 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 88 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 89 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 92 7.2. Informative References . . . . . . . . . . . . . . . . . 12 93 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 13 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 96 1. Introduction 98 The evolution of the network towards 5G implies a challenge for the 99 infrastructure. The targeted services and the full deployment of 100 virtualization in all segments of the network will need service 101 function chains that previously resided in the(local and remote) 102 infrastructure of the Network operators to extend to the radio access 103 network (RAN). 105 Existing mobile networks use cases presented to the working group and 106 the requirement gathering process of the ITU-R IMT 2020 and different 107 initiatives in Europe, Korea and China to anticipate network elements 108 that will be needed in 5G networks allow us to define use cases for 109 this next generation mobile networks. Once on the pillars of them 110 will be service-aware orchestration. We present scenarios 111 identifying where different network functions con be deployed in a 112 fully virtualised future network, where both the core and the edge 113 provide advanced virtualisation capabilities. These scenarios will 114 allow us to derive Service Function Chaining (SFC)-specific 115 requirements. 117 1.1. Terminology and abbreviations 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC2119 [RFC2119]. 123 Much of the terminology used in this document has been defined by 124 either the 3rd Generation Partnership Project (3GPP) or by activities 125 related to 5G networks like IMT2020 in ITU-R. Some terms are defined 126 here for convenience, in addition to those found in RFC6459 127 [RFC6459]. 129 +-------+-----------------------------------------------------------+ 130 | UE | User equipment like tablets or smartphones | 131 | eNB | enhanced NodeB, radio access part of the LTE system | 132 | S-GW | Serving Gateway, primary function is user plane mobility | 133 | P-GW | Packet Gateway, actual service creation point, terminates | 134 | | 3GPP mobile network, interface to Packet Data Networks | 135 | | (PDN) | 136 | HSS | Home Subscriber Server (control plane element) | 137 | MME | Mobility Management Entity (control plane element) | 138 | GTP | GPRS (General Packet Radio Service) Tunnel Protocol | 139 | S-IP | Source IP address | 140 | D-IP | Destination IP address | 141 | IMSI | The International Mobile Subscriber Identity that | 142 | | identifies a mobile subscriber | 143 | (S)Gi | Egress termination point of the mobile network (SGi in | 144 | | case of LTE, Gi in case of UMTS/HSPA). The internal data | 145 | | structure of this interface is not standardized by 3GPP | 146 | PCRF | 3GPP standardized Policy and Charging Rules Function | 147 | PCEF | Policy and Charging Enforcement Function | 148 | TDF | Traffic Detection Function | 149 | TSSF | Traffic Steering Support Function | 150 | IDS | Intrusion Detection System | 151 | FW | Firewall | 152 | ACL | Access Control List | 153 | PEP | Performance Enhancement Proxy | 154 | IMS | IP Multimedia Subsystem | 155 | LI | Legal Intercept | 156 +-------+-----------------------------------------------------------+ 158 Table 1 160 1.2. General scope of mobile service chains 162 Current mobile access networks terminate at a mobile service creation 163 point (called Packet Gateway) typically located at the edge of an 164 operator IP backbone. Within the mobile network, the user payload is 165 encapsulated in 3GPP specific tunnels terminating eventually at the 166 P-GW. In many cases application-specific IP traffic is not directly 167 exchanged between the original mobile network, more specific the 168 P-GW, and an application platform, but will be forced to pass a set 169 of service functions. Network operators use these service functions 170 to differentiate their services. 172 In order to cope with the stringent requirements of 5G networks (cf. 173 Section 1.3), we expect a new architecture to appear. This 174 architecture will surely make extensive use of virtualisation up to 175 the RAN. We also expect that IP packets will need to be processed 176 much earlier that in the current 3GPP architecture. In this context, 177 it is foreseeable that Service Function Chaining will play a 178 substantial role when managing the chains network traffic will 179 traverse. We also expect new kinds of service functions specific to 180 the radio access part to appear and that these new service functions 181 will need to be managed by the SFC management infrastructure of the 182 operator. 184 1.3. Requirements for 5G networks 186 As set forth by the 5G Infrastructure Public Private Partenrship 187 (5GPPP) [5], the evolution of the infrastructure towards 5G should 188 enable the following features in the mobile environment: 190 o Providing 1000 times higher wireless area capacity 192 o Saving up to 90% of energy per service provided 194 o Reducing the average service creation time cycle from 90 hours to 195 90 minutes 197 o Facilitating very dense deployments of wireless communication 198 links to connect over 7 trillion wireless devices serving over 7 199 billion people 201 1.3.1. Evolution of the end-to-end carrier network 203 [SFC-Mobile-UC] presents the structure of end-to-end carrier 204 networks and focused on the Service Function Chaining use cases for 205 mobile carrier networks, such as current 3GPP- based networks. We 206 recognise that other types of carrier networks that are currently 207 deployed share similarities in the structure of the access networks 208 and the service functions with mobile networks. The evolution 209 towards 5G networks will make the distinction between these different 210 types of networks blur and eventually disappear. 212 5G networks are expected to massively deploy virtualisation 213 technologies from the radio elements to the core of the network. The 214 four building blocks of the RAN, i.e. i) spectrum allocation or 215 physical layer (PHY), i) Medium Access Control (MAC), iii) Radio Link 216 Control (RLC) and iv) Packet Data Convergence, are candidates for 217 virtualisation. 219 2. Mobile network overview 221 [SFC-Mobile-UC] provides an overview of mobile networks up to LTE 222 (Long Term Evolution) networks. As the specifications mature, we 223 will provide the updates to the LTE architecture. 225 2.1. Building blocks of 4G and 5G networks 227 The major functional components of an LTE network are shown in 228 Figure 2 and include user equipment (UE) like smartphones or tablets, 229 the LTE radio unit named enhanced NodeB (eNB), the serving gateway 230 (S-GW) which together with the mobility management entity (MME) takes 231 care of mobility and the packet gateway (P-GW), which finally 232 terminates the actual mobile service. These elements are described 233 in detail in [ts-23-401]. Other important components are the home 234 subscriber system (HSS), the Policy and Charging Rule Function (PCRF) 235 and the optional components: the Traffic Detection Function (TDF) and 236 the Traffic Steering Support Function (TSSF), which are described in 237 [ts-23-203]. The P-GW interface towards the SGi-LAN is called the 238 SGi-interface, which is described in [ts-29-061]. The TDF resides on 239 this interface. Finally, the SGi-LAN is the home of service function 240 chains (SFC), which are not standardized by 3GPP. 242 +--------------------------------------------+ 243 | Control Plane (C) [HSS] | [OTT Appl. Platform] 244 | | | | 245 | +--------[MME] [PCRF]--+--------+ Internet 246 | | | | | | | 247 | [UE-C] -- [eNB-C] == [S-GW-C] == [P-GW-C] | | | 248 +=====|=========|==========|============|====+ +-----+----+-------+ 249 | | | | | | | | | | 250 | [UE-U] -- [eNB-U] == [S-GW-U] == [P-GW-U]-+--+----[SGi-LAN] | 251 | | | | | 252 | | | | | 253 | | | [Appl. Platform] | 254 | | | | 255 | User Plane (U) | | | 256 +--------------------------------------------+ +------------------+ 258 Source [SFC-Mobile-UC] 260 Figure 1: End to end context including all major components of an LTE 261 network. 263 Service Functions handle session flows between mobile user equipment 264 and application platforms. Control plane metadata supporting policy 265 based traffic handling may be linked to individual service functions. 266 In 5G networks, we expect the packet gateway (P-GW) to loose its 267 central position and be integrated with functions in the RAN. Radio 268 Resource Control (RRC) in 5G network will be integrated into the 269 Control Plane environment. 271 2.1.1. Classification schemes for 5G networks 273 TBD: We expect classification schemes for 5G networks to evolve as 274 the standards appear. 276 2.2. Control plane considerations 278 TBD: We except the RRC to be integrated with the SFC Control plane in 279 5G. 281 2.3. Operator requirements 283 4G mobile operators use service function chains to enable and 284 optimize service delivery, offer network related customer services, 285 optimize network behavior or protect networks against attacks and 286 ensure privacy. Service function chains are essential to their 287 business. Without these, mobile operators are not able to deliver 288 the necessary and contracted Quality of Experience (QoE) or even 289 certain products to their customers. 291 As set forth by the 5G-PPP [5GPPP], the evolution of the 292 infrastructure towards 5G should enable the following features in the 293 mobile environment: 295 o Providing 1000 times higher wireless area capacity 297 o Saving up to 90% of energy per service provided 299 o Reducing the average service creation time cycle from 90 hours to 300 90 minutes 302 o Facilitating very dense deployments of wireless communication 303 links to connect over 7 trillion wireless 305 To meet these additional requirements, operators will need to make an 306 extensive use of service chains and to extend their scope to 307 functions in the Radio Access Network. 309 3. New concepts for virtualized mobile networks 311 Virtualisation and softwarization will be among the key technology 312 introduced in the design of future 5G Network architecture. They 313 allow to decouple the binding between hardware and software 314 components in a flexible way. While used in conjunction with SFC, 315 future mobile network may support the dynamical allocation of Network 316 Functions (NFs) in network nodes and their orchestration according to 317 the requirements of the implemented service. These concepts will be 318 the building blocks of the future 5G architecture. Current efforts 319 in the definition of SFC mostly focus on Core Network functions. We 320 believe that the cloudification of RAN functions will increase the 321 flexiblity needed to support very demanding and heterogeneous 322 services envisioned by future 5G Networks, and hence the definition 323 of the SFC Dataplane elements must also take into account functions 324 once considered monolithically embedded in the eNB. In the next 325 sections, we present some technical solutions that leverage on these 326 novel concepts. 328 3.1. Service-aware orchestration 330 The current 3GPP LTE Mobile Network architecture offers a low 331 flexibility. Even by applying SFC techniques, specific network 332 functions are executed in well-defined units (e.g., eNB and P-GW 333 functions are carried out in dedicated hardware). Moreover, those 334 network equipment are usually physically located in precise 335 locations. This static approach burdens the flexibility needed by 336 future 5G Networks. 338 Softwarization and Virtualisation techniques allow for the flexible 339 deployment of functions in the network. Therefore, the placement and 340 execution of network functions should not be driven by topological 341 constraints, but rather on QoS ones such as the specific requirements 342 of the implemented service (e.g., latency, bandwidth and reliability, 343 among others), the radio characteristics and the transport network 344 capacity. 346 This approach enables enables the concurrent execution of different 347 instantiations of the protocol stack in the same nework 348 infrastructure, as envisioned by the network slicing [REF NGMN 349 Description of Network Slicing Concepts] concepts. SFC is set to be 350 a fundamental technology in this framework, allowing the dynamic 351 deployment of different chains across many network slices spanning 352 different cloud infrastructure arrangements. Hence, network 353 functions can be physically located into different zones of the 354 network: near the transmission point (edge cloud) or in centralised 355 data centers (central cloud). The choice on the orchestration of 356 such network functions will hence happen on a per-service basis. 358 Edge Cloud Central Cloud 359 +--------------------Vehicular Communications----------------------+ 360 | +----+ +----+ +----+ +----+ +----+ | 361 | | DR | | CR | | DC | | CC | | CC | | 362 | +----+ +----+ +----+ +----+ +----+ | 363 +------------------------------------------------------------------+ 364 +--------------------Haptic Internet-------------------------------+ 365 | +----+ +----+ +----+ +----+ | 366 | | DR | | CR | | DC | | CC | | 367 | +----+ +----+ +----+ +----+ | 368 +------------------------------------------------------------------+ 369 +--------------------Internet Access-------------------------------+ 370 | +----+ +----+ +----+ +----+ +----+ | 371 | | DR | | DR | | CR | | DC | | CC | | 372 | +----+ +----+ +----+ +----+ +----+ | 373 +------------------------------------------------------------------+ 374 DR: data plane RAN 375 CR: control plane RAN 376 DC: data plane Core 377 CC: control plane Core 379 Source [SFC-Mobile-UC] 381 Figure 2: Service-aware orchestration of network functions. 383 In order to achieve a service aware orchestration described above, 384 there are some challenges that need to be addressed. They are 385 illustrated by the following examples : 387 o Vehicular communications need low latency and sessionless 388 connectivity. Therefore, almost all the VNFs belonging to this 389 service should be located close to the transmission point, 390 including those traditionally located in the core network; 392 o Tactile Internet applications require both low latency and session 393 continuity. Therefore, most of the the network functions should 394 be located close to the transmission point, but some control plane 395 ones should be located in the core network; 397 o Broadband access users do not usually have strict latency 398 requirements. Thus, the network functions related to them may be 399 located in the core network, efficiently exploiting the 400 multiplexing gain enabled by this kind of deployment. 402 3.2. Combining Access and Core 404 Traditional architectures force a fixed topological relation between 405 network functions, while in a virtualized architecture, as the one 406 proposed above, these constraints are relaxed. This difference is 407 especially highlighted for access and core network functions. While 408 in a traditional architecture, these functions were usually executed 409 in different parts of the network (e.g., the scheduler in the base 410 station and a firewall in the centre of the network), a virtualised 411 architecture blends the boundaries between access and core functions: 412 their final location is decided on a functional basis. 414 For instance, services with strict latency requirements may be 415 located close to the transmission points, while services that can 416 exploit centralisation may be located in the core data centre. The 417 application of this concept may end up with access and core functions 418 sharing the same network location. This fact enables possible 419 improvements, as detailed in the following example. Currently, 420 mobility and scheduling decisions are taken separately. The 421 mobility-related network functions are traditionally located in the 422 core network and their decisions are taken before scheduling ones, 423 which are taken subsequently, in the access network. It is important 424 to note that a decision about mobility cannot be modified at the 425 scheduling level. With a fully virtualised architecture, the 426 mobility and scheduler network functions may be co-located in the 427 same network node, enabling a possible joint-optimization between 428 mobility and scheduling. 430 However, this is only one example of possible optimizations that can 431 be achieved using this kind of approach. The proposed approach 432 reduces high latencies introduced by the traditional access-core 433 deployment. Therefore, further optimisation may be introduced as the 434 impact of signalling protocols is reduced. SFC is expected to play a 435 fundamental role in this picture, allowing the flexible chaining of 436 network functions. 438 4. Security Considerations 440 Organizational security policies must apply to ensure the integrity 441 of the SFC environment. 443 SFC will very likely handle user traffic and user specific 444 information in greater detail than the current service environments 445 do today. This is reflected in the considerations of carrying more 446 metadata through the service chains and the control systems of the 447 service chains. This metadata will contain sensitive information 448 about the user and the environment in which the user is situated. 449 This will require proper considerations in the design, implementation 450 and operations of such environments to preserve the privacy of the 451 user and also the integrity of the provided metadata. 453 5. IANA Considerations 455 This document has no actions for IANA. 457 6. Acknowledgements 459 This work has been partially performed in the scope of the 460 SUPERFLUIDITY project, which has received funding from the European 461 Union's Horizon 2020 research and innovation programme under grant 462 agreement No.671566 (Research and Innovation Action). This work has 463 also been partially performed in the framework of the H2020-ICT- 464 2014-2 project 5G NORMA. The authors would like to acknowledge the 465 contributions of their colleagues. This information reflects the 466 consortium's view, but the consortium is not liable for any use that 467 may be made of any of the information contained therein. 469 7. References 471 7.1. Normative References 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, 475 DOI 10.17487/RFC2119, March 1997, 476 . 478 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 479 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 480 Partnership Project (3GPP) Evolved Packet System (EPS)", 481 RFC 6459, DOI 10.17487/RFC6459, January 2012, 482 . 484 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 485 Service Function Chaining", RFC 7498, 486 DOI 10.17487/RFC7498, April 2015, 487 . 489 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 490 Chaining (SFC) Architecture", RFC 7665, 491 DOI 10.17487/RFC7665, October 2015, 492 . 494 7.2. Informative References 496 [I-D.ietf-sfc-use-case-mobility] 497 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and 498 J. Uttaro, "Service Function Chaining Use Cases in Mobile 499 Networks", draft-ietf-sfc-use-case-mobility-05 (work in 500 progress), October 2015. 502 [ts-23-003] 503 3GPP, ""Numbering, addressing and identification"", , 504 July 2015. 506 [ts-23-203] 507 3GPP, "Policy and charging control architecture", 508 TS 29.203, July 2015. 510 [ts-23-401] 511 3GPP, "General Packet Radio Service (GPRS) enhancements 512 for Evolved Universal Terrestrial Radio Access Network 513 (E-UTRAN) access", 3GPP YS 23.401, July 2015. 515 [ts-29-061] 516 3GPP, "Interworking between the Public Land Mobile 517 Network(PLMN) supporting packet based services and Packet 518 Data Networks (PDN)", 3GPP TS 29.061, March 2015. 520 [ts-29-212] 521 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 522 Packet Radio Service (GPRS) Tunneling Protocol for Control 523 plane (GTPv2-C); Stage 3", 3GPP TS , July 2015. 525 [ts-29-274] 526 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 527 Packet Radio Service (GPRS) Tunneling Protocol for Control 528 plane (GTPv2-C); Stage 3", 3GPP 29.274, December 2013. 530 [ts-29-281] 531 3GPP, "General Packet Radio System (GPRS) Tunneling 532 ProtocolUser Plane (GTPv1-U)", 3GPP TS , January 2015. 534 [ts-33-210] 535 3GPP, "3G security; Network Domain Security (NDS); IP 536 network layer security", 3GPP TS 33.210, December 2012. 538 7.3. URIs 540 [1] http://www.itu.int/en/ITU-R/study-groups/rsg5/rwp5d/imt- 541 2020/Pages/default.aspx 543 [2] https://5g-ppp.eu 545 [3] http://www.5gforum.org/#!eng/cvb1 547 [4] http://www.imt-2020.cn/en/introduction 549 [5] https://5g-ppp.eu 551 Authors' Addresses 553 Pedro A. Aranda Gutierrez 554 Telefonica, I+D 555 Zurbaran, 12 556 Madrid 28010 557 Spain 559 Email: pedroa.aranda@telefonica.com 561 Marco Gramaglia 562 IMDEA Networks Institute 563 Av. Mar Mediterraneo, 22 564 Leganes 28911 565 Spain 567 Email: marco.gramaglia@imdea.org 569 Diego R. Lopez 570 Telefonica I+D 571 Zurbaran, 12 572 Madrid 28010 573 Spain 575 Email: diego@tid.es 576 Walter Haeffner 577 Vodafone D2 GmbH 578 Ferdinand-Braun-Platz 1 579 Duesseldorf 40549 580 Germany 582 Email: walter.haeffner@vodafone.com