Control Plane Protocols and Procedures for Multiple Access Management Services

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 .

Multi Access Management Service (MAMS) is a framework to select and configure network paths when multiple connections can serve a client device. It allows the path selection and configuration to adapt to dynamic network conditions. It is based on principles of user plane interworking that enables the solution to be deployed as an overlay without impacting the underlying networks. This document presents the control plane protocols for the MAMS framework. It co-exists and complements user plane protocols (e.g. MPTCP , MPTCP Proxy , , GRE ) by providing a way to negotiate and configure them based on client and network capabilities. It allows exchange of network state information and leverages network intelligence to optimize the performance of such protocols.

"Anchor Connection": Refers to the network path from the N-MADP to the Application Server that corresponds to a specific IP anchor that has assigned an IP address to the client. "Delivery Connection”: Refers to the network path from the N-MADP to the client. "Network Connection Manager" (NCM), "Client Connection Manager" (CCM), "Network Multi Access Data Proxy" (N-MADP), and "Client Multi Access Data Proxy" (C-MADP) in this document are to be interpreted as described in .

The MAMS architecture introduces the following functional elements, Network Connection Manager (NCM) and Client Connection Manager (CCM) in the control plane, and Network Multi Access Data Proxy (N-MADP) and Client Multi Access Data Proxy (C-MADP) handling the user plane. Figure 1 shows the default MAMS control plane protocol stack. WebSocket is used for transporting management and control messages between NCM and CCM.

Figure 2 shows the MAMS user plane protocol stack.

It consists of the following two Sublayers: Multi-Access (MX) Convergence Sublayer: This layer performs multi-access specific tasks, e.g. access (path) selection, multi-link (path) aggregation, splitting/reordering, lossless switching, fragmentation, concatenation, etc. For example, MX Convergence layer can be implemented using existing user plane protocols like MPTCP or by adapting encapsulating header/trailer schemes (e.g Trailer Based MX Convergence as specified in ). Multi-Access (MX) Adaptation Sublayer: This layer performs functions to handle tunnelling, network layer security, and NAT. For example, MX Adaptation can be implemented using IPsec, DTLS or Client NAT (Source NAT at Client with inverse mapping at N-MADP ). The MX Adaptation Layer is optional and can be independently configured for each of the Access Links, e.g. in a deployment with LTE (assumed secure) and Wi-Fi (assumed not secure), the MX Adaptation Sublayer can be omitted for the LTE link but MX Adaptation Sublayer is configured as IPsec for the Wi-Fi link.

CCM and NCM exchange signaling messages to configure the user plane functions, C-MADP and N-MADP, at the client and network respectively. The means for CCM to obtain the NCM credentials (FQDN or IP Address) for sending the initial discovery messages are out of the scope of MAMS document, e.g. using methods like provisioning, DNS query. Once the discovery process is successful, the (initial) NCM can update and assign additional NCM addresses for sending subsequent control plane messages. CCM discovers and exchanges capabilities with the NCM. NCM provides the credentials of the N-MADP end-point and negotiates the parameters for user plane with the CCM. CCM configures C-MADP to setup the user plane path (e.g. MPTCP/UDP Proxy Connection) with the N-MADP based on the credentials (e.g. (MPTCP/UDP) Proxy IP address and port, Associated Core Network Path), and the parameters exchanged with the NCM. The key procedures are described in details in the following sub-sections.

Each MAMS control message consists of the following common fields: Version: indicates the version of MAMS control protocol. Message Type: indicates the type of the message, e.g. MX Discovery, MX Capability REQ/RSP etc. Sequence Number: auto-incremented integer to uniquely identify a transaction of message exchange, e.g. MX Capability REQ/RSP.

This section describes the common procedures for MAMS Control Messages.

MAMS Control plane peer (NCM or CCM) waits for a duration of MAMS_TIMEOUT ms, after sending a MAMS control message, before timing out when expecting a response. The sender of the message will retransmit the message for MAMS_RETRY times before declaring failure. A failure implies that the MAMS peer is dead. CCM may initiate the MAMS discovery procedure for re-establishment of the MAMS session.

MAMS Control plane peers execute the keep alive procedures to ensure that peers are reachable and to recover from dead-peer scenarios. Each MAMS control plane end-point maintains a MAMS_KEEP_ALIVE timer that is set for duration MAMS_KEEP_ALIVE_TIMEOUT. MAMS_KEEP_ALIVE timer is reset whenever the peer receives a MAMS Control message. When MAMS_KEEP_ALIVE timer expires, MAMS KEEP ALIVE REQ message is sent. On reception of a MAMS KEEP ALIVE REQ message, the receiver responds with a MAMS KEEP ALIVE RSP message. If the sender does not receive a MAMS Control message in response to MAMS_RETRY number of retries of MAMS KEEP ALIVE REQ message, the MAMS peer declares that the peer is dead. CCM may initiate MAMS Discovery procedure for re-establishment of the MAMS session. CCM shall additionally send MX KEEP ALIVE REQ message immediately to NCM whenever it detects a handover from one base station/access point to another. During this time the user equipment shall stop using MAMS user plane functionality in uplink direction till it receives a MX KEEP ALIVE RSP from NCM. MX KEEP ALIVE REQ includes following information: Reason: Can be 'Timeout' or 'Handover'. Reason 'Handover' shall be used by CCM only on detection of handover. Unique Session Identifier: As defined in . Connection Id: This field shall be mandatorily be included if the reason is 'Handover'. Delivery Node Identity (ECGI in case of LTE and WiFi AP Id or MAC address in case of WiFi). This field shall be mandatorily be included if the reason is 'Handover'.

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

| | +-----------------+ | |Learn CCM | | | IP address | | |& port | | +-----------------+ | | |<--------------------------------MX System INFO-----| | | |---------------------------------MX Capability REQ->| |<----- MX Capability RSP----------------------------| |---------------------------------MX Capability ACK->| | | + + ]]> Step 1 (Discovery): CCM periodically sends out the MX Discovery Message to a pre-defined (NCM) IP Address/port until MX System INFO message is received in acknowledgement. MX Discovery Message includes the following information: MAMS Version MX System INFO includes the following information: Number of Anchor Connections For each Anchor Connection, it includes the following parameters: Connection ID: Unique identifier for the Anchor Connection Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: LTE) NCM Endpoint Address (For Control Plane Messages over this connection) IP Address or FQDN (Fully Qualified Domain Name) Port Number 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: MX Feature Activation List: Indicates if the corresponding feature is supported or not, e.g. lossless switching, fragmentation, concatenation, Uplink aggregation, Downlink aggregation, Measurement, probing, etc. Number of Anchor Connections (Core Networks) For each Anchor Connection, it includes the following parameters: Connection ID Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: LTE) Number of Delivery Connections (Access Links) For each Delivery Connection, it includes the following parameters: Connection ID Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: LTE) MX Convergence Method Support List Trailer-based MX Convergence MPTCP Proxy GRE Aggregation Proxy MX Adaptation Method Support List UDP Tunnel without DTLS UDP Tunnel with DTLS IPsec Tunnel [RFC3948] Client NAT In response, NCM creates a unique identity for the CCM session, and sends out the MX Capability RSP message, including the following information: MX Feature Activation List: Indicates if the corresponding feature is enabled or not, e.g. lossless switching, fragmentation, concatenation, Uplink aggregation, Downlink aggregation, Measurement, probing, etc. Number of Anchor Connections (Core Networks) For each Anchor Connection, it includes the following parameters: Connection ID Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: LTE) Number of Delivery Connections (Access Links) For each Delivery Connection, it includes the following parameters: Connection ID Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: Multi-Fire; 3: LTE) MX Convergence Method Support List Trailer-based MX Convergence MPTCP Proxy GRE Aggregation Proxy MX Adaptation Method Support List UDP Tunnel without DTLS UDP Tunnel with DTLS IPsec Tunnel [RFC3948] Client NAT Unique Session Identifier: Unique session identifier for the CCM which has setup the connection. In case the session for the UE already exists then the existing unique session identifier is sent back. NCM Id: Unique Identity of the NCM in the operator network. Session Id: Unique identity assigned to the CCM instance by this NCM instance. In response to MX Capability RSP message, the CCM sends confirmation (or reject) in the MX Capability ACK message. MX Capability ACK includes the following parameters Unique Session Identifier: Same identifier as provided in MX Capability RSP. Acknowledgement: An indication if the client has accepted or rejected the capability phase. MX ACCEPT: CCM Accepts the Capability set proposed by the NCM. MX REJECT: CCM Rejects the Capability set proposed by the NCM. If MX_REJECT is received by the NCM, the current MAMS session will be terminated. If CCM can no longer continue with the current capabilities, it should send an MX SESSION TERMINATE message to terminate the MAMS session. In response, the NCM should send a MX SESSION TERMINATE ACK to confirm the termination.

Figure 5 shows the user plane configuration procedure consisting of the following key steps:

| |<------------------------+MX Reconfiguration RSP+---| | +-----------+----------------+ | | NCM prepares N+MADP for | | | User Plane|Setup | | +----------------------------+ |<----------------------------- MX UP Setup Config---| |-----| MX UP Setup CNF+---------------------------->| +-------------------+ | |Link "X" is up/down| | +-------------------+ | |-----MX Reconfiguration REQ (update/release)------->| |<------------------------+MX Reconfiguration RSP+---| ]]> Reconfiguration: when the client detects that the link is up/down or the IP address changes (e.g. via APIs provided by the client OS), CCM sends out a MX Reconfiguration REQ Message to setup / release / update the connection, and the message SHOULD include the following information Unique Session Identifier: Identity of the CCM identity at NCM, created by NCM during the capability exchange phase. Reconfiguration Action: indicate the reconfiguration action (0:release; 1: setup; 2: update). Connection ID: identify the connection for reconfiguration If (Reconfiguration Action is setup or update), then include the following parameters IP address of the connection SSID (if Connection Type = WiFi) MTU of the connection: MTU of the delivery path that is calculated at the UE for use by NCM to configure fragmentation and concatenation procedures[I-D.zhu-intarea-mams-user-protocol] at N-MADP. Delivery Node Identity: Identity of the node to which the client is attached. ECGI in case of LTE and WiFi AP Id or MAC address in case of WiFi. At the beginning of a connection setup, CCM informs the NCM of the connection status using the MX Reconfiguration REQ message with Reconfiguration Action type set to "setup". NCM acknowledges the connection setup status and exchanges parameters with the CCM for user plane setup, described as follows. User Plane Protocols Setup: Based on the negotiated capabilities, NCM sets up the user plane (Adaptation Layer and Convergence Layer) protocols at the N-MADP, and informs the CCM of the user plane protocols to setup at the client (C-MADP) and the parameters for C-MADP to connect to N-MADP. Each MADP instance is responsible for one anchor connection. The MX UP Setup Config consists of the following parameters: Number of Anchor Connections (Core Networks) For Each Anchor Connection, it includes the following parameters Anchor Connection ID Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: LTE) MX Convergence Method Trailer-based MX Convergence MPTCP Proxy GRE Aggregation Proxy MX Convergence Method Parameters Convergence Proxy IP Address Convergence Proxy Port Number of Delivery Connections For each Delivery Connection, include the following: Delivery Connection ID Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: LTE) MX Adaptation Method UDP Tunnel without DTLS UDP Tunnel with DTLS IPSec Tunnel Client NAT MX Adaptation Method Parameters Tunnel Endpoint IP Address Tunnel Endpoint Port Shared Secret e.g. When LTE and Wi-Fi are the two user plane accesses, NCM conveys to CCM that IPsec needs to be setup as the MX Adaptation Layer over the Wi-Fi Access, using the following parameters - IPsec end-point IP address, Pre-Shared Key., No Adaptation Layer is needed or Client NAT may be used over the LTE Access as it is considered secure with no NAT. The MX Convergence Method is configured as MPTCP Proxy along with parameters for connection to the MPTCP Proxy, namely IP Address and Port of the MPTCP Proxy for TCP Applications. Once the user plane protocols are configured, CCM informs the NCM of the status via the MX UP Setup CNF message. The MX UP Setup CNF consists of the following parameters: Unique Session Identifier: Session identifier provided to the client in MX Capability RSP. MX Probe Parameters (included if probing is supported): UDP Port Number for receiving Probes Client Adaptation Layer Parameters: Number of Delivery Connections For each Delivery Connection, include the following: Delivery Connection ID UDP port number: If UDP based adaptation is in use, the UDP port at C-MADP side

Path quality estimations can be done either passively or actively. Traffic measurements in the network could be performed passively by comparing the real-time data throughput of the device with the capacity available in the network. The utilization of a cell/eNB attached to a device could be used as an indicator for path quality estimations without creating an extra traffic overhead. Active measurements by the device are alternatives to measure path quality estimations.

| | | ]]> NCM sends following the configuration parameters in the MX Path Estimation Configuration message to the CCM Connection ID (of Delivery Connection whose path quality needs to be estimated) Init Probe Test Duration (ms) Init Probe Test Rate (Mbps) Init Probe Size (Bytes) Init Probe Ack Required (0 -> No/1 -> Yes) Active Probe Frequency (ms) Active Probe Size (Bytes) Active Probe Test Duration (ms) Active Probe Ack Required (0 -> No/1 -> Yes) CCM configures the C-MADP for probe reception based on these parameters and for collection of the statistics according to the following configuration. Unique Session Identifier: Session identifier provided to the client in MX Capability RSP. Init Probe Results Configuration Lost Probes (%) Probe Receiving Rate (packets per second) Active Probe Results Configuration Average Throughput in the last Probe Duration The user plane probing is divided into two phases - Initialization phase and Active phase. Initialization phase: A network path that is not included by N-MADP for transmission of user data is deemed to be in the Initialization phase. The user data may be transmitted over other available network paths. Active phase: A network path that is included by N-MADP for transmission of user data is deemed to be in Active phase. In Initialization phase, NCM configures N-MADP to send an MX Idle Probe REQ message. CCM collects the Idle probe statistics from C-MADP and sends the MX Path Estimation Results Message to NCM per the Initialization Probe Results configuration. In Active phase, NCM configures N-MADP to send an MX Active Probe REQ message.. C-MADP calculates the metrics as specified by the Active Probe Results Configuration. CCM collects the Active probe statistics from C-MADP and sends the MX Path Estimation Results Message to NCM per the Active Probe Results configuration.

| ]]> NCM sends out a MX Traffic Steering (TS) REQ message to steer data traffic. It is also possible to send data traffic over multiple connections simultaneously, i.e. aggregation. The message includes the following information: Connection ID of the Anchor Connection Connection ID List of Delivery Connections for DL traffic For the number of Specific UL traffic Templates, include the following Traffic Template for identifying the UL traffic Connection ID List of Delivery connections for UL traffic identified by the traffic template MX Feature Activation List: each parameter indicates if the corresponding feature is enabled or not: lossless switching, fragmentation, concatenation, Uplink aggregation, Downlink aggregation, Measurement, probing In response, CCM sends out a MX Traffic Steering (TS) RSP message, including the following information: Unique Session Identifier: Session identifier provided to the client in MX Capability RSP. MX Feature Activation List: each parameter indicates if the corresponding feature is enabled or not: lossless switching, fragmentation, concatenation, Uplink aggregation, Downlink aggregation, probing

NCM indicates the preferred network list to the CCM to guide client on networks that it should connect to. To indicate preferred Wi-Fi Networks, the NCM sends the list of WLAN networks, represented by SSID/BSSID/HESSID, available in the MX SSID Indication.

| ]]> NCM configures the CCM with the different parameters (e.g. radio link information), with the associated thresholds to be reported by the client. The MX MEAS CONFIG message contains the following parameters. For each Delivery Connection, include the following: Delivery Connection ID Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: LTE) If Connection Type is Wi-Fi WLAN_RSSI_THRESH: High and Low Thresholds for sending Average RSSI of the Wi-Fi Link. WLAN_RSSI_PERIOD: Periodicity in ms for sending Average RSSI of the Wi-Fi Link. WLAN_LOAD_THRESH: High and Low Thresholds for sending Loading of the WLAN system. WLAN_LOAD_PERIOD: Periodicity in ms for sending Loading of the WLAN system. UL_TPUT_THRESH: High and Low Thresholds for sending Reverse Link Throughput on the Wi-Fi link. UL_TPUT_PERIOD: Periodicity in ms for sending Reverse Link Throughput on the Wi-Fi link. DL_TPUT_THRESH: High and Low Thresholds for sending Forward Link Throughput on the Wi-Fi link. DL_TPUT_PERIOD: Periodicity in ms for sending Forward Link Throughput on the Wi-Fi link. EST_UL_TPUT_THRESH: High and Low Thresholds for sending Reverse Link Throughput (EstimatedThroughputOutbound as defined in ) on the Wi-Fi link. EST_UL_TPUT_PERIOD: Periodicity in ms for sending Reverse Link Throughput (EstimatedThroughputOutbound as defined in ) on the Wi-Fi link. EST_DL_TPUT_THRESH: High and Low Thresholds for sending Forward Link Throughput (EstimatedThroughputInbound as defined in ) on the Wi-Fi link. EST_DL_TPUT_PERIOD: Periodicity in ms for sending Forward Link Throughput (EstimatedThroughputInbound as defined in ) on the Wi-Fi link. If Connection Type is LTE LTE_RSRP_THRESH: High and Low Thresholds for sending RSRP of Serving LTE link. LTE_RSRP_PERIOD: Periodicity in ms for sending RSRP of Serving LTE link. LTE_RSRQ_THRESH: High and Low Thresholds for sending RSRQ of the serving LTE link. LTE_RSRQ_PERIOD: Periodicity in ms for sending RSRP of Serving LTE link. UL_TPUT_THRESH: High and Low Thresholds for sending Reverse Link Throughput on the serving LTE link. UL_TPUT_PERIOD: Periodicity in ms for sending Reverse Link Throughput on the serving LTE link. DL_TPUT_THRESH: High and Low Thresholds for sending Forward Link Throughput on the serving LTE link. DL_TPUT_PERIOD: Periodicity in ms for sending Forward Link Throughput on the serving LTE link. The MX MEAS REPORT message contains the following parameters Unique Session Identifier: Session identifier provided to the client in MX Capability RSP. For each Delivery Connection, include the following: Delivery Connection ID Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: LTE) Delivery Node Identity (ECGI in case of LTE and WiFi AP Id or MAC address in case of WiFi) If Connection Type is Wi-Fi WLAN_RSSI: Average RSSI of the Wi-Fi Link. WLAN_LOAD: Loading of the WLAN system. UL_TPUT: Reverse Link Throughput on the Wi-Fi link. DL_TPUT: Forward Link Throughput on the Wi-Fi link. EST_UL_TPUT: Estimated Reverse Link Throughput on the Wi-Fi link (EstimatedThroughputOutbound as defined in ). EST_DL_TPUT: Estimated Forward Link Throughput on the Wi-Fi link (EstimatedThroughputInbound as defined in ). If Connection Type is LTE LTE_RSRP: RSRP of Serving LTE link. LTE_RSRQ: RSRQ of the serving LTE link. UL_TPUT: Reverse Link Throughput on the serving LTE link. DL_TPUT: Forward Link Throughput on the serving LTE link.

| | | | | |<---MX Session Terminate Ack-------| | +---------------+ | Remove Resources | +---------------+ | | ]]>

| | | | +-----------+-----------+ | | Remove Resources | | +-----------+-----------+ | | | ]]> At any point in MAMS functioning if CCM or NCM is unable to support the MAMS functions anymore, then either of them can initiate a termination procedure by sending MX Session Terminate to the peer, the peer shall acknowledge the termination by sending MX Session Terminate ACK message. After the session is disconnected the CCM shall start a new procedure with MX Discover Message. MX Session Terminate message shall contain Unique Session Identifier and reason for termination in Request. Possible reasons for termination can be: Normal Release No Response from Peer Internal Error

If NCM determines that N-MADP is to be instantiated with MPTCP as the MX Convergence Protocol, it exchanges the MPTCP capability support in discovery and capability exchange procedures. NCM then exchanges the credentials of the N-MADP instance, setup as MPTCP Proxy, along with related parameters to the CCM. CCM configures C-MADP with these parameters to connect with the N-MADP, MPTCP proxy (e.g. , ) instance, on the available network path (Access). Figure 8 shows the call flow describing MAMS control procedures applied to configure user plane and dynamic optimal path selection in a scenario with MPTCP Proxy as the convergence protocol in the user plane.

| | 3. MX SYSTEM INFO (Serving NCM IP/Port Address) | | <-------------+-------------+-------------+-------------+ | | | | | | | |4. MX CAPABILITY REQ(Supported Anchor/Delivery Links ( Wi-Fi, LTE ) | +-----------------------------------------------------+-> | |5. MX CAPABILITY RSP(Convergence/Adaptation Parameters)| | <-----------------------------------------+-------------+ | | 6. MX CAPABILITY ACK(ACCEPT) | | | +-------------+-------------+---------------------------> | | | | | | | |7. MX MEAS CONFIG (WLAN/LTE Measurement Thresholds/Period) | <-------------------------------------------------------+ | |8. MX MEAS REPORT ( LTE RSRP, UL/DL TPUT ) | | +-----------------------------------------+-------------> | |9. MAMS SSID IND(List of SSIDs) | | | <-------------+-------------+---------------------------+ | | | | | | | |10. MX RECONFIGURATION REQ (LTE IP) | | | +-------------------------------------------------------> | |11. MX RECONFONFIGURATION RSP | | | <-----------------------------------------+-------------+ | |12. MX UP SETUP REQ (MPTCP Proxy IP/Port, Aggregation) | | <---------------------------+-------------+-------------+ | |13. MX UP SETUP RSP | | | | +-------------+-------------+-------------+-------------> + | | 14. MPTCP Connection with designated MPTCP Proxy over LTE | +-------------+-------------+-------------+-------------> | | | | | | + + + + + + ]]> Following are the salient steps described in the call flow. The client connects to the LTE network and obtains an IP address (assume LTE is the first connection), and initiates the NCM discovery procedures and exchange capabilities, including the support for MPTCP as the convergence protocol at both the network and the client. The CCM informs the LTE connection parameters to the NCM. NCM provides the parameters like MPTCP Proxy IP address/Port for configuring the convergence layer. This is useful if N-MADP is reachable via different IP address or/and port, from different access networks. The current MPTCP signaling can't identify or differentiate the MPTCP proxy IP address and port among multiple access networks. Since LTE is the only connection, the user plane traffic flows over the single TCP subflow over the LTE connection. Optionally, NCM can provide assistance to the device on the neighboring/preferred Wi-Fi networks that it can associate with.

| |16. MX RECONFONFIGURATION RSP | | | <-----------------------------------------+-------------+ | |17. MX UP SETUP REQ (MPTCP Proxy IP/Port, Aggregation) | | <---------------------------+-------------+-------------+ | |18. MX UP SETUP RSP | | | | +-------------+-------------+-------------+-------------> | | | 19. IPsec Tunnel Establishment over WLAN path | | <-----------------------------------------|-------------> | 20. MX MEAS REPORT (WLAN RSSI, LTE RSRP. UL/DL TPUT) |+-------------+ +-------------+-------------+-------------+------------->+Wait for | | | | | |+good reports | | | | | |+-------------+ | 21. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) | +------------+ <-----------------------------------------+-------------+ |Allow Use of| | 22. MX TRAFFIC STEERING RSP (...) | | |Wi-Fi link | +-------------+-------------+---------------------------> +-----------++ | | | | | | | Add TCP subflow to the MPTCP connection over the WiFi link | |<----------------------------------------------------->| +-----------------------------------------------------------------------+ || Aggregated Wi-Fi and LTE capacity for UL and DL || +-----------------------------------------------------------------------+ | | | | ]]> Figure 9 describes the steps, when the client establishes a Wi-Fi connection. CCM informs the NCM of the Wi-Fi connection along with parameters like the Wi-Fi IP address, SSID. NCM determines that the Wi-Fi connection needs to be secured configures the Adaptation Layer to be IPsec and provides the required parameters to the CCM. In addition, NCM provides the information to configure the convergence layer, (e.g. MPTCP Proxy IP Address), and provides the Traffic Steering Request to indicate that client should use only the LTE access. NCM may do this, for example, on determination from the measurements that the Wi-Fi link is not consistently good enough. As the Wi-Fi link conditions improve, NCM sends a Traffic Steering Request to use Wi-Fi access as well. This triggers the client to establish the TCP subflow over the Wi-Fi link with the MPTCP proxy

|| Reports of bad| | | | | |+ Wi-Fi UL tput| | + + + ++---------------+ | 24. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) | +-------------+ |<-----------------------------------------+------------+ |Disallow use| | 25. MX TRAFFIC STEERING RSP (...) | | |of Wi-Fi UL | |-------------+-------------+-------------------------->| +----------+--+ | | | | | | ++-------------+-------------+-------------+-------------+------------+-+ | UL data to use TCP subflow over LTE link only, | | Aggregated Wi-Fi+LTE capacity for DL | ++-------------+-------------+-------------+-------------+-------------++ | | | | | | + + + + + + ]]> Figure 10 describes the steps, when the client reports that Wi-Fi link conditions degrade in UL. MAMS control plane is used to continuously monitor the access link conditions on Wi-Fi and LTE connections. The NCM may at some point determine increase in UL traffic on Wi-Fi, and trigger the client to only LTE in the UL via Traffic Steering Request to improve UL performance.

|| Reports of bad+ | | | | || Wi+Fi UL/DL tput | + + + +----------------+ | 24. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) | +-------------+ +<----------------------------------------+-------------+ |Disallow use| | 25. MX TRAFFIC STEERING RSP (...) | | |of Wi+Fi | +-----------------------------------------+------------>+ +-------------+ | |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 11 describes the steps, when the client reports that Wi-Fi link conditions degrade in both UL and DL. As the Wi-Fi link conditions deteriorate further, the NCM may determine to send Traffic Steering Request guiding the client to stop using Wi-Fi, and to use only LTE access in both UL and DL. This condition may be maintained until NCM determines, based on reported measurements that Wi-Fi link has become usable.

Figure Y shows the call flow describing MAMS control procedures applied for dynamic optimal path selection in a scenario convergence and Adaptation layer protocols are not ommitted. This scenario indicates the applicability of a MAMS Control Plane only solution. In the capability exchange messages, NCM and CCM negotiate that Convergence and Adaptation layer protocols are not needed (or supported). CCM informs the NCM of the availability of the LTE and Wi-Fi links. NCM determines the access links, Wi-Fi or LTE to be used dynamically based on the reported link quality measurements.

| | | 3. MX SYSTEM INFO (Serving NCM IP/Port Address) | | <-------------+-------------+-------------+-------------+ | | + + + + | |4. MX CAPABILITY REQ(Supported Anchor/Delivery Links ( Wi-Fi, LTE ) | +------------------------------------------------------>| | |5. MX CAPABILITY RSP(No Convergence/Adpatation parameters) | |<-----------------------------------------+------------+ | | 6. MX CAPABILITY ACK(ACCEPT) | | | +-------------+-------------+-------------------------->| | | + + + + | |7. MX MEAS CONFIG (WLAN/LTE Measurement Thresholds/Period) | |<------------------------------------------------------| | |8. MX MEAS REPORT ( LTE RSRP, UL/DL TPUT ) | | |-----------------------------------------+------------>| | |9. MAMS SSID IND(List of SSIDs) | | | |<------------------------------------------------------| | +-----------------------------------------------------------------------++ | 10. Wi|Fi connection setup and IP Address allocation | +-+-------------+-------------+-------------+-------------+-------------++ | + + | | | |10. MX RECONFIGURATION REQ (LTE IP, Wi-Fi IP) | | +-----------------------------------------+------------>| | |11. MX RECONFONFIGURATION RSP | | | <------------------------------------------------------+| | +-----------------------------------------------------------------------++ | Initial Condition, Data over LTE link only, WLAN link is poor | +---------------------------------------------------------+-------------++ |12. MX MEAS REPORT (WLAN RSSI, LTE RSRP, UL/DL TPUT) |+-------------+ |------------------------------------------------------>||Wi-Fi Link | | | | | ||conditions | | | | | ||reported good| | | | | |+-------------+ | | | | | | |13. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) |+--------------+ |<-------------+-------------+-------------+------------||Steer traffic | |14. MX TRAFFIC STEERING RSP (...) | ||to use Wi-Fi | |<-------------+-------------+-------------+------------||link | | | | | |+--------------+ +-----------------------------------------------------------------------++ | Use Wi-Fi link for Data | +---------------------------------------------------------+-------------++ | | | | | | + + + + + + ]]>

MAMS u-plane protocols support multiple combinations and instances of user plane protocols to be used in the MX Adaptation and the Convergence layer. For example, one instance of the MX Convergence Layer can be MPTCP Proxy and another instance can be Trailer based. The MX Adaptation for each can be either UDP tunnel or IPsec. IPSec may be set up when network pathneeds to be secured, e.g. to protect the TCP subflow traversing the network path between the client and MPTCP proxy. Each of the instances of MAMS user plane, i.e. combination of MX Convergence and MX Adaptation layer protocols, can coexist simultaneously and independently handle different traffic types.

For deployment scenarios, where the client is configured (e.g. by the network operator) to use a specific network for exchanging control plane messages and assume the network path to be secure, MAMS control messages will rely on security provided by the underlying transport network. For deployment scenarios where the security of the network path cannot be assumed, NCM and CCM implementations MUST support the "https" URI scheme [RFC2818] and Transport Layer Security (TLS) [RFC5246] to secure control plane message exchange between the NCM and CCM. For deployment scenarios where client authentication is desired, HTTP Digest Authentication MUST be supported. TLS Client Authentication is the preferred mechanism if it is available.

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

The editors gratefully acknowledge the following additional contributors in alphabetical order: A Krishna Pramod/Nokia, Hannu Flinck/Nokia, Hema Pentakota/Nokia, Nurit Sprecher/Nokia

&rfc4301; &rfc2119; &rfc3948; &rfc6347; &rfc7296; &rfc6824; Mobile Edge Computing (MEC) Radio Network Information API 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.

If the connection between CCM and NCM over which the MAMS control plane messages are transported is assumed to be secure, UDP is used as the transport for management & control messages between NCM and UCM (see Figure 9).