﻿<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [


<!ENTITY rfc4301 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml'>


<!ENTITY rfc3948 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3948.xml'>


<!ENTITY rfc7296 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml'>

<!ENTITY rfc2119 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'>

]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes" ?> 
<?rfc subcompact="yes" ?>

<rfc category="std" ipr="trust200902" docName="draft-kanugovi-intarea-mams-protocol-04">


<front>
<title abbrev="MAMS">Multiple Access Management Services</title>

<author fullname="Satish Kanugovi" initials="S." surname="Kanugovi">
      <organization>Nokia</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <region/>

          <code></code>

          <country></country>
        </postal>

        <phone/>

        <facsimile/>

        <email>satish.k@nokia.com</email>

        <uri/>
      </address>
    </author>

 <author fullname="Subramanian Vasudevan" initials="S." surname="Vasudevan">
      <organization>Nokia</organization>

      <address>
        <postal>
          <street></street>

          <!-- Reorder these if your country does things differently -->

          <city></city>

          <region/>

          <code></code>

          <country></country>
        </postal>

        <phone></phone>

        <email>vasu.vasudevan@nokia.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>



<author fullname="Florin Baboescu" initials="F." surname="Baboescu">
      <organization>Broadcom</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region/>
          <code/>
          <country></country>
        </postal>
        <phone/>
        <facsimile/>
        <email>florin.baboescu@broadcom.com</email>
        <uri/>
      </address>
</author>

<author fullname="Jing Zhu" initials="J." surname="Zhu">
      <organization>Intel</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region/>
          <code/>
          <country></country>
        </postal>
        <phone/>
        <facsimile/>
        <email>jing.z.zhu@intel.com</email>
        <uri/>
      </address>
</author>

<author fullname="Shuping Peng" initials="S." surname="Peng">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region/>
          <code/>
          <country></country>
        </postal>
        <phone/>
        <facsimile/>
        <email>pengshuping@huawei.com</email>
        <uri/>
      </address>
</author>

<author fullname="Julius Mueller" initials="J." surname="Mueller">
      <organization>AT&amp;T</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region/>
          <code/>
          <country></country>
        </postal>
        <phone/>
        <facsimile/>
        <email>jm169k@att.com</email>
        <uri/>
      </address>
</author>

<author fullname="SungHoon Seo" initials="S." surname="Seo">
      <organization>Korea Telecom</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region/>
          <code/>
          <country></country>
        </postal>
        <phone/>
        <facsimile/>
        <email>sh.seo@kt.com</email>
        <uri/>
      </address>
</author>

<date day="27" month="March" year="2017"/>


<area>INTERNET</area><workgroup>INTAREA</workgroup>
<abstract>

	<t> A communication network includes an access network segment that
   delivers data to/from the users and an associated core network segment
   providing connectivity with the application servers.
   Multiconnectivity scenarios are common where an end-user device can simultaneously connect to multiple communication networks based on
   different technology implementations and network architectures like
   WiFi, LTE, DSL.  A smart selection and combination of access and core
   network paths that can dynamically adapt to changing network
   conditions can improve quality of experience for a user in such a
   Multiconnectivity scenario and improve overall network utilization
   and efficiency.  This document presents the problem statement and
   proposes solution principles.  It specifies the requirements and
   reference architecture for a multi-access management services
   framework that can be used to flexibly select the best combination of
   access and core network paths for uplink and downlink, as well as the    
flexible usage of uplink and downlink, ensuring better
   network efficiency and enhanced application performance. 
     </t>
 </abstract>
</front>

<middle>
	
      <section title="Conventions used in this document">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in <xref target="RFC2119"/>. </t>
      </section>

<section title="Contributing Authors">
<t>

   The editors gratefully acknowledge the following additional
   Contributors in alphabetical order: Hannu Flinck/Nokia, Nurit Sprecher/Nokia
</t></section>

<section title="Introduction">
    

<t>
Multi Access Management Services (MAMS) is a programmable framework that provides mechanisms for flexible selection of network paths in a multi-access communication environment, based on application needs, which can leverage network intelligence and policies to dynamically adapt to changing network/link conditions. The network path selection and configuration procedures use the user plane to exchange data between the functional elements in the network and the end-user device without any impact to the control plane signaling schemes of each individual access network. For example, in a multi-access network with LTE and WiFi technologies, existing LTE and existing WiFi signaling procedures will be used to setup the LTE and WiFi connections, respectively. The proposed MAMS framework offers the capabilities of smart selection and flexible combination of access paths and core network paths. It is a broad programmable framework providing functions beyond just sharing network policies, e.g. in comparison to ANDSF that provides policies/rules for assisting 3GPP devices to discover and select available access networks, that allows choosing and configuring user plane protocols and treatment depending on needs of the application.
</t>

<t>
The document presents the requirements, solution principles and
   functional architecture for the MAMS framework.  MAMS mechanisms are
   not dependent on any specific network and transport protocols like
   TCP, UDP, GRE, MPTCP etc.  It co-exists and complements the existing
   protocols by providing a way to negotiate and configure the protocols
   based on client and network capabilities.  Further it allows exchanges
   of network state information and leveraging network intelligence to
   optimize the performance of such protocols.
</t>

<t>
   An important goal for MAMS is to ensure that there is minimal or no
   dependency on the actual access technologies of the participating
   links, beyond the fact that the MAMS functional elements can be placed in the user plane.
This allows the scheme to be future proof, for addition of new access technologies and for independent technology evolution of the existing access and core networks.
</t>

</section>

      <section title="Terminology">

     <t> "Client": The end-user device supporting connections with multiple access nodes, possibly over different access technologies.
     </t>

        <t>"Multiconnectivity Client”: A client with multiple network connections.</t>

        <t>"Access network": The segment in the network that delivers user data packets to the client via an access link like WiFi airlink, LTE airlink, or DSL.</t>

      <t> "Core": The functional element that anchors the client’s IP address used for communication with applications via the network. 
       </t>

       <t> 
	     "User Plane Gateway": The functional element that can intercept and route user data packets.
   </t>

 <t> 
	     "Network Connection manager"(NCM): A functional entity in the network that oversees distribution of data packets over the multiple available access and core network paths.
   </t>

 <t> 
	     "Client Connection Manager" (CCM): A functional entity in the client that exchanges MAMS Signaling with the Network Connection Manager and configures the multiple network paths for transport of user data.
   </t>

 
 <t> 
"Network Multi Access Data Proxy" (N-MADP): This functional entity in the network handles the user data 
   traffic forwarding across multiple network paths. N-MADP is responsible for MAMS related user-plane functionalities in the network.
   </t>

<t> 
	     "Client Multi Access Data Proxy" (C-MADP): This functional entity in the client handles the user data traffic forwarding across multiple network paths. C-MADP is responsible for MAMS related user-plane functionalities in the client.
   </t>

      </section>
    

    <section title="Problem Statement">
    

  <t> Typically, an end-user device has access to multiple communication networks based on different technologies, say LTE, WiFi, DSL, MuLTEfire, for accessing application services.  Different technologies exhibit
   benefits and limitations in different scenarios.  For example, WiFi
   leverages the large spectrum available in unlicensed spectrum to
   deliver high capacities at low cost in uncongested scenarios with
   small user population, but can show significant degradation in
   application performance in congested scenarios with large user
   population.  Another example is LTE network, the capacity of which is
   often constrained by high cost and limited availability of the
   licensed spectrum, but offers predictable service even in multi-user
   scenarios due to controlled scheduling and licensed spectrum usage.
</t>
<t>
Additionally, the use of a particular access network path is often
   coupled with the use of its associated core network.  For example, in
   an enterprise that has deployed WiFi and LTE communications network,
   enterprise applications, 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 LTE operator core anchored services including access to public
   Internet.
</t>

<t>
   Application performance in different scenarios, therefore becomes
   dependent on the choice of the communication networks based on different technologies (e.g. WiFi and LTE) due to the
   tight coupling of the access and the core network paths.  Therefore
   to achieve the best possible application performance in a wide
   range of possible scenarios, a framework is needed that allows 
   the selection and flexible combination of access and core network paths for uplink and downlink data delivery.
</t>
<t>
For example, in uncongested scenarios, it would be beneficial to use
   WiFi access in both uplink and downlink for connecting to enterprise
   applications.  Whereas in congested scenarios, where use of WiFi in
   uplink by multiple users can lead to degraded capacity and increased
   delays due to contention, it would be beneficial to use scheduled LTE
   as uplink combined with WiFi as downlink.
</t>

</section>

<section title="Solution Principles">
    
    
<t>
This document proposes a Multiple Access Management Services(MAMS)
   framework for dynamic selection and flexible combination of access and
   core network paths as uplink and downlink for a device connected to multiple communication
   networks.  The multiple communication networks interwork at the user
   plane.  The selection of paths is based on negotiation of
   capabilities (of device and network) and network link quality between the user plane functional elements at the end-user device/client (C-MADP) and the 
   network (N-MADP).NCM has the intelligence to setup and offer the best
   network path based on device and network capabilities, application
   needs and knowledge of the network state.
</t>

<t>
The NCM communicates with the Client Connection Manager (CCM), a
   functional element in the device, for negotiation, sharing
   information on the network path conditions, and configuring usage of
   the network paths.  The messages between the NCM and CCM are carried
   as user plane data over any of the available network paths between
   the NCM and CCM.
</t>

</section>
      

<section title="Requirements">

<t>
The requirements set out in this section are for the definition of behavior of the MAMS mechanism and the related functional elements. 
</t>

<section title="Access technology agnostic interworking">
<t>
   The access nodes can be of different technology types like LTE, WiFi
   etc.  Since MAMS routes user plane data packets at the IP layer,
   which makes it agnostic to the type of underlying technology used at
   the access nodes.
</t>
</section>

<section title="Support common transport deployments">
<t>
   The network path selection and user data distribution should work
   transparently across transport deployments that include e2e IPsec,
   VPNs, and middleboxes like NATs and proxies.
</t>
</section>

<section title="Independent Access path selection for Uplink and Downlink">
<t>
IP layer routing enables the client to transmit on uplink using one access and receive data on downlink using another access, allowing client and network connection manager to select the access paths for uplink and downlink independent of each other.
</t>
</section>

<section title="Core selection independent of uplink and downlink access">
<t>
A client is able to flexibly select the Core, independent of the access paths used to reach the Core, depending on the application needs.
</t>
</section>

<section title="Adaptive network path selection">
<t>
   The MAMS functional elements have the ability to determine the
   quality of each of the network paths, e.g. access link delay and
   capacity.  The network path quality information is fed into the logic
   for selection of combination of network paths to be used for
   transporting user data.  The path selection algorithm can use network
   path quality information, in addition to other considerations like
   network policies, for optimizing network usage and enhancing QoE
   delivered to the user.
</t>
</section>

<section title="Multipath support and Aggregation of access link capacities">
<t>
   MAMS supports distribution and aggregation of user data across
   multiple network paths at the IP layer. MAMS allows the client to leverage the
   combined capacity of the multiple network connections by enabling
   simultaneous transport of user data over multiple network paths.  If
   required, packet re-ordering is done at the receiver, client(C-MADP) and/or
   the network (N-MADP), when user data packets are received out
   of order.  MAMS allows flexibility to choose the flow steering and
   aggregation protocol based on capabilities supported by the client
   and the network data plane entities, C-MADP and N-MADP respectively. 
   A MAMS multi-connection aggregation solution should support existing transport and network layer protocols like TCP, UDP, GRE. 
   If flow aggregation functions are realized using existing protocols such as Multi-Path TCP(MPTCP) and SCTP, MAMS framework should allow use and configuration of these aggregation protocols.

</t>
</section>

<section title="Scalable mechanism based on user plane interworking">
<t>
   The mechanism is based on user plane interworking, requiring only that the MAMS functional elements (NCM and N-MADP) should be added in the user plane path between the client and the network. The interworking functionality is based on generically available routing and tunneling capabilities. This makes solution easy to deploy and scale when different networks are added and removed.
</t>
</section>

<section title="Separate Control and Data plane functions">
<t>
The client negotiates with a network connection manager on the choice of access for both uplink and downlink, as well as the Core.
   The network connection manager configures the actual user plane data distribution function. This allows common control protocol to be used with multiple and potentially different user plane (e.g. tunneling) protocols, thus maintaining a clear separation between the control and data plane functions.  This makes the MAMS framework scalable and extensible, e.g. by being amenable to SDN based architecture and implementations.
</t>
</section>

<section title="Lossless Path (Connection) Switching">
<t>
When switching data traffic from one path (connection) to another, packets may be lost or delivered out-of-order, which will have negative impacts on the performance of higher layer protocols, e.g. TCP. MAMS should provide necessary mechanisms to ensure in-order delivery at the receiver, as well as support retransmissions at the transmitter during path switching.
</t>
</section>

<section title="Concatenation and Fragmentation to adapt to MTU differences">
<t>
MAMS should support heterogeneous access networks, which may have different MTU sizes. Moreover, tunneling protocols also have a big impact on the MTU size. Hence, MAMS should support concatenation such that multiple IP packets may be encapsulated into a single packet to improve efficiency. MAMS should also support fragmentation such that a single IP packet may be fragmented and encapsulated into multiple ones to avoid IP fragmentation.
</t>
</section>

<section title="Configuring network middleboxes based on negotiated protocols">
<t>
MAMS enables identification of the optimal parameters that may be used for configuring the middle-boxes, like binding expiry times and supported MTUs, for efficient operation of the user plane protocols, depending on the data plane related parameters negotiated between the client and the network, e.g. Configuring longer binding expiry time in NATs when UDP transport is used in contrast to the scenario where TCP is configured at the transport layer.
</t>
</section>

<section title="Policy based Optimal path selection">
<t>
MAMS framework should support consideration of policies at the client, in addition to guidance from the network in determination of network paths selected for different application services.
</t>
</section>

<section title="MAMS Control signaling">
<t>
MAMS control signaling is carried over the user plane and is transparent to the transport protocols. MAMS should support delivery of control signaling over the existing Internet protocols, e.g. TCP or UDP.
</t>
</section>

<section title="Service discovery and reachability">
<t>
   MAMS offers the flexibility for the functional entity NCM to be
   collocated with any of the network elements and reachable via any of
   the available user plane paths.  MAMS framework allows the
   flexibility for the CCM to choose one of the available NCMs and
   exchange control plane signaling over any of the available user plane
   paths.  The choice of NCM can be based on considerations like, but
   not limited to, quality of link through which the NCM is reachable,
   Client preference, or pre-configuration etc.
</t>
</section>

</section>

<section title="MAMS Reference Architecture">
    
    
         <figure anchor="figure1" title="MAMS Reference Architecture">
        <artwork align="center"><![CDATA[
		
+---------------------------------------------------+
!     +---------------+       +---------------+     !
!     !               !       !               !     !
!     !Core(IP anchor)!       !Core(IP anchor)!     !
!     !(network n)    !       !(network 1)    !     !
!     !               !       !               !     !
!     +---------------+       +---------------+     !
!          +-----------------------+                !
!          ! +-----+  +------+     !                !
!          ! ! NCM !  !N-MADP|     !                !
!          ! +-----+  +------+     !                !
!          +-----------------------+                !
!                                                   !
!     +-----------+            +---------------+    !
!     !           !            !               !    !
!     !           !            !               !    !
!     !access     !            !access         !    !
!     !(network n)!            !(network 1)    !    !
!     !           !            !               !    !
!     +-----------+            +---------------+    !
+---------------------------------------------------+


		+-----------------+
		! +------+ +-----+!
		! |C-MADP| ! CCM !!
		! +------+ +-----+!
		!        Client   !
		+-----------------+
]]></artwork>
      </figure>
    
<t>
   Figure 1 illustrates MAMS architecture for the scenario of a client
   served by multiple (n) networks.  The NCM and N-MADP, functional elements, are
   introduced for supporting MAMS mechanisms.  The architecture is
   extendable to combine any number of networks, as well as any choice of
   participating network types (e.g.  LTE, WLAN, MuLTEfire, DSL) and
   deployment architectures (e.g. with user plane gateway function at
   the access edge).
</t>
<t>

   The N-MADP entity, at the network, handles the user data traffic forwarding across multiple network paths, as well as other user-plane functionalities, e.g. encapsulation, fragmentation, concatenation, reordering, retransmission, etc. 

 N-MADP is the distribution node for uplink and downlink data delivery with visibility of packets at the IP layer. There can be multiple N-MADP entities in the network, e.g. to load balance across clients. A single client can also be served by multiple N-MADP instances, e.g to address different user plane requirements of multiple applications running on the client.
   Identification and distribution rules for different user data traffic
   types at the N-MADP are configured by the NCM.
   The NCM configures the data delivery paths, access links, and user plane protocols to be used by N-MADP for downlink user data traffic.  The CCM configures the data delivery paths, access links, and user plane protocols to be used by C-MADP for uplink user data traffic based on the signaling exchanged with NCM. In the UL, NCM allows selection of the core network path to be used by N-MADP to route uplink user data.
</t>

<t>
The scheduling and load balancing algorithm at the N-MADP is
   configured by the NCM, based on static and/or dynamic network
   policies like assigning access and core paths for specific user data
   traffic type, data volume based percentage distribution, and link
   availability and feedback information from exchange of MAMS signaling
   with the CCM at the Client.
</t>

<t>
      At the client, the Client Connection Manager (CCM) manages the
   multiple network connections.  CCM is responsible for exchange of
   MAMS signaling messages with the NCM for supporting functions like
   UL and DL user network path configuration for transporting user
   data packets, link probing and reporting to support adaptive network 
   path selection by NCM.  

   In the downlink, for
   the user data received by the client, it configures C-MADP such that application data packet received over any of the
   accesses to reach the appropriate application on the client.
   In the uplink, for the data transmitted by the client, it configures
   the C-MADP to determine the best access links to be used for uplink
   data based on a combination of local policy and network policy
   delivered by the NCM.  
The C-MADP entity handles all MAMS-specific
   user-plane functionalities at the client, e.g. encapsulation,
   fragmentation, concatenation, reordering, retransmissions, etc.
   C-MADP is configured by CCM based on signaling exchange with NCM and
   local policies at the client.
</t>

<t>
   A user plane tunnel, e.g.  IPsec, may be needed for transporting user
   data packets between the N-MADP at the network and the C-MADP at the
   client.  The user plane tunnel is needed to ensure security and
   routability of the user plane packets between the N-MADP and the
   C-MADP.  The most common implementation of the user plane tunnel is
   the IPsec.  C-MADP receives the configuration from CCM indicates, to
   C-MADP, the access network interfaces over which the IPsec tunnel
   needs to be established, and for each of the indicated interfaces,
   the parameters (e.g.  N-MADP IPsec endpoint IP address reachable via
   the indicated access network interface) for setting up the IPsec
   tunnel.  C-MADP sets up the IPsec tunnel with the N-MADP via each of
   the indicated access network interfaces, using appropriate signaling,
   say IKEv2 and parameters provided by the CCM.  In deployments where
   N-MADP and the client are connected via a
   secure and direct IP path, user plane tunnel may not be needed.
   Note that the method for transporting user data packets between the
   N-MADP and the C-MADP should be general, based on the existing
   protocols, and consider minimizing overhead.
</t>


   </section>
      
      
	<section title=" Solution Principles">

         <figure anchor="figure2" title="MAMS call flow">
        <artwork align="center"><![CDATA[
		
                
                       +----------------------------------------+
                       |   MAMS enabled Network of Networks     |
                       | +-----+    +-----+   +-----+    +------+
+-----------------+    | |     |    |     |   |     |    |     ||
|     Client      |    | |Netwo|    |Netwo|   |     |    |     ||
| +-----+ +-----+ |    | |rk 1 |    |rk 2 +   |NCM  |    N-MADP||
| C-MADP  |CCM  | |    | |(LTE)|    |(WiFi)   |     |    |     ||
| +-----+ +-----+ |    | +-----+    +-----+   +-----+    +------|
-+----------------+    +----------------------------------------+
 |   |       |              |          |         |          |
 |   |       |              |          |         |          |
 |   |    1.SETUP CONNECTION|          |         |          |
 |<-----------+------------>|          |         |          |
 |   |       |              +          +         |          |
 |   |       |  2. MAMS Capabilities Exchange    |          |
 |   |       |<-------------+----------+-------->|          |
 |   |       |              |          |         |          |
 |   |       +              |          |         |          |
 |   |    3. SETUP CONNECTION          |         |          |
 |<--+-------------------------------->|         |          |
 | 4c. Config| 4a. NEGOTIATE NETWORK PATHS, FLOW |4b. Config|
 | C-MADP    | PROTOCOL AND PARAMETERS |         |N-MADP    |
 |   |<----->|<-------------+----------+-------->|<-------->|
 |   |       |              +          +         |          |
 |   |       |5. ESTABLISH USER PLANE PATH ACCORDING TO     |
 |   |       | SELECTED FLOW PROTOCOL  |         |          |
 |   |<---------------------+----------+------------------->|
 |   |       |              |          |         |          |
 +   +       +              +          +         +          +

]]></artwork>
      </figure>

       <t>Figure 2 illustrates the MAMS signaling mechanism for negotiation of network paths and flow protocols between the client and the network. In this example scenario, the client is connected to two networks (say LTE and WiFi).
<list style="numbers">
<t>
UE connects to network 1 and gets an IP address assigned by network 1.
</t>

<t>
CCM communicates with NCM functional element via the network 1 connection and exchanges capabilities and parameters for MAMS operation. Note: The NCM credentials (e.g. NCM IP Address) can be made known to the UE by pre-provisioning.
</t>

<t>
Client sets up connection with network 2 and gets an IP address assigned by network 2. 
</t>

<t>
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.
<vspace blankLines="1" />
4a. CCM and NCM negotiate network paths, flow routing and aggregation protocols, and related parameters.
<vspace blankLines="1" />
4b. NCM communicates with the N-MADP to exchange and configure
       flow aggregation protocols, policies and parameters
       in alignment with those negotiated with the CCM.
<vspace blankLines="1" />
4c. CCM communicates with the C-MADP to exchange and configure
       flow aggregation protocols, policies and parameters
       in alignment with those negotiated with the NCM.
<vspace blankLines="1" />

</t>

<t>
C-MADP and N-MADP establish the user plane paths, e.g. using IKE <xref target="RFC7296"></xref> signaling, based on the negotiated flow aggregation protocols and
       parameters specified by NCM.
</t>

</list>
CCM and NCM can further exchange messages containing access link
   measurements for link maintenance by the NCM.  NCM evaluates the link
   conditions in the UL and DL across LTE and WiFi, based on link
   measurements reported by CCM and/or link probing techniques and
   determines the UL and DL user data distribution policy.  NCM and CCM also negotiate application level policies for categorizing applications, e.g.  based on DSCP, Destination IP address, and determining which of the available network 
   paths, needs to be used for transporting data of that category of applications.  NCM configures N-MADP and CCM configures C-MADP based on the negotiated application policies. CCM may apply local 
   application policies, in addition to the application policy conveyed by the NCM.

</t>
</section>

<section title="Implementation considerations">
<t>
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.
</t>
</section>	

<section title="Applicability to Mobile Edge Computing">
<t>
Mobile edge computing (MEC) is an access-edge cloud platform being standardized at ETSI, whose initial focus was to improve quality of experience by leveraging intelligence at cellular (e.g. 3GPP technologies like LTE) access edge, and the scope is now being extended to support access technologies beyond 3GPP. This applicability of the framework described in this document to the MEC platform has been evaluated and tested in different network configurations.
</t>

<t>
The NCM and N-MADP are hosted on the MEC cloud server that is located in the user plane path at the edge of multi-technology access networks, and in a particular large venue use case at the edge of LTE and Wi-Fi access networks. The NCM and CCM negotiate the network path combinations based on application needs and the necessary user plane protocols to manage the multiple paths. The network conditions reported by the CCM to the NCM is used in addition to Radio Analytics application residing at the MEC to configure the uplink and downlink access paths according to changing radio and congestion conditions.
</t>

<t>
The aim of these enhancements is to improve the end-user's quality of experience by leveraging the best network path based on application needs and network conditions, and building on the advantages of significantly reduced latency and the dynamic and real-time exposure of radio network information available at the MEC.
</t>

</section>	


<section title="Security Considerations">
<t>
This section details the security considerations for the MAMS framework.
</t>	
<section title="Data and Control plane security">
<t>
Signaling messages and the user data in MAMS framework rely on the security of the underlying network transport paths. When this cannot be assumed, network connection manager configures use of protocols, like IPsec <xref target="RFC4301"></xref> <xref target="RFC3948"></xref>, for securing user data and MAMS signaling messages.
</t>
</section>	
</section>

    <!-- This PI places the pagebreak correctly (before the section title) in the text output. -->

    <!-- Possibly a 'Contributors' section ... -->


    <section title="Contributors">
      <t>
This protocol is the outcome of work by many engineers, not just the authors of this document.  
In alphabetical order, the contributors to the project are: Barbara Orlandi, Bongho Kim,David Lopez-Perez, Doru Calin, Jonathan Ling, Krishna Pramod A., Lohith Nayak, Michael Scharf.
</t>
    </section>
  </middle>



<back>
<references title="Normative References">
&rfc4301;
&rfc2119;
</references>

<references title="Informative References">
&rfc3948;
&rfc7296;
</references>


</back>
</rfc>
