idnits 2.17.1 draft-sfc-sinha-5g-split-bearer-dual-access-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 3) being 62 lines 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 (June 10, 2018) is 2141 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Service Function Chaining Sunil Kumar Sinha 2 Internet-Draft Infinite Computing Solutions 3 Intended status: Informational Amardeep Sinha 4 Expires: December 9, 2018 Reliance Jio Infocomm Limited 5 Amit Mishra 6 Varsa Networks 7 Yogesh Chandeshware 8 Mavenier 9 June 10, 2018 11 5G System Split Bearer for Dual-Access 12 draft-sfc-sinha-5g-split-bearer-dual-access-00 14 Abstract 16 This document attempts the case for new work that needs to be 17 developed for 5G users to improve faster download and upload of 18 user's data in a scenario of dual-access outlining the poor radio 19 coverage issues. This document also outlines the faster user data 20 mechanisum accompanying dual access capabilities of 5G user device 21 via split bearer in case of a poor coverage. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 9, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. 52 Table of Contents: 54 1. Introduction...................................................2 55 2. Conventions and Terminology....................................2 56 3. User data flow for Dual Connectivity for Dual Access and 57 problem statement..............................................2 58 3.1 5G System Architecture.....................................2 59 3.2 QoS........................................................4 60 3.3 Dual Connectivity..........................................5 61 3.4 Problem Statement..........................................5 62 4. Proposal of Split Bearer for dual access.......................5 63 5. IANA Considerations............................................7 64 6. Security Considerations........................................7 65 7. Privacy Considerations ........................................7 66 8. Acknowledgements...............................................7 67 9. References.....................................................7 68 9.1 Normative References.......................................7 69 9.2 Informative References.....................................8 70 Authors' Addresses................................................9 72 1. Introduction 74 5G system has been evolved to serve the user in more efficient way of 75 meeting higher download and upload of user data, 5G Users accessing 76 the network via wireline and wireless, in addition to this 77 Residential Gateway RG and IoT support is also defined. Access and 78 user experience is challenging for poor radio coverage (for both 79 wi-fi and RAN) and the proposal in this document addresses the 80 problem of poor coverage on either 3GPP or non-3GPP access with UE in 81 dual-access mode. 83 2. Conventions and Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 3. User data flow for Dual Connectivity for Dual Access and problem 90 statement 92 3.1 5G System Architecture 94 A simplified 5G System architecture shown in Figure-1 in the case of 95 UE in non-roaming scenario with RAN access(3GPP). 97 User data of 5G system is delivered to user from Service or data 98 network via interface N6 and N3 to UE. 100 +-----------------------------+ 101 | +-----------------+ | 102 | | |N8 |N15 103 +------+ | | +----+ N13 +-----+ | 104 | NSSF |---+ | | |AUSF|-------| UDM | | 105 +------+ | | | +----+ +-----+ | 106 | | | | | | 107 N22| | | |N12 |N10 +-----+ N5 +----+ 108 | | | +-+ | | PCF |------| AF | 109 | | | | | +-----+ +----+ 110 | | | | | | 111 +-------+ N11 +---+ N7 | 112 | AMF |------------|SMF|-------+ 113 +-------+ +---+ 114 | | 115 |N2 |N4 116 | | 117 | | 118 Uu +-----+ N3 +---+ N6 +-------------+ 119 UE--------------| RAN |-------------|UPF|--------| Service N/W | 120 +-----+ +---+ +-------------+ 122 Figure 1 : Simplified 5G System Architecture for RAN access 124 For the clarity in the current document proposal, multiple node/ 125 function like UDSF, NRF, and interfaces N9, N14 are not shown. 127 5G System supporting UE access to the network function and services 128 via non-3GPP is shown in Figure-2. An example of such access are 129 like WLAN or Wi-Fi. The N3IWF interface connect UE with 5G core 130 network via N2 and N3 interface. 132 +-----------------------------+ 133 | +-----------------+ | 134 | | |N8 |N15 135 +------+ | | +----+ N13 +-----+ | 136 | NSSF |---+ | | |AUSF|-------| UDM | | 137 +------+ | | | +----+ +-----+ | 138 | | | | | | 139 N22| | | |N12 |N10 +-----+ N5 +----+ 140 | | | +-+ | | PCF |------| AF | 141 | | | | | +-----+ +----+ 142 | | | | | | 143 +-------+ N11 +---+ N7 | 144 | AMF |------------|SMF|-------+ 145 +-------+ +---+ 146 | | 147 |N2 |N4 148 | | 149 | | 150 Y1 +--+ Y2 +-----+ N3 +---+ N6 +-------------+ 151 UE-----|AP|-----|N3IWF|-------------|UPF|--------| Service N/W | 152 +--+ +-----+ +---+ +-------------+ 154 Figure 2 : Simplified 5G System Architecture for Wi-Fi access 155 A complete architectural diagram of 5G System catering to both 156 access type being supported by UE is shown in Figure 3. 158 +--------------------------------------------------------+ 159 | +----------------------------+ | 160 | | +------------------+ | | 161 | | | | | | 162 | | | |N8 |N15 | 163 | | | | | | 164 | +------+ | | +------+ N13 +---+ | | 165 | | NSSF |--+ | | | AUSF |-------|UDM| | | 166 | +------+ | | | +------+ +---+ | | 167 | | | | | | | | 168 | | | | | | | | 169 N3| N22| | | |N12 N10| +---+ N5 +--+ | 170 | | | | +---+ | |PCF|------|AF| | 171 | | | | | | +---+ +--+ | 172 | | | | | | | | 173 +-----+ +---------+ +-----+ | | 174 | RAN |------| AMF |-----------| SMF |----+ | 175 +-----+ N2 +---------+ N11 +-----+ N7 | 176 | | | | 177 +--+ Uu | | | | 178 | |-----+ |N2 |N4 | 179 |UE| | | | 180 | |-----+ | | | 181 +--+ Y1 | +----------+ +---------+ | 182 | | | | 183 | | | | 184 +--------+ N3 +-----+ N6 +-------------+ | 185 |AP+N3IWF|---------------| UPF |------| Service N/W | | 186 +--------+ +-----+ +-------------+ | 187 | | 188 +-------------------------------+ 190 Figure 3 : Simplified 5G System Architecture for Multi access 192 3.2 QoS 194 QFI is defined as Qos Flow ID is a identity to QoS flow in the 5G 195 system. All data traffic within a PDU session are each labelled or 196 identified by QFI, implies same QFI labelled data flow will receives 197 same traffic forwarding treatment like scheduling, priority, etc. 199 QoS /Data flow is via N3(and N3 and N9) interface, being encapsulated 200 end-to-end. This flow is controlled by SMF, who provides QoS profile 201 during session establishment to R(AN) and provide the PDR to the UPF. 203 Please Note that like 4G system, default QoS flow is applied to each 204 PDU session and retain till lifetime span of connectivity. In case 205 of non-3GPP access QFI is delivered to N3IWF entity (or NG-RAN) for 206 every time User Plane of the PDU session is established, modified or 207 activated. 209 3.3 Dual Connectivity 211 Dual connectivity (DC) functionality support the network to make use 212 of additional radio resource to achieve required throughput in 213 downlink and uplink of user data. This was introduced in 4G system 214 support 5G data speed by addition of dual connectivity of UE with 215 eNBs, master eNB and secondary eNB and /or eNodeB in congestion with 216 gNB. This is achieved by addition of secondary eNodeB to the Master 217 eNodeB. Master eNB has full control to add, delete and HO(handover) 218 of eNodeBs as and when needed.[20160157293] 220 3.4 Problem Statement 222 Problem statement: Inspite of dual access 5G users radio condition 223 capabilities degrade on either of the access types and the 224 associated user experience on that access type becomes a challenge. 226 4. Proposal of Split Bearer for dual access 228 The solution proposed in this document to solve the problem of 229 degrade radio condition on the either of the access type at UE and 230 bearer offloading to other access-type. 232 Bearer split among RAN and Wifi referring to Fig-4. Trigger for split 233 bearer of bearer can originate from other of access type RAN or wifi. 235 - In the example given in figure-4 there is a degrade in radio 236 condition at RAN access of user. And at the same time 5G user also 237 have wi-fi access registered. 239 - Based on measurement report from UE, gNB (RAN) take decision for 240 partial Handover. gNB asked for UECapabilitys to check availability 241 of other access type. 243 - Taking inputs on UECapabilities response about the availability of 244 other access type, gNB process for Split bearer with other access 245 type 247 - gNB(RAN) triggers split bearer request for Wi-Fi access to AMF 248 and also includes user data traffic template FILTER. 250 FILTER: 251 FILTER is a user data delivery template defined by NG-RAN for the 252 5G-core UPF to implement and execute, without super imposing on the 253 PCC rule. 255 - If offload of complete user data traffic is needed, then FILTER 256 value MUST be empty/NULL. 258 +--+ +-----+ +-----+ +---+ +---+ +---+ 259 |UE| | gNB | |N3IWF| |AMF| |SMF| |UPF| 260 +--+ +-----+ +-----+ +---+ +---+ +---+ 261 | | | | | | 262 |<==User Data==>|<==============User Data==============>| 263 | | | | | | 264 | Measurement Control | | | | 265 |<--------------| | | | | 266 | | | | | | 267 | Measurement | | | | | 268 |-------------->| | | | | 269 | Report | | | | | 270 | +-------------+ | | | | 271 | | HO Decision | | | | | 272 | +-------------+ | | | | 273 | | | | | | 274 |UEAccessCapability | | | | 275 |<--------------| | | | | 276 | | | | | | 277 |UE-Wifi Access Report | | | | 278 |-------------->| | | | | 279 | | | | | | 280 | +-------------+ | | | | 281 | |SPLIT Bearer | | | | | 282 | |Dual Access | | | | | 283 | +-------------+ | | | | 284 | | | | | | 285 | Split-Bearer Request to Wifi | | 286 | |------------------->| | | 287 | | (FILTER) | | | | 288 | | | | | | 289 | | +---------------------+ | | 290 | | |HO procedure to N3IWF| | | 291 | | | + FILTER | | | 292 | | +---------------------+ | | 293 | | | | | | 294 | | | +-------------------------+ 295 | | | |Bearer Update + FILTER | 296 | | | +-------------------------+ 297 || | | | 298 | | | | | | 299 |<=Split Bearer with Wifi=>|<========Data==============>| 300 | | | | | | 301 |<=Split Beare=>|<========Data=========================>| 302 | with RAN | | | | | 304 Figure 4 : Bearer Offloading Dual-Connectivity with dual access 306 - If split of user data traffic is needed, then FILTER SHOULD have 307 required template according to which partial user data traffic is 308 split between RAN and Wi-Fi by UPF on N3 interface. 310 5. IANA Considerations 312 None. 314 6. Security Considerations 316 Security considerations related to the 5G systems are discussed in 317 [NGMN]. Due to the request for intrinsic realization of security 318 such aspects have to be considered by design for architecture and 319 protocols. 321 Especially as a joint usage of resources and network functions by 322 different separate logical network slices (e.g. in terms of virtual 323 network functions) seems to be inevitable in the framework of 5G the 324 need for strong security measures in such an environment is a major 325 challenge. 327 7. Privacy Considerations 329 Support of full privacy of the users (customers and tenants / end 330 service providers) is a basic feature of the next generation trusted 331 and reliable communications offering system. Such a high degree of 332 ensured privacy shall be reflected in the proposed architecture and 333 protocol solutions. 335 Especially as Identifiers and mapping of locators to them are 336 addressed some privacy concerns arise. Mobility solutions tend to 337 expose unique identifiers. A solution inside the mobile network 338 exposes these identifiers to the network operator, which is not a big 339 deal since the network operator already has information about the 340 device's location. In contrast, an IP level solution exposes both 341 the identifiers and the locations at the IP layer. That means that 342 web sites, for example, can now track the device's successive 343 locations by watching the IP address. Solutions such as transporting 344 the identifiers not as part of the IP header should be considered. 346 8. Acknowledgements 348 This work has been partially performed in the framework of the 349 cooperation Config. Contributions of the project partners are 350 gratefully acknowledged. The project consortium is not liable for 351 any use that may be made of any of the information contained therein. 353 Comments, constructive critisms from Karthik Palaniswamy and 354 Nagesh V. J. are respectfully acknowledged. 356 9. References 358 9.1. Normative References 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, 362 DOI 10.17487/RFC2119, March 1997, 363 . 365 9.2. Informative References 367 [20160157293] 368 "Method to Provide Dual Connectivity Using LTE Master 369 eNodeB and Wi-Fi Based Secondary eNodeB", June,2016. 371 [TS23.228] 372 "IP Multimedia Subsystem (IMS)", March 2018. 374 [TR38.801] 375 "Study on new radio access technology: Radio 376 access architecture and interfaces", March 2017. 378 [TR23.793] 379 "Study on Access Traffic Steering, Switch and Splitting 380 support in the 5G system architecture.", April 2018. 382 [TR23.793] 383 "Study on Access Traffic Steering, Switch and Splitting 384 support in the 5G system architecture.", April 2018. 386 [ETSI GR NGP 004] 387 "Next Generation Protocol (NGP):Evolved Architecture for 388 mobility using. Identity Oriented Networks.",January 2018 390 [ETSI GR NGP 001] 391 "Next Generation Protocol (NGP); Scenario Definitions". 392 ,May 2017 394 [TS23.501] 395 "3GPP TS23.501, System Architecture for the 5G System 396 (Release 15)", March 2018. 398 [TS23.502] 399 "3Procedures for the 5G System", March 2018. 401 [TS36.300] 402 "3GPP TS36.300, Evolved Universal Terrestrial Radio Access 403 (E-UTRA) and Evolved Universal Terrestrial Radio Access 404 Network (E-UTRAN); Overall description", March 2018. 406 [NGMN] 407 NGMN Alliance, "NGMN White Paper", February 2015. 409 Authors' Addresses 411 Sunil Kumar Sinha 412 FF-01, Rainbow Residency, 413 Green Glan layout, 414 Bellandur, Bangalore 415 Karnataka, India 417 Email: sunilkumarsinha9@gmail.com 419 Amardeep Sinha 420 C-1003, Yashodeep Heights, 421 Sec-29C, Airoli, 422 Navi-Mumbai, Maharashtra, India 424 Email: sinha.amardeep@gmail.com 426 Amit Mishra 427 Flat No: 208, 16th Block, 428 Sun City Appartments, 429 Iblur Junction, Sarjapur Signal, 430 Bengaluru, India 432 Email: amit.j.mishra@gmail.com 434 Yogesh Chandeshware 435 Shasi Nivas, 1st Street , F main, 436 Vijaya Vank Colony Extn, 437 Banaswadi, Bangalore 438 Karnataka, 439 India 441 Email: yogeshjc017@gmail.com