idnits 2.17.1 draft-defoy-netslices-3gpp-network-slicing-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 6, 2017) is 2608 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. de Foy 3 Internet-Draft A. Rahman 4 Intended status: Informational InterDigital Communications, LLC 5 Expires: September 7, 2017 March 6, 2017 7 Network Slicing - 3GPP Use Case 8 draft-defoy-netslices-3gpp-network-slicing-00 10 Abstract 12 This document describes work conducted at the 3GPP standard 13 organization on 5G Network Slicing. Its goal is to provide a 14 detailed use case, and help better define requirements, for Internet 15 Protocols supporting Network Slicing. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 7, 2017. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2. NS Work in 3GPP Prior to 5G Phase 1 . . . . . . . . . . . 3 54 2. Network Slicing Requirements in 3GPP . . . . . . . . . . . . 3 55 3. Network Slicing in Logical 5G Architecture in 3GPP . . . . . 4 56 3.1. Early Work on RAN Slicing . . . . . . . . . . . . . . . . 7 57 4. Management Aspect of Network Slicing in 3GPP . . . . . . . . 8 58 5. 5G Virtual Infrastructure Management in 3GPP . . . . . . . . 8 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 60 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 63 10. Informative References . . . . . . . . . . . . . . . . . . . 13 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 66 1. Introduction 68 This document describes work conducted at the 3GPP standard 69 organization on 5G Network Slicing. Its goal is to provide a 70 detailed use case, and help better define requirements, for Internet 71 Protocols supporting Network Slicing. 73 The concept of Network Slicing (NS) is considered a key mechanism for 74 5G networks to serve vertical industries with widely different 75 service needs, in term of latency, reliability, capacity, and domain 76 specific extra functionalities. It does so by exposing isolated 77 partitions of network resources and services. The IETF Bar-BoF 78 NETSLICES activity studies the need for supporting protocols. In 79 particular, [I-D.gdmb-netslices-intro-and-ps] defines Network Slicing 80 in a broad context and suggests related problems and work areas. It 81 also identifies the need to provide use cases such as, for example, 82 ultra-low latency and massive-connectivity machine communication 83 services. We propose to review ongoing NS work in 3GPP within the 84 present document. This constitutes in our view another valid type of 85 use case, since 3GPP architecture may ultimately use or integrate 86 with NS solutions defined in IETF. 88 Sections 2 to 6 aim to represent the current state of network slicing 89 and related aspects in 3GPP. We attempted to leave our own analysis 90 out of these sections and present it into section 7. For simplicity, 91 3GPP-specific acronyms are defined in the section they are used, 92 which is mostly section 3. 94 1.1. Background 96 The 3GPP standard organization is in the process of developing 5G 97 system architecture, which includes network slicing. In the present 98 document we will use information collected from 3GPP Release 15 99 specifications (as well as preliminary studies from Release 14 when 100 specifications are not yet available). This release aims to address 101 a more urgent subset of commercial needs in "5G Phase 1", with 102 expected deployments in 2020. Work on network slicing is split 103 between different working and study groups, reviewed here in separate 104 sections. 106 1.2. NS Work in 3GPP Prior to 5G Phase 1 108 While the present document will only focus on Network Slicing in 5G 109 Phase 1, an early form of network slicing was introduced in Release 110 13, with the Dedicated Core Network (DCN) or DECOR feature, where 111 dedicated core network nodes are forming a DCN serving subscribers or 112 devices with a certain "usage type" (e.g. machine-to-machine or 113 enterprise). In the Release 14 eDECOR feature, the DCN selection 114 mechanism was extended to be assisted by the device, which can now 115 send its usage type to the RAN. This is specified in [_3GPP.23.401]. 116 Deployments are expected in 2017 and 2018. 118 2. Network Slicing Requirements in 3GPP 120 Network slicing requirements are included in [_3GPP.22.261]. There 121 are requirements related to: 123 o Provisioning: create/modify/delete network slices, provision 124 network functions to be used in slices, define network services 125 and capabilities supported by a network slice. 127 o Managing association to slices: configure association of devices 128 and services to network slices, move/remove user between/from 129 slices. 131 o Interoperating: support roaming and non-roaming using the same 132 home slice, support devices simultaneously connected to multiple 133 slices. 135 o Supporting performance and isolation: support dynamic slice 136 elasticity, ensure performance isolation during normal and elastic 137 slice operation and during slice creation or deletion, enable 138 operators to differentiate performance and functionalities between 139 slices. 141 3. Network Slicing in Logical 5G Architecture in 3GPP 143 5G network architecture is entering its normative stage in 2017 with 144 a "5G System - Phase 1" Release 15 work item, which is in the process 145 of producing two technical specifications: 23.501 "System 146 Architecture for the 5G System" and 23.502 "Procedures for the 5G 147 System". At this early stage, though, we will still need to refer to 148 the earlier technical report [_3GPP.23.799]. The following text 149 summarizes what has been agreed about network slicing (refer to 150 section 8.1 of that report for more details). 152 A network slice is a complete logical network including Radio Access 153 Network (RAN) and Core Network (CN). It provides telecommunication 154 services and network capabilities, which may vary (or not) from slice 155 to slice. Distinct RAN and core network slices will exist. A device 156 may access multiple slices simultaneously through a single RAN. 158 The device may provide Network Slice Selection Assistance Information 159 (NSSAI) parameters to the network to help it select a RAN and a core 160 network part of a slice instance for the device. A single NSSAI may 161 lead to the selection of several slices. The network may also use 162 device capabilities, subscription information and local operator 163 policies to do the selection. 165 A NSSAI is a collection of smaller components, Session Management 166 NSSAIs (SM-NSSAI), which each include a Slice Service Type (SST) and 167 possibly a Slice Differentiator (SD). Slice service type refers to 168 an expected network behavior in terms of features and services (e.g. 169 specialized for broadband or massive IoT), while the slice 170 differentiator can help selecting among several network slice 171 instances of the same type, e.g. to isolate traffic related to 172 different services into different slices. 174 A PDU session is a 5G concept for an association between the device 175 and a data network, which can be IP, Ethernet or Unstructured (i.e. 176 transparent to the 5G system). The device will associate an 177 application with one out of multiple parallel PDU sessions, each PDU 178 session correspond to one core network slice and one RAN slice. 179 Different PDU sessions may belong to different slices. More 180 precisely, an application will be associated with a SM-NSSAI (as 181 mentioned above, this includes a slice service type and may also 182 include a service differentiator), and data for this application will 183 be routed to a PDU session associated to this SM-NSSAI. 185 Part of the control plane, the Common Control Network Function 186 (CCNF), is common to all or several slices. It includes the Access 187 and mobility Management Function (AMF) as well as the Network Slice 188 Selection Function (NSSF), which is in charge of selecting core 189 network slice instances. Besides those shared functions, different 190 slices may also have dedicated control plane functions such as the 191 Session Management Function (SMF), which manages PDU sessions. User 192 plane functions are dedicated to each slice. The RAN selects a CCNF 193 for a new PDU session. CCNF may initiate the redirection of service 194 for a device towards another CCNF, initially at session setup, or 195 later on. 197 In figures 1 and 2 we attempt to represent the use of network slicing 198 in 3GPP logical architecture (those figures are our interpretation 199 and are not directly adapted from the report). Figure 1 represents 200 the role of NSSAI in network selection. Figure 2 represents the 201 major network functions and interfaces in the context of RAN and Core 202 Network slicing. The terms used in these diagrams were introduced 203 earlier. System description and diagrams in section 4 of 204 [_3GPP.23.501] can provide additional context. 206 +-------+ 207 | | 208 |Device | 209 | | 210 RAN uses NSSAI +---+---+ 211 to select CCNF | 212 \ |(NSSAI) 213 \ | 214 +---+---+ 215 | +-------------+ 216 CCNF uses NSSAI | RAN +---------+ | 217 to select slice | | | | 218 or redirect to +---+---+ | | 219 another CCNF | | | 220 \ |(NSSAI) | | 221 \ | | | 222 +-------+--------+ | | 223 | Common Control | | | 224 | Plane Network | | | 225 | Functions | | | 226 | (CCNF) | | | 227 +-----+----+-----+ | | 228 | | | | 229 | | | | 230 | | | | 231 +---------|----+----------|---+-------+ 232 | | | | 233 +------------|---------------|-------+ | 234 | +---------++ +-----+----+ | | 235 | | | | | | | 236 | | +------+ | | +------+ | | | 237 | | | | | | | | | | | 238 | | |CP NF1| | | |UP NF1| | | | 239 | | | | | | | | | | | 240 | | +------+ | | +------+ | | | 241 | | ... | | ... | | | 242 | | | | | | | 243 | | +------+ | | +------+ | | | 244 | | | | | | | | | | | 245 | | |CP NFn| | | |UP NFn| | | | 246 | | | | | | | | | | | 247 | | +------+ | | +------+ | | | 248 | | | | | +---+ 249 | +----------+ +----------+ | 250 +------------------------------------+ 251 Core Network Slice Instances 253 Figure 1: Network Slice Selection in 3GPP architecture 254 CCNF Network Slice Instance 255 +-----------------+---------------------+ 256 | | | 257 | | | 258 | +--------+ | +--------+ | 259 | | Control| | | Control| | 260 +--------+ Plane +----------+ Plane | | 261 | | | AMF... | | | SMF... | | 262 | | +--------+ | +----+---+ | 263 | | | | | 264 | | | | | 265 | | | | | 266 +---+--+ +-----------------+ | | 267 |Device| | | | | 268 +---+--+ | | | | 269 | | | | | 270 | | +--------+ | +------+-----+ | 271 | | | | | | User Plane | | +---------------+ 272 +--------+ RAN +--------+ Functions +------+Data Network or| 273 | | | | | | | | The Internet | 274 | +--------+ | +------------+ | +---------------+ 275 | | | 276 | | | 277 +-----------------+---------------------+ 278 RAN Slice 280 Figure 2: Network Slices in 3GPP architecture 282 3.1. Early Work on RAN Slicing 284 In line with the logical architecture described above, early work on 285 RAN slicing is being conducted as part of the larger Release 14 286 "Study on New Radio Access Technology". Key principles are likely to 287 include the following, extracted from [_3GPP.38.801]: 289 1. RAN will support differentiated handling of traffic between pre- 290 configured, isolated RAN slices. How to perform this is left to 291 implementation. 293 2. Selection of the RAN slice will be based on IDs (which should be 294 the slice service type and slice differentiator defined above) 295 provided by the device or core network. 297 3. A RAN slice may or may not be available at a given location. 299 4. RAN will select the core network slice. 301 5. QoS differentiation within a RAN slice will be supported as well. 303 4. Management Aspect of Network Slicing in 3GPP 305 3GPP is developing a Release 14 "Study on management and 306 orchestration of network slicing for next generation network" 307 technical report [_3GPP.28.801], which defines an information model 308 where the network slice as well as physical and virtualized network 309 functions belong to the network operator domain, while the 310 virtualized resources belong to another domain operated by a 311 virtualization infrastructure service provider. 313 The concept of "sub-netslice" is used in the model, as defined 314 originally in [NGMN_Network_Slicing] (we will use the term sub- 315 netslices here, instead of the original subnet or sub-networks, which 316 can be confusing). Sub-netslice instances are comprised of physical 317 and virtual resources, have a life cycle independent from network 318 slices they belong to, can be shared between several network slices 319 and may be associated with other sub-netslice instances. 321 Multiple management use cases are described, ranging from creating 322 and monitoring a slice instance to configuring its SLA policy, 323 capacity and roaming support. It is also expected that some level of 324 slice management will be exposed to customers, and that operators 325 will have the possibility to create end-to-end network slices 326 involving multiple operators' networks. 328 Key issues are identified, including creating a slice across multiple 329 administrative domains, sharing a network slice between multiple 330 services, moving towards a more autonomous management, as well as 331 additional management specific key issues. 333 Finally, the life cycle of a slice is defined over 4 phases: 334 preparation phase including design and pre-provisioning, an 335 "instantiation, configuration and activation" phase, a run-time phase 336 including supervision and reporting, as well as upgrade, 337 reconfiguration and scaling, and a decommissioning phase. 339 5. 5G Virtual Infrastructure Management in 3GPP 341 To support the logical architecture defined earlier, some aspects of 342 virtualization infrastructure management are also being standardized 343 by 3GPP, through the activity "Management of mobile networks that 344 include virtualized network functions". This includes 5 work tasks, 345 the first of which deals with concept, architecture and requirements 346 [_3GPP.28.500], and 4 additional specialized work tasks on 347 configuration, fault, lifecycle and performance management, are in 348 the process of creating more detailed technical specification 349 documents. 351 The new 5G management system is tied to NFV-MANO, as defined by ETSI. 352 Its system architecture is described in [_3GPP.28.500] and 353 represented in Figure 3 (directly adapted from TS28.500). It defines 354 interconnections between the 3GPP management system and the NFV-MANO 355 system. NFV-MANO has the responsibility to manage NFV Infrastructure 356 (NFVI) and VNF lifecycle, and to report performance data, fault and 357 VNF instance information to 3GPP management system. 359 +--------------------------------------------+ +-------------+ 360 | +----------------------------------+OSS/BSS| | NFV |(3) 361 | | NM | | (1)|Orchestrator +--+ 362 | +--+--------------+--------------+-+ +----+ (NFVO) | | 363 +----|--------------|--------------|---------+ +-------------+ | 364 | | | |(2) | 365 | Itf-N | Itf-N | Itf-N | | 366 | | | +------+------+ | 367 | | | | | | 368 | +---------+------------+ | | | | 369 | |DM +----------------+ | | (5) | | | 370 | | | EM +------------------+ VNF | | 371 | | +-+--------+-----+ | | (5) | Manager | | 372 | +-----|--------|-------+ | +----------+ (VNFM) | | 373 | | | | | | | | 374 | | | | | | | | 375 | | | | | | | | 376 | | | | | | | | 377 +-+-+--+ | | +--+---++--+ (5) | | | 378 | | EM | | | | EM | +------+ | | 379 | +----+ | | +-------+ | +------+------+ | 380 | | | | | VNF | | | 381 | | +----++ +----+----+ +----+-----+ |(4) | 382 | | | | | | | | | 383 | | | | | VNF | | | | 384 | | | | | | |(7) | | 385 | | | | +-----+---+ | +------+------+ | 386 | | | | |(7) | | | | 387 | NE | | NE | +-----+----------+----+ | Virtualized | | 388 | (PNF)| |(PNF)| | | | Infrastruct.| | 389 | | | | | NFV Infrastructure | (6) | Manager +--+ 390 | | | | | (NFVI) +-------+ (VIM) | 391 | | | | | | | | 392 +------+ +-----+ +---------------------+ +-------------+ 394 Figure 3: 3GPP Network Management Architecture 396 The major building blocks on the left are from pre-existing 3GPP 397 architecture and on the right are from ETSI NFV architecture. Itf-N 398 is the traditional 3GPP management interface between the network 399 manager and domain and element managers, some of which will now be 400 collocated with VNFs. Other interfaces identified in the diagram are 401 defined as part of the NFV architecture and described in published 402 NFV specifications (which themselves do not make mention of network 403 slicing). 405 o (1) Os-Ma-nfvo enables managing Network Service Descriptors (NSD), 406 network service lifecycle, performance, faults and VNF packages. 407 The NSD information model is specified by ETSI NFV as well. It 408 enables describing network connectivity topology graphs where VNFs 409 are connected together through virtual links. An NSD also 410 includes VNF descriptors, which include memory and CPU 411 requirements, a link to a software image, initial setup scripts, 412 etc. 414 o (2) Or-Vnfm includes package management, VNF lifecycle/fault/ 415 configuration management, virtualized resources management (in 416 indirect mode as seen below), and relays notifications from the 417 VNF or EM. 419 o (3) Or-Vi and (4) Vi-Vnfm are the northbound interface of the 420 Virtual Infrastructure Manager (VIM). The orchestrator can 421 basically use a direct interface to VIM, or indirectly go through 422 the VNF manager over Or-Vnfm. The orchestrator can add software 423 images, create/update/terminate virtualized compute/network/ 424 storage resources allocations, manage resource capacity, manage 425 network virtual paths, run and query performance collection jobs, 426 set quotas. Location/affinity constraints can be applied when 427 creating resources. 429 o (5) Ve-Vnfm is used both between VNFM and EM and between VNFM and 430 VNFs. It includes lifecycle, performance, fault and configuration 431 management, as well as notifications from the EM that VNFM can 432 subscribe to. 434 o (6) Nf-Vi is for assignment of virtualized resources, hardware 435 resource configuration and state information exchange. 437 o (7) Vn-Nf represents the execution environment provided to the 438 VNF. 440 6. Security Considerations 442 The present section on network slicing security is based on the 443 "Study on Architecture and Security for Next Generation System", a 444 Release 14 study item. Its related technical report is 445 [_3GPP.33.899], and covers, among other areas, a network slicing 446 security area dealing with service access, network function sharing 447 and isolation. Multiple key issues are summarized here (refer to the 448 TR section 5.8 for more details): 450 1. Isolation requirements, especially performance isolation, ask for 451 data plane actions on one slice to have no influence on other 452 slices and for control plane actions (e.g. creation/update/ 453 deletion) to have little influence on other slices. Lack of 454 isolation can enable DoS attacks from one slice to another, 455 especially since some functions can be shared between slices. 456 Moreover, a device can access multiple slices, which increases 457 the possibility for leakage/breach type of issues between slices, 458 both from the device and the service side. 460 2. Different slices may need to implement different security 461 policies, e.g. in term of authentication requirements (IoT vs. 462 mobile broadband user). Authentication may be centralized and/or 463 per-slice. 465 3. Security and privacy of devices' access to slices is also a 466 concern. It may be possible to forge slice selection information 467 for a device. Slice selection information sent over the access 468 network can also lead to confidentiality issues. The proposed 469 key hierarchy supports having different keys for different 470 slices. How to enable security isolation of a common control 471 plane between different slices is not addressed at this point. 473 4. Security of sensitive shared network elements such as the HSS 474 (which holds customers' profiles) is identified as a key issue as 475 well. 477 5. Slice management functions should be secured, since an attacker 478 may use them, e.g. to delete a slice. Slice management 479 capabilities exposed through APIs for 3rd parties are especially 480 vulnerable. 482 6. Security on inter-slice communications is an issue in several 483 scenarios, for example when multiple slices share control plane 484 functions, and when a RAN slice and a core network slice are 485 interconnected to form a complete slice. Each slice is 486 considered a different trusted domain. 488 7. A range of potential issues related to virtualization are yet to 489 be explored further, though it is not clear if they are in the 490 scope of 3GPP. Issues include for example isolation between VNFs 491 hosted by the same hypervisor, authentication between VNFs, 492 performance isolation between VNFs. 494 7. Conclusion 496 This document summarized our understanding of 5G architecture and 497 requirements for network slicing, as defined by 3GPP, in their 498 current state. Our goal was to provide context to IETF NETSLICES, 499 since a protocol or framework defined by IETF for network slicing may 500 be used to implement or interoperate with 3GPP-compliant 5G systems. 501 In reference to Figure 3, the scope of IETF involvement with network 502 slicing could be within NFV Infrastructure, as well as some aspects 503 of the control plane on the right-hand side of the figure. 505 Here is a list of discussion points gathered while preparing this 506 document, in no particular order: 508 1. The concept of "sub-netslice" in section 4 may be useful as a 509 building block, e.g. a single-domain, indivisible and composable 510 service chain that is used to assemble a network slice. Defining 511 the interfaces of such a component could help focusing on sharing 512 between slices and extending slices across domains. 514 2. A large portion of the NS-related logical architecture agreements 515 so far is focusing on network slice instance selection. 3GPP 516 architecture demonstrate a requirement for common authentication 517 and network slice selection functions. It is our understanding 518 that the described mechanism enables a wide variation of cases 519 associating "n" slices with "m" network services or applications 520 involving "p" end devices. For example: a single slice instance 521 could be associated with multiple IoT applications, each 522 connected to multiple devices. In another example, an 523 application may split its end users in 2 service categories with 524 different SLAs, using different network slice instances. 526 3. Interoperation between slices is a major risk factor on isolation 527 and can occur in various scenarios: 529 * "Interoperation for extension" when data and control plane are 530 interconnected for extending a slice between RAN and CN, or 531 between visitor and home networks in a roaming scenario. 533 * "Interoperation through network function sharing" occurs in 534 3GPP when some control planes functions are performed by 535 common functions. 537 * "Interoperation through end points" can occur on user devices 538 connected to multiple network slices, or on an application 539 server side interacting with clients over different slices. 541 4. Sharing and interoperation within slices is also a concern and 542 occurs at multiple levels: QoS differentiation within a given 543 slice, and sharing a single slice between multiple services. 544 Deployment of a single slice over multiple data centers is not an 545 explicitly described scenario but may possibly be implied by the 546 use of virtualization of core network function. 548 5. Managing and deploying 3rd party network services is a potential 549 use case for network slicing. For example, network slice 550 management will likely be partially exposed to customers. 551 Additionally, an early requirement, that was finally not included 552 in the 3GPP specifications for network slicing, mentioned 553 "hosting multiple 3rd parties (e.g., enterprises) or MVNOs". 555 6. There is a strict requirement for security and performance 556 isolation from data plane and control plane actions between 557 slices. Should network slices be allowed to tap into currently 558 unused resource capacity? There is a possible tradeoff here 559 between performance/network efficiency and isolation, since in 560 this case, through its normal operation, a slice may influence 561 another slice by denying it this extra capacity. 563 7. Beyond performance isolation, there are multiple security 564 concerns related to network slicing, including the need for 565 separate per-netslice security policies. 567 We hope these points will contribute to the ongoing discussion taking 568 place in IETF NETSLICES to define requirements and work areas related 569 to network slicing. 571 8. IANA Considerations 573 This document requests no IANA actions. 575 9. Acknowledgements 577 The authors would like to thank Ulises Olvera-Hernandez for his 578 contribution and comments. 580 10. Informative References 582 [_3GPP.22.261] 583 3GPP, "Service requirements for next generation new 584 services and markets", 3GPP TS 22.261 1.1.0, February 585 2017, . 587 [_3GPP.23.401] 588 3GPP, "General Packet Radio Service (GPRS) enhancements 589 for Evolved Universal Terrestrial Radio Access Network 590 (E-UTRAN) access", 3GPP TS 23.401 14.2.0, 12 2016, 591 . 593 [_3GPP.23.501] 594 3GPP, "System Architecture for the 5G System", 3GPP 595 TS 23.501 0.2.0, 2 2017, 596 . 598 [_3GPP.23.799] 599 3GPP, "Study on Architecture for Next Generation System", 600 3GPP TR 23.799 14.0.0, 12 2016, 601 . 603 [_3GPP.28.500] 604 3GPP, "Telecommunication management; Management concept, 605 architecture and requirements for mobile networks that 606 include virtualized network functions", 3GPP TS 28.500 607 1.3.0, 11 2016, 608 . 610 [_3GPP.28.801] 611 3GPP, "Study on management and orchestration of network 612 slicing for next generation network", 3GPP TR 28.801 613 0.4.0, 1 2017, 614 . 616 [_3GPP.33.899] 617 3GPP, "Study on the security aspects of the next 618 generation system", 3GPP TR 33.899 0.6.0, 11 2016, 619 . 621 [_3GPP.38.801] 622 3GPP, "Study on the security aspects of the next 623 generation system", 3GPP TR 38.801 1.0.0, 12 2016, 624 . 626 [I-D.gdmb-netslices-intro-and-ps] 627 Galis, A., Dong, J., kiran.makhijani@huawei.com, k., 628 Bryant, S., Boucadair, M., and P. Martinez-Julia, "Network 629 Slicing - Introductory Document and Revised Problem 630 Statement", draft-gdmb-netslices-intro-and-ps-02 (work in 631 progress), February 2017. 633 [NGMN_Network_Slicing] 634 NGMN, "Description of Network Slicing Concept", 1 2016, 635 . 638 Authors' Addresses 640 Xavier de Foy 641 InterDigital Communications, LLC 642 Montreal 643 Canada 645 Email: Xavier.Defoy@InterDigital.com 647 Akbar Rahman 648 InterDigital Communications, LLC 649 Montreal 650 Canada 652 Email: Akbar.Rahman@InterDigital.com