diff options
Diffstat (limited to 'doc/rfc/rfc8743.txt')
| -rw-r--r-- | doc/rfc/rfc8743.txt | 6490 |
1 files changed, 6490 insertions, 0 deletions
diff --git a/doc/rfc/rfc8743.txt b/doc/rfc/rfc8743.txt new file mode 100644 index 0000000..bbf1d40 --- /dev/null +++ b/doc/rfc/rfc8743.txt @@ -0,0 +1,6490 @@ + + + + +Independent Submission S. Kanugovi +Request for Comments: 8743 Nokia Bell Labs +Category: Informational F. Baboescu +ISSN: 2070-1721 Broadcom + J. Zhu + Intel + S. Seo + Korea Telecom + March 2020 + + + Multi-Access Management Services (MAMS) + +Abstract + + In multiconnectivity scenarios, the clients can simultaneously + connect to multiple networks based on different access technologies + and network architectures like Wi-Fi, LTE, and DSL. Both the quality + of experience of the users and the overall network utilization and + efficiency may be improved through the smart selection and + combination of access and core network paths that can dynamically + adapt to changing network conditions. + + This document presents a unified problem statement and introduces a + solution for managing multiconnectivity. The solution has been + developed by the authors based on their experiences in multiple + standards bodies, including the IETF and the 3GPP. However, this + document is not an Internet Standards Track specification, and it + does not represent the consensus opinion of the IETF. + + This document describes requirements, solution principles, and the + architecture of the Multi-Access Management Services (MAMS) + framework. The MAMS framework aims to provide best performance while + being easy to implement in a wide variety of multiconnectivity + deployments. It specifies the protocol for (1) flexibly selecting + the best combination of access and core network paths for the uplink + and downlink, and (2) determining the user-plane treatment (e.g., + tunneling, encryption) and traffic distribution over the selected + links, to ensure network efficiency and the best possible application + performance. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not candidates for any level of Internet Standard; + see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8743. + +Copyright Notice + + Copyright (c) 2020 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. Problem Statement + 4. Requirements + 4.1. Access-Technology-Agnostic Interworking + 4.2. Support for Common Transport Deployments + 4.3. Independent Access Path Selection for Uplink and Downlink + 4.4. Core Selection Independent of Uplink and Downlink Access + 4.5. Adaptive Access Network Path Selection + 4.6. Multipath Support and Aggregation of Access Link Capacities + 4.7. Scalable Mechanism Based on User-Plane Interworking + 4.8. Separate Control-Plane and User-Plane Functions + 4.9. Lossless Path (Connection) Switching + 4.10. Concatenation and Fragmentation for Adaptation to MTU + Differences + 4.11. Configuring Network Middleboxes Based on Negotiated + Protocols + 4.12. Policy-Based Optimal Path Selection + 4.13. Access-Technology-Agnostic Control Signaling + 4.14. Service Discovery and Reachability + 5. Solution Principles + 6. MAMS Reference Architecture + 7. MAMS Protocol Architecture + 7.1. MAMS Control-Plane Protocol + 7.2. MAMS User-Plane Protocol + 8. MAMS Control-Plane Procedures + 8.1. Overview + 8.2. Common Fields in MAMS Control Messages + 8.3. Common Procedures for MAMS Control Messages + 8.3.1. Message Timeout + 8.3.2. Keep-Alive Procedure + 8.4. Discovery and Capability Exchange + 8.5. User-Plane Configuration + 8.6. MAMS Path Quality Estimation + 8.6.1. MX Control PDU Definition + 8.6.2. Keep-Alive Message + 8.6.3. Probe-REQ/ACK Message + 8.7. MAMS Traffic Steering + 8.8. MAMS Application MADP Association + 8.9. MAMS Network ID Indication + 8.10. MAMS Client Measurement Configuration and Reporting + 8.11. MAMS Session Termination Procedure + 8.12. MAMS Network Analytics Request Procedure + 9. Generic MAMS Signaling Flow + 10. Relationship to IETF Technologies + 11. Applying MAMS Control Procedures with MPTCP Proxy as User Plane + 12. Applying MAMS Control Procedures for Network-Assisted Traffic + Steering When There Is No Convergence Layer + 13. Coexistence of MX Adaptation and MX Convergence Layers + 14. Security Considerations + 14.1. MAMS Control-Plane Security + 14.2. MAMS User-Plane Security + 15. Implementation Considerations + 16. Applicability to Multi-Access Edge Computing + 17. Related Work in Other Industry and Standards Forums + 18. IANA Considerations + 19. References + 19.1. Normative References + 19.2. Informative References + Appendix A. MAMS Control-Plane Optimization over Secure + Connections + Appendix B. MAMS Application Interface + B.1. Overall Design + B.2. Notation + B.3. Error Indication + B.4. CCM APIs + B.4.1. GET Capabilities + B.4.2. Posting Application Requirements + B.4.3. Getting Predictive Link Parameters + Appendix C. MAMS Control-Plane Messages Described Using JSON + C.1. Protocol Specification: General Processing + C.1.1. Notation + C.1.2. Discovery Procedure + C.1.3. System Information Procedure + C.1.4. Capability Exchange Procedure + C.1.5. User-Plane Configuration Procedure + C.1.6. Reconfiguration Procedure + C.1.7. Path Estimation Procedure + C.1.8. Traffic-Steering Procedure + C.1.9. MAMS Application MADP Association + C.1.10. MX SSID Indication + C.1.11. Measurements + C.1.12. Keep-Alive + C.1.13. Session Termination Procedure + C.1.14. Network Analytics + C.2. Protocol Specification: Data Types + C.2.1. MXBase + C.2.2. Unique Session ID + C.2.3. NCM Connections + C.2.4. Connection Information + C.2.5. Features and Their Activation Status + C.2.6. Anchor Connections + C.2.7. Delivery Connections + C.2.8. Method Support + C.2.9. Convergence Methods + C.2.10. Adaptation Methods + C.2.11. Setup of Anchor Connections + C.2.12. Init Probe Results + C.2.13. Active Probe Results + C.2.14. Downlink Delivery + C.2.15. Uplink Delivery + C.2.16. Traffic Flow Template + C.2.17. Measurement Report Configuration + C.2.18. Measurement Report + C.3. Schemas in JSON + C.3.1. MX Base Schema + C.3.2. MX Definitions + C.3.3. MX Discover + C.3.4. MX System Info + C.3.5. MX Capability Request + C.3.6. MX Capability Response + C.3.7. MX Capability Acknowledge + C.3.8. MX Reconfiguration Request + C.3.9. MX Reconfiguration Response + C.3.10. MX UP Setup Configuration Request + C.3.11. MX UP Setup Confirmation + C.3.12. MX Traffic Steering Request + C.3.13. MX Traffic Steering Response + C.3.14. MX Application MADP Association Request + C.3.15. MX Application MADP Association Response + C.3.16. MX Path Estimation Request + C.3.17. MX Path Estimation Results + C.3.18. MX SSID Indication + C.3.19. MX Measurement Configuration + C.3.20. MX Measurement Report + C.3.21. MX Keep-Alive Request + C.3.22. MX Keep-Alive Response + C.3.23. MX Session Termination Request + C.3.24. MX Session Termination Response + C.3.25. MX Network Analytics Request + C.3.26. MX Network Analytics Response + C.4. Examples in JSON + C.4.1. MX Discover + C.4.2. MX System Info + C.4.3. MX Capability Request + C.4.4. MX Capability Response + C.4.5. MX Capability Acknowledge + C.4.6. MX Reconfiguration Request + C.4.7. MX Reconfiguration Response + C.4.8. MX UP Setup Configuration Request + C.4.9. MX UP Setup Confirmation + C.4.10. MX Traffic Steering Request + C.4.11. MX Traffic Steering Response + C.4.12. MX Application MADP Association Request + C.4.13. MX Application MADP Association Response + C.4.14. MX Path Estimation Request + C.4.15. MX Path Estimation Results + C.4.16. MX SSID Indication + C.4.17. MX Measurement Configuration + C.4.18. MX Measurement Report + C.4.19. MX Keep-Alive Request + C.4.20. MX Keep-Alive Response + C.4.21. MX Session Termination Request + C.4.22. MX Session Termination Response + C.4.23. MX Network Analytics Request + C.4.24. MX Network Analytics Response + Appendix D. Definition of APIs Provided by the CCM to the + Applications at the Client + Appendix E. Implementation Example Using Python for MAMS Client + and Server + E.1. Client-Side Implementation + E.2. Server-Side Implementation + Acknowledgments + Contributors + Authors' Addresses + +1. Introduction + + Multi-Access Management Services (MAMS) is a programmable framework + that provides mechanisms for the flexible selection of network paths + in a multi-access (MX) communication environment, based on the + application's needs. The MAMS framework leverages network + intelligence and policies to dynamically adapt traffic distribution + across selected paths and user-plane treatments (e.g., encryption + needed for transport over Wi-Fi, or tunneling needed to overcome a + NAT between client and multipath proxy) to changing network/link + conditions. The network path selection and configuration messages + are carried as user-plane data between the functional elements in the + network and the client, and thus without any impact on the control- + plane signaling schemes of the underlying access networks. For + example, in a multi-access network with LTE and Wi-Fi technologies, + existing LTE and Wi-Fi signaling procedures will be used to set up + the LTE and Wi-Fi connections, respectively, and MAMS-specific + control-plane messages are carried as LTE or Wi-Fi user-plane data. + The MAMS framework defined in this document provides the capability + to make a smart selection of a flexible combination of access paths + and core network paths, as well as to choose the user-plane treatment + when the traffic is distributed across the selected paths. Thus, it + is a broad programmable framework that provides functions beyond the + simple sharing of network policies such as those provided by the + Access Network Discovery and Selection Function (ANDSF) [ANDSF], + which offers policies and rules for assisting 3GPP clients to + discover and select available access networks. Further, it allows + the choice and configuration of user-plane treatment for the traffic + over the paths, depending on the application's needs. + + The MAMS framework mechanisms are not dependent on any specific + access network types or user-plane protocols (e.g., TCP, UDP, Generic + Routing Encapsulation (GRE) [RFC2784] [RFC2890], Multipath TCP + (MPTCP) [RFC6824]). The MAMS framework coexists and complements the + existing protocols by providing a way to negotiate and configure + those protocols to match their use to a given multi-access scenario + based on client and network capabilities, and the specific needs of + each access network path. Further, the MAMS framework allows load + balancing of the traffic flows across the selected access network + paths, and the exchange of network state information to be used for + network intelligence to optimize the performance of such protocols. + + This document presents the requirements, solution principles, + functional architecture, and protocols for realizing the MAMS + framework. An important goal for the MAMS framework is to ensure + that it requires either minimum dependency or (better) no dependency + on the actual access technologies of the participating links, beyond + the fact that MAMS functional elements form an IP overlay across the + multiple paths. This allows the scheme to be "future proof" by + allowing independent technology evolution of the existing access and + core networks as well as seamless integration of new access + technologies. + + The solution described in this document has been developed by the + authors, based on their experiences in multiple standards bodies, + including the IETF and the 3GPP. However, this document is not an + Internet Standards Track specification, and it does not represent the + consensus opinion of the IETF. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + Client: An end-user device that supports connections with multiple + access nodes, possibly over different access technologies. Also + called a user device or user equipment (UE). + + Multiconnectivity Client: A client with multiple network + connections. + + Access Network: The segment in the network that delivers user data + packets to the client via an access link such as a Wi-Fi airlink, + an LTE airlink, or DSL. + + Core: The functional element that anchors the client IP address used + for communication with applications via the network. + + Network Connection Manager (NCM): A functional entity in the network + that handles MAMS control messages from the client and configures + the distribution of data packets over the available access and + core network paths, and manages the user-plane treatment (e.g., + tunneling, encryption) of the traffic flows. + + Client Connection Manager (CCM): A functional entity in the client + that exchanges MAMS signaling messages with the NCM, and which + configures the network paths at the client for the transport of + user data. + + Network Multi-Access Data Proxy (N-MADP): A functional entity in the + network that handles the forwarding of user data traffic across + multiple network paths. The N-MADP is responsible for MAMS- + related user-plane functionalities in the network. + + Client Multi-Access Data Proxy (C-MADP): A functional entity in the + client that handles the forwarding of user data traffic across + multiple network paths. The C-MADP is responsible for MAMS- + related user-plane functionalities in the client. + + Anchor Connection: Refers to the network path from the N-MADP to the + user-plane gateway (IP anchor) that has assigned an IP address to + the client. + + Delivery Connection: Refers to the network path from the N-MADP to + the client. + + Uplink (also referred to as "UL" in this document): Refers to the + direction of a connection from a client toward the network. + + Downlink (also referred to as "DL" in this document): Refers to the + direction of a connection from the network toward a client. + +3. Problem Statement + + Typically, a client has access to multiple communication networks + based on different technologies for accessing application services, + for example, LTE, Wi-Fi, DSL, or MulteFire. Different technologies + exhibit benefits and limitations in different scenarios. For + example, Wi-Fi provides high throughput for end users when their Wi- + Fi coverage is good, but the throughput degrades significantly as a + given user moves closer to the edge of its Wi-Fi coverage area + (typically in the range of a few tens of meters) or if the user + population is large (due to a contention-based Wi-Fi access scheme). + In LTE networks, the capacity is often constrained by the limited + availability of licensed spectrum. However, the quality of the + service is predictable even in multi-user scenarios, due to + controlled scheduling and licensed-spectrum usage. + + Additionally, the use of a particular access network path is often + coupled with the use of its associated core network and the services + that are offered by that network. For example, in an enterprise that + has deployed both Wi-Fi and LTE networks, the enterprise services, + such as printers and corporate audio/video conferencing, are + accessible only via Wi-Fi access connected to the enterprise-hosted + (Wi-Fi) core, whereas the LTE access can be used to get operator + services, including access to the public Internet. + + Thus, application performance in different scenarios becomes + dependent on the choice of access networks (e.g., Wi-Fi, LTE) and the + network and transport protocols used (e.g., VPN, MPTCP, GRE). + Therefore, to achieve the best possible application performance in a + wide range of scenarios, a framework is needed that allows the + selection and flexible combination of access and core network paths + as well as the protocols used for uplink and downlink data delivery. + + For example, in uncongested scenarios and when the user's Wi-Fi + coverage is good, to ensure best performance for enterprise + applications at all times, it would be beneficial to use Wi-Fi access + for both the uplink and downlink for connecting to enterprise + applications. However, in congested scenarios or when the user is + getting close to the edge of its Wi-Fi coverage area, the use of Wi- + Fi in the uplink by multiple users can lead to degraded capacity and + increased delays due to contention. In this case, it would be + beneficial to at least use the LTE access for increased uplink + coverage, while Wi-Fi may still continue to be used for the downlink. + +4. Requirements + + The requirements set out in this section define the behavior of the + MAMS mechanism and the related functional elements. + +4.1. Access-Technology-Agnostic Interworking + + The access nodes MAY use different technology types (LTE, Wi-Fi, + etc.). The framework, however, MUST be agnostic about the type of + underlying technology used by the access network. + +4.2. Support for Common Transport Deployments + + The network path selection and user data distribution MUST work + transparently across various transport deployments that include end- + to-end IPsec, VPNs, and middleboxes like NATs and proxies. + +4.3. Independent Access Path Selection for Uplink and Downlink + + A client SHOULD be able to transmit on the uplink and receive on the + downlink, using one or more access networks. The selections of the + access paths for the uplink and downlink SHOULD happen independently. + +4.4. Core Selection Independent of Uplink and Downlink Access + + A client SHOULD flexibly select the core independently of the access + paths used to reach the core, depending on the application's needs, + local policies, and the result of MAMS control-plane negotiation. + +4.5. Adaptive Access Network Path Selection + + The framework MUST have the ability to determine the quality of each + of the network paths, e.g., access link delay and capacity. This + information regarding network path quality needs to be considered in + the logic for the selection of the combination of network paths to be + used for transporting user data. The path selection algorithm can + use the information regarding network path quality, in addition to + other considerations like network policies, for optimizing network + usage and enhancing the Quality of Experience (QoE) delivered to the + user. + +4.6. Multipath Support and Aggregation of Access Link Capacities + + The framework MUST support the distribution and aggregation of user + data across multiple network paths at the IP layer. The client + SHOULD be able to leverage the combined capacity of the multiple + network connections by enabling the simultaneous transport of user + data over multiple network paths. If required, packet reordering + needs to be done at the receiver. The framework MUST allow the + flexibility to choose the flow-steering and aggregation protocols + based on capabilities supported by the client and the network user- + plane entities. The multiconnection aggregation solution MUST + support existing transport and network-layer protocols like TCP, UDP, + and GRE. The framework MUST allow the use and configuration of + existing aggregation protocols such as MPTCP and SCTP [RFC4960]. + +4.7. Scalable Mechanism Based on User-Plane Interworking + + 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 the solution easy to + deploy and scale when different networks are added and removed. + +4.8. Separate Control-Plane and User-Plane Functions + + The client MUST use the control-plane protocol to negotiate the + following with the network: (1) the choice of access and core network + paths for both the uplink and downlink, and (2) the user-plane + protocol treatment. The control plane MUST configure the actual + user-plane data distribution function per this negotiation. A common + control protocol SHOULD allow the creation of multiple user-plane + function instances with potentially different user-plane (e.g., + tunneling) protocol types. This enables maintaining a clear + separation between the control-plane and user-plane functions, + allowing the framework to be scalable and extensible, e.g., using + architectures and implementations based on Software-Defined + Networking (SDN). + +4.9. Lossless Path (Connection) Switching + + When switching data traffic from one path (connection) to another, + packets may be lost or delivered out of order; this will have + negative impact on the performance of higher-layer protocols, e.g., + TCP. The framework SHOULD provide the necessary mechanisms to ensure + in-order delivery at the receiver, e.g., during path switching. The + framework MUST NOT cause any packet loss beyond losses that access + network mobility functions may cause. + +4.10. Concatenation and Fragmentation for Adaptation to MTU Differences + + Different network paths may have different security and middlebox + (e.g., NAT) configurations. These configurations will lead to the + use of different tunneling protocols for the transport of data + between the network user-plane function and the client. As a result, + different effective payload sizes per network path are possible + (e.g., due to variable encapsulation header overheads). Hence, the + MAMS framework SHOULD support the fragmentation of a single payload + across MTU-sized IP packets to avoid IP packet fragmentation when + aggregating packets from different paths. Further, the concatenation + of multiple IP packets into a single IP packet to improve efficiency + in packing the MTU size SHOULD also be supported. + +4.11. Configuring Network Middleboxes Based on Negotiated Protocols + + The framework SHOULD enable the identification of optimal settings, + like radio link dormancy timers, binding expiry times, and supported + MTUs, based on parameters negotiated between the client and the + network, that may be used to configure middleboxes for efficient + operation of user-plane protocols, e.g., configuring a NAT with a + longer binding expiry time when UDP versus TCP is used. + +4.12. Policy-Based Optimal Path Selection + + The framework MUST support both the implementation of policies at the + client and guidance from the network for network path selection that + will address different application requirements. + +4.13. Access-Technology-Agnostic Control Signaling + + The control-plane signaling MUST NOT be dependent on the underlying + access technology procedures, i.e., it is carried transparently, like + application data, on the user plane. The MAMS framework SHOULD + support the delivery of control-plane signaling over existing + Internet protocols, e.g., TCP or UDP. + +4.14. Service Discovery and Reachability + + There can be multiple instances of the control-plane and user-plane + functional elements of the framework, either collocated or hosted on + separate network elements and reachable via any of the available + user-plane paths. The client MUST have the flexibility to choose the + appropriate control-plane instance in the network and use the + control-plane signaling to choose the desired user-plane functional + element instances. The client's choice can be based on + considerations such as, but not limited to, the quality of the link + through which the network function is reachable, client preferences, + preconfiguration, etc. + +5. Solution Principles + + This document describes the Multi-Access Management Services (MAMS) + framework for dynamic selection of a flexible combination of access + and core network paths for the uplink and downlink, as well as the + user-plane treatment for the traffic spread across the selected + links. The user-plane paths, and access and core network + connections, can be selected independently for the uplink and + downlink. For example, the network paths chosen for the uplink do + not apply any constraints on the choice of paths for the downlink. + The uplink and downlink network paths can be chosen based on the + application needs and on the characteristics and available resources + on different network connections. For example, a Wi-Fi connection + can be chosen for the downlink for transporting high-bandwidth data + from the network to the client, whereas an LTE connection can be + chosen to carry the low-bandwidth feedback to the application server. + + Also, depending on the characteristics of the access network link, + different processing would be needed on the user-plane packets on + different network paths. Encryption would be needed on a Wi-Fi link + to secure user-plane packets, but not on an LTE link. Tunneling + would be needed to ensure client and network end-point reachability + over NATs. Such differentiated user-plane treatment can be + accomplished by configuration of user plane-protocols (e.g., IPsec) + specific to each link. + + The MAMS framework consists of clearly separated control- and user- + plane functions in the network and the client. The control-plane + protocol allows the configuration of the user-plane protocols and + desired network paths for the transport of application traffic. The + control-plane messages are carried as user-plane data over any of the + available network paths between the peer control-plane functional + elements in the client and the network. Multiple user-plane paths + are dynamically distributed across multiple access networks and + aggregated in the network (by the N-MADP). The access network's + diversity is not exposed to the application servers, but is kept + within the scope of the elements defined in this framework. This + reduces the burden placed on application servers that would otherwise + have to react to access link changes caused by mobility events or + changing link characteristics. + + The selection of paths and user-plane treatment of the traffic is + based on (1) the negotiation of client and network capabilities, and + (2) link probing (i.e., checking the quality of links between the + user-plane functional elements at the client and the network). This + framework enables leveraging network intelligence to set up and + dynamically configure the best access network path combination based + on client and network capabilities, an application's needs, and + knowledge of the network state. + +6. MAMS Reference Architecture + + Figure 1 illustrates the MAMS architecture for the scenario where a + client is served by multiple (n) networks. It also introduces the + following functional elements: + + * The NCM and the CCM in the control plane. + + * The N-MADP and the C-MADP in the user plane. + + +--------------------------------------------------------+ + | +----------------+ +----------------+ | + | | | | | | + | |Core (IP anchor)| ..... |Core (IP anchor)| | + | |Network 1 | |Network "n" | | + | | | | | | + | +----------------+ +----------------+ | + | \ / | + | Anchor \ ...... Anchor | + | Connection 1 Connection "n" | + | \ / | + | +---------------+\+---+/+------+ | + | | +-----+ +----------+ | | + | +--------------| NCM | | N-MADP | | | + | | | +-----+ +----------+ | | + | | +------------------------------+ | + | | / \ | + | |Control-Plane Delivery ...... Delivery | + | |Path (over any Connection 1 Connection "n" | + | |access user plane) / \ | + | | / \ | + | | +------------------+ +---------------+ | + | | | Access | ...... | Access | | + | | | Network 1 | | Network "n" | | + | | +------------------+ +---------------+ | + +-----------------------------\----------------/---------+ + | \ / + | +----------\------------/-+ + | | +---+ \ +------+ / | + +--------------------+CCM| \|C-MADP|/ | + | +---+ +------+ | + | Client | + +-------------------------+ + + Figure 1: MAMS Reference Architecture + + The NCM is the functional element in the network that handles the + MAMS control-plane procedures. It configures the network (N-MADP) + and client (C-MADP) user-plane functions, such as negotiating with + the client for the use of available access network paths, protocols, + and rules for processing the user-plane traffic, as well as link- + monitoring procedures. The control-plane messages between the NCM + and the CCM are transported as an overlay on the user plane, without + any impact on the underlying access networks. + + The CCM is the peer functional element in the client for handling + MAMS control-plane procedures. It manages multiple network + connections at the client. The CCM exchanges MAMS signaling messages + with the NCM to support such functions as the configuration of the UL + and DL user network path for transporting user data packets and the + adaptive selection of network path by the NCM by reporting on the + results of link probing. In the downlink, for user data received by + the client, it configures the C-MADP such that application data + packets can be received over any access link so that the packets will + reach the appropriate application on the client. In the uplink, for + the data transmitted by the client, it configures the C-MADP to + determine the best access links to be used for uplink data based on a + combination of local and network policies delivered by the NCM. + + The N-MADP is the functional element in the network that handles the + forwarding of user data traffic across multiple network paths, as + well as other user-plane functionalities (e.g., encapsulation, + fragmentation, concatenation, reordering, retransmission). The + N-MADP is the distribution node that routes (1) the uplink user-plane + traffic to the appropriate anchor connection toward the core network, + and (2) the downlink user traffic to the client over the appropriate + delivery connections. In the downlink, the NCM configures the use of + delivery connections and user-plane protocols at the N-MADP for + transporting user data traffic. The N-MADP SHOULD implement ECMP + support for the downlink traffic. Alternatively, it MAY be connected + to a router with ECMP functionality. The load-balancing algorithm at + the N-MADP is configured by the NCM, based on static and/or dynamic + network policies like assigning access and core paths for a specific + user data traffic type, user-volume-based percentage distribution, + and link availability and feedback information from the exchange of + MAMS signaling messages with the CCM at the client. The N-MADP can + be configured with appropriate user-plane protocols to support both + per-flow and per-packet traffic distribution across the delivery + connections. In the uplink, the N-MADP selects the appropriate + anchor connection over which to forward the user data traffic + received from the client (via the delivery connections). The + forwarding rules in the uplink at the N-MADP are configured by the + NCM based on application requirements, e.g., enterprise-hosted + application flows via a Wi-Fi anchor or mobile-operator-hosted + applications via the cellular core. + + The C-MADP is the functional element in the client that handles the + MAMS user-plane data procedures. The C-MADP is configured by the + CCM, based on the signaling exchange with the NCM and local policies + at the client. The CCM configures the selection of delivery + connections and the user-plane protocols to be used for uplink user + data traffic based on the signaling messages exchanged with the NCM. + The C-MADP entity handles the forwarding of user-plane data across + multiple delivery connections and associated user-plane functions + (e.g., encapsulation, fragmentation, concatenation, reordering, + retransmissions). + + The NCM and N-MADP can be either collocated or instantiated on + different network nodes. The NCM can set up multiple N-MADP + instances in the network. The NCM controls the selection of the + N-MADP instance by the client and the rules for the distribution of + user traffic across the N-MADP instances. This is beneficial in + multiple deployment scenarios, like the following examples: + + * Different N-MADP instances to handle different sets of clients for + load balancing across clients. + + * Network topologies where the N-MADP is hosted at the user-plane + node at the access edge or in the core network, while the NCM is + hosted at the access edge node. + + * Access network technology architecture with an N-MADP instance at + the core network node to manage traffic distribution across LTE + and DSL networks, and an N-MADP instance at an access network node + to manage traffic distribution across LTE and Wi-Fi networks. + + * A single client can be configured to use multiple N-MADP + instances. This is beneficial in addressing different application + requirements. For example, separate N-MADP instances to handle + traffic that is based on TCP and UDP transport. + + Thus, the MAMS architecture flexibly addresses multiple network + deployments. + +7. MAMS Protocol Architecture + + This section describes the protocol structure for the MAMS user-plane + and control-plane functional elements. + +7.1. MAMS Control-Plane Protocol + + Figure 2 shows the default MAMS control-plane protocol stack. + WebSocket [RFC6455] is used for transporting management and control + messages between the NCM and the CCM. + + +------------------------------------------+ + | | + | Multi-Access (MX) Control Message | + | | + +------------------------------------------+ + | | + | WebSocket | + | | + +------------------------------------------+ + | | + | TCP/TLS | + | | + +------------------------------------------+ + + Figure 2: TCP-Based MAMS Control-Plane Protocol Stack + +7.2. MAMS User-Plane Protocol + + Figure 3 shows the MAMS user-plane protocol stack for transporting + the user payload, e.g., an IP Protocol Data Unit (PDU). + + +-----------------------------------------------------+ + | User Payload, e.g., IP Protocol Data Unit (PDU) | + +-----------------------------------------------------+ + + +-----------------------------------------------------------+ + | +-----------------------------------------------------+ | + | | Multi-Access (MX) Convergence Layer | | + | +-----------------------------------------------------+ | + | +-----------------------------------------------------+ | + | | MX Adaptation | MX Adaptation | MX Adaptation | | + | | Layer | Layer | Layer | | + | | (optional) | (optional) | (optional) | | + | +-----------------+-----------------+-----------------+ | + | | Access #1 IP | Access #2 IP | Access #3 IP | | + | +-----------------------------------------------------+ | + | MAMS User-Plane Protocol Stack | + +-----------------------------------------------------------+ + + Figure 3: MAMS User-Plane Protocol Stack + + The MAMS user-plane protocol consists of the following two layers: + + * Multi-Access (MX) Convergence Layer: The MAMS framework configures + the Convergence Layer to perform multi-access-specific tasks in + the user plane. This layer performs such functions as access + (path) selection, multi-link (path) aggregation, splitting/ + reordering, lossless switching, fragmentation, or concatenation. + The MX Convergence Layer can be implemented by using existing + user-plane protocols like MPTCP [RFC6824] or Multipath QUIC + (MPQUIC) [QUIC-MULTIPATH], or by adapting encapsulating header/ + trailer schemes such as GRE [RFC2784] [RFC2890] or Generic Multi- + Access (GMA) [INTAREA-GMA]. + + * Multi-Access (MX) Adaptation Layer: The MAMS framework configures + the Adaptation Layer to address transport-network-related aspects + such as reachability and security in the user plane. This layer + performs functions to handle tunneling, network-layer security, + and NAT. The MX Adaptation Layer can be implemented using IPsec, + DTLS [RFC6347], or a Client NAT (Source NAT at the client with + inverse mapping at the N-MADP [INTAREA-MAMS]). The MX Adaptation + Layer is OPTIONAL and can be independently configured for each of + the access links. For example, in a deployment with LTE (assumed + secure) and Wi-Fi (assumed to not be secure), the MX Adaptation + Layer can be omitted for the LTE link, but is configured with + IPsec to secure the Wi-Fi link. Further details on the MAMS user + plane are provided in [INTAREA-MAMS]. + +8. MAMS Control-Plane Procedures + +8.1. Overview + + The CCM and NCM exchange signaling messages to configure the user- + plane functions via the C-MADP and the N-MADP at the client and the + network, respectively. The means for the CCM to obtain the NCM + credentials (Fully Qualified Domain Name (FQDN) or IP address) for + sending the initial discovery messages are out of scope for this + document. As an example, the client can obtain the NCM credentials + by using such methods as provisioning or DNS queries. Once the + discovery process is successful, the (initial) NCM can update and + assign additional NCM addresses, e.g., based on Mobile Country Code + (MCC) / Mobile Network Code (MNC) tuple information received in the + MX Discover message, for sending subsequent control-plane messages. + + The CCM discovers and exchanges capabilities with the NCM. The NCM + provides the credentials of the N-MADP endpoint and negotiates the + parameters for the user plane with the CCM. The CCM configures the + C-MADP to set up the user-plane path (e.g., MPTCP/UDP Proxy + connection) with the N-MADP, based on the credentials (e.g., + (MPTCP/UDP) Proxy IP address and port, associated core network path), + and the parameters exchanged with the NCM. Further, the NCM and CCM + exchange link status information to adapt traffic steering and user- + plane treatment to dynamic network conditions. The key procedures + are described in detail in the following subsections. + + +-----+ +-----+ + | CCM | | NCM | + +--+--+ +--+--+ + | Discovery and | + | Capability | + | Exchange | + |<--------------------->| + | | + | Setup of | + | User-Plane | + | Protocols | + |<--------------------->| + | | + | Path Quality | + | Estimation | + |<--------------------->| + | | + | Network Capabilities | + | e.g., RNIS [ETSIRNIS] | + |<----------------------| + | | + | Network Policies | + |<----------------------| + + + + + "RNIS" stands for "Radio Network Information Service" + + Figure 4: MAMS Control-Plane Procedures + +8.2. Common Fields in MAMS Control Messages + + Each MAMS control message consists of the following common fields: + + * Version: Indicates the version of the MAMS control protocol. + + * Message Type: Indicates the type of the message, e.g., MX + Discover, MX Capability Request (REQ) / Response (RSP). + + * Sequence Number: Auto-incremented integer to uniquely identify a + particular message exchange, e.g., MX Capability Request/Response. + +8.3. Common Procedures for MAMS Control Messages + + This section describes the common procedures for MAMS control + messages. + +8.3.1. Message Timeout + + After sending a MAMS control message, the MAMS control-plane peer + (NCM or CCM) waits for a duration of MAMS_TIMEOUT ms before timing + out in cases where a response was expected. The sender of the + message will retransmit the message for MAMS_RETRY times before + declaring failure if no response is received. A failure implies that + the MAMS peer is dead or unreachable, and the sender reverts to + native non-multi-access / single-path mode. The CCM may initiate the + MAMS discovery procedure for re-establishing the MAMS session. + +8.3.2. Keep-Alive Procedure + + MAMS control-plane peers execute the keep-alive procedures to ensure + that the other peers are reachable and to recover from dead-peer + scenarios. Each MAMS control-plane endpoint maintains a Keep-Alive + timer that is set for a duration of MAMS_KEEP_ALIVE_TIMEOUT. The + Keep-Alive timer is reset whenever the peer receives a MAMS control + message. When the Keep-Alive timer expires, an MX Keep-Alive Request + is sent. + + The values for MAMS_RETRY and MAMS_KEEP_ALIVE_TIMEOUT parameters used + in keep-alive procedures are deployment dependent, and the means for + obtaining them are out of scope for this document. As an example, + the client and network can obtain the values using provisioning. On + receipt of an MX Keep-Alive Request, the receiver responds with an MX + Keep-Alive Response. If the sender does not receive a MAMS control + message in response to MAMS_RETRY retries of the MX Keep-Alive + Request, the MAMS peer declares that the peer is dead or unreachable. + The CCM MAY initiate the MAMS discovery procedure for re-establishing + the MAMS session. + + Additionally, the CCM SHALL immediately send an MX Keep-Alive Request + to the NCM whenever it detects a handover from one base station / + access point to another. During this time, the client SHALL stop + using MAMS user-plane functionality in the uplink direction until it + receives an MX Keep-Alive Response from the NCM. + + The MX Keep-Alive Request includes the following information: + + * Reason: Can be timeout or handover. Handover shall be used by the + CCM only on detection of a handover. + + * Unique Session ID: See Section 8.4. + + * Connection ID: If the reason is handover, the inclusion of this + field is mandatory. + + * Delivery Node ID: Identity of the node to which the client is + attached. In the case of LTE, this is an E-UTRAN Cell Global + Identifier (ECGI). In the case of Wi-Fi, this is an AP ID or a + Media Access Control (MAC) address. If the reason is "Handover", + the inclusion of this field is mandatory. + +8.4. Discovery and Capability Exchange + + Figure 5 shows the MAMS discovery and capability exchange procedure. + + CCM NCM + | | + |------- MX Discover Message ----------------------->| + | +-----------------+ + | | Learn CCM | + | | IP address | + | | and port | + | +-----------------+ + | | + |<----------------------------- MX System Info ------| + | | + |------------------------------ MX Capability REQ -->| + |<----- MX Capability RSP ---------------------------| + |------------------------------ MX Capability ACK -->| + | | + + + + + Figure 5: MAMS Control Procedure for Discovery and Capability + Exchange + + This procedure consists of the following key steps: + + Step 1 (discovery): The CCM periodically sends an MX Discover message + to a predefined (NCM) IP address/port until an MX System Info message + is received in acknowledgment. + + * The MX Discover message includes the following information: + + - MAMS Version. + + - Mobile Country Code (MCC) / Mobile Network Code (MNC) Tuple: + Optional parameter to identify the operator network to which + the client is subscribed, in conformance with the format + specified in [ITU-E212]. + + * The MX System Info message includes the following information: + + - Number of Anchor Connections. + + For each anchor connection, the following parameters are + included: + + o Connection ID: Unique identifier for the anchor connection. + + o Connection Type (e.g., Wi-Fi, 5G NR, MulteFire, LTE). + + o NCM Endpoint Address (for control-plane messages over this + connection): + + + IP Address or FQDN + + + Port Number + + Step 2 (capability exchange): The CCM learns the IP address and port + from the MX System Info message. It then sends the MX Capability REQ + message, which includes the following parameters: + + * MX Feature Activation List: Indicates whether the corresponding + feature is supported or not, e.g., lossless switching, + fragmentation, concatenation, uplink aggregation, downlink + aggregation, measurement, probing. + + * Number of Anchor Connections (core networks). + + For each anchor connection, the following parameters are included: + + - Connection ID + + - Connection Type (e.g., Wi-Fi, 5G NR, MulteFire, LTE) + + * Number of Delivery Connections (access links). + + For each delivery connection, the following parameters are + included: + + - Connection ID + + - Connection Type (e.g., Wi-Fi, 5G NR, MulteFire, LTE) + + * MX Convergence Method Support List: + + - GMA + + - MPTCP Proxy + + - GRE Aggregation Proxy + + - MPQUIC + + * MX Adaptation Method Support List: + + - UDP without DTLS + + - UDP with DTLS + + - IPsec [RFC3948] + + - Client NAT + + In response, the NCM creates a unique identity for the CCM session + and sends the MX Capability Response, including the following + information: + + * MX Feature Activation List: Indicates whether the corresponding + feature is enabled or not, e.g., lossless switching, + fragmentation, concatenation, uplink aggregation, downlink + aggregation, measurement, probing. + + * Number of Anchor Connections (core networks): + + For each anchor connection, the following parameters are included: + + - Connection ID + + - Connection Type (e.g., Wi-Fi, 5G NR, MulteFire, LTE) + + * Number of Delivery Connections (access links): + + For each delivery connection, the following parameters are + included: + + - Connection ID + + - Connection Type (e.g., Wi-Fi, 5G NR, MulteFire, LTE) + + * MX Convergence Method Support List: + + - GMA + + - MPTCP Proxy + + - GRE Aggregation Proxy + + - MPQUIC + + * MX Adaptation Method Support List: + + - UDP without DTLS + + - UDP with DTLS + + - IPsec [RFC3948] + + - Client NAT + + * Unique Session ID: Unique session identifier for the CCM that set + up the connection. If the session already exists, then the + existing unique session identifier is returned. + + - NCM ID: Unique identity of the NCM in the operator network. + + - Session ID: Unique identity assigned to the CCM instance by + this NCM instance. + + In response to the MX Capability Response, the CCM sends a + confirmation (or rejection) in the MX Capability Acknowledge. The MX + Capability Acknowledge includes the following parameters: + + * Unique Session ID: Same identifier as the identifier provided in + the MX Capability Response. + + * Acknowledgment: An indication of whether the client has accepted + or rejected the capability exchange phase. + + - MX ACCEPT: The CCM accepts the capability set proposed by the + NCM. + + - MX REJECT: The CCM rejects the capability set proposed by the + NCM. + + If the NCM receives an MX_REJECT, the current MAMS session will be + terminated. + + If the CCM can no longer continue with the current capabilities, it + SHOULD send an MX Session Termination Request to terminate the MAMS + session. In response, the NCM SHOULD send an MX Session Termination + Response to confirm the termination. + +8.5. User-Plane Configuration + + Figure 6 shows the user-plane (UP) configuration procedure. + + CCM NCM + | | + |---- MX Reconfiguration REQ (setup) ----------->| + |<-------------------- MX Reconfiguration RSP ---| + | +-------------------------+ + | | NCM prepares N-MADP for | + | | User-Plane Setup | + | +-------------------------+ + |<-------------------- MX UP Setup Config -------| + |---- MX UP Setup Confirmation ----------------->| + +-------------------+ | + |Link "X" is up/down| | + +-------------------+ | + |---- MX Reconfiguration REQ (update/release) -->| + |<-------------------- MX Reconfiguration RSP ---| + + Figure 6: MAMS Control Procedure for User-Plane Configuration + + This procedure consists of the following two key steps: + + * Reconfiguration: The CCM informs the NCM about the changes to the + client's connections - setup of a new connection, teardown of an + existing connection, or update of parameters related to an + existing connection. It consists of the client triggering the + procedure by requesting an update to the connection configuration, + and a response from the NCM. + + * UP Setup: The NCM configures the user-plane protocols at the + client and the network. The NCM initiates the UP setup by sending + the MX UP Setup Configuration Request to the client, which + confirms the set of mutually acceptable parameters by using the + User Plane Setup Confirmation (CNF) message. + + These steps are elaborated as follows. + + Reconfiguration: When the client detects that the link is up/down or + the IP address changes (e.g., via APIs provided by the client OS), + the CCM sends an MX Reconfiguration Request to set up, update, or + release the connection. The message SHOULD include the following + information: + + * Unique Session ID: Identity of the CCM at the NCM, created by the + NCM during the capability exchange phase. + + * Reconfiguration Action: Indicates the reconfiguration action + (release, setup, or update). + + * Connection ID: Identifies the connection for reconfiguration. + + If the Reconfiguration Action is set to "setup" or "update", then the + message includes the following parameters: + + * IP address of the connection. + + * SSID (Service Set Identifier of the Wi-Fi connection). + + * MTU of the connection: The MTU of the delivery path that is + calculated at the client for use by the NCM to configure + fragmentation and concatenation procedures [INTAREA-MAMS] at the + N-MADP. + + * Delivery Node ID: Identity of the node to which the client is + attached. In the case of LTE, this is an ECGI. In the case of + Wi-Fi, this is an AP ID or a MAC address. + + At the beginning of a connection setup, the CCM informs the NCM of + the connection status using the MX Reconfiguration Request with the + Reconfiguration Action set to "setup". The NCM acknowledges the + connection setup status and exchanges parameters with the CCM for + user-plane setup, as described below. + + Setup of User-Plane Protocols: Based on the negotiated capabilities, + the NCM sets up the user-plane (Adaptation Layer and Convergence + Layer) protocols at the N-MADP and informs the CCM of the user-plane + protocols to be set up at the client (C-MADP) and the parameters for + the C-MADP to connect to the N-MADP. + + The MX UP Setup Configuration Request is used to create one or more + MADP instances, with each anchor connection having one or more + configurations, namely MX Configurations. The MX UP Setup + Configuration Request consists of the following parameters: + + * Number of Anchor Connections (core networks). + + For each anchor connection, the following parameters are included: + + - Anchor Connection ID + + - Connection Type (e.g., Wi-Fi, 5G NR, MulteFire, LTE) + + - Number of Active MX Configurations (included only if more than + one MX configuration is active for the anchor connection). + + For each active MX configuration, the following parameters are + included: + + o MX Configuration ID (included if more than one MX + configuration is present) + + o MX Convergence Method. One of the following: + + + GMA + + + MPTCP Proxy + + + GRE Aggregation Proxy + + + MPQUIC + + o MX Convergence Method Parameters: + + + Convergence Proxy IP Address + + + Convergence Proxy Port + + + Client Key + + o MX Convergence Control Parameters (included if any MX + Control PDU types (e.g., Probe-REQ/ACK) are supported): + + + UDP port number for sending and receiving MX Control PDUs + (e.g., Probe-REQ/ACK, Keep-Alive) + + + Convergence Proxy Port + + o Number of Delivery Connections. + + For each delivery connection, include the following: + + + Delivery Connection ID + + + Connection Type (e.g., Wi-Fi, 5G NR, MulteFire, LTE) + + + MX Adaptation Method. One of the following: + + * UDP without DTLS + + * UDP with DTLS + + * IPsec + + * Client NAT + + + MX Adaptation Method Parameters: + + * Tunnel Endpoint IP Address + + * Tunnel Endpoint Port + + * Shared Secret + + * Header Optimization (included only if the MX + Convergence Method is GMA) + + For example, when LTE and Wi-Fi are the two user-plane accesses, the + NCM conveys to the CCM that IPsec needs to be set up as the MX + Adaptation Layer over the Wi-Fi access, using the following + parameters: IPsec endpoint IP address, and Pre-Shared Key. No + Adaptation Layer is needed if it is considered secure with no NAT, or + a Client NAT may be used over the LTE access. + + Similarly, as an example of the MX Convergence Method, the + configuration indicates the convergence method as the MPTCP proxy, + along with parameters for a connection to the MPTCP proxy: namely the + IP address and port of the MPTCP proxy for TCP applications. + + Once the user-plane protocols are configured, the CCM informs the NCM + of the status via the MX UP Setup Confirmation. The MX UP Setup + Confirmation consists of the following parameters: + + * Unique Session ID: Session identifier provided to the client in an + MX Capability Response. + + * MX Convergence Control Parameters (included if any MX Control PDU + types (e.g., Probe-REQ/ACK, Keep-Alive) are supported): + + - UDP port number for sending and receiving MX Control PDUs + (e.g., Probe-REQ/ACK, Keep-Alive) + + - MX Configuration ID (if an MX Configuration ID is specified in + an MX UP Setup Configuration Request) to indicate the MX + Configuration that will be used for probing) + + * Client Adaptation-Layer Parameters: + + - Number of Delivery Connections. + + For each delivery connection, include the following: + + o Delivery Connection ID + + o UDP port number: If UDP-based adaptation is in use, the UDP + port on the C-MADP side + +8.6. MAMS Path Quality Estimation + + Path quality estimations can be done either passively or actively. + Traffic measurements in the network can be performed passively by + comparing the real-time data throughput of the client with the + capacity available in the network. In special deployments where the + NCM has interfaces with access nodes, direct interfaces can be used + to gather information regarding path quality. For example, the + utilization of the LTE access node (also known as Evolved Node B), to + which the client is attached, could be used as data for the + estimation of path quality without creating any extra traffic + overhead. Active measurements by the client provide an alternative + way to estimate path quality. + + CCM NCM + | | + |<-------------- MX Path Estimation Request ---------| + |------ MX Path Estimation Results ----------------->| + | | + + Figure 7: MAMS Control-Plane Procedure for Path Quality Estimation + + The NCM sends the following configuration parameters in the MX Path + Estimation Request to the CCM: + + * Connection ID (of the delivery connection whose path quality needs + to be estimated) + + * Init Probe Test Duration (ms) + + * Init Probe Test Rate (Mbps) + + * Init Probe Size (bytes) + + * Init Probe-ACK Required (0 -> No / 1 -> Yes) + + * Active Probe Frequency (ms) + + * Active Probe Size (bytes) + + * Active Probe Test Duration (ms) + + * Active Probe-ACK Required (0 -> No / 1 -> Yes) + + The CCM configures the C-MADP for probe receipt based on these + parameters and for collection of the statistics according to the + following configuration. + + * Unique Session ID: Session identifier provided to the client in an + MX Capability Response. + + * Init Probe Results Configuration: + + - Lost Probes (percent) + + - Probe Receiving Rate (packets per second) + + * Active Probe Results Configuration: + + - Average Throughput in the last Probe Duration + + The user-plane probing is divided into two phases: the Initialization + phase and the Active phase. + + * Initialization Phase: A network path that is not included by the + N-MADP for transmission of user data is deemed to be in the + Initialization phase. The user data may be transmitted over other + available network paths. + + * Active Phase: A network path that is included by the N-MADP for + transmission of user data is deemed to be in the Active phase. + + During the Initialization phase, the NCM configures the N-MADP to + send an Init Probe-REQ message. The CCM collects the Init Probe + statistics from the C-MADP and sends the MX Path Estimation Results + message to the NCM per the Initialization Probe Results + configuration. + + During the Active phase, the NCM configures the N-MADP to send an + Active Probe-REQ message. The C-MADP calculates the metrics as + specified by the Active Probe Results configuration. The CCM + collects the Active Probe statistics from the C-MADP and sends the MX + Path Estimation Results message to the NCM per the Active Probe + Results configuration. + + The following subsections define the control PDU encoding for Keep- + Alive and Probe-REQ/ACK messages to support path quality estimation. + +8.6.1. MX Control PDU Definition + + Control PDUs are sent as UDP messages between the C-MADP and the + N-MADP to exchange control messages for keep-alive or path quality + estimation. MX probe parameters are negotiated during the user-plane + setup phase (MX UP Setup Configuration Request and MX UP Setup + Confirmation). Figure 8 shows the MX Control PDU format with the + following fields: + + * Type (1 byte): The type of the MX Control message. + + - 0: Keep-Alive + + - 1: Probe-REQ/ACK + + - Others: Reserved + + * CID (1 byte): The connection ID of the delivery connection for + sending the MX Control message. + + * MX Control Message (variable): The payload of the MX Control + message. + + The MX Control PDU is sent as a normal user-plane packet over the + desired delivery connection whose quality and reachability need to be + determined. + + + | | + |<--------- MX Control PDU Payload ------->| + | | + +-----------+-------------------+-----+-----------------------------+ + | IP Header | UDP Header | Type | CID | MX Control Message | + +-----------+-------------------+-----+-----------------------------+ + + Figure 8: MX Control PDU Format + +8.6.2. Keep-Alive Message + + The "Type" field is set to "0" for Keep-Alive messages. The C-MADP + may periodically send a Keep-Alive message over one or multiple + delivery connections, especially if UDP tunneling is used as the + adaptation method for the delivery connection with a NAT function on + the path. + + A Keep-Alive message is 2 bytes long and consists of the following + field: + + * Keep-Alive Sequence Number (2 bytes): The sequence number of the + Keep-Alive message. + +8.6.3. Probe-REQ/ACK Message + + The "Type" field is set to "1" for Probe-REQ/ACK messages. The + N-MADP may send the Probe-REQ message for path quality estimation. + In response, the C-MADP may return the Probe-ACK message. + + A Probe-REQ message consists of the following fields: + + * Probing Sequence Number (2 bytes): The sequence number of the + Probe REQ message. + + * Probing Flag (1 byte): + + - Bit 0: A Probe-ACK flag to indicate whether the Probe-ACK + message is expected (1) or not (0). + + - Bit 1: A Probe Type flag to indicate whether the Probe-REQ/ACK + message was sent during the Initialization phase (0) when the + network path is not included for transmission of user data, or + during the Active phase (1) when the network path is included + for transmission of user data. + + - Bit 2: A bit flag to indicate the presence of the Reverse + Connection ID (R-CID) field. + + - Bits 3-7: Reserved. + + * Reverse Connection ID (R-CID) (1 byte): The connection ID of the + delivery connection for sending the Probe-ACK message on the + reverse path. + + * Padding (variable). + + The "R-CID" field is only present if both Bit 0 and Bit 2 of the + "Probing Flag" field are set to "1". Moreover, Bit 2 of the "Probing + Flag" field SHOULD be set to "0" if Bit 0 is "0", indicating that the + Probe-ACK message is not expected. + + If the "R-CID" field is not present, but Bit 0 of the "Probing Flag" + field is set to "1", the Probe-ACK message SHOULD be sent over the + same delivery connection as the Probe-REQ message. + + The "Padding" field is used to control the length of the Probe-REQ + message. + + The C-MADP SHOULD send the Probe-ACK message in response to a Probe- + REQ message with the Probe-ACK flag set to "1". + + A Probe-ACK message is 3 bytes long and consists of the following + field: + + * Probing Acknowledgment Number (2 bytes): The sequence number of + the corresponding Probe-REQ message. + +8.7. MAMS Traffic Steering + + CCM NCM + | | + | +------------------------------+ + | |Steer user traffic to Path "X"| + | +------------------------------+ + |<----------------- MX Traffic Steering REQ ------| + |----- MX Traffic Steering RSP ------------------>| + + Figure 9: MAMS Traffic-Steering Procedure + + The NCM sends an MX Traffic Steering Request to steer data traffic. + It is also possible to send data traffic over multiple connections + simultaneously, i.e., aggregation. The message includes the + following information: + + * Anchor Connection ID: Connection ID of the anchor connection. + + * MX Configuration ID (if an MX Configuration ID is specified in an + MX UP Setup Configuration Request). + + * DL Connection ID List: List of DL delivery connections, provided + as Connection IDs. + + * UL Connection ID: Connection ID of the default UL delivery + connection. + + * For the number of specific UL traffic templates, the message + includes the following: + + - Traffic Flow Template for identifying the UL traffic. + + - UL Connection ID List: List of UL delivery connections, + provided as Connection IDs, to be used for sending the UL + traffic. + + * MX Feature Activation List. Each parameter indicates whether the + corresponding feature is enabled or not: lossless switching, + fragmentation, concatenation, uplink aggregation, downlink + aggregation, measurement, probing. + + In response, the CCM sends an MX Traffic Steering Response, including + the following information: + + * Unique Session ID: Session identifier provided to the client in an + MX Capability Response. + + * MX Feature Activation List. Each parameter indicates whether the + corresponding feature is enabled or not: lossless switching, + fragmentation, concatenation, uplink aggregation, downlink + aggregation, measurement, probing. + +8.8. MAMS Application MADP Association + + + CCM NCM + | | + | +-------------------------+ + | | Associate MADP instance | + | | with application flow | + | +-------------------------+ + |---------- MX App MADP ------------------->| + | Association REQ | + | | + |<----------------- MX App MADP ------------| + | Association RSP | + + Figure 10: MAMS Application MADP Association Procedure + + The CCM sends an MX Application MADP Association Request to request + the association of a specific application flow with a specific MADP + instance ID for the anchor connection with multiple active MX + configurations. The MADP Instance ID is a tuple (Anchor Connection + ID, MX Configuration ID). This provides the capability for the + client to indicate the user-plane processing that needs to be + associated with different application flows depending on the needs of + those flows. The application flow is identified by its associated + Traffic Flow Template. + + The MX Application MADP Association Request includes the following + information: + + * Number of Application Flows. + + For each application flow, identified by the Traffic Flow + Templates: + + - Anchor Connection ID + + - MX Configuration ID (if more than one MX configuration is + associated with an anchor connection) + + - Traffic Flow Template for identifying the UL traffic + + - Traffic Flow Template for identifying the DL traffic + + In response, the NCM sends an MX Application MADP Association + Response, including the following information: + + * Number of Application Flows. + + For each application flow, identified by the Traffic Flow + Templates: + + - Status (Success or Failure) + +8.9. MAMS Network ID Indication + + + CCM NCM + | | + | +---------------------------------+ + | |NCM determines preferred networks| + | +---------------------------------+ + | | + |<----------------- MX SSID Indication -----------| + | | + + Figure 11: MAMS Network ID Indication Procedure + + The NCM indicates the preferred network list to the CCM to guide the + client regarding networks that it should connect to. To indicate + preferred Wi-Fi networks, the NCM sends the list of WLANs, each + represented by an SSID (Service Set Identifier)/BSSID (Basic Service + Set Identifier)/HESSID (Homogeneous Extended Service Set Identifier) + as defined in [IEEE-80211]), available in the MX SSID Indication. + +8.10. MAMS Client Measurement Configuration and Reporting + + CCM NCM + | | + |<--------------- MX Measurement Config ----------| + | | + +---------------------------------+ | + |Client ready to send measurements| | + +---------------------------------+ | + | | + |----- MX Measurement Report -------------------->| + | | + + Figure 12: MAMS Client Measurement Configuration and Reporting + Procedure + + The NCM configures the CCM with the different parameters (e.g., radio + link information), with the associated thresholds to be reported by + the client. The MX Measurement Configuration message contains the + following parameters for each delivery connection: + + * Delivery Connection ID. + + * Connection Type (e.g., Wi-Fi, 5G NR, MulteFire, LTE). + + * If the connection type is Wi-Fi: + + - High and low thresholds for the sending of average Received + Signal Strength Indicator (RSSI) of the Wi-Fi link. + + - Periodicity, in ms, for sending the average RSSI of the Wi-Fi + link. + + - High and low thresholds for sending the loading of the WLAN + system. + + - Periodicity, in ms, for sending the loading of the WLAN system. + + - High and low thresholds for sending the reverse link throughput + on the Wi-Fi link. + + - Periodicity, in ms, for sending the reverse link throughput on + the Wi-Fi link. + + - High and low thresholds for sending the forward link throughput + on the Wi-Fi link. + + - Periodicity, in ms, for sending the forward link throughput on + the Wi-Fi link. + + - High and low thresholds for sending the reverse link throughput + (EstimatedThroughputOutbound as defined in [IEEE-80211]) on the + Wi-Fi link. + + - Periodicity, in ms, for sending the reverse link throughput + (EstimatedThroughputOutbound as defined in [IEEE-80211]) on the + Wi-Fi link. + + - High and low thresholds for sending the forward link throughput + (EstimatedThroughputInbound, as defined in [IEEE-80211]) on the + Wi-Fi link. + + - Periodicity, in ms, for sending the forward link throughput + (EstimatedThroughputInbound, as defined in [IEEE-80211]) on the + Wi-Fi link. + + * If the connection type is LTE: + + - High and low thresholds for sending the Reference Signal + Received Power (RSRP) of the serving LTE link. + + - Periodicity, in ms, for sending the RSRP of the serving LTE + link. + + - High and low thresholds for sending the RSRQ (Reference Signal + Received Quality) of the serving LTE link. + + - Periodicity, in ms, for sending the RSRP of the serving LTE + link. + + - High and low thresholds for sending the reverse link throughput + on the serving LTE link. + + - Periodicity, in ms, for sending the reverse link throughput on + the serving LTE link. + + - High and low thresholds, for sending the forward link + throughput on the serving LTE link. + + - Periodicity, in ms, for sending the forward link throughput on + the serving LTE link. + + * If the connection type is 5G NR: + + - High and low thresholds for sending the RSRP of the serving NR + link. + + - Periodicity, in ms, for sending the RSRP of the serving NR + link. + + - High and low thresholds for sending the RSRQ of the serving NR + link. + + - Periodicity, in ms, for sending the RSRP of the serving NR + link. + + - High and low thresholds for sending the reverse link throughput + on the serving NR link. + + - Periodicity, in ms, for sending the reverse link throughput on + the serving NR link. + + - High and low thresholds for sending the forward link throughput + on the serving NR link. + + - Periodicity, in ms, for sending the forward link throughput on + the serving NR link. + + The MX Measurement Report contains the following parameters: + + * Unique Session ID: Session identifier provided to the client in an + MX Capability Response. + + * For each delivery connection, include the following: + + - Delivery Connection ID + + - Connection Type (e.g., Wi-Fi, 5G NR, MulteFire, LTE) + + - Delivery Node ID (ECGI in the case of LTE. In the case of Wi- + Fi, this is an AP ID or a MAC address.) + + - If the connection type is Wi-Fi: + + o Average RSSI of the Wi-Fi link. + + o Loading of the WLAN system. + + o Reverse link throughput on the Wi-Fi link. + + o Forward link throughput on the Wi-Fi link. + + o Estimated reverse link throughput on the Wi-Fi link + (EstimatedThroughputOutbound as defined in [IEEE-80211]). + + o Estimated forward link throughput on the Wi-Fi link + (EstimatedThroughputInbound, as defined in [IEEE-80211]). + + - If the connection type is LTE: + + o RSRP of the serving LTE link. + + o RSRQ of the serving LTE link. + + o Reverse link throughput on the serving LTE link. + + o Forward link throughput on the serving LTE link. + + - If the connection type is 5G NR: + + o RSRP of the serving NR link. + + o RSRQ of the serving NR link. + + o Reverse link throughput on the serving NR link. + + o Forward link throughput on the serving NR link. + +8.11. MAMS Session Termination Procedure + + CCM NCM + | | + |---- MX Session Termination REQ --->| + | | + | | + |<--- MX Session Termination RSP ----| + | | + | +------------------+ + | | Remove Resources | + | +------------------+ + | | + + Figure 13: MAMS Session Termination Procedure - Initiated by Client + + CCM NCM + | | + |<--- MX Session Termination REQ ----| + | | + | | + |---- MX Session Termination RSP --->| + | | + +------------------+ | + | Remove Resources | | + +------------------+ | + | | + + Figure 14: MAMS Session Termination Procedure - Initiated by Network + + At any point in MAMS processing, if the CCM or NCM is no longer able + to support the MAMS functions, then either of them can initiate a + termination procedure by sending an MX Session Termination Request to + the peer. The peer SHALL acknowledge the termination by sending an + MX Session Termination Response message. After the session is + disconnected, the CCM SHALL start a new procedure with an MX Discover + message. An MX Session Termination Request shall contain a Unique + Session ID and the reason for the termination. Possible reasons for + termination are: + + * Normal Release + + * No Response from Peer + + * Internal Error + +8.12. MAMS Network Analytics Request Procedure + + CCM NCM + | | + |----- MX Network Analytics REQ --->| + | | + | | + |<--- MX Network Analytics RSP -----| + | | + + Figure 15: MAMS Network Analytics Request Procedure + + The CCM sends the MX Network Analytics Request to the NCM to request + information related to such network parameters as bandwidth, latency, + jitter, and signal quality, based on the application of analytics at + the network (utilizing the received path measurements and client + measurement reporting). + + The MX Network Analytics Request consists of the following + parameters: + + * Link Quality Indicators. One or more of the following: + + - Bandwidth + + - Jitter + + - Latency + + - Signal Quality + + The NCM sends the MX Network Analytics Response to convey analytics + information that might be of interest to the CCM. This message will + include network parameters with their predicted likelihoods. + + The MX Network Analytics Response consists of the following + parameters: + + * Number of Delivery Connections. + + For each delivery connection, include the following: + + - Access Link Identifier: + + o Connection Type + + o Connection ID + + - Link Quality Indicator: + + o Bandwidth: + + + Predicted Value (Mbps) + + + Likelihood (percent) + + + Prediction Validity (Validity Time, in seconds) + + o Jitter: + + + Predicted Value (in seconds) + + + Likelihood (percent) + + + Prediction Validity (Validity Time, in seconds) + + o Latency: + + + Predicted Value (in seconds) + + + Likelihood (percent) + + + Prediction Validity (Validity Time, in seconds) + + o Signal Quality: + + + If delivery connection type is LTE, LTE_RSRP Predicted + Value in decibel-milliwatts (dBm) + + + If delivery connection type is LTE, LTE_RSRQ Predicted + Value (dBm) + + + If delivery connection type is 5G NR, NR_RSRP Predicted + Value (dBm) + + + If delivery connection type is 5G NR, NR_RSRQ Predicted + Value (dBm) + + + If delivery connection type is Wi-Fi, WLAN_RSSI Predicted + Value (dBm) + + + Likelihood (percent) + + + Prediction Validity (Validity Time, in seconds) + +9. Generic MAMS Signaling Flow + + Figure 16 illustrates the MAMS signaling mechanism for negotiation of + network paths and flow protocols between the client and the network. + In this example scenario, the client is connected to two networks + (LTE and Wi-Fi). + + +--------------------------------------------+ + | MAMS-enabled Network of Networks | + | +-------+ +-------+ +-----+ +------+ | + +------------------+ | | | | | | | | | | + | Client | | |Network| |Network| | | | | | + | +------+ +-----+ | | | 1 | | 2 | | NCM | |N-MADP| | + | |C-MADP| | CCM | | | | (LTE) | |(Wi-Fi)| | | | | | + | +------+ +-----+ | | +-------+ +-------+ +-----+ +------+ | + | | | | | | | | | | + ++---+--------+----+ +-----+-----------+----------+----------+----+ + | | | | | | | + | | | | | | | + | | 1. Setup Connection | | | | + |<-----------+------------->| | | | + | | | | | | | + | | | 2. MAMS Capabilities Exchange | | + | | |<-------------+-----------+--------->| | + | | | | | | | + | | 3. Setup Connection | | | | + |<--+---------------------------------->| | | + | | | | | | | + | 4c. Config | 4a. Negotiate network paths, |4b. Config| + | | C-MADP | Flow protocol, and parameters | N-MADP| + | |<------>|<-------------+-----------+--------->|<-------->| + | | | | | | | + | | | 5. Establish user-plane path according | + | | | to selected flow protocol | | + | |<----------------------+-----------+-------------------->| + | | | | | | | + + + + + + + + + + Figure 16: MAMS Call Flow + + 1. The client connects to Network 1 and gets an IP address assigned + by Network 1. + + 2. The CCM communicates with the NCM functional element via the + Network 1 connection and exchanges capabilities and parameters + for MAMS operation. Note: The NCM credentials (e.g., the NCM's + IP address) can be made known to the client by provisioning. + + 3. The client sets up the connection with Network 2 and gets an IP + address assigned by Network 2. + + 4. The CCM and NCM negotiate capabilities and parameters for + establishing network paths. The negotiated capabilities and + parameters are then used to configure user-plane functions, i.e., + the N-MADP at the network and the C-MADP at the client. + + 4a. The CCM and NCM negotiate network paths, flow routing and + aggregation protocols, and related parameters. + + 4b. The NCM communicates with the N-MADP to exchange and + configure flow aggregation protocols, policies, and + parameters in alignment with those negotiated with the CCM. + + 4c. The CCM communicates with the C-MADP to exchange and + configure flow aggregation protocols, policies, and + parameters in alignment with those negotiated with the NCM. + + 5. The C-MADP and N-MADP establish the user-plane paths, e.g., using + Internet Key Exchange Protocol (IKE) [RFC7296] signaling, based + on the negotiated flow aggregation protocols and parameters + specified by the NCM. + + The CCM and NCM can further exchange messages containing access link + measurements for link maintenance by the NCM. The NCM evaluates the + link conditions in the UL and DL across LTE and Wi-Fi, based on link + measurements reported by the CCM and/or link-probing techniques, and + determines the policy for UL and DL user data distribution. The NCM + and CCM also negotiate application-level policies for categorizing + applications, e.g., based on the Differentiated Services Code Point + (DSCP), destination IP address, and determination of which available + network path needs to be used for transporting data of that category + of applications. The NCM configures the N-MADP, and the CCM + configures the C-MADP, based on the negotiated application policies. + The CCM may apply local application policies, in addition to the + application policy conveyed by the NCM. + +10. Relationship to IETF Technologies + + The MAMS framework leverages technologies developed in the IETF (such + as MPTCP and GRE) and enables a control-plane framework to negotiate + the use of these protocols between the client and the network. It + also addresses the limitations in scope of other multihoming + protocols. For example, the IKEv2 Mobility and Multihoming Protocol + (MOBIKE [RFC4555]) scope indicates that it is limited to multihoming + between IPsec clients (tunnel mode IPsec Security Associations) and + does not support load balancing. To address this limitation + regarding how the multihoming scenario is handled, the MAMS framework + supports load balancing with the simultaneous use of multiple access + paths by negotiating the use of protocols like MPTCP. Unlike MOBIKE, + which only applies to endpoints connected with an IPsec tunnel mode + Security Association, the MAMS framework allows the flexibility to + use a wide range of tunneling protocols in the Adaptation Layer. + +11. Applying MAMS Control Procedures with MPTCP Proxy as User Plane + + If the NCM determines that the N-MADP is to be instantiated with + MPTCP as the MX Convergence Protocol, it exchanges the MPTCP + capability support in the discovery and capability exchange + procedures. An MPTCP proxy (e.g., see [TCPM-CONVERTERS]) is + configured to be the N-MADP instance. The NCM then provides the + credentials of the MPTCP Proxy instance, along with related + parameters, to the CCM. The CCM configures the C-MADP with these + parameters to connect to this MPTCP proxy instance. + + Figure 17 illustrates the user-plane protocol layering when MPTCP is + configured to be the "MX Convergence Layer" protocol. MPTCP manages + traffic distribution and aggregation over multiple delivery + connections. + + + +-----------------------------------------------------+ + | MPTCP | + +-----------------+-----------------+-----------------+ + | TCP | TCP | TCP | + +-----------------------------------------------------+ + | MX Adaptation | MX Adaptation | MX Adaptation | + | Layer | Layer | Layer | + | (optional) | (optional) | (optional) | + +-----------------------------------------------------+ + | Access #1 IP | Access #2 IP | Access #3 IP | + +-----------------+-----------------+-----------------+ + + Figure 17: MAMS User-Plane Protocol Stack with MPTCP as MX + Convergence Layer + + The client (C-MADP) sets up an MPTCP connection with the N-MADP to + begin with. The MAMS control procedures are then applied to do the + following: + + * Connect to the appropriate MPTCP network endpoint, e.g., the MPTCP + proxy (illustrated in Figure 18). + + * Control the addition of a second TCP subflow after the Wi-Fi + connection is established and is deemed good (illustrated in + Figure 19). + + * Control the behavior of the MPTCP scheduler, e.g., by using only + the LTE subflow in the UL and both the LTE and Wi-Fi subflows in + the DL (illustrated in Figure 20). + + * Provide faster response to Wi-Fi link degradation by proactively + deleting a TCP subflow over Wi-Fi when poor link conditions are + reported, maintaining optimum performance (illustrated in + Figure 21). + + Figure 18 shows the call flow describing MAMS control procedures + applied to configure the user plane and dynamic optimal path + selection in a scenario with the MPTCP proxy as the convergence + protocol in the user plane. + + + +------+ +--------+ +--------+ +-------+ +-------+ +------+ + | | | | | | | | | | | | + | CCM | | C-MADP | | Wi-Fi | | LTE | | NCM | |N-MADP| + | | | | | N/W | | N/W | | | | | + +------+ +--------+ +--------+ +-------+ +-------+ +------+ + +------------------------------------------------------------------+ + | 1. LTE Session Setup and IP Address Allocation | + +-----------------------------------------+-----------+------------+ + | | | | + |2. MX Discover (MAMS Version, MCC/MNC) | | | + +----------------------------------------+---------->| | + |3. MX System Info (Serving NCM IP/Port Address) | | + |<------------+-------------+-------------+----------+ | + | | | | | | + |4. MX Capability REQ (Supported Anchor/Delivery | | + | | Links (Wi-Fi, LTE)) | | + +--------------------------------------------------->| | + |5. MX Capability RSP (Convergence/Adaptation Parameters) | + |<----------------------------------------+----------+ | + |6. MX Capability ACK (ACCEPT) | | | + +-------------+-------------+----------------------->| | + | | | | | | + |7. MX Meas Config (Wi-Fi/LTE Measurement Thresholds/Period) | + |<---------------------------------------------------+ | + |8. MX Meas Report (LTE RSRP, UL/DL TPUT) | | | + +-----------------------------------------+--------->| | + |9. MX SSID Indication (List of SSIDs) | | | + |<------------+-------------+------------------------+ | + | | | | | | + |10. MX Reconfiguration REQ (LTE IP) | | | + +--------------------------------------------------->| | + |11. MX Reconfiguration RSP | | | + |<----------------------------------------+----------+ | + |12. MX UP Setup REQ (MPTCP proxy IP/Port, Aggregation) | + |<--------------------------+-------------+----------+ | + |13. MX UP Setup RSP | | | | + +-------------+-------------+-------------+--------->| | + | | 14. MPTCP connection with designated | | + | | MPTCP proxy over LTE | | + | +-------------+-------------+----------+------->| + | | | | | | + + + + + + + + + Figure 18: MAMS-Assisted MPTCP Proxy as User Plane - Initial + Setup with LTE Leg + + The salient steps described in the call flow are as follows. The + client connects to the LTE network and obtains an IP address (assume + that LTE is the first connection). It then initiates the NCM + discovery procedures and exchanges capabilities, including the + support for MPTCP as the convergence protocol at both the network and + the client. + + The CCM provides the LTE connection parameters to the NCM. The NCM + provides the parameters like MPTCP proxy IP address/port, and MPTCP + Client Key for configuring the Convergence Layer. This is useful if + the N-MADP is reachable, via a different IP address or/and port, from + different access networks. The current MPTCP signaling can't + identify or differentiate the MPTCP proxy IP address and port from + multiple access networks. The client uses the MPTCP Client Key + during the subflow creation, and this enables the N-MADP to uniquely + identify the client, even if a NAT is present. The N-MADP can then + inform the NCM of the subflow creation and parameters related to + creating additional subflows. Since LTE is the only connection, the + user-plane traffic flows over the single TCP subflow over the LTE + connection. Optionally, the NCM provides assistance information to + the client on the neighboring/preferred Wi-Fi networks that it can + associate with. + + Figure 19 describes the steps where the client establishes a Wi-Fi + connection. The CCM informs the NCM of the Wi-Fi connection, along + with such parameters as the Wi-Fi IP address or the SSID. The NCM + determines that the Wi-Fi connection needs to be secured, configures + the Adaptation Layer to use IPsec, and provides the required + parameters to the CCM. In addition, the NCM provides the information + for configuring the Convergence Layer (e.g., MPTCP proxy IP address) + and provides the MX Traffic Steering Request to indicate that the + client SHOULD use only the LTE access. The NCM may do this, for + example, on determining from the measurements that the Wi-Fi link is + not consistently good enough. As the Wi-Fi link conditions improve, + the NCM sends an MX Traffic Steering Request to use Wi-Fi access as + well. This triggers the client to establish the TCP subflow over the + Wi-Fi link with the MPTCP proxy. + + +------+ +--------+ +--------+ +-------+ +-------+ +------+ + | | | | | | | | | | | | + | CCM | | C-MADP | | Wi-Fi | | LTE | | NCM | |N-MADP| + | | | | | N/W | | N/W | | | | | + +------+ +--------+ +--------+ +-------+ +-------+ +------+ + +-------------------------------------------------------------------+ + | Traffic over LTE in UL and DL over MPTCP Connection | + +-------------------------------------------------------------------+ + +-------------------------------------------------------------------+ + | Wi-Fi Connection Establishment and IP Address Allocation | + +----------------------------------------------------------------+--+ + | | | | | | + |15. MX Reconfiguration REQ (Wi-Fi IP) | | | + +--------------------------------------------------->| | + |16. MX Reconfiguration RSP | | | + |<----------------------------------------+----------+ | + |17. MX UP Setup REQ (MPTCP proxy IP/Port, Aggregation) | + |<--------------------------+-------------+----------+ | + |18. MX UP Setup RSP | | | | + +-------------+-------------+-------------+--------->| | + | |19. IPsec Tunnel Establishment over Wi-Fi Path | + | |<-------------------------------------+-------->| + | | | | | | + |20. MX Meas Report (Wi-Fi RSSI, | | | + | LTE RSRP, UL/DL TPUT) | |+------------+ + +-------------+-------------+-------------+--------->||Wait for | + | | | | ||good reports| + | | | | |+------------+ + |21. MX Traffic Steering REQ (UL/DL access, | | + | Traffic Flow Templates (TFTs)) | +----------+ + |<----------------------------------------+----------+ |Allow use | + | | | | of | + |22. MX Traffic Steering RSP (...) | | |Wi-Fi link| + +-------------+-------------+----------------------->| +----------+ + | | | | | | + | | 23. Add TCP subflow to the MPTCP connection | + | | over Wi-Fi link (IPsec Tunnel) | + | |<---------------------------------------------->| + | | | | | | + +----------------------------------------------------------------+ + || Aggregated Wi-Fi and LTE capacity for UL and DL || + +----------------------------------------------------------------+ + | | + | | + + Figure 19: MAMS-Assisted MPTCP Proxy as User Plane - Add Wi-Fi Leg + + Figure 20 describes the steps where the client reports that Wi-Fi + link conditions degrade in UL. The MAMS control plane is used to + continuously monitor the access link conditions on Wi-Fi and LTE + connections. The NCM may at some point determine an increase in UL + traffic on the Wi-Fi network, and trigger the client to use only LTE + in the UL via a MX Traffic Steering Request to improve UL + performance. + + + +------+ +--------+ +--------+ +-------+ +-------+ +------+ + | | | | | | | | | | | | + | CCM | | C-MADP | | Wi-Fi | | LTE | | NCM | |N-MADP| + | | | | | N/W | | N/W | | | | | + +------+ +--------+ +--------+ +-------+ +-------+ +------+ + +-------------------------------------------------------------------+ + | Traffic over LTE and Wi-Fi in UL And DL over MPTCP | + ++------------+-------------+-------------+------------+--------+---+ + | | | | | | + |24. MX Meas Report (Wi-Fi RSSI, LTE RSRP, UL/DL TPUT)| +------+---+ + +------------+-------------+-------------+----------->| |Reports of| + | | | | | |bad Wi-Fi | + | | | | | |UL tput | + | | | | | +----------+ + |25. MX Traffic Steering REQ (UL/DL Access, TFTs) | +----------+ + |<---------------------------------------+------------+ |Disallow | + | | | | | |use of | + |26. MX Traffic Steering RSP (...) | | |Wi-Fi UL | + |------------+-------------+------------------------->| +------+---+ + | | | | | | + ++------------+-------------+-------------+------------+--------+---+ + | UL data to use TCP subflow over LTE link only, | + | aggregated Wi-Fi+LTE capacity for DL | + ++------------+-------------+-------------+------------+--------+---+ + | | | | | | + + + + + + + + + Figure 20: MAMS-Assisted MPTCP Proxy as User Plane - Wi-Fi UL + Degrades + + Figure 21 describes the steps where the client reports that Wi-Fi + link conditions have degraded in both the UL and DL. As the Wi-Fi + link conditions deteriorate further, the NCM may decide to send a MX + Traffic Steering Request that instructs the client to stop using Wi- + Fi and to use only the LTE access in both the UL and DL. This + condition may be maintained until the NCM determines, based on + reported measurements, that the Wi-Fi link has again become usable. + + + +------+ +--------+ +--------+ +-------+ +-------+ +------+ + | | | | | | | | | | | | + | CCM | | C-MADP | | Wi-Fi | | LTE | | NCM | |N-MADP| + | | | | | N/W | | N/W | | | | | + +------+ +--------+ +--------+ +-------+ +-------+ +------+ + +------------------------------------------------------------------+ + | UL data to use TCP subflow over LTE link only, | + | aggregated Wi-Fi+LTE capacity for DL | + ++------------+-------------+-------------+----------+---------+---+ + | | | | | | + | | | | | | + |27. MX Meas Report (Wi-Fi RSSI, | | | + | LTE RSRP, UL/DL TPUT) | | +-------+----+ + +------------+-------------+-------------+--------->| | Reports of | + | | | | | | bad Wi-Fi | + | | | | | | UL/DL tput | + | | | | | +------------+ + |28. MX Traffic Steering REQ (UL/DL Access, TFTs) | +------------+ + |<---------------------------------------+----------+ | Disallow | + | | | | | | use of | + |29. MX Traffic Steering RSP (...) | | | Wi-Fi | + +----------------------------------------+--------->| +------------+ + | |30. Delete TCP subflow from MPTCP | | + | | connection over Wi-Fi link | | + | |<---------------------------------------------->| + | | | | | | + +--------------------------------------------------------------+ + || Traffic over LTE link only for DL and UL | + || (until client reports better Wi-Fi link conditions) | + +--------------------------------------------------------------+ + | | | | | | + + + + + + + + + Figure 21: MAMS-Assisted MPTCP Proxy as User Plane - Part 4 + +12. Applying MAMS Control Procedures for Network-Assisted Traffic + Steering When There Is No Convergence Layer + + Figure 22 shows the call flow describing MAMS control procedures + applied for dynamic optimal path selection in a scenario where + Convergence and Adaptation Layer protocols are omitted. This + scenario indicates the applicability of a solution for only the MAMS + control plane. + + In the capability exchange messages, the NCM and CCM negotiate that + Convergence-Layer and Adaptation-Layer protocols are not needed (or + supported). The CCM informs the NCM of the availability of the LTE + and Wi-Fi links. The NCM dynamically determines the access links + (Wi-Fi or LTE) to be used based on the reported measurements of link + quality. + + + +------+ +--------+ +--------+ +-------+ +-------+ +------+ + | | | | | | | | | | | | + | CCM | | C-MADP | | Wi-Fi | | LTE | | NCM | |N-MADP| + | | | | | N/W | | N/W | | | | | + +------+ +--------+ +--------+ +-------+ +-------+ +------+ + +------------------------------------------------------------------+ + | 1. LTE Session Setup and IP Address Allocation | + +---------------------------------------+-------------+----------+-+ + |2. MX Discover (MAMS Version, MCC/MNC ) | | + +--------------------------------------+------------>| | + |3. MX System Info (Serving NCM IP/Port address) | | + |<------------+-------------+----------+-------------| | + | | | | | | + |4. MX Capability REQ (Supported | | | + | Anchor/Delivery Links (Wi-Fi, LTE))| | | + +--------------------------------------------------->| | + |5. MX Capability RSP (No Convergence/Adaptation parameters) | + |<-------------------------------------+-------------+ | + |6. MX Capability ACK (ACCEPT) | | | + +-------------+-------------+----------------------->| | + | | | | | | + |7. MX Meas Config (Wi-Fi/LTE Measurement Thresholds/Period) | + |<---------------------------------------------------| | + |8. MX Meas Report (LTE RSRP, UL/DL TPUT) | | + |--------------------------------------+------------>| | + |9. MX SSID Ind (List of SSIDs) | | | + |<---------------------------------------------------| | + +-----------------------------------------------------------------++ + | 10. Wi-Fi Connection Setup and IP Address Allocation | + +-+-------------+-------------+----------+-------------+----------++ + | | | | | | + |11. MX Reconfiguration REQ (LTE IP, Wi-Fi IP) | | + |--------------------------------------+------------>| | + |12. MX Reconfiguration RSP | | | + |<---------------------------------------------------| | + +-----------------------------------------------------------------++ + | Initial Condition, Data over LTE link only, Wi-Fi link is poor | + +------------------------------------------------------+----------++ + | | | | | | + |13. MX Meas Report (Wi-Fi RSSI, | | | + | LTE RSRP, UL/DL TPUT)| | |+----------+ + |--------------------------------------------------->||Wi-Fi link| + | | | | ||conditions| + | | | | ||reported | + | | | | ||good | + | | | | |+----------+ + | | | | | | + |14. MX Traffic Steering REQ (UL/DL Access, TFTs) |+----------+ + |<------------+-------------+----------+-------------||Steer | + | | | | ||traffic to| + |15. MX Traffic Steering RSP (...) | ||use Wi-Fi | + |<------------+-------------+----------+-------------||link | + | | | | |+----------+ + | | | | | | + +-----------------------------------------------------------------++ + | Use Wi-Fi link for Data | + +------------------------------------------------------+----------++ + | | | | | | + + + + + + + + + Figure 22: MAMS with No Convergence Layer + +13. Coexistence of MX Adaptation and MX Convergence Layers + + The MAMS user plane supports multiple instances and combinations of + protocols to be used at the MX Adaptation and the Convergence Layer. + + For example, one instance of the MX Convergence Layer can be MPTCP + Proxy and another instance can be GMA. The MX Adaptation for each + can be either a UDP tunnel or IPsec. IPsec may be set up when the + network path needs to be secured, e.g., to protect the TCP subflow + traversing the network path between the client and the MPTCP proxy. + + Each instance of the MAMS user plane, i.e., the combination of MX + Convergence-Layer and MX Adaptation-Layer protocols, can coexist + simultaneously and independently handle different traffic types. + +14. Security Considerations + +14.1. MAMS Control-Plane Security + + The NCM functional element is hosted on a network node that is + assumed to be within a secure network, e.g., within the operator's + network, and is assumed to be protected against hijack attacks. + + For deployment scenarios where the client is configured (e.g., by the + network operator) to use a specific network path for exchanging + control-plane messages, and if the network path is assumed to be + secure, MAMS control messages will rely on security provided by the + underlying network. + + For deployment scenarios where the security of the network path + cannot be assumed, NCM and CCM implementations MUST support the "wss" + URI scheme [RFC6455] and Transport Layer Security (TLS) [RFC8446] to + secure the exchange of control-plane messages between the NCM and the + CCM. + + For deployment scenarios where client authentication is desired, the + WebSocket server can use any client authentication mechanisms + available to a generic HTTP server, such as cookies, HTTP + authentication, or TLS authentication. + +14.2. MAMS User-Plane Security + + User data in the MAMS framework relies on the security of the + underlying network transport paths. When this security cannot be + assumed, the NCM configures the use of protocols (e.g., IPsec + [RFC4301] [RFC3948]) in the MX Adaptation Layer, for security. + +15. Implementation Considerations + + The MAMS architecture builds on commonly available functions in + clients that can be used to deliver software updates over popular + client operating systems, thereby enabling rapid deployment and + addressing the large base of deployed clients. + +16. Applicability to Multi-Access Edge Computing + + Multi-access Edge Computing (MEC), previously known as Mobile Edge + Computing, is an access-edge cloud platform being considered at the + European Telecommunications Standards Institute (ETSI) [ETSIMEC], + whose initial focus was to improve the QoE by leveraging intelligence + at the cellular (e.g., 3GPP technologies like LTE) access edge, and + the scope is now being extended to support access technologies beyond + 3GPP. The applicability of the framework described in this document + to the MEC platform has been evaluated and tested in different + network configurations by the authors. + + The NCM can be hosted on a MEC cloud server that is located in the + user-plane path at the edge of the multi-technology access network. + The NCM and CCM can negotiate the network path combinations based on + an application's needs and the necessary user-plane protocols to be + used across the multiple paths. The network conditions reported by + the CCM to the NCM can be complemented by a Radio Analytics + application [ETSIRNIS] residing at the MEC cloud server to configure + the uplink and downlink access paths according to changing radio and + congestion conditions. + + The user-plane functional element, N-MADP, can either be collocated + with the NCM at the MEC cloud server (e.g., MEC-hosted applications) + or placed at a separate network element like a common user-plane + gateway across the multiple networks. + + Also, even in scenarios where an N-MADP is not deployed, the NCM can + be used to augment the traffic-steering decisions at the client. + + The aim of these enhancements is to improve the end user's QoE by + leveraging the best network path based on an application's needs and + network conditions, and building on the advantages of significantly + reduced latency and the dynamic and real-time exposure of radio + network information available at the MEC. + +17. Related Work in Other Industry and Standards Forums + + The MAMS framework described in this document has been incorporated + or is proposed for incorporation as a solution to address multi- + access integration in multiple industry forums and standards. This + section describes the related work in other industry forums and the + standards organizations. + + Wireless Broadband Alliance industry partners have published a white + paper that describes the applicability of different technologies for + multi-access integration to different deployments as part of their + "Unlicensed Integration with 5G Networks" project [WBAUnl5G]. The + white paper includes the MAMS framework described in this document as + a technology for integrating unlicensed (Wi-Fi) networks with 5G + networks above the 5G core network. + + The 3GPP is developing a technical report as part of its work item + Study on Access Traffic Steering, Switching, and Splitting (ATSSS). + That report, TR 23.793 [ATSSS], contains a number of potential + solutions; Solution 1 in [ATSSS] utilizes a separate control plane + for the flexible negotiation of user-plane protocols and path + measurements in a way that is similar to the MAMS architecture + described in this document. + + The Small Cell Forum (SCF) [SCFTECH5G] plans to develop a white paper + as part of its work item on LTE/5G and Wi-Fi. There is a proposal to + include MAMS in this white paper. + + The ETSI Multi-access Edge Computing Phase 2 technical work is + examining many aspects of this work, including use cases for + optimizing QoE and resource utilization. The MAMS architecture and + procedures outlined in this document are included in the ETSI's use + cases and requirements document [ETSIMAMS]. + +18. IANA Considerations + + This document has no IANA actions. + +19. References + +19.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, + December 2005, <https://www.rfc-editor.org/info/rfc4301>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +19.2. Informative References + + [ANDSF] 3rd Generation Partnership Project, "Access Network + Discovery and Selection Function (ANDSF) Management Object + (MO)", 3GPP TS 24.312 version 15.0.0, Technical + Specification Group Core Network and Terminals, June 2018, + <https://www.3gpp.org/ftp//Specs/ + archive/24_series/24.312/24312-f00.zip>. + + [ATSSS] 3rd Generation Partnership Project, "Study on access + traffic steering, switch and splitting support in the 5G + System (5GS) architecture", Work in Progress, 3GPP TR + 23.793 v16.0.0, December 2018, + <https://www.3gpp.org/ftp/Specs/ + archive/23_series/23.793/>. + + [ETSIMAMS] European Telecommunications Standards Institute, "Multi- + access Edge Computing (MEC); Phase 2: Use Cases and + Requirements", ETSI GS MEC 002 v2.1.1, October 2018, + <https://www.etsi.org/deliver/etsi_gs/ + MEC/001_099/002/02.01.01_60/gs_MEC002v020101p.pdf>. + + [ETSIMEC] European Telecommunications Standards Institute, "Multi- + access Edge Computing (MEC)", + <https://www.etsi.org/technologies/multi-access-edge- + computing>. + + [ETSIRNIS] European Telecommunications Standards Institute, "Mobile + Edge Computing (MEC) Radio Network Information API", ETSI + GS MEC 012 v1.1.1, July 2017, + <https://www.etsi.org/deliver/etsi_gs/ + MEC/001_099/012/01.01.01_60/gs_MEC012v010101p.pdf>. + + [IEEE-80211] + IEEE, "IEEE Standard for Information technology- + Telecommunications and information exchange between + systems - Local and metropolitan area networks-Specific + requirements - Part 11: Wireless LAN Medium Access Control + (MAC) and Physical Layer (PHY) Specifications", + IEEE 802.11-2016, + <https://ieeexplore.ieee.org/document/7786995>. + + [INTAREA-GMA] + Zhu, J. and S. Kanugovi, "Generic Multi-Access (GMA) + Convergence Encapsulation Protocols", Work in Progress, + Internet-Draft, draft-zhu-intarea-gma-05, 16 December + 2019, + <https://tools.ietf.org/html/draft-zhu-intarea-gma-05>. + + [INTAREA-MAMS] + Zhu, J., Seo, S., Kanugovi, S., and S. Peng, "User-Plane + Protocols for Multiple Access Management Service", Work in + Progress, Internet-Draft, draft-zhu-intarea-mams-user- + protocol-09, 4 March 2020, <https://tools.ietf.org/html/ + draft-zhu-intarea-mams-user-protocol-09>. + + [ITU-E212] International Telecommunication Union, "The international + identification plan for public networks and + subscriptions", ITU-T Recommendation E.212, September + 2016, <https://www.itu.int/rec/T-REC-E.212-201609-I/en>. + + [QUIC-MULTIPATH] + Coninck, Q. and O. Bonaventure, "Multipath Extensions for + QUIC (MP-QUIC)", Work in Progress, Internet-Draft, draft- + deconinck-quic-multipath-04, 5 March 2020, + <https://tools.ietf.org/html/draft-deconinck-quic- + multipath-04>. + + [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. + Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, + DOI 10.17487/RFC2784, March 2000, + <https://www.rfc-editor.org/info/rfc2784>. + + [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", + RFC 2890, DOI 10.17487/RFC2890, September 2000, + <https://www.rfc-editor.org/info/rfc2890>. + + [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. + Stenberg, "UDP Encapsulation of IPsec ESP Packets", + RFC 3948, DOI 10.17487/RFC3948, January 2005, + <https://www.rfc-editor.org/info/rfc3948>. + + [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol + (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, + <https://www.rfc-editor.org/info/rfc4555>. + + [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", + RFC 4960, DOI 10.17487/RFC4960, September 2007, + <https://www.rfc-editor.org/info/rfc4960>. + + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, + January 2012, <https://www.rfc-editor.org/info/rfc6347>. + + [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", + RFC 6455, DOI 10.17487/RFC6455, December 2011, + <https://www.rfc-editor.org/info/rfc6455>. + + [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, + "TCP Extensions for Multipath Operation with Multiple + Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, + <https://www.rfc-editor.org/info/rfc6824>. + + [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Semantics and Content", RFC 7231, + DOI 10.17487/RFC7231, June 2014, + <https://www.rfc-editor.org/info/rfc7231>. + + [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. + Kivinen, "Internet Key Exchange Protocol Version 2 + (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October + 2014, <https://www.rfc-editor.org/info/rfc7296>. + + [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data + Interchange Format", STD 90, RFC 8259, + DOI 10.17487/RFC8259, December 2017, + <https://www.rfc-editor.org/info/rfc8259>. + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + <https://www.rfc-editor.org/info/rfc8446>. + + [SCFTECH5G] + Small Cell Forum, "Small Cell Forum", <https://scf.io/>. + + [ServDesc3GPP] + 3rd Generation Partnership Project, "General Packet Radio + Service (GPRS); Service description; Stage 2", 3GPP TS + 23.060 version 16.0.0, Technical Specification Group + Services and System Aspects, March 2019, + <https://www.3gpp.org/ftp/Specs/ + archive/23_series/23.060/23060-g00.zip>. + + [TCPM-CONVERTERS] + Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S., + and B. Hesmans, "0-RTT TCP Convert Protocol", Work in + Progress, Internet-Draft, draft-ietf-tcpm-converters-19, + 22 March 2020, <https://tools.ietf.org/html/draft-ietf- + tcpm-converters-19>. + + [WBAUnl5G] Wireless Broadband Alliance, "Unlicensed Integration with + 5G Networks", <https://wballiance.com/resource/unlicensed- + integration-with-5g-networks/>. + +Appendix A. MAMS Control-Plane Optimization over Secure Connections + + This appendix is informative, and provides indicative information + about how MAMS operates. + + If the connection between the CCM and the NCM over which the MAMS + control-plane messages are transported is assumed to be secure, UDP + is used as the transport for management and control messages between + the NCM and the CCM (see Figure 23). + + + +-------------------------------------------------+ + | Multi-Access (MX) Control Message | + |-------------------------------------------------| + | UDP | + |-------------------------------------------------| + + Figure 23: UDP-Based MAMS Control-Plane Protocol Stack + +Appendix B. MAMS Application Interface + + This appendix describes the MAMS Application Interface. It does not + provide normative text for the definition of the MAMS framework or + protocols, but offers additional information that may be used to + construct a system based on the MAMS framework. + +B.1. Overall Design + + The CCM hosts an HTTPS server for applications to communicate and + request services. This document assumes, from a security point of + view, that all CCMs and the communicating application instances are + hosted in a single administrative domain. + + The content of messages is described in JavaScript Object Notation + (JSON) format. They offer RESTful APIs for communication. + + The exact mechanism regarding how the application knows about the + endpoint of the CCM is out of scope for this document. This + mechanism may instead be provided as part of the application + settings. + +B.2. Notation + + The documentation of APIs is provided in the OpenAPI format, using + Swagger v2.0. See Appendix D. + +B.3. Error Indication + + For every API, there could be an error response if the objective of + the API could not be met; see [RFC7231]. + +B.4. CCM APIs + + The following subsections describe the APIs exposed by the CCM to the + applications. + +B.4.1. GET Capabilities + + The CCM provides an HTTPS GET interface as "/ccm/v1.0/capabilities" + for the application to query the capabilities supported by the CCM + instance. + + + +---------+ +-----------+ + | | | | + | App |--------- HTTPS GET / Capabilities -------->| CCM | + | | | | + +---------+ +-----------+ + + Figure 24: CCM API - GET Procedures + + The CCM shall provide information regarding its capabilities as + follows: + + * Supported Features: One or more of the "Feature Name" values, as + defined in the MX Feature Activation List parameter of the MX + Capability Request (Appendix C.2.5). + + * Supported Connections: Supported connection types and connection + IDs. + + * Supported MX Adaptation Layers: List of MX Adaptation Layer + protocols supported by the N-MADP instance, along with the + connection types where these are supported and their respective + parameters. + + * Supported MX Convergence Layers: List of supported MX Convergence + Layer protocols, along with the parameters associated with the + respective convergence technique. + +B.4.2. Posting Application Requirements + + The CCM provides an HTTPS POST interface as "/ccm/v1.0/ + app_requirements" for the application to post the needs of the + application data streams to the CCM instance. + + +---------+ +-----------+ + | | | | + | App |-------- HTTPS POST / App Requirements ---->| CCM | + | | | | + +---------+ +-----------+ + + Figure 25: CCM API - POST Procedures + + The CCM shall provide for the application to post the following + requirements for its different data streams: + + * Number of Data Stream Types. + + * For each data stream type, specify the following parameters for + the link, which are preferred by the application: + + - Protocol Type: Transport-layer protocol associated with the + application data stream packets. + + - Port Range: Supported connection types and connection IDs. + + - Traffic QoS: Quality of service parameters, as follows: + + o Bandwidth + + o Latency + + o Jitter + +B.4.3. Getting Predictive Link Parameters + + The CCM provides an HTTPS GET interface as "/ccm/v1.0/ + predictive_link_params" for the application to get the predicted link + parameters from the CCM instance. + + +---------+ +-----------+ + | | | | + | App |----- HTTPS GET / Predictive Link Params --->| CCM | + | | | | + +---------+ +-----------+ + + Figure 26: CCM API - Getting Predictive Link Parameters + + The CCM asks the NCM for link parameters via the MAMS Network + Analytics Request Procedure (Section 8.12) and includes the + information in response to the API invocation. + + * Number of Delivery Connections. + + For each delivery connection, include the following: + + - Access Link Identifier: + + o Connection Type + + o Connection ID + + - Link Quality Indicator + + o Bandwidth: + + + Predicted Value (Mbps) + + + Likelihood (percent) + + + Prediction Validity (Validity Time, in seconds) + + o Jitter: + + + Predicted Value (in seconds) + + + Likelihood (percent) + + + Prediction Validity (Validity Time, in seconds) + + o Latency: + + + Predicted Value (in seconds) + + + Likelihood (percent) + + + Prediction Validity (Validity Time, in seconds) + + o Signal Quality + + + If delivery connection type is LTE, LTE_RSRP Predicted + Value (dBm) + + + If delivery connection type is LTE, LTE_RSRQ Predicted + Value (dBm) + + + If delivery connection type is 5G NR, NR_RSRP Predicted + Value (dBm) + + + If delivery connection type is 5G NR, NR_RSRQ Predicted + Value (dBm) + + + If delivery connection type is Wi-Fi, WLAN_RSSI Predicted + Value (dBm) + + + Likelihood (percent) + + + Prediction Validity (Validity Time, in seconds) + +Appendix C. MAMS Control-Plane Messages Described Using JSON + + MAMS control-plane messages are exchanged between the CCM and the + NCM. This non-normative appendix describes the format and content of + messages using JSON [RFC8259]. + +C.1. Protocol Specification: General Processing + +C.1.1. Notation + + This document uses JSONString, JSONNumber, and JSONBool to indicate + the JSON string, number, and boolean types, respectively. + + This document uses an adaptation of the C-style struct notation to + describe JSON objects. A JSON object consists of name/value pairs. + This document refers to each pair as a field. In some contexts, this + document also refers to a field as an attribute. The name of a + field/attribute may be referred to as the key. An optional field is + enclosed by "[ ]". In the definitions, the JSON names of the fields + are case sensitive. An array is indicated by two numbers in angle + brackets, <m..n>, where m indicates the minimal number of values and + n is the maximum. When this document uses * for n, it means no upper + bound. + + For example, the text below describes a new type Type4, with three + fields: "name1", "name2", and "name3", respectively. The "name3" + field is optional, and the "name2" field is an array of at least one + value. + + object { Type1 name1; Type2 name2 <1..*>; [Type3 name3;] } Type4; + + This document uses subtyping to denote that one type is derived from + another type. The example below denotes that TypeDerived is derived + from TypeBase. TypeDerived includes all fields defined in TypeBase. + If TypeBase does not have a "name1" field, TypeDerived will have a + new field called "name1". If TypeBase already has a field called + "name1" but with a different type, TypeDerived will have a field + called "name1" with the type defined in TypeDerived (i.e., Type1 in + the example). + + object { Type1 name1; } TypeDerived : TypeBase; + + Note that, despite the notation, no standard, machine-readable + interface definition or schema is provided in this document. + Extension documents may describe these as necessary. + + For compatibility with publishing requirements, line breaks have been + inserted inside long JSON strings, with the following continuation + lines indented. To form the valid JSON example, any line breaks + inside a string must be replaced with a space and any other white + space after the line break removed. + +C.1.2. Discovery Procedure + +C.1.2.1. MX Discover Message + + This message is the first message sent by the CCM to discover the + presence of NCM in the network. It contains only the base + information as described in Appendix C.2.1 with message_type set as + mx_discover. + + The representation of the message is as follows: + + object { + [JSONString MCC_MNC_Tuple;] + } MXDiscover : MXBase; + +C.1.3. System Information Procedure + +C.1.3.1. MX System Info Message + + This message is sent by the NCM to the CCM to inform the endpoints + that the NCM supports MAMS functionality. In addition to the base + information (Appendix C.2.1), it contains the following information: + + (a) NCM Connections (Appendix C.2.3). + + The representation of the message is as follows: + + object { + NCMConnections ncm_connections; + } MXSystemInfo : MXBase; + +C.1.4. Capability Exchange Procedure + +C.1.4.1. MX Capability Request + + This message is sent by the CCM to the NCM to indicate the + capabilities of the CCM instance available to the NCM indicated in + the System Info message earlier. In addition to the base information + (Appendix C.2.1), it contains the following information: + + (a) Features and their activation status: See Appendix C.2.5. + + (b) Number of Anchor Connections: The number of anchor connections + (toward the core) supported by the NCM. + + (c) Anchor connections: See Appendix C.2.6. + + (d) Number of Delivery Connections: The number of delivery + connections (toward the access) supported by the NCM. + + (e) Delivery connections: See Appendix C.2.7. + + (f) Convergence methods: See Appendix C.2.9. + + (g) Adaptation methods: See Appendix C.2.10. + + The representation of the message is as follows: + + object { + FeaturesActive feature_active; + JSONNumber num_anchor_connections; + AnchorConnections anchor_connections; + JSONNumber num_delivery_connections; + DeliveryConnections delivery_connections; + ConvergenceMethods convergence_methods; + AdaptationMethods adaptation_methods + } MXCapabilityReq : MXBase; + +C.1.4.2. MX Capability Response + + This message is sent by the NCM to the CCM to indicate the + capabilities of the NCM instance and unique session identifier for + the CCM. In addition to the base information (Appendix C.2.1), it + contains the following information: + + (a) Features and their activation status: See Appendix C.2.5. + + (b) Number of Anchor Connections: The number of anchor connections + (toward the core) supported by the NCM. + + (c) Anchor connections: See Appendix C.2.6. + + (d) Number of Delivery Connections: The number of delivery + connections (toward the access) supported by the NCM. + + (e) Delivery connections: See Appendix C.2.7. + + (f) Convergence methods: See Appendix C.2.9. + + (g) Adaptation methods: See Appendix C.2.10. + + (h) Unique Session ID: This uniquely identifies the session between + the CCM and the NCM in a network. See Appendix C.2.2. + + The representation of the message is as follows: + + object { + FeaturesActive feature_active; + JSONNumber num_anchor_connections; + AnchorConnections anchor_connections; + JSONNumber num_delivery_connections; + DeliveryConnections delivery_connections; + ConvergenceMethods convergence_methods; + AdaptationMethods adaptation_methods + UniqueSessionId unique_session_id; + } MXCapabilityRsp : MXBase; + +C.1.4.3. MX Capability Acknowledge + + This message is sent by the CCM to the NCM to indicate acceptance of + capabilities advertised by the NCM in an earlier MX Capability + Response message. In addition to the base information + (Appendix C.2.1), it contains the following information: + + (a) Unique Session ID: Same identifier as the identifier provided in + the MX Capability Response. See Appendix C.2.2. + + (b) Capability Acknowledgment: Indicates either acceptance or + rejection of the capabilities sent by the CCM. Can use either + "MX_ACCEPT" or "MX_REJECT" as acceptable values. + + The representation of the message is as follows: + + object { + UniqueSessionId unique_session_id; + JSONString capability_ack; + } MXCapabilityAck : MXBase; + +C.1.5. User-Plane Configuration Procedure + +C.1.5.1. MX User-Plane Configuration Request + + This message is sent by the NCM to the CCM to configure the user + plane for MAMS. In addition to the base information + (Appendix C.2.1), it contains the following information: + + (a) Number of Anchor Connections: The number of anchor connections + supported by the NCM. + + (b) Setup of anchor connections: See Appendix C.2.11. + + The representation of the message is as follows: + + object { + JSONNumber num_anchor_connections; + SetupAnchorConns anchor_connections; + } MXUPSetupConfigReq : MXBase; + +C.1.5.2. MX User-Plane Configuration Confirmation + + This message is the confirmation of the user-plane setup message sent + from the CCM after successfully configuring the user plane on the + client. This message contains the following information: + + (a) Unique Session ID: Same identifier as the identifier provided in + the MX Capability Response. See Appendix C.2.2. + + (b) MX probe parameters (included if probing is supported). + + (1) Probe Port: UDP port for accepting probe message. + + (2) Anchor connection ID: Identifier of the anchor connection + to be used for probe function. Provided in the MX UP Setup + Configuration Request. + + (3) MX Configuration ID: This parameter is included only if the + MX Configuration ID parameter is available from the user- + plane setup configuration. It indicates the MX + configuration ID of the anchor connection to be used for + probe function. + + (c) The following information is required for each delivery + connection: + + (1) Connection ID: Delivery connection ID supported by the + client. + + (2) Client Adaptation-Layer Parameters: If the UDP Adaptation + Layer is in use, then the UDP port to be used on the C-MADP + side. + + The representation of the message is as follows: + + object { + UniqueSessionId unique_session_id; + [ProbeParam probe_param;] + JSONNumber num_delivery_conn; + ClientParam client_params <1...*>; + } MXUPSetupConfigCnf : MXBase; + + Where ProbeParam is defined as follows: + + object { + JSONNumber probe_port; + JSONNumber anchor_conn_id; + [JSONNumber mx_configuration_id;] + } ProbeParam; + + Where ClientParam is defined as follows: + + object { + JSONNumber connection_id; + [AdaptationParam adapt_param;] + } ClientParam; + + Where AdaptationParam is defined as follows: + + object { + JSONNumber udp_adapt_port; + } AdaptationParam; + +C.1.6. Reconfiguration Procedure + +C.1.6.1. MX Reconfiguration Request + + This message is sent by the CCM to the NCM in the case of + reconfiguration of any of the connections from the client's side. In + addition to the base information (Appendix C.2.1), it contains the + following information: + + (a) Unique Session ID: Identifier for the CCM-NCM association + Appendix C.2.2. + + (b) Reconfiguration Action: The reconfiguration action type can be + one of "setup", "release", or "update". + + (c) Connection ID: Connection ID for which the reconfiguration is + taking place. + + (d) IP address: Included if Reconfiguration Action is either "setup" + or "update". + + (e) SSID: If the connection type is Wi-Fi, then this parameter + contains the SSID to which the client has attached. + + (f) MTU of the connection: The MTU of the delivery path that is + calculated at the client for use by the NCM to configure + fragmentation and concatenation procedures at the N-MADP. + + (g) Connection Status: This parameter indicates whether the + connection is currently "disabled", "enabled", or "connected". + Default: "connected". + + (h) Delivery Node ID: Identity of the node to which the client is + attached. In the case of LTE, this is an ECGI. In the case of + Wi-Fi, this is an AP ID or a MAC address. + + The representation of the message is as follows: + + object { + UniqueSessionId unique_session_id; + JSONString reconf_action; + JSONNumber connection_id; + JSONString ip_address; + JSONString ssid; + JSONNumber mtu_size; + JSONString connection_status; + [JSONString delivery_node_id;] + } MXReconfReq : MXBase; + +C.1.6.2. MX Reconfiguration Response + + This message is sent by the NCM to the CCM as a confirmation of the + received MX Reconfiguration Request and contains only the base + information (as defined in Appendix C.2.1). + + The representation of the message is as follows: + + object { + } MXReconfRsp : MXBase; + +C.1.7. Path Estimation Procedure + +C.1.7.1. MX Path Estimation Request + + This message is sent by the NCM toward the CCM to configure the CCM + to send MX Path Estimation Results. In addition to the base + information (Appendix C.2.1), it contains the following information: + + (a) Connection ID: ID of the connection for which the path + estimation report is required. + + (b) Init Probe Test Duration: Duration of initial probe test, in + milliseconds. + + (c) Init Probe Test Rate: Initial testing rate, in megabits per + second. + + (d) Init Probe Size: Size of each packet for initial probe, in + bytes. + + (e) Init Probe-ACK: If an acknowledgment for probe is required. + (Possible values: "yes", "no") + + (f) Active Probe Frequency: Frequency, in milliseconds, at which the + active probes shall be sent. + + (g) Active Probe Size: Size of the active probe, in bytes. + + (h) Active Probe Duration: Duration, in seconds, for which the + active probe shall be performed. + + (i) Active Probe-ACK: If an acknowledgment for probe is required. + (Possible values: "yes", "no") + + The representation of the message is as follows: + + object { + JSONNumber connection_id; + JSONNumber init_probe_test_duration_ms; + JSONNumber init_probe_test_rate_Mbps; + JSONNumber init_probe_size_bytes; + JSONString init_probe_ack_req; + JSONNumber active_probe_freq_ms; + JSONNumber active_probe_size_bytes; + JSONNumber active_probe_duration_sec; + JSONString active_probe_ack_req; + } MXPathEstReq : MXBase; + +C.1.7.2. MX Path Estimation Results + + This message is sent by the CCM to the NCM to report on the probe + estimation configured by the NCM. In addition to the base + information (Appendix C.2.1), it contains the following information: + + (a) Unique Session ID: Same identifier as the identifier provided in + the MX Capability Response. See Appendix C.2.2. + + (b) Connection ID: ID of the connection for which the MX Path + Estimation Results message is required. + + (c) Init Probe Results: See Appendix C.2.12. + + (d) Active Probe Results: See Appendix C.2.13. + + The representation of the message is as follows: + + object { + JSONNumber connection_id; + UniqueSessionId unique_session_id; + [InitProbeResults init_probe_results;] + [ActiveProbeResults active_probe_results;] + } MXPathEstResults : MXBase; + +C.1.8. Traffic-Steering Procedure + +C.1.8.1. MX Traffic Steering Request + + This message is sent by the NCM to the CCM to enable traffic steering + on the delivery side in uplink and downlink configurations. In + addition to the base information (Appendix C.2.1), it contains the + following information: + + (a) Connection ID: Anchor connection number for which the traffic + steering is being defined. + + (b) MX Configuration ID: MX configuration for which the traffic + steering is being defined. + + (c) Downlink Delivery: See Appendix C.2.14. + + (d) Default UL Delivery: The default delivery connection for the + uplink. All traffic should be delivered on this connection in + the uplink direction, and the Traffic Flow Template (TFT) filter + should be applied only for the traffic mentioned in Uplink + Delivery. + + (e) Uplink Delivery: See Appendix C.2.15. + + (f) Features and their activation status: See Appendix C.2.5. + + The representation of the message is as follows: + + object { + JSONNumber connection_id; + [JSONNumber mx_configuration_id;] + DLDelivery downlink_delivery; + JSONNumber default_uplink_delivery; + ULDelivery uplink_delivery; + FeaturesActive feature_active; + } MXTrafficSteeringReq : MXBase; + +C.1.8.2. MX Traffic Steering Response + + This message is a response to an MX Traffic Steering Request from the + CCM to the NCM. In addition to the base information + (Appendix C.2.1), it contains the following information: + + (a) Unique Session ID: Same identifier as the identifier provided in + the MX Capability Response. See Appendix C.2.2. + + (b) Features and their activation status: See Appendix C.2.5. + + The representation of the message is as follows: + + object { + UniqueSessionId unique_session_id; + FeaturesActive feature_active; + } MXTrafficSteeringResp : MXBase; + +C.1.9. MAMS Application MADP Association + +C.1.9.1. MX Application MADP Association Request + + This message is sent by the CCM to the NCM to select MADP instances + provided earlier in the MX UP Setup Configuration Request, based on + requirements for the applications. + + In addition to the base information (Appendix C.2.1), it contains the + following: + + (a) Unique Session ID: This uniquely identifies the session between + the CCM and the NCM in a network. See Appendix C.2.2. + + (b) A list of MX Application MADP Associations, with each entry as + follows: + + (1) Connection ID: Represents the anchor connection number of + the MADP instance. + + (2) MX Configuration ID: Identifies the MX configuration of the + MADP instance. + + (3) Traffic Flow Template Uplink: Traffic Flow Template, as + defined in Appendix C.2.16, to be used in the uplink + direction. + + (4) Traffic Flow Template Downlink: Traffic Flow Template, as + defined in Appendix C.2.16, to be used in the downlink + direction. + + The representation of the message is as follows: + + object { + UniqueSessionId unique_session_id; + MXAppMADPAssoc app_madp_assoc_list <1..*>; + } MXAppMADPAssocReq : MXBase; + + Where each measurement MXAppMADPAssoc is represented by the + following: + + object { + JSONNumber connection_id; + JSONNumber mx_configuration_id + TrafficFlowTemplate tft_ul_list <1..*>; + TrafficFlowTemplate tft_dl_list <1..*>; + } MXAppMADPAssoc; + +C.1.9.2. MX Application MADP Association Response + + This message is sent by the NCM to the CCM to confirm the selected + MADP instances provided in the MX Application MADP Association + Request by the CCM. + + In addition to the base information (Appendix C.2.1), it contains + information if the request has been successful. + + The representation of the message is as follows: + + object { + JSONBool is_success; + } MXAppMADPAssocResp : MXBase; + +C.1.10. MX SSID Indication + + This message is sent by the NCM to the CCM to indicate the list of + allowed SSIDs that are supported by the MAMS entity on the network + side. It contains the list of SSIDs. + + Each SSID consists of the type of SSID (which can be one of the + following: SSID, BSSID, or HESSID) and the SSID itself. + + The representation of the message is as follows: + + object { + SSID ssid_list <1..*>; + } MXSSIDIndication : MXBase; + + Where each SSID is defined as follows: + + object { + JSONString ssid_type; + JSONString ssid; + } SSID; + +C.1.11. Measurements + +C.1.11.1. MX Measurement Configuration + + This message is sent from the NCM to the CCM to configure the period + measurement reporting at the CCM. The message contains a list of + measurement configurations, with each element containing the + following information: + + (a) Connection ID: Connection ID of the delivery connection for + which the reporting is being configured. + + (b) Connection Type: Connection type for which the reporting is + being configured. Can be "LTE", "Wi-Fi", "5G_NR". + + (c) Measurement Report Configuration: Actual report configuration + based on the Connection Type, as defined in Appendix C.2.17. + + The representation of the message is as follows: + + object { + MeasReportConf measurement_configuration <1..*>; + } MXMeasReportConf : MXBase; + + Where each measurement MeasReportConf is represented by the + following: + + object { + JSONNumber connection_id; + JSONString connection_type; + MeasReportConfs meas_rep_conf <1..*>; + } MeasReportConf; + +C.1.11.2. MX Measurement Report + + This message is periodically sent by the CCM to the NCM after + measurement configuration. In addition to the base information, it + contains the following information: + + (a) Unique Session ID: Same identifier as the identifier provided in + the MX Capability Response. Described in Appendix C.2.2. + + (b) Measurement report for each delivery connection is measured by + the client as defined in Appendix C.2.18. + + The representation of the message is as follows: + + object { + UniqueSessionId unique_session_id; + MXMeasRep measurement_reports <1..*>; + } MXMeasurementReport : MXBase; + +C.1.12. Keep-Alive + +C.1.12.1. MX Keep-Alive Request + + An MX Keep-Alive Request can be sent from either the NCM or the CCM + on expiry of the Keep-Alive timer or a handover event. The peer + shall respond to this request with an MX Keep-Alive Response. In the + case of no response from the peer, the MAMS connection shall be + assumed to be broken, and the CCM shall establish a new connection by + sending MX Discover messages. + + In addition to the base information, it contains the following + information: + + (a) Keep-Alive Reason: Reason for sending this message, can be + "Timeout" or "Handover". + + (b) Unique Session ID: Identifier for the CCM-NCM association + Appendix C.2.2. + + (c) Connection ID: Connection ID for which handover is detected, if + the reason is "Handover". + + (d) Delivery Node ID: The target delivery node ID (ECGI or Wi-Fi AP + ID/MAC address) to which the handover is executed. + + The representation of the message is as follows: + + object { + JSONString keep_alive_reason; + UniqueSessionId unique_session_id; + JSONNumber connection_id; + JSONString delivery_node_id; + } MXKeepAliveReq : MXBase; + +C.1.12.2. MX Keep-Alive Response + + On receiving an MX Keep-Alive Request from a peer, the NCM/CCM shall + immediately respond with an MX Keep-Alive Response on the same + delivery path from where the request arrived. In addition to the + base information, it contains the unique session identifier for the + CCM-NCM association (defined in Appendix C.2.2) + + The representation of the message is as follows: + + object { + UniqueSessionId unique_session_id; + } MXKeepAliveResp : MXBase; + +C.1.13. Session Termination Procedure + +C.1.13.1. MX Session Termination Request + + In the event where the NCM or CCM can no longer handle MAMS for any + reason, it can send an MX Session Termination Request to the peer. + In addition to the base information, it contains a Unique Session ID + and the reason for the termination; this can be "MX_NORMAL_RELEASE", + "MX_NO_RESPONSE", or "INTERNAL_ERROR". + + The representation of the message is as follows: + + object { + UniqueSessionId unique_session_id; + JSONString reason; + } MXSessionTerminationReq : MXBase; + +C.1.13.2. MX Session Termination Response + + On receipt of an MX Session Termination Request from a peer, the NCM/ + CCM shall respond with MX Session Termination Response on the same + delivery path where the request arrived and clean up the MAMS-related + resources and settings. The CCM shall reinitiate a new session with + MX Discover messages. + + The representation of the message is as follows: + + object { + UniqueSessionId unique_session_id; + } MXSessionTerminationResp : MXBase; + +C.1.14. Network Analytics + +C.1.14.1. MX Network Analytics Request + + This message is sent by the CCM to the NCM to request parameters like + bandwidth, jitter, latency, and signal quality predicted by the + network analytics function. In addition to the base information, it + contains the following parameter: + + (a) Unique Session ID: Same identifier as the identifier provided in + the MX Capability Response. Described in Appendix C.2.2. + + (b) Parameter List: List of parameters in which the CCM is + interested: one or more of "bandwidth", "jitter", "latency", and + "signal_quality". + + The representation of the message is as follows: + + object { + UniqueSessionId unique_session_id; + JSONString params <1..*>; + } MXNetAnalyticsReq : MXBase; + + Where the params object can take one or more of the following values: + + "bandwidth" + "jitter" + "latency" + "signal_quality" + +C.1.14.2. MX Network Analytics Response + + This message is sent by the NCM to the CCM in response to the MX + Network Analytics Request. For each delivery connection that the + client has, the NCM reports the requested parameter predictions and + their respective likelihoods (between 1 and 100 percent). + + In addition to the base information, it contains the following + parameters: + + (a) Number of Delivery Connections: The number of delivery + connections that are currently configured for the client. + + (b) The following information is provided for each delivery + connection: + + (1) Connection ID: Connection ID of the delivery connection for + which the parameters are being predicted. + + (2) Connection Type: Type of connection. Can be "Wi-Fi", + "5G_NR", "MulteFire", or "LTE". + + (3) List of Parameters for which Prediction is requested, where + each of the predicted parameters consists of the following: + + (a) Parameter Name: Name of the parameter being predicted. + Can be one of "bandwidth", "jitter", "latency", or + "signal_quality". + + (b) Additional Parameter: If Parameter name is + "signal_quality", then this qualifies the quality + parameter like "lte_rsrp", "lte_rsrq", "nr_rsrp", + "nr_rsrq", or "wifi_rssi". + + (c) Predicted Value: Provides the predicted value of the + parameter and, if applicable, the additional + parameter. + + (d) Likelihood: Provides a stochastic likelihood of the + predicted value. + + (e) Validity Time: The time duration for which the + predictions are valid. + + The representation of the message is as follows: + + object { + MXAnalyticsList param_list <1..*>; + } MXNetAnalyticsResp : MXBase; + + Where MXAnalyticsList is defined as follows: + + object { + JSONNumber connection_id; + JSONString connection_type; + ParamPredictions predictions <1..*>; + } MXAnalyticsList; + + Where each ParamPredictions item is defined as: + + object { + JSONString param_name; + [JSONString additional_param;] + JSONNumber prediction; + JSONNumber likelihood; + JSONNumber validity_time; + } ParamPredictions; + +C.2. Protocol Specification: Data Types + +C.2.1. MXBase + + This is the base information that every message between the CCM and + NCM exchanges shall have as mandatory information. It contains the + following information: + + (a) Version: Version of MAMS used. + + (b) Message Type: Message type being sent, where the following are + considered valid values: + + "mx_discover" + "mx_system_info" + "mx_capability_req" + "mx_capability_rsp" + "mx_capability_ack" + "mx_up_setup_conf_req" + "mx_up_setup_cnf" + "mx_reconf_req" + "mx_reconf_rsp" + "mx_path_est_req" + "mx_path_est_results" + "mx_traffic_steering_req" + "mx_traffic_steering_rsp" + "mx_ssid_indication" + "mx_keep_alive_req" + "mx_keep_alive_rsp" + "mx_measurement_conf" + "mx_measurement_report" + "mx_session_termination_req" + "mx_session_termination_rsp" + "mx_app_madp_assoc_req" + "mx_app_madp_assoc_rsp" + "mx_network_analytics_req" + "mx_network_analytics_rsp" + + (c) Sequence Number: Sequence number to uniquely identify a + particular message exchange, e.g., MX Capability + Request/Response/Acknowledge. + + The representation of this data type is as follows: + + object { + JSONString version; + JSONString message_type; + JSONNumber sequence_num; + } MXBase; + +C.2.2. Unique Session ID + + This data type represents the unique session ID between a CCM and NCM + entity. It contains an NCM ID that is unique in the network and a + session ID that is allocated by the NCM for that session. On receipt + of the MX Discover message, if the session exists, then the old + session ID is returned in the MX System Info message; otherwise, the + NCM allocates a new session ID for the CCM and sends the new ID in + the MX System Info message. + + The representation of this data type is as follows: + + object { + JSONNumber ncm_id; + JSONNumber session_id; + } UniqueSessionId; + +C.2.3. NCM Connections + + This data type represents the connection available at the NCM for + MAMS connectivity toward the client. It contains a list of NCM + connections available, where each connection has the following + information: + + (a) Connection Information: See Appendix C.2.4. + + (b) NCM Endpoint Information: Contains the IP address and port + exposed by the NCM endpoint for the CCM. + + The representation of this data type is as follows: + + object { + NCMConnection items <1..*>; + } NCMConnections; + + where NCMConnection is defined as: + + object { + NCMEndPoint ncm_end_point; + } NCMConnection : ConnectionInfo; + + where NCMEndPoint is defined as: + + object { + JSONString ip_address; + JSONNumber port; + } NCMEndPoint; + +C.2.4. Connection Information + + This data type provides the mapping of connection ID and connection + type. It contains the following information: + + (a) Connection ID: Unique number identifying the connection. + + (b) Connection Type: Type of connection can be "Wi-Fi", "5G_NR", + "MulteFire", or "LTE". + + The representation of this data type is as follows: + + object { + JSONNumber connection_id; + JSONString connection_type; + } ConnectionInfo; + +C.2.5. Features and Their Activation Status + + This data type provides the list of all features with their + activation status. Each feature status contains the following: + + (a) Feature Name: The name of the feature can be one of the + following: + + "lossless_switching" + "fragmentation" + "concatenation" + "uplink_aggregation" + "downlink_aggregation" + "measurement" + + (b) Active status: Activation status of the feature: "true" means + that the feature is active, and "false" means that the feature + is inactive. + + The representation of this data type is as follows: + + object { + FeatureInfo items <1..*>; + } FeaturesActive; + + where FeatureInfo is defined as: + + object { + JSONString feature_name; + JSONBool active; + } FeatureInfo; + +C.2.6. Anchor Connections + + This data type contains the list of Connection Information items + (Appendix C.2.4) that are supported on the anchor (core) side. + + The representation of this data type is as follows: + + object { + ConnectionInfo items <1..*>; + } AnchorConnections; + +C.2.7. Delivery Connections + + This data type contains the list of Connection Information + (Appendix C.2.4) that are supported on the delivery (access) side. + + The representation of this data type is as follows: + + object { + ConnectionInfo items <1..*>; + } DeliveryConnections; + +C.2.8. Method Support + + This data type provides the support for a particular convergence or + adaptation method. It consists of the following: + + (a) Method: Name of the method. + + (b) Supported: Whether the method listed above is supported or not. + Possible values are "true" and "false". + + The representation of this data type is as follows: + + object { + JSONString method; + JSONBool supported; + } MethodSupport; + +C.2.9. Convergence Methods + + This data type contains the list of all convergence methods and their + support status. The possible convergence methods are: + + "GMA" + "MPTCP_Proxy" + "GRE_Aggregation_Proxy" + "MPQUIC" + + The representation of this data type is as follows: + + object { + MethodSupport items <1..*>; + } ConvergenceMethods; + +C.2.10. Adaptation Methods + + This data type contains the list of all adaptation methods and their + support status. The possible adaptation methods are: + + "UDP_without_DTLS" + "UDP_with_DTLS" + "IPsec" + "Client_NAT" + + The representation of this data type is as follows: + + object { + MethodSupport items <1..*>; + } AdaptationMethods; + +C.2.11. Setup of Anchor Connections + + This data type represents the setup configuration for each anchor + connection that is required on the client's side. It contains the + following information, in addition to the connection ID and type of + the anchor connection: + + (a) Number of Active MX Configurations: If more than one active + configuration is present for this anchor, then this identifies + the number of such connections. + + (b) The following convergence parameters are provided for each + active configuration: + + (1) MX Configuration ID: Present if there are multiple active + configurations. Identifies the configuration for this MADP + instance ID. + + (2) Convergence Method: Convergence method selected. Has to be + one of the supported convergence methods listed in + Appendix C.2.9. + + (3) Convergence Method Parameters: Described in + Appendix C.2.11.1 + + (4) Number of Delivery Connections: The number of delivery + connections (access side) that are supported for this + anchor connection. + + (5) Setup of delivery connections: Described in + Appendix C.2.11.2. + + The representation of this data type is as follows: + + object { + SetupAnchorConn items <1..*>; + } SetupAnchorConns; + + Where each anchor connection configuration is defined as follows: + + object { + [JSONNumber num_active_mx_conf;] + ConvergenceConfig convergence_config + } SetupAnchorConn : ConnectionInfo; + + where each Convergence configuration is defined as follows: + + object { + [JSONNumber mx_configuration_id;] + JSONString convergence_method; + ConvergenceMethodParam convergence_method_params; + JSONNumber num_delivery_connections; + SetupDeliveryConns delivery_connections; + } ConvergenceConfig; + +C.2.11.1. Convergence Method Parameters + + This data type represents the parameters used for the convergence + method and contains the following: + + (a) Proxy IP: IP address of the proxy that is provided by the + selected convergence method. + + (b) Proxy Port: Port of the proxy that is provided by the selected + convergence method. + + The representation of this data type is as follows: + + object { + JSONString proxy_ip; + JSONString proxy_port; + JSONString client_key; + } ConvergenceMethodParam; + +C.2.11.2. Setup Delivery Connections + + This is the list of delivery connections and their parameters to be + configured on the client. Each delivery connection defined by its + connection information (Appendix C.2.4) optionally contains the + following: + + (a) Adaptation Method: Selected adaptation method name. This shall + be one of the methods listed in Appendix C.2.10. + + (b) Adaptation Method Parameters: Depending on the adaptation + method, one or more of the following parameters shall be + provided. + + (1) Tunnel IP address + + (2) Tunnel Port number + + (3) Shared Secret + + (4) MX header optimization: If the adaptation method is + UDP_without_DTLS or UDP_with_DTLS, and convergence is GMA, + then this flag represents whether or not the checksum field + and the length field in the IP header of an MX PDU should + be recalculated by the MX Convergence Layer. The possible + values are "true" and "false". If it is "true", both + fields remain unchanged; otherwise, both fields should be + recalculated. If this field is not present, then the + default of "false" should be considered. + + The representation of this data type is as follows: + + object { + SetupDeliveryConn items <1..*>; + } SetupDeliveryConns; + + where each "SetupDeliveryConn" consists of the following: + + object { + [JSONString adaptation_method;] + [AdaptationMethodParam adaptation_method_param;] + } SetupDeliveryConn : ConnectionInfo; + + where AdaptationMethodParam is defined as: + + object { + JSONString tunnel_ip_addr; + JSONString tunnel_end_port; + JSONString shared_secret; + [JSONBool mx_header_optimization;] + } AdaptationMethodParam; + +C.2.12. Init Probe Results + + This data type provides the results of the init probe request made by + the NCM. It consists of the following information: + + (a) Lost Probes: Percentage of probes lost. + + (b) Probe Delay: Average delay of probe message, in microseconds. + + (c) Probe Rate: Probe rate achieved, in megabits per second. + + The representation of this data type is as follows: + + object { + JSONNumber lost_probes_percentage; + JSONNumber probe_rate_Mbps; + } InitProbeResults; + +C.2.13. Active Probe Results + + This data type provides the results of the active probe request made + by the NCM. It consists of the following information: + + (a) Average Probe Throughput: Average active probe throughput + achieved, in megabits per second. + + The representation of this data type is as follows: + + object { + JSONNumber avg_tput_last_probe_duration_Mbps; + } ActiveProbeResults; + +C.2.14. Downlink Delivery + + This data type represents the list of connections that are enabled on + the delivery side to be used in the downlink direction. + + The representation of this data type is as follows: + + object { + JSONNumber connection_id <1..*>; + } DLDelivery; + +C.2.15. Uplink Delivery + + This data type represents the list of connections and parameters + enabled for the delivery side to be used in the uplink direction. + + The uplink delivery consists of multiple uplink delivery entities, + where each entity consists of a Traffic Flow Template (TFT) + (Appendix C.2.16) and a list of connection IDs in the uplink, where + traffic qualifying for such a Traffic Flow Template can be + redirected. + + The representation of this data type is as follows: + + object { + ULDeliveryEntity ul_del <1..*>; + } ULDelivery; + + Where each uplink delivery entity consists of the following data + type: + + object { + TrafficFlowTemplate ul_tft <1..*>; + JSONNumber connection_id <1..*>; + } ULDeliveryEntity; + +C.2.16. Traffic Flow Template + + The Traffic Flow Template generally follows the guidelines specified + in [ServDesc3GPP]. + + The Traffic Flow Template in MAMS consists of one or more of the + following: + + (a) Remote Address and Mask: IP address and subnet for remote + addresses represented in Classless Inter-Domain Routing (CIDR) + notation. Default: "0.0.0.0/0". + + (b) Local Address and Mask: IP address and subnet for local + addresses represented in CIDR notation. Default: "0.0.0.0/0" + + (c) Protocol Type: IP protocol number of the payload being carried + by an IP packet (e.g., UDP, TCP). Default: 255. + + (d) Local Port Range: Range of ports for local ports for which the + Traffic Flow Template is applicable. Default: Start=0, + End=65535. + + (e) Remote Port Range: Range of ports for remote ports for which the + Traffic Flow Template is applicable. Default: Start=0, + End=65535. + + (f) Traffic Class: Represented by Type of Service in IPv4 and + Traffic Class in IPv6. Default: 255 + + (g) Flow Label: Flow label for IPv6, applicable only for IPv6 + protocol type. Default: 0. + + The representation of this data type is as follows: + + object { + JSONString remote_addr_mask; + JSONString local_addr_mask; + JSONNumber protocol_type; + PortRange local_port_range; + PortRange remote_port_range; + JSONNumber traffic_class; + JSONNumber flow_label; + } TrafficFlowTemplate; + + Where the port range is defined as follows: + + object { + JSONNumber start; + JSONNumber end; + } PortRange; + +C.2.17. Measurement Report Configuration + + This data type represents the configuration done by the NCM toward + the CCM for reporting measurement events. + + (a) Measurement Report Parameter: Parameter that shall be measured + and reported. This is dependent on the connection type: + + (1) For the connection type of "Wi-Fi", the allowed measurement + type parameters are "WLAN_RSSI", "WLAN_LOAD", "UL_TPUT", + "DL_TPUT", "EST_UL_TPUT", and "EST_DL_TPUT". + + (2) For the connection type of "LTE", the allowed measurement + type parameters are "LTE_RSRP", "LTE_RSRQ", "UL_TPUT", and + "DL_TPUT". + + (3) For the connection type of "5G_NR", the allowed measurement + type parameters are "NR_RSRP", "NR_RSRQ", "UL_TPUT", and + "DL_TPUT". + + (b) Threshold: High and low threshold for reporting. + + (c) Period: Period for reporting, in milliseconds. + + The representation of this data type is as follows: + + object { + JSONString meas_rep_param; + Threshold meas_threshold; + JSONNumber meas_period; + } MeasReportConfs; + + Where "Threshold" is defined as follows: + + object { + JSONNumber high; + JSONNumber low; + } Threshold; + +C.2.18. Measurement Report + + This data type represents the measurements reported by the CCM for + each access network measured. This type contains the connection + information, the Delivery Node ID that identifies either the cell + (ECGI) or the Wi-Fi Access Point ID or MAC address (or equivalent + identifier in other technologies), and the actual measurement + performed by the CCM in the last measurement period. + + The representation of this data type is as follows: + + object { + JSONNumber connection_id; + JSONString connection_type; + JSONString delivery_node_id; + Measurement measurements <1..*>; + } MXMeasRep; + + Where Measurement is defined as the key-value pair of the measurement + type and value. The exact measurement type parameter reported for a + given connection depends on its Connection Type. The measurement + type parameters, for each Connection Type, are specified in + Appendix C.2.17. + + object { + JSONString measurement_type; + JSONNumber measurement_value; + } Measurement; + +C.3. Schemas in JSON + +C.3.1. MX Base Schema + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "definitions": { + "message_type_def": { + "enum": [ + "mx_discover", + "mx_system_info", + "mx_capability_req", + "mx_capability_rsp", + "mx_capability_ack", + "mx_up_setup_conf_req", + "mx_up_setup_cnf", + "mx_reconf_req", + "mx_reconf_rsp", + "mx_path_est_req", + "mx_path_est_results", + "mx_traffic_steering_req", + "mx_traffic_steering_rsp", + "mx_ssid_indication", + "mx_keep_alive_req", + "mx_keep_alive_rsp", + "mx_measurement_conf", + "mx_measurement_report", + "mx_session_termination_req", + "mx_session_termination_rsp", + "mx_app_madp_assoc_req", + "mx_app_madp_assoc_rsp", + "mx_network_analytics_req", + "mx_network_analytics_rsp" + ], + "type": "string" + }, + "sequence_num_def": { + "minimum": 1, + "type": "integer" + }, + "version_def": { + "type": "string" + } + }, + "id": "https://example.com/mams/mx_base_def.json" + } + +C.3.2. MX Definitions + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "definitions": { + "adapt_method": { + "enum": [ + "UDP_without_DTLS", + "UDP_with_DTLS", + "IPsec", + "Client_NAT" + ], + "type": "string" + }, + "conv_method": { + "enum": [ + "GMA", + "MPTCP_Proxy", + "GRE_Aggregation_Proxy", + "MPQUIC" + ], + "type": "string" + }, + "supported": { + "type": "boolean" + }, + "active": { + "type": "boolean" + }, + "connection_id": { + "type": "integer" + }, + "feature_name": { + "enum": [ + "lossless_switching", + "fragmentation", + "concatenation", + "uplink_aggregation", + "downlink_aggregation", + "measurement" + "probing" + ], + "type": "string" + }, + "connection_type": { + "enum": [ + "Wi-Fi", + "5G_NR", + "MulteFire", + "LTE" + ], + "type": "string" + }, + "ip_address": { + "type": "string" + }, + "port": { + "maximum": 65535, + "minimum": 1, + "type": "integer" + }, + "adaptation_method": { + "allOf" : [ + { "$ref": "#/definitions/adapt_method" }, + { "$ref": "#/definitions/supported" } + ] + }, + "connection": { + "allOf" : [ + { "$ref": "#/definitions/connection_id" }, + { "$ref": "#/definitions/connection_type" } + ] + }, + "convergence_method": { + "allOf": [ + { "$ref": "#/definitions/conv_method" }, + { "$ref": "#/definitions/supported" } + ] + }, + "feature_status": { + "allOf": [ + { "$ref": "#/definitions/feature_name" }, + { "$ref": "#/definitions/active" } + ] + }, + "ncm_end_point": { + "allOf" : [ + { "$ref" : "#/definitions/ip_address" }, + { "$ref" : "#/definitions/port" } + ] + }, + "capability_acknowledgment" : { + "enum" : [ + "MX_ACCEPT", + "MX_REJECT" + ], + "type" : "string" + }, + "threshold" : { + "high" : { + "type" : "integer" + }, + "low" : { + "type" : "integer" + }, + "type" : "object" + }, + "meas_report_param" : { + "enum" : [ + "WLAN_RSSI", + "WLAN_LOAD", + "LTE_RSRP", + "LTE_RSRQ", + "UL_TPUT", + "DL_TPUT", + "EST_UL_TPUT", + "EST_DL_TPUT", + "NR_RSRP", + "NR_RSRQ" + ], + "type" : "string" + }, + "meas_report_conf" : { + "meas_rep_param" : { + "$ref" : "#definitions/meas_report_param" + }, + "meas_threshold" : { + "$ref" : "#definitions/threshold" + }, + "meas_period_ms" : { + "type" : "integer" + }, + "type" : "object" + }, + "ssid_types" : { + "enum" : [ + "ssid", + "bssid", + "hessid" + ], + "type" : "string" + }, + "ip_addr_mask" : { + "type" : "string", + "default" : "0.0.0.0/0" + }, + "port_range" : { + "start" : { + "type" : "integer", + "default" : 0 + }, + "end" : { + "type" : "integer", + "default" : 65535 + } + }, + "traffic_flow_template" : { + "remote_addr_mask" : { + "$ref" : "#definitions/ip_addr_mask" }, + "local_addr_mask" : { + "$ref" : "#definitions/ip_addr_mask" }, + "protocol_type" : { + "type" : "integer", + "minimum" : 0, + "maximum" : 255 + }, + "local_port_range" : { + "$ref" : "#definitions/port_range" }, + "remote_port_range" : { + "$ref" : "#definitions/port_range" }, + "traffic_class" : { + "type" : "integer", + "default" : 255 + }, + "flow_label" : { + "type" : "integer", + "default" : 0 + } + }, + "delivery_node_id" : { + "type" : "string" + }, + "unique_session_id" : { + "type" : "object", + "ncm_id" : { + "type" : "integer" + }, + "session_id" : { + "type" : "integer" + } + }, + "keep_alive_reason" : { + "enum" : [ + "Timeout", + "Handover" + ], + "type" : "string" + }, + "connection_status" : { + "enum" : [ + "disabled", + "enabled", + "connected" + ], + "type" : "string", + "default" : "connected" + }, + "adaptation_param" : { + "udp_adapt_port" : { + "type" : "integer" + } + }, + "probe_param" : { + "probe_port" : { + "type" : "integer" + }, + "anchor_conn_id" : { + "type" : "integer" + }, + "mx_configuration_id" : { + "type" : "integer" + } + }, + "client_param" : { + "connection_id" : { + "type" : "integer" + }, + "adapt_param" : { + "type" : {"$ref" : "#definitions/adaptation_param" } + } + } + }, + "adapt_param": { + "tunnel_ip_addr": { + "type": "string" + }, + "tunnel_end_port": { + "type": "integer" + }, + "shared_secret": { + "type": "string" + }, + "mx_header_optimization": { + "type": "boolean", + "default": false + } + }, + "delivery_connection": { + "connection_id": { + "$ref": "#definitions/connection_id" + }, + "connection_type": { + "$ref": "#definitions/connection_type" + }, + "adaptation_method": { + "$ref": "#definitions/adapt_method" + }, + "adaptation_method_param": { + "$ref": "#definitions/adapt_param" + } + }, + "app_madp_assoc": { + "anchor_conn_id" : { + "type" : "integer" + }, + "mx_configuration_id" : { + "type" : "integer" + } + + "ul_tft_list": { + "items": { + "$ref": "#definitions/traffic_flow_template" + }, + "type": "array" + }, + "dl_tft_list": { + "items": { + "$ref": "#definitions/traffic_flow_template" + }, + "type": "array" + } + }, + "predict_param_name": { + "enum": [ + "validity_time", + "bandwidth", + "jitter", + "latency", + "signal_quality" + ], + "type": "string" + }, + "predict_add_param_name": { + "enum": [ + "WLAN_RSSI", + "WLAN_LOAD", + "LTE_RSRP", + "LTE_RSRQ", + "NR_RSRP", + "NR_RSRQ" + ], + "type": "string" + }, + "id": "https://example.com/mams/definitions.json" + } + +C.3.3. MX Discover + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "additionalProperties": false, + "id": "https://example.com/mams/mx_discover.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"} + }, + "type": "object" + } + +C.3.4. MX System Info + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "additionalProperties": false, + "id": "https://example.com/mams/mx_system_info.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "ncm_connections": { + "type": "array", + "items": [ + {"$ref": "definitions.json#/connection"}, + {"$ref": "definitions.json#/ncm_end_point"} + ] + } + }, + "type": "object" + } + +C.3.5. MX Capability Request + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "additionalProperties": false, + "id": "https://example.com/mams/mx_capability_req.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "adaptation_methods": { + "items": {"$ref": "definitions.json#/adaptation_method"}, + "type": "array" + }, + "anchor_connections": { + "items": {"$ref": "definitions.json#/connection"}, + "type": "array" + }, + "convergence_methods": { + "items": {"$ref": "definitions.json#/convergence_method"}, + "type": "array" + }, + "delivery_connections": { + "items": {"$ref": "definitions.json#/connection"}, + "type": "array" + }, + "feature_active": { + "items": {"$ref": "definitions.json#/feature_status"}, + "type": "array" + }, + "num_anchor_connections": { + "type": "integer" + }, + "num_delivery_connections": { + "type": "integer" + } + }, + "type": "object" + } + +C.3.6. MX Capability Response + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "additionalProperties": false, + "id": "https://example.com/mams/mx_capability_rsp.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "adaptation_methods": { + "items": {"$ref": "definitions.json#/adaptation_method"}, + "type": "array" + }, + "anchor_connections": { + "items": {"$ref": "definitions.json#/connection"}, + "type": "array" + }, + "convergence_methods": { + "items": {"$ref": "definitions.json#/convergence_method"}, + "type": "array" + }, + "delivery_connections": { + "items": {"$ref": "definitions.json#/connection"}, + "type": "array" + }, + "feature_active": { + "items": {"$ref": "definitions.json#/feature_status"}, + "type": "array" + }, + "num_anchor_connections": { + "type": "integer" + }, + "num_delivery_connections": { + "type": "integer" + }, + "unique_session_id": { + "$ref": "definitions.json#/unique_session_id" + } + }, + "type": "object" + } + +C.3.7. MX Capability Acknowledge + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "definitions": {}, + "id": "https://example.com/mams/mx_capability_ack.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "unique_session_id": { + "$ref": "definitions.json#/unique_session_id"}, + "capability_ack": { + "$ref": "definitions.json#/capability_acknowledgment"} + }, + "type": "object" + } + +C.3.8. MX Reconfiguration Request + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "definitions": {}, + "id": "https://example.com/mams/mx_reconf_req.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "unique_session_id": { + "$ref": "definitions.json#/unique_session_id" + }, + "connection_id": {"$ref": "definitions.json#/connection_id"}, + "ip_address": {"$ref": "definitions.json#/ip_address"}, + "mtu_size": { + "maximum": 65535, + "minimum": 1, + "type": "integer" + }, + "ssid": { + "type": "string" + }, + "reconf_action": { + "enum": [ + "release", + "setup", + "update" + ], + "id": "/properties/reconf_action", + "type": "string" + }, + "connection_status": { + "$ref": "definitions.json#/connection_status"}, + "delivery_node_id": { + "$ref": "definitions.json#/delivery_node_id"} + }, + "type": "object" + } + +C.3.9. MX Reconfiguration Response + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "definitions": {}, + "id": "https://example.com/mams/mx_reconf_rsp.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"} + }, + "type": "object" + } + +C.3.10. MX UP Setup Configuration Request + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "additionalProperties": false, + "definitions": { + "convergence_configuration": { + "mx_configuration_id": {"type": "integer"}, + "convergence_method": { + "$ref": "definitions.json#/conv_method"}, + "convergence_method_params": { + "properties": { + "proxy_ip": {"$ref": "definitions.json#/ip_address"}, + "proxy_port": {"$ref": "definitions.json#/port"}, + "client_key": {"$ref": "definitions.json#/client_key"} + }, + "type": "object" + }, + "num_delivery_connections": { + "type": "integer" + }, + "delivery_connections": { + "items": {"$ref": "definitions.json#/delivery_connection"}, + "type": "array" + } + } + }, + "id": "https://example.com/mams/mx_up_setup_conf_req.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "num_anchor_connections": { + "type": "integer" + }, + "anchor_connections": { + "items": { + "properties": { + "connection_id": { + "$ref": "definitions.json#/connection_id"}, + "connection_type": { + "$ref": "definitions.json#/connection_type"}, + "num_active_mx_conf": {"type": "integer"}, + "convergence_config": { + "items": { + "$ref": "definitions/convergence_configuration"}, + "type": "array" + } + }, + "type": "object" + }, + "type": "array" + } + }, + "type": "object" + } + +C.3.11. MX UP Setup Confirmation + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "definitions": {}, + "id": "https://example.com/mams/mx_up_setup_cnf.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "unique_session_id": { + "$ref": "definitions.json#/unique_session_id"}, + "probe_param": {"$ref": "definitions.json#/probe_param"}, + "num_delivery_conn": { + "type": "integer" + }, + "client_params": { + "type": "array", + "items": [ + {"$ref": "definitions.json#/client_param"} + ] + } + }, + "type": "object" + } + +C.3.12. MX Traffic Steering Request + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "definitions": { + "conn_list": { + "items": {"$ref": "definitions.json#/connection_id"}, + "type": "array" + }, + "ul_delivery": { + "ul_tft": { + "$ref": "definitions.json#/traffic_flow_template"}, + "connection_list": {"$ref": "#definitions/conn_list"} + } + }, + "id": "https://example.com/mams/mx_traffic_steering_req.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "connection_id": {"$ref": "definitions.json#/connection_id"}, + "mx_configuration_id": {"type": "integer"}, + "downlink_delivery": { + "items": {"$ref": "definitions.json#/connection_id"}, + "type": "array" + }, + "feature_active": { + "items": {"$ref": "definitions.json#/feature_status"}, + "type": "array" + }, + "default_uplink_delivery": { + "type": "integer" + }, + "uplink_delivery": { + "items": {"$ref": "#definitions/ul_delivery"}, + "type": "array" + } + }, + "type": "object" + } + +C.3.13. MX Traffic Steering Response + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "definitions": {}, + "id": "https://example.com/example.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "unique_session_id": { + "$ref": "definitions.json#/unique_session_id"}, + "feature_active": { + "items": {"$ref": "definitions.json#/feature_status"}, + "type": "array" + } + }, + "type": "object" + } + +C.3.14. MX Application MADP Association Request + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "definitions": {}, + "id": "https://example.com/example.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "unique_session_id": { + "$ref": "definitions.json#/unique_session_id"}, + "app_madp_assoc_list": { + "items": { + "$ref": "definitions.json#/app_madp_assoc" + }, + "type": "array" + } + }, + "type": "object" + } + +C.3.15. MX Application MADP Association Response + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "definitions": {}, + "id": "https://example.com/example.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "unique_session_id": { + "$ref": "definitions.json#/unique_session_id"}, + "is_success": { + "type": "boolean" + } + }, + "type": "object" + } + +C.3.16. MX Path Estimation Request + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "definitions": {}, + "id": "https://example.com/mams/mx_path_est_req.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "active_probe_ack_req": { + "enum": [ + "no", + "yes" + ], + "type": "string" + }, + "active_probe_freq_ms": { + "maximum": 10000, + "minimum": 100, + "type": "integer" + }, + "active_probe_size_bytes": { + "maximum": 1500, + "minimum": 100, + "type": "integer" + }, + "active_probe_duration_sec": { + "maximum": 100, + "minimum": 10, + "type": "integer" + }, + "connection_id": {"$ref": "definitions#/connection_id"}, + "init_probe_ack_req": { + "enum": [ + "no", + "yes" + ], + "type": "string" + }, + "init_probe_size_bytes": { + "maximum": 1500, + "minimum": 100, + "type": "integer" + }, + "init_probe_test_duration_ms": { + "maximum": 10000, + "minimum": 100, + "type": "integer" + }, + "init_probe_test_rate_Mbps": { + "maximum": 100, + "minimum": 1, + "type": "integer" + } + }, + "type": "object" + } + +C.3.17. MX Path Estimation Results + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "definitions": {}, + "id": "https://example.com/mams/mx_path_est_results.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "unique_session_id": { + "$ref": "definitions.json#/unique_session_id"}, + "active_probe_results": { + "properties": { + "avg_tput_last_probe_duration_Mbps": { + "maximum":100, + "minimum": 1, + "type": "number" + } + }, + "type": "object" + }, + "connection_id": {"$ref": "definitions.json#/connection_id"}, + "init_probe_results": { + "properties": { + "lost_probes_percentage": { + "maximum": 100, + "minimum": 1, + "type": "integer" + }, + "probe_rate_Mbps": { + "maximum": 100, + "minimum": 1, + "type": "number" + } + }, + "type": "object" + } + }, + "type": "object" + } + +C.3.18. MX SSID Indication + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "definitions": {}, + "id": "https://example.com/mams/mx_ssid_indication.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "ssid_list": { + "items": { + "properties": { + "ssid_type": { + "$ref": "definitions.json#/ssid_types"}, + "ssid_id": { + "type": "integer" + } + } + }, + "type": "array" + } + }, + "type": "object" + } + +C.3.19. MX Measurement Configuration + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "additionalProperties": false, + "definitions": { + "meas_conf": { + "connection_id" : { + "$ref": "definitions.json#/connection_id"}, + "connection_type": { + "$ref": "definitions.json#/connection_type"}, + "meas_rep_conf": { + "items": { + "$ref": "definitions.json#/meas_report_conf"}, + "type": "array" + } + } + }, + "id": "https://example.com/mams/mx_measurement_conf.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "measurement_configuration": { + "items": {"$ref": "#definitions/meas_conf"}, + "type": "array" + } + }, + "type": "object" + } + +C.3.20. MX Measurement Report + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "definitions": {}, + "id": "https://example.com/mams/mx_measurement_report.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "unique_session_id": { + "$ref": "definitions.json#/unique_session_id"}, + "measurement_reports": { + "items": { + "properties": { + "connection_id": { + "$ref": "definitions.json#/connection_id"}, + "connection_type": { + "$ref": "definitions.json#/connection_type"}, + "delivery_node_id": { + "$ref": "definitions.json#/delivery_node_id"}, + "measurements": { + "items": { + "properties": { + "measurement_type": { + "$ref": "definitions.json#/meas_report_param"}, + "measurement_value": { + "type": "integer" + } + }, + "type": "object" + }, + "type": "array" + } + }, + "type": "object" + }, + "type": "array" + } + }, + "type": "object" + } + +C.3.21. MX Keep-Alive Request + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "additionalProperties": false, + "id": "https://example.com/mams/mx_keep_alive_req.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "keep_alive_reason": { + "$ref": "definitions.json#/keep_alive_reason"}, + "unique_session_id": { + "$ref": "definitions.json#/unique_session_id"}, + "connection_id": { + "$ref": "definitions.json#/connection_id"}, + "delivery_node_id": { + "$ref": "definitions.json#/connection_id"} + }, + "type": "object" + } + +C.3.22. MX Keep-Alive Response + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "additionalProperties": false, + "id": "https://example.com/mams/mx_keep_alive_rsp.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "unique_session_id": { + "$ref": "definitions.json#/unique_session_id"} + }, + "type": "object" + } + +C.3.23. MX Session Termination Request + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "additionalProperties": false, + "id": "https://example.com/mams/mx_keep_alive_req.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "unique_session_id": { + "$ref": "definitions.json#/unique_session_id"}, + "reason": { + "enum": [ + "MX_NORMAL_RELEASE", + "MX_NO_RESPONSE", + "INTERNAL_ERROR" + ], + "type": "string" + } + }, + "type": "object" + } + +C.3.24. MX Session Termination Response + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "additionalProperties": false, + "id": "https://example.com/mams/mx_session_termination_rsp.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "unique_session_id": { + "$ref": "definitions.json#/unique_session_id"} + }, + "type": "object" + } + +C.3.25. MX Network Analytics Request + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "additionalProperties": false, + "id": "https://example.com/mams/mx_network_analytics_req.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "unique_session_id": { + "$ref": "definitions.json#/unique_session_id"}, + "params": { + "items": { + "$ref": "definitions.json#/predict_param_name"}, + "type": "array" + } + }, + "type": "object" + } + +C.3.26. MX Network Analytics Response + + { + "$schema": "https://json-schema.org/draft-04/schema#", + "additionalProperties": false, + "definitions": { + "ParamPredictions": { + "param_name": { + "$ref": "definitions.json#/predict_param_name"}, + "additional_param": { + "$ref": "definitions.json#/predict_add_param_name"}, + "prediction": {"type": "integer"}, + "likelihood": {"type": "integer"}, + "validity_time": {"type": "integer"} + + }, + "MXAnalyticsList": { + "connection_id": { + "$ref": "definitions.json#/connection_id"}, + "connection_type": { + "$ref": "definitions.json#/connection_type"}, + "predictions": { + "items": { + "$ref": "#definitions/ParamPredictions"}, + "type": "array" + } + } + }, + "id": "https://example.com/mams/mx_network_analytics_rsp.json", + "properties": { + "message_type": {"$ref": "mx_base_def.json#/message_type_def"}, + "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"}, + "version": {"$ref": "mx_base_def.json#/version_def"}, + "param_list": { + "items": { + "$ref": "#definitions/MXAnalyticsList"}, + "type": "array"} + }, + "type": "object" + } + +C.4. Examples in JSON + +C.4.1. MX Discover + + { + "version" : "1.0", + "message_type" : "mx_discover", + "sequence_num" : 1 + } + +C.4.2. MX System Info + + { + "version" : "1.0", + "message_type" : "mx_system_info", + "sequence_num" : 2, + "ncm_connections" : [ + { + "connection_id" : 0, + "connection_type" : "LTE", + "ncm_end_point" : { + "ip_address" : "192.168.1.10", + "port" : 1234 + } + }, + { + "connection_id" : 1, + "connection_type" : "Wi-Fi", + "ncm_end_point" : { + "ip_address" : "192.168.1.10", + "port" : 1234 + } + } + ] + } + +C.4.3. MX Capability Request + + { + "version" : "1.0", + "message_type" : "mx_capability_req", + "sequence_num" : 3, + "feature_active" : [ + { + "feature_name" : "lossless_switching", + "active" : true + }, + { + "feature_name" : "fragmentation", + "active" : false + } + ], + "num_anchor_connections" : 2, + "anchor_connections" : [ + { + "connection_id" : 0, + "connection_type" : "LTE" + }, + { + "connection_id" : 1, + "connection_type" : "Wi-Fi" + } + ], + "num_delivery_connections" : 2, + "delivery_connections" : [ + { + "connection_id" : 0, + "connection_type" : "LTE" + }, + { + "connection_id" : 1, + "connection_type" : "Wi-Fi" + } + ], + "convergence_methods" : [ + { + "method" : "GMA", + "supported" : true + }, + { + "method" : "MPTCP_Proxy", + "supported" : false + } + ], + "adaptation_methods" : [ + { + "method" : "UDP_without_DTLS", + "supported" : false + }, + { + "method" : "UDP_with_DTLS", + "supported" : false + }, + { + "method" : "IPsec", + "supported" : true + }, + { + "method" : "Client_NAT", + "supported" : false + } + ] + } + +C.4.4. MX Capability Response + + { + "version" : "1.0", + "message_type" : "mx_capability_rsp", + "sequence_num" : 3, + "feature_active" : [ + { + "feature_name" : "lossless_switching", + "active" : true + }, + { + "feature_name" : "fragmentation", + "active" : false + } + ], + "num_anchor_connections" : 2, + "anchor_connections" : [ + { + "connection_id" : 0, + "connection_type" : "LTE" + }, + { + "connection_id" : 1, + "connection_type" : "Wi-Fi" + } + ], + "num_delivery_connections" : 2, + "delivery_connections" : [ + { + "connection_id" : 0, + "connection_type" : "LTE" + }, + { + "connection_id" : 1, + "connection_type" : "Wi-Fi" + } + ], + "convergence_methods" : [ + { + "method" : "GMA", + "supported" : true + }, + { + "method" : "MPTCP_Proxy", + "supported" : false + } + ], + "adaptation_methods" : [ + { + "method" : "UDP_without_DTLS", + "supported" : false + }, + { + "method" : "UDP_with_DTLS", + "supported" : false + }, + { + "method" : "IPsec", + "supported" : true + }, + { + "method" : "Client_NAT", + "supported" : false + } + ], + "unique_session_id" : { + "ncm_id" : 110, + "session_id" : 1111 + } + } + +C.4.5. MX Capability Acknowledge + + { + "version" : "1.0", + "message_type" : "mx_capability_ack", + "sequence_num" : 3, + "unique_session_id" : { + "ncm_id" : 110, + "session_id" : 1111 + }, + "capability_ack" : "MX_ACCEPT" + } + +C.4.6. MX Reconfiguration Request + + { + "version" : "1.0", + "message_type" : "mx_reconf_req", + "sequence_num" : 4, + "unique_session_id" : { + "ncm_id" : 110, + "session_id" : 1111 + }, + "reconf_action" : "setup", + "connection_id" : 0, + "ip_address" : "192.168.110.1", + "ssid" : "SSID_1", + "mtu_size" : 1300, + "connection_status" : "connected", + "delivery_node_id" : "2A12C" + } + +C.4.7. MX Reconfiguration Response + + { + "version" : "1.0", + "message_type" : "mx_reconf_rsp", + "sequence_num" : 4 + } + +C.4.8. MX UP Setup Configuration Request + + { + "version": "1.0", + "message_type": "mx_up_setup_conf_req", + "sequence_num": 5, + "num_anchor_connections": 2, + "anchor_connections": [{ + "connection_id": 1, + "connection_type": "Wi-Fi", + "num_active_mx_conf" : 2, + "convergence_config" : [ + { + "mx_configuration_id" : 1, + "convergence_method": "GMA", + "convergence_method_params": {}, + "num_delivery_connections": 2, + "delivery_connections": [{ + "connection_id": 0, + "connection_type": "LTE", + "adaptation_method": "UDP_without_DTLS", + "adaptation_method_param": { + "tunnel_ip_addr": "6.6.6.6", + "tunnel_end_port": 9999, + "mx_header_optimization": true + } + }, + { + "connection_id": 1, + "connection_type": "Wi-Fi" + } + ] + }, + { + "mx_configuration_id" : 2, + "convergence_method": "GMA", + "convergence_method_params": {}, + "num_delivery_connections": 1, + "delivery_connections": [{ + "connection_id": 0, + "connection_type": "LTE", + "adaptation_method": "UDP_without_DTLS", + "adaptation_method_param": { + "tunnel_ip_addr": "6.6.6.6", + "tunnel_end_port": 8877 + } + } + ] + } + ] + }, + { + "connection_id": 0, + "connection_type": "LTE", + "udp_port": 8888, + "num_delivery_connections": 2, + "delivery_connections": [{ + "connection_id": 0, + "connection_type": "LTE" + }, + { + "connection_id": 1, + "connection_type": "Wi-Fi", + "adaptation_method": "UDP_without_DTLS", + "adaptation_method_param": { + "tunnel_ip_addr": "192.168.3.3", + "tunnel_end_port": "6000" + } + } + ] + } + ] + } + +C.4.9. MX UP Setup Confirmation + + { + "version" : "1.0", + "message_type" : "mx_up_setup_cnf", + "sequence_num" : 5, + "unique_session_id" : { + "ncm_id" : 110, + "session_id" : 1111 + }, + "probe_param" : { + "probe_port" : 48700, + "anchor_conn_id" : 0, + "mx_configuration_id" : 1 + }, + "num_delivery_conn" : 2, + "client_params" : [ + { + "connection_id" : 0, + "adapt_param" : { + "udp_adapt_port" : 51000 + } + }, + { + "connection_id" : 1, + "adapt_param" : { + "udp_adapt_port" : 52000 + } + } + ] + } + +C.4.10. MX Traffic Steering Request + + { + "version" : "1.0", + "message_type" : "mx_traffic_steering_req", + "sequence_num" : 6, + "connection_id" : 0, + "mx_configuration_id" : 1, + "downlink_delivery" : [ + { + "connection_id" : 0 + }, + { + "connection_id" : 1 + } + ], + "default_uplink_delivery" : 0, + "uplink_delivery" : [ + { + "ul_tft" : { + "remote_addr_mask" : "10.10.0.0/24", + "local_addr_mask" : "192.168.0.0/24", + "protocol_type" : 6, + "local_port_range" : { + "start" : 100, + "end" : 1000 + }, + "remote_port_range" : { + "start" : 100, + "end" : 1000 + }, + "traffic_class" : 20, + "flow_label" : 100 + }, + "conn_list" : [ + { + "connection_id" : 1 + } + ] + }, + { + "ul_tft" : { + "remote_addr_mask" : "10.10.0.0/24", + "local_addr_mask" : "192.168.0.0/24", + "protocol_type" : 6, + "local_port_range" : { + "start" : 2000, + "end" : 2000 + }, + "remote_port_range" : { + "start" : 100, + "end" : 1000 + }, + "traffic_class" : 20, + "flow_label" : 50 + }, + "conn_list" : [ + { + "connection_id" : 1 + } + ] + } + ], + "feature_active" : [ + { + "feature_name" : "dl_aggregation", + "active" : true + }, + { + "feature_name" : "ul_aggregation", + "active" : false + } + ] + } + +C.4.11. MX Traffic Steering Response + + { + "version": "1.0", + "message_type": "mx_traffic_steering_rsp", + "sequence_num": 6, + "unique_session_id": { + "ncm_id": 110, + "session_id": 1111 + }, + "feature_active": [{ + "feature_name": "lossless_switching", + "active": true + }, + { + "feature_name": "fragmentation", + "active": false + } + ] + } + +C.4.12. MX Application MADP Association Request + + { + "version": "1.0", + "message_type": "mx_app_madp_assoc_req", + "sequence_num": 6, + "unique_session_id": { + "ncm_id": 110, + "session_id": 1111 + }, + "app_madp_assoc_list": [{ + "connection_id" : 0, + "mx_configuration_id" : 1, + "ul_tft_list": [{ + "protocol_type": 17, + "local_port_range": { + "start": 8888, + "end": 8888 + } + }], + "dl_tft_list": [{ + "protocol_type": 17, + "remote_port_range": { + "start": 8888, + "end": 8888 + } + }] + } + ] + } + +C.4.13. MX Application MADP Association Response + + { + "version": "1.0", + "message_type": "mx_app_madp_assoc_rsp", + "sequence_num": 6, + "is_success": true + } + +C.4.14. MX Path Estimation Request + + { + "version" : "1.0", + "message_type" : "mx_path_est_req", + "sequence_num" : 7, + "connection_id" : 0, + "init_probe_test_duration_ms" : 100, + "init_probe_test_rate_Mbps" : 10, + "init_probe_size_bytes" : 1000, + "init_probe_ack_req" : "yes", + "active_probe_freq_ms" : 10000, + "active_probe_size_bytes" : 1000, + "active_probe_duration_sec" : 10, + "active_probe_ack_req" : "no" + } + +C.4.15. MX Path Estimation Results + + { + "version" : "1.0", + "message_type" : "mx_path_est_results", + "sequence_num" : 8, + "unique_session_id" : { + "ncm_id" : 110, + "session_id" : 1111 + }, + "connection_id" : 0, + "init_probe_results" : { + "lost_probes_percentage" : 1, + "probe_rate_Mbps" : 9.9 + }, + "active_probe_results" : { + "avg_tput_last_probe_duration_Mbps" : 9.8 + } + } + +C.4.16. MX SSID Indication + + { + "version" : "1.0", + "message_type" : "mx_ssid_indication", + "sequence_num" : 9, + "ssid_list" : [ + { + "ssid_type" : "ssid", + "ssid_id" : "SSID_1" + }, + { + "ssid_type" : "bssid", + "ssid_id" : "xxx-yyy" + } + ] + } + +C.4.17. MX Measurement Configuration + + { + "version" : "1.0", + "message_type" : "mx_measurement_conf", + "sequence_num" : 10, + "measurement_configuration" : [ + { + "connection_id" : 0, + "connection_type" : "Wi-Fi", + "meas_rep_conf" : [ + { + "meas_rep_param" : "WLAN_RSSI", + "meas_threshold" : { + "high" : -10, + "low" : -15 + }, + "meas_period_ms" : 500 + }, + { + "meas_rep_param" : "WLAN_LOAD", + "meas_threshold" : { + "high" : -10, + "low" : -15 + }, + "meas_period_ms" : 500 + }, + { + "meas_rep_param" : "EST_UL_TPUT", + "meas_threshold" : { + "high" : 100, + "low" : 30 + }, + "meas_period_ms" : 500 + } + ] + }, + { + "connection_id" : 1, + "connection_type" : "LTE", + "meas_rep_conf" : [ + { + "meas_rep_param" : "LTE_RSRP", + "meas_threshold" : { + "high" : -10, + "low" : -15 + }, + "meas_period_ms" : 500 + }, + { + "meas_rep_param" : "LTE_RSRQ", + "meas_threshold" : { + "high" : -10, + "low" : -15 + }, + "meas_period_ms" : 500 + } + ] + } + ] + } + +C.4.18. MX Measurement Report + + { + "version" : "1.0", + "message_type" : "mx_measurement_report", + "sequence_num" : 11, + "unique_session_id" : { + "ncm_id" : 110, + "session_id" : 1111 + }, + "measurement_reports" : [ + { + "connection_id" : 0, + "connection_type" : "Wi-Fi", + "delivery_node_id" : "2021A", + "measurements" : [ + { + "measurement_type" : "WLAN_RSSI", + "measurement_value" : -12 + }, + { + "measurement_type" : "UL_TPUT", + "measurement_value" : 10 + }, + { + "measurement_type" : "EST_UL_TPUT", + "measurement_value" : 20 + } + ] + }, + { + "connection_id" : 1, + "connection_type" : "LTE", + "delivery_node_id" : "12323", + "measurements" : [ + { + "measurement_type" : "LTE_RSRP", + "measurement_value" : -12 + + }, + { + "measurement_type" : "LTE_RSRQ", + "measurement_value" : -12 + + } + ] + } + ] + } + +C.4.19. MX Keep-Alive Request + + { + "version" : "1.0", + "message_type" : "mx_keep_alive_req", + "sequence_num" : 12, + "keep_alive_reason" : "Handover", + "unique_session_id" : { + "ncm_id" : 110, + "session_id" : 1111 + }, + "connection_id" : 0, + "delivery_node_id" : "2021A" + } + +C.4.20. MX Keep-Alive Response + + { + "version" : "1.0", + "message_type" : "mx_keep_alive_rsp", + "sequence_num" : 12, + "unique_session_id" : { + "ncm_id" : 110, + "session_id" : 1111 + } + } + +C.4.21. MX Session Termination Request + + { + "version" : "1.0", + "message_type" : "mx_session_termination_req", + "sequence_num" : 13, + "unique_session_id" : { + "ncm_id" : 110, + "session_id" : 1111 + }, + "reason" : "MX_NORMAL_RELEASE" + } + +C.4.22. MX Session Termination Response + + { + "version" : "1.0", + "message_type" : "mx_session_termination_rsp", + "sequence_num" : 13, + "unique_session_id" : { + "ncm_id" : 110, + "session_id" : 1111 + } + } + +C.4.23. MX Network Analytics Request + + { + "version" : "1.0", + "message_type" : "mx_network_analytics_req", + "sequence_num" : 20, + "unique_session_id" : { + "ncm_id" : 110, + "session_id" : 1111 + }, + "params" : [ + "jitter", + "latency" + ] + } + +C.4.24. MX Network Analytics Response + + { + "version": "1.0", + "message_type": "mx_network_analytics_rsp", + "sequence_num": 20, + "param_list": [{ + "connection_id": 1, + "connection_type": "Wi-Fi", + "predictions": [{ + "param_name": "jitter", + "prediction": 100, + "likelihood": 50, + "validity_time": 10 + }, + { + "param_name": "latency", + "prediction": 19, + "likelihood": 40, + "validity_time": 10 + } + ] + }, + { + "connection_id": 2, + "connection_type": "LTE", + "predictions": [{ + "param_name": "jitter", + "prediction": 10, + "likelihood": 80, + "validity_time": 10 + }, + { + "param_name": "latency", + "prediction": 4, + "likelihood": 60, + "validity_time": 10 + } + ] + } + ] + } + +Appendix D. Definition of APIs Provided by the CCM to the Applications + at the Client + + This section provides an example implementation of the APIs exposed + by the CCM to the applications on the client, documented with OpenAPI + using Swagger 2.0. + + { + "swagger": "2.0", + "info": { + "version": "1.0.0", + "title": "Client Connection Manager (CCM)", + "description": "API provided by the CCM towards the application + on a MAMS client." + }, + "host": "MAMS.ietf.org", + "basePath": "/ccm/v1.0", + "schemes": [ + "https" + ], + "consumes": [ + "application/json" + ], + "produces": [ + "application/json" + ], + "paths": { + "/capabilities": { + "get": { + "description": "This API can be used by an application to + request the capabilities of the CCM.", + "produces": [ + "application/json", + "text/html" + ], + "responses": { + "200": { + "description": "OK", + "schema": { + "$ref": "#/definitions/capability" + } + }, + "default": { + "description": "unexpected error", + "schema": { + "$ref": "#/definitions/errorModel" + } + } + } + } + }, + "/app_requirements": { + "post": { + "description": "This API is used by the N-MADP to report + any types of MAMS user-specific errors to + the NCM.", + "produces": [ + "application/json", + "text/html" + ], + "parameters": [ + { + "name": "app-requirements", + "in": "body", + "required": true, + "schema": { + "$ref": "#/definitions/app-requirements" + } + } + ], + "responses": { + "200": { + "description": "OK" + }, + "default": { + "description": "unexpected error", + "schema": { + "$ref": "#/definitions/errorModel" + } + } + } + } + }, + "/predictive_link_params": { + "get": { + "description": "This API is used by applications to get the + information about predicted parameters for + each delivery connection.", + "produces": [ + "application/json", + "text/html" + ], + "responses": { + "200": { + "description": "OK", + "schema": { + "$ref": "#/definitions/link-params" + } + }, + "default": { + "description": "unexpected error", + "schema": { + "$ref": "#/definitions/errorModel" + } + } + } + } + } + }, + "definitions": { + "connection-id": { + "type": "integer", + "format": "uint8" + }, + "connection-type": { + "enum": [ + "Wi-Fi", + "5G_NR", + "MulteFire", + "LTE" + ], + "type": "string" + }, + "features": { + "enum": [ + "lossless_switching", + "fragmentation", + "concatenation", + "uplink_aggregation", + "downlink_aggregation", + "measurement" + "probing" + ], + "type": "string" + }, + "adaptation-methods": { + "enum": [ + "UDP_without_DTLS", + "UDP_with_DTLS", + "IPsec", + "Client_NAT" + ], + "type": "string" + }, + "convergence-methods": { + "enum": [ + "GMA", + "MPTCP_Proxy", + "GRE_Aggregation_Proxy", + "MPQUIC" + ], + "type": "string" + }, + "connection": { + "type": "object", + "properties": { + "conn-id": { + "$ref": "#/definitions/connection-id" + }, + "conn-type": { + "$ref": "#/definitions/connection-type" + } + } + }, + "convergence-parameters": { + "type": "object", + "properties": { + "conv-param-name": { + "type": "string" + }, + "conv-param-value": { + "type": "string" + } + } + }, + "convergence-details": { + "type": "object", + "properties": { + "conv-method": { + "$ref": "#/definitions/convergence-methods" + }, + "conv-params": { + "type": "array", + "items": { + "$ref": "#/definitions/convergence-parameters" + } + } + } + }, + "capability": { + "type": "object", + "properties": { + "connections": { + "type": "array", + "items": { + "$ref": "#/definitions/connection" + } + }, + "features": { + "type": "array", + "items": { + "$ref": "#/definitions/features" + } + }, + "adapt-methods": { + "type": "array", + "items": { + "$ref": "#/definitions/adaptation-methods" + } + }, + "conv-methods": { + "type": "array", + "items": { + "$ref": "#/definitions/convergence-details" + } + } + } + }, + "qos-param-name": { + "enum": [ + "jitter", + "latency", + "bandwidth" + ], + "type": "string" + }, + "qos-param": { + "type": "object", + "properties": { + "qos-param-name": { + "$ref": "#/definitions/qos-param-name" + }, + "qos-param-value": { + "type": "integer" + } + } + }, + "port-range": { + "type": "object", + "properties": { + "start": { + "type": "integer" + }, + "end": { + "type": "integer" + } + } + }, + "protocol-type": { + "type": "integer" + }, + "stream-features": { + "type": "object", + "properties": { + "proto": { + "$ref": "#/definitions/protocol-type" + }, + "port-range": { + "$ref": "#/definitions/port-range" + }, + "traffic-qos": { + "$ref": "#/definitions/qos-param" + } + } + }, + "app-requirements": { + "type": "object", + "properties": { + "num-streams": { + "type": "integer" + }, + "stream-feature": { + "type": "array", + "items": { + "$ref": "#/definitions/stream-features" + } + } + } + }, + "param-name": { + "enum": [ + "bandwidth", + "jitter", + "latency", + "signal_quality" + ], + "type": "string" + }, + "additional-param-name": { + "enum": [ + "lte-rsrp", + "lte-rsrq", + "nr-rsrp", + "nr-rsrq", + "wifi-rssi" + ], + "type": "string" + }, + "link-parameter": { + "type": "object", + "properties": { + "connection": { + "$ref": "#/definitions/connection" + }, + "param": { + "$ref": "#/definitions/param-name" + }, + "additional-param": { + "$ref": "#/definitions/additional-param-name" + }, + "prediction": { + "type": "integer" + }, + "likelihood": { + "type": "integer" + }, + "validity_time": { + "type": "integer" + } + } + }, + "link-params": { + "type": "array", + "items": { + "$ref": "#/definitions/link-parameter" + } + }, + "errorModel": { + "type": "object", + "description": "Error indication containing the error code and + message.", + "required": [ + "code", + "message" + ], + "properties": { + "code": { + "type": "integer", + "format": "int32" + }, + "message": { + "type": "string" + } + } + } + } + } + +Appendix E. Implementation Example Using Python for MAMS Client and + Server + +E.1. Client-Side Implementation + + A simple client-side implementation using Python can be as follows: + + #!/usr/bin/env python + import asyncio + import websockets + import json + import ssl + import time + import sys + + context = ssl.SSLContext(ssl.PROTOCOL_TLS) + context.verify_mode = ssl.CERT_REQUIRED + context.set_ciphers("RSA") + context.check_hostname = False + context.load_verify_locations("/home/mecadmin/certs/rootca.pem") + + discoverMsg = {'version':'1.0', + 'message_type':'mx_discover'} + + MXCapabilityRes = {'version':'1.0', + 'message_type':'mx_capability_res', + 'FeatureActive':[{'feature_name':'fragmentation', 'active':'yes'}, + {'feature_name':'lossless_switching', 'active':'yes'}], + 'num_anchor_connections':1, + 'anchor_connections':[{'connection_id':0, 'connection_type':'LTE'}], + 'num_delivery_connections':1, + 'delivery_connections':[{'connection_id':1, + 'connection_type':"Wi-Fi"}], + 'convergence_methods':[{'method':'GMA', 'supported':'true'}], + 'adaptation_methods':[{'method':'client_nat', 'supported':'false'}] + } + + async def hello(): + async with websockets.connect('wss://localhost:8765', + ssl=context) as websocket: + try: + loopFlag=False + while True: + await websocket.send(json.dumps(discoverMsg)) + json_message = await websocket.recv() + message = json.loads(json_message) + if "message_type" in message.keys(): + print("Received message:{}".format( + message["message_type"]), + "version:{}".format(message["version"])) + if message["message_type"] == "mx_capability_req" : + await websocket.send(json.dumps(MXCapabilityRes)) + loopFlag=True + while(loopFlag==True): + pass + except: + print("Client stopped") + + asyncio.get_event_loop().run_until_complete(hello()) + +E.2. Server-Side Implementation + + A server-side implementation using Python can be as follows: + + #!/usr/bin/env python + import asyncio + import websockets + import json + import ssl + + ctx = ssl.SSLContext(ssl.PROTOCOL_TLS) + #ctx.set_ciphers("RSA-AES256-SHA") + ctx.load_verify_locations("/home/mecadmin/certs/rootca.pem") + certfile = "/home/mecadmin/certs/server.pem" + keyfile = "/home/mecadmin/certs/serverkey.pem" + ctx.load_cert_chain(certfile, keyfile, password=None) + + MXCapabilityReq = {'version':'1.0', + 'message_type':'mx_capability_req', + 'FeatureActive':[{'feature_name':'fragmentation', 'active':'yes'}, + {'feature_name':'lossless_switching', 'active':'yes'}], + 'num_anchor_connections':1, + 'anchor_connections':[{'connection_id':0, 'connection_type':'LTE'}], + 'num_delivery_connections':1, + 'delivery_connections':[{'connection_id':1, + 'connection_type':"Wi-Fi"}], + 'convergence_methods':[{'method':'GMA', 'supported':'true'}], + 'adaptation_methods':[{'method':'client_nat', 'supported':'false'}] + } + + async def hello(websocket, path): + try: + while True: + name = await websocket.recv() + msg = json.loads(name) + if "message_type" in msg.keys(): + print("Received message:{}".format(msg["message_type"]), + "version:{}".format(msg["version"])) + if msg['message_type'] == 'mx_discover': + await websocket.send(json.dumps(MXCapabilityReq)) + + except: + print("Client disconnected") + + try: + start_server = websockets.serve(hello, 'localhost', 8765,ssl=ctx) + + asyncio.get_event_loop().run_until_complete(start_server) + asyncio.get_event_loop().run_forever() + except: + print("Server stopped") + +Acknowledgments + + This protocol is the outcome of work by many engineers, not just the + authors of this document. The people who contributed to this + project, listed in alphabetical order by first name, are Barbara + Orlandi, Bongho Kim, David Lopez-Perez, Doru Calin, Jonathan Ling, + Lohith Nayak, and Michael Scharf. + +Contributors + + The authors gratefully acknowledge the following additional + contributors, in alphabetical order by first name: A Krishna Pramod/ + Nokia Bell Labs, Hannu Flinck/Nokia Bell Labs, Hema Pentakota/Nokia, + Julius Mueller/AT&T, Nurit Sprecher/Nokia, Salil Agarwal/Nokia, + Shuping Peng/Huawei, and Subramanian Vasudevan/Nokia Bell Labs. + Subramanian Vasudevan has been instrumental in conceptualization and + development of solution principles for the MAMS framework. Shuping + Peng has been a key contributor in refining the framework and + control-plane protocol aspects. + +Authors' Addresses + + Satish Kanugovi + Nokia Bell Labs + + Email: satish.k@nokia-bell-labs.com + + + Florin Baboescu + Broadcom + + Email: florin.baboescu@broadcom.com + + + Jing Zhu + Intel + + Email: jing.z.zhu@intel.com + + + SungHoon Seo + Korea Telecom + + Email: sh.seo@kt.com |