RFC 8743
Multiple Access Management Services Multi-Access Management Services (MAMS)
Multi-Access Management Services (MAMS) ✨
Okay bestie, this is RFC 8743 and it's giving informational energy 💅. Here's the lowdown:
- Stream: Independent Submission 🌸
- Category: Informational, so it's not a Standards Track spec 🫶
- Date: March 2020 📅
- ISSN: 2070-1721
- Authors: S. Kanugovi (Nokia Bell Labs), F. Baboescu (Broadcom), J. Zhu (Intel), and S. Seo (Korea Telecom) 👑
- Obsoletes / Updates: the header doesn't list any RFCs, so this one doesn't replace or update anything 🦋
Abstract 🎀
Okay so picture this: in multiconnectivity setups, clients can connect to multiple networks at the same time, using different access technologies and network architectures like Wi-Fi, LTE, and DSL. The users' quality of experience and the overall network utilization and efficiency may be improved through smart selection and combination of access and core network paths that can dynamically adapt to changing network conditions ✨.
This doc presents a unified problem statement and introduces a solution for managing multiconnectivity 🧚. The authors built the solution from their experiences in multiple standards bodies, including the IETF and the 3GPP. BUT, this doc is not an Internet Standards Track spec, and it does not represent the consensus opinion of the IETF 🙈.
This doc describes requirements, solution principles, and the architecture of the Multi-Access Management Services (MAMS) framework. MAMS aims to provide the best performance while staying 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, all to keep the network efficient and the app performance the best it can be 🔥.
Status of This Memo 🌈
This document is not an Internet Standards Track specification. It's published for informational purposes 🍓.
This is a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose 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 💀.
For the current status, any errata, and how to send feedback, check 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' Addresses1. Introduction ✨
okay so MAMS (Multi-Access Management Services) is a programmable framework 🎀 that helps pick network paths in a multi-access (MX) communication environment, based on what the application actually needs 💅. It uses network intelligence and policies to keep adapting how traffic gets spread across the selected paths, and which user-plane treatments get applied (like encryption for transport over Wi-Fi, or tunneling to get past a NAT between the client and the multipath proxy), as network and link conditions change 🦋. The path selection and configuration messages ride along as user-plane data between the network functional elements and the client, so they have zero impact on the control-plane signaling of the underlying access networks 🫶. Like, in a multi-access network with LTE and Wi-Fi, the existing LTE and Wi-Fi signaling procedures still set up their own connections, and the MAMS-specific control-plane messages just travel as LTE or Wi-Fi user-plane data 🧚.
The MAMS framework can make a smart pick of a flexible combo of access paths and core network paths, and it can choose the user-plane treatment for traffic spread across them 💖. So it's a broad programmable framework that does way more than just sharing network policies, which is what the Access Network Discovery and Selection Function (ANDSF) [ANDSF] does. ANDSF offers policies and rules to help 3GPP clients discover and select available access networks 🌸. MAMS also lets you choose and configure the user-plane treatment for traffic over the paths, based on what the application needs 👑.
The MAMS framework mechanisms aren't tied to any specific access network types or user-plane protocols (for example TCP, UDP, Generic Routing Encapsulation (GRE) [RFC2784] [RFC2890], or Multipath TCP (MPTCP) [RFC6824]) 🌈. It coexists with and complements those existing protocols by giving a way to negotiate and configure them so they fit a given multi-access scenario, based on client and network capabilities and the specific needs of each access network path ⭐. MAMS also allows load balancing of traffic flows across the selected access network paths, and the exchange of network state information that network intelligence can use to optimize how those protocols perform 💜.
This document lays out the requirements, solution principles, functional architecture, and protocols for realizing the MAMS framework 📝. A big goal here is to make sure MAMS needs either minimum dependency or (even 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 🦋. That's what makes the scheme "future proof": existing access and core networks can evolve their technologies independently, and new access technologies can slot in seamlessly 🔥.
The solution in this document was 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 💅. Those are the only ones that count as requirement words, so if you see them in lowercase, they're just regular words 🫶.
Here's the vocab you need 📖:
- 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, 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 📶. Each technology has its own benefits and limitations depending on the scenario 🌈. Wi-Fi gives high throughput when coverage is good, but it degrades a lot as a user moves toward the edge of the Wi-Fi coverage area (typically in the range of a few tens of meters), or when the user population is large (because of a contention-based Wi-Fi access scheme) 😭. LTE networks are often capacity constrained by the limited availability of licensed spectrum 📉. But LTE's quality of service is predictable even in multi-user scenarios, thanks to controlled scheduling and licensed-spectrum usage 💅.
On top of that, using a particular access network path is often tied to its associated core network and the services that network offers 🔗. For example, say an enterprise has deployed both Wi-Fi and LTE networks. Enterprise services like printers and corporate audio/video conferencing are only reachable via Wi-Fi access connected to the enterprise-hosted (Wi-Fi) core, whereas LTE access can be used to reach operator services, including the public Internet 🏢.
So application performance in different scenarios depends on which access networks (e.g., Wi-Fi, LTE) and which network and transport protocols (e.g., VPN, MPTCP, GRE) are used 🎢. To get the best possible application performance across a wide range of scenarios, we need a framework that lets us select and flexibly combine access and core network paths, plus the protocols used for uplink and downlink data delivery 🧩.
Here's an example 🍓. In uncongested scenarios where the user's Wi-Fi coverage is good, using Wi-Fi access for both uplink and downlink to reach enterprise applications would be the best way to make sure performance stays great all the time ✨. But in congested scenarios, or when the user is getting close to the edge of their Wi-Fi coverage area, having multiple users use Wi-Fi in the uplink can lead to reduced capacity and increased delays due to contention 😵. In that case, it would be beneficial to at least use LTE access for better uplink coverage, while Wi-Fi may still keep being used for the downlink 💜.
4. Requirements
The requirements 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 selecting the combination of network paths 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, to optimize network usage and enhance 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 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 🎀
okay bestie, so the client MUST use the control-plane protocol to negotiate two things with the network ✨: (1) which access and core network paths get used for uplink and downlink, and (2) how the user-plane protocol gets treated 💅. Then the control plane MUST configure the actual user-plane data distribution function to match whatever was agreed 🔥. A common control protocol SHOULD allow creating multiple user-plane function instances that might use different user-plane (e.g., tunneling) protocol types 🦋. The whole point is keeping control-plane and user-plane functions clearly separate 🧚, so the framework stays scalable and extensible, like in architectures and implementations built on Software-Defined Networking (SDN) 💜. literally so clean 😭
4.9. Lossless Path (Connection) Switching 🌸
ngl this one is so relatable 🙈. When you switch data traffic from one path (connection) to another, packets might get lost or show up out of order 💀, and that hurts higher-layer protocols like TCP 😭. So the framework SHOULD provide the mechanisms needed to make sure the receiver gets things in order, e.g., during path switching ✨. The framework MUST NOT cause any packet loss beyond the losses that access network mobility functions might already cause 🫶. no extra drama allowed 💅
4.10. Concatenation and Fragmentation for Adaptation to MTU Differences 🦋
different network paths can have different security and middlebox (e.g., NAT) configurations, and those lead to different tunneling protocols for moving data between the network user-plane function and the client 🌈. Because of that, the effective payload sizes can differ per path (e.g., due to variable encapsulation header overheads) 🍓. So the MAMS framework SHOULD support fragmenting a single payload across MTU-sized IP packets, so IP packet fragmentation gets avoided when packets from different paths get aggregated 🧚. Also, concatenating multiple IP packets into a single IP packet to pack the MTU size more efficiently SHOULD be supported too 💖.
4.11. Configuring Network Middleboxes Based on Negotiated Protocols 🌷
this section is giving optimization energy 👑. The framework SHOULD enable identifying optimal settings, like radio link dormancy timers, binding expiry times, and supported MTUs 🔥. These get based on parameters negotiated between the client and the network, and then used to configure middleboxes so user-plane protocols run efficiently 🫶. For example, you'd configure a NAT with a longer binding expiry time when UDP is used instead of TCP ✨ (main character config, honestly 💅).
4.12. Policy-Based Optimal Path Selection 💜
the framework MUST support both things here: implementing policies at the client 🧚, and guidance from the network for choosing network paths 🌸. The goal is to address different application requirements 💅✨.
4.13. Access-Technology-Agnostic Control Signaling 🌈
the control-plane signaling MUST NOT depend on the underlying access technology procedures 🙈. It gets carried transparently, like application data, on the user plane 🦋. The MAMS framework SHOULD support delivering control-plane signaling over existing Internet protocols, e.g., TCP or UDP 💖.
4.14. Service Discovery and Reachability 🧚
okay this one is so good 😭. There can be multiple instances of the control-plane and user-plane functional elements in the framework, either collocated or hosted on separate network elements 🍓. They're 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 then use 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 ✨
okay so this section is the big picture bestie 🔥. This document describes the Multi-Access Management Services (MAMS) framework, which dynamically selects a flexible combination of access and core network paths for uplink and downlink 🦋. It also picks the user-plane treatment for the traffic spread across the selected links 💜. The user-plane paths, and the access and core network connections, can be selected independently for uplink and downlink 🌸. For example, the network paths chosen for uplink don't put any limits on which paths get chosen for downlink 🫶. The uplink and downlink paths can be picked based on application needs and on the characteristics and available resources of different network connections 🍓. For example, a Wi-Fi connection can handle downlink for high-bandwidth data going from the network to the client 📶, while an LTE connection can carry the low-bandwidth feedback going to the application server 💖.
Also, depending on the characteristics of the access network link, different processing is needed on user-plane packets on different network paths 🌈. Encryption is needed on a Wi-Fi link to secure user-plane packets, but not on an LTE link 🔐. Tunneling is needed to keep client and network endpoints reachable over NATs 🧚. This kind of differentiated user-plane treatment can be set up by configuring user-plane protocols (e.g., IPsec) specific to each link 👑.
The MAMS framework has clearly separated control- and user-plane functions in both the network and the client ✨. The control-plane protocol lets you configure the user-plane protocols and the desired network paths for carrying application traffic 💅. The control-plane messages get 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 get dynamically distributed across multiple access networks and aggregated in the network (by the N-MADP) 🔥. The access network's diversity isn't exposed to the application servers, and stays within the scope of the elements defined in this framework 🫶. This takes a load off application servers, which 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 traffic is based on (1) negotiating 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 lets the network's intelligence 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 ✨
okay so bestie, Figure 1 is the big picture 🦋 It shows the MAMS setup for when a client is hooked up to multiple (n) networks at once. It also brings in a couple of new 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
So the NCM is the network-side brain of the control plane 🧠💅. It handles the MAMS control-plane procedures and configures the network side (N-MADP) and the client side (C-MADP) user-plane functions. That includes negotiating with the client over which available access network paths to use, which protocols to use, and what rules apply to processing user-plane traffic, plus all the link-monitoring procedures. The control-plane messages between the NCM and the CCM ride as an overlay on the user plane, so they don't mess with the underlying access networks at all. Iconic. 🫶
The CCM is the NCM's peer on the client side 📱✨. It manages multiple network connections at the client. It swaps MAMS signaling messages with the NCM to handle things like setting up the UL and DL user network path for carrying user data packets, and letting the NCM adaptively select network paths by reporting the results of link probing. On the downlink, it configures the C-MADP so application data packets can come in over any access link and still reach the right application on the client 🎀. On the uplink, it configures the C-MADP to pick the best access links for uplink data, based on a mix of local policies and network policies delivered by the NCM 💜.
The N-MADP is the network-side element that forwards user data traffic across multiple network paths, and it also does other user-plane jobs like encapsulation, fragmentation, concatenation, reordering, and retransmission 🌸. It's the distribution node that routes (1) uplink user-plane traffic to the right anchor connection heading toward the core network, and (2) downlink user traffic to the client over the right delivery connections. On the downlink, the NCM sets which delivery connections and user-plane protocols the N-MADP uses to carry the user data.
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 set by the NCM, based on static and/or dynamic network policies. Examples are assigning access and core paths for a specific user data traffic type, splitting traffic by percentage based on user volume, and link availability plus feedback from the MAMS signaling exchange with the CCM at the client 📊. The N-MADP can be configured with user-plane protocols that support both per-flow and per-packet traffic distribution across the delivery connections 🦋. On the uplink, the N-MADP picks the right anchor connection to forward user data it got from the client (through the delivery connections). The uplink forwarding rules are set by the NCM based on application requirements, like enterprise-hosted application flows going via a Wi-Fi anchor, or mobile-operator-hosted apps going via the cellular core 🏢📶.
The C-MADP is the client-side element that handles the MAMS user-plane data procedures 📲. The CCM configures it, based on the signaling exchange with the NCM and the local policies at the client. The CCM controls which delivery connections and user-plane protocols get used for uplink user data, based on the signaling messages it swaps with the NCM. The C-MADP does the forwarding of user-plane data across multiple delivery connections, along with the associated user-plane functions (like encapsulation, fragmentation, concatenation, reordering, and retransmissions) 🍓.
The NCM and N-MADP can be collocated or set up on different network nodes 🧚. The NCM can also spin up multiple N-MADP instances in the network, and it decides which N-MADP instance the client uses and the rules for spreading user traffic across those instances. This is super useful in a bunch of deployment scenarios, like these:
- Different N-MADP instances handling different sets of clients, so load gets balanced across clients ⚖️.
- Networks where the N-MADP lives on the user-plane node at the access edge or in the core network, while the NCM lives at the access edge node 🌈.
- An access network technology setup with one N-MADP instance at the core network node to manage traffic across LTE and DSL networks, and another N-MADP instance at an access network node to manage traffic across LTE and Wi-Fi networks 🛰️.
- A single client that can be configured to use multiple N-MADP instances. This helps address different application requirements, like having separate N-MADP instances for TCP-based traffic and UDP-based traffic 🔥.
Thus, the MAMS architecture flexibly addresses multiple network deployments. Periodt. 💖
7. MAMS Protocol Architecture ✨
okay, this section is all about how the protocol stacks are layered for the MAMS user-plane and control-plane functional elements 🧁 Let's gooo.
7.1. MAMS Control-Plane Protocol
Figure 2 shows the default MAMS control-plane protocol stack 🎀. WebSocket [RFC6455] is what carries the 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, which carries the user payload (like an IP Protocol Data Unit, or 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 has two layers 🌸:
- Multi-Access (MX) Convergence Layer: The MAMS framework configures this layer to do multi-access-specific tasks in the user plane 💅. It handles things like access (path) selection, multi-link (path) aggregation, splitting/reordering, lossless switching, fragmentation, or concatenation. The MX Convergence Layer can be built on 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 this layer to deal with transport-network stuff like reachability and security in the user plane 🔐. It handles 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 set independently 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 left out for the LTE link, but it's configured with IPsec to secure the Wi-Fi link 🔒. More details on the MAMS user plane are in [INTAREA-MAMS] 🧚.
8. MAMS Control-Plane Procedures ✨
8.1. Overview 💖
okay so the CCM and NCM are the ones doing the signaling chat 💬, and they use it to set up the user-plane stuff through the C-MADP (client side) and the N-MADP (network side) 🦋. how the CCM actually gets the NCM credentials (FQDN or IP address) for its first discovery messages? that's out of scope for this doc 🙈. as an example, the client could get them through provisioning or DNS queries. once discovery works, the initial NCM can hook the client up with more NCM addresses, like based on the MCC / MNC tuple it sees in the MX Discover message, and those are used for the follow-up control messages 🌸
the CCM discovers stuff and swaps capabilities with the NCM ✨. the NCM hands over the N-MADP endpoint credentials and works out the user-plane parameters with the CCM 💅. then the CCM tells the C-MADP to set up the user-plane path (like an MPTCP/UDP Proxy connection) to the N-MADP, using those credentials (like the (MPTCP/UDP) Proxy IP address and port, plus the associated core network path) and the parameters they agreed on 🎀. the NCM and CCM also trade link status info so traffic steering and user-plane treatment can keep up with network conditions that keep changing 🔥. the key procedures get the full breakdown in the subsections below 👑
+-----+ +-----+
| 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 Procedures8.2. Common Fields in MAMS Control Messages 🧚
every MAMS control message comes with these common fields, bestie 🫶
- Version: tells you which version of the MAMS control protocol it's using.
- Message Type: says what kind of message it is, like MX Discover or MX Capability Request (REQ) / Response (RSP) 💜
- Sequence Number: an auto-incremented integer that uniquely identifies a particular message exchange, like an MX Capability Request/Response pair 🍓
8.3. Common Procedures for MAMS Control Messages 🌈
this section covers the common procedures that apply to MAMS control messages, so pay attention 👀
8.3.1. Message Timeout ⏳
after sending a MAMS control message, the MAMS control-plane peer (NCM or CCM) waits for MAMS_TIMEOUT ms before timing out, but only in cases where a response was expected 🕐. the sender retransmits the message MAMS_RETRY times before it declares failure if nothing comes back 🔁. a failure means the MAMS peer is dead or unreachable, and the sender falls back to native non-multi-access / single-path mode 😭. the CCM may kick off the MAMS discovery procedure to re-establish the MAMS session ✨
8.3.2. Keep-Alive Procedure 💓
MAMS control-plane peers run keep-alive procedures so they can check that the other peers are still reachable and recover when a peer is dead 🫶. each MAMS control-plane endpoint keeps a Keep-Alive timer set to MAMS_KEEP_ALIVE_TIMEOUT 🕰️. that timer resets every time the peer gets a MAMS control message, and when it expires, an MX Keep-Alive Request gets sent 🦋
the values for MAMS_RETRY and MAMS_KEEP_ALIVE_TIMEOUT depend on the deployment, and how to get them is out of scope for this document 🙈. as an example, the client and network can get the values through provisioning. when an MX Keep-Alive Request shows up, the receiver answers with an MX Keep-Alive Response 💌. if the sender gets no MAMS control message back after MAMS_RETRY retries of the MX Keep-Alive Request, the MAMS peer declares the other peer dead or unreachable 💀. the CCM MAY initiate the MAMS discovery procedure to re-establish the MAMS session 🌸
on top of that, 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 that time, the client SHALL stop using MAMS user-plane functionality in the uplink direction until it gets 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, including this field is mandatory 💅
- Delivery Node ID: the identity of the node the client is attached to. with LTE, this is an E-UTRAN Cell Global Identifier (ECGI). with Wi-Fi, this is an AP ID or a Media Access Control (MAC) address. if the reason is "Handover", including this field is mandatory 📡
8.4. Discovery and Capability Exchange 🤝
figure 5 shows the MAMS discovery and capability exchange procedure, and it's giving main character energy 👑
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
Exchangethis procedure has the following key steps 📝
Step 1 (discovery): the CCM periodically sends an MX Discover message to a predefined (NCM) IP address/port until it gets an MX System Info message back as an acknowledgment 🔍
- the MX Discover message includes the following information:
- MAMS Version.
- Mobile Country Code (MCC) / Mobile Network Code (MNC) Tuple: an optional parameter that identifies the operator network the client is subscribed to, 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:
- Connection ID: a unique identifier for the anchor connection 🆔
- Connection Type (e.g., Wi-Fi, 5G NR, MulteFire, LTE) 📶
- 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 🧠. then it sends the MX Capability REQ message, which includes the following parameters 💫
- MX Feature Activation List: shows whether the matching feature is supported or not, like 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
the NCM then makes a unique identity for the CCM session and sends back the MX Capability Response, which includes the following info 🎀
- MX Feature Activation List: shows whether the matching feature is enabled or not, like 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: a unique session identifier for the CCM that set up the connection. if the session already exists, the existing unique session identifier is returned 🆔
- NCM ID: the unique identity of the NCM in the operator network.
- Session ID: a unique identity the NCM instance assigns to the CCM instance.
in response to the MX Capability Response, the CCM sends a confirmation (or a rejection) in the MX Capability Acknowledge 💌. the MX Capability Acknowledge includes these parameters:
- Unique Session ID: same identifier as the one given in the MX Capability Response 🫶
- Acknowledgment: shows whether the client accepted or rejected the capability exchange phase 🧐
MX ACCEPT: the CCM accepts the capability set the NCM proposed ✅MX REJECT: the CCM rejects the capability set the NCM proposed ❌
if the NCM gets an MX_REJECT, the current MAMS session gets terminated 💀
if the CCM can't keep going with the current capabilities anymore, it SHOULD send an MX Session Termination Request to end the MAMS session 🚪. in response, the NCM SHOULD send an MX Session Termination Response to confirm the termination 🌙
8.5. User-Plane Configuration ✨
okay bestie, Figure 6 is the user-plane (UP) configuration procedure 🦋 here's how the messages bounce between the CCM and the NCM 💖
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 Configurationthis procedure has two key steps 🌸
- Reconfiguration: the CCM tells the NCM about changes to the client's connections 🔥 that means setting up a brand new connection, tearing one down, or updating the parameters of one that already exists. The client kicks it off by asking for an update to the connection configuration, and then the NCM responds 💅
- UP Setup: the NCM configures the user-plane protocols at both the client and the network 🌈 it starts this by sending the MX UP Setup Configuration Request to the client, and the client confirms the set of mutually acceptable parameters with the User Plane Setup Confirmation (CNF) message 🫶
let's break these down, because they're giving a lot 😭
Reconfiguration: when the client notices that the link went up or down, or that the IP address changed (for example, through APIs the client OS provides) 👑 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: the identity of the CCM at the NCM, created by the NCM during the capability exchange phase 💜
- Reconfiguration Action: says which reconfiguration action it is (release, setup, or update) 🍓
- Connection ID: identifies the connection being reconfigured 🦋
if the Reconfiguration Action is set to "setup" or "update", the message also carries these 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, calculated at the client so the NCM can configure fragmentation and concatenation procedures [INTAREA-MAMS] at the N-MADP 🧚
- Delivery Node ID: identity of the node the client is attached to. For LTE, this is an ECGI. For Wi-Fi, this is an AP ID or a MAC address 🎀
at the very beginning of a connection setup, the CCM tells the NCM the connection status using the MX Reconfiguration Request with the Reconfiguration Action set to "setup" 🌸 the NCM acknowledges that status and swaps parameters with the CCM for user-plane setup, which we'll get into next 💖
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 🔥 then it tells the CCM which user-plane protocols to set up at the client (C-MADP), plus the parameters the C-MADP needs to connect to the N-MADP 🫶
the MX UP Setup Configuration Request is used to create one or more MADP instances. Each anchor connection can have one or more configurations, called MX Configurations 👑 the request carries these 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:
- MX Configuration ID (included if more than one MX configuration is present)
- MX Convergence Method. One of the following:
- GMA
- MPTCP Proxy
- GRE Aggregation Proxy
- MPQUIC
- MX Convergence Method Parameters:
- Convergence Proxy IP Address
- Convergence Proxy Port
- Client Key
- 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
- 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 each delivery connection, include the following:
- For each active MX configuration, the following parameters are included:
- For each anchor connection, the following parameters are included:
for example, when LTE and Wi-Fi are the two user-plane accesses, the NCM tells the CCM that IPsec needs to be set up as the MX Adaptation Layer over the Wi-Fi access 🌈 the parameters are the IPsec endpoint IP address and a Pre-Shared Key. No Adaptation Layer is needed if the link is considered secure with no NAT, or a Client NAT may be used over the LTE access 🧚
as another example of the MX Convergence Method 💅 the configuration can name the MPTCP proxy, along with the parameters for connecting to it: the IP address and port of the MPTCP proxy for TCP applications 💜
once the user-plane protocols are configured, the CCM reports the status back to the NCM with the MX UP Setup Confirmation 🦋 it carries these 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:
- Delivery Connection ID
- UDP port number: if UDP-based adaptation is in use, the UDP port on the C-MADP side 🍓
- For each delivery connection, include the following:
- Number of Delivery Connections.
8.6. MAMS Path Quality Estimation ✨
okay so path quality can be estimated either passively or actively 🌸 passive measurements happen in the network by comparing the client's real-time data throughput with the capacity the network has available 🫶 in special deployments where the NCM has interfaces with access nodes, those direct interfaces can be used to gather path quality info 👑 for example, the utilization of the LTE access node (also known as Evolved Node B) the client is attached to could be used to estimate path quality without adding any extra traffic overhead 🔥 and active measurements by the client are another way to estimate it 💖
here's the flow, which is giving very clean energy 🦋
CCM NCM
| |
|<-------------- MX Path Estimation Request ---------|
|------ MX Path Estimation Results ----------------->|
| |
Figure 7: MAMS Control-Plane Procedure for Path Quality Estimationthe NCM sends these 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 it collects statistics according to the configuration below 🎀
- 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
user-plane probing is split into two phases 🌈
- Initialization Phase: a network path that the N-MADP is not using to transmit user data is considered to be in the Initialization phase. User data may still go over other available network paths 🫶
- Active Phase: a network path that the N-MADP is using to transmit user data is considered 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, following 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 🍓 then the CCM collects the Active Probe statistics from the C-MADP and sends the MX Path Estimation Results message to the NCM, following the Active Probe Results configuration 🔥
the next subsections define the control PDU encoding for Keep-Alive and Probe-REQ/ACK messages that support path quality estimation 🧚
8.6.1. MX Control PDU Definition 💌
okay so control PDUs are basically little UDP messages zipping between the C-MADP and the N-MADP 💖 they carry control messages for keep-alive or path quality estimation, aka the "is this path alive and how good is it" check 🦋 the MX probe parameters get 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 these 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 gets sent as a normal user-plane packet over the desired delivery connection, the one whose quality and reachability we need to figure out 🧚
| |
|<--------- MX Control PDU Payload ------->|
| |
+-----------+-------------------+-----+-----------------------------+
| IP Header | UDP Header | Type | CID | MX Control Message |
+-----------+-------------------+-----+-----------------------------+
Figure 8: MX Control PDU Format8.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 has just one 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, and in response the C-MADP may return the Probe-ACK message 👑
a Probe-REQ message has these 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).
okay the "R-CID" field only shows up if both Bit 0 and Bit 2 of the "Probing Flag" field are set to "1" 🙈 and Bit 2 of the "Probing Flag" field SHOULD be set to "0" if Bit 0 is "0", meaning the Probe-ACK message is not expected 💀
if the "R-CID" field isn't there 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 has one 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 Procedurethe NCM sends an MX Traffic Steering Request to steer data traffic 🎀 it's also possible to send data traffic over multiple connections at the same time, which is called aggregation 🌈 the message includes this info:
- 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 this info 💜
- 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 Procedurethe CCM sends an MX Application MADP Association Request to ask for a specific application flow to be associated 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 lets the client say which user-plane processing should go with which application flows, depending on what those flows need 🔥 the application flow is identified by its associated Traffic Flow Template 💅
the MX Application MADP Association Request includes this info:
- 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
- For each application flow, identified by the Traffic Flow Templates:
in response, the NCM sends an MX Application MADP Association Response, including this info 🌸
- Number of Application Flows.
- For each application flow, identified by the Traffic Flow Templates:
- Status (Success or Failure)
- For each application flow, identified by the Traffic Flow Templates:
8.9. MAMS Network ID Indication 📶
CCM NCM
| |
| +---------------------------------+
| |NCM determines preferred networks|
| +---------------------------------+
| |
|<----------------- MX SSID Indication -----------|
| |
Figure 11: MAMS Network ID Indication Procedurethe NCM tells the CCM which networks are preferred, so the client knows which networks it should connect to 🫶 to indicate preferred Wi-Fi networks, the NCM sends a list of WLANs in the MX SSID Indication, and each WLAN is represented by an SSID (Service Set Identifier)/BSSID (Basic Service Set Identifier)/HESSID (Homogeneous Extended Service Set Identifier) as defined in [IEEE-80211]), ✨
8.10. MAMS Client Measurement Configuration and Reporting 📡
okay so the NCM is basically the one handing out the measurement homework 📋✨ it tells the CCM which radio stats to keep an eye on, plus the thresholds where the client should speak up. bestie this is so organized 😭
CCM NCM
| |
|<--------------- MX Measurement Config ----------|
| |
+---------------------------------+ |
|Client ready to send measurements| |
+---------------------------------+ |
| |
|----- MX Measurement Report -------------------->|
| |Figure 12: MAMS Client Measurement Configuration and Reporting Procedure
so the NCM configures the CCM with the different parameters (think radio link info 📶), along with the thresholds the client has to report on. the MX Measurement Configuration message has these 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 sending the 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.
now the MX Measurement Report 📊 this is the client's reply, and it carries these parameters:
- Unique Session ID: the session identifier the client got 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:
- Average RSSI of the Wi-Fi link.
- Loading of the WLAN system.
- Reverse link throughput on the Wi-Fi link.
- Forward link throughput on the Wi-Fi link.
- Estimated reverse link throughput on the Wi-Fi link (EstimatedThroughputOutbound as defined in [IEEE-80211]).
- Estimated forward link throughput on the Wi-Fi link (EstimatedThroughputInbound, as defined in [IEEE-80211]).
- If the connection type is LTE:
- RSRP of the serving LTE link.
- RSRQ of the serving LTE link.
- Reverse link throughput on the serving LTE link.
- Forward link throughput on the serving LTE link.
- If the connection type is 5G NR:
- RSRP of the serving NR link.
- RSRQ of the serving NR link.
- Reverse link throughput on the serving NR link.
- 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
okay bestie, this is the "we're done here" 👋 procedure. at any point in MAMS processing, if the CCM or NCM can't keep supporting the MAMS functions anymore, either one can kick off a termination by sending an MX Session Termination Request to its peer. the peer SHALL acknowledge it by sending back an MX Session Termination Response message. once the session is disconnected, the CCM SHALL start a fresh procedure with an MX Discover message 🔄 an MX Session Termination Request shall contain a Unique Session ID and the reason for the termination. the possible reasons 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
so the CCM sends the MX Network Analytics Request to the NCM to ask about network stuff like bandwidth, latency, jitter, and signal quality 📈. the network runs analytics on the path measurements and the client measurement reports it already has, so the answers are based on real data, not vibes 🧠
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 then sends back the MX Network Analytics Response 💌 with analytics info that might be useful to the CCM. it includes network parameters along with their predicted likelihoods, which is giving fortune teller 🔮
The MX Network Analytics Response consists of the following parameters:
- Number of Delivery Connections.
For each delivery connection, include the following:
- Access Link Identifier:
- Connection Type
- Connection ID
- Link Quality Indicator:
- Bandwidth:
- Predicted Value (Mbps)
- Likelihood (percent)
- Prediction Validity (Validity Time, in seconds)
- Jitter:
- Predicted Value (in seconds)
- Likelihood (percent)
- Prediction Validity (Validity Time, in seconds)
- Latency:
- Predicted Value (in seconds)
- Likelihood (percent)
- Prediction Validity (Validity Time, in seconds)
- 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)
- Bandwidth:
that's the whole vibe for this part bestie 🌈💖
9. Generic MAMS Signaling Flow ✨
okay bestie, Figure 16 shows how MAMS signaling negotiates network paths and flow protocols between the client and the network 🫶 In this example, the client is connected to two networks at once, 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 FlowHere's the play-by-play 💅
- The client connects to Network 1 and gets an IP address assigned by Network 1.
- The CCM talks to the NCM functional element over the Network 1 connection, and they swap 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. 🔐
- The client sets up the connection with Network 2 and gets an IP address assigned by Network 2.
- The CCM and NCM negotiate capabilities and parameters for establishing network paths. Then the negotiated capabilities and parameters get used to configure the user-plane functions, aka 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 talks to the N-MADP to exchange and configure flow aggregation protocols, policies, and parameters, lined up with what was negotiated with the CCM.
- 4c. The CCM talks to the C-MADP to exchange and configure flow aggregation protocols, policies, and parameters, lined up with what was negotiated with the NCM.
- 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 also swap messages with access link measurements so the NCM can keep the links healthy 🌸 The NCM checks link conditions in the UL and DL across LTE and Wi-Fi, using the measurements the CCM reports and/or link-probing techniques, and then decides the policy for UL and DL user data distribution 📊 The NCM and CCM also negotiate application-level policies for sorting apps into categories, e.g., based on the Differentiated Services Code Point (DSCP), destination IP address, and figuring out which available network path should carry data for that category of apps 🧚 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 too, on top of the application policy the NCM sends over ✨
10. Relationship to IETF Technologies 💜
the MAMS framework leverages technologies developed in the IETF (like MPTCP and GRE) and gives you a control-plane framework to negotiate the use of these protocols between the client and the network 🌈 It also covers the scope limitations of other multihoming protocols 🙈 For example, the IKEv2 Mobility and Multihoming Protocol (MOBIKE [RFC4555]) scope says it's limited to multihoming between IPsec clients (tunnel mode IPsec Security Associations) and doesn't support load balancing 😭 To fix that multihoming gap, the MAMS framework supports load balancing with simultaneous use of multiple access paths by negotiating protocols like MPTCP 🔥 Unlike MOBIKE, which only applies to endpoints connected with an IPsec tunnel mode Security Association, the MAMS framework lets you use a wide range of tunneling protocols in the Adaptation Layer 🦋
11. Applying MAMS Control Procedures with MPTCP Proxy as User Plane 🧚
okay so, if the NCM decides the N-MADP should be instantiated with MPTCP as the MX Convergence Protocol, it swaps the MPTCP capability support during the discovery and capability exchange procedures 🎀 An MPTCP proxy (e.g., see [TCPM-CONVERTERS]) gets configured to be the N-MADP instance. Then the NCM hands the credentials of the MPTCP Proxy instance, along with related parameters, over to the CCM. The CCM configures the C-MADP with these parameters so it can connect to this MPTCP proxy instance 💖
Figure 17 shows 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 LayerThe client (C-MADP) starts by setting up an MPTCP connection with the N-MADP. Then the MAMS control procedures get 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 for the MAMS control procedures that configure the user plane and do dynamic optimal path selection, in a scenario where the MPTCP proxy is 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 LegHere are the salient steps in that call flow 💕 The client connects to the LTE network and gets an IP address (assume LTE is the first connection). Then it kicks off the NCM discovery procedures and exchanges capabilities, including support for MPTCP as the convergence protocol at both the network and the client 🌷
Okay so the CCM hands the LTE connection parameters over to the NCM, bestie 💖 Then the NCM passes along stuff like the MPTCP proxy IP address and port, plus the MPTCP Client Key, so the client can set up the Convergence Layer 🎀 This is super useful when the N-MADP can be reached at a different IP address or port depending on which access network you're on, because the current MPTCP signaling just can't tell apart the proxy IP and port coming from multiple access networks 🙈 The client uses the MPTCP Client Key when it creates a subflow, and that lets the N-MADP uniquely identify the client even if there's a NAT in the way. Slay 👑 The N-MADP can then tell the NCM about the subflow creation and the parameters needed for making extra subflows. Since LTE is the only connection right now, user-plane traffic just flows over the single TCP subflow on LTE 🦋 And optionally, the NCM can give the client assistance info about neighboring or preferred Wi-Fi networks it's allowed to associate with ✨
Figure 19 walks through the steps where the client sets up a Wi-Fi connection, and it's giving main character energy 🌈 The CCM tells the NCM about the new Wi-Fi connection, including stuff like the Wi-Fi IP address or the SSID. The NCM decides the Wi-Fi connection needs to be secured, so it configures the Adaptation Layer to use IPsec and sends the required parameters back to the CCM 🔥 It also gives the info needed to configure the Convergence Layer (like the MPTCP proxy IP address) and sends an MX Traffic Steering Request saying the client SHOULD use only the LTE access 💅 The NCM might do this, for example, after measurements show the Wi-Fi link isn't consistently good enough 🫶 Then, once the Wi-Fi link conditions get better, the NCM sends another MX Traffic Steering Request so Wi-Fi gets used too. That's the trigger for the client to set up 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 covers the steps where the client reports that Wi-Fi link conditions are degrading in UL 🥺 The MAMS control plane keeps an eye on the access link conditions for both Wi-Fi and LTE connections, nonstop 👀 The NCM might eventually notice more UL traffic going over Wi-Fi, and then it triggers the client to use only LTE in the UL with an MX Traffic Steering Request, so UL performance gets a glow-up 🌸
+------+ +--------+ +--------+ +-------+ +-------+ +------+
| | | | | | | | | | | |
| 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 UL and DL 😭 As Wi-Fi conditions get even worse, the NCM may decide to send an MX Traffic Steering Request telling the client to stop using Wi-Fi and use only the LTE access for both UL and DL 💀 That setup can stick around until the NCM figures out, from the reported measurements, that Wi-Fi is usable again 🧚
+------+ +--------+ +--------+ +-------+ +-------+ +------+
| | | | | | | | | | | |
| 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 ✨
Okay so, Figure 22 shows the call flow for MAMS control procedures doing dynamic optimal path selection when the Convergence and Adaptation Layer protocols are left out entirely 🦋 This scenario is all about the MAMS control plane on its own, so it's giving "just the control plane, no extras" energy 💅
In the capability exchange messages, the NCM and CCM agree that Convergence-Layer and Adaptation-Layer protocols aren't needed (or supported) 🫶 The CCM tells the NCM that the LTE and Wi-Fi links are available, and then the NCM dynamically picks which access link (Wi-Fi or LTE) to use based on the link quality measurements that get reported to it 📶✨
+------+ +--------+ +--------+ +-------+ +-------+ +------+
| | | | | | | | | | | |
| 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 Layer13. Coexistence of MX Adaptation and MX Convergence Layers 🌈
Okay, so the MAMS user plane can handle multiple instances and combos of protocols at the MX Adaptation and Convergence Layers 🧚
For example, one MX Convergence Layer instance can be MPTCP Proxy, and another can be GMA 💜 Each one can use either a UDP tunnel or IPsec for its MX Adaptation. IPsec might get set up when the network path needs securing, like to protect the TCP subflow going between the client and the MPTCP proxy 🔒
Each instance of the MAMS user plane (basically, the combo of an MX Convergence-Layer protocol and an MX Adaptation-Layer protocol) can coexist at the same time and handle different traffic types independently. Main character energy 👑
14. Security Considerations 🔐
Security is serious business, bestie. Everything in this section matters, so read it all 💀
14.1. MAMS Control-Plane Security
The NCM functional element lives on a network node that's assumed to be inside a secure network, like the operator's network, and it's assumed to be protected against hijack attacks 🏰
For deployments where the client is configured (for example, by the network operator) to use a specific network path for exchanging control-plane messages, and that path is assumed to be secure, MAMS control messages rely on the security the underlying network provides 🛡️
For deployments where the security of the network path can't be assumed, NCM and CCM implementations MUST support the "wss" URI scheme [RFC6455] and Transport Layer Security (TLS) [RFC8446] to secure the control-plane message exchange between the NCM and the CCM 🚨 This one is non-negotiable, periodt 💅
For deployments where client authentication is wanted, the WebSocket server can use any client authentication mechanism that's 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 that security can't be assumed, the NCM configures protocols (like IPsec [RFC4301] [RFC3948]) in the MX Adaptation Layer to keep things secure 🔐✨
15. Implementation Considerations 🛠️
The MAMS architecture builds on common functions in clients that can be used to deliver software updates across popular client operating systems 📲 That means rapid deployment and it reaches the large base of deployed clients, which is lowkey iconic 🌸
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 looked at by the European Telecommunications Standards Institute (ETSI) [ETSIMEC] 🌐 Its initial focus was improving QoE by using intelligence at the cellular (for example, 3GPP technologies like LTE) access edge, and now the scope is extending to access technologies beyond 3GPP 📡 The authors have evaluated and tested the applicability of the framework in this document to the MEC platform in different network configurations 🧪✨
The NCM can be hosted on a MEC cloud server that sits in the user-plane path at the edge of the multi-technology access network 🖥️ The NCM and CCM can negotiate network path combinations based on an application's needs and the user-plane protocols needed across the multiple paths 🔀 The network conditions the CCM reports to the NCM can be complemented by a Radio Analytics application [ETSIRNIS] running on the MEC cloud server, which configures the uplink and downlink access paths as radio and congestion conditions change 📊
The user-plane functional element, N-MADP, can be collocated with the NCM at the MEC cloud server (for example, for MEC-hosted applications), or it can sit on a separate network element like a common user-plane gateway across the multiple networks 🚪
Also, even where an N-MADP isn't deployed, the NCM can still be used to augment traffic-steering decisions at the client 💖
The goal of all this is to boost the end user's QoE by using the best network path for an application's needs and the current network conditions 🚀 It builds on the big wins of significantly reduced latency and the dynamic, real-time exposure of radio network information available at the MEC 🌈
17. Related Work in Other Industry and Standards Forums 🤝
The MAMS framework in this document has been incorporated into, or is proposed for incorporation into, multiple industry forums and standards as a solution for multi-access integration 🌍 This section covers that related work 📚
The Wireless Broadband Alliance industry partners published a white paper on how different multi-access integration technologies apply to different deployments, as part of their "Unlicensed Integration with 5G Networks" project [WBAUnl5G] 📝 The white paper includes the MAMS framework from 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 for its Study on Access Traffic Steering, Switching, and Splitting (ATSSS) work item 🛰️ That report, TR 23.793 [ATSSS], has a bunch of potential solutions, and Solution 1 in [ATSSS] uses a separate control plane for flexibly negotiating user-plane protocols and path measurements, which is pretty similar to the MAMS architecture in this document 🙌
The Small Cell Forum (SCF) [SCFTECH5G] plans to write a white paper for its LTE/5G and Wi-Fi work item 🎀 There's a proposal to include MAMS in it 🥰
The ETSI Multi-access Edge Computing Phase 2 technical work is looking at lots of aspects of this work, including use cases for optimizing QoE and resource utilization 🧠 The MAMS architecture and procedures in this document are included in ETSI's use cases and requirements document [ETSIMAMS] 💜
18. IANA Considerations 🎈
This document has no IANA actions 🙈
19. References ✨
19.1. Normative References ✨
okay bestie, these are the must-read docs this spec leans on so hard 📚💖
[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 🌸
these ones are the extra reading 🤓 good for context, not strictly required to build the thing
[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 💅 so it's here to give you the vibe of how MAMS works, not to set the rules
if the connection between the CCM and the NCM that carries the MAMS control-plane messages is assumed to be secure, then UDP is 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 StackAppendix B. MAMS Application Interface 🎀
this appendix walks through the MAMS Application Interface. it doesn't have normative text for the MAMS framework or protocols, but it gives you extra info you can use to build a system on top of the MAMS framework ✨
B.1. Overall Design 🧚
the CCM hosts an HTTPS server so applications can talk to it and ask for services. this document assumes, from a security point of view, that all CCMs and the communicating application instances live in a single administrative domain 🏠
the content of messages is described in JavaScript Object Notation (JSON) format. the APIs are RESTful for communication 💜
how the application finds out the endpoint of the CCM is out of scope for this document. that mechanism may instead be provided as part of the application settings 🙈
B.2. Notation 🍓
the APIs are documented 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 API's objective could not be met. see [RFC7231]. 🚨
B.4. CCM APIs 🦋
the following subsections describe the APIs the CCM exposes to applications 👑
B.4.1. GET Capabilities 🌈
the CCM provides an HTTPS GET interface as "/ccm/v1.0/capabilities" so the application can query the capabilities the CCM instance supports 🫶
+---------+ +-----------+
| | | |
| App |--------- HTTPS GET / Capabilities -------->| CCM |
| | | |
+---------+ +-----------+
Figure 24: CCM API - GET Proceduresthe 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 ✨
okay so the CCM has an HTTPS POST spot at /ccm/v1.0/app_requirements 🎀 where the app can drop the needs of its application data streams off at the CCM instance 💌
+---------+ +-----------+
| | | |
| App |-------- HTTPS POST / App Requirements ---->| CCM |
| | | |
+---------+ +-----------+
Figure 25: CCM API - POST Proceduresthe 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:
- Bandwidth
- Latency
- Jitter
B.4.3. Getting Predictive Link Parameters 🔮
the CCM also has an HTTPS GET spot at /ccm/v1.0/predictive_link_params 🧚 so the app can ask for the predicted link parameters from the CCM instance 💜
+---------+ +-----------+
| | | |
| App |----- HTTPS GET / Predictive Link Params --->| CCM |
| | | |
+---------+ +-----------+
Figure 26: CCM API - Getting Predictive Link Parametersthe CCM asks the NCM for link parameters via the MAMS Network Analytics Request Procedure (Section 8.12) and then pops that info into its response to the API call 🫶
- Number of Delivery Connections.
For each delivery connection, include the following:
- Access Link Identifier:
- Connection Type
- Connection ID
- Link Quality Indicator
- Bandwidth:
- Predicted Value (Mbps)
- Likelihood (percent)
- Prediction Validity (Validity Time, in seconds)
- Jitter:
- Predicted Value (in seconds)
- Likelihood (percent)
- Prediction Validity (Validity Time, in seconds)
- Latency:
- Predicted Value (in seconds)
- Likelihood (percent)
- Prediction Validity (Validity Time, in seconds)
- 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)
- Bandwidth:
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 mean the JSON string, number, and boolean types, respectively ✨
this document uses a little adaptation of C-style struct notation to describe JSON objects 🧁 a JSON object is basically a bunch of name/value pairs, and this doc calls each pair a field 💜 sometimes it also says attribute, and the field's name can be called the key 🔑 an optional field gets wrapped in [ ] 🎀 field names are case sensitive, so be careful bestie 😭 an array gets written as <m..n>, where m is the minimum number of values and n is the maximum 🌸 if n is *, there's no upper bound at all 🦋
here's an example. this text describes a new type Type4 with three fields, "name1", "name2", and "name3", in that order 🧚 "name3" is optional, and "name2" is an array with at least one value 💅
object { Type1 name1; Type2 name2 <1..*>; [Type3 name3;] } Type4;this doc also uses subtyping to say one type is derived from another 👑 the example below says TypeDerived is derived from TypeBase 🍓 TypeDerived includes every field defined in TypeBase 💖 if TypeBase doesn't have a "name1" field, TypeDerived gets a brand new one called "name1" ✨ if TypeBase already has a "name1" field but with a different type, TypeDerived keeps the name "name1" but uses the type defined in TypeDerived (so Type1, in the example) 🔥
object { Type1 name1; } TypeDerived : TypeBase;ngl, even with all this notation, there's no standard, machine-readable interface definition or schema in this document 🙈 extension documents can describe these things if they need to 🫶
for publishing reasons, line breaks have been slipped inside long JSON strings, and the lines after them are indented 💌 to make a valid JSON example, any line break inside a string must be swapped for a space, and any other white space after that break has to go 🦋
C.1.2. Discovery Procedure 🔍
C.1.2.1. MX Discover Message 👀
wait, this is the very first message the CCM sends to find out whether an NCM is even around in the network 🕵️♀️ it only carries the base info from Appendix C.2.1, with message_type set to mx_discover 💜
the message looks like this 💅
object {
[JSONString MCC_MNC_Tuple;]
} MXDiscover : MXBase;C.1.3. System Information Procedure 🌈
C.1.3.1. MX System Info Message 📡
the NCM sends this one to the CCM to say "hey, I support MAMS!" 🎀 on top of the base info (Appendix C.2.1), it has:
(a) NCM Connections (Appendix C.2.3).
the message looks like this ✨
object {
NCMConnections ncm_connections;
} MXSystemInfo : MXBase;C.1.4. Capability Exchange Procedure 🤝
C.1.4.1. MX Capability Request 🙌
the CCM sends this to the NCM to show off the capabilities of the CCM instance that the NCM can use, which is the one from the System Info message earlier 💖 on top of the base info (Appendix C.2.1), it has:
(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 message looks like this 🧚
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 one goes the other way, from the NCM back to the CCM 🦋 it shows off the NCM's capabilities and gives the CCM a unique session identifier 🫶 on top of the base info (Appendix C.2.1), it has:
(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 message looks like this 🌸
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 💅
the CCM sends this back to the NCM to say "yep, we accept the capabilities you sent in the MX Capability Response" 🎉 or to say no 😬 on top of the base info (Appendix C.2.1), it has:
(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 message looks like this ✨
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 🌟
the NCM sends this to the CCM to set up the user plane for MAMS 🦋 on top of the base info (Appendix C.2.1), it has:
(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 message looks like this 👑
object {
JSONNumber num_anchor_connections;
SetupAnchorConns anchor_connections;
} MXUPSetupConfigReq : MXBase;C.1.5.2. MX User-Plane Configuration Confirmation 🎀
This is the "we did it!" message 🫶. After the client has successfully set up the user plane, the CCM sends this back to confirm it. It carries the following:
- (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 message looks like this 👇
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 one is sent by the CCM to the NCM whenever any of the connections change on the client's side. On top of the base information (Appendix C.2.1), it has:
- (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 is the NCM saying "got it!" to the CCM's MX Reconfiguration Request. It only carries the base information (as defined in Appendix C.2.1), so it's very chill ✨.
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 🧪
The NCM sends this toward the CCM to set the CCM up so it will send MX Path Estimation Results. On top of the base information (Appendix C.2.1), it has:
- (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 is the CCM reporting back to the NCM on the probe estimation the NCM set up. On top of the base information (Appendix C.2.1), it has:
- (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 🛣️
The NCM sends this to the CCM to turn on traffic steering on the delivery side, for both uplink and downlink setups 💅. On top of the base information (Appendix C.2.1), it has:
- (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 is the CCM's reply to an MX Traffic Steering Request from the NCM. On top of the base information (Appendix C.2.1), it has:
- (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 💌
The CCM sends this to the NCM to pick out MADP instances from the list it got earlier in the MX UP Setup Configuration Request, based on what each application needs 🧚.
On top of 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 ✅
The NCM sends this to the CCM to confirm the MADP instances the CCM picked in its MX Application MADP Association Request. On top of the base information (Appendix C.2.1), it includes a yes-or-no on whether the request worked out 🙌.
The representation of the message is as follows:
object {
JSONBool is_success;
} MXAppMADPAssocResp : MXBase;C.1.10. MX SSID Indication 📶
The NCM sends this to the CCM to share the list of allowed SSIDs that the MAMS entity on the network side supports. It contains the list of SSIDs ✨.
Each SSID is made up of a type (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 ⚙️
okay so this message is the NCM telling the CCM how to do its period measurement reporting 📡 it's giving "here's your to-do list, bestie" 💅 The message carries a list of measurement configurations, and each element has:
- (a) Connection ID: the Connection ID of the delivery connection that the reporting is being configured for 🔗
- (b) Connection Type: the connection type being configured, which can be
"LTE","Wi-Fi", or"5G_NR"📶 - (c) Measurement Report Configuration: the 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 gets sent by the CCM to the NCM periodically after the measurement configuration is set up 🔁 On top of the base info, it has:
- (a) Unique Session ID: same identifier as the one given in the MX Capability Response. Described in Appendix C.2.2 🆔
- (b) Measurement report: a measurement report for each delivery connection, 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 when the Keep-Alive timer expires or a handover event happens ⏰ The peer shall respond to this request with an MX Keep-Alive Response. If there's 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 💀
On top of the base info, it contains:
- (a) Keep-Alive Reason: the reason for sending this message, which 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) that the handover is executed to 🎯
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 ✅
when an NCM or CCM gets an MX Keep-Alive Request from a peer, it shall immediately reply with an MX Keep-Alive Response on the same delivery path the request came in on 🛤️ On top of the base info, it carries 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 🛑
if the NCM or CCM can't handle MAMS anymore for any reason, it can send an MX Session Termination Request to the peer 😭 On top of the base info, it has a Unique Session ID and the reason for the termination. That reason 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 🧹
when an NCM or CCM gets an MX Session Termination Request from a peer, it shall respond with an MX Session Termination Response on the same delivery path the request arrived on, 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 ask for parameters like bandwidth, jitter, latency, and signal quality, as predicted by the network analytics function 📉 On top of the base info, it contains:
- (a) Unique Session ID: same identifier as the one given in the MX Capability Response. Described in Appendix C.2.2 🆔
- (b) Parameter List: the list of parameters the CCM is interested in: 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 the client has, the NCM reports the requested parameter predictions and their respective likelihoods (between 1 and 100 percent) 🎲
On top of the base info, it contains:
- (a) Number of Delivery Connections: the number of delivery connections 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 the Parameter name is
"signal_quality", this qualifies the quality parameter as"lte_rsrp","lte_rsrq","nr_rsrp","nr_rsrq", or"wifi_rssi"📡 - (c) Predicted Value: the predicted value of the parameter and, if applicable, the additional parameter 🔮
- (d) Likelihood: a stochastic likelihood of the predicted value 🎰
- (e) Validity Time: the time duration for which the predictions are valid ⏳
- (a) Parameter Name: name of the parameter being predicted. Can be one of
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 info that every message between the CCM and NCM exchanges shall have as mandatory information. It contains:
- (a) Version: the version of MAMS used 🏷️
- (b) Message Type: the message type being sent. These are the 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: a sequence number that uniquely identifies 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 connections available at the NCM for MAMS connectivity toward the client 🛰️ It contains a list of NCM connections available, where each connection has:
- (a) Connection Information: see Appendix C.2.4 🔗
- (b) NCM Endpoint Information: 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 gives you the mapping of connection ID and connection type 🗺️ It contains:
- (a) Connection ID: a unique number identifying the connection 🪪
- (b) Connection Type: the type of connection, which 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 ✨
okay bestie, this one is the feature checklist 💅 It lists every feature along with whether it's switched on 🔥 Each feature status has two parts:
- (a) Feature Name: the name has to be one of these 🌸
"lossless_switching"
"fragmentation"
"concatenation"
"uplink_aggregation"
"downlink_aggregation"
"measurement"- (b) Active status: "true" means the feature is on, and "false" means it's off 🫶
Here's the shape:
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 holds the list of Connection Information items (Appendix C.2.4) that are supported on the anchor (core) side. Main character energy 👑
The representation of this data type is as follows:
object {
ConnectionInfo items <1..*>;
} AnchorConnections;C.2.7. Delivery Connections 🧚
Same vibe as the anchor one, but this list is for the delivery (access) side 💜 It's the list of Connection Information (Appendix C.2.4) items supported there.
The representation of this data type is as follows:
object {
ConnectionInfo items <1..*>;
} DeliveryConnections;C.2.8. Method Support 🍓
This data type tells you how things stand for one particular convergence or adaptation method ✨ It has two fields:
- (a) Method: the name of the method.
- (b) Supported: whether that method is supported or not. The 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 is the full list of convergence methods and whether each one is supported. 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 💅
Same energy as the convergence list, except this one is for 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 one is the setup config for each anchor connection that the client needs to have in place 🔥 Along with the connection ID and the anchor connection type, it includes:
- (a) Number of Active MX Configurations: if more than one active configuration is present for this anchor, this tells you how many there are.
- (b) The following convergence parameters are provided for each active configuration:
- (1) MX Configuration ID: present if there are multiple active configurations. It identifies the configuration for this MADP instance ID.
- (2) Convergence Method: the convergence method that got selected. It 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: how many delivery connections (access side) 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;Each anchor connection configuration is defined like this:
object {
[JSONNumber num_active_mx_conf;]
ConvergenceConfig convergence_config
} SetupAnchorConn : ConnectionInfo;and each convergence configuration is defined like this:
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 holds the parameters used by the convergence method, and it has:
- (a) Proxy IP: the IP address of the proxy that the selected convergence method provides.
- (b) Proxy Port: the port of the proxy that the selected convergence method provides.
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 that get configured on the client 💜 Each delivery connection is defined by its connection information (Appendix C.2.4) and optionally contains:
- (a) Adaptation Method: the name of the selected adaptation method. It 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, this flag says whether 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, 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 gives you the results of the init probe request that the NCM made ✨ It has three pieces of info:
- (a) Lost Probes: the percentage of probes lost.
- (b) Probe Delay: the average delay of a probe message, in microseconds.
- (c) Probe Rate: the 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 gives you the results of the active probe request that the NCM made. It has one piece of info:
- (a) Average Probe Throughput: the 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 is the list of connections that are enabled on the delivery side for 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 is the list of connections and parameters enabled on the delivery side for the uplink direction 🫶
The uplink delivery is made up of multiple uplink delivery entities. Each entity has a Traffic Flow Template (TFT) (Appendix C.2.16) and a list of connection IDs in the uplink, where traffic that matches that Traffic Flow Template can be redirected.
The representation of this data type is as follows:
object {
ULDeliveryEntity ul_del <1..*>;
} ULDelivery;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 in [ServDesc3GPP] 💅
The Traffic Flow Template in MAMS consists of one or more of the following:
- (a) Remote Address and Mask: the IP address and subnet for remote addresses, written in Classless Inter-Domain Routing (CIDR) notation. Default: "0.0.0.0/0".
- (b) Local Address and Mask: the IP address and subnet for local addresses, written in CIDR notation. Default: "0.0.0.0/0"
- (c) Protocol Type: the IP protocol number of the payload carried by an IP packet (e.g., UDP, TCP). Default: 255.
- (d) Local Port Range: the range of local ports this Traffic Flow Template applies to. Default: Start=0, End=65535.
- (e) Remote Port Range: the range of remote ports this Traffic Flow Template applies to. 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: the flow label for IPv6, applicable only for the 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 📡✨
okay so this one is the NCM telling the CCM what to measure and report, bestie 💅 it's giving config settings, and it's lowkey so organized 🫶
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 📊💖
okay this one is the CCM reporting back what it measured, iykyk 🙈 it's the receipts, bestie 💅 for each access network it measured, it includes the connection info, the Delivery Node ID (that's the cell ECGI or the Wi-Fi Access Point ID or MAC address, or whatever the equivalent identifier is in other technologies 🧚), and the actual measurement from the last measurement period. no cap, main character energy 👑
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 🧾🌈
okay bestie, this is where the schemas live, and they're giving structured and so clean ✨ no notes 😭
C.3.1. MX Base Schema 🎀💜
this is the base schema, and it's the whole vibe 🫶 it's got the draft-04 JSON Schema link, the definitions for the message types, the sequence numbers, and the version, all wrapped up with its own id. literally iconic 💅
{
"$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 💖
okay this is the big definitions file, and it's giving everything 💅 all the shared building blocks live here so the other schemas can just point back to them 🧚
{
"$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 🦋
this one is the simple little hello 👋 it only lets three fields through, and additionalProperties is set to false so nothing extra sneaks in 🙈
{
"$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 🌸
same three basics up top, but then we add ncm_connections as the main event ✨ it's an array where each item pulls in a connection and an NCM end point from the definitions file
{
"$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 🎀
this is where the requester gets to list everything it wants to talk about 💅 adaptation methods, anchor and delivery connections, convergence methods, active features, and the two counts at the bottom 🫶
{
"$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 ✨
okay so this one's the path estimation results message, and it's giving clean schema energy 💅
{
"$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 🎀
this one's the SSID indication, and the ssid_list is literally an array of little objects, so iconic 🧚
{
"$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 🦋
bestie, this is the measurement config, and it's got a definitions block with its own meas_conf in it. main character energy 👑
{
"$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 📊
okay the measurement report is where all the good stats live 🔥 measurement_reports nests a whole bunch of stuff inside it, so get comfy
{
"$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 💖
the keep-alive request, aka the "hey, still here?" message 🫶
{
"$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 🌸
and the reply! short and sweet, just the basics 💅
{
"$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 💀
the termination request, which is giving "we're done here, bye" 🙈 note that the id in this one points at the keep-alive request file, and that's exactly how it appears in the original, so I'm leaving it as is
{
"$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 🍓
and the goodbye reply, very polite of it 🫶
{
"$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 🔮
so this is where you ask for the network predictions, and you list the params you want 👀
{
"$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 🧠
the response is where the predictions finally show up, and it's a whole nested situation 🌈
{
"$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 🎀
okay now the fun part, real examples you can actually look at! 🦋
C.4.1. MX Discover 👋
the very first hello, sequence number 1, no frills
{
"version" : "1.0",
"message_type" : "mx_discover",
"sequence_num" : 1
}C.4.2. MX System Info 💻
this one tells you about the connections, LTE and Wi-Fi, each with its own end point 🌍
{
"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 ✨
okay this example is a whole capability request, and it's packed with features, connections, and methods, so grab a snack 🍿
{
"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 ✨
Okay, this one is a whole vibe 💅
{
"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 🔥
Okay this one is long, bestie, so grab a snack 🍓
{
"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 💖
Okay bestie, here's the keep-alive request, and it's giving "checking in on you" energy 🫶
{
"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 🌸
And the reply is simple and iconic, same sequence number and same session ID, no extra drama ✨
{
"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 🦋
Time to close things out, and the reason is literally MX_NORMAL_RELEASE 🍓
{
"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 🧚
The response mirrors the request, sequence number 13 and the same session ID, so everyone's on the same page 💅
{
"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 🔥
Here the client asks for two params, jitter and latency, and honestly it's a very main character move 👑
{
"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 🌈
Now the juicy part! The response gives predictions for each connection, a Wi-Fi one and an LTE one, with prediction, likelihood and validity time for both jitter and latency. Obsessed 😭
{
"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 🎀
Okay so this appendix is an example of the APIs the CCM exposes to the applications on the client side 🧚 It's written up in OpenAPI using Swagger 2.0, so every endpoint, response and definition is laid out below, no cap 📋
{
"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 💖
okay so, here's a simple client-side version in Python. it's giving clean and easy to follow 🫶
#!/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 🧚
and now the server side, the other half of the conversation 💅 this one loads the certs, sets up the TLS context, and waits for the client to say hi
#!/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 result of a whole crowd of engineers, not just the authors of this doc. bestie, everyone deserves a shoutout! 🎀 the people who contributed, listed alphabetically by first name, are Barbara Orlandi, Bongho Kim, David Lopez-Perez, Doru Calin, Jonathan Ling, Lohith Nayak, and Michael Scharf. 🫶
Contributors 💜
the authors also want to thank these extra contributors, listed alphabetically 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 was instrumental in the conceptualization and development of the solution principles for the MAMS framework. 👑 Shuping Peng was a key contributor in refining the framework and the 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
📦 where this page comes from
- ietf: rfc8743 2020-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms