idnits 2.17.1 draft-defoy-mptcp-considerations-for-5g-01.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 (June 22, 2018) is 2135 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-feng-dmm-ra-prefixtype-02 == Outdated reference: A later version (-18) exists of draft-ietf-dmm-ondemand-mobility-14 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. de Foy 3 Internet-Draft M. Perras 4 Intended status: Informational InterDigital Communications 5 Expires: December 24, 2018 U. Chunduri 6 Huawei USA 7 K. Nguyen 8 M. Kibria 9 K. Ishizu 10 F. Kojima 11 NICT 12 June 22, 2018 14 Considerations for MPTCP operation in 5G 15 draft-defoy-mptcp-considerations-for-5g-01 17 Abstract 19 This document describes scenarios where the behavior of the 5G 20 mobility management framework is different from earlier cellular 21 generations, and describes how it may benefit from some form of 22 adaptation of MPTCP implementations and protocol aspects in the 5G 23 system. This document also describes how MPTCP may be leveraged in 24 5G system specifications. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 24, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Need for Adapting MPTCP to 5G Session and Service 62 Continuity . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Opportunity for Leveraging MPTCP in 5G Dual Connectivity 64 Feature . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Impact of 5G Session and Service Continuity on MPTCP . . . . 3 66 2.1. New Inputs for MPTCP stacks . . . . . . . . . . . . . . . 4 67 2.2. SSC mode 1 . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.3. SSC mode 2 . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.4. SSC mode 3 . . . . . . . . . . . . . . . . . . . . . . . 7 70 2.5. Behavior of Remote Peer . . . . . . . . . . . . . . . . . 9 71 3. MPTCP with 5G Dual Connectivity . . . . . . . . . . . . . . . 10 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 75 7. Informative References . . . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 MPTCP [RFC6824] is being deployed and widely adopted in today's smart 81 devices, which typically have multiple network interfaces such as 82 Cellular and Wifi. It provides reliability, bandwidth aggregation 83 capability, and handover efficiency. 85 This document describes scenarios where the behavior of the 5G 86 mobility management framework is different from earlier cellular 87 generations, and describes how it may benefit from some form of 88 adaptation of MPTCP implementations and protocol aspects in the 5G 89 system (see Section 1.1). This document also describes how MPTCP may 90 be leveraged in 5G system specifications (see Section 1.2). 92 1.1. Need for Adapting MPTCP to 5G Session and Service Continuity 94 With regards to 5G session and service continuity mechanisms, MPTCP 95 stack behavior (including path manager and scheduling) should be 96 updated to achieve optimal performance: 98 o Proposed 5G MPTCP behavior is described in Section 2.2, 99 Section 2.3 and Section 2.4. 101 o To enable this behavior, MPTCP will need additional information 102 about local IP addresses: (1) its session continuity service type 103 and (2) a notification that a new IP address has been provided for 104 service continuity. This is described in Section 2.1. 106 o Remote MPTCP peers may need access to the IP address SCS type 107 (through MPTCP signaling or otherwise). This is discussed in 108 Section 2.5. 110 1.2. Opportunity for Leveraging MPTCP in 5G Dual Connectivity Feature 112 With regards to dual connectivity, MPTCP can be closely integrated 113 with the 5G stack to avoid duplicating its feature in 5G, as 114 discussed in Section 3. As a summary: 116 o MPTCP should be aware of the presence of multiple DC radio links, 117 which may be exposed as a single or distinct network interfaces/IP 118 addresses. 120 o MPTCP should optimally partition traffic or duplicate a data flow 121 over DC links, depending on the application's need, network policy 122 and conditions. 124 2. Impact of 5G Session and Service Continuity on MPTCP 126 One of the goals of 5G systems, as outlined in [_3GPP.23.501], is to 127 enable low latency services and access to local data networks where 128 mobility anchors can be deployed close to devices, thereby satisfying 129 use cases with stringent transmission delay and high reliability. 130 Mobility in 4G networks, as described at the architecture level in 131 [_3GPP.23.401], was based on a central mobility solution that made it 132 difficult to relocate mobility anchors closer to the end user. In 133 contrast, 5G uses a distributed mobility solution based on multiple 134 anchors providing different IP addresses as the device moves from one 135 area to another. 137 The base scenario in this section is: a 5G device connected to a 138 single-homed server is in an area with no usable Wifi coverage. An 139 application using MPTCP sends traffic over a single subflow, over the 140 cellular air interface. Then, as the device moves, the 5G device 141 reacts to mobility events. Additionally, we briefly discuss cases 142 where the device switches from a Wifi to a cellular backup 143 connection, and other cases where both MPTCP peers are 5G mobile 144 devices. 146 In 5G, every unit of a network connectivity service (PDU session) has 147 a type which can be IP (IPv4 or IPv6), Ethernet or unstructured. 148 While session continuity is supported for all types, we will focus on 149 PDU sessions of IP type primarily. Different PDU sessions will 150 typically correspond to distinct network interfaces on the device 151 (though this is not explicit in the standard, and some 152 implementations may possibly behave differently). 154 In 4G networks, session continuity is enabled by anchoring a PDN 155 Connection (as PDU Sessions are referred to in 4G networks) to a P-GW 156 which allocates an IP address to the mobile device: PDN connection 157 and IP address allocation are maintained as long as the device 158 remains attached to the network, even when the device moves around. 159 In 5G, different types of session continuity can be provided, and are 160 indicated by a "Session and Service Continuity" (SSC) mode value of 161 1, 2 or 3 (defined in [_3GPP.23.501] section 5.6.9). Every PDU 162 session is associated with a single SSC mode, which cannot be changed 163 on this PDU session. The following sub-sections will study how 5G 164 handles each SSC mode, and potential effects on MPTCP. 166 2.1. New Inputs for MPTCP stacks 168 IP Address Session Continuity Service Type 170 The "session continuity service type" (SCS type) of an IP address 171 allocated by the network can be used as input by MPTCP 172 implementations. It has been defined for on-demand mobility 173 management [I-D.ietf-dmm-ondemand-mobility], as: 175 FIXED IP address: valid for a very long time, for session 176 continuity and IP address reachability. 178 SESSION_LASTING IP address: valid for the lifetime of an IP 179 session, even if the mobility host moves. 181 NON_PERSISTENT IP address: which does not provide session 182 continuity nor IP address reachability. 184 GRACEFUL_REPLACEMENT IP address: similar to a non-persistent 185 address, but adding a limited graceful period for the 186 transition from one address to another. 188 This information needs to be conveyed to the device by the network 189 that allocates the address: for example, as described in 190 [I-D.feng-dmm-ra-prefixtype], the SCS type of IP address may be 191 conveyed through router advertisements. The MPTCP stack may 192 obtain the SCS type of a local IP address using a programmatic 193 API. This information does not directly tell which SSC mode the 194 application is using, nevertheless it is sufficient for MPTCP to 195 appropriately and non-ambiguously decide how to handle new IP 196 addresses in the context of SSC in 5G. 198 Notification of a New IP Address from Session Continuity 200 As in non-5G cases, MPTCP starts handling the initial socket 201 created by the application. The initial connection attempt 202 triggers the creation of the first PDU session (or the reuse of an 203 existing one), associated with a network interface and an IP 204 address on this interface. Later on, the network decides to use a 205 new anchor, e.g., when a mobility event occurs or when a Local 206 Data Network becomes available. The network then triggers the 207 modification of the existing PDU session, or creation of a new PDU 208 session, and ultimately a new IP address is provided to the 5G 209 device, respectively on the same or a new network interface. 211 The 5G stack on the device is aware of the relationship between 212 the old and new IP addresses, and can therefore notify the MPTCP 213 stack. Such a notification may include both the old and new IP 214 addresses , which ensures that the MPTCP stack has all necessary 215 information (for example, the MPTCP stack may then obtain the SCS 216 type of the new IP address, and the validity lifetime associated 217 with the old IP address, if it is still up). 219 2.2. SSC mode 1 221 In SSC mode 1 the same network anchor is kept regardless of device 222 location. An application running on the device will therefore be 223 able to keep using the same IP address on the same interface. 225 Additionally, in SSC mode 1, the network may decide to add and 226 remove, dynamically, additional network anchors (and therefore IP 227 addresses) to the PDU session, while always keeping the initial one. 229 PROPOSED MPTCP BEHAVIOR SPECIFICATION: 231 These steps are applicable when the initial IP address returned by 232 the network stack is FIXED or SESSION_LASTING. 234 MPTCP should not close all subflows originated from this original 235 IP address at any point during the session, since this IP address 236 is the only one that is guaranteed, under normal circumstances, to 237 be maintained over time for this application. 239 At any time during the session, a new IP address of SCS type 240 NON_PERSISTENT may become available. MPTCP may create new 241 subflows for the application, using this IP address (this IP 242 address is likely to provide shorter path subflows, but may 243 disappear at any time). 245 2.3. SSC mode 2 247 SSC mode 2 has a break-before-make behavior. When the device leaves 248 the service area of its first network anchor, the network stops using 249 it and starts using a new second network anchor closer to the device. 250 (Such service areas may have a highly variable size depending on 251 network deployments.) On the device, this can result in the 252 currently used network interface being brought down, and after a 253 short time a new network interface being brought up. The time 254 between these 2 events is not standardized and implementation 255 dependent. 257 Break-before-make within cellular technology 259 When MPTCP is active on cellular only, this break-before-make 260 behavior is similar to the existing break-before-make capability 261 usually used in cellular/Wifi offload (section 3.1.3 of [RFC6897] 262 and section 2.2 of [RFC8041]). A similar MPTCP behavior is 263 therefore needed: wait for a given time for a new IP address to be 264 configured. As per [RFC6897], to benefit from this MPTCP 265 resilience feature, the application should not request using a 266 specific network interface. 268 Cellular and Wifi 270 Additionally, when Wifi is active and cellular is used as backup, 271 MPTCP implementations should also support this break-before-make 272 behavior to maintain a usable backup IP address on cellular. In 273 rare cases where a switch-to-cellular backup would be needed 274 during a break-before-make transition on cellular, MPTCP's 275 existing break-before-make capability can ensure MPTCP waits for a 276 new cellular-facing IP address to be available. 278 PROPOSED MPTCP BEHAVIOR SPECIFICATION: 280 These steps are applicable when the initial IP address returned by 281 the network stack is NON_PERSISTENT. 283 At any point in time, the current NON_PERSISTENT IP address may be 284 taken down by the network stack. The MPTCP stack should wait for 285 another NON_PERSISTENT IP address to be made available by the 286 network stack. If such an address is made available within a 287 given time limit, the MPTCP stack should create new subflows using 288 this new address (effectively following the existing break-before- 289 make behavior present in MPTCP). 291 Additionally, if an initial backup IP address is a NON_PERSISTENT 292 address, the MPTCP stack should consider any subsequent 293 NON_PERSISTENT IP address as a backup IP address in replacement of 294 the initial NON_PERSISTENT address. 296 2.4. SSC mode 3 298 SSC mode 3 has a make-before-break behavior. When the device leaves 299 the service area of its first network anchor, the network selects a 300 second network anchor closer to the device, and either creates a new 301 PDU session (i.e. new IP address on new network interface) or share 302 the existing PDU session (i.e. new IP address on same network 303 interface). The first network anchor keeps being used for a given 304 time period, which is communicated to the device by the network using 305 the "valid lifetime" field of a prefix information option in a router 306 advertisement ([RFC4861], [RFC4862]). 5G does not mandate a specific 307 range for this valid lifetime. The first/older IP address should not 308 be used to create any new traffic ([RFC4862] section 5.5.4). In some 309 implementations, the network (SMF) may decide to release the first 310 network anchor as soon as it stops carrying traffic. 312 There is no limit set by the 5G standard for the number of 313 concurrently used network anchors. We expect that in usual cases the 314 first network anchor will be released before a third network anchor 315 starts being used. Nevertheless, to our knowledge nothing prevents a 316 5G system deployment to allow a third network anchor to be selected 317 while the first one is still in use. 319 On the 5G device, when using SSC mode 3, mobility will therefore 320 result in a new IP address being configured, either on the same 321 network interface initially used, or on a different interface. In 322 general, an application will see a single cellular-facing IP address, 323 and during transient phase it will see 2 IP addresses (with a 324 possibility for more than 2 concurrent IP addresses on some 5G system 325 implementations). In cases where the server is single-homed and the 326 Wifi interface is down, and assuming a full-mesh path manager policy, 327 there will be in general one subflow, and from time to time, 328 temporarily 2 subflows (or more on some 5G systems). In cases where 329 two mobile 5G devices are communicating with each other over MPTCP 330 and with the same assumptions on Wifi and path manager policy, there 331 will be in general one subflow, and from time to time, temporarily 2 332 or even more rarely 4 subflows (again, possibly more on some 5G 333 systems). 335 MPTCP must create new subflows when a new IP address on a same or a 336 new cellular-facing network interface becomes available to the 337 application. MPTCP may keep using the first subflow during a 338 transient phase. Here are some considerations related to this 339 transient phase: 341 o When compared with simply waiting for the first IP address to be 342 brought down, ramping down usage of the first subflow will not 343 incur inefficiencies from resending lost segments. This may 344 especially help low-latency applications by avoiding throughput 345 drop. 347 o Assuming a lowest-rtt-first scheduling policy is used, after the 348 initial TCP slow start, the shortest path subflow should typically 349 carry the most traffic. Ramping down should ideally start after 350 the initial slow start is over. 352 o To make sure the ramping down completes before the interface is 353 brought down by the network, the MPTCP stack should be aware of 354 how long will the first network anchor be kept in use, e.g. 355 through configuration or communication with the local 5G stack. 357 o Ramping down and closing flows on the first network anchor as soon 358 as possible will help recycling network resources more rapidly. 359 This is especially true in cases where more than 2 network anchors 360 may be used concurrently. 362 o There may be some level of contention between subflows during the 363 transient phase, since they share the same air interface, and 364 especially if they share the same PDU session and QoS marking. 365 The shortest path subflow may therefore not reach its full 366 capacity during the transient phase. 368 o Additionally, the shortest subflow must not be closed during the 369 transient phase (even if it is less efficient for some reason), to 370 avoid losing all connectivity at the end of the transient phase. 371 To avoid this issue, the MPTCP stack could for example follow a 372 policy not to close any subflow created using the latest IP 373 address, during the transient period (in SSC mode 3). 375 In cases where cellular is used for backup, there is a possibility 376 that the switch to using backup occurs during a transient phase. To 377 support this case, MPTCP should keep creating and releasing subflows 378 as described above, even when cellular subflows are used as backup, 379 to ensure that the backup is always usable. When a backup event 380 occurs during a transient phase, MPTCP should use the subflows 381 associated with the most recent cellular-facing IP address, i.e. 382 corresponding to the latest/closest network anchor. 384 PROPOSED MPTCP BEHAVIOR SPECIFICATION: 386 These steps are applicable when the initial IP address returned by 387 the network stack is GRACEFUL_REPLACEMENT. 389 At any point in time, a new GRACEFUL_REPLACEMENT IP address may be 390 made available by the network stack. The MPTCP stack must create 391 new subflows using this new address, gracefully transfer traffic 392 to these new subflow(s), and close subflow(s) using the previous 393 GRACEFUL_REPLACEMENT IP address before its scheduled closing 394 (known by obtaining the valid lifetime of the IP address from the 395 operating system). 397 Additionally, if an initial backup IP address is a 398 GRACEFUL_REPLACEMENT address, the MPTCP stack should consider any 399 subsequent GRACEFUL_REPLACEMENT IP address as the new backup IP 400 address, in replacement of the first GRACEFUL_REPLACEMENT IP 401 address. 403 2.5. Behavior of Remote Peer 405 The SCS type of an IP address is only available locally, which limits 406 to only one peer the MPTCP behavior specified in sections 407 Section 2.2, Section 2.3 and Section 2.4. This can potentially cause 408 problems: 410 A remote may for example close subflows that should be maintained 411 e.g. closing all subflows to a SESSION_LASTING IP address or to 412 the latest GRACEFUL_REPLACEMENT address. 414 A remote may also not behave optimally in some cases, e.g. because 415 it cannot distinguish between a transition from 416 GRACEFUL_REPLACEMENT to GRACEFUL_REPLACEMENT, from a temporary 417 addition of a NON_PERSISTENT address to a SESSION_LASTING address. 419 There are two possible ways to handle this: either explicitly 420 transmit the SCS type over MPTCP signalling, or use heuristics on the 421 remote peer (e.g. never close a subflow created by a peer, mirror 422 behavior of peer, etc.). In the explicit solution, a MPTCP peer 423 provides the SCS type of IP addresses to its remote peer, using 424 existing or new options (mp_capable, add_addr, mp_join, or an 425 experimental option). When compared to using heuristics, 426 transmitting the SCS type can lead to a less complex and more 427 explicit implementation, which can help better handling unusual or 428 error cases, and adapt to future evolution of 5G or other mobility 429 management systems. 431 3. MPTCP with 5G Dual Connectivity 433 One of the key features of 5G [_3GPP.23.501] is dual connectivity 434 (DC). With DC, a 5G device can be served by two different base 435 stations. DC may play an essential role in leveraging the benefit of 436 5G new radio, especially in the evolving architecture with the 437 coexistence of 4G and 5G radios. 439 On a 5G device with DC, an application is able to send data to the 440 destination (e.g., a single-home server) through multiple radio 441 links, over one or more PDU sessions. Some PDU sessions may be over 442 a single radio link, while others may have flows over each radio 443 link. Therefore, in a first case, DC can be made visible to 444 applications through different IP addresses, while in a second case, 445 DC can be used by different flows terminated at the same IP address 446 on the device. 448 In any of those cases, the issues of out of order delivery and 449 diverse latency values need to be supported in DC. However, such 450 reliable communication scenarios have not been addressed in the 451 current DC architecture. Based on the design history of DC in 452 earlier systems, the 5G system will need to incorporate features to 453 support robustness/reliability (e.g., backup and duplication), that 454 will likely result in added complexity. Meanwhile, similar issues 455 have been solved in MPTCP (e.g., two types of sequences at subflow 456 and connection levels for out of order delivery, etc.). MPTCP hence 457 could be leveraged in those scenarios. On the other hand, to satisfy 458 new QoS requirements of 5G applications as well as to benefit the 459 most from DC, 5G devices are expected to include advanced algorithms 460 that control data transmissions over each radio link optimally. For 461 example, those algorithms could aim to minimize overall latency or 462 satisfy latency requirements of applications. Hence, the 5G device 463 needs to dynamically select the most suitable path for a given radio 464 condition. Additionally, algorithms for shifting, based on 465 congestion, ongoing traffic between transmissions over radio links 466 are also necessary. 468 MPTCP, which includes path manager, scheduler, and congestion control 469 functions, shows a lot of potential to address the issues mentioned 470 above. MPTCP could, therefore, be integrated with DC and the 5G 471 protocol stack, as an alternative to developing 5G-specific 472 solutions. As part of this integration, the MPTCP stack should be 473 aware of the presence of multiple radio links, whether they are 474 exposed using multiple IP addresses or hidden under a single IP 475 address. MPTCP's scheduler should optimally partition traffic or 476 duplicate a data flow over different links, depending on the 477 application's need, network policy, and conditions. 479 4. IANA Considerations 481 This document requests no IANA actions. 483 5. Security Considerations 485 No new security considerations are identified at this time. 487 6. Acknowledgements 489 Thanks to following people for contributing, reviewing or providing 490 feedback: Debashish Purkayastha, Akbar Rahman, Ulises Olvera- 491 Hernandez, Sri Gundavelli. 493 7. Informative References 495 [_3GPP.23.401] 496 3GPP, "General Packet Radio Service (GPRS) enhancements 497 for Evolved Universal Terrestrial Radio Access Network 498 (E-UTRAN) access", 3GPP TS 23.401 15.3.0, 3 2018, 499 . 501 [_3GPP.23.501] 502 3GPP, "System Architecture for the 5G System", 3GPP 503 TS 23.501 15.14.0, 3 2018, 504 . 506 [I-D.feng-dmm-ra-prefixtype] 507 Feng, W. and D. Moses, "Router Advertisement Extensions 508 for On-Demand Mobility", draft-feng-dmm-ra-prefixtype-02 509 (work in progress), March 2018. 511 [I-D.ietf-dmm-ondemand-mobility] 512 Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S. 513 Jeon, "On Demand Mobility Management", draft-ietf-dmm- 514 ondemand-mobility-14 (work in progress), March 2018. 516 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 517 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 518 DOI 10.17487/RFC4861, September 2007, 519 . 521 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 522 Address Autoconfiguration", RFC 4862, 523 DOI 10.17487/RFC4862, September 2007, 524 . 526 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 527 "TCP Extensions for Multipath Operation with Multiple 528 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 529 . 531 [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application 532 Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, 533 March 2013, . 535 [RFC8041] Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and 536 Operational Experience with Multipath TCP", RFC 8041, 537 DOI 10.17487/RFC8041, January 2017, 538 . 540 Authors' Addresses 542 Xavier de Foy 543 InterDigital Communications, LLC 544 1000 Sherbrooke West 545 Montreal 546 Canada 548 Email: Xavier.Defoy@InterDigital.com 550 Michelle Perras 551 InterDigital Communications, LLC 552 Montreal 553 Canada 555 Email: Michelle.Perras@InterDigital.com 557 Uma Chunduri 558 Huawei USA 559 2330 Central Expressway 560 Santa Clara, CA 95050 561 USA 563 Email: uma.chunduri@huawei.com 564 Kien Nguyen 565 National Institute of Information and Communications Technology 566 YRP Center No.1 Building 7F, 3-4 Hikarinooka, Yokosuka 567 Kanagawa 239-0847 568 Japan 570 Email: kienng@nict.go.jp 572 Mirza Golam Kibria 573 National Institute of Information and Communications Technology 574 YRP Center No.1 Building 7F, 3-4 Hikarinooka, Yokosuka 575 Kanagawa 239-0847 576 Japan 578 Email: mirza.kibria@nict.go.jp 580 Kentaro Ishizu 581 National Institute of Information and Communications Technology 582 YRP Center No.1 Building 7F, 3-4 Hikarinooka, Yokosuka 583 Kanagawa 239-0847 584 Japan 586 Email: ishidu@nict.go.jp 588 Fumihide Kojima 589 National Institute of Information and Communications Technology 590 YRP Center No.1 Building 7F, 3-4 Hikarinooka, Yokosuka 591 Kanagawa 239-0847 592 Japan 594 Email: f-kojima@nict.go.jp