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