Movatterモバイル変換

<?xml<!DOCTYPE rfc SYSTEM<rfccategory="info"submissionType="independent"ipr="trust200902"  <front>    <title abbrev="MAMS">Multi&nbhy;Access Management Services (MAMS)</title>    <!-- [rfced] We see that the title of this document is"Multiple Access Management Services," but we also see"Multi Access Management Services (MAMS)" in Section 1 and"Multiple Access Management Services(MAMS)" in Section 5.We also see both forms used in draft-zhu-intarea-mams-user-protocol.We also see (for example) "MAMS leverages technologies ..."(Section 10) (where "MAMS" is used in the singular).(Please also note that draft-zhu-intarea-mams-user-protocol also usesboth the singular form "Management Service" and the plural form"Management Services.")Please let us know whether you prefer "Multiple Access" or"Multi Access."  If you prefer the latter, we suggesthyphenating it ("Multi-Access").Original: Multiple Access Management Services... Multi Access Management Services (MAMS) is a programmable framework... This document proposes the Multiple Access Management Services(MAMS)-->    <!-- [author1]Prefer using "Multi-Access". Changes done.Also changed: "MAMS leverages technologies ..." to "The MAMS framework leverages technologies ..."I.e., dodged the singular/plural issue.-->    <author fullname="Satish Kanugovi" initials="S." surname="Kanugovi">      <organization>Nokia Bell Labs</organization>      <address>        <postal>          <region/>        </postal>        <email>satish.k@nokia-bell-labs.com</email>      </address>    </author>    <!-- [author1] Updated Email Address and Affiliation per internal company re-organization -->    <author fullname="Florin Baboescu" initials="F." surname="Baboescu">      <organization>Broadcom</organization>      <address>        <postal>          <region/>          <code/>        </postal>        <email>florin.baboescu@broadcom.com</email>      </address>    </author>    <author fullname="Jing Zhu" initials="J." surname="Zhu">      <organization>Intel</organization>      <address>        <postal>          <region/>          <code/>        </postal>        <email>jing.z.zhu@intel.com</email>      </address>    </author>    <author fullname="Julius Mueller" initials="J." surname="Mueller">      <organization>AT&amp;T</organization>      <address>        <postal>          <region/>          <code/>        </postal>        <email>jm169k@att.com</email>      </address>    </author>    <author fullname="SungHoon Seo" initials="S." surname="Seo">      <organization>Korea Telecom</organization>      <address>        <postal>          <region/>          <code/>        </postal>        <email>sh.seo@kt.com</email>      </address>    </author>    <date year="2019"/>    <!-- [rfced-auth48] Please insert any keywords (beyond those that appear inthe title) for use on https://www.rfc-editor.org/search. -->    <keyword>Integration, Aggregation, Switching, MPTCP, MPQUIC, GMA, 5G, LTE, Wi-Fi, Ethernet, Edge, Proxy</keyword>    <!-- [rfced-auth48] The alignment of several figures in the originaldocument was bad (for example, the top portions of Figures 16 and 18,and the bottom portion of Figure 21)).The line lengths in several figures were too long as well (i.e.,greater than 72 characters; one was as long as 138 characters).We corrected the bad alignments and narrowed the figures that weretoo wide.  (For example, we found that in the figure inAppendix C.3.2 each indent level was 8 spaces; we changed the indentlevels to 4 spaces each.)Note:  Even after reducing the indent levels in the figure inAppendix C.3.2, we still had several lines that were too long for apublished RFC:  We broke these lines per other parts of the code(e.g., the "meas_report_conf" portion.Warning: Output line (from source around line 4344) is 74 characters; longerthan 72.  Excess characters: '},':  '            "remote_addr_mask" : { "$ref" : "#definitions/ip_addr_mask" },'Warning: Output line (from source around line 4345) is 74 characters; longerthan 72.  Excess characters: '},':  '            "local_addr_mask" : {  "$ref" : "#definitions/ip_addr_mask" },'Warning: Output line (from source around line 4351) is 73 characters; longerthan 72.  Excess characters: ',':  '            "local_port_range" : {  "$ref" : "#definitions/port_range" },'Warning: Output line (from source around line 4352) is 73 characters; longerthan 72.  Excess characters: ',':  '            "remote_port_range" : { "$ref" : "#definitions/port_range" },'Because of this issue, we suggest, at the very least, adding thefollowing text (perhaps to the beginning of Appendix C.3 of thisdocument), as was done in RFC 8620 ("The JSON Meta ApplicationProtocol (JMAP)"):   For compatibility with publishing requirements, line breaks have been   inserted inside long JSON strings, with the following continuation   lines indented.("the following continuation lines" appears to mean "continuation  lines that follow")If the following sentence is also applicable to this document(i.e., if an implementer would have to replace line breaks withspaces if using the code in Appendix C.3.2), we suggest includingthis sentence as well:   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.-->    <!-- [author1]: Thanks for the guidance. It may be more appropriate to add the text in the "Notation" section (section C.1.1).              Added both the lines in Section C.1.1.1.-->    <!-- [rfced-auth48]Please review all of the figures carefully, and let us know ifanything is incorrect.-->    <!-- [author 1]: OK. Thanks for the fixes.We have made a number of edits to the figures.-->    <abstract>      <t>In multiconnectivity scenarios, the end-user devices can   simultaneously connect to multiple networks based on different access   technologies and network architectures like Wi-Fi, LTE, and DSL.  Both the   quality of experience of the users and the overall network   utilization and efficiency may be improved through the smart   selection and combination of access and core network paths that can   dynamically adapt to changing network conditions.</t>      <t>This document presents a unified problem statement and introduces a   solution for managing multiconnectivity.  The solution has been   developed by the authors based on their experiences in multiple   standards bodies, including the IETF and the 3GPP.  However, this document   is not an Internet Standards Track specification, and it does not represent   the consensus opinion of the IETF.</t>      <t>This document describes requirements, solution principles, and the   architecture of the Multi&nbhy;Access Management Services (MAMS) framework.   The MAMS framework aims to provide best performance while being easy to implement   in a wide variety of multiconnectivity deployments.  It specifies the protocol for   (1) flexibly selecting the best combination of access and core network   paths for the uplink and downlink, and (2) determining the user-plane   treatment (e.g., tunneling, encryption) and traffic distribution over   the selected links, to ensure network efficiency and the best possible   application performance.</t>      <!-- [rfced] Abstract:  Please clarify the meaning of "the protocolmulti-access management"; are some words missing?Original: It specifies the protocol multi-access management to: 1) flexibly select the best combination of access and core network paths for uplink and downlink; as well as 2) determine the user plane treatment and traffic distribution over the selected links ensuring network efficiency and application performance.-->      <!-- [author1] Fixed.-->      <!-- [rfced] Abstract and subsequent.  We are not able to determinewhat "treatment" means in the context of this document.  Will thisterm be clear to readers?For example: It specifies the protocol multi-access management to: 1) flexibly select the best combination of access and core network paths for uplink and downlink; as well as 2) determine the user plane treatment and traffic distribution over the selected links ensuring network efficiency and application performance.... It leverages network intelligence and policies to dynamically adapt traffic distribution across selected paths and user plane treatment to changing network/link conditions.... "Network Connection manager"(NCM): A functional entity in the network that handles MAMS control messages from the client and configures distribution of data packets over the multiple available access and core network paths, and user plane treatment of the traffic flows. -->      <!-- [author1]User-plane treatment implies, the processing, to address aspects, specific to the network connection. E.g., encryption needed for transport over Wi-Fi, tunnelling needed to overcome NAT between client and multipath proxy.This has now been clarified in the abstract. And there is also some rework in the other sections that use "treatments", later.-->    </abstract>  </front>  <middle>    <section      <t>Multi-Access Management Services (MAMS) is a programmable framework that     provides mechanisms for the flexible selection of network paths in a     multi&nbhy;access communication environment, based on the needs.     The MAMS framework leverages network intelligence and policies to dynamically adapt traffic     distribution across selected paths and user&nbhy;plane treatments (e.g., encryption needed     for transport over Wi-Fi, or tunnelling 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&nbhy;plane data between the functional elements     in the network and the end&nbhy;user device, and thus without any impact on     the control&nbhy;plane signaling schemes of the underlying access networks.     For example, in a multi-access network with LTE and Wi&nbhy;Fi     technologies, existing LTE and Wi&nbhy;Fi signaling procedures will     be used to set up the LTE and Wi&nbhy;Fi connections, respectively, and     MAMS-specific control&nbhy;plane messages are carried as LTE or Wi&nbhy;Fi     user&nbhy;plane data.  The MAMS framework defined in this document provides the     capability to make a smart selection of a flexible combination of access paths and     core network paths, as well as to choose the user&nbhy;plane treatment when the traffic     is distributed across the selected paths.  Thus, it is a broad programmable     framework that provides functions beyond the simple sharing of network     policies such as those provided by the Access Network Discovery and Selection     Function (ANDSF) <xref which offers policies and rules for     assisting 3GPP devices to discover and select available access networks.     Further, it allows the choice and configuration of user&nbhy;plane treatment     for the traffic over the paths, depending on the needs.</t>      <t>The MAMS framework mechanisms are not dependent on any specific access     network types or user&nbhy;plane protocols (e.g., TCP, UDP, Generic Routing     Encapsulation (GRE) <xref <xref     Multipath TCP (MPTCP) <xref  The MAMS framework coexists and complements     the existing protocols by providing a way to negotiate and configure those     protocols to match their use to a given multi&nbhy;access scenario based on client     and network capabilities, and the specific needs of each access network path.     Further, the MAMS framework allows load balancing of the traffic flows across the selected     access network paths, and the exchange of network state information to be used for     network intelligence to optimize the performance of such protocols.</t>      <!-- [rfced] Section 1:  To what does "it" refer in these sentences -the MAMS mechanisms, or something else?-->      <!-- [author1]: It refers to "MAMS framework" - updated the text.Also, please clarify "capabilities per access basis."-->      <!-- [author1]: Rephrased for clarification: "... capabilities, and specific needs of each access network path,..."-->      <t>This document presents the requirements, solution principles,     functional architecture, and protocols for realizing the MAMS     framework.  An important goal for the MAMS framework is to ensure that it requires     either minimum dependency or (better) no dependency on the actual access     technologies of the participating links, beyond the fact that MAMS     functional elements form an IP overlay across the multiple paths.     This allows the scheme to be "future proof" by allowing independent     technology evolution of the existing access and core networks as well     as seamless integration of new access technologies.</t>      <t>The solution described in this document has been developed by the     authors, based on their experiences in multiple standards bodies,     including the IETF and the 3GPP.  However, this document is not an     Internet Standards Track specification, and it does not represent     the consensus opinion of the IETF.</t>    </section>    <section      <t>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     <xref <xref when,     and only when, they appear in all capitals, as shown here.</t> end-user device that supports connections with    multiple access nodes, possibly over different access client with multiple network segment in the network that delivers user    data packets to the client via an access link such as a Wi&nbhy;Fi airlink,    an LTE airlink, or functional element that anchors the client IP    address used for communication with applications via the Connection Manager functional entity in the    network that handles MAMS control messages from the client and configures    the distribution of data packets over the available access and core    network paths, and manages the user&nbhy;plane treatment (e.g., tunneling,    encryption) of the traffic Connection Manager functional entity in the    client that exchanges MAMS signaling messages with the NCM, and which configures    the network paths at the client for the transport of user Multi-Access Data Proxy functional entity    in the network that handles the forwarding of user data traffic across    multiple network paths.  The N-MADP is responsible for MAMS&nbhy;related    user&nbhy;plane functionalities in the Multi-Access Data Proxy functional entity    in the client that handles the forwarding of user data traffic across    multiple network paths.  The C-MADP is responsible for MAMS&nbhy;related    user&nbhy;plane functionalities in the to the network path from the N-MADP    to the user&nbhy;plane gateway (IP anchor) that has assigned an IP address    to the to the network path from the    N-MADP to the (also referred to as in this to the direction of a connection    from a client toward the (also referred to as in this to the direction of a connection    from the network toward a    </section>    <section      <t>Typically, an end-user device has access to multiple communication     networks based on different technologies for accessing application services,     for example, LTE, Wi&nbhy;Fi, DSL, or MulteFire.  Different technologies     exhibit benefits and limitations in different scenarios.  For example,     Wi&nbhy;Fi provides high throughput for end users when their Wi&nbhy;Fi     coverage is good, but the throughput degrades significantly as a given user     moves closer to the edge of its of Wi&nbhy;Fi coverage area (typically in     the range of a few tens of meters) or if the user population is large (due     to a contention-based Wi&nbhy;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&nbhy;user scenarios, due to controlled scheduling and     licensed-spectrum usage.</t>      <t>Additionally, the use of a particular access network path is often     coupled with the use of its associated core network and the services that     are offered by that network.  For example, in an enterprise that has deployed both     Wi&nbhy;Fi and LTE networks, the enterprise services, such as printers and     corporate audio/video conferencing, are accessible only via Wi&nbhy;Fi     access connected to the enterprise-hosted (Wi&nbhy;Fi) core, whereas the     LTE access can be used to get operator services, including access to the     public Internet.</t>      <!-- [rfced] Section 3:  This sentence did not parse.  We updated itas listed below.  Please let us know if this is incorrect.Original: For example, in an enterprise that has deployed both WiFi and LTE networks, the enterprise services, like printers, Corporate Audio and Video conferencing, are accessible only via WiFi access connected to the enterprise hosted (WiFi) core, whereas the LTE access can be used to get operator core anchored services including access to public Internet.Currently: For example, in an enterprise that has deployed both Wi-Fi and LTE networks, the enterprise services, such as printers and corporate audio/video conferencing, are accessible only via Wi-Fi access connected to the enterprise-hosted (Wi-Fi) core, whereas the LTE access can be used to get core services anchored by the operator, including access to the public Internet. -->      <!-- [author1] Accepted the suggested changes with minor modifications -  "... the LTE access can be used to get operator services.." -->      <t>Thus, application performance in different scenarios becomes     dependent on the choice of access networks (e.g., Wi&nbhy;Fi, LTE) and     the network and transport protocols used (e.g., VPN, MPTCP, GRE).     Therefore, to achieve the best possible application performance in a wide     range of scenarios, a framework is needed that allows the selection and     flexible combination of access and core network paths as well as the     protocols used for uplink and downlink data delivery.</t>      <t>For example, in uncongested scenarios and when the Wi&nbhy;Fi     coverage is good, to ensure best performance for enterprise applications     at all times, it would be beneficial to use Wi&nbhy;Fi access for both     the uplink and downlink for connecting to enterprise applications.     However, in congested scenarios or when the user is getting close to     the edge of its Wi&nbhy;Fi coverage area, the use of Wi&nbhy;Fi in the     uplink by multiple users can lead to degraded capacity and increased delays     due to contention.  In this case, it would be beneficial to at least use     the LTE access for increased uplink coverage, while Wi&nbhy;Fi may still     continue to be used for the downlink.</t>    </section>    <section      <t>The requirements set out in this section define the behavior of the MAMS     mechanism and the related functional elements.</t>      <section        <t>The access nodes MAY use different technology types (LTE, Wi&nbhy;Fi, etc.).       The framework, however, MUST be agnostic about the type of underlying       technology used by the access network.</t>      </section>      <section for Common Transport        <t>The network path selection and user data distribution MUST work       transparently across various transport deployments that include       end&nbhy;to&nbhy;end IPsec, VPNs, and middleboxes like NATs and proxies.</t>      </section>      <section Access Path Selection for Uplink and        <t>A client SHOULD be able to transmit on the uplink and receive on the       downlink, using one or more access networks.  The selections of the access       paths for the uplink and downlink SHOULD happen independently.</t>      </section>      <section Selection Independent of Uplink and Downlink        <t>A client SHOULD flexibly select the core independently of the access paths       used to reach the core, depending on the needs, local policies,       and the result of MAMS control&nbhy;plane negotiation.</t>      </section>      <section Access Network Path        <t>The framework MUST have the ability to determine the       quality of each of the network paths, e.g., access link delay and       capacity.  This information regarding network path quality needs to be       considered in the logic for the selection of the combination of network       paths to be used for transporting user data.  The path selection algorithm       can use the information regarding network path quality, in addition to       other considerations like network policies, for optimizing network usage       and enhancing the Quality of Experience (QoE) delivered to the user.</t>      </section>      <section Support and Aggregation of Access Link        <t>The framework MUST support the distribution and aggregation of user data       across multiple network paths at the IP layer.  The client SHOULD be able to       leverage the combined capacity of the multiple network connections by       enabling the simultaneous transport of user data over multiple network       paths.  If required, packet reordering needs to be done at the receiver.  The       framework MUST allow the flexibility to choose the flow&nbhy;steering and       aggregation protocols based on capabilities supported by the client and the       network user&nbhy;plane entities.  The multiconnection aggregation solution       MUST support existing transport and network&nbhy;layer protocols like TCP,       UDP, and GRE.  The framework MUST allow the use and configuration of existing       aggregation protocols such as MPTCP and the Stream Control Transmission       Protocol (SCTP) <xref      </section>      <section Mechanism Based on User-Plane        <t>The framework MUST leverage commonly available transport, routing, and       tunneling capabilities to provide user&nbhy;plane interworking       functionality.  The addition of functional elements in the user&nbhy;plane       path between the client and the network MUST NOT impact the       access&nbhy;technology-specific procedures.<!-- [rfced-auth48] Authors and *[ISE]:  Sections 4.7 and 4.9:Should these instances of "MUST not" be "MUST NOT" or "must not"?Original: The addition of functional elements in the user plane path between the client and the network MUST not impact the access technology specific procedures.... The framework MUST not cause any packet loss beyond that of access network mobility functions may cause. --><!-- [author1]: changed to "MUST NOT"-->       This makes the solution easy to       deploy and scale when different networks are added and removed.</t>      </section>      <section Control-Plane and User-Plane        <t>The client MUST use the control-plane protocol to negotiate the       following with the network: (1) the choice of access and core       network paths for both the uplink and downlink, and (2) the       user&nbhy;plane protocol treatment.<!-- [rfced] Section 4.8:  We had trouble parsing this sentence.If the suggested text is not correct, please clarify what is beingnegotiated.Original: The client MUST use the control plane protocol to negotiate with the network, the choice of access and core network paths for both uplink and downlink, as well as the user plane protocol treatment.Suggested: The client MUST use the control-plane protocol to negotiate the following with the network: (1) the choice of access and core network paths for both the uplink and downlink and (2) the user-plane protocol treatment.--><!-- [author1]: Updated text per the Suggestion for clarity.-->       The control plane       MUST configure the actual user&nbhy;plane data distribution function per this       negotiation.  A common control protocol SHOULD allow the creation of multiple       user&nbhy;plane function instances with potentially different user&nbhy;plane       (e.g., tunneling) protocol types.  This enables maintaining a clear separation       between the control&nbhy;plane and user&nbhy;plane functions, allowing the       framework to be scalable and extensible, e.g., using Software Defined Networking (SDN)&nbhy;based       architectures and implementations.</t>        <!-- [rfced] Sections 4.8 and subsequent:  For ease of the reader,please let us know how the following terms should be expanded wherefirst used in this document: SDN (Section 4.8) MCC/MNC (Section 8.1) PDU (Figure 3) ECGI (Section 8.3.2) SSID (Section 8.5) CNF (Section 8.5) eNB (Section 8.6) BSSID/HESSID (Section 8.9) RSRP (Section 8.10) (e.g., "sending RSRP of") SA ("IPsec SAs") (Section 10) TFT (Figure 19 in Section 11)-->        <!-- [author1] Ok. Updated text with expansions where first used in text.-->        <!-- [rfced] UCM* (Appendix A)  * (Note:  We only see "UCM" used once in this document.     Should it be "CCM"?)-->        <!-- [author1] UCM is a typo - it should indeed be CCM. Fixed.-->        <!-- [rfced] Also, is the "UP" in "MX UP" an abbreviation for something?If so, what does it stand for?  (Perhaps "uplink," in which casemaybe "UL" could be used instead?)-->        <!-- [author1] UP is abbreviation for user-plane. Expanded at first occurence in Section 8.5.-->      </section>      <section Path (Connection)        <t>When switching data traffic from one path (connection) to another, packets       may be lost or delivered out of order; this will have negative impact on the       performance of higher&nbhy;layer protocols, e.g., TCP.  The framework SHOULD       provide the necessary mechanisms to ensure in&nbhy;order delivery at the       receiver, e.g., during path switching.  The framework MUST NOT cause any packet       loss beyond losses that access network mobility functions may cause.</t>      </section>      <section and Fragmentation for Adaptation to MTU        <t>Different network paths may have different security and middlebox       (e.g., NAT) configurations.  These configurations will lead to the use of       different tunneling protocols for the transport of data between the network       user&nbhy;plane function and the client.  As a result, different effective       payload sizes per network path are possible (e.g., due to variable encapsulation       header overheads).  Hence, the MAMS framework SHOULD support the       fragmentation of a single payload across MTU&nbhy;sized IP packets       to avoid IP packet fragmentation when aggregating packets from different       paths.  Further, the concatenation of multiple IP packets into a single IP       packet to improve efficiency in packing the MTU size SHOULD also be supported.</t>        <!-- [rfced] Section 4.10:  We had difficulty following these items inthis section.  Please clarify the meaning of the following:* for adaptation to MTU Differences (the section title)* MTU sized* packing the MTU sizeOriginal:4.10.  Concatenation and Fragmentation for adaptation to MTU Differences Different network paths may have different security and middlebox (e.g NAT) configurations, which will lead to use of different tunneling protocols for transport of data between the network user plane function and the client.  As a result, different effective payload sizes (e.g. due to variable encapsulation header overheads) per network path are possible.  Hence, the MAMS framework SHOULD support fragmentation of a single IP packet payload across MTU sized IP packets to avoid IP fragmentation when aggregating packets from different paths.  Further, concatenation of multiple IP packets into a single IP packet to improve efficiency in packing the MTU size should also be supported.Possibly:4.10.  Concatenation and Fragmentation for Adaptation to MTU Differences Different network paths may have different security and middlebox (e.g., NAT) configurations.  These configurations will lead to the use of different tunneling protocols for the transport of data between the network user-plane function and the client.  As a result, different effective payload sizes (e.g., due to variable encapsulation header overheads) per network path are possible. Hence, the MAMS framework SHOULD support the fragmentation of a single IP packet payload across MTU-sized IP packets to avoid IP fragmentation when aggregating packets from different paths. Further, the concatenation of multiple IP packets into a single IP packet to improve efficiency in packing the MTU size should also be supported. -->        <!-- [author1] Agreed and updated with the suggested text. -->      </section>      <section Network Middleboxes Based on Negotiated        <t>The framework SHOULD enable the identification of optimal parameters that       may be used for configuring the middleboxes, like radio link dormancy timers,       binding expiry times, and supported MTUs, for efficient operation of the       user&nbhy;plane protocols, based on parameters negotiated between the client       and the network, e.g., configuring a longer binding expiry time in NATs when       UDP transport is used, in contrast to the scenario where TCP is configured at       the transport layer.</t>      </section>      <section Optimal Path        <t>The framework MUST support both the implementation of policies at       the client, and guidance from the network for network path       selection that will address different application requirements.</t>        <!-- [rfced] Section 4.12:  We had trouble following this sentence.If the suggested text is not correct, please clarify"consideration of policies at."Original: The framework MUST support consideration of policies at the client, in addition to guidance from the network, for network path selection addressing different application requirements.Suggested: The framework MUST support both the implementation of policies at the client and guidance from the network for network path selection that will address different application requirements. -->        <!-- [author1] Agree with suggested text and Updated. -->      </section>      <section Control        <t>The control-plane signaling MUST NOT be dependent on the underlying access       technology procedures, i.e., it is carried transparently, like application       data, on the user plane.<!-- [rfced] Section 4.13:  We had trouble following this sentence.If the suggested text is not correct, please clarify the meaning of"e.g. be carried transparently as user plane."Original: The control plane signaling MUST NOT be dependent on the underlying access technology procedures, e.g. be carried transparently as user plane.Suggested: The control-plane signaling MUST NOT be dependent on the underlying access technology procedures, e.g., it should be carried transparently on the user plane. --><!-- [author1]: Agree with suggested text. Changed to "i.e." and added the phrase, "like application data", for further clarity. -->       The MAMS framework SHOULD support the delivery of control-plane signaling over existing Internet protocols, e.g., TCP or UDP.</t>      </section>      <section Discovery and        <t>There can be multiple instances of the control-plane and user&nbhy;plane       functional elements of the framework, either collocated or hosted on separate       network elements and reachable via any of the available user&nbhy;plane       paths.  The client MUST have the flexibility to choose the appropriate       control&nbhy;plane instance in the network and use the control&nbhy;plane       signaling to choose the desired user&nbhy;plane functional element instances.       The choice can be based on considerations such as, but not limited to,       the quality of the link through which the network function is reachable, client       preferences, preconfiguration, etc.</t>      </section>    </section>    <section      <t>This document describes the Multi&nbhy;Access Management Services (MAMS)     framework for dynamic selection of a flexible combination of access     and core network paths for the uplink and downlink, as     well as the user&nbhy;plane treatment for the traffic spread across the     selected links.  The user-plane paths, and access and core network connections, can be selected independently for the uplink and downlink.     For example, the network paths chosen for the uplink do not apply any constraints on the choice of paths for the downlink.  The uplink and downlink network paths     can be chosen based on the application needs, and on the characteritics and available resources on different network connections.  For example,     a Wi&nbhy;Fi connection can be chosen for the downlink for transporting high bandwidth data     from network to device, whereas an LTE connection can be chosen to carry the low     bandwidth feedback to the application server.</t>      <t>Also, depending on the characteristics of the access network link, different     processing would be needed on the user&nbhy;plane packets on different network paths.     Encryption would be needed on a Wi&nbhy;Fi link to secure user plane packets, but     not on an LTE link.  Tunneling would be needed to ensure client and network end&nbhy;point     reachability over NATs.  Such, differentiated user&nbhy;plane treatment can be     effected by configuration of user plane&nbhy;protocols (e.g., IPsec) specific to each link.</t>      <!-- [rfced] Section 5:  To what does "independently" refer in thissentence?Original (a space has been added between "Services" and "(MAMS)"): This document proposes the Multiple Access Management Services(MAMS) framework for dynamic selection and flexible combination of access and core network paths independently for the uplink and downlink, as well as the user plane treatment for the traffic spread across the selected links. -->      <!-- [author1] It means that choice of a set of network paths on the uplink does not constrain the choices available for network paths in the downlink.Rephrased the sentences to clarify "independently". -->      <t>The MAMS framework consists of clearly separated control&nbhy; and     user&nbhy;plane functions in the network and the client.  The     control&nbhy;plane protocol allows the configuration of the user&nbhy;plane     protocols and desired network paths for the transport of application     traffic.  The control&nbhy;plane messages are carried as user&nbhy;plane     data over any of the available network paths between the peer     control&nbhy;plane functional elements in the client and the     network.  Multiple user&nbhy;plane paths are dynamically distributed across     multiple access networks and aggregated in the network (by the N-MADP).     The access diversity is not exposed to the application servers,     but is kept within the scope of the elements defined in this     framework.  This reduces the burden placed on application servers that     would otherwise have to react to access link changes caused by mobility     events or changing link characteristics.</t>      <t>The selection of paths and user&nbhy;plane treatment of the traffic is based     on (1) the negotiation of device and network capabilities, and (2) link probing     (i.e., checking the quality of links between the user-plane     functional elements at the end&nbhy;user device/client and the network).<!-- [rfced] Section 5:  We had trouble following this sentence.Does this text refer to link probing as mentioned in Sections 6 and 9?If yes, may we update as suggested below?Original: The selection of paths and user plane treatment of the traffic, is based on negotiation of capabilities (of device and network) and probing of network link quality between the user plane functional elements at the end-user device/client and the network.Suggested: The selection of paths and user-plane treatment of the traffic is based on (1) the negotiation of device and network capabilities and (2) link probing (i.e., checking the quality of links between the user-plane functional elements at the end-user device/client and the network). --><!-- [author1]: Agree with the suggested text, and updated the same. -->     This framework enables leveraging network     intelligence to set up and dynamically configure the best     access network path combination based on device and network     capabilities, an needs, and knowledge of the network     state.</t>    </section>    <section Reference      <t><xref illustrates the MAMS architecture for the scenario     where a client is served by multiple (n) networks.  It also introduces the     following functional elements: NCM and the CCM in the control N-MADP and the C-MADP in the user      <figure Reference        <artwork  +--------------------------------------------------------+  |          +----------------+       +----------------+   |  |          |                |       |                |   |  |          |Core (IP anchor)| ..... |Core (IP anchor)|   |  |          |Network 1       |       |Network "n"     |   |  |          |                |       |                |   |  |          +----------------+       +----------------+   |  |                           \             /              |  |                     Anchor \  ...... Anchor            |  |                     Connection 1     Connection "n"    |  |                              \       /                 |  |              +---------------+\+---+/+------+          |  |              | +-----+      +----------+    |          |  | +--------------| NCM |      |  N-MADP  |    |          |  | |            | +-----+      +----------+    |          |  | |            +------------------------------+          |  | |                           /           \              |  | |Control-Plane       Delivery  ...... Delivery         |  | |Path (over any      Connection 1     Connection "n"   |  | |access user plane)      /                 \           |  | |                       /                   \          |  | |       +------------------+        +---------------+  |  | |       |    Access        | ...... | Access        |  |  | |       |    Network 1     |        | Network "n"   |  |  | |       +------------------+        +---------------+  |  +-----------------------------\----------------/---------+    |                            \              /    |                  +----------\------------/-+    |                  | +---+     \ +------+ /  |    +--------------------+CCM|      \|C-MADP|/   |                       | +---+       +------+    |                       |        Client           |                       +-------------------------+      </figure>      <t>The NCM is the functional element in the network that handles the MAMS     control&nbhy;plane procedures.  It configures the network (N-MADP) and client     (C-MADP) user&nbhy;plane functions, such as negotiating with the client for the use of     available access network paths, protocols, and rules for processing the     user&nbhy;plane traffic, as well as link&nbhy;monitoring procedures.<!-- [rfced] Section 6:  We had trouble following this sentence.Please clarify "negotiating the client on the use"; are some wordsmissing?  Perhaps "on" should be "for" or "negotiating the client"should be "negotiating with the client"?Original: It configures the network (N-MADP) and client (C-MADP) user plane functions like negotiating the client on the use of available access network paths, protocols and rules for processing the user plane traffic, as well as link monitoring procedures.--><!-- [author1] Agree with the suggested grammatical fixes.-->     The     control&nbhy;plane messages between the NCM and the CCM are transported as an     overlay on the user plane, without any impact on the underlying access networks.</t>      <t>The CCM is the peer functional element in the client for handling MAMS     control&nbhy;plane procedures.  It manages multiple network connections at the     client.  It is responsible for the exchange of MAMS signaling messages with the     NCM for supporting such functions as UL and DL user network path     configuration for transporting user data packets, link probing, and reporting     to support adaptive network path selection by the NCM.<!-- [rfced] Sections 6 and subsequent:  We see what appears to bea shift from "uplink" and "downlink" to mixed usage of "UL," "uplink,""DL," and "downlink."Please confirm that "UL" and "DL" stand for "uplink" and "downlink."If yes, for ease of the reader we suggest adding the followingdefinitions to the end of Section 2 (these are examples; we do notassume that our wording is correct): Uplink (also referred to as "UL" in this document):  A connection    from a device or smaller local network to a larger network. Downlink (also referred to as "DL" in this document):  A connection    from a larger network to a device or smaller local network.--><!-- [author1]: Defined "Uplink (UL)" and "Downlink (DL)" in the "Terminology" section.-->     In the downlink, for user data received by     the client, it configures the C-MADP such that application data     packets can be received over any access link so that the packets     will reach the appropriate application on the client.<!-- [rfced] Section 6:  This sentence does not parse.  If thesuggested text is not correct, please clarify "such that applicationdata packet received."Original: In the downlink, for the user data received by the client, it configures C-MADP such that application data packet received over any of the accesses to reach the appropriate application on the client.Suggested: In the downlink, for user data received by the client, it configures the C-MADP such that application data packets can be received over any access link so that the packets will reach the appropriate application on the client.--><!-- [author1] Agreed and incorporated the suggested updates. -->     In the uplink, for the data transmitted by the client, it     configures the C-MADP to determine the best access links to be used for uplink     data based on a combination of local and network policies delivered by     the NCM.</t>      <t>The N-MADP is the functional element in the network that handles the     forwarding of user data traffic across multiple network paths, as well as     other user&nbhy;plane functionalities (e.g., encapsulation, fragmentation,     concatenation, reordering, retransmission).  The N-MADP is the distribution node     that routes (1) the uplink user&nbhy;plane traffic to the appropriate     anchor connection toward the core network, and (2) the downlink user     traffic to the client over the appropriate delivery connections.  In the     downlink, the NCM configures the use of delivery connections and     user&nbhy;plane protocols at the N&nbhy;MADP for transporting user data     traffic.  The N&nbhy;MADP SHOULD implement ECMP support for the downlink     traffic.  Alternatively, it MAY be connected to a router with ECMP     functionality.  The load&nbhy;balancing algorithm at the N&nbhy;MADP is     configured by the NCM, based on static and/or dynamic network policies like     assigning access and core paths for a specific user data traffic type,     user&nbhy;volume-based percentage distribution, and link availability and     feedback information from the exchange of MAMS signaling messages with the CCM at the     client.  The N&nbhy;MADP can be configured with appropriate user&nbhy;plane     protocols to support both per&nbhy;flow and per&nbhy;packet traffic     distribution across the delivery connections.  In the uplink, the N&nbhy;MADP     selects the appropriate anchor connection over which to forward the user data     traffic received from the client (via the delivery connections).  The     forwarding rules in the uplink at the N&nbhy;MADP are configured by the NCM     based on application requirements, e.g., enterprise-hosted application flows     via a Wi&nbhy;Fi anchor or mobile-operator-hosted applications via the     cellular core.</t>      <t>The C-MADP is the functional element in the client that handles the MAMS     user&nbhy;plane data procedures.  The C-MADP is configured by the CCM, based on     the signaling exchange with the NCM and local policies at the client.     The CCM configures the selection of delivery connections and the     user&nbhy;plane protocols to be used for uplink user data traffic based on the     signaling messages exchanged with the NCM.  The C-MADP entity handles the forwarding of     user&nbhy;plane data across multiple delivery connections and associated     user&nbhy;plane functions (e.g., encapsulation, fragmentation, concatenation,     reordering, retransmissions).</t>      <t>The NCM and N-MADP can be either collocated or instantiated on different     network nodes.  The NCM can set up multiple N-MADP instances in the network.     The NCM controls the selection of the N&nbhy;MADP instance by the client and     the rules for the distribution of user traffic across the N&nbhy;MADP     instances.  This is beneficial in multiple deployment scenarios, like the     following examples: N-MADP instances to handle different sets of clients for load          balancing across topologies where the N-MADP is hosted at the          user&nbhy;plane node at the access edge or in the core network, while the          NCM is hosted at the access edge network technology architecture with an N&nbhy;MADP instance at          the core network node to manage traffic distribution          across LTE and DSL networks, and an N&nbhy;MADP instance at an access          network node to manage traffic distribution across LTE and Wi&nbhy;Fi        <!-- [rfced] Section 6:  We had trouble following the meaning of"Address" in these two bullet items.  Is "Address" used as aninstruction in these paragraphs?[author1]: Yes, Address is being used as a verb/instruction.Original ("exanple" has been fixed): o  Address deployment topologies e.g.  N-MADP hosted at the user    plane node at the access edge or in the core network, while the    NCM hosted at the access edge node) o  Address access network technology architecture.  For exanple,    N-MADP instance at core network node to manage traffic    distribution across LTE and DSL networks, and N-MADP instance at    access network node to manage traffic distribution across LTE and    Wi-Fi traffic.Perhaps (guessing that "Address" means "Address-based"): o  Address-based deployment topologies, e.g., a N-MADP is hosted at    the user-plane node at the access edge or in the core network,    while the NCM is hosted at the access edge node. o  Address-based access network technology architecture - for    example, a N-MADP instance at a core network node to manage    traffic distribution across LTE and DSL networks, and a N-MADP    instance at an access network node to manage traffic distribution    across LTE and Wi-Fi networks.-->        <!-- [author1]: Here "Address" was used to mean "Consider". Rephrased text to remove ambiguity.--> 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     Thus, the MAMS architecture flexibly addresses multiple network deployments.</t>    </section>    <section Protocol      <t>This section describes the protocol structure for the MAMS user&nbhy;plane and     control&nbhy;plane functional elements.</t>      <section Control-Plane        <t><xref shows the default MAMS control&nbhy;plane protocol        stack.  WebSocket <xref is used for transporting management        and control messages between the NCM and the CCM.</t>        <figure MAMS Control-Plane Protocol          <artwork    +------------------------------------------+    |                                          |    |    Multi-Access (MX) Control Message     |    |                                          |    +------------------------------------------+    |                                          |    |                WebSocket                 |    |                                          |    +------------------------------------------+    |                                          |    |                 TCP/TLS                  |    |                                          |    +------------------------------------------+        </figure>      </section>      <section User-Plane        <t><xref shows the MAMS user&nbhy;plane protocol stack for transporting the user       payload, e.g., an IP Protocol Data Unit (PDU).</t>        <figure User-Plane Protocol          <artwork   +-----------------------------------------------------+   |   User Payload, e.g., IP Protocol Data Unit (PDU)   |   +-----------------------------------------------------++-----------------------------------------------------------+|  +-----------------------------------------------------+  ||  | Multi-Access (MX) Convergence Layer                 |  ||  +-----------------------------------------------------+  ||  +-----------------------------------------------------+  ||  | MX Adaptation   | MX Adaptation  | MX Adaptation    |  ||  | Layer           | Layer          | Layer            |  ||  | (optional)      | (optional)     | (optional)       |  ||  +-----------------+----------------+------------------+  ||  | Access #1 IP    | Access #2 IP   | Access #3 IP     |  ||  +-----------------------------------------------------+  ||                             MAMS User-Plane Protocol Stack|+-----------------------------------------------------------+        </figure>        <t>The MAMS user-plane protocol consists of the following two layers: (MX) Convergence Layer: The MAMS framework configures           the Convergence Layer to perform multi-access-specific tasks in the           user plane.  This layer performs such functions as access (path)           selection, multi&nbhy;link (path) aggregation, splitting/reordering,           lossless switching, fragmentation, or concatenation.           The MX Convergence Layer can be implemented by using existing           user&nbhy;plane protocols like MPTCP <xref or           Multipath QUIC (MPQUIC) <xref or by adapting           encapsulating header/trailer schemes such as GRE <xref            <xref or Generic Multi&nbhy;Access (GMA) <xref (MX) Adaptation Layer: The MAMS framework configures the           Adaptation Layer to address transport-network-related aspects such as           reachability and security in the user plane.  This layer performs functions           to handle tunneling, network&nbhy;layer security, and NAT.  The MX Adaptation Layer can be           implemented using IPsec, DTLS <xref or a Client NAT (Source NAT at the client with           inverse mapping at the N-MADP <xref  The MX           Adaptation Layer is OPTIONAL and can be independently configured for each of           the access links.  For example, in a deployment with LTE (assumed secure) and           Wi-Fi (assumed to not be secure), the MX Adaptation Layer can be omitted for the           LTE link, but is configured with IPsec to secure the Wi-Fi link.  Further           details on the MAMS user plane are provided in <xref      </section>    </section>    <section Control-Plane      <section        <t>The CCM and NCM exchange signaling messages to configure the user&nbhy;plane       functions via the C-MADP and the N-MADP at the client and the network,       respectively.  The means for the CCM to obtain the NCM credentials (Fully       Qualified Domain Name (FQDN) or IP address) for sending the initial discovery       messages are out of scope for this document.  As an example, the client can       obtain the NCM credentials by using such methods as provisioning or DNS       queries.  Once the discovery process is successful, the (initial) NCM can       update and assign additional NCM addresses, e.g., based on Mobile Country Code       (MCC) / Mobile Network Code (MNC) tuple information received in the MX Discover       message, for sending subsequent control&nbhy;plane messages.</t>        <t>The CCM discovers and exchanges capabilities with the NCM.  The       NCM provides the credentials of the N&nbhy;MADP endpoint and negotiates the       parameters for the user plane with the CCM.  The CCM configures the C&nbhy;MADP       to set up the user&nbhy;plane path (e.g., MPTCP/UDP Proxy connection)       with the N&nbhy;MADP, based on the credentials (e.g., (MPTCP&wj;/UDP) Proxy IP       address and port, associated core network path), and the parameters exchanged       with the NCM.  Further, the NCM and CCM exchange link status information       to adapt traffic steering and user&nbhy;plane treatment to dynamic network       conditions.  The key procedures are described in detail in the following       subsections.</t>        <figure Control-Plane          <artwork                +-----+                 +-----+                | CCM |                 | NCM |                +--+--+                 +--+--+                   |     Discovery and     |                   |     Capability        |                   |     Exchange          |                   |<--------------------->|                   |                       |                   |     Setup of          |                   |     User-Plane        |                   |     Protocols         |                   |<--------------------->|                   |                       |                   |     Path Quality      |                   |     Estimation        |                   |<--------------------->|                   |                       |                   | Network Capabilities  |                   | e.g., RNIS [ETSIRNIS] |                   |<----------------------|                   |                       |                   |   Network Policies    |                   |<----------------------|                   +                       +      "RNIS" stands for "Radio Network Information Service"        </figure>      </section>      <section Fields in MAMS Control        <t>Each MAMS control message consists of the following common fields: Indicates the version of the MAMS control Type: Indicates the type of the message, e.g., MX Discover,           MX Capability Request (REQ) / Response Number: Auto-incremented integer to uniquely identify a           particular message exchange, e.g., MX Capability      </section>      <section Procedures for MAMS Control        <t>This section describes the common procedures for MAMS control messages.</t>        <section          <t>After sending a MAMS control message, the MAMS control&nbhy;plane peer           (NCM or CCM) waits for a duration of MAMS_TIMEOUT ms before           timing out in cases where a response was expected.  The sender of the           message will retransmit the message for MAMS_RETRY times before declaring           failure if no response is received.  A failure implies that the MAMS peer           is dead or unreachable, and the sender reverts to native           non&nbhy;multi&nbhy;access / single-path mode.  The CCM may initiate the           MAMS discovery procedure for re&nbhy;establishing the MAMS session.</t>        </section>        <section          <t>MAMS control-plane peers execute the keep-alive procedures to ensure that           the other peers are reachable and to recover from dead-peer scenarios.  Each           MAMS control&nbhy;plane endpoint maintains a Keep&nbhy;Alive timer that is set           for a duration of MAMS_KEEP_ALIVE_TIMEOUT.  The Keep&nbhy;Alive timer is reset           whenever the peer receives a MAMS control message.  When the Keep&nbhy;Alive           timer expires, an MX KEEP&nbhy;ALIVE REQ message is sent.</t>          <t>The values for MAMS_RETRY and MAMS_KEEP_ALIVE_TIMEOUT parameters           used in keep&nbhy;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.<!-- [rfced] Section 8.3.2:  Should the instances of"MAMS KEEP ALIVE REQ," "MAMS KEEP ALIVE RSP," "MX KEEP ALIVE REQ,"and "MX KEEP ALIVE RSP" be hyphenated, e.g., "MAMS KEEP-ALIVE REQ"?Original: When MAMS_KEEP_ALIVE timer expires, MAMS KEEP ALIVE REQ message is sent.  On reception of a MAMS KEEP ALIVE REQ message, the receiver responds with a MAMS KEEP ALIVE RSP message.  If the sender does not receive a MAMS Control message in response to MAMS_RETRY number of retries of MAMS KEEP ALIVE REQ message, the MAMS peer declares that the peer is dead.  CCM may initiate MAMS Discovery procedure for re- establishment of the MAMS session. CCM shall additionally send MX KEEP ALIVE REQ message immediately to NCM whenever it detects a handover from one base station/access point to another.  During this time the user equipment shall stop using MAMS user plane functionality in uplink direction till it receives a MX KEEP ALIVE RSP from NCM. MX KEEP ALIVE REQ includes following information: --><!-- [author1] Agreed and incorporated the suggested changes. Added, clarification on obtaining values for MAMS_RETRY and MAMS_KEEP_ALIVE_TIMEOUT. -->           On receipt of a MAMS           KEEP&nbhy;ALIVE REQ message, the receiver responds with a MAMS KEEP&nbhy;ALIVE RSP           message.  If the sender does not receive a MAMS control message in response to           MAMS_RETRY retries of the MAMS KEEP&nbhy;ALIVE REQ message, the MAMS           peer declares that the peer is dead or unreachable.  The CCM MAY initiate the MAMS Discovery           procedure for re&nbhy;establishing the MAMS session.</t>          <t>Additionally, the CCM SHALL immediately send an MX KEEP&nbhy;ALIVE REQ message           to the NCM whenever it detects a handover from one           base station / access point to another.  During this time, the           user equipment SHALL stop using MAMS user&nbhy;plane functionality in the           uplink direction until it receives an MX KEEP&nbhy;ALIVE RSP from the NCM.</t>          <t>The MX KEEP&nbhy;ALIVE REQ message includes the following information: Can be "Timeout" or "Handover". "Handover" shall be used                by the CCM only on detection of a Session Identifier: See <xref ID: If the reason is "Handover", the inclusion of this                field is Node Identity : E-UTRAN Cell Global Identifier (ECGI) in the case of LTE, and a Wi&nbhy;Fi AP                ID or a Media Access Control(MAC) address in the case of                Wi&nbhy;Fi). If the reason is "Handover", the inclusion of this                field is        </section>      </section>      <section and Capability        <t><xref shows the MAMS discovery and capability exchange       procedure.</t>        <figure Control Procedure for Discovery and Capability          <artwork CCM                                                  NCM  |                                                    |  |------- MX Discover Message ----------------------->|  |                                         +-----------------+  |                                         | Learn CCM       |  |                                         | IP address      |  |                                         | and port        |  |                                         +-----------------+  |                                                    |  |<--------------------------------MX System Info-----|  |                                                    |  |---------------------------------MX Capability REQ->|  |<----- MX Capability RSP----------------------------|  |---------------------------------MX Capability ACK->|  |                                                    |  +                                                    +        </figure>        <t>This procedure consists of the following key steps:</t>        <t>Step 1 (discovery): The CCM periodically sends an MX Discover message       to a predefined (NCM) IP address/port until an MX System Info message is       received in acknowledgment.            <t>The MX Discover message includes the following information: Country Code (MCC) / Mobile Network Code (MNC) Tuple: Optional parameter to identify the operator network to which                   the client is subscribed, in conformance with the format specified in <xref            <t>The MX System Info message includes the following information:                <t>Number of Anchor Connections.                  For each anchor connection, the following parameters are included: ID: Unique identifier for the anchor Type (e.g., "Wi-Fi", "5G NR", "MulteFire",                    <t>NCM Endpoint Address (for control-plane messages over this connection): Address or        <t>Step 2 (capability exchange): The CCM learns the IP address and port       from the MX System Info message.  It then sends the MX Capability       REQ message, which includes the following parameters:<!-- [rfced] Section 8.4:  We found this sentence confusing, becausethis paragraph is the "Step 2" paragraph.  Should "the step 2 of thecontrol plane connection" be "this step"?  Alternatively, could thephrase be removed, per our "Possibly" text below?Original: Step 2 (Capability Exchange): On receiving MX System Info message CCM learns the IP Address and port to start the step 2 of the control plane connection, and sends out the MX Capability REQ message, including the following Parameters:Possibly: Step 2 (capability exchange): The CCM learns the IP address and port from the MX System Info message.  It then sends the MX Capability REQ message, which includes the following parameters: --><!-- [author1] Agreed and incorporated the suggested changes. --> Feature Activation List: Indicates whether the corresponding feature is            supported or not, e.g., lossless switching, fragmentation, concatenation,            uplink aggregation, downlink aggregation, measurement,            <t>Number of Anchor Connections (core networks).            For each anchor connection, the following parameters are included: Type (e.g., "Wi-Fi", "5G NR", "MulteFire",            <t>Number of Delivery Connections (access links).            For each delivery connection, the following parameters are included: Type (e.g., "Wi-Fi", "5G NR", "MulteFire",            <t>MX Convergence Method Support List: Aggregation            <t>MX Adaptation Method Support List: Tunnel without Tunnel with Tunnel <xref        <t>In response, the NCM creates a unique identity for the CCM session and sends       the MX Capability RSP message, including the following information: Feature Activation List: Indicates whether the corresponding feature is            enabled or not, e.g., lossless switching, fragmentation, concatenation,            uplink aggregation, downlink aggregation, measurement,            <t>Number of Anchor Connections (core networks):            For each anchor connection, the following parameters are included: Type (e.g., "Wi-Fi", "5G NR", "MulteFire",            <t>Number of Delivery Connections (access links):            For each delivery connection, the following parameters are included: Type (e.g., "Wi-Fi", "5G NR", "MulteFire",            <t>MX Convergence Method Support List: Aggregation            <t>MX Adaptation Method Support List: Tunnel without Tunnel with Tunnel <xref            <t>Unique Session Identifier: Unique session identifier for the CCM that            set up the connection. If the session already exists, then the            existing unique session identifier is returned.<!-- [rfced] Section 8.4:  We see that "UE" is first used in thissection.  It appears that "UE" stands for "User Equipment."  May weexpand this term in Section 8.3.2, where "user equipment" is firstused, and use "UE" after that?Original: In case the session for the UE already exists then the existing unique session identifier is sent back. --><!-- [author1] Removed the reference to UE, and rephrased for clarity. --> ID: Unique identity of the NCM in the operator ID: Unique identity assigned to the CCM instance by this NCM        <t>In response to the MX Capability RSP message, the CCM sends a confirmation (or       rejection) in the MX Capability ACK message.  The MX Capability ACK includes the       following parameters: Session Identifier: Same identifier as the identifier            provided in the MX Capability            <t>Acknowledgment: An indication of whether the client has accepted or            rejected the capability exchange phase. ACCEPT: The CCM accepts the capability set proposed by                 the REJECT: The CCM rejects the capability set proposed by                 the        <t>If the NCM receives an MX_REJECT, the current MAMS session will be       terminated.</t>        <t>If the CCM can no longer continue with the current capabilities, it SHOULD       send an MX SESSION TERMINATE message to terminate the MAMS session.  In       response, the NCM SHOULD send an MX SESSION TERMINATE ACK to confirm the       termination.</t>      </section>      <section        <t><xref shows the user-plane (UP) configuration procedure.</t>        <figure Control Procedure for User-Plane          <artwork    CCM                                              NCM     |                                                |     |---- MX Reconfiguration REQ (setup)------------>|     |<--------------------+MX Reconfiguration RSP+---|     |                                    +----------------------------+     |                                    | NCM prepares N-MADP for    |     |                                    | User-Plane Setup           |     |                                    +----------------------------+     |<------------------- MX UP Setup CFG (Config)---|     |---- MX UP Setup CNF (Confirm) ---------------->|+-------------------+                                 ||Link "X" is up/down|                                 |+-------------------+                                 |     |---- MX Reconfiguration REQ (update/release)--->|     |<--------------------+MX Reconfiguration RSP+---|        </figure>        <!-- [rfced] Figure 6:  We changed "Plane|Setup" to "Plane Setup"here.  Please let us know any objections.Original: | User Plane|Setup           |Currently: | User-Plane Setup           | -->        <!-- [author1] Agreed. -->        <t>This procedure consists of the following two key steps: The CCM informs the NCM about the changes to the connections - setup            of a new access connection, teardown of an existing access connection or update of parameters related            to an exiting access connection.  It consists of client triggering the procedure by requesting update            to the connection configuration, and response from the Setup: The NCM configures the user plane protocols at the client and the network.  The NCM initiates            the UP setup by sending the, User Plane Setup Configuration, message to the client which confirms the            set of mutually acceptable parameters using the User Plane Setup Confirmation (CNF)      These steps are elaborated as follows.</t>        <!-- [rfced-auth48] Section 8.5:  It is difficult to see what the stepsthat follow Figure 6 are.  Are there two steps -  "Reconfiguration" and"User Plane Protocols Setup"?  If yes, will this be clear to readers?Please review this section in the updated document, and let us know ifany clarifications are needed.-->        <!-- [author1] Added text to clarify that there are 2 steps.-->        <t>Reconfiguration: When the client detects that the link is up/down or       the IP address changes (e.g., via APIs provided by the client OS),       the CCM sends an MX Reconfiguration REQ message to       set up / release / update the connection.  The message SHOULD       include the following information: Session Identifier: Identity of the CCM at the NCM,            created by the NCM during the capability exchange Action: Indicates the reconfiguration action            (0: release; 1: setup; 2: ID: Identifies the connection for        <t>If the Reconfiguration Action type is set to "setup" or "update", then       the message includes the following parameters: address of the (Service Set Idenfier of the Wi&nbhy;Fi access of the connection: The MTU of the delivery path that is            calculated at the user equipment for use by the NCM to configure fragmentation and            concatenation procedures <xref at the Node Identity: Identity of the node to which the client is            attached.  ECGI in the case of LTE, and a Wi&nbhy;Fi AP ID or a            MAC address in the case of        <t>At the beginning of a connection setup, the CCM informs the NCM of the       connection status using the MX Reconfiguration REQ message with the       Reconfiguration Action type set to "setup".  The NCM acknowledges the       connection setup status and exchanges parameters with the CCM for       user&nbhy;plane setup, as described below.</t>        <t>Setup of User-Plane Protocols: Based on the negotiated capabilities,       the NCM sets up the user&nbhy;plane (Adaptation Layer and Convergence Layer)       protocols at the N&nbhy;MADP and informs the CCM of the user&nbhy;plane       protocols to be set up at the client (C&nbhy;MADP) and the parameters       for the C&nbhy;MADP to connect to the N&nbhy;MADP.</t>        <t>The MX UP Setup Config is used to create (multiple) MADP instances, with       each anchor connection having one or more configurations, namely MX       Configurations.  The MX UP Setup Config consists of the following parameters:            <t>Number of Anchor Connections (core networks).          For each anchor connection, the following parameters are included: Connection Type (e.g., "Wi-Fi", "5G NR", "MulteFire",                <t>Number of Active MX Configurations (included only if more than one               MX configuration is active for the anchor connection).               For each active MX configuration, the following parameters are included: Configuration ID (included if more than one MX configuration is                    <t>MX Convergence Method.  One of the following: Aggregation                    <t>MX Convergence Method Parameters: Proxy IP Proxy                    <t>MX Convergence Control Parameters (included if any MX Control PDU types                    (e.g., Probe-REQ/ACK) are supported): port number for sending and receiving MX Control PDUs                        (e.g., Probe-REQ/ACK, Proxy                    <t>Number of Delivery Connections.                    For each delivery connection, include the following: Connection Type (e.g., "Wi-Fi", "5G NR", "MulteFire",                        <t>MX Adaptation Method. One of the following: Tunnel without Tunnel with                        <t>MX Adaptation Method Parameters: Endpoint IP Endpoint Optimization (included only if the MX Convergence Method                              is        <t>For example, when LTE and Wi-Fi are the two user&nbhy;plane accesses, the       NCM conveys to the CCM that IPsec needs to be set up as the MX Adaptation       Layer over the Wi-Fi access, using the following parameters: IPsec endpoint       IP address, and Pre-Shared Key.  No Adaptation Layer is needed if it is       considered secure with no NAT, or a Client NAT may be used over the LTE access.</t>        <t>Similarly, as an example of the MX Convergence Method, the configuration       indicates the convergence protocol as the MPTCP proxy, along with parameters       for a connection to the MPTCP proxy: namely the IP address and port of the       MPTCP proxy for TCP applications.</t>        <!-- [rfced] Section 8.5:  We had trouble with these two sentences.* Please clarify the meaning of "Client NAT may be used" and"with no NAT" in the same sentence."* Please clarify "as an example of the MX Convergence Methodconfiguration is to indicate":  Should "as an example" be"an example," or should "as an example of the" be "as an example,the"?Original: No Adaptation Layer is needed or Client NAT may be used over the LTE Access as it is considered secure with no NAT. Similarly, as an example of the MX Convergence Method configuration is to indicate the convergence protocol as MPTCP Proxy along with parameters for connection to the MPTCP Proxy, namely IP Address and Port of the MPTCP Proxy for TCP Applications. -->        <!-- [author1] Changes made. -->        <t>Once the user&nbhy;plane protocols are configured, the CCM informs the NCM       of the status via the MX UP Setup CNF message.  The MX UP Setup CNF consists of       the following parameters: Session Identifier: Session identifier provided to the client in            an MX Capability            <t>MX Convergence Control Parameters (included if any MX Control PDU            types (e.g., Probe-REQ/ACK, Keep-Alive) are supported): port number for sending and receiving MX Control PDUs                 (e.g., Probe-REQ/ACK, Configuration ID (if an MX Configuration ID is specified in                 an MX UP Setup Config, indicate the MX Configuration that will be                 used for            <t>Client Adaptation-Layer Parameters:                <t>Number of Delivery Connections.                 For each delivery connection, include the following: Connection port number: If UDP-based adaptation is in use, the UDP port                      on the C-MADP      </section>      <section Path Quality        <t>Path quality estimations can be done either passively or actively.       Traffic measurements in the network can be performed passively by       comparing the real-time data throughput of the device with the capacity       available in the network.  In special deployments where the NCM has       interfaces with access nodes, direct interfaces can be used to gather       information regarding path quality.  For example, the utilization of       the LTE access node (also known as enhanced Node B), to which the device is attached, could be used as       an indicator for path quality estimations without creating any extra       traffic overhead.  Active measurements by the device provide an alternative       way to estimate path quality.</t>        <figure Control-Plane Procedure for Path Quality          <artworkCCM                                                 NCM|                                                    ||<-------------- MX Path Estimation Configuration ---||------ MX Path Estimation Results ----------------->||                                                    |        </figure>        <t>The NCM sends the following configuration parameters in the MX Path Estimation Configuration message to the CCM: ID (of the delivery connection whose path quality             needs to be Probe Test Duration Probe Test Rate Probe Size Probe ACK Required (0 No / 1 Probe Frequency Probe Size Probe Test Duration Probe ACK Required (0 No / 1        <t>The CCM configures the C-MADP for probe receipt based on these       parameters, and for collection of the statistics according to the following       configuration. Session Identifier: Session identifier provided to the client in an MX Capability            <t>Init Probe Results Configuration: Probes Receiving Rate (packets per            <t>Active Probe Results Configuration: Throughput in the last Probe        <t>The user&nbhy;plane probing is divided into two phases: the       Initialization phase and the Active 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 Phase: A network path that is included by the N-MADP for            transmission of user data is deemed to be in the Active        <t>During the Initialization phase, the NCM configures the N-MADP to send an       Idle Probe-REQ message.  The CCM collects the Idle Probe statistics       from the C&nbhy;MADP and sends the MX Path Estimation Results message to the       NCM per the Initialization Probe Results configuration.</t>        <t>During the Active phase, the NCM configures the N-MADP to send an Active       Probe-REQ message.  The C-MADP calculates the metrics as specified by the       Active Probe Results configuration.  The CCM collects the Active Probe       statistics from the C&nbhy;MADP and sends the MX Path Estimation Results       message to the NCM per the Active Probe Results configuration.</t>        <t>The following subsections define the control PDU encoding for Keep-Alive and       Probe-REQ/ACK messages to support path quality estimation.</t>        <section Control PDU          <t>Control PDUs are sent as UDP messages between the C-MADP and the N&nbhy;MADP         to exchange control messages for keep-alive or path quality estimation.         MX probe parameters are negotiated during the user-plane setup phase (MX UP         Setup CFG and MX UP Setup CNF).  <xref shows         the MX Control PDU format with the following fields:<!-- Lynne: Fix the "Figure 7" hard-code per author reply to the AQ below. --><!-- [rfced] Section 8.6.1:  It appears that "Figure 7" should be"Figure 8" here, as Figure 7's title is "MAMS Control Plane Procedurefor Path Quality Estimation" and Figure 8's title is "MX Control PDUFormat."  Please let us know how/if this text should be corrected.Original: Figure 7 shows the MX control PDU format with the following fields:We also see the following: o  Figure 8 shows the MX Control PDU format.  MX Control PDU is sent --> <!-- [author1] Hard-code is now replaced with cross reference to fix the incorrect Figure number reference -->              <t>Type (1 byte): The type of the MX Control message. (1 byte): The connection ID of the delivery connection for              sending the MX Control Control Message (variable): The payload of the MX Control          <t>The MX Control PDU is sent as a normal user&nbhy;plane packet         over the desired delivery connection whose quality and reachability         need to be determined.</t>          <figure Control PDU            <artwork                         |                                          |                         |<--------- MX Control PDU Payload ------->|                         |                                          |+-----------+-------------------+-----+-----------------------------+| IP Header | UDP Header | Type | CID |       MX Control Message    |+-----------+-------------------+-----+-----------------------------+          </figure>        </section>        <section          <t>The "Type" field is set to "0" for Keep-Alive messages.  The C-MADP may         periodically send a Keep-Alive message over one or multiple delivery         connections, especially if UDP tunneling is used as the adaptation         method for the delivery connection with a NAT function on the path.</t>          <t>A Keep-Alive message is 2 bytes long and consists of the following         field: Sequence Number (2 bytes): The sequence number of the              Keep-Alive        </section>        <section REQ/ACK          <t>The "Type" field is set to "1" for Probe-REQ/ACK messages. The N-MADP         may send the Probe-REQ message for path quality estimation.         In response, the C-MADP may return the Probe-ACK message.</t>          <t>A Probe-REQ message consists of the following fields: Sequence Number (2 bytes): The sequence number of the Probe              REQ              <t>Probing Flag (1 byte): 0: A Probe ACK flag to indicate whether the Probe-ACK message                   is expected (1) or not 1: A Probe Type flag to indicate whether the Probe-REQ/ACK                   message was sent during the Initialization phase (0) when the                   network path is not included for transmission of user data, or                   during the Active phase (1) when the network path is included for                   transmission of user 2: A bit flag to indicate the presence of the Reverse                   Connection ID (R-CID) 3-7: Connection ID (R-CID) (1 byte): The connection ID of the              delivery connection for sending the Probe-ACK message on the              reverse          <t>The "R-CID" field is only present if both Bit 0 and Bit 2 of the         "Probing Flag" field are set to "1".  Moreover, Bit 2 of the "Probing         Flag" field SHOULD be set to "0" if Bit 0 is "0", indicating that the         Probe-ACK message is not expected.</t>          <t>If the "R-CID" field is not present, but Bit 0 of the "Probing         Flag" field is set to "1", the Probe-ACK message SHOULD be sent over         the same delivery connection as the Probe-REQ message.</t>          <t>The "Padding" field is used to control the length of the Probe-REQ message.</t>          <t>The C-MADP SHOULD send the Probe-ACK message in response to a Probe-REQ         message with the Probe-ACK flag set to "1".</t>          <t>A Probe-ACK message is 3 bytes long and consists of the following field: Acknowledgment Number (2 bytes): The sequence number of the              corresponding Probe-REQ        </section>      </section>      <section Traffic        <!-- This is actually Figure 9.  Figure 8 wasn't given the "figure8"     anchor (along the lines of Figures 1 through 7 and most of the     other figures), so this is where the "off-by" stuff starts.     Off by 1 here, but by time you get to Figure 18, it's off by 4 -->        <!-- [author1] replacing hard-coded numbers with strings to indicate context -->        <figure Traffic-Steering          <artworkCCM                                               NCM |                                                 | |                                +------------------------------+ |                                |Steer user traffic to Path "X"| |                                +------------------------------+ |<------------------MX Traffic Steering (TS) REQ--| |----- MX Traffic Steering (TS) RSP ------------->|        </figure>        <t>The NCM sends an MX Traffic Steering (TS) REQ message to steer data       traffic.  It is also possible to send data traffic over multiple connections       simultaneously, i.e., aggregation.  The message includes the following       information: Connection ID: Connection ID of the anchor Configuration ID (if an MX Configuration ID is specified in an MX UP Setup Connection ID List: List of DL delivery connections, provided as Connection          <!-- [rfced] Section 8.7:  Does "Connection ID List of DeliveryConnections" (or "Connection ID List of Delivery connections") mean"List of Delivery Connections, provided as Connection IDs" orsomething else?Original: o  Connection ID List of Delivery Connections for DL traffic... *  Connection ID List of Delivery connections for UL traffic    identified by the traffic template-->          <!-- [author1] rephrased parameters as "DL Connection ID List" and "UL Connection ID List" for clarity--> Connection ID: Connection ID of the default UL delivery            <t>For the number of specific UL traffic templates, the message includes the            following: Flow Template for identifying the UL Connection ID List: List of UL delivery connections, provided as Connection IDs, to be used for sending the UL Feature Activation List.  Each parameter indicates whether            the corresponding feature is enabled or not: lossless switching,            fragmentation, concatenation, uplink aggregation,            downlink aggregation, measurement,        <t>In response, the CCM sends an MX Traffic Steering (TS) RSP message,       including the following information: Session Identifier: Session identifier provided to the            client in an MX Capability Feature Activation List.  Each parameter indicates whether            the corresponding feature is enabled or not: lossless switching,            fragmentation, concatenation, uplink aggregation,            downlink aggregation, measurement,          <!-- [rfced] Section 8.7:  Please confirm that, unlike the otherthree "MX Feature Activation List:" paragraphs in this document, thisparagraph should not include "measurement" in the list.Original: o  MX Feature Activation List: each parameter indicates if the    corresponding feature is enabled or not: lossless switching,    fragmentation, concatenation, Uplink aggregation, Downlink    aggregation, probing-->          <!-- [author1] This should include "measurement". That was a miss. Added it.-->      </section>      <section Application MADP        <figure Application MADP Association          <artwork    CCM                                         NCM     |                                           |     |                        +-------------------------+     |                        | Associate MADP instance |     |                        | with application flow   |     |                        +-------------------------+     |------------------MX App MADP ------------>|     |                  Association (AMA) REQ    |     |                                           |     |<------------------MX App MADP ------------|     |                  Association (AMA) RSP    |        </figure>        <t>The CCM sends an MX App MADP Association (AMA) REQ message to request       the association of a specific application flow with a specific MADP       instance ID for the anchor connection with multiple active MX       configurations.  The MADP Instance ID is a tuple (Anchor Connection ID, MX       Configuration ID).  This provides the capability for the client to indicate       the user&nbhy;plane processing that needs to be associated with different       application flows depending on the needs of those flows.<!-- [rfced] Section 8.8:  Does "their" refer to the client (in whichcase it should be "its") or the application flows?Original (the previous two sentences are included for context): CCM sends out a MX App MADP Association(AMA) REQ message to request association of a specific Application flow with a specific MADP instance ID for the anchor connection with multiple active MX configurations.  MADP Instance ID is a tuple (Anchor Connection ID, MX Configuration ID).  This provides the capability for the client to indicate the user plane processing that needs to be associated with different application flows depending on their needs. --><!-- [author1] "their" refers to the "application flows". Fixed. -->       The application flow is identified by its associated Traffic Flow Template.</t>        <t>The MX AMA REQ message includes the following information:            <t>Number of Application Flows.            For each application flow, identified by the Traffic Flow Templates: Connection Configuration ID (if more than one MX configuration is                 associated with an anchor Flow Template for identifying the UL Flow Template for identifying the DL        <t>In response, the NCM sends an MX App MADP Association (AMA) RSP message,       including the following information:<!-- [rfced] Section 8.8:  Figure 10 shows that the CCM sends outboth the MX App MADP Association (AMA) REQ message and theMX App MADP Association (AMA) RSP message.  Assuming that the flow inFigure 10 is correct, this sentence contradicts Figure 10.  Pleaselet us know how this should be corrected.Original: In response, NCM sends out a MX App MADP Association (AMA) RSP message, including the following information: --><!-- [author1] The error is in the figure. Corrected the error in the figure to pointthe arrow towards CCM for the MX App MADP Association (AMA) RSP message. -->            <t>Number of Application Flows.            For each application flow, identified by the Traffic Flow Templates: (Success or      </section>      <section Network ID        <figure Network ID Indication          <artwork    CCM                                               NCM     |                                                 |     |                            +---------------------------------+     |                            |NCM determines preferred networks|     |                            +---------------------------------+     |<------------------MX SSID Indication------------|        </figure>        <t>The NCM indicates the preferred network list to the CCM to guide the       client regarding networks that it should connect to.  To indicate preferred       Wi-Fi networks, the NCM sends the list of WLANs, each represented by an       SSID (Service Set Identifier)/BSSID (Basic Service Set Identifier)/HESSID       (Homogeneous Extended Service Set Identifier) as defined in <xref       available in the MX SSID Indication.</t>      </section>      <section Client Measurement Configuration and        <figure Client Measurement Configuration and Reporting          <artwork     CCM                                               NCM      |                                                 |      |<------------------MX Meas Config ---------------|      |                                                 |+---------------------------------+                     ||Client ready to send measurements|                     |+---------------------------------+                     |      |                                                 |      |----- MX Meas Report --------------------------->|        </figure>        <t>The NCM configures the CCM with the different parameters (e.g., radio link       information), with the associated thresholds to be reported by the client.  The       MX MEAS CONFIG message contains the following parameters for each delivery connection: Connection Type (e.g., "Wi-Fi", "5G NR", "MulteFire",            <t>If the connection type is "Wi-Fi": High and low thresholds for the sending of average                 RSSI of the Wi-Fi              <!-- [rfced] Section 8.10:  For these particular parameters, we atfirst could not tell whether "for sending" should be "for sending the"or "for the sending."  We changed them to "for sending the."  Pleaselet us know if this is incorrect (i.e., should they be "for thesending"?).Original: for sending Average RSSI of for sending RSRP of for sending RSRQ ofCurrently: for sending the Average RSSI of for sending the RSRP of for sending the RSRQ of -->              <!-- [author1] Fixed the text. It should be "for sending the". --> Periodicity, in ms, for sending the average RSSI (Received Signal Strength Indicator) of the Wi-Fi High and low thresholds for sending the loading of the WLAN Periodicity, in ms, for sending the loading of the WLAN High and low thresholds for sending the reverse link throughput on the Wi-Fi Periodicity, in ms, for sending the reverse link throughput on the Wi-Fi High and low thresholds for sending the forward link throughput on the Wi-Fi Periodicity, in ms, for sending the forward link throughput on the Wi-Fi High and low thresholds for sending the reverse link throughput (EstimatedThroughputOutbound as defined in <xref on the Wi-Fi Periodicity, in ms, for sending the reverse link throughput (EstimatedThroughputOutbound as defined in <xref on the Wi-Fi High and low thresholds for sending the forward link throughput (EstimatedThroughputInbound, as defined in <xref on the Wi-Fi Periodicity, in ms, for sending the forward link throughput (EstimatedThroughputInbound, as defined in <xref on the Wi-Fi            <t>If the connection type is "LTE": High and low thresholds for sending the RSRP (Reference Signal Received Power) of the serving LTE Periodicity, in ms, for sending the RSRP of the serving LTE High and low thresholds for sending the RSRQ (Reference Signal Received Quality) of the serving LTE Periodicity, in ms, for sending the RSRP of the serving LTE High and low thresholds for sending the reverse link throughput on the serving LTE Periodicity, in ms, for sending the reverse link throughput on the serving LTE High and low thresholds, for sending the forward link throughput on the serving LTE Periodicity, in ms, for sending the forward link throughput on the serving LTE            <t>If the connection type is "5G NR": High and low thresholds, for sending the RSRP of the serving NR Periodicity, in ms, for sending the RSRP of the serving NR High and low thresholds, for sending the RSRQ of the serving NR Periodicity, in ms, for sending the RSRP of the serving NR High and low thresholds, for sending the reverse link throughput on the serving NR Periodicity, in ms, for sending the reverse link throughput on the serving NR High and low thresholds, for sending the forward link throughput on the serving NR Periodicity, in ms, for sending the forward link throughput on the serving NR        <t>The MX MEAS REPORT message contains the following parameters: Session Identifier: Session identifier provided to the client in an MX Capability            <t>For each delivery connection, include the following: Connection Type (e.g., "Wi-Fi", "5G NR", "MulteFire", Node Identity (ECGI in the case of LTE, and                 a Wi&nbhy;Fi AP ID or a MAC address in the case of                <t>If the connection type is "Wi-Fi": Average RSSI of the Wi-Fi Loading of the WLAN Reverse link throughput on the Wi-Fi Forward link throughput on the Wi-Fi Estimated reverse link throughput on the Wi-Fi link (EstimatedThroughputOutbound as defined in  <xref Estimated forward link throughput on the Wi-Fi link (EstimatedThroughputInbound, as defined in  <xref                <t>If the connection type is "LTE": RSRP of the serving LTE RSRQ of the serving LTE Reverse link throughput on the serving LTE Forward link throughput on the serving LTE                <t>If the connection type is "5G NR": RSRP of the serving NR RSRQ of the serving NR Reverse link throughput on the serving NR Forward link throughput on the serving NR      </section>      <section Session Termination        <figure Session Termination Procedure - Initiated by          <artworkCCM                                 NCM |                                   | |---- MX Session Terminate -------->| |                                   | |                                   | |<-- MX Session Terminate ACK ------| |                              +----------------+ |                              |Remove Resources| |                              +----------------+ |                                   |        </figure>        <figure Session Termination Procedure - Initiated by          <artwork           CCM                                     NCM            |                                       |            |<--------- MX Session Terminate -------|            |                                       |            |                                       |            |                                       |            |------- MX Session Terminate ACK ----->|            |                                       |            |                                       |+-----------------------+                           ||    Remove Resources   |                           |+-----------------------+                           |            |                                       |        </figure>        <t>At any point in MAMS processing, if the CCM or NCM is no longer able to       support the MAMS functions, then either of them can initiate a termination       procedure by sending an MX Session Terminate to the peer.  The peer SHALL       acknowledge the termination by sending an MX Session Terminate ACK       message.  After the session is disconnected, the CCM SHALL start a new       procedure with an MX Discover message.  An MX Session Terminate message shall       contain a Unique Session Identifier and the reason for the termination       in the request.  Possible reasons for termination are: Response from      </section>      <section Network Analytics Request        <figure Network Analytics Request          <artwork       CCM                                           NCM        |                                             |        |-----MX Network Analytics Request----------->|        |                                             |        |                                             |        |<---MX Network Analytics Info----------------|        |                                             |        </figure>        <t>The CCM sends the MX Network Analytics Request to the NCM for requesting       information related to such network parameters as bandwidth, latency, jitter,       and signal quality, derived based on the application of analytics at the network       (utilizing the received path measurements and client measurement reporting).</t>        <!-- [rfced] Section 8.12:  This sentence does not parse; it appearsthat one or more words are missing.  If the suggested text is notcorrect, please clarify.Original: CCM sends the MX Network Analytics Request informs the NCM to send information related to network parameters like bandwidth, latency, jitter, signal quality based on application of analytics at the network utilizing the received path measurements and client measurement reporting.Suggested: The CCM sends the MX Network Analytics Request to the NCM to request information related to such network parameters as bandwidth, latency, jitter, and signal quality, based on the application of analytics at the network (utilizing the received path measurements and information related to client measurement reporting). -->        <!-- [author1] Agreed and Accepted the suggested wording, with minor modifications. -->        <t>The MX Network Analytics Request message consists of the following parameters:            <t>Link Quality Indicators.  One or more of the following:        <t>The NCM sends the MX Network Analytics Info message to convey       analytics information that might be of interest to the CCM.  This       message will include network parameters with their predicted likelihoods.</t>        <!-- [rfced] Section 8.12:  We had trouble following this sentence.If the suggested text is not correct, please clarify.Original: NCM sends the MX Network Analytics Info to convey the analytics info, predictive parameters with likelihoods, for the different parameters of interest for the CCM.Suggested: The NCM sends the MX Network Analytics Info message to convey analytics information that might be of interest to the CCM; this message will include predictive parameters, e.g., likelihoods. -->        <!-- [author1] Modified per suggestion with minor edits: The NCM sends the MX Network Analytics Info message to convey analytics information that might be of interest to the CCM; this message will include network parameters with their predicted likelihoods. -->        <t>The MX Network Analytics Info message consists of the following parameters:            <t>Number of Delivery Connections.            For each delivery connection, include the following:                <t>Access Link Identifier:                <t>Link Quality Indicator:                    <t>Bandwidth: Value Validity (Validity Time, in                    <t>Jitter: Value (in Validity (Validity Time, in                    <t>Latency: Value (in Validity (Validity Time, in                    <t>Signal Quality: delivery connection type is "LTE", LTE_RSRP Predicted Value delivery connection type is "LTE", LTE_RSRQ Predicted Value delivery connection type is "5G NR", NR_RSRP Predicted Value delivery connection type is "5G NR", NR_RSRQ Predicted Value delivery connection type is "Wi&nbhy;Fi", WLAN_RSSI Predicted Value Validity (Validity Time, in      </section>    </section>    <section MAMS Signaling      <t><xref illustrates the MAMS signaling mechanism     for negotiation of network paths and flow protocols between the client     and the network.  In this example scenario, the client is connected to     two networks (LTE and Wi&nbhy;Fi).</t>      <figure Call        <artwork                       +--------------------------------------------+                       |     MAMS-enabled Network of Networks       |                       | +-------+    +-------+   +-----+   +------+|+-----------------+    | |       |    |       |   |     |   |      |||     Client      |    | |Network|    |Network|   |     |   |      ||| +------+ +-----+|    | |   1   |    |   2   |   | NCM |   |N-MADP||| |C-MADP| | CCM ||    | | (LTE) |    |(Wi-Fi)|   |     |   |      ||| +------+ +-----+|    | +-------+    +-------+   +-----+   +------+||    |       |    |    |     |            |          |          |   |++---+-------+----+    +-----+------------+----------+----------+---+ |   |       |               |            |          |          | |   |       |               |            |          |          | |   |    1.Setup Connection |            |          |          | |<----------+-------------->|            |          |          | |   |       |               |            |          |          | |   |       |  2. MAMS Capabilities Exchange        |          | |   |       |<--------------+------------+--------->|          | |   |       |               |            |          |          | |   |    3. Setup Connection             |          |          | |<--+----------------------------------->|          |          | |   |       |               |            |          |          | | 4c. Config| 4a. Negotiate network paths, Flow     |4b. Config| | C-MADP    | protocol, and parameters   |          |N-MADP    | |   |<----->|<--------------+------------+--------->|<-------->| |   |       |               |            |          |          | |   |       |5. Establish user-plane path according to         | |   |       | selected flow protocol     |          |          | |   |<----------------------+------------+-------------------->| |   |       |               |            |          |          | +   +       +               +            +          +          +      </figure> UE connects to Network 1 and gets an IP address assigned by        Network CCM communicates with the NCM functional element via the Network 1        connection and exchanges capabilities and parameters for MAMS operation.  Note:        The NCM credentials (e.g., the IP address) can be made known to the UE        by client sets up the connection with Network 2 and gets an IP address        assigned by Network          <t>The CCM and NCM negotiate capabilities and parameters for establishing        network paths.  The negotiated capabilities and parameters are then used        to configure user&nbhy;plane functions, i.e., the N&nbhy;MADP at the network        and the C&nbhy;MADP at the client.<!-- [rfced] Section 9:  What is used to configure the user-planefunctions - the capabilities and parameters, the network paths, orsomething else?Original: 4.  CCM and NCM negotiate capabilities and parameters for     establishment of network paths, which are then used to configure     user plane functions N-MADP at the network and C-MADP at the     client.--><!-- [author1] The CCM and NCM negotiate capabilities and parameters for     establishing network paths.  The negotiated capabilities and     parameters are then used to configure user-plane functions, i.e. the     N-MADP at the network and the C-MADP at the client.--> CCM and NCM negotiate network paths, flow routing and aggregation             protocols, and related NCM communicates with the N-MADP to exchange and configure             flow aggregation protocols, policies, and parameters in alignment with             those negotiated with the CCM communicates with the C-MADP to exchange and configure             flow aggregation protocols, policies and parameters in alignment with             those negotiated with the C-MADP and N-MADP establish the user&nbhy;plane paths, e.g.,        using Internet Key Exchange Protocol (IKE) <xref        signaling, based on the negotiated flow aggregation protocols and parameters        specified by the      <t>The CCM and NCM can further exchange messages containing access link     measurements for link maintenance by the NCM.  The NCM evaluates the link     conditions in the UL and DL across LTE and Wi&nbhy;Fi, based on link     measurements reported by the CCM and/or link&nbhy;probing techniques, and     determines the policy for UL and DL user data distribution.  The NCM and CCM     also negotiate application&nbhy;level policies for categorizing applications,     e.g., based on the Differentiated Services Code Point (DSCP), destination IP     address, and determination of which available network path needs to be used     for transporting data of that category of applications.  The NCM configures     the N-MADP, and the CCM configures the C-MADP, based on the negotiated     application policies.  The CCM may apply local application policies, in     addition to the application policy conveyed by the NCM.</t>    </section>    <section to IETF      <t>The MAMS framework leverages technologies developed in the IETF (such as MPTCP and GRE) and     enables a control&nbhy;plane framework to negotiate the use of these protocols between the client     and the network.  It also addresses the limitations in scope of other multihoming protocols.     For example, the IKEv2 Mobility and Multihoming Protocol (MOBIKE <xref scope     indicates that it is limited to multihoming between IPsec     clients (tunnel mode IPsec Security Associations) and does not support load balancing.     To address this limitation regarding how the multihoming scenario is handled,     the MAMS framework supports load balancing with the simultaneous use of multiple access     paths by negotiating the use of protocols like MPTCP.  Unlike MOBIKE, which     only applies to endpoints connected with an IPsec tunnel mode Security Association, the MAMS     framework allows the flexibility to use a wide range of tunneling protocols     in the Adaptation Layer.</t>    </section>    <section MAMS Control Procedures with MPTCP Proxy as User      <t>If the NCM determines that the N-MADP is to be instantiated with MPTCP as     the MX Convergence Protocol, it exchanges the MPTCP capability support in the     discovery and capability exchange procedures.     An MPTCP proxy (e.g., see <xref is configured to     be the N-MADP instance.  The NCM then provides the credentials of the MPTCP     Proxy instance, along with related parameters to the CCM.<!-- [rfced] Section 11:  This sentence does not parse.Please clarify "the N-MADP instance, setup as MPTCP Proxy, alongwith ..."Original: NCM then exchanges the credentials of the N-MADP instance, setup as MPTCP Proxy, along with related parameters to the CCM. --><!-- [author1] Rephrased for clarification. -->     The CCM configures the C-MADP with these parameters to connect to this     MPTCP proxy instance.</t>      <!-- [rfced] Section 11:  Should "the N-MADP, MPTCP proxy (e.g.[I-D.ietf-tcpm-converters]) instance" be "the N-MADP and theMPTCP proxy (e.g., see [I-D.ietf-tcpm-converters]) instance," orsomething else?Original: CCM configures C-MADP with these parameters to connect with the N-MADP, MPTCP proxy (e.g. [I-D.ietf-tcpm-converters]) instance, on the available network path (Access). -->      <!-- [author1] Rephrased for clarification. -->      <t><xref illustrates the user&nbhy;plane protocol layering when     MPTCP is configured to be the "MX Convergence Layer" protocol.  MPTCP manages traffic distribution and     aggregation over multiple delivery connections.      <figure User-Plane Protocol Stack with MPTCP as MX Convergence        <artwork+-----------------------------------------------------+|                       MPTCP                         |+----------------+---------------+--------------------+|  TCP           |   TCP         |      TCP           |+-----------------------------------------------------+| MX Adaptation  | MX Adaptation | MX Adaptation      || Layer          | Layer         | Layer              || (optional)     | (optional)    | (optional)         |+-----------------------------------------------------+| Access #1 IP   | Access #2 IP  | Access #3 IP       |+----------------+---------------+--------------------+      </figure>     The client (C-MADP) sets up an MPTCP connection with the N-MADP to begin with.  The MAMS control procedures are     then applied to: to the appropriate MPTCP network endpoint, e.g., the MPTCP proxy (illustrated in <xref the addition of a second TCP subflow after the Wi&nbhy;Fi            connection is established and is deemed good (illustrated in <xref the behavior of the MPTCP scheduler, e.g., by using only the LTE            subflow in the UL and both the LTE and Wi&nbhy;Fi subflows in the DL            (illustrated in <xref response to Wi&nbhy;Fi link degradation by proactive deletion of a            TCP subflow over Wi&nbhy;Fi when poor link conditions are reported, to maintain            optimum performance (illustrated in <xref      <t><xref shows the call flow describing MAMS control     procedures applied to configure the user plane and dynamic optimal path selection     in a scenario with the MPTCP proxy as the convergence protocol in the user plane.<!-- [rfced] This is actually Figure 18 --><!-- [author1] Fixed with direct xref -->      <figure MPTCP Proxy as User Plane - Initial Setup with LTE        <artwork+------+   +--------+   +---------+   +---------+   +-------+   +------+|      |   |        |   |         |   |         |   |       |   |      || CCM  |   | C-MADP |   |Wi-Fi N/W|   | LTE N/W |   |  NCM  |   |N-MADP|+------+   +--------+   +---------+   +---------+   +-------+   +------+ +---------------------------------------------------------------------+ |                1. LTE Session Setup and IP Address Allocation       | +------------------------------------------+--------------+-----------+  |                                         |              |          |  |2. MX Discover (MAMS Version, MCC/MNC)   |              |          |  +-----------------------------------------+------------->|          |  |3. MX System Info (Serving NCM IP/Port Address)         |          |  |<------------+-------------+-------------+--------------+          |  |             |             |             |              |          |  |4. MX Capability REQ (Supported Anchor/Delivery Links (Wi-Fi, LTE) |  +------------------------------------------------------->|          |  |5. MX Capability RSP (Convergence/Adaptation Parameters)|          |  |<----------------------------------------+--------------+          |  | 6. MX Capability ACK (ACCEPT)           |              |          |  +-------------+-------------+--------------------------->|          |  |             |             |             |              |          |  |7. MX Meas Config (Wi-Fi/LTE Measurement Thresholds/Period)        |  |<-------------------------------------------------------+          |  |8. MX Meas Report (LTE RSRP, UL/DL TPUT) |              |          |  +-----------------------------------------+------------->|          |  |9. MX SSID Indication (List of SSIDs)    |              |          |  |<------------+-------------+----------------------------+          |  |             |             |             |              |          |  |10. MX Reconfiguration REQ (LTE IP)      |              |          |  +------------------------------------------------------->|          |  |11. MX Reconfiguration RSP               |              |          |  |<----------------------------------------+--------------+          |  |12. MX UP Setup REQ (MPTCP proxy IP/Port, Aggregation)  |          |  |<--------------------------+-------------+--------------+          |  |13. MX UP Setup RSP        |             |              |          |  +-------------+-------------+-------------+------------->|          |  |             | 14. MPTCP connection with designated MPTCP proxy    |  |             |     over LTE              |                         |  |             +-------------+-------------+--------------+--------->|  |             |             |             |              |          |  +             +             +             +              +          +      </figure>      <t>The salient steps described in the call flow are as follows.     The client connects to the LTE network and obtains an IP address (assume that     LTE is the first connection).  It then initiates the NCM discovery procedures     and exchanges capabilities, including the support for MPTCP as the convergence     protocol at both the network and the client.</t>      <t>The CCM provides the LTE connection parameters to the NCM.  The NCM provides     the parameters like MPTCP proxy IP address/Port, MPTCP Client Key for     configuring the Convergence Layer.  This is useful if the N&nbhy;MADP is     reachable, via a different IP address or/and port, from different access     networks. The current MPTCP signaling identify or differentiate the     MPTCP proxy IP address and port among multiple access networks.     The client uses the MPTCP Client Key during the subflow creation, and this     enables the N-MADP to uniquely identify the client, even if a NAT is     present.  The N-MADP can then inform the NCM of the subflow creation and     parameters related to creating additional subflows.     Since LTE is the only connection, the user&nbhy;plane traffic flows over the     single TCP subflow over the LTE connection.     Optionally, the NCM provides assistance information to the device on the     neighboring/preferred Wi-Fi networks that it can associate with.</t>      <t><xref describes the steps where the client establishes     a Wi-Fi connection.  The CCM informs the NCM of the Wi-Fi connection, along with     such parameters as the Wi-Fi IP address or the SSID.  The NCM determines that     the Wi-Fi connection needs to be secured, configures the Adaptation Layer     to use IPsec, and provides the required parameters to the CCM.  In addition, the     NCM provides the information for configuring the Convergence Layer (e.g.,     MPTCP proxy IP address) and provides the Traffic Steering Request to indicate     that the client SHOULD use only the LTE access.  The NCM may do this, for     example, on determining from the measurements that the Wi-Fi link is not     consistently good enough.  As the Wi-Fi link conditions improve, the NCM sends     a Traffic Steering Request to use Wi-Fi access as well.  This triggers the client     to establish the TCP subflow over the Wi-Fi link with the MPTCP proxy.</t>      <!-- [rfced] This is actually Figure 19 -->      <!-- [author1] Fixed with direct xref -->      <figure MPTCP Proxy as User Plane - Add Wi-Fi        <artwork+-----+   +---------+   +---------+   +---------+   +-------+   +------+|     |   |         |   |         |   |         |   |       |   |      || CCM |   |  C-MADP |   |Wi-Fi N/W|   | LTE N/W |   |  NCM  |   |N-MADP|+-----+   +---------+   +---------+   +---------+   +-------+   +------++----------------------------------------------------------------------+|    Traffic over LTE in UL and DL over MPTCP Connection               |+----------------------------------------------------------------------++----------------------------------------------------------------------+|    Wi-Fi Connection Establishment and IP Address Allocation          |+-------------------------------------------------------------------+--+ |             |             |             |             |          | |15. MX Reconfiguration REQ (Wi-Fi IP)    |             |          | +------------------------------------------------------>|          | |16. MX Reconfiguration RSP               |             |          | |<----------------------------------------+-------------+          | |17. MX UP Setup REQ (MPTCP proxy IP/Port, Aggregation) |          | |<--------------------------+-------------+-------------+          | |18. MX UP Setup RSP        |             |             |          | +-------------+-------------+-------------+------------>|          | |             | 19. IPsec Tunnel Establishment over Wi-Fi Path     | |             |<----------------------------------------+--------->| |             |             |             |             |          | | 20. MX Meas Report (Wi-Fi RSSI, LTE RSRP, UL/DL TPUT) |+------------+ +-------------+-------------+-------------+------------>||Wait for    | |             |             |             |             ||good reports| |             |             |             |             |+------------+ |   21. MX Traffic Sterring REQ (UL/DL access,          |          | |                  Traffic Flow Templates (TFTs))       | +-----------+ |<----------------------------------------+-------------+ |Allow use  | |                                         |             | |    of     | |   22. MX Traffic Steering RSP (...)     |             | |Wi-Fi link | +-------------+-------------+-------------------------->| +-----------+ |             |             |             |             |          | |            23. Add TCP subflow to the MPTCP connection over      | |             |    Wi-Fi link (IPsec Tunnel)                       | |             |<-------------------------------------------------->| |             |             |             |             |          |+----------------------------------------------------------------------+||              Aggregated Wi-Fi and LTE capacity for UL and DL     |  |+----------------------------------------------------------------------+ |                                                                  | |                                                                  |      </figure>      <t><xref describes the steps where the client reports     that Wi-Fi link conditions degrade in UL.  The MAMS control plane is used to continuously monitor the     access link conditions on Wi-Fi and LTE connections.  The NCM may at some point determine an increase in     UL traffic on the Wi-Fi network, and trigger the client to use only LTE in the UL via a Traffic Steering Request to     improve UL performance.</t>      <figure MPTCP Proxy as User Plane - Wi-Fi UL        <artwork+-----+   +---------+   +---------+   +---------+   +-------+   +------+|     |   |         |   |         |   |         |   |       |   |      || CCM |   |  C-MADP |   |Wi-Fi N/W|   | LTE N/W |   |  NCM  |   |N-MADP|+-----+   +---------+   +---------+   +---------+   +-------+   +------++----------------------------------------------------------------------+|    Traffic over LTE and Wi-Fi in UL And DL over MPTCP                |++-------------+-------------+-------------+------------+----------+---+ |             |             |             |            |          | | 24. MX Meas Report (Wi-Fi RSSI, LTE RSRP, UL/DL TPUT)| +--------+---+ +-------------+-------------+-------------+----------->| | Reports of | |             |             |             |            | | bad Wi-Fi  | |             |             |             |            | | UL tput    | |             |             |             |            | +------------+ |   25. MX Traffic Steering REQ (UL/DL Access, TFTs)   | +-----------+ |<-----------------------------------------+-----------+ | Disallow  | |   26. MX Traffic Steering RSP (...)     |            | | use of    | |             |             |             |            | | Wi-Fi UL  | |-------------+-------------+------------------------->| +-------+---+ |             |             |             |            |         |++-------------+-------------+-------------+------------+---------+---+|  UL data to use TCP subflow over LTE link only,                     ||     aggregated Wi-Fi+LTE capacity for DL                            |++-------------+-------------+-------------+------------+---------+---+ |             |             |             |            |         | +             +             +             +            +         +      </figure>      <!-- [rfced] Figures 20, 21, and 22:  We changed the instances of"Wi+Fi" to "Wi-Fi" in these figures.  (For example, we saw both"Wi+Fi N/W" and "Wi-Fi N/W" in several figures, and it seemed that"Wi-Fi" was intended.)  Please let us know if this is incorrect.Original (for example): ... |Wi+Fi N/W| ...       (versus "Wi-Fi N/W") ... |  Aggregated Wi+Fi+LTE capacity for DL ...   (versus "Aggregated Wi-Fi+LTE capacity for DL") ... Wi+Fi UL/DL tput ...   (versus "Wi-Fi UL tput") ... |of Wi+Fi     | ...    (versus "|of Wi-Fi UL") Figure 21 describes the steps, when the client reports that Wi-Fi ...Currently (for example): ... |Wi-Fi N/W| ... ... |     aggregated Wi-Fi+LTE capacity for DL ... -->      <!-- [author1] OK. Thanks for the changes. -->      <t><xref describes the steps where the client reports that     Wi-Fi link conditions have degraded in both the UL and DL.  As the Wi-Fi     link conditions deteriorate further, the NCM may decide to send a Traffic     Steering Request that instructs the client to stop using Wi-Fi and to use only     the LTE access in both the UL and DL.  This condition may be maintained     until the NCM determines, based on reported measurements, that the Wi&nbhy;Fi     link has again become usable.</t>      <figure MPTCP Proxy as User Plane - Part        <artwork+-----+   +--------+   +---------+   +---------+   +-------+   +-------+|     |   |        |   |         |   |         |   |       |   |       || CCM |   | C-MADP |   |Wi-Fi N/W|   | LTE N/W |   |  NCM  |   |N-MADP |+-----+   +--------+   +---------+   +---------+   +-------+   +-------++--------------------------------------------------------------------+|           UL data to use TCP subflow over LTE link only,           ||                aggregated Wi-Fi+LTE capacity for DL                |++-------------+-------------+-------------+-------------+---------+-+ |             |             |             |             |         | |             |             |             |             |         | | 27. MX Meas Report (Wi-Fi RSSI, LTE RSRP, UL/DL TPUT) |+--------+---+ +-------------+-------------+-------------+------------>|| Reports of | |             |             |             |             || bad Wi-Fi  | |             |             |             |             || UL/DL tput | |             |             |             |             |+------------+ |   28. MX Traffic Steering REQ (UL/DL Access, TFTs)    | +-----------+ |<----------------------------------------+-------------+ | Disallow  | |   29. MX Traffic Steering RSP (...)     |             | | use of    | |             |             |             |             | | Wi-Fi     | +-----------------------------------------+------------>| +-----------+ |             |30. Delete TCP subflow from MPTCP conn. over Wi-Fi link |             |<------------------------------------------------->| |             |             |             |             |         |+------------------------------------------------------------------+||             Traffic over LTE link only for DL and UL  |         |||        (until client reports better Wi-Fi link conditions)      |+------------------------------------------------------------------+ |             |             |             |             |         | +             +             +             +             +         +      </figure>    </section>    <section MAMS Control Procedures for Network-Assisted Traffic Steering when There Is No Convergence      <t><xref shows the call flow describing MAMS control     procedures applied for dynamic optimal path selection in a scenario where     Convergence and Adaptation Layer protocols are omitted.<!-- [rfced] Section 12:  It appears that one or more words aremissing in this sentence.  Please clarify "in a scenario convergence."Original: Figure 22 shows the call flow describing MAMS control procedures applied for dynamic optimal path selection in a scenario convergence and Adaptation layer protocols are not omitted. --><!-- [author1] Added missing "where" -->     This scenario indicates the     applicability of a solution for only the MAMS control plane.</t>      <t>In the capability exchange messages, the NCM and CCM negotiate that     Convergence-layer and Adaptation-layer protocols are not needed (or     supported).  The CCM informs the NCM of the availability of the LTE     and Wi-Fi links.  The NCM determines the access links, Wi-Fi, or LTE     to be used dynamically, based on the reported link quality measurements.</t>      <figure with No Convergence        <artwork+-----+   +---------+   +---------+   +---------+   +-----+   +------+|     |   |         |   |         |   |         |   |     |   |      || CCM |   |  C-MADP |   |Wi-Fi N/W|   | LTE N/W |   | NCM |   |N-MADP|+-----+   +---------+   +---------+   +---------+   +-----+   +------+ +---------------------------------------------------------------------+ |          1. LTE Session Setup and IP Address Allocation             | +------------------------------------------+-------------+----------+-+  |2. MX Discover (MAMS Version, MCC/MNC )                |          |  +-----------------------------------------+------------>|          |  | 3. MX System Info (Serving NCM IP/Port address)       |          |  |<------------+-------------+-------------+-------------|          |  |             |             |             |             |          |  |4. MX Capability REQ (Supported Anchor/Delivery Links (Wi-Fi, LTE)|  +------------------------------------------------------>|          |  |5. MX Capability RSP (No Convergence/Adaptation parameters)       |  |<-----------------------------------------+------------+          |  | 6. MX Capability ACK (ACCEPT)           |             |          |  +-------------+-------------+-------------------------->|          |  |             |             |             |             |          |  |7. MX Meas Config (Wi-Fi/LTE Measurement Thresholds/Period)       |  |<------------------------------------------------------|          |  |8. MX Meas Report (LTE RSRP, UL/DL TPUT)               |          |  |-----------------------------------------+------------>|          |  |9. MX SSID Ind (List of SSIDs)           |             |          |  |<------------------------------------------------------|          |+--------------------------------------------------------------------++|         10. Wi-Fi Connection Setup and IP Address Allocation        |+-+-------------+-------------+-------------+-------------+----------++  |             |             |             |             |          |  |10. MX Reconfiguration REQ (LTE IP, Wi-Fi IP)          |          |  |-----------------------------------------+------------>|          |  |11. MX Reconfiguration RSP               |             |          |  |<------------------------------------------------------|          |+--------------------------------------------------------------------++|    Initial Condition, Data over LTE link only, Wi-Fi link is poor   |+---------------------------------------------------------+----------++  |             |             |             |             |          |  |12. MX Meas Report (Wi-Fi RSSI, LTE RSRP, UL/DL TPUT)  |+----------+  |------------------------------------------------------>||Wi-Fi link|  |             |             |             |             ||conditions|  |             |             |             |             ||reported  |  |             |             |             |             ||good      |  |             |             |             |             |+----------+  |             |             |             |             |          |  |13. MX Traffic Steering REQ (UL/DL Access, TFTs)       |+----------+  |<------------+-------------+-------------+-------------||Steer     |  |             |             |             |             ||traffic to|  |14. MX Traffic Steering RSP (...)        |             ||use Wi-Fi |  |<------------+-------------+-------------+-------------||link      |  |             |             |             |             |+----------+  |             |             |             |             |          |+--------------------------------------------------------------------++|    Use Wi-Fi link for Data                                          |+---------------------------------------------------------+----------++  |             |             |             |             |          |  +             +             +             +             +          +      </figure>    </section>    <section of MX Adaptation and MX Convergence      <t>The MAMS user plane supports multiple instances and combinations of     protocols to be used at the MX Adaptation and the Convergence Layer.</t>      <t>For example, one instance of the MX Convergence Layer can be MPTCP     Proxy and another instance can be GMA.  The MX Adaptation for each can     be either a UDP tunnel or IPsec.  IPsec may be set up when network path     needs to be secured, e.g., to protect the TCP subflow traversing the     network path between the client and the MPTCP proxy.</t>      <t>Each instance of the MAMS user plane, i.e., combination of     MX Convergence-layer and MX Adaptation-layer protocols, can coexist     simultaneously and independently handle different traffic types.</t>    </section>    <section Control-Plane        <t>The NCM functional element is hosted on a network node that is assumed to be       within a secure network, e.g., within the network, and is assumed to       be protected against hijack attacks.</t>        <t>For deployment scenarios where the client is configured (e.g., by the       network operator) to use a specific network path for exchanging control&nbhy;plane       messages and if the network path is assumed to be secure, MAMS control       messages will rely on security provided by the underlying network.</t>        <t>For deployment scenarios where the security of the network path cannot be       assumed, NCM and CCM implementations MUST support the "wss" URI scheme       <xref and Transport Layer Security (TLS)       <xref to secure the exchange of control&nbhy;plane       messages between the NCM and the CCM.</t>        <t>For deployment scenarios where client authentication is desired, the WebSocket       server can use any client authentication mechanisms available to a generic       HTTP server, such as cookies, HTTP authentication, or TLS authentication.</t>      </section>      <section User-Plane        <t>User data in the MAMS framework relies on the security of the underlying       network transport paths.  When this security cannot be assumed, the NCM       configures the use of protocols (e.g., IPsec <xref <xref in the MX Adaptation Layer, for security.</t>      </section>    </section>    <section      <t>The MAMS architecture builds on commonly available functions on terminal     devices, where these functions can be used to deliver software updates over     popular end&nbhy;user device operating systems, thereby enabling rapid     deployment and addressing the large base of deployed devices.</t>      <!-- [rfced] Section 15:  We found this sentence difficult to follow.We updated it as listed below.  If this update is incorrect, pleaseclarify the text.Original: MAMS builds on commonly available functions available on terminal devices that can be delivered as a software update over the popular end-user device operating systems, enabling rapid deployment and addressing the large deployed device base.Currently: The MAMS architecture builds on commonly available functions on terminal devices, where these functions can be used to deliver software updates over popular end-user device operating systems, thereby enabling rapid deployment and addressing the large base of deployed devices. -->      <!-- [author1] Agree with the changes. Thanks. -->    </section>    <section to Multi-Access Edge      <t>Multi-access Edge Computing (MEC), previously known as Mobile Edge     Computing, is an access-edge cloud platform being considered at     the European Telecommunications Standards Institute (ETSI)     <xref whose initial focus was to improve the QoE     by leveraging intelligence at the cellular (e.g.,     3GPP technologies like LTE) access edge, and the scope is now being     extended to support access technologies beyond 3GPP.  The applicability of     the framework described in this document to the MEC platform has been     evaluated and tested in different network configurations by the authors.</t>      <t>The NCM can be hosted on a MEC cloud server that is located in the     user&nbhy;plane path at the edge of the multi-technology access network.     The NCM and CCM can negotiate the network path combinations based on     an needs and the necessary user&nbhy;plane protocols to be used     across the multiple paths.  The network conditions reported by the     CCM to the NCM can be complemented by a Radio Analytics application     <xref residing at the MEC cloud server to configure the uplink and downlink     access paths according to changing radio and congestion conditions.</t>      <t>The user&nbhy;plane functional element, N-MADP, can either be collocated     with the NCM at the MEC cloud server (e.g., MEC&nbhy;hosted applications)     or placed at a separate network element like a common user&nbhy;plane     gateway across the multiple networks.</t>      <t>Also, even in scenarios where an N-MADP is not deployed, the NCM can be     used to augment the traffic-steering decisions at the device.</t>      <t>The aim of these enhancements is to improve the end QoE by     leveraging the best network path based on an needs and network     conditions, and building on the advantages of significantly reduced latency     and the dynamic and real-time exposure of radio network information available     at the MEC.</t>    </section>    <section Work in Other Industry and Standards      <t>The MAMS framework described in this document has been incorporated     or is proposed for incorporation as a solution to address multi&nbhy;access     integration in multiple industry forums and standards.  This section describes     the related work in other industry forums and the standards organizations.</t>      <t>Wireless Broadband Alliance industry partners have published a     white paper that describes the applicability of different technologies     for multi&nbhy;access integration to different deployments as part of their     "Unlicensed Integration with 5G Networks" project <xref     The white paper includes the MAMS framework described in this document as     a technology for integrating unlicensed (Wi&nbhy;Fi) networks with 5G networks     above the 5G core network.</t>      <t>The 3GPP is developing a technical report as part of its work item Study     on Access Traffic Steering, Switching, and Splitting (ATSSS).  That     report, TR 23.793 <xref contains a     number of potential solutions; Solution 1 in     <xref utilizes a separate control plane     for the flexible negotiation of user&nbhy;plane protocols and path     measurements in a way that is similar to the MAMS architecture described     in this document.</t>      <t>The Small Cell Forum (SCF) <xref plans to develop a     white paper as part of its work item on LTE/5G and Wi&nbhy;Fi.  There is a     proposal to include MAMS in this white paper.</t>      <t>The ETSI Multi-access Edge Computing Phase 2 technical work is examining     many aspects of this work, including use cases for optimizing QoE and     resource utilization.  The MAMS architecture and procedures outlined in this     document are included in the use cases and requirements document     <xref    </section>    <section      <t>This document has no IANA actions.</t>    </section>  </middle>  <back>      </references>        <!-- [rfced] Informative References:  RFC 6347 is not cited anywherein the text.  Please let us know where it should be cited (perhapsin the last paragraph of Section 7.2?); otherwise, this listing willbe removed.Original: [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>.-->        <!-- [author1] Added reference in Section 7.2-->        <!-- [rfced] The following references were cited in text but were notlisted in the References section.  We added listings for each of themin the Informative References section.  Please let us know anyobjections. RFC 6455 RFC 5246 (obsoleted by RFC 8446; we updated accordingly) RFC 2616 RFC 7159 (obsoleted by RFC 8259; we updated accordingly)-->        <!-- [author1] OK.-->        <!-- [rfced]** Side note:  This document only has one instance of "JSONValue."Should it have a corresponding JSON definition somewhere in thisdocument, along the lines of JSONString, JSONNumber, and JSONBool?-->        <!-- [author1] Removed mention of JSONValue which is unused in the specification.-->        <!-- [rfced]Original: For deployment scenarios where the security of the network path cannot be assumed, NCM and CCM implementations MUST support the "wss" URI scheme [RFC6455] and Transport Layer Security (TLS) [RFC5246] to secure control plane message exchange between the NCM and CCM.... For every API, there could be an error response in case the objective of API could not be met as defined in [RFC2616].... The type JSONValue indicates a JSON value, as specified in Section 3 of [RFC7159].Currently (text and Informative References): For deployment scenarios where the security of the network path cannot be assumed, NCM and CCM implementations MUST support the "wss" URI scheme [RFC6455] and Transport Layer Security (TLS) [RFC8446] to secure the exchange of control-plane messages between the NCM and the CCM.-->        <!-- [author1] OK.-->        <!-- [rfced] ... For every API, there could be an error response if the objective of the API could not be met; see [RFC2616].-->        <!-- [author1] OK.-->        <!-- [rfced] ... The type JSONValue indicates a JSON value as specified in Section 3 of [RFC8259].-->        <!-- [author1] This line has been deleted altogether, but reference to 8259 is used in Appendix C.-->        <!-- [rfced]... [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,            Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext            Transfer Protocol - HTTP/1.1", RFC 2616,            DOI 10.17487/RFC2616, June 1999,            <https://www.rfc-editor.org/info/rfc2616>.... [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",            RFC 6455, DOI 10.17487/RFC6455, December 2011,            <https://www.rfc-editor.org/info/rfc6455>.... [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>.-->        <!-- [author1] Thanks for adding the references.-->        <reference          <front>            <title>User-Plane Protocols for Multiple Access Management Service</title>            <author            </author>            <author            </author>            <author            </author>            <author            </author>            <date          </front>        </reference>        <reference          <front>            <title>Generic Multi-Access (GMA) Convergence Encapsulation Protocols</title>            <author            </author>            <author            </author>            <date          </front>        </reference>        <reference          <front>            <title>0-RTT TCP Convert Protocol</title>            <author            </author>            <author            </author>            <author            </author>            <author            </author>            <author            </author>            <date          </front>        </reference>        <reference          <front>            <title>Multipath Extensions for QUIC (MP-QUIC)</title>            <author            </author>            <author            </author>            <date          </front>        </reference>        <reference anchor="ETSIRNIS">          <front>            <title>Mobile Edge Computing (MEC) Radio Network Information API</title>            <author>              <organization>European Telecommunications Standards Institute</organization>            </author>            <date month="July" year="2017"/>          </front>        </reference>        <reference anchor="ANDSF">          <front>            <title>Access Network Discovery and Selection Function (ANDSF) Management     Object (MO)</title>            <author>              <organization>3rd Generation Partnership Project</organization>            </author>            <date month="June" year="2018"/>          </front>        </reference>        <reference anchor="ServDesc3GPP">          <front>            <title>General Packet Radio Service (GPRS); Service description; Stage 2</title>            <author>              <organization>3rd Generation Partnership Project</organization>            </author>            <date month="March" year="2019"/>          </front>        </reference>        <reference anchor="IEEE-80211">          <front>            <title>IEEE Standard for Information technology-Telecommunications and information exchange between systems - Local and metropolitan area networks-Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications</title>            <author>              <organization>IEEE</organization>            </author>            <date/>          </front>        </reference>        <reference anchor="WBAUnl5G">          <front>            <title>Unlicensed Integration with 5G Networks</title>            <author>              <organization>Wireless Broadband Alliance</organization>            </author>            <date/>          </front>        </reference>        <reference anchor="ATSSS-3GPP-TR-23793">          <front>            <title>Study on access traffic steering, switch and splitting support in the 5G System (5GS) architecture</title>            <author>              <organization>3rd Generation Partnership Project</organization>            </author>            <date month="December" year="2018"/>          </front>        </reference>        <reference anchor="ITU-E212">          <front>            <title>The international identification plan for public networks and subscriptions</title>            <author>              <organization>International Telecommunication Union</organization>            </author>            <date month="September" year="2016"/>          </front>        </reference>        <reference anchor="SCFTECH5G">          <front>            <title>Small Cell Forum</title>            <author/>            <date/>          </front>        </reference>        <reference anchor="ETSIMEC">          <front>            <title>Multi-access Edge Computing (MEC)</title>            <author>              <organization>European Telecommunications Standards Institute</organization>            </author>            <date/>          </front>        </reference>        <reference anchor="ETSIMAMS">          <front>            <title>Multi-access Edge Computing (MEC); Phase 2: Use Cases and Requirements   </title>            <author>              <organization>European Telecommunications Standards Institute</organization>            </author>            <date month="October" year="2018"/>          </front>        </reference>      </references>    <section Control-Plane Optimization over Secure      <t>This appendix is informative, and provides indicative information     about how MAMS operates.</t>      <t>If the connection between the CCM and the NCM over which the MAMS     control&nbhy;plane messages are transported is assumed to be secure, UDP is     used as the transport for management and control messages between the     NCM and the CCM (see <xref      <figure MAMS Control-Plane Protocol        <artwork+-----------------------------------------------------+|        Multi-Access (MX) Control Message            ||-----------------------------------------------------||                      UDP                            ||-----------------------------------------------------|      </figure>    </section>    <section Application      <t>This appendix describes the MAMS Application Interface.  It does not     provide normative text for the definition of the MAMS framework or protocols,     but offers additional information that may be used to construct a system     based on the MAMS framework.</t>      <section        <t>The CCM hosts an HTTPS server for applications to communicate and request       services.  This document assumes, from a security point of view, that       all CCMs and the communicating application instances are hosted in a       single administrative domain.</t>        <!-- [rfced] Appendix B.1:  Does "all CCM and the communicatingApplication instances" mean "all CCMs and the communicatingapplication instances," "all CCM instances and communicatingapplication instances," or something else?Original: It is assumed in this draft that all CCM and the communicating Application instances are hosted in a single administrative domain from security point of view.Possibly (guessing that "all CCMs" might be correct): This document assumes, from a security point of view, that all CCMs and the communicating application instances are hosted in a single administrative domain.-->        <!-- [author1] Agreed and incorporated the suggested change.-->        <t>The content of messages is desecribed in JavaScript Object Notation (JSON)       format.  They offer RESTful APIs for communication.</t>        <t>The exact mechanism regarding how the application knows about the endpoint of       the CCM is out of scope for this document.  This mechanism may instead be       provided as part of the application settings.</t>      </section>      <section        <t>The documentation of APIs is provided in the OpenAPI format, using       Swagger v2.0. See <xref        <!-- [rfced] Appendix B.2:  Please clarify "TBD - Add section inappendix" here.  Is some text missing?  (Perhaps "(TBD - Add sectionin appendix)" should be "(Appendix D)" (where we see "OpenAPI" and"Swagger 2.0" mentioned again)?Original: The documentation of APIs are provided in OpenAPI format using swagger v2.0 (TBD - Add section in appendix)-->        <!-- [author1] replaced TBD with reference to appropriate section-->      </section>      <section        <t>For every API, there could be an error response if the objective of the API       could not be met; see <xref      </section>      <section        <t>The following subsections describe the APIs exposed by the CCM to the       applications.</t>        <section          <t>The CCM provides an HTTPS GET interface as "/ccm/v1.0/capabilities" for the            application to query the capabilities supported by the CCM instance.</t>          <figure API - GET            <artwork+---------+                                            +------------+|         |                                            |            ||   App   |--------- HTTPS GET / Capabilities -------->|     CCM    ||         |                                            |            |+---------+                                            +------------+          </figure>          <t>The CCM shall provide information regarding its capabilities as follows: Features: One of more of the "Feature Name" values, as defined                 in the MX Feature Activation List parameter of the MX Capability REQ                 message (<xref            <!-- [rfced] Appendix B.4.1:  It appears that some words are missingfrom this sentence.  Please clarify "One of more of as defined."Original: o  Supported Features: One of more of as defined in MX Feature    Activation List parameter of MX Capability REQ.-->            <!-- [author1] Rephrased to address the comment.--> Connections: Supported connection types and connection MX Adaptation Layers: List of MX Adaptation Layer protocols                 supported by the N-MADP instance, along with the connection type where these                 are supported and their respective MX Convergence Layers: List of supported MX Convergence Layer                 protocols, along with the parameters associated with the respective convergence        </section>        <section Application          <t>The CCM provides an HTTPS POST interface as "/ccm/v1.0/app_requirements" for            the application to post the needs of the application data streams to the CCM            instance.</t>          <figure API - POST            <artwork+---------+                                            +-----------+|         |                                            |           ||   App   |----------HTTPS POST / App Requirements---->|    CCM    ||         |                                            |           |+---------+                                            +-----------+          </figure>          <t>The CCM shall provide for the application to post the following requirements            for its different data streams: of Data Stream            <!-- [rfced] Appendix B.4.2:  Please clarify the meaning of"For each data stream type, the following link feature preferences,"Original: o  Number of data stream types For each data stream type, the    following link feature preferences,-->            <!-- [author1] Two bullets got merged into one by mistake. Fixed that and alsorephrased to address the comment for clarifying text.-->              <t>For each data stream type, specify the following parameters for the link,                  which are preferred by the Application: Type: Transport-layer protocol associated with the application data                       stream Range: Supported connection types and connection                  <t>Traffic QoS: Quality of service parameters, as follows:        </section>        <section Predictive Link          <t>The CCM provides an HTTPS GET interface as "/ccm/v1.0/predictive_link_params" for            the application to get the predicted link parameters from the CCM instance.</t>          <figure API - Getting Predictive Link            <artwork+---------+                                             +-----------+|         |                                             |           ||   App   |-------HTTPS GET / Predictive Link Params--->|    CCM    ||         |                                             |           |+---------+                                             +-----------+          </figure>          <t>The CCM asks the NCM for link parameters via the MAMS Network Analytics            Request Procedure (<xref and includes            the information in response to the API invocation.              <t>Number of Delivery Connections.                 For each delivery connection, include the following:                  <t>Access Link Identifier:                  <t>Link Quality Indicator                      <t>Bandwidth: Value Validity (Validity Time, in                      <t>Jitter: Value (in Validity (Validity Time, in                      <t>Latency: Value (in Validity (Validity Time, in                      <t>Signal Quality delivery connection type is "LTE", LTE_RSRP Predicted Value delivery connection type is "LTE", LTE_RSRQ Predicted Value delivery connection type is "5G NR", NR_RSRP Predicted Value delivery connection type is "5G NR", NR_RSRQ Predicted Value delivery connection type is "Wi-Fi", WLAN_RSSI Predicted Value Validity (Validity Time, in        </section>      </section>    </section>    <section Control Plane Messages Described Using      <t>MAMS control-plane messages are exchanged between the CCM and the     NCM.  This non-normative appendix describes the format and content of     messages using JSON <xref      <section Specification: General        <section          <t>This document uses JSONString, JSONNumber, and JSONBool to         indicate the JSON string, number, and boolean types,         respectively.</t>          <t>This document uses an adaptation of the C-style struct         notation to describe JSON objects.  A JSON object consists of         name/value pairs.  This document refers to each pair as a         field.  In some contexts, this document also refers to a field as         an attribute.  The name of a field/attribute may be referred to         as the key.  An optional field is enclosed by "[ ]".  In the         definitions, the JSON names of the fields are case         sensitive.  An array is indicated by two numbers in angle         brackets, &lt;m..n&gt;, where m indicates the minimal number of         values and n is the maximum.  When this document uses * for n,         it means no upper bound.</t>          <t>For example, the text below describes a new type Type4, with         three fields: "name1", "name2", and "name3", respectively. The         "name3" field is optional, and the "name2" field  is an array         of at least one value.</t>    object { Type1 name1; Type2 name2 <1..*>; [Type3 name3;] } Type4;          <t>This document uses subtyping to denote that one type is derived from         another type.  The example below denotes that TypeDerived is derived         from TypeBase.  TypeDerived includes all fields defined in TypeBase.         If TypeBase does not have a "name1" field, TypeDerived will have a         new field called "name1".  If TypeBase already has a field called         "name1" but with a different type, TypeDerived will have a         field called "name1" with the type defined in TypeDerived         (i.e., Type1 in the example).</t>    object { Type1 name1; } TypeDerived : TypeBase;          <t>Note that, despite the notation, no standard, machine-readable         interface definition or schema is provided in this document. Extension         documents may describe these as necessary.</t>          <!-- [author1] Added text below, per [rfced] suggestion to address long JSON strings, similar to that in RFC 8620-->          <t>For compatibility with publishing requirements, line breaks have been         inserted inside long JSON strings, with the following continuation         lines indented.  To form the valid JSON example, any line breaks         inside a string must be replaced with a space and any other white         space after the line break removed.</t>        </section>        <section Discover            <t>This message is the first message sent by the CCM to discover the            presence of NCM in the network.  It contains only the base information            as described in <xref with message_type set as            mx_discover.</t>            <t>The representation of the message is as follows:</t>      object {         [JSONString MCC_MNC_Tuple;]      } MXDiscover : MXBase;          </section>        </section>        <section Information          <section System Information            <t>This message is sent by the NCM to the CCM to inform the            endpoints that the NCM supports MAMS functionality.  In addition to            the base information (<xref it contains the            following information: Connections (<xref            <t>The representation of the message is as follows:</t>      object {         NCMConnections ncm_connections;      } MXSystemInfo : MXBase;          </section>        </section>        <section Exchange          <section Capability            <t>This message is sent by the CCM to the NCM to indicate the capabilities            of the CCM instance available to the NCM indicated in the System Info            message earlier.  In addition to the base information (<xref            it contains the following information: and their activation status: See <xref of Anchor Connections: The number of anchor connections (toward the                 core) supported by the connections: See <xref of Delivery Connections: The number of delivery connections                 (toward the access) supported by the connections: See <xref methods: See <xref methods: See <xref            <t>The representation of the message is as follows:</t>      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;          </section>          <section Capability            <t>This message is sent by the NCM to the CCM to indicate the            capabilities of the NCM instance and unique session identifier            for the CCM.  In addition to the base information (<xref            it contains the following information: and their activation status: See <xref of Anchor Connections: The number of anchor connections              (toward the core) supported by the connections: See <xref of Delivery Connections: The number of delivery connections                 (toward the access) supported by the connections: See <xref methods: See <xref methods: See <xref Session ID: This uniquely identifies the session between the                 CCM and the NCM in a network. See <xref            <t>The representation of the message is as follows:</t>      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 : MXBase;          </section>          <section Capability            <t>This message is sent by the CCM to the NCM to indicate acceptance of            capabilities advertised by the NCM in an earlier MX Capability Response            message. In addition to the base information (<xref            it contains the following information: Session ID: Same identifier as the identifier provided in                 the MX Capability RSP. See <xref Acknowledgment: Indicates either acceptance or rejection                 of the capabilities sent by the CCM. Can use either "MX_ACCEPT" or                "MX_REJECT" as acceptable            <t>The representation of the message is as follows:</t>      object {         UniqueSessionId unique_session_id;         JSONString capability_ack;      } MXCapabilityAck : MXBase;          </section>        </section>        <section Configuration          <section User-Plane Configuration            <t>This message is sent by the NCM to the CCM to configure the user            plane for MAMS.  In addition to the base information (<xref it contains the following information: of Anchor Connections: The number of anchor connections supported by the of anchor connections: See <xref            <t>The representation of the message is as follows:</t>      object {         JSONNumber num_anchor_connections;         SetupAnchorConns anchor_connections;      } MXUPSetupConfigReq : MXBase;          </section>          <section User-Plane Configuration            <t>This message is the confirmation of the user&nbhy;plane setup            message sent from the CCM after successfully configuring the            user plane on the user equipment.  This message contains the            following information: Session ID: Same identifier as the identifier provided in the MX Capability RSP. See <xref                <t>MX probe parameters (included if probing is supported). Port: UDP port for accepting probe connection ID: Identifier of the anchor connection to be                      used for probe function. Provided in the user&nbhy;plane setup Configuration ID: This parameter is included, only, if the MX                      Configuration ID parameter is available from the user&nbhy;plane                      setup configuration.  Indicates MX configuration ID of the anchor                      connection to be used for probe                  <!-- [rfced] Appendix C.1.5.2:  This sentence does not parse  Pleaseclarify "connection, which configuration id is to be used for probe,this ..."Original: (3)  MX Configuration Id: For the given anchor connection, which      configuration id is to be used for probe, this is present      only if provided in the user plane setup request.-->                  <!-- [author1] Rephrased to address the comment to clarify the text.-->                <t>The following information is required for each delivery connection: ID: Delivery connection ID supported by Adaptation-Layer Parameters: If the UDP Adaptation Layer                      is in use, then the UDP port to be used on the C&nbhy;MADP            <t>The representation of the message is as follows:</t>      object {         UniqueSessionId unique_session_id;         [ProbeParam probe_param;]         JSONNumber num_delivery_conn;         ClientParam client_params <1...*>;      } MXUPSetupConfigCnf : MXBase;            <t>Where ProbeParam is defined as follows:</t>      object {         JSONNumber probe_port;         JSONNumber anchor_conn_id;         [JSONNumber mx_configuration_id;]      } ProbeParam;            <t>Where ClientParam is defined as follows:</t>      object {         JSONNumber connection_id;         [AdaptationParam adapt_param;]      } ClientParam;            <t>Where AdaptationParam is defined as follows:</t>      object {         JSONNumber udp_adapt_port;      } AdaptationParam;          </section>        </section>        <section          <section            <t>This message is sent by the CCM to the NCM in the case of            reconfiguration of any of the connections from the user            side.  In addition to the base information (<xref it            contains the following information: Session ID: Identifier for the CCM-NCM association <xref Action: The reconfiguration action type can be one                 of "setup", "release" or ID: Connection ID for which the reconfiguration is                 taking address: Included, if Reconfiguration Action is "setup" or              <!-- [rfced] Appendix C.1.6.1:  Please clarify the meaning of"IP address in case of setup and modify type of reconfiguration."Original: (d)  IP address: IP address in case of setup and modify type of      reconfiguration.-->              <!-- [author1] Rephrased to address the comment to clarify the text.--> If the connection type is Wi&nbhy;Fi, in that case the SSID the                 UE has attached to is contained in this parameter. of the connection: The MTU of the delivery path that is                 calculated at the UE for use by the NCM to configure fragmentation and                 concatenation procedures at the Status: This parameter indicates whether the connection is currently "disabled", "enabled" or "connected". Default: Node ID: Identity of the node to which the client is                 attached.  ECGI in the case of LTE, and a Wi&nbhy;Fi AP ID or a                 MAC address in the case of            <t>The representation of the message is as follows:</t>      object {         UniqueSessionId unique_session_id;         JSONString reconf_action;         JSONNumber connection_id;         JSONString ip_address;         JSONString ssid;         JSONNumber mtu_size;         JSONString connection_status;         [JSONString delivery_node_id;]      } MXReconfReq : MXBase;            <!-- [rfced] Appendix C.1.6.1:  We changed "JSONSring" to"JSONString" here.  Please let us know any concerns (i.e., is"JSONSring" an unchangeable string in code?).Original: [JSONSring delivery_node_id;]Currently: [JSONString delivery_node_id;]-->            <!-- [author1] OK.-->          </section>          <section            <t>This message is sent by the NCM to the CCM as a confirmation of the            received Reconfiguration Request message and contains only the base            information (as defined in <xref            <!-- [rfced] Appendix C.1.6.2:  We had trouble following thissentence.  Please clarify "confirmation towards reconfigurationrequirement" and "taking the reconfiguration into use."Original: This message is sent by NCM to CCM as a confirmation towards reconfiguration requirement after taking the reconfiguration into use and contains only the base information (as defined in Appendix C.2.1).-->            <!-- [author1] Rephrased to address the comment to clarify the text.-->            <t>The representation of the message is as follows:</t>      object {      } MXReconfRsp : MXBase;          </section>        </section>        <section Estimation          <section Estimation            <t>This message is sent by the NCM toward the CCM to configure the CCM to            send Path Estimation Results.  In addition to the base information (<xref it contains the following information: ID: ID of the connection for which the path estimation report is Probe Test Duration: Duration of initial probe test, in Probe Test Rate: Initial testing rate, in megabits per Probe Size: Size of each packet for initial probe, in Probe ACK: If an acknowledgment for probe is required. (Possible values: "yes", Probe Frequency:  Frequency, in milliseconds, at which the active probes shall be Probe Size: Size of the active probe, in Probe Duration: Duration, in seconds, for which the active probe shall be              <!-- [rfced] Appendix C.1.7.1:  Please provide the missinginformation for the following "TBD" items.Original: (b)  Init Probe Test Duration: Duration of initial probe test in      milliseconds.  [TBD: Range of values] (c)  Init Probe Test Rate: Initial testing rate in Mega Bits per      Second.  [TBD: Range of values] (d)  Init Probe Size: Size of each packet for initial probe in Bytes.      [TBD: Range of values] (e)  Init Probe Ack: If an acknowledgement for probe is required.      [Possible values: "yes", "no"] (f)  Active Probe Frequency: Frequency in milliseconds at which the      active probes shall be sent.  [TBD: Range of values] (g)  Active Probe Size: Size of the active probe in Bytes.  [TBD:      Range of values] (h)  Active Probe Duration: Duration in seconds for which the active      probe shall be performed.  [TBD.  Range of values]-->              <!-- [author1] Removed TBD. The specification of these values is outside the scope of this document.--> Probe ACK: If an acknowledgment for probe is required. (Possible values: "yes",            <t>The representation of the message is as follows:</t>      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;          </section>          <section Estimation            <t>This message is sent by the CCM to the NCM as report to the probe estimation configured            by the NCM.  In addition to the base information (<xref it contains            the following information: Session ID: Same identifier as the identifier provided in the MX Capability                 RSP.  See <xref ID: ID of the connection for which the Path Estimation Results message is Probe Results: See <xref Probe Results: See <xref            <t>The representation of the message is as follows:</t>      object {         JSONNumber connection_id;         UniqueSessionId unique_session_id;         [InitProbeResults init_probe_results;]         [ActiveProbeResults active_probe_results;]      } MXPathEstResults : MXBase;          </section>        </section>        <section          <section Steering Request            <t>This message is sent by the NCM to the CCM, to enable traffic            steering on the delivery side in uplink and downlink            configurations. In addition to the base information (<xref it contains the following information: ID: Anchor connection number for which the traffic steering is being Configuration ID: MX configuration for which the traffic steering is being Delivery: See <xref UL Delivery: The default delivery connection                 for the uplink.  All traffic should be delivered on this                 connection in the uplink direction, and the Traffic Flow                 Template (TFT) filter should be applied only for the traffic                 mentioned in Uplink Delivery: See <xref and their activation status: See <xref            <t>The representation of the message is as follows:</t>      object {         JSONNumber connection_id;         [JSONNumber mx_configuration_id;]         DLDelivery downlink_delivery;         JSONNumber default_uplink_delivery;         ULDelivery uplink_delivery;         FeaturesActive feature_activation;      } MXTrafficSteeringReq : MXBase;            <!-- [rfced] Appendices C.1.8.1 and C.1.8.2:  Should"MXTraffiSteeringReq" and "MXTraffiSteeringResp" be"MXTrafficSteeringReq" and "MXTrafficSteeringResp"?(In other words, the "c" in "Traffic" appears to be missing.)Original: } MXTraffiSteeringReq : MXBase;... } MXTraffiSteeringResp : MXBase;-->            <!-- [author1] OK. Thanks.-->          </section>          <section Steering Response            <t>This message is a response to a Traffic Steering Request from            the CCM to the NCM. In addition to the base information (<xref            it contains the following information: Session ID: Same identifier as the identifier provided in the MX Capability RSP. See <xref and their activation status: See <xref            <t>The representation of the message is as follows:</t>      object {         UniqueSessionId unique_session_id;         FeaturesActive feature_activation;      } MXTrafficSteeringResp : MXBase;          </section>        </section>        <section Application MADP          <section Application MADP Association            <t>This message is sent by the CCM to the NCM to select MADP instances            provided earlier in the user-plane setup request, based on requirements for the            applications.</t>            <t>In addition to the base information (<xref it contains the following: Session ID: This uniquely identifies the session between the CCM and                 the NCM in a network.  See <xref                <t>A list of MX Application MADP Associations, with each entry as follows:<!-- [rfced] Appendix C.1.9.1:  This sentence did not parse.We updated it as follows.  Please let us know if this is incorrect.Original: Described in Appendix C.2.2, and a list of following MX Application MADP AssociationsCurrently: See Appendix C.2.2.  A list of MX Application MADP Associations is as follows:--><!-- [author1] Accepted with modifications to clarify the text.--> ID: Represents the anchor connection number of the MADP Configuration ID: Identifies the MX configuration of the MADP Flow Template Uplink: Traffic Flow Template, as defined in <xref to be used in                      the uplink Flow Template Downlink: Traffic Flow Template, as defined in <xref to be used                      in the downlink                  <!-- [rfced] Appendix C.1.9.1:  This document does not have aSection 5.16.  Please clarify the meaning of "defined in 5.16."Original: (c)  Traffic Template Uplink: Traffic template as defined in      5.16 to be used in uplink direction. (d)  Traffic Template Downlink: Traffic template as defined in      5.16 to be used in downlink direction.-->                  <!-- [author1] Fixed hard-code reference.-->            <t>The representation of the message is as follows:</t>      object {         UniqueSessionId unique_session_id;         MXAppMADPAssoc app_madp_assoc_list <1..*>;      } MXAppMADPAssocReq : MXBase;            <t>Where each measurement MXAppMADPAssoc is represented by the following:</t>      object {         JSONNumber connection_id;         JSONNumber mx_configuration_id         TrafficFlowTemplate tft_ul_list <1..*>;         TrafficFlowTemplate tft_dl_list <1..*>;      } MXAppMADPAssoc;          </section>          <section Application MADP Association            <t>This message is sent by the NCM to the CCM to confirm the selected MADP instances provided in request message by the CCM.</t>            <t>In addition to the base information (<xref it contains information if the request has been successful.</t>            <t>The representation of the message is as follows:</t>      object {         JSONBool is_success;      } MXAppMADPAssocResp : MXBase;          </section>        </section>        <section          <t>This message is sent by the NCM to the CCM to indicate         the list of allowed SSIDs that are supported by the MAMS entity on the         network side.  It contains the list of SSIDs.</t>          <t>Each SSID consists of the type of SSID (which can be one of         the "SSID", "BSSID", or "HESSID" and the SSID itself.</t>          <t>The representation of the message is as follows:</t>      object {         SSID ssid_list <1..*>;      } MXSSIDIndication : MXBase;          <t>Where each SSID is defined as follows:</t>      object {         JSONString ssid_type;         JSONString ssid;      } SSID;        </section>        <section          <section            <t>This message is sent from the NCM to the CCM to configure the            period measurement reporting at the CCM.  The message contains a list            of measurement configurations, with each element containing the            following information: ID: Connection ID of the delivery connection for which the reporting is being Type: Connection type for which the reporting is being configured. Can be "LTE", "Wi-Fi", "5G Report Configuration: Actual report configuration based on the Connection Type, as defined in <xref            <t>The representation of the message is as follows:</t>      object {         MeasReportConf measurement_configuration <1..*>;      } MXMeasReportConf : MXBase;            <t>Where each measurement MeasReportConf is represented by the following:</t>      object {         JSONNumber connection_id;         JSONString connection_type;         MeasReportConfs meas_rep_conf <1..*>;      } MeasReportConf;          </section>          <section            <t>This message is periodically sent by the CCM to the NCM after measurement configuration.  In            addition to the base information, it contains the following information: Session ID: Same identifier as the identifier provided in the MX Capability RSP. Described in <xref report for each delivery connection is measured by the client device as defined in <xref            <t>The representation of the message is as follows:</t>      object {         UniqueSessionId unique_session_id;         MXMeasRep measurement_reports <1..*>;      } MXMeasurementReport : MXBase;            <!-- [rfced] Appendices C.1.11.2, C.3.20, and C.4.18:  Should thethree instances of "measurment_reports" be "measurement_reports"or perhaps "measurement_report" (per "mx_measurement_report" usedelsewhere)?  (In other words, are these strings parts of code thatcannot be modified, or can we correct the spelling of "measurment"?)Original: MXMeasRep measurment_reports <1..*>;... "measurment_reports": {... "measurment_reports" : [-->            <!-- [author1] Suggested changes are correct. Thanks.-->          </section>        </section>        <section            <t>A Keep-Alive Request message can be sent from either the NCM or            the CCM on expiry of the MAMS_KEEP_ALIVE timer or a handover event.            The peer shall respond to this request with a Keep-Alive Response.            In the case of no response from the peer, the MAMS connection shall be            assumed to be broken, and the CCM shall establish a new connection by            sending MX Discover messages.</t>            <t>In addition to the base information, it contains the following            information: Reason: Reason for sending this message, can be "Timeout" or Session ID: Identifier for the CCM-NCM association <xref ID: Connection ID for which handover is detected, if the reason is Node ID: The target delivery node ID (ECGI or Wi&nbhy;Fi Access Point ID/MAC) to which the handover is            <t>The representation of the message is as follows:</t>      object {         JSONString keep_alive_reason;         UniqueSessionId unique_session_id;         JSONNumber connection_id;         JSONString delivery_node_id;      } MXKeepAliveReq : MXBase;          </section>          <section            <t>On receiving a Keep-Alive Request from a peer, the NCM/CCM shall            immediately respond with a Keep-Alive Response message on the same            delivery path from where the request arrived.  In addition to the base            information it contains the unique session identifier for the CCM-NCM            association (defined in <xref            <t>The representation of the message is as follows:</t>      object {         UniqueSessionId unique_session_id;      } MXKeepAliveResp : MXBase;          </section>        </section>        <section Termination          <section Terminate            <t>In the event where the NCM or CCM can no longer handle MAMS for any            reason, it can send an MX session termination request to the peer.  In            addition to the base information, it contains a Unique Session ID and            the reason for the termination; this can be "MX_NORMAL_RELEASE",            "MX_NO_RESPONSE", or "INTERNAL_ERROR".</t>            <t>The representation of the message is as follows:</t>      object {         UniqueSessionId unique_session_id;         JSONString reason;      } MXSessionTerminationReq : MXBase;          </section>          <section Terminate            <t>On receipt of an MX session termination request from a peer, the            NCM/CCM shall respond with MX Session Termination Response on the same            delivery path where the request arrived and clean the            MAMS&nbhy;related resources and settings.  The CCM shall reinitiate a            new session with MX Discover messages again.</t>            <t>The representation of the message is as follows:</t>        object {           UniqueSessionId unique_session_id;        } MXSessionTerminationResp : MXBase;          </section>        </section>        <section          <section Network Analytics            <t>This message is sent by the CCM to the NCM to request parameters like            bandwidth, jitter, latency, and signal quality predicted by the network analytics function.            In addition to the base information, it contains the following parameter: Session ID: Same identifier as the identifier provided in the MX Capability RSP.  Described in <xref List: List of parameters in which the CCM is interested: one or more of "bandwidth", "jitter", "latency" and            <t>The representation of the message is as follows:</t>      object {         UniqueSessionId unique_session_id;         JSONString params <1..*>;      } MXNetAnalyticsReq : MXBase;            <t>Where the params object can take one or more of the following values:</t>      "bandwidth"      "jitter"      "latency"      "signal_quality"          </section>          <section Network Analytics            <t>This message is sent by the NCM to the CCM in response to the analytics            request.  For each delivery connection that the client has, the NCM reports the            requested parameter predictions and their respective likelihoods            (between 1 and 100 percent).</t>            <t>In addition to the base information, it contains the following parameters: of Delivery Connections: The number of delivery connections                 that are currently configured for the                <t>The following information is provided for each delivery connection: ID: Connection ID of the delivery connection for which the parameters are being Type: Type of connection. Can be "Wi-Fi", "5G NR", "MulteFire", or                    <t>List of Parameters for which Prediction is requested, where each of the                      predicted parameters consists of the following: Name: Name of the parameter being predicted. Can be one                           of "bandwidth", "jitter", "latency", or Parameter: If Parameter name is "signal_quality",                           then this qualifies the quality parameter like "lte_rsrp",                           "lte_rsrq", "nr_rsrp", "nr_rsrq", or Value: Provides the predicted value of the parameter                           and, if applicable, the additional Provides a stochastic likelihood of the predicted                      <!-- [rfced] Appendix C.1.14.2:* "Likelihood":  Does "of about" mean "of approximately,""regarding," or something else?* "Validity Time":  Please clarify "time horizon until which the."Original: (d)  Likelihood: Provides a stochastic likelihood of about       the predicted value. (e)  Validity Time: the time horizon until which the      predictions are valid.-->                      <!-- [author1] Rephrased to address the comment to clarify the text.--> Time: The time duration for which the predictions are            <t>The representation of the message is as follows:</t>      object {         MXAnalyticsList param_list <1..*>;      } MXNetAnalyticsResp : MXBase;            <!-- [rfced] Appendix C.1.14.2:  We removed what appeared to be anextra ">" here.  (This was the only such instance of a double">>" in this document.)  Please let us know if this is incorrect.Original: MXAnalyticsList param_list<1..*>>;Currently: MXAnalyticsList param_list<1..*>;-->            <!-- [author1] Suggested change is correct. Thanks.-->            <t>Where MXAnalyticsList is defined as follows:</t>      object {         JSONNumber connection_id;         JSONString connection_type;         ParamPredictions predictions <1..*>;      } MXAnalyticsList;            <t>Where each ParamPredictions item is defined as:</t>      object {         JSONString param_name;         [JSONString additional_param;]         JSONNumber prediction;         JSONNumber likelihood;         JSONNumber validity_time;      } ParamPredictions;          </section>        </section>      </section>      <section Specification: Data        <section          <t>This is the base information that every message between the         CCM and NCM exchanges shall have as mandatory information. It         contains the following information: Version of MAMS Type: Message type being sent, where the following              are considered valid      "mx_discover"      "mx_system_info"      "mx_capability_req"      "mx_capability_resp"      "mx_capability_ack"      "mx_up_setup_conf_req"      "mx_up_setup_cnf"      "mx_reconf_req"      "mx_reconf_rsp"      "mx_path_est_req"      "mx_path_est_results"      "mx_traffic_steering_req"      "mx_traffic_steering_rsp"      "mx_ssid_indication"      "mx_keep_alive_req"      "mx_keep_alive_rsp"      "mx_measurement_conf"      "mx_measurement_report"      "mx_session_termination_req"      "mx_session_termination_resp"      "mx_app_madp_assoc_req"      "mx_app_madp_assoc_resp"      "mx_network_analytics_req"      "mx_network_analytics_resp" Number: Sequence number to uniquely identify a              particular message exchange, e.g., MX Capability          <t>The representation of this data type is as follows:</t>      object {         JSONString version;         JSONString message_type;         JSONNumber sequence_num;      } MXBase;        </section>        <section Session          <t>This data type represents the unique session ID between a CCM         and NCM entity.  It contains a NCM ID that is unique in the         network and a session ID that is allocated by the NCM for that         session.  On receipt of the MX Discover message, if the session         exists, then the old session ID is returned in the MX System Info         message; otherwise, the NCM allocates a new session ID for the CCM         and sends the new ID in the MX System Info message.</t>          <t>The representation of this data type is as follows:</t>      object {         JSONNumber ncm_id;         JSONNumber session_id;      } UniqueSessionId;        </section>        <section          <t>This data type represents the connection available at the NCM for MAMS         connectivity toward the user equipment. It contains a list of NCM         connections available, where each connection has the following         information: Information: See <xref Endpoint Information: Contains the IP address and port exposed by the NCM endpoint for the          <t>The representation of this data type is as follows:</t>      object {         NCMConnection items <1..*>;      } NCMConnections;          <t>where NCMConnection is defined as:</t>      object {         NCMEndPoint ncm_end_point;      } NCMConnection : ConnectionInfo;          <t>where NCMEndPoint is defined as:</t>      object {         JSONString ip_address;         JSONNumber port;      } NCMEndPoint;        </section>        <section          <t>This data type provides the mapping of connection ID and connection type.  It contains the following information: ID: Unique Number identifying the            <!-- [rfced] Appendix C.2.4:  An "and" relationship is shown here.Should "and" be "or"?  It is not clear from the lists of optionsshown elsewhere in this document whether an "and" or "or"relationship is indicated.  Please clarify.Original (we added the missing closing quotes for the two instances  of ' "Wi-Fi, '  in the original): (a)  Connection Id: Number indicating the connection can be 0,1,2 and      3. (b)  Connection type: Type of connect can be "Wi-Fi, "5G NR", "Multi-      Fire" and "LTE". The two are considered a mapping like 0-"Wi-Fi", 1-"5G NR", 2-"Multi- Fire" and 3-"LTE".As shown elsewhere (9 instances, with a discrepancy: "2: Multi-Fire;"  and "2-"Multi-Fire" here, versus "2: MulteFire;" elsewhere): Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: LTE)Notes:  We also see the following:* both "wifi" and "wi-fi" for connection type* two enum lists that show "multi-fire"* both "5G NR" and "5g-nr"From Appendix C.1.11.1: (b)  Connection Type: Connection Type for which the reporting is      being configured, can be "lte", "wifi", "5g-nr" etc.From Appendix C.1.14.2: (b)  Connection Type: Type of connection, can be "Wi-Fi, "5G      NR", "Multi-Fire" and "LTE".-->            <!-- [author1] This error had crept into the spec from an earlier version of implementation.Fixed the definitions to make clear and consistent distinction between the two parameters.The Connection ID is a number that uniquely identifies the connection.The Connection Type is a separate attribute which can one of the following values - "Wi-Fi", "5G NR", "MulteFire", "LTE".--> Type: Type of connection can be "Wi-Fi", "5G NR", "MulteFire", or          <t>The representation of this data type is as follows:</t>      object {         JSONNumber connection_id;         JSONString connection_type;      } ConnectionInfo;        </section>        <section and Their Activation          <t>This data type provides the list of all features with their         activation status. Each feature status contains the following: Name: The name of the feature can be one of      "lossless_switching"      "fragmentation"      "concatenation"      "uplink_aggregation"      "downlink_aggregation"      "measurement" status: Activation status of the feature.  "true" means that the feature is active, and            "false" means that the feature is          <t>The representation of this data type is as follows:</t>      object {         FeatureInfo items <1..*>;      } FeaturesActive;          <t>where FeatureInfo is defined as:</t>      object {         JSONString feature_name;         JSONBool active;      } FeatureInfo;        </section>        <section          <t>This data type contains the list of Connection Information items         (<xref that are supported on the anchor (core) side.</t>          <t>The representation of this data type is as follows:</t>      object {         ConnectionInfo items <1..*>;      } AnchorConnections;        </section>        <section          <t>This data type contains the list of Connection Information (<xref that are supported on the delivery (access) side.</t>          <t>The representation of this data type is as follows:</t>      object {         ConnectionInfo items <1..*>;      } DeliveryConnections;        </section>        <section          <t>This data type provides the support for a particular convergence or         adaptation method. It consists of the following: Name of the Whether the method listed above is supported or not.  Possible values are "true" and          <t>The representation of this data type is as follows:</t>      object {         JSONString method;         JSONBool supported;      } MethodSupport;        </section>        <section          <t>This data type contains the list of all convergence methods and         their support status. The possible convergence methods are:</t>      "GMA"      "MPTCP_Proxy"      "GRE_Aggregation_Proxy"      "MPQUIC"          <t>The representation of this data type is as follows:</t>      object {         MethodSupport items <1..*>;      } ConvergenceMethods;        </section>        <section          <t>This data type contains the list of all convergence methods         and their support status. The possible convergence methods are:</t>      "UDP_without_DTLS"      "UDP_with_DTLS"      "IPsec"      "Client_NAT"          <t>The representation of this data type is as follows:</t>      object {         MethodSupport items <1..*>;      } AdaptationMethods;        </section>        <section of Anchor          <t>This data type represents the setup configuration for each anchor         connection that is required on the user side. It         contains the following information, in addition to the connection ID         and type of the anchor connection: of Active MX Configurations: If more than one active              configuration is present for this anchor, then this identifies the              number of such              <t>The following convergence parameters are provided for each active              configuration: Configuration Identifier: Present if there are multiple active                   configurations. Identifies the configuration for this MADP                   instance Method: Convergence method selected. Has to be one of                   the supported convergence methods listed in                   <xref Method Parameters: Described in <xref of Delivery Connections: The number of delivery connections                   (access side) that are supported for this anchor of delivery connections: Described in <xref          <t>The representation of this data type is as follows:</t>      object {         SetupAnchorConn items <1..*>;      } SetupAnchorConns;          <t>Where each anchor connection configuration is defined as follows:</t>      object {         [JSONNumber num_active_mx_conf;]         ConvergenceConfig convergence_config      } SetupAnchorConn : ConnectionInfo;          <t>where each Convergence configuration is defined as follows:</t>      object {         [JSONNumber mx_configuration_id;]         JSONString convergence_method;         ConvergenceMethodParam convergence_method_params;         JSONNumber num_delivery_connections;         SetupDeliveryConns delivery_connections;      } ConvergenceConfig;          <section Method            <t>This data type represents the parameters used for the           convergence method and contains the following: IP: IP address of the proxy that is provided by the                selected convergence Port: Port of the proxy that is provided by the selected                convergence            <t>The representation of this data type is as follows:</t>      object {         JSONString proxy_ip;         JSONString proxy_port;         JSONString client_key;      } ConvergenceMethodParam;          </section>          <section Delivery            <t>This is the list of delivery connections and their parameters           to be configured on the user equipment. Each delivery connection           defined by its connection information (<xref optionally contains the following: Method: Selected adaptation method name. This shall                be one of the methods listed in <xref                <t>Adaptation Method Parameters: Depending on the adaptation                method, one or more of the following parameters shall be provided. IP Port header optimization: If the adaptation method is UDP_and                     convergence is GMA, then this flag represents whether or not                     the checksum field and the length field in the IP header of an                     MX PDU should be recalculated by the MX Convergence Layer. The                     possible values are "true" and "false". If it is "true", both                     fields remain unchanged; otherwise, both fields should be                     recalculated. If this field is not present then the default of                     "false" should be            <t>The representation of this data type is as follows:</t>      object {         SetupDeliveryConn items <1..*>;      } SetupDeliveryConns;            <t>where each "SetupDeliveryConn" consists of the following:</t>      object {         [JSONString adaptation_method;]         [AdaptationMethodParam adaptation_method_param;]      } SetupDeliveryConn : ConnectionInfo;            <!-- [rfced] Appendix C.2.11.2:  We changed "JSONSting" to"JSONString" here.  Please let us know any concerns (i.e., is themisspelled form unchangeable because it is part of implemented code?).Original: [JSONSting adaptation_method;]Currently: [JSONString adaptation_method;]-->            <!-- [author1] OK. Thanks.-->            <t>where AdaptationMethodParam is defined as:</t>      object {         JSONString tunnel_ip_addr;         JSONString tunnel_end_port;         JSONString shared_secret;         [JSONBool mx_header_optimization;]      } AdaptationMethodParam;          </section>        </section>        <section Probe          <t>This data type provides the results of the init probe request made by         the NCM.  It consists of the following information: Probes: Percentage of probes Delay: Average delay of probe message, in Rate: Probe rate achieved, in megabits per          <t>The representation of this data type is as follows:</t>        object {           JSONNumber lost_probes_percentage;           JSONNumber probe_rate_Mbps;        } InitProbeResults;        </section>        <section Probe          <t>This data type provides the results of the init probe request made by         the NCM.  It consists of the following information: Probe Throughput: Average active probe throughput               achieved, in megabits per          <t>The representation of this data type is as follows:</t>        object {           JSONNumber avg_tput_last_probe_duration_Mbps;        } ActiveProbeResults;        </section>        <section          <t>This data type represents the list of connections that are enabled         on the delivery side, to be used in the downlink direction.</t>          <t>The representation of this data type is as follows:</t>      object {         JSONNumber connection_id <1..*>;      } DLDelivery;        </section>        <section          <t>This data type represents the list of connections and parameters         enabled for the delivery side to be used in the uplink direction.</t>          <t>The uplink delivery consists of multiple uplink delivery entities,         where each entity consists of a Traffic Flow Template (TFT) (<xref and a list of connection ids in the uplink,         where traffic qualifying for such a Traffic Flow Template can be         redirected.</t>          <t>The representation of this data type is as follows:</t>      object {         ULDeliveryEntity ul_del <1..*>;      } ULDelivery;          <t>Where each uplink delivery entity consists of the following data type:</t>      object {         TrafficFlowTemplate ul_tft <1..*>;         JSONNumber connection_id <1..*>;      } ULDeliveryEntity;        </section>        <section Flow          <t>The Traffic Flow Template generally follows the guidelines specified         in <xref          <!-- [rfced] Appendix C.2.16:  Please provide reference informationfor 3GPP TS 23.060, so that we may add a citation for it here andalso add a corresponding listing in the Informative Referencessection.Original: Traffic flow template follows in general guidelines specified in 3GPP TS 23.060.-->          <!-- [author1] Added reference to 3GPP 23.060-->          <t>The Traffic Flow Template in MAMS consists of one or more of the         following: Address and Mask: IP address and subnet for remote              addresses represented in Classless Inter-Domain Routing (CIDR)              notation.  Default: Address and Mask: IP address and subnet for local addresses represented in CIDR notation. Default: Type: IP protocol number of the payload being carried by an IP packet (e.g., UDP, TCP).  Default: Port Range: Range of ports for local ports for which the Traffic Flow Template is applicable.  Default: Start=0, Port Range: Range of ports for remote ports for which the Traffic Flow Template is applicable.  Default: Start=0, Class: Represented by Type of Service in IPv4 and Traffic Class in IPv6.  Default: Label: Flow label for IPv6, applicable only for IPv6 protocol type.  Default:          <t>The representation of this data type is as follows:</t>      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;          <t>Where the port range is defined as follows:</t>      object {         JSONNumber start;         JSONNumber end;      } PortRange;        </section>        <section Report          <t>This data type represents the configuration done by the NCM toward         the CCM for reporting measurement events.              <t>Measurement Report Parameter: Parameter which shall be measured              and reported. This is dependent on the connection type: connection type "Wi-Fi", the allowed measurement parameters                   are "WLAN_RSSI", "WLAN_LOAD", "UL_TPUT", "DL_TPUT", "EST_UL_TPUT",                   and connection type "LTE", the allowed measurement parameters are                   "LTE_RSRP", "LTE_RSRQ", "UL_TPUT", and connection type "5G NR", the allowed measurement parameters                   are "NR_RSRP", "NR_RSRQ", "UL_TPUT", and High and low threshold for Period for reporting, in          <t>The representation of this data type is as follows:</t>      object {         JSONString meas_rep_param;         Threshold meas_threshold;         JSONNumber meas_period;      } MeasReportConfs;          <t>Where "Threshold" is defined as follows:</t>      object {         JSONNumber high;         JSONNumber low;      } Threshold;        </section>        <section          <t>This data type represents the measurements reported by the CCM for each         access network measured.  This type contains the connection information,         delivery node ID which identifies the cell (ECGI) or the Wi&nbhy;Fi         Access Point ID or MAC address (or equivalent identifier in other         technologies) and the actual measurement performed by the CCM in the         last measurement period.</t>          <t>The representation of this data type is as follows:</t>      object {         JSONNumber connection_id;         JSONString connection_type;         JSONString delivery_node_id;         Measurement measurements <1..*>;      } MXMeasRep;          <!-- Figure out what "on a per(-)delivery type" means -->          <!-- [author1] Believe that the above comment is a stray work-in-progress and addressed by the comment below -->          <t>Where Measurement is defined as the key value pair of the         measurement type and value.  The exact measurement type parameter reported         for a given connection depends on its Connection Type.         The measurement type parameters, for each Connection Type, are specified in <xref          <!-- [rfced] Appendix C.2.18:  Please clarify the meaning of"type and value are defined on a per delivery type."Original: The exact type and value are defined on a per delivery type and defined in Appendix C.2.17. -->          <!-- [author1] Rephrased for clarification. The measurement type parameter reported for each connection is dependent on the connection type.  These measurement types are specified in the referred section. -->      object {         JSONString measurement_type;         JSONNumber measurement_value;      } Measurement;        </section>      </section>      <section in        <section Base          <!-- [rfced] Appendices C.3.1 and subsequent:  We noticed that thereare 682 opening curly braces ("{") and 683 closing curly braces ("}").We do not have the ability to readily find the mismatch, but webelieve that the mismatch occurs somewhere after the beginning ofAppendix C.3.1.  (The 65 JSON definitions in Appendices C.1 and C.2look OK.)We do not know if this is an issue worth pursuing, but we wanted tomention it all the same as an "FYI." -->          <!-- [author1]The issue is with section C.3.2.Fixed 3 more issues, in addition to the removal of the extra closing brace "}".1. Removed extra comma: "NR_RSRQ", to  "NR_RSRQ"2. Removed extra comma at the end, in the last line:        "probe_param" : {            "probe_port" : {                "type" : "integer"            },            "anchor_conn_id" : {                "type" : "integer"            },            "mx_configuration_id" : {                "type" : "integer">>>            }3. Added Missing Comma, before line "predict_param_name":>>>        },        "predict_param_name": {4. Removed extra brace "}", before the line "id:":>>>     "id": "https://www.ietf.org/mams/definitions.json"}  </artwork></figure>-->{  "$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_ack",                "mx_up_setup_conf_req",                "mx_up_setup_cnf",                "mx_reconf_req",                "mx_reconf_rsp",                "mx_path_est_req",                "mx_path_est_results",                "mx_traffic_steering_req",                "mx_traffic_steering_rsp",                "mx_ssid_indication",                "mx_keep_alive_req",                "mx_keep_alive_rsp",                "mx_measurement_conf",                "mx_measurement_report",                "mx_session_termination_req",                "mx_session_termination_resp",                "mx_app_madp_assoc_req",                "mx_app_madp_assoc_resp",                "mx_network_analytics_req",                "mx_network_analytics_resp"      ],          "type": "string"    },    "sequence_num_def": {      "minimum": 1,      "type": "integer"    },    "version_def": {      "type": "string"    }   },  "id": "https://www.ietf.org/mams/mx_base_def.json"}        </section>        <section{    "$schema": "https://json-schema.org/draft-04/schema#",    "definitions": {        "adapt_method": {            "enum": [                "UDP_without_DTLS",                "UDP_with_DTLS",                "IPsec",                "Client_NAT"            ],            "type": "string"        },        "conv_method": {            "enum": [                "GMA",                "MPTCP_Proxy",                "GRE_Aggregation_Proxy",                "MPQUIC"            ],            "type": "string"        },        "supported": {            "type": "boolean"        },        "active": {            "type": "boolean"        },        "connection_id": {            "type": "integer"        },        "feature_name": {            "enum": [                "lossless_switching",                "fragmentation",                "concatenation",                "uplink_aggregation",                "downlink_aggregation",                "measurement"            ],            "type": "string"        },        "connection_type": {            "enum": [                "Wi-Fi",                "5G NR",                "MulteFire",                "LTE"            ],            "type": "string"        },        "ip_address": {                "type": "string"        },        "port": {            "maximum": 65535,            "minimum": 1,            "type": "integer"        },        "adaptation_method": {            "allOf" : [                { "$ref": "#/definitions/adapt_method" },                { "$ref": "#/definitions/supported" }            ]        },        "connection": {            "allOf" : [                { "$ref": "#/definitions/connection_id" },                { "$ref": "#/definitions/connection_type" }            ]        },        "convergence_method": {            "allOf": [                { "$ref": "#/definitions/conv_method" },                { "$ref": "#/definitions/supported" }            ]        },        "feature_status": {            "allOf": [                { "$ref": "#/definitions/feature_name" },                { "$ref": "#/definitions/active" }            ]        },        "ncm_end_point": {            "allOf" : [                { "$ref" : "#/definitions/ip_address" },                { "$ref" : "#/definitions/port" }            ]        },        "capability_acknowledgment" : {            "enum" : [                "MX_ACCEPT",                "MX_REJECT"            ],            "type" : "string"        },        "threshold" : {            "high" : {                "type" : "integer"            },            "low" : {                "type" : "integer"            },            "type" : "object"        },        "meas_report_param" : {            "enum" : [                    "WLAN_RSSI",                    "WLAN_LOAD",                    "LTE_RSRP",                    "LTE_RSRQ",                    "UL_TPUT",                    "DL_TPUT",                    "EST_UL_TPUT",                    "EST_DL_TPUT",                    "NR_RSRP",                    "NR_RSRQ"            ],            "type" : "string"        },        "meas_report_conf" : {            "meas_rep_param" : {                "$ref" : "#definitions/meas_report_param"            },            "meas_threshold" : {                "$ref" : "#definitions/threshold"            },            "meas_period_ms" : {                "type" : "integer"            },            "type" : "object"        },        "ssid_types" : {            "enum" : [                "ssid",                "bssid",                "hessid"            ],            "type" : "string"        },        "ip_addr_mask" : {            "type" : "string",            "default" : "0.0.0.0/0"        },        "port_range" : {            "start" : {                "type" : "integer",                "default" : 0            },            "end" : {                "type" : "integer",                "default" : 65535            }        },        "traffic_flow_template" : {            "remote_addr_mask" : {                "$ref" : "#definitions/ip_addr_mask" },            "local_addr_mask" : {                "$ref" : "#definitions/ip_addr_mask" },            "protocol_type" : {                "type" : "integer",                "minimum" : 0,                "maximum" : 255            },            "local_port_range" : {                "$ref" : "#definitions/port_range" },            "remote_port_range" : {                "$ref" : "#definitions/port_range" },            "traffic_class" : {                "type" : "integer",                "default" : 255            },            "flow_label" : {                "type" : "integer",                "default" : 0            }        },        "delivery_node_id" : {            "type" : "string"        },        "unique_session_id" : {            "type" : "object",            "ncm_id" : {              "type" : "integer"            },            "session_id" : {              "type" : "integer"            }        },        "keep_alive_reason" : {            "enum" : [                "Timeout",                "Handover"            ],            "type" : "string"        },        "connection_status" : {            "enum" : [                "disabled",                "enabled",                "connected"            ],            "type" : "string",            "default" : "connected"        },        "adaptation_param" : {           "udp_adapt_port" : {              "type" : "integer"           }        },        "probe_param" : {            "probe_port" : {                "type" : "integer"            },            "anchor_conn_id" : {                "type" : "integer"            },            "mx_configuration_id" : {                "type" : "integer"            }    },        "client_param" : {            "connection_id" : {                "type" : "integer"            },            "adapt_param" : {                "type" : {"$ref" : "#definitions/adaptation_param" }            }        }    },            "adapt_param": {            "tunnel_ip_addr": {                "type": "string"            },            "tunnel_end_port": {                "type": "integer"            },            "shared_secret": {                "type": "string"            },            "mx_header_optimization": {                "type": "boolean",                "default": false            }        },        "delivery_connection": {            "connection_id": {                "$ref": "#definitions/connection_id"            },            "connection_type": {                "$ref": "#definitions/connection_type"            },            "adaptation_method": {                "$ref": "#definitions/adapt_method"            },            "adaptation_method_param": {                "$ref": "#definitions/adapt_param"            }        },        "app_madp_assoc": {            "anchor_conn_id" : {                "type" : "integer"            },            "mx_configuration_id" : {                "type" : "integer"            }            "ul_tft_list": {                "items": {                    "$ref": "#definitions/traffic_flow_template"                },                "type": "array"            },            "dl_tft_list": {                "items": {                    "$ref": "#definitions/traffic_flow_template"                },                "type": "array"            }        },        "predict_param_name": {            "enum": [                "validity time",                "bandwidth",                "jitter",                "latency",                "signal_quality"            ],            "type": "string"        },        "predict_add_param_name": {            "enum": [                "WLAN_RSSI",                "WLAN_LOAD",                "LTE_RSRP",                "LTE_RSRQ",                "NR_RSRP",                "NR_RSRQ"            ],            "type": "string"        },    "id": "https://www.ietf.org/mams/definitions.json"}        </section>        <section{  "$schema": "https://json-schema.org/draft-04/schema#",  "additionalProperties": false,  "id": "https://www.ietf.org/mams/mx_discover.json",  "properties": {    "message_type" : {"$ref": "mx_base_def.json#/message_type_def"},        "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"},        "version" : {"$ref": "mx_base_def.json#/version_def"}  },  "type": "object"}        </section>        <section System{    "$schema": "https://json-schema.org/draft-04/schema#",    "additionalProperties": false,    "id": "https://www.ietf.org/mams/mx_system_info.json",    "properties": {        "message_type": {            "$ref": "mx_base_def.json#/message_type_def"        },        "sequence_num": {            "$ref": "mx_base_def.json#/sequence_num_def"        },        "version": {            "$ref": "mx_base_def.json#/version_def"        },        "ncm_connections": {            "type": "array",            "items": [                { "$ref": "definitions.json#/connection" },                { "$ref": "definitions.json#/ncm_end_point" }            ]        }    },    "type": "object"}        </section>        <section Capability{  "$schema": "https://json-schema.org/draft-04/schema#",  "additionalProperties": false,  "id": "https://www.ietf.org/mams/mx_capability_req.json",  "properties": {    "message_type" : {"$ref": "mx_base_def.json#/message_type_def"},    "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"},    "version" : {"$ref": "mx_base_def.json#/version_def"},    "adaptation_methods": {      "items": { "$ref" : "definitions.json#/adaptation_method"},      "type": "array"    },    "anchor_connections": {      "items": { "$ref" : "definitions.json#/connection"},      "type": "array"    },    "convergence_methods": {      "items": { "$ref" : "definitions.json#/convergence_method"},      "type": "array"    },    "delivery_connections": {      "items": { "$ref" : "definitions.json#/connection"},      "type": "array"    },    "feature_active": {      "items": { "$ref" : "definitions.json#/feature_status"},      "type": "array"    },    "num_anchor_connections": {      "type": "integer"    },    "num_delivery_connections": {      "type": "integer"    }  },  "type": "object"}        </section>        <section Capability{  "$schema": "https://json-schema.org/draft-04/schema#",  "additionalProperties": false,  "id": "https://www.ietf.org/mams/mx_capability_resp.json",  "properties": {    "message_type" : {"$ref": "mx_base_def.json#/message_type_def"},    "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"},    "version" : {"$ref": "mx_base_def.json#/version_def"},    "adaptation_methods": {      "items": { "$ref" : "definitions.json#/adaptation_method" },      "type": "array"    },    "anchor_connections": {      "items": { "$ref" : "definitions.json#/connection" },      "type": "array"    },    "convergence_methods": {      "items": { "$ref" : "definitions.json#/convergence_method" },      "type": "array"    },    "delivery_connections": {      "items": { "$ref" : "definitions.json#/connection" },      "type": "array"    },    "feature_active": {      "items": { "$ref" : "definitions.json#/feature_status" },      "type": "array"    },    "num_anchor_connections": {      "type": "integer"    },    "num_delivery_connections": {      "type": "integer"    },    "unique_session_id" : {            "$ref": "definitions.json#/unique_session_id"    }  },  "type": "object"}        </section>        <section Capability{    "$schema": "https://json-schema.org/draft-04/schema#",    "definitions": {},    "id": "https://www.ietf.org/mams/mx_capability_ack.json",    "properties": {        "message_type" : {"$ref": "mx_base_def.json#/message_type_def"},        "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"},        "version" : {            "$ref": "mx_base_def.json#/version_def"},        "unique_session_id" : {            "$ref": "definitions.json#/unique_session_id" },    "capability_ack": {        "$ref" : "definitions.json#/capability_acknowledgment" }    },    "type": "object"}        </section>        <section Reconfiguration{  "$schema": "https://json-schema.org/draft-04/schema#",  "definitions": {},  "id": "https://www.ietf.org/mams/mx_reconf_req.json",  "properties": {        "message_type" : {"$ref": "mx_base_def.json#/message_type_def"},        "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"},        "version" : {"$ref": "mx_base_def.json#/version_def"},        "unique_session_id" : {                        "$ref": "definitions.json#/unique_session_id"        },        "connection_id" : {"$ref" : "definitions.json#/connection_id"},    "ip_address": {"$ref" : "definitions.json#/ip_address"},    "mtu_size": {          "maximum" : 65535,      "minimum": 1,      "type": "integer"    },        "ssid" : {         "type" : "string"        },    "reconf_action": {      "enum": [            "release",        "setup",                "update"      ],      "id": "/properties/reconf_action",      "type": "string"    },        "connection_status" : {              "$ref" : "definitions.json#/connection_status"},        "delivery_node_id" : {              "$ref": "definitions.json#/delivery_node_id"}  },  "type": "object"}        </section>        <section Reconfiguration{  "$schema": "https://json-schema.org/draft-04/schema#",  "definitions": {},  "id": "https://www.ietf.org/mams/mx_reconf_rsp.json",  "properties": {    "message_type" : {"$ref": "mx_base_def.json#/message_type_def"},        "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"},        "version" : {"$ref": "mx_base_def.json#/version_def"}  },  "type": "object"}        </section>        <section UP Setup{  "$schema": "https://json-schema.org/draft-04/schema#",  "additionalProperties": false,  "definitions": {   "convergence_configuration" : {                "mx_configuration_id": { "type" : "integer"},                "convergence_method": {                    "$ref" : "definitions.json#/conv_method" },          "convergence_method_params": {            "properties": {              "proxy_ip": { "$ref" : "definitions.json#/ip_address" },              "proxy_port": {"$ref" : "definitions.json#/port"},              "client_key": {"$ref" : "definitions.json#/client_key"}            },            "type": "object"          },                  "num_delivery_connections": {            "type": "integer"          },          "delivery_connections": {            "items": {              "$ref" : "definitions.json#/delivery_connection" },                          "type": "array"          }        }  },  "id": "https://www.ietf.org/mams/mx_up_setup_conf_req.json",  "properties": {        "message_type" : {"$ref": "mx_base_def.json#/message_type_def"},        "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"},        "version" : {"$ref": "mx_base_def.json#/version_def"},    "num_anchor_connections": {      "type": "integer"    },    "anchor_connections": {      "items": {        "properties": {          "connection_id": {            "$ref" : "definitions.json#/connection_id" },          "connection_type": {            "$ref" : "definitions.json#/connection_type" },                 "num_active_mx_conf" : { "type" : "integer" },                 "convergence_config" : {                   "items": {                     "$ref" : "definitions/convergence_configuration" },                       "type" : "array"                 }         },        "type": "object"      },      "type": "array"    }  },  "type": "object"}        </section>        <section UP Setup{  "$schema": "https://json-schema.org/draft-04/schema#",  "definitions": {},  "id": "https://www.ietf.org/mams/mx_up_setup_cnf.json",  "properties": {    "message_type" : {"$ref": "mx_base_def.json#/message_type_def"},        "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"},        "version" : {"$ref": "mx_base_def.json#/version_def"},        "unique_session_id" : {            "$ref": "definitions.json#/unique_session_id" },        "probe_param" : { "$ref": "definitions.json#/probe_param" },        "num_delivery_conn" : {                "type" : "integer"        },        "client_params" : {                "type" : "array",                "items" : [                        {"$ref": "definitions.json#/client_param"}                ]        }  },  "type": "object"}        </section>        <section Traffic Steering{  "$schema": "https://json-schema.org/draft-04/schema#",  "definitions": {        "conn_list" : {              "items" : { "$ref" : "definitions.json#/connection_id" },              "type": "array"        },        "ul_delivery" : {              "ul_tft" : {                    "$ref" : "definitions.json#/traffic_flow_template"},              "connection_list" : { "$ref" : "#definitions/conn_list" }        }  },  "id": "https://www.ietf.org/mams/mx_traffic_steering_req.json",  "properties": {        "message_type" : {"$ref": "mx_base_def.json#/message_type_def"},        "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"},        "version" : {"$ref": "mx_base_def.json#/version_def"},"connection_id": {"$ref" : "definitions.json#/connection_id"},"mx_configuration_id": { "type" : "integer"},   "downlink_delivery": {      "items": { "$ref" : "definitions.json#/connection_id" },      "type": "array"    },    "feature_activation": {      "items": {"$ref" : "definitions.json#/feature_status"},      "type": "array"    },        "default_uplink_delivery": {                "type": "integer"        },    "uplink_delivery": {      "items": { "$ref" : "#definitions/ul_delivery" },      "type": "array"    }  },  "type": "object"}        </section>        <section Traffic Steering{  "$schema": "https://json-schema.org/draft-04/schema#",  "definitions": {},  "id": "https://example.com/example.json",  "properties": {    "message_type" : {"$ref": "mx_base_def.json#/message_type_def"},        "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"},        "version" : {"$ref": "mx_base_def.json#/version_def"},        "unique_session_id" : {            "$ref": "definitions.json#/unique_session_id" },        "feature_activation": {      "items": {"$ref" : "definitions.json#/feature_status"},      "type": "array"    }  },  "type": "object"}        </section>        <section Application MADP Association{    "$schema": "https://json-schema.org/draft-04/schema#",    "definitions": {},    "id": "https://example.com/example.json",    "properties": {        "message_type": {            "$ref": "mx_base_def.json#/message_type_def"        },        "sequence_num": {            "$ref": "mx_base_def.json#/sequence_num_def"        },        "version": {            "$ref": "mx_base_def.json#/version_def"        },        "unique_session_id": {            "$ref": "definitions.json#/unique_session_id"        },        "app_madp_assoc_list": {            "items": {                "$ref": "definitions.json#/app_madp_assoc"            },            "type": "array"        }    },    "type": "object"}        </section>        <section Application MADP Association{        "$schema": "https://json-schema.org/draft-04/schema#",        "definitions": {},        "id": "https://example.com/example.json",        "properties": {                "message_type": {                        "$ref": "mx_base_def.json#/message_type_def"                },                "sequence_num": {                        "$ref": "mx_base_def.json#/sequence_num_def"                },                "version": {                        "$ref": "mx_base_def.json#/version_def"                },                "unique_session_id": {                        "$ref": "definitions.json#/unique_session_id"                },                "is_success": {                        "type": "boolean"                }        },        "type": "object"}        </section>        <section Path Estimation{  "$schema": "https://json-schema.org/draft-04/schema#",  "definitions": {},  "id": "https://www.ietf.org/mams/mx_path_est_req.json",  "properties": {        "message_type" : {"$ref": "mx_base_def.json#/message_type_def"},        "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"},        "version" : {"$ref": "mx_base_def.json#/version_def"},    "active_probe_ack_req": {      "enum": [        "no",                "yes"      ],      "type": "string"    },    "active_probe_freq_ms": {      "maximum" : 10000,      "minimum": 100,      "type": "integer"    },    "active_probe_size_bytes": {      "maximum": 1500,      "minimum": 100,      "type": "integer"    },        "active_probe_duration_sec" : {          "maximum" : 100,          "minimum" : 10,          "type" :  "integer"        },    "connection_id": { "$ref" : "definitions#/connection_id" },    "init_probe_ack_req": {      "enum": [        "no",        "yes"      ],      "type": "string"    },    "init_probe_size_bytes": {      "maximum": 1500,      "minimum": 100,      "type": "integer"    },    "init_probe_test_duration_ms": {      "maximum": 10000,      "minimum": 100,      "type": "integer"    },    "init_probe_test_rate_Mbps": {      "maximum": 100,      "minimum": 1,      "type": "integer"    }  },  "type": "object"}        </section>        <section Path Estimation{  "$schema": "https://json-schema.org/draft-04/schema#",  "definitions": {},  "id": "https://www.ietf.org/mams/mx_path_est_results.json",  "properties": {        "message_type" : {"$ref": "mx_base_def.json#/message_type_def"},        "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"},        "version" : {"$ref": "mx_base_def.json#/version_def"},        "unique_session_id" : {              "$ref": "definitions.json#/unique_session_id" },    "active_probe_results": {      "properties": {        "avg_tput_last_probe_duration_Mbps": {              "maximum":100,          "minimum": 1,          "type": "number"        }      },      "type": "object"    },    "connection_id": { "$ref" : "definitions.json#/connection_id" },    "init_probe_results": {      "properties": {                "lost_probes_percentage": {                  "maximum": 100,          "minimum": 1,          "type": "integer"        },       "probe_rate_Mbps": {          "maximum": 100,          "minimum": 1,          "type": "number"        }      },      "type": "object"    }  },  "type": "object"}        </section>        <section SSID{    "$schema": "https://json-schema.org/draft-04/schema#",    "definitions": {},    "id": "https://www.ietf.org/mams/mx_ssid_indication.json",    "properties": {                "message_type" : {                    "$ref": "mx_base_def.json#/message_type_def"},                "sequence_num" : {                    "$ref": "mx_base_def.json#/sequence_num_def"},                "version" : {"$ref": "mx_base_def.json#/version_def"},        "ssid_list": {            "items": {                      "properties" : {                          "ssid_type": {                              "$ref" : "definitions.json#/ssid_types" },                                   "ssid_id" : {                                       "type" : "integer"                                   }                          }            },            "type": "array"        }    },    "type": "object"}        </section>        <section Measurement{  "$schema": "https://json-schema.org/draft-04/schema#",  "additionalProperties": false,  "definitions" : {        "meas_conf" : {                "connection_id" : {                    "$ref" : "definitions.json#/connection_id" },                "connection_type" : {                    "$ref" : "definitions.json#/connection_type" },                "meas_rep_conf" : {                        "items" : {                    "$ref" : "definitions.json#/meas_report_conf" },                        "type" : "array"                }        }  },  "id": "https://www.ietf.org/mams/mx_measurement_conf.json",  "properties": {    "message_type" : {"$ref": "mx_base_def.json#/message_type_def"},        "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"},        "version" : {"$ref": "mx_base_def.json#/version_def"},        "measurement_configuration" : {                "items" : {"$ref" : "#definitions/meas_conf"},                "type" : "array"        }  },  "type": "object"}        </section>        <section Measurement{"$schema": "https://json-schema.org/draft-04/schema#","definitions": {},"id": "https://www.ietf.org/mams/mx_measurement_report.json","properties": {            "message_type" : {                "$ref": "mx_base_def.json#/message_type_def"},            "sequence_num" : {                "$ref": "mx_base_def.json#/sequence_num_def"},            "version" : {                "$ref": "mx_base_def.json#/version_def"},            "unique_session_id" : {                "$ref": "definitions.json#/unique_session_id" },    "measurement_reports": {        "items": {            "properties": {                "connection_id": {                    "$ref" : "definitions.json#/connection_id"                },                     "connection_type" : {                         "$ref" : "definitions.json#/connection_type"                                 },                                 "delivery_node_id" : {                                    "$ref" :                                    "definitions.json#/delivery_node_id"                                },            "measurements": {                "items": {                    "properties": {                        "measurement_type": {                          "$ref" : "definitions.json#/meas_report_param"                            },                            "measurement_value": {                                "type": "integer"                            }                         },                         "type": "object"                      },                      "type": "array"                  }              },              "type": "object"          },         "type": "array"      }  },  "type": "object"}        </section>        <section Keep-Alive{  "$schema": "https://json-schema.org/draft-04/schema#",  "additionalProperties": false,  "id": "https://www.ietf.org/mams/mx_keep_alive_req.json",  "properties": {    "message_type" : {"$ref": "mx_base_def.json#/message_type_def"},        "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"},        "version" : {            "$ref": "mx_base_def.json#/version_def"},        "keep_alive_reason" : {            "$ref": "definitions.json#/keep_alive_reason"},        "unique_session_id" : {            "$ref": "definitions.json#/unique_session_id"},        "connection_id" : {            "$ref": "definitions.json#/connection_id"},        "delivery_node_id" : {            "$ref": "definitions.json#/connection_id"}  },  "type": "object"}        </section>        <section Keep-Alive{  "$schema": "https://json-schema.org/draft-04/schema#",  "additionalProperties": false,  "id": "https://www.ietf.org/mams/mx_keep_alive_rsp.json",  "properties": {    "message_type" : {"$ref": "mx_base_def.json#/message_type_def"},        "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"},        "version" : {"$ref": "mx_base_def.json#/version_def"},        "unique_session_id" : {            "$ref": "definitions.json#/unique_session_id"}  },  "type": "object"}        </section>        <section Session Termination{  "$schema": "https://json-schema.org/draft-04/schema#",  "additionalProperties": false,  "id": "https://www.ietf.org/mams/mx_keep_alive_req.json",  "properties": {    "message_type" : {"$ref": "mx_base_def.json#/message_type_def"},        "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"},        "version" : {"$ref": "mx_base_def.json#/version_def"},        "unique_session_id" : {            "$ref": "definitions.json#/unique_session_id" },        "reason" : {                "enum" : [                        "MX_NORMAL_RELEASE",                        "MX_NO_RESPONSE",                        "INTERNAL_ERROR"                ],           "type" : "string"        }  },  "type": "object"}        </section>        <section Session Termination{  "$schema": "https://json-schema.org/draft-04/schema#",  "additionalProperties": false,  "id": "https://www.ietf.org/mams/mx_session_termination_resp.json",  "properties": {    "message_type" : {"$ref": "mx_base_def.json#/message_type_def"},        "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"},        "version" : {"$ref": "mx_base_def.json#/version_def"},        "unique_session_id" : {            "$ref": "definitions.json#/unique_session_id" }  },  "type": "object"}        </section>        <section Network Analytics{  "$schema": "https://json-schema.org/draft-04/schema#",  "additionalProperties": false,  "id": "https://www.ietf.org/mams/mx_network_analytics_req.json",  "properties": {    "message_type" : {"$ref": "mx_base_def.json#/message_type_def"},        "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"},        "version" : {"$ref": "mx_base_def.json#/version_def"},        "unique_session_id" : {            "$ref": "definitions.json#/unique_session_id" },        "params" : {                "items" : {                    "$ref": "definitions.json#/predict_param_name"},                "type" : "array"                }  },  "type": "object"}        </section>        <section Network Analytics{  "$schema": "https://json-schema.org/draft-04/schema#",  "additionalProperties": false,  "definitions" : {   "ParamPredictions" : {    "param_name" : {"$ref" : "definitions.json#/predict_param_name"},        "additional_param" : {            "$ref" : "definitions.json#/predict_add_param_name"},        "prediction" : { "type" : "integer" },        "likelihood" : { "type" : "integer" }, "validity_time" : { "type" : "integer" }   },   "MXAnalyticsList" : {                "connection_id" : {                    "$ref" : "definitions.json#/connection_id" },                "connection_type" : {                    "$ref" : "definitions.json#/connection_type" },                "predictions " : {                        "items" : {                            "$ref" : "#definitions/ParamPredictions" },                        "type" : "array"                }        }  },  "id": "https://www.ietf.org/mams/mx_network_analytics_resp.json",  "properties": {    "message_type" : {"$ref": "mx_base_def.json#/message_type_def"},        "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"},        "version" : {"$ref": "mx_base_def.json#/version_def"},        "param_list" : {                            "items" : {                                "$ref": "#definitions/MXAnalyticsList"},                            "type" : "array"}  },  "type": "object"}        </section>      </section>      <section in        <section{  "version" : "1.0",  "message_type" : "mx_discover",  "sequence_num" : 1}        </section>        <section System{  "version" : "1.0",  "message_type" : "mx_system_info",  "sequence_num" : 2,  "ncm_connections" : [                        {                                "connection_id" : 0,                                "connection_type" : "LTE",                                "ncm_end_point" : {                                        "ip_address" : "192.168.1.10",                                        "port" : 1234                                }                        },                        {                                "connection_id" : 1,                                "connection_type" : "Wi-Fi",                                "ncm_end_point" : {                                        "ip_address" : "192.168.1.10",                                        "port" : 1234                                }                        }        ]}        </section>        <section Capability{  "version" : "1.0",  "message_type" : "mx_capability_req",  "sequence_num" : 3,  "feature_active" : [                {                        "feature_name" : "lossless_switching",                        "active" : true                },                {                        "feature_name" : "fragmentation",                        "active" : false                }  ],  "num_anchor_connections" : 2,  "anchor_connections" : [                {                        "connection_id" : 0,                        "connection_type" : "LTE"                },                {                        "connection_id" : 1,                        "connection_type" : "Wi-Fi"                }  ],  "num_delivery_connections" : 2,  "delivery_connections" : [                {                        "connection_id" : 0,                        "connection_type" : "LTE"                },                {                        "connection_id" : 1,                        "connection_type" : "Wi-Fi"                }  ],  "convergence_methods" : [                {                        "method" : "GMA",                        "supported" : true                },                {                        "method" : "MPTCP_Proxy",                        "supported" : false                }  ],  "adaptation_methods" : [                {                        "method" : "UDP_without_DTLS",                        "supported" : false                },                {                        "method" : "UDP_with_TLS",                        "supported" : false                },                {                        "method" : "IPsec",                        "supported" : true                },                {                        "method" : "Client_NAT",                        "supported" : false                }  ]}        </section>        <section Capability{  "version" : "1.0",  "message_type" : "mx_capability_resp",  "sequence_num" : 3,  "feature_active" : [                {                        "feature_name" : "lossless_switching",                        "active" : true                },                {                        "feature_name" : "fragmentation",                        "active" : false                }  ],  "num_anchor_connections" : 2,  "anchor_connections" : [                {                        "connection_id" : 0,                        "connection_type" : "LTE"                },                {                        "connection_id" : 1,                        "connection_type" : "Wi-Fi"                }  ],  "num_delivery_connections" : 2,  "delivery_connections" : [                {                        "connection_id" : 0,                        "connection_type" : "LTE"                },                {                        "connection_id" : 1,                        "connection_type" : "Wi-Fi"                }  ],  "convergence_methods" : [                {                        "method" : "GMA",                        "supported" : true                },                {                        "method" : "MPTCP_Proxy",                        "supported" : false                }  ],  "adaptation_methods" : [                {                        "method" : "UDP_without_DTLS",                        "supported" : false                },                {                        "method" : "UDP_with_TLS",                        "supported" : false                },                {                        "method" : "IPsec",                        "supported" : true                },                {                        "method" : "Client_NAT",                        "supported" : false                }  ],  "unique_session_id" : {                "ncm_id" : 110,                "session_id" : 1111  }}        </section>        <section Capability{  "version" : "1.0",  "message_type" : "mx_capability_ack",  "sequence_num" : 3,  "unique_session_id" : {                "ncm_id" : 110,                "session_id" : 1111  },  "capability_ack" : "MX ACCEPT"}        </section>        <section Reconfiguration{  "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"}        </section>        <section Reconfiguration{  "version" : "1.0",  "message_type" : "mx_reconf_rsp",  "sequence_num" : 4}        </section>        <section UP Setup Configuration{    "version": "1.0",    "message_type": "mx_up_setup_conf_req",    "sequence_num": 5,    "num_anchor_connections": 2,    "anchor_connections": [{            "connection_id": 1,            "connection_type": "Wi-Fi",            "num_active_mx_conf" : 2,            "convergence_config" : [            {                "mx_configuration_id" : 1,                "convergence_method": "GMA",                "convergence_method_params": {},                "num_delivery_connections": 2,                "delivery_connections": [{                        "connection_id": 0,                        "connection_type": "LTE",                        "adaptation_method": "UDP_without_DTLS",                        "adaptation_method_param": {                            "tunnel_ip_addr": "6.6.6.6",                            "tunnel_end_port": 9999,                            "mx_header_optimization": true                        }                    },                    {                        "connection_id": 1,                        "connection_type": "Wi-Fi"                    }                ]            },            {                "mx_configuration_id" : 2,                "convergence_method": "GMA",                "convergence_method_params": {},                "num_delivery_connections": 1,                "delivery_connections": [{                        "connection_id": 0,                        "connection_type": "LTE",                        "adaptation_method": "UDP_without_DTLS",                        "adaptation_method_param": {                            "tunnel_ip_addr": "6.6.6.6",                            "tunnel_end_port": 8877                        }                    }                ]            }          ]        },        {            "connection_id": 0,            "connection_type": "LTE",            "udp_port": 8888,            "num_delivery_connections": 2,            "delivery_connections": [{                    "connection_id": 0,                    "connection_type": "LTE"                },                {                    "connection_id": 1,                    "connection_type": "Wi-Fi",                    "adaptation_method": "UDP_without_DTLS",                    "adaptation_method_param": {                        "tunnel_ip_addr": "192.168.3.3",                        "tunnel_end_port": "6000"                    }                }            ]        }    ]}        </section>        <section UP Setup{  "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                        }                }  ]}        </section>        <section Traffic Steering{  "version" : "1.0",  "message_type" : "mx_traffic_steering_req",  "sequence_num" : 6,  "connection_id" : 0,  "mx_configuration_id" : 1,  "downlink_delivery" : [        {                "connection_id" : 0        },        {                "connection_id" : 1        }  ],  "default_uplink_delivery" : 0,  "uplink_delivery" : [        {                "ul_tft" : {                        "remote_addr_mask" : "10.10.0.0/24",                        "local_addr_mask" : "192.168.0.0/24",                        "protocol_type" :  6,                        "local_port_range" : {                          "start" : 100,                          "end" : 1000                        },                        "remote_port_range" : {                                "start" : 100,                                "end" : 1000                        },                        "traffic_class" : 20,                        "flow_label" : 100                },                "conn_list" : [                        {                                "connection_id" : 1                        }                ]        },        {                "ul_tft" : {                        "remote_addr_mask" : "10.10.0.0/24",                        "local_addr_mask" : "192.168.0.0/24",                        "protocol_type" :  6,                        "local_port_range" : {                          "start" : 2000,                          "end" : 2000                        },                        "remote_port_range" : {                                "start" : 100,                                "end" : 1000                        },                        "traffic_class" : 20,                        "flow_label" : 50                },                "conn_list" : [                        {                                "connection_id" : 1                        }                ]        }  ],  "feature_activation" : [                {                        "feature_name" : "dl_aggregation",                        "active" : true                },                {                        "feature_name" : "ul_aggregation",                        "active" : false                }        ]}          <!-- [rfced] We changed this lone instance of "loca_port_range" to"local_port_range".  Please let us know any concerns (e.g., if it isunchangeable code).Original: "loca_port_range" : {   "start" : 100,   "end" : 1000 },Currently: "local_port_range" : {   "start" : 100,   "end" : 1000 }, -->          <!-- [author1] Changes accepted with thanks. -->        </section>        <section Traffic Steering{        "version": "1.0",        "message_type": "mx_traffic_steering_rsp",        "sequence_num": 6,        "unique_session_id": {                "ncm_id": 110,                "session_id": 1111        },        "feature_activation": [{                        "feature_name": "lossless_switching",                        "active": true                },                {                        "feature_name": "fragmentation",                        "active": false                }        ]}        </section>        <section Application MADP Association{        "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                                }                        }]                }        ]}        </section>        <section Application MADP Association{        "version": "1.0",        "message_type": "mx_app_madp_assoc_resp",        "sequence_num": 6,        "is_success": true}        </section>        <section Path Estimation{  "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"}        </section>        <section Path Estimation{  "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  }}        </section>        <section SSID{        "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"                }        ]}        </section>        <section Measurement{        "version" : "1.0",        "message_type" : "mx_measurement_conf",        "sequence_num" : 10,        "measurement_configuration" : [        {                "connection_id" : 0,                "connection_type" : "Wi-Fi",                "meas_rep_conf"  : [                        {                           "meas_rep_param" : "WLAN_RSSI",                           "meas_threshold" : {                                "high" : -10,                                "low" : -15                                },                           "meas_period_ms" : 500                        },                        {                           "meas_rep_param" : "WLAN_LOAD",                           "meas_threshold" : {                                "high" : -10,                                "low" : -15                                },                           "meas_period_ms" : 500                        },                        {                           "meas_rep_param" : "EST_UL_TPUT",                           "meas_threshold" : {                                "high" : 100,                                "low" : 30                                },                           "meas_period_ms" : 500                        }                ]        },        {                "connection_id" : 1,                "connection_type" : "LTE",                "meas_rep_conf"  : [                        {                           "meas_rep_param" : "LTE_RSRP",                           "meas_threshold" : {                                "high" : -10,                                "low" : -15                                },                           "meas_period_ms" : 500                        },                        {                           "meas_rep_param" : "LTE_RSRQ",                           "meas_threshold" : {                                "high" : -10,                                "low" : -15                                },                           "meas_period_ms" : 500                        }                ]        } ]}        </section>        <section Measurement{        "version" : "1.0",        "message_type" : "mx_measurement_report",        "sequence_num" : 11,        "unique_session_id" : {                "ncm_id" : 110,                "session_id" : 1111    },        "measurement_reports" : [        {                "connection_id" : 0,                "connection_type" : "Wi-Fi",                "delivery_node_id" : "2021A",                "measurements"  : [                        {                           "measurement_type" : "WLAN_RSSI",                           "measurement_value" : -12                        },                        {                           "measurement_type" : "UL_TPUT",                           "measurement_value" : 10                        },                        {                           "measurement_type" : "EST_UL_TPUT",                           "measurement_value" : 20                        }                ]        },        {                "connection_id" : 1,                "connection_type" : "LTE",                "delivery_node_id" : "12323",                "measurements"  : [                        {                           "measurement_type" : "LTE_RSRP",                           "measurement_value" : -12                        },                        {                           "measurement_type" : "LTE_RSRQ",                           "measurement_value" : -12                        }                ]        }  ]}        </section>        <section Keep-Alive{  "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"}        </section>        <section Keep-Alive{  "version" : "1.0",  "message_type" : "mx_keep_alive_rsp",  "sequence_num" : 12,  "unique_session_id" : {                "ncm_id" : 110,                "session_id" : 1111  }}        </section>        <section Session Termination{  "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"}        </section>        <section Session Termination{  "version" : "1.0",  "message_type" : "mx_session_termination_resp",  "sequence_num" : 13,  "unique_session_id" : {                "ncm_id" : 110,                "session_id" : 1111  }}        </section>        <section Network Analytics{     "version" : "1.0",     "message_type" : "mx_network_analytics_req",     "sequence_num" : 20,     "unique_session_id" : {                   "ncm_id" : 110,                   "session_id" : 1111     },     "params" : [         "jitter",         "latency"         ]}          <!-- [rfced] Appendix C.4.23:  We changed this lone instance of"parmas" to "params".  Please let us know any concerns.Original: "parmas" : [Currently: "params" : [ -->          <!-- [author1] Changes accepted with thanks. -->        </section>        <section Network Analytics{        "version": "1.0",        "message_type": "mx_network_analytics_resp",        "sequence_num": 20,        "param_list": [{                        "connection_id": 1,                        "connection_type": "Wi-Fi",                        "predictions": [{                                        "param_name": "jitter",                                        "prediction": 100,                                        "likelihood": 50,                                        "validity_time": 10                                },                                {                                        "param_name": "latency",                                        "prediction": 19,                                        "likelihood": 40,                                        "validity_time": 10                                }                        ]                },                {                        "connection_id": 2,                        "connection_type": "LTE",                        "predictions": [{                                        "param_name": "jitter",                                        "prediction": 10,                                        "likelihood": 80,                                        "validity_time": 10                                },                                {                                        "param_name": "latency",                                        "prediction": 4,                                        "likelihood": 60,                                        "validity_time": 10                                }                        ]                }        ]}        </section>      </section>    </section>    <section of APIs Provided by the CCM to the Applications at the      <t>This section provides an example implementation of the APIs exposed by the CCM to     the applications on the client, documented with OpenAPI using Swagger 2.0.</t>{  "swagger": "2.0",  "info": {    "version": "1.0.0",    "title": "Client Connection Manager (CCM)",    "description": "API provided by the CCM towards the application                    on a MAMS client."  },  "host": "MAMS.ietf.org",  "basePath": "/ccm/v1.0",  "schemes": [    "https"  ],  "consumes": [    "application/json"  ],  "produces": [    "application/json"  ],  "paths": {    "/capabilities": {      "get": {        "description": "This API can be used by an application to                        request the capabilities of the CCM.",        "produces": [          "application/json",          "text/html"        ],        "responses": {          "200": {            "description": "OK",            "schema": {              "$ref": "#/definitions/capability"            }          },          "default": {            "description": "unexpected error",            "schema": {              "$ref": "#/definitions/errorModel"            }          }        }      }    },    "/app_requirements": {      "post": {        "description": "This API is used by the N-MADP to report                        any types of MAMS user-specific errors to                        the NCM.",        "produces": [          "application/json",          "text/html"        ],        "parameters": [          {            "name": "app-requirements",            "in": "body",            "required": true,            "schema": {              "$ref": "#/definitions/app-requirements"            }          }        ],        "responses": {          "200": {            "description": "OK"          },          "default": {            "description": "unexpected error",            "schema": {              "$ref": "#/definitions/errorModel"            }          }        }      }    },    "/predictive_link_params": {      "get": {        "description": "This API is used by applications to get the                        information about predicted parameters for                        each delivery connection.",        "produces": [          "application/json",          "text/html"        ],        "responses": {          "200": {            "description": "OK",            "schema": {              "$ref": "#/definitions/link-params"            }          },          "default": {            "description": "unexpected error",            "schema": {              "$ref": "#/definitions/errorModel"            }          }        }      }    }  },  "definitions": {    "connection-id": {      "type": "integer",      "format": "uint8"    },    "connection-type": {      "enum": [        "Wi-Fi",        "5G NR",        "MulteFire",        "LTE"      ],      "type": "string"    },    "features": {      "enum": [        "lossless_switching",        "fragmentation",        "concatenation",        "uplink_aggregation",        "downlink_aggregation",        "measurement"      ],      "type": "string"    },    "adaptation-methods": {      "enum": [        "UDP_without_DTLS",        "UDP_with_DTLS",        "IPsec",        "Client_NAT"      ],      "type": "string"    },    "convergence-methods": {      "enum": [        "GMA",        "MPTCP_Proxy",        "GRE_Aggregation_Proxy",        "MPQUIC"      ],      "type": "string"    },    "connection": {      "type": "object",      "properties": {        "conn-id": {          "$ref": "#/definitions/connection-id"        },        "conn-type": {          "$ref": "#/definitions/connection-type"        }      }    },    "convergence-parameters": {      "type": "object",      "properties": {        "conv-param-name": {          "type": "string"        },        "conv-param-value": {          "type": "string"        }      }    },    "convergence-details": {      "type": "object",      "properties": {        "conv-method": {          "$ref": "#/definitions/convergence-methods"        },        "conv-params": {          "type": "array",          "items": {            "$ref": "#/definitions/convergence-parameters"          }        }      }    },    "capability": {      "type": "object",      "properties": {        "connections": {          "type": "array",          "items": {            "$ref": "#/definitions/connection"          }        },        "features": {          "type": "array",          "items": {            "$ref": "#/definitions/features"          }        },        "adapt-methods": {          "type": "array",          "items": {            "$ref": "#/definitions/adaptation-methods"          }        },        "conv-methods": {          "type": "array",          "items": {            "$ref": "#/definitions/convergence-details"          }        }      }    },    "qos-param-name": {      "enum": [        "jitter",        "latency",        "bandwidth"      ],      "type": "string"    },    "qos-param": {      "type": "object",      "properties": {        "qos-param-name": {          "$ref": "#/definitions/qos-param-name"        },        "qos-param-value": {          "type": "integer"        }      }    },    "port-range": {      "type": "object",      "properties": {        "start": {          "type": "integer"        },        "end": {          "type": "integer"        }      }    },    "protocol-type": {      "type": "integer"    },    "stream-features": {      "type": "object",      "properties": {        "proto": {          "$ref": "#/definitions/protocol-type"        },        "port-range": {          "$ref": "#/definitions/port-range"        },        "traffic-qos": {          "$ref": "#/definitions/qos-param"        }      }    },    "app-requirements": {      "type": "object",      "properties": {        "num-streams": {          "type": "integer"        },        "stream-feature": {          "type": "array",          "items": {            "$ref": "#/definitions/stream-features"          }        }      }    },    "param-name": {      "enum": [        "bandwidth",        "jitter",        "latency",        "signal_quality"      ],      "type": "string"    },    "additional-param-name": {      "enum": [        "lte-rsrp",        "lte-rsrq",        "nr-rsrp",        "nr-rsrq",        "wifi-rssi"      ],      "type": "string"    },    "link-parameter": {      "type": "object",      "properties": {        "connection": {          "$ref": "#/definitions/connection"        },        "param": {          "$ref": "#/definitions/param-name"        },        "additional-param": {          "$ref": "#/definitions/additional-param-name"        },        "prediction": {          "type": "integer"        },        "likelihood": {          "type": "integer"        },        "validity_time": {          "type": "integer"        }      }    },    "link-params": {      "type": "array",      "items": {        "$ref": "#/definitions/link-parameter"      }    },    "errorModel": {      "type": "object",      "description": "Error indication containing the error code and                      message.",      "required": [        "code",        "message"      ],      "properties": {        "code": {          "type": "integer",          "format": "int32"        },        "message": {          "type": "string"        }      }    }  }}      <!-- [rfced] Appendix D:  Should "lte-rspq" be "lte-rsrq" here?Original: "lte-rspq", -->      <!-- [author1] Correct - fixed the typo -->    </section>    <section Example Using Python for MAMS Client and      <section        <t>A simple client-side implementation using Python can be as follows:</t>#!/usr/bin/env pythonimport asyncioimport websocketsimport jsonimport sslimport timeimport syscontext = ssl.SSLContext(ssl.PROTOCOL_TLS)context.verify_mode = ssl.CERT_REQUIREDcontext.set_ciphers("RSA")context.check_hostname = Falsecontext.load_verify_locations("/home/mecadmin/certs/rootca.pem")discoverMsg = {'version':'1.0','message_type':'mx_discover'}MXCapabilityRes = {'version':'1.0','message_type':'mx_capability_res','FeatureActive':[{'feature_name':'fragmentation', 'active':'yes'},    {'feature_name':'lossless_switching', 'active':'yes'}],'num_anchor_connections':1,'anchor_connections':[{'connection_id':0, 'connection_type':'LTE'}],'num_delivery_connections':1,'delivery_connections':[{'connection_id':1, 'connection_type':"Wi-Fi"}],'convergence_methods':[{'method':'GMA', 'supported':'true'}],'adaptation_methods':[{'method':'client_nat', 'supported':'false'}]}async def hello():    async with websockets.connect('wss://localhost:8765', ssl=context)       as websocket:     try:      loopFlag=False      while True:          await websocket.send(json.dumps(discoverMsg))          json_message = await websocket.recv()          message = json.loads(json_message)          if "message_type" in message.keys():            print("Received message:{}".format(message["message_type"]),               "version:{}".format(message["version"]))            if message["message_type"] == "mx_capability_req" :                await websocket.send(json.dumps(MXCapabilityRes))                loopFlag=True                while(loopFlag==True):                      pass     except:          print("Client stopped")asyncio.get_event_loop().run_until_complete(hello())        <!-- [rfced] Appendices E.1 and E.2:  We changed "Recieved" to"Received" in these print() calls.  Please let us know any objections.Original: print("Recieved message:{}".format(message["message_type"]), ...... print("Recieved message:{}".format(msg["message_type"]), ...Currently: print("Received message:{}".format(message["message_type"]),... print("Received message:{}".format(msg["message_type"]), -->        <!-- [author1] Changes accepted with thanks. -->      </section>      <section        <t>A server-side implementation using Python can be as follows:</t>        <!-- [rfced] Appendix E.2:  We changed "server client sideimplementation" to "server-side implementation" per the titleof this appendix.  Please let us know if this is incorrect.Original: A server client side implementation using python can be as following:Currently: A server-side implementation using Python can be as follows: -->        <!-- [author1] Changes accepted with thanks.-->#!/usr/bin/env pythonimport asyncioimport websocketsimport jsonimport sslctx = ssl.SSLContext(ssl.PROTOCOL_TLS)#ctx.set_ciphers("RSA-AES256-SHA")ctx.load_verify_locations("/home/mecadmin/certs/rootca.pem")certfile = "/home/mecadmin/certs/server.pem"keyfile = "/home/mecadmin/certs/serverkey.pem"ctx.load_cert_chain(certfile, keyfile, password=None)MXCapabilityReq = {'version':'1.0','message_type':'mx_capability_req','FeatureActive':[{'feature_name':'fragmentation', 'active':'yes'},    {'feature_name':'lossless_switching', 'active':'yes'}],'num_anchor_connections':1,'anchor_connections':[{'connection_id':0, 'connection_type':'LTE'}],'num_delivery_connections':1,'delivery_connections':[{'connection_id':1, 'connection_type':"Wi-Fi"}],'convergence_methods':[{'method':'GMA', 'supported':'true'}],'adaptation_methods':[{'method':'client_nat', 'supported':'false'}]}async def hello(websocket, path): try:   while True:     name = await websocket.recv()     msg = json.loads(name)     if "message_type" in msg.keys():        print("Received message:{}".format(msg["message_type"]),           "version:{}".format(msg["version"]))        if msg['message_type'] == 'mx_discover':           await websocket.send(json.dumps(MXCapabilityReq)) except:      print("Client disconnected")try: start_server = websockets.serve(hello, 'localhost', 8765,ssl=ctx) asyncio.get_event_loop().run_until_complete(start_server) asyncio.get_event_loop().run_forever()except: print("Server stopped")      </section>    </section>    <section      <t>This protocol is the outcome of work by many engineers, not just the authors     of this document. The people who contributed to this project,     listed in alphabetical order by first name, are Barbara Orlandi, Bongho Kim,     David Lopez-Perez, Doru Calin, Jonathan Ling, Lohith Nayak, and Michael Scharf.</t>    </section>    <section      <t>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, 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&nbhy;plane protocol aspects.</t>      <!-- [author1] Corrected the name (order of "first name" and "last name") of contributing author Subramanian Vasudevan,and updated affiliations for Hannu Flinck and A Krishna Pramod -->      <!-- [rfced-auth48]  Authors and *[ISE]:  We changed "ContributingAuthors" to "Contributors" per Section 4.1.1 of RFC 7322 ("RFC StyleGuide") and https://www.rfc-editor.org/old/policy.html ("Authors vs.Contributors" and "Author Overload").  Please let us know anyconcerns. -->      <!-- [author1] OK. -->    </section>    <!-- [rfced-auth48] Please let us know if any changes are needed for thefollowing:a) The following terms were used inconsistently in this document.We chose to use the latter forms.  Please let us know any objections. acknowledgement / acknowledgment (in text only - not in code, i.e.,   the two instances of "capability_acknowledgement" are left as is)-->    <!-- [author1] Made changes in code as well to be consistent - "acknowledgment" is used at all places now.-->    <!-- [rfced-auth48] keep alive / keep-alive (used generally)-->    <!-- [author1] OK-->    <!-- [rfced-auth48] IPSec* / IPsec (per our style guidelines)    * Note:  Please let us know if the instances of "IPSec" in the      code in Appendices C and D cannot be modified; if that is the      case, we will revert those changes.-->    <!-- [author1] OK. "IPsec" is correct-->    <!-- [rfced-auth48] Client (used generally; 5 instances in text) /   client (used generally; approx. 95 instances in text)   (Also, we see the lowercase form "server" used in text)-->    <!-- [author1] OK.-->    <!-- [rfced-auth48] a MX / an MX (per post-6000  published RFCs, except for RFC 6672)-->    <!-- [author1] OK.-->    <!-- [rfced-auth48] initialization phase / Initialization phase (in text)-->    <!-- [author1] OK.-->    <!-- [rfced-auth48] MX Reconfiguration REQ Message / MX Reconfiguration REQ message-->    <!-- [author1] OK. We also found some other message types where "Message" was capitalised, and we fixed them.-->    <!-- [rfced-auth48] MX control PDU / MX Control PDU (in text)-->    <!-- [author1] OK.-->    <!-- [rfced-auth48] active phase / Active phase (in text)-->    <!-- [author1] OK.-->    <!-- [rfced-auth48] Spacing:  { 'version':'1.0', / {'version':'1.0',-->    <!-- [author1] OK.-->    <!-- [rfced-auth48] b) The following terms appear to be used inconsistently in thisdocument.  Please let us know which form is preferred. N+MADP (4 instances - Figures 6, 20, 21, and 22) /   N-MADP (57 instances)-->    <!-- [author1] OK. Changed all to N-MADP-->    <!-- [rfced-auth48] capability phase / capability exchange phase-->    <!-- [author1] OK. Changed.-->    <!-- [rfced-auth48] Access Link / access link (in text)-->    <!-- [author1] OK. The remaining occurrences of "Access Link" are either in titles or as parameter definitions and should remain capitalised.-->    <!-- [rfced-auth48] convergence layer / Convergence layer / Convergence Layer (in text)**-->    <!-- [author1] OK. Changed to all be capitalised.-->    <!-- [rfced-auth48] convergence sublayer / Convergence sublayer /   Convergence Sublayer (in text)**-->    <!-- [author1] See next point.-->    <!-- [rfced-auth48] ** Are "convergence layer" and "convergence sublayer" the same thing,   or different entities?  We ask because we see   "It consists of the following two Sublayers" in Section 7.2.-->    <!-- [author1] Sublayer and Layer are same - thanks for catching the inconsistency - have fixed it, and used "Layer" at all places.-->    <!-- [rfced-auth48] adaptation layer / Adaptation layer / Adaptation Layer (in text)***-->    <!-- [author1] OK. Changed to all be capitalised.-->    <!-- [rfced-auth48] adaptation sublayer / Adaptation Sublayer***-->    <!-- [author1] See next point.-->    <!-- [rfced-auth48] *** Are "adaptation layer" and "adaptation sublayer" the same thing,    or different entities?  As noted above, we ask because of    "It consists of the following two Sublayers" in Section 7.2.-->    <!-- [author1] Sublayer and Layer are same - thanks for catching the inconsistency - have fixed it, and used "Layer" at all places.-->    <!-- [rfced-auth48] MX Adaptation (layer or sublayer)?  "MX Adaptation can be   implemented ..."  Should this be followed by the word "layer"   or "sublayer"?-->    <!-- [author1] Fixed - It should be Adaptation Layer.-->    <!-- [rfced-auth48] MPTCP Proxy / MPTCP proxy-->    <!-- [author1] OK. Changed in text. Retained "Proxy" in parameter definitions.-->    <!-- [rfced-auth48] Active Probe Results Configuration / Active Probe Results configuration-->    <!-- [author1] There is one instance (section 8.6) of this, in the parameter definition. It seems ok to leave the capitalization "Configuration" as it is.-->    <!-- [rfced-auth48] MuLTEfire / MulteFire-->    <!-- [author1] OK. Changed.-->    <!-- [rfced-auth48] 2: Multi-Fire; (1 instance) / 2: MulteFire; (8 instances)-->    <!-- [author1] OK. Changed.-->    <!-- [rfced-auth48] SYSTEM INFO / System INFO / System Info-->    <!-- [author1] OK.-->    <!-- [rfced-auth48] MX Discovery Message / MX Discover Message /   MX Discover message (in text)-->    <!-- [author1] OK. The message name is "MX Discover" - this has been made consistent now across the document.     And 'message' is lower case.-->    <!-- [rfced-auth48] MAMS Control Message / MAMS Control message /   MAMS control message (in text)-->    <!-- [author1] OK. Fixed at remaining places as well to consistently use "MAMS control message"-->    <!-- [rfced-auth48] CAPABILITY REQ / Capability REQ-->    <!-- [author1] OK. Changed.-->    <!-- [rfced-auth48] RECONFIGURATION REQ / Reconfiguration REQ-->    <!-- [author1] OK. Changed.-->    <!-- [rfced-auth48] RECONF[ONF]IGURATION RSP / Reconfiguration RSP (spelling has been   corrected)-->    <!-- [author1] OK. Changed.-->    <!-- [rfced-auth48] setup request / Setup Request-->    <!-- [author1] OK. Actually change done (by RFCED) is the other way round "Setup Request => setup request", but that is OK as well.-->    <!-- [rfced-auth48] MX UP SETUP CFG (1 instance) / MX UP Setup Config (4 instances)-->    <!-- [author1] OK. Changed.-->    <!-- [rfced-auth48] MX UP SETUP CNF (1 instance) / MX UP Setup CNF (3 instances)-->    <!-- [author1] OK. Changed.-->    <!-- [rfced-auth48] Probe REQ ("Probe REQ/ACK") / Probe-REQ ("Probe-REQ/ACK")-->    <!-- [author1] OK. Changed.-->    <!-- [rfced-auth48] traffic Template / traffic template / Traffic Template**** traffic flow template / Traffic Flow Template**** **** Does "the flow template" mean "the traffic template,"      "the TFT," or something else?-->    <!-- [author1] traffic template is same as Traffic Flow Template or TFT. Made changes to consistently use "Traffic Flow Template"-->    <!-- [rfced-auth48] id / Id / ID (e.g., "Connection ID," "connection ID,"   "Connection Id," "Connection id," "connection Id,"   "connection id," "Delivery connection id,"   "delivery node id," "Wi-Fi AP Id,"   "Wi-Fi Access Point Id," "MADP instance ID,"   "MADP Instance ID," "NCM id," "session id"   "unique session id," "Unique Session Id,"   "Anchor Connection ID," "Anchor connection Id,"   "MX Configuration ID," "MX Configuration Id,"   "configuration id"-->    <!-- [author1] OK. Changed to "ID".-->    <!-- [rfced-auth48] Ack / ACK (e.g., "Probe Ack," "Probe ACK"-->    <!-- [author1] OK. Changed to use "ACK" consistently.-->    <!-- [rfced-auth48] "wifi" / "wi-fi" (e.g., "connection_type" : "wi-fi",   "connection_type" : "wifi")-->    <!-- [author1] OK. Changed to use "Wi-Fi" consistently.-->    <!-- [rfced-auth48] Spacing before "<1" (yes, no, or doesn't matter?):  For example:    NCMConnection items<1..*>;     JSONNumber connection_id <1..*>;-->    <!-- [author1] Changed to use space before "<1" consistently.-->    <!-- [rfced-auth48] Path Estimation Report (message) / Path Estimation Results (message)-->    <!-- [author1] Changed to use "Path Estimation Results" consistently.-->  </back></rfc>