idnits 2.17.1 draft-fattore-dmm-n6-cpdp-trafficsteering-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 : ---------------------------------------------------------------------------- ** There are 17 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 20, 2018) is 2043 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-02) exists of draft-hmm-dmm-5g-uplane-analysis-01 ** Downref: Normative reference to an Informational draft: draft-hmm-dmm-5g-uplane-analysis (ref. 'I-D.hmm-dmm-5g-uplane-analysis') ** Downref: Normative reference to an Informational draft: draft-bogineni-dmm-optimized-mobile-user-plane (ref. 'I-D.bogineni-dmm-optimized-mobile-user-plane') Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Distributed Mobility Management (DMM) U. Fattore 3 Internet-Draft M. Liebsch 4 Intended status: Standards Track NEC 5 Expires: March 24, 2019 September 20, 2018 7 Control-/Data Plane Aspects for N6 Traffic Steering 8 draft-fattore-dmm-n6-cpdp-trafficsteering-00.txt 10 Abstract 12 Current standardization effort on the evolution of the mobile 13 communication system reconsiders the mobile data plane protocol. The 14 IETF DMM Working Group has work that proposes and analyzes various 15 protocols as alternative to the GPRS Tunneling Protocol for User 16 Plane (GTP-U) for an overlay deployment in between the mobile 17 device's assigned data plane anchor and its current radio base 18 station, which are denoted as N9 and N3 interfaces. In the view of 19 some future deployment and the original intent per the very early DMM 20 WG charter, a mobile device's data plane anchor may be highly 21 distributed and re-selected for optimization throughout a mobile 22 device's communication with one or more correspondent services. Such 23 re-configuration has impact on the packet routing in between the 24 mobile device's data plane anchor and the one or multiple data 25 networks hosting the services, which is denoted as N6 interface. 26 This draft proposes and discusses a solution to control, setup and 27 maintain traffic treatment policy on the cellular communication 28 system's N6 interface while taking the UE's PDU session settings per 29 the cellular system's control plane, such as QoS and locator 30 information, into account. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on March 24, 2019. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 3. Positioning of N6 policy control . . . . . . . . . . . . . . 4 69 3.1. System architecture for mobile access to data networks . 4 70 3.2. Use cases with demand for N6 traffic treatment policy . . 7 71 4. N6 traffic treatment - Requirements and policy types . . . . 8 72 5. Leveraging the mobile control plane for N6 policy control . . 9 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 76 9. Normative References . . . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [RFC2119]. 85 2. Introduction 87 Recent releases and deployments of cellular mobile communication 88 systems utilize an overlay on the mobile data plane to forward a 89 mobile device's data packets in between the mobile device and an 90 anchor point, which serves as first hop router to the mobile device. 91 The overlay is realized by the GPRS Tunneling Protocol for user plane 92 (GTP-U), which is able to carry network-specific attributes in the 93 tunnel protocol headers. 95 The 3rd Generation Partnership Project (3GPP) is in charge of the 96 cellular mobile communication system's specification and is currently 97 finalizing a 15th release, which has fundamental changes compared to 98 previous releases. Such changes include a clean split between 99 control- and data plane functions, more flexible deployment and re- 100 configuration of data plane anchors, as well as support for local 101 data network (DN) access and multi-homing. 103 In between a mobile device's current radio base station in the radio 104 access network (RAN) and its data plane anchor, the release 15 105 specification assumes an overlay per the previous releases utilizing 106 GTP-U. The data plane anchor is denoted as User Plane Function (UPF) 107 to anchor a Packet Data Unit (PDU) Session for the mobile device. 108 This draft abbreviates the UPF, which serves a device's PDU session 109 anchor, as UPF_a. In between a UPF_a and the device's current radio 110 base station, none, one or multiple additional UPFs can be deployed 111 to classify uplink traffic in support of policy-based routing to a 112 particular DN without traversing the UPF_a. This draft denotes such 113 intermediate UPF as UPF_i. Interfaces between a DN and a mobile 114 device's UPF_a is denoted as N6, the interface between a UPF_i and 115 one or multiple UPF_a is denoted as N9, and the interface between a 116 UPF_i and a radio base station is denoted as N3. Whereas regular 117 routing of mobile devices' PDUs is assumed on N6, N9 and N3 deploy a 118 GTP-U overlay with UPF_a, UPF_i and the radio base station serving as 119 tunnel endpoints. This end-to-end architecture is depicted in 120 Figure 1. For a more detailed description of anchor and intermediate 121 UPF and associated deployment and operation, please refer to 122 [I-D.bogineni-dmm-optimized-mobile-user-plane] and the 3GPP 123 specification [TS23.501]. 125 ________ 126 mobile +-----+ N3 +-------+ N9 +-------+ N6 / data \ 127 device---+ RAN +======/==+ UPF_i +=====/====+ UPF_a +-----/--+ network | 128 +-----+ GTP-U +-------+ GTP-U +-------+ IP \________/ 129 tunnel tunnel PDUs 131 Figure 1: Architecture and interfaces of a 3GPP release 15 data plane 132 in between a data network and a mobile device. 134 In alignment with the 3GPP's current directions to study data plane 135 protocol candidates which can serve as suitable alternative to GTP-U, 136 the IETF's DMM WG has valuable ongoing individual work that analyzes 137 the GTP-U protocol and derives requirements for an alternative mobile 138 data plane protocol [I-D.hmm-dmm-5g-uplane-analysis], as well as work 139 that investigates the use of alternative protocol candidates based on 140 SRv6, ID-Locator separation, and locator re-writing in the current 141 release 15 system architecture 142 [I-D.bogineni-dmm-optimized-mobile-user-plane]. The focus of these 143 drafts is on N9 and N3. 145 In the view of optimization options on the complete end-to-end data 146 plane, [I-D.gundavelli-dmm-mfa] complements other draft and proposes 147 data plane optimization on N6. Such operation is of particular 148 interest when the mobile device's UPF_a is decentralized and deployed 149 close to the device's current radio base station. Such deployment 150 may be preferable for some services, such as edge computing and 151 access to associated edge DNs, and mitigates the role of the UPF_i 152 and N9 interfaces. In particular the selection and configuration of 153 UPF_i instances can omitted and associated signaling costs can be 154 saved. However, such deployment strengthens the expectation on IP- 155 based PDU routing on N6, as the serving DN may not be always 156 topologically close to the device and its current UPF_a. Such 157 requirements include QoS support on N6, metering support and traffic 158 steering in case the mobile device's UPF_a changes while its IP 159 address and associated sessions should continue. 161 The same requirements on N6 apply for multi-homing per [TS23.501] 162 where the mobile device's UPF_a is close to a first DN (DN1) whereas 163 a UPF_i is used to enable access to a second DN (DN2), either through 164 a secondary UPF_a close to DN2 or directly from the UPF_i, without 165 the use of a secondary UPF_a. Since services in both DNs address the 166 same IP address of the mobile device (IP_ue) to send downlink 167 traffic, both DNs' traffic need to be forwarded to the most suitable 168 (e.g. closest) UPF_a or UPF_i respectively. 170 This draft focuses on a solution to control, setup and maintain such 171 dedicated routes and additional traffic treatment policy on N6, while 172 taking the UE's PDU session settings per the cellular system's 173 control plane, such as QoS and locator information, into account. 175 3. Positioning of N6 policy control 177 This section briefly introduces the relevant mobile system 178 architecture components and interfaces, and covers some high-level 179 use cases which can benefit from data plane policy control on N6 180 interface endpoints. 182 3.1. System architecture for mobile access to data networks 184 The 3GPP's 5G system architecture introduces in the core network a 185 clear control-/user plane separation (CUPS), in order to have 186 flexible deployment of the different functions (e.g., user plane 187 nodes can scale independently from control plane elements in case of 188 user traffic growth). Again to leverage flexibility and efficiency, 189 the control plane is split in different functions, each offering a 190 specific service, in the so called Service Based Architecture (SBA). 192 Among all the control plane functions, the Session Management 193 function (SMF) takes care of the session management (session 194 establishment, modification, release), IP allocation and selection of 195 an IP anchor point for the session, as well as traffic steering in 196 between UPFs and radio base stations. In order to manage the user 197 session, the SMF collaborates with other control plane services 198 (e.g., Policy Control Function - PCF - providing policy rules for 199 traffic treatment and monitoring), in particular with the Access and 200 Mobility Management Function (AMF), which manages registration, 201 authentication and authorization and security context. One of the 202 main task of the SMF is to instruct User Plane Functions (UPFs), 203 through N4 interface. When a new session is to be created, the SMF 204 selects one or multiple UPFs for the user traffic and selects one UPF 205 as session anchor (UPF_a). UPF_a acts as a proxy for user traffic, 206 which means all traffic directed to the UE passes through the UPF 207 anchor. Beside the UPF_a, if other UPFs are present (i.e., between 208 the radio base station and the UPF_a), this are deployed as 209 classifiers for user uplink traffic. 211 In Figure 2 a simplified 5G architecture [TS23.501] is depicted, 212 showing two Data Networks (DN) to whom a user may need a connection. 213 To each Data Network a UPF_a is associated, acting as session anchor 214 and providing to the user an IP address needed for the connection. 215 UPF_a also acts as tunnel termination point, since user traffic is 216 encapsulated on both N3 and N9 interfaces, using the GPRS Tunneling 217 Protocol for User Plane (GTP-U). Whereas, on N6 interface IP PDUs 218 are routed without tunneling. 220 communication between control plane functions 221 - - +---------------------+ - - 222 | | 223 +--+--+ +-----+ 224 | AMF | | SMF | 225 +-----+ +-----+ 226 /N2 N4| |N4 227 / +------+ +------+ 228 / | | _________ 229 +----+ +-----+ N3 +---+---+ N9 +---+---+ N6 / data \ 230 | UE |-----+ RAN +=========+ UPF_i +=========+ UPF_a +----/--+ network | 231 +----+ +-----+ +---+---+ +-------+ IP \____1____/ 232 IP_ue +---+---+ proxy IP_ue 233 proxy| UPF_a | 234 IP_ue+-------+ _________ 235 | N6 / data \ 236 +-------/----+ network | 237 IP \____2____/ 239 Figure 2: Data plane with a simplified release 15 control plane 241 Data networks host Application Servers (AS), which provide a services 242 to UEs, and an internal network comprising data plane nodes (DPN), 243 such as routers and switches, to connect the services with the 244 transport network. Both, the transport network and the data 245 network's internal network build the N6 interface, which is depicted 246 in Figure 3. In order to apply traffic treatment policy to uplink 247 traffic in between a UPF and a data network, the UPF receives 248 policies via the N4 interface. For downlink traffic, the AS/DPN 249 should have means to receive traffic treatment policies. 251 A way to enforce N6 policies to the DPN/AS in a data network is 252 needed. It is evident that this rule must originate from the 253 cellular control plane due to its knowledge about the UE's states, 254 such as its locator or QoS, and when these states are updated or re- 255 configured. Different means to convey and enforce associated traffic 256 treatment policies in a DPN/AS exist, such as the use of routing 257 protocols or control-/data plane configuration protocols. 259 communication between control plane functions 260 - - +-------------------+ - - 261 | | 262 +--+--+ +-----+ 263 | AMF | | SMF | 264 +-----+ +-----+ 265 /N2 N4| |N4 N6 policy 266 / +-------+ +--+ | __________ 267 / | | v/ \ 268 +----+ +-----+ N3 +---+---+ N9 +---+---+ N6 +------+ data \ 269 | UE |-----+ RAN +======+ UPF_i +======+ UPF_a +--/----+DPN|AS| network | 270 +----+ +-----+ +---+---+ +-------+ IP +------+ 1 / 271 IP_ue +---+---+ proxy IP_ue \__________/ 272 proxy| UPF_a | 273 IP_ue+-------+ ___________ 274 | / \ 275 | N6 +------+ data \ 276 +-------/----+DPN|AS| network | 277 IP +------+ 2 / 278 ^ \___________/_ 279 | 280 N6 policy 282 Figure 3: Data network DPN/AS as traffic treatment policy enforcement 283 point 285 3.2. Use cases with demand for N6 traffic treatment policy 287 The motivations behind the need for N6 treatment policy are many. 288 Following, some of the use cases are listed and described. 290 UE to UE communication: a scenario which is not explicitly shown in 291 Figure 2 and Figure 3 is UE to UE communication, when a UPF_a via N6 292 interface is connected to another UPF_a (belonging to the same or to 293 another network, and controlled by the same of another SMF), with the 294 latter UPF being associated to a second UE. In this scenario, all 295 the data plane elements on the path are controlled by control plane 296 elements of the 5GC (i.e., SMFs), but anyway additional policies on 297 N6 may be forwarded in order to steer traffic on an optimized route 298 directly towards the edge UPF for the specific UE, without passing 299 through the UPF_a. 301 UE to edge data network: in this use case, the UE connects to an edge 302 Data Network, meaning a DN positioned at the edge of the core 303 network, near to the access network (typical MEC scenario). In 304 mobility, a new UPF_a may be assigned to UE, and routes to the 305 previous edge network would follow a non-optimized path, passing 306 through the new UPF_a for the UE. With traffic treatment policies 307 this can be avoid, giving a traffic steering policy to the DPN in 308 charge for the edge DN. 310 Concurrent use of multiple data networks: a possible scenario is the 311 one in which a UE collects the desired content from different data 312 networks (e.g., because of Content Delivery Networks - CDN). To 313 optimize routing in this scenario, the downlink traffic should 314 traverse for each data network the optimized path through the UE and 315 not be forced through a (central) UPF_a common to all the data 316 networks. Again, this can be done with policies on N6 interface. 317 This particular use case also highlights the importance to consider 318 optimization on N6, whereas other works focus on N9: considering a 319 UPF_a near the data network, as proposed in other solutions, would 320 not allow multiple DN access in an unique user session and so would 321 not allow for content access on different destinations. 323 4. N6 traffic treatment - Requirements and policy types 325 Use cases for traffic treatment on N6 per a data plane policy include 326 cases where the UPF_a is deployed closer at the mobile edge, e.g. to 327 not only access a local data network in the proximity of the UE, but 328 also other data networks sharing the single edge UPF_a. In that case 329 the N6 interface may span some distance in the transport network in 330 between the data network(s) and the UPF_a. Dependent on the expected 331 QoE/QoS of the traffic, traffic treatment policies for QoS 332 differentiation, packet labeling, etc. may apply to the UE's packets 333 on N6. For uplink traffic, the UE's UPF_a can enforce such traffic 334 treatment policies to uplink traffic, where a DPN associated with the 335 data network(s) (e.g. PE router, transit router, router/switch of 336 the data center transport network, TOR switches of Application 337 Servers, etc.) enforces such policies to downlink traffic. 339 The same need for traffic treatment policies applies to traffic 340 between a UPF_i, which classifies uplink traffic for forwarding to a 341 local data network, and the data network. Downlink traffic from the 342 local data network to the UE should then be forwarded towards the 343 UPF_i, not via the UE's UPF_a. 345 In advanced scenarios, the SMF may decide to reconfigure the UE's 346 UPFs, e.g. by relocating the UPF_a or a UPF_i while maintaining the 347 UE's IP address (IP_ue) and data sessions using this IP address. In 348 such case, a DPN associated with the one or multiple data networks, 349 which run correspondent services for the UE, must enforce traffic 350 steering policies to downlink traffic to achieve routing of downlink 351 traffic to the UE's current UPF_a or UPF_i respectively. 353 In summary, traffic treatment policies that apply to a UE's uplink 354 and downlink traffic on N6 include the following types: 356 o QoS differentiation and traffic engineering 358 o Packet label push/pop 360 o Metering 362 o Traffic steering (e.g. SRv6 rules, locator re-write rules, etc.) 364 o UE dormancy monitoring rules to initiate paging 366 Requirements for N6 traffic treatment include the following: 368 o Awareness of UE location information (first hop router accuracy, 369 UPF_a/UPF_i) - Set or update DPN policy for traffic steering 371 o Awareness of topology - Select and update most suitable UPF (UPF_a/ 372 UPF_i) for the communication with a data network, e.g. after UPF 373 changed 375 o Availability of initial or updated policies when needed 377 o No/Low impact on data traffic (packet loss, re-ordering) when 378 policies are updated - DPNs may request/solicit policies or get 379 notified about initial and updated policies 381 5. Leveraging the mobile control plane for N6 policy control 383 Methods for N6 policy control consist in instructing the DPNs with 384 rules for traffic steering, QoS policies enforcing, etc. The 385 solution described in this draft is based on leveraging the mobile 386 control plane, in order to introduce some logic to manage and forward 387 policies to DPNs on N6 interface. To do this, the Application 388 Function (AF) defined in 5GS [TS23.501] is used as binding element in 389 between the cellular network control plane and the data network data 390 plane. 392 Per [TS23.501], the AF is introduced to inter-work with the Policy 393 Control Function (PCF) in order to condition and contribute to some 394 SMF decisions. This happens with the AF sending specific requests to 395 the PCF and the latter translating those requests in policies for the 396 SMF. Depending on the domain in which the AF is located, a Network 397 Exposure Function (NEF) may be in between to enable the AF 398 collaborating with the other control plane elements of the cellular 399 architecture. 401 In support of the proposed scenario, the AF can solicit data plane 402 policies from the cellular control plane by sending a request. At 403 reception of the policies, the AF can pass the policies on for 404 further processing and enfocement in the data network's AS/DPN. In 405 this way, DPNs receive from the control plane policies for the user 406 traffic traversing them. The AF may be co-located with a control 407 function, which utilizes the DMM WG's Forwarding Policy Configuration 408 (FPC) protocol to implement policies in the AS/DPN, or leverage an 409 SDN controller for the selection and configuration of AS/DPN. 411 The policies defined and forwarded by the AF are based on the status 412 of the mobile network, which the AF can obtain from the SMF. In any 413 moment, in fact, the SMF is in charge of keeping track of the 414 selected UPFs and of monitoring the user session. Based on this 415 information, the AF forwards specific rules to a DPN (e.g., traffic 416 steering rules to make the user's traffic reach the most suitable 417 UPF_a). In some cases (e.g., user mobility), the SMF can also change 418 UPFs for a specific user and in this case the AF will receive updated 419 policies for enforcement in the involved AS/DPN. 421 Figure 4 shows how the previous architecture evolves with the 422 introduction of the AF. 424 communication between control plane functions 425 - - +----------------+---------------+ - - 426 | | | 427 +--+--+ +-----+ +------+__ _ _ _ _ _ _ _ 428 | AMF | | SMF | | AF |_ | 429 +-----+ +-----+ +------+ | | 430 /N2 N4| |N4 | N6 policy | 431 / +-----+ +--+ | _________ | 432 / | | |/ \ | 433 +----+ +-----+ N3 +---+---+ N9 +---+---+ N6 +---+--+ Data \ | 434 | UE |----+ RAN +=====+ UPF_i +======+ UPF_a +---/---+DPN|AS| Network | | 435 +----+ +-----+ +---+---+ +-------+ IP +---+--+ 1 / | 436 IP_ue | proxy IP_ue \_________/ | 437 | _________ | 438 | / \ | 439 +---+---+ N6 +---+--+ Data \ | 440 proxy| UPF_a +--------/--+DPN|AS| Network | | 441 IP_ue+-------+ IP +---+--+ 2 / | 442 |\_________/ | 443 |__ _ _ _ _ _ _ _ _ _ _ _| 444 N6 policy 446 Figure 4: Using AF in control plane for traffic policy enforcement 448 6. IANA Considerations 450 No IANA action is required for this version of the draft. 452 7. Security Considerations 454 Since the solution proposed in this document utilizes the AF to 455 solicit and receive N6 traffic treatment policies from the cellular 456 system's control plane, the trust relationship between the AF and the 457 cellular system's domain matters. In case the AF is located in a 458 different administrative domain, the communication from and to the AF 459 may happen via the system's Network Exposure Functions (NEF). The 460 semantic to request and receive the N6 policy at the AF and in 461 particular the policy types and their descriptions must be aligned to 462 the trust relationship. 464 Also, the trust relationship between the AF and the DPN/AS matters 465 and a secure direct or indirect (e.g. through an Network Controller) 466 interface, must be ensured. 468 8. Acknowledgments 470 The research leading to these results has been partially supported by 471 the H2020-MSCA-ITN-2016 framework under grant agreement number 722788 472 (SPOTLIGHT). 474 Authors want to thank Sri Gundavelli, John Kaippallimalil and 475 Shunsuke Homma for their interest and feedback to the use cases and 476 the solution principles for N6 traffic treatment policies. 478 9. Normative References 480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, 482 DOI 10.17487/RFC2119, March 1997, 483 . 485 [I-D.hmm-dmm-5g-uplane-analysis] 486 Homma, S., Miyasaka, T., Matsushima, S., and d. 487 daniel.voyer@bell.ca, "User Plane Protocol and 488 Architectural Analysis on 3GPP 5G System", draft-hmm-dmm- 489 5g-uplane-analysis-01 (work in progress), August 2018. 491 [I-D.gundavelli-dmm-mfa] 492 Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility- 493 aware Floating Anchor (MFA)", draft-gundavelli-dmm-mfa-01 494 (work in progress), September 2018. 496 [I-D.bogineni-dmm-optimized-mobile-user-plane] 497 Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D., 498 Rodriguez-Natal, A., Carofiglio, G., Auge, J., 499 Muscariello, L., Camarillo, P., and S. Homma, "Optimized 500 Mobile User Plane Solutions for 5G", draft-bogineni-dmm- 501 optimized-mobile-user-plane-01 (work in progress), June 502 2018. 504 [TS23.501] 505 3rd Generation Partnership Project (3GPP), "Technical 506 Specification TS23.501, System Architecture for the 5G 507 System, Release 15.", 3GPPTS 23.501, June 2018. 509 Authors' Addresses 511 Umberto Fattore 512 NEC Laboratories Europe GmbH 513 Kurfuersten-Anlage 36 514 D-69115 Heidelberg 515 Germany 517 Email: umberto.fattore@neclab.eu 519 Marco Liebsch 520 NEC Laboratories Europe GmbH 521 Kurfuersten-Anlage 36 522 D-69115 Heidelberg 523 Germany 525 Email: marco.liebsch@neclab.eu