| INTAREA | S. Kanugovi |
| Internet-Draft | Nokia |
| Intended status: Informational | F. Baboescu |
| Expires: March 8, 2019 | Broadcom |
| J. Zhu | |
| Intel | |
| J. Mueller | |
| AT&T | |
| S. Seo | |
| Korea Telecom | |
| September 4, 2018 |
Multiple Access Management Services
draft-kanugovi-intarea-mams-framework-02
In multiconnectivity scenarios the end-user devices can simultaneously connect to multiple networks based on different access technologies and network architectures like WiFi, LTE, DSL. Both the quality of experience of the users and the overall network utilization and efficiency may be improved through a smart selection and combination of access and core network paths that can dynamically adapt to changing network conditions. The document presents a unified problem statement and introduces a solution for managing multiconnectivity. The solution has been developed based on the authors’ experience in multiple standards bodies including the IETF and 3GPP and is not an Internet Standard. It describes the requirements, solution principles and the architectural framework that ensures best performance and can be easily implemented in a wide variety of multiconnectivity deployments. It specifies the the protocol multi-access management to 1) flexibly select the best combination of access and core network paths for uplink and downlink, as well as 2) determining the user plane treatment and traffic distribution over the selected links ensuring better network efficiency and enhanced application performance.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 8, 2019.
Copyright (c) 2018 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Multi Access Management Services (MAMS) is a programmable framework that provides mechanisms for flexible selection of network paths in a multi-access communication environment, based on application needs. It leverages network intelligence and policies to dynamically adapt traffic distribution across selected paths and user plane treatment to changing network/link conditions. The network path selection and configuration messages are carried as user plane data between the functional elements in the network and the end-user device, and thus without any impact to the control plane signaling schemes of the underlying access network(s). For example, in a multi-access network with LTE and WiFi technologies, existing LTE and existing WiFi signaling procedures will be used to setup the LTE and WiFi connections, respectively, and MAMS specific control plane messages are carried as LTE or WiFi user plane data. The proposed MAMS framework offers the capabilities of smart selection and flexible combination of access paths and core network paths, as well as the user plane treatment when the traffic is distributed across the selected paths. Thus, it is a broad programmable framework providing functions beyond just sharing network policies, e.g. ANDSF that provides policies/rules for assisting 3GPP devices to discover and select available access networks. Further, it allows choosing and configuring user plane treatment for the traffic over the multiple paths, depending on needs of the application.
MAMS mechanisms are not dependent on any specific access network type or user plane protocols like TCP, UDP, GRE, MPTCP etc. It co-exists and complements the existing protocols by providing a way to negotiate and configure these protocols based on client and network capabilities per access basis to match their use for a given multi-access scenario. Further, it allows load balancing of the traffic flows across the selected multiple accesses and exchange of network state information to be used for network intelligence to optimize the performance of such protocols.
The document presents the requirements, solution principles, functional architecture, and protocols for realizing the MAMS framework. An important goal for MAMS is to ensure that it either requires minimum dependency or (better) no dependency on the actual access technologies of the participating links, beyond the fact that MAMS functional elements form an IP-overlay across the multiple paths. This allows the scheme to be future proof by allowing independent technology evolution of the existing access and core networks as well as, seamless integration of new access technologies.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
"Client": The end-user device supporting connections with multiple access nodes, possibly over different access technologies.
"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 like WiFi airlink, LTE airlink, or DSL.
"Core": The functional element that anchors the client IP address used for communication with applications via the network.
"Network Connection manager"(NCM): A functional entity in the network that handles MAMS control messages from the client and configures distribution of data packets over the multiple available access and core network paths, and user plane treatment of the traffic flows.
"Client Connection Manager" (CCM): A functional entity in the client that exchanges MAMS Signaling with the Network Connection Manager and configures the multiple network paths at the client for transport of user data.
"Network Multi Access Data Proxy" (N-MADP): This functional entity in the network handles the user data traffic forwarding across multiple network paths. N-MADP is responsible for MAMS related user-plane functionalities in the network.
"Client Multi Access Data Proxy" (C-MADP): This functional entity in the client handles the user data traffic forwarding across multiple network paths. 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.
Typically, an end-user device has access to multiple communication networks based on different technologies, say LTE, WiFi, DSL, MuLTEfire, for accessing application services. Different technologies exhibit benefits and limitations in different scenarios. For example, WiFi provides high throughput for end users when under good coverage, but the throughput degrades significantly as the user moves closer to the edge of WiFi coverage (typically in the range of few tens of meters) or with large user population (due to contention based WiFi access scheme). In LTE networks, the capacity is often constrained by the limited availability of licensed spectrum. However, the quality of the service is predictable even in multi-user scenarios due to controlled scheduling and licensed spectrum usage.
Additionally, the use of a particular access network path is often coupled with the use of its associated core network and the services that are offered by it. For example, in an enterprise that has deployed both WiFi and LTE networks, the enterprise services, like printers, Corporate Audio and Video conferencing, are accessible only via WiFi access connected to the enterprise hosted (WiFi) core, whereas the LTE access can be used to get operator core anchored services including access to public Internet.
Thus, application performance in different scenarios becomes dependent on the choice of the access networks (e.g. WiFi, LTE, etc.) and the used network and transport protocols (e.g. VPN, MPTCP, GRE etc.). . Therefore, to achieve the best possible application performance in a wide range of scenarios, a framework is needed that allows the selection and flexible combination of access and core network paths and used protocols for uplink and downlink data delivery.
For example, to ensure best performance for enterprise applications at all times, in uncongested scenarios, when the user is under good WiFi coverage, it would be beneficial to use WiFi access in both uplink and downlink for connecting to enterprise applications. However, in congested scenarios or when the user is getting close to the edge of its WiFi coverage, the use of WiFi in uplink by multiple users can lead to degraded capacity and increased delays due to contention. In this case, it would be beneficial to at least use the LTE access for increased uplink coverage while WiFi may still continue to be used for downlink.
The requirements set out in this section are for the definition of behavior of the MAMS mechanism and the related functional elements.
The access nodes may use different technology types like LTE, WiFi, etc. The framework, however, MUST agnostic to the type of underlying technology used at the access network.
The network path selection and user data distribution MUST work transparently across various transport deployments that include e2e IPsec, VPNs, and middleboxes like NATs and proxies.
Client should be able to transmit on the uplink and, receive on the downlink, using one or more accesses. The selection of the access paths for uplink and downlink SHOULD happen independent of each other.
A client SHOULD flexibly select the Core, independent of the access paths used to reach the Core, depending on the application needs, local policies and the result of MAMS control plane negotiation.
The framework MUST have the ability to determine the quality of each of the network paths, e.g. access link delay and capacity. The network path quality information needs to be considered in the logic for selection of the combination of network paths to be used for transporting user data. The path selection algorithm can use network path quality information, in addition to other considerations like network policies, for optimizing network usage and enhancing QoE delivered to the user.
The framework MUST support 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 re-ordering needs to be done at the receiver. The framework MUST allow flexibility to choose the flow steering and aggregation protocols based on capabilities supported by the client and the network data plane entities. The multi-connection aggregation solution MUST support existing transport and network layer protocols like TCP, UDP, GRE. The framework MUST allow use and configuration of existing aggregation protocols such as Multi-Path TCP(MPTCP) and SCTP.
The framework MUST leverage commonly available transport, routing and tunneling capabilities to provide user plane interworking functionality. The addition of functional elements in the user plane path between the client and the network MUST not impact the access technology specific procedures. This makes solution easy to deploy and scale when different networks are added and removed.
The client MUST use the control plane protocol to negotiate with the network, the choice of access and core network paths for both uplink and downlink, as well as the user plane protocol treatment. The control plane MUST configure the actual user plane data distribution function per this negotiation. A common control protocol SHOULD allow creation of multiple user plane function instance with potentially different user plane (e.g. tunneling) protocol types. This enables maintaining a clear separation between the control and data plane functions, allowing the framework to be scalable and extensible, e.g. using SDN based architecture and implementations.
When switching data traffic from one path (connection) to another, packets may be lost or delivered out-of-order, which will have negative impacts on the performance of higher layer protocols, e.g. TCP. The framework SHOULD provide necessary mechanisms to ensure in-order delivery at the receiver, e.g. during path switching. The framework MUST not cause any packet loss beyond that of access network mobility functions may cause.
Different network paths may have different security and middlebox (e.g NAT) configurations, which will lead to use of different tunneling protocols for transport of data between the network user plane function and the client. As a result, different effective payload sizes (e.g. due to variable encapsulation header overheads) per network path are possible. Hence, MAMS framework SHOULD support fragmentation of a single IP packet payload across MTU sized IP packets to avoid IP fragmentation when aggregating packets from different paths. Further, concatenation of multiple IP packets into a single IP packet to improve efficiency in packing the MTU size should also be supported.
The framework SHOULD enable identification of the optimal parameters that may be used for configuring the middle-boxes, like radio link dormancy timers, binding expiry times and supported MTUs, for efficient operation of the user plane protocols, based on parameters negotiated between the client and the network, e.g. Configuring longer binding expiry time in NATs when UDP transport is used in contrast to the scenario where TCP is configured at the transport layer.
The framework MUST support consideration of policies at the client, in addition to guidance from the network, for network path selection addressing different application requirements.
The control plane signaling MUST NOT be dependent on the underlying access technology procedures, e.g. be carried transparently as user plane. It should support delivery of control plane signaling over the existing Internet protocols, e.g. TCP or UDP.
There can be multiple instances of the control and user plane functional elements of the framework, either collocated or hosted on separate network elements, and reachable via any of the available user plane paths. The client MUST have flexibility to choose the appropriate control plane instance in the network and use the control plane signaling to choose the desired user plane functional element instances. The choice can be based on considerations like, but not limited to, quality of link through which the network function is reachable, client preferences, pre-configuration etc.
This document proposes the Multiple Access Management Services(MAMS) framework for dynamic selection and flexible combination of access and core network paths independently for the uplink and downlink, as well as the user plane treatment for the traffic spread across the selected links. MAMS framework consists of clearly separated control and user plane functions in the network and the client. The control plane protocol allows configuration of the user plane protocols and desired network paths for transport of application traffic. The control plane messages are carried as user plane data over any of the available network paths between the peer control plane functional elements in the client and the network . Multiple user plane paths are dynamically distributed across multiple access networks and aggregated in side the common core network. The access network diversity is not exposed to the application servers but kept within the scope of the elements defined in this framework. This offloads the application servers from reacting to access link changes caused to mobility events or changing of link characteristics. The selection of paths and user plane treatment of the traffic, is based on negotiation of capabilities (of device and network) and probing of network link quality between the user plane functional elements at the end-user device/client and the network. The framework enables leveraging network intelligence to setup and dynamically configure the best access network path combination based on device and network capabilities, application needs and knowledge of the network state.
+--------------------------------------------------------+
| +---------------+ +---------------+ |
| ! ! ! ! |
| !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 | |
| | | n/w 1 | | n/w 'n' | |
| +------------------+ +---------/-----+ |
+-----------------------------\----------------/---------+
| \ /
| +---- -\------------/-+
| | +---+ \ |------+ / |
+------------+CCM | \|C-MADP|/ |
| +---+ +------+ |
| Client |
+---------------------+
Figure 1: MAMS Reference Architecture
Figure 1 illustrates MAMS architecture for the scenario of a client served by multiple (n) networks. It introduces the following functional elements,
NCM: It is the functional element in the network that handles the MAMS control plane procedures. It configures the network (N-MADP) and client (C-MADP) user plane functions like negotiating the client on the use of available access network paths, protocols and rules for processing the user plane traffic, as well as link monitoring procedures. The control plane messages between the NCM and CCM are transported as an overlay, without any impact to the underlying access networks.
CCM: It is the peer functional element in the client for handling MAMS control plane procedures. It manages multiple network connections at the client. It is responsible for exchange of MAMS signaling messages with the NCM for supporting functions like UL and DL user network path configuration for transporting user data packets, link probing and reporting to support adaptive network path selection by NCM. In the downlink, for the user data received by the client, it configures C-MADP such that application data packet received over any of the accesses to reach the appropriate application on the client. In the uplink, for the data transmitted by the client, it configures the C-MADP to determine the best access links to be used for uplink data based on a combination of local policy and network policy delivered by the NCM.
N-MADP: It is the functional element in the network that handles the user data traffic forwarding across multiple network paths, as well as other user-plane functionalities like encapsulation, fragmentation, concatenation, reordering, retransmission, etc. It is the distribution node that routes the uplink user plane traffic to the appropriate anchor connection towards the core network, and the downlink user traffic to the client over the appropriate delivery connection(s). In the downlink, the NCM configures the use of delivery connections, and user plane protocols at the N-MADP for transporting user data traffic. The N-MADP should implement ECMP support for the down link traffic. Or alternatively, it may be connected to a router with ECMP functionality. The load balancing algorithm at the N-MADP is configured by the NCM, based on static and/or dynamic network policies like assigning access and core paths for specific user data traffic type, data volume based percentage distribution, and link availability and feedback information from exchange of MAMS signaling with the CCM at the Client.. N-MADP can be configured with appropriate user plane protocols to support both per-flow and per-packet traffic distribution across the delivery connections. In the uplink, N-MADP selects the appropriate anchor connection over which to forward the user data traffic, received from the client (via the delivery connections). The forwarding rules in the uplink at the N-MADP are configured by the NCM based on application requirements, e.g. Enterprise hosted Application flows via Wi-Fi Anchor, Mobile Operator hosted applications via the Cellular Core.
C-MADP: It is the functional element in the client that handles the MAMS user plane data procedures. C-MADP is configured by CCM based on signaling exchange with NCM and local policies at the client. The CCM configures the selection of delivery connections and the user plane protocols to be used for uplink user data traffic based on the signaling exchanged with NCM. The C-MADP entity handles user plane data forwarding across multiple delivery connections and associated user-plane functions like encapsulation, fragmentation, concatenation, reordering, retransmissions, etc.
The NCM and N-MADP can be either collocated or instantiated on different network nodes. NCM can setup multiple N-MADP instances in the network. NCM controls the selection of N-MADP instance by the client and the rules for distribution of user traffic across the N-MADP instances., This is beneficial in multple deployment scenarios, like the following examples.
Thus, MAMS architecture flexibly addresses multiple network deployments.
This section describes the protocol structure for the MAMS User and Control plane functional elements.
+------------------------------------------+
| Multi Access (MX) Control Message |
| |
+------------------------------------------+
| WebSocket |
| |
+------------------------------------------+
| TCP/TLS |
| |
+------------------------------------------+
Figure 2: TCP-based MAMS Control Plane Protocol Stack
Figure 2 shows the default MAMS control plane protocol stack. WebSocket is used for transporting management and control messages between NCM and CCM.
+-----------------------------------------------------+
| User Payload (e.g. IP PDU) |
+-----------------------------------------------------+
+-----------------------------------------------------------+
| +-----------------------------------------------------+ |
| | Multi Access (MX) Convergence Sublayer | |
| +-----------------------------------------------------+ |
| +-----------------------------------------------------+ |
| | MX Adaptation | MX Adaptation | MX Adaptation | |
| | Sublayer | Sublayer | Sublayer | |
| | (optional) | (optional) | (optional) | |
| +----------------++--------------+-+------------------+ |
| | Access #1 IP | Access #2 IP | Access #3 IP | |
| +-----------------------------------------------------+ |
| MAMS User Plane Protocol Stack|
+-----------------------------------------------------------+
Figure 3: MAMS User Plane Protocol Stack
Figure 3 shows the MAMS user plane protocol stack.
It consists of the following two Sublayers:
CCM and NCM exchange signaling messages to configure the user plane functions, C-MADP and N-MADP, at the client and network respectively. The means for CCM to obtain the NCM credentials (FQDN or IP Address) for sending the initial discovery messages are out of the scope of MAMS document. As an example, the client can obtain the NCM credentials using methods like provisioning, DNS query. Once the discovery process is successful, the (initial) NCM can update and assign additional NCM addresses, e.g. based on MCC/MNC tuple information received in the MX Discovery Message, for sending subsequent control plane messages.
+-----+ +-----+ | CCM | | NCM | +--+--+ +--+--+ | Discovery and | | Capability | | Exchange | <----------------------> | | | User Plane | | Protocols | | Setup | <----------------------> | Path Quality | | Estimation | <----------------------> | Network capabilities | | e.g. RNIS[ETSIRNIS] | <----------------------+ | | | Network policies | <----------------------+ + +
Figure 4: MAMS Control Plane Procedures
CCM discovers and exchanges capabilities with the NCM. NCM provides the credentials of the N-MADP end-point and negotiates the parameters for user plane with the CCM. CCM configures C-MADP to setup the user plane path (e.g. MPTCP/UDP Proxy Connection) with the N-MADP based on the credentials (e.g. (MPTCP/UDP) Proxy IP address and port, Associated Core Network Path), and the parameters exchanged with the NCM. Further, NCM and CCM exchange link status information to adapt traffic steering and user plane treatment with dynamic network conditions. The key procedures are described in details in the following sub-sections.
Each MAMS control message consists of the following common fields:
This section describes the common procedures for MAMS Control Messages.
MAMS Control plane peer (NCM or CCM) waits for a duration of MAMS_TIMEOUT ms, after sending a MAMS control message, before timing out when expecting a response. The sender of the message will retransmit the message for MAMS_RETRY times before declaring failure. A failure implies that the MAMS peer is dead, and the sender reverts back to native non-multi access/single path mode. CCM may initiate the MAMS discovery procedure for re-establishment of the MAMS session.
MAMS Control plane peers execute the keep alive procedures to ensure that peers are reachable and to recover from dead-peer scenarios. Each MAMS control plane end-point maintains a MAMS_KEEP_ALIVE timer that is set for duration MAMS_KEEP_ALIVE_TIMEOUT. MAMS_KEEP_ALIVE timer is reset whenever the peer receives a MAMS Control message. When MAMS_KEEP_ALIVE timer expires, MAMS KEEP ALIVE REQ message is sent. On reception of a MAMS KEEP ALIVE REQ message, the receiver responds with a MAMS KEEP ALIVE RSP message. If the sender does not receive a MAMS Control message in response to MAMS_RETRY number of retries of MAMS KEEP ALIVE REQ message, the MAMS peer declares that the peer is dead. CCM may initiate MAMS Discovery procedure for re-establishment of the MAMS session.
CCM shall additionally send MX KEEP ALIVE REQ message immediately to NCM whenever it detects a handover from one base station/access point to another. During this time the user equipment shall stop using MAMS user plane functionality in uplink direction till it receives a MX KEEP ALIVE RSP from NCM.
MX KEEP ALIVE REQ includes following information:
CCM NCM
| |
+------- MX Discovery Message ---------------------->|
| +-----------------+
| |Learn CCM |
| | IP address |
| |& port |
| +-----------------+
| |
|<--------------------------------MX System INFO-----|
| |
|---------------------------------MX Capability REQ->|
|<----- MX Capability RSP----------------------------|
|---------------------------------MX Capability ACK->|
| |
+ +
Figure 5: MAMS Control Procedure for Discovery & Capability Exchange
Figure 5 shows the MAMS discovery and capability exchange procedure consisting of the following key steps:
Step 1 (Discovery): CCM periodically sends out the MX Discovery Message to a pre-defined (NCM) IP Address/port until MX System INFO message is received in acknowledgement.
MX Discovery Message includes the following information:
MX System INFO includes the following information:
Step 2 (Capability Exchange): On receiving MX System Info message CCM learns the IP Address and port to start the step 2 of the control plane connection, and sends out the MX Capability REQ message, including the following Parameters:
In response, NCM creates a unique identity for the CCM session, and sends out the MX Capability RSP message, including the following information:
Unique Session Identifier: Unique session identifier for the CCM which has setup the connection. In case the session for the UE already exists then the existing unique session identifier is sent back.
In response to MX Capability RSP message, the CCM sends confirmation (or reject) in the MX Capability ACK message. MX Capability ACK includes the following parameters
If MX_REJECT is received by the NCM, the current MAMS session will be terminated.
If CCM can no longer continue with the current capabilities, it should send an MX SESSION TERMINATE message to terminate the MAMS session. In response, the NCM should send a MX SESSION TERMINATE ACK to confirm the termination.
CCM NCM | | |------MX Reconfiguration REQ (setup)--------------->| |<------------------------+MX Reconfiguration RSP+---| | +-----------+----------------+ | | NCM prepares N+MADP for | | | User Plane|Setup | | +----------------------------+ |<----------------------------- MX UP Setup Config---| |-----| MX UP Setup CNF+---------------------------->| +-------------------+ | |Link "X" is up/down| | +-------------------+ | |-----MX Reconfiguration REQ (update/release)------->| |<------------------------+MX Reconfiguration RSP+---|
Figure 6: MAMS Control Procedure for User Plane Configuration
Figure 6 shows the user plane configuration procedure consisting of the following key steps:
Reconfiguration: when the client detects that the link is up/down or the IP address changes (e.g. via APIs provided by the client OS), CCM sends out a MX Reconfiguration REQ Message to setup / release / update the connection, and the message SHOULD include the following information
If (Reconfiguration Action is setup or update), then include the following parameters
At the beginning of a connection setup, CCM informs the NCM of the connection status using the MX Reconfiguration REQ message with Reconfiguration Action type set to "setup". NCM acknowledges the connection setup status and exchanges parameters with the CCM for user plane setup, described as follows.
User Plane Protocols Setup: Based on the negotiated capabilities, NCM sets up the user plane (Adaptation Layer and Convergence Layer) protocols at the N-MADP, and informs the CCM of the user plane protocols to setup at the client (C-MADP) and the parameters for C-MADP to connect to N-MADP.
The MX UP Setup Config is used to create (multiple) MADP instances with each Anchor Connection having one or more Configurations, namely MX Configurations. It consists of the following parameters:
e.g. When LTE and Wi-Fi are the two user plane accesses, NCM conveys to CCM that IPsec needs to be setup as the MX Adaptation Layer over the Wi-Fi Access, using the following parameters - IPsec end-point IP address, Pre-Shared Key. No Adaptation Layer is needed or Client NAT may be used over the LTE Access as it is considered secure with no NAT.
Similarly, as an example of the MX Convergence Method configuration is to indicate the convergence protocol as MPTCP Proxy along with parameters for connection to the MPTCP Proxy, namely IP Address and Port of the MPTCP Proxy for TCP Applications.
Once the user plane protocols are configured, CCM informs the NCM of the status via the MX UP Setup CNF message. The MX UP Setup CNF consists of the following parameters:
Path quality estimations can be done either passively or actively. Traffic measurements in the network could be performed passively by comparing the real-time data throughput of the device with the capacity available in the network. In special deployments where the NCM has interfaces with access nodes, direct interfaces can be used to gather path quality information. For example, the utilization of a cell/eNB attached to a device could be used as an indicator for path quality estimations without creating an extra traffic overhead. Active measurements by the device are an alternative for estimating path quality.
CCM NCM | | |<--------------+ MX Path Estimation Configuration+--| |-----+ MX Path Estimation Results+----------------->| | |
Figure 7: MAMS Control Plane Procedure for Path Quality Estimation
NCM sends following the configuration parameters in the MX Path Estimation Configuration message to the CCM
CCM configures the C-MADP for probe reception based on these parameters and for collection of the statistics according to the following configuration.
The user plane probing is divided into two phases - Initialization phase and Active phase.
In Initialization phase, NCM configures N-MADP to send an MX Idle Probe REQ message. CCM collects the Idle probe statistics from C-MADP and sends the MX Path Estimation Results Message to NCM per the Initialization Probe Results configuration.
In Active phase, NCM configures N-MADP to send an MX Active Probe REQ message.. C-MADP calculates the metrics as specified by the Active Probe Results Configuration. CCM collects the Active probe statistics from C-MADP and sends the MX Path Estimation Results Message to NCM per the Active Probe Results configuration.
The following sub-sections define the control PDU encoding for Probe and Keep Alive messages to support path quality estimation.
| |
| <-----+MX Control PDU Payload +--------> |
| |
+-----------+------------------+-----+-----------------------------+
| IP header | UDP Header| Type | CID | MX Control Message |
+-----------+------------------+-----+-----------------------------+
Figure 8: MX Control PDU Format
Control PDUs are sent as UDP Messages between C-MADP and N-MADP to exchange control messages for keep-alive or path quality estimation. MX Probe Parameters are negotiated during the User Plane Setup phase (MX UP SETUP CFG and MX UP SETUP CNF). Figure 7 shows the MX control PDU format with the following fields:
The "Type" field is set to "0" for Keep-Alive messages. C-MADP may send out Keep-Alive message periodically over one or multiple delivery connections, especially if UDP tunneling is used as the adaptation method for the delivery connection with a NAT function on the path.
A Keep-Alive message is 2 Bytes long, and consists of the following fields:
The "Type" field is set to "1" for Probe REQ/ACK messages. N-MADP may send out the Probe REQ message for path quality estimation. In response, C-MADP may send back the Probe ACK message.
A Probe REQ message consists of the following fields:
The "R-CID" field is only present if both Bit #0 and Bit #2 of the "Probing Flag" field are set to "1". Moreover, Bit #2 of the "Probing Flag" field SHOULD be set to "0" if the Bit #0 is "0", indicating the Probe ACK message is not expected.
If the "R-CID" field is not present but the 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 Probe REQ message.
C-MADP SHOULD send out the Probe ACK message in response to a Probe REQ message with the Probe ACK flag set to "1".
A Probe ACK message is 3 Bytes long, and consists of the following fields:
CCM NCM | | | +------------------------------+ | |Steer user traffic to Path "X"| | +------------------------------+ |<------------------MX Traffic Steering (TS) REQ--| |----- MX Traffic Steering (TS) RSP ------------->|
Figure 9: MAMS Traffic Steering Procedure
NCM sends out a MX Traffic Steering (TS) REQ message to steer data traffic. It is also possible to send data traffic over multiple connections simultaneously, i.e. aggregation. The message includes the following information:
In response, CCM sends out a MX Traffic Steering (TS) RSP message, including the following information:
CCM NCM
| |
| +-------------------------+
| | Associate MADP instance |
| | with application flow |
| +-------------------------+
|-------------------MX App MADP ----------->|
| Association(AMA) REQ |
| |
|-------------------MX App MADP ----------->|
| Association(AMA) RSP |
Figure 10: MAMS Application MADP Association Procedure
CCM sends out a MX App MADP Association(AMA) REQ message to request association of a specific Application flow with a specific MADP instance ID for the anchor connection with multiple active MX configurations. MADP Instance ID is a tuple (Anchor Connection ID, MX Configuration ID). This provides the capability for the client to indicate the user plane processing that needs to be associated with different application flows depending on their needs. The application flow is identified by its associated traffic flow template.
The message includes the following information:
In response, NCM sends out a MX App MADP Association (AMA) RSP message, including the following information:
CCM NCM
| |
| +---------------------------------+
| |NCM determines preferred Networks|
| +---------------------------------+
|<------------------MX SSID Indication------------|
Figure 11: MAMS Network ID Indication Procedure
NCM indicates the preferred network list to the CCM to guide client on networks that it should connect to. To indicate preferred Wi-Fi Networks, the NCM sends the list of WLAN networks, represented by SSID/BSSID/HESSID, available in the MX SSID Indication.
CCM NCM
| |
|<------------------MX MEAS CONFIG----------------|
| |
+---------------------------------+ |
|Client Ready to send measurements| |
+---------------------------------+ |
| |
|----- MX MEAS REPORT---------------------------->|
Figure 12: MAMS Client Measurement Configuration and Reporting Procedure
NCM configures the CCM with the different parameters (e.g. radio link information), with the associated thresholds to be reported by the client. The MX MEAS CONFIG message contains the following parameters. For each Delivery Connection, include the following:
The MX MEAS REPORT message contains the following parameters
CCM NCM | | |+----MX Session Terminate--------->| | | | | |<---MX Session Terminate Ack-------| | +---------------+ | Remove Resources | +---------------+ | |
Figure 13: MAMS Session Termination Procedure - Client Initiated
CCM NCM
| |
|<----------MX Session Terminate--------|
| |
| |
| |
+--------MX Session Terminate Ack------->
| |
| |
+-----------+-----------+ |
| Remove Resources | |
+-----------+-----------+ |
| |
Figure 14: MAMS Session Termination Procedure - Network Initiated
At any point in MAMS functioning if CCM or NCM is unable to support the MAMS functions anymore, then either of them can initiate a termination procedure by sending MX Session Terminate to the peer, the peer shall acknowledge the termination by sending MX Session Terminate ACK message. After the session is disconnected the CCM shall start a new procedure with MX Discover Message. MX Session Terminate message shall contain Unique Session Identifier and reason for termination in Request. Possible reasons for termination can be:
CCM NCM
| |
|+----MX Network Analytics Request----------->|
| |
| |
|<---MX Network Analytics Info----------------|
| |
Figure 15: MAMS Network Analytics Request Procedure
CCM sends the MX Network Analytics Request informs the NCM to send information related to network parameters like bandwidth, latency, jitter, signal quality based on application of analytics at the network utilizing the received path measurements and client measurement reporting.
The MX Network Analytics Request message consists of the following parameters.
NCM sends the MX Network Analytics Info to convey the analytics info, predictive parameters with likelihoods, for the different parameters of interest for the CCM.
The MX Network Analytics Info messages consists of the following parameters.
+----------------------------------------+
| MAMS enabled Network of Networks |
| +-----+ +-----+ +-----+ +------+
+-----------------+ | | | | | | | | ||
| Client | | |Netwo| |Netwo| | | | ||
| +-----+ +-----+ | | |rk 1 | |rk 2 + |NCM | N-MADP||
| C-MADP |CCM | | | |(LTE)| |(WiFi) | | | ||
| +-----+ +-----+ | | +-----+ +-----+ +-----+ +------|
-+----------------+ +----------------------------------------+| | | | | | |
| | | | | | |
| | 1.SETUP CONNECTION| | | |
|<-----------+------------>| | | |
| | | + + | |
| | | 2. MAMS Capabilities Exchange | |
| | |<-------------+----------+-------->| |
| | | | | | |
| | + | | | |
| | 3. SETUP CONNECTION | | |
|<--+-------------------------------->| | |
| 4c. Config| 4a. NEGOTIATE NETWORK PATHS, FLOW |4b. Config|
| C-MADP | PROTOCOL AND PARAMETERS | |N-MADP |
| |<----->|<-------------+----------+-------->|<-------->|
| | | + + | |
| | |5. ESTABLISH USER PLANE PATH ACCORDING TO |
| | | SELECTED FLOW PROTOCOL | | |
| |<---------------------+----------+------------------->|
| | | | | | |
+ + + + + + +
Figure 16: MAMS call flow
Figure 16 illustrates the MAMS signaling mechanism for negotiation of network paths and flow protocols between the client and the network. In this example scenario, the client is connected to two networks (say LTE and WiFi).
CCM and NCM can further exchange messages containing access link measurements for link maintenance by the NCM. NCM evaluates the link conditions in the UL and DL across LTE and WiFi, based on link measurements reported by CCM and/or link probing techniques and determines the UL and DL user data distribution policy. NCM and CCM also negotiate application level policies for categorizing applications, e.g. based on DSCP, Destination IP address, and determining which of the available network paths, needs to be used for transporting data of that category of applications. NCM configures N-MADP, and CCM configures C-MADP, based on the negotiated application policies. CCM may apply local application policies, in addition to the application policy conveyed by the NCM.
MAMS leverages technologies developed in IETF like MPTCP, GRE and enables a control plane framework to negotiate the use of these protocols between the client and the network. It also addresses the limitations in the scope of other multihoming protocols. E.g. MOBIKE RFC 4555 (IKEv2 Mobility and Multihoming Protocol (MOBIKE)) scope indicates that it is limited to multihoming between IPsec clients(tunnel mode IPsec SAs) ONLY and does NOT support load balancing. MAMS addresses this limitation in handling multihoming scenario by supporting load balancing with simultaneous use of multiple access paths by negotiating use of protocols like MPTCP. Unlike MOBIKE, which only applies to end points connected with IPsec tunnel mode SA, MAMS allows flexibility to use a wide range of tunneling protocols to be used in the Adaptation layer.
If NCM determines that N-MADP is to be instantiated with MPTCP as the MX Convergence Protocol, it exchanges the MPTCP capability support in discovery and capability exchange procedures. NCM then exchanges the credentials of the N-MADP instance, setup as MPTCP Proxy, along with related parameters to the CCM. CCM configures C-MADP with these parameters to connect with the N-MADP, MPTCP proxy (e.g. [I-D.ietf-tcpm-converters]) instance, on the available network path (Access).
+-----------------------------------------------------+ | MPTCP | +----------------+---------------+--------------------+ | TCP | TCP | TCP | +-----------------------------------------------------+ | MX Adaptation | MX Adaptation | MX Adaptation | | Sublayer | Sublayer | Sublayer | | (optional) | (optional) | (optional) | +-----------------------------------------------------+ | Access #1 IP | Access #2 IP | Access #3 IP | +----------------+---------------+--------------------+
Figure 17: MAMS U-plane Protocol Stack with MPTCP as MX Convergence Layer
Figure 17 illustrates the user plane protocol layering when MPTCP is configured to be the "MX Convergence Sublayer" protocol. MPTCP manages traffic distribution and aggregation over multiple delivery connections.
+------+ +---------+ +---------+ +---------+ +---------+ +------+ | | | | | | | | | | | | |CCM | | C-MADP | |Wi-Fi N/W| | LTE N/W | | NCM | |N-MADP| +------+ +---------+ +---------+ +---------+ +---------+ +------+ +------------------------------------------------------------------------+ | 1. LTE Session Setup and IP Add. Allocation | -------------------------------------------+-------------+-------------+-+ |2. MAMS Discovery Message (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 (WLAN/LTE Measurement Thresholds/Period) | <-------------------------------------------------------+ | |8. MX MEAS REPORT ( LTE RSRP, UL/DL TPUT ) | | +-----------------------------------------+-------------> | |9. MAMS SSID IND(List of SSIDs) | | | <-------------+-------------+---------------------------+ | | | | | | | |10. MX RECONFIGURATION REQ (LTE IP) | | | +-------------------------------------------------------> | |11. MX RECONFONFIGURATION RSP | | | <-----------------------------------------+-------------+ | |12. MX UP SETUP REQ (MPTCP Proxy IP/Port, Aggregation) | | <---------------------------+-------------+-------------+ | |13. MX UP SETUP RSP | | | | +-------------+-------------+-------------+-------------> + | | 14. MPTCP Connection with designated MPTCP Proxy over LTE | +-------------+-------------+-------------+-------------> | | | | | | + + + + + +
Figure 18: MAMS-assisted MPTCP Proxy as User Plane - Initial Setup with LTE leg
Figure 18 shows the call flow describing MAMS control procedures applied to configure user plane and dynamic optimal path selection in a scenario with MPTCP Proxy as the convergence protocol in the user plane.
Following are the salient steps described in the call flow. The client connects to the LTE network and obtains an IP address (assume LTE is the first connection), and initiates the NCM discovery procedures and exchange capabilities, including the support for MPTCP as the convergence protocol at both the network and the client.
The CCM informs the LTE connection parameters to the NCM. NCM provides the parameters like MPTCP Proxy IP address/Port for configuring the convergence layer. This is useful if N-MADP is reachable via different IP address or/and port, from different access networks. The current MPTCP signaling can't identify or differentiate the MPTCP proxy IP address and port among multiple access networks. Since LTE is the only connection, the user plane traffic, flows over the single TCP subflow over the LTE connection. Optionally, NCM provides assistance information to the device on the neighboring/preferred Wi-Fi networks that it can associate with.
+------+ +---------+ +---------+ +---------+ +---------+ +------+ | | | | | | | | | | | | |CCM | | C-MADP | |Wi-Fi N/W| | LTE N/W | | NCM | |N-MADP| +------+ +---------+ +---------+ +---------+ +---------+ +------+ +------------------------------------------------------------------------+ | 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 RECONFONFIGURATION RSP | | | <-----------------------------------------+-------------+ | |17. MX UP SETUP REQ (MPTCP Proxy IP/Port, Aggregation) | | <---------------------------+-------------+-------------+ | |18. MX UP SETUP RSP | | | | +-------------+-------------+-------------+-------------> | | | 19. IPsec Tunnel Establishment over WLAN path | | <-----------------------------------------|-------------> | 20. MX MEAS REPORT (WLAN RSSI, LTE RSRP. UL/DL TPUT) |+-------------+ +-------------+-------------+-------------+------------->+Wait for | | | | | |+good reports | | | | | |+-------------+ | 21. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) | +------------+ <-----------------------------------------+-------------+ |Allow Use of| | 22. MX TRAFFIC STEERING RSP (...) | | |Wi-Fi link | +-------------+-------------+---------------------------> +-----------++ | | | | | | | 23. Add TCP subflow to the MPTCP connection over WiFi 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 19 describes the steps, when the client establishes a Wi-Fi connection. CCM informs the NCM of the Wi-Fi connection along with parameters like the Wi-Fi IP address, SSID. NCM determines that the Wi-Fi connection needs to be secured and configures the Adaptation Layer to be IPsec and provides the required parameters to the CCM. In addition, NCM provides the information to configure the convergence layer, (e.g. MPTCP Proxy IP Address), and provides the Traffic Steering Request to indicate that client should use only the LTE access. NCM may do this, for example, on determination from the measurements that the Wi-Fi link is not consistently good enough. As the Wi-Fi link conditions improve, NCM sends a Traffic Steering Request to use Wi-Fi access as well. This triggers the client to establish the TCP subflow over the Wi-Fi link with the MPTCP proxy
+------+ +---------+ +---------+ +---------+ +---------+ +------+ | | | | | | | | | | | | |CCM | | C+MADP | |Wi+Fi N/W| | LTE N/W | | NCM | |N+MADP| +------+ +---------+ +---------+ +---------+ +---------+ +------+ +------------------------------------------------------------------------+ | Traffic over LTE and Wi Fi in UL And DL over MPTCP | +-------------+-------------+-------------+-------------+------------+---+ | | | | | | | 24. MX MEAS REPORT (WLAN RSSI, LTE RSRP ,UL/DL TPUT) |+-----------+---+ +-------------+-------------+-------------+------------>|| Reports of bad| | | | | |+ Wi-Fi UL tput| | + + + ++---------------+ | 25. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) | +-------------+ |<-----------------------------------------+------------+ |Disallow use| | 26. MX TRAFFIC STEERING RSP (...) | | |of 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 20 describes the steps, when the client reports that Wi-Fi link conditions degrade in UL. MAMS control plane is used to continuously monitor the access link conditions on Wi-Fi and LTE connections. The NCM may at some point determine increase in UL traffic on Wi-Fi, and trigger the client to only LTE in the UL via Traffic Steering Request to improve UL performance.
+------+ +---------+ +---------+ +---------+ +---------+ +------+ | | | | | | | | | | | | |CCM | | C+MADP | |Wi+Fi N/W| | LTE N/W | | NCM | |N+MADP| +------+ +---------+ +---------+ +---------+ +---------+ +------+ +-----------------------------------------------------------------------+ | UL data to use TCP subflow over LTE link only, | | Aggregated Wi+Fi+LTE capacity for DL | ++-------------+-------------+-------------+-------------+------------+-+ | | | | | | | + + + | | | 27. MX MEAS REPORT (WLAN 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| | 29. MX TRAFFIC STEERING RSP (...) | | |of Wi+Fi | +-----------------------------------------+------------>+ +-------------+ | |30. Delete TCP subflow from MPTCP conn. 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
Figure 21 describes the steps, when the client reports that Wi-Fi link conditions degrade in both UL and DL. As the Wi-Fi link conditions deteriorate further, the NCM may determine to send Traffic Steering Request guiding the client to stop using Wi-Fi, and to use only LTE access in both UL and DL. This condition may be maintained until NCM determines, based on reported measurements that Wi-Fi link has become usable.
Figure 22 shows the call flow describing MAMS control procedures applied for dynamic optimal path selection in a scenario convergence and Adaptation layer protocols are not omitted. This scenario indicates the applicability of a MAMS Control Plane only solution.
In the capability exchange messages, NCM and CCM negotiate that Convergence and Adaptation layer protocols are not needed (or supported). CCM informs the NCM of the availability of the LTE and Wi-Fi links. NCM determines the access links, Wi-Fi or LTE to be used dynamically based on the reported link quality measurements.
+------+ +---------+ +---------+ +---------+ +---------+ +------+ | | | | | | | | | | | | |CCM | | C+MADP | |Wi+Fi N/W| | LTE N/W | | NCM | |N+MADP| +------+ +---------+ +---------+ +---------+ +---------+ +------+ +------------------------------------------------------------------------+ | 1. LTE Session Setup and IP Add. Allocation | +------------------------------------------+-------------+-------------+-+ |2. MAMS Discovery Message (MAMS Version, MCC/MNC Tuple) | | | +-----------------------------------------+------------>| | | 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/Adpatation parameters) | |<-----------------------------------------+------------+ | | 6. MX CAPABILITY ACK(ACCEPT) | | | +-------------+-------------+-------------------------->| | | + + + + | |7. MX MEAS CONFIG (WLAN/LTE Measurement Thresholds/Period) | |<------------------------------------------------------| | |8. MX MEAS REPORT ( LTE RSRP, UL/DL TPUT ) | | |-----------------------------------------+------------>| | |9. MAMS SSID IND(List of SSIDs) | | | |<------------------------------------------------------| | +-----------------------------------------------------------------------++ | 10. Wi|Fi connection setup and IP Address allocation | +-+-------------+-------------+-------------+-------------+-------------++ | + + | | | |10. MX RECONFIGURATION REQ (LTE IP, Wi-Fi IP) | | +-----------------------------------------+------------>| | |11. MX RECONFONFIGURATION RSP | | | <------------------------------------------------------+| | +-----------------------------------------------------------------------++ | Initial Condition, Data over LTE link only, WLAN link is poor | +---------------------------------------------------------+-------------++ |12. MX MEAS REPORT (WLAN RSSI, LTE RSRP, UL/DL TPUT) |+-------------+ |------------------------------------------------------>||Wi-Fi Link | | | | | ||conditions | | | | | ||reported good| | | | | |+-------------+ | | | | | | |13. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) |+--------------+ |<-------------+-------------+-------------+------------||Steer traffic | |14. MX TRAFFIC STEERING RSP (...) | ||to use Wi-Fi | |<-------------+-------------+-------------+------------||link | | | | | |+--------------+ +-----------------------------------------------------------------------++ | Use Wi-Fi link for Data | +---------------------------------------------------------+-------------++ | | | | | | + + + + + +
Figure 22: MAMS With No Convergence Layer
MAMS user plane supports multiple instances and combinations of protocols to be used at the MX Adaptation and the Convergence layer.
For example, one instance of the MX Convergence Layer can be MPTCP Proxy and another instance can be Trailer based. The MX Adaptation for each can be either UDP tunnel or IPsec. IPSec may be set up when network path needs to be secured, e.g. to protect the TCP subflow traversing the network path between the client and MPTCP proxy.
Each of the instances of MAMS user plane, i.e. combination of MX Convergence and MX Adaptation layer protocols, can coexist simultaneously and independently handle different traffic types.
The NCM functional element is hosted on a network node which is assumed to be within a secure network, e.g. within the operator's network, and is assumed to be protected against hijack attacks.
For deployment scenarios, where the client is configured (e.g. by the network operator) to use a specific network path for exchanging control plane messages and if the network path is assumed to be secure, MAMS control messages will rely on security provided by the underlying network.
For deployment scenarios where the security of the network path cannot be assumed, NCM and CCM implementations MUST support the "wss" URI scheme [RFC6455] and Transport Layer Security (TLS) [RFC5246] to secure control plane message exchange between the NCM and CCM.
For deployment scenarios where client authentication is desired, the WebSocket server can use any client authentication mechanisms available to a generic HTTP server, such as cookies, HTTP authentication, or TLS authentication.
User data in MAMS framework relies on the security of the underlying network transport paths. When this cannot be assumed, NCM configures use of protocols, like IPsec [RFC4301] [RFC3948] in the MX Adaptation Layer, for security.
MAMS builds on commonly available functions available on terminal devices that can be delivered as a software update over the popular end-user device operating systems, enabling rapid deployment and addressing the large deployed device base.
Multi Access Edge Computing (MEC), earlier known as Mobile edge computing, is an access-edge cloud platform being standardized at ETSI, whose initial focus was to improve quality of experience by leveraging intelligence at cellular (e.g. 3GPP technologies like LTE) access edge, and the scope is now being extended to support access technologies beyond 3GPP. This applicability of the framework described in this document to the MEC platform has been evaluated and tested in different network configurations.
The NCM is hosted on the MEC cloud server that is located in the user plane path at the edge of multi-technology access networks. The NCM and CCM negotiate the network path combinations based on application needs and the necessary user plane protocols to be used across the multiple paths. The network conditions reported by the CCM to the NCM is complemented by Radio Analytics application[ETSIRNIS] residing at the MEC to configure the uplink and downlink access paths according to changing radio and congestion conditions.
The user plane functional element, N-MADP, can either be collocated with the NCM at the MEC cloud server (e.g. MEC hosted applications), or placed at a separate network element like a common user plane gateway across the multiple networks.
Also, even in scenarios where N-MADP is not deployed, NCM can be used to augment the traffic steering decisions at the device.
The aim of these enhancements is to improve the end-user's quality of experience by leveraging the best network path based on application needs and network conditions, and building on the advantages of significantly reduced latency and the dynamic and real-time exposure of radio network information available at the MEC.
MAMS framework has been incorporated as a solution to address multi access integration in multiple industry forums and standards. The section describes the related work in other industry forums and standards that have incorporated MAMS solutions in their work.
Wireless Broadband Alliance industry partners are developing a whitepaper that describes applicability of different technologies for multi access integration to different deployments in their project named, Unlicensed Integration with 5G Networks [WBAUnl5G]. As part of this project, MAMS has been included as a technology for integrating Unlicensed (WiFi) networks with 5G networks above the 5G core network.
3GPP is developing the technical report, TR23.793 as part of the workitem [GPPATSSS] on Study on Access Traffic Steering, Switching and splitting (ATSSS) support. Solution 1 of TR 23.793 is based on MAMS protocol architecture and control plane for flexible negotiation of user plane protocols and path measurements.
Small Cell Forum (SCF) has included MAMS in the whitepaper [SCFTECH5G] proposed to be developed as part of the Workitem on LTE/5G and WiFi update.
ETSI Multi Access Edge Computing in its Phase 2 technical work [ETSIMAMS] includes MAMS based use cases.
The editors gratefully acknowledge the following additional contributors in alphabetical order: A Krishna Pramod/Nokia, Hannu Flinck/Nokia, Hema Pentakota/Nokia, Nurit Sprecher/Nokia, Salil Agarwal/Nokia; Shuping Peng/Huawei, Vasudevan Subramanian/Nokia. Vasudevan Subramanian has been instrumental in conceptualization and development of solution principles for the MAMS framework. Shuping Peng has been a key contributor in refining the framework and control plane protocol aspects.
This protocol is the outcome of work by many engineers, not just the authors of this document. In alphabetical order, the contributors to the project are: Barbara Orlandi, Bongho Kim,David Lopez-Perez, Doru Calin, Jonathan Ling, Lohith Nayak, Michael Scharf.
This draft makes no requests of IANA
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC4301] | Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005. |
If the connection between CCM and NCM over which the MAMS control plane messages are transported is assumed to be secure, UDP is used as the transport for management & control messages between NCM and UCM (see Figure 23).
+-----------------------------------------------------+ | Multi-Access (MX) Control Message | |-----------------------------------------------------| | UDP | |-----------------------------------------------------|
Figure 23: UDP-based MAMS Control plane Protocol Stack
CCM hosts an HTTPS server for applications to communicate and request services. It is assumed in this draft that all CCM and the communicating Application instances are hosted in a single administrative domain from security point of view.
The content of messages is defined in "Java Script Object Notation" (JSON) format. They offer RESTful APIs for communication.
The exact mechanism regarding how Application knows about the end point of CCM is not covered as part of this document. It may be provided as part of the Application Settings.
The documentation of APIs are provided in OpenAPI format using swagger v2.0 (TBD – Add section in appendix)
For every API, there could be an error response in case the objective of API could not be met as defined in [RFC2616].
The following sections describe the APIs exposed by CCM to the applications
CCM MUST provide a HTTPS GET interface as "/ccm/v1.0/capabilities" for the Application to query about the capabilities supported by the CCM instance.
+-----------+ +-------------+ | | | | | App +----------+HTTPS GET /capabilities+-------->| CCM | | | | | +-----------+ +-------------+
Figure 24: CCM API - GET Procedures
The CCM shall provide information of its capabilities as follows:
CCM MUST provide a HTTPS POST interface as "/ccm/v1.0/app_requirements" for the Application to post the needs of the application data streams to the CCM instance.
+-----------+ +-------------+ | | | | | App +----------+HTTPS POST /App Requirements+--->| CCM | | | | | +-----------+ +-------------+
Figure 25: CCM API - POST Procedures
The CCM shall provide for the application to post the following requirements of its different data streams:
CCM MUST provide a HTTPS GET interface as "/ccm/v1.0/predictive_link_params" for the Application to get the predicted link parameters from the CCM instance.
+-----------+ +-------------+ | | | | | App +-------+HTTPS GET /Predictive Link Params--->| CCM | | | | | +-----------+ +-------------+
Figure 26: CCM API - GET Predictive Link Parameters Procedures
CCM requests the NCM for link parameters via the MAMS Network Analytics Request Procedure (Section 8.12) and includes the information in response to the API invocation.
MAMS Control plane messages are exchanged between the CCM and the NCM. This section, specifies the format and content of messages in "Java Script Object Notation" (JSON) format.
This document uses JSONString, JSONNumber, and JSONBool to indicate the JSON string, number, and boolean types, respectively. The type JSONValue indicates a JSON value, as specified in Section 3 of [RFC7159].
This document uses an adaptation of the C-style struct notation to define JSON objects. A JSON object consists of name/value pairs. This document refers to each pair as a field. In some context, this document also refers to a field as an attribute. The name of a field/attribute may be referred to as the key. An optional field is enclosed by [ ]. In the definitions, the JSON names of the fields are case sensitive. An array is indicated by two numbers in angle brackets, <m..n>, where m indicates the minimal number of values and n is the maximum. When this document uses * for n, it means no upper bound.
For example, the definition below defines a new type Type4, with three fields named "name1", "name2", and "name3", respectively. The field named "name3" is optional, and the field named "name2" is an array of at least one value.
object { Type1 name1; Type2 name2<1..*>; [Type3 name3;] } Type4;
This document uses subtyping to denote that one type is derived from another type. The example below denotes that TypeDerived is derived from TypeBase. TypeDerived includes all fields defined in TypeBase. If TypeBase does not have a field named "name1", TypeDerived will have a new field named "name1". If TypeBase already has a field named "name1" but with a different type, TypeDerived will have a field named "name1" with the type defined in TypeDerived (i.e., Type1 in the example).
object { Type1 name1; } TypeDerived : TypeBase;
Note that, despite the notation, no standard, machine-readable interface definition or schema is provided in this document. Extension documents may describe these as necessary.
This message is the first message sent by CCM to discover the presence of NCM in the network. It contains only the base information as described in Appendix C.2.1 with message_type set as mx_discover.
Following is the representation of the message:
object {
[JSONString MCC_MNC_Tuple;]
} MXDiscover : MXBase;
This message is sent by NCM to CCM to inform the endpoints that NCM supports for MAMS functionality. In addition to base information (Appendix C.2.1) it contains following information:
a) NCM Connections (described in Appendix C.2.3)
Following is the representation of the message:
object {
NCMConnections ncm_connections;
} MXSystemInfo : MXBase;
This message is sent by CCM to NCM to indicate the capabilities of the CCM instance available to the NCM indicated in System Info message earlier. In addition to base information (Appendix C.2.1) it contains following information:
Following is the representation of the message:
This message is sent by NCM to CCM to indicate the capabilities of the NCM instance and unique session identifier for CCM. In addition to base information (Appendix C.2.1) it contains following information:
Following is the representation of the message:
This message is sent by CCM to NCM to indicate acceptance of capabilities advertised by NCM in earlier MX Capability Response message. In addition to base information (Appendix C.2.1) it contains following information:
Following is the representation of the message:
This message is sent by NCM to CCM to configure the user plane for MAMS. In addition to base information (Appendix C.2.1) it contains following information:
Following is the representation of the message:
This message is the confirmation of user plane setup message sent from CCM after successfully configuring the user plane at user equipment. This message contains following information:
Following is the representation of the message:
Where ProbeParam is defined as following:
Where ClientParam is defined as following:
Where AdaptationParam is defined as following:
This message is sent by CCM to NCM in case of reconfiguration of any the connections from user equipment's side. In addition to base information (Appendix C.2.1) it contains following information:
Following is the representation of the message:
This message is sent by NCM to CCM as a confirmation towards reconfiguration requirement after taking the reconfiguration into use and contains only the base information (as defined in Appendix C.2.1).
Following is the representation of the message:]
This message is sent by NCM towards CCM to configure the CCM to send path estimation reports. In addition to base information (Appendix C.2.1) it contains following information:
Following is the representation of the message:
This message is sent by CCM to NCM as report to the probe estimation configured by NCM. In addition to base information (Appendix C.2.1) it contains following information:
Following is the representation of the message:
This message is sent by NCM to CCM for enabling traffic steering at delivery side in uplink and downlink configuration. In addition to base information (Appendix C.2.1) it contains following information:
Following is the representation of the message:
This message is response to Traffic Steering request from CCM to NCM. In addition to base information (Appendix C.2.1) it contains following information:
Following is the representation of the message:
This message is sent by CCM to NCM to select MADP instances provided earlier in User Plane Setup Request based on requirement of the applications.
In addition to the base information (Appendix C.2.1) it contains following:
Following is the representation of the message:
Where each measurement MXAppMADPAssoc is represented by following:
This message is sent by NCM to CCM to confirm the selected MADP instances provided in request message by CCM.
In addition to the base information (Appendix C.2.1), it contains information if the request has been successful.
Following is the representation of the message:
This message is sent by NCM to CCM to indicate the list of allowed SSID which are supported by MAMS entity at the network side. It contains the list of SSIDs.
Each SSID consists of the type of SSID (which can be one of the "SSID", "BSSID" or "HESSID" and the SSID itself.
Following is the representation of the message:
Where each SSID is defined as following:
This message is sent from NCM to CCM to configure the period measurement reporting at CCM. The message contains a list of measurement configuration with each element containing following information:
Following is the representation of the message:
Where each measurement MeasReportConf is represented by following:
This message is periodically sent by CCM to NCM after measurement configuration. In addition to the base information it contains following information:
Following is the representation of the message:
A Keep Alive Request message can be sent from either NCM or CCM on expiry of MAMS_KEEP_ALIVE timer or a handover event. This request shall be responded by the peer with Keep Alive Response. In case of no response from peer the MAMS connection shall be assumed to be broken and new connection shall be established again by CCM by sending MX Discover messages.
In addition to the base information it cantains following information:
Following is the representation of the message:
On receiving Keep Alive Request from peer, NCM/CCM shall immediately respond with a Keep Alive Response message on the same delivery path from where the request arrived. In addition to base information it contains the unique session identifier for the CCM-NCM association (defined in Appendix C.2.2)
Following is the representation of the message:
In the event where NCM or CCM can no longer handle MAMS for any reason then it can send MX session termination request to the peer. In addition to base information it contains Unique Session Id and reason for termination, this can be "MX_NORMAL_RELEASE", "MX_NO_RESPONSE" or "INTERNAL_ERROR".
Following is the representation of the message:
On reception of MX session termination request from peer, NCM/CCM shall respond with MX Session Termination Response on the same delivery path where the request arrived and clean the MAMS related resources and settings. CCM shall re-initiate a new session with MX Discover messages again.
Following is the representation of the message:
This message is sent by CCM to NCM to request for parameters like bandwidth, jitter, latency and signal quality predicted by network analytics function. In addition to the base information it contains following parameter:
Following is the representation of the message:
Where the params object can take one or more of the following values:
This message is sent by NCM to CCM in response to the analytics request. For each delivery connection that the client has NCM reports the requested parameter predictions and their respective likelihood (between 1-100).
In addition to the base information it contains following parameters:
Following is the representation of the message:
Where MXAnalyticsList is defined as following::
Where each ParamPredictions is defined as:
This is the base information that every message between CCM and NCM exchanges shall have as mandatory information. It contains following information:
Following is the representation of this data type:
This data type defines the unique session id between a CCM and NCM entity, it contains a NCM id which is unique in the network and a session id allocated by NCM for that session. On reception, of discovery message if the session is existing then the old session id is returned in System Info message otherwise NCM allocates a new session id to the CCM and sends in response with System Info message.
Following is the representation of this data type:
This data type defines the connection available at NCM for MAMS connectivity towards the User Equipment. It contains a list of NCM connections available where each connection has following information:
Following is the representation of this data type:
where NCMConnection is defined as:
where NCMEndPoint is defined as:
This data type provides the mapping of connection Id and connection type. It contains following information:
The two are considered a mapping like 0-"Wi-Fi", 1-"5G NR", 2-"Multi-Fire" and 3-"LTE".
Following is the representation of this data type:
This data type provides the list of all features with their activation status. Each feature status contains following:
Following is the representation of this data type:
where FeatureInfo is defined as:
This data type contains the list of Connection Information (Appendix C.2.4) that are supported at anchor (core) side.
Following is the representation of this data type:
This data type contains the list of Connection Information (Appendix C.2.4) that are supported at delivery (access) side.
Following is the representation of this data type:
This data type provides the support for a particular convergence or adaptation method. It consists of following:
Following is the representation of this data type:
This data type contains the list of all convergence methods and their support status. Converge Methods possible are:
Following is the representation of this data type:
This data type contains the list of all convergence methods and their support status. Converge Methods possible are:
Following is the representation of this data type:
This data type defines the setup configuration for each of the anchor connection that is required at the user equipment side. It contains following information in addition to the connection id and type of the anchor connection:
Following is the representation of this data type:
Where each Anchor connection configuration is defined as following:
where each Convergence configuration is defined as following:
This data type defines the parameters used for convergence method and contains following:
Following in the representation of this data type:
This is the list of delivery connections and their parameters to be configured at the user equipment. Each delivery connection defined by its connection information (Appendix C.2.4) contains optionally following:
Following in the representation of this data type:
where each Setup Delivery Connection consists of following:
where Adaptation Method Param is defined as:
This data type defines the results of init probe request made by NCM. It consists of following information:
Following in the representation of this data type:
This data type defines the results of init probe request made by NCM. It consists of following information:
Following in the representation of this data type:
This data type defines the list of connections which are enabled in delivery side to be used in downlink direction.
Following in the representation of this data type:
This data type defines the list of connections and parameters enabled for deliver side to be used in uplink direction.
The uplink delivery consists of multiple uplink delivery entities, where each entity consists of a traffic flow template (TFT) Appendix C.2.16 and list of connection ids in uplink where traffic qualifying for such traffic flow template can be redirected.
Following in the representation of this data type:
Where each uplink delivery entity consists of following data type:
Traffic flow template follows in general guidelines specified in 3GPP TS 23.060.
Traffic flow template in MAMS consists of one or more of following:
Following in the representation of this data type:
Where the port range is defined as following:
This data type defines the configuration done by NCM towards CCM for reporting measurement events.
Following is the representation of this data type:
Where Threshold is defined as following:
This data type defines the measurements reported by CCM for each access network measured. This type contains the connection information, delivery node id which identifies the cell (ECGI) or the WiFI Access Point Id or MAC address (or equivalent identifier in other technologies) and the actual measurement performed by CCM in the last measurement period.
Following is the representation of this data type:
Where Measurement is defined as the key value pair of measurement type and value. The exact type and value are defined on a per delivery type and defined in Appendix C.2.17.
{
"$schema": "http://json-schema.org/draft-04/schema#",
"definitions": {
"message_type_def": {
"enum": [
"mx_discover",
"mx_system_info",
"mx_capability_req",
"mx_capability_resp",
"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_resp",
"mx_app_madp_assoc_req",
"mx_app_madp_assoc_resp",
"mx_network_analytics_req",
"mx_network_analytics_resp"
],
"type": "string"
},
"sequence_num_def": {
"minimum": 1,
"type": "integer"
},
"version_def": {
"type": "string"
}
},
"id": "http://www.ietf.org/mams/mx_base_def.json"
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"definitions": {
"adapt_method": {
"enum": [
"UDP_without_DTLS",
"UDP_with_DTLS",
"IPSec",
"Client_NAT"
],
"type": "string"
},
"conv_method": {
"enum": [
"Trailer_Based",
"MPTCP_Proxy",
"GRE_Aggregation_Proxy"
],
"type": "string"
},
"supported": {
"type": "boolean"
},
"active": {
"type": "boolean"
},
"connection_id": {
"type": "integer"
},
"feature_name": {
"enum": [
"lossless_switching",
"fragmentation",
"concatenation",
"uplink_aggregation",
"downlink_aggregation",
"measurement"
],
"type": "string"
},
"connection_type": {
"enum": [
"wi-fi",
"5g-nr",
"multi-fire",
"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_acknowledgement" : {
"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": "http://www.ietf.org/mams/definitions.json"
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"id": "http://www.ietf.org/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"
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"id": "http://www.ietf.org/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"
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"id": "http://www.ietf.org/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"
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"id": "http://www.ietf.org/mams/mx_capability_resp.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"
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"definitions": {},
"id": "http://www.ietf.org/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_acknowledgement"}
},
"type": "object"
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"definitions": {},
"id": "http://www.ietf.org/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"
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"definitions": {},
"id": "http://www.ietf.org/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"
}
{
"$schema": "http://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" }
},
"type": "object"
},
"num_delivery_connections": {
"type": "integer"
},
"delivery_connections": {
"items":{ "$ref" : "definitions.json#/delivery_connection" },
"type": "array"
}
}
},
"id": "http://www.ietf.org/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"
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"definitions": {},
"id": "http://www.ietf.org/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"
}
{
"$schema": "http://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": "http://www.ietf.org/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_activation": {
"items": {"$ref" : "definitions.json#/feature_status" },
"type": "array"
},
"default_uplink_delivery": {
"type": "integer"
},
"uplink_delivery": {
"items": { "$ref" : "#definitions/ul_delivery" },
"type": "array"
}
},
"type": "object"
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"definitions": {},
"id": "http://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_activation": {
"items": {"$ref" : "definitions.json#/feature_status" },
"type": "array"
}
},
"type": "object"
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"definitions": {},
"id": "http://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"
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"definitions": {},
"id": "http://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"
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"definitions": {},
"id": "http://www.ietf.org/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"
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"definitions": {},
"id": "http://www.ietf.org/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"
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"definitions": {},
"id": "http://www.ietf.org/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"
}
{
"$schema": "http://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": "http://www.ietf.org/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"
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"definitions": {},
"id": "http://www.ietf.org/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" },
"measurment_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"
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"id": "http://www.ietf.org/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"
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"id": "http://www.ietf.org/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"
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"id": "http://www.ietf.org/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"
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"id": "http://www.ietf.org/mams/mx_session_termination_resp.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"
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"id": "http://www.ietf.org/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"
}
{
"$schema": "http://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": "http://www.ietf.org/mams/mx_network_analytics_resp.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"
}
{
"version" : "1.0",
"message_type" : "mx_discover",
"sequence_num" : 1
}
{
"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" : "wifi",
"ncm_end_point" : {
"ip_address" : "192.168.1.10",
"port" : 1234
}
}
]
}
{
"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" : "wifi"
}
],
"num_delivery_connections" : 2,
"delivery_connections" : [
{
"connection_id" : 0,
"connection_type" : "lte"
},
{
"connection_id" : 1,
"connection_type" : "wifi"
}
],
"convergence_methods" : [
{
"method" : "Trailer_Based",
"supported" : true
},
{
"method" : "MPTCP_Proxy",
"supported" : false
}
],
"adaptation_methods" : [
{
"method" : "UDP_without_DTLS",
"supported" : false
},
{
"method" : "UDP_with_TLS",
"supported" : false
},
{
"method" : "IPSec",
"supported" : true
},
{
"method" : "Client_NAT",
"supported" : false
}
]
}
{
"version" : "1.0",
"message_type" : "mx_capability_resp",
"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" : "wifi"
}
],
"num_delivery_connections" : 2,
"delivery_connections" : [
{
"connection_id" : 0,
"connection_type" : "lte"
},
{
"connection_id" : 1,
"connection_type" : "wifi"
}
],
"convergence_methods" : [
{
"method" : "Trailer_Based",
"supported" : true
},
{
"method" : "MPTCP_Proxy",
"supported" : false
}
],
"adaptation_methods" : [
{
"method" : "UDP_without_DTLS",
"supported" : false
},
{
"method" : "UDP_with_TLS",
"supported" : false
},
{
"method" : "IPSec",
"supported" : true
},
{
"method" : "Client_NAT",
"supported" : false
}
],
"unique_session_id" : {
"ncm_id" : 110,
"session_id" : 1111
}
}
{
"version" : "1.0",
"message_type" : "mx_capability_ack",
"sequence_num" : 3,
"unique_session_id" : {
"ncm_id" : 110,
"session_id" : 1111
},
"capability_ack" : "MX ACCEPT"
}
{
"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"
}
{
"version" : "1.0",
"message_type" : "mx_reconf_rsp",
"sequence_num" : 4
}
{
"version": "1.0",
"message_type": "mx_up_setup_conf_req",
"sequence_num": 5,
"num_anchor_connections": 2,
"anchor_connections": [{ "connection_id": 1,
"connection_type": "wifi",
"num_active_mx_conf" : 2,
"convergence_config" : [
{
"mx_configuration_id" : 1,
"convergence_method": "Trailer_Based",
"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": "wifi"
}
]
},
{
"mx_configuration_id" : 2,
"convergence_method": "Trailer_Based",
"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": "wifi",
"adaptation_method": "UDP_without_DTLS",
"adaptation_method_param": {
"tunnel_ip_addr": "192.168.3.3",
"tunnel_end_port": "6000"
}
}
]
}
]
}
{
"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
}
}
]
}
{
"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,
"loca_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_activation" : [
{
"feature_name" : "dl_aggregation",
"active" : true
},
{
"feature_name" : "ul_aggregation",
"active" : false
}
]
}
{
"version": "1.0",
"message_type": "mx_traffic_steering_rsp",
"sequence_num": 6,
"unique_session_id": {
"ncm_id": 110,
"session_id": 1111
},
"feature_activation": [{
"feature_name": "lossless_switching",
"active": true
},
{
"feature_name": "fragmentation",
"active": false
}
]
}
{
"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
}
}]
}
]
}
{
"version": "1.0",
"message_type": "mx_app_madp_assoc_resp",
"sequence_num": 6,
"is_success": true
}
{
"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"
}
{
"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
}
}
{
"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"
}
]
}
{
"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
}
]
}
]
}
{
"version" : "1.0",
"message_type" : "mx_measurement_report",
"sequence_num" : 11,
"unique_session_id" : {
"ncm_id" : 110,
"session_id" : 1111
},
"measurment_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
}
]
}
]
}
{
"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"
}
{
"version" : "1.0",
"message_type" : "mx_keep_alive_rsp",
"sequence_num" : 12,
"unique_session_id" : {
"ncm_id" : 110,
"session_id" : 1111
}
}
{
"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"
}
{
"version" : "1.0",
"message_type" : "mx_session_termination_resp",
"sequence_num" : 13,
"unique_session_id" : {
"ncm_id" : 110,
"session_id" : 1111
}
}
{
"version" : "1.0",
"message_type" : "mx_network_analytics_req",
"sequence_num" : 20,
"unique_session_id" : {
"ncm_id" : 110,
"session_id" : 1111
},
"parmas" : [
"jitter",
"latency"
]
}
{
"version": "1.0",
"message_type": "mx_network_analytics_resp",
"sequence_num": 20,
"param_list": [{
"connection_id": 1,
"connection_type": "wifi",
"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
}
]
}
]
}
This section provides an example implementation of the APIs exposed by the CCM to the Applications on the client, documented with OpenAPI using Swagger 2.0.
{
"swagger": "2.0",
"info": {
"version": "1.0.0",
"title": "Client Connection Manager (CCM)",
"description": "API provided by CCM towards 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 application to request for 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 N-MADP to report any kind of MAMS user specific errors to 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",
"multi-fire",
"lte"
],
"type": "string"
},
"features": {
"enum": [
"lossless_switching",
"fragmentation",
"concatenation",
"uplink_aggregation",
"downlink_aggregation",
"measurement"
],
"type": "string"
},
"adaptation-methods": {
"enum": [
"UDP_without_DTLS",
"UDP_with_DTLS",
"IPSec",
"Client_NAT"
],
"type": "string"
},
"convergence-methods": {
"enum": [
"Trailer_Based",
"MPTCP_Proxy",
"GRE_Aggregation_Proxy"
],
"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-rspq",
"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"
}
}
}
}
}
A simple client side implementation using python can be as following:
#!/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':"wifi"}],
'convergence_methods':[{'method':'trailer_based', '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("Recieved 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())
A server client side implementation using python can be as following:
#!/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':"wifi"}],
'convergence_methods':[{'method':'trailer_based', '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("Recieved 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")