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