INTAREA

Independent Submission                                       S. Kanugovi
Internet-Draft
Request for Comments: 8743                               Nokia
Intended status: Bell Labs
Category: Informational                                      F. Baboescu
Expires: December 2, 2019
ISSN: 2070-1721                                                 Broadcom
                                                                  J. Zhu
                                                                   Intel
                                                              J. Mueller
                                                                    AT&T
                                                                  S. Seo
                                                           Korea Telecom
                                                            May 31, 2019

                  Multiple Access
                                                              March 2020

                Multi-Access Management Services
                draft-kanugovi-intarea-mams-framework-04 (MAMS)

Abstract

   In multiconnectivity scenarios, the end-user devices clients can simultaneously
   connect to multiple networks based on different access technologies
   and network architectures like WiFi, Wi-Fi, LTE, and DSL.  Both the quality
   of experience of the users and the overall network utilization and
   efficiency may be improved through the smart selection and
   combination of access and core network paths that can dynamically
   adapt to changing network conditions.

   This document presents a unified problem statement and introduces a
   solution for managing multiconnectivity.  The solution has been
   developed by the authors based on their experiences in multiple
   standards bodies bodies, including the IETF and 3GPP, but the 3GPP.  However, this
   document is not an Internet Standard Standards Track specification, and it
   does not represent the consensus opinion of the IETF.

   This document describes the requirements, solution principles, and an architectural the
   architecture of the Multi-Access Management Services (MAMS)
   framework.  The MAMS framework that aims to provide best performance while
   being easy to implement in a wide variety of multiconnectivity
   deployments.  It specifies the protocol multi-access management to: 1) for (1) flexibly select selecting
   the best combination of access and core network paths for the uplink
   and
   downlink; as well as 2) determine downlink, and (2) determining the user plane user-plane treatment (e.g.,
   tunneling, encryption) and traffic distribution over the selected links ensuring
   links, to ensure network efficiency and the best possible application
   performance.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
   published for informational purposes.

   This is a contribution to the
   provisions RFC Series, independently of BCP 78 any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its discretion and BCP 79.

   Internet-Drafts makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are working documents not candidates for any level of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list Standard;
   see Section 2 of RFC 7841.

   Information about the current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 2, 2019.
   https://www.rfc-editor.org/info/rfc8743.

Copyright Notice

   Copyright (c) 2019 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   6
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   7
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   8
   4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Access Technology Agnostic  Access-Technology-Agnostic Interworking . . . . . . . . .   9
     4.2.  Support for Common Transport Deployments  . . . . . . . . . .   9
     4.3.  Independent Access Path Selection for Uplink and Downlink   9
     4.4.  Core Selection Independent of Uplink and Downlink Access    9
     4.5.  Adaptive Access Network Path Selection  . . . . . . . . .   9
     4.6.  Multipath Support and Aggregation of Access Link Capacities  . . . . . . . . . . . . . . . . . . . . . . .  10
     4.7.  Scalable Mechanism based Based on User Plane User-Plane Interworking . . .  10
     4.8.  Separate Control Control-Plane and Data Plane functions . . . . . . . .  10 User-Plane Functions
     4.9.  Lossless Path (Connection) Switching  . . . . . . . . . .  10
     4.10. Concatenation and Fragmentation for adaptation Adaptation to MTU
            Differences . . . . . . . . . . . . . . . . . . . . . . .  11
     4.11. Configuring Network Middleboxes based Based on Negotiated
            Protocols . . . . . . . . . . . . . . . . . . . . . . . .  11
     4.12. Policy based Policy-Based Optimal Path Selection . . . . . . . . . . .  11
     4.13. Access Technology Agnostic Access-Technology-Agnostic Control Signaling  . . . . . .  11
     4.14. Service Discovery and Reachability  . . . . . . . . . . .  11
   5.  Solution Principles . . . . . . . . . . . . . . . . . . . . .  12
   6.  MAMS Reference Architecture . . . . . . . . . . . . . . . . .  12
   7.  MAMS Protocol Architecture  . . . . . . . . . . . . . . . . .  15
     7.1.  MAMS Control-Plane Protocol . . . . . . . . . . . . . . .  15
     7.2.  MAMS User Plane User-Plane Protocol  . . . . . . . . . . . . . . . .  16
   8.  MAMS Control Plane Control-Plane Procedures . . . . . . . . . . . . . . . .  18
     8.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  18
     8.2.  Common fields Fields in MAMS Control Messages  . . . . . . . . .  20
     8.3.  Common Procedures for MAMS Control Messages . . . . . . .  20
       8.3.1.  Message Timeout . . . . . . . . . . . . . . . . . . .  20
       8.3.2.  Keep Alive  Keep-Alive Procedure  . . . . . . . . . . . . . . . .  20
     8.4.  Discovery & and Capability Exchange . . . . . . . . . . . . .  21
     8.5.  User Plane  User-Plane Configuration  . . . . . . . . . . . . . . . .  25
     8.6.  MAMS Path Quality Estimation  . . . . . . . . . . . . . .  29
       8.6.1.  MX Control PDU definition . . . . . . . . . . . . . .  31 Definition
       8.6.2.  Keep-Alive Message  . . . . . . . . . . . . . . . . .  32
       8.6.3.  Probe REQ/ACK  Probe-REQ/ACK Message . . . . . . . . . . . . . . . .  32
     8.7.  MAMS Traffic Steering . . . . . . . . . . . . . . . . . .  33
     8.8.  MAMS Application MADP Association . . . . . . . . . . . .  34
     8.9.  MAMS Network ID Indication  . . . . . . . . . . . . . . .  35
     8.10. MAMS Client Measurement Configuration and Reporting . . .  36
     8.11. MAMS Session Termination Procedure  . . . . . . . . . . .  38
     8.12. MAMS Network Analytics Request Procedure  . . . . . . . .  39
   9.  Generic MAMS Signaling Flow . . . . . . . . . . . . . . . . .  41
   10. Relation Relationship to IETF Technologies . . . . . . . . . . . . . . . .  43
   11. Applying MAMS Control Procedures with MPTCP Proxy as User Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . .  43
   12. Applying MAMS Control Procedures for Network Assisted Network-Assisted Traffic
           Steering when there is When There Is No Convergence Layer . . . . . . . . .  49
   13. Co-existence Coexistence of MX Adaptation and MX Convergence Layers . . .  51
   14. Security Considerations . . . . . . . . . . . . . . . . . . .  51
     14.1.  MAMS Control Plane Control-Plane Security  . . . . . . . . . . . . . .  51
     14.2.  MAMS User Plane User-Plane Security . . . . . . . . . . . . . . . .  52
   15. Implementation Considerations . . . . . . . . . . . . . . . .  52
   16. Applicability to Multi Access Multi-Access Edge Computing  . . . . . . . .  52
   17. Related work Work in other Other Industry and Standards Forums . . . . .  53
   18. Contributing Authors  . . . . . . . . . . . . . . . . . . . .  53
   19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  54
   20. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  54
   21.
   19. References  . . . . . . . . . . . . . . . . . . . . . . . . .  54
     21.1.
     19.1.  Normative References . . . . . . . . . . . . . . . . . .  54
     21.2.
     19.2.  Informative References . . . . . . . . . . . . . . . . .  54
   Appendix A.  MAMS Control Plane Control-Plane Optimization over Secure
           Connections  . . . . . . . . . . . . . . . . . . . .  56
   Appendix B.  MAMS Application Interface . . . . . . . . . . . . .  57
     B.1.  Overall Design  . . . . . . . . . . . . . . . . . . . . .  57
     B.2.  Notation  . . . . . . . . . . . . . . . . . . . . . . . .  57
     B.3.  Error Indication  . . . . . . . . . . . . . . . . . . . .  57
     B.4.  CCM APIs  . . . . . . . . . . . . . . . . . . . . . . . .  57
       B.4.1.  Get  GET Capabilities  . . . . . . . . . . . . . . . . . .  57
       B.4.2.  Post App  Posting Application Requirements . . . . . . . . . . . . . . . .  58
       B.4.3.  Get  Getting Predictive Link Parameters  . . . . . . . . . . .  59
   Appendix C.  JSON Specification for  MAMS Control Plane  . . . . .  60 Control-Plane Messages Described Using JSON
     C.1.  Protocol Specification: General Processing  . . . . . . .  60
       C.1.1.  Notation  . . . . . . . . . . . . . . . . . . . . . .  60
       C.1.2.  Discovery Procedure . . . . . . . . . . . . . . . . .  61
       C.1.3.  System Information Procedure  . . . . . . . . . . . .  61
       C.1.4.  Capability Exchange Procedure . . . . . . . . . . . .  62
       C.1.5.  User Plane  User-Plane Configuration Procedure  . . . . . . . . .  63
       C.1.6.  Reconfiguration Procedure . . . . . . . . . . . . . .  65
       C.1.7.  Path Estimation Procedure . . . . . . . . . . . . . .  66
       C.1.8.  Traffic Steering  Traffic-Steering Procedure  . . . . . . . . . . . . .  67
       C.1.9.  MAMS Application MADP Association . . . . . . . . . .  68
       C.1.10. MX SSID Indication . . . . . . . . . . . . . . . . . . .  69
       C.1.11. Measurements  . . . . . . . . . . . . . . . . . . . .  70
       C.1.12. Keep Alive  . . . . . . . . . . . . . . . . . . . . .  71 Keep-Alive
       C.1.13. Session Termination Procedure . . . . . . . . . . . .  72
       C.1.14. Network Analytics . . . . . . . . . . . . . . . . . .  73
     C.2.  Protocol Specification: Data Types  . . . . . . . . . . .  74
       C.2.1.  MXBase  . . . . . . . . . . . . . . . . . . . . . . .  74
       C.2.2.  Unique Session Id . . . . . . . . . . . . . . . . . .  75 ID
       C.2.3.  NCM Connections . . . . . . . . . . . . . . . . . . .  76
       C.2.4.  Connection Information  . . . . . . . . . . . . . . .  76
       C.2.5.  Features and Their Activation Status  . . . . . . . . . . . . .  77
       C.2.6.  Anchor Connections  . . . . . . . . . . . . . . . . .  77
       C.2.7.  Delivery Connections  . . . . . . . . . . . . . . . .  78
       C.2.8.  Method Support  . . . . . . . . . . . . . . . . . . .  78
       C.2.9.  Convergence Methods . . . . . . . . . . . . . . . . .  78
       C.2.10. Adaptation Methods  . . . . . . . . . . . . . . . . .  79
       C.2.11. Setup of Anchor Connections . . . . . . . . . . . . .  79
       C.2.12. Init Probe Results  . . . . . . . . . . . . . . . . .  81
       C.2.13. Active Probe Results  . . . . . . . . . . . . . . . .  82
       C.2.14. Downlink Delivery . . . . . . . . . . . . . . . . . .  82
       C.2.15. Uplink Delivery . . . . . . . . . . . . . . . . . . .  82
       C.2.16. Traffic Flow Template . . . . . . . . . . . . . . . .  83
       C.2.17. Measurement Report Configuration  . . . . . . . . . .  83
       C.2.18. Measurement Report  . . . . . . . . . . . . . . . . .  84
     C.3.  Schemas in JSON . . . . . . . . . . . . . . . . . . . . .  85
       C.3.1.  MX Base Schema  . . . . . . . . . . . . . . . . . . .  85
       C.3.2.  MX Definitions  . . . . . . . . . . . . . . . . . . .  86
       C.3.3.  MX Discover . . . . . . . . . . . . . . . . . . . . .  93
       C.3.4.  MX System Update  . . . . . . . . . . . . . . . . . .  93 Info
       C.3.5.  MX Capability Request . . . . . . . . . . . . . . . .  94
       C.3.6.  MX Capability Response  . . . . . . . . . . . . . . .  95
       C.3.7.  MX Capability Ack . . . . . . . . . . . . . . . . . .  96 Acknowledge
       C.3.8.  MX Reconfiguration Request  . . . . . . . . . . . . .  97
       C.3.9.  MX Reconfiguration Response . . . . . . . . . . . . .  98
       C.3.10. MX UP Setup Configuration . . . . . . . . . . . . . .  99 Request
       C.3.11. MX UP Setup Confirmation  . . . . . . . . . . . . . . 100
       C.3.12. MX Traffic Steering Request . . . . . . . . . . . . . 101
       C.3.13. MX Traffic Steering Response  . . . . . . . . . . . . 101
       C.3.14. MX Application MADP Association Request . . . . . . . 102
       C.3.15. MX Application MADP Association Response  . . . . . . 103
       C.3.16. MX Path Estimation Request  . . . . . . . . . . . . . 103
       C.3.17. MX Path Estimation Report . . . . . . . . . . . . . . 104 Results
       C.3.18. MX SSID Indication  . . . . . . . . . . . . . . . . . 105
       C.3.19. MX Measurements Measurement Configuration . . . . . . . . . . . . 106
       C.3.20. MX Measurements Measurement Report  . . . . . . . . . . . . . . . 107
       C.3.21. MX Keep Alive Keep-Alive Request . . . . . . . . . . . . . . . . 109
       C.3.22. MX Keep Alive Keep-Alive Response  . . . . . . . . . . . . . . . 109
       C.3.23. MX Session Termination Request  . . . . . . . . . . . 109
       C.3.24. MX Session Termination Response . . . . . . . . . . . 110
       C.3.25. MX Network Analytics Request  . . . . . . . . . . . . 110
       C.3.26. MX Network Analytics Response . . . . . . . . . . . . 111
     C.4.  Examples in JSON  . . . . . . . . . . . . . . . . . . . . 112
       C.4.1.  MX Discover . . . . . . . . . . . . . . . . . . . . . 112
       C.4.2.  MX System Update  . . . . . . . . . . . . . . . . . . 112 Info
       C.4.3.  MX Capability Request . . . . . . . . . . . . . . . . 113
       C.4.4.  MX Capability Response  . . . . . . . . . . . . . . . 115
       C.4.5.  MX Capability Ack . . . . . . . . . . . . . . . . . . 116 Acknowledge
       C.4.6.  MX Reconfiguration Request  . . . . . . . . . . . . . 116
       C.4.7.  MX Reconfiguration Response . . . . . . . . . . . . . 117
       C.4.8.  MX UP Setup Configuration Request . . . . . . . . . . 117
       C.4.9.  MX UP Setup Confirmation  . . . . . . . . . . . . . . 119
       C.4.10. MX Traffic Steering Request . . . . . . . . . . . . . 119
       C.4.11. MX Traffic Steering Response  . . . . . . . . . . . . 121
       C.4.12. MX Application MADP Association Request . . . . . . . 121
       C.4.13. MX Application MADP Association Response  . . . . . . 122
       C.4.14. MX Path Estimation Request  . . . . . . . . . . . . . 122
       C.4.15. MX Path Estimation Results  . . . . . . . . . . . . . 123
       C.4.16. MX SSID Indication  . . . . . . . . . . . . . . . . . 123
       C.4.17. MX Measurements Measurement Configuration . . . . . . . . . . . . 124
       C.4.18. MX Measurements Measurement Report  . . . . . . . . . . . . . . . 125
       C.4.19. MX Keep Alive Keep-Alive Request . . . . . . . . . . . . . . . . 127
       C.4.20. MX Keep Alive Keep-Alive Response  . . . . . . . . . . . . . . . 127
       C.4.21. MX Session Termination Request  . . . . . . . . . . . 127
       C.4.22. MX Session Termination Response . . . . . . . . . . . 127
       C.4.23. MX Network Analytics Request  . . . . . . . . . . . . 128
       C.4.24. MX Network Analytics Response . . . . . . . . . . . . 128
   Appendix D.  Definition of APIs provided Provided by the CCM to the
           Applications at the Client . . . . . . . . . . . . . 129
   Appendix E.  Implementation Example using Using Python for MAMS Client
           and Server . . . . . . . . . . . . . . . . . . . . . 137
     E.1.  Client Side  Client-Side Implementation  . . . . . . . . . . . . . . . 137
     E.2.  Server Side  Server-Side Implementation  . . . . . . . . . . . . . . . 139
   Acknowledgments
   Contributors
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 141

1.  Introduction

   Multi Access

   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 application the
   application's needs.
   It  The MAMS framework leverages network
   intelligence and policies to dynamically adapt traffic distribution
   across selected paths and user plane treatment 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 user-plane data between the functional elements in the
   network and the end-user device, client, and thus without any impact to on the control control-
   plane signaling schemes of the underlying access network(s). networks.  For
   example, in a multi-access network with LTE and WiFi Wi-Fi technologies,
   existing LTE and existing WiFi Wi-Fi signaling procedures will be used to setup set up
   the LTE and WiFi Wi-Fi connections, respectively, and MAMS specific control plane MAMS-specific
   control-plane messages are carried as LTE or WiFi user plane Wi-Fi user-plane data.
   The MAMS framework defined in this document provides the capabilities of capability
   to make a smart selection
   and of a flexible combination of access paths
   and core network paths, as well as to choose the user plane user-plane treatment
   when the traffic is distributed across the selected paths.  Thus, it
   is a broad programmable framework providing that provides functions beyond the
   simple sharing of network policies such as those provided by the
   Access Network Discovery and Selection Function (ANDSF) [ANDSF] that [ANDSF],
   which offers policies and rules for assisting 3GPP devices clients to
   discover and select available access networks.  Further, it allows
   the choice and configuration of user plane user-plane treatment for the traffic
   over the multiple paths, depending on the
   needs of the application. application's needs.

   The MAMS framework mechanisms are not dependent on any specific
   access network type types or user plane user-plane protocols like (e.g., TCP, UDP, GRE, MPTCP etc.  It co-exists Generic
   Routing Encapsulation (GRE) [RFC2784] [RFC2890], Multipath TCP
   (MPTCP) [RFC6824]).  The MAMS framework coexists and complements the
   existing protocols by providing a way to negotiate and configure these
   those protocols based on client and network
   capabilities per access basis to match their use for to a given multi- multi-access scenario
   based on client and network capabilities, and the specific needs of
   each access scenario. network path.  Further, it the MAMS framework allows load
   balancing of the traffic flows across the selected multiple accesses access network
   paths, and the exchange of network state information to be used for
   network intelligence to optimize the performance of such protocols.

   The

   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 either 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 IP overlay across the
   multiple paths.  This allows the scheme to be future proof "future proof" by
   allowing independent technology evolution of the existing access and
   core networks as well as, as seamless integration of new access
   technologies.

   The solution described in this document has been developed by the
   authors
   authors, based on their experiences in multiple standards bodies bodies,
   including the IETF and 3GPP, but the 3GPP.  However, this document is not an
   Internet Standard Standards Track specification, and it does not represent the
   consensus opinion of the IETF.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   "Client": The

   Client:  An end-user device supporting that supports connections with multiple
      access nodes, possibly over different access technologies.

   "Multiconnectivity Client":  Also
      called a user device or user equipment (UE).

   Multiconnectivity Client:  A client with multiple network
      connections.

   "Access network":

   Access Network:  The segment in the network that delivers user data
      packets to the client via an access link like WiFi such as a Wi-Fi airlink,
      an LTE airlink, or DSL.

   "Core":

   Core:  The functional element that anchors the client IP address used
      for communication with applications via the network.

   "Network

   Network Connection manager"(NCM): Manager (NCM):  A functional entity in the network
      that handles MAMS control messages from the client and configures
      the distribution of data packets over the multiple available access and
      core network paths, and user plane manages the user-plane treatment (e.g.,
      tunneling, encryption) of the traffic flows.

   "Client

   Client Connection Manager" Manager (CCM):  A functional entity in the client
      that exchanges MAMS Signaling signaling messages with the Network Connection Manager NCM, and which
      configures the multiple network paths at the client for the transport of
      user data.

   "Network Multi Access

   Network Multi-Access Data Proxy" Proxy (N-MADP): This  A functional entity in the
      network that handles the forwarding of user data traffic forwarding across
      multiple network paths.  The N-MADP is responsible for MAMS MAMS-
      related user-plane functionalities in the network.

   "Client Multi Access

   Client Multi-Access Data Proxy" Proxy (C-MADP): This  A functional entity in the
      client that handles the forwarding of user data traffic forwarding across
      multiple network paths.  The C-MADP is responsible for MAMS MAMS-
      related user-plane functionalities in the client.

   "Anchor Connection":

   Anchor Connection:  Refers to the network path from the N-MADP to the user plane
      user-plane gateway (IP anchor ) anchor) that has assigned an IP address to
      the client.

   "Delivery Connection":

   Delivery Connection:  Refers to the network path from the N-MADP to
      the client.

   Uplink (also referred to as "UL" in this document):  Refers to the
      direction of a connection from a client toward the network.

   Downlink (also referred to as "DL" in this document):  Refers to the
      direction of a connection from the network toward a client.

3.  Problem Statement

   Typically, an end-user device a client has access to multiple communication networks
   based on different technologies, say LTE, WiFi, DSL,
   MuLTEfire, technologies for accessing application services. services,
   for example, LTE, Wi-Fi, DSL, or MulteFire.  Different technologies
   exhibit benefits and limitations in different scenarios.  For
   example, WiFi Wi-Fi provides high throughput for end users when under
   good coverage, their Wi-
   Fi coverage is good, but the throughput degrades significantly as the a
   given user moves closer to the edge of WiFi its Wi-Fi coverage area
   (typically in the range of a few tens of meters) or with large if the user
   population is large (due to contention
   based WiFi 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 scenarios, due to
   controlled scheduling and licensed spectrum licensed-spectrum usage.

   Additionally, the use of a particular access network path is often
   coupled with the use of its associated core network and the services
   that are offered by it. that network.  For example, in an enterprise that
   has deployed both WiFi Wi-Fi and LTE networks, the enterprise services, like
   printers, Corporate Audio
   such as printers and Video corporate audio/video conferencing, are
   accessible only via WiFi Wi-Fi access connected to the enterprise hosted (WiFi) enterprise-hosted
   (Wi-Fi) core, whereas the LTE access can be used to get operator core anchored
   services
   services, including access to the public Internet.

   Thus, application performance in different scenarios becomes
   dependent on the choice of the access networks (e.g.  WiFi, LTE,
   etc.) (e.g., Wi-Fi, LTE) and the used
   network and transport protocols (e.g. used (e.g., VPN, MPTCP,
   GRE etc.). 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 and used
   as well as the protocols used for uplink and downlink data delivery.

   For example, in uncongested scenarios and when the user's Wi-Fi
   coverage is good, to ensure best performance for enterprise
   applications at all times, in uncongested scenarios, when the user is under good
   WiFi coverage, it would be beneficial to use WiFi Wi-Fi access in
   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 WiFi coverage, Wi-Fi coverage area, the use of WiFi 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
   coverage, while WiFi Wi-Fi may still continue to be used for the downlink.

4.  Requirements

   The requirements set out in this section are for define the definition of behavior of the
   MAMS mechanism and the related functional elements.

4.1.  Access Technology Agnostic  Access-Technology-Agnostic Interworking

   The access nodes may MAY use different technology types like LTE, WiFi,
   etc. (LTE, Wi-Fi,
   etc.).  The framework, however, MUST be agnostic to about the type of
   underlying technology used at by the access network.

4.2.  Support for Common Transport Deployments

   The network path selection and user data distribution MUST work
   transparently across various transport deployments that include end-
   to-end IPsec, VPNs, and middleboxes like NATs and proxies.

4.3.  Independent Access Path Selection for Uplink and Downlink

   A Client client SHOULD be able to transmit on the uplink and, and receive on the
   downlink, using one or more accesses. access networks.  The selection selections of the
   access paths for the uplink and downlink SHOULD happen independent of each
   other. independently.

4.4.  Core Selection Independent of Uplink and Downlink Access

   A client SHOULD flexibly select the Core, independent core independently of the access
   paths used to reach the Core, core, depending on the application application's needs,
   local policies policies, and the result of MAMS control plane control-plane negotiation.

4.5.  Adaptive Access Network Path Selection

   The framework MUST have the ability to determine the quality of each
   of the network paths, e.g. e.g., access link delay and capacity.  The  This
   information regarding network path quality information 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 information, quality, in addition to
   other considerations like network policies, for optimizing network
   usage and enhancing QoE the Quality of Experience (QoE) delivered to the
   user.

4.6.  Multipath Support and Aggregation of Access Link Capacities

   The framework MUST support the distribution and aggregation of user
   data across multiple network paths at the IP layer.  The client
   SHOULD be able to leverage the combined capacity of the multiple
   network connections by enabling the simultaneous transport of user
   data over multiple network paths.  If required, packet re-ordering reordering
   needs to be done at the receiver.  The framework MUST allow the
   flexibility to choose the flow steering flow-steering and aggregation protocols
   based on capabilities supported by the client and the network data user-
   plane entities.  The
   multi-connection multiconnection aggregation solution MUST
   support existing transport and network layer network-layer protocols like TCP, UDP,
   and GRE.  The framework MUST allow the use and configuration of
   existing aggregation protocols such as
   Multi-Path TCP(MPTCP) MPTCP and SCTP. SCTP [RFC4960].

4.7.  Scalable Mechanism based Based on User Plane User-Plane Interworking

   The framework MUST leverage commonly available transport, routing routing,
   and tunneling capabilities to provide user plane user-plane interworking
   functionality.  The addition of functional elements in the user plane user-plane
   path between the client and the network MUST not NOT impact the access
   technology specific access-
   technology-specific procedures.  This makes the solution easy to
   deploy and scale when different networks are added and removed.

4.8.  Separate Control Control-Plane and Data Plane functions User-Plane Functions

   The client MUST use the control plane control-plane protocol to negotiate the
   following with the
   network, network: (1) the choice of access and core network
   paths for both the uplink and downlink, as well as and (2) the user plane user-plane
   protocol treatment.  The control plane MUST configure the actual user plane
   user-plane data distribution function per this negotiation.  A common
   control protocol SHOULD allow the creation of multiple user plane user-plane
   function instance instances with potentially different user plane (e.g. user-plane (e.g.,
   tunneling) protocol types.  This enables maintaining a clear
   separation between the control control-plane and
   data plane user-plane functions,
   allowing the framework to be scalable and extensible, e.g. e.g., using SDN based architecture
   architectures and implementations. implementations based on Software-Defined
   Networking (SDN).

4.9.  Lossless Path (Connection) Switching

   When switching data traffic from one path (connection) to another,
   packets may be lost or delivered out-of-order, which out of order; this will have
   negative impacts impact on the performance of higher layer higher-layer protocols, e.g. e.g.,
   TCP.  The framework SHOULD provide the necessary mechanisms to ensure in-
   order
   in-order delivery at the receiver, e.g. e.g., during path switching.  The
   framework MUST not NOT cause any packet loss beyond losses that of access
   network mobility functions may cause.

4.10.  Concatenation and Fragmentation for adaptation Adaptation to MTU Differences

   Different network paths may have different security and middlebox
   (e.g
   (e.g., NAT) configurations, which configurations.  These configurations will lead to the
   use of different tunneling protocols for the transport of data
   between the network user
   plane user-plane function and the client.  As a result,
   different effective payload sizes (e.g. per network path are possible
   (e.g., due to variable encapsulation header overheads)
   per network path are possible. overheads).  Hence, the
   MAMS framework SHOULD support the fragmentation of a single IP packet payload
   across MTU sized MTU-sized IP packets to avoid IP packet fragmentation when
   aggregating packets from different paths.  Further, the concatenation
   of multiple IP packets into a single IP packet to improve efficiency
   in packing the MTU size
   should SHOULD also be supported.

4.11.  Configuring Network Middleboxes based Based on Negotiated Protocols

   The framework SHOULD enable the identification of the optimal parameters
   that may be used for configuring the middle-boxes, settings,
   like radio link dormancy timers, binding expiry times times, and supported
   MTUs, for
   efficient operation of the user plane protocols, based on parameters negotiated between the client and the
   network, e.g.  Configuring 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 in NATs when UDP transport is used in
   contrast to the scenario where versus TCP is configured at the transport
   layer. used.

4.12.  Policy based  Policy-Based Optimal Path Selection

   The framework MUST support consideration both the implementation of policies at the client,
   in addition to
   client and guidance from the network, network for network path selection
   addressing that
   will address different application requirements.

4.13.  Access Technology Agnostic  Access-Technology-Agnostic Control Signaling

   The control plane control-plane signaling MUST NOT be dependent on the underlying
   access technology procedures, e.g. be i.e., it is carried transparently as transparently, like
   application data, on the user plane.  It should  The MAMS framework SHOULD
   support the delivery of control plane control-plane signaling over
   the existing
   Internet protocols, e.g. e.g., TCP or UDP.

4.14.  Service Discovery and Reachability

   There can be multiple instances of the control control-plane and user plane user-plane
   functional elements of the framework, either collocated or hosted on
   separate network elements, elements and reachable via any of the available
   user plane
   user-plane paths.  The client MUST have the flexibility to choose the
   appropriate control plane control-plane instance in the network and use the control
   plane
   control-plane signaling to choose the desired user plane user-plane functional
   element instances.  The client's choice can be based on
   considerations like, such as, but not limited to, the quality of the link
   through which the network function is reachable, client preferences, pre-configuration
   preconfiguration, etc.

5.  Solution Principles

   This document proposes describes the Multiple Access Multi-Access Management Services(MAMS) Services (MAMS)
   framework for dynamic selection and of a flexible combination of access
   and core network paths independently for the uplink and downlink, as well as the user plane
   user-plane treatment for the traffic spread across the selected
   links.  MAMS framework consists of clearly separated control  The user-plane paths, and user plane functions in the access and core network
   connections, can be selected independently for the uplink and
   downlink.  For example, the client.  The control
   plane protocol allows configuration network paths chosen for the uplink do
   not apply any constraints on the choice of paths for the downlink.
   The uplink and downlink network paths can be chosen based on the
   application needs and on the characteristics and available resources
   on different network connections.  For example, a Wi-Fi connection
   can be chosen for the downlink for transporting high-bandwidth data
   from the network to the client, whereas an LTE connection can be
   chosen to carry the low-bandwidth feedback to the application server.

   Also, depending on the characteristics of the access network link,
   different processing would be needed on the user-plane packets on
   different network paths.  Encryption would be needed on a Wi-Fi link
   to secure user-plane packets, but not on an LTE link.  Tunneling
   would be needed to ensure client and network end-point reachability
   over NATs.  Such differentiated user-plane treatment can be
   accomplished by configuration of user plane-protocols (e.g., IPsec)
   specific to each link.

   The MAMS framework consists of clearly separated control- and user-
   plane functions in the network and the client.  The control-plane
   protocol allows the configuration of the user-plane protocols and
   desired network paths for the transport of application traffic.  The
   control plane
   control-plane messages are carried as user plane user-plane data over any of the
   available network paths between the peer control plane control-plane functional
   elements in the client and the network . network.  Multiple user plane user-plane paths
   are dynamically distributed across multiple access networks and
   aggregated in side the common core network. network (by the N-MADP).  The access network network's
   diversity is not exposed to the application servers servers, but is kept
   within the scope of the elements defined in this framework.  This offloads
   reduces the burden placed on application servers from reacting that would otherwise
   have to react to access link changes caused
   to by mobility events or
   changing of link characteristics.

   The selection of paths and user plane user-plane treatment of the traffic, traffic is
   based on (1) the negotiation of capabilities (of device and network) client and probing of network capabilities, and
   (2) link probing (i.e., checking the quality of links between the user plane
   user-plane functional elements at the end-user device/client client and the network.  The network).  This
   framework enables leveraging network intelligence to setup set up and
   dynamically configure the best access network path combination based
   on device client and network capabilities, application needs an application's needs, and
   knowledge of the network state.

6.  MAMS Reference Architecture

   Figure 1 illustrates the MAMS architecture for the scenario where a
   client is served by multiple (n) networks.  It also introduces the
   following functional elements:

   *  The NCM and the CCM in the control plane.

   *  The N-MADP and the C-MADP in the user plane.

        +--------------------------------------------------------+
        |           +---------------+       +---------------+          +----------------+       +----------------+   |
        |          |                |           !               !       !               !       |                |           !Core(IP anchor)! +---+ !Core(IP anchor)!   |
        |           !network          |Core (IP anchor)| ..... |Core (IP anchor)|   |
        |          |Network 1      !       !(network 'n'   !       |       |Network "n"     |   |
        |           !               !       !               !          |                |           +---------------+       +---------------+       |                |   |
        |          +----------------+       +----------------+   |
        |                           \             /              |
        |                     Anchor \   +---+  ...... Anchor            |
        |                     Connection 1     Connection 'n' "n"    |
        |                              \       /                 |
        |              +---------------+\+---+/+------+          |
        |              | |-----+ +-----+      +----------+    |          |
        |            +----|NCM ! +--------------| NCM |      |  N-MADP  |    |          |
        | |            | |-----+ +-----+      +----------+    |          |
        | |            +------------------------------+          |
        | |                           /           \              |
        |    Control Plane |Control-Plane       Delivery  ...... Delivery  +----+Delivery         |
        |    Path |Path (over any      Connection 1     Connection 'n' "n"   |
        |    access |access user plane)      /                 \           |
        | |                       /                   \          |
        | |       +------------------+        +---------------+  |
        | |       |    Access        | +---+ ...... | Access        |  |
        | |       |  n/w    Network 1     |        |  n/w 'n' Network "n"   |  |
        | |       +------------------+        +---------/-----+        +---------------+  |
        +-----------------------------\----------------/---------+
          |                            \              /
          |           +---- -\------------/-+                  +----------\------------/-+
          |                  | +---+     \ |------+ +------+ /  |
                     +------------+CCM |
          +--------------------+CCM|      \|C-MADP|/   |
                             | +---+       +------+    |
                             |       Client            |
                                 +---------------------+
                             +-------------------------+

                   Figure 1: MAMS Reference Architecture

   Figure 1 illustrates MAMS architecture for the scenario of a client
   served by multiple (n) networks.  It introduces the following
   functional elements,

   o  Network Connection Manager (NCM) and Client Connection Manager
      (CCM) in the control plane, and
   o  Network Multi Access Data Proxy (N-MADP) and Client Multi Access
      Data Proxy (C-MADP) handling the user plane.

   NCM: It

   The NCM is the functional element in the network that handles the
   MAMS control plane control-plane procedures.  It configures the network (N-MADP)
   and client (C-MADP) user plane functions like user-plane functions, such as negotiating with
   the client
   on for the use of available access network paths, protocols protocols,
   and rules for processing the user plane user-plane traffic, as well as link link-
   monitoring procedures.  The control plane control-plane messages between the NCM
   and the CCM are transported as an overlay, overlay on the user plane, without
   any impact to on the underlying access networks.

   CCM: It

   The CCM is the peer functional element in the client for handling
   MAMS control plane control-plane procedures.  It manages multiple network
   connections at the client.  It is responsible for exchange of  The CCM exchanges MAMS signaling messages
   with the NCM for supporting to support such functions like as the configuration of the UL
   and DL user network path configuration for transporting user data
   packets, link probing packets and reporting to support the
   adaptive selection of network path
   selection by NCM. the NCM by reporting on the
   results of link probing.  In the downlink, for the user data received by
   the client, it configures the C-MADP such that application data packet
   packets can be received over any of access link so that the accesses to 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
   policy and network policy policies delivered by the NCM.

   N-MADP: It

   The N-MADP is the functional element in the network that handles the
   forwarding of user data traffic forwarding across multiple network paths, as
   well as other user-plane functionalities like (e.g., encapsulation,
   fragmentation, concatenation, reordering, retransmission, etc.  It retransmission).  The
   N-MADP is the distribution node that routes (1) the uplink user plane user-plane
   traffic to the appropriate anchor connection towards toward the core network,
   and (2) the downlink user traffic to the client over the appropriate
   delivery
   connection(s). connections.  In the downlink, the NCM configures the use of
   delivery connections, connections and user plane user-plane protocols at the N-MADP for
   transporting user data traffic.  The N-MADP should SHOULD implement ECMP
   support for the down link downlink traffic.  Or alternatively,  Alternatively, it may MAY be connected
   to a router with ECMP functionality.  The load balancing 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, data volume based user-volume-based percentage distribution,
   and link availability and feedback information from the exchange of
   MAMS signaling messages with the CCM at the Client.. client.  The N-MADP can
   be configured with appropriate user plane user-plane protocols to support both per-
   flow
   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, 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 e.g., enterprise-hosted
   application flows via a Wi-Fi Anchor, Mobile Operator hosted anchor or mobile-operator-hosted
   applications via the
   Cellular Core.

   C-MADP: It cellular core.

   The C-MADP is the functional element in the client that handles the
   MAMS user plane user-plane data procedures.  The C-MADP is configured by CCM 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 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 user plane
   data the forwarding of user-plane data across
   multiple delivery connections and associated user-plane functions like
   (e.g., encapsulation, fragmentation, concatenation, reordering, retransmissions, etc.
   retransmissions).

   The NCM and N-MADP can be either collocated or instantiated on
   different network nodes.  The NCM can setup 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., instances.  This is beneficial in multple
   multiple deployment scenarios, like the following examples.

   o examples:

   *  Different N-MADP instances to handle different sets of clients for
      load balancing across clients
   o  Address deployment clients.

   *  Network topologies e.g. where the N-MADP is hosted at the user
      plane user-plane
      node at the access edge or in the core network, while the NCM is
      hosted at the access edge node)
   o  Address access node.

   *  Access network technology architecture.  For exanple, 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 traffic.
   o networks.

   *  A single client can be configured to use multiple N-MADP
      instances.  This is beneficial in addressing different application
      requirements.  For example, separate N-MADP instances to handle
      traffic that is based on TCP and UDP transport based traffic. transport.

   Thus, the MAMS architecture flexibly addresses multiple network
   deployments.

7.  MAMS Protocol Architecture

   This section describes the protocol structure for the MAMS User user-plane
   and
   Control plane control-plane functional elements.

7.1.  MAMS Control-Plane Protocol

   Figure 2 shows the default MAMS control plane control-plane protocol stack.
   WebSocket [RFC6455] is used for transporting management and control
   messages between the NCM and the CCM.

               +------------------------------------------+
               |    Multi Access                                          |
               |    Multi-Access (MX) Control Message     |
               |                                          |
               +------------------------------------------+
               |                                          |
               |                WebSocket                 |
               |                                          |
               +------------------------------------------+
               |                                          |
               |                 TCP/TLS                  |
               |                                          |
               +------------------------------------------+

           Figure 2: TCP-based TCP-Based MAMS Control Plane Control-Plane Protocol Stack

7.2.  MAMS User Plane User-Plane Protocol

   Figure 3 shows the MAMS user plane user-plane protocol stack. stack for transporting
   the user payload, e.g., an IP Protocol Data Unit (PDU).

          +-----------------------------------------------------+
          |   User Payload (e.g. Payload, e.g., IP PDU) Protocol Data Unit (PDU)   |
          +-----------------------------------------------------+

       +-----------------------------------------------------------+
       |  +-----------------------------------------------------+  |
       |  | Multi Access Multi-Access (MX) Convergence Sublayer Layer                 |  |
       |  +-----------------------------------------------------+  |
       |  +-----------------------------------------------------+  |
       |  | MX Adaptation   | MX Adaptation   | MX Adaptation   |  |
       |  | Sublayer Layer           | Sublayer Layer           | Sublayer Layer           |  |
       |  | (optional)      | (optional)      | (optional)      |  |
       |  +----------------++--------------+-+------------------+  +-----------------+-----------------+-----------------+  |
       |  | Access #1 IP    | Access #2 IP    | Access #3 IP    |  |
       |  +-----------------------------------------------------+  |
       |                            MAMS User Plane User-Plane Protocol Stack| Stack |
       +-----------------------------------------------------------+

                  Figure 3: MAMS User Plane User-Plane Protocol Stack

   It

   The MAMS user-plane protocol consists of the following two Sublayers:

   o layers:

   *  Multi-Access (MX) Convergence Sublayer: Layer: The MAMS framework configures
      the Convergence sublayer Layer to perform multi-access
      specific multi-access-specific tasks in
      the user plane.  This layer performs such functions
      like as access
      (path) selection, multi-link (path) aggregation,
      splitting/reordering, splitting/
      reordering, lossless switching, fragmentation,
      concatenation, etc. or concatenation.
      The MX Convergence layer Layer can be implemented by using existing user plane
      user-plane protocols like MPTCP [RFC6824] or Multipath TCP (MPTCP [RFC
      6824]), Multi Path QUIC (MPQUIC [I-D.deconinck-multipath-quic])
      (MPQUIC) [QUIC-MULTIPATH], or by adapting encapsulating header/trailer header/
      trailer schemes like Generic
      Routing and Encapsulation (GRE [RFC 2784], [RFC 2890]), such as GRE [RFC2784] [RFC2890] or Generic
      Multi Access(GMA [I-D.zhu-intarea-gma]).
   o Multi-
      Access (GMA) [INTAREA-GMA].

   *  Multi-Access (MX) Adaptation Sublayer: Layer: The MAMS framework configures
      the Adaptation Sublayer Layer to address transport network
      related transport-network-related aspects like
      such as reachability and security in the user plane.  This layer
      performs functions to handle tunnelling, network layer tunneling, network-layer security,
      and NAT.  The MX Adaptation Layer can be implemented using IPsec,
      DTLS [RFC6347], or a Client NAT (Source NAT at Client the client with
      inverse mapping at the N-MADP [I-D.zhu-intarea-mams-user-protocol]). [INTAREA-MAMS]).  The MX Adaptation
      Layer is optional OPTIONAL and can be independently configured for each of
      the Access Links.  E.g.  In access links.  For example, in a deployment with LTE (assumed
      secure) and Wi-Fi (assumed to not be secure), the MX Adaptation Sublayer
      Layer can be omitted for the LTE link link, but MX Adaptation Sublayer is configured
      as with
      IPsec for securing to secure the Wi-Fi link.  Further details on the MAMS user
      plane are described provided in [I-D.zhu-intarea-mams-user-protocol]. [INTAREA-MAMS].

8.  MAMS Control Plane Control-Plane Procedures

8.1.  Overview

   The CCM and NCM exchange signaling messages to configure the user user-
   plane
   functions, functions via the C-MADP and N-MADP, the N-MADP at the client and network the
   network, respectively.  The means for the CCM to obtain the NCM
   credentials (FQDN (Fully Qualified Domain Name (FQDN) or IP Address) address) for
   sending the initial discovery messages are out of the scope of
   MAMS for this
   document.  As an example, the client can obtain the NCM credentials
   by using such methods like provisioning, as provisioning or DNS query. queries.  Once the
   discovery process is successful, the (initial) NCM can update and
   assign additional NCM addresses, e.g. e.g., based on MCC/MNC Mobile Country Code
   (MCC) / Mobile Network Code (MNC) tuple information received in the
   MX Discovery Message, Discover message, for sending subsequent control plane control-plane messages.

   The CCM discovers and exchanges capabilities with the NCM.  The NCM
   provides the credentials of the N-MADP end-point endpoint and negotiates the
   parameters for the user plane with the CCM.  The CCM configures the
   C-MADP to setup set up the user
   plane user-plane path (e.g. (e.g., MPTCP/UDP Proxy Connection)
   connection) with the N-MADP N-MADP, based on the credentials (e.g. (e.g.,
   (MPTCP/UDP) Proxy IP address and port,
   Associated Core Network Path), 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 user-
   plane treatment with to dynamic network conditions.  The key procedures
   are described in details detail in the following sub-sections. subsections.

                     +-----+                 +-----+
                     | CCM |                 | NCM |
                     +--+--+                 +--+--+
                        |     Discovery and     |
                        |     Capability        |
                        |     Exchange          |

                         <---------------------->
                        |<--------------------->|
                        |                       |
                        |    User Plane     Setup of          |
                        |     User-Plane        |
                        |     Protocols         |
                        |<--------------------->|
                        |    Setup                       |

                         <---------------------->
                        |     Path Quality      |
                        |     Estimation        |

                         <---------------------->
                        |<--------------------->|
                        |                       |
                        | Network capabilities Capabilities  |
                        | e.g. RNIS[ETSIRNIS] e.g., RNIS [ETSIRNIS] |

                         <----------------------+
                        |<----------------------|
                        |                       |
                        |   Network policies Policies    |

                         <----------------------+
                        |<----------------------|
                        +                       +

           "RNIS" stands for "Radio Network Information Service"

                  Figure 4: MAMS Control Plane Control-Plane Procedures

8.2.  Common fields Fields in MAMS Control Messages

   Each MAMS control message consists of the following common fields:

   o

   *  Version: indicates Indicates the version of the MAMS control protocol.
   o

   *  Message Type: indicates Indicates the type of the message, e.g. e.g., MX
      Discovery,
      Discover, MX Capability REQ/RSP etc.
   o Request (REQ) / Response (RSP).

   *  Sequence Number: auto-incremented Auto-incremented integer to uniquely identify a
      transaction of
      particular message exchange, e.g. e.g., MX Capability REQ/RSP. Request/Response.

8.3.  Common Procedures for MAMS Control Messages

   This section describes the common procedures for MAMS Control
   Messages. control
   messages.

8.3.1.  Message Timeout

   After sending a MAMS Control plane control message, the MAMS control-plane peer
   (NCM or CCM) waits for a duration of MAMS_TIMEOUT ms, after sending a MAMS control message, ms before timing
   out when expecting in cases where a response. response was expected.  The sender of the
   message will retransmit the message for MAMS_RETRY times before
   declaring failure. failure if no response is received.  A failure implies that
   the MAMS peer is dead, dead or unreachable, and the sender reverts
   back to
   native non-multi access/single path non-multi-access / single-path mode.  The CCM may initiate the
   MAMS discovery procedure for re-establishment of re-establishing the MAMS session.

8.3.2.  Keep Alive  Keep-Alive Procedure

   MAMS Control plane control-plane peers execute the keep alive keep-alive procedures to ensure
   that the other peers are reachable and to recover from dead-peer
   scenarios.  Each MAMS control plane end-point control-plane endpoint maintains a MAMS_KEEP_ALIVE Keep-Alive
   timer that is set for a duration of MAMS_KEEP_ALIVE_TIMEOUT.  MAMS_KEEP_ALIVE  The
   Keep-Alive timer is reset whenever the peer receives a MAMS Control control
   message.  When MAMS_KEEP_ALIVE the Keep-Alive timer expires, MAMS KEEP ALIVE REQ message an MX Keep-Alive Request
   is sent.

   The values for MAMS_RETRY and MAMS_KEEP_ALIVE_TIMEOUT parameters used
   in keep-alive procedures are deployment dependent, and the means for
   obtaining them are out of scope for this document.  As an example,
   the client and network can obtain the values using provisioning.  On reception
   receipt of a MAMS KEEP ALIVE REQ message, an MX Keep-Alive Request, the receiver responds with a MAMS KEEP ALIVE RSP message. an MX
   Keep-Alive Response.  If the sender does not receive a MAMS Control control
   message in response to MAMS_RETRY number of retries of MAMS KEEP ALIVE REQ message, the MX Keep-Alive
   Request, the MAMS peer declares that the peer is dead. dead or unreachable.
   The CCM may MAY initiate the MAMS Discovery discovery procedure for re-
   establishment of re-establishing
   the MAMS session.

   Additionally, the CCM shall additionally SHALL immediately send an MX KEEP ALIVE REQ message immediately Keep-Alive Request
   to the NCM whenever it detects a handover from one base station/access station /
   access point to another.  During this time time, the user equipment shall client SHALL stop
   using MAMS user plane user-plane functionality in the uplink direction till until it
   receives a an MX KEEP ALIVE RSP Keep-Alive Response from the NCM.

   The MX KEEP ALIVE REQ Keep-Alive Request includes the following information:

   o

   *  Reason: Can be 'Timeout' timeout or 'Handover'.  Reason 'Handover' handover.  Handover shall be used by the
      CCM only on detection of a handover.
   o

   *  Unique Session Identifier: As defined in ID: See Section 8.4.
   o

   *  Connection Id: This field shall be mandatorily be included if ID: If the reason is 'Handover'.
   o handover, the inclusion of this
      field is mandatory.

   *  Delivery Node ID: Identity (ECGI in 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 LTE and WiFi Wi-Fi, this is an AP Id ID or MAC
      address in case of WiFi).  This field shall be mandatorily be
      included if a
      Media Access Control (MAC) address.  If the reason is 'Handover'. "Handover",
      the inclusion of this field is mandatory.

8.4.  Discovery & and Capability Exchange

   Figure 5 shows the MAMS discovery and capability exchange procedure
   consisting of the following key steps: procedure.

      CCM                                                  NCM
       |                                                    |

          +-------
       |------- MX Discovery Discover Message ---------------------->| ----------------------->|
       |                                         +-----------------+
       |                                         |Learn                                         | Learn CCM       |
       |                                         | IP address      |
       |                                         |&                                         | and port        |
       |                                         +-----------------+
       |                                                    |

          |<--------------------------------MX
       |<----------------------------- MX System INFO-----| Info ------|
       |                                                    |

          |---------------------------------MX
       |------------------------------ MX Capability REQ->| REQ -->|
       |<----- MX Capability RSP----------------------------|

          |---------------------------------MX RSP ---------------------------|
       |------------------------------ MX Capability ACK->| ACK -->|
       |                                                    |
       +                                                    +

       Figure 5: MAMS Control Procedure for Discovery & and Capability
                                  Exchange

   This procedure consists of the following key steps:

   Step 1 (Discovery): (discovery): The CCM periodically sends out the an MX Discovery
   Message Discover message
   to a pre-defined predefined (NCM) IP Address/port address/port until an MX System INFO Info message
   is received in acknowledgement. acknowledgment.

   *  The MX Discovery Message Discover message includes the following information:

   o

      -  MAMS Version
   o  MCC/MNC Version.

      -  Mobile Country Code (MCC) / Mobile Network Code (MNC) Tuple:
         Optional Parameter parameter to Identify identify the Operator Network operator network to which
         the client is susbcribed, subscribed, in conformance with the format
         specified in [E212] [ITU-E212].

   *  The MX System INFO Info message includes the following information:

   o

      -  Number of Anchor Connections Connections.

         For each Anchor Connection, it includes anchor connection, the following parameters:

      * parameters are
         included:

         o  Connection ID: Unique identifier for the Anchor Connection
      * anchor connection.

         o  Connection Type (e.g., 0: Wi-Fi; 1: Wi-Fi, 5G NR; 2: MulteFire; 3:
         LTE)
      * NR, MulteFire, LTE).

         o  NCM Endpoint Address (For Control Plane Messages (for control-plane messages over this
         connection)
            connection):

            +  IP Address or FQDN (Fully Qualified Domain Name)

            +  Port Number

   Step 2 (Capability Exchange): On receiving MX System Info message (capability exchange): The CCM learns the IP Address address and port to start the step 2 of
   from the control
   plane connection, and MX System Info message.  It then sends out the MX Capability REQ
   message,
   including which includes the following Parameters:

   o parameters:

   *  MX Feature Activation List: Indicates if whether the corresponding
      feature is supported or not, e.g. e.g., lossless switching,
      fragmentation, concatenation, Uplink uplink aggregation, Downlink downlink
      aggregation,
      Measurement, probing, etc.
   o measurement, probing.

   *  Number of Anchor Connections (Core Networks) (core networks).

      For each Anchor Connection, it includes anchor connection, the following parameters:

      * parameters are included:

      -  Connection ID
      *

      -  Connection Type (e.g., 0: Wi-Fi; 1: Wi-Fi, 5G NR; 2: MulteFire; 3: NR, MulteFire, LTE)
   o

   *  Number of Delivery Connections (Access Links) (access links).

      For each Delivery Connection, it includes delivery connection, the following
      parameters:

      * parameters are
      included:

      -  Connection ID
      *

      -  Connection Type (e.g., 0: Wi-Fi; 1: Wi-Fi, 5G NR; 2: MulteFire; 3: NR, MulteFire, LTE)
   o

   *  MX Convergence Method Support List

      * List:

      -  GMA
      *

      -  MPTCP Proxy
      *

      -  GRE Aggregation Proxy
      *

      -  MPQUIC
   o

   *  MX Adaptation Method Support List

      * List:

      -  UDP Tunnel without DTLS
      *

      -  UDP Tunnel with DTLS
      *

      -  IPsec Tunnel [RFC3948]
      *

      -  Client NAT

   In response, the NCM creates a unique identity for the CCM session, session
   and sends out the MX Capability RSP message, Response, including the following
   information:

   o

   *  MX Feature Activation List: Indicates if whether the corresponding
      feature is enabled or not, e.g. e.g., lossless switching,
      fragmentation, concatenation, Uplink uplink aggregation, Downlink downlink
      aggregation,
      Measurement, probing, etc.
   o measurement, probing.

   *  Number of Anchor Connections (Core Networks) (core networks):

      For each Anchor Connection, it includes anchor connection, the following parameters:

      * parameters are included:

      -  Connection ID
      *

      -  Connection Type (e.g., 0: Wi-Fi; 1: Wi-Fi, 5G NR; 2: MulteFire; 3: NR, MulteFire, LTE)
   o

   *  Number of Delivery Connections (Access Links) (access links):

      For each Delivery Connection, it includes delivery connection, the following
      parameters:

      * parameters are
      included:

      -  Connection ID
      *

      -  Connection Type (e.g., 0: Wi-Fi; 1: Wi-Fi, 5G NR; 2: Multi-Fire; 3: NR, MulteFire, LTE)
   o

   *  MX Convergence Method Support List

      * List:

      -  GMA
      *

      -  MPTCP Proxy
      *

      -  GRE Aggregation Proxy
      *

      -  MPQUIC
   o

   *  MX Adaptation Method Support List

      * List:

      -  UDP Tunnel without DTLS
      *

      -  UDP Tunnel with DTLS
      *

      -  IPsec Tunnel [RFC3948]
      *

      -  Client NAT

   *  Unique Session Identifier: ID: Unique session identifier for the CCM
   which has setup that set
      up the connection.  In case  If the session for the UE already exists exists, then the
      existing unique session identifier is sent
   back.

   o returned.

      -  NCM Id: ID: Unique Identity identity of the NCM in the operator network.
   o

      -  Session Id: ID: Unique identity assigned to the CCM instance by
         this NCM instance.

   In response to the MX Capability RSP message, Response, the CCM sends a
   confirmation (or reject) rejection) in the MX Capability ACK message. Acknowledge.  The MX
   Capability ACK Acknowledge includes the following parameters

   o parameters:

   *  Unique Session Identifier: ID: Same identifier as the identifier provided in
      the MX Capability RSP.
   o  Acknowledgement: Response.

   *  Acknowledgment: An indication if of whether the client has accepted
      or rejected the capability exchange phase.

      *

      -  MX ACCEPT: The CCM Accepts accepts the Capability capability set proposed by the
         NCM.
      *

      -  MX REJECT: The CCM Rejects rejects the Capability capability set proposed by the
         NCM.

   If MX_REJECT is received by the NCM, NCM receives an MX_REJECT, the current MAMS session will be
   terminated.

   If the CCM can no longer continue with the current capabilities, it
   should
   SHOULD send an MX SESSION TERMINATE message Session Termination Request to terminate the MAMS
   session.  In response, the NCM should SHOULD send a an MX SESSION TERMINATE ACK Session Termination
   Response to confirm the termination.

8.5.  User Plane  User-Plane Configuration

   Figure 6 shows the user plane user-plane (UP) configuration procedure consisting of
   the following key steps: procedure.

        CCM                                              NCM
         |                                                |

 |------MX
         |---- MX Reconfiguration REQ (setup)--------------->|

 |<------------------------+MX (setup) ----------->|
         |<-------------------- MX Reconfiguration RSP+---| RSP ---|
         |                                        +-----------+----------------+                                  +-------------------------+
         |                                  | NCM prepares N+MADP N-MADP for |
         |                                  | User Plane|Setup User-Plane Setup        |
         |                                        +----------------------------+

 |<-----------------------------                                  +-------------------------+
         |<-------------------- MX UP Setup Config---|

 |-----| Config -------|
         |---- MX UP Setup CNF+---------------------------->| Confirmation ----------------->|
    +-------------------+                                 |
    |Link "X" is up/down|                                 |
    +-------------------+                                 |

 |-----MX
         |---- MX Reconfiguration REQ (update/release)------->|

 |<------------------------+MX (update/release) -->|
         |<-------------------- MX Reconfiguration RSP+---| RSP ---|

       Figure 6: MAMS Control Procedure for User-Plane Configuration

   This procedure consists of the following two key steps:

   *  Reconfiguration: The CCM informs the NCM about the changes to the
      client's connections - setup of a new connection, teardown of an
      existing connection, or update of parameters related to an
      existing connection.  It consists of the client triggering the
      procedure by requesting an update to the connection configuration,
      and a response from the NCM.

   *  UP Setup: The NCM configures the user-plane protocols at the
      client and the network.  The NCM initiates the UP setup by sending
      the MX UP Setup Configuration Request to the client, which
      confirms the set of mutually acceptable parameters by using the
      User Plane Configuration Setup Confirmation (CNF) message.

   These steps are elaborated as follows.

   Reconfiguration: when When the client detects that the link is up/down or
   the IP address changes (e.g. (e.g., via APIs provided by the client OS),
   the CCM sends out a an MX Reconfiguration REQ Message Request to setup / set up, update, or
   release /
   update the connection, and the connection.  The message SHOULD include the following
   information

   o
   information:

   *  Unique Session Identifier: ID: Identity of the CCM identity at the NCM, created by the
      NCM during the capability exchange phase.

   o

   *  Reconfiguration Action: indicate Indicates the reconfiguration action
      (0:release; 1: setup; 2:
      (release, setup, or update).
   o

   *  Connection ID: identify Identifies the connection for reconfiguration reconfiguration.

   If (Reconfiguration the Reconfiguration Action is setup set to "setup" or update), "update", then include the
   message includes the following parameters

   o parameters:

   *  IP address of the connection
   o connection.

   *  SSID (if Connection Type = WiFi)
   o (Service Set Identifier of the Wi-Fi connection).

   *  MTU of the connection: The MTU of the delivery path that is
      calculated at the UE client for use by the NCM to configure
      fragmentation and concatenation procedures[I-D.zhu-intarea-mams-user-protocol] procedures [INTAREA-MAMS] at the
      N-MADP.
   o

   *  Delivery Node Identity: ID: Identity of the node to which the client is
      attached.  ECGI in  In the case of LTE and WiFi LTE, this is an ECGI.  In the case of
      Wi-Fi, this is an AP Id ID or a MAC address in
      case of WiFi. address.

   At the beginning of a connection setup, the CCM informs the NCM of
   the connection status using the MX Reconfiguration REQ message Request with the
   Reconfiguration Action type set to "setup".  The NCM acknowledges the
   connection setup status and exchanges parameters with the CCM for
   user plane
   user-plane setup, described as follows.

   User Plane Protocols Setup: described below.

   Setup of User-Plane Protocols: Based on the negotiated capabilities,
   the NCM sets up the user plane user-plane (Adaptation Layer and Convergence
   Layer) protocols at the N-MADP, N-MADP and informs the CCM of the user plane user-plane
   protocols to setup be set up at the client (C-MADP) and the parameters for
   the C-MADP to connect to the N-MADP.

   The MX UP Setup Config Configuration Request is used to create (multiple) one or more
   MADP instances instances, with each Anchor Connection anchor connection having one or more Configurations,
   configurations, namely MX Configurations.  It  The MX UP Setup
   Configuration Request consists of the following parameters:

   o

   *  Number of Anchor Connections (Core Networks) (core networks).

      For Each Anchor Connection, it includes each anchor connection, the following parameters

      * are included:

      -  Anchor Connection ID
      *

      -  Connection Type (e.g., 0: Wi-Fi; 1: Wi-Fi, 5G NR; 2: MulteFire; 3: NR, MulteFire, LTE)
      *

      -  Number of Active MX Configurations (Included (included only if more than
         one MX configurations are configuration is active for the anchor connection) connection).

         For each active MX configuration, it includes the following parameters

         + are
         included:

         o  MX Configuration ID (included if more than one MX
            Configuration
            configuration is present
         + present)

         o  MX Convergence Method, one Method.  One of the following

            - following:

            +  GMA
            -

            +  MPTCP Proxy
            -

            +  GRE Aggregation Proxy
            -  MPQUIC

            +  MPQUIC

         o  MX Convergence Method Parameters

            - Parameters:

            +  Convergence Proxy IP Address
            -

            +  Convergence Proxy Port
            -

            +  Client Key
         +

         o  MX Convergence Control Parameters (included if any MX
            Control PDU, e.g.  Probe-REQ/ACK, is PDU types (e.g., Probe-REQ/ACK) are supported):

            -

            +  UDP Port Number port number for sending and receiving MX Control
               PDUs, e.g. PDUs
               (e.g., Probe-REQ/ACK, Keep-Alive, etc.)
            - Keep-Alive)

            +  Convergence Proxy Port
         +

         o  Number of Delivery Connections Connections.

            For each Delivery Connection, delivery connection, include the following:

            -

            +  Delivery Connection ID
            -

            +  Connection Type (e.g., 0: Wi-Fi; 1: Wi-Fi, 5G NR; 2: MulteFire;
               3: NR, MulteFire, LTE)
            -

            +  MX Adaptation Method, one Method.  One of the following

               o following:

               *  UDP Tunnel without DTLS
               o

               *  UDP Tunnel with DTLS
               o  IPSec Tunnel
               o

               *  IPsec

               *  Client NAT
            -

            +  MX Adaptation Method Parameters

               o Parameters:

               *  Tunnel Endpoint IP Address
               o

               *  Tunnel Endpoint Port
               o

               *  Shared Secret
               o

               *  Header Optimization (included only if the MX
                  Convergence Method is GMA)

   e.g.  When

   For example, when LTE and Wi-Fi are the two user plane user-plane accesses, the
   NCM conveys to the CCM that IPsec needs to be setup set up as the MX
   Adaptation Layer over the Wi-Fi Access, access, using the following parameters -
   parameters: IPsec end-point 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 as it is considered secure with no
   NAT. access.

   Similarly, as an example of the MX Convergence Method Method, the
   configuration
   is to indicate indicates the convergence protocol method as the MPTCP Proxy proxy,
   along with parameters for a connection to the MPTCP Proxy, proxy: namely the
   IP Address address and
   Port port of the MPTCP Proxy proxy for TCP Applications. applications.

   Once the user plane user-plane protocols are configured, the CCM informs the NCM
   of the status via the MX UP Setup CNF message. Confirmation.  The MX UP Setup CNF
   Confirmation consists of the following parameters:

   o

   *  Unique Session Identifier: ID: Session identifier provided to the client in an
      MX Capability RSP.
   o Response.

   *  MX Convergence Control Parameters (included if any MX Control PDU,
      e.g. PDU
      types (e.g., Probe-REQ/ACK, Keep-alive, is Keep-Alive) are supported):

      *

      -  UDP Port Number port number for sending and receiving MX Control PDUs, e.g. PDUs
         (e.g., Probe-REQ/ACK, Keep-Alive, etc.)
      * Keep-Alive)

      -  MX Configuration ID (if an MX Configuration ID is specified in
         an MX UP Setup Config, Configuration Request) to indicate the MX
         Configuration that will be used for Probing)
   o probing)

   *  Client Adaptation Layer Adaptation-Layer Parameters:

      *

      -  Number of Delivery Connections
      * Connections.

         For each Delivery Connection, delivery connection, include the following:

         +

         o  Delivery Connection ID
         +

         o  UDP port number: If UDP based UDP-based adaptation is in use, the UDP
            port at on the C-MADP side

8.6.  MAMS Path Quality Estimation

   Path quality estimations can be done either passively or actively.
   Traffic measurements in the network could can be performed passively by
   comparing the real-time data throughput of the device 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 information. quality.  For example, the
   utilization of
   a cell/eNB attached the LTE access node (also known as Evolved Node B), to a device
   which the client is attached, could be used as an indicator data for the
   estimation of path quality estimations without creating an any extra traffic
   overhead.  Active measurements by the device are client provide an alternative for estimating
   way to estimate path quality.

         CCM                                                  NCM
          |                                                    |
          |<--------------+
          |<-------------- MX Path Estimation Configuration+--|
          |-----+ Request ---------|
          |------ MX Path Estimation Results+----------------->| Results ----------------->|
          |                                                    |

     Figure 7: MAMS Control Plane Control-Plane Procedure for Path Quality Estimation

   The NCM sends following the following configuration parameters in the MX Path
   Estimation Configuration message Request to the CCM

   o CCM:

   *  Connection ID (of Delivery Connection the delivery connection whose path quality needs
      to be estimated)
   o

   *  Init Probe Test Duration (ms)
   o

   *  Init Probe Test Rate (Mbps)
   o

   *  Init Probe Size (Bytes)
   o (bytes)

   *  Init Probe Ack Probe-ACK Required (0 -> No/1 No / 1 -> Yes)
   o

   *  Active Probe Frequency (ms)
   o

   *  Active Probe Size (Bytes)
   o (bytes)

   *  Active Probe Test Duration (ms)
   o

   *  Active Probe Ack Probe-ACK Required (0 -> No/1 No / 1 -> Yes)

   The CCM configures the C-MADP for probe reception receipt based on these
   parameters and for collection of the statistics according to the
   following configuration.

   o

   *  Unique Session Identifier: ID: Session identifier provided to the client in an
      MX Capability RSP.
   o Response.

   *  Init Probe Results Configuration

      * Configuration:

      -  Lost Probes (%)
      * (percent)

      -  Probe Receiving Rate (packets per second)
   o

   *  Active Probe Results Configuration

      * Configuration:

      -  Average Throughput in the last Probe Duration

   The user plane user-plane probing is divided into two phases - phases: the Initialization
   phase and the Active phase.

   o

   *  Initialization phase: 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.

   o

   *  Active phase: Phase: A network path that is included by the N-MADP for
      transmission of user data is deemed to be in the Active phase.

   In

   During the Initialization phase, the NCM configures the N-MADP to
   send an MX Idle
   Probe REQ Init Probe-REQ message.  The CCM collects the Idle probe Init Probe
   statistics from the C-MADP and sends the MX Path Estimation Results Message
   message to the NCM per the Initialization Probe Results
   configuration.

   In

   During the Active phase, the NCM configures the N-MADP to send an MX
   Active Probe REQ
   message.. Probe-REQ message.  The C-MADP calculates the metrics as
   specified by the Active Probe Results Configuration. configuration.  The CCM
   collects the Active probe Probe statistics from the C-MADP and sends the MX
   Path Estimation Results
   Message message to the NCM per the Active Probe
   Results configuration.

   The following sub-sections subsections define the control PDU encoding for Probe
   and Keep Keep-
   Alive and Probe-REQ/ACK messages to support path quality estimation.

8.6.1.  MX Control PDU definition Definition

   Control PDUs are sent as UDP Messages messages between the C-MADP and the
   N-MADP to exchange control messages for keep-alive or path quality
   estimation.  MX Probe Parameters probe parameters are negotiated during the User Plane Setup user-plane
   setup phase (MX UP SETUP CFG Setup Configuration Request and MX UP SETUP CNF). Setup
   Confirmation).  Figure 7 8 shows the MX control Control PDU format with the
   following fields:

   o

   *  Type (1 Byte): the byte): The type of the MX control message

      * Control message.

      -  0: Keep-Alive
      *

      -  1: Probe REQ/ACK
      * Probe-REQ/ACK

      -  Others: Reserved
   o

   *  CID (1 Byte): the byte): The connection ID of the delivery connection for
      sending out the MX control message
   o Control message.

   *  MX Control Message (variable): the The payload of the MX control
      message
   o  Figure 8 shows the MX Control PDU format.
      message.

   The MX Control PDU is sent as a normal user plane user-plane packet over the
   desired delivery connection whose quality and reachability needs need to be
   determined.

                            |                                          |
                           | <-----+MX
                            |<--------- MX Control PDU Payload +--------> ------->|
                            |                                          |                                          |
   +-----------+------------------+-----+-----------------------------+
   +-----------+-------------------+-----+-----------------------------+
   | IP header Header | UDP Header| Header | Type | CID |       MX Control Message    |
   +-----------+------------------+-----+-----------------------------+
   +-----------+-------------------+-----+-----------------------------+

                      Figure 8: MX Control PDU Format

8.6.2.  Keep-Alive Message

   The "Type" field is set to "0" for Keep-Alive messages.  The C-MADP
   may periodically send out a Keep-Alive message periodically over one or multiple
   delivery connections, especially if UDP tunneling is used as the
   adaptation method for the delivery connection with a NAT function on
   the path.

   A Keep-Alive message is 2 Bytes long, bytes long and consists of the following
   fields:

   o
   field:

   *  Keep-Alive Sequence Number (2 Bytes): the bytes): The sequence number of the
      keep-alive
      Keep-Alive message.

8.6.3.  Probe REQ/ACK  Probe-REQ/ACK Message

   The "Type" field is set to "1" for Probe REQ/ACK Probe-REQ/ACK messages.  The
   N-MADP may send out the Probe REQ Probe-REQ message for path quality estimation.
   In response, the C-MADP may send back return the Probe ACK Probe-ACK message.

   A Probe REQ Probe-REQ message consists of the following fields:

   o

   *  Probing Sequence Number (2 Bytes): the bytes): The sequence number of the
      Probe REQ message
   o message.

   *  Probing Flag (1 Byte):

      * byte):

      -  Bit #0: a Probe ACK 0: A Probe-ACK flag to indicate if whether the Probe ACK Probe-ACK
         message is expected (1) or not (0);
      * (0).

      -  Bit #1: a 1: A Probe Type flag to indicate if whether the Probe REQ/ACK Probe-REQ/ACK
         message is was sent during the initialization Initialization phase (0) when the
         network path is not included for transmission of user data data, or
         during the active Active phase (1) when the network path is included
         for transmission of user data;
      * data.

      -  Bit #2: a 2: A bit flag to indicate the presence of the Reverse
         Connection ID (R-CID) field.

      -  Bits 3-7: Reserved.

   *  Bit #3~7: reserved
   o  Reverse Connection ID (R-CID) (1 Byte): the byte): The connection ID of the
      delivery connection for sending out the Probe ACK Probe-ACK message on the
      reverse
      path
   o path.

   *  Padding (variable) (variable).

   The "R-CID" field is only present if both Bit #0 0 and Bit #2 2 of the
   "Probing Flag" field are set to "1".  Moreover, Bit #2 2 of the "Probing
   Flag" field SHOULD be set to "0" if the Bit #0 0 is "0", indicating that the Probe ACK
   Probe-ACK message is not expected.

   If the "R-CID" field is not present present, but the Bit #0 0 of the "Probing Flag"
   field is set to "1", the Probe ACK Probe-ACK message SHOULD be sent over the
   same delivery connection as the Probe REQ Probe-REQ message.

   The "Padding" field is used to control the length of Probe REQ the Probe-REQ
   message.

   The C-MADP SHOULD send out the Probe ACK Probe-ACK message in response to a Probe Probe-
   REQ message with the Probe ACK Probe-ACK flag set to "1".

   A Probe ACK Probe-ACK message is 3 Bytes long, bytes long and consists of the following
   fields:

   o
   field:

   *  Probing Acknowledgement Acknowledgment Number (2 Bytes): the bytes): The sequence number of
      the corresponding Probe REQ message Probe-REQ message.

8.7.  MAMS Traffic Steering

    CCM                                               NCM
     |                                                 |
     |                                +------------------------------+
     |                                |Steer user traffic to Path "X"|
     |                                +------------------------------+
     |<------------------MX
     |<----------------- MX Traffic Steering (TS) REQ--| REQ ------|
     |----- MX Traffic Steering (TS) RSP ------------->| ------------------>|

                 Figure 9: MAMS Traffic Steering Traffic-Steering Procedure

   The NCM sends out a an MX Traffic Steering (TS) REQ message Request to steer data traffic.
   It is also possible to send data traffic over multiple connections
   simultaneously, i.e. i.e., aggregation.  The message includes the
   following information:

   o

   *  Anchor Connection ID: Connection ID of the Anchor Connection
   o anchor connection.

   *  MX Configuration ID (if an MX Configuration ID is specified in an
      MX UP Setup Config)
   o Configuration Request).

   *  DL Connection ID List: List of Delivery Connections for DL traffic
   o delivery connections, provided
      as Connection IDs.

   *  UL Connection ID: Connection ID of Default the default UL Delivery Connection
   o delivery
      connection.

   *  For the number of Specific specific UL traffic Templates, include templates, the
      following

      * message
      includes the following:

      -  Traffic Flow Template for identifying the UL traffic
      * traffic.

      -  UL Connection ID List: List of Delivery connections for UL traffic
         identified by delivery connections,
         provided as Connection IDs, to be used for sending the traffic template
   o UL
         traffic.

   *  MX Feature Activation List: each List.  Each parameter indicates if whether the
      corresponding feature is enabled or not: lossless switching,
      fragmentation, concatenation, Uplink uplink aggregation, Downlink downlink
      aggregation, Measurement, probing measurement, probing.

   In response, the CCM sends out a an MX Traffic Steering (TS) RSP message, Response, including
   the following information:

   o

   *  Unique Session Identifier: ID: Session identifier provided to the client in an
      MX Capability RSP.
   o Response.

   *  MX Feature Activation List: each List.  Each parameter indicates if whether the
      corresponding feature is enabled or not: lossless switching,
      fragmentation, concatenation, Uplink uplink aggregation, Downlink downlink
      aggregation, probing measurement, probing.

8.8.  MAMS Application MADP Association

           CCM                                         NCM
            |                                           |
            |                        +-------------------------+
            |                        | Associate MADP instance |
            |                        | with application flow   |
            |                        +-------------------------+
              |-------------------MX
            |---------- MX App MADP ----------->| ------------------->|
            |                   Association(AMA)           Association REQ                 |
            |                                           |
              |-------------------MX
            |<----------------- MX App MADP ----------->| ------------|
            |                   Association(AMA)                   Association RSP         |

           Figure 10: MAMS Application MADP Association Procedure

   The CCM sends out a an MX App Application MADP Association(AMA) REQ message Association Request to request
   the association of a specific Application 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 user-plane processing that needs to be
   associated with different application flows depending on their needs. the needs of
   those flows.  The application flow is identified by its associated traffic flow
   template.
   Traffic Flow Template.

   The message MX Application MADP Association Request includes the following
   information:

   o

   *  Number of Application Flows Flows.

      For Each Application Flow, each application flow, identified by the Traffic Flow
      Template(s),

      *
      Templates:

      -  Anchor Connection ID
      *

      -  MX Configuration ID (if more than one MX Configurations are configuration is
         associated with an Anchor Connection)
      * anchor connection)

      -  Traffic Flow Template for identifying the UL traffic
      *

      -  Traffic Flow Template for identifying the DL traffic

   In response, the NCM sends out a an MX App Application MADP Association (AMA) RSP
   message,
   Response, including the following information:

   o

   *  Number of Application Flows Flows.

      For Each Application Flow, each application flow, identified by the Traffic Flow
      Template(s),

      *
      Templates:

      -  Status (Success or Failure)

8.9.  MAMS Network ID Indication

     CCM                                               NCM
      |                                                 |
      |                            +---------------------------------+
      |                            |NCM determines preferred Networks| networks|
      |                            +---------------------------------+
        |<------------------MX
      |                                                 |
      |<----------------- MX SSID Indication------------| Indication -----------|
      |                                                 |

              Figure 11: MAMS Network ID Indication Procedure

   The NCM indicates the preferred network list to the CCM to guide the
   client
   on regarding networks that it should connect to.  To indicate
   preferred Wi-Fi
   Networks, networks, the NCM sends the list of WLAN networks, WLANs, each
   represented by
   SSID/BSSID/HESSID, an SSID (Service Set Identifier)/BSSID (Basic Service
   Set Identifier)/HESSID (Homogeneous Extended Service Set Identifier)
   as defined in [IEEE-80211]), available in the MX SSID Indication.

8.10.  MAMS Client Measurement Configuration and Reporting

             CCM                                               NCM
              |                                                 |
              |<------------------MX MEAS CONFIG----------------|
              |<--------------- MX Measurement Config ----------|
              |                                                 |
        +---------------------------------+                     |
        |Client Ready ready to send measurements|                     |
        +---------------------------------+                     |
              |                                                 |
              |----- MX MEAS REPORT---------------------------->| Measurement Report -------------------->|
              |                                                 |

       Figure 12: MAMS Client Measurement Configuration and Reporting
                                 Procedure

   The NCM configures the CCM with the different parameters (e.g. (e.g., radio
   link information), with the associated thresholds to be reported by
   the client.  The MX MEAS CONFIG Measurement Configuration message contains the
   following
   parameters.  For parameters for each Delivery Connection, include the following:

   o delivery connection:

   *  Delivery Connection ID
   o ID.

   *  Connection Type (e.g., 0: Wi-Fi; 1: Wi-Fi, 5G NR; 2: MulteFire; 3: LTE)
   o  If Connection Type is Wi-Fi NR, MulteFire, LTE).

   *  WLAN_RSSI_THRESH:  If the connection type is Wi-Fi:

      -  High and Low Thresholds low thresholds for the sending Average
         RSSI of average Received
         Signal Strength Indicator (RSSI) of the Wi-Fi Link.
      *  WLAN_RSSI_PERIOD: Periodicity link.

      -  Periodicity, in ms ms, for sending Average the average RSSI of the Wi-Fi Link.
      *  WLAN_LOAD_THRESH:
         link.

      -  High and Low Thresholds low thresholds for sending Loading the loading of the WLAN
         system.
      *  WLAN_LOAD_PERIOD: Periodicity

      -  Periodicity, in ms ms, for sending Loading the loading of the WLAN system.
      *  UL_TPUT_THRESH:

      -  High and Low Thresholds low thresholds for sending Reverse
         Link Throughput the reverse link throughput
         on the Wi-Fi link.
      *  UL_TPUT_PERIOD: Periodicity

      -  Periodicity, in ms ms, for sending Reverse Link
         Throughput the reverse link throughput on
         the Wi-Fi link.
      *  DL_TPUT_THRESH:

      -  High and Low Thresholds low thresholds for sending Forward
         Link Throughput the forward link throughput
         on the Wi-Fi link.
      *  DL_TPUT_PERIOD: Periodicity

      -  Periodicity, in ms ms, for sending Forward Link
         Throughput the forward link throughput on
         the Wi-Fi link.
      *  EST_UL_TPUT_THRESH:

      -  High and Low Thresholds low thresholds for sending Reverse
         Link Throughput the reverse link throughput
         (EstimatedThroughputOutbound as defined in
         [IEEE]) [IEEE-80211]) on the
         Wi-Fi link.

      *  EST_UL_TPUT_PERIOD: Periodicity

      -  Periodicity, in ms ms, for sending Reverse Link
         Throughput the reverse link throughput
         (EstimatedThroughputOutbound as defined in [IEEE]) [IEEE-80211]) on the
         Wi-Fi link.
      *  EST_DL_TPUT_THRESH:

      -  High and Low Thresholds low thresholds for sending Forward
         Link Throughput (EstimatedThroughputInbound the forward link throughput
         (EstimatedThroughputInbound, as defined in
         [IEEE]) [IEEE-80211]) on the
         Wi-Fi link.
      *  EST_DL_TPUT_PERIOD: Periodicity

      -  Periodicity, in ms ms, for sending Forward Link
         Throughput (EstimatedThroughputInbound the forward link throughput
         (EstimatedThroughputInbound, as defined in [IEEE]) [IEEE-80211]) on the
         Wi-Fi link.
   o

   *  If Connection Type the connection type is LTE

      *  LTE_RSRP_THRESH: LTE:

      -  High and Low Thresholds low thresholds for sending RSRP the Reference Signal
         Received Power (RSRP) of
         Serving the serving LTE link.
      *  LTE_RSRP_PERIOD: Periodicity

      -  Periodicity, in ms ms, for sending the RSRP of Serving the serving LTE
         link.
      *  LTE_RSRQ_THRESH:

      -  High and Low Thresholds low thresholds for sending the RSRQ (Reference Signal
         Received Quality) of the serving LTE link.
      *  LTE_RSRQ_PERIOD: Periodicity

      -  Periodicity, in ms ms, for sending the RSRP of Serving the serving LTE
         link.
      *  UL_TPUT_THRESH:

      -  High and Low Thresholds low thresholds for sending Reverse
         Link Throughput the reverse link throughput
         on the serving LTE link.
      *  UL_TPUT_PERIOD: Periodicity

      -  Periodicity, in ms ms, for sending Reverse Link
         Throughput the reverse link throughput on
         the serving LTE link.
      *  DL_TPUT_THRESH:

      -  High and Low Thresholds low thresholds, for sending Forward
         Link Throughput the forward link
         throughput on the serving LTE link.
      *  DL_TPUT_PERIOD: Periodicity

      -  Periodicity, in ms ms, for sending Forward Link
         Throughput the forward link throughput on
         the serving LTE link.
   o

   *  If Connection Type the connection type is 5G NR

      *  NR_RSRP_THRESH: NR:

      -  High and Low Thresholds low thresholds for sending the RSRP of
         Serving the serving NR
         link.
      *  NR_RSRP_PERIOD: Periodicity

      -  Periodicity, in ms ms, for sending the RSRP of Serving the serving NR
         link.
      *  NR_RSRQ_THRESH:

      -  High and Low Thresholds low thresholds for sending the RSRQ of the serving NR
         link.
      *  NR_RSRQ_PERIOD: Periodicity

      -  Periodicity, in ms ms, for sending the RSRP of Serving the serving NR
         link.
      *  UL_TPUT_THRESH:

      -  High and Low Thresholds low thresholds for sending Reverse
         Link Throughput the reverse link throughput
         on the serving NR link.
      *  UL_TPUT_PERIOD: Periodicity

      -  Periodicity, in ms ms, for sending Reverse Link
         Throughput the reverse link throughput on
         the serving NR link.
      *  DL_TPUT_THRESH:

      -  High and Low Thresholds low thresholds for sending Forward
         Link Throughput the forward link throughput
         on the serving NR link.
      *  DL_TPUT_PERIOD: Periodicity

      -  Periodicity, in ms ms, for sending Forward Link
         Throughput the forward link throughput on
         the serving NR link.

   The MX MEAS REPORT message Measurement Report contains the following parameters
   o parameters:

   *  Unique Session Identifier: ID: Session identifier provided to the client in an
      MX Capability RSP.
   o Response.

   *  For each Delivery Connection, delivery connection, include the following:

      *

      -  Delivery Connection ID
      *

      -  Connection Type (e.g., 0: Wi-Fi; 1: Wi-Fi, 5G NR; 2: MulteFire; 3: NR, MulteFire, LTE)
      *

      -  Delivery Node Identity ID (ECGI in the case of LTE and WiFi LTE.  In the case of Wi-
         Fi, this is an AP Id ID or a MAC address in case of WiFi)
      * address.)

      -  If Connection Type the connection type is Wi-Fi

         +  WLAN_RSSI: Wi-Fi:

         o  Average RSSI of the Wi-Fi Link.
         +  WLAN_LOAD: link.

         o  Loading of the WLAN system.
         +  UL_TPUT:

         o  Reverse Link Throughput link throughput on the Wi-Fi link.
         +  DL_TPUT:

         o  Forward Link Throughput link throughput on the Wi-Fi link.
         +  EST_UL_TPUT:

         o  Estimated Reverse Link Throughput reverse link throughput on the Wi-Fi link
            (EstimatedThroughputOutbound as defined in [IEEE]).
         +  EST_DL_TPUT: [IEEE-80211]).

         o  Estimated Forward Link Throughput forward link throughput on the Wi-Fi link (EstimatedThroughputInbound
            (EstimatedThroughputInbound, as defined in [IEEE]).
      * [IEEE-80211]).

      -  If Connection Type the connection type is LTE

         +  LTE_RSRP: LTE:

         o  RSRP of Serving the serving LTE link.
         +  LTE_RSRQ:

         o  RSRQ of the serving LTE link.
         +  UL_TPUT:

         o  Reverse Link Throughput link throughput on the serving LTE link.
         +  DL_TPUT:

         o  Forward Link Throughput link throughput on the serving LTE link.
      *

      -  If Connection Type the connection type is 5G NR

         +  NR_RSRP: NR:

         o  RSRP of Serving the serving NR link.
         +  NR_RSRQ:

         o  RSRQ of the serving NR link.
         +  UL_TPUT:

         o  Reverse Link Throughput link throughput on the serving NR link.
         +  DL_TPUT:

         o  Forward Link Throughput link throughput on the serving NR link.

8.11.  MAMS Session Termination Procedure

             CCM                                  NCM
              |                                    |
              |+----MX
              |---- MX Session Terminate--------->| Termination REQ --->|
              |                                    |
              |                                    |
              |<---MX
              |<--- MX Session Terminate Ack-------| Termination RSP ----|
              |                                    |
              |                           +------------------+
              |                              +---------------+                           | Remove Resources |                              +---------------+
              |                           +------------------+
              |                                    |

    Figure 13: MAMS Session Termination Procedure - Client Initiated by Client

                     CCM                                  NCM
                      |                                    |
                      |<----------MX
                      |<--- MX Session Terminate--------|
                      |                                       | Termination REQ ----|
                      |                                    |
                      |                                    |
                      +--------MX
                      |---- MX Session Terminate Ack------->
                      |                                       | Termination RSP --->|
                      |                                    |
          +-----------+-----------+
             +------------------+                          |
             | Remove Resources |                          |
          +-----------+-----------+
             +------------------+                          |
                      |                                    |

    Figure 14: MAMS Session Termination Procedure - Network Initiated by Network

   At any point in MAMS functioning processing, if the CCM or NCM is unable no longer able
   to support the MAMS functions anymore, functions, then either of them can initiate a
   termination procedure by sending an MX Session Terminate Termination Request to
   the peer,
   the peer.  The peer shall SHALL acknowledge the termination by sending an
   MX Session
   Terminate ACK Termination Response message.  After the session is disconnected
   disconnected, the CCM
   shall SHALL start a new procedure with an MX Discover Message.
   message.  An MX Session
   Terminate message Termination Request shall contain a Unique
   Session Identifier ID and the reason for termination in Request. the termination.  Possible reasons for
   termination can be:

   o are:

   *  Normal Release
   o

   *  No Response from Peer
   o

   *  Internal Error

8.12.  MAMS Network Analytics Request Procedure

                  CCM                                 NCM
                   |                                   |
                    |+----MX
                   |----- MX Network Analytics Request----------->| REQ --->|
                   |                                   |
                   |                                   |
                    |<---MX
                   |<--- MX Network Analytics Info----------------| RSP -----|
                   |                                   |

            Figure 15: MAMS Network Analytics Request Procedure

   The CCM sends the MX Network Analytics Request informs to the NCM to send request
   information related to such network parameters like as bandwidth, latency,
   jitter, and signal quality quality, based on the application of analytics at
   the network utilizing (utilizing the received path measurements and client
   measurement reporting. reporting).

   The MX Network Analytics Request message consists of the following
   parameters.

   o
   parameters:

   *  Link Quality Indicators, one Indicators.  One or more of the following:

      *

      -  Bandwidth
      *

      -  Jitter
      *

      -  Latency
      *

      -  Signal Quality

   The NCM sends the MX Network Analytics Info Response to convey the analytics info,
   predictive parameters with likelihoods, for the different parameters
   information that might be of interest for to the CCM.  This message will
   include network parameters with their predicted likelihoods.

   The MX Network Analytics Info messages Response consists of the following
   parameters.

   o
   parameters:

   *  Number of Delivery Connections Connections.

      For Each Delivery Connection,

      * each delivery connection, include the following:

      -  Access Link Identifier

         + Identifier:

         o  Connection Type
         +

         o  Connection ID
      *

      -  Link Quality Indicator Indicator:

         o  Bandwidth:

            +  Bandwidth

            -  Predicted Value (in Mbps)
            -  - Likelihoood (in Percentage)
            - (Mbps)

            +  Likelihood (percent)

            +  Prediction Validity (Validity Time Time, in s) seconds)

         o  Jitter:

            +  Jitter

            -  Predicted Value (in s)
            -  - Likelihoood (in Percentage)
            - seconds)

            +  Likelihood (percent)

            +  Prediction Validity (Validity Time Time, in s) seconds)

         o  Latency:

            +  Latency

            -  Predicted Value (in s)
            -  - Likelihoood (in Percentage)
            - seconds)

            +  Likelihood (percent)

            +  Prediction Validity (Validity Time Time, in s)
         + seconds)

         o  Signal Quality

            -  if Delivery Connection Type Quality:

            +  If delivery connection type is LTE, LTE_RSRP Predicted
               Value (in dBm)
            -  if Delivery Connection Type in decibel-milliwatts (dBm)

            +  If delivery connection type is LTE, LTE_RSRQ Predicted
               Value (in dBm)
            -  if Delivery Connection Type (dBm)

            +  If delivery connection type is 5G NR, NR_RSRP Predicted
               Value (in dBm)
            -  if Delivery Connection Type (dBm)

            +  If delivery connection type is 5G NR, NR_RSRQ Predicted
               Value (in dBm)
            -  if Delivery Connection Type (dBm)

            +  If delivery connection type is WiFi, Wi-Fi, WLAN_RSSI Predicted
               Value (in dBm)
            -  - Likelihoood (in Percentage)
            - (dBm)

            +  Likelihood (percent)

            +  Prediction Validity (Validity Time Time, in s) seconds)

9.  Generic MAMS Signaling Flow

                       +----------------------------------------+
                       |

   Figure 16 illustrates the MAMS enabled signaling mechanism for negotiation of
   network paths and flow protocols between the client and the network.
   In this example scenario, the client is connected to two networks
   (LTE and Wi-Fi).

                          +--------------------------------------------+
                          |      MAMS-enabled Network of Networks      |
                          | +-----+    +-----+ +-------+   +-------+   +-----+   +------+
+-----------------+ |
   +------------------+   | |       |   |       |   |     |   |      | |     ||
   |      Client      |   | |Netwo|    |Netwo| |Network|   |Network|   |     |   |     ||      | |
   | +------+ +-----+ +-----+ |   | |rk |   1   |    |rk   |   2 +   |NCM   |    N-MADP||   | C-MADP  |CCM NCM |   |N-MADP| |
   | |(LTE)|    |(WiFi) |C-MADP| | CCM | |     ||   | +-----+ +-----+ | (LTE) |   |(Wi-Fi)|   |     |   |      | |
   | +------+ +-----+ |   | +-------+   +-------+   +-----+   +-----+    +------|
-+----------------+    +----------------------------------------+|   +------+ |
   |    |        |    |   |     |           |          |          |    |
   ++---+--------+----+   +-----+-----------+----------+----------+----+
    |   |        |              |    1.SETUP CONNECTION|           |          |          |
 |<-----------+------------>|
    |   |        |              |           |          |              +          +          |
    |   |  1. Setup Connection  |           |          |          |
    |<-----------+------------->|           |          |          |
    |   |        |              |           |          |          |
    |   |        |  2. MAMS Capabilities Exchange      |          |
    |   |       |<-------------+----------+-------->|        |<-------------+-----------+--------->|          |
    |   |        |              |           |          |          |
    |   |       +  3. Setup Connection  |           |          |          |
    |<--+---------------------------------->|          |          |
    |   |    3. SETUP CONNECTION        |              |           |
 |<--+-------------------------------->|          |          |
    | 4c. Config| Config | 4a. NEGOTIATE NETWORK PATHS, FLOW Negotiate network paths,        |4b. Config|
    |   | C-MADP | PROTOCOL AND PARAMETERS     Flow protocol, and parameters   |    N-MADP|
    |         |N-MADP   |<------>|<-------------+-----------+--------->|<-------->|
    |   |   |<----->|<-------------+----------+-------->|<-------->|        |              |           |              +          +          |          |
    |   |       |5. ESTABLISH USER PLANE PATH ACCORDING TO        | 5. Establish user-plane path according         |
    |   | SELECTED FLOW PROTOCOL        |    to selected flow protocol        |          |
    |   |<---------------------+----------+------------------->|   |<----------------------+-----------+-------------------->|
    |   |        |              |           |          |          |
    +   +        +              +           +          +          +

                         Figure 16: MAMS call flow
   Figure 16 illustrates the MAMS signaling mechanism for negotiation of
   network paths and flow protocols between the client and the network.
   In this example scenario, the client is connected to two networks
   (say LTE and WiFi). Call Flow

   1.  UE  The client connects to network Network 1 and gets an IP address assigned
       by
       network Network 1.

   2.  The CCM communicates with the NCM functional element via the network
       Network 1 connection and exchanges capabilities and parameters
       for MAMS operation.  Note: The NCM credentials (e.g.  NCM (e.g., the NCM's
       IP Address) address) can be made known to the UE client by pre-provisioning. provisioning.

   3.  Client  The client sets up the connection with network Network 2 and gets an IP
       address assigned by network Network 2.

   4.  The CCM and NCM negotiate capabilities and parameters for
       establishment of
       establishing network paths, which paths.  The negotiated capabilities and
       parameters are then used to configure
       user plane functions user-plane functions, i.e.,
       the N-MADP at the network and the C-MADP at the client.

       4a.  The CCM and NCM negotiate network paths, flow routing and
            aggregation protocols, and related parameters.

       4b.  The NCM communicates with the N-MADP to exchange and
            configure flow aggregation protocols, policies policies, and
            parameters in alignment with those negotiated with the CCM.

       4c.  The CCM communicates with the C-MADP to exchange and
            configure flow aggregation protocols, policies policies, and
            parameters in alignment with those negotiated with the NCM.

   5.  The C-MADP and N-MADP establish the user plane user-plane paths, e.g. e.g., using IKE
       Internet Key Exchange Protocol (IKE) [RFC7296] signaling, based
       on the negotiated flow aggregation protocols and parameters
       specified by the NCM.

   The CCM and NCM can further exchange messages containing access link
   measurements for link maintenance by the NCM.  The NCM evaluates the
   link conditions in the UL and DL across LTE and WiFi, Wi-Fi, based on link
   measurements reported by the CCM and/or link probing techniques link-probing techniques, and
   determines the policy for UL and DL user data distribution policy. distribution.  The NCM
   and CCM also negotiate application level application-level policies for categorizing
   applications, e.g. e.g., based on DSCP, Destination the Differentiated Services Code Point
   (DSCP), destination IP address, and
   determining which determination of the which available
   network paths, path needs to be used for transporting data of that category
   of applications.  The NCM configures the N-MADP, and the CCM
   configures the C-MADP, based on the negotiated application policies.
   The CCM may apply local application policies, in addition to the
   application policy conveyed by the NCM.

10.  Relation  Relationship to IETF Technologies

   The MAMS framework leverages technologies developed in the IETF like MPTCP, GRE (such
   as MPTCP and GRE) and enables a control plane control-plane framework to negotiate
   the use of these protocols between the client and the network.  It
   also addresses the limitations in the scope of other multihoming
   protocols.  E.g.
   MOBIKE RFC 4555 (IKEv2  For example, the IKEv2 Mobility and Multihoming Protocol (MOBIKE))
   (MOBIKE [RFC4555]) scope indicates that it is limited to multihoming
   between IPsec
   clients(tunnel clients (tunnel mode IPsec SAs) ONLY Security Associations) and
   does NOT not support load balancing.  MAMS addresses  To address this limitation in handling
   regarding how the multihoming scenario by supporting 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 end points endpoints connected with an IPsec tunnel mode SA,
   Security Association, the MAMS framework allows the flexibility to
   use a wide range of tunneling protocols to be used in the Adaptation layer. Layer.

11.  Applying MAMS Control Procedures with MPTCP Proxy as User Plane

   If the NCM determines that the N-MADP is to be instantiated with
   MPTCP as the MX Convergence Protocol, it exchanges the MPTCP
   capability support in the discovery and capability exchange
   procedures.  An MPTCP proxy (e.g., see [TCPM-CONVERTERS]) is
   configured to be the N-MADP instance.  The NCM then exchanges provides the
   credentials of the N-MADP instance, setup as MPTCP Proxy, Proxy instance, along with related parameters
   parameters, to the CCM.  The CCM configures the C-MADP with these
   parameters to connect with the N-MADP, to this MPTCP proxy (e.g.
   [I-D.ietf-tcpm-converters]) instance, on the available network path
   (Access). instance.

   Figure 17 illustrates the user plane user-plane protocol layering when MPTCP is
   configured to be the "MX Convergence Sublayer" Layer" protocol.  MPTCP manages
   traffic distribution and aggregation over multiple delivery
   connections.

          +-----------------------------------------------------+
          |                        MPTCP                        |
          +----------------+---------------+--------------------+
          +-----------------+-----------------+-----------------+
          |       TCP       |       TCP       |       TCP       |
          +-----------------------------------------------------+
          |  MX Adaptation  |  MX Adaptation  |  MX Adaptation  |
          | Sublayer  Layer          | Sublayer  Layer          | Sublayer  Layer          |
          |  (optional)     |  (optional)     |  (optional)     |
          +-----------------------------------------------------+
          |  Access #1 IP   |  Access #2 IP   |  Access #3 IP   |
          +----------------+---------------+--------------------+
          +-----------------+-----------------+-----------------+

         Figure 17: MAMS U-plane User-Plane Protocol Stack with MPTCP as MX
                             Convergence Layer

   The Client client (C-MADP) sets up an MPTCP connection with the N-MADP to
   begin with.  The MAMS control procedures are then applied to,

   o to do the
   following:

   *  Connect to the appropriate MPTCP network endpoint, e.g. e.g., the MPTCP
      Proxy
      proxy (illustrated in Figure 18)
   o 18).

   *  Control the addition of a second TCP subflow after WiFi the Wi-Fi
      connection is established and is deemed good, good (illustrated in illustrated in
      Figure 19),
   o 19).

   *  Control the MPTCP scheduler behavior like use of the MPTCP scheduler, e.g., by using only
      the LTE Subflow subflow in the UL and both the LTE and WiFi Wi-Fi subflows in
      the DL (illustrated in
      illustrated in Figure 20),
   o  Faster 20).

   *  Provide faster response to WiFi Wi-Fi link degradation by proactive deletion of proactively
      deleting a TCP subflow over WiFi Wi-Fi when poor link conditions are
      reported, to
      maintain maintaining optimum performance (illustrated in illustrated in
      Figure 21) 21).

   Figure 18 shows the call flow describing MAMS control procedures
   applied to configure the user plane and dynamic optimal path
   selection in a scenario with the MPTCP Proxy proxy as the convergence
   protocol in the user plane.

   +------+   +---------+   +---------+   +---------+   +---------+   +--------+   +--------+   +-------+   +-------+   +------+
   |      |   |        |   |        |   |       |   |       |   |      |
|CCM
   | CCM  |   | C-MADP |   |Wi-Fi N/W|   | Wi-Fi  |   |  LTE N/W  |   |  NCM  |   |N-MADP|
   |      |   |        |   |  N/W   |   |  N/W  |   |       |   |      |
   +------+   +---------+   +---------+   +---------+   +---------+   +--------+   +--------+   +-------+   +-------+   +------+
 +------------------------------------------------------------------------+
    +------------------------------------------------------------------+
    |           1. LTE Session Setup and IP Add. Address Allocation         |
 -------------------------------------------+-------------+-------------+-+
    +-----------------------------------------+-----------+------------+
     |                                        |           |        |
     |2. MAMS Discovery Message MX Discover (MAMS Version, MCC/MNC)  |           |        |
  +-----------------------------------------+------------->
     +----------------------------------------+---------->|        |
  | 3.
     |3. MX SYSTEM INFO System Info (Serving NCM IP/Port Address)     |        |
  <-------------+-------------+-------------+-------------+
     |<------------+-------------+-------------+----------+        |
     |             |             |             |          |        |
     |4. MX CAPABILITY REQ(Supported Capability REQ (Supported Anchor/Delivery     |        |
     |             |        Links ( Wi-Fi, LTE ) (Wi-Fi, LTE))           |        |
  +-----------------------------------------------------+->
     +--------------------------------------------------->|        |
     |5. MX CAPABILITY RSP(Convergence/Adaptation Parameters)|             |
  <-----------------------------------------+-------------+ Capability RSP (Convergence/Adaptation Parameters)     |
     |<----------------------------------------+----------+        | 6.
     |6. MX CAPABILITY ACK(ACCEPT) Capability ACK (ACCEPT)            |          |        |
  +-------------+-------------+--------------------------->
     +-------------+-------------+----------------------->|        |
     |             |             |             |          |        |
     |7. MX MEAS CONFIG (WLAN/LTE Meas Config (Wi-Fi/LTE Measurement Thresholds/Period)  |
  <-------------------------------------------------------+
     |<---------------------------------------------------+        |
     |8. MX MEAS REPORT ( LTE Meas Report (LTE RSRP, UL/DL TPUT ) TPUT) |          |
  +-----------------------------------------+------------->        |
     +-----------------------------------------+--------->|        |
     |9. MAMS MX SSID IND(List Indication (List of SSIDs)    |          |        |
  <-------------+-------------+---------------------------+
     |<------------+-------------+------------------------+        |
     |             |             |             |          |        |
     |10. MX RECONFIGURATION Reconfiguration REQ (LTE IP)      |          |        |
  +------------------------------------------------------->
     +--------------------------------------------------->|        |
     |11. MX RECONFONFIGURATION Reconfiguration RSP               |          |        |
  <-----------------------------------------+-------------+
     |<----------------------------------------+----------+        |
     |12. MX UP SETUP Setup REQ (MPTCP Proxy proxy IP/Port, Aggregation)       |             |
  <---------------------------+-------------+-------------+
     |<--------------------------+-------------+----------+        |
     |13. MX UP SETUP Setup RSP        |             |          |        |
  +-------------+-------------+-------------+------------->             +
     +-------------+-------------+-------------+--------->|        |
     |             | 14. MPTCP Connection connection with designated |        |
     |             |     MPTCP Proxy proxy over LTE             |             +-------------+-------------+-------------+------------->        |
     |             +-------------+-------------+----------+------->|
     |             |             |             |          |        |
     +             +             +             +          +        +

        Figure 18: MAMS-assisted MAMS-Assisted MPTCP Proxy as User Plane - Initial
                             Setup with LTE leg

   Following are the Leg

   The salient steps described in the call flow. flow are as follows.  The
   client connects to the LTE network and obtains an IP address (assume
   that LTE is the first connection), and connection).  It then initiates the NCM
   discovery procedures and exchange exchanges capabilities, including the
   support for MPTCP as the convergence protocol at both the network and
   the client.

   The CCM informs provides the LTE connection parameters to the NCM.  The NCM
   provides the parameters like MPTCP Proxy proxy IP address/Port, address/port, and MPTCP
   Client Key for configuring the convergence layer. Convergence Layer.  This is useful if
   the N-MADP is reachable 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 among from
   multiple access networks.  The client uses the MPTCP Client Key
   during the subflow creation, and this enables the N-MADP N-MADP to uniquely
   identify the client, even if a NAT is present.  The N-MADP can then
   inform the NCM of the subflow creation and parameters related to
   creating additional subflows.  Since LTE is the only connection, the
   user-plane traffic flows over the single TCP subflow over the LTE
   connection.  Optionally, the NCM provides assistance information to
   the client on the neighboring/preferred Wi-Fi networks that it can
   associate with.

   Figure 19 describes the steps where the client establishes a Wi-Fi
   connection.  The CCM informs the NCM of the Wi-Fi connection, along
   with such parameters as the Wi-Fi IP address or the SSID.  The NCM
   determines that the Wi-Fi connection needs to be secured, configures
   the Adaptation Layer to use IPsec, and provides the required
   parameters to uniquely
   identify the client, even if NAT is present.  The N-MADP then can
   inform CCM.  In addition, the NCM of provides the subflow creation information
   for configuring the Convergence Layer (e.g., MPTCP proxy IP address)
   and pararmeters related provides the MX Traffic Steering Request to
   creating additional subflows.  Since LTE is indicate that the
   client SHOULD use only connection, the
   user plane traffic, flows over LTE access.  The NCM may do this, for
   example, on determining from the single TCP subflow over measurements that the Wi-Fi link is
   not consistently good enough.  As the Wi-Fi link conditions improve,
   the LTE
   connection.  Optionally, NCM provides assistance information sends an MX Traffic Steering Request to use Wi-Fi access as
   well.  This triggers the
   device on client to establish the TCP subflow over the neighboring/preferred
   Wi-Fi networks that it can
   associate with. link with the MPTCP proxy.

   +------+   +---------+   +---------+   +---------+   +---------+   +--------+   +--------+   +-------+   +-------+   +------+
   |      |   |        |   |        |   |       |   |       |   |      |
|CCM
   | CCM  |   | C-MADP |   |Wi-Fi N/W|   | Wi-Fi  |   |  LTE N/W  |   |  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 Reconfiguration REQ (Wi-Fi IP)    |          |         |
 +------------------------------------------------------->
    +--------------------------------------------------->|         |
    |16. MX RECONFONFIGURATION Reconfiguration RSP               |          |         |
 <-----------------------------------------+-------------+
    |<----------------------------------------+----------+         |
    |17. MX UP SETUP Setup REQ (MPTCP Proxy proxy IP/Port, Aggregation)        |             |
 <---------------------------+-------------+-------------+
    |<--------------------------+-------------+----------+         |
    |18. MX UP SETUP Setup RSP        |             |          |         |
 +-------------+-------------+-------------+------------->             |
    +-------------+-------------+-------------+--------->|         |
    | 19.             |19. IPsec Tunnel Establishment over WLAN path Wi-Fi Path  |
    |             |<-------------------------------------+-------->|
    |             |             |             <-----------------------------------------|------------->             | 20.          |         |
    |20. MX MEAS REPORT (WLAN Meas Report (Wi-Fi RSSI,          |          |         |
    |    LTE RSRP. RSRP, UL/DL TPUT)  |+-------------+
 +-------------+-------------+-------------+------------->+Wait for     |                |          |+------------+
    +-------------+-------------+-------------+--------->||Wait for    |
    |             |             |+good reports             |             |          ||good reports|
    |             |             |             |+-------------+             |   21.          |+------------+
    |21. MX TRAFFIC STEERING Traffic Steering REQ (UL/DL Access, TFTs) access,          | +------------+
 <-----------------------------------------+-------------+         |
    |    Traffic Flow Templates (TFTs))                  | +----------+
    |<----------------------------------------+----------+ |Allow Use of| use |
    |   22.                                         |          | |    of    |
    |22. MX TRAFFIC STEERING Traffic Steering RSP (...)        |          | |Wi-Fi link link|
    +-------------+-------------+----------------------->| +----------+
    |
 +-------------+-------------+---------------------------> +-----------++             |             |             |          |         |
    |             | 23. Add TCP subflow to the MPTCP connection    |
    |             |     over WiFi Wi-Fi link (IPsec Tunnel)             |             |<----------------------------------------------------->|
+-----------------------------------------------------------------------+
    |             |<---------------------------------------------->|
    |             |             |             |          |         |
   +----------------------------------------------------------------+
   ||      Aggregated Wi-Fi and LTE capacity for UL and DL         ||
+-----------------------------------------------------------------------+
   +----------------------------------------------------------------+
    |                                                              |
    |                                                              |

     Figure 19: MAMS-assisted MAMS-Assisted MPTCP Proxy as User Plane - Add Wi-Fi leg Leg

   Figure 19 20 describes the steps, when steps where the client establishes a Wi-Fi
   connection.  CCM informs the NCM of the Wi-Fi connection along with
   parameters like the Wi-Fi IP address, SSID.  NCM determines reports that the Wi-Fi connection needs
   link conditions degrade in UL.  The MAMS control plane is used to be secured and configures
   continuously monitor the Adaptation
   Layer to be IPsec access link conditions on Wi-Fi and provides the required parameters to the CCM.
   In addition, LTE
   connections.  The NCM provides the information to configure may at some point determine an increase in UL
   traffic on the
   convergence layer, (e.g.  MPTCP Proxy IP Address), Wi-Fi network, and provides trigger the
   Traffic Steering Request to indicate that client should to use only the LTE access.  NCM may do this, for example, on determination from the
   measurements that the Wi-Fi link is not consistently good enough.  As
   in the Wi-Fi link conditions improve, NCM sends UL via a 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 improve UL
   performance.

   +------+   +---------+   +---------+   +---------+   +---------+   +--------+   +--------+   +-------+   +-------+   +------+
   |      |   |        |   |        |   |       |   |       |   |      |
|CCM
   | CCM  |   | C-MADP |  C+MADP   |   |Wi+Fi N/W| Wi-Fi  |   |  LTE N/W  |   |  NCM  |   |N+MADP|   |N-MADP|
   |      |   |        |   |  N/W   |   |  N/W  |   |       |   |      |
   +------+   +---------+   +---------+   +---------+   +---------+   +--------+   +--------+   +-------+   +-------+   +------+
 +------------------------------------------------------------------------+
   +-------------------------------------------------------------------+
   |   Traffic over LTE and Wi Fi Wi-Fi in UL And DL over MPTCP              |
 +-------------+-------------+-------------+-------------+------------+---+
   ++------------+-------------+-------------+------------+--------+---+
    |            |             |             |            |        |
 | 24.
    |24. MX MEAS REPORT (WLAN Meas Report (Wi-Fi RSSI, LTE RSRP ,UL/DL TPUT)  |+-----------+---+
 +-------------+-------------+-------------+------------>|| Reports of bad| RSRP, UL/DL TPUT)| +------+---+
    +------------+-------------+-------------+----------->| |Reports of|
    |            |             |             |             |+            | |bad Wi-Fi UL tput| |             +             +             +             ++---------------+
    |   25.            |             |             |            | |UL tput   |
    |            |             |             |            | +----------+
    |25. MX TRAFFIC STEERING Traffic Steering REQ (UL/DL Access, TFTs)     | +-------------+
 |<-----------------------------------------+------------+ +----------+
    |<---------------------------------------+------------+ |Disallow  use|  |   26.
    |            |             |             |            | |use of    |
    |26. MX TRAFFIC STEERING Traffic Steering RSP (...)       |            | |of Wi-Fi |Wi-Fi UL  |
 |-------------+-------------+-------------------------->| +----------+--+
    |------------+-------------+------------------------->| +------+---+
    |            |             |             |            |        |
++-------------+-------------+-------------+-------------+------------+-+
   ++------------+-------------+-------------+------------+--------+---+
   | UL data to use TCP subflow over LTE link only,                    |
   |  Aggregated    aggregated Wi-Fi+LTE capacity for DL                           |
++-------------+-------------+-------------+-------------+-------------++
   ++------------+-------------+-------------+------------+--------+---+
    |            |             |             |            |        |
    +            +             +             +            +        +

       Figure 20: MAMS-assisted MAMS-Assisted MPTCP Proxy as User Plane - Wi-Fi UL
                                 degrades
                                  Degrades

   Figure 20 21 describes the steps, when steps where the client reports that Wi-Fi
   link conditions degrade have degraded in UL.  MAMS control plane is used to
   continuously monitor both the access link conditions on Wi-Fi and LTE
   connections.  The NCM may at some point determine increase in UL
   traffic on Wi-Fi, and trigger 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 via
   Traffic Steering Request to improve UL performance. and DL.  This
   condition may be maintained until the NCM determines, based on
   reported measurements, that the Wi-Fi link has again become usable.

   +------+   +---------+   +---------+   +---------+   +---------+   +--------+   +--------+   +-------+   +-------+   +------+
   |      |   |        |   |        |   |       |   |       |   |      |
|CCM
   | CCM  |   | C-MADP |   |  C+MADP Wi-Fi  |   |Wi+Fi N/W|   |  LTE N/W  |   |  NCM  |   |N+MADP|   |N-MADP|
   |      |   |        |   |  N/W   |   |  N/W  |   |       |   |      |
   +------+   +---------+   +---------+   +---------+   +---------+   +--------+   +--------+   +-------+   +-------+   +------+
+-----------------------------------------------------------------------+
   +------------------------------------------------------------------+
   |          UL data to use TCP subflow over LTE link only,          |
   |  Aggregated Wi+Fi+LTE               aggregated Wi-Fi+LTE capacity for DL               |
++-------------+-------------+-------------+-------------+------------+-+
   ++------------+-------------+-------------+----------+---------+---+
    |            |             |             |          |         |
    |            |             +             +             +             |             |          | 27.         |
    |27. MX MEAS REPORT (WLAN Meas Report (Wi-Fi RSSI,         |          |         |
    |    LTE RSRP, UL/DL TPUT)  +------------+---+
 +-------------+-------------+-------------+------------>||               |          | +-------+----+
    +------------+-------------+-------------+--------->| | Reports of bad+ |
    |            |             |             || Wi+Fi             |          | | bad Wi-Fi  |
    |            |             |             |          | | UL/DL tput |             +             +             +             +----------------+
    |   28.            |             |             |          | +------------+
    |28. MX TRAFFIC STEERING Traffic Steering REQ (UL/DL Access, TFTs)   | +-------------+
 +<----------------------------------------+-------------+ |Disallow  use| +------------+
    |<---------------------------------------+----------+ | Disallow   |
    |            |             |             |          | |   29. use of     |
    |29. MX TRAFFIC STEERING Traffic Steering RSP (...)       |          | |of Wi+Fi |
 +-----------------------------------------+------------>+ +-------------+ Wi-Fi      |
    +----------------------------------------+--------->| +------------+
    |            |30. Delete TCP subflow from MPTCP conn.     |         |
    |            |    connection over Wi-Fi link        |         |             +<---------------------------------------------------->|
+-----------------------------------------------------------------------+
    |            |<---------------------------------------------->|
    |            |             |             |          |         |
   +--------------------------------------------------------------+
   ||            Traffic over LTE link only for DL and UL         |            | |
   ||      (until Client client reports better Wi-Fi link conditions)    |            | |
+-----------------------------------------------------------------------+
   +--------------------------------------------------------------+
    |            |             |             |          |         |
    +            +             +             +          +         +

        Figure 21: MAMS-assisted MAMS-Assisted MPTCP Proxy as User Plane - Part 4

   Figure 21 describes the steps, when the client reports that Wi-Fi
   link conditions degrade in both UL and DL.  As the Wi-Fi link
   conditions deteriorate further, the NCM may determine to send Traffic
   Steering Request guiding the client to stop using Wi-Fi, and to use
   only LTE access in both UL and DL.  This condition may be maintained
   until NCM determines, based on reported measurements that Wi-Fi link
   has become usable.

12.  Applying MAMS Control Procedures for Network Assisted Network-Assisted Traffic
     Steering when there is When There Is No Convergence Layer

   Figure 22 shows the call flow describing MAMS control procedures
   applied for dynamic optimal path selection in a scenario convergence where
   Convergence and Adaptation layer Layer protocols are not omitted.  This
   scenario indicates the applicability of a MAMS Control Plane solution for only solution. the MAMS
   control plane.

   In the capability exchange messages, the NCM and CCM negotiate that
   Convergence
   Convergence-Layer and Adaptation layer 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 links
   (Wi-Fi or LTE LTE) to be used dynamically based on the reported measurements of link quality measurements.
   quality.

   +------+   +---------+   +---------+   +---------+   +---------+   +--------+   +--------+   +-------+   +-------+   +------+
   |      |   |        |   |        |   |       |   |       |   |      |
|CCM
   | CCM  |   | C-MADP |   |  C+MADP Wi-Fi  |   |Wi+Fi N/W|   |  LTE N/W  |   |  NCM  |   |N+MADP|   |N-MADP|
   |      |   |        |   |  N/W   |   |  N/W  |   |       |   |      |
   +------+   +---------+   +---------+   +---------+   +---------+   +--------+   +--------+   +-------+   +-------+   +------+
 +------------------------------------------------------------------------+
    +------------------------------------------------------------------+
    |       1. LTE Session Setup and IP Add. Address Allocation             |
 +------------------------------------------+-------------+-------------+-+
    +---------------------------------------+-------------+----------+-+
     |2. MAMS Discovery Message MX Discover (MAMS Version, MCC/MNC Tuple) |             | )             |
  +-----------------------------------------+------------>|          |
     +--------------------------------------+------------>|          | 3.
     |3. MX SYSTEM INFO System Info (Serving NCM IP/Port Address) address)     |          |
     |<------------+-------------+----------+-------------|          |
     |             |             |
  <-------------+-------------+-------------+-------------+          |             |             +             +             +             +          |
     |4. MX CAPABILITY REQ(Supported Capability REQ (Supported       |             |          |
     |   Anchor/Delivery Links ( Wi-Fi, LTE ) (Wi-Fi, LTE))|             |
  +------------------------------------------------------>|          |
     +--------------------------------------------------->|          |
     |5. MX CAPABILITY RSP(No Convergence/Adpatation Capability RSP (No Convergence/Adaptation parameters)    |
  |<-----------------------------------------+------------+             |
     |<-------------------------------------+-------------+          | 6.
     |6. MX CAPABILITY ACK(ACCEPT) Capability ACK (ACCEPT)         |             |          |
     +-------------+-------------+----------------------->|          |
     |             |             |
  +-------------+-------------+-------------------------->|          |             |             +             +             +             +          |
     |7. MX MEAS CONFIG (WLAN/LTE Meas Config (Wi-Fi/LTE Measurement Thresholds/Period)    |
  |<------------------------------------------------------|
     |<---------------------------------------------------|          |
     |8. MX MEAS REPORT ( LTE Meas Report (LTE RSRP, UL/DL TPUT ) TPUT)            |          |
  |-----------------------------------------+------------>|
     |--------------------------------------+------------>|          |
     |9. MAMS MX SSID IND(List Ind (List of SSIDs)        |             |          |
  |<------------------------------------------------------|
     |<---------------------------------------------------|          |
+-----------------------------------------------------------------------++
   +-----------------------------------------------------------------++
   |      10. Wi|Fi connection setup Wi-Fi Connection Setup and IP Address allocation Allocation        |
+-+-------------+-------------+-------------+-------------+-------------++
   +-+-------------+-------------+----------+-------------+----------++
     |             +             +             |             |          |
  |10.             |          |
     |11. MX RECONFIGURATION Reconfiguration REQ (LTE IP, Wi-Fi IP)       |          |
  +-----------------------------------------+------------>|
     |--------------------------------------+------------>|          |
  |11.
     |12. MX RECONFONFIGURATION Reconfiguration RSP            |             |          |
  <------------------------------------------------------+|
     |<---------------------------------------------------|          |
+-----------------------------------------------------------------------++
   +-----------------------------------------------------------------++
   | Initial Condition, Data over LTE link only, WLAN Wi-Fi link is poor   |
+---------------------------------------------------------+-------------++
  |12.
   +------------------------------------------------------+----------++
     |             |             |          |             |          |
     |13. MX MEAS REPORT (WLAN Meas Report (Wi-Fi RSSI,       |             |          |
     |    LTE RSRP, UL/DL TPUT)   |+-------------+
  |------------------------------------------------------>||Wi-Fi Link   | TPUT)|            |             |+----------+
     |--------------------------------------------------->||Wi-Fi link|
     |             |             |             ||conditions          |             ||conditions|
     |             |             |          |             ||reported good|  |
     |             |             |             |+-------------+          |             ||good      |
     |             |             |          |
  |13.             |+----------+
     |             |             |          |             |          |
     |14. MX TRAFFIC STEERING Traffic Steering REQ (UL/DL Access, TFTs)       |+--------------+
  |<-------------+-------------+-------------+------------||Steer traffic    |+----------+
     |<------------+-------------+----------+-------------||Steer     |
  |14.
     |             |             |          |             ||traffic to|
     |15. MX TRAFFIC STEERING Traffic Steering RSP (...)     |             ||to use             ||use Wi-Fi |
  |<-------------+-------------+-------------+------------||link
     |<------------+-------------+----------+-------------||link      |
     |             |             |          |             |+--------------+
+-----------------------------------------------------------------------++             |+----------+
     |             |             |          |             |          |
   +-----------------------------------------------------------------++
   |    Use Wi-Fi link for Data                                       |
+---------------------------------------------------------+-------------++
   +------------------------------------------------------+----------++
     |             |             |          |             |          |
     +             +             +          +             +          +

                 Figure 22: MAMS With with No Convergence Layer

13.  Co-existence  Coexistence of MX Adaptation and MX Convergence Layers

   The MAMS user plane supports multiple instances and combinations of
   protocols to be used at the MX Adaptation and the Convergence layer. Layer.

   For example, one instance of the MX Convergence Layer can be MPTCP
   Proxy and another instance can be GMA.  The MX Adaptation for each
   can be either a UDP tunnel or IPsec.  IPSec  IPsec may be set up when the
   network path needs to be secured, e.g. e.g., to protect the TCP subflow
   traversing the network path between the client and the MPTCP proxy.

   Each instance of the instances of MAMS user plane, i.e. i.e., the combination of MX
   Convergence
   Convergence-Layer and MX Adaptation layer Adaptation-Layer protocols, can coexist
   simultaneously and independently handle different traffic types.

14.  Security Considerations

14.1.  MAMS Control Plane Control-Plane Security

   The NCM functional element is hosted on a network node which that is
   assumed to be within a secure network, e.g. e.g., within the operator's
   network, and is assumed to be protected against hijack attacks.

   For deployment scenarios, scenarios where the client is configured (e.g. (e.g., by the
   network operator) to use a specific network path for exchanging
   control plane messages
   control-plane messages, and if the network path is assumed to be
   secure, MAMS control messages will rely on security provided by the
   underlying network.

   For deployment scenarios where the security of the network path
   cannot be assumed, NCM and CCM implementations MUST support the "wss"
   URI scheme [RFC6455] and Transport Layer Security (TLS) [RFC5246] [RFC8446] to
   secure control plane message the exchange of control-plane messages between the NCM and the
   CCM.

   For deployment scenarios where client authentication is desired, the
   WebSocket server can use any client authentication mechanisms
   available to a generic HTTP server, such as cookies, HTTP
   authentication, or TLS authentication.

14.2.  MAMS User Plane User-Plane Security

   User data in the MAMS framework relies on the security of the
   underlying network transport paths.  When this security cannot be
   assumed, the NCM configures the use of protocols, like protocols (e.g., IPsec
   [RFC4301] [RFC3948] [RFC3948]) in the MX Adaptation Layer, for security.

15.  Implementation Considerations

   The MAMS architecture builds on commonly available functions available on terminal
   devices in
   clients that can be delivered as a used to deliver software update updates over the popular
   end-user device
   client operating systems, thereby enabling rapid deployment and
   addressing the large base of deployed device base. clients.

16.  Applicability to Multi Access Multi-Access Edge Computing

   Multi-access Edge Computing (MEC), previously known as Mobile Edge
   Computing, is an access-edge cloud platform being considered at ETSI
   [ETSIMEC] , the
   European Telecommunications Standards Institute (ETSI) [ETSIMEC],
   whose initial focus was to improve quality of experience the QoE by leveraging intelligence
   at the cellular (e.g., 3GPP technologies like LTE) access edge, and
   the scope is now being extended to support access technologies beyond
   3GPP.  The applicability of the framework described in this document
   to the MEC platform has been evaluated and tested in different
   network configurations by the authors.

   The NCM can be hosted on a MEC cloud server that is located in the
   user plane
   user-plane path at the edge of the multi-technology access network.
   The NCM and CCM can negotiate the network path combinations based on
   application
   an application's needs and the necessary user plane user-plane protocols to be
   used across the multiple paths.  The network conditions reported by
   the CCM to the NCM can be complemented by a Radio Analytics
   application [ETSIRNIS] residing at the MEC cloud server to configure
   the uplink and downlink access paths according to changing radio and
   congestion conditions.

   The user plane user-plane functional element, N-MADP, can either be collocated
   with the NCM at the MEC cloud server (e.g., MEC hosted applications), MEC-hosted applications)
   or placed at a separate network element like a common user plane user-plane
   gateway across the multiple networks.

   Also, even in scenarios where an N-MADP is not deployed, the NCM can
   be used to augment the traffic steering traffic-steering decisions at the device. client.

   The aim of these enhancements is to improve the end-user's quality of
   experience end user's QoE by
   leveraging the best network path based on application an application's needs and
   network conditions, and building on the advantages of significantly
   reduced latency and the dynamic and real-time exposure of radio
   network information available at the MEC.

17.  Related work Work in other Other Industry and Standards Forums

   The MAMS framework described in this document has been incorporated
   or is proposed for incorporation as a solution to address multi multi-
   access integration in multiple industry forums and standards.  This
   section describes the related work in other industry forums and the
   standards organizations.

   Wireless Broadband Alliance Industry industry partners have published a
   whitepaper white
   paper that describes the applicability of different technologies for
   multi access
   multi-access integration to different deployments as part of their
   project named, Unlicensed
   "Unlicensed Integration with 5G Networks Networks" project [WBAUnl5G].  The whitepaper
   white paper includes the MAMS framework described in this document as
   a technology for integrating Unlicensed (WiFi) unlicensed (Wi-Fi) networks with 5G
   networks above the 5G core network.

   The 3GPP is developing a technical report as part of its work item
   Study on Access Traffic Steering, Switching Switching, and Splitting (ATSSS).
   That report, TR23.793 [GPPATSSS], TR 23.793 [ATSSS], contains a number of potential solutions
   and
   solutions; Solution 1 in [ATSSS] utilizes a separate control plane
   for the flexible negotiation of user plane user-plane protocols and path
   measurements in a way that is similar to the MAMS architecture
   described in this document.

   The Small Cell Forum (SCF) [SCFTECH5G] plans to develop a while white paper
   as part of its work item on LTE/5G and WiFi. Wi-Fi.  There is a proposal to
   include MAMS in this whitepaper. white paper.

   The ETSI Multi-access Edge Computing Phase 2 technical work is
   examining many aspects of this work work, including use cases for
   optimizing Quality of Experience (QoE) QoE and resource utilization.  The MAMS architecture and
   procedures outlined in this document is are included in the ETSI's use
   cases and requirements document[ETSIMAMS]. document [ETSIMAMS].

18.  Contributing Authors

   The editors gratefully acknowledge the following additional
   contributors in alphabetical order: A Krishna Pramod/Nokia, Hannu
   Flinck/Nokia, Hema Pentakota/Nokia, Nurit Sprecher/Nokia, Salil
   Agarwal/Nokia; Shuping Peng/Huawei, Vasudevan Subramanian/Nokia.
   Vasudevan Subramanian has been instrumental in conceptualization and
   development of solution principles for the MAMS framework.  Shuping
   Peng has been a key contributor in refining the framework and control
   plane protocol aspects.

19.  Acknowledgments

   This protocol is the outcome of work by many engineers, not just the
   authors of this document.  In alphabetical order, the contributors to
   the project are: Barbara Orlandi, Bongho Kim,David Lopez-Perez, Doru
   Calin, Jonathan Ling, Lohith Nayak, Michael Scharf.

20.  IANA Considerations

   This draft makes document has no requests of IANA

21. actions.

19.  References

21.1.

19.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <https://www.rfc-editor.org/info/rfc4301>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

21.2.

19.2.  Informative References

   [ANDSF]    "TS 24.312 version 15.0, 21 June 2018: 3GPP Specification
              on Access    3rd Generation Partnership Project, "Access Network
              Discovery and Selection Function (ANDSF) Management Object
              (MO)", http://www.3gpp.org/ftp//Specs/
              archive/24_series/24.312/24312-f00.zip", <TS24.312>.

   [E212]     "ITU-T E.212: The international identification plan for
              public networks 3GPP TS 24.312 version 15.0.0, Technical
              Specification Group Core Network and Terminals, June 2018,
              <https://www.3gpp.org/ftp//Specs/
              archive/24_series/24.312/24312-f00.zip>.

   [ATSSS]    3rd Generation Partnership Project, "Study on access
              traffic steering, switch and subscriptions,
              https://www.itu.int/rec/T-REC-E.212-201609-I/en", <ITU-T
              E.212>. splitting support in the 5G
              System (5GS) architecture", Work in Progress, 3GPP TR
              23.793 v16.0.0, December 2018,
              <https://www.3gpp.org/ftp/Specs/
              archive/23_series/23.793/>.

   [ETSIMAMS]
              "Multi-access European Telecommunications Standards Institute, "Multi-
              access Edge Computing (MEC); Phase 2: Use Cases and
              Requirements, https://www.etsi.org/deliver/etsi_gs/
              MEC/001_099/002/02.01.01_60/gs_MEC002v020101p.pdf", <ETSI
              Requirements", ETSI GS MEC 002>. 002 v2.1.1, October 2018,
              <https://www.etsi.org/deliver/etsi_gs/
              MEC/001_099/002/02.01.01_60/gs_MEC002v020101p.pdf>.

   [ETSIMEC]  "Multi-access  European Telecommunications Standards Institute, "Multi-
              access Edge Computing (MEC), ETSI",
              <https://www.etsi.org/technologies-clusters/technologies/
              multi-access-edge-computing>. (MEC)",
              <https://www.etsi.org/technologies/multi-access-edge-
              computing>.

   [ETSIRNIS] European Telecommunications Standards Institute, "Mobile
              Edge Computing (MEC) Radio Network Information API", <ETSI ETSI
              GS MEC 012>.

   [GPPATSSS]
              "3rd Generation Partnership Project; Technical
              Specification Group Services and System Aspects; Study on
              Access Traffic Steering, Switching and Splitting support
              in the 5G system architecture (Release 16),
              https://www.3gpp.org, work in progress", <TR23.793>.

   [I-D.deconinck-multipath-quic]
              Coninck, Q. and O. Bonaventure, "Multipath Extension 012 v1.1.1, July 2017,
              <https://www.etsi.org/deliver/etsi_gs/
              MEC/001_099/012/01.01.01_60/gs_MEC012v010101p.pdf>.

   [IEEE-80211]
              IEEE, "IEEE Standard for
              QUIC", draft-deconinck-multipath-quic-00 (work in
              progress), October 2017.

   [I-D.ietf-tcpm-converters]
              Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S., Information technology-
              Telecommunications and B. Hesmans, "0-RTT TCP Convert Protocol", draft-ietf-
              tcpm-converters-06 (work in progress), March 2019.

   [I-D.zhu-intarea-gma] information exchange between
              systems - Local and metropolitan area networks-Specific
              requirements - Part 11: Wireless LAN Medium Access Control
              (MAC) and Physical Layer (PHY) Specifications",
              IEEE 802.11-2016,
              <https://ieeexplore.ieee.org/document/7786995>.

   [INTAREA-GMA]
              Zhu, J. and S. Kanugovi, "Generic Multi-Access (GMA)
              Convergence Encapsulation Protocols", draft-zhu-intarea-
              gma-02 (work Work in progress), March 2019.

   [I-D.zhu-intarea-mams-user-protocol] Progress,
              Internet-Draft, draft-zhu-intarea-gma-05, 16 December
              2019,
              <https://tools.ietf.org/html/draft-zhu-intarea-gma-05>.

   [INTAREA-MAMS]
              Zhu, J., Seo, S., Kanugovi, S., and S. Peng, "User-Plane
              Protocols for Multiple Access Management Service", draft-
              zhu-intarea-mams-user-protocol-07 (work Work in progress),
              April 2019.

   [IEEE]     "IEEE Standard
              Progress, Internet-Draft, draft-zhu-intarea-mams-user-
              protocol-09, 4 March 2020, <https://tools.ietf.org/html/
              draft-zhu-intarea-mams-user-protocol-09>.

   [ITU-E212] International Telecommunication Union, "The international
              identification plan for Information technology:
              Telecommunications and information exchange between
              systems Local public networks and metropolitan area networks:Specific
              requirements - Part 11: Wireless LAN Medium Access Control
              (MAC)
              subscriptions", ITU-T Recommendation E.212, September
              2016, <https://www.itu.int/rec/T-REC-E.212-201609-I/en>.

   [QUIC-MULTIPATH]
              Coninck, Q. and Physical Layer (PHY) Specifications.", <IEEE
              802.11-2016>. O. Bonaventure, "Multipath Extensions for
              QUIC (MP-QUIC)", Work in Progress, Internet-Draft, draft-
              deconinck-quic-multipath-04, 5 March 2020,
              <https://tools.ietf.org/html/draft-deconinck-quic-
              multipath-04>.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              DOI 10.17487/RFC2784, March 2000,
              <https://www.rfc-editor.org/info/rfc2784>.

   [RFC2890]  Dommety, G., "Key and Sequence Number Extensions to GRE",
              RFC 2890, DOI 10.17487/RFC2890, September 2000,
              <https://www.rfc-editor.org/info/rfc2890>.

   [RFC3948]  Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
              Stenberg, "UDP Encapsulation of IPsec ESP Packets",
              RFC 3948, DOI 10.17487/RFC3948, January 2005,
              <https://www.rfc-editor.org/info/rfc3948>.

   [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
              (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
              <https://www.rfc-editor.org/info/rfc4555>.

   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
              RFC 4960, DOI 10.17487/RFC4960, September 2007,
              <https://www.rfc-editor.org/info/rfc4960>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <https://www.rfc-editor.org/info/rfc6347>.

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
              RFC 6455, DOI 10.17487/RFC6455, December 2011,
              <https://www.rfc-editor.org/info/rfc6455>.

   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
              <https://www.rfc-editor.org/info/rfc6824>.

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <https://www.rfc-editor.org/info/rfc7231>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/info/rfc7296>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [SCFTECH5G]
              "Small
              Small Cell Forum, https://scf.io/", <Small "Small Cell Forum>. Forum", <https://scf.io/>.

   [ServDesc3GPP]
              3rd Generation Partnership Project, "General Packet Radio
              Service (GPRS); Service description; Stage 2", 3GPP TS
              23.060 version 16.0.0, Technical Specification Group
              Services and System Aspects, March 2019,
              <https://www.3gpp.org/ftp/Specs/
              archive/23_series/23.060/23060-g00.zip>.

   [TCPM-CONVERTERS]
              Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S.,
              and B. Hesmans, "0-RTT TCP Convert Protocol", Work in
              Progress, Internet-Draft, draft-ietf-tcpm-converters-18, 6
              March 2020, <https://tools.ietf.org/html/draft-ietf-tcpm-
              converters-18>.

   [WBAUnl5G]
              "Wireless Wireless Broadband Alliance Project - Unlicensed Alliance, "Unlicensed Integration with
              5G Networks,
              https://www.wballiance.com/resource/
              unlicensed-integration-with-5g-networks/.", <Unlicensed
              Integration with 5G Networks>. Networks", <https://wballiance.com/resource/unlicensed-
              integration-with-5g-networks/>.

Appendix A.  MAMS Control Plane Control-Plane Optimization over Secure Connections

   This appendix is informative, and provides indicative information
   about how MAMS operates.

   If the connection between the CCM and the NCM over which the MAMS control
   plane
   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
   UCM the CCM (see Figure 23).

          +-----------------------------------------------------+

            +-------------------------------------------------+
            |        Multi-Access (MX) Control Message        |
          |-----------------------------------------------------|
            |-------------------------------------------------|
            |                       UDP                       |
          |-----------------------------------------------------|
            |-------------------------------------------------|

           Figure 23: UDP-based UDP-Based MAMS Control plane Control-Plane Protocol Stack

Appendix B.  MAMS Application Interface

   This appendix describes the MAMS Application Interface.  It does not
   provide normative text for the definition of the MAMS framework or
   protocols, but offers additional information that may be used to
   construct a system based on the MAMS framework.

B.1.  Overall Design

   The CCM hosts an HTTPS server for applications to communicate and
   request services.  It is assumed in this draft  This document assumes, from a security point of
   view, that all CCM CCMs and the communicating Application application instances are
   hosted in a single administrative domain from security point of view. domain.

   The content of messages is defined described in "Java Script JavaScript Object Notation" Notation
   (JSON) format.  They offer RESTful APIs for communication.

   The exact mechanism regarding how Application the application knows about the end
   point
   endpoint of the CCM is not covered as part out of scope for this document.  It  This
   mechanism may instead be provided as part of the Application Settings. application
   settings.

B.2.  Notation

   The documentation of APIs are is provided in the OpenAPI format using
   swagger v2.0 (TBD - Add section in appendix) format, using
   Swagger v2.0.  See Appendix D.

B.3.  Error Indication

   For every API, there could be an error response in case if the objective of
   the API could not be met as defined in [RFC2616]. met; see [RFC7231].

B.4.  CCM APIs

   The following sections subsections describe the APIs exposed by the CCM to the
   applications
   applications.

B.4.1.  Get  GET Capabilities

   The CCM provides a an HTTPS GET interface as "/ccm/v1.0/capabilities"
   for the Application application to query about the capabilities supported by the CCM
   instance.

   +---------+                                            +-----------+                                            +-------------+
   |         |                                            |           |
   |   App      +----------+HTTPS   |--------- HTTPS GET /capabilities+-------->| / Capabilities -------->|    CCM    |
   |         |                                            |           |
   +---------+                                            +-----------+                                            +-------------+

                    Figure 24: CCM API - GET Procedures

   The CCM shall provide information of regarding its capabilities as
   follows:

   o

   *  Supported Features: One of or more of the "Feature Name" values, as
      defined in the MX Feature Activation List parameter of the MX
      Capability REQ.
   o Request (Appendix C.2.5).

   *  Supported Connections: Supported connection types and connection
      IDs
   o
      IDs.

   *  Supported MX Adaptation Sublayers: Layers: List of MX adaptation sublayer Adaptation Layer
      protocols supported by the N-MADP instance alongwith instance, along with the
      connection type types where these are supported and their respective
      parameters.
   o

   *  Supported MX Convergence Sublayers: Layers: List of supported MX Convergence Sublayer protocols alongwith
      Layer protocols, along with the parameters associated with the
      respective convergence technique.

B.4.2.  Post App  Posting Application Requirements

   The CCM provides a an HTTPS POST interface as "/ccm/v1.0/
   app_requirements" for the Application application to post the needs of the
   application data streams to the CCM instance.

   +---------+                                            +-----------+                                            +-------------+
   |         |                                            |           |
   |   App      +----------+HTTPS   |-------- HTTPS POST /App Requirements+--->| / App Requirements ---->|    CCM    |
   |         |                                            |           |
   +---------+                                            +-----------+                                            +-------------+

                    Figure 25: CCM API - POST Procedures

   The CCM shall provide for the application to post the following
   requirements of for its different data streams:

   o

   *  Number of data stream types Data Stream Types.

   *  For each data stream type, specify the following link feature preferences,
   o parameters for
      the link, which are preferred by the application:

      -  Protocol Type: Transport layer Transport-layer protocol associated with the
         application data stream packets.
   o

      -  Port Range: Supported connection types and connection IDs.

   o

      -  Traffic QoS: Quality of service parameters parameters, as follows

      * follows:

         o  Bandwidth
      *

         o  Latency
      *

         o  Jitter

B.4.3.  Get  Getting Predictive Link Parameters

   The CCM provides a an HTTPS GET interface as "/ccm/v1.0/
   predictive_link_params" for the Application application to get the predicted link
   parameters from the CCM instance.

   +---------+                                             +-----------+                                             +-------------+
   |         |                                             |           |
   |   App      +-------+HTTPS   |----- HTTPS GET /Predictive / Predictive Link Params--->| Params --->|    CCM    |
   |         |                                             |           |
   +---------+                                             +-----------+                                             +-------------+

          Figure 26: CCM API - GET Getting Predictive Link Parameters Procedures

   The CCM requests asks the NCM for link parameters via the MAMS Network
   Analytics Request Procedure (Section 8.12) and includes the
   information in response to the API invocation.

   o

   *  Number of Delivery Connections Connections.

      For Each Delivery Connection,

      * each delivery connection, include the following:

      -  Access Link Identifier

         + Identifier:

         o  Connection Type
         +

         o  Connection ID
      *

      -  Link Quality Indicator

         o  Bandwidth:

            +  Bandwidth

            -  Predicted Value (in Mbps)
            -  - Likelihoood (in Percentage)
            - (Mbps)

            +  Likelihood (percent)

            +  Prediction Validity (Validity Time Time, in s) seconds)

         o  Jitter:

            +  Jitter

            -  Predicted Value (in s)
            -  - Likelihoood (in Percentage)
            - seconds)

            +  Likelihood (percent)

            +  Prediction Validity (Validity Time Time, in s) seconds)

         o  Latency:

            +  Latency

            -  Predicted Value (in s)
            -  - Likelihoood (in Percentage)
            - seconds)

            +  Likelihood (percent)

            +  Prediction Validity (Validity Time Time, in s)
         + seconds)

         o  Signal Quality

            -  if Delivery Connection Type

            +  If delivery connection type is LTE, LTE_RSRP Predicted
               Value (in dBm)
            -  if Delivery Connection Type (dBm)

            +  If delivery connection type is LTE, LTE_RSRQ Predicted
               Value (in dBm)
            -  if Delivery Connection Type (dBm)

            +  If delivery connection type is 5G NR, NR_RSRP Predicted
               Value (in dBm)
            -  if Delivery Connection Type (dBm)

            +  If delivery connection type is 5G NR, NR_RSRQ Predicted
               Value (in dBm)
            -  if Delivery Connection Type (dBm)

            +  If delivery connection type is WiFi, Wi-Fi, WLAN_RSSI Predicted
               Value (in dBm)
            -  - Likelihoood (in Percentage)
            - (dBm)

            +  Likelihood (percent)

            +  Prediction Validity (Validity Time Time, in s) seconds)

Appendix C.  JSON Specification for  MAMS Control Plane Control-Plane Messages Described Using JSON

   MAMS Control plane control-plane messages are exchanged between the CCM and the
   NCM.  This section, specifies non-normative appendix describes the format and content of
   messages in
   "Java Script Object Notation" (JSON) format. using JSON [RFC8259].

C.1.  Protocol Specification: General Processing

C.1.1.  Notation

   This document uses JSONString, JSONNumber, and JSONBool to indicate
   the JSON string, number, and boolean types, respectively.  The type
   JSONValue indicates a JSON value, as specified in Section 3 of
   [RFC7159].

   This document uses an adaptation of the C-style struct notation to
   define
   describe JSON objects.  A JSON object consists of name/value pairs.
   This document refers to each pair as a field.  In some context, contexts, this
   document also refers to a field as an attribute.  The name of a
   field/attribute may be referred to as the key.  An optional field is
   enclosed by [ ]. "[ ]".  In the definitions, the JSON names of the fields
   are case sensitive.  An array is indicated by two numbers in angle
   brackets, <m..n>, where m indicates the minimal number of values and
   n is the maximum.  When this document uses * for n, it means no upper
   bound.

   For example, the definition text below defines describes a new type Type4, with three fields named
   fields: "name1", "name2", and "name3", respectively.  The
   field named "name3"
   field is optional, and the field named "name2" field is an array of at least one
   value.

       object { Type1 name1; Type2 name2<1..*>; name2 <1..*>; [Type3 name3;] } Type4;

   This document uses subtyping to denote that one type is derived from
   another type.  The example below denotes that TypeDerived is derived
   from TypeBase.  TypeDerived includes all fields defined in TypeBase.
   If TypeBase does not have a field named "name1", "name1" field, TypeDerived will have a
   new field named called "name1".  If TypeBase already has a field
   named called
   "name1" but with a different type, TypeDerived will have a field named
   called "name1" with the type defined in TypeDerived (i.e., Type1 in
   the example).

       object { Type1 name1; } TypeDerived : TypeBase;

   Note that, despite the notation, no standard, machine-readable
   interface definition or schema is provided in this document.
   Extension documents may describe these as necessary.

   For compatibility with publishing requirements, line breaks have been
   inserted inside long JSON strings, with the following continuation
   lines indented.  To form the valid JSON example, any line breaks
   inside a string must be replaced with a space and any other white
   space after the line break removed.

C.1.2.  Discovery Procedure

C.1.2.1.  MX Discovery Discover Message

   This message is the first message sent by the CCM to discover the
   presence of NCM in the network.  It contains only the base
   information as described in Appendix C.2.1 with message_type set as
   mx_discover.

   Following is the

   The representation of the message: message is as follows:

       object {
           [JSONString MCC_MNC_Tuple;]
        } MXDiscover : MXBase;

C.1.3.  System Information Procedure

C.1.3.1.  MX System Information Info Message

   This message is sent by the NCM to the CCM to inform the endpoints
   that the NCM supports for MAMS functionality.  In addition to the base
   information (Appendix C.2.1) C.2.1), it contains the following information:

   a)

   (a)  NCM Connections (described in Appendix C.2.3)

   Following is the (Appendix C.2.3).

   The representation of the message: message is as follows:

       object {
          NCMConnections ncm_connections;
       } MXSystemInfo : MXBase;

C.1.4.  Capability Exchange Procedure

C.1.4.1.  MX Capability Request

   This message is sent by the CCM to the NCM to indicate the
   capabilities of the CCM instance available to the NCM indicated in
   the System Info message earlier.  In addition to the base information
   (Appendix C.2.1) C.2.1), it contains the following information:

   (a)  Features Activation Status: Described in and their activation status: See Appendix C.2.5 C.2.5.

   (b)  Number of anchor connections: Number Anchor Connections: The number of anchor connection
        (towards connections
        (toward the core) supported by the NCM.

   (c)  Anchor Connections: Described in sec connections: See Appendix C.2.6 C.2.6.

   (d)  Number of Delivery connections: Number Connections: The number of delivery connection
        (towards
        connections (toward the access) supported by the NCM.

   (e)  Delivery Connections: Described in connections: See Appendix C.2.7 C.2.7.

   (f)  Convergence Methods: Described in methods: See Appendix C.2.9 C.2.9.

   (g)  Adaptation Methods: Described in methods: See Appendix C.2.10

   Following is the C.2.10.

   The representation of the message: message is as follows:

       object {
          FeaturesActive feature_active;
          JSONNumber num_anchor_connections;
          AnchorConnections anchor_connections;
          JSONNumber num_delivery_connections;
          DeliveryConnections delivery_connections;
          ConvergenceMethods convergence_methods;
          AdaptationMethods adaptation_methods
       } MXCapabilityReq : MXBase;

C.1.4.2.  MX Capability Response

   This message is sent by the NCM to the CCM to indicate the
   capabilities of the NCM instance and unique session identifier for
   the CCM.  In addition to the base information (Appendix C.2.1) C.2.1), it
   contains the following information:

   (a)  Features Activation Status: Described in and their activation status: See Appendix C.2.5 C.2.5.

   (b)  Number of anchor connections: Number Anchor Connections: The number of anchor connection
        (towards connections
        (toward the core) supported by the NCM.

   (c)  Anchor Connections: Described in connections: See Appendix C.2.6 C.2.6.

   (d)  Number of Delivery connections: Number Connections: The number of delivery connection
        (towards
        connections (toward the access) supported by the NCM.

   (e)  Delivery Connections: Described in connections: See Appendix C.2.7 C.2.7.

   (f)  Convergence Methods: Described in methods: See Appendix C.2.9 C.2.9.

   (g)  Adaptation Methods: Described in methods: See Appendix C.2.10 C.2.10.

   (h)  Unique Session Id: ID: This uniquely identifies the session between
        the CCM and the NCM in a network.  Described in  See Appendix C.2.2

   Following is the C.2.2.

   The representation of the message: message is as follows:

       object {
          FeaturesActive feature_active;
          JSONNumber num_anchor_connections;
          AnchorConnections anchor_connections;
          JSONNumber num_delivery_connections;
          DeliveryConnections delivery_connections;
          ConvergenceMethods convergence_methods;
          AdaptationMethods adaptation_methods
          UniqueSessionId unique_session_id;
       } MXCapabilityRsq MXCapabilityRsp : MXBase;

C.1.4.3.  MX Capability Acknowledge

   This message is sent by the CCM to the NCM to indicate acceptance of
   capabilities advertised by the NCM in an earlier MX Capability
   Response message.  In addition to the base information
   (Appendix C.2.1) C.2.1), it contains the following information:

   (a)  Unique Session Id: ID: Same identifier as the identifier provided in
        the MX Capability
        RSP.  Described in Response.  See Appendix C.2.2.

   (b)  Capability Acknowledgement: Either Accept Acknowledgment: Indicates either acceptance or Reject
        rejection of the capabilities sent by the CCM.  Can take use either
        "MX_ACCEPT" or "MX_REJECT" as acceptable values.

   Following is the

   The representation of the message: message is as follows:

       object {
          UniqueSessionId unique_session_id;
          JSONString capability_ack;
       } MXCapabilityAck : MXBase;

C.1.5.  User Plane  User-Plane Configuration Procedure

C.1.5.1.  MX User Plane User-Plane Configuration Request

   This message is sent by the NCM to the CCM to configure the user
   plane for MAMS.  In addition to the base information
   (Appendix C.2.1) C.2.1), it contains the following information:

   (a)  Number of Anchor Connection: Number Connections: The number of anchor connections
        supported by the NCM.

   (b)  Setup of Anchor Connections: Described in anchor connections: See Appendix C.2.11.

   Following is the

   The representation of the message: message is as follows:

       object {
          JSONNumber num_anchor_connections;
          SetupAnchorConns anchor_connections;
       } MXUPSetupConfigReq : MXBase;

C.1.5.2.  MX User Plane User-Plane Configuration Confirmation

   This message is the confirmation of user plane the user-plane setup message sent
   from the CCM after successfully configuring the user plane at user
   equipment. on the
   client.  This message contains the following information:

   (a)  Unique Session Id: ID: Same identifier as the identifier provided in
        the MX Capability
        RSP.  Described in Response.  See Appendix C.2.2.

   (b)  MX Probe Parameters probe parameters (included if probing is supported) supported).

        (1)  Probe Port: UDP port for accepting probe message.

        (2)  Anchor connection Id: ID: Identifier of the anchor connection
             to be used for probe function, provided function.  Provided in user plane setup
             request. the MX UP Setup
             Configuration Request.

        (3)  MX Configuration Id: For the given anchor connection, which
             configuration id is to be used for probe, this ID: This parameter is present included only if provided in the user
             MX Configuration ID parameter is available from the user-
             plane setup request.
   (c)  For each delivery configuration.  It indicates the MX
             configuration ID of the anchor connection to be used for
             probe function.

   (c)  The following information is required: required for each delivery
        connection:

        (1)  Connection ID: Delivery connection id ID supported by UE. the
             client.

        (2)  Client Adaptation Layer Adaptation-Layer Parameters: If the UDP adaptation layer Adaptation
             Layer is in use use, then the UDP port to be used at on the C-MADP
             side.

   Following is the

   The representation of the message: message is as follows:

       object {
          UniqueSessionId unique_session_id;
          [ProbeParam probe_param;]
          JSONNumber num_delivery_conn;
          ClientParam client_params <1...*>;
       } MXUPSetupConfigCnf : MXBase;

   Where ProbeParam is defined as following: follows:

       object {
          JSONNumber probe_port;
          JSONNumber anchor_conn_id;
          [JSONNumber mx_configuration_id;]
       } ProbeParam;

   Where ClientParam is defined as following: follows:

       object {
          JSONNumber connection_id;
          [AdaptationParam adapt_param;]
       } ClientParam;

   Where AdaptationParam is defined as following: follows:

       object {
          JSONNumber udp_adapt_port;
       } AdaptationParam;

C.1.6.  Reconfiguration Procedure

C.1.6.1.  MX Reconfiguration Request

   This message is sent by the CCM to the NCM in the case of
   reconfiguration of any of the connections from user equipment's the client's side.  In
   addition to the base information (Appendix C.2.1) C.2.1), it contains the
   following information:

   (a)  Unique Session Id: ID: Identifier for the CCM-NCM association
        Appendix C.2.2.

   (b)  Reconfiguration Action: Type of The reconfiguration action type can be
        one of "setup", "release" "release", or "modify". "update".

   (c)  Connection Id: ID: Connection Id ID for which the reconfiguration is
        taking place.

   (d)  IP address: IP address in case of setup and modify type of
        reconfiguration. Included if Reconfiguration Action is either "setup"
        or "update".

   (e)  SSID: If the connection type is WiFi, in that case Wi-Fi, then this parameter
        contains the SSID to which the
        UE client has attached to is contained in this parameter. attached.

   (f)  MTU of the connection: The MTU of the delivery path that is
        calculated at the UE client for use by the NCM to configure
        fragmentation and concatenation procedures at the N-MADP.

   (g)  Connection Status: This parameter informs if indicates whether the
        connection is currently "disabled", "enabled" "enabled", or "connected".
        Default: "connected".

   (h)  Delivery Node Id: ID: Identity of the node to which the client is
        attached.  ECGI in  In the case of LTE and WiFi AP Id or MAC address in LTE, this is an ECGI.  In the case of WiFi.

   Following
        Wi-Fi, this is the an AP ID or a MAC address.

   The representation of the message: message is as follows:

       object {
          UniqueSessionId unique_session_id;
          JSONString reconf_action;
          JSONNumber connection_id;
          JSONString ip_address;
          JSONString ssid;
          JSONNumber mtu_size;
          JSONString connection_status;
      [JSONSring
          [JSONString delivery_node_id;]
       } MXReconfReq : MXBase;

C.1.6.2.  MX Reconfiguration Response

   This message is sent by the NCM to the CCM as a confirmation towards
   reconfiguration requirement after taking of the reconfiguration into use
   received MX Reconfiguration Request and contains only the base
   information (as defined in Appendix C.2.1).

   Following is the

   The representation of the message:] message is as follows:

       object {
       } MXReconfRsp : MXBase;

C.1.7.  Path Estimation Procedure

C.1.7.1.  MX Path Estimation Request

   This message is sent by the NCM towards toward the CCM to configure the CCM
   to send
   path estimation reports. MX Path Estimation Results.  In addition to the base
   information (Appendix C.2.1) C.2.1), it contains the following information:

   (a)  Connection Id: Id ID: ID of the connection for which the path
        estimation report is required.

   (b)  Init Probe Test Duration: Duration of initial probe test test, in
        milliseconds.  [TBD: Range of values]
        milliseconds.

   (c)  Init Probe Test Rate: Initial testing rate rate, in Mega Bits megabits per
        Second.  [TBD: Range of values]
        second.

   (d)  Init Probe Size: Size of each packet for initial probe probe, in Bytes.
        [TBD: Range of values]
        bytes.

   (e)  Init Probe Ack: Probe-ACK: If an acknowledgement acknowledgment for probe is required.
        [Possible
        (Possible values: "yes", "no"] "no")

   (f)  Active Probe Frequency: Frequency Frequency, in milliseconds milliseconds, at which the
        active probes shall be sent.  [TBD: Range of values]

   (g)  Active Probe Size: Size of the active probe probe, in Bytes.  [TBD:
        Range of values] bytes.

   (h)  Active Probe Duration: Duration Duration, in seconds seconds, for which the
        active probe shall be performed.  [TBD.  Range of values]

   (i)  Active Probe Ack. Probe-ACK: If an acknowledgement acknowledgment for probe is required.
        [Possible
        (Possible values: "yes", "no"]
   Following is the "no")

   The representation of the message: message is as follows:

       object {
          JSONNumber connection_id;
          JSONNumber init_probe_test_duration_ms;
          JSONNumber init_probe_test_rate_Mbps;
          JSONNumber init_probe_size_bytes;
          JSONString init_probe_ack_req;
          JSONNumber active_probe_freq_ms;
          JSONNumber active_probe_size_bytes;
          JSONNumber active_probe_duration_sec;
          JSONString active_probe_ack_req;
       } MXPathEstReq : MXBase;

C.1.7.2.  MX Path Estimation Report Results

   This message is sent by the CCM to the NCM as report to report on the probe
   estimation configured by the NCM.  In addition to the base
   information (Appendix C.2.1) C.2.1), it contains the following information:

   (a)  Unique Session Id: ID: Same identifier as the identifier provided in
        the MX Capability
        RSP.  Described in Response.  See Appendix C.2.2.

   (b)  Connection Id: Id ID: ID of the connection for which the path
        estimation report MX Path
        Estimation Results message is required.

   (c)  Init Probe Results: Defined in section See Appendix C.2.12.

   (d)  Active Probe Results: Defined in section See Appendix C.2.13.

   Following is the

   The representation of the message: message is as follows:

       object {
          JSONNumber connection_id;
          UniqueSessionId unique_session_id;
          [InitProbeResults init_probe_results;]
          [ActiveProbeResults active_probe_results;]
       } MXPathEstResults : MXBase;

C.1.8.  Traffic Steering  Traffic-Steering Procedure

C.1.8.1.  MX Traffic Steering Request

   This message is sent by the NCM to the CCM for enabling to enable traffic steering at
   on the delivery side in uplink and downlink configuration. configurations.  In
   addition to the base information (Appendix C.2.1) C.2.1), it contains the
   following information:

   (a)  Connection id: ID: Anchor connection number for which the traffic
        steering is getting being defined.

   (b)  MX Configuration Id: ID: MX configuration for which the traffic
        steering is getting being defined.

   (c)  Downlink Delivery: Defined in See Appendix C.2.14.

   (d)  Default UL Delivery: The default delivery connection for the
        uplink.  All traffic should be delivered on this connection in
        the uplink
        direction direction, and the TFT Traffic Flow Template (TFT) filter
        should be applied only for the traffic mentioned in Uplink
        Delivery.

   (e)  Uplink Delivery: Defined in See Appendix C.2.15.

   (f)  Features Activated: Defined in and their activation status: See Appendix C.2.5.

   Following is the

   The representation of the message: message is as follows:

       object {
          JSONNumber connection_id;
          [JSONNumber mx_configuration_id;]
          DLDelivery downlink_delivery;
          JSONNumber default_uplink_delivery;
          ULDelivery uplink_delivery;
          FeaturesActive feature_activation; feature_active;
       } MXTraffiSteeringReq MXTrafficSteeringReq : MXBase;

C.1.8.2.  MX Traffic Steering Response

   This message is a response to an MX Traffic Steering request Request from the
   CCM to the NCM.  In addition to the base information
   (Appendix C.2.1) C.2.1), it contains the following information:

   (a)  Unique Session Id: ID: Same identifier as the identifier provided in
        the MX Capability
        RSP.  Described in Response.  See Appendix C.2.2.

   (b)  Features Activated: Defined in and their activation status: See Appendix C.2.5.

   Following is the

   The representation of the message: message is as follows:

       object {
          UniqueSessionId unique_session_id;
          FeaturesActive feature_activation; feature_active;
       } MXTraffiSteeringResp MXTrafficSteeringResp : MXBase;

C.1.9.  MAMS Application MADP Association

C.1.9.1.  MAMS  MX Application MADP Association Request

   This message is sent by the CCM to the NCM to select MADP instances
   provided earlier in User Plane the MX UP Setup Request Configuration Request, based on requirement of
   requirements for the applications.

   In addition to the base information (Appendix C.2.1) C.2.1), it contains the
   following:

   (a)  Unique Session Id: ID: This uniquely identifies the session between
        the CCM and the NCM in a network.  Described in  See Appendix C.2.2, and a C.2.2.

   (b)  A list of following MX Application MADP Associations

        (a) Associations, with each entry as
        follows:

        (1)  Connection id: Defines ID: Represents the anchor connection number of
             the MADP instance
        (b) instance.

        (2)  MX Configuration Id: identify ID: Identifies the MX configuration of the
             MADP instance
        (c) instance.

        (3)  Traffic Flow Template Uplink: Traffic template Flow Template, as
             defined in
             5.16 Appendix C.2.16, to be used in the uplink
             direction.
        (d)

        (4)  Traffic Flow Template Downlink: Traffic template Flow Template, as
             defined in
             5.16 Appendix C.2.16, to be used in the downlink
             direction.

   Following is the

   The representation of the message: message is as follows:

       object {
          UniqueSessionId unique_session_id;
          MXAppMADPAssoc app_madp_assoc_list <1..*>;
       } MXAppMADPAssocReq : MXBase;

   Where each measurement MXAppMADPAssoc is represented by the
   following:

       object {
          JSONNumber connection_id;
          JSONNumber mx_configuration_id
          TrafficFlowTemplate tft_ul_list <1..*>;
          TrafficFlowTemplate tft_dl_list <1..*>;
       } MXAppMADPAssoc;

C.1.9.2.  MAMS  MX Application MADP Association Response

   This message is sent by the NCM to the CCM to confirm the selected
   MADP instances provided in request message the MX Application MADP Association
   Request by the CCM.

   In addition to the base information (Appendix C.2.1), it contains
   information if the request has been successful.

   Following is the

   The representation of the message: message is as follows:

       object {
          JSONBool is_success;
       } MXAppMADPAssocResp : MXBase;

C.1.10.  MX SSID Indication

   This message is sent by the NCM to the CCM to indicate the list of
   allowed
   SSID which SSIDs that are supported by the MAMS entity at on the network
   side.  It contains the list of SSIDs.

   Each SSID consists of the type of SSID (which can be one of the
   "SSID", "BSSID"
   following: SSID, BSSID, or "HESSID" HESSID) and the SSID itself.

   Following is the

   The representation of the message: message is as follows:

       object {
          SSID ssid_list<1..*>; ssid_list <1..*>;
       } MXSSIDIndication : MXBase;

   Where each SSID is defined as following: follows:

       object {
          JSONString ssid_type;
          JSONString ssid;
       } SSID;

C.1.11.  Measurements

C.1.11.1.  MX Measurement Configuration

   This message is sent from the NCM to the CCM to configure the period
   measurement reporting at the CCM.  The message contains a list of
   measurement configuration configurations, with each element containing the
   following information:

   (a)  Connection Id: ID: Connection id ID of the delivery connection for
        which the reporting is being configured.

   (b)  Connection Type: Connection Type type for which the reporting is
        being configured, can configured.  Can be "lte", "wifi", "5g-nr" etc. "LTE", "Wi-Fi", "5G_NR".

   (c)  Measurement Report Configuration: Actual report configuration
        based on the connection type, Connection Type, as defined in Appendix C.2.17

   Following is the C.2.17.

   The representation of the message: message is as follows:

       object {
          MeasReportConf measurement_configuration <1..*>;
       } MXMeasReportConf : MXBase;

   Where each measurement MeasReportConf is represented by the
   following:

       object {
          JSONNumber connection_id;
          JSONString connection_type;
          MeasReportConfs meas_rep_conf <1..*>;
       } MeasReportConf;

C.1.11.2.  MX Measurement Report

   This message is periodically sent by the CCM to the NCM after
   measurement configuration.  In addition to the base information information, it
   contains the following information:

   (a)  Unique Session Id: ID: Same identifier as the identifier provided in
        the MX Capability
        RSP. Response.  Described in Appendix C.2.2.

   (b)  Measurement report for each delivery connection is measured by
        the client device as defined in Appendix C.2.18.

   Following is the

   The representation of the message: message is as follows:

       object {
          UniqueSessionId unique_session_id;
          MXMeasRep measurment_reports measurement_reports <1..*>;
       } MXMeasurementReport : MXBase;

C.1.12.  Keep Alive  Keep-Alive

C.1.12.1.  Keep Alive  MX Keep-Alive Request

   A Keep Alive

   An MX Keep-Alive Request message can be sent from either the NCM or the CCM
   on expiry of MAMS_KEEP_ALIVE the Keep-Alive timer or a handover event.  This request
   shall be responded by the  The peer
   shall respond to this request with Keep Alive an MX Keep-Alive Response.  In the
   case of no response from peer the peer, the MAMS connection shall be
   assumed to be
   broken broken, and the CCM shall establish a new connection shall be established again by CCM by
   sending MX Discover messages.

   In addition to the base information information, it cantains contains the following
   information:

   (a)  Keep Alive  Keep-Alive Reason: Reason for sending this message, can be
        "Timeout" or "Handover".

   (b)  Unique Session Id: ID: Identifier for the CCM-NCM association
        Appendix C.2.2.

   (c)  Connection Id: ID: Connection id ID for which handover is detected, in
        case if
        the reason is "Handover".

   (d)  Delivery Node Id: ID: The target delivery node id ID (ECGI or WiFi
        Access Point Id/MAC) Wi-Fi AP
        ID/MAC address) to which the handover is executed.

   Following is the

   The representation of the message: message is as follows:

       object {
          JSONString keep_alive_reason;
          UniqueSessionId unique_session_id;
          JSONNumber connection_id;
          JSONString delivery_node_id;
       } MXKeepAliveReq : MXBase;

C.1.12.2.  Keep Alive  MX Keep-Alive Response

   On receiving Keep Alive an MX Keep-Alive Request from a peer, the NCM/CCM shall
   immediately respond with a Keep Alive an MX Keep-Alive Response message on the same
   delivery path from where the request arrived.  In addition to the
   base information information, it contains the unique session identifier for the
   CCM-NCM association (defined in Appendix C.2.2)

   Following is the

   The representation of the message: message is as follows:

       object {
          UniqueSessionId unique_session_id;
       } MXKeepAliveResp : MXBase;

C.1.13.  Session Termination Procedure

C.1.13.1.  MX Session Terminate Termination Request

   In the event where the NCM or CCM can no longer handle MAMS for any
   reason then
   reason, it can send an MX session termination request Session Termination Request to the peer.
   In addition to the base information information, it contains a Unique Session Id ID
   and the reason for termination, the termination; this can be "MX_NORMAL_RELEASE",
   "MX_NO_RESPONSE"
   "MX_NO_RESPONSE", or "INTERNAL_ERROR".

   Following is the

   The representation of the message: message is as follows:

       object {
          UniqueSessionId unique_session_id;
          JSONString reason;
       } MXSessionTerminationReq : MXBase;

C.1.13.2.  MX Session Terminate Termination Response

   On reception receipt of an MX session termination request Session Termination Request from a peer, NCM/CCM 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 MAMS-related
   resources and settings.  The CCM shall re-initiate reinitiate a new session with
   MX Discover messages again.

   Following is the messages.

   The representation of the message: message is as follows:

         object {
            UniqueSessionId unique_session_id;
         } MXSessionTerminationResp : MXBase;

C.1.14.  Network Analytics

C.1.14.1.  MX Network Analytics Request

   This message is sent by the CCM to the NCM to request for parameters like
   bandwidth, jitter, latency latency, and signal quality predicted by the
   network analytics function.  In addition to the base information information, it
   contains the following parameter:

   (a)  Unique Session Id: ID: Same identifier as the identifier provided in
        the MX Capability
        RSP. Response.  Described in Appendix C.2.2.

   (b)  Parameter List: List of parameters in which the CCM is interested
        in namely
        interested: one or more of, of "bandwidth", "jitter", "latency" "latency", and
        "signal_quality".

   Following is the

   The representation of the message: message is as follows:

       object {
          UniqueSessionId unique_session_id;
          JSONString params<1..*>; params <1..*>;
       } MXNetAnalyticsReq : MXBase;

   Where the params object can take one or more of the following values:

       "bandwidth"
       "jitter"
       "latency"
       "signal_quality"

C.1.14.2.  MX Network Analytics Response

   This message is sent by the NCM to the CCM in response to the analytics
   request. MX
   Network Analytics Request.  For each delivery connection that the
   client has has, the NCM reports the requested parameter predictions and
   their respective
   likelihood likelihoods (between 1-100). 1 and 100 percent).

   In addition to the base information information, it contains the following
   parameters:

   (a)  Number of delivery connections: Delivery Connections: The number of delivery
        connections that are currently configured for the client currently. client.

   (b)  For each delivery connection  The following information is provided:

        (a) provided for each delivery
        connection:

        (1)  Connection Id: ID: Connection ID of the delivery connection for
             which the parameters are being predicted.
        (b)

        (2)  Connection Type: Type of connection, can connection.  Can be "Wi-Fi, "5G
             NR", "Multi-Fire" and "Wi-Fi",
             "5G_NR", "MulteFire", or "LTE".
        (c)

        (3)  List of Parameters for which Prediction is requested, where
             each of the predicted parameters consists of the following:

             (a)  Parameter name: Name: Name of the parameter being predicted.
                  Can be one of "bandwidth", "jitter", "latency", or
                  "signal_quality".

             (b)  Additional Parameter: If Parameter name is
                  "signal_quality", then this qualifies the quality
                  parameter like "lte_rsrp", "lte_rsrq", "nr_rsrp",
                  "nr_rsrq", or "wifi_rssi".

             (c)  Predicted value: Value: Provides the predicted value of the
                  parameter and, if applicable, the additional
                  parameter.

             (d)  Likelihood: Provides a stochastic likelihood of about the
                  predicted value.

             (e)  Validity Time: the The time horizon until duration for which the
                  predictions are valid.

   Following is the

   The representation of the message: message is as follows:

       object {
          MXAnalyticsList param_list<1..*>>; param_list <1..*>;
       } MXNetAnalyticsResp : MXBase;

   Where MXAnalyticsList is defined as following::

      object{ follows:

       object {
          JSONNumber connection_id;
          JSONString connection_type;
          ParamPredictions predictions <1..*>;
       } MXAnalyticsList;

   Where each ParamPredictions item is defined as:

      object{

       object {
          JSONString param_name;
          [JSONString additional_param;]
          JSONNumber prediction;
          JSONNumber likelihood;
          JSONNumber validity_time;
       } ParamPredictions;

C.2.  Protocol Specification: Data Types

C.2.1.  MXBase

   This is the base information that every message between the CCM and
   NCM exchanges shall have as mandatory information.  It contains the
   following information:

   (a)  Version: Version of MAMS in used used.

   (b)  Message Type: Message type being sent with sent, where the following as are
        considered valid values:

        (a)

          "mx_discover"
        (b)
          "mx_system_info"
        (c)
          "mx_capability_req"
        (d)  "mx_capability_resp"
        (e)  mx_capability_ack"
        (f)
          "mx_capability_rsp"
          "mx_capability_ack"
          "mx_up_setup_conf_req"
        (g)
          "mx_up_setup_cnf"
        (h)
          "mx_reconf_req"
        (i)
          "mx_reconf_rsp"
        (j)
          "mx_path_est_req"
        (k)
          "mx_path_est_results"
        (l)
          "mx_traffic_steering_req"
        (m)
          "mx_traffic_steering_rsp"
        (n)
          "mx_ssid_indication"
        (o)
          "mx_keep_alive_req"
        (p)
          "mx_keep_alive_rsp"
        (q)
          "mx_measurement_conf"
        (r)
          "mx_measurement_report"
        (s)
          "mx_session_termination_req"
        (t)  "mx_session_termination_resp"
        (u)
          "mx_session_termination_rsp"
          "mx_app_madp_assoc_req"
        (v)  "mx_app_madp_assoc_resp"
        (w)
          "mx_app_madp_assoc_rsp"
          "mx_network_analytics_req"
        (x)  "mx_network_analytics_resp"
          "mx_network_analytics_rsp"

   (c)  Sequence Number: Sequence number to uniquely identify a
        transaction of
        particular message exchange, e.g. e.g., MX Capability REQ/RSP/
        ACK.

   Following is the
        Request/Response/Acknowledge.

   The representation of this data type: type is as follows:

       object {
          JSONString version;
          JSONString message_type;
          JSONNumber sequence_num;
       } MXBase;

C.2.2.  Unique Session Id ID

   This data type defines represents the unique session id ID between a CCM and NCM
   entity, it
   entity.  It contains a an NCM id which ID that is unique in the network and a
   session id ID that is allocated by the NCM for that session.  On reception, receipt
   of
   discovery message the MX Discover message, if the session is existing exists, then the old
   session id ID is returned in the MX System Info message otherwise message; otherwise, the
   NCM allocates a new session id to ID for the CCM and sends the new ID in response with
   the MX System Info message.

   Following is the

   The representation of this data type: type is as follows:

       object {
          JSONNumber ncm_id;
          JSONNumber session_id;
       } UniqueSessionId;

C.2.3.  NCM Connections

   This data type defines represents the connection available at the NCM for
   MAMS connectivity towards toward the User Equipment. client.  It contains a list of NCM
   connections available available, where each connection has the following
   information:

   (a)  Connection Information: As defined in See Appendix C.2.4 C.2.4.

   (b)  NCM End Point information: This contains Endpoint Information: Contains the IP Address address and Port port
        exposed by the NCM end point endpoint for CCM.

   Following is the CCM.

   The representation of this data type: type is as follows:

       object {
          NCMConnection items<1..*>; items <1..*>;
       } NCMConnections;

   where NCMConnection is defined as:

       object {
          NCMEndPoint ncm_end_point;
       } NCMConnection : ConnectionInfo;

   where NCMEndPoint is defined as:

       object {
          JSONString ip_address;
          JSONNumber port;
       } NCMEndPoint;

C.2.4.  Connection Information

   This data type provides the mapping of connection Id ID and connection
   type.  It contains the following information:

   (a)  Connection Id: Number indicating ID: Unique number identifying the connection can be 0,1,2 and
        3. connection.

   (b)  Connection type: Type: Type of connect connection can be "Wi-Fi, "5G NR", "Multi-
        Fire" and "Wi-Fi", "5G_NR",
        "MulteFire", or "LTE".

   The two are considered a mapping like 0-"Wi-Fi", 1-"5G NR", 2-"Multi-
   Fire" and 3-"LTE".

   Following is the representation of this data type: type is as follows:

       object {
          JSONNumber connection_id;
          JSONString connection_type;
       } ConnectionInfo;

C.2.5.  Features and Their Activation Status

   This data type provides the list of all features with their
   activation status.  Each feature status contains the following:

   (a)  Feature Name: Name The name of the feature can be one of the
        following:

        (a)

       "lossless_switching"
        (b)
       "fragmentation"
        (c)
       "concatenation"
        (d)
       "uplink_aggregation"
        (e)
       "downlink_aggregation"
        (f)
       "measurement"

   (b)  Active status: Activation status of the feature, feature: "true" means
        that the feature is active, and "false" means that the feature
        is inactive.

   Following is the

   The representation of this data type: type is as follows:

       object {
          FeatureInfo items<1..*>; items <1..*>;
       } FeaturesActive;

   where FeatureInfo is defined as:

       object {
          JSONString feature_name;
          JSONBool active;
       } FeatureInfo;

C.2.6.  Anchor Connections

   This data type contains the list of Connection Information items
   (Appendix C.2.4) that are supported at on the anchor (core) side.

   Following is the

   The representation of this data type: type is as follows:

       object {
          ConnectionInfo items<1..*>; items <1..*>;
       } AnchorConnections;

C.2.7.  Delivery Connections

   This data type contains the list of Connection Information
   (Appendix C.2.4) that are supported at on the delivery (access) side.

   Following is the

   The representation of this data type: type is as follows:

       object {
          ConnectionInfo items<1..*>; items <1..*>;
       } DeliveryConnections;

C.2.8.  Method Support

   This data type provides the support for a particular convergence or
   adaptation method.  It consists of the following:

   (a)  Method: Name of the method.

   (b)  Supported: Whether the method named listed above is supported or not.
        Possible values are "true" and "false".

   Following is the

   The representation of this data type: type is as follows:

       object {
          JSONString method;
          JSONBool supported;
       } MethodSupport;

C.2.9.  Convergence Methods

   This data type contains the list of all convergence methods and their
   support status.  Convergence Methods  The possible convergence methods are:

       "GMA"
       "MPTCP_Proxy"
       "GRE_Aggregation_Proxy"
       "MPQUIC"

   Following is the

   The representation of this data type: type is as follows:

       object {
          MethodSupport items<1..*>; items <1..*>;
       } ConvergenceMethods;

C.2.10.  Adaptation Methods

   This data type contains the list of all convergence adaptation methods and their
   support status.  Converge Methods  The possible adaptation methods are:

       "UDP_without_DTLS"
       "UDP_with_DTLS"
      "IPSec"
       "IPsec"
       "Client_NAT"

   Following is the

   The representation of this data type: type is as follows:

       object {
          MethodSupport items<1..*>; items <1..*>;
       } AdaptationMethods;

C.2.11.  Setup of Anchor Connections

   This data type defines represents the setup configuration for each of the anchor
   connection that is required at on the user equipment client's side.  It contains the
   following information information, in addition to the connection id ID and type of
   the anchor connection:

   (a)  Number of Active MX configurations: Configurations: If more than one active
        configurations are
        configuration is present for this anchor anchor, then this identifies
        the number of such connections connections.

   (b)  For each active configuration  The following convergence parameters are provided:

        (a) provided for each
        active configuration:

        (1)  MX Configuration Identifier: This identifier is present in
             case ID: Present if there are multiple active configuration and identifies
             configurations.  Identifies the configuration for this MADP
             instance id.
        (b) ID.

        (2)  Convergence Method: Converge Convergence method selected, has selected.  Has to be
             one of the supported convergence method as methods listed in section
             Appendix C.2.9.
        (c)

        (3)  Convergence Method Parameters: Described in section
             Appendix C.2.11.1
        (d)

        (4)  Number of Delivery Connections: Number The number of delivery
             connections (access side) that are supported for this
             anchor connection.
        (e)

        (5)  Setup Delivery Connections: of delivery connections: Described in section
             Appendix C.2.11.2.

   Following is the

   The representation of this data type: type is as follows:

       object {
          SetupAnchorConn items<1..*>; items <1..*>;
       } SetupAnchorConns;

   Where each Anchor anchor connection configuration is defined as following: follows:

       object {
          [JSONNumber num_active_mx_conf;]
          ConvergenceConfig convergence_config
       } SetupAnchorConn : ConnectionInfo;

   where each Convergence configuration is defined as following: follows:

       object {
          [JSONNumber mx_configuration_id;]
          JSONString convergence_method;
          ConvergenceMethodParam convergence_method_params;
          JSONNumber num_delivery_connections;
          SetupDeliveryConns delivery_connections;
       } ConvergenceConfig;

C.2.11.1.  Convergence Method Parameters

   This data type defines represents the parameters used for the convergence
   method and contains the following:

   (a)  Proxy IP: IP Address address of the proxy that is provided by Convergence
        Method selected. the
        selected convergence method.

   (b)  Proxy Port: Port of the proxy that is provided by Convergence
        Method selected.

   Following in the selected
        convergence method.

   The representation of this data type: type is as follows:

       object {
          JSONString proxy_ip;
          JSONString proxy_port;
          JSONString client_key;
       } ConvergenceMethodParam;

C.2.11.2.  Setup Delivery Connections

   This is the list of delivery connections and their parameters to be
   configured at on the user equipment. client.  Each delivery connection defined by its
   connection information (Appendix C.2.4) contains optionally contains the
   following:

   (a)  Adaptation Method: Selected adaptation method name, this name.  This shall
        be one of the names as methods listed in Appendix C.2.10.

   (b)  Adaptation Method Parameters: Depending on the adaptation method
        method, one or more of the following parameters shall be
        provided.

        (a)

        (1)  Tunnel IP address
        (b)

        (2)  Tunnel Port number
        (c)

        (3)  Shared Secret
        (d)

        (4)  MX header optimization: If the adaptation method is UDP_and
             UDP_without_DTLS or UDP_with_DTLS, and convergence is GMA GMA,
             then this flag represents if whether or not the checksum field
             and the length field in the IP header of a an MX PDU should
             be recalculated or not by the MX convergence
             sublayer. 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 present, then the
             default of "false" should be considered.

   Following in the

   The representation of this data type: type is as follows:

       object {
          SetupDeliveryConn items<1..*>; items <1..*>;
       } SetupDeliveryConns;

   where each Setup Delivery Connection "SetupDeliveryConn" consists of the following:

       object {
      [JSONSting
         [JSONString adaptation_method;]
         [AdaptationMethodParam adaptation_method_param;]
       } SetupDeliveryConn : ConnectionInfo;

   where Adaptation Method Param AdaptationMethodParam is defined as:

       object {
          JSONString tunnel_ip_addr;
          JSONString tunnel_end_port;
          JSONString shared_secret;
          [JSONBool mx_header_optimization;]
       } AdaptationMethodParam;

C.2.12.  Init Probe Results

   This data type defines provides the results of the init probe request made by
   the NCM.  It consists of the following information:

   (a)  Lost Probes: Percentage or of probes lost.

   (b)  Prode  Probe Delay: Average delay of probe message message, in microseconds.

   (c)  Probe Rate: Probe rate achieved achieved, in Mega Bits megabits per second.

   Following in the

   The representation of this data type: type is as follows:

       object {
          JSONNumber lost_probes_percentage;
          JSONNumber probe_rate_Mbps;
       } InitProbeResults;

C.2.13.  Active Probe Results

   This data type defines provides the results of init the active probe request made
   by the NCM.  It consists of the following information:

   (a)  Average Probe Throughput: Average active probe throughput
        achieved
        achieved, in Mega Bits megabits per second.

   Following in the

   The representation of this data type: type is as follows:

       object {
          JSONNumber avg_tput_last_probe_duration_Mbps;
       } ActiveProbeResults;

C.2.14.  Downlink Delivery

   This data type defines represents the list of connections which that are enabled in on
   the delivery side to be used in the downlink direction.

   Following in the

   The representation of this data type: type is as follows:

       object {
          JSONNumber connection_id <1..*>;
       } DLDelivery;

C.2.15.  Uplink Delivery

   This data type defines represents the list of connections and parameters
   enabled for deliver the delivery side to be used in the uplink direction.

   The uplink delivery consists of multiple uplink delivery entities,
   where each entity consists of a traffic flow template Traffic Flow Template (TFT)
   Appendix C.2.16
   (Appendix C.2.16) and a list of connection ids IDs in uplink the uplink, where
   traffic qualifying for such traffic flow template a Traffic Flow Template can be
   redirected.

   Following in the

   The representation of this data type: type is as follows:

       object {
          ULDeliveryEntity ul_del <1..*>;
       } ULDelivery;

   Where each uplink delivery entity consists of the following data
   type:

       object {
          TrafficFlowTemplate ul_tft <1..*>;
          JSONNumber connection_id <1..*>;
       } ULDeliveryEntity;

C.2.16.  Traffic Flow Template

   The Traffic flow template Flow Template generally follows in general the guidelines specified
   in 3GPP
   TS 23.060. [ServDesc3GPP].

   The Traffic flow template Flow Template in MAMS consists of one or more of the
   following:

   (a)  Remote Address and Mask: IP address and subnet for remote
        addresses represented in CIDR Classless Inter-Domain Routing (CIDR)
        notation.  Default: "0.0.0.0/0".

   (b)  Local Address and Mask: IP address and subnet for local
        addresses represented in CIDR notation.  Default: "0.0.0.0/0"

   (c)  Protocol Type: IP protocol number of the payload being carried
        by an IP packet. e.g. packet (e.g., UDP, TCP etc. TCP).  Default: 255.

   (d)  Local Port Range: Range of ports for local ports for which the
        flow template
        Traffic Flow Template is applicable.  Default: Start=0,
        End=65535.

   (e)  Remote Port Range: Range of ports for remote ports for which the
        flow template
        Traffic Flow Template is applicable.  Default: Start=0,
        End=65535.

   (f)  Traffic Class: Represented by Type of Service in IPv4 and
        Traffic Class in IPv6.  Default: 255

   (g)  Flow Label: Flow label for IPv6, applicable only for IPv6
        protocol type.  Default: 0.

   Following in the

   The representation of this data type: type is as follows:

       object {
          JSONString remote_addr_mask;
          JSONString local_addr_mask;
          JSONNumber protocol_type;
          PortRange local_port_range;
          PortRange remote_port_range;
          JSONNumber traffic_class;
          JSONNumber flow_label;
       } TrafficFlowTemplate;

   Where the port range is defined as following: follows:

       object {
          JSONNumber start;
          JSONNumber end;
       } PortRange;

C.2.17.  Measurement Report Configuration

   This data type defines represents the configuration done by the NCM towards toward
   the CCM for reporting measurement events.

   (a)  Measurement Report Parameter: Parameter which that shall be measured
        and reported.  This is dependent on the connection type:

        (a)

        (1)  For the connection type "wifi" of "Wi-Fi", the allowed measurement
             type parameters are "WLAN_RSSI", "WLAN_LOAD", "UL_TPUT",
             "DL_TPUT",
             "EST_UL_TPUT" "EST_UL_TPUT", and "EST_DL_TPUT".
        (b)

        (2)  For the connection type "lte" of "LTE", the allowed measurement
             type parameters are "LTE_RSRP", "LTE_RSRQ", "UL_TPUT" "UL_TPUT", and
             "DL_TPUT".
        (c)

        (3)  For the connection type "5g-nr" of "5G_NR", the allowed measurement
             type parameters are "NR_RSRP", "NR_RSRQ", "UL_TPUT" "UL_TPUT", and
             "DL_TPUT".

   (b)  Threshold: High and Low low threshold for reporting.

   (c)  Period: Period for reporting reporting, in milliseconds.

   Following is the

   The representation of this data type: type is as follows:

       object {
          JSONString meas_rep_param;
          Threshold meas_threshold;
          JSONNumber meas_period;
       } MeasReportConfs;

   Where Threshold "Threshold" is defined as following: follows:

       object {
          JSONNumber high;
          JSONNumber low;
       } Threshold;

C.2.18.  Measurement Report

   This data type defines represents the measurements reported by the CCM for
   each access network measured.  This type contains the connection
   information, delivery node id which the Delivery Node ID that identifies either the cell
   (ECGI) or the
   WiFI Wi-Fi Access Point Id ID or MAC address (or equivalent
   identifier in other technologies) technologies), and the actual measurement
   performed by the CCM in the last measurement period.

   Following is the

   The representation of this data type: type is as follows:

       object {
          JSONNumber connection_id;
          JSONString connection_type;
          JSONString delivery_node_id;
          Measurement measurements <1..*>;
      }MXMeasRep;
       } MXMeasRep;

   Where Measurement is defined as the key value key-value pair of the measurement
   type and value.  The exact measurement type and value are defined on parameter reported for a per
   delivery
   given connection depends on its Connection Type.  The measurement
   type and defined parameters, for each Connection Type, are specified in
   Appendix C.2.17.

      object{

       object {
          JSONString measurement_type;
          JSONNumber measurement_value;
       } Measurement;

C.3.  Schemas in JSON

C.3.1.  MX Base Schema

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "definitions": {
       "message_type_def": {
         "enum": [
           "mx_discover",
           "mx_system_info",
           "mx_capability_req",
                   "mx_capability_resp",
           "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_resp",
           "mx_session_termination_rsp",
           "mx_app_madp_assoc_req",
                   "mx_app_madp_assoc_resp",
           "mx_app_madp_assoc_rsp",
           "mx_network_analytics_req",
                   "mx_network_analytics_resp"
           "mx_network_analytics_rsp"
         ],
         "type": "string"
       },
       "sequence_num_def": {
         "minimum": 1,
         "type": "integer"
       },
       "version_def": {
         "type": "string"
       }
      },
     "id": "http://www.ietf.org/mams/mx_base_def.json" "https://example.com/mams/mx_base_def.json"
   }

C.3.2.  MX Definitions

   {
       "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
       "definitions": {
           "adapt_method": {
               "enum": [
                   "UDP_without_DTLS",
                   "UDP_with_DTLS",
                                "IPSec",
                   "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",
                                "multi-fire",
                                "lte"
                   "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_acknowledgement"
           "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",
                       "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",
                   "validity_time",
                   "bandwidth",
                   "jitter",
                   "latency",
                   "signal_quality"
               ],
               "type": "string"
           },
           "predict_add_param_name": {
               "enum": [
                   "WLAN_RSSI",
                   "WLAN_LOAD",
                   "LTE_RSRP",
                   "LTE_RSRQ",
                   "NR_RSRP",
                   "NR_RSRQ"
               ],
               "type": "string"
                }
           },
       "id": "http://www.ietf.org/mams/definitions.json" "https://example.com/mams/definitions.json"
   }

C.3.3.  MX Discover

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "additionalProperties": false,
     "id": "http://www.ietf.org/mams/mx_discover.json", "https://example.com/mams/mx_discover.json",
     "properties": {
    "message_type" :
       "message_type": {"$ref": "mx_base_def.json#/message_type_def"},
        "sequence_num" :
       "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
        "version" :
       "version": {"$ref": "mx_base_def.json#/version_def"}
     },
     "type": "object"
   }

C.3.4.  MX System Update Info

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "additionalProperties": false,
     "id": "http://www.ietf.org/mams/mx_system_info.json", "https://example.com/mams/mx_system_info.json",
     "properties": {
       "message_type": {
                        "$ref": "mx_base_def.json#/message_type_def"
                }, {"$ref": "mx_base_def.json#/message_type_def"},
       "sequence_num": {
                        "$ref": "mx_base_def.json#/sequence_num_def"
                }, {"$ref": "mx_base_def.json#/sequence_num_def"},
       "version": {
                        "$ref": "mx_base_def.json#/version_def"
                }, {"$ref": "mx_base_def.json#/version_def"},
       "ncm_connections": {
         "type": "array",
         "items": [
                                { "$ref": "definitions.json#/connection" },
                                { "$ref": "definitions.json#/ncm_end_point" }
           {"$ref": "definitions.json#/connection"},
           {"$ref": "definitions.json#/ncm_end_point"}
         ]
       }
     },
     "type": "object"
   }

C.3.5.  MX Capability Request

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "additionalProperties": false,
     "id": "http://www.ietf.org/mams/mx_capability_req.json", "https://example.com/mams/mx_capability_req.json",
     "properties": {
    "message_type" :
       "message_type": {"$ref": "mx_base_def.json#/message_type_def"},
        "sequence_num" :
       "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
        "version" :
       "version": {"$ref": "mx_base_def.json#/version_def"},
       "adaptation_methods": {
         "items": { "$ref" : {"$ref": "definitions.json#/adaptation_method"},
         "type": "array"
       },
       "anchor_connections": {
         "items": { "$ref" : {"$ref": "definitions.json#/connection"},
         "type": "array"
       },
       "convergence_methods": {
         "items": { "$ref" : {"$ref": "definitions.json#/convergence_method"},
         "type": "array"
       },
       "delivery_connections": {
         "items": { "$ref" : {"$ref": "definitions.json#/connection"},
         "type": "array"
       },
       "feature_active": {
         "items": { "$ref" : {"$ref": "definitions.json#/feature_status"},
         "type": "array"
       },
       "num_anchor_connections": {
         "type": "integer"
       },
       "num_delivery_connections": {
         "type": "integer"
       }
     },
     "type": "object"
   }

C.3.6.  MX Capability Response

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "additionalProperties": false,
     "id": "http://www.ietf.org/mams/mx_capability_resp.json", "https://example.com/mams/mx_capability_rsp.json",
     "properties": {
        "message_type" :
       "message_type": {"$ref": "mx_base_def.json#/message_type_def"},
        "sequence_num" :
       "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
        "version" :
       "version": {"$ref": "mx_base_def.json#/version_def"},
       "adaptation_methods": {
         "items": { "$ref" : "definitions.json#/adaptation_method" }, {"$ref": "definitions.json#/adaptation_method"},
         "type": "array"
       },
       "anchor_connections": {
         "items": { "$ref" : {"$ref": "definitions.json#/connection"},
         "type": "array"
       },
       "convergence_methods": {
         "items": { "$ref" : "definitions.json#/convergence_method" }, {"$ref": "definitions.json#/convergence_method"},
         "type": "array"
       },
       "delivery_connections": {
         "items": { "$ref" : {"$ref": "definitions.json#/connection"},
         "type": "array"
       },
       "feature_active": {
         "items": { "$ref" : {"$ref": "definitions.json#/feature_status"},
         "type": "array"
       },
       "num_anchor_connections": {
         "type": "integer"
       },
       "num_delivery_connections": {
         "type": "integer"
       },
        "unique_session_id" :
       "unique_session_id": {
         "$ref": "definitions.json#/unique_session_id"
       }
     },
     "type": "object"
   }

C.3.7.  MX Capability Ack Acknowledge

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "definitions": {},
     "id": "http://www.ietf.org/mams/mx_capability_ack.json", "https://example.com/mams/mx_capability_ack.json",
     "properties": {
                "message_type" :
        "message_type": {"$ref": "mx_base_def.json#/message_type_def"},
                "sequence_num" :
        "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
                "version" :
        "version": {"$ref": "mx_base_def.json#/version_def"},
                "unique_session_id" :
        "unique_session_id": {
          "$ref": "definitions.json#/unique_session_id" }, "definitions.json#/unique_session_id"},
        "capability_ack": {"$ref" : "definitions.json#/capability_acknowledgement"} {
          "$ref": "definitions.json#/capability_acknowledgment"}
     },
     "type": "object"
   }

C.3.8.  MX Reconfiguration Request

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "definitions": {},
     "id": "http://www.ietf.org/mams/mx_reconf_req.json", "https://example.com/mams/mx_reconf_req.json",
     "properties": {
        "message_type" :
       "message_type": {"$ref": "mx_base_def.json#/message_type_def"},
        "sequence_num" : "mx_base_def.json#/message_type_def"},
       "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
        "version" :
       "version": {"$ref": "mx_base_def.json#/version_def"},
        "unique_session_id" :
       "unique_session_id": {
         "$ref": "definitions.json#/unique_session_id"
       },
        "connection_id" : {"$ref" : "definitions.json#/connection_id" },
       "connection_id": {"$ref": "definitions.json#/connection_id"},
       "ip_address": {"$ref" : "definitions.json#/ip_address" }, {"$ref": "definitions.json#/ip_address"},
       "mtu_size": {
          "maximum" :
         "maximum": 65535,
         "minimum": 1,
         "type": "integer"
       },
        "ssid" :
       "ssid": {
         "type" :
         "type": "string"
       },
       "reconf_action": {
         "enum": [
           "release",
           "setup",
           "update"
         ],
         "id": "/properties/reconf_action",
         "type": "string"
       },
        "connection_status" : {"$ref" :
       "connection_status": {
          "$ref": "definitions.json#/connection_status"},
        "delivery_node_id" : {"$ref":
       "delivery_node_id": {
          "$ref": "definitions.json#/delivery_node_id"}
     },
     "type": "object"
   }

C.3.9.  MX Reconfiguration Response

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "definitions": {},
     "id": "http://www.ietf.org/mams/mx_reconf_rsp.json", "https://example.com/mams/mx_reconf_rsp.json",
     "properties": {
    "message_type" :
       "message_type": {"$ref": "mx_base_def.json#/message_type_def"},
        "sequence_num" :
       "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
        "version" :
       "version": {"$ref": "mx_base_def.json#/version_def"}
     },
     "type": "object"
   }

C.3.10.  MX UP Setup Configuration Request

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "additionalProperties": false,
     "definitions": {
   "convergence_configuration" :
       "convergence_configuration": {
         "mx_configuration_id": { "type" : {"type": "integer"},
         "convergence_method": { "$ref" : "definitions.json#/conv_method" },
           "$ref": "definitions.json#/conv_method"},
         "convergence_method_params": {
           "properties": {
             "proxy_ip": { "$ref" : "definitions.json#/ip_address" }, {"$ref": "definitions.json#/ip_address"},
             "proxy_port": {"$ref" : "definitions.json#/port" }, {"$ref": "definitions.json#/port"},
             "client_key": {"$ref" : "definitions.json#/client_key" } {"$ref": "definitions.json#/client_key"}
           },
           "type": "object"
         },
         "num_delivery_connections": {
           "type": "integer"
         },
         "delivery_connections": {
            "items":{ "$ref" : "definitions.json#/delivery_connection" },
           "items": {"$ref": "definitions.json#/delivery_connection"},
           "type": "array"
         }
       }
     },
     "id": "http://www.ietf.org/mams/mx_up_setup_conf_req.json", "https://example.com/mams/mx_up_setup_conf_req.json",
     "properties": {
        "message_type" :
       "message_type": {"$ref": "mx_base_def.json#/message_type_def"},
        "sequence_num" :
       "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
        "version" :
       "version": {"$ref": "mx_base_def.json#/version_def"},
       "num_anchor_connections": {
         "type": "integer"
       },
       "anchor_connections": {
         "items": {
           "properties": {
             "connection_id": { "$ref" : "definitions.json#/connection_id" },
               "$ref": "definitions.json#/connection_id"},
             "connection_type": { "$ref" : "definitions.json#/connection_type" },
                  "num_active_mx_conf" :
               "$ref": "definitions.json#/connection_type"},
             "num_active_mx_conf": {"type": "integer"},
             "convergence_config": { "type" : "integer" },
                  "convergence_config" :
               "items": {
                        "items":{ "$ref" : "definitions/convergence_configuration" },
                        "type" :
                 "$ref": "definitions/convergence_configuration"},
               "type": "array"
             }
           },
           "type": "object"
         },
         "type": "array"
       }
     },
     "type": "object"
   }

C.3.11.  MX UP Setup Confirmation

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "definitions": {},
     "id": "http://www.ietf.org/mams/mx_up_setup_cnf.json", "https://example.com/mams/mx_up_setup_cnf.json",
     "properties": {
    "message_type" :
       "message_type": {"$ref": "mx_base_def.json#/message_type_def"},
        "sequence_num" :
       "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
        "version" :
       "version": {"$ref": "mx_base_def.json#/version_def"},
        "unique_session_id" : { "$ref": "definitions.json#/unique_session_id" },
        "probe_param" :
       "unique_session_id": {
         "$ref": "definitions.json#/probe_param" },
        "num_delivery_conn" : "definitions.json#/unique_session_id"},
       "probe_param": {"$ref": "definitions.json#/probe_param"},
       "num_delivery_conn": {
                "type" :
         "type": "integer"
       },
        "client_params" :
       "client_params": {
                "type" :
         "type": "array",
                "items" :
         "items": [
           {"$ref": "definitions.json#/client_param"}
         ]
       }
     },
     "type": "object"
   }

C.3.12.  MX Traffic Steering Request

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "definitions": {
        "conn_list" : {
                "items" :
       "conn_list": { "$ref" : "definitions.json#/connection_id" },
         "items": {"$ref": "definitions.json#/connection_id"},
         "type": "array"
       },
        "ul_delivery" :
       "ul_delivery": {
                "ul_tft" :
         "ul_tft": { "$ref" :
           "$ref": "definitions.json#/traffic_flow_template"},
                "connection_list" : { "$ref" : "#definitions/conn_list" }
         "connection_list": {"$ref": "#definitions/conn_list"}
       }
     },
     "id": "http://www.ietf.org/mams/mx_traffic_steering_req.json", "https://example.com/mams/mx_traffic_steering_req.json",
     "properties": {
        "message_type" :
       "message_type": {"$ref": "mx_base_def.json#/message_type_def"},
        "sequence_num" :
       "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
        "version" :
       "version": {"$ref": "mx_base_def.json#/version_def"},
       "connection_id": {"$ref" : "definitions.json#/connection_id" }, {"$ref": "definitions.json#/connection_id"},
       "mx_configuration_id": { "type" : {"type": "integer"},
       "downlink_delivery": {
         "items": { "$ref" : "definitions.json#/connection_id" }, {"$ref": "definitions.json#/connection_id"},
         "type": "array"
       },
    "feature_activation":
       "feature_active": {
         "items": {"$ref" : "definitions.json#/feature_status" }, {"$ref": "definitions.json#/feature_status"},
         "type": "array"
       },
       "default_uplink_delivery": {
         "type": "integer"
       },
       "uplink_delivery": {
         "items": { "$ref" : "#definitions/ul_delivery" }, {"$ref": "#definitions/ul_delivery"},
         "type": "array"
       }
     },
     "type": "object"
   }

C.3.13.  MX Traffic Steering Response

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "definitions": {},
     "id": "http://example.com/example.json", "https://example.com/example.json",
     "properties": {
    "message_type" :
       "message_type": {"$ref": "mx_base_def.json#/message_type_def"},
        "sequence_num" :
       "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
        "version" :
       "version": {"$ref": "mx_base_def.json#/version_def"},
        "unique_session_id" :
       "unique_session_id": {
         "$ref": "definitions.json#/unique_session_id" },
        "feature_activation": "definitions.json#/unique_session_id"},
       "feature_active": {
         "items": {"$ref" : "definitions.json#/feature_status" }, {"$ref": "definitions.json#/feature_status"},
         "type": "array"
       }
     },
     "type": "object"
   }

C.3.14.  MX Application MADP Association Request

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "definitions": {},
     "id": "http://example.com/example.json", "https://example.com/example.json",
     "properties": {
       "message_type": {
                        "$ref": "mx_base_def.json#/message_type_def"
                }, {"$ref": "mx_base_def.json#/message_type_def"},
       "sequence_num": {
                        "$ref": "mx_base_def.json#/sequence_num_def"
                }, {"$ref": "mx_base_def.json#/sequence_num_def"},
       "version": {
                        "$ref": "mx_base_def.json#/version_def"
                }, {"$ref": "mx_base_def.json#/version_def"},
       "unique_session_id": {
         "$ref": "definitions.json#/unique_session_id"
                }, "definitions.json#/unique_session_id"},
       "app_madp_assoc_list": {
         "items": {
           "$ref": "definitions.json#/app_madp_assoc"
          },
         "type": "array"
       }
     },
     "type": "object"
   }

C.3.15.  MX Application MADP Association Response

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "definitions": {},
     "id": "http://example.com/example.json", "https://example.com/example.json",
     "properties": {
       "message_type": {
                           "$ref": "mx_base_def.json#/message_type_def"
                   }, {"$ref": "mx_base_def.json#/message_type_def"},
       "sequence_num": {
                           "$ref": "mx_base_def.json#/sequence_num_def"
                   }, {"$ref": "mx_base_def.json#/sequence_num_def"},
       "version": {
                           "$ref": "mx_base_def.json#/version_def"
                   }, {"$ref": "mx_base_def.json#/version_def"},
       "unique_session_id": {
                           "$ref": "definitions.json#/unique_session_id"
                   },
         "$ref": "definitions.json#/unique_session_id"},
       "is_success": {
         "type": "boolean"
       }
     },
     "type": "object"
   }

C.3.16.  MX Path Estimation Request

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "definitions": {},
     "id": "http://www.ietf.org/mams/mx_path_est_req.json", "https://example.com/mams/mx_path_est_req.json",
     "properties": {
        "message_type" :
       "message_type": {"$ref": "mx_base_def.json#/message_type_def"},
        "sequence_num" :
       "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
        "version" :
       "version": {"$ref": "mx_base_def.json#/version_def"},
       "active_probe_ack_req": {
         "enum": [
           "no",
           "yes"
         ],
         "type": "string"
       },
       "active_probe_freq_ms": {
          "maximum" :
         "maximum": 10000,
         "minimum": 100,
         "type": "integer"
       },
       "active_probe_size_bytes": {
         "maximum": 1500,
         "minimum": 100,
         "type": "integer"
       },
        "active_probe_duration_sec" :
       "active_probe_duration_sec": {
          "maximum" :
         "maximum": 100,
          "minimum" :
         "minimum": 10,
          "type" :
         "type":  "integer"
           },
       "connection_id": { "$ref" : "definitions#/connection_id" }, {"$ref": "definitions#/connection_id"},
       "init_probe_ack_req": {
         "enum": [
           "no",
           "yes"
         ],
         "type": "string"
       },
       "init_probe_size_bytes": {
         "maximum": 1500,
         "minimum": 100,
         "type": "integer"
       },
       "init_probe_test_duration_ms": {
         "maximum": 10000,
         "minimum": 100,
         "type": "integer"
       },
       "init_probe_test_rate_Mbps": {
         "maximum": 100,
         "minimum": 1,
         "type": "integer"
       }
     },
     "type": "object"
   }

C.3.17.  MX Path Estimation Report Results

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "definitions": {},
     "id": "http://www.ietf.org/mams/mx_path_est_results.json", "https://example.com/mams/mx_path_est_results.json",
     "properties": {
        "message_type" :
       "message_type": {"$ref": "mx_base_def.json#/message_type_def"},
        "sequence_num" :
       "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
        "version" :
       "version": {"$ref": "mx_base_def.json#/version_def"},
        "unique_session_id" :
       "unique_session_id": {
                 "$ref": "definitions.json#/unique_session_id" }, "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" }, {"$ref": "definitions.json#/connection_id"},
       "init_probe_results": {
         "properties": {
           "lost_probes_percentage": {
             "maximum": 100,
             "minimum": 1,
             "type": "integer"
           },
          "probe_rate_Mbps": {
             "maximum": 100,
             "minimum": 1,
             "type": "number"
           }
         },
         "type": "object"
       }
     },
     "type": "object"
   }

C.3.18.  MX SSID Indication

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "definitions": {},
     "id": "http://www.ietf.org/mams/mx_ssid_indication.json", "https://example.com/mams/mx_ssid_indication.json",
     "properties": {
                "message_type" :
       "message_type": {"$ref": "mx_base_def.json#/message_type_def"},
                "sequence_num" :
       "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
                "version" :
       "version": {"$ref": "mx_base_def.json#/version_def"},
       "ssid_list": {
         "items": {
                                "properties" :
           "properties": {
             "ssid_type": { "$ref" : "definitions.json#/ssid_types" },
                                        "ssid_id" :
               "$ref": "definitions.json#/ssid_types"},
             "ssid_id": {
                                                "type" :
               "type": "integer"
               }
             }
         },
         "type": "array"
       }
     },
     "type": "object"
   }

C.3.19.  MX Measurements Measurement Configuration

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "additionalProperties": false,
  "definitions" :
     "definitions": {
        "meas_conf" :
       "meas_conf": {
         "connection_id" : { "$ref" : "definitions.json#/connection_id" },
                "connection_type" :
           "$ref": "definitions.json#/connection_id"},
         "connection_type": { "$ref" : "definitions.json#/connection_type" },
                "meas_rep_conf" :
           "$ref": "definitions.json#/connection_type"},
         "meas_rep_conf": {
                        "items" :
           "items": { "$ref" : "definitions.json#/meas_report_conf" },
                        "type" :
             "$ref": "definitions.json#/meas_report_conf"},
           "type": "array"
         }
       }
     },
     "id": "http://www.ietf.org/mams/mx_measurement_conf.json", "https://example.com/mams/mx_measurement_conf.json",
     "properties": {
    "message_type" :
       "message_type": {"$ref": "mx_base_def.json#/message_type_def"},
        "sequence_num" :
       "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
        "version" :
       "version": {"$ref": "mx_base_def.json#/version_def"},
        "measurement_configuration" :
       "measurement_configuration": {
                "items" : {"$ref" : "#definitions/meas_conf" },
                "type" :
         "items": {"$ref": "#definitions/meas_conf"},
         "type": "array"
       }
     },
     "type": "object"
   }

C.3.20.  MX Measurements Measurement Report

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "definitions": {},
     "id": "http://www.ietf.org/mams/mx_measurement_report.json", "https://example.com/mams/mx_measurement_report.json",
     "properties": {
                "message_type" :
       "message_type": {"$ref": "mx_base_def.json#/message_type_def"},
                "sequence_num" :
       "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
                "version" :
       "version": {"$ref": "mx_base_def.json#/version_def"},
                "unique_session_id" :
       "unique_session_id": {
         "$ref": "definitions.json#/unique_session_id" },
        "measurment_reports": "definitions.json#/unique_session_id"},
       "measurement_reports": {
         "items": {
           "properties": {
             "connection_id": {
                        "$ref" : "definitions.json#/connection_id"
                    },
                                        "connection_type" :
               "$ref": "definitions.json#/connection_id"},
             "connection_type": {
                                                "$ref" : "definitions.json#/connection_type"
                                        },
                                        "delivery_node_id" :
               "$ref": "definitions.json#/connection_type"},
             "delivery_node_id": {
                                                "$ref" : "definitions.json#/delivery_node_id"
                                        },
               "$ref": "definitions.json#/delivery_node_id"},
             "measurements": {
               "items": {
                 "properties": {
                   "measurement_type": {
                                  "$ref" : "definitions.json#/meas_report_param"
                                },
                     "$ref": "definitions.json#/meas_report_param"},
                   "measurement_value": {
                     "type": "integer"
                   }
                 },
                 "type": "object"
               },
               "type": "array"
             }
           },
           "type": "object"
         },
         "type": "array"
       }
     },
     "type": "object"
   }

C.3.21.  MX Keep Alive Keep-Alive Request

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "additionalProperties": false,
     "id": "http://www.ietf.org/mams/mx_keep_alive_req.json", "https://example.com/mams/mx_keep_alive_req.json",
     "properties": {
    "message_type" :
       "message_type": {"$ref": "mx_base_def.json#/message_type_def"},
        "sequence_num" :
       "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
        "version" :
       "version": {"$ref": "mx_base_def.json#/version_def"},
        "keep_alive_reason" : {"$ref":
       "keep_alive_reason": {
         "$ref": "definitions.json#/keep_alive_reason"},
        "unique_session_id" : {"$ref":
       "unique_session_id": {
         "$ref": "definitions.json#/unique_session_id"},
        "connection_id" : {"$ref":
       "connection_id": {
         "$ref": "definitions.json#/connection_id"},
        "delivery_node_id" : {"$ref":
       "delivery_node_id": {
         "$ref": "definitions.json#/connection_id"}
     },
     "type": "object"
   }

C.3.22.  MX Keep Alive Keep-Alive Response

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "additionalProperties": false,
     "id": "http://www.ietf.org/mams/mx_keep_alive_rsp.json", "https://example.com/mams/mx_keep_alive_rsp.json",
     "properties": {
    "message_type" :
       "message_type": {"$ref": "mx_base_def.json#/message_type_def"},
        "sequence_num" :
       "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
        "version" :
       "version": {"$ref": "mx_base_def.json#/version_def"},
        "unique_session_id" : {"$ref":
       "unique_session_id": {
         "$ref": "definitions.json#/unique_session_id"}
     },
     "type": "object"
   }

C.3.23.  MX Session Termination Request

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "additionalProperties": false,
     "id": "http://www.ietf.org/mams/mx_keep_alive_req.json", "https://example.com/mams/mx_keep_alive_req.json",
     "properties": {
    "message_type" :
       "message_type": {"$ref": "mx_base_def.json#/message_type_def"},
        "sequence_num" :
       "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
        "version" :
       "version": {"$ref": "mx_base_def.json#/version_def"},
        "unique_session_id" :
       "unique_session_id": {
         "$ref": "definitions.json#/unique_session_id" },
        "reason" : "definitions.json#/unique_session_id"},
       "reason": {
                "enum" :
         "enum": [
           "MX_NORMAL_RELEASE",
           "MX_NO_RESPONSE",
           "INTERNAL_ERROR"
         ],
           "type" :
         "type": "string"
       }
     },
     "type": "object"
   }

C.3.24.  MX Session Termination Response

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "additionalProperties": false,
     "id": "http://www.ietf.org/mams/mx_session_termination_resp.json", "https://example.com/mams/mx_session_termination_rsp.json",
     "properties": {
    "message_type" :
       "message_type": {"$ref": "mx_base_def.json#/message_type_def"},
        "sequence_num" :
       "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
        "version" :
       "version": {"$ref": "mx_base_def.json#/version_def"},
        "unique_session_id" :
       "unique_session_id": {
         "$ref": "definitions.json#/unique_session_id" } "definitions.json#/unique_session_id"}
     },
     "type": "object"
   }

C.3.25.  MX Network Analytics Request

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "additionalProperties": false,
     "id": "http://www.ietf.org/mams/mx_network_analytics_req.json", "https://example.com/mams/mx_network_analytics_req.json",
     "properties": {
    "message_type" :
       "message_type": {"$ref": "mx_base_def.json#/message_type_def"},
        "sequence_num" :
       "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
        "version" :
       "version": {"$ref": "mx_base_def.json#/version_def"},
        "unique_session_id" :
       "unique_session_id": {
         "$ref": "definitions.json#/unique_session_id" },
        "params" : "definitions.json#/unique_session_id"},
       "params": {
                "items" : {"$ref":
         "items": {
           "$ref": "definitions.json#/predict_param_name"},
                "type" :
         "type": "array"
       }
     },
     "type": "object"
   }

C.3.26.  MX Network Analytics Response

   {
     "$schema": "http://json-schema.org/draft-04/schema#", "https://json-schema.org/draft-04/schema#",
     "additionalProperties": false,
  "definitions" : {
   "ParamPredictions" :
     "definitions": {
    "param_name" : {"$ref" : "definitions.json#/predict_param_name"},
        "additional_param" : {"$ref" : "definitions.json#/predict_add_param_name"},
        "prediction" :
       "ParamPredictions": { "type" : "integer" },
        "likelihood" :
         "param_name": { "type" : "integer" },
 "validity_time" :
           "$ref": "definitions.json#/predict_param_name"},
         "additional_param": { "type" : "integer" }
           "$ref": "definitions.json#/predict_add_param_name"},
         "prediction": {"type": "integer"},
         "likelihood": {"type": "integer"},
         "validity_time": {"type": "integer"}

       },
   "MXAnalyticsList" :
       "MXAnalyticsList": {
                "connection_id" :
         "connection_id": { "$ref" : "definitions.json#/connection_id" },
                "connection_type" :
           "$ref": "definitions.json#/connection_id"},
         "connection_type": { "$ref" : "definitions.json#/connection_type" },
                "predictions " :
           "$ref": "definitions.json#/connection_type"},
         "predictions": {
                        "items" :
           "items": { "$ref" : "#definitions/ParamPredictions" },
                        "type" :
             "$ref": "#definitions/ParamPredictions"},
             "type": "array"
         }
       }
     },
     "id": "http://www.ietf.org/mams/mx_network_analytics_resp.json", "https://example.com/mams/mx_network_analytics_rsp.json",
     "properties": {
    "message_type" :
       "message_type": {"$ref": "mx_base_def.json#/message_type_def"},
        "sequence_num" :
       "sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
        "version" :
       "version": {"$ref": "mx_base_def.json#/version_def"},
        "param_list" :
       "param_list": {
                                "items" : {"$ref":
         "items": {
           "$ref": "#definitions/MXAnalyticsList"},
                                "type" :
           "type": "array"}
     },
     "type": "object"
   }

C.4.  Examples in JSON

C.4.1.  MX Discover

   {
     "version" : "1.0",
     "message_type" : "mx_discover",
     "sequence_num" : 1
   }

C.4.2.  MX System Update Info

   {
     "version" : "1.0",
     "message_type" : "mx_system_info",
     "sequence_num" : 2,
     "ncm_connections" : [
       {
         "connection_id" : 0,
         "connection_type" : "lte", "LTE",
         "ncm_end_point" : {
           "ip_address" : "192.168.1.10",
           "port" : 1234
         }
       },
       {
         "connection_id" : 1,
         "connection_type" : "wifi", "Wi-Fi",
         "ncm_end_point" : {
           "ip_address" : "192.168.1.10",
           "port" : 1234
         }
       }
     ]
   }

C.4.3.  MX Capability Request

   {
     "version" : "1.0",
     "message_type" : "mx_capability_req",
     "sequence_num" : 3,
     "feature_active" : [
       {
         "feature_name" : "lossless_switching",
         "active" : true
       },
       {
         "feature_name" : "fragmentation",
         "active" : false
       }
     ],
     "num_anchor_connections" : 2,
     "anchor_connections" : [
       {
         "connection_id" : 0,
         "connection_type" : "lte" "LTE"
       },
       {
         "connection_id" : 1,
         "connection_type" : "wifi" "Wi-Fi"
       }
     ],
     "num_delivery_connections" : 2,
     "delivery_connections" : [
       {
         "connection_id" : 0,
         "connection_type" : "lte" "LTE"
       },
       {
         "connection_id" : 1,
         "connection_type" : "wifi" "Wi-Fi"
       }
     ],
     "convergence_methods" : [
       {
         "method" : "GMA",
         "supported" : true
       },
       {
         "method" : "MPTCP_Proxy",
         "supported" : false
       }
     ],
     "adaptation_methods" : [
       {
         "method" : "UDP_without_DTLS",
         "supported" : false
       },
       {
         "method" : "UDP_with_TLS", "UDP_with_DTLS",
         "supported" : false
       },
       {
         "method" : "IPSec", "IPsec",
         "supported" : true
       },
       {
         "method" : "Client_NAT",
         "supported" : false
       }
     ]
   }

C.4.4.  MX Capability Response

   {
     "version" : "1.0",
     "message_type" : "mx_capability_resp", "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" "LTE"
       },
       {
         "connection_id" : 1,
         "connection_type" : "wifi" "Wi-Fi"
       }
     ],
     "num_delivery_connections" : 2,
     "delivery_connections" : [
       {
         "connection_id" : 0,
         "connection_type" : "lte" "LTE"
       },
       {
         "connection_id" : 1,
         "connection_type" : "wifi" "Wi-Fi"
       }
     ],
     "convergence_methods" : [
       {
         "method" : "GMA",
         "supported" : true
       },
       {
         "method" : "MPTCP_Proxy",
         "supported" : false
       }
     ],
     "adaptation_methods" : [
       {
         "method" : "UDP_without_DTLS",
         "supported" : false
       },
       {
         "method" : "UDP_with_TLS", "UDP_with_DTLS",
         "supported" : false
       },
       {
         "method" : "IPSec", "IPsec",
         "supported" : true
       },
       {
         "method" : "Client_NAT",
         "supported" : false
       }
     ],
     "unique_session_id" : {
       "ncm_id" : 110,
       "session_id" : 1111
     }
   }

C.4.5.  MX Capability Ack Acknowledge

   {
     "version" : "1.0",
     "message_type" : "mx_capability_ack",
     "sequence_num" : 3,
     "unique_session_id" : {
       "ncm_id" : 110,
       "session_id" : 1111
     },
     "capability_ack" : "MX ACCEPT" "MX_ACCEPT"
   }

C.4.6.  MX Reconfiguration Request

   {
     "version" : "1.0",
     "message_type" : "mx_reconf_req",
     "sequence_num" : 4,
     "unique_session_id" : {
       "ncm_id" : 110,
       "session_id" : 1111
     },
     "reconf_action" : "setup",
     "connection_id" : 0,
     "ip_address" : "192.168.110.1",
     "ssid" : "SSID_1",
     "mtu_size" : 1300,
     "connection_status" : "connected",
     "delivery_node_id" : "2A12C"
   }

C.4.7.  MX Reconfiguration Response

   {
     "version" : "1.0",
     "message_type" : "mx_reconf_rsp",
     "sequence_num" : 4
   }

C.4.8.  MX UP Setup Configuration Request

   {
     "version": "1.0",
     "message_type": "mx_up_setup_conf_req",
     "sequence_num": 5,
     "num_anchor_connections": 2,
     "anchor_connections": [{
       "connection_id": 1,
       "connection_type": "wifi", "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", "LTE",
           "adaptation_method": "UDP_without_DTLS",
           "adaptation_method_param": {
             "tunnel_ip_addr": "6.6.6.6",
             "tunnel_end_port": 9999,
             "mx_header_optimization": true
           }
         },
         {
           "connection_id": 1,
           "connection_type": "wifi" "Wi-Fi"
         }
         ]
       },
       {
         "mx_configuration_id" : 2,
         "convergence_method": "GMA",
         "convergence_method_params": {},
         "num_delivery_connections": 1,
         "delivery_connections": [{
           "connection_id": 0,
           "connection_type": "lte", "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", "LTE",
       "udp_port": 8888,
       "num_delivery_connections": 2,
       "delivery_connections": [{
         "connection_id": 0,
         "connection_type": "lte" "LTE"
       },
       {
         "connection_id": 1,
         "connection_type": "wifi", "Wi-Fi",
         "adaptation_method": "UDP_without_DTLS",
         "adaptation_method_param": {
           "tunnel_ip_addr": "192.168.3.3",
           "tunnel_end_port": "6000"
         }
       }
       ]
     }
     ]
   }

C.4.9.  MX UP Setup Confirmation

   {
     "version" : "1.0",
     "message_type" : "mx_up_setup_cnf",
     "sequence_num" : 5,
     "unique_session_id" : {
       "ncm_id" : 110,
       "session_id" : 1111
     },
     "probe_param" : {
       "probe_port" : 48700,
       "anchor_conn_id" : 0,
       "mx_configuration_id" : 1
     },
     "num_delivery_conn" : 2,
     "client_params" : [
       {
         "connection_id" : 0,
         "adapt_param" : {
           "udp_adapt_port" : 51000
         }
       },
       {
         "connection_id" : 1,
         "adapt_param" : {
           "udp_adapt_port" : 52000
         }
       }
     ]
   }

C.4.10.  MX Traffic Steering Request

   {
     "version" : "1.0",
     "message_type" : "mx_traffic_steering_req",
     "sequence_num" : 6,
     "connection_id" : 0,
     "mx_configuration_id" : 1,
     "downlink_delivery" : [
       {
         "connection_id" : 0
       },
       {
         "connection_id" : 1
       }
     ],
     "default_uplink_delivery" : 0,
     "uplink_delivery" : [
       {
         "ul_tft" : {
            "remote_addr_mask" : "10.10.0.0/24",
            "local_addr_mask" : "192.168.0.0/24",
            "protocol_type" :  6,
                           "loca_port_range"
            "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_activation"
     "feature_active" : [
       {
         "feature_name" : "dl_aggregation",
         "active" : true
       },
       {
         "feature_name" : "ul_aggregation",
         "active" : false
       }
     ]
   }

C.4.11.  MX Traffic Steering Response

   {
     "version": "1.0",
     "message_type": "mx_traffic_steering_rsp",
     "sequence_num": 6,
     "unique_session_id": {
       "ncm_id": 110,
       "session_id": 1111
     },
           "feature_activation":
     "feature_active": [{
       "feature_name": "lossless_switching",
       "active": true
     },
     {
       "feature_name": "fragmentation",
       "active": false
     }
     ]
   }

C.4.12.  MX Application MADP Association Request

   {
     "version": "1.0",
     "message_type": "mx_app_madp_assoc_req",
     "sequence_num": 6,
     "unique_session_id": {
       "ncm_id": 110,
       "session_id": 1111
     },
     "app_madp_assoc_list": [{
       "connection_id" : 0,
       "mx_configuration_id" : 1,
       "ul_tft_list": [{
         "protocol_type": 17,
         "local_port_range": {
           "start": 8888,
           "end": 8888
         }
         }],
           "dl_tft_list": [{
             "protocol_type": 17,
             "remote_port_range": {
               "start": 8888,
               "end": 8888
             }
           }]
     }
     ]
   }

C.4.13.  MX Application MADP Association Response

   {
     "version": "1.0",
     "message_type": "mx_app_madp_assoc_resp", "mx_app_madp_assoc_rsp",
     "sequence_num": 6,
     "is_success": true
   }

C.4.14.  MX Path Estimation Request

   {
     "version" : "1.0",
     "message_type" : "mx_path_est_req",
     "sequence_num" : 7,
     "connection_id" : 0,
     "init_probe_test_duration_ms" : 100,
     "init_probe_test_rate_Mbps" : 10,
     "init_probe_size_bytes" : 1000,
     "init_probe_ack_req" : "yes",
     "active_probe_freq_ms" : 10000,
     "active_probe_size_bytes" : 1000,
     "active_probe_duration_sec" : 10,
     "active_probe_ack_req" : "no"
   }

C.4.15.  MX Path Estimation Results

   {
     "version" : "1.0",
     "message_type" : "mx_path_est_results",
     "sequence_num" : 8,
     "unique_session_id" : {
       "ncm_id" : 110,
       "session_id" : 1111
     },
     "connection_id" : 0,
     "init_probe_results" : {
       "lost_probes_percentage" : 1,
       "probe_rate_Mbps" : 9.9
     },
     "active_probe_results" : {
       "avg_tput_last_probe_duration_Mbps" : 9.8
     }
   }

C.4.16.  MX SSID Indication

   {
     "version" : "1.0",
     "message_type" : "mx_ssid_indication",
     "sequence_num" : 9,
     "ssid_list" : [
       {
         "ssid_type" : "ssid",
         "ssid_id" : "SSID_1"
       },
       {
         "ssid_type" : "bssid",
         "ssid_id" : "xxx-yyy"
       }
     ]
   }

C.4.17.  MX Measurements Measurement Configuration

   {
     "version" : "1.0",
     "message_type" : "mx_measurement_conf",
     "sequence_num" : 10,
     "measurement_configuration" : [
     {
       "connection_id" : 0,
       "connection_type" : "wi-fi", "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", "LTE",
       "meas_rep_conf"  : [
         {
           "meas_rep_param" : "LTE_RSRP",
           "meas_threshold" : {
             "high" : -10,
             "low" : -15
           },
           "meas_period_ms" : 500
         },
         {
           "meas_rep_param" : "LTE_RSRQ",
           "meas_threshold" : {
             "high" : -10,
             "low" : -15
           },
           "meas_period_ms" : 500
         }
       ]
     }
     ]
   }

C.4.18.  MX Measurements Measurement Report

   {
     "version" : "1.0",
     "message_type" : "mx_measurement_report",
     "sequence_num" : 11,
     "unique_session_id" : {
       "ncm_id" : 110,
       "session_id" : 1111
     },
           "measurment_reports"
     "measurement_reports" : [
       {
         "connection_id" : 0,
         "connection_type" : "wi-fi", "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", "LTE",
         "delivery_node_id" : "12323",
         "measurements"  : [
           {
             "measurement_type" : "LTE_RSRP",
             "measurement_value" : -12

            },
            {
              "measurement_type" : "LTE_RSRQ",
              "measurement_value" : -12

            }
         ]
       }
     ]
   }

C.4.19.  MX Keep Alive Keep-Alive Request

   {
     "version" : "1.0",
     "message_type" : "mx_keep_alive_req",
     "sequence_num" : 12,
     "keep_alive_reason" : "Handover",
     "unique_session_id" : {
       "ncm_id" : 110,
       "session_id" : 1111
     },
     "connection_id" : 0,
     "delivery_node_id" : "2021A"
   }

C.4.20.  MX Keep Alive Keep-Alive Response

   {
     "version" : "1.0",
     "message_type" : "mx_keep_alive_rsp",
     "sequence_num" : 12,
     "unique_session_id" : {
       "ncm_id" : 110,
       "session_id" : 1111
     }
   }

C.4.21.  MX Session Termination Request

   {
     "version" : "1.0",
     "message_type" : "mx_session_termination_req",
     "sequence_num" : 13,
     "unique_session_id" : {
       "ncm_id" : 110,
       "session_id" : 1111
     },
     "reason" : "MX_NORMAL_RELEASE"
   }

C.4.22.  MX Session Termination Response

   {
     "version" : "1.0",
     "message_type" : "mx_session_termination_resp", "mx_session_termination_rsp",
     "sequence_num" : 13,
     "unique_session_id" : {
       "ncm_id" : 110,
       "session_id" : 1111
     }
   }

C.4.23.  MX Network Analytics Request

   {
     "version" : "1.0",
     "message_type" : "mx_network_analytics_req",
     "sequence_num" : 20,
     "unique_session_id" : {
       "ncm_id" : 110,
       "session_id" : 1111
     },
        "parmas"
     "params" : [
       "jitter",
       "latency"
     ]
   }

C.4.24.  MX Network Analytics Response

   {
     "version": "1.0",
     "message_type": "mx_network_analytics_resp", "mx_network_analytics_rsp",
     "sequence_num": 20,
     "param_list": [{
       "connection_id": 1,
       "connection_type": "wifi", "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", "LTE",
       "predictions": [{
         "param_name": "jitter",
         "prediction": 10,
         "likelihood": 80,
         "validity_time": 10
       },
       {
         "param_name": "latency",
         "prediction": 4,
         "likelihood": 60,
         "validity_time": 10
       }
       ]
     }
     ]
   }

Appendix D.  Definition of APIs provided Provided by the CCM to the Applications
             at the Client

   This section provides an example implementation of the APIs exposed
   by the CCM to the Applications applications on the client, documented with OpenAPI
   using Swagger 2.0.

   {
     "swagger": "2.0",
     "info": {
       "version": "1.0.0",
       "title": "Client Connection Manager (CCM)",
       "description": "API provided by the CCM towards Application 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 for 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 kind types of MAMS user specific 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",
        "multi-fire",
        "lte"
           "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",
           "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-rspq",
           "lte-rsrq",
           "nr-rsrp",
           "nr-rsrq",
           "wifi-rssi"
         ],
         "type": "string"
       },
       "link-parameter": {
         "type": "object",
         "properties": {
           "connection": {
             "$ref": "#/definitions/connection"
           },
           "param": {
             "$ref": "#/definitions/param-name"
           },
           "additional-param": {
             "$ref": "#/definitions/additional-param-name"
           },
           "prediction": {
             "type": "integer"
           },
           "likelihood": {
             "type": "integer"
           },
           "validity_time": {
             "type": "integer"
           }
         }
       },
       "link-params": {
         "type": "array",
         "items": {
           "$ref": "#/definitions/link-parameter"
         }
       },
       "errorModel": {
         "type": "object",
         "description": "Error indication containing the error code and
                         message.",
         "required": [
           "code",
           "message"
         ],
         "properties": {
           "code": {
             "type": "integer",
             "format": "int32"
           },
           "message": {
             "type": "string"
           }
         }
       }
     }
   }

Appendix E.  Implementation Example using Using Python for MAMS Client and
             Server

E.1.  Client Side  Client-Side Implementation

   A simple client side client-side implementation using python Python can be as following: follows:

   #!/usr/bin/env python
   import asyncio
   import websockets
   import json
   import ssl
   import time
   import sys

   context = ssl.SSLContext(ssl.PROTOCOL_TLS)
   context.verify_mode = ssl.CERT_REQUIRED
   context.set_ciphers("RSA")
   context.check_hostname = False
   context.load_verify_locations("/home/mecadmin/certs/rootca.pem")

   discoverMsg = {'version':'1.0',
   'message_type':'mx_discover'}

   MXCapabilityRes = { 'version':'1.0', {'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'}], 'connection_type':'LTE'}],
   'num_delivery_connections':1,
   'delivery_connections':[{'connection_id':1, 'connection_type':"wifi"}],
       '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("Recieved message:{}".format(message["message_type"]),"version:{}".format(message["version"]))
               print("Received message:{}".format(
                  message["message_type"]),
                  "version:{}".format(message["version"]))
               if message["message_type"] == "mx_capability_req" :
                   await websocket.send(json.dumps(MXCapabilityRes))
                   loopFlag=True
                   while(loopFlag==True):
                         pass
        except:
             print("Client stopped")

   asyncio.get_event_loop().run_until_complete(hello())

E.2.  Server Side  Server-Side Implementation

   A server client side server-side implementation using python Python can be as following: follows:

   #!/usr/bin/env python
   import asyncio
   import websockets
   import json
   import ssl

   ctx = ssl.SSLContext(ssl.PROTOCOL_TLS)
   #ctx.set_ciphers("RSA-AES256-SHA")
   ctx.load_verify_locations("/home/mecadmin/certs/rootca.pem")
   certfile = "/home/mecadmin/certs/server.pem"
   keyfile = "/home/mecadmin/certs/serverkey.pem"
   ctx.load_cert_chain(certfile, keyfile, password=None)

   MXCapabilityReq = { 'version':'1.0', {'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'}], 'connection_type':'LTE'}],
   'num_delivery_connections':1,
   'delivery_connections':[{'connection_id':1, 'connection_type':"wifi"}],
       '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("Recieved message:{}".format(msg["message_type"]),"version:{}".format(msg["version"]))
           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
         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
    print("Server stopped")

Acknowledgments

   This protocol is the outcome of work by many engineers, not just the
   authors of this document.  The people who contributed to this
   project, listed in alphabetical order by first name, are Barbara
   Orlandi, Bongho Kim, David Lopez-Perez, Doru Calin, Jonathan Ling,
   Lohith Nayak, and Michael Scharf.

Contributors

   The authors gratefully acknowledge the following additional
   contributors, in alphabetical order by first name: A Krishna Pramod/
   Nokia Bell Labs, Hannu Flinck/Nokia Bell Labs, Hema Pentakota/Nokia,
   Julius Mueller/AT&T, Nurit Sprecher/Nokia, Salil Agarwal/Nokia,
   Shuping Peng/Huawei, and Subramanian Vasudevan/Nokia Bell Labs.
   Subramanian Vasudevan has been instrumental in conceptualization and
   development of solution principles for the MAMS framework.  Shuping
   Peng has been a key contributor in refining the framework and
   control-plane protocol aspects.

Authors' Addresses

   Satish Kanugovi
   Nokia Bell Labs

   Email: satish.k@nokia.com satish.k@nokia-bell-labs.com

   Florin Baboescu
   Broadcom

   Email: florin.baboescu@broadcom.com

   Jing Zhu
   Intel

   Email: jing.z.zhu@intel.com

   Julius Mueller
   AT&T

   Email: jm169k@att.com

   SungHoon Seo
   Korea Telecom

   Email: sh.seo@kt.com