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