idnits 2.17.1 draft-kanugovi-intarea-mams-framework-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 240 instances of too long lines in the document, the longest one being 66 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2036 has weird spacing: '...isallow use|...' == Line 2072 has weird spacing: '...isallow use|...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The framework MUST leverage commonly available transport, routing and tunneling capabilities to provide user plane interworking functionality. The addition of functional elements in the user plane path between the client and the network MUST not impact the access technology specific procedures. This makes solution easy to deploy and scale when different networks are added and removed. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When switching data traffic from one path (connection) to another, packets may be lost or delivered out-of-order, which will have negative impacts on the performance of higher layer protocols, e.g. TCP. The framework SHOULD provide necessary mechanisms to ensure in-order delivery at the receiver, e.g. during path switching. The framework MUST not cause any packet loss beyond that of access network mobility functions may cause. -- The document date (May 31, 2019) is 1792 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 2784' is mentioned on line 765, but not defined == Missing Reference: 'RFC 2890' is mentioned on line 765, but not defined == Missing Reference: 'RFC6455' is mentioned on line 2194, but not defined == Missing Reference: 'RFC5246' is mentioned on line 2194, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Missing Reference: 'RFC2616' is mentioned on line 2459, but not defined ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Missing Reference: 'RFC7159' is mentioned on line 2592, but not defined ** Obsolete undefined reference: RFC 7159 (Obsoleted by RFC 8259) == Unused Reference: 'RFC2784' is defined on line 2382, but no explicit reference was found in the text == Unused Reference: 'RFC2890' is defined on line 2387, but no explicit reference was found in the text == Unused Reference: 'RFC6347' is defined on line 2396, but no explicit reference was found in the text == Unused Reference: 'RFC6824' is defined on line 2400, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-tcpm-converters-06 == Outdated reference: A later version (-14) exists of draft-zhu-intarea-gma-02 == Outdated reference: A later version (-09) exists of draft-zhu-intarea-mams-user-protocol-07 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 4 errors (**), 0 flaws (~~), 18 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTAREA S. Kanugovi 3 Internet-Draft Nokia 4 Intended status: Informational F. Baboescu 5 Expires: December 2, 2019 Broadcom 6 J. Zhu 7 Intel 8 J. Mueller 9 AT&T 10 S. Seo 11 Korea Telecom 12 May 31, 2019 14 Multiple Access Management Services 15 draft-kanugovi-intarea-mams-framework-04 17 Abstract 19 In multiconnectivity scenarios, the end-user devices can 20 simultaneously connect to multiple networks based on different access 21 technologies and network architectures like WiFi, LTE, DSL. Both the 22 quality of experience of the users and the overall network 23 utilization and efficiency may be improved through the smart 24 selection and combination of access and core network paths that can 25 dynamically adapt to changing network conditions. This document 26 presents a unified problem statement and introduces a solution for 27 managing multiconnectivity. The solution has been developed by the 28 authors based on their experiences in multiple standards bodies 29 including the IETF and 3GPP, but is not an Internet Standard and does 30 not represent the consensus opinion of the IETF. This document 31 describes the requirements, solution principles, and an architectural 32 framework that aims to provide best performance while being easy to 33 implement in a wide variety of multiconnectivity deployments. It 34 specifies the protocol multi-access management to: 1) flexibly select 35 the best combination of access and core network paths for uplink and 36 downlink; as well as 2) determine the user plane treatment and 37 traffic distribution over the selected links ensuring network 38 efficiency and application performance. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on December 2, 2019. 57 Copyright Notice 59 Copyright (c) 2019 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 77 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9 78 4.1. Access Technology Agnostic Interworking . . . . . . . . . 9 79 4.2. Support Common Transport Deployments . . . . . . . . . . 9 80 4.3. Independent Access Path Selection for Uplink and Downlink 9 81 4.4. Core Selection Independent of Uplink and Downlink Access 9 82 4.5. Adaptive Access Network Path Selection . . . . . . . . . 9 83 4.6. Multipath Support and Aggregation of Access Link 84 Capacities . . . . . . . . . . . . . . . . . . . . . . . 10 85 4.7. Scalable Mechanism based on User Plane Interworking . . . 10 86 4.8. Separate Control and Data Plane functions . . . . . . . . 10 87 4.9. Lossless Path (Connection) Switching . . . . . . . . . . 10 88 4.10. Concatenation and Fragmentation for adaptation to MTU 89 Differences . . . . . . . . . . . . . . . . . . . . . . . 11 90 4.11. Configuring Network Middleboxes based on Negotiated 91 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 11 92 4.12. Policy based Optimal Path Selection . . . . . . . . . . . 11 93 4.13. Access Technology Agnostic Control Signaling . . . . . . 11 94 4.14. Service Discovery and Reachability . . . . . . . . . . . 11 95 5. Solution Principles . . . . . . . . . . . . . . . . . . . . . 12 96 6. MAMS Reference Architecture . . . . . . . . . . . . . . . . . 12 97 7. MAMS Protocol Architecture . . . . . . . . . . . . . . . . . 15 98 7.1. MAMS Control-Plane Protocol . . . . . . . . . . . . . . . 15 99 7.2. MAMS User Plane Protocol . . . . . . . . . . . . . . . . 16 100 8. MAMS Control Plane Procedures . . . . . . . . . . . . . . . . 18 101 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18 102 8.2. Common fields in MAMS Control Messages . . . . . . . . . 20 103 8.3. Common Procedures for MAMS Control Messages . . . . . . . 20 104 8.3.1. Message Timeout . . . . . . . . . . . . . . . . . . . 20 105 8.3.2. Keep Alive Procedure . . . . . . . . . . . . . . . . 20 106 8.4. Discovery & Capability Exchange . . . . . . . . . . . . . 21 107 8.5. User Plane Configuration . . . . . . . . . . . . . . . . 25 108 8.6. MAMS Path Quality Estimation . . . . . . . . . . . . . . 29 109 8.6.1. MX Control PDU definition . . . . . . . . . . . . . . 31 110 8.6.2. Keep-Alive Message . . . . . . . . . . . . . . . . . 32 111 8.6.3. Probe REQ/ACK Message . . . . . . . . . . . . . . . . 32 112 8.7. MAMS Traffic Steering . . . . . . . . . . . . . . . . . . 33 113 8.8. MAMS Application MADP Association . . . . . . . . . . . . 34 114 8.9. MAMS Network ID Indication . . . . . . . . . . . . . . . 35 115 8.10. MAMS Client Measurement Configuration and Reporting . . . 36 116 8.11. MAMS Session Termination Procedure . . . . . . . . . . . 38 117 8.12. MAMS Network Analytics Request Procedure . . . . . . . . 39 118 9. Generic MAMS Signaling Flow . . . . . . . . . . . . . . . . . 41 119 10. Relation to IETF Technologies . . . . . . . . . . . . . . . . 43 120 11. Applying MAMS Control Procedures with MPTCP Proxy as User 121 Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 122 12. Applying MAMS Control Procedures for Network Assisted Traffic 123 Steering when there is No Convergence Layer . . . . . . . . . 49 124 13. Co-existence of MX Adaptation and MX Convergence Layers . . . 51 125 14. Security Considerations . . . . . . . . . . . . . . . . . . . 51 126 14.1. MAMS Control Plane Security . . . . . . . . . . . . . . 51 127 14.2. MAMS User Plane Security . . . . . . . . . . . . . . . . 52 128 15. Implementation Considerations . . . . . . . . . . . . . . . . 52 129 16. Applicability to Multi Access Edge Computing . . . . . . . . 52 130 17. Related work in other Industry and Standards Forums . . . . . 53 131 18. Contributing Authors . . . . . . . . . . . . . . . . . . . . 53 132 19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 133 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 134 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 135 21.1. Normative References . . . . . . . . . . . . . . . . . . 54 136 21.2. Informative References . . . . . . . . . . . . . . . . . 54 137 Appendix A. MAMS Control Plane Optimization over Secure 138 Connections . . . . . . . . . . . . . . . . . . . . 56 139 Appendix B. MAMS Application Interface . . . . . . . . . . . . . 57 140 B.1. Overall Design . . . . . . . . . . . . . . . . . . . . . 57 141 B.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 57 142 B.3. Error Indication . . . . . . . . . . . . . . . . . . . . 57 143 B.4. CCM APIs . . . . . . . . . . . . . . . . . . . . . . . . 57 144 B.4.1. Get Capabilities . . . . . . . . . . . . . . . . . . 57 145 B.4.2. Post App Requirements . . . . . . . . . . . . . . . . 58 146 B.4.3. Get Predictive Link Parameters . . . . . . . . . . . 59 147 Appendix C. JSON Specification for MAMS Control Plane . . . . . 60 148 C.1. Protocol Specification: General Processing . . . . . . . 60 149 C.1.1. Notation . . . . . . . . . . . . . . . . . . . . . . 60 150 C.1.2. Discovery Procedure . . . . . . . . . . . . . . . . . 61 151 C.1.3. System Information Procedure . . . . . . . . . . . . 61 152 C.1.4. Capability Exchange Procedure . . . . . . . . . . . . 62 153 C.1.5. User Plane Configuration Procedure . . . . . . . . . 63 154 C.1.6. Reconfiguration Procedure . . . . . . . . . . . . . . 65 155 C.1.7. Path Estimation Procedure . . . . . . . . . . . . . . 66 156 C.1.8. Traffic Steering Procedure . . . . . . . . . . . . . 67 157 C.1.9. MAMS Application MADP Association . . . . . . . . . . 68 158 C.1.10. SSID Indication . . . . . . . . . . . . . . . . . . . 69 159 C.1.11. Measurements . . . . . . . . . . . . . . . . . . . . 70 160 C.1.12. Keep Alive . . . . . . . . . . . . . . . . . . . . . 71 161 C.1.13. Session Termination Procedure . . . . . . . . . . . . 72 162 C.1.14. Network Analytics . . . . . . . . . . . . . . . . . . 73 163 C.2. Protocol Specification: Data Types . . . . . . . . . . . 74 164 C.2.1. MXBase . . . . . . . . . . . . . . . . . . . . . . . 74 165 C.2.2. Unique Session Id . . . . . . . . . . . . . . . . . . 75 166 C.2.3. NCM Connections . . . . . . . . . . . . . . . . . . . 76 167 C.2.4. Connection Information . . . . . . . . . . . . . . . 76 168 C.2.5. Features Activation Status . . . . . . . . . . . . . 77 169 C.2.6. Anchor Connections . . . . . . . . . . . . . . . . . 77 170 C.2.7. Delivery Connections . . . . . . . . . . . . . . . . 78 171 C.2.8. Method Support . . . . . . . . . . . . . . . . . . . 78 172 C.2.9. Convergence Methods . . . . . . . . . . . . . . . . . 78 173 C.2.10. Adaptation Methods . . . . . . . . . . . . . . . . . 79 174 C.2.11. Setup of Anchor Connections . . . . . . . . . . . . . 79 175 C.2.12. Init Probe Results . . . . . . . . . . . . . . . . . 81 176 C.2.13. Active Probe Results . . . . . . . . . . . . . . . . 82 177 C.2.14. Downlink Delivery . . . . . . . . . . . . . . . . . . 82 178 C.2.15. Uplink Delivery . . . . . . . . . . . . . . . . . . . 82 179 C.2.16. Traffic Flow Template . . . . . . . . . . . . . . . . 83 180 C.2.17. Measurement Report Configuration . . . . . . . . . . 83 181 C.2.18. Measurement Report . . . . . . . . . . . . . . . . . 84 182 C.3. Schemas in JSON . . . . . . . . . . . . . . . . . . . . . 85 183 C.3.1. MX Base Schema . . . . . . . . . . . . . . . . . . . 85 184 C.3.2. MX Definitions . . . . . . . . . . . . . . . . . . . 86 185 C.3.3. MX Discover . . . . . . . . . . . . . . . . . . . . . 93 186 C.3.4. MX System Update . . . . . . . . . . . . . . . . . . 93 187 C.3.5. MX Capability Request . . . . . . . . . . . . . . . . 94 188 C.3.6. MX Capability Response . . . . . . . . . . . . . . . 95 189 C.3.7. MX Capability Ack . . . . . . . . . . . . . . . . . . 96 190 C.3.8. MX Reconfiguration Request . . . . . . . . . . . . . 97 191 C.3.9. MX Reconfiguration Response . . . . . . . . . . . . . 98 192 C.3.10. MX UP Setup Configuration . . . . . . . . . . . . . . 99 193 C.3.11. MX UP Setup Confirmation . . . . . . . . . . . . . . 100 194 C.3.12. MX Traffic Steering Request . . . . . . . . . . . . . 101 195 C.3.13. MX Traffic Steering Response . . . . . . . . . . . . 101 196 C.3.14. MX Application MADP Association Request . . . . . . . 102 197 C.3.15. MX Application MADP Association Response . . . . . . 103 198 C.3.16. MX Path Estimation Request . . . . . . . . . . . . . 103 199 C.3.17. MX Path Estimation Report . . . . . . . . . . . . . . 104 200 C.3.18. MX SSID Indication . . . . . . . . . . . . . . . . . 105 201 C.3.19. MX Measurements Configuration . . . . . . . . . . . . 106 202 C.3.20. MX Measurements Report . . . . . . . . . . . . . . . 107 203 C.3.21. MX Keep Alive Request . . . . . . . . . . . . . . . . 109 204 C.3.22. MX Keep Alive Response . . . . . . . . . . . . . . . 109 205 C.3.23. MX Session Termination Request . . . . . . . . . . . 109 206 C.3.24. MX Session Termination Response . . . . . . . . . . . 110 207 C.3.25. MX Network Analytics Request . . . . . . . . . . . . 110 208 C.3.26. MX Network Analytics Response . . . . . . . . . . . . 111 209 C.4. Examples in JSON . . . . . . . . . . . . . . . . . . . . 112 210 C.4.1. MX Discover . . . . . . . . . . . . . . . . . . . . . 112 211 C.4.2. MX System Update . . . . . . . . . . . . . . . . . . 112 212 C.4.3. MX Capability Request . . . . . . . . . . . . . . . . 113 213 C.4.4. MX Capability Response . . . . . . . . . . . . . . . 115 214 C.4.5. MX Capability Ack . . . . . . . . . . . . . . . . . . 116 215 C.4.6. MX Reconfiguration Request . . . . . . . . . . . . . 116 216 C.4.7. MX Reconfiguration Response . . . . . . . . . . . . . 117 217 C.4.8. MX UP Setup Configuration Request . . . . . . . . . . 117 218 C.4.9. MX UP Setup Confirmation . . . . . . . . . . . . . . 119 219 C.4.10. MX Traffic Steering Request . . . . . . . . . . . . . 119 220 C.4.11. MX Traffic Steering Response . . . . . . . . . . . . 121 221 C.4.12. MX Application MADP Association Request . . . . . . . 121 222 C.4.13. MX Application MADP Association Response . . . . . . 122 223 C.4.14. MX Path Estimation Request . . . . . . . . . . . . . 122 224 C.4.15. MX Path Estimation Results . . . . . . . . . . . . . 123 225 C.4.16. MX SSID Indication . . . . . . . . . . . . . . . . . 123 226 C.4.17. MX Measurements Configuration . . . . . . . . . . . . 124 227 C.4.18. MX Measurements Report . . . . . . . . . . . . . . . 125 228 C.4.19. MX Keep Alive Request . . . . . . . . . . . . . . . . 127 229 C.4.20. MX Keep Alive Response . . . . . . . . . . . . . . . 127 230 C.4.21. MX Session Termination Request . . . . . . . . . . . 127 231 C.4.22. MX Session Termination Response . . . . . . . . . . . 127 232 C.4.23. MX Network Analytics Request . . . . . . . . . . . . 128 233 C.4.24. MX Network Analytics Response . . . . . . . . . . . . 128 234 Appendix D. Definition of APIs provided by CCM to the 235 Applications at the Client . . . . . . . . . . . . . 129 236 Appendix E. Implementation Example using Python for MAMS Client 237 and Server . . . . . . . . . . . . . . . . . . . . . 137 238 E.1. Client Side Implementation . . . . . . . . . . . . . . . 137 239 E.2. Server Side Implementation . . . . . . . . . . . . . . . 139 240 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 141 242 1. Introduction 244 Multi Access Management Services (MAMS) is a programmable framework 245 that provides mechanisms for flexible selection of network paths in a 246 multi-access communication environment, based on application needs. 247 It leverages network intelligence and policies to dynamically adapt 248 traffic distribution across selected paths and user plane treatment 249 to changing network/link conditions. The network path selection and 250 configuration messages are carried as user plane data between the 251 functional elements in the network and the end-user device, and thus 252 without any impact to the control plane signaling schemes of the 253 underlying access network(s). For example, in a multi-access network 254 with LTE and WiFi technologies, existing LTE and existing WiFi 255 signaling procedures will be used to setup the LTE and WiFi 256 connections, respectively, and MAMS specific control plane messages 257 are carried as LTE or WiFi user plane data. The MAMS framework 258 defined in this document provides the capabilities of smart selection 259 and flexible combination of access paths and core network paths, as 260 well as the user plane treatment when the traffic is distributed 261 across the selected paths. Thus, it is a broad programmable 262 framework providing functions beyond simple sharing of network 263 policies such as provided by Access Network Discovery and Selection 264 Function (ANDSF) [ANDSF] that offers policies and rules for assisting 265 3GPP devices to discover and select available access networks. 266 Further, it allows the choice and configuration of user plane 267 treatment for the traffic over the multiple paths, depending on the 268 needs of the application. 270 MAMS mechanisms are not dependent on any specific access network type 271 or user plane protocols like TCP, UDP, GRE, MPTCP etc. It co-exists 272 and complements the existing protocols by providing a way to 273 negotiate and configure these protocols based on client and network 274 capabilities per access basis to match their use for a given multi- 275 access scenario. Further, it allows load balancing of the traffic 276 flows across the selected multiple accesses and exchange of network 277 state information to be used for network intelligence to optimize the 278 performance of such protocols. 280 The document presents the requirements, solution principles, 281 functional architecture, and protocols for realizing the MAMS 282 framework. An important goal for MAMS is to ensure that it either 283 requires minimum dependency or (better) no dependency on the actual 284 access technologies of the participating links, beyond the fact that 285 MAMS functional elements form an IP-overlay across the multiple 286 paths. This allows the scheme to be future proof by allowing 287 independent technology evolution of the existing access and core 288 networks as well as, seamless integration of new access technologies. 290 The solution described in this document has been developed by the 291 authors based on their experiences in multiple standards bodies 292 including the IETF and 3GPP, but is not an Internet Standard and does 293 not represent the consensus opinion of the IETF. 295 2. Terminology 297 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 298 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 299 "OPTIONAL" in this document are to be interpreted as described in BCP 300 14 [RFC2119] [RFC8174] when, and only when, they appear in all 301 capitals, as shown here. 303 "Client": The end-user device supporting connections with multiple 304 access nodes, possibly over different access technologies. 306 "Multiconnectivity Client": A client with multiple network 307 connections. 309 "Access network": The segment in the network that delivers user data 310 packets to the client via an access link like WiFi airlink, LTE 311 airlink, or DSL. 313 "Core": The functional element that anchors the client IP address 314 used for communication with applications via the network. 316 "Network Connection manager"(NCM): A functional entity in the network 317 that handles MAMS control messages from the client and configures 318 distribution of data packets over the multiple available access and 319 core network paths, and user plane treatment of the traffic flows. 321 "Client Connection Manager" (CCM): A functional entity in the client 322 that exchanges MAMS Signaling with the Network Connection Manager and 323 configures the multiple network paths at the client for transport of 324 user data. 326 "Network Multi Access Data Proxy" (N-MADP): This functional entity in 327 the network handles the user data traffic forwarding across multiple 328 network paths. N-MADP is responsible for MAMS related user-plane 329 functionalities in the network. 331 "Client Multi Access Data Proxy" (C-MADP): This functional entity in 332 the client handles the user data traffic forwarding across multiple 333 network paths. C-MADP is responsible for MAMS related user-plane 334 functionalities in the client. 336 "Anchor Connection": Refers to the network path from the N-MADP to 337 the user plane gateway (IP anchor ) that has assigned an IP address 338 to the client. 340 "Delivery Connection": Refers to the network path from the N-MADP to 341 the client. 343 3. Problem Statement 345 Typically, an end-user device has access to multiple communication 346 networks based on different technologies, say LTE, WiFi, DSL, 347 MuLTEfire, for accessing application services. Different 348 technologies exhibit benefits and limitations in different scenarios. 349 For example, WiFi provides high throughput for end users when under 350 good coverage, but the throughput degrades significantly as the user 351 moves closer to the edge of WiFi coverage (typically in the range of 352 few tens of meters) or with large user population (due to contention 353 based WiFi access scheme). In LTE networks, the capacity is often 354 constrained by the limited availability of licensed spectrum. 355 However, the quality of the service is predictable even in multi-user 356 scenarios due to controlled scheduling and licensed spectrum usage. 358 Additionally, the use of a particular access network path is often 359 coupled with the use of its associated core network and the services 360 that are offered by it. For example, in an enterprise that has 361 deployed both WiFi and LTE networks, the enterprise services, like 362 printers, Corporate Audio and Video conferencing, are accessible only 363 via WiFi access connected to the enterprise hosted (WiFi) core, 364 whereas the LTE access can be used to get operator core anchored 365 services including access to public Internet. 367 Thus, application performance in different scenarios becomes 368 dependent on the choice of the access networks (e.g. WiFi, LTE, 369 etc.) and the used network and transport protocols (e.g. VPN, MPTCP, 370 GRE etc.). Therefore, to achieve the best possible application 371 performance in a wide range of scenarios, a framework is needed that 372 allows the selection and flexible combination of access and core 373 network paths and used protocols for uplink and downlink data 374 delivery. 376 For example, to ensure best performance for enterprise applications 377 at all times, in uncongested scenarios, when the user is under good 378 WiFi coverage, it would be beneficial to use WiFi access in both 379 uplink and downlink for connecting to enterprise applications. 380 However, in congested scenarios or when the user is getting close to 381 the edge of its WiFi coverage, the use of WiFi in uplink by multiple 382 users can lead to degraded capacity and increased delays due to 383 contention. In this case, it would be beneficial to at least use the 384 LTE access for increased uplink coverage while WiFi may still 385 continue to be used for downlink. 387 4. Requirements 389 The requirements set out in this section are for the definition of 390 behavior of the MAMS mechanism and the related functional elements. 392 4.1. Access Technology Agnostic Interworking 394 The access nodes may use different technology types like LTE, WiFi, 395 etc. The framework, however, MUST be agnostic to the type of 396 underlying technology used at the access network. 398 4.2. Support Common Transport Deployments 400 The network path selection and user data distribution MUST work 401 transparently across various transport deployments that include end- 402 to-end IPsec, VPNs, and middleboxes like NATs and proxies. 404 4.3. Independent Access Path Selection for Uplink and Downlink 406 A Client SHOULD be able to transmit on the uplink and, receive on the 407 downlink, using one or more accesses. The selection of the access 408 paths for uplink and downlink SHOULD happen independent of each 409 other. 411 4.4. Core Selection Independent of Uplink and Downlink Access 413 A client SHOULD flexibly select the Core, independent of the access 414 paths used to reach the Core, depending on the application needs, 415 local policies and the result of MAMS control plane negotiation. 417 4.5. Adaptive Access Network Path Selection 419 The framework MUST have the ability to determine the quality of each 420 of the network paths, e.g. access link delay and capacity. The 421 network path quality information needs to be considered in the logic 422 for selection of the combination of network paths to be used for 423 transporting user data. The path selection algorithm can use network 424 path quality information, in addition to other considerations like 425 network policies, for optimizing network usage and enhancing QoE 426 delivered to the user. 428 4.6. Multipath Support and Aggregation of Access Link Capacities 430 The framework MUST support distribution and aggregation of user data 431 across multiple network paths at the IP layer. The client SHOULD be 432 able to leverage the combined capacity of the multiple network 433 connections by enabling simultaneous transport of user data over 434 multiple network paths. If required, packet re-ordering needs to be 435 done at the receiver. The framework MUST allow flexibility to choose 436 the flow steering and aggregation protocols based on capabilities 437 supported by the client and the network data plane entities. The 438 multi-connection aggregation solution MUST support existing transport 439 and network layer protocols like TCP, UDP, GRE. The framework MUST 440 allow use and configuration of existing aggregation protocols such as 441 Multi-Path TCP(MPTCP) and SCTP. 443 4.7. Scalable Mechanism based on User Plane Interworking 445 The framework MUST leverage commonly available transport, routing and 446 tunneling capabilities to provide user plane interworking 447 functionality. The addition of functional elements in the user plane 448 path between the client and the network MUST not impact the access 449 technology specific procedures. This makes solution easy to deploy 450 and scale when different networks are added and removed. 452 4.8. Separate Control and Data Plane functions 454 The client MUST use the control plane protocol to negotiate with the 455 network, the choice of access and core network paths for both uplink 456 and downlink, as well as the user plane protocol treatment. The 457 control plane MUST configure the actual user plane data distribution 458 function per this negotiation. A common control protocol SHOULD 459 allow creation of multiple user plane function instance with 460 potentially different user plane (e.g. tunneling) protocol types. 461 This enables maintaining a clear separation between the control and 462 data plane functions, allowing the framework to be scalable and 463 extensible, e.g. using SDN based architecture and implementations. 465 4.9. Lossless Path (Connection) Switching 467 When switching data traffic from one path (connection) to another, 468 packets may be lost or delivered out-of-order, which will have 469 negative impacts on the performance of higher layer protocols, e.g. 470 TCP. The framework SHOULD provide necessary mechanisms to ensure in- 471 order delivery at the receiver, e.g. during path switching. The 472 framework MUST not cause any packet loss beyond that of access 473 network mobility functions may cause. 475 4.10. Concatenation and Fragmentation for adaptation to MTU Differences 477 Different network paths may have different security and middlebox 478 (e.g NAT) configurations, which will lead to use of different 479 tunneling protocols for transport of data between the network user 480 plane function and the client. As a result, different effective 481 payload sizes (e.g. due to variable encapsulation header overheads) 482 per network path are possible. Hence, MAMS framework SHOULD support 483 fragmentation of a single IP packet payload across MTU sized IP 484 packets to avoid IP fragmentation when aggregating packets from 485 different paths. Further, concatenation of multiple IP packets into 486 a single IP packet to improve efficiency in packing the MTU size 487 should also be supported. 489 4.11. Configuring Network Middleboxes based on Negotiated Protocols 491 The framework SHOULD enable identification of the optimal parameters 492 that may be used for configuring the middle-boxes, like radio link 493 dormancy timers, binding expiry times and supported MTUs, for 494 efficient operation of the user plane protocols, based on parameters 495 negotiated between the client and the network, e.g. Configuring 496 longer binding expiry time in NATs when UDP transport is used in 497 contrast to the scenario where TCP is configured at the transport 498 layer. 500 4.12. Policy based Optimal Path Selection 502 The framework MUST support consideration of policies at the client, 503 in addition to guidance from the network, for network path selection 504 addressing different application requirements. 506 4.13. Access Technology Agnostic Control Signaling 508 The control plane signaling MUST NOT be dependent on the underlying 509 access technology procedures, e.g. be carried transparently as user 510 plane. It should support delivery of control plane signaling over 511 the existing Internet protocols, e.g. TCP or UDP. 513 4.14. Service Discovery and Reachability 515 There can be multiple instances of the control and user plane 516 functional elements of the framework, either collocated or hosted on 517 separate network elements, and reachable via any of the available 518 user plane paths. The client MUST have flexibility to choose the 519 appropriate control plane instance in the network and use the control 520 plane signaling to choose the desired user plane functional element 521 instances. The choice can be based on considerations like, but not 522 limited to, quality of link through which the network function is 523 reachable, client preferences, pre-configuration etc. 525 5. Solution Principles 527 This document proposes the Multiple Access Management Services(MAMS) 528 framework for dynamic selection and flexible combination of access 529 and core network paths independently for the uplink and downlink, as 530 well as the user plane treatment for the traffic spread across the 531 selected links. MAMS framework consists of clearly separated control 532 and user plane functions in the network and the client. The control 533 plane protocol allows configuration of the user plane protocols and 534 desired network paths for transport of application traffic. The 535 control plane messages are carried as user plane data over any of the 536 available network paths between the peer control plane functional 537 elements in the client and the network . Multiple user plane paths 538 are dynamically distributed across multiple access networks and 539 aggregated in side the common core network. The access network 540 diversity is not exposed to the application servers but kept within 541 the scope of the elements defined in this framework. This offloads 542 the application servers from reacting to access link changes caused 543 to mobility events or changing of link characteristics. The 544 selection of paths and user plane treatment of the traffic, is based 545 on negotiation of capabilities (of device and network) and probing of 546 network link quality between the user plane functional elements at 547 the end-user device/client and the network. The framework enables 548 leveraging network intelligence to setup and dynamically configure 549 the best access network path combination based on device and network 550 capabilities, application needs and knowledge of the network state. 552 6. MAMS Reference Architecture 553 +--------------------------------------------------------+ 554 | +---------------+ +---------------+ | 555 | ! ! ! ! | 556 | !Core(IP anchor)! +---+ !Core(IP anchor)! | 557 | !network 1 ! !(network 'n' ! | 558 | ! ! ! ! | 559 | +---------------+ +---------------+ | 560 | \ / | 561 | Anchor \ +---+ Anchor | 562 | Connection 1 Connection 'n' | 563 | \ / | 564 | +---------------+\+---+/+------+ | 565 | | |-----+ +----------+ | | 566 | +----|NCM ! | N-MADP | | | 567 | | | |-----+ +----------+ | | 568 | | +------------------------------+ | 569 | | / \ | 570 | Control Plane Delivery +----+Delivery | 571 | Path (over any Connection 1 Connection 'n' | 572 | access user plane) / \ | 573 | | / \ | 574 | +------------------+ +---------------+ | 575 | | | Access | +---+ | Access | | 576 | | | n/w 1 | | n/w 'n' | | 577 | +------------------+ +---------/-----+ | 578 +-----------------------------\----------------/---------+ 579 | \ / 580 | +---- -\------------/-+ 581 | | +---+ \ |------+ / | 582 +------------+CCM | \|C-MADP|/ | 583 | +---+ +------+ | 584 | Client | 585 +---------------------+ 587 Figure 1: MAMS Reference Architecture 589 Figure 1 illustrates MAMS architecture for the scenario of a client 590 served by multiple (n) networks. It introduces the following 591 functional elements, 593 o Network Connection Manager (NCM) and Client Connection Manager 594 (CCM) in the control plane, and 595 o Network Multi Access Data Proxy (N-MADP) and Client Multi Access 596 Data Proxy (C-MADP) handling the user plane. 598 NCM: It is the functional element in the network that handles the 599 MAMS control plane procedures. It configures the network (N-MADP) 600 and client (C-MADP) user plane functions like negotiating the client 601 on the use of available access network paths, protocols and rules for 602 processing the user plane traffic, as well as link monitoring 603 procedures. The control plane messages between the NCM and CCM are 604 transported as an overlay, without any impact to the underlying 605 access networks. 607 CCM: It is the peer functional element in the client for handling 608 MAMS control plane procedures. It manages multiple network 609 connections at the client. It is responsible for exchange of MAMS 610 signaling messages with the NCM for supporting functions like UL and 611 DL user network path configuration for transporting user data 612 packets, link probing and reporting to support adaptive network path 613 selection by NCM. In the downlink, for the user data received by the 614 client, it configures C-MADP such that application data packet 615 received over any of the accesses to reach the appropriate 616 application on the client. In the uplink, for the data transmitted 617 by the client, it configures the C-MADP to determine the best access 618 links to be used for uplink data based on a combination of local 619 policy and network policy delivered by the NCM. 621 N-MADP: It is the functional element in the network that handles the 622 user data traffic forwarding across multiple network paths, as well 623 as other user-plane functionalities like encapsulation, 624 fragmentation, concatenation, reordering, retransmission, etc. It is 625 the distribution node that routes the uplink user plane traffic to 626 the appropriate anchor connection towards the core network, and the 627 downlink user traffic to the client over the appropriate delivery 628 connection(s). In the downlink, the NCM configures the use of 629 delivery connections, and user plane protocols at the N-MADP for 630 transporting user data traffic. The N-MADP should implement ECMP 631 support for the down link traffic. Or alternatively, it may be 632 connected to a router with ECMP functionality. The load balancing 633 algorithm at the N-MADP is configured by the NCM, based on static 634 and/or dynamic network policies like assigning access and core paths 635 for specific user data traffic type, data volume based percentage 636 distribution, and link availability and feedback information from 637 exchange of MAMS signaling with the CCM at the Client.. N-MADP can be 638 configured with appropriate user plane protocols to support both per- 639 flow and per-packet traffic distribution across the delivery 640 connections. In the uplink, N-MADP selects the appropriate anchor 641 connection over which to forward the user data traffic, received from 642 the client (via the delivery connections). The forwarding rules in 643 the uplink at the N-MADP are configured by the NCM based on 644 application requirements, e.g. Enterprise hosted Application flows 645 via Wi-Fi Anchor, Mobile Operator hosted applications via the 646 Cellular Core. 648 C-MADP: It is the functional element in the client that handles the 649 MAMS user plane data procedures. C-MADP is configured by CCM based 650 on signaling exchange with NCM and local policies at the client. The 651 CCM configures the selection of delivery connections and the user 652 plane protocols to be used for uplink user data traffic based on the 653 signaling exchanged with NCM. The C-MADP entity handles user plane 654 data forwarding across multiple delivery connections and associated 655 user-plane functions like encapsulation, fragmentation, 656 concatenation, reordering, retransmissions, etc. 658 The NCM and N-MADP can be either collocated or instantiated on 659 different network nodes. NCM can setup multiple N-MADP instances in 660 the network. NCM controls the selection of N-MADP instance by the 661 client and the rules for distribution of user traffic across the 662 N-MADP instances., This is beneficial in multple deployment 663 scenarios, like the following examples. 665 o Different N-MADP instances to handle different sets of clients for 666 load balancing across clients 667 o Address deployment topologies e.g. N-MADP hosted at the user 668 plane node at the access edge or in the core network, while the 669 NCM hosted at the access edge node) 670 o Address access network technology architecture. For exanple, 671 N-MADP instance at core network node to manage traffic 672 distribution across LTE and DSL networks, and N-MADP instance at 673 access network node to manage traffic distribution across LTE and 674 Wi-Fi traffic. 675 o A single client can be configured to use multiple N-MADP 676 instances. This is beneficial in addressing different application 677 requirements. For example, separate N-MADP instances to handle 678 TCP and UDP transport based traffic. 680 Thus, MAMS architecture flexibly addresses multiple network 681 deployments. 683 7. MAMS Protocol Architecture 685 This section describes the protocol structure for the MAMS User and 686 Control plane functional elements. 688 7.1. MAMS Control-Plane Protocol 690 Figure 2 shows the default MAMS control plane protocol stack. 691 WebSocket is used for transporting management and control messages 692 between NCM and CCM. 694 +------------------------------------------+ 696 | Multi Access (MX) Control Message | 698 | | 700 +------------------------------------------+ 702 | WebSocket | 704 | | 706 +------------------------------------------+ 708 | TCP/TLS | 710 | | 712 +------------------------------------------+ 714 Figure 2: TCP-based MAMS Control Plane Protocol Stack 716 7.2. MAMS User Plane Protocol 718 Figure 3 shows the MAMS user plane protocol stack. 720 +-----------------------------------------------------+ 722 | User Payload (e.g. IP PDU) | 724 +-----------------------------------------------------+ 726 +-----------------------------------------------------------+ 728 | +-----------------------------------------------------+ | 730 | | Multi Access (MX) Convergence Sublayer | | 732 | +-----------------------------------------------------+ | 734 | +-----------------------------------------------------+ | 736 | | MX Adaptation | MX Adaptation | MX Adaptation | | 738 | | Sublayer | Sublayer | Sublayer | | 740 | | (optional) | (optional) | (optional) | | 742 | +----------------++--------------+-+------------------+ | 744 | | Access #1 IP | Access #2 IP | Access #3 IP | | 746 | +-----------------------------------------------------+ | 748 | MAMS User Plane Protocol Stack| 750 +-----------------------------------------------------------+ 752 Figure 3: MAMS User Plane Protocol Stack 754 It consists of the following two Sublayers: 756 o Multi-Access (MX) Convergence Sublayer: The MAMS framework 757 configures the Convergence sublayer to perform multi-access 758 specific tasks in the user plane. This layer performs functions 759 like access (path) selection, multi-link (path) aggregation, 760 splitting/reordering, lossless switching, fragmentation, 761 concatenation, etc. MX Convergence layer can be implemented using 762 existing user plane protocols like Multipath TCP (MPTCP [RFC 763 6824]), Multi Path QUIC (MPQUIC [I-D.deconinck-multipath-quic]) or 764 by adapting encapsulating header/trailer schemes like Generic 765 Routing and Encapsulation (GRE [RFC 2784], [RFC 2890]), Generic 766 Multi Access(GMA [I-D.zhu-intarea-gma]). 767 o Multi-Access (MX) Adaptation Sublayer: The MAMS framework 768 configures the Adaptation Sublayer to address transport network 769 related aspects like reachability and security in the user plane. 770 This layer performs functions to handle tunnelling, network layer 771 security, and NAT. MX Adaptation can be implemented using IPsec, 772 DTLS or Client NAT (Source NAT at Client with inverse mapping at 773 N-MADP [I-D.zhu-intarea-mams-user-protocol]). The MX Adaptation 774 Layer is optional and can be independently configured for each of 775 the Access Links. E.g. In a deployment with LTE (assumed secure) 776 and Wi-Fi (assumed not secure), the MX Adaptation Sublayer can be 777 omitted for the LTE link but MX Adaptation Sublayer is configured 778 as IPsec for securing the Wi-Fi link. Further details on the MAMS 779 user plane are described in [I-D.zhu-intarea-mams-user-protocol]. 781 8. MAMS Control Plane Procedures 783 8.1. Overview 785 CCM and NCM exchange signaling messages to configure the user plane 786 functions, C-MADP and N-MADP, at the client and network respectively. 787 The means for CCM to obtain the NCM credentials (FQDN or IP Address) 788 for sending the initial discovery messages are out of the scope of 789 MAMS document. As an example, the client can obtain the NCM 790 credentials using methods like provisioning, DNS query. Once the 791 discovery process is successful, the (initial) NCM can update and 792 assign additional NCM addresses, e.g. based on MCC/MNC tuple 793 information received in the MX Discovery Message, for sending 794 subsequent control plane messages. 796 CCM discovers and exchanges capabilities with the NCM. NCM provides 797 the credentials of the N-MADP end-point and negotiates the parameters 798 for user plane with the CCM. CCM configures C-MADP to setup the user 799 plane path (e.g. MPTCP/UDP Proxy Connection) with the N-MADP based 800 on the credentials (e.g. (MPTCP/UDP) Proxy IP address and port, 801 Associated Core Network Path), and the parameters exchanged with the 802 NCM. Further, NCM and CCM exchange link status information to adapt 803 traffic steering and user plane treatment with dynamic network 804 conditions. The key procedures are described in details in the 805 following sub-sections. 807 +-----+ +-----+ 809 | CCM | | NCM | 811 +--+--+ +--+--+ 813 | Discovery and | 815 | Capability | 817 | Exchange | 819 <----------------------> 821 | | 823 | User Plane | 825 | Protocols | 827 | Setup | 829 <----------------------> 831 | Path Quality | 833 | Estimation | 835 <----------------------> 837 | Network capabilities | 839 | e.g. RNIS[ETSIRNIS] | 841 <----------------------+ 843 | | 845 | Network policies | 847 <----------------------+ 849 + + 851 Figure 4: MAMS Control Plane Procedures 853 8.2. Common fields in MAMS Control Messages 855 Each MAMS control message consists of the following common fields: 857 o Version: indicates the version of MAMS control protocol. 858 o Message Type: indicates the type of the message, e.g. MX 859 Discovery, MX Capability REQ/RSP etc. 860 o Sequence Number: auto-incremented integer to uniquely identify a 861 transaction of message exchange, e.g. MX Capability REQ/RSP. 863 8.3. Common Procedures for MAMS Control Messages 865 This section describes the common procedures for MAMS Control 866 Messages. 868 8.3.1. Message Timeout 870 MAMS Control plane peer (NCM or CCM) waits for a duration of 871 MAMS_TIMEOUT ms, after sending a MAMS control message, before timing 872 out when expecting a response. The sender of the message will 873 retransmit the message for MAMS_RETRY times before declaring failure. 874 A failure implies that the MAMS peer is dead, and the sender reverts 875 back to native non-multi access/single path mode. CCM may initiate 876 the MAMS discovery procedure for re-establishment of the MAMS 877 session. 879 8.3.2. Keep Alive Procedure 881 MAMS Control plane peers execute the keep alive procedures to ensure 882 that peers are reachable and to recover from dead-peer scenarios. 883 Each MAMS control plane end-point maintains a MAMS_KEEP_ALIVE timer 884 that is set for duration MAMS_KEEP_ALIVE_TIMEOUT. MAMS_KEEP_ALIVE 885 timer is reset whenever the peer receives a MAMS Control message. 886 When MAMS_KEEP_ALIVE timer expires, MAMS KEEP ALIVE REQ message is 887 sent. On reception of a MAMS KEEP ALIVE REQ message, the receiver 888 responds with a MAMS KEEP ALIVE RSP message. If the sender does not 889 receive a MAMS Control message in response to MAMS_RETRY number of 890 retries of MAMS KEEP ALIVE REQ message, the MAMS peer declares that 891 the peer is dead. CCM may initiate MAMS Discovery procedure for re- 892 establishment of the MAMS session. 894 CCM shall additionally send MX KEEP ALIVE REQ message immediately to 895 NCM whenever it detects a handover from one base station/access point 896 to another. During this time the user equipment shall stop using 897 MAMS user plane functionality in uplink direction till it receives a 898 MX KEEP ALIVE RSP from NCM. 900 MX KEEP ALIVE REQ includes following information: 902 o Reason: Can be 'Timeout' or 'Handover'. Reason 'Handover' shall 903 be used by CCM only on detection of handover. 904 o Unique Session Identifier: As defined in Section 8.4. 905 o Connection Id: This field shall be mandatorily be included if the 906 reason is 'Handover'. 907 o Delivery Node Identity (ECGI in case of LTE and WiFi AP Id or MAC 908 address in case of WiFi). This field shall be mandatorily be 909 included if the reason is 'Handover'. 911 8.4. Discovery & Capability Exchange 913 Figure 5 shows the MAMS discovery and capability exchange procedure 914 consisting of the following key steps: 916 CCM NCM 918 | | 920 +------- MX Discovery Message ---------------------->| 922 | +-----------------+ 924 | |Learn CCM | 925 | | IP address | 927 | |& port | 929 | +-----------------+ 931 | | 933 |<--------------------------------MX System INFO-----| 935 | | 937 |---------------------------------MX Capability REQ->| 939 |<----- MX Capability RSP----------------------------| 941 |---------------------------------MX Capability ACK->| 942 | | 944 + + 946 Figure 5: MAMS Control Procedure for Discovery & Capability Exchange 948 Step 1 (Discovery): CCM periodically sends out the MX Discovery 949 Message to a pre-defined (NCM) IP Address/port until MX System INFO 950 message is received in acknowledgement. 952 MX Discovery Message includes the following information: 954 o MAMS Version 955 o MCC/MNC Tuple: Optional Parameter to Identify the Operator Network 956 to which the client is susbcribed, in conformance with format 957 specified in [E212] 959 MX System INFO includes the following information: 961 o Number of Anchor Connections 963 For each Anchor Connection, it includes the following parameters: 965 * Connection ID: Unique identifier for the Anchor Connection 966 * Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: 967 LTE) 968 * NCM Endpoint Address (For Control Plane Messages over this 969 connection) 971 + IP Address or FQDN (Fully Qualified Domain Name) 972 + Port Number 974 Step 2 (Capability Exchange): On receiving MX System Info message CCM 975 learns the IP Address and port to start the step 2 of the control 976 plane connection, and sends out the MX Capability REQ message, 977 including the following Parameters: 979 o MX Feature Activation List: Indicates if the corresponding feature 980 is supported or not, e.g. lossless switching, fragmentation, 981 concatenation, Uplink aggregation, Downlink aggregation, 982 Measurement, probing, etc. 983 o Number of Anchor Connections (Core Networks) 985 For each Anchor Connection, it includes the following parameters: 987 * Connection ID 988 * Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: 989 LTE) 990 o Number of Delivery Connections (Access Links) 992 For each Delivery Connection, it includes the following 993 parameters: 995 * Connection ID 996 * Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: 997 LTE) 998 o MX Convergence Method Support List 1000 * GMA 1001 * MPTCP Proxy 1002 * GRE Aggregation Proxy 1003 * MPQUIC 1004 o MX Adaptation Method Support List 1006 * UDP Tunnel without DTLS 1007 * UDP Tunnel with DTLS 1008 * IPsec Tunnel [RFC3948] 1009 * Client NAT 1011 In response, NCM creates a unique identity for the CCM session, and 1012 sends out the MX Capability RSP message, including the following 1013 information: 1015 o MX Feature Activation List: Indicates if the corresponding feature 1016 is enabled or not, e.g. lossless switching, fragmentation, 1017 concatenation, Uplink aggregation, Downlink aggregation, 1018 Measurement, probing, etc. 1019 o Number of Anchor Connections (Core Networks) 1021 For each Anchor Connection, it includes the following parameters: 1023 * Connection ID 1024 * Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: 1025 LTE) 1026 o Number of Delivery Connections (Access Links) 1028 For each Delivery Connection, it includes the following 1029 parameters: 1031 * Connection ID 1032 * Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: Multi-Fire; 3: 1033 LTE) 1034 o MX Convergence Method Support List 1036 * GMA 1037 * MPTCP Proxy 1038 * GRE Aggregation Proxy 1039 * MPQUIC 1040 o MX Adaptation Method Support List 1042 * UDP Tunnel without DTLS 1043 * UDP Tunnel with DTLS 1044 * IPsec Tunnel [RFC3948] 1045 * Client NAT 1047 Unique Session Identifier: Unique session identifier for the CCM 1048 which has setup the connection. In case the session for the UE 1049 already exists then the existing unique session identifier is sent 1050 back. 1052 o NCM Id: Unique Identity of the NCM in the operator network. 1053 o Session Id: Unique identity assigned to the CCM instance by this 1054 NCM instance. 1056 In response to MX Capability RSP message, the CCM sends confirmation 1057 (or reject) in the MX Capability ACK message. MX Capability ACK 1058 includes the following parameters 1060 o Unique Session Identifier: Same identifier as provided in MX 1061 Capability RSP. 1062 o Acknowledgement: An indication if the client has accepted or 1063 rejected the capability phase. 1065 * MX ACCEPT: CCM Accepts the Capability set proposed by the NCM. 1066 * MX REJECT: CCM Rejects the Capability set proposed by the NCM. 1068 If MX_REJECT is received by the NCM, the current MAMS session will be 1069 terminated. 1071 If CCM can no longer continue with the current capabilities, it 1072 should send an MX SESSION TERMINATE message to terminate the MAMS 1073 session. In response, the NCM should send a MX SESSION TERMINATE ACK 1074 to confirm the termination. 1076 8.5. User Plane Configuration 1078 Figure 6 shows the user plane configuration procedure consisting of 1079 the following key steps: 1081 CCM NCM 1083 | | 1085 |------MX Reconfiguration REQ (setup)--------------->| 1087 |<------------------------+MX Reconfiguration RSP+---| 1089 | +-----------+----------------+ 1091 | | NCM prepares N+MADP for | 1093 | | User Plane|Setup | 1095 | +----------------------------+ 1097 |<----------------------------- MX UP Setup Config---| 1099 |-----| MX UP Setup CNF+---------------------------->| 1101 +-------------------+ | 1103 |Link "X" is up/down| | 1105 +-------------------+ | 1107 |-----MX Reconfiguration REQ (update/release)------->| 1109 |<------------------------+MX Reconfiguration RSP+---| 1111 Figure 6: MAMS Control Procedure for User Plane Configuration 1113 Reconfiguration: when the client detects that the link is up/down or 1114 the IP address changes (e.g. via APIs provided by the client OS), CCM 1115 sends out a MX Reconfiguration REQ Message to setup / release / 1116 update the connection, and the message SHOULD include the following 1117 information 1119 o Unique Session Identifier: Identity of the CCM identity at NCM, 1120 created by NCM during the capability exchange phase. 1122 o Reconfiguration Action: indicate the reconfiguration action 1123 (0:release; 1: setup; 2: update). 1124 o Connection ID: identify the connection for reconfiguration 1126 If (Reconfiguration Action is setup or update), then include the 1127 following parameters 1129 o IP address of the connection 1130 o SSID (if Connection Type = WiFi) 1131 o MTU of the connection: MTU of the delivery path that is calculated 1132 at the UE for use by NCM to configure fragmentation and 1133 concatenation procedures[I-D.zhu-intarea-mams-user-protocol] at 1134 N-MADP. 1135 o Delivery Node Identity: Identity of the node to which the client 1136 is attached. ECGI in case of LTE and WiFi AP Id or MAC address in 1137 case of WiFi. 1139 At the beginning of a connection setup, CCM informs the NCM of the 1140 connection status using the MX Reconfiguration REQ message with 1141 Reconfiguration Action type set to "setup". NCM acknowledges the 1142 connection setup status and exchanges parameters with the CCM for 1143 user plane setup, described as follows. 1145 User Plane Protocols Setup: Based on the negotiated capabilities, NCM 1146 sets up the user plane (Adaptation Layer and Convergence Layer) 1147 protocols at the N-MADP, and informs the CCM of the user plane 1148 protocols to setup at the client (C-MADP) and the parameters for 1149 C-MADP to connect to N-MADP. 1151 The MX UP Setup Config is used to create (multiple) MADP instances 1152 with each Anchor Connection having one or more Configurations, namely 1153 MX Configurations. It consists of the following parameters: 1155 o Number of Anchor Connections (Core Networks) 1157 For Each Anchor Connection, it includes the following parameters 1159 * Anchor Connection ID 1160 * Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: 1161 LTE) 1162 * Number of Active MX Configurations (Included only if more than 1163 one MX configurations are active for the anchor connection) 1165 For each active MX configuration, it includes the following 1166 parameters 1168 + MX Configuration ID (included if more than one MX 1169 Configuration is present 1171 + MX Convergence Method, one of the following 1173 - GMA 1174 - MPTCP Proxy 1175 - GRE Aggregation Proxy 1176 - MPQUIC 1177 + MX Convergence Method Parameters 1179 - Convergence Proxy IP Address 1180 - Convergence Proxy Port 1181 - Client Key 1182 + MX Convergence Control Parameters (included if any MX 1183 Control PDU, e.g. Probe-REQ/ACK, is supported): 1185 - UDP Port Number for sending and receiving MX Control 1186 PDUs, e.g. Probe-REQ/ACK, Keep-Alive, etc.) 1187 - Convergence Proxy Port 1188 + Number of Delivery Connections 1190 For each Delivery Connection, include the following: 1192 - Delivery Connection ID 1193 - Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 1194 3: LTE) 1195 - MX Adaptation Method, one of the following 1197 o UDP Tunnel without DTLS 1198 o UDP Tunnel with DTLS 1199 o IPSec Tunnel 1200 o Client NAT 1201 - MX Adaptation Method Parameters 1203 o Tunnel Endpoint IP Address 1204 o Tunnel Endpoint Port 1205 o Shared Secret 1206 o Header Optimization (included only if MX Convergence 1207 Method is GMA) 1209 e.g. When LTE and Wi-Fi are the two user plane accesses, NCM conveys 1210 to CCM that IPsec needs to be setup as the MX Adaptation Layer over 1211 the Wi-Fi Access, using the following parameters - IPsec end-point IP 1212 address, Pre-Shared Key. No Adaptation Layer is needed or Client NAT 1213 may be used over the LTE Access as it is considered secure with no 1214 NAT. 1216 Similarly, as an example of the MX Convergence Method configuration 1217 is to indicate the convergence protocol as MPTCP Proxy along with 1218 parameters for connection to the MPTCP Proxy, namely IP Address and 1219 Port of the MPTCP Proxy for TCP Applications. 1221 Once the user plane protocols are configured, CCM informs the NCM of 1222 the status via the MX UP Setup CNF message. The MX UP Setup CNF 1223 consists of the following parameters: 1225 o Unique Session Identifier: Session identifier provided to the 1226 client in MX Capability RSP. 1227 o MX Convergence Control Parameters (included if any MX Control PDU, 1228 e.g. Probe-REQ/ACK, Keep-alive, is supported): 1230 * UDP Port Number for sending and receiving MX Control PDUs, e.g. 1231 Probe-REQ/ACK, Keep-Alive, etc.) 1232 * MX Configuration ID (if MX Configuration ID is specified in MX 1233 UP Setup Config, indicate the MX Configuration that will be 1234 used for Probing) 1235 o Client Adaptation Layer Parameters: 1237 * Number of Delivery Connections 1238 * For each Delivery Connection, include the following: 1240 + Delivery Connection ID 1241 + UDP port number: If UDP based adaptation is in use, the UDP 1242 port at C-MADP side 1244 8.6. MAMS Path Quality Estimation 1246 Path quality estimations can be done either passively or actively. 1247 Traffic measurements in the network could be performed passively by 1248 comparing the real-time data throughput of the device with the 1249 capacity available in the network. In special deployments where the 1250 NCM has interfaces with access nodes, direct interfaces can be used 1251 to gather path quality information. For example, the utilization of 1252 a cell/eNB attached to a device could be used as an indicator for 1253 path quality estimations without creating an extra traffic overhead. 1254 Active measurements by the device are an alternative for estimating 1255 path quality. 1257 CCM NCM 1258 | | 1259 |<--------------+ MX Path Estimation Configuration+--| 1260 |-----+ MX Path Estimation Results+----------------->| 1261 | | 1263 Figure 7: MAMS Control Plane Procedure for Path Quality Estimation 1265 NCM sends following the configuration parameters in the MX Path 1266 Estimation Configuration message to the CCM 1268 o Connection ID (of Delivery Connection whose path quality needs to 1269 be estimated) 1270 o Init Probe Test Duration (ms) 1271 o Init Probe Test Rate (Mbps) 1272 o Init Probe Size (Bytes) 1273 o Init Probe Ack Required (0 -> No/1 -> Yes) 1274 o Active Probe Frequency (ms) 1275 o Active Probe Size (Bytes) 1276 o Active Probe Test Duration (ms) 1277 o Active Probe Ack Required (0 -> No/1 -> Yes) 1279 CCM configures the C-MADP for probe reception based on these 1280 parameters and for collection of the statistics according to the 1281 following configuration. 1283 o Unique Session Identifier: Session identifier provided to the 1284 client in MX Capability RSP. 1285 o Init Probe Results Configuration 1287 * Lost Probes (%) 1288 * Probe Receiving Rate (packets per second) 1289 o Active Probe Results Configuration 1291 * Average Throughput in the last Probe Duration 1293 The user plane probing is divided into two phases - Initialization 1294 phase and Active phase. 1296 o Initialization phase: A network path that is not included by 1297 N-MADP for transmission of user data is deemed to be in the 1298 Initialization phase. The user data may be transmitted over other 1299 available network paths. 1301 o Active phase: A network path that is included by N-MADP for 1302 transmission of user data is deemed to be in Active phase. 1304 In Initialization phase, NCM configures N-MADP to send an MX Idle 1305 Probe REQ message. CCM collects the Idle probe statistics from 1306 C-MADP and sends the MX Path Estimation Results Message to NCM per 1307 the Initialization Probe Results configuration. 1309 In Active phase, NCM configures N-MADP to send an MX Active Probe REQ 1310 message.. C-MADP calculates the metrics as specified by the Active 1311 Probe Results Configuration. CCM collects the Active probe 1312 statistics from C-MADP and sends the MX Path Estimation Results 1313 Message to NCM per the Active Probe Results configuration. 1315 The following sub-sections define the control PDU encoding for Probe 1316 and Keep Alive messages to support path quality estimation. 1318 8.6.1. MX Control PDU definition 1320 Control PDUs are sent as UDP Messages between C-MADP and N-MADP to 1321 exchange control messages for keep-alive or path quality estimation. 1322 MX Probe Parameters are negotiated during the User Plane Setup phase 1323 (MX UP SETUP CFG and MX UP SETUP CNF). Figure 7 shows the MX control 1324 PDU format with the following fields: 1326 o Type (1 Byte): the type of the MX control message 1328 * 0: Keep-Alive 1329 * 1: Probe REQ/ACK 1330 * Others: Reserved 1331 o CID (1 Byte): the connection ID of the delivery connection for 1332 sending out the MX control message 1333 o MX Control Message (variable): the payload of the MX control 1334 message 1335 o Figure 8 shows the MX Control PDU format. MX Control PDU is sent 1336 as a normal user plane packet over the desired delivery connection 1337 whose quality and reachability needs to be determined. 1339 | | 1340 | <-----+MX Control PDU Payload +--------> | 1341 | | 1342 +-----------+------------------+-----+-----------------------------+ 1343 | IP header | UDP Header| Type | CID | MX Control Message | 1344 +-----------+------------------+-----+-----------------------------+ 1346 Figure 8: MX Control PDU Format 1348 8.6.2. Keep-Alive Message 1350 The "Type" field is set to "0" for Keep-Alive messages. C-MADP may 1351 send out Keep-Alive message periodically over one or multiple 1352 delivery connections, especially if UDP tunneling is used as the 1353 adaptation method for the delivery connection with a NAT function on 1354 the path. 1356 A Keep-Alive message is 2 Bytes long, and consists of the following 1357 fields: 1359 o Keep-Alive Sequence Number (2 Bytes): the sequence number of the 1360 keep-alive message. 1362 8.6.3. Probe REQ/ACK Message 1364 The "Type" field is set to "1" for Probe REQ/ACK messages. N-MADP 1365 may send out the Probe REQ message for path quality estimation. In 1366 response, C-MADP may send back the Probe ACK message. 1368 A Probe REQ message consists of the following fields: 1370 o Probing Sequence Number (2 Bytes): the sequence number of the 1371 Probe REQ message 1372 o Probing Flag (1 Byte): 1374 * Bit #0: a Probe ACK flag to indicate if the Probe ACK message 1375 is expected (1) or not (0); 1376 * Bit #1: a Probe Type flag to indicate if the Probe REQ/ACK 1377 message is sent during the initialization phase (0) when the 1378 network path is not included for transmission of user data or 1379 the active phase (1) when the network path is included for 1380 transmission of user data; 1381 * Bit #2: a bit flag to indicate the presence of the Reverse 1382 Connection ID (R-CID) field. 1383 * Bit #3~7: reserved 1385 o Reverse Connection ID (1 Byte): the connection ID of the delivery 1386 connection for sending out the Probe ACK message on the reverse 1387 path 1388 o Padding (variable) 1390 The "R-CID" field is only present if both Bit #0 and Bit #2 of the 1391 "Probing Flag" field are set to "1". Moreover, Bit #2 of the 1392 "Probing Flag" field SHOULD be set to "0" if the Bit #0 is "0", 1393 indicating the Probe ACK message is not expected. 1395 If the "R-CID" field is not present but the Bit #0 of the "Probing 1396 Flag" field is set to "1", the Probe ACK message SHOULD be sent over 1397 the same delivery connection as the Probe REQ message. 1399 The "Padding" field is used to control the length of Probe REQ 1400 message. 1402 C-MADP SHOULD send out the Probe ACK message in response to a Probe 1403 REQ message with the Probe ACK flag set to "1". 1405 A Probe ACK message is 3 Bytes long, and consists of the following 1406 fields: 1408 o Probing Acknowledgement Number (2 Bytes): the sequence number of 1409 the corresponding Probe REQ message 1411 8.7. MAMS Traffic Steering 1413 CCM NCM 1414 | | 1415 | +------------------------------+ 1416 | |Steer user traffic to Path "X"| 1417 | +------------------------------+ 1418 |<------------------MX Traffic Steering (TS) REQ--| 1419 |----- MX Traffic Steering (TS) RSP ------------->| 1421 Figure 9: MAMS Traffic Steering Procedure 1423 NCM sends out a MX Traffic Steering (TS) REQ message to steer data 1424 traffic. It is also possible to send data traffic over multiple 1425 connections simultaneously, i.e. aggregation. The message includes 1426 the following information: 1428 o Connection ID of the Anchor Connection 1429 o MX Configuration ID (if MX Configuration ID is specified in MX UP 1430 Setup Config) 1432 o Connection ID List of Delivery Connections for DL traffic 1433 o Connection ID of Default UL Delivery Connection 1434 o For the number of Specific UL traffic Templates, include the 1435 following 1437 * Traffic Template for identifying the UL traffic 1438 * Connection ID List of Delivery connections for UL traffic 1439 identified by the traffic template 1440 o MX Feature Activation List: each parameter indicates if the 1441 corresponding feature is enabled or not: lossless switching, 1442 fragmentation, concatenation, Uplink aggregation, Downlink 1443 aggregation, Measurement, probing 1445 In response, CCM sends out a MX Traffic Steering (TS) RSP message, 1446 including the following information: 1448 o Unique Session Identifier: Session identifier provided to the 1449 client in MX Capability RSP. 1450 o MX Feature Activation List: each parameter indicates if the 1451 corresponding feature is enabled or not: lossless switching, 1452 fragmentation, concatenation, Uplink aggregation, Downlink 1453 aggregation, probing 1455 8.8. MAMS Application MADP Association 1457 CCM NCM 1458 | | 1459 | +-------------------------+ 1460 | | Associate MADP instance | 1461 | | with application flow | 1462 | +-------------------------+ 1463 |-------------------MX App MADP ----------->| 1464 | Association(AMA) REQ | 1465 | | 1466 |-------------------MX App MADP ----------->| 1467 | Association(AMA) RSP | 1469 Figure 10: MAMS Application MADP Association Procedure 1471 CCM sends out a MX App MADP Association(AMA) REQ message to request 1472 association of a specific Application flow with a specific MADP 1473 instance ID for the anchor connection with multiple active MX 1474 configurations. MADP Instance ID is a tuple (Anchor Connection ID, 1475 MX Configuration ID). This provides the capability for the client to 1476 indicate the user plane processing that needs to be associated with 1477 different application flows depending on their needs. The 1478 application flow is identified by its associated traffic flow 1479 template. 1481 The message includes the following information: 1483 o Number of Application Flows 1485 For Each Application Flow, identified by the Traffic Flow 1486 Template(s), 1488 * Anchor Connection ID 1489 * MX Configuration ID (if more than one MX Configurations are 1490 associated with an Anchor Connection) 1491 * Traffic Template for identifying the UL traffic 1492 * Traffic Template for identifying the DL traffic 1494 In response, NCM sends out a MX App MADP Association (AMA) RSP 1495 message, including the following information: 1497 o Number of Application Flows 1499 For Each Application Flow, identified by the Traffic Flow 1500 Template(s), 1502 * Status (Success or Failure) 1504 8.9. MAMS Network ID Indication 1506 CCM NCM 1507 | | 1508 | +---------------------------------+ 1509 | |NCM determines preferred Networks| 1510 | +---------------------------------+ 1511 |<------------------MX SSID Indication------------| 1513 Figure 11: MAMS Network ID Indication Procedure 1515 NCM indicates the preferred network list to the CCM to guide client 1516 on networks that it should connect to. To indicate preferred Wi-Fi 1517 Networks, the NCM sends the list of WLAN networks, represented by 1518 SSID/BSSID/HESSID, available in the MX SSID Indication. 1520 8.10. MAMS Client Measurement Configuration and Reporting 1522 CCM NCM 1523 | | 1524 |<------------------MX MEAS CONFIG----------------| 1525 | | 1526 +---------------------------------+ | 1527 |Client Ready to send measurements| | 1528 +---------------------------------+ | 1529 | | 1530 |----- MX MEAS REPORT---------------------------->| 1532 Figure 12: MAMS Client Measurement Configuration and Reporting 1533 Procedure 1535 NCM configures the CCM with the different parameters (e.g. radio link 1536 information), with the associated thresholds to be reported by the 1537 client. The MX MEAS CONFIG message contains the following 1538 parameters. For each Delivery Connection, include the following: 1540 o Delivery Connection ID 1541 o Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: LTE) 1542 o If Connection Type is Wi-Fi 1544 * WLAN_RSSI_THRESH: High and Low Thresholds for sending Average 1545 RSSI of the Wi-Fi Link. 1546 * WLAN_RSSI_PERIOD: Periodicity in ms for sending Average RSSI of 1547 the Wi-Fi Link. 1548 * WLAN_LOAD_THRESH: High and Low Thresholds for sending Loading 1549 of the WLAN system. 1550 * WLAN_LOAD_PERIOD: Periodicity in ms for sending Loading of the 1551 WLAN system. 1552 * UL_TPUT_THRESH: High and Low Thresholds for sending Reverse 1553 Link Throughput on the Wi-Fi link. 1554 * UL_TPUT_PERIOD: Periodicity in ms for sending Reverse Link 1555 Throughput on the Wi-Fi link. 1556 * DL_TPUT_THRESH: High and Low Thresholds for sending Forward 1557 Link Throughput on the Wi-Fi link. 1558 * DL_TPUT_PERIOD: Periodicity in ms for sending Forward Link 1559 Throughput on the Wi-Fi link. 1560 * EST_UL_TPUT_THRESH: High and Low Thresholds for sending Reverse 1561 Link Throughput (EstimatedThroughputOutbound as defined in 1562 [IEEE]) on the Wi-Fi link. 1564 * EST_UL_TPUT_PERIOD: Periodicity in ms for sending Reverse Link 1565 Throughput (EstimatedThroughputOutbound as defined in [IEEE]) 1566 on the Wi-Fi link. 1567 * EST_DL_TPUT_THRESH: High and Low Thresholds for sending Forward 1568 Link Throughput (EstimatedThroughputInbound as defined in 1569 [IEEE]) on the Wi-Fi link. 1570 * EST_DL_TPUT_PERIOD: Periodicity in ms for sending Forward Link 1571 Throughput (EstimatedThroughputInbound as defined in [IEEE]) on 1572 the Wi-Fi link. 1573 o If Connection Type is LTE 1575 * LTE_RSRP_THRESH: High and Low Thresholds for sending RSRP of 1576 Serving LTE link. 1577 * LTE_RSRP_PERIOD: Periodicity in ms for sending RSRP of Serving 1578 LTE link. 1579 * LTE_RSRQ_THRESH: High and Low Thresholds for sending RSRQ of 1580 the serving LTE link. 1581 * LTE_RSRQ_PERIOD: Periodicity in ms for sending RSRP of Serving 1582 LTE link. 1583 * UL_TPUT_THRESH: High and Low Thresholds for sending Reverse 1584 Link Throughput on the serving LTE link. 1585 * UL_TPUT_PERIOD: Periodicity in ms for sending Reverse Link 1586 Throughput on the serving LTE link. 1587 * DL_TPUT_THRESH: High and Low Thresholds for sending Forward 1588 Link Throughput on the serving LTE link. 1589 * DL_TPUT_PERIOD: Periodicity in ms for sending Forward Link 1590 Throughput on the serving LTE link. 1591 o If Connection Type is 5G NR 1593 * NR_RSRP_THRESH: High and Low Thresholds for sending RSRP of 1594 Serving NR link. 1595 * NR_RSRP_PERIOD: Periodicity in ms for sending RSRP of Serving 1596 NR link. 1597 * NR_RSRQ_THRESH: High and Low Thresholds for sending RSRQ of the 1598 serving NR link. 1599 * NR_RSRQ_PERIOD: Periodicity in ms for sending RSRP of Serving 1600 NR link. 1601 * UL_TPUT_THRESH: High and Low Thresholds for sending Reverse 1602 Link Throughput on the serving NR link. 1603 * UL_TPUT_PERIOD: Periodicity in ms for sending Reverse Link 1604 Throughput on the serving NR link. 1605 * DL_TPUT_THRESH: High and Low Thresholds for sending Forward 1606 Link Throughput on the serving NR link. 1607 * DL_TPUT_PERIOD: Periodicity in ms for sending Forward Link 1608 Throughput on the serving NR link. 1610 The MX MEAS REPORT message contains the following parameters 1611 o Unique Session Identifier: Session identifier provided to the 1612 client in MX Capability RSP. 1613 o For each Delivery Connection, include the following: 1615 * Delivery Connection ID 1616 * Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: 1617 LTE) 1618 * Delivery Node Identity (ECGI in case of LTE and WiFi AP Id or 1619 MAC address in case of WiFi) 1620 * If Connection Type is Wi-Fi 1622 + WLAN_RSSI: Average RSSI of the Wi-Fi Link. 1623 + WLAN_LOAD: Loading of the WLAN system. 1624 + UL_TPUT: Reverse Link Throughput on the Wi-Fi link. 1625 + DL_TPUT: Forward Link Throughput on the Wi-Fi link. 1626 + EST_UL_TPUT: Estimated Reverse Link Throughput on the Wi-Fi 1627 link (EstimatedThroughputOutbound as defined in [IEEE]). 1628 + EST_DL_TPUT: Estimated Forward Link Throughput on the Wi-Fi 1629 link (EstimatedThroughputInbound as defined in [IEEE]). 1630 * If Connection Type is LTE 1632 + LTE_RSRP: RSRP of Serving LTE link. 1633 + LTE_RSRQ: RSRQ of the serving LTE link. 1634 + UL_TPUT: Reverse Link Throughput on the serving LTE link. 1635 + DL_TPUT: Forward Link Throughput on the serving LTE link. 1636 * If Connection Type is 5G NR 1638 + NR_RSRP: RSRP of Serving NR link. 1639 + NR_RSRQ: RSRQ of the serving NR link. 1640 + UL_TPUT: Reverse Link Throughput on the serving NR link. 1641 + DL_TPUT: Forward Link Throughput on the serving NR link. 1643 8.11. MAMS Session Termination Procedure 1645 CCM NCM 1646 | | 1647 |+----MX Session Terminate--------->| 1648 | | 1649 | | 1650 |<---MX Session Terminate Ack-------| 1651 | +---------------+ 1652 | Remove Resources 1653 | +---------------+ 1654 | | 1656 Figure 13: MAMS Session Termination Procedure - Client Initiated 1657 CCM NCM 1658 | | 1659 |<----------MX Session Terminate--------| 1660 | | 1661 | | 1662 | | 1663 +--------MX Session Terminate Ack-------> 1664 | | 1665 | | 1666 +-----------+-----------+ | 1667 | Remove Resources | | 1668 +-----------+-----------+ | 1669 | | 1671 Figure 14: MAMS Session Termination Procedure - Network Initiated 1673 At any point in MAMS functioning if CCM or NCM is unable to support 1674 the MAMS functions anymore, then either of them can initiate a 1675 termination procedure by sending MX Session Terminate to the peer, 1676 the peer shall acknowledge the termination by sending MX Session 1677 Terminate ACK message. After the session is disconnected the CCM 1678 shall start a new procedure with MX Discover Message. MX Session 1679 Terminate message shall contain Unique Session Identifier and reason 1680 for termination in Request. Possible reasons for termination can be: 1682 o Normal Release 1683 o No Response from Peer 1684 o Internal Error 1686 8.12. MAMS Network Analytics Request Procedure 1688 CCM NCM 1689 | | 1690 |+----MX Network Analytics Request----------->| 1691 | | 1692 | | 1693 |<---MX Network Analytics Info----------------| 1694 | | 1696 Figure 15: MAMS Network Analytics Request Procedure 1698 CCM sends the MX Network Analytics Request informs the NCM to send 1699 information related to network parameters like bandwidth, latency, 1700 jitter, signal quality based on application of analytics at the 1701 network utilizing the received path measurements and client 1702 measurement reporting. 1704 The MX Network Analytics Request message consists of the following 1705 parameters. 1707 o Link Quality Indicators, one or more of the following: 1709 * Bandwidth 1710 * Jitter 1711 * Latency 1712 * Signal Quality 1714 NCM sends the MX Network Analytics Info to convey the analytics info, 1715 predictive parameters with likelihoods, for the different parameters 1716 of interest for the CCM. 1718 The MX Network Analytics Info messages consists of the following 1719 parameters. 1721 o Number of Delivery Connections For Each Delivery Connection, 1723 * Access Link Identifier 1725 + Connection Type 1726 + Connection ID 1727 * Link Quality Indicator 1729 + Bandwidth 1731 - Predicted Value (in Mbps) 1732 - - Likelihoood (in Percentage) 1733 - Prediction Validity (Validity Time in s) 1734 + Jitter 1736 - Predicted Value (in s) 1737 - - Likelihoood (in Percentage) 1738 - Prediction Validity (Validity Time in s) 1739 + Latency 1741 - Predicted Value (in s) 1742 - - Likelihoood (in Percentage) 1743 - Prediction Validity (Validity Time in s) 1744 + Signal Quality 1746 - if Delivery Connection Type is LTE, LTE_RSRP Predicted 1747 Value (in dBm) 1749 - if Delivery Connection Type is LTE, LTE_RSRQ Predicted 1750 Value (in dBm) 1751 - if Delivery Connection Type is NR, NR_RSRP Predicted 1752 Value (in dBm) 1753 - if Delivery Connection Type is NR, NR_RSRQ Predicted 1754 Value (in dBm) 1755 - if Delivery Connection Type is WiFi, WLAN_RSSI Predicted 1756 Value (in dBm) 1757 - - Likelihoood (in Percentage) 1758 - Prediction Validity (Validity Time in s) 1760 9. Generic MAMS Signaling Flow 1762 +----------------------------------------+ 1763 | MAMS enabled Network of Networks | 1764 | +-----+ +-----+ +-----+ +------+ 1765 +-----------------+ | | | | | | | | || 1766 | Client | | |Netwo| |Netwo| | | | || 1767 | +-----+ +-----+ | | |rk 1 | |rk 2 + |NCM | N-MADP|| 1768 | C-MADP |CCM | | | |(LTE)| |(WiFi) | | | || 1769 | +-----+ +-----+ | | +-----+ +-----+ +-----+ +------| 1770 -+----------------+ +----------------------------------------+| | | | | | | 1771 | | | | | | | 1772 | | 1.SETUP CONNECTION| | | | 1773 |<-----------+------------>| | | | 1774 | | | + + | | 1775 | | | 2. MAMS Capabilities Exchange | | 1776 | | |<-------------+----------+-------->| | 1777 | | | | | | | 1778 | | + | | | | 1779 | | 3. SETUP CONNECTION | | | 1780 |<--+-------------------------------->| | | 1781 | 4c. Config| 4a. NEGOTIATE NETWORK PATHS, FLOW |4b. Config| 1782 | C-MADP | PROTOCOL AND PARAMETERS | |N-MADP | 1783 | |<----->|<-------------+----------+-------->|<-------->| 1784 | | | + + | | 1785 | | |5. ESTABLISH USER PLANE PATH ACCORDING TO | 1786 | | | SELECTED FLOW PROTOCOL | | | 1787 | |<---------------------+----------+------------------->| 1788 | | | | | | | 1789 + + + + + + + 1791 Figure 16: MAMS call flow 1793 Figure 16 illustrates the MAMS signaling mechanism for negotiation of 1794 network paths and flow protocols between the client and the network. 1795 In this example scenario, the client is connected to two networks 1796 (say LTE and WiFi). 1798 1. UE connects to network 1 and gets an IP address assigned by 1799 network 1. 1800 2. CCM communicates with NCM functional element via the network 1 1801 connection and exchanges capabilities and parameters for MAMS 1802 operation. Note: The NCM credentials (e.g. NCM IP Address) can 1803 be made known to the UE by pre-provisioning. 1804 3. Client sets up connection with network 2 and gets an IP address 1805 assigned by network 2. 1806 4. CCM and NCM negotiate capabilities and parameters for 1807 establishment of network paths, which are then used to configure 1808 user plane functions N-MADP at the network and C-MADP at the 1809 client. 1811 4a. CCM and NCM negotiate network paths, flow routing and 1812 aggregation protocols, and related parameters. 1814 4b. NCM communicates with the N-MADP to exchange and configure 1815 flow aggregation protocols, policies and parameters in alignment 1816 with those negotiated with the CCM. 1818 4c. CCM communicates with the C-MADP to exchange and configure 1819 flow aggregation protocols, policies and parameters in alignment 1820 with those negotiated with the NCM. 1822 5. C-MADP and N-MADP establish the user plane paths, e.g. using IKE 1823 [RFC7296] signaling, based on the negotiated flow aggregation 1824 protocols and parameters specified by NCM. 1826 CCM and NCM can further exchange messages containing access link 1827 measurements for link maintenance by the NCM. NCM evaluates the link 1828 conditions in the UL and DL across LTE and WiFi, based on link 1829 measurements reported by CCM and/or link probing techniques and 1830 determines the UL and DL user data distribution policy. NCM and CCM 1831 also negotiate application level policies for categorizing 1832 applications, e.g. based on DSCP, Destination IP address, and 1833 determining which of the available network paths, needs to be used 1834 for transporting data of that category of applications. NCM 1835 configures N-MADP, and CCM configures C-MADP, based on the negotiated 1836 application policies. CCM may apply local application policies, in 1837 addition to the application policy conveyed by the NCM. 1839 10. Relation to IETF Technologies 1841 MAMS leverages technologies developed in IETF like MPTCP, GRE and 1842 enables a control plane framework to negotiate the use of these 1843 protocols between the client and the network. It also addresses the 1844 limitations in the scope of other multihoming protocols. E.g. 1845 MOBIKE RFC 4555 (IKEv2 Mobility and Multihoming Protocol (MOBIKE)) 1846 scope indicates that it is limited to multihoming between IPsec 1847 clients(tunnel mode IPsec SAs) ONLY and does NOT support load 1848 balancing. MAMS addresses this limitation in handling multihoming 1849 scenario by supporting load balancing with simultaneous use of 1850 multiple access paths by negotiating use of protocols like MPTCP. 1851 Unlike MOBIKE, which only applies to end points connected with IPsec 1852 tunnel mode SA, MAMS allows flexibility to use a wide range of 1853 tunneling protocols to be used in the Adaptation layer. 1855 11. Applying MAMS Control Procedures with MPTCP Proxy as User Plane 1857 If NCM determines that N-MADP is to be instantiated with MPTCP as the 1858 MX Convergence Protocol, it exchanges the MPTCP capability support in 1859 discovery and capability exchange procedures. NCM then exchanges the 1860 credentials of the N-MADP instance, setup as MPTCP Proxy, along with 1861 related parameters to the CCM. CCM configures C-MADP with these 1862 parameters to connect with the N-MADP, MPTCP proxy (e.g. 1863 [I-D.ietf-tcpm-converters]) instance, on the available network path 1864 (Access). 1866 Figure 17 illustrates the user plane protocol layering when MPTCP is 1867 configured to be the "MX Convergence Sublayer" protocol. MPTCP 1868 manages traffic distribution and aggregation over multiple delivery 1869 connections. 1871 +-----------------------------------------------------+ 1872 | MPTCP | 1873 +----------------+---------------+--------------------+ 1874 | TCP | TCP | TCP | 1875 +-----------------------------------------------------+ 1876 | MX Adaptation | MX Adaptation | MX Adaptation | 1877 | Sublayer | Sublayer | Sublayer | 1878 | (optional) | (optional) | (optional) | 1879 +-----------------------------------------------------+ 1880 | Access #1 IP | Access #2 IP | Access #3 IP | 1881 +----------------+---------------+--------------------+ 1883 Figure 17: MAMS U-plane Protocol Stack with MPTCP as MX Convergence 1884 Layer 1886 The Client (C-MADP) sets up an MPTCP connection with the N-MADP to 1887 begin with. MAMS control procedures are then applied to, 1889 o Connect to the appropriate MPTCP network endpoint, e.g. MPTCP 1890 Proxy (illustrated in Figure 18) 1891 o Control addition of second TCP subflow after WiFi connection is 1892 established and is deemed good, (illustrated in illustrated in 1893 Figure 19), 1894 o Control the MPTCP scheduler behavior like use of only LTE Subflow 1895 in UL and both LTE and WiFi subflows in DL (illustrated in 1896 illustrated in Figure 20), 1897 o Faster response to WiFi link degradation by proactive deletion of 1898 TCP subflow over WiFi when poor link conditions are reported, to 1899 maintain performance (illustrated in illustrated in Figure 21) 1901 Figure 18 shows the call flow describing MAMS control procedures 1902 applied to configure user plane and dynamic optimal path selection in 1903 a scenario with MPTCP Proxy as the convergence protocol in the user 1904 plane. 1906 +------+ +---------+ +---------+ +---------+ +---------+ +------+ 1907 | | | | | | | | | | | | 1908 |CCM | | C-MADP | |Wi-Fi N/W| | LTE N/W | | NCM | |N-MADP| 1909 +------+ +---------+ +---------+ +---------+ +---------+ +------+ 1910 +------------------------------------------------------------------------+ 1911 | 1. LTE Session Setup and IP Add. Allocation | 1912 -------------------------------------------+-------------+-------------+-+ 1913 |2. MAMS Discovery Message (MAMS Version, MCC/MNC) | | | 1914 +-----------------------------------------+-------------> | 1915 | 3. MX SYSTEM INFO (Serving NCM IP/Port Address) | | 1916 <-------------+-------------+-------------+-------------+ | 1917 | | | | | | 1918 |4. MX CAPABILITY REQ(Supported Anchor/Delivery Links ( Wi-Fi, LTE ) | 1919 +-----------------------------------------------------+-> | 1920 |5. MX CAPABILITY RSP(Convergence/Adaptation Parameters)| | 1921 <-----------------------------------------+-------------+ | 1922 | 6. MX CAPABILITY ACK(ACCEPT) | | | 1923 +-------------+-------------+---------------------------> | 1924 | | | | | | 1925 |7. MX MEAS CONFIG (WLAN/LTE Measurement Thresholds/Period) | 1926 <-------------------------------------------------------+ | 1927 |8. MX MEAS REPORT ( LTE RSRP, UL/DL TPUT ) | | 1928 +-----------------------------------------+-------------> | 1929 |9. MAMS SSID IND(List of SSIDs) | | | 1930 <-------------+-------------+---------------------------+ | 1931 | | | | | | 1932 |10. MX RECONFIGURATION REQ (LTE IP) | | | 1933 +-------------------------------------------------------> | 1934 |11. MX RECONFONFIGURATION RSP | | | 1935 <-----------------------------------------+-------------+ | 1936 |12. MX UP SETUP REQ (MPTCP Proxy IP/Port, Aggregation) | | 1937 <---------------------------+-------------+-------------+ | 1938 |13. MX UP SETUP RSP | | | | 1939 +-------------+-------------+-------------+-------------> + 1940 | | 14. MPTCP Connection with designated MPTCP Proxy over LTE 1941 | +-------------+-------------+-------------+-------------> 1942 | | | | | | 1943 + + + + + + 1945 Figure 18: MAMS-assisted MPTCP Proxy as User Plane - Initial Setup 1946 with LTE leg 1948 Following are the salient steps described in the call flow. The 1949 client connects to the LTE network and obtains an IP address (assume 1950 LTE is the first connection), and initiates the NCM discovery 1951 procedures and exchange capabilities, including the support for MPTCP 1952 as the convergence protocol at both the network and the client. 1954 The CCM informs the LTE connection parameters to the NCM. NCM 1955 provides the parameters like MPTCP Proxy IP address/Port, MPTCP 1956 Client Key for configuring the convergence layer. This is useful if 1957 N-MADP is reachable via different IP address or/and port, from 1958 different access networks. The current MPTCP signaling can't 1959 identify or differentiate the MPTCP proxy IP address and port among 1960 multiple access networks. The client uses the MPTCP Client Key 1961 during the subflow creation, and this enables the N-MADP to uniquely 1962 identify the client, even if NAT is present. The N-MADP then can 1963 inform the NCM of the subflow creation and pararmeters related to 1964 creating additional subflows. Since LTE is the only connection, the 1965 user plane traffic, flows over the single TCP subflow over the LTE 1966 connection. Optionally, NCM provides assistance information to the 1967 device on the neighboring/preferred Wi-Fi networks that it can 1968 associate with. 1970 +------+ +---------+ +---------+ +---------+ +---------+ +------+ 1971 | | | | | | | | | | | | 1972 |CCM | | C-MADP | |Wi-Fi N/W| | LTE N/W | | NCM | |N-MADP| 1973 +------+ +---------+ +---------+ +---------+ +---------+ +------+ 1974 +------------------------------------------------------------------------+ 1975 | Traffic over LTE in UL and DL over MPTCP Connection | 1976 +------------------------------------------------------------------------+ 1977 +------------------------------------------------------------------------+ 1978 | Wi-Fi Connection Establishment and IP Address Allocation | 1979 +---------------------------------------------------------------------+--+ 1980 |15. MX RECONFIGURATION REQ (Wi-Fi IP) | | | 1981 +-------------------------------------------------------> | 1982 |16. MX RECONFONFIGURATION RSP | | | 1983 <-----------------------------------------+-------------+ | 1984 |17. MX UP SETUP REQ (MPTCP Proxy IP/Port, Aggregation) | | 1985 <---------------------------+-------------+-------------+ | 1986 |18. MX UP SETUP RSP | | | | 1987 +-------------+-------------+-------------+-------------> | 1988 | | 19. IPsec Tunnel Establishment over WLAN path | 1989 | <-----------------------------------------|-------------> 1990 | 20. MX MEAS REPORT (WLAN RSSI, LTE RSRP. UL/DL TPUT) |+-------------+ 1991 +-------------+-------------+-------------+------------->+Wait for | 1992 | | | | |+good reports | 1993 | | | | |+-------------+ 1994 | 21. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) | +------------+ 1995 <-----------------------------------------+-------------+ |Allow Use of| 1996 | 22. MX TRAFFIC STEERING RSP (...) | | |Wi-Fi link | 1997 +-------------+-------------+---------------------------> +-----------++ 1998 | | | | | | 1999 | 23. Add TCP subflow to the MPTCP connection over WiFi link (IPsec Tunnel) 2000 | |<----------------------------------------------------->| 2001 +-----------------------------------------------------------------------+ 2002 || Aggregated Wi-Fi and LTE capacity for UL and DL || 2003 +-----------------------------------------------------------------------+ 2004 | | 2005 | | 2007 Figure 19: MAMS-assisted MPTCP Proxy as User Plane - Add Wi-Fi leg 2009 Figure 19 describes the steps, when the client establishes a Wi-Fi 2010 connection. CCM informs the NCM of the Wi-Fi connection along with 2011 parameters like the Wi-Fi IP address, SSID. NCM determines that the 2012 Wi-Fi connection needs to be secured and configures the Adaptation 2013 Layer to be IPsec and provides the required parameters to the CCM. 2014 In addition, NCM provides the information to configure the 2015 convergence layer, (e.g. MPTCP Proxy IP Address), and provides the 2016 Traffic Steering Request to indicate that client should use only the 2017 LTE access. NCM may do this, for example, on determination from the 2018 measurements that the Wi-Fi link is not consistently good enough. As 2019 the Wi-Fi link conditions improve, NCM sends a Traffic Steering 2020 Request to use Wi-Fi access as well. This triggers the client to 2021 establish the TCP subflow over the Wi-Fi link with the MPTCP proxy 2023 +------+ +---------+ +---------+ +---------+ +---------+ +------+ 2024 | | | | | | | | | | | | 2025 |CCM | | C+MADP | |Wi+Fi N/W| | LTE N/W | | NCM | |N+MADP| 2026 +------+ +---------+ +---------+ +---------+ +---------+ +------+ 2027 +------------------------------------------------------------------------+ 2028 | Traffic over LTE and Wi Fi in UL And DL over MPTCP | 2029 +-------------+-------------+-------------+-------------+------------+---+ 2030 | | | | | | 2031 | 24. MX MEAS REPORT (WLAN RSSI, LTE RSRP ,UL/DL TPUT) |+-----------+---+ 2032 +-------------+-------------+-------------+------------>|| Reports of bad| 2033 | | | | |+ Wi-Fi UL tput| 2034 | + + + ++---------------+ 2035 | 25. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) | +-------------+ 2036 |<-----------------------------------------+------------+ |Disallow use| 2037 | 26. MX TRAFFIC STEERING RSP (...) | | |of Wi-Fi UL | 2038 |-------------+-------------+-------------------------->| +----------+--+ 2039 | | | | | | 2040 ++-------------+-------------+-------------+-------------+------------+-+ 2041 | UL data to use TCP subflow over LTE link only, | 2042 | Aggregated Wi-Fi+LTE capacity for DL | 2043 ++-------------+-------------+-------------+-------------+-------------++ 2044 | | | | | | 2045 + + + + + + 2047 Figure 20: MAMS-assisted MPTCP Proxy as User Plane - Wi-Fi UL 2048 degrades 2050 Figure 20 describes the steps, when the client reports that Wi-Fi 2051 link conditions degrade in UL. MAMS control plane is used to 2052 continuously monitor the access link conditions on Wi-Fi and LTE 2053 connections. The NCM may at some point determine increase in UL 2054 traffic on Wi-Fi, and trigger the client to only LTE in the UL via 2055 Traffic Steering Request to improve UL performance. 2057 +------+ +---------+ +---------+ +---------+ +---------+ +------+ 2058 | | | | | | | | | | | | 2059 |CCM | | C+MADP | |Wi+Fi N/W| | LTE N/W | | NCM | |N+MADP| 2060 +------+ +---------+ +---------+ +---------+ +---------+ +------+ 2061 +-----------------------------------------------------------------------+ 2062 | UL data to use TCP subflow over LTE link only, | 2063 | Aggregated Wi+Fi+LTE capacity for DL | 2064 ++-------------+-------------+-------------+-------------+------------+-+ 2065 | | | | | | 2066 | + + + | | 2067 | 27. MX MEAS REPORT (WLAN RSSI, LTE RSRP, UL/DL TPUT) +------------+---+ 2068 +-------------+-------------+-------------+------------>|| Reports of bad+ 2069 | | | | || Wi+Fi UL/DL tput 2070 | + + + +----------------+ 2071 | 28. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) | +-------------+ 2072 +<----------------------------------------+-------------+ |Disallow use| 2073 | 29. MX TRAFFIC STEERING RSP (...) | | |of Wi+Fi | 2074 +-----------------------------------------+------------>+ +-------------+ 2075 | |30. Delete TCP subflow from MPTCP conn. over Wi-Fi link | 2076 | +<---------------------------------------------------->| 2077 +-----------------------------------------------------------------------+ 2078 || Traffic over LTE link only for DL and UL | | | 2079 || (until Client reports better Wi-Fi link conditions) | | | 2080 +-----------------------------------------------------------------------+ 2081 | | | | | | 2082 + + + + + + 2084 Figure 21: MAMS-assisted MPTCP Proxy as User Plane - Part 4 2086 Figure 21 describes the steps, when the client reports that Wi-Fi 2087 link conditions degrade in both UL and DL. As the Wi-Fi link 2088 conditions deteriorate further, the NCM may determine to send Traffic 2089 Steering Request guiding the client to stop using Wi-Fi, and to use 2090 only LTE access in both UL and DL. This condition may be maintained 2091 until NCM determines, based on reported measurements that Wi-Fi link 2092 has become usable. 2094 12. Applying MAMS Control Procedures for Network Assisted Traffic 2095 Steering when there is No Convergence Layer 2097 Figure 22 shows the call flow describing MAMS control procedures 2098 applied for dynamic optimal path selection in a scenario convergence 2099 and Adaptation layer protocols are not omitted. This scenario 2100 indicates the applicability of a MAMS Control Plane only solution. 2102 In the capability exchange messages, NCM and CCM negotiate that 2103 Convergence and Adaptation layer protocols are not needed (or 2104 supported). CCM informs the NCM of the availability of the LTE and 2105 Wi-Fi links. NCM determines the access links, Wi-Fi or LTE to be 2106 used dynamically based on the reported link quality measurements. 2108 +------+ +---------+ +---------+ +---------+ +---------+ +------+ 2109 | | | | | | | | | | | | 2110 |CCM | | C+MADP | |Wi+Fi N/W| | LTE N/W | | NCM | |N+MADP| 2111 +------+ +---------+ +---------+ +---------+ +---------+ +------+ 2112 +------------------------------------------------------------------------+ 2113 | 1. LTE Session Setup and IP Add. Allocation | 2114 +------------------------------------------+-------------+-------------+-+ 2115 |2. MAMS Discovery Message (MAMS Version, MCC/MNC Tuple) | | | 2116 +-----------------------------------------+------------>| | 2117 | 3. MX SYSTEM INFO (Serving NCM IP/Port Address) | | 2118 <-------------+-------------+-------------+-------------+ | 2119 | + + + + | 2120 |4. MX CAPABILITY REQ(Supported Anchor/Delivery Links ( Wi-Fi, LTE ) | 2121 +------------------------------------------------------>| | 2122 |5. MX CAPABILITY RSP(No Convergence/Adpatation parameters) | 2123 |<-----------------------------------------+------------+ | 2124 | 6. MX CAPABILITY ACK(ACCEPT) | | | 2125 +-------------+-------------+-------------------------->| | 2126 | + + + + | 2127 |7. MX MEAS CONFIG (WLAN/LTE Measurement Thresholds/Period) | 2128 |<------------------------------------------------------| | 2129 |8. MX MEAS REPORT ( LTE RSRP, UL/DL TPUT ) | | 2130 |-----------------------------------------+------------>| | 2131 |9. MAMS SSID IND(List of SSIDs) | | | 2132 |<------------------------------------------------------| | 2133 +-----------------------------------------------------------------------++ 2134 | 10. Wi|Fi connection setup and IP Address allocation | 2135 +-+-------------+-------------+-------------+-------------+-------------++ 2136 | + + | | | 2137 |10. MX RECONFIGURATION REQ (LTE IP, Wi-Fi IP) | | 2138 +-----------------------------------------+------------>| | 2139 |11. MX RECONFONFIGURATION RSP | | | 2140 <------------------------------------------------------+| | 2141 +-----------------------------------------------------------------------++ 2142 | Initial Condition, Data over LTE link only, WLAN link is poor | 2143 +---------------------------------------------------------+-------------++ 2144 |12. MX MEAS REPORT (WLAN RSSI, LTE RSRP, UL/DL TPUT) |+-------------+ 2145 |------------------------------------------------------>||Wi-Fi Link | 2146 | | | | ||conditions | 2147 | | | | ||reported good| 2148 | | | | |+-------------+ 2149 | | | | | | 2150 |13. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) |+--------------+ 2151 |<-------------+-------------+-------------+------------||Steer traffic | 2152 |14. MX TRAFFIC STEERING RSP (...) | ||to use Wi-Fi | 2153 |<-------------+-------------+-------------+------------||link | 2154 | | | | |+--------------+ 2155 +-----------------------------------------------------------------------++ 2156 | Use Wi-Fi link for Data | 2157 +---------------------------------------------------------+-------------++ 2158 | | | | | | 2159 + + + + + + 2161 Figure 22: MAMS With No Convergence Layer 2163 13. Co-existence of MX Adaptation and MX Convergence Layers 2165 MAMS user plane supports multiple instances and combinations of 2166 protocols to be used at the MX Adaptation and the Convergence layer. 2168 For example, one instance of the MX Convergence Layer can be MPTCP 2169 Proxy and another instance can be GMA. The MX Adaptation for each 2170 can be either UDP tunnel or IPsec. IPSec may be set up when network 2171 path needs to be secured, e.g. to protect the TCP subflow traversing 2172 the network path between the client and MPTCP proxy. 2174 Each of the instances of MAMS user plane, i.e. combination of MX 2175 Convergence and MX Adaptation layer protocols, can coexist 2176 simultaneously and independently handle different traffic types. 2178 14. Security Considerations 2180 14.1. MAMS Control Plane Security 2182 The NCM functional element is hosted on a network node which is 2183 assumed to be within a secure network, e.g. within the operator's 2184 network, and is assumed to be protected against hijack attacks. 2186 For deployment scenarios, where the client is configured (e.g. by the 2187 network operator) to use a specific network path for exchanging 2188 control plane messages and if the network path is assumed to be 2189 secure, MAMS control messages will rely on security provided by the 2190 underlying network. 2192 For deployment scenarios where the security of the network path 2193 cannot be assumed, NCM and CCM implementations MUST support the "wss" 2194 URI scheme [RFC6455] and Transport Layer Security (TLS) [RFC5246] to 2195 secure control plane message exchange between the NCM and CCM. 2197 For deployment scenarios where client authentication is desired, the 2198 WebSocket server can use any client authentication mechanisms 2199 available to a generic HTTP server, such as cookies, HTTP 2200 authentication, or TLS authentication. 2202 14.2. MAMS User Plane Security 2204 User data in MAMS framework relies on the security of the underlying 2205 network transport paths. When this cannot be assumed, NCM configures 2206 use of protocols, like IPsec [RFC4301] [RFC3948] in the MX Adaptation 2207 Layer, for security. 2209 15. Implementation Considerations 2211 MAMS builds on commonly available functions available on terminal 2212 devices that can be delivered as a software update over the popular 2213 end-user device operating systems, enabling rapid deployment and 2214 addressing the large deployed device base. 2216 16. Applicability to Multi Access Edge Computing 2218 Multi-access Edge Computing (MEC), previously known as Mobile Edge 2219 Computing, is an access-edge cloud platform being considered at ETSI 2220 [ETSIMEC] , whose initial focus was to improve quality of experience 2221 by leveraging intelligence at the cellular (e.g., 3GPP technologies 2222 like LTE) access edge, and the scope is now being extended to support 2223 access technologies beyond 3GPP. The applicability of the framework 2224 described in this document to the MEC platform has been evaluated and 2225 tested in different network configurations by the authors. 2227 The NCM can be hosted on a MEC cloud server that is located in the 2228 user plane path at the edge of the multi-technology access network. 2229 The NCM and CCM can negotiate the network path combinations based on 2230 application needs and the necessary user plane protocols to be used 2231 across the multiple paths. The network conditions reported by the 2232 CCM to the NCM can be complemented by a Radio Analytics application 2233 [ETSIRNIS] residing at the MEC to configure the uplink and downlink 2234 access paths according to changing radio and congestion conditions. 2236 The user plane functional element, N-MADP, can either be collocated 2237 with the NCM at the MEC cloud server (e.g., MEC hosted applications), 2238 or placed at a separate network element like a common user plane 2239 gateway across the multiple networks. 2241 Also, even in scenarios where N-MADP is not deployed, the NCM can be 2242 used to augment the traffic steering decisions at the device. 2244 The aim of these enhancements is to improve the end-user's quality of 2245 experience by leveraging the best network path based on application 2246 needs and network conditions, and building on the advantages of 2247 significantly reduced latency and the dynamic and real-time exposure 2248 of radio network information available at the MEC. 2250 17. Related work in other Industry and Standards Forums 2252 The MAMS framework described in this document has been incorporated 2253 as a solution to address multi access integration in multiple 2254 industry forums and standards. This section describes the related 2255 work in other industry forums and the standards organizations. 2257 Wireless Broadband Alliance Industry partners have published a 2258 whitepaper that describes applicability of different technologies for 2259 multi access integration to different deployments as part of their 2260 project named, Unlicensed Integration with 5G Networks [WBAUnl5G]. 2261 The whitepaper includes MAMS framework described in this document as 2262 a technology for integrating Unlicensed (WiFi) networks with 5G 2263 networks above the 5G core network. 2265 3GPP is developing a technical report as part of its work item Study 2266 on Access Traffic Steering, Switching and Splitting (ATSSS). That 2267 report, TR23.793 [GPPATSSS], contains a number of potential solutions 2268 and Solution 1 utilizes a separate control plane for flexible 2269 negotiation of user plane protocols and path measurements in a way 2270 that is similar the MAMS architecture described in this document. 2272 The Small Cell Forum (SCF) [SCFTECH5G] plans to develop a while paper 2273 as part of its work item on LTE/5G and WiFi. There is a proposal to 2274 include MAMS in this whitepaper. 2276 The ETSI Multi-access Edge Computing Phase 2 technical work is 2277 examining many aspects of this work including use cases for 2278 optimizing Quality of Experience (QoE) and resource utilization. The 2279 MAMS architecture and procedures outlined in this document is 2280 included in the use cases and requirements document[ETSIMAMS]. 2282 18. Contributing Authors 2284 The editors gratefully acknowledge the following additional 2285 contributors in alphabetical order: A Krishna Pramod/Nokia, Hannu 2286 Flinck/Nokia, Hema Pentakota/Nokia, Nurit Sprecher/Nokia, Salil 2287 Agarwal/Nokia; Shuping Peng/Huawei, Vasudevan Subramanian/Nokia. 2288 Vasudevan Subramanian has been instrumental in conceptualization and 2289 development of solution principles for the MAMS framework. Shuping 2290 Peng has been a key contributor in refining the framework and control 2291 plane protocol aspects. 2293 19. Acknowledgments 2295 This protocol is the outcome of work by many engineers, not just the 2296 authors of this document. In alphabetical order, the contributors to 2297 the project are: Barbara Orlandi, Bongho Kim,David Lopez-Perez, Doru 2298 Calin, Jonathan Ling, Lohith Nayak, Michael Scharf. 2300 20. IANA Considerations 2302 This draft makes no requests of IANA 2304 21. References 2306 21.1. Normative References 2308 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2309 Requirement Levels", BCP 14, RFC 2119, 2310 DOI 10.17487/RFC2119, March 1997, 2311 . 2313 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2314 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 2315 December 2005, . 2317 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2318 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2319 May 2017, . 2321 21.2. Informative References 2323 [ANDSF] "TS 24.312 version 15.0, 21 June 2018: 3GPP Specification 2324 on Access Network Discovery and Selection Function (ANDSF) 2325 Management Object (MO)", http://www.3gpp.org/ftp//Specs/ 2326 archive/24_series/24.312/24312-f00.zip", . 2328 [E212] "ITU-T E.212: The international identification plan for 2329 public networks and subscriptions, 2330 https://www.itu.int/rec/T-REC-E.212-201609-I/en", . 2333 [ETSIMAMS] 2334 "Multi-access Edge Computing (MEC); Phase 2: Use Cases and 2335 Requirements, https://www.etsi.org/deliver/etsi_gs/ 2336 MEC/001_099/002/02.01.01_60/gs_MEC002v020101p.pdf", . 2339 [ETSIMEC] "Multi-access Edge Computing (MEC), ETSI", 2340 . 2343 [ETSIRNIS] 2344 "Mobile Edge Computing (MEC) Radio Network Information 2345 API", . 2347 [GPPATSSS] 2348 "3rd Generation Partnership Project; Technical 2349 Specification Group Services and System Aspects; Study on 2350 Access Traffic Steering, Switching and Splitting support 2351 in the 5G system architecture (Release 16), 2352 https://www.3gpp.org, work in progress", . 2354 [I-D.deconinck-multipath-quic] 2355 Coninck, Q. and O. Bonaventure, "Multipath Extension for 2356 QUIC", draft-deconinck-multipath-quic-00 (work in 2357 progress), October 2017. 2359 [I-D.ietf-tcpm-converters] 2360 Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S., 2361 and B. Hesmans, "0-RTT TCP Convert Protocol", draft-ietf- 2362 tcpm-converters-06 (work in progress), March 2019. 2364 [I-D.zhu-intarea-gma] 2365 Zhu, J. and S. Kanugovi, "Generic Multi-Access (GMA) 2366 Convergence Encapsulation Protocols", draft-zhu-intarea- 2367 gma-02 (work in progress), March 2019. 2369 [I-D.zhu-intarea-mams-user-protocol] 2370 Zhu, J., Seo, S., Kanugovi, S., and S. Peng, "User-Plane 2371 Protocols for Multiple Access Management Service", draft- 2372 zhu-intarea-mams-user-protocol-07 (work in progress), 2373 April 2019. 2375 [IEEE] "IEEE Standard for Information technology: 2376 Telecommunications and information exchange between 2377 systems Local and metropolitan area networks:Specific 2378 requirements - Part 11: Wireless LAN Medium Access Control 2379 (MAC) and Physical Layer (PHY) Specifications.", . 2382 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2383 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2384 DOI 10.17487/RFC2784, March 2000, 2385 . 2387 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 2388 RFC 2890, DOI 10.17487/RFC2890, September 2000, 2389 . 2391 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 2392 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 2393 RFC 3948, DOI 10.17487/RFC3948, January 2005, 2394 . 2396 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2397 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2398 January 2012, . 2400 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 2401 "TCP Extensions for Multipath Operation with Multiple 2402 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 2403 . 2405 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2406 Kivinen, "Internet Key Exchange Protocol Version 2 2407 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2408 2014, . 2410 [SCFTECH5G] 2411 "Small Cell Forum, https://scf.io/", . 2413 [WBAUnl5G] 2414 "Wireless Broadband Alliance Project - Unlicensed 2415 Integration with 5G Networks, 2416 https://www.wballiance.com/resource/ 2417 unlicensed-integration-with-5g-networks/.", . 2420 Appendix A. MAMS Control Plane Optimization over Secure Connections 2422 If the connection between CCM and NCM over which the MAMS control 2423 plane messages are transported is assumed to be secure, UDP is used 2424 as the transport for management & control messages between NCM and 2425 UCM (see Figure 23). 2427 +-----------------------------------------------------+ 2428 | Multi-Access (MX) Control Message | 2429 |-----------------------------------------------------| 2430 | UDP | 2431 |-----------------------------------------------------| 2433 Figure 23: UDP-based MAMS Control plane Protocol Stack 2435 Appendix B. MAMS Application Interface 2437 B.1. Overall Design 2439 CCM hosts an HTTPS server for applications to communicate and request 2440 services. It is assumed in this draft that all CCM and the 2441 communicating Application instances are hosted in a single 2442 administrative domain from security point of view. 2444 The content of messages is defined in "Java Script Object Notation" 2445 (JSON) format. They offer RESTful APIs for communication. 2447 The exact mechanism regarding how Application knows about the end 2448 point of CCM is not covered as part of this document. It may be 2449 provided as part of the Application Settings. 2451 B.2. Notation 2453 The documentation of APIs are provided in OpenAPI format using 2454 swagger v2.0 (TBD - Add section in appendix) 2456 B.3. Error Indication 2458 For every API, there could be an error response in case the objective 2459 of API could not be met as defined in [RFC2616]. 2461 B.4. CCM APIs 2463 The following sections describe the APIs exposed by CCM to the 2464 applications 2466 B.4.1. Get Capabilities 2468 The CCM provides a HTTPS GET interface as "/ccm/v1.0/capabilities" 2469 for the Application to query about the capabilities supported by the 2470 CCM instance. 2472 +-----------+ +-------------+ 2473 | | | | 2474 | App +----------+HTTPS GET /capabilities+-------->| CCM | 2475 | | | | 2476 +-----------+ +-------------+ 2478 Figure 24: CCM API - GET Procedures 2480 The CCM shall provide information of its capabilities as follows: 2482 o Supported Features: One of more of as defined in MX Feature 2483 Activation List parameter of MX Capability REQ. 2484 o Supported Connections: Supported connection types and connection 2485 IDs 2486 o Supported MX Adaptation Sublayers: List of MX adaptation sublayer 2487 protocols supported by the N-MADP instance alongwith the 2488 connection type where these are supported and their respective 2489 parameters. 2490 o Supported MX Convergence Sublayers: List of supported MX 2491 Convergence Sublayer protocols alongwith the parameters associated 2492 with respective convergence technique. 2494 B.4.2. Post App Requirements 2496 The CCM provides a HTTPS POST interface as "/ccm/v1.0/ 2497 app_requirements" for the Application to post the needs of the 2498 application data streams to the CCM instance. 2500 +-----------+ +-------------+ 2501 | | | | 2502 | App +----------+HTTPS POST /App Requirements+--->| CCM | 2503 | | | | 2504 +-----------+ +-------------+ 2506 Figure 25: CCM API - POST Procedures 2508 The CCM shall provide for the application to post the following 2509 requirements of its different data streams: 2511 o Number of data stream types For each data stream type, the 2512 following link feature preferences, 2513 o Protocol Type: Transport layer protocol associated with the 2514 application data stream packets. 2515 o Port Range: Supported connection types and connection IDs. 2517 o Traffic QoS: Quality of service parameters as follows 2519 * Bandwidth 2520 * Latency 2521 * Jitter 2523 B.4.3. Get Predictive Link Parameters 2525 The CCM provides a HTTPS GET interface as "/ccm/v1.0/ 2526 predictive_link_params" for the Application to get the predicted link 2527 parameters from the CCM instance. 2529 +-----------+ +-------------+ 2530 | | | | 2531 | App +-------+HTTPS GET /Predictive Link Params--->| CCM | 2532 | | | | 2533 +-----------+ +-------------+ 2535 Figure 26: CCM API - GET Predictive Link Parameters Procedures 2537 CCM requests the NCM for link parameters via the MAMS Network 2538 Analytics Request Procedure (Section 8.12) and includes the 2539 information in response to the API invocation. 2541 o Number of Delivery Connections For Each Delivery Connection, 2543 * Access Link Identifier 2545 + Connection Type 2546 + Connection ID 2547 * Link Quality Indicator 2549 + Bandwidth 2551 - Predicted Value (in Mbps) 2552 - - Likelihoood (in Percentage) 2553 - Prediction Validity (Validity Time in s) 2554 + Jitter 2556 - Predicted Value (in s) 2557 - - Likelihoood (in Percentage) 2558 - Prediction Validity (Validity Time in s) 2559 + Latency 2561 - Predicted Value (in s) 2562 - - Likelihoood (in Percentage) 2563 - Prediction Validity (Validity Time in s) 2564 + Signal Quality 2566 - if Delivery Connection Type is LTE, LTE_RSRP Predicted 2567 Value (in dBm) 2568 - if Delivery Connection Type is LTE, LTE_RSRQ Predicted 2569 Value (in dBm) 2570 - if Delivery Connection Type is NR, NR_RSRP Predicted 2571 Value (in dBm) 2572 - if Delivery Connection Type is NR, NR_RSRQ Predicted 2573 Value (in dBm) 2574 - if Delivery Connection Type is WiFi, WLAN_RSSI Predicted 2575 Value (in dBm) 2576 - - Likelihoood (in Percentage) 2577 - Prediction Validity (Validity Time in s) 2579 Appendix C. JSON Specification for MAMS Control Plane 2581 MAMS Control plane messages are exchanged between the CCM and the 2582 NCM. This section, specifies the format and content of messages in 2583 "Java Script Object Notation" (JSON) format. 2585 C.1. Protocol Specification: General Processing 2587 C.1.1. Notation 2589 This document uses JSONString, JSONNumber, and JSONBool to indicate 2590 the JSON string, number, and boolean types, respectively. The type 2591 JSONValue indicates a JSON value, as specified in Section 3 of 2592 [RFC7159]. 2594 This document uses an adaptation of the C-style struct notation to 2595 define JSON objects. A JSON object consists of name/value pairs. 2596 This document refers to each pair as a field. In some context, this 2597 document also refers to a field as an attribute. The name of a 2598 field/attribute may be referred to as the key. An optional field is 2599 enclosed by [ ]. In the definitions, the JSON names of the fields 2600 are case sensitive. An array is indicated by two numbers in angle 2601 brackets, , where m indicates the minimal number of values and 2602 n is the maximum. When this document uses * for n, it means no upper 2603 bound. 2605 For example, the definition below defines a new type Type4, with 2606 three fields named "name1", "name2", and "name3", respectively. The 2607 field named "name3" is optional, and the field named "name2" is an 2608 array of at least one value. 2610 object { Type1 name1; Type2 name2<1..*>; [Type3 name3;] } Type4; 2612 This document uses subtyping to denote that one type is derived from 2613 another type. The example below denotes that TypeDerived is derived 2614 from TypeBase. TypeDerived includes all fields defined in TypeBase. 2615 If TypeBase does not have a field named "name1", TypeDerived will 2616 have a new field named "name1". If TypeBase already has a field 2617 named "name1" but with a different type, TypeDerived will have a 2618 field named "name1" with the type defined in TypeDerived (i.e., Type1 2619 in the example). 2621 object { Type1 name1; } TypeDerived : TypeBase; 2623 Note that, despite the notation, no standard, machine-readable 2624 interface definition or schema is provided in this document. 2625 Extension documents may describe these as necessary. 2627 C.1.2. Discovery Procedure 2629 C.1.2.1. MX Discovery Message 2631 This message is the first message sent by CCM to discover the 2632 presence of NCM in the network. It contains only the base 2633 information as described in Appendix C.2.1 with message_type set as 2634 mx_discover. 2636 Following is the representation of the message: 2638 object { 2640 [JSONString MCC_MNC_Tuple;] 2642 } MXDiscover : MXBase; 2644 C.1.3. System Information Procedure 2646 C.1.3.1. MX System Information Message 2648 This message is sent by NCM to CCM to inform the endpoints that NCM 2649 supports for MAMS functionality. In addition to base information 2650 (Appendix C.2.1) it contains following information: 2652 a) NCM Connections (described in Appendix C.2.3) 2654 Following is the representation of the message: 2656 object { 2657 NCMConnections ncm_connections; 2659 } MXSystemInfo : MXBase; 2661 C.1.4. Capability Exchange Procedure 2663 C.1.4.1. MX Capability Request 2665 This message is sent by CCM to NCM to indicate the capabilities of 2666 the CCM instance available to the NCM indicated in System Info 2667 message earlier. In addition to base information (Appendix C.2.1) it 2668 contains following information: 2670 (a) Features Activation Status: Described in Appendix C.2.5 2671 (b) Number of anchor connections: Number of anchor connection 2672 (towards core) supported by the NCM. 2673 (c) Anchor Connections: Described in sec Appendix C.2.6 2674 (d) Number of Delivery connections: Number of delivery connection 2675 (towards access) supported by the NCM. 2676 (e) Delivery Connections: Described in Appendix C.2.7 2677 (f) Convergence Methods: Described in Appendix C.2.9 2678 (g) Adaptation Methods: Described in Appendix C.2.10 2680 Following is the representation of the message: 2682 object { 2683 FeaturesActive feature_active; 2684 JSONNumber num_anchor_connections; 2685 AnchorConnections anchor_connections; 2686 JSONNumber num_delivery_connections; 2687 DeliveryConnections delivery_connections; 2688 ConvergenceMethods convergence_methods; 2689 AdaptationMethods adaptation_methods 2690 } MXCapabilityReq : MXBase; 2692 C.1.4.2. MX Capability Response 2694 This message is sent by NCM to CCM to indicate the capabilities of 2695 the NCM instance and unique session identifier for CCM. In addition 2696 to base information (Appendix C.2.1) it contains following 2697 information: 2699 (a) Features Activation Status: Described in Appendix C.2.5 2700 (b) Number of anchor connections: Number of anchor connection 2701 (towards core) supported by the NCM. 2702 (c) Anchor Connections: Described in Appendix C.2.6 2703 (d) Number of Delivery connections: Number of delivery connection 2704 (towards access) supported by the NCM. 2706 (e) Delivery Connections: Described in Appendix C.2.7 2707 (f) Convergence Methods: Described in Appendix C.2.9 2708 (g) Adaptation Methods: Described in Appendix C.2.10 2709 (h) Unique Session Id: This uniquely identifies the session between 2710 CCM and NCM in a network. Described in Appendix C.2.2 2712 Following is the representation of the message: 2714 object { 2715 FeaturesActive feature_active; 2716 JSONNumber num_anchor_connections; 2717 AnchorConnections anchor_connections; 2718 JSONNumber num_delivery_connections; 2719 DeliveryConnections delivery_connections; 2720 ConvergenceMethods convergence_methods; 2721 AdaptationMethods adaptation_methods 2722 UniqueSessionId unique_session_id; 2723 } MXCapabilityRsq : MXBase; 2725 C.1.4.3. MX Capability Acknowledge 2727 This message is sent by CCM to NCM to indicate acceptance of 2728 capabilities advertised by NCM in earlier MX Capability Response 2729 message. In addition to base information (Appendix C.2.1) it 2730 contains following information: 2732 (a) Unique Session Id: Same identifier as provided in MX Capability 2733 RSP. Described in Appendix C.2.2. 2734 (b) Capability Acknowledgement: Either Accept or Reject of the 2735 capabilities sent by CCM. Can take either "MX_ACCEPT" or 2736 "MX_REJECT" as acceptable values. 2738 Following is the representation of the message: 2740 object { 2741 UniqueSessionId unique_session_id; 2742 JSONString capability_ack; 2743 } MXCapabilityAck : MXBase; 2745 C.1.5. User Plane Configuration Procedure 2747 C.1.5.1. MX User Plane Configuration Request 2749 This message is sent by NCM to CCM to configure the user plane for 2750 MAMS. In addition to base information (Appendix C.2.1) it contains 2751 following information: 2753 (a) Number of Anchor Connection: Number of anchor connections 2754 supported by NCM. 2755 (b) Setup of Anchor Connections: Described in Appendix C.2.11. 2757 Following is the representation of the message: 2759 object { 2760 JSONNumber num_anchor_connections; 2761 SetupAnchorConns anchor_connections; 2762 } MXUPSetupConfigReq : MXBase; 2764 C.1.5.2. MX User Plane Configuration Confirmation 2766 This message is the confirmation of user plane setup message sent 2767 from CCM after successfully configuring the user plane at user 2768 equipment. This message contains following information: 2770 (a) Unique Session Id: Same identifier as provided in MX Capability 2771 RSP. Described in Appendix C.2.2. 2772 (b) MX Probe Parameters (included if probing is supported) 2774 (1) Probe Port: UDP port for accepting probe message. 2775 (2) Anchor connection Id: Identifier of the anchor connection 2776 to be used for probe function, provided in user plane setup 2777 request. 2778 (3) MX Configuration Id: For the given anchor connection, which 2779 configuration id is to be used for probe, this is present 2780 only if provided in the user plane setup request. 2781 (c) For each delivery connection following is required: 2783 (1) Connection ID: Delivery connection id supported by UE. 2784 (2) Client Adaptation Layer Parameters: If UDP adaptation layer 2785 is in use then the UDP port to be used at C-MADP side. 2787 Following is the representation of the message: 2789 object { 2790 UniqueSessionId unique_session_id; 2791 [ProbeParam probe_param;] 2792 JSONNumber num_delivery_conn; 2793 ClientParam client_params <1...*>; 2794 } MXUPSetupConfigCnf : MXBase; 2796 Where ProbeParam is defined as following: 2798 object { 2799 JSONNumber probe_port; 2800 JSONNumber anchor_conn_id; 2802 [JSONNumber mx_configuration_id;] 2803 } ProbeParam; 2805 Where ClientParam is defined as following: 2807 object { 2808 JSONNumber connection_id; 2809 [AdaptationParam adapt_param;] 2810 } ClientParam; 2812 Where AdaptationParam is defined as following: 2814 object { 2815 JSONNumber udp_adapt_port; 2816 } AdaptationParam; 2818 C.1.6. Reconfiguration Procedure 2820 C.1.6.1. Reconfiguration Request 2822 This message is sent by CCM to NCM in case of reconfiguration of any 2823 the connections from user equipment's side. In addition to base 2824 information (Appendix C.2.1) it contains following information: 2826 (a) Unique Session Id: Identifier for CCM-NCM association 2827 Appendix C.2.2. 2828 (b) Reconfiguration Action: Type of reconfiguration action can be 2829 one of "setup", "release" or "modify". 2830 (c) Connection Id: Connection Id for which the reconfiguration is 2831 taking place. 2832 (d) IP address: IP address in case of setup and modify type of 2833 reconfiguration. 2834 (e) SSID: If the connection type is WiFi, in that case the SSID the 2835 UE has attached to is contained in this parameter. 2836 (f) MTU of connection: MTU of the delivery path that is calculated 2837 at the UE for use by NCM to configure fragmentation and 2838 concatenation procedures at N-MADP. 2839 (g) Connection Status: This parameter informs if the connection is 2840 currently "disabled", "enabled" or "connected". Default: 2841 "connected". 2842 (h) Delivery Node Id: Identity of the node to which the client is 2843 attached. ECGI in case of LTE and WiFi AP Id or MAC address in 2844 case of WiFi. 2846 Following is the representation of the message: 2848 object { 2849 UniqueSessionId unique_session_id; 2850 JSONString reconf_action; 2851 JSONNumber connection_id; 2852 JSONString ip_address; 2853 JSONString ssid; 2854 JSONNumber mtu_size; 2855 JSONString connection_status; 2856 [JSONSring delivery_node_id;] 2857 } MXReconfReq : MXBase; 2859 C.1.6.2. Reconfiguration Response 2861 This message is sent by NCM to CCM as a confirmation towards 2862 reconfiguration requirement after taking the reconfiguration into use 2863 and contains only the base information (as defined in 2864 Appendix C.2.1). 2866 Following is the representation of the message:] 2868 object { 2869 } MXReconfRsp : MXBase; 2871 C.1.7. Path Estimation Procedure 2873 C.1.7.1. Path Estimation Request 2875 This message is sent by NCM towards CCM to configure the CCM to send 2876 path estimation reports. In addition to base information 2877 (Appendix C.2.1) it contains following information: 2879 (a) Connection Id: Id of the connection for which the path 2880 estimation report is required. 2881 (b) Init Probe Test Duration: Duration of initial probe test in 2882 milliseconds. [TBD: Range of values] 2883 (c) Init Probe Test Rate: Initial testing rate in Mega Bits per 2884 Second. [TBD: Range of values] 2885 (d) Init Probe Size: Size of each packet for initial probe in Bytes. 2886 [TBD: Range of values] 2887 (e) Init Probe Ack: If an acknowledgement for probe is required. 2888 [Possible values: "yes", "no"] 2889 (f) Active Probe Frequency: Frequency in milliseconds at which the 2890 active probes shall be sent. [TBD: Range of values] 2891 (g) Active Probe Size: Size of the active probe in Bytes. [TBD: 2892 Range of values] 2893 (h) Active Probe Duration: Duration in seconds for which the active 2894 probe shall be performed. [TBD. Range of values] 2895 (i) Active Probe Ack. If an acknowledgement for probe is required. 2896 [Possible values: "yes", "no"] 2898 Following is the representation of the message: 2900 object { 2901 JSONNumber connection_id; 2902 JSONNumber init_probe_test_duration_ms; 2903 JSONNumber init_probe_test_rate_Mbps; 2904 JSONNumber init_probe_size_bytes; 2905 JSONString init_probe_ack_req; 2906 JSONNumber active_probe_freq_ms; 2907 JSONNumber active_probe_size_bytes; 2908 JSONNumber active_probe_duration_sec; 2909 JSONString active_probe_ack_req; 2910 } MXPathEstReq : MXBase; 2912 C.1.7.2. Path Estimation Report 2914 This message is sent by CCM to NCM as report to the probe estimation 2915 configured by NCM. In addition to base information (Appendix C.2.1) 2916 it contains following information: 2918 (a) Unique Session Id: Same identifier as provided in MX Capability 2919 RSP. Described in Appendix C.2.2. 2920 (b) Connection Id: Id of the connection for which the path 2921 estimation report is required. 2922 (c) Init Probe Results: Defined in section Appendix C.2.12. 2923 (d) Active Probe Results: Defined in section Appendix C.2.13. 2925 Following is the representation of the message: 2927 object { 2928 JSONNumber connection_id; 2929 UniqueSessionId unique_session_id; 2930 [InitProbeResults init_probe_results;] 2931 [ActiveProbeResults active_probe_results;] 2932 } MXPathEstResults : MXBase; 2934 C.1.8. Traffic Steering Procedure 2936 C.1.8.1. Traffic Steering Request 2938 This message is sent by NCM to CCM for enabling traffic steering at 2939 delivery side in uplink and downlink configuration. In addition to 2940 base information (Appendix C.2.1) it contains following information: 2942 (a) Connection id: Anchor connection number for which the traffic 2943 steering is getting defined. 2944 (b) MX Configuration Id: MX configuration for which the traffic 2945 steering is getting defined. 2947 (c) Downlink Delivery: Defined in Appendix C.2.14. 2948 (d) Default UL Delivery: The default delivery connection for uplink. 2949 All traffic should be delivered on this connection in uplink 2950 direction and the TFT filter should be applied only for the 2951 traffic mentioned in Uplink Delivery. 2952 (e) Uplink Delivery: Defined in Appendix C.2.15. 2953 (f) Features Activated: Defined in Appendix C.2.5. 2955 Following is the representation of the message: 2957 object { 2958 JSONNumber connection_id; 2959 [JSONNumber mx_configuration_id;] 2960 DLDelivery downlink_delivery; 2961 JSONNumber default_uplink_delivery; 2962 ULDelivery uplink_delivery; 2963 FeaturesActive feature_activation; 2964 } MXTraffiSteeringReq : MXBase; 2966 C.1.8.2. Traffic Steering Response 2968 This message is response to Traffic Steering request from CCM to NCM. 2969 In addition to base information (Appendix C.2.1) it contains 2970 following information: 2972 (a) Unique Session Id: Same identifier as provided in MX Capability 2973 RSP. Described in Appendix C.2.2. 2974 (b) Features Activated: Defined in Appendix C.2.5. 2976 Following is the representation of the message: 2978 object { 2979 UniqueSessionId unique_session_id; 2980 FeaturesActive feature_activation; 2981 } MXTraffiSteeringResp : MXBase; 2983 C.1.9. MAMS Application MADP Association 2985 C.1.9.1. MAMS Application MADP Association Request 2987 This message is sent by CCM to NCM to select MADP instances provided 2988 earlier in User Plane Setup Request based on requirement of the 2989 applications. 2991 In addition to the base information (Appendix C.2.1) it contains 2992 following: 2994 (a) Unique Session Id: This uniquely identifies the session between 2995 CCM and NCM in a network. Described in Appendix C.2.2, and a 2996 list of following MX Application MADP Associations 2998 (a) Connection id: Defines the anchor connection number of the 2999 MADP instance 3000 (b) MX Configuration Id: identify the MX configuration of the 3001 MADP instance 3002 (c) Traffic Template Uplink: Traffic template as defined in 3003 5.16 to be used in uplink direction. 3004 (d) Traffic Template Downlink: Traffic template as defined in 3005 5.16 to be used in downlink direction. 3007 Following is the representation of the message: 3009 object { 3010 UniqueSessionId unique_session_id; 3011 MXAppMADPAssoc app_madp_assoc_list <1..*>; 3012 } MXAppMADPAssocReq : MXBase; 3014 Where each measurement MXAppMADPAssoc is represented by following: 3016 object { 3017 JSONNumber connection_id; 3018 JSONNumber mx_configuration_id 3019 TrafficFlowTemplate tft_ul_list <1..*>; 3020 TrafficFlowTemplate tft_dl_list <1..*>; 3021 } MXAppMADPAssoc; 3023 C.1.9.2. MAMS Application MADP Association Response 3025 This message is sent by NCM to CCM to confirm the selected MADP 3026 instances provided in request message by CCM. 3028 In addition to the base information (Appendix C.2.1), it contains 3029 information if the request has been successful. 3031 Following is the representation of the message: 3033 object { 3034 JSONBool is_success; 3035 } MXAppMADPAssocResp : MXBase; 3037 C.1.10. SSID Indication 3039 This message is sent by NCM to CCM to indicate the list of allowed 3040 SSID which are supported by MAMS entity at the network side. It 3041 contains the list of SSIDs. 3043 Each SSID consists of the type of SSID (which can be one of the 3044 "SSID", "BSSID" or "HESSID" and the SSID itself. 3046 Following is the representation of the message: 3048 object { 3049 SSID ssid_list<1..*>; 3050 } MXSSIDIndication : MXBase; 3052 Where each SSID is defined as following: 3054 object { 3055 JSONString ssid_type; 3056 JSONString ssid; 3057 } SSID; 3059 C.1.11. Measurements 3061 C.1.11.1. Measurement Configuration 3063 This message is sent from NCM to CCM to configure the period 3064 measurement reporting at CCM. The message contains a list of 3065 measurement configuration with each element containing following 3066 information: 3068 (a) Connection Id: Connection id of the delivery connection for 3069 which the reporting is being configured. 3070 (b) Connection Type: Connection Type for which the reporting is 3071 being configured, can be "lte", "wifi", "5g-nr" etc. 3072 (c) Measurement Report Configuration: Actual report configuration 3073 based on the connection type, as defined in Appendix C.2.17 3075 Following is the representation of the message: 3077 object { 3078 MeasReportConf measurement_configuration <1..*>; 3079 } MXMeasReportConf : MXBase; 3081 Where each measurement MeasReportConf is represented by following: 3083 object { 3084 JSONNumber connection_id; 3085 JSONString connection_type; 3086 MeasReportConfs meas_rep_conf <1..*>; 3087 } MeasReportConf; 3089 C.1.11.2. Measurement Report 3091 This message is periodically sent by CCM to NCM after measurement 3092 configuration. In addition to the base information it contains 3093 following information: 3095 (a) Unique Session Id: Same identifier as provided in MX Capability 3096 RSP. Described in Appendix C.2.2. 3097 (b) Measurement report for each delivery connection is measured by 3098 the client device as defined in Appendix C.2.18. 3100 Following is the representation of the message: 3102 object { 3103 UniqueSessionId unique_session_id; 3104 MXMeasRep measurment_reports <1..*>; 3105 } MXMeasurementReport : MXBase; 3107 C.1.12. Keep Alive 3109 C.1.12.1. Keep Alive Request 3111 A Keep Alive Request message can be sent from either NCM or CCM on 3112 expiry of MAMS_KEEP_ALIVE timer or a handover event. This request 3113 shall be responded by the peer with Keep Alive Response. In case of 3114 no response from peer the MAMS connection shall be assumed to be 3115 broken and new connection shall be established again by CCM by 3116 sending MX Discover messages. 3118 In addition to the base information it cantains following 3119 information: 3121 (a) Keep Alive Reason: Reason for sending this message, can be 3122 "Timeout" or "Handover". 3123 (b) Unique Session Id: Identifier for CCM-NCM association 3124 Appendix C.2.2. 3125 (c) Connection Id: Connection id for which handover is detected, in 3126 case the reason is "Handover". 3127 (d) Delivery Node Id: The target delivery node id (ECGI or WiFi 3128 Access Point Id/MAC) to which the handover is executed. 3130 Following is the representation of the message: 3132 object { 3133 JSONString keep_alive_reason; 3134 UniqueSessionId unique_session_id; 3135 JSONNumber connection_id; 3136 JSONString delivery_node_id; 3137 } MXKeepAliveReq : MXBase; 3139 C.1.12.2. Keep Alive Response 3141 On receiving Keep Alive Request from peer, NCM/CCM shall immediately 3142 respond with a Keep Alive Response message on the same delivery path 3143 from where the request arrived. In addition to base information it 3144 contains the unique session identifier for the CCM-NCM association 3145 (defined in Appendix C.2.2) 3147 Following is the representation of the message: 3149 object { 3150 UniqueSessionId unique_session_id; 3151 } MXKeepAliveResp : MXBase; 3153 C.1.13. Session Termination Procedure 3155 C.1.13.1. Session Terminate Request 3157 In the event where NCM or CCM can no longer handle MAMS for any 3158 reason then it can send MX session termination request to the peer. 3159 In addition to base information it contains Unique Session Id and 3160 reason for termination, this can be "MX_NORMAL_RELEASE", 3161 "MX_NO_RESPONSE" or "INTERNAL_ERROR". 3163 Following is the representation of the message: 3165 object { 3166 UniqueSessionId unique_session_id; 3167 JSONString reason; 3168 } MXSessionTerminationReq : MXBase; 3170 C.1.13.2. Session Terminate Response 3172 On reception of MX session termination request from peer, NCM/CCM 3173 shall respond with MX Session Termination Response on the same 3174 delivery path where the request arrived and clean the MAMS related 3175 resources and settings. CCM shall re-initiate a new session with MX 3176 Discover messages again. 3178 Following is the representation of the message: 3180 object { 3181 UniqueSessionId unique_session_id; 3182 } MXSessionTerminationResp : MXBase; 3184 C.1.14. Network Analytics 3186 C.1.14.1. MX Network Analytics Request 3188 This message is sent by CCM to NCM to request for parameters like 3189 bandwidth, jitter, latency and signal quality predicted by network 3190 analytics function. In addition to the base information it contains 3191 following parameter: 3193 (a) Unique Session Id: Same identifier as provided in MX Capability 3194 RSP. Described in Appendix C.2.2. 3195 (b) Parameter List: List of parameters which the CCM is interested 3196 in namely one or more of, "bandwidth", "jitter", "latency" and 3197 "signal_quality". 3199 Following is the representation of the message: 3201 object { 3202 UniqueSessionId unique_session_id; 3203 JSONString params<1..*>; 3204 } MXNetAnalyticsReq : MXBase; 3206 Where the params object can take one or more of the following values: 3208 "bandwidth" 3209 "jitter" 3210 "latency" 3211 "signal_quality" 3213 C.1.14.2. MX Network Analytics Response 3215 This message is sent by NCM to CCM in response to the analytics 3216 request. For each delivery connection that the client has NCM 3217 reports the requested parameter predictions and their respective 3218 likelihood (between 1-100). 3220 In addition to the base information it contains following parameters: 3222 (a) Number of delivery connections: The number of delivery 3223 connections configured for the client currently. 3224 (b) For each delivery connection following is provided: 3226 (a) Connection Id: Connection ID of the delivery connection for 3227 which the parameters are being predicted. 3228 (b) Connection Type: Type of connection, can be "Wi-Fi, "5G 3229 NR", "Multi-Fire" and "LTE". 3230 (c) List of Parameters for which Prediction is requested, where 3231 each of the predicted parameters consists of following: 3233 (a) Parameter name: Name of the parameter being predicted. 3234 Can be one of "bandwidth", "jitter", "latency", 3235 "signal_quality". 3236 (b) Additional Parameter: If Parameter name is 3237 "signal_quality", then this qualifies the quality 3238 parameter like "lte_rsrp", "lte_rsrq", "nr_rsrp", 3239 "nr_rsrq", or "wifi_rssi". 3240 (c) Predicted value: Provides the predicted value of the 3241 parameter and, if applicable, the additional 3242 parameter. 3243 (d) Likelihood: Provides a stochastic likelihood of about 3244 the predicted value. 3245 (e) Validity Time: the time horizon until which the 3246 predictions are valid. 3248 Following is the representation of the message: 3250 object { 3251 MXAnalyticsList param_list<1..*>>; 3252 } MXNetAnalyticsResp : MXBase; 3254 Where MXAnalyticsList is defined as following:: 3256 object{ 3257 JSONNumber connection_id; 3258 JSONString connection_type; 3259 ParamPredictions predictions <1..*>; 3260 } MXAnalyticsList; 3262 Where each ParamPredictions is defined as: 3264 object{ 3265 JSONString param_name; 3266 [JSONString additional_param;] 3267 JSONNumber prediction; 3268 JSONNumber likelihood; 3269 JSONNumber validity_time; 3270 } ParamPredictions; 3272 C.2. Protocol Specification: Data Types 3274 C.2.1. MXBase 3276 This is the base information that every message between CCM and NCM 3277 exchanges shall have as mandatory information. It contains following 3278 information: 3280 (a) Version: Version of MAMS in used 3281 (b) Message Type: Message type being sent with following as valid 3282 values: 3284 (a) "mx_discover" 3285 (b) "mx_system_info" 3286 (c) "mx_capability_req" 3287 (d) "mx_capability_resp" 3288 (e) mx_capability_ack" 3289 (f) "mx_up_setup_conf_req" 3290 (g) "mx_up_setup_cnf" 3291 (h) "mx_reconf_req" 3292 (i) "mx_reconf_rsp" 3293 (j) "mx_path_est_req" 3294 (k) "mx_path_est_results" 3295 (l) "mx_traffic_steering_req" 3296 (m) "mx_traffic_steering_rsp" 3297 (n) "mx_ssid_indication" 3298 (o) "mx_keep_alive_req" 3299 (p) "mx_keep_alive_rsp" 3300 (q) "mx_measurement_conf" 3301 (r) "mx_measurement_report" 3302 (s) "mx_session_termination_req" 3303 (t) "mx_session_termination_resp" 3304 (u) "mx_app_madp_assoc_req" 3305 (v) "mx_app_madp_assoc_resp" 3306 (w) "mx_network_analytics_req" 3307 (x) "mx_network_analytics_resp" 3308 (c) Sequence Number: Sequence number to uniquely identify a 3309 transaction of message exchange, e.g. MX Capability REQ/RSP/ 3310 ACK. 3312 Following is the representation of this data type: 3314 object { 3315 JSONString version; 3316 JSONString message_type; 3317 JSONNumber sequence_num; 3318 } MXBase; 3320 C.2.2. Unique Session Id 3322 This data type defines the unique session id between a CCM and NCM 3323 entity, it contains a NCM id which is unique in the network and a 3324 session id allocated by NCM for that session. On reception, of 3325 discovery message if the session is existing then the old session id 3326 is returned in System Info message otherwise NCM allocates a new 3327 session id to the CCM and sends in response with System Info message. 3329 Following is the representation of this data type: 3331 object { 3332 JSONNumber ncm_id; 3333 JSONNumber session_id; 3334 } UniqueSessionId; 3336 C.2.3. NCM Connections 3338 This data type defines the connection available at NCM for MAMS 3339 connectivity towards the User Equipment. It contains a list of NCM 3340 connections available where each connection has following 3341 information: 3343 (a) Connection Information: As defined in Appendix C.2.4 3344 (b) NCM End Point information: This contains IP Address and Port 3345 exposed by NCM end point for CCM. 3347 Following is the representation of this data type: 3349 object { 3350 NCMConnection items<1..*>; 3351 } NCMConnections; 3353 where NCMConnection is defined as: 3355 object { 3356 NCMEndPoint ncm_end_point; 3357 } NCMConnection : ConnectionInfo; 3359 where NCMEndPoint is defined as: 3361 object { 3362 JSONString ip_address; 3363 JSONNumber port; 3364 } NCMEndPoint; 3366 C.2.4. Connection Information 3368 This data type provides the mapping of connection Id and connection 3369 type. It contains following information: 3371 (a) Connection Id: Number indicating the connection can be 0,1,2 and 3372 3. 3373 (b) Connection type: Type of connect can be "Wi-Fi, "5G NR", "Multi- 3374 Fire" and "LTE". 3376 The two are considered a mapping like 0-"Wi-Fi", 1-"5G NR", 2-"Multi- 3377 Fire" and 3-"LTE". 3379 Following is the representation of this data type: 3381 object { 3382 JSONNumber connection_id; 3383 JSONString connection_type; 3384 } ConnectionInfo; 3386 C.2.5. Features Activation Status 3388 This data type provides the list of all features with their 3389 activation status. Each feature status contains following: 3391 (a) Feature Name: Name of the feature can be one of the following: 3393 (a) "lossless_switching" 3394 (b) "fragmentation" 3395 (c) "concatenation" 3396 (d) "uplink_aggregation" 3397 (e) "downlink_aggregation" 3398 (f) "measurement" 3399 (b) Active status: Activation status of the feature, "true" means 3400 feature is active, "false" means feature is inactive. 3402 Following is the representation of this data type: 3404 object { 3405 FeatureInfo items<1..*>; 3406 } FeaturesActive; 3408 where FeatureInfo is defined as: 3410 object { 3411 JSONString feature_name; 3412 JSONBool active; 3413 } FeatureInfo; 3415 C.2.6. Anchor Connections 3417 This data type contains the list of Connection Information 3418 (Appendix C.2.4) that are supported at anchor (core) side. 3420 Following is the representation of this data type: 3422 object { 3423 ConnectionInfo items<1..*>; 3424 } AnchorConnections; 3426 C.2.7. Delivery Connections 3428 This data type contains the list of Connection Information 3429 (Appendix C.2.4) that are supported at delivery (access) side. 3431 Following is the representation of this data type: 3433 object { 3434 ConnectionInfo items<1..*>; 3435 } DeliveryConnections; 3437 C.2.8. Method Support 3439 This data type provides the support for a particular convergence or 3440 adaptation method. It consists of following: 3442 (a) Method: Name of the method. 3443 (b) Supported: Whether the method named above is supported or not. 3444 Possible values are "true" and "false". 3446 Following is the representation of this data type: 3448 object { 3449 JSONString method; 3450 JSONBool supported; 3451 } MethodSupport; 3453 C.2.9. Convergence Methods 3455 This data type contains the list of all convergence methods and their 3456 support status. Convergence Methods possible are: 3458 "GMA" 3459 "MPTCP_Proxy" 3460 "GRE_Aggregation_Proxy" 3461 "MPQUIC" 3463 Following is the representation of this data type: 3465 object { 3466 MethodSupport items<1..*>; 3467 } ConvergenceMethods; 3469 C.2.10. Adaptation Methods 3471 This data type contains the list of all convergence methods and their 3472 support status. Converge Methods possible are: 3474 "UDP_without_DTLS" 3475 "UDP_with_DTLS" 3476 "IPSec" 3477 "Client_NAT" 3479 Following is the representation of this data type: 3481 object { 3482 MethodSupport items<1..*>; 3483 } AdaptationMethods; 3485 C.2.11. Setup of Anchor Connections 3487 This data type defines the setup configuration for each of the anchor 3488 connection that is required at the user equipment side. It contains 3489 following information in addition to the connection id and type of 3490 the anchor connection: 3492 (a) Number of Active MX configurations: If more than one active 3493 configurations are present for this anchor then this identifies 3494 the number of such connections 3495 (b) For each active configuration following convergence parameters 3496 are provided: 3498 (a) MX Configuration Identifier: This identifier is present in 3499 case there are multiple active configuration and identifies 3500 the configuration for this MADP instance id. 3501 (b) Convergence Method: Converge method selected, has to be one 3502 of the supported convergence method as listed in section 3503 Appendix C.2.9. 3504 (c) Convergence Method Parameters: Described in section 3505 Appendix C.2.11.1 3506 (d) Number of Delivery Connections: Number of delivery 3507 connections (access side) that are supported for this 3508 anchor connection. 3509 (e) Setup Delivery Connections: Described in section 3510 Appendix C.2.11.2. 3512 Following is the representation of this data type: 3514 object { 3515 SetupAnchorConn items<1..*>; 3516 } SetupAnchorConns; 3518 Where each Anchor connection configuration is defined as following: 3520 object { 3521 [JSONNumber num_active_mx_conf;] 3522 ConvergenceConfig convergence_config 3523 } SetupAnchorConn : ConnectionInfo; 3525 where each Convergence configuration is defined as following: 3527 object { 3528 [JSONNumber mx_configuration_id;] 3529 JSONString convergence_method; 3530 ConvergenceMethodParam convergence_method_params; 3531 JSONNumber num_delivery_connections; 3532 SetupDeliveryConns delivery_connections; 3533 } ConvergenceConfig; 3535 C.2.11.1. Convergence Method Parameters 3537 This data type defines the parameters used for convergence method and 3538 contains following: 3540 (a) Proxy IP: IP Address of proxy that is provided by Convergence 3541 Method selected. 3542 (b) Proxy Port: Port of the proxy that is provided by Convergence 3543 Method selected. 3545 Following in the representation of this data type: 3547 object { 3548 JSONString proxy_ip; 3549 JSONString proxy_port; 3550 JSONString client_key; 3551 } ConvergenceMethodParam; 3553 C.2.11.2. Setup Delivery Connections 3555 This is the list of delivery connections and their parameters to be 3556 configured at the user equipment. Each delivery connection defined 3557 by its connection information (Appendix C.2.4) contains optionally 3558 following: 3560 (a) Adaptation Method: Selected adaptation method name, this shall 3561 be one of the names as listed in Appendix C.2.10. 3562 (b) Adaptation Method Parameters: Depending on the adaptation method 3563 one or more of the following parameters shall be provided. 3565 (a) Tunnel IP address 3566 (b) Tunnel Port number 3567 (c) Shared Secret 3568 (d) MX header optimization: If the adaptation method is UDP_and 3569 convergence is GMA then this flag represents if the 3570 checksum field and the length field in the IP header of a 3571 MX PDU should be recalculated or not by the MX convergence 3572 sublayer. The possible values are "true" and "false". If 3573 it is "true", both fields remain unchanged; otherwise, both 3574 fields should be recalculated. If this field is not 3575 present then the default of "false" should be considered. 3577 Following in the representation of this data type: 3579 object { 3580 SetupDeliveryConn items<1..*>; 3581 } SetupDeliveryConns; 3583 where each Setup Delivery Connection consists of following: 3585 object { 3586 [JSONSting adaptation_method;] 3587 [AdaptationMethodParam adaptation_method_param;] 3588 } SetupDeliveryConn : ConnectionInfo; 3590 where Adaptation Method Param is defined as: 3592 object { 3593 JSONString tunnel_ip_addr; 3594 JSONString tunnel_end_port; 3595 JSONString shared_secret; 3596 [JSONBool mx_header_optimization;] 3597 } AdaptationMethodParam; 3599 C.2.12. Init Probe Results 3601 This data type defines the results of init probe request made by NCM. 3602 It consists of following information: 3604 (a) Lost Probes: Percentage or probes lost. 3605 (b) Prode Delay: Average delay of probe message in microseconds. 3606 (c) Probe Rate: Probe rate achieved in Mega Bits per second. 3608 Following in the representation of this data type: 3610 object { 3611 JSONNumber lost_probes_percentage; 3612 JSONNumber probe_rate_Mbps; 3613 } InitProbeResults; 3615 C.2.13. Active Probe Results 3617 This data type defines the results of init probe request made by NCM. 3618 It consists of following information: 3620 (a) Average Probe Throughput: Average active probe throughput 3621 achieved in Mega Bits per second. 3623 Following in the representation of this data type: 3625 object { 3626 JSONNumber avg_tput_last_probe_duration_Mbps; 3627 } ActiveProbeResults; 3629 C.2.14. Downlink Delivery 3631 This data type defines the list of connections which are enabled in 3632 delivery side to be used in downlink direction. 3634 Following in the representation of this data type: 3636 object { 3637 JSONNumber connection_id <1..*>; 3638 } DLDelivery; 3640 C.2.15. Uplink Delivery 3642 This data type defines the list of connections and parameters enabled 3643 for deliver side to be used in uplink direction. 3645 The uplink delivery consists of multiple uplink delivery entities, 3646 where each entity consists of a traffic flow template (TFT) 3647 Appendix C.2.16 and list of connection ids in uplink where traffic 3648 qualifying for such traffic flow template can be redirected. 3650 Following in the representation of this data type: 3652 object { 3653 ULDeliveryEntity ul_del <1..*>; 3654 } ULDelivery; 3656 Where each uplink delivery entity consists of following data type: 3658 object { 3659 TrafficFlowTemplate ul_tft <1..*>; 3660 JSONNumber connection_id <1..*>; 3661 } ULDeliveryEntity; 3663 C.2.16. Traffic Flow Template 3665 Traffic flow template follows in general guidelines specified in 3GPP 3666 TS 23.060. 3668 Traffic flow template in MAMS consists of one or more of following: 3670 (a) Remote Address and Mask: IP address and subnet for remote 3671 addresses represented in CIDR notation. Default: "0.0.0.0/0". 3672 (b) Local Address and Mask: IP address and subnet for local 3673 addresses represented in CIDR notation. Default: "0.0.0.0/0" 3674 (c) Protocol Type: IP protocol number of the payload being carried 3675 by IP packet. e.g. UDP, TCP etc. Default: 255. 3676 (d) Local Port Range: Range of ports for local ports for which the 3677 flow template is applicable. Default: Start=0, End=65535. 3678 (e) Remote Port Range: Range of ports for remote ports for which the 3679 flow template is applicable. Default: Start=0, End=65535. 3680 (f) Traffic Class: Represented by Type of Service in IPv4 and 3681 Traffic Class in IPv6. Default: 255 3682 (g) Flow Label: Flow label for IPv6, applicable only for IPv6 3683 protocol type. Default: 0. 3685 Following in the representation of this data type: 3687 object { 3688 JSONString remote_addr_mask; 3689 JSONString local_addr_mask; 3690 JSONNumber protocol_type; 3691 PortRange local_port_range; 3692 PortRange remote_port_range; 3693 JSONNumber traffic_class; 3694 JSONNumber flow_label; 3695 } TrafficFlowTemplate; 3697 Where the port range is defined as following: 3699 object { 3700 JSONNumber start; 3701 JSONNumber end; 3702 } PortRange; 3704 C.2.17. Measurement Report Configuration 3706 This data type defines the configuration done by NCM towards CCM for 3707 reporting measurement events. 3709 (a) Measurement Report Parameter: Parameter which shall be measured 3710 and reported. This is dependent on the connection type: 3712 (a) For connection type "wifi" allowed measurement parameters 3713 are "WLAN_RSSI", "WLAN_LOAD", "UL_TPUT", "DL_TPUT", 3714 "EST_UL_TPUT" and "EST_DL_TPUT". 3715 (b) For connection type "lte" allowed measurement parameters 3716 are "LTE_RSRP", "LTE_RSRQ", "UL_TPUT" and "DL_TPUT". 3717 (c) For connection type "5g-nr" allowed measurement parameters 3718 are "NR_RSRP", "NR_RSRQ", "UL_TPUT" and "DL_TPUT". 3719 (b) Threshold: High and Low threshold for reporting. 3720 (c) Period: Period for reporting in milliseconds. 3722 Following is the representation of this data type: 3724 object { 3725 JSONString meas_rep_param; 3726 Threshold meas_threshold; 3727 JSONNumber meas_period; 3728 } MeasReportConfs; 3730 Where Threshold is defined as following: 3732 object { 3733 JSONNumber high; 3734 JSONNumber low; 3735 } Threshold; 3737 C.2.18. Measurement Report 3739 This data type defines the measurements reported by CCM for each 3740 access network measured. This type contains the connection 3741 information, delivery node id which identifies the cell (ECGI) or the 3742 WiFI Access Point Id or MAC address (or equivalent identifier in 3743 other technologies) and the actual measurement performed by CCM in 3744 the last measurement period. 3746 Following is the representation of this data type: 3748 object { 3749 JSONNumber connection_id; 3750 JSONString connection_type; 3751 JSONString delivery_node_id; 3752 Measurement measurements <1..*>; 3753 }MXMeasRep; 3755 Where Measurement is defined as the key value pair of measurement 3756 type and value. The exact type and value are defined on a per 3757 delivery type and defined in Appendix C.2.17. 3759 object{ 3760 JSONString measurement_type; 3761 JSONNumber measurement_value; 3762 } Measurement; 3764 C.3. Schemas in JSON 3766 C.3.1. MX Base Schema 3767 { 3768 "$schema": "http://json-schema.org/draft-04/schema#", 3769 "definitions": { 3770 "message_type_def": { 3771 "enum": [ 3772 "mx_discover", 3773 "mx_system_info", 3774 "mx_capability_req", 3775 "mx_capability_resp", 3776 "mx_capability_ack", 3777 "mx_up_setup_conf_req", 3778 "mx_up_setup_cnf", 3779 "mx_reconf_req", 3780 "mx_reconf_rsp", 3781 "mx_path_est_req", 3782 "mx_path_est_results", 3783 "mx_traffic_steering_req", 3784 "mx_traffic_steering_rsp", 3785 "mx_ssid_indication", 3786 "mx_keep_alive_req", 3787 "mx_keep_alive_rsp", 3788 "mx_measurement_conf", 3789 "mx_measurement_report", 3790 "mx_session_termination_req", 3791 "mx_session_termination_resp", 3792 "mx_app_madp_assoc_req", 3793 "mx_app_madp_assoc_resp", 3794 "mx_network_analytics_req", 3795 "mx_network_analytics_resp" 3796 ], 3797 "type": "string" 3798 }, 3799 "sequence_num_def": { 3800 "minimum": 1, 3801 "type": "integer" 3802 }, 3803 "version_def": { 3804 "type": "string" 3805 } 3806 }, 3807 "id": "http://www.ietf.org/mams/mx_base_def.json" 3808 } 3810 C.3.2. MX Definitions 3812 { 3813 "$schema": "http://json-schema.org/draft-04/schema#", 3814 "definitions": { 3815 "adapt_method": { 3816 "enum": [ 3817 "UDP_without_DTLS", 3818 "UDP_with_DTLS", 3819 "IPSec", 3820 "Client_NAT" 3821 ], 3822 "type": "string" 3823 }, 3824 "conv_method": { 3825 "enum": [ 3826 "GMA", 3827 "MPTCP_Proxy", 3828 "GRE_Aggregation_Proxy", 3829 "MPQUIC" 3830 ], 3831 "type": "string" 3832 }, 3833 "supported": { 3834 "type": "boolean" 3835 }, 3836 "active": { 3837 "type": "boolean" 3838 }, 3839 "connection_id": { 3840 "type": "integer" 3841 }, 3842 "feature_name": { 3843 "enum": [ 3844 "lossless_switching", 3845 "fragmentation", 3846 "concatenation", 3847 "uplink_aggregation", 3848 "downlink_aggregation", 3849 "measurement" 3850 ], 3851 "type": "string" 3852 }, 3853 "connection_type": { 3854 "enum": [ 3855 "wi-fi", 3856 "5g-nr", 3857 "multi-fire", 3858 "lte" 3859 ], 3860 "type": "string" 3861 }, 3862 "ip_address": { 3863 "type": "string" 3864 }, 3865 "port": { 3866 "maximum": 65535, 3867 "minimum": 1, 3868 "type": "integer" 3869 }, 3870 "adaptation_method": { 3871 "allOf" : [ 3872 { "$ref": "#/definitions/adapt_method" }, 3873 { "$ref": "#/definitions/supported" } 3874 ] 3875 }, 3876 "connection": { 3877 "allOf" : [ 3878 { "$ref": "#/definitions/connection_id" }, 3879 { "$ref": "#/definitions/connection_type" } 3880 ] 3881 }, 3882 "convergence_method": { 3883 "allOf": [ 3884 { "$ref": "#/definitions/conv_method" }, 3885 { "$ref": "#/definitions/supported" } 3886 ] 3887 }, 3888 "feature_status": { 3889 "allOf": [ 3890 { "$ref": "#/definitions/feature_name" }, 3891 { "$ref": "#/definitions/active" } 3892 ] 3893 }, 3894 "ncm_end_point": { 3895 "allOf" : [ 3896 { "$ref" : "#/definitions/ip_address" }, 3897 { "$ref" : "#/definitions/port" } 3898 ] 3899 }, 3900 "capability_acknowledgement" : { 3901 "enum" : [ 3902 "MX_ACCEPT", 3903 "MX_REJECT" 3904 ], 3905 "type" : "string" 3906 }, 3907 "threshold" : { 3908 "high" : { 3909 "type" : "integer" 3910 }, 3911 "low" : { 3912 "type" : "integer" 3913 }, 3914 "type" : "object" 3915 }, 3916 "meas_report_param" : { 3917 "enum" : [ 3918 "WLAN_RSSI", 3919 "WLAN_LOAD", 3920 "LTE_RSRP", 3921 "LTE_RSRQ", 3922 "UL_TPUT", 3923 "DL_TPUT", 3924 "EST_UL_TPUT", 3925 "EST_DL_TPUT", 3926 "NR_RSRP", 3927 "NR_RSRQ", 3928 ], 3929 "type" : "string" 3930 }, 3931 "meas_report_conf" : { 3932 "meas_rep_param" : { 3933 "$ref" : "#definitions/meas_report_param" 3934 }, 3935 "meas_threshold" : { 3936 "$ref" : "#definitions/threshold" 3937 }, 3938 "meas_period_ms" : { 3939 "type" : "integer" 3940 }, 3941 "type" : "object" 3942 }, 3943 "ssid_types" : { 3944 "enum" : [ 3945 "ssid", 3946 "bssid", 3947 "hessid" 3948 ], 3949 "type" : "string" 3950 }, 3951 "ip_addr_mask" : { 3952 "type" : "string", 3953 "default" : "0.0.0.0/0" 3954 }, 3955 "port_range" : { 3956 "start" : { 3957 "type" : "integer", 3958 "default" : 0 3960 }, 3961 "end" : { 3962 "type" : "integer", 3963 "default" : 65535 3964 } 3965 }, 3966 "traffic_flow_template" : { 3967 "remote_addr_mask" : { "$ref" : "#definitions/ip_addr_mask" }, 3968 "local_addr_mask" : { "$ref" : "#definitions/ip_addr_mask" }, 3969 "protocol_type" : { 3970 "type" : "integer", 3971 "minimum" : 0, 3972 "maximum" : 255 3973 }, 3974 "local_port_range" : { "$ref" : "#definitions/port_range" }, 3975 "remote_port_range" : { "$ref" : "#definitions/port_range" }, 3976 "traffic_class" : { 3977 "type" : "integer", 3978 "default" : 255 3979 }, 3980 "flow_label" : { 3981 "type" : "integer", 3982 "default" : 0 3983 } 3984 }, 3985 "delivery_node_id" : { 3986 "type" : "string" 3987 }, 3988 "unique_session_id" : { 3989 "type" : "object", 3990 "ncm_id" : { 3991 "type" : "integer" 3992 }, 3993 "session_id" : { 3994 "type" : "integer" 3995 } 3996 }, 3997 "keep_alive_reason" : { 3998 "enum" : [ 3999 "Timeout", 4000 "Handover" 4001 ], 4002 "type" : "string" 4003 }, 4004 "connection_status" : { 4005 "enum" : [ 4006 "disabled", 4007 "enabled", 4008 "connected" 4009 ], 4010 "type" : "string", 4011 "default" : "connected" 4012 }, 4013 "adaptation_param" : { 4014 "udp_adapt_port" : { 4015 "type" : "integer" 4016 } 4017 }, 4018 "probe_param" : { 4019 "probe_port" : { 4020 "type" : "integer" 4021 }, 4022 "anchor_conn_id" : { 4023 "type" : "integer" 4024 }, 4025 "mx_configuration_id" : { 4026 "type" : "integer" 4027 }, 4028 }, 4029 "client_param" : { 4030 "connection_id" : { 4031 "type" : "integer" 4032 }, 4033 "adapt_param" : { 4034 "type" : {"$ref" : "#definitions/adaptation_param" } 4035 } 4036 } 4037 }, 4038 "adapt_param": { 4039 "tunnel_ip_addr": { 4040 "type": "string" 4041 }, 4042 "tunnel_end_port": { 4043 "type": "integer" 4044 }, 4045 "shared_secret": { 4046 "type": "string" 4047 }, 4048 "mx_header_optimization": { 4049 "type": "boolean", 4050 "default": false 4051 } 4052 }, 4053 "delivery_connection": { 4054 "connection_id": { 4055 "$ref": "#definitions/connection_id" 4057 }, 4058 "connection_type": { 4059 "$ref": "#definitions/connection_type" 4060 }, 4061 "adaptation_method": { 4062 "$ref": "#definitions/adapt_method" 4063 }, 4064 "adaptation_method_param": { 4065 "$ref": "#definitions/adapt_param" 4066 } 4067 }, 4068 "app_madp_assoc": { 4069 "anchor_conn_id" : { 4070 "type" : "integer" 4071 }, 4072 "mx_configuration_id" : { 4073 "type" : "integer" 4074 } 4076 "ul_tft_list": { 4077 "items": { 4078 "$ref": "#definitions/traffic_flow_template" 4079 }, 4080 "type": "array" 4081 }, 4082 "dl_tft_list": { 4083 "items": { 4084 "$ref": "#definitions/traffic_flow_template" 4085 }, 4086 "type": "array" 4087 } 4088 } 4089 "predict_param_name": { 4090 "enum": [ 4091 "validity time", 4092 "bandwidth", 4093 "jitter", 4094 "latency", 4095 "signal_quality" 4096 ], 4097 "type": "string" 4098 }, 4099 "predict_add_param_name": { 4100 "enum": [ 4101 "WLAN_RSSI", 4102 "WLAN_LOAD", 4103 "LTE_RSRP", 4104 "LTE_RSRQ", 4105 "NR_RSRP", 4106 "NR_RSRQ" 4107 ], 4108 "type": "string" 4109 } 4110 }, 4111 "id": "http://www.ietf.org/mams/definitions.json" 4112 } 4114 C.3.3. MX Discover 4116 { 4117 "$schema": "http://json-schema.org/draft-04/schema#", 4118 "additionalProperties": false, 4119 "id": "http://www.ietf.org/mams/mx_discover.json", 4120 "properties": { 4121 "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, 4122 "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, 4123 "version" : {"$ref": "mx_base_def.json#/version_def"} 4124 }, 4125 "type": "object" 4126 } 4128 C.3.4. MX System Update 4129 { 4130 "$schema": "http://json-schema.org/draft-04/schema#", 4131 "additionalProperties": false, 4132 "id": "http://www.ietf.org/mams/mx_system_info.json", 4133 "properties": { 4134 "message_type": { 4135 "$ref": "mx_base_def.json#/message_type_def" 4136 }, 4137 "sequence_num": { 4138 "$ref": "mx_base_def.json#/sequence_num_def" 4139 }, 4140 "version": { 4141 "$ref": "mx_base_def.json#/version_def" 4142 }, 4143 "ncm_connections": { 4144 "type": "array", 4145 "items": [ 4146 { "$ref": "definitions.json#/connection" }, 4147 { "$ref": "definitions.json#/ncm_end_point" } 4148 ] 4149 } 4150 }, 4151 "type": "object" 4152 } 4154 C.3.5. MX Capability Request 4155 { 4156 "$schema": "http://json-schema.org/draft-04/schema#", 4157 "additionalProperties": false, 4158 "id": "http://www.ietf.org/mams/mx_capability_req.json", 4159 "properties": { 4160 "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, 4161 "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, 4162 "version" : {"$ref": "mx_base_def.json#/version_def"}, 4163 "adaptation_methods": { 4164 "items": { "$ref" : "definitions.json#/adaptation_method"}, 4165 "type": "array" 4166 }, 4167 "anchor_connections": { 4168 "items": { "$ref" : "definitions.json#/connection"}, 4169 "type": "array" 4170 }, 4171 "convergence_methods": { 4172 "items": { "$ref" : "definitions.json#/convergence_method"}, 4173 "type": "array" 4174 }, 4175 "delivery_connections": { 4176 "items": { "$ref" : "definitions.json#/connection"}, 4177 "type": "array" 4178 }, 4179 "feature_active": { 4180 "items": { "$ref" : "definitions.json#/feature_status"}, 4181 "type": "array" 4182 }, 4183 "num_anchor_connections": { 4184 "type": "integer" 4185 }, 4186 "num_delivery_connections": { 4187 "type": "integer" 4188 } 4189 }, 4190 "type": "object" 4191 } 4193 C.3.6. MX Capability Response 4194 { 4195 "$schema": "http://json-schema.org/draft-04/schema#", 4196 "additionalProperties": false, 4197 "id": "http://www.ietf.org/mams/mx_capability_resp.json", 4198 "properties": { 4199 "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, 4200 "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, 4201 "version" : {"$ref": "mx_base_def.json#/version_def"}, 4202 "adaptation_methods": { 4203 "items": { "$ref" : "definitions.json#/adaptation_method" }, 4204 "type": "array" 4205 }, 4206 "anchor_connections": { 4207 "items": { "$ref" : "definitions.json#/connection"}, 4208 "type": "array" 4209 }, 4210 "convergence_methods": { 4211 "items": { "$ref" : "definitions.json#/convergence_method" }, 4212 "type": "array" 4213 }, 4214 "delivery_connections": { 4215 "items": { "$ref" : "definitions.json#/connection"}, 4216 "type": "array" 4217 }, 4218 "feature_active": { 4219 "items": { "$ref" : "definitions.json#/feature_status"}, 4220 "type": "array" 4221 }, 4222 "num_anchor_connections": { 4223 "type": "integer" 4224 }, 4225 "num_delivery_connections": { 4226 "type": "integer" 4227 }, 4228 "unique_session_id" : { 4229 "$ref": "definitions.json#/unique_session_id" 4230 } 4231 }, 4232 "type": "object" 4233 } 4235 C.3.7. MX Capability Ack 4236 { 4237 "$schema": "http://json-schema.org/draft-04/schema#", 4238 "definitions": {}, 4239 "id": "http://www.ietf.org/mams/mx_capability_ack.json", 4240 "properties": { 4241 "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, 4242 "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, 4243 "version" : {"$ref": "mx_base_def.json#/version_def"}, 4244 "unique_session_id" : { "$ref": "definitions.json#/unique_session_id" }, 4245 "capability_ack": {"$ref" : "definitions.json#/capability_acknowledgement"} 4246 }, 4247 "type": "object" 4248 } 4250 C.3.8. MX Reconfiguration Request 4251 { 4252 "$schema": "http://json-schema.org/draft-04/schema#", 4253 "definitions": {}, 4254 "id": "http://www.ietf.org/mams/mx_reconf_req.json", 4255 "properties": { 4256 "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, 4257 "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, 4258 "version" : {"$ref": "mx_base_def.json#/version_def"}, 4259 "unique_session_id" : { 4260 "$ref": "definitions.json#/unique_session_id" 4261 }, 4262 "connection_id" : {"$ref" : "definitions.json#/connection_id" }, 4263 "ip_address": {"$ref" : "definitions.json#/ip_address" }, 4264 "mtu_size": { 4265 "maximum" : 65535, 4266 "minimum": 1, 4267 "type": "integer" 4268 }, 4269 "ssid" : { 4270 "type" : "string" 4271 }, 4272 "reconf_action": { 4273 "enum": [ 4274 "release", 4275 "setup", 4276 "update" 4277 ], 4278 "id": "/properties/reconf_action", 4279 "type": "string" 4280 }, 4281 "connection_status" : {"$ref" : "definitions.json#/connection_status"}, 4282 "delivery_node_id" : {"$ref": "definitions.json#/delivery_node_id"} 4283 }, 4284 "type": "object" 4285 } 4287 C.3.9. MX Reconfiguration Response 4288 { 4289 "$schema": "http://json-schema.org/draft-04/schema#", 4290 "definitions": {}, 4291 "id": "http://www.ietf.org/mams/mx_reconf_rsp.json", 4292 "properties": { 4293 "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, 4294 "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, 4295 "version" : {"$ref": "mx_base_def.json#/version_def"} 4296 }, 4297 "type": "object" 4298 } 4300 C.3.10. MX UP Setup Configuration 4302 { 4303 "$schema": "http://json-schema.org/draft-04/schema#", 4304 "additionalProperties": false, 4305 "definitions": { 4306 "convergence_configuration" : { 4307 "mx_configuration_id": { "type" : "integer"}, 4308 "convergence_method": { "$ref" : "definitions.json#/conv_method" }, 4309 "convergence_method_params": { 4310 "properties": { 4311 "proxy_ip": { "$ref" : "definitions.json#/ip_address" }, 4312 "proxy_port": {"$ref" : "definitions.json#/port" }, 4313 "client_key": {"$ref" : "definitions.json#/client_key" } 4314 }, 4315 "type": "object" 4316 }, 4317 "num_delivery_connections": { 4318 "type": "integer" 4319 }, 4320 "delivery_connections": { 4321 "items":{ "$ref" : "definitions.json#/delivery_connection" }, 4322 "type": "array" 4323 } 4324 } 4325 }, 4326 "id": "http://www.ietf.org/mams/mx_up_setup_conf_req.json", 4327 "properties": { 4328 "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, 4329 "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, 4330 "version" : {"$ref": "mx_base_def.json#/version_def"}, 4331 "num_anchor_connections": { 4332 "type": "integer" 4333 }, 4334 "anchor_connections": { 4335 "items": { 4336 "properties": { 4337 "connection_id": { "$ref" : "definitions.json#/connection_id" }, 4338 "connection_type": { "$ref" : "definitions.json#/connection_type" }, 4339 "num_active_mx_conf" : { "type" : "integer" }, 4340 "convergence_config" : { 4341 "items":{ "$ref" : "definitions/convergence_configuration" }, 4342 "type" : "array" 4343 } 4345 }, 4346 "type": "object" 4347 }, 4348 "type": "array" 4349 } 4350 }, 4351 "type": "object" 4352 } 4354 C.3.11. MX UP Setup Confirmation 4356 { 4357 "$schema": "http://json-schema.org/draft-04/schema#", 4358 "definitions": {}, 4359 "id": "http://www.ietf.org/mams/mx_up_setup_cnf.json", 4360 "properties": { 4361 "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, 4362 "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, 4363 "version" : {"$ref": "mx_base_def.json#/version_def"}, 4364 "unique_session_id" : { "$ref": "definitions.json#/unique_session_id" }, 4365 "probe_param" : { "$ref": "definitions.json#/probe_param" }, 4366 "num_delivery_conn" : { 4367 "type" : "integer" 4368 }, 4369 "client_params" : { 4370 "type" : "array", 4371 "items" : [ 4372 {"$ref": "definitions.json#/client_param"} 4373 ] 4374 } 4375 }, 4376 "type": "object" 4377 } 4378 C.3.12. MX Traffic Steering Request 4380 { 4381 "$schema": "http://json-schema.org/draft-04/schema#", 4382 "definitions": { 4383 "conn_list" : { 4384 "items" : { "$ref" : "definitions.json#/connection_id" }, 4385 "type": "array" 4386 }, 4387 "ul_delivery" : { 4388 "ul_tft" : { "$ref" : "definitions.json#/traffic_flow_template"}, 4389 "connection_list" : { "$ref" : "#definitions/conn_list" } 4390 } 4391 }, 4392 "id": "http://www.ietf.org/mams/mx_traffic_steering_req.json", 4393 "properties": { 4394 "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, 4395 "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, 4396 "version" : {"$ref": "mx_base_def.json#/version_def"}, 4397 "connection_id": {"$ref" : "definitions.json#/connection_id" }, 4398 "mx_configuration_id": { "type" : "integer"}, 4399 "downlink_delivery": { 4400 "items": { "$ref" : "definitions.json#/connection_id" }, 4401 "type": "array" 4402 }, 4403 "feature_activation": { 4404 "items": {"$ref" : "definitions.json#/feature_status" }, 4405 "type": "array" 4406 }, 4407 "default_uplink_delivery": { 4408 "type": "integer" 4409 }, 4410 "uplink_delivery": { 4411 "items": { "$ref" : "#definitions/ul_delivery" }, 4412 "type": "array" 4413 } 4414 }, 4415 "type": "object" 4416 } 4418 C.3.13. MX Traffic Steering Response 4419 { 4420 "$schema": "http://json-schema.org/draft-04/schema#", 4421 "definitions": {}, 4422 "id": "http://example.com/example.json", 4423 "properties": { 4424 "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, 4425 "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, 4426 "version" : {"$ref": "mx_base_def.json#/version_def"}, 4427 "unique_session_id" : { "$ref": "definitions.json#/unique_session_id" }, 4428 "feature_activation": { 4429 "items": {"$ref" : "definitions.json#/feature_status" }, 4430 "type": "array" 4431 } 4432 }, 4433 "type": "object" 4434 } 4436 C.3.14. MX Application MADP Association Request 4438 { 4439 "$schema": "http://json-schema.org/draft-04/schema#", 4440 "definitions": {}, 4441 "id": "http://example.com/example.json", 4442 "properties": { 4443 "message_type": { 4444 "$ref": "mx_base_def.json#/message_type_def" 4445 }, 4446 "sequence_num": { 4447 "$ref": "mx_base_def.json#/sequence_num_def" 4448 }, 4449 "version": { 4450 "$ref": "mx_base_def.json#/version_def" 4451 }, 4452 "unique_session_id": { 4453 "$ref": "definitions.json#/unique_session_id" 4454 }, 4455 "app_madp_assoc_list": { 4456 "items": { 4457 "$ref": "definitions.json#/app_madp_assoc" 4458 }, 4459 "type": "array" 4460 } 4461 }, 4462 "type": "object" 4463 } 4464 C.3.15. MX Application MADP Association Response 4466 { 4467 "$schema": "http://json-schema.org/draft-04/schema#", 4468 "definitions": {}, 4469 "id": "http://example.com/example.json", 4470 "properties": { 4471 "message_type": { 4472 "$ref": "mx_base_def.json#/message_type_def" 4473 }, 4474 "sequence_num": { 4475 "$ref": "mx_base_def.json#/sequence_num_def" 4476 }, 4477 "version": { 4478 "$ref": "mx_base_def.json#/version_def" 4479 }, 4480 "unique_session_id": { 4481 "$ref": "definitions.json#/unique_session_id" 4482 }, 4483 "is_success": { 4484 "type": "boolean" 4485 } 4486 }, 4487 "type": "object" 4488 } 4490 C.3.16. MX Path Estimation Request 4492 { 4493 "$schema": "http://json-schema.org/draft-04/schema#", 4494 "definitions": {}, 4495 "id": "http://www.ietf.org/mams/mx_path_est_req.json", 4496 "properties": { 4497 "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, 4498 "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, 4499 "version" : {"$ref": "mx_base_def.json#/version_def"}, 4500 "active_probe_ack_req": { 4501 "enum": [ 4502 "no", 4503 "yes" 4504 ], 4505 "type": "string" 4506 }, 4507 "active_probe_freq_ms": { 4508 "maximum" : 10000, 4509 "minimum": 100, 4510 "type": "integer" 4512 }, 4513 "active_probe_size_bytes": { 4514 "maximum": 1500, 4515 "minimum": 100, 4516 "type": "integer" 4517 }, 4518 "active_probe_duration_sec" : { 4519 "maximum" : 100, 4520 "minimum" : 10, 4521 "type" : "integer" 4522 }, 4523 "connection_id": { "$ref" : "definitions#/connection_id" }, 4524 "init_probe_ack_req": { 4525 "enum": [ 4526 "no", 4527 "yes" 4528 ], 4529 "type": "string" 4530 }, 4531 "init_probe_size_bytes": { 4532 "maximum": 1500, 4533 "minimum": 100, 4534 "type": "integer" 4535 }, 4536 "init_probe_test_duration_ms": { 4537 "maximum": 10000, 4538 "minimum": 100, 4539 "type": "integer" 4540 }, 4541 "init_probe_test_rate_Mbps": { 4542 "maximum": 100, 4543 "minimum": 1, 4544 "type": "integer" 4545 } 4546 }, 4547 "type": "object" 4548 } 4550 C.3.17. MX Path Estimation Report 4551 { 4552 "$schema": "http://json-schema.org/draft-04/schema#", 4553 "definitions": {}, 4554 "id": "http://www.ietf.org/mams/mx_path_est_results.json", 4555 "properties": { 4556 "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, 4557 "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, 4558 "version" : {"$ref": "mx_base_def.json#/version_def"}, 4559 "unique_session_id" : { "$ref": "definitions.json#/unique_session_id" }, 4560 "active_probe_results": { 4561 "properties": { 4562 "avg_tput_last_probe_duration_Mbps": { 4563 "maximum":100, 4564 "minimum": 1, 4565 "type": "number" 4566 } 4567 }, 4568 "type": "object" 4569 }, 4570 "connection_id": { "$ref" : "definitions.json#/connection_id" }, 4571 "init_probe_results": { 4572 "properties": { 4573 "lost_probes_percentage": { 4574 "maximum": 100, 4575 "minimum": 1, 4576 "type": "integer" 4577 }, 4578 "probe_rate_Mbps": { 4579 "maximum": 100, 4580 "minimum": 1, 4581 "type": "number" 4582 } 4583 }, 4584 "type": "object" 4585 } 4586 }, 4587 "type": "object" 4588 } 4590 C.3.18. MX SSID Indication 4591 { 4592 "$schema": "http://json-schema.org/draft-04/schema#", 4593 "definitions": {}, 4594 "id": "http://www.ietf.org/mams/mx_ssid_indication.json", 4595 "properties": { 4596 "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, 4597 "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, 4598 "version" : {"$ref": "mx_base_def.json#/version_def"}, 4599 "ssid_list": { 4600 "items": { 4601 "properties" : { 4602 "ssid_type": { "$ref" : "definitions.json#/ssid_types" }, 4603 "ssid_id" : { 4604 "type" : "integer" 4605 } 4606 } 4607 }, 4608 "type": "array" 4609 } 4610 }, 4611 "type": "object" 4612 } 4614 C.3.19. MX Measurements Configuration 4615 { 4616 "$schema": "http://json-schema.org/draft-04/schema#", 4617 "additionalProperties": false, 4618 "definitions" : { 4619 "meas_conf" : { 4620 "connection_id" : { "$ref" : "definitions.json#/connection_id" }, 4621 "connection_type" : { "$ref" : "definitions.json#/connection_type" }, 4622 "meas_rep_conf" : { 4623 "items" : { "$ref" : "definitions.json#/meas_report_conf" }, 4624 "type" : "array" 4625 } 4626 } 4627 }, 4628 "id": "http://www.ietf.org/mams/mx_measurement_conf.json", 4629 "properties": { 4630 "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, 4631 "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, 4632 "version" : {"$ref": "mx_base_def.json#/version_def"}, 4633 "measurement_configuration" : { 4634 "items" : {"$ref" : "#definitions/meas_conf" }, 4635 "type" : "array" 4636 } 4637 }, 4638 "type": "object" 4639 } 4641 C.3.20. MX Measurements Report 4642 { 4643 "$schema": "http://json-schema.org/draft-04/schema#", 4644 "definitions": {}, 4645 "id": "http://www.ietf.org/mams/mx_measurement_report.json", 4646 "properties": { 4647 "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, 4648 "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, 4649 "version" : {"$ref": "mx_base_def.json#/version_def"}, 4650 "unique_session_id" : { "$ref": "definitions.json#/unique_session_id" }, 4651 "measurment_reports": { 4652 "items": { 4653 "properties": { 4654 "connection_id": { 4655 "$ref" : "definitions.json#/connection_id" 4656 }, 4657 "connection_type" : { 4658 "$ref" : "definitions.json#/connection_type" 4659 }, 4660 "delivery_node_id" : { 4661 "$ref" : "definitions.json#/delivery_node_id" 4662 }, 4663 "measurements": { 4664 "items": { 4665 "properties": { 4666 "measurement_type": { 4667 "$ref" : "definitions.json#/meas_report_param" 4668 }, 4669 "measurement_value": { 4670 "type": "integer" 4671 } 4672 }, 4673 "type": "object" 4674 }, 4675 "type": "array" 4676 } 4677 }, 4678 "type": "object" 4679 }, 4680 "type": "array" 4681 } 4682 }, 4683 "type": "object" 4684 } 4685 C.3.21. MX Keep Alive Request 4687 { 4688 "$schema": "http://json-schema.org/draft-04/schema#", 4689 "additionalProperties": false, 4690 "id": "http://www.ietf.org/mams/mx_keep_alive_req.json", 4691 "properties": { 4692 "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, 4693 "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, 4694 "version" : {"$ref": "mx_base_def.json#/version_def"}, 4695 "keep_alive_reason" : {"$ref": "definitions.json#/keep_alive_reason"}, 4696 "unique_session_id" : {"$ref": "definitions.json#/unique_session_id"}, 4697 "connection_id" : {"$ref": "definitions.json#/connection_id"}, 4698 "delivery_node_id" : {"$ref": "definitions.json#/connection_id"} 4699 }, 4700 "type": "object" 4701 } 4703 C.3.22. MX Keep Alive Response 4705 { 4706 "$schema": "http://json-schema.org/draft-04/schema#", 4707 "additionalProperties": false, 4708 "id": "http://www.ietf.org/mams/mx_keep_alive_rsp.json", 4709 "properties": { 4710 "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, 4711 "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, 4712 "version" : {"$ref": "mx_base_def.json#/version_def"}, 4713 "unique_session_id" : {"$ref": "definitions.json#/unique_session_id"} 4714 }, 4715 "type": "object" 4716 } 4718 C.3.23. MX Session Termination Request 4719 { 4720 "$schema": "http://json-schema.org/draft-04/schema#", 4721 "additionalProperties": false, 4722 "id": "http://www.ietf.org/mams/mx_keep_alive_req.json", 4723 "properties": { 4724 "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, 4725 "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, 4726 "version" : {"$ref": "mx_base_def.json#/version_def"}, 4727 "unique_session_id" : { "$ref": "definitions.json#/unique_session_id" }, 4728 "reason" : { 4729 "enum" : [ 4730 "MX_NORMAL_RELEASE", 4731 "MX_NO_RESPONSE", 4732 "INTERNAL_ERROR" 4733 ], 4734 "type" : "string" 4735 } 4736 }, 4737 "type": "object" 4738 } 4740 C.3.24. MX Session Termination Response 4742 { 4743 "$schema": "http://json-schema.org/draft-04/schema#", 4744 "additionalProperties": false, 4745 "id": "http://www.ietf.org/mams/mx_session_termination_resp.json", 4746 "properties": { 4747 "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, 4748 "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, 4749 "version" : {"$ref": "mx_base_def.json#/version_def"}, 4750 "unique_session_id" : { "$ref": "definitions.json#/unique_session_id" } 4751 }, 4752 "type": "object" 4753 } 4755 C.3.25. MX Network Analytics Request 4756 { 4757 "$schema": "http://json-schema.org/draft-04/schema#", 4758 "additionalProperties": false, 4759 "id": "http://www.ietf.org/mams/mx_network_analytics_req.json", 4760 "properties": { 4761 "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, 4762 "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, 4763 "version" : {"$ref": "mx_base_def.json#/version_def"}, 4764 "unique_session_id" : { "$ref": "definitions.json#/unique_session_id" }, 4765 "params" : { 4766 "items" : {"$ref": "definitions.json#/predict_param_name"}, 4767 "type" : "array" 4768 } 4769 }, 4770 "type": "object" 4771 } 4773 C.3.26. MX Network Analytics Response 4774 { 4775 "$schema": "http://json-schema.org/draft-04/schema#", 4776 "additionalProperties": false, 4777 "definitions" : { 4778 "ParamPredictions" : { 4779 "param_name" : {"$ref" : "definitions.json#/predict_param_name"}, 4780 "additional_param" : {"$ref" : "definitions.json#/predict_add_param_name"}, 4781 "prediction" : { "type" : "integer" }, 4782 "likelihood" : { "type" : "integer" }, 4783 "validity_time" : { "type" : "integer" } 4785 }, 4786 "MXAnalyticsList" : { 4787 "connection_id" : { "$ref" : "definitions.json#/connection_id" }, 4788 "connection_type" : { "$ref" : "definitions.json#/connection_type" }, 4789 "predictions " : { 4790 "items" : { "$ref" : "#definitions/ParamPredictions" }, 4791 "type" : "array" 4792 } 4793 } 4794 }, 4795 "id": "http://www.ietf.org/mams/mx_network_analytics_resp.json", 4796 "properties": { 4797 "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, 4798 "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, 4799 "version" : {"$ref": "mx_base_def.json#/version_def"}, 4800 "param_list" : { 4801 "items" : {"$ref": "#definitions/MXAnalyticsList"}, 4802 "type" : "array"} 4803 }, 4804 "type": "object" 4805 } 4807 C.4. Examples in JSON 4809 C.4.1. MX Discover 4811 { 4812 "version" : "1.0", 4813 "message_type" : "mx_discover", 4814 "sequence_num" : 1 4815 } 4817 C.4.2. MX System Update 4818 { 4819 "version" : "1.0", 4820 "message_type" : "mx_system_info", 4821 "sequence_num" : 2, 4822 "ncm_connections" : [ 4823 { 4824 "connection_id" : 0, 4825 "connection_type" : "lte", 4826 "ncm_end_point" : { 4827 "ip_address" : "192.168.1.10", 4828 "port" : 1234 4829 } 4830 }, 4831 { 4832 "connection_id" : 1, 4833 "connection_type" : "wifi", 4834 "ncm_end_point" : { 4835 "ip_address" : "192.168.1.10", 4836 "port" : 1234 4837 } 4838 } 4839 ] 4840 } 4842 C.4.3. MX Capability Request 4844 { 4845 "version" : "1.0", 4846 "message_type" : "mx_capability_req", 4847 "sequence_num" : 3, 4848 "feature_active" : [ 4849 { 4850 "feature_name" : "lossless_switching", 4851 "active" : true 4852 }, 4853 { 4854 "feature_name" : "fragmentation", 4855 "active" : false 4856 } 4857 ], 4858 "num_anchor_connections" : 2, 4859 "anchor_connections" : [ 4860 { 4861 "connection_id" : 0, 4862 "connection_type" : "lte" 4863 }, 4864 { 4865 "connection_id" : 1, 4866 "connection_type" : "wifi" 4867 } 4868 ], 4869 "num_delivery_connections" : 2, 4870 "delivery_connections" : [ 4871 { 4872 "connection_id" : 0, 4873 "connection_type" : "lte" 4874 }, 4875 { 4876 "connection_id" : 1, 4877 "connection_type" : "wifi" 4878 } 4879 ], 4880 "convergence_methods" : [ 4881 { 4882 "method" : "GMA", 4883 "supported" : true 4884 }, 4885 { 4886 "method" : "MPTCP_Proxy", 4887 "supported" : false 4888 } 4889 ], 4890 "adaptation_methods" : [ 4891 { 4892 "method" : "UDP_without_DTLS", 4893 "supported" : false 4894 }, 4895 { 4896 "method" : "UDP_with_TLS", 4897 "supported" : false 4898 }, 4899 { 4900 "method" : "IPSec", 4901 "supported" : true 4902 }, 4903 { 4904 "method" : "Client_NAT", 4905 "supported" : false 4906 } 4907 ] 4908 } 4910 C.4.4. MX Capability Response 4912 { 4913 "version" : "1.0", 4914 "message_type" : "mx_capability_resp", 4915 "sequence_num" : 3, 4916 "feature_active" : [ 4917 { 4918 "feature_name" : "lossless_switching", 4919 "active" : true 4920 }, 4921 { 4922 "feature_name" : "fragmentation", 4923 "active" : false 4924 } 4925 ], 4926 "num_anchor_connections" : 2, 4927 "anchor_connections" : [ 4928 { 4929 "connection_id" : 0, 4930 "connection_type" : "lte" 4931 }, 4932 { 4933 "connection_id" : 1, 4934 "connection_type" : "wifi" 4935 } 4936 ], 4937 "num_delivery_connections" : 2, 4938 "delivery_connections" : [ 4939 { 4940 "connection_id" : 0, 4941 "connection_type" : "lte" 4942 }, 4943 { 4944 "connection_id" : 1, 4945 "connection_type" : "wifi" 4946 } 4947 ], 4948 "convergence_methods" : [ 4949 { 4950 "method" : "GMA", 4951 "supported" : true 4952 }, 4953 { 4954 "method" : "MPTCP_Proxy", 4955 "supported" : false 4956 } 4957 ], 4958 "adaptation_methods" : [ 4959 { 4960 "method" : "UDP_without_DTLS", 4961 "supported" : false 4962 }, 4963 { 4964 "method" : "UDP_with_TLS", 4965 "supported" : false 4966 }, 4967 { 4968 "method" : "IPSec", 4969 "supported" : true 4970 }, 4971 { 4972 "method" : "Client_NAT", 4973 "supported" : false 4974 } 4975 ], 4976 "unique_session_id" : { 4977 "ncm_id" : 110, 4978 "session_id" : 1111 4979 } 4980 } 4982 C.4.5. MX Capability Ack 4984 { 4985 "version" : "1.0", 4986 "message_type" : "mx_capability_ack", 4987 "sequence_num" : 3, 4988 "unique_session_id" : { 4989 "ncm_id" : 110, 4990 "session_id" : 1111 4991 }, 4992 "capability_ack" : "MX ACCEPT" 4993 } 4995 C.4.6. MX Reconfiguration Request 4996 { 4997 "version" : "1.0", 4998 "message_type" : "mx_reconf_req", 4999 "sequence_num" : 4, 5000 "unique_session_id" : { 5001 "ncm_id" : 110, 5002 "session_id" : 1111 5003 }, 5004 "reconf_action" : "setup", 5005 "connection_id" : 0, 5006 "ip_address" : "192.168.110.1", 5007 "ssid" : "SSID_1", 5008 "mtu_size" : 1300, 5009 "connection_status" : "connected", 5010 "delivery_node_id" : "2A12C" 5011 } 5013 C.4.7. MX Reconfiguration Response 5015 { 5016 "version" : "1.0", 5017 "message_type" : "mx_reconf_rsp", 5018 "sequence_num" : 4 5019 } 5021 C.4.8. MX UP Setup Configuration Request 5023 { 5024 "version": "1.0", 5025 "message_type": "mx_up_setup_conf_req", 5026 "sequence_num": 5, 5027 "num_anchor_connections": 2, 5028 "anchor_connections": [{ "connection_id": 1, 5029 "connection_type": "wifi", 5030 "num_active_mx_conf" : 2, 5031 "convergence_config" : [ 5032 { 5033 "mx_configuration_id" : 1, 5034 "convergence_method": "GMA", 5035 "convergence_method_params": {}, 5036 "num_delivery_connections": 2, 5037 "delivery_connections": [{ 5038 "connection_id": 0, 5039 "connection_type": "lte", 5040 "adaptation_method": "UDP_without_DTLS", 5041 "adaptation_method_param": { 5042 "tunnel_ip_addr": "6.6.6.6", 5043 "tunnel_end_port": 9999, 5044 "mx_header_optimization": true 5045 } 5046 }, 5047 { 5048 "connection_id": 1, 5049 "connection_type": "wifi" 5050 } 5051 ] 5052 }, 5053 { 5054 "mx_configuration_id" : 2, 5055 "convergence_method": "GMA", 5056 "convergence_method_params": {}, 5057 "num_delivery_connections": 1, 5058 "delivery_connections": [{ 5059 "connection_id": 0, 5060 "connection_type": "lte", 5061 "adaptation_method": "UDP_without_DTLS", 5062 "adaptation_method_param": { 5063 "tunnel_ip_addr": "6.6.6.6", 5064 "tunnel_end_port": 8877 5065 } 5066 } 5067 ] 5068 } 5069 ] 5070 }, 5071 { 5072 "connection_id": 0, 5073 "connection_type": "lte", 5074 "udp_port": 8888, 5075 "num_delivery_connections": 2, 5076 "delivery_connections": [{ 5077 "connection_id": 0, 5078 "connection_type": "lte" 5079 }, 5080 { 5081 "connection_id": 1, 5082 "connection_type": "wifi", 5083 "adaptation_method": "UDP_without_DTLS", 5084 "adaptation_method_param": { 5085 "tunnel_ip_addr": "192.168.3.3", 5086 "tunnel_end_port": "6000" 5087 } 5088 } 5089 ] 5090 } 5091 ] 5093 } 5095 C.4.9. MX UP Setup Confirmation 5097 { 5098 "version" : "1.0", 5099 "message_type" : "mx_up_setup_cnf", 5100 "sequence_num" : 5, 5101 "unique_session_id" : { 5102 "ncm_id" : 110, 5103 "session_id" : 1111 5104 }, 5105 "probe_param" : { 5106 "probe_port" : 48700, 5107 "anchor_conn_id" : 0, 5108 "mx_configuration_id" : 1 5109 }, 5110 "num_delivery_conn" : 2, 5111 "client_params" : [ 5112 { 5113 "connection_id" : 0, 5114 "adapt_param" : { 5115 "udp_adapt_port" : 51000 5116 } 5117 }, 5118 { 5119 "connection_id" : 1, 5120 "adapt_param" : { 5121 "udp_adapt_port" : 52000 5122 } 5123 } 5124 ] 5125 } 5127 C.4.10. MX Traffic Steering Request 5129 { 5130 "version" : "1.0", 5131 "message_type" : "mx_traffic_steering_req", 5132 "sequence_num" : 6, 5133 "connection_id" : 0, 5134 "mx_configuration_id" : 1, 5135 "downlink_delivery" : [ 5136 { 5137 "connection_id" : 0 5138 }, 5139 { 5140 "connection_id" : 1 5142 } 5143 ], 5144 "default_uplink_delivery" : 0, 5145 "uplink_delivery" : [ 5146 { 5147 "ul_tft" : { 5148 "remote_addr_mask" : "10.10.0.0/24", 5149 "local_addr_mask" : "192.168.0.0/24", 5150 "protocol_type" : 6, 5151 "loca_port_range" : { 5152 "start" : 100, 5153 "end" : 1000 5154 }, 5155 "remote_port_range" : { 5156 "start" : 100, 5157 "end" : 1000 5158 }, 5159 "traffic_class" : 20, 5160 "flow_label" : 100 5161 }, 5162 "conn_list" : [ 5163 { 5164 "connection_id" : 1 5165 } 5166 ] 5167 }, 5168 { 5169 "ul_tft" : { 5170 "remote_addr_mask" : "10.10.0.0/24", 5171 "local_addr_mask" : "192.168.0.0/24", 5172 "protocol_type" : 6, 5173 "local_port_range" : { 5174 "start" : 2000, 5175 "end" : 2000 5176 }, 5177 "remote_port_range" : { 5178 "start" : 100, 5179 "end" : 1000 5180 }, 5181 "traffic_class" : 20, 5182 "flow_label" : 50 5183 }, 5184 "conn_list" : [ 5185 { 5186 "connection_id" : 1 5187 } 5188 ] 5189 } 5191 ], 5192 "feature_activation" : [ 5193 { 5194 "feature_name" : "dl_aggregation", 5195 "active" : true 5196 }, 5197 { 5198 "feature_name" : "ul_aggregation", 5199 "active" : false 5200 } 5201 ] 5202 } 5204 C.4.11. MX Traffic Steering Response 5206 { 5207 "version": "1.0", 5208 "message_type": "mx_traffic_steering_rsp", 5209 "sequence_num": 6, 5210 "unique_session_id": { 5211 "ncm_id": 110, 5212 "session_id": 1111 5213 }, 5214 "feature_activation": [{ 5215 "feature_name": "lossless_switching", 5216 "active": true 5217 }, 5218 { 5219 "feature_name": "fragmentation", 5220 "active": false 5221 } 5222 ] 5223 } 5225 C.4.12. MX Application MADP Association Request 5226 { 5227 "version": "1.0", 5228 "message_type": "mx_app_madp_assoc_req", 5229 "sequence_num": 6, 5230 "unique_session_id": { 5231 "ncm_id": 110, 5232 "session_id": 1111 5233 }, 5234 "app_madp_assoc_list": [{ 5235 "connection_id" : 0, 5236 "mx_configuration_id" : 1, 5237 "ul_tft_list": [{ 5238 "protocol_type": 17, 5239 "local_port_range": { 5240 "start": 8888, 5241 "end": 8888 5242 } 5243 }], 5244 "dl_tft_list": [{ 5245 "protocol_type": 17, 5246 "remote_port_range": { 5247 "start": 8888, 5248 "end": 8888 5249 } 5250 }] 5251 } 5252 ] 5253 } 5255 C.4.13. MX Application MADP Association Response 5257 { 5258 "version": "1.0", 5259 "message_type": "mx_app_madp_assoc_resp", 5260 "sequence_num": 6, 5261 "is_success": true 5262 } 5264 C.4.14. MX Path Estimation Request 5265 { 5266 "version" : "1.0", 5267 "message_type" : "mx_path_est_req", 5268 "sequence_num" : 7, 5269 "connection_id" : 0, 5270 "init_probe_test_duration_ms" : 100, 5271 "init_probe_test_rate_Mbps" : 10, 5272 "init_probe_size_bytes" : 1000, 5273 "init_probe_ack_req" : "yes", 5274 "active_probe_freq_ms" : 10000, 5275 "active_probe_size_bytes" : 1000, 5276 "active_probe_duration_sec" : 10, 5277 "active_probe_ack_req" : "no" 5278 } 5280 C.4.15. MX Path Estimation Results 5282 { 5283 "version" : "1.0", 5284 "message_type" : "mx_path_est_results", 5285 "sequence_num" : 8, 5286 "unique_session_id" : { 5287 "ncm_id" : 110, 5288 "session_id" : 1111 5289 }, 5290 "connection_id" : 0, 5291 "init_probe_results" : { 5292 "lost_probes_percentage" : 1, 5293 "probe_rate_Mbps" : 9.9 5294 }, 5295 "active_probe_results" : { 5296 "avg_tput_last_probe_duration_Mbps" : 9.8 5297 } 5298 } 5300 C.4.16. MX SSID Indication 5301 { 5302 "version" : "1.0", 5303 "message_type" : "mx_ssid_indication", 5304 "sequence_num" : 9, 5305 "ssid_list" : [ 5306 { 5307 "ssid_type" : "ssid", 5308 "ssid_id" : "SSID_1" 5309 }, 5310 { 5311 "ssid_type" : "bssid", 5312 "ssid_id" : "xxx-yyy" 5313 } 5314 ] 5315 } 5317 C.4.17. MX Measurements Configuration 5319 { 5320 "version" : "1.0", 5321 "message_type" : "mx_measurement_conf", 5322 "sequence_num" : 10, 5323 "measurement_configuration" : [ 5324 { 5325 "connection_id" : 0, 5326 "connection_type" : "wi-fi", 5327 "meas_rep_conf" : [ 5328 { 5329 "meas_rep_param" : "WLAN_RSSI", 5330 "meas_threshold" : { 5331 "high" : -10, 5332 "low" : -15 5333 }, 5334 "meas_period_ms" : 500 5335 }, 5336 { 5337 "meas_rep_param" : "WLAN_LOAD", 5338 "meas_threshold" : { 5339 "high" : -10, 5340 "low" : -15 5341 }, 5342 "meas_period_ms" : 500 5343 }, 5344 { 5345 "meas_rep_param" : "EST_UL_TPUT", 5346 "meas_threshold" : { 5347 "high" : 100, 5348 "low" : 30 5349 }, 5350 "meas_period_ms" : 500 5351 } 5352 ] 5353 }, 5354 { 5355 "connection_id" : 1, 5356 "connection_type" : "lte", 5357 "meas_rep_conf" : [ 5358 { 5359 "meas_rep_param" : "LTE_RSRP", 5360 "meas_threshold" : { 5361 "high" : -10, 5362 "low" : -15 5363 }, 5364 "meas_period_ms" : 500 5365 }, 5366 { 5367 "meas_rep_param" : "LTE_RSRQ", 5368 "meas_threshold" : { 5369 "high" : -10, 5370 "low" : -15 5371 }, 5372 "meas_period_ms" : 500 5373 } 5374 ] 5375 } 5376 ] 5377 } 5379 C.4.18. MX Measurements Report 5380 { 5381 "version" : "1.0", 5382 "message_type" : "mx_measurement_report", 5383 "sequence_num" : 11, 5384 "unique_session_id" : { 5385 "ncm_id" : 110, 5386 "session_id" : 1111 5387 }, 5388 "measurment_reports" : [ 5389 { 5390 "connection_id" : 0, 5391 "connection_type" : "wi-fi", 5392 "delivery_node_id" : "2021A", 5393 "measurements" : [ 5394 { 5395 "measurement_type" : "WLAN_RSSI", 5396 "measurement_value" : -12 5397 }, 5398 { 5399 "measurement_type" : "UL_TPUT", 5400 "measurement_value" : 10 5401 }, 5402 { 5403 "measurement_type" : "EST_UL_TPUT", 5404 "measurement_value" : 20 5405 } 5406 ] 5407 }, 5408 { 5409 "connection_id" : 1, 5410 "connection_type" : "lte", 5411 "delivery_node_id" : "12323", 5412 "measurements" : [ 5413 { 5414 "measurement_type" : "LTE_RSRP", 5415 "measurement_value" : -12 5417 }, 5418 { 5419 "measurement_type" : "LTE_RSRQ", 5420 "measurement_value" : -12 5422 } 5423 ] 5424 } 5425 ] 5426 } 5428 C.4.19. MX Keep Alive Request 5430 { 5431 "version" : "1.0", 5432 "message_type" : "mx_keep_alive_req", 5433 "sequence_num" : 12, 5434 "keep_alive_reason" : "Handover", 5435 "unique_session_id" : { 5436 "ncm_id" : 110, 5437 "session_id" : 1111 5438 }, 5439 "connection_id" : 0, 5440 "delivery_node_id" : "2021A" 5441 } 5443 C.4.20. MX Keep Alive Response 5445 { 5446 "version" : "1.0", 5447 "message_type" : "mx_keep_alive_rsp", 5448 "sequence_num" : 12, 5449 "unique_session_id" : { 5450 "ncm_id" : 110, 5451 "session_id" : 1111 5452 } 5453 } 5455 C.4.21. MX Session Termination Request 5457 { 5458 "version" : "1.0", 5459 "message_type" : "mx_session_termination_req", 5460 "sequence_num" : 13, 5461 "unique_session_id" : { 5462 "ncm_id" : 110, 5463 "session_id" : 1111 5464 }, 5465 "reason" : "MX_NORMAL_RELEASE" 5466 } 5468 C.4.22. MX Session Termination Response 5469 { 5470 "version" : "1.0", 5471 "message_type" : "mx_session_termination_resp", 5472 "sequence_num" : 13, 5473 "unique_session_id" : { 5474 "ncm_id" : 110, 5475 "session_id" : 1111 5476 } 5477 } 5479 C.4.23. MX Network Analytics Request 5481 { 5482 "version" : "1.0", 5483 "message_type" : "mx_network_analytics_req", 5484 "sequence_num" : 20, 5485 "unique_session_id" : { 5486 "ncm_id" : 110, 5487 "session_id" : 1111 5488 }, 5489 "parmas" : [ 5490 "jitter", 5491 "latency" 5492 ] 5493 } 5495 C.4.24. MX Network Analytics Response 5496 { 5497 "version": "1.0", 5498 "message_type": "mx_network_analytics_resp", 5499 "sequence_num": 20, 5500 "param_list": [{ 5501 "connection_id": 1, 5502 "connection_type": "wifi", 5503 "predictions": [{ 5504 "param_name": "jitter", 5505 "prediction": 100, 5506 "likelihood": 50, 5507 "validity_time": 10 5508 }, 5509 { 5510 "param_name": "latency", 5511 "prediction": 19, 5512 "likelihood": 40, 5513 "validity_time": 10 5514 } 5515 ] 5516 }, 5517 { 5518 "connection_id": 2, 5519 "connection_type": "lte", 5520 "predictions": [{ 5521 "param_name": "jitter", 5522 "prediction": 10, 5523 "likelihood": 80, 5524 "validity_time": 10 5525 }, 5526 { 5527 "param_name": "latency", 5528 "prediction": 4, 5529 "likelihood": 60, 5530 "validity_time": 10 5531 } 5532 ] 5533 } 5534 ] 5535 } 5537 Appendix D. Definition of APIs provided by CCM to the Applications at 5538 the Client 5540 This section provides an example implementation of the APIs exposed 5541 by the CCM to the Applications on the client, documented with OpenAPI 5542 using Swagger 2.0. 5544 { 5545 "swagger": "2.0", 5546 "info": { 5547 "version": "1.0.0", 5548 "title": "Client Connection Manager (CCM)", 5549 "description": "API provided by CCM towards Application on a MAMS client." 5550 }, 5551 "host": "MAMS.ietf.org", 5552 "basePath": "/ccm/v1.0", 5553 "schemes": [ 5554 "https" 5555 ], 5556 "consumes": [ 5557 "application/json" 5558 ], 5559 "produces": [ 5560 "application/json" 5561 ], 5562 "paths": { 5563 "/capabilities": { 5564 "get": { 5565 "description": "This API can be used by application to request for capabilities of the CCM.", 5566 "produces": [ 5567 "application/json", 5568 "text/html" 5569 ], 5570 "responses": { 5571 "200": { 5572 "description": "OK", 5573 "schema": { 5574 "$ref": "#/definitions/capability" 5575 } 5576 }, 5577 "default": { 5578 "description": "unexpected error", 5579 "schema": { 5580 "$ref": "#/definitions/errorModel" 5581 } 5582 } 5583 } 5584 } 5585 }, 5586 "/app_requirements": { 5587 "post": { 5588 "description": "This API is used by N-MADP to report any kind of MAMS user specific errors to NCM.", 5589 "produces": [ 5590 "application/json", 5591 "text/html" 5593 ], 5594 "parameters": [ 5595 { 5596 "name": "app-requirements", 5597 "in": "body", 5598 "required": true, 5599 "schema": { 5600 "$ref": "#/definitions/app-requirements" 5601 } 5602 } 5603 ], 5604 "responses": { 5605 "200": { 5606 "description": "OK" 5607 }, 5608 "default": { 5609 "description": "unexpected error", 5610 "schema": { 5611 "$ref": "#/definitions/errorModel" 5612 } 5613 } 5614 } 5615 } 5616 }, 5617 "/predictive_link_params": { 5618 "get": { 5619 "description": "This API is used by applications to get the information about predicted parameters for each delivery connection.", 5620 "produces": [ 5621 "application/json", 5622 "text/html" 5623 ], 5624 "responses": { 5625 "200": { 5626 "description": "OK", 5627 "schema": { 5628 "$ref": "#/definitions/link-params" 5629 } 5630 }, 5631 "default": { 5632 "description": "unexpected error", 5633 "schema": { 5634 "$ref": "#/definitions/errorModel" 5635 } 5636 } 5637 } 5638 } 5639 } 5640 }, 5641 "definitions": { 5642 "connection-id": { 5643 "type": "integer", 5644 "format": "uint8" 5645 }, 5646 "connection-type": { 5647 "enum": [ 5648 "wi-fi", 5649 "5g-nr", 5650 "multi-fire", 5651 "lte" 5652 ], 5653 "type": "string" 5654 }, 5655 "features": { 5656 "enum": [ 5657 "lossless_switching", 5658 "fragmentation", 5659 "concatenation", 5660 "uplink_aggregation", 5661 "downlink_aggregation", 5662 "measurement" 5663 ], 5664 "type": "string" 5665 }, 5666 "adaptation-methods": { 5667 "enum": [ 5668 "UDP_without_DTLS", 5669 "UDP_with_DTLS", 5670 "IPSec", 5671 "Client_NAT" 5672 ], 5673 "type": "string" 5674 }, 5675 "convergence-methods": { 5676 "enum": [ 5677 "GMA", 5678 "MPTCP_Proxy", 5679 "GRE_Aggregation_Proxy", 5680 "MPQUIC" 5681 ], 5682 "type": "string" 5683 }, 5684 "connection": { 5685 "type": "object", 5686 "properties": { 5687 "conn-id": { 5688 "$ref": "#/definitions/connection-id" 5690 }, 5691 "conn-type": { 5692 "$ref": "#/definitions/connection-type" 5693 } 5694 } 5695 }, 5696 "convergence-parameters": { 5697 "type": "object", 5698 "properties": { 5699 "conv-param-name": { 5700 "type": "string" 5701 }, 5702 "conv-param-value": { 5703 "type": "string" 5704 } 5705 } 5706 }, 5707 "convergence-details": { 5708 "type": "object", 5709 "properties": { 5710 "conv-method": { 5711 "$ref": "#/definitions/convergence-methods" 5712 }, 5713 "conv-params": { 5714 "type": "array", 5715 "items": { 5716 "$ref": "#/definitions/convergence-parameters" 5717 } 5718 } 5719 } 5720 }, 5721 "capability": { 5722 "type": "object", 5723 "properties": { 5724 "connections": { 5725 "type": "array", 5726 "items": { 5727 "$ref": "#/definitions/connection" 5728 } 5729 }, 5730 "features": { 5731 "type": "array", 5732 "items": { 5733 "$ref": "#/definitions/features" 5734 } 5735 }, 5736 "adapt-methods": { 5737 "type": "array", 5738 "items": { 5739 "$ref": "#/definitions/adaptation-methods" 5740 } 5741 }, 5742 "conv-methods": { 5743 "type": "array", 5744 "items": { 5745 "$ref": "#/definitions/convergence-details" 5746 } 5747 } 5748 } 5749 }, 5750 "qos-param-name": { 5751 "enum": [ 5752 "jitter", 5753 "latency", 5754 "bandwidth" 5755 ], 5756 "type": "string" 5757 }, 5758 "qos-param": { 5759 "type": "object", 5760 "properties": { 5761 "qos-param-name": { 5762 "$ref": "#/definitions/qos-param-name" 5763 }, 5764 "qos-param-value": { 5765 "type": "integer" 5766 } 5767 } 5768 }, 5769 "port-range": { 5770 "type": "object", 5771 "properties": { 5772 "start": { 5773 "type": "integer" 5774 }, 5775 "end": { 5776 "type": "integer" 5777 } 5778 } 5779 }, 5780 "protocol-type": { 5781 "type": "integer" 5782 }, 5783 "stream-features": { 5784 "type": "object", 5785 "properties": { 5786 "proto": { 5787 "$ref": "#/definitions/protocol-type" 5788 }, 5789 "port-range": { 5790 "$ref": "#/definitions/port-range" 5791 }, 5792 "traffic-qos": { 5793 "$ref": "#/definitions/qos-param" 5794 } 5795 } 5796 }, 5797 "app-requirements": { 5798 "type": "object", 5799 "properties": { 5800 "num-streams": { 5801 "type": "integer" 5802 }, 5803 "stream-feature": { 5804 "type": "array", 5805 "items": { 5806 "$ref": "#/definitions/stream-features" 5807 } 5808 } 5809 } 5810 }, 5811 "param-name": { 5812 "enum": [ 5813 "bandwidth", 5814 "jitter", 5815 "latency", 5816 "signal_quality" 5817 ], 5818 "type": "string" 5819 }, 5820 "additional-param-name": { 5821 "enum": [ 5822 "lte-rsrp", 5823 "lte-rspq", 5824 "nr-rsrp", 5825 "nr-rsrq", 5826 "wifi-rssi" 5827 ], 5828 "type": "string" 5829 }, 5830 "link-parameter": { 5831 "type": "object", 5832 "properties": { 5833 "connection": { 5834 "$ref": "#/definitions/connection" 5835 }, 5836 "param": { 5837 "$ref": "#/definitions/param-name" 5838 }, 5839 "additional-param": { 5840 "$ref": "#/definitions/additional-param-name" 5841 }, 5842 "prediction": { 5843 "type": "integer" 5844 }, 5845 "likelihood": { 5846 "type": "integer" 5847 }, 5848 "validity_time": { 5849 "type": "integer" 5850 } 5851 } 5852 }, 5853 "link-params": { 5854 "type": "array", 5855 "items": { 5856 "$ref": "#/definitions/link-parameter" 5857 } 5858 }, 5859 "errorModel": { 5860 "type": "object", 5861 "description": "Error indication containing the error code and message.", 5862 "required": [ 5863 "code", 5864 "message" 5865 ], 5866 "properties": { 5867 "code": { 5868 "type": "integer", 5869 "format": "int32" 5870 }, 5871 "message": { 5872 "type": "string" 5873 } 5874 } 5875 } 5876 } 5877 } 5878 Appendix E. Implementation Example using Python for MAMS Client and 5879 Server 5881 E.1. Client Side Implementation 5883 A simple client side implementation using python can be as following: 5885 #!/usr/bin/env python 5886 import asyncio 5887 import websockets 5888 import json 5889 import ssl 5890 import time 5891 import sys 5893 context = ssl.SSLContext(ssl.PROTOCOL_TLS) 5894 context.verify_mode = ssl.CERT_REQUIRED 5895 context.set_ciphers("RSA") 5896 context.check_hostname = False 5897 context.load_verify_locations("/home/mecadmin/certs/rootca.pem") 5899 discoverMsg = {'version':'1.0', 5900 'message_type':'mx_discover'} 5902 MXCapabilityRes = { 'version':'1.0', 5903 'message_type':'mx_capability_res', 5904 'FeatureActive':[{'feature_name':'fragmentation', 'active':'yes'}, {'feature_name':'lossless_switching', 'active':'yes'}], 5905 'num_anchor_connections':1, 5906 'anchor_connections':[{'connection_id':0, 'connection_type':'lte'}], 5907 'num_delivery_connections':1, 5908 'delivery_connections':[{'connection_id':1, 'connection_type':"wifi"}], 5909 'convergence_methods':[{'method':'GMA', 'supported':'true'}], 5910 'adaptation_methods':[{'method':'client_nat', 'supported':'false'}] 5911 } 5913 async def hello(): 5914 async with websockets.connect('wss://localhost:8765', ssl=context) as websocket: 5915 try: 5916 loopFlag=False 5917 while True: 5918 await websocket.send(json.dumps(discoverMsg)) 5919 json_message = await websocket.recv() 5920 message = json.loads(json_message) 5921 if "message_type" in message.keys(): 5922 print("Recieved message:{}".format(message["message_type"]),"version:{}".format(message["version"])) 5923 if message["message_type"] == "mx_capability_req" : 5924 await websocket.send(json.dumps(MXCapabilityRes)) 5925 loopFlag=True 5926 while(loopFlag==True): 5927 pass 5928 except: 5929 print("Client stopped") 5931 asyncio.get_event_loop().run_until_complete(hello()) 5932 E.2. Server Side Implementation 5934 A server client side implementation using python can be as following: 5936 #!/usr/bin/env python 5937 import asyncio 5938 import websockets 5939 import json 5940 import ssl 5942 ctx = ssl.SSLContext(ssl.PROTOCOL_TLS) 5943 #ctx.set_ciphers("RSA-AES256-SHA") 5944 ctx.load_verify_locations("/home/mecadmin/certs/rootca.pem") 5945 certfile = "/home/mecadmin/certs/server.pem" 5946 keyfile = "/home/mecadmin/certs/serverkey.pem" 5947 ctx.load_cert_chain(certfile, keyfile, password=None) 5949 MXCapabilityReq = { 'version':'1.0', 5950 'message_type':'mx_capability_req', 5951 'FeatureActive':[{'feature_name':'fragmentation', 'active':'yes'}, {'feature_name':'lossless_switching', 'active':'yes'}], 5952 'num_anchor_connections':1, 5953 'anchor_connections':[{'connection_id':0, 'connection_type':'lte'}], 5954 'num_delivery_connections':1, 5955 'delivery_connections':[{'connection_id':1, 'connection_type':"wifi"}], 5956 'convergence_methods':[{'method':'GMA', 'supported':'true'}], 5957 'adaptation_methods':[{'method':'client_nat', 'supported':'false'}] 5958 } 5960 async def hello(websocket, path): 5961 try: 5962 while True: 5963 name = await websocket.recv() 5964 msg = json.loads(name) 5965 if "message_type" in msg.keys(): 5966 print("Recieved message:{}".format(msg["message_type"]),"version:{}".format(msg["version"])) 5967 if msg['message_type'] == 'mx_discover': 5968 await websocket.send(json.dumps(MXCapabilityReq)) 5970 except: 5971 print("client disconnected") 5973 try: 5974 start_server = websockets.serve(hello, 'localhost', 8765,ssl=ctx) 5976 asyncio.get_event_loop().run_until_complete(start_server) 5977 asyncio.get_event_loop().run_forever() 5978 except: 5979 print("server stopped") 5981 Authors' Addresses 5983 Satish Kanugovi 5984 Nokia 5986 Email: satish.k@nokia.com 5988 Florin Baboescu 5989 Broadcom 5991 Email: florin.baboescu@broadcom.com 5993 Jing Zhu 5994 Intel 5996 Email: jing.z.zhu@intel.com 5998 Julius Mueller 5999 AT&T 6001 Email: jm169k@att.com 6003 SungHoon Seo 6004 Korea Telecom 6006 Email: sh.seo@kt.com