[要約] RFC 8743は、複数のアクセス管理サービスに関する標準化されたプロトコルを提案しています。その目的は、異なるアクセス管理サービス間の相互運用性を向上させ、セキュリティとアクセス制御の効率を向上させることです。
Independent Submission S. Kanugovi
Request for Comments: 8743 Nokia Bell Labs
Category: Informational F. Baboescu
ISSN: 2070-1721 Broadcom
J. Zhu
Intel
S. Seo
Korea Telecom
March 2020
Multi-Access Management Services (MAMS)
マルチアクセス管理サービス（MAMS）
Abstract
概要
In multiconnectivity scenarios, the clients can simultaneously connect to multiple networks based on different access technologies and network architectures like Wi-Fi, LTE, and DSL. Both the quality of experience of the users and the overall network utilization and efficiency may be improved through the smart selection and combination of access and core network paths that can dynamically adapt to changing network conditions.
マルチコネクティビティシナリオでは、クライアントは、Wi-Fi、LTE、DSLなどの異なるアクセステクノロジーとネットワークアーキテクチャに基づいて、複数のネットワークに同時に接続できます。変化するネットワーク条件に動的に適応できるアクセスとコアネットワークパスのスマートな選択と組み合わせにより、ユーザーのエクスペリエンスの質とネットワーク全体の使用率と効率の両方が向上する可能性があります。
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.
このドキュメントでは、統一された問題ステートメントを提示し、マルチコネクティビティを管理するためのソリューションを紹介します。このソリューションは、IETFや3GPPを含む複数の標準化団体での経験に基づいて作成者によって開発されました。ただし、このドキュメントはInternet Standards Trackの仕様ではなく、IETFのコンセンサス意見を表すものではありません。
This document describes requirements, solution principles, and the architecture of the Multi-Access Management Services (MAMS) framework. The MAMS framework aims to provide best performance while being easy to implement in a wide variety of multiconnectivity deployments. It specifies the protocol for (1) flexibly selecting the best combination of access and core network paths for the uplink and downlink, and (2) determining the user-plane treatment (e.g., tunneling, encryption) and traffic distribution over the selected links, to ensure network efficiency and the best possible application performance.
このドキュメントでは、要件、ソリューションの原則、およびマルチアクセス管理サービス（MAMS）フレームワークのアーキテクチャについて説明します。 MAMSフレームワークは、多種多様なマルチコネクティビティ配置での実装が容易でありながら、最高のパフォーマンスを提供することを目的としています。これは、（1）アップリンクとダウンリンクのアクセスとコアネットワークパスの最適な組み合わせを柔軟に選択し、（2）ユーザープレーンの処理（たとえば、トンネリング、暗号化）と選択したリンク上のトラフィック分散を決定するためのプロトコルを指定します。ネットワーク効率と可能な限り最高のアプリケーションパフォーマンスを保証するため。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8743.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8743で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction
2. Terminology
3. Problem Statement
4. Requirements
4.1. Access-Technology-Agnostic Interworking
4.2. Support for Common Transport Deployments
4.3. Independent Access Path Selection for Uplink and Downlink
4.4. Core Selection Independent of Uplink and Downlink Access
4.5. Adaptive Access Network Path Selection
4.6. Multipath Support and Aggregation of Access Link Capacities
4.7. Scalable Mechanism Based on User-Plane Interworking
4.8. Separate Control-Plane and User-Plane Functions
4.9. Lossless Path (Connection) Switching
4.10. Concatenation and Fragmentation for Adaptation to MTU
Differences
4.11. Configuring Network Middleboxes Based on Negotiated
Protocols
4.12. Policy-Based Optimal Path Selection
4.13. Access-Technology-Agnostic Control Signaling
4.14. Service Discovery and Reachability
5. Solution Principles
6. MAMS Reference Architecture
7. MAMS Protocol Architecture
7.1. MAMS Control-Plane Protocol
7.2. MAMS User-Plane Protocol
8. MAMS Control-Plane Procedures
8.1. Overview
8.2. Common Fields in MAMS Control Messages
8.3. Common Procedures for MAMS Control Messages
8.3.1. Message Timeout
8.3.2. Keep-Alive Procedure
8.4. Discovery and Capability Exchange
8.5. User-Plane Configuration
8.6. MAMS Path Quality Estimation
8.6.1. MX Control PDU Definition
8.6.2. Keep-Alive Message
8.6.3. Probe-REQ/ACK Message
8.7. MAMS Traffic Steering
8.8. MAMS Application MADP Association
8.9. MAMS Network ID Indication
8.10. MAMS Client Measurement Configuration and Reporting
8.11. MAMS Session Termination Procedure
8.12. MAMS Network Analytics Request Procedure
9. Generic MAMS Signaling Flow
10. Relationship to IETF Technologies
11. Applying MAMS Control Procedures with MPTCP Proxy as User Plane
12. Applying MAMS Control Procedures for Network-Assisted Traffic
Steering When There Is No Convergence Layer
13. Coexistence of MX Adaptation and MX Convergence Layers
14. Security Considerations
14.1. MAMS Control-Plane Security
14.2. MAMS User-Plane Security
15. Implementation Considerations
16. Applicability to Multi-Access Edge Computing
17. Related Work in Other Industry and Standards Forums
18. IANA Considerations
19. References
19.1. Normative References
19.2. Informative References
Appendix A. MAMS Control-Plane Optimization over Secure
Connections
Appendix B. MAMS Application Interface
B.1. Overall Design
B.2. Notation
B.3. Error Indication
B.4. CCM APIs
B.4.1. GET Capabilities
B.4.2. Posting Application Requirements
B.4.3. Getting Predictive Link Parameters
Appendix C. MAMS Control-Plane Messages Described Using JSON
C.1. Protocol Specification: General Processing
C.1.1. Notation
C.1.2. Discovery Procedure
C.1.3. System Information Procedure
C.1.4. Capability Exchange Procedure
C.1.5. User-Plane Configuration Procedure
C.1.6. Reconfiguration Procedure
C.1.7. Path Estimation Procedure
C.1.8. Traffic-Steering Procedure
C.1.9. MAMS Application MADP Association
C.1.10. MX SSID Indication
C.1.11. Measurements
C.1.12. Keep-Alive
C.1.13. Session Termination Procedure
C.1.14. Network Analytics
C.2. Protocol Specification: Data Types
C.2.1. MXBase
C.2.2. Unique Session ID
C.2.3. NCM Connections
C.2.4. Connection Information
C.2.5. Features and Their Activation Status
C.2.6. Anchor Connections
C.2.7. Delivery Connections
C.2.8. Method Support
C.2.9. Convergence Methods
C.2.10. Adaptation Methods
C.2.11. Setup of Anchor Connections
C.2.12. Init Probe Results
C.2.13. Active Probe Results
C.2.14. Downlink Delivery
C.2.15. Uplink Delivery
C.2.16. Traffic Flow Template
C.2.17. Measurement Report Configuration
C.2.18. Measurement Report
C.3. Schemas in JSON
C.3.1. MX Base Schema
C.3.2. MX Definitions
C.3.3. MX Discover
C.3.4. MX System Info
C.3.5. MX Capability Request
C.3.6. MX Capability Response
C.3.7. MX Capability Acknowledge
C.3.8. MX Reconfiguration Request
C.3.9. MX Reconfiguration Response
C.3.10. MX UP Setup Configuration Request
C.3.11. MX UP Setup Confirmation
C.3.12. MX Traffic Steering Request
C.3.13. MX Traffic Steering Response
C.3.14. MX Application MADP Association Request
C.3.15. MX Application MADP Association Response
C.3.16. MX Path Estimation Request
C.3.17. MX Path Estimation Results
C.3.18. MX SSID Indication
C.3.19. MX Measurement Configuration
C.3.20. MX Measurement Report
C.3.21. MX Keep-Alive Request
C.3.22. MX Keep-Alive Response
C.3.23. MX Session Termination Request
C.3.24. MX Session Termination Response
C.3.25. MX Network Analytics Request
C.3.26. MX Network Analytics Response
C.4. Examples in JSON
C.4.1. MX Discover
C.4.2. MX System Info
C.4.3. MX Capability Request
C.4.4. MX Capability Response
C.4.5. MX Capability Acknowledge
C.4.6. MX Reconfiguration Request
C.4.7. MX Reconfiguration Response
C.4.8. MX UP Setup Configuration Request
C.4.9. MX UP Setup Confirmation
C.4.10. MX Traffic Steering Request
C.4.11. MX Traffic Steering Response
C.4.12. MX Application MADP Association Request
C.4.13. MX Application MADP Association Response
C.4.14. MX Path Estimation Request
C.4.15. MX Path Estimation Results
C.4.16. MX SSID Indication
C.4.17. MX Measurement Configuration
C.4.18. MX Measurement Report
C.4.19. MX Keep-Alive Request
C.4.20. MX Keep-Alive Response
C.4.21. MX Session Termination Request
C.4.22. MX Session Termination Response
C.4.23. MX Network Analytics Request
C.4.24. MX Network Analytics Response
Appendix D. Definition of APIs Provided by the CCM to the
Applications at the Client
Appendix E. Implementation Example Using Python for MAMS Client
and Server
E.1. Client-Side Implementation
E.2. Server-Side Implementation
Acknowledgments
Contributors
Authors' Addresses
Multi-Access Management Services (MAMS) is a programmable framework that provides mechanisms for the flexible selection of network paths in a multi-access (MX) communication environment, based on the application's needs. The MAMS framework leverages network intelligence and policies to dynamically adapt traffic distribution across selected paths and user-plane treatments (e.g., encryption needed for transport over Wi-Fi, or tunneling needed to overcome a NAT between client and multipath proxy) to changing network/link conditions. The network path selection and configuration messages are carried as user-plane data between the functional elements in the network and the client, and thus without any impact on the control-plane signaling schemes of the underlying access networks. For example, in a multi-access network with LTE and Wi-Fi technologies, existing LTE and Wi-Fi signaling procedures will be used to set up the LTE and Wi-Fi connections, respectively, and MAMS-specific control-plane messages are carried as LTE or Wi-Fi user-plane data. The MAMS framework defined in this document provides the capability to make a smart selection of a flexible combination of access paths and core network paths, as well as to choose the user-plane treatment when the traffic is distributed across the selected paths. Thus, it is a broad programmable framework that provides functions beyond the simple sharing of network policies such as those provided by the Access Network Discovery and Selection Function (ANDSF) [ANDSF], which offers policies and rules for assisting 3GPP clients to discover and select available access networks. Further, it allows the choice and configuration of user-plane treatment for the traffic over the paths, depending on the application's needs.
マルチアクセス管理サービス（MAMS）は、アプリケーションのニーズに基づいて、マルチアクセス（MX）通信環境でネットワークパスを柔軟に選択するためのメカニズムを提供するプログラム可能なフレームワークです。 MAMSフレームワークは、ネットワークインテリジェンスとポリシーを利用して、選択したパス全体のトラフィック分散とユーザープレーンの処理（Wi-Fi経由のトランスポートに必要な暗号化、またはクライアントとマルチパスプロキシ間のNATを克服するために必要なトンネリングなど）を変化するネットワークに動的に適応させます。リンク条件。ネットワークパスの選択と構成のメッセージは、ネットワークの機能要素とクライアントの間でユーザープレーンデータとして伝送されるため、基盤となるアクセスネットワークのコントロールプレーンシグナリングスキームに影響を与えることはありません。たとえば、LTEおよびWi-Fiテクノロジーを使用するマルチアクセスネットワークでは、既存のLTEおよびWi-Fiシグナリング手順を使用して、LTEおよびWi-Fi接続をそれぞれセットアップします。MAMS固有のコントロールプレーンメッセージは、 LTEまたはWi-Fiユーザープレーンデータとして伝送されます。このドキュメントで定義されているMAMSフレームワークは、アクセスパスとコアネットワークパスの柔軟な組み合わせを賢く選択し、トラフィックが選択されたパスに分散されている場合にユーザープレーンの処理を選択する機能を提供します。したがって、これは、3GPPクライアントが検出および選択するのを支援するためのポリシーとルールを提供する、Access Network Discovery and Selection Function（ANDSF）[ANDSF]によって提供されるものなど、ネットワークポリシーの単純な共有を超える機能を提供する幅広いプログラム可能なフレームワークです。利用可能なアクセスネットワーク。さらに、アプリケーションのニーズに応じて、パス上のトラフィックのユーザープレーン処理を選択および構成できます。
The MAMS framework mechanisms are not dependent on any specific access network types or user-plane protocols (e.g., TCP, UDP, Generic Routing Encapsulation (GRE) [RFC2784] [RFC2890], Multipath TCP (MPTCP) [RFC6824]). The MAMS framework coexists and complements the existing protocols by providing a way to negotiate and configure those protocols to match their use to a given multi-access scenario based on client and network capabilities, and the specific needs of each access network path. Further, the MAMS framework allows load balancing of the traffic flows across the selected access network paths, and the exchange of network state information to be used for network intelligence to optimize the performance of such protocols.
MAMSフレームワークメカニズムは、特定のアクセスネットワークタイプやユーザープレーンプロトコル（TCP、UDP、Generic Routing Encapsulation（GRE）[RFC2784] [RFC2890]、マルチパスTCP（MPTCP）[RFC6824]など）に依存していません。 MAMSフレームワークは、既存のプロトコルを共存および補完し、クライアントとネットワークの機能、および各アクセスネットワークパスの特定のニーズに基づいて、それらのプロトコルをネゴシエートおよび構成して特定のマルチアクセスシナリオに一致させる方法を提供します。さらに、MAMSフレームワークにより、選択したアクセスネットワークパス全体のトラフィックフローのロードバランシング、およびネットワークインテリジェンスがそのようなプロトコルのパフォーマンスを最適化するために使用するネットワーク状態情報の交換が可能になります。
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.
このドキュメントでは、MAMSフレームワークを実現するための要件、ソリューションの原則、機能アーキテクチャ、およびプロトコルについて説明します。 MAMSフレームワークの重要な目標は、MAMS機能要素が複数のパスにわたってIPオーバーレイを形成するという事実を超えて、参加リンクの実際のアクセステクノロジーへの依存を最小限にするか、または（より良い）依存しないことを保証することです。これにより、既存のアクセスおよびコアネットワークの独立したテクノロジーの進化と、新しいアクセステクノロジーのシームレスな統合を可能にすることで、このスキームを「将来を見据えた」ものにすることができます。
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.
このドキュメントで説明されているソリューションは、IETFや3GPPを含む複数の標準化団体での経験に基づいて作成者によって開発されました。ただし、このドキュメントはInternet Standards Trackの仕様ではなく、IETFのコンセンサス意見を表すものではありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Client: An end-user device that supports connections with multiple access nodes, possibly over different access technologies. Also called a user device or user equipment (UE).
クライアント：異なるアクセステクノロジーを介して、複数のアクセスノードとの接続をサポートするエンドユーザーデバイス。ユーザーデバイスまたはユーザー機器（UE）とも呼ばれます。
Multiconnectivity Client: A client with multiple network connections.
マルチコネクティビティクライアント：複数のネットワーク接続を持つクライアント。
Access Network: The segment in the network that delivers user data packets to the client via an access link such as a Wi-Fi airlink, an LTE airlink, or DSL.
アクセスネットワーク：Wi-Fiエアリンク、LTEエアリンク、DSLなどのアクセスリンクを介してユーザーデータパケットをクライアントに配信するネットワーク内のセグメント。
Core: The functional element that anchors the client IP address used for communication with applications via the network.
コア：ネットワークを介したアプリケーションとの通信に使用されるクライアントIPアドレスを固定する機能要素。
Network Connection Manager (NCM): A functional entity in the network that handles MAMS control messages from the client and configures the distribution of data packets over the available access and core network paths, and manages the user-plane treatment (e.g., tunneling, encryption) of the traffic flows.
ネットワーク接続マネージャー（NCM）：クライアントからのMAMS制御メッセージを処理し、利用可能なアクセスおよびコアネットワークパスを介したデータパケットの配信を構成し、ユーザープレーンの処理（トンネリング、暗号化など）を管理するネットワーク内の機能エンティティ）のトラフィックフロー。
Client Connection Manager (CCM): A functional entity in the client that exchanges MAMS signaling messages with the NCM, and which configures the network paths at the client for the transport of user data.
クライアント接続マネージャー（CCM）：NCMとMAMSシグナリングメッセージを交換し、ユーザーデータの転送用にクライアントでネットワークパスを構成するクライアントの機能エンティティ。
Network Multi-Access Data Proxy (N-MADP): A functional entity in the network that handles the forwarding of user data traffic across multiple network paths. The N-MADP is responsible for MAMS-related user-plane functionalities in the network.
ネットワークマルチアクセスデータプロキシ（N-MADP）：複数のネットワークパス間でのユーザーデータトラフィックの転送を処理するネットワーク内の機能エンティティ。 N-MADPは、ネットワーク内のMAMS関連のユーザープレーン機能を担当します。
Client Multi-Access Data Proxy (C-MADP): A functional entity in the client that handles the forwarding of user data traffic across multiple network paths. The C-MADP is responsible for MAMS-related user-plane functionalities in the client.
クライアントマルチアクセスデータプロキシ（C-MADP）：複数のネットワークパスにわたるユーザーデータトラフィックの転送を処理するクライアントの機能エンティティ。 C-MADPは、クライアントのMAMS関連のユーザープレーン機能を担当します。
Anchor Connection: Refers to the network path from the N-MADP to the user-plane gateway (IP anchor) that has assigned an IP address to the client.
アンカー接続：N-MADPから、クライアントにIPアドレスを割り当てたユーザープレーンゲートウェイ（IPアンカー）へのネットワークパスを指します。
Delivery Connection: Refers to the network path from the N-MADP to the client.
配信接続：N-MADPからクライアントへのネットワークパスを指します。
Uplink (also referred to as "UL" in this document): Refers to the direction of a connection from a client toward the network.
アップリンク（このドキュメントでは「UL」とも呼ばれます）：クライアントからネットワークへの接続の方向を指します。
Downlink (also referred to as "DL" in this document): Refers to the direction of a connection from the network toward a client.
ダウンリンク（このドキュメントでは「DL」とも呼ばれます）：ネットワークからクライアントへの接続の方向を指します。
Typically, a client has access to multiple communication networks based on different technologies for accessing application services, for example, LTE, Wi-Fi, DSL, or MulteFire. Different technologies exhibit benefits and limitations in different scenarios. For example, Wi-Fi provides high throughput for end users when their Wi-Fi coverage is good, but the throughput degrades significantly as a given user moves closer to the edge of its Wi-Fi coverage area (typically in the range of a few tens of meters) or if the user population is large (due to a contention-based Wi-Fi access scheme). In LTE networks, the capacity is often constrained by the limited availability of licensed spectrum. However, the quality of the service is predictable even in multi-user scenarios, due to controlled scheduling and licensed-spectrum usage.
通常、クライアントは、LTE、Wi-Fi、DSL、MulteFireなどのアプリケーションサービスにアクセスするためのさまざまなテクノロジーに基づく複数の通信ネットワークにアクセスできます。さまざまな技術は、さまざまなシナリオで利点と制限を示します。たとえば、Wi-Fiカバレッジが良好な場合、Wi-Fiはエンドユーザーに高いスループットを提供しますが、特定のユーザーがWi-Fiカバレッジエリアの端に近づくと、スループットは大幅に低下します（通常、数十メートル）、またはユーザー数が多い場合（コンテンションベースのWi-Fiアクセス方式のため）。 LTEネットワークでは、ライセンスされたスペクトルの限られた可用性によって容量が制限されることがよくあります。ただし、スケジューリングの制御とライセンススペクトルの使用により、マルチユーザーシナリオでもサービスの品質を予測できます。
Additionally, the use of a particular access network path is often coupled with the use of its associated core network and the services that are offered by that network. For example, in an enterprise that has deployed both Wi-Fi and LTE networks, the enterprise services, such as printers and corporate audio/video conferencing, are accessible only via Wi-Fi access connected to the enterprise-hosted (Wi-Fi) core, whereas the LTE access can be used to get operator services, including access to the public Internet.
さらに、特定のアクセスネットワークパスの使用は、多くの場合、関連するコアネットワークおよびそのネットワークによって提供されるサービスの使用と結合されます。たとえば、Wi-FiネットワークとLTEネットワークの両方を展開している企業では、プリンターや企業の音声/ビデオ会議などの企業サービスは、企業がホストする（Wi-Fi）に接続されたWi-Fiアクセスを介してのみアクセスできます。一方、LTEアクセスは、公衆インターネットへのアクセスを含むオペレーターサービスを取得するために使用できます。
Thus, application performance in different scenarios becomes dependent on the choice of access networks (e.g., Wi-Fi, LTE) and the network and transport protocols used (e.g., VPN, MPTCP, GRE). Therefore, to achieve the best possible application performance in a wide range of scenarios, a framework is needed that allows the selection and flexible combination of access and core network paths as well as the protocols used for uplink and downlink data delivery.
したがって、さまざまなシナリオでのアプリケーションのパフォーマンスは、アクセスネットワーク（Wi-Fi、LTEなど）の選択、および使用されるネットワークとトランスポートプロトコル（VPN、MPTCP、GREなど）に依存します。したがって、幅広いシナリオで可能な限り最高のアプリケーションパフォーマンスを実現するには、アクセスとコアネットワークパス、およびアップリンクとダウンリンクのデータ配信に使用されるプロトコルの選択と柔軟な組み合わせを可能にするフレームワークが必要です。
For example, in uncongested scenarios and when the user's Wi-Fi coverage is good, to ensure best performance for enterprise applications at all times, it would be beneficial to use Wi-Fi access for both the uplink and downlink for connecting to enterprise applications. However, in congested scenarios or when the user is getting close to the edge of its Wi-Fi coverage area, the use of Wi-Fi in the uplink by multiple users can lead to degraded capacity and increased delays due to contention. In this case, it would be beneficial to at least use the LTE access for increased uplink coverage, while Wi-Fi may still continue to be used for the downlink.
たとえば、混雑していないシナリオで、ユーザーのWi-Fiカバレッジが良好な場合に、エンタープライズアプリケーションのパフォーマンスを常に最高にするには、アップリンクとダウンリンクの両方にWi-Fiアクセスを使用して、エンタープライズアプリケーションに接続することが有益です。ただし、混雑したシナリオや、ユーザーがWi-Fiカバレッジエリアの端に近づいている場合、アップリンクで複数のユーザーがWi-Fiを使用すると、容量の低下と競合による遅延の増加につながる可能性があります。この場合、Wi-Fiがダウンリンクに引き続き使用される可能性がある一方で、アップリンクカバレッジを拡大するために少なくともLTEアクセスを使用することは有益です。
The requirements set out in this section define the behavior of the MAMS mechanism and the related functional elements.
このセクションで説明する要件は、MAMSメカニズムおよび関連する機能要素の動作を定義します。
The access nodes MAY use different technology types (LTE, Wi-Fi, etc.). The framework, however, MUST be agnostic about the type of underlying technology used by the access network.
アクセスノードは、異なるテクノロジータイプ（LTE、Wi-Fiなど）を使用する場合があります。ただし、フレームワークは、アクセスネットワークで使用される基礎となるテクノロジーのタイプにとらわれない必要があります。
The network path selection and user data distribution MUST work transparently across various transport deployments that include end-to-end IPsec, VPNs, and middleboxes like NATs and proxies.
ネットワークパスの選択とユーザーデータの配布は、エンドツーエンドのIPsec、VPN、NATやプロキシなどのミドルボックスを含むさまざまなトランスポート展開にわたって透過的に機能する必要があります。
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.
クライアントは、1つ以上のアクセスネットワークを使用して、アップリンクで送信し、ダウンリンクで受信できる必要があります（SHOULD）。アップリンクとダウンリンクのアクセスパスの選択は、独立して行われる必要があります。
A client SHOULD flexibly select the core independently of the access paths used to reach the core, depending on the application's needs, local policies, and the result of MAMS control-plane negotiation.
クライアントは、アプリケーションのニーズ、ローカルポリシー、およびMAMSコントロールプレーンネゴシエーションの結果に応じて、コアに到達するために使用されるアクセスパスとは無関係にコアを柔軟に選択する必要があります（SHOULD）。
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.
フレームワークは、各ネットワークパスの品質（アクセスリンクの遅延や容量など）を決定する機能を備えている必要があります。ネットワークパスの品質に関するこの情報は、ユーザーデータの転送に使用するネットワークパスの組み合わせを選択するためのロジックで考慮する必要があります。パス選択アルゴリズムは、ネットワークポリシーのような他の考慮事項に加えて、ネットワークパス品質に関する情報を使用して、ネットワーク使用を最適化し、ユーザーに提供されるエクスペリエンスの品質（QoE）を向上させることができます。
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-steering and aggregation protocols based on capabilities supported by the client and the network user-plane entities. The multiconnection aggregation solution MUST support existing transport and network-layer protocols like TCP, UDP, and GRE. The framework MUST allow the use and configuration of existing aggregation protocols such as MPTCP and SCTP [RFC4960].
フレームワークは、IP層の複数のネットワークパスにわたるユーザーデータの分散と集約をサポートする必要があります。クライアントは、複数のネットワークパスを介したユーザーデータの同時転送を可能にすることにより、複数のネットワーク接続の結合容量を活用できる必要があります（SHOULD）。必要に応じて、受信側でパケットの並べ替えを行う必要があります。フレームワークは、クライアントとネットワークユーザープレーンエンティティによってサポートされる機能に基づいて、フローステアリングと集約プロトコルを柔軟に選択できるようにする必要があります。マルチ接続集約ソリューションは、TCP、UDP、GREなどの既存のトランスポートおよびネットワーク層プロトコルをサポートする必要があります。フレームワークは、MPTCPやSCTP [RFC4960]などの既存の集約プロトコルの使用と構成を許可する必要があります。
The framework MUST leverage commonly available transport, routing, and tunneling capabilities to provide user-plane interworking functionality. The addition of functional elements in the user-plane path between the client and the network MUST NOT impact the access-technology-specific procedures. This makes the solution easy to deploy and scale when different networks are added and removed.
フレームワークは、ユーザープレーンインターワーキング機能を提供するために、一般的に利用可能なトランスポート、ルーティング、およびトンネリング機能を活用する必要があります。クライアントとネットワーク間のユーザープレーンパスに機能要素を追加しても、アクセス技術固有の手順に影響があってはなりません。これにより、さまざまなネットワークが追加および削除されたときに、ソリューションの展開と拡張が容易になります。
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. The control plane MUST configure the actual user-plane data distribution function per this negotiation. A common control protocol SHOULD allow the creation of multiple user-plane function instances with potentially different user-plane (e.g., tunneling) protocol types. This enables maintaining a clear separation between the control-plane and user-plane functions, allowing the framework to be scalable and extensible, e.g., using architectures and implementations based on Software-Defined Networking (SDN).
クライアントは、コントロールプレーンプロトコルを使用して、ネットワークと以下をネゴシエートする必要があります。（1）アップリンクとダウンリンクの両方のアクセスとコアネットワークパスの選択、および（2）ユーザープレーンプロトコルの扱い。コントロールプレーンは、このネゴシエーションごとに実際のユーザープレーンデータ分散機能を構成する必要があります。共通の制御プロトコルは、潜在的に異なるユーザープレーン（トンネリングなど）のプロトコルタイプを持つ複数のユーザープレーン関数インスタンスの作成を許可する必要があります（SHOULD）。これにより、コントロールプレーンとユーザープレーンの機能を明確に分離し、たとえば、ソフトウェア定義ネットワーク（SDN）に基づくアーキテクチャと実装を使用して、フレームワークをスケーラブルかつ拡張可能にすることができます。
When switching data traffic from one path (connection) to another, packets may be lost or delivered out of order; this will have negative impact on the performance of higher-layer protocols, e.g., TCP. The framework SHOULD provide the necessary mechanisms to ensure in-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.
データトラフィックを1つのパス（接続）から別のパスに切り替えると、パケットが失われたり、順不同で配信されたりすることがあります。これは、TCPなどの上位層プロトコルのパフォーマンスに悪影響を及ぼします。フレームワークは、パスの切り替え中など、受信側での順序どおりの配信を保証するために必要なメカニズムを提供する必要があります（SHOULD）。フレームワークは、ネットワークモビリティ機能へのアクセスが引き起こす可能性がある損失を超えて、パケット損失を引き起こしてはなりません。
Different network paths may have different security and middlebox (e.g., NAT) configurations. These configurations will lead to the use of different tunneling protocols for the transport of data between the network user-plane function and the client. As a result, different effective payload sizes per network path are possible (e.g., due to variable encapsulation header overheads). Hence, the MAMS framework SHOULD support the fragmentation of a single payload across MTU-sized IP packets to avoid IP packet fragmentation when aggregating packets from different paths. Further, the concatenation of multiple IP packets into a single IP packet to improve efficiency in packing the MTU size SHOULD also be supported.
ネットワークパスが異なると、セキュリティとミドルボックス（NATなど）の構成が異なる場合があります。これらの構成では、ネットワークユーザープレーン機能とクライアント間のデータの転送に異なるトンネリングプロトコルが使用されます。その結果、ネットワークパスごとに異なる有効ペイロードサイズが可能です（たとえば、可変のカプセル化ヘッダーのオーバーヘッドが原因です）。したがって、MAMSフレームワークは、MTUサイズのIPパケット全体で単一のペイロードの断片化をサポートして、異なるパスからのパケットを集約する際のIPパケットの断片化を回避する必要があります（SHOULD）。さらに、複数のIPパケットを単一のIPパケットに連結して、MTUサイズのパッキングの効率を向上させることもサポートする必要があります（SHOULD）。
The framework SHOULD enable the identification of optimal settings, like radio link dormancy timers, binding expiry times, and supported MTUs, based on parameters negotiated between the client and the network, that may be used to configure middleboxes for efficient operation of user-plane protocols, e.g., configuring a NAT with a longer binding expiry time when UDP versus TCP is used.
フレームワークは、クライアントとネットワークの間でネゴシエートされたパラメーターに基づいて、無線リンクの休止タイマー、バインディングの有効期限、サポートされているMTUなどの最適な設定を識別できるようにする必要があります（SHOULD）。ユーザープレーンプロトコルの効率的な運用のためにミドルボックスを構成するために使用できます。たとえば、UDPとTCPを使用する場合は、バインディングの有効期限が長いNATを構成します。
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.
フレームワークは、クライアントでのポリシーの実装と、さまざまなアプリケーション要件に対処するネットワークパス選択のためのネットワークからのガイダンスの両方をサポートする必要があります。
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. The MAMS framework SHOULD support the delivery of control-plane signaling over existing Internet protocols, e.g., TCP or UDP.
コントロールプレーンシグナリングは、基盤となるアクセステクノロジー手順に依存してはなりません。つまり、アプリケーションプレーンのように、ユーザープレーンで透過的に伝送されます。 MAMSフレームワークは、既存のインターネットプロトコル（TCPやUDPなど）を介したコントロールプレーンシグナリングの配信をサポートする必要があります（SHOULD）。
There can be multiple instances of the control-plane and user-plane functional elements of the framework, either collocated or hosted on separate network elements and reachable via any of the available user-plane paths. The client MUST have the flexibility to choose the appropriate control-plane instance in the network and use the control-plane signaling to choose the desired user-plane functional element instances. The client's choice can be based on considerations such as, but not limited to, the quality of the link through which the network function is reachable, client preferences, preconfiguration, etc.
フレームワークのコントロールプレーンとユーザープレーンの機能要素の複数のインスタンスが存在する可能性があり、個別のネットワーク要素上に配置またはホストされ、利用可能なユーザープレーンパスのいずれかを介して到達可能です。クライアントは、ネットワーク内の適切なコントロールプレーンインスタンスを選択し、コントロールプレーンシグナリングを使用して目的のユーザープレーン機能要素インスタンスを選択する柔軟性を持つ必要があります。クライアントの選択は、ネットワーク機能に到達できるリンクの品質、クライアントの設定、事前設定などの考慮事項に基づくことができますが、これらに限定されません。
This document describes the Multi-Access Management Services (MAMS) framework for dynamic selection of a flexible combination of access and core network paths for the uplink and downlink, as well as the user-plane treatment for the traffic spread across the selected links. The user-plane paths, and access and core network connections, can be selected independently for the uplink and downlink. For example, the network paths chosen for the uplink do not apply any constraints on the choice of paths for the downlink. The uplink and downlink network paths can be chosen based on the application needs and on the characteristics and available resources on different network connections. For example, a Wi-Fi connection can be chosen for the downlink for transporting high-bandwidth data from the network to the client, whereas an LTE connection can be chosen to carry the low-bandwidth feedback to the application server.
このドキュメントでは、アップリンクとダウンリンクのアクセスとコアネットワークパスの柔軟な組み合わせを動的に選択するためのマルチアクセス管理サービス（MAMS）フレームワークと、選択したリンクに広がるトラフィックのユーザープレーン処理について説明します。ユーザープレーンパス、アクセスおよびコアネットワーク接続は、アップリンクとダウンリンクで個別に選択できます。たとえば、アップリンク用に選択されたネットワークパスは、ダウンリンク用のパスの選択に制約を適用しません。アップリンクとダウンリンクのネットワークパスは、アプリケーションのニーズと、さまざまなネットワーク接続の特性と利用可能なリソースに基づいて選択できます。たとえば、ネットワークからクライアントに高帯域幅のデータを転送するためのダウンリンクにはWi-Fi接続を選択でき、アプリケーションサーバーに低帯域幅のフィードバックを運ぶためにLTE接続を選択できます。
Also, depending on the characteristics of the access network link, different processing would be needed on the user-plane packets on different network paths. Encryption would be needed on a Wi-Fi link to secure user-plane packets, but not on an LTE link. Tunneling would be needed to ensure client and network end-point reachability over NATs. Such differentiated user-plane treatment can be accomplished by configuration of user plane-protocols (e.g., IPsec) specific to each link.
また、アクセスネットワークリンクの特性に応じて、異なるネットワークパス上のユーザープレーンパケットで異なる処理が必要になります。 Wi-Fiリンクではユーザープレーンパケットを保護するために暗号化が必要ですが、LTEリンクでは必要ありません。 NATを介したクライアントとネットワークのエンドポイントの到達可能性を確保するには、トンネリングが必要です。このような差別化されたユーザープレーンの処理は、各リンクに固有のユーザープレーンプロトコル（IPsecなど）を構成することで実現できます。
The MAMS framework consists of clearly separated control- and user-plane functions in the network and the client. The control-plane protocol allows the configuration of the user-plane protocols and desired network paths for the transport of application traffic. The control-plane messages are carried as user-plane data over any of the available network paths between the peer control-plane functional elements in the client and the network. Multiple user-plane paths are dynamically distributed across multiple access networks and aggregated in the network (by the N-MADP). The access network's diversity is not exposed to the application servers, but is kept within the scope of the elements defined in this framework. This reduces the burden placed on application servers that would otherwise have to react to access link changes caused by mobility events or changing link characteristics.
MAMSフレームワークは、ネットワークとクライアントで明確に分離されたコントロールプレーンとユーザープレーンの機能で構成されます。コントロールプレーンプロトコルを使用すると、ユーザープレーンプロトコルと、アプリケーショントラフィックの転送に必要なネットワークパスを構成できます。コントロールプレーンメッセージは、クライアントとネットワークのピアコントロールプレーン機能要素間の利用可能なネットワークパスを介して、ユーザープレーンデータとして伝送されます。複数のユーザープレーンパスが複数のアクセスネットワークに動的に分散され、ネットワークに集約されます（N-MADPによって）。アクセスネットワークの多様性はアプリケーションサーバーに公開されませんが、このフレームワークで定義された要素の範囲内に保持されます。これにより、モビリティイベントやリンク特性の変更によって発生したアクセスリンクの変更に対応する必要のあるアプリケーションサーバーの負担が軽減されます。
The selection of paths and user-plane treatment of the traffic is based on (1) the negotiation of client and network capabilities, and (2) link probing (i.e., checking the quality of links between the user-plane functional elements at the client and the network). This framework enables leveraging network intelligence to set up and dynamically configure the best access network path combination based on client and network capabilities, an application's needs, and knowledge of the network state.
トラフィックのパスとユーザープレーン処理の選択は、（1）クライアントとネットワーク機能のネゴシエーション、および（2）リンクプローブ（つまり、クライアントのユーザープレーン機能要素間のリンクの品質のチェック）に基づいています。とネットワーク）。このフレームワークにより、ネットワークインテリジェンスを活用して、クライアントとネットワークの機能、アプリケーションのニーズ、およびネットワークの状態に関する知識に基づいて、最適なアクセスネットワークパスの組み合わせをセットアップし、動的に構成できます。
Figure 1 illustrates the MAMS architecture for the scenario where a client is served by multiple (n) networks. It also introduces the following functional elements:
図1は、クライアントが複数の（n）ネットワークからサービスを受けるシナリオのMAMSアーキテクチャを示しています。また、次の機能要素も紹介します。
* The NCM and the CCM in the control plane.
* コントロールプレーンのNCMおよびCCM。
* The N-MADP and the C-MADP in the user plane.
* ユーザープレーンのN-MADPおよびC-MADP。
+--------------------------------------------------------+
| +----------------+ +----------------+ |
| | | | | |
| |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 1: MAMS Reference Architecture
図1：MAMSリファレンスアーキテクチャ
The NCM is the functional element in the network that handles the MAMS control-plane procedures. It configures the network (N-MADP) and client (C-MADP) user-plane functions, such as negotiating with the client for the use of available access network paths, protocols, and rules for processing the user-plane traffic, as well as link-monitoring procedures. The control-plane messages between the NCM and the CCM are transported as an overlay on the user plane, without any impact on the underlying access networks.
NCMは、MAMSコントロールプレーン手順を処理するネットワークの機能要素です。ネットワーク（N-MADP）およびクライアント（C-MADP）のユーザープレーン機能を構成します。たとえば、利用可能なアクセスネットワークパス、プロトコル、ユーザープレーントラフィックを処理するためのルールを使用するためのクライアントとのネゴシエーションなどです。リンク監視手順として。 NCMとCCM間のコントロールプレーンメッセージは、基盤となるアクセスネットワークに影響を与えることなく、ユーザープレーン上のオーバーレイとして転送されます。
The CCM is the peer functional element in the client for handling MAMS control-plane procedures. It manages multiple network connections at the client. The CCM exchanges MAMS signaling messages with the NCM to support such functions as the configuration of the UL and DL user network path for transporting user data packets and the adaptive selection of network path by the NCM by reporting on the results of link probing. In the downlink, for user data received by the client, it configures the C-MADP such that application data packets can be received over any access link so that the packets will reach the appropriate application on the client. In the uplink, for the data transmitted by the client, it configures the C-MADP to determine the best access links to be used for uplink data based on a combination of local and network policies delivered by the NCM.
CCMは、MAMSコントロールプレーンプロシージャを処理するためのクライアントのピア機能要素です。クライアントで複数のネットワーク接続を管理します。 CCMは、MAMSシグナリングメッセージをNCMと交換して、ユーザーデータパケットを転送するためのULおよびDLユーザーネットワークパスの構成や、リンクプローブの結果を報告することによるNCMによるネットワークパスの適応選択などの機能をサポートします。ダウンリンクでは、クライアントが受信したユーザーデータに対して、アプリケーションデータパケットを任意のアクセスリンク経由で受信できるようにC-MADPを構成し、パケットがクライアント上の適切なアプリケーションに到達するようにします。アップリンクでは、クライアントによって送信されたデータに対して、NCMによって配信されたローカルポリシーとネットワークポリシーの組み合わせに基づいて、アップリンクデータに使用される最適なアクセスリンクを決定するようにC-MADPを構成します。
The N-MADP is the functional element in the network that handles the forwarding of user data traffic across multiple network paths, as well as other user-plane functionalities (e.g., encapsulation, fragmentation, concatenation, reordering, retransmission). The N-MADP is the distribution node that routes (1) the uplink user-plane traffic to the appropriate anchor connection toward the core network, and (2) the downlink user traffic to the client over the appropriate delivery connections. In the downlink, the NCM configures the use of delivery connections and user-plane protocols at the N-MADP for transporting user data traffic. The N-MADP SHOULD implement ECMP support for the downlink traffic. Alternatively, it MAY be connected to a router with ECMP functionality. The load-balancing algorithm at the N-MADP is configured by the NCM, based on static and/or dynamic network policies like assigning access and core paths for a specific user data traffic type, user-volume-based percentage distribution, and link availability and feedback information from the exchange of MAMS signaling messages with the CCM at the client. The N-MADP can be configured with appropriate user-plane protocols to support both per-flow and per-packet traffic distribution across the delivery connections. In the uplink, the N-MADP selects the appropriate anchor connection over which to forward the user data traffic received from the client (via the delivery connections). The forwarding rules in the uplink at the N-MADP are configured by the NCM based on application requirements, e.g., enterprise-hosted application flows via a Wi-Fi anchor or mobile-operator-hosted applications via the cellular core.
N-MADPは、複数のネットワークパスにわたるユーザーデータトラフィックの転送、および他のユーザープレーン機能（カプセル化、断片化、連結、並べ替え、再送信など）を処理するネットワークの機能要素です。 N-MADPは、（1）アップリンクユーザープレーントラフィックを適切なアンカー接続にコアネットワークにルーティングし、（2）ダウンリンクユーザートラフィックを適切な配信接続を介してクライアントにルーティングする配信ノードです。ダウンリンクでは、NCMはユーザーデータトラフィックを転送するために、N-MADPで配信接続とユーザープレーンプロトコルの使用を構成します。 N-MADPは、ダウンリンクトラフィックのECMPサポートを実装する必要があります（SHOULD）。または、ECMP機能を備えたルーターに接続することもできます。 N-MADPでのロードバランシングアルゴリズムは、特定のユーザーデータトラフィックタイプへのアクセスおよびコアパスの割り当て、ユーザーボリュームベースのパーセンテージ分布、リンクの可用性などの静的または動的ネットワークポリシーに基づいて、NCMによって構成されます。クライアントでのCCMとのMAMSシグナリングメッセージの交換からのフィードバック情報。 N-MADPは、適切なユーザープレーンプロトコルを使用して構成でき、配信接続全体のフロー単位とパケット単位の両方のトラフィック分散をサポートします。アップリンクでは、N-MADPは、クライアントから受信したユーザーデータトラフィックを転送する適切なアンカー接続を選択します（配信接続を介して）。 N-MADPでのアップリンクの転送ルールは、アプリケーション要件に基づいてNCMによって構成されます。たとえば、Wi-Fiアンカーを介したエンタープライズホストアプリケーションフローや、セルラーコアを介したモバイルオペレーターホストアプリケーションなどです。
The C-MADP is the functional element in the client that handles the MAMS user-plane data procedures. The C-MADP is configured by the CCM, based on the signaling exchange with the NCM and local policies at the client. The CCM configures the selection of delivery connections and the user-plane protocols to be used for uplink user data traffic based on the signaling messages exchanged with the NCM. The C-MADP entity handles the forwarding of user-plane data across multiple delivery connections and associated user-plane functions (e.g., encapsulation, fragmentation, concatenation, reordering, retransmissions).
C-MADPは、MAMSユーザープレーンデータプロシージャを処理するクライアントの機能要素です。 C-MADPは、クライアントでのNCMおよびローカルポリシーとのシグナリング交換に基づいて、CCMによって設定されます。 CCMは、NCMと交換されるシグナリングメッセージに基づいて、アップリンクユーザーデータトラフィックに使用される配信接続とユーザープレーンプロトコルの選択を構成します。 C-MADPエンティティは、複数の配信接続にわたるユーザープレーンデータの転送と、関連するユーザープレーン機能（カプセル化、断片化、連結、並べ替え、再送信など）を処理します。
The NCM and N-MADP can be either collocated or instantiated on different network nodes. The NCM can set up multiple N-MADP instances in the network. The NCM controls the selection of the N-MADP instance by the client and the rules for the distribution of user traffic across the N-MADP instances. This is beneficial in multiple deployment scenarios, like the following examples:
NCMとN-MADPは、異なるネットワークノードに配置するかインスタンス化することができます。 NCMは、ネットワーク内に複数のN-MADPインスタンスをセットアップできます。 NCMは、クライアントによるN-MADPインスタンスの選択と、N-MADPインスタンス間でのユーザートラフィックの分散ルールを制御します。これは、次の例のような複数の展開シナリオで役立ちます。
* Different N-MADP instances to handle different sets of clients for load balancing across clients.
* 異なるN-MADPインスタンスは、異なるクライアントのセットを処理して、クライアント間で負荷を分散します。
* Network topologies where the N-MADP is hosted at the user-plane node at the access edge or in the core network, while the NCM is hosted at the access edge node.
* NCMがアクセスエッジノードでホストされている一方で、N-MADPがアクセスエッジまたはコアネットワークのユーザープレーンノードでホストされているネットワークトポロジ。
* Access network technology architecture with an N-MADP instance at the core network node to manage traffic distribution across LTE and DSL networks, and an N-MADP instance at an access network node to manage traffic distribution across LTE and Wi-Fi networks.
* コアネットワークノードにN-MADPインスタンスを使用してLTEおよびDSLネットワーク全体のトラフィック分散を管理し、アクセスネットワークノードにN-MADPインスタンスを使用してLTEおよびWi-Fiネットワーク全体のトラフィック分散を管理するアクセスネットワークテクノロジーアーキテクチャ。
* A single client can be configured to use multiple N-MADP instances. This is beneficial in addressing different application requirements. For example, separate N-MADP instances to handle traffic that is based on TCP and UDP transport.
* 単一のクライアントは、複数のN-MADPインスタンスを使用するように構成できます。これは、さまざまなアプリケーション要件に対処するのに役立ちます。たとえば、TCPおよびUDPトランスポートに基づくトラフィックを処理するためのN-MADPインスタンスを分離します。
Thus, the MAMS architecture flexibly addresses multiple network deployments.
したがって、MAMSアーキテクチャは複数のネットワーク展開に柔軟に対応します。
This section describes the protocol structure for the MAMS user-plane and control-plane functional elements.
このセクションでは、MAMSユーザープレーンとコントロールプレーンの機能要素のプロトコル構造について説明します。
Figure 2 shows the default MAMS control-plane protocol stack. WebSocket [RFC6455] is used for transporting management and control messages between the NCM and the CCM.
図2は、デフォルトのMAMSコントロールプレーンプロトコルスタックを示しています。 WebSocket [RFC6455]は、NCMとCCMの間で管理および制御メッセージを転送するために使用されます。
+------------------------------------------+
| |
| Multi-Access (MX) Control Message |
| |
+------------------------------------------+
| |
| WebSocket |
| |
+------------------------------------------+
| |
| TCP/TLS |
| |
+------------------------------------------+
Figure 2: TCP-Based MAMS Control-Plane Protocol Stack
図2：TCPベースのMAMSコントロールプレーンプロトコルスタック
Figure 3 shows the MAMS user-plane protocol stack for transporting the user payload, e.g., an IP Protocol Data Unit (PDU).
図3は、IPプロトコルデータユニット（PDU）などのユーザーペイロードを転送するためのMAMSユーザープレーンプロトコルスタックを示しています。
+-----------------------------------------------------+
| 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 3: MAMS User-Plane Protocol Stack
図3：MAMSユーザープレーンプロトコルスタック
The MAMS user-plane protocol consists of the following two layers:
MAMSユーザープレーンプロトコルは、次の2つの層で構成されています。
* Multi-Access (MX) Convergence Layer: The MAMS framework configures the Convergence Layer to perform multi-access-specific tasks in the user plane. This layer performs such functions as access (path) selection, multi-link (path) aggregation, splitting/ reordering, lossless switching, fragmentation, or concatenation. The MX Convergence Layer can be implemented by using existing user-plane protocols like MPTCP [RFC6824] or Multipath QUIC (MPQUIC) [QUIC-MULTIPATH], or by adapting encapsulating header/ trailer schemes such as GRE [RFC2784] [RFC2890] or Generic Multi-Access (GMA) [INTAREA-GMA].
* マルチアクセス（MX）コンバージェンスレイヤー：MAMSフレームワークは、ユーザープレーンでマルチアクセス固有のタスクを実行するようにコンバージェンスレイヤーを構成します。この層は、アクセス（パス）選択、マルチリンク（パス）集約、分割/並べ替え、ロスレススイッチング、フラグメンテーション、または連結などの機能を実行します。 MXコンバージェンスレイヤーは、MPTCP [RFC6824]またはマルチパスQUIC（MPQUIC）[QUIC-MULTIPATH]などの既存のユーザープレーンプロトコルを使用するか、GRE [RFC2784] [RFC2890]またはGenericなどのカプセル化ヘッダー/トレーラースキームを採用することで実装できます。マルチアクセス（GMA）[INTAREA-GMA]。
* Multi-Access (MX) Adaptation Layer: The MAMS framework configures the Adaptation Layer to address transport-network-related aspects such as reachability and security in the user plane. This layer performs functions to handle tunneling, network-layer security, and NAT. The MX Adaptation Layer can be implemented using IPsec, DTLS [RFC6347], or a Client NAT (Source NAT at the client with inverse mapping at the N-MADP [INTAREA-MAMS]). 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 [INTAREA-MAMS].
* マルチアクセス（MX）アダプテーションレイヤー：MAMSフレームワークは、ユーザープレーンの到達可能性やセキュリティなどのトランスポートネットワーク関連の側面に対処するようにアダプテーションレイヤーを構成します。この層は、トンネリング、ネットワーク層セキュリティ、およびNATを処理する機能を実行します。 MXアダプテーションレイヤーは、IPsec、DTLS [RFC6347]、またはクライアントNAT（N-MADP [INTAREA-MAMS]で逆マッピングを行うクライアントのソースNAT）を使用して実装できます。 MXアダプテーションレイヤーはオプションであり、アクセスリンクごとに個別に構成できます。たとえば、LTE（安全であると想定）とWi-Fi（安全でないと想定）を使用した展開では、LTEリンクのMXアダプテーションレイヤーを省略できますが、Wi-Fiリンクを保護するようにIPsecで構成されています。 MAMSユーザープレーンの詳細については、[INTAREA-MAMS]を参照してください。
The CCM and NCM exchange signaling messages to configure the user-plane functions via the C-MADP and the N-MADP at the client and the network, respectively. The means for the CCM to obtain the NCM credentials (Fully Qualified Domain Name (FQDN) or IP address) for sending the initial discovery messages are out of scope for this document. As an example, the client can obtain the NCM credentials by using such methods as provisioning or DNS queries. Once the discovery process is successful, the (initial) NCM can update and assign additional NCM addresses, e.g., based on Mobile Country Code (MCC) / Mobile Network Code (MNC) tuple information received in the MX Discover message, for sending subsequent control-plane messages.
CCMとNCMはシグナリングメッセージを交換して、クライアントとネットワークでそれぞれC-MADPとN-MADPを介してユーザープレーン機能を設定します。 CCMが初期検出メッセージを送信するためのNCM資格情報（完全修飾ドメイン名（FQDN）またはIPアドレス）を取得する手段は、このドキュメントの範囲外です。例として、クライアントはプロビジョニングやDNSクエリなどの方法を使用してNCM資格情報を取得できます。検出プロセスが成功すると、（最初の）NCMは追加のNCMアドレスを更新して割り当てることができます。たとえば、MX Discoverメッセージで受信したモバイル国コード（MCC）/モバイルネットワークコード（MNC）タプル情報に基づいて、後続の制御を送信します。 -planeメッセージ。
The CCM discovers and exchanges capabilities with the NCM. The NCM provides the credentials of the N-MADP endpoint and negotiates the parameters for the user plane with the CCM. The CCM configures the C-MADP to set up the user-plane path (e.g., MPTCP/UDP Proxy connection) with the N-MADP, based on the credentials (e.g., (MPTCP/UDP) Proxy IP address and port, associated core network path), and the parameters exchanged with the NCM. Further, the NCM and CCM exchange link status information to adapt traffic steering and user-plane treatment to dynamic network conditions. The key procedures are described in detail in the following subsections.
CCMは、NCMと機能を検出して交換します。 NCMは、N-MADPエンドポイントの資格情報を提供し、ユーザープレーンのパラメーターをCCMとネゴシエートします。 CCMは、資格情報（例：（MPTCP / UDP）プロキシIPアドレスとポート、関連するコア）に基づいて、N-MADPとのユーザープレーンパス（例：MPTCP / UDPプロキシ接続）をセットアップするようにC-MADPを構成します。ネットワークパス）、およびNCMと交換されるパラメータ。さらに、NCMとCCMはリンクステータス情報を交換して、トラフィックステアリングとユーザープレーンの処理を動的なネットワーク条件に適合させます。主要な手順については、次のサブセクションで詳しく説明します。
+-----+ +-----+
| 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"
「RNIS」は「無線ネットワーク情報サービス」の略です
Figure 4: MAMS Control-Plane Procedures
図4：MAMSコントロールプレーンプロシージャ
Each MAMS control message consists of the following common fields:
各MAMS制御メッセージは、次の共通フィールドで構成されています。
* Version: Indicates the version of the MAMS control protocol.
* バージョン：MAMS制御プロトコルのバージョンを示します。
* Message Type: Indicates the type of the message, e.g., MX Discover, MX Capability Request (REQ) / Response (RSP).
* メッセージタイプ：メッセージのタイプを示します（例：MX Discover、MX Capability Request（REQ）/ Response（RSP））。
* Sequence Number: Auto-incremented integer to uniquely identify a particular message exchange, e.g., MX Capability Request/Response.
* シーケンス番号：特定のメッセージ交換を一意に識別するために自動インクリメントされる整数（例：MX機能要求/応答）。
This section describes the common procedures for MAMS control messages.
このセクションでは、MAMS制御メッセージの一般的な手順について説明します。
After sending a MAMS control message, the MAMS control-plane peer (NCM or CCM) waits for a duration of MAMS_TIMEOUT ms before timing out in cases where a response was expected. The sender of the message will retransmit the message for MAMS_RETRY times before declaring failure if no response is received. A failure implies that the MAMS peer is dead or unreachable, and the sender reverts to native non-multi-access / single-path mode. The CCM may initiate the MAMS discovery procedure for re-establishing the MAMS session.
MAMSコントロールメッセージを送信した後、MAMSコントロールプレーンピア（NCMまたはCCM）は、応答が予期された場合にタイムアウトする前に、MAMS_TIMEOUTミリ秒待機します。メッセージの送信者は、応答が受信されない場合、失敗を宣言する前にMAMS_RETRY回メッセージを再送信します。障害は、MAMSピアが停止しているか到達できないことを意味し、送信者はネイティブの非マルチアクセス/シングルパスモードに戻ります。 CCMは、MAMSセッションを再確立するためにMAMS検出手順を開始する場合があります。
MAMS control-plane peers execute the keep-alive procedures to ensure that the other peers are reachable and to recover from dead-peer scenarios. Each MAMS control-plane endpoint maintains a Keep-Alive timer that is set for a duration of MAMS_KEEP_ALIVE_TIMEOUT. The Keep-Alive timer is reset whenever the peer receives a MAMS control message. When the Keep-Alive timer expires, an MX Keep-Alive Request is sent.
MAMSコントロールプレーンピアは、キープアライブ手順を実行して、他のピアが到達可能であることを確認し、デッドピアシナリオから回復します。各MAMSコントロールプレーンエンドポイントは、MAMS_KEEP_ALIVE_TIMEOUTの間設定されるキープアライブタイマーを維持します。キープアライブタイマーは、ピアがMAMS制御メッセージを受信するたびにリセットされます。キープアライブタイマーが期限切れになると、MXキープアライブ要求が送信されます。
The values for MAMS_RETRY and MAMS_KEEP_ALIVE_TIMEOUT parameters used in keep-alive procedures are deployment dependent, and the means for obtaining them are out of scope for this document. As an example, the client and network can obtain the values using provisioning. On receipt of an MX Keep-Alive Request, the receiver responds with an MX Keep-Alive Response. If the sender does not receive a MAMS control message in response to MAMS_RETRY retries of the MX Keep-Alive Request, the MAMS peer declares that the peer is dead or unreachable. The CCM MAY initiate the MAMS discovery procedure for re-establishing the MAMS session.
キープアライブプロシージャで使用されるMAMS_RETRYおよびMAMS_KEEP_ALIVE_TIMEOUTパラメータの値は展開に依存し、それらを取得する方法はこのドキュメントの範囲外です。例として、クライアントとネットワークはプロビジョニングを使用して値を取得できます。 MXキープアライブ要求を受信すると、受信者はMXキープアライブ応答で応答します。 MXキープアライブ要求のMAMS_RETRY再試行に応答して送信者がMAMS制御メッセージを受信しない場合、MAMSピアは、ピアがデッドまたは到達不能であることを宣言します。 CCMは、MAMSセッションを再確立するためのMAMS検出手順を開始する場合があります。
Additionally, the CCM SHALL immediately send an MX Keep-Alive Request to the NCM whenever it detects a handover from one base station / access point to another. During this time, the client SHALL stop using MAMS user-plane functionality in the uplink direction until it receives an MX Keep-Alive Response from the NCM.
さらに、CCMは、ある基地局/アクセスポイントから別の基地局へのハンドオーバーを検出するたびに、MXキープアライブ要求をすぐにNCMに送信する必要があります（SHALL）。この間、クライアントは、NCMからMXキープアライブ応答を受信するまで、アップリンク方向のMAMSユーザープレーン機能の使用を停止する必要があります（SHALL）。
The MX Keep-Alive Request includes the following information:
MXキープアライブ要求には、次の情報が含まれています。
* Reason: Can be timeout or handover. Handover shall be used by the CCM only on detection of a handover.
* 理由：タイムアウトまたはハンドオーバーの可能性があります。ハンドオーバーは、ハンドオーバーの検出時にのみCCMによって使用されます。
* Unique Session ID: See Section 8.4.
* 一意のセッションID：セクション8.4を参照してください。
* Connection ID: If the reason is handover, the inclusion of this field is mandatory.
* 接続ID：理由がハンドオーバーの場合、このフィールドの入力は必須です。
* Delivery Node ID: Identity of the node to which the client is attached. In the case of LTE, this is an E-UTRAN Cell Global Identifier (ECGI). In the case of Wi-Fi, this is an AP ID or a Media Access Control (MAC) address. If the reason is "Handover", the inclusion of this field is mandatory.
* 配信ノードID：クライアントが接続されているノードのID。 LTEの場合、これはE-UTRAN Cell Global Identifier（ECGI）です。 Wi-Fiの場合、これはAP IDまたはメディアアクセス制御（MAC）アドレスです。理由が「引き渡し」の場合、このフィールドの入力は必須です。
Figure 5 shows the MAMS discovery and capability exchange procedure.
図5は、MAMSの検出と機能交換の手順を示しています。
CCM NCM
| |
|------- MX Discover Message ----------------------->|
| +-----------------+
| | Learn CCM |
| | IP address |
| | and port |
| +-----------------+
| |
|<----------------------------- MX System Info ------|
| |
|------------------------------ MX Capability REQ -->|
|<----- MX Capability RSP ---------------------------|
|------------------------------ MX Capability ACK -->|
| |
+ +
Figure 5: MAMS Control Procedure for Discovery and Capability Exchange
図5：検出と機能交換のためのMAMS制御手順
This procedure consists of the following key steps:
この手順は、次の主要な手順で構成されています。
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.
手順1（検出）：MXシステム情報メッセージが確認で受信されるまで、CCMはMX検出メッセージを定義済み（NCM）IPアドレス/ポートに定期的に送信します。
* The MX Discover message includes the following information:
* MX Discoverメッセージには、次の情報が含まれています。
- MAMS Version.
- MAMSバージョン。
- Mobile Country Code (MCC) / Mobile Network Code (MNC) Tuple: Optional parameter to identify the operator network to which the client is subscribed, in conformance with the format specified in [ITU-E212].
- モバイル国コード（MCC）/モバイルネットワークコード（MNC）タプル：[ITU-E212]で指定された形式に準拠して、クライアントが加入しているオペレーターネットワークを識別するオプションのパラメーター。
* The MX System Info message includes the following information:
* MXシステム情報メッセージには、次の情報が含まれています。
- Number of Anchor Connections.
- アンカー接続の数。
For each anchor connection, the following parameters are included:
アンカー接続ごとに、次のパラメーターが含まれています。
o Connection ID: Unique identifier for the anchor connection.
o 接続ID：アンカー接続の一意の識別子。
o Connection Type (e.g., Wi-Fi, 5G NR, MulteFire, LTE).
o 接続タイプ（Wi-Fi、5G NR、MulteFire、LTEなど）。
o NCM Endpoint Address (for control-plane messages over this connection):
o NCMエンドポイントアドレス（この接続を介したコントロールプレーンメッセージ用）：
+ IP Address or FQDN
+ IPアドレスまたはFQDN
+ Port Number
+ ポート番号
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:
ステップ2（機能交換）：CCMは、MXシステム情報メッセージからIPアドレスとポートを学習します。次に、次のパラメーターを含むMX機能REQメッセージを送信します。
* MX Feature Activation List: Indicates whether the corresponding feature is supported or not, e.g., lossless switching, fragmentation, concatenation, uplink aggregation, downlink aggregation, measurement, probing.
* MX機能アクティベーションリスト：対応する機能がサポートされているかどうかを示します（例：ロスレススイッチング、フラグメンテーション、連結、アップリンク集約、ダウンリンク集約、測定、プローブ）。
* Number of Anchor Connections (core networks).
* アンカー接続（コアネットワーク）の数。
For each anchor connection, the following parameters are included:
アンカー接続ごとに、次のパラメーターが含まれています。
- Connection ID
- 接続ID
- Connection Type (e.g., Wi-Fi, 5G NR, MulteFire, LTE)
- 接続タイプ（Wi-Fi、5G NR、MulteFire、LTEなど）
* Number of Delivery Connections (access links).
* 配信接続（アクセスリンク）の数。
For each delivery connection, the following parameters are included:
各配信接続には、次のパラメータが含まれています。
- Connection ID
- 接続ID
- Connection Type (e.g., Wi-Fi, 5G NR, MulteFire, LTE)
- 接続タイプ（Wi-Fi、5G NR、MulteFire、LTEなど）
* MX Convergence Method Support List:
* MX収束方法サポートリスト：
- GMA
- GMA
- MPTCP Proxy
- MPTCPプロキシ
- GRE Aggregation Proxy
- GRE集約プロキシ
- MPQUIC
- MPQUIC
* MX Adaptation Method Support List:
* MX適応方法サポートリスト：
- UDP without DTLS
- DTLSなしのUDP
- UDP with DTLS
- UDPとDTLS
- IPsec [RFC3948]
- IPsec [RFC3948]
- Client NAT
- NATクライアント
In response, the NCM creates a unique identity for the CCM session and sends the MX Capability Response, including the following information:
それに応じて、NCMはCCMセッションの一意のIDを作成し、次の情報を含むMX機能応答を送信します。
* MX Feature Activation List: Indicates whether the corresponding feature is enabled or not, e.g., lossless switching, fragmentation, concatenation, uplink aggregation, downlink aggregation, measurement, probing.
* MX機能アクティベーションリスト：対応する機能が有効かどうかを示します。たとえば、ロスレススイッチング、フラグメンテーション、連結、アップリンク集約、ダウンリンク集約、測定、プローブなどです。
* Number of Anchor Connections (core networks):
* アンカー接続数（コアネットワーク）：
For each anchor connection, the following parameters are included:
アンカー接続ごとに、次のパラメーターが含まれています。
- Connection ID
- 接続ID
- Connection Type (e.g., Wi-Fi, 5G NR, MulteFire, LTE)
- 接続タイプ（Wi-Fi、5G NR、MulteFire、LTEなど）
* Number of Delivery Connections (access links):
* 配信接続数（アクセスリンク）：
For each delivery connection, the following parameters are included:
各配信接続には、次のパラメータが含まれています。
- Connection ID
- 接続ID
- Connection Type (e.g., Wi-Fi, 5G NR, MulteFire, LTE)
- 接続タイプ（Wi-Fi、5G NR、MulteFire、LTEなど）
* MX Convergence Method Support List:
* MX収束方法サポートリスト：
- GMA
- GMA
- MPTCP Proxy
- MPTCPプロキシ
- GRE Aggregation Proxy
- GRE集約プロキシ
- MPQUIC
- MPQUIC
* MX Adaptation Method Support List:
* MX適応方法サポートリスト：
- UDP without DTLS
- DTLSなしのUDP
- UDP with DTLS
- UDPとDTLS
- IPsec [RFC3948]
- IPsec [RFC3948]
- Client NAT
- NATクライアント
* Unique Session ID: Unique session identifier for the CCM that set up the connection. If the session already exists, then the existing unique session identifier is returned.
* 一意のセッションID：接続を設定したCCMの一意のセッションID。セッションがすでに存在する場合は、既存の一意のセッション識別子が返されます。
- NCM ID: Unique identity of the NCM in the operator network.
- NCM ID：オペレーターネットワークにおけるNCMの一意のID。
- Session ID: Unique identity assigned to the CCM instance by this NCM instance.
- セッションID：このNCMインスタンスによってCCMインスタンスに割り当てられた一意のID。
In response to the MX Capability Response, the CCM sends a confirmation (or rejection) in the MX Capability Acknowledge. The MX Capability Acknowledge includes the following parameters:
MX機能応答に応答して、CCMはMX機能確認で確認（または拒否）を送信します。 MX機能確認には、次のパラメーターが含まれます。
* Unique Session ID: Same identifier as the identifier provided in the MX Capability Response.
* 一意のセッションID：MX機能応答で提供される識別子と同じ識別子。
* Acknowledgment: An indication of whether the client has accepted or rejected the capability exchange phase.
* 確認：クライアントが機能交換フェーズを受け入れたか拒否したかを示します。
- MX ACCEPT: The CCM accepts the capability set proposed by the NCM.
- MX ACCEPT：CCMは、NCMによって提案された機能セットを受け入れます。
- MX REJECT: The CCM rejects the capability set proposed by the NCM.
- MX REJECT：CCMは、NCMによって提案された機能セットを拒否します。
If the NCM receives an MX_REJECT, the current MAMS session will be terminated.
NCMがMX_REJECTを受信した場合、現在のMAMSセッションは終了します。
If the CCM can no longer continue with the current capabilities, it SHOULD send an MX Session Termination Request to terminate the MAMS session. In response, the NCM SHOULD send an MX Session Termination Response to confirm the termination.
CCMが現在の機能を続行できなくなった場合は、MAMSセッションを終了するためにMXセッション終了要求を送信する必要があります（SHOULD）。応答として、NCMはMXセッション終了応答を送信して、終了を確認する必要があります（SHOULD）。
Figure 6 shows the user-plane (UP) configuration procedure.
図6は、ユーザープレーン（UP）の構成手順を示しています。
CCM NCM
| |
|---- MX Reconfiguration REQ (setup) ----------->|
|<-------------------- MX Reconfiguration RSP ---|
| +-------------------------+
| | NCM prepares N-MADP for |
| | User-Plane Setup |
| +-------------------------+
|<-------------------- MX UP Setup Config -------|
|---- MX UP Setup Confirmation ----------------->|
+-------------------+ |
|Link "X" is up/down| |
+-------------------+ |
|---- MX Reconfiguration REQ (update/release) -->|
|<-------------------- MX Reconfiguration RSP ---|
Figure 6: MAMS Control Procedure for User-Plane Configuration
図6：ユーザープレーン構成のMAMS制御手順
This procedure consists of the following two key steps:
この手順は、次の2つの主要なステップで構成されています。
* Reconfiguration: The CCM informs the NCM about the changes to the client's connections - setup of a new connection, teardown of an existing connection, or update of parameters related to an existing connection. It consists of the client triggering the procedure by requesting an update to the connection configuration, and a response from the NCM.
* 再構成：CCMは、クライアントの接続への変更（新しい接続のセットアップ、既存の接続の破棄、または既存の接続に関連するパラメーターの更新）についてNCMに通知します。これは、接続構成の更新を要求することによって手順をトリガーするクライアントと、NCMからの応答で構成されます。
* UP Setup: The NCM configures the user-plane protocols at the client and the network. The NCM initiates the UP setup by sending the MX UP Setup Configuration Request to the client, which confirms the set of mutually acceptable parameters by using the User Plane Setup Confirmation (CNF) message.
* UPセットアップ：NCMは、クライアントとネットワークでユーザープレーンプロトコルを構成します。 NCMはMX UPセットアップ構成要求をクライアントに送信してUPセットアップを開始します。クライアントは、ユーザープレーンセットアップ確認（CNF）メッセージを使用して相互に受け入れ可能なパラメーターのセットを確認します。
These steps are elaborated as follows.
これらの手順は次のように詳しく説明されています。
Reconfiguration: When the client detects that the link is up/down or the IP address changes (e.g., via APIs provided by the client OS), the CCM sends an MX Reconfiguration Request to set up, update, or release the connection. The message SHOULD include the following information:
再構成：クライアントがリンクのアップ/ダウンまたはIPアドレスの変更を（たとえば、クライアントOSによって提供されるAPIを介して）検出すると、CCMはMX再構成要求を送信して、接続をセットアップ、更新、または解放します。メッセージには、次の情報を含める必要があります。
* Unique Session ID: Identity of the CCM at the NCM, created by the NCM during the capability exchange phase.
* 一意のセッションID：機能交換フェーズ中にNCMによって作成された、NCMでのCCMのID。
* Reconfiguration Action: Indicates the reconfiguration action (release, setup, or update).
* 再構成アクション：再構成アクション（リリース、セットアップ、または更新）を示します。
* Connection ID: Identifies the connection for reconfiguration.
* 接続ID：再構成する接続を識別します。
If the Reconfiguration Action is set to "setup" or "update", then the message includes the following parameters:
再構成アクションが「セットアップ」または「更新」に設定されている場合、メッセージには次のパラメーターが含まれます。
* IP address of the connection.
* 接続のIPアドレス。
* SSID (Service Set Identifier of the Wi-Fi connection).
* SSID（Wi-Fi接続のサービスセット識別子）。
* MTU of the connection: The MTU of the delivery path that is calculated at the client for use by the NCM to configure fragmentation and concatenation procedures [INTAREA-MAMS] at the N-MADP.
* 接続のMTU：N-MADPでフラグメンテーションおよび連結手順[INTAREA-MAMS]を構成するためにNCMが使用するためにクライアントで計算される配信パスのMTU。
* Delivery Node ID: Identity of the node to which the client is attached. In the case of LTE, this is an ECGI. In the case of Wi-Fi, this is an AP ID or a MAC address.
* 配信ノードID：クライアントが接続されているノードのID。 LTEの場合、これはECGIです。 Wi-Fiの場合、これはAP IDまたはMACアドレスです。
At the beginning of a connection setup, the CCM informs the NCM of the connection status using the MX Reconfiguration Request with the Reconfiguration Action set to "setup". The NCM acknowledges the connection setup status and exchanges parameters with the CCM for user-plane setup, as described below.
接続セットアップの最初に、CCMは、再構成アクションを「セットアップ」に設定したMX再構成リクエストを使用して、NCMに接続ステータスを通知します。 NCMは、以下で説明するように、接続セットアップステータスを確認し、ユーザープレーンセットアップ用のCCMとパラメーターを交換します。
Setup of User-Plane Protocols: Based on the negotiated capabilities, the NCM sets up the user-plane (Adaptation Layer and Convergence Layer) protocols at the N-MADP and informs the CCM of the user-plane protocols to be set up at the client (C-MADP) and the parameters for the C-MADP to connect to the N-MADP.
ユーザープレーンプロトコルのセットアップ：ネゴシエートされた機能に基づいて、NCMはN-MADPでユーザープレーン（アダプテーションレイヤーおよびコンバージェンスレイヤー）プロトコルをセットアップし、CCMにセットアップされるユーザープレーンプロトコルを通知します。クライアント（C-MADP）およびC-MADPがN-MADPに接続するためのパラメーター。
The MX UP Setup Configuration Request is used to create one or more MADP instances, with each anchor connection having one or more configurations, namely MX Configurations. The MX UP Setup Configuration Request consists of the following parameters:
MX UPセットアップ構成要求は、1つ以上のMADPインスタンスを作成するために使用され、各アンカー接続には1つ以上の構成、つまりMX構成があります。 MX UPセットアップ構成要求は、次のパラメーターで構成されています。
* Number of Anchor Connections (core networks).
* アンカー接続（コアネットワーク）の数。
For each anchor connection, the following parameters are included:
アンカー接続ごとに、次のパラメーターが含まれています。
- Anchor Connection ID
- アンカー接続ID
- Connection Type (e.g., Wi-Fi, 5G NR, MulteFire, LTE)
- 接続タイプ（Wi-Fi、5G NR、MulteFire、LTEなど）
- Number of Active MX Configurations (included only if more than one MX configuration is active for the anchor connection).
- アクティブなMX構成の数（アンカー接続で複数のMX構成がアクティブな場合にのみ含まれます）。
For each active MX configuration, the following parameters are included:
アクティブなMX構成ごとに、次のパラメーターが含まれています。
o MX Configuration ID (included if more than one MX configuration is present)
o MX構成ID（複数のMX構成が存在する場合に含まれます）
o MX Convergence Method. One of the following:
o MX収束方法。次のいずれか：
+ GMA
+ GMA
+ MPTCP Proxy
+ MPTCPプロキシ
+ GRE Aggregation Proxy
+ GRE集約プロキシ
+ MPQUIC
+ MPQUIC
o MX Convergence Method Parameters:
o MX収束方法パラメーター：
+ Convergence Proxy IP Address
+ コンバージェンスプロキシIPアドレス
+ Convergence Proxy Port
+ コンバージェンスプロキシポート
+ Client Key
+ クライアントキー
o MX Convergence Control Parameters (included if any MX Control PDU types (e.g., Probe-REQ/ACK) are supported):
o MXコンバージェンスコントロールパラメータ（MXコントロールPDUタイプ（プローブ-REQ / ACKなど）がサポートされている場合に含まれます）：
+ UDP port number for sending and receiving MX Control PDUs (e.g., Probe-REQ/ACK, Keep-Alive)
+ MXコントロールPDUを送受信するためのUDPポート番号（例：Probe-REQ / ACK、Keep-Alive）
+ Convergence Proxy Port
+ コンバージェンスプロキシポート
o Number of Delivery Connections.
o 配信接続の数。
For each delivery connection, include the following:
配信接続ごとに、以下を含めます。
+ Delivery Connection ID
+ 配信接続ID
+ Connection Type (e.g., Wi-Fi, 5G NR, MulteFire, LTE)
+ 接続タイプ（Wi-Fi、5G NR、MulteFire、LTEなど）
+ MX Adaptation Method. One of the following:
+ MX適応メソッド。次のいずれか：
* UDP without DTLS
* DTLSなしのUDP
* UDP with DTLS
* UDPとDTLS
* IPsec
* IPsec
* Client NAT
* NATクライアント
+ MX Adaptation Method Parameters:
+ MX適応メソッドパラメータ：
* Tunnel Endpoint IP Address
* トンネルエンドポイントIPアドレス
* Tunnel Endpoint Port
* トンネルエンドポイントポート
* Shared Secret
* 共有秘密
* Header Optimization (included only if the MX Convergence Method is GMA)
* ヘッダーの最適化（MX収束方法がGMAの場合にのみ含まれます）
For example, when LTE and Wi-Fi are the two user-plane accesses, the NCM conveys to the CCM that IPsec needs to be set up as the MX Adaptation Layer over the Wi-Fi access, using the following parameters: IPsec endpoint IP address, and Pre-Shared Key. No Adaptation Layer is needed if it is considered secure with no NAT, or a Client NAT may be used over the LTE access.
たとえば、LTEとWi-Fiが2つのユーザープレーンアクセスである場合、NCMは、次のパラメーターを使用して、IPsecがWi-Fiアクセス上のMXアダプテーションレイヤーとして設定される必要があることをCCMに伝えます。IPsecエンドポイントIPアドレス、事前共有キー。 NATを使用せずに安全であると見なされている場合、またはLTEアクセスでクライアントNATを使用できる場合、適応層は必要ありません。
Similarly, as an example of the MX Convergence Method, the configuration indicates the convergence method as the MPTCP proxy, along with parameters for a connection to the MPTCP proxy: namely the IP address and port of the MPTCP proxy for TCP applications.
同様に、MXコンバージェンスメソッドの例として、構成はコンバージェンスメソッドをMPTCPプロキシとして示すとともに、MPTCPプロキシへの接続のパラメーター、つまりTCPアプリケーションのMPTCPプロキシのIPアドレスとポートを示します。
Once the user-plane protocols are configured, the CCM informs the NCM of the status via the MX UP Setup Confirmation. The MX UP Setup Confirmation consists of the following parameters:
ユーザープレーンプロトコルが設定されると、CCMはMX UPセットアップ確認を介してステータスをNCMに通知します。 MX UPセットアップ確認は、次のパラメーターで構成されています。
* Unique Session ID: Session identifier provided to the client in an MX Capability Response.
* 一意のセッションID：MX機能応答でクライアントに提供されるセッション識別子。
* MX Convergence Control Parameters (included if any MX Control PDU types (e.g., Probe-REQ/ACK, Keep-Alive) are supported):
* MXコンバージェンス制御パラメーター（MXコントロールPDUタイプ（プローブ-REQ / ACK、キープアライブなど）がサポートされている場合に含まれます）：
- UDP port number for sending and receiving MX Control PDUs (e.g., Probe-REQ/ACK, Keep-Alive)
- MXコントロールPDUを送受信するためのUDPポート番号（例：Probe-REQ / ACK、Keep-Alive）
- MX Configuration ID (if an MX Configuration ID is specified in an MX UP Setup Configuration Request) to indicate the MX Configuration that will be used for probing)
- MX構成ID（MX構成IDがMX UPセットアップ構成要求で指定されている場合）は、プローブに使用されるMX構成を示します）
* Client Adaptation-Layer Parameters:
* クライアント適応層パラメーター：
- Number of Delivery Connections.
- 配信接続の数。
For each delivery connection, include the following:
配信接続ごとに、以下を含めます。
o Delivery Connection ID
o 配信接続ID
o UDP port number: If UDP-based adaptation is in use, the UDP port on the C-MADP side
o UDPポート番号：UDPベースの適応が使用されている場合、C-MADP側のUDPポート
Path quality estimations can be done either passively or actively. Traffic measurements in the network can be performed passively by comparing the real-time data throughput of the client with the capacity available in the network. In special deployments where the NCM has interfaces with access nodes, direct interfaces can be used to gather information regarding path quality. For example, the utilization of the LTE access node (also known as Evolved Node B), to which the client is attached, could be used as data for the estimation of path quality without creating any extra traffic overhead. Active measurements by the client provide an alternative way to estimate path quality.
パス品質の推定は、受動的または能動的に行うことができます。ネットワークのトラフィック測定は、クライアントのリアルタイムデータスループットをネットワークで利用可能な容量と比較することにより、受動的に実行できます。 NCMがアクセスノードとのインターフェイスを備えている特殊な展開では、直接インターフェイスを使用して、パス品質に関する情報を収集できます。たとえば、クライアントが接続されているLTEアクセスノード（Evolved Node Bとも呼ばれます）の利用率は、余分なトラフィックオーバーヘッドを発生させることなく、パス品質を推定するためのデータとして使用できます。クライアントによるアクティブな測定は、パスの品質を推定する別の方法を提供します。
CCM NCM
| |
|<-------------- MX Path Estimation Request ---------|
|------ MX Path Estimation Results ----------------->|
| |
Figure 7: MAMS Control-Plane Procedure for Path Quality Estimation
図7：パス品質推定のためのMAMSコントロールプレーン手順
The NCM sends the following configuration parameters in the MX Path Estimation Request to the CCM:
NCMは、MXパス推定要求で次の構成パラメーターをCCMに送信します。
* Connection ID (of the delivery connection whose path quality needs to be estimated)
* 接続ID（パス品質を推定する必要がある配信接続の）
* Init Probe Test Duration (ms)
* Initプローブテスト期間（ミリ秒）
* Init Probe Test Rate (Mbps)
* 初期プローブテストレート（Mbps）
* Init Probe Size (bytes)
* 初期プローブサイズ（バイト）
* Init Probe-ACK Required (0 -> No / 1 -> Yes)
* Init Probe-ACKが必要（0->いいえ/ 1->はい）
* Active Probe Frequency (ms)
* アクティブプローブ周波数（ms）
* Active Probe Size (bytes)
* アクティブプローブサイズ（バイト）
* Active Probe Test Duration (ms)
* アクティブプローブテスト期間（ミリ秒）
* Active Probe-ACK Required (0 -> No / 1 -> Yes)
* アクティブプローブACKが必要（0->いいえ/ 1->はい）
The CCM configures the C-MADP for probe receipt based on these parameters and for collection of the statistics according to the following configuration.
CCMは、以下の構成に従って、これらのパラメーターに基づいてプローブを受信し、統計を収集するようにC-MADPを構成します。
* Unique Session ID: Session identifier provided to the client in an MX Capability Response.
* 一意のセッションID：MX機能応答でクライアントに提供されるセッション識別子。
* Init Probe Results Configuration:
* 初期プローブ結果の構成：
- Lost Probes (percent)
- 失われたプローブ（パーセント）
- 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: the Initialization phase and the Active phase.
ユーザープレーンプローブは、初期化フェーズとアクティブフェーズの2つのフェーズに分かれています。
* Initialization Phase: A network path that is not included by the N-MADP for transmission of user data is deemed to be in the Initialization phase. The user data may be transmitted over other available network paths.
* 初期化フェーズ：ユーザーデータの送信用にN-MADPに含まれていないネットワークパスは、初期化フェーズにあると見なされます。ユーザーデータは、他の利用可能なネットワークパスを介して送信される場合があります。
* Active Phase: A network path that is included by the N-MADP for transmission of user data is deemed to be in the Active phase.
* アクティブフェーズ：ユーザーデータの送信用にN-MADPに含まれているネットワークパスは、アクティブフェーズにあると見なされます。
During the Initialization phase, the NCM configures the N-MADP to send an Init Probe-REQ message. The CCM collects the Init Probe statistics from the C-MADP and sends the MX Path Estimation Results message to the NCM per the Initialization Probe Results configuration.
初期化フェーズ中に、NCMはInit Probe-REQメッセージを送信するようにN-MADPを構成します。 CCMはC-MADPからInitプローブ統計を収集し、初期化プローブ結果構成に従ってMXパス推定結果メッセージをNCMに送信します。
During the Active phase, the NCM configures the N-MADP to send an Active Probe-REQ message. The C-MADP calculates the metrics as specified by the Active Probe Results configuration. The CCM collects the Active Probe statistics from the C-MADP and sends the MX Path Estimation Results message to the NCM per the Active Probe Results configuration.
アクティブフェーズ中に、NCMはアクティブプローブREQメッセージを送信するようにN-MADPを設定します。 C-MADPは、アクティブプローブ結果の構成で指定されたメトリックを計算します。 CCMは、C-MADPからアクティブプローブ統計を収集し、アクティブプローブ結果の構成ごとにMXパス推定結果メッセージをNCMに送信します。
The following subsections define the control PDU encoding for Keep-Alive and Probe-REQ/ACK messages to support path quality estimation.
次のサブセクションでは、キープアライブメッセージおよびプローブREQ / ACKメッセージの制御PDUエンコーディングを定義して、パス品質の推定をサポートします。
Control PDUs are sent as UDP messages between the C-MADP and the N-MADP to exchange control messages for keep-alive or path quality estimation. MX probe parameters are negotiated during the user-plane setup phase (MX UP Setup Configuration Request and MX UP Setup Confirmation). Figure 8 shows the MX Control PDU format with the following fields:
コントロールPDUは、C-MADPとN-MADPの間でUDPメッセージとして送信され、キープアライブまたはパス品質の推定のためにコントロールメッセージを交換します。 MXプローブパラメータは、ユーザープレーンのセットアップフェーズ（MX UPセットアップ構成要求およびMX UPセットアップ確認）でネゴシエートされます。図8は、次のフィールドを持つMXコントロールPDUフォーマットを示しています。
* Type (1 byte): The type of the MX Control message.
* タイプ（1バイト）：MXコントロールメッセージのタイプ。
- 0: Keep-Alive
- 0：キープアライブ
- 1: Probe-REQ/ACK
- 1：プローブREQ / ACK
- Others: Reserved
- その他：予約済み
* CID (1 byte): The connection ID of the delivery connection for sending the MX Control message.
* CID（1バイト）：MXコントロールメッセージを送信するための配信接続の接続ID。
* MX Control Message (variable): The payload of the MX Control message.
* MXコントロールメッセージ（変数）：MXコントロールメッセージのペイロード。
The MX Control PDU is sent as a normal user-plane packet over the desired delivery connection whose quality and reachability need to be determined.
MXコントロールPDUは、品質と到達可能性を決定する必要のある、目的の配信接続を介して通常のユーザープレーンパケットとして送信されます。
| |
|<--------- MX Control PDU Payload ------->|
| |
+-----------+-------------------+-----+-----------------------------+
| IP Header | UDP Header | Type | CID | MX Control Message |
+-----------+-------------------+-----+-----------------------------+
Figure 8: MX Control PDU Format
図8：MXコントロールPDUフォーマット
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.
「タイプ」フィールドは、キープアライブメッセージの「0」に設定されます。特にパス上でNAT機能を使用する配信接続の適応方法としてUDPトンネリングが使用されている場合、C-MADPは1つまたは複数の配信接続を介してキープアライブメッセージを定期的に送信します。
A Keep-Alive message is 2 bytes long and consists of the following field:
キープアライブメッセージは2バイト長で、次のフィールドで構成されています。
* Keep-Alive Sequence Number (2 bytes): The sequence number of the Keep-Alive message.
* キープアライブシーケンス番号（2バイト）：キープアライブメッセージのシーケンス番号。
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.
「タイプ」フィールドは、Probe-REQ / ACKメッセージに対して「1」に設定されます。 N-MADPは、パス品質推定のためにProbe-REQメッセージを送信できます。応答として、C-MADPはプローブACKメッセージを返す場合があります。
A Probe-REQ message consists of the following fields:
Probe-REQメッセージは、次のフィールドで構成されています。
* Probing Sequence Number (2 bytes): The sequence number of the Probe REQ message.
* プローブシーケンス番号（2バイト）：プローブREQメッセージのシーケンス番号。
* Probing Flag (1 byte):
* プローブフラグ（1バイト）：
- Bit 0: A Probe-ACK flag to indicate whether the Probe-ACK message is expected (1) or not (0).
- ビット0：プローブACKメッセージが予期される（1）か予期されない（0）かを示すプローブACKフラグ。
- Bit 1: A Probe Type flag to indicate whether the Probe-REQ/ACK message was sent during the Initialization phase (0) when the network path is not included for transmission of user data, or during the Active phase (1) when the network path is included for transmission of user data.
- ビット1：ネットワークパスがユーザーデータの送信用に含まれていない場合の初期化フェーズ（0）またはネットワークの場合のアクティブフェーズ（1）の間にプローブ-REQ / ACKメッセージが送信されたかどうかを示すプローブタイプフラグパスはユーザーデータの送信用に含まれています。
- Bit 2: A bit flag to indicate the presence of the Reverse Connection ID (R-CID) field.
- ビット2：リバース接続ID（R-CID）フィールドの存在を示すビットフラグ。
- Bits 3-7: Reserved.
- ビット3〜7：予約済み。
* Reverse Connection ID (R-CID) (1 byte): The connection ID of the delivery connection for sending the Probe-ACK message on the reverse path.
* リバース接続ID（R-CID）（1バイト）：リバースパスでProbe-ACKメッセージを送信するための配信接続の接続ID。
* Padding (variable).
* パディング（変数）。
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.
「R-CID」フィールドは、「プローブフラグ」フィールドのビット0とビット2の両方が「1」に設定されている場合にのみ存在します。さらに、「Probing Flag」フィールドのビット2は、ビット0が「0」の場合、「0」に設定する必要があります。これは、Probe-ACKメッセージが予期されないことを示します。
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.
「R-CID」フィールドが存在せず、「Probing Flag」フィールドのビット0が「1」に設定されている場合、Probe-ACKメッセージは、Probe-REQメッセージと同じ配信接続を介して送信される必要があります（SHOULD）。
The "Padding" field is used to control the length of the Probe-REQ message.
「パディング」フィールドは、Probe-REQメッセージの長さを制御するために使用されます。
The C-MADP SHOULD send the Probe-ACK message in response to a Probe-REQ message with the Probe-ACK flag set to "1".
C-MADPは、Probe-ACKフラグが「1」に設定されたProbe-REQメッセージに応答して、Probe-ACKメッセージを送信する必要があります（SHOULD）。
A Probe-ACK message is 3 bytes long and consists of the following field:
プローブACKメッセージは3バイト長で、次のフィールドで構成されています。
* Probing Acknowledgment Number (2 bytes): The sequence number of the corresponding Probe-REQ message.
* Probing Acknowledgement Number（2 bytes）：対応するProbe-REQメッセージのシーケンス番号。
CCM NCM
| |
| +------------------------------+
| |Steer user traffic to Path "X"|
| +------------------------------+
|<----------------- MX Traffic Steering REQ ------|
|----- MX Traffic Steering RSP ------------------>|
Figure 9: MAMS Traffic-Steering Procedure
図9：MAMSトラフィックステアリング手順
The NCM sends an MX Traffic Steering Request to steer data traffic. It is also possible to send data traffic over multiple connections simultaneously, i.e., aggregation. The message includes the following information:
NCMはMXトラフィックステアリング要求を送信して、データトラフィックをステアリングします。複数の接続を介してデータトラフィックを同時に送信すること、つまり集約することも可能です。メッセージには次の情報が含まれます。
* Anchor Connection ID: Connection ID of the anchor connection.
* アンカー接続ID：アンカー接続の接続ID。
* MX Configuration ID (if an MX Configuration ID is specified in an MX UP Setup Configuration Request).
* MX構成ID（MX構成IDがMX UPセットアップ構成要求で指定されている場合）。
* DL Connection ID List: List of DL delivery connections, provided as Connection IDs.
* DL接続IDリスト：接続IDとして提供されるDL配信接続のリスト。
* UL Connection ID: Connection ID of the default UL delivery connection.
* UL接続ID：デフォルトのUL配信接続の接続ID。
* For the number of specific UL traffic templates, the message includes the following:
* 特定のULトラフィックテンプレートの数については、メッセージに次のものが含まれます。
- Traffic Flow Template for identifying the UL traffic.
- ULトラフィックを識別するためのトラフィックフローテンプレート。
- UL Connection ID List: List of UL delivery connections, provided as Connection IDs, to be used for sending the UL traffic.
- UL接続IDリスト：ULトラフィックの送信に使用される、接続IDとして提供されるUL配信接続のリスト。
* MX Feature Activation List. Each parameter indicates whether the corresponding feature is enabled or not: lossless switching, fragmentation, concatenation, uplink aggregation, downlink aggregation, measurement, probing.
* MX機能アクティベーションリスト。各パラメータは、対応する機能が有効であるかどうかを示します：ロスレススイッチング、フラグメンテーション、連結、アップリンク集約、ダウンリンク集約、測定、プローブ。
In response, the CCM sends an MX Traffic Steering Response, including the following information:
これに応じて、CCMは次の情報を含むMXトラフィックステアリング応答を送信します。
* Unique Session ID: Session identifier provided to the client in an MX Capability Response.
* Unique Session ID: Session identifier provided to the client in an MX Capability Response.
* MX Feature Activation List. Each parameter indicates whether the corresponding feature is enabled or not: lossless switching, fragmentation, concatenation, uplink aggregation, downlink aggregation, measurement, probing.
* MX機能アクティベーションリスト。各パラメータは、対応する機能が有効であるかどうかを示します：ロスレススイッチング、フラグメンテーション、連結、アップリンク集約、ダウンリンク集約、測定、プローブ。
CCM NCM
| |
| +-------------------------+
| | Associate MADP instance |
| | with application flow |
| +-------------------------+
|---------- MX App MADP ------------------->|
| Association REQ |
| |
|<----------------- MX App MADP ------------|
| Association RSP |
Figure 10: MAMS Application MADP Association Procedure
図10：MAMSアプリケーションMADP関連付け手順
The CCM sends an MX Application MADP Association Request to request the association of a specific application flow with a specific MADP instance ID for the anchor connection with multiple active MX configurations. The MADP Instance ID is a tuple (Anchor Connection ID, MX Configuration ID). This provides the capability for the client to indicate the user-plane processing that needs to be associated with different application flows depending on the needs of those flows. The application flow is identified by its associated Traffic Flow Template.
CCMは、MXアプリケーションMADPアソシエーション要求を送信して、複数のアクティブなMX構成とのアンカー接続のために、特定のアプリケーションフローと特定のMADPインスタンスIDの関連付けを要求します。 MADPインスタンスIDはタプル（アンカー接続ID、MX構成ID）です。これにより、クライアントは、フローのニーズに応じて異なるアプリケーションフローに関連付ける必要のあるユーザープレーン処理を示すことができます。アプリケーションフローは、関連するトラフィックフローテンプレートによって識別されます。
The MX Application MADP Association Request includes the following information:
MXアプリケーションMADPアソシエーション要求には、次の情報が含まれています。
* Number of Application Flows.
* アプリケーションフローの数。
For each application flow, identified by the Traffic Flow Templates:
トラフィックフローテンプレートで識別されるアプリケーションフローごとに、
- Anchor Connection ID
- アンカー接続ID
- MX Configuration ID (if more than one MX configuration is associated with an anchor connection)
- MX構成ID（1つのアンカー接続に複数のMX構成が関連付けられている場合）
- Traffic Flow Template for identifying the UL traffic
- ULトラフィックを識別するためのトラフィックフローテンプレート
- Traffic Flow Template for identifying the DL traffic
- DLトラフィックを識別するためのトラフィックフローテンプレート
In response, the NCM sends an MX Application MADP Association Response, including the following information:
それに応じて、NCMは次の情報を含むMXアプリケーションMADPアソシエーション応答を送信します。
* Number of Application Flows.
* アプリケーションフローの数。
For each application flow, identified by the Traffic Flow Templates:
For each application flow, identified by the Traffic Flow Templates:
- Status (Success or Failure)
- ステータス（成功または失敗）
CCM NCM
| |
| +---------------------------------+
| |NCM determines preferred networks|
| +---------------------------------+
| |
|<----------------- MX SSID Indication -----------|
| |
Figure 11: MAMS Network ID Indication Procedure
図11：MAMSネットワークIDの表示手順
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 [IEEE-80211]), available in the MX SSID Indication.
NCMは、CCMに優先ネットワークリストを示し、接続先のネットワークに関してクライアントをガイドします。優先Wi-Fiネットワークを示すため、NCMは[IEEE-80211 ]）、MX SSIDインジケーションで利用できます。
CCM NCM
| |
|<--------------- MX Measurement Config ----------|
| |
+---------------------------------+ |
|Client ready to send measurements| |
+---------------------------------+ |
| |
|----- MX Measurement Report -------------------->|
| |
Figure 12: MAMS Client Measurement Configuration and Reporting Procedure
Figure 12: MAMS Client Measurement Configuration and Reporting Procedure
The NCM configures the CCM with the different parameters (e.g., radio link information), with the associated thresholds to be reported by the client. The MX Measurement Configuration message contains the following parameters for each delivery connection:
The NCM configures the CCM with the different parameters (e.g., radio link information), with the associated thresholds to be reported by the client. The MX Measurement Configuration message contains the following parameters for each delivery connection:
* Delivery Connection ID.
* 配信接続ID。
* Connection Type (e.g., Wi-Fi, 5G NR, MulteFire, LTE).
* 接続タイプ（Wi-Fi、5G NR、MulteFire、LTEなど）。
* If the connection type is Wi-Fi:
* 接続タイプがWi-Fiの場合：
- High and low thresholds for the sending of average Received Signal Strength Indicator (RSSI) of the Wi-Fi link.
- Wi-Fiリンクの平均受信信号強度インジケーター（RSSI）を送信するための高しきい値と低しきい値。
- Periodicity, in ms, for sending the average RSSI of the Wi-Fi link.
- Periodicity, in ms, for sending the average RSSI of the Wi-Fi link.
- High and low thresholds for sending the loading of the WLAN system.
- WLANシステムの負荷を送信するための高しきい値と低しきい値。
- Periodicity, in ms, for sending the loading of the WLAN system.
- WLANシステムの負荷を送信するための周期（ミリ秒）。
- High and low thresholds for sending the reverse link throughput on the Wi-Fi link.
- High and low thresholds for sending the reverse link throughput on the Wi-Fi link.
- Periodicity, in ms, for sending the reverse link throughput on the Wi-Fi link.
- Wi-Fiリンクでリバースリンクのスループットを送信する周期（ミリ秒）。
- High and low thresholds for sending the forward link throughput on the Wi-Fi link.
- Wi-Fiリンクでフォワードリンクのスループットを送信するための高しきい値と低しきい値。
- Periodicity, in ms, for sending the forward link throughput on the Wi-Fi link.
- Wi-Fiリンクでフォワードリンクスループットを送信するための周期（ミリ秒）。
- High and low thresholds for sending the reverse link throughput (EstimatedThroughputOutbound as defined in [IEEE-80211]) on the Wi-Fi link.
- Wi-Fiリンクでリバースリンクのスループット（[IEEE-80211]で定義されているEstimatedThroughputOutbound）を送信するための高しきい値と低しきい値。
- Periodicity, in ms, for sending the reverse link throughput (EstimatedThroughputOutbound as defined in [IEEE-80211]) on the Wi-Fi link.
- Wi-Fiリンクでリバースリンクのスループット（[IEEE-80211]で定義されているEstimatedThroughputOutbound）を送信するための周期（ミリ秒）。
- High and low thresholds for sending the forward link throughput (EstimatedThroughputInbound, as defined in [IEEE-80211]) on the Wi-Fi link.
- Wi-Fiリンクでフォワードリンクのスループット（[IEEE-80211]で定義されているEstimatedThroughputInbound）を送信するための高しきい値と低しきい値。
- Periodicity, in ms, for sending the forward link throughput (EstimatedThroughputInbound, as defined in [IEEE-80211]) on the Wi-Fi link.
- Wi-Fiリンクでフォワードリンクスループット（[IEEE-80211]で定義されているEstimatedThroughputInbound）を送信するための周期（ミリ秒）。
* If the connection type is LTE:
* 接続タイプがLTEの場合：
- High and low thresholds for sending the Reference Signal Received Power (RSRP) of the serving LTE link.
- サービングLTEリンクの参照信号受信電力（RSRP）を送信するための高しきい値と低しきい値。
- Periodicity, in ms, for sending the RSRP of the serving LTE link.
- サービングLTEリンクのRSRPを送信するための周期（ミリ秒）。
- High and low thresholds for sending the RSRQ (Reference Signal Received Quality) of the serving LTE link.
- サービングLTEリンクのRSRQ（参照信号受信品質）を送信するための高しきい値と低しきい値。
- Periodicity, in ms, for sending the RSRP of the serving LTE link.
- サービングLTEリンクのRSRPを送信するための周期（ミリ秒）。
- High and low thresholds for sending the reverse link throughput on the serving LTE link.
- サービングLTEリンクでリバースリンクスループットを送信するための高しきい値と低しきい値。
- Periodicity, in ms, for sending the reverse link throughput on the serving LTE link.
- サービングLTEリンクでリバースリンクスループットを送信するための周期（ミリ秒）。
- High and low thresholds, for sending the forward link throughput on the serving LTE link.
- サービングLTEリンクでフォワードリンクスループットを送信するための高しきい値と低しきい値。
- Periodicity, in ms, for sending the forward link throughput on the serving LTE link.
- サービングLTEリンクでフォワードリンクスループットを送信するための周期（ミリ秒）。
* If the connection type is 5G NR:
* If the connection type is 5G NR:
- High and low thresholds for sending the RSRP of the serving NR link.
- サービングNRリンクのRSRPを送信するための高しきい値と低しきい値。
- Periodicity, in ms, for sending the RSRP of the serving NR link.
- サービングNRリンクのRSRPを送信するための周期（ミリ秒）。
- High and low thresholds for sending the RSRQ of the serving NR link.
- サービングNRリンクのRSRQを送信するための高しきい値と低しきい値。
- Periodicity, in ms, for sending the RSRP of the serving NR link.
- サービングNRリンクのRSRPを送信するための周期（ミリ秒）。
- High and low thresholds for sending the reverse link throughput on the serving NR link.
- サービングNRリンクでリバースリンクスループットを送信するための高しきい値と低しきい値。
- Periodicity, in ms, for sending the reverse link throughput on the serving NR link.
- サービングNRリンクでリバースリンクスループットを送信するための周期（ミリ秒）。
- High and low thresholds for sending the forward link throughput on the serving NR link.
- サービングNRリンクでフォワードリンクスループットを送信するための高しきい値と低しきい値。
- Periodicity, in ms, for sending the forward link throughput on the serving NR link.
- サービングNRリンクでフォワードリンクスループットを送信するための周期（ミリ秒）。
The MX Measurement Report contains the following parameters:
MX測定レポートには、次のパラメーターが含まれています。
* Unique Session ID: Session identifier provided to the client in an MX Capability Response.
* 一意のセッションID：MX機能応答でクライアントに提供されるセッション識別子。
* For each delivery connection, include the following:
* 配信接続ごとに、以下を含めます。
- Delivery Connection ID
- 配信接続ID
- Connection Type (e.g., Wi-Fi, 5G NR, MulteFire, LTE)
- 接続タイプ（Wi-Fi、5G NR、MulteFire、LTEなど）
- Delivery Node ID (ECGI in the case of LTE. In the case of Wi-Fi, this is an AP ID or a MAC address.)
- 配信ノードID（LTEの場合はECGI。Wi-Fiの場合は、AP IDまたはMACアドレスです。）
- If the connection type is Wi-Fi:
- 接続タイプがWi-Fiの場合：
o Average RSSI of the Wi-Fi link.
o Wi-Fiリンクの平均RSSI。
o Loading of the WLAN system.
o Loading of the WLAN system.
o Reverse link throughput on the Wi-Fi link.
o Wi-Fiリンクのリバースリンクスループット。
o Forward link throughput on the Wi-Fi link.
o Wi-Fiリンクでのフォワードリンクスループット。
o Estimated reverse link throughput on the Wi-Fi link (EstimatedThroughputOutbound as defined in [IEEE-80211]).
o Estimated reverse link throughput on the Wi-Fi link (EstimatedThroughputOutbound as defined in [IEEE-80211]).
o Estimated forward link throughput on the Wi-Fi link (EstimatedThroughputInbound, as defined in [IEEE-80211]).
o Wi-Fiリンクの推定フォワードリンクスループット（[IEEE-80211]で定義されているEstimatedThroughputInbound）。
- If the connection type is LTE:
- 接続タイプがLTEの場合：
o RSRP of the serving LTE link.
o サービングLTEリンクのRSRP。
o RSRQ of the serving LTE link.
o サービングLTEリンクのRSRQ。
o Reverse link throughput on the serving LTE link.
o サービングLTEリンクのリバースリンクスループット。
o Forward link throughput on the serving LTE link.
o サービングLTEリンクでのフォワードリンクスループット。
- If the connection type is 5G NR:
- If the connection type is 5G NR:
o RSRP of the serving NR link.
o サービングNRリンクのRSRP。
o RSRQ of the serving NR link.
o サービングNRリンクのRSRQ。
o Reverse link throughput on the serving NR link.
o サービングNRリンクのリバースリンクスループット。
o Forward link throughput on the serving NR link.
o サービングNRリンクでのフォワードリンクスループット。
CCM NCM
| |
|---- MX Session Termination REQ --->|
| |
| |
|<--- MX Session Termination RSP ----|
| |
| +------------------+
| | Remove Resources |
| +------------------+
| |
Figure 13: MAMS Session Termination Procedure - Initiated by Client
図13：MAMSセッション終了手順-クライアントが開始
CCM NCM
| |
|<--- MX Session Termination REQ ----|
| |
| |
|---- MX Session Termination RSP --->|
| |
+------------------+ |
| Remove Resources | |
+------------------+ |
| |
Figure 14: MAMS Session Termination Procedure - Initiated by Network
図14：MAMSセッション終了手順-ネットワークによって開始
At any point in MAMS processing, if the CCM or NCM is no longer able to support the MAMS functions, then either of them can initiate a termination procedure by sending an MX Session Termination Request to the peer. The peer SHALL acknowledge the termination by sending an MX Session Termination Response message. After the session is disconnected, the CCM SHALL start a new procedure with an MX Discover message. An MX Session Termination Request shall contain a Unique Session ID and the reason for the termination. Possible reasons for termination are:
MAMS処理の任意の時点で、CCMまたはNCMがMAMS機能をサポートできなくなった場合、どちらかがMXセッション終了要求をピアに送信して終了手順を開始できます。ピアは、MXセッション終了応答メッセージを送信して終了を確認する必要があります（SHALL）。セッションが切断された後、CCMはMX Discoverメッセージで新しいプロシージャを開始する必要があります。 MXセッション終了リクエストには、一意のセッションIDと終了の理由が含まれます。終了の考えられる理由は次のとおりです。
* Normal Release
* 通常リリース
* No Response from Peer
* ピアからの応答がありません
* Internal Error
* 内部エラー
CCM NCM
| |
|----- MX Network Analytics REQ --->|
| |
| |
|<--- MX Network Analytics RSP -----|
| |
Figure 15: MAMS Network Analytics Request Procedure
図15：MAMSネットワーク分析要求手順
The CCM sends the MX Network Analytics Request to the NCM to request information related to such network parameters as bandwidth, latency, jitter, and signal quality, based on the application of analytics at the network (utilizing the received path measurements and client measurement reporting).
CCMはMXネットワーク分析要求をNCMに送信し、ネットワークでの分析のアプリケーションに基づいて、帯域幅、待ち時間、ジッター、信号品質などのネットワークパラメーターに関連する情報を要求します（受信したパス測定とクライアント測定レポートを利用） 。
The MX Network Analytics Request consists of the following parameters:
The MX Network Analytics Request consists of the following parameters:
* Link Quality Indicators. One or more of the following:
* リンク品質インジケータ。以下の1つ以上：
- Bandwidth
- 帯域幅
- Jitter
- ジッタ
- Latency
- 待ち時間
- Signal Quality
- 信号品質
The NCM sends the MX Network Analytics Response to convey analytics information that might be of interest to the CCM. This message will include network parameters with their predicted likelihoods.
NCMは、MXネットワーク分析応答を送信して、CCMに関係する可能性のある分析情報を伝えます。このメッセージには、予測される可能性のあるネットワークパラメータが含まれます。
The MX Network Analytics Response consists of the following parameters:
MXネットワーク分析応答は、次のパラメーターで構成されています。
* Number of Delivery Connections.
* 配信接続の数。
For each delivery connection, include the following:
配信接続ごとに、以下を含めます。
- Access Link Identifier:
- アクセスリンク識別子：
o Connection Type
o 接続タイプ
o Connection ID
o 接続ID
- Link Quality Indicator:
- Link Quality Indicator:
o Bandwidth:
o 帯域幅：
+ Predicted Value (Mbps)
+ 予測値（Mbps）
+ Likelihood (percent)
+ Likelihood (percent)
+ Prediction Validity (Validity Time, in seconds)
+ 予測有効性（有効時間、秒単位）
o Jitter:
o ジッタ：
+ Predicted Value (in seconds)
+ 予測値（秒）
+ Likelihood (percent)
+ 可能性（パーセント）
+ Prediction Validity (Validity Time, in seconds)
+ 予測有効性（有効時間、秒単位）
o Latency:
o 待ち時間：
+ Predicted Value (in seconds)
+ 予測値（秒）
+ Likelihood (percent)
+ 可能性（パーセント）
+ Prediction Validity (Validity Time, in seconds)
+ 予測有効性（有効時間、秒単位）
o Signal Quality:
o 信号品質：
+ If delivery connection type is LTE, LTE_RSRP Predicted Value in decibel-milliwatts (dBm)
+ 配信接続タイプがLTEの場合、LTE_RSRP予測値（デシベルミリワット（dBm））
+ If delivery connection type is LTE, LTE_RSRQ Predicted Value (dBm)
+ 配信接続タイプがLTEの場合、LTE_RSRQ予測値（dBm）
+ If delivery connection type is 5G NR, NR_RSRP Predicted Value (dBm)
+ 配信接続タイプが5G NRの場合、NR_RSRP予測値（dBm）
+ If delivery connection type is 5G NR, NR_RSRQ Predicted Value (dBm)
+ 配信接続タイプが5G NRの場合、NR_RSRQ予測値（dBm）
+ If delivery connection type is Wi-Fi, WLAN_RSSI Predicted Value (dBm)
+ 配信接続タイプがWi-Fiの場合、WLAN_RSSI予測値（dBm）
+ Likelihood (percent)
+ 可能性（パーセント）
+ Prediction Validity (Validity Time, in seconds)
+ 予測有効性（有効時間、秒単位）
Figure 16 illustrates the MAMS signaling mechanism for negotiation of network paths and flow protocols between the client and the network. In this example scenario, the client is connected to two networks (LTE and Wi-Fi).
図16は、クライアントとネットワーク間のネットワークパスとフロープロトコルのネゴシエーションのためのMAMSシグナリングメカニズムを示しています。このシナリオ例では、クライアントは2つのネットワーク（LTEとWi-Fi）に接続されています。
+--------------------------------------------+
| MAMS-enabled Network of Networks |
| +-------+ +-------+ +-----+ +------+ |
+------------------+ | | | | | | | | | |
| Client | | |Network| |Network| | | | | |
| +------+ +-----+ | | | 1 | | 2 | | NCM | |N-MADP| |
| |C-MADP| | CCM | | | | (LTE) | |(Wi-Fi)| | | | | |
| +------+ +-----+ | | +-------+ +-------+ +-----+ +------+ |
| | | | | | | | | |
++---+--------+----+ +-----+-----------+----------+----------+----+
| | | | | | |
| | | | | | |
| | 1. Setup Connection | | | |
|<-----------+------------->| | | |
| | | | | | |
| | | 2. MAMS Capabilities Exchange | |
| | |<-------------+-----------+--------->| |
| | | | | | |
| | 3. Setup Connection | | | |
|<--+---------------------------------->| | |
| | | | | | |
| 4c. Config | 4a. Negotiate network paths, |4b. Config|
| | C-MADP | Flow protocol, and parameters | N-MADP|
| |<------>|<-------------+-----------+--------->|<-------->|
| | | | | | |
| | | 5. Establish user-plane path according |
| | | to selected flow protocol | |
| |<----------------------+-----------+-------------------->|
| | | | | | |
+ + + + + + +
Figure 16: MAMS Call Flow
図16：MAMSコールフロー
1. The client connects to Network 1 and gets an IP address assigned by Network 1.
1. クライアントはネットワーク1に接続し、ネットワーク1によって割り当てられたIPアドレスを取得します。
2. The CCM communicates with the NCM functional element via the Network 1 connection and exchanges capabilities and parameters for MAMS operation. Note: The NCM credentials (e.g., the NCM's IP address) can be made known to the client by provisioning.
2. CCMは、ネットワーク1接続を介してNCM機能要素と通信し、MAMS操作の機能とパラメーターを交換します。注：NCM資格情報（NCMのIPアドレスなど）は、プロビジョニングによってクライアントに知らせることができます。
3. The client sets up the connection with Network 2 and gets an IP address assigned by Network 2.
3. クライアントはネットワーク2との接続をセットアップし、ネットワーク2によって割り当てられたIPアドレスを取得します。
4. 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.
4. CCMおよびNCMは、ネットワークパスを確立するための機能とパラメータをネゴシエートします。次に、ネゴシエートされた機能とパラメータを使用して、ユーザープレーン機能、つまりネットワークのN-MADPとクライアントのC-MADPを構成します。
4a. The CCM and NCM negotiate network paths, flow routing and aggregation protocols, and related parameters.
4a。 CCMおよびNCMは、ネットワークパス、フロールーティングおよび集約プロトコル、および関連するパラメーターをネゴシエートします。
4b. The NCM communicates with the N-MADP to exchange and configure flow aggregation protocols, policies, and parameters in alignment with those negotiated with the CCM.
4b。 NCMはN-MADPと通信して、CCMとネゴシエートされたものと整合するフロー集約プロトコル、ポリシー、およびパラメーターを交換および構成します。
4c. The CCM communicates with the C-MADP to exchange and configure flow aggregation protocols, policies, and parameters in alignment with those negotiated with the NCM.
4c。 CCMはC-MADPと通信して、NCMとネゴシエートされたものと整合するフロー集約プロトコル、ポリシー、およびパラメーターを交換および構成します。
5. The C-MADP and N-MADP establish the user-plane paths, e.g., using Internet Key Exchange Protocol (IKE) [RFC7296] signaling, based on the negotiated flow aggregation protocols and parameters specified by the NCM.
5. C-MADPおよびN-MADPは、ネゴシエートされたフロー集約プロトコルおよびNCMによって指定されたパラメーターに基づいて、たとえばインターネットキーエクスチェンジプロトコル（IKE）[RFC7296]シグナリングを使用してユーザープレーンパスを確立します。
The CCM and NCM can further exchange messages containing access link measurements for link maintenance by the NCM. The NCM evaluates the link conditions in the UL and DL across LTE and Wi-Fi, based on link measurements reported by the CCM and/or link-probing techniques, and determines the policy for UL and DL user data distribution. The NCM and CCM also negotiate application-level policies for categorizing applications, e.g., based on the Differentiated Services Code Point (DSCP), destination IP address, and determination of which available network path needs to be used for transporting data of that category of applications. The NCM configures the N-MADP, and the CCM configures the C-MADP, based on the negotiated application policies. The CCM may apply local application policies, in addition to the application policy conveyed by the NCM.
CCMおよびNCMは、NCMによるリンクメンテナンスのためのアクセスリンク測定を含むメッセージをさらに交換できます。 NCMは、CCMおよび/またはリンクプローブ技術によって報告されたリンク測定に基づいて、LTEおよびWi-Fi全体のULおよびDLのリンク状態を評価し、ULおよびDLユーザーデータ配信のポリシーを決定します。 NCMおよびCCMは、アプリケーションを分類するためのアプリケーションレベルのポリシーもネゴシエートします。たとえば、Differentiated Services Code Point（DSCP）、宛先IPアドレス、およびアプリケーションのそのカテゴリのデータの転送に使用する必要がある利用可能なネットワークパスの決定に基づいています。 。ネゴシエートされたアプリケーションポリシーに基づいて、NCMがN-MADPを構成し、CCMがC-MADPを構成します。 CCMは、NCMによって伝達されるアプリケーションポリシーに加えて、ローカルアプリケーションポリシーを適用する場合があります。
The MAMS framework leverages technologies developed in the IETF (such as MPTCP and GRE) and enables a control-plane framework to negotiate the use of these protocols between the client and the network. It also addresses the limitations in scope of other multihoming protocols. For example, the IKEv2 Mobility and Multihoming Protocol (MOBIKE [RFC4555]) 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.
MAMSフレームワークは、IETFで開発されたテクノロジー（MPTCPやGREなど）を活用し、コントロールプレーンフレームワークがクライアントとネットワーク間でこれらのプロトコルの使用をネゴシエートできるようにします。また、他のマルチホーミングプロトコルの範囲の制限にも対処します。たとえば、IKEv2モビリティおよびマルチホーミングプロトコル（MOBIKE [RFC4555]）スコープは、IPsecクライアント（トンネルモードIPsecセキュリティアソシエーション）間のマルチホーミングに限定され、ロードバランシングをサポートしないことを示します。マルチホーミングシナリオの処理方法に関するこの制限に対処するために、MAMSフレームワークは、MPTCPなどのプロトコルの使用をネゴシエートすることにより、複数のアクセスパスを同時に使用するロードバランシングをサポートしています。 IPsecトンネルモードのセキュリティアソシエーションで接続されたエンドポイントにのみ適用されるMOBIKEとは異なり、MAMSフレームワークでは、適応層で幅広いトンネリングプロトコルを柔軟に使用できます。
If the NCM determines that the N-MADP is to be instantiated with MPTCP as the MX Convergence Protocol, it exchanges the MPTCP capability support in the discovery and capability exchange procedures. An MPTCP proxy (e.g., see [TCPM-CONVERTERS]) is configured to be the N-MADP instance. The NCM then provides the credentials of the MPTCP Proxy instance, along with related parameters, to the CCM. The CCM configures the C-MADP with these parameters to connect to this MPTCP proxy instance.
NCMは、N-MADPがMXコンバージェンスプロトコルとしてMPTCPでインスタンス化されると判断した場合、ディスカバリおよび機能交換手順でMPTCP機能サポートを交換します。 MPTCPプロキシ（例：[TCPM-CONVERTERS]を参照）は、N-MADPインスタンスとして構成されます。次に、NCMはMPTCPプロキシインスタンスの資格情報を、関連するパラメータとともにCCMに提供します。 CCMは、これらのパラメータを使用してC-MADPを構成し、このMPTCPプロキシインスタンスに接続します。
Figure 17 illustrates the user-plane protocol layering when MPTCP is configured to be the "MX Convergence Layer" protocol. MPTCP manages traffic distribution and aggregation over multiple delivery connections.
図17は、MPTCPが "MXコンバージェンスレイヤー"プロトコルになるように構成されている場合のユーザープレーンプロトコルレイヤーを示しています。 MPTCPは、複数の配信接続でのトラフィックの分散と集約を管理します。
+-----------------------------------------------------+
| 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 17: MAMS User-Plane Protocol Stack with MPTCP as MX Convergence Layer
図17：MXコンバージェンスレイヤーとしてMPTCPを使用したMAMSユーザープレーンプロトコルスタック
The client (C-MADP) sets up an MPTCP connection with the N-MADP to begin with. The MAMS control procedures are then applied to do the following:
クライアント（C-MADP）は、まずN-MADPとのMPTCP接続をセットアップします。次に、MAMS制御手順を適用して、次のことを行います。
* Connect to the appropriate MPTCP network endpoint, e.g., the MPTCP proxy (illustrated in Figure 18).
* MPTCPプロキシなどの適切なMPTCPネットワークエンドポイントに接続します（図18を参照）。
* Control the addition of a second TCP subflow after the Wi-Fi connection is established and is deemed good (illustrated in Figure 19).
* Wi-Fi接続が確立され、良好と見なされた後、2番目のTCPサブフローの追加を制御します（図19に示されています）。
* Control the behavior of the MPTCP scheduler, e.g., by using only the LTE subflow in the UL and both the LTE and Wi-Fi subflows in the DL (illustrated in Figure 20).
* MPULスケジューラの動作を制御します。たとえば、ULでLTEサブフローのみを使用し、DLでLTEサブフローとWi-Fiサブフローの両方を使用します（図20を参照）。
* Provide faster response to Wi-Fi link degradation by proactively deleting a TCP subflow over Wi-Fi when poor link conditions are reported, maintaining optimum performance (illustrated in Figure 21).
* リンクの状態が悪いことが報告されたときにWi-Fi経由のTCPサブフローを積極的に削除し、最適なパフォーマンスを維持することで、Wi-Fiリンクの劣化に対する応答を高速化します（図21を参照）。
Figure 18 shows the call flow describing MAMS control procedures applied to configure the user plane and dynamic optimal path selection in a scenario with the MPTCP proxy as the convergence protocol in the user plane.
図18は、MPTCPプロキシをユーザープレーンのコンバージェンスプロトコルとして使用するシナリオでユーザープレーンと動的最適パス選択を構成するために適用されるMAMS制御手順を説明するコールフローを示しています。
+------+ +--------+ +--------+ +-------+ +-------+ +------+
| | | | | | | | | | | |
| CCM | | C-MADP | | Wi-Fi | | LTE | | NCM | |N-MADP|
| | | | | N/W | | N/W | | | | |
+------+ +--------+ +--------+ +-------+ +-------+ +------+
+------------------------------------------------------------------+
| 1. LTE Session Setup and IP Address Allocation |
+-----------------------------------------+-----------+------------+
| | | |
|2. MX Discover (MAMS Version, MCC/MNC) | | |
+----------------------------------------+---------->| |
|3. MX System Info (Serving NCM IP/Port Address) | |
|<------------+-------------+-------------+----------+ |
| | | | | |
|4. MX Capability REQ (Supported Anchor/Delivery | |
| | Links (Wi-Fi, LTE)) | |
+--------------------------------------------------->| |
|5. MX Capability RSP (Convergence/Adaptation Parameters) |
|<----------------------------------------+----------+ |
|6. MX Capability ACK (ACCEPT) | | |
+-------------+-------------+----------------------->| |
| | | | | |
|7. MX Meas Config (Wi-Fi/LTE Measurement Thresholds/Period) |
|<---------------------------------------------------+ |
|8. MX Meas Report (LTE RSRP, UL/DL TPUT) | | |
+-----------------------------------------+--------->| |
|9. MX SSID Indication (List of SSIDs) | | |
|<------------+-------------+------------------------+ |
| | | | | |
|10. MX Reconfiguration REQ (LTE IP) | | |
+--------------------------------------------------->| |
|11. MX Reconfiguration RSP | | |
|<----------------------------------------+----------+ |
|12. MX UP Setup REQ (MPTCP proxy IP/Port, Aggregation) |
|<--------------------------+-------------+----------+ |
|13. MX UP Setup RSP | | | |
+-------------+-------------+-------------+--------->| |
| | 14. MPTCP connection with designated | |
| | MPTCP proxy over LTE | |
| +-------------+-------------+----------+------->|
| | | | | |
+ + + + + +
Figure 18: MAMS-Assisted MPTCP Proxy as User Plane - Initial Setup with LTE Leg
図18：ユーザープレーンとしてのMAMS支援MPTCPプロキシ-LTE Legを使用した初期セットアップ
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.
コールフローで説明されている主な手順は次のとおりです。クライアントはLTEネットワークに接続し、IPアドレスを取得します（LTEが最初の接続であると想定します）。次に、NCM検出手順を開始し、ネットワークとクライアントの両方でコンバージェンスプロトコルとしてのMPTCPのサポートを含む機能を交換します。
The CCM provides the LTE connection parameters to the NCM. The NCM provides the parameters like MPTCP proxy IP address/port, and MPTCP Client Key for configuring the Convergence Layer. This is useful if the N-MADP is reachable, via a different IP address or/and port, from different access networks. The current MPTCP signaling can't identify or differentiate the MPTCP proxy IP address and port from multiple access networks. The client uses the MPTCP Client Key during the subflow creation, and this enables the N-MADP to uniquely identify the client, even if a NAT is present. The N-MADP can then inform the NCM of the subflow creation and parameters related to creating additional subflows. Since LTE is the only connection, the user-plane traffic flows over the single TCP subflow over the LTE connection. Optionally, the NCM provides assistance information to the client on the neighboring/preferred Wi-Fi networks that it can associate with.
CCMは、LTE接続パラメーターをNCMに提供します。 NCMは、MPTCPプロキシIPアドレス/ポート、およびコンバージェンスレイヤーを構成するためのMPTCPクライアントキーなどのパラメーターを提供します。これは、異なるアクセスネットワークから異なるIPアドレスまたはポート、あるいはその両方を介してN-MADPに到達できる場合に役立ちます。現在のMPTCPシグナリングでは、MPTCPプロキシIPアドレスとポートを識別したり、複数のアクセスネットワークから区別したりできません。クライアントはサブフローの作成中にMPTCPクライアントキーを使用します。これにより、N-MADPは、NATが存在する場合でもクライアントを一意に識別できます。次に、N-MADPはNCMにサブフローの作成と追加のサブフローの作成に関連するパラメーターを通知できます。 LTEが唯一の接続であるため、ユーザープレーントラフィックは、LTE接続上の単一のTCPサブフローを流れます。必要に応じて、NCMは、関連付け可能な近隣/優先Wi-Fiネットワーク上のクライアントに支援情報を提供します。
Figure 19 describes the steps where the client establishes a Wi-Fi connection. The CCM informs the NCM of the Wi-Fi connection, along with such parameters as the Wi-Fi IP address or the SSID. The NCM determines that the Wi-Fi connection needs to be secured, configures the Adaptation Layer to use IPsec, and provides the required parameters to the CCM. In addition, the NCM provides the information for configuring the Convergence Layer (e.g., MPTCP proxy IP address) and provides the MX Traffic Steering Request to indicate that the client 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 an MX Traffic Steering Request to use Wi-Fi access as well. This triggers the client to establish the TCP subflow over the Wi-Fi link with the MPTCP proxy.
図19は、クライアントがWi-Fi接続を確立する手順を示しています。 CCMは、Wi-Fi接続や、Wi-Fi IPアドレスやSSIDなどのパラメーターをNCMに通知します。 NCMは、Wi-Fi接続を保護する必要があると判断し、IPsecを使用するようにアダプテーションレイヤーを構成し、必要なパラメーターをCCMに提供します。さらに、NCMは、コンバージェンスレイヤー（MPTCPプロキシIPアドレスなど）を構成するための情報を提供し、クライアントがLTEアクセスのみを使用する必要があることを示すMXトラフィックステアリング要求を提供します。 NCMは、たとえば、測定からWi-Fiリンクが一貫して十分に良好でないと判断したときにこれを行う場合があります。 Wi-Fiリンクの状態が改善すると、NCMはMXトラフィックステアリング要求を送信して、Wi-Fiアクセスも使用できるようにします。これにより、クライアントはMPTCPプロキシとのWi-Fiリンクを介してTCPサブフローを確立します。
+------+ +--------+ +--------+ +-------+ +-------+ +------+
| | | | | | | | | | | |
| CCM | | C-MADP | | Wi-Fi | | LTE | | NCM | |N-MADP|
| | | | | N/W | | N/W | | | | |
+------+ +--------+ +--------+ +-------+ +-------+ +------+
+-------------------------------------------------------------------+
| Traffic over LTE in UL and DL over MPTCP Connection |
+-------------------------------------------------------------------+
+-------------------------------------------------------------------+
| Wi-Fi Connection Establishment and IP Address Allocation |
+----------------------------------------------------------------+--+
| | | | | |
|15. MX Reconfiguration REQ (Wi-Fi IP) | | |
+--------------------------------------------------->| |
|16. MX Reconfiguration RSP | | |
|<----------------------------------------+----------+ |
|17. MX UP Setup REQ (MPTCP proxy IP/Port, Aggregation) |
|<--------------------------+-------------+----------+ |
|18. MX UP Setup RSP | | | |
+-------------+-------------+-------------+--------->| |
| |19. IPsec Tunnel Establishment over Wi-Fi Path |
| |<-------------------------------------+-------->|
| | | | | |
|20. MX Meas Report (Wi-Fi RSSI, | | |
| LTE RSRP, UL/DL TPUT) | |+------------+
+-------------+-------------+-------------+--------->||Wait for |
| | | | ||good reports|
| | | | |+------------+
|21. MX Traffic Steering REQ (UL/DL access, | |
| Traffic Flow Templates (TFTs)) | +----------+
|<----------------------------------------+----------+ |Allow use |
| | | | of |
|22. MX Traffic Steering RSP (...) | | |Wi-Fi link|
+-------------+-------------+----------------------->| +----------+
| | | | | |
| | 23. Add TCP subflow to the MPTCP connection |
| | over Wi-Fi link (IPsec Tunnel) |
| |<---------------------------------------------->|
| | | | | |
+----------------------------------------------------------------+
|| Aggregated Wi-Fi and LTE capacity for UL and DL ||
+----------------------------------------------------------------+
| |
| |
Figure 19: MAMS-Assisted MPTCP Proxy as User Plane - Add Wi-Fi Leg
図19：ユーザープレーンとしてのMAMS支援MPTCPプロキシ-Wi-Fiレッグの追加
Figure 20 describes the steps where the client reports that Wi-Fi link conditions degrade in UL. The MAMS control plane is used to continuously monitor the access link conditions on Wi-Fi and LTE connections. The NCM may at some point determine an increase in UL traffic on the Wi-Fi network, and trigger the client to use only LTE in the UL via a MX Traffic Steering Request to improve UL performance.
図20は、ULでWi-Fiリンクの状態が低下したことをクライアントが報告する手順を示しています。 MAMSコントロールプレーンは、Wi-Fi接続とLTE接続のアクセスリンク状態を継続的に監視するために使用されます。 NCMは、ある時点でWi-Fiネットワーク上のULトラフィックの増加を判断し、クライアントをトリガーして、MXトラフィックステアリングリクエストを介してULでLTEのみを使用し、ULパフォーマンスを向上させることができます。
+------+ +--------+ +--------+ +-------+ +-------+ +------+
| | | | | | | | | | | |
| CCM | | C-MADP | | Wi-Fi | | LTE | | NCM | |N-MADP|
| | | | | N/W | | N/W | | | | |
+------+ +--------+ +--------+ +-------+ +-------+ +------+
+-------------------------------------------------------------------+
| Traffic over LTE and Wi-Fi in UL And DL over MPTCP |
++------------+-------------+-------------+------------+--------+---+
| | | | | |
|24. MX Meas Report (Wi-Fi RSSI, LTE RSRP, UL/DL TPUT)| +------+---+
+------------+-------------+-------------+----------->| |Reports of|
| | | | | |bad Wi-Fi |
| | | | | |UL tput |
| | | | | +----------+
|25. MX Traffic Steering REQ (UL/DL Access, TFTs) | +----------+
|<---------------------------------------+------------+ |Disallow |
| | | | | |use of |
|26. MX Traffic Steering RSP (...) | | |Wi-Fi UL |
|------------+-------------+------------------------->| +------+---+
| | | | | |
++------------+-------------+-------------+------------+--------+---+
| UL data to use TCP subflow over LTE link only, |
| aggregated Wi-Fi+LTE capacity for DL |
++------------+-------------+-------------+------------+--------+---+
| | | | | |
+ + + + + +
Figure 20: MAMS-Assisted MPTCP Proxy as User Plane - Wi-Fi UL Degrades
図20：ユーザープレーンとしてのMAMS支援MPTCPプロキシ-Wi-Fi ULが低下
Figure 21 describes the steps where the client reports that Wi-Fi link conditions have degraded in both the UL and DL. As the Wi-Fi link conditions deteriorate further, the NCM may decide to send a MX Traffic Steering Request that instructs the client to stop using Wi-Fi and to use only the LTE access in both the UL and DL. This condition may be maintained until the NCM determines, based on reported measurements, that the Wi-Fi link has again become usable.
図21は、ULとDLの両方でWi-Fiリンク状態が低下したことをクライアントが報告する手順を示しています。 Wi-Fiリンクの状態がさらに悪化すると、NCMはMXトラフィックステアリング要求を送信して、Wi-Fiの使用を停止し、ULとDLの両方でLTEアクセスのみを使用するように指示する場合があります。この状態は、NCMが報告された測定に基づいてWi-Fiリンクが再び使用可能になったと判断するまで維持されます。
+------+ +--------+ +--------+ +-------+ +-------+ +------+
| | | | | | | | | | | |
| CCM | | C-MADP | | Wi-Fi | | LTE | | NCM | |N-MADP|
| | | | | N/W | | N/W | | | | |
+------+ +--------+ +--------+ +-------+ +-------+ +------+
+------------------------------------------------------------------+
| UL data to use TCP subflow over LTE link only, |
| aggregated Wi-Fi+LTE capacity for DL |
++------------+-------------+-------------+----------+---------+---+
| | | | | |
| | | | | |
|27. MX Meas Report (Wi-Fi RSSI, | | |
| LTE RSRP, UL/DL TPUT) | | +-------+----+
+------------+-------------+-------------+--------->| | Reports of |
| | | | | | bad Wi-Fi |
| | | | | | UL/DL tput |
| | | | | +------------+
|28. MX Traffic Steering REQ (UL/DL Access, TFTs) | +------------+
|<---------------------------------------+----------+ | Disallow |
| | | | | | use of |
|29. MX Traffic Steering RSP (...) | | | Wi-Fi |
+----------------------------------------+--------->| +------------+
| |30. Delete TCP subflow from MPTCP | |
| | connection over Wi-Fi link | |
| |<---------------------------------------------->|
| | | | | |
+--------------------------------------------------------------+
|| Traffic over LTE link only for DL and UL |
|| (until client reports better Wi-Fi link conditions) |
+--------------------------------------------------------------+
| | | | | |
+ + + + + +
Figure 21: MAMS-Assisted MPTCP Proxy as User Plane - Part 4
図21：ユーザープレーンとしてのMAMS支援MPTCPプロキシ-パート4
12. Applying MAMS Control Procedures for Network-Assisted Traffic Steering When There Is No Convergence Layer
12. コンバージェンスレイヤーがない場合のネットワーク支援トラフィックステアリングへのMAMS制御手順の適用
Figure 22 shows the call flow describing MAMS control procedures applied for dynamic optimal path selection in a scenario where Convergence and Adaptation Layer protocols are omitted. This scenario indicates the applicability of a solution for only the MAMS control plane.
図22は、収束および適応層プロトコルが省略されているシナリオで動的最適パス選択に適用されるMAMS制御手順を説明するコールフローを示しています。このシナリオは、MAMSコントロールプレーンのみに対するソリューションの適用性を示しています。
In the capability exchange messages, the NCM and CCM negotiate that Convergence-Layer and Adaptation-Layer protocols are not needed (or supported). The CCM informs the NCM of the availability of the LTE and Wi-Fi links. The NCM dynamically determines the access links (Wi-Fi or LTE) to be used based on the reported measurements of link quality.
機能交換メッセージでは、NCMとCCMは、Convergence-LayerおよびAdaptation-Layerプロトコルが不要（またはサポートされていない）であることを交渉します。 CCMは、LTEおよびWi-Fiリンクの可用性をNCMに通知します。 NCMは、報告されたリンク品質の測定値に基づいて、使用するアクセスリンク（Wi-FiまたはLTE）を動的に決定します。
+------+ +--------+ +--------+ +-------+ +-------+ +------+
| | | | | | | | | | | |
| CCM | | C-MADP | | Wi-Fi | | LTE | | NCM | |N-MADP|
| | | | | N/W | | N/W | | | | |
+------+ +--------+ +--------+ +-------+ +-------+ +------+
+------------------------------------------------------------------+
| 1. LTE Session Setup and IP Address Allocation |
+---------------------------------------+-------------+----------+-+
|2. MX Discover (MAMS Version, MCC/MNC ) | |
+--------------------------------------+------------>| |
|3. MX System Info (Serving NCM IP/Port address) | |
|<------------+-------------+----------+-------------| |
| | | | | |
|4. MX Capability REQ (Supported | | |
| Anchor/Delivery Links (Wi-Fi, LTE))| | |
+--------------------------------------------------->| |
|5. MX Capability RSP (No Convergence/Adaptation parameters) |
|<-------------------------------------+-------------+ |
|6. MX Capability ACK (ACCEPT) | | |
+-------------+-------------+----------------------->| |
| | | | | |
|7. MX Meas Config (Wi-Fi/LTE Measurement Thresholds/Period) |
|<---------------------------------------------------| |
|8. MX Meas Report (LTE RSRP, UL/DL TPUT) | |
|--------------------------------------+------------>| |
|9. MX SSID Ind (List of SSIDs) | | |
|<---------------------------------------------------| |
+-----------------------------------------------------------------++
| 10. Wi-Fi Connection Setup and IP Address Allocation |
+-+-------------+-------------+----------+-------------+----------++
| | | | | |
|11. MX Reconfiguration REQ (LTE IP, Wi-Fi IP) | |
|--------------------------------------+------------>| |
|12. MX Reconfiguration RSP | | |
|<---------------------------------------------------| |
+-----------------------------------------------------------------++
| Initial Condition, Data over LTE link only, Wi-Fi link is poor |
+------------------------------------------------------+----------++
| | | | | |
|13. MX Meas Report (Wi-Fi RSSI, | | |
| LTE RSRP, UL/DL TPUT)| | |+----------+
|--------------------------------------------------->||Wi-Fi link|
| | | | ||conditions|
| | | | ||reported |
| | | | ||good |
| | | | |+----------+
| | | | | |
|14. MX Traffic Steering REQ (UL/DL Access, TFTs) |+----------+
|<------------+-------------+----------+-------------||Steer |
| | | | ||traffic to|
|15. MX Traffic Steering RSP (...) | ||use Wi-Fi |
|<------------+-------------+----------+-------------||link |
| | | | |+----------+
| | | | | |
+-----------------------------------------------------------------++
| Use Wi-Fi link for Data |
+------------------------------------------------------+----------++
| | | | | |
+ + + + + +
Figure 22: MAMS with No Convergence Layer
図22：コンバージェンスレイヤーのないMAMS
The MAMS user plane supports multiple instances and combinations of protocols to be used at the MX Adaptation and the Convergence Layer.
MAMSユーザープレーンは、MXアダプテーションとコンバージェンスレイヤーで使用される複数のインスタンスとプロトコルの組み合わせをサポートします。
For example, one instance of the MX Convergence Layer can be MPTCP Proxy and another instance can be GMA. The MX Adaptation for each can be either a UDP tunnel or IPsec. IPsec may be set up when the network path needs to be secured, e.g., to protect the TCP subflow traversing the network path between the client and the MPTCP proxy.
たとえば、MXコンバージェンスレイヤーの1つのインスタンスをMPTCPプロキシにして、別のインスタンスをGMAにすることができます。それぞれのMX適応は、UDPトンネルまたはIPsecのいずれかです。クライアントとMPTCPプロキシ間のネットワークパスを通過するTCPサブフローを保護するなど、ネットワークパスを保護する必要がある場合は、IPsecを設定できます。
Each instance of the MAMS user plane, i.e., the combination of MX Convergence-Layer and MX Adaptation-Layer protocols, can coexist simultaneously and independently handle different traffic types.
MAMSユーザープレーンの各インスタンス、つまりMX Convergence-LayerプロトコルとMX Adaptation-Layerプロトコルの組み合わせは、同時に共存して異なるトラフィックタイプを処理できます。
The NCM functional element is hosted on a network node that is assumed to be within a secure network, e.g., within the operator's network, and is assumed to be protected against hijack attacks.
NCM機能要素は、安全なネットワーク内、たとえば事業者のネットワーク内にあると想定され、ハイジャック攻撃から保護されていると想定されるネットワークノードでホストされます。
For deployment scenarios where the client is configured (e.g., by the network operator) to use a specific network path for exchanging control-plane messages, and if the network path is assumed to be secure, MAMS control messages will rely on security provided by the underlying network.
クライアントが（たとえば、ネットワークオペレーターによって）コントロールプレーンメッセージを交換するために特定のネットワークパスを使用するように構成され、ネットワークパスが安全であると想定されている場合、MAMSコントロールメッセージは、基礎となるネットワーク。
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.
ネットワークパスのセキュリティを想定できない導入シナリオでは、NCMおよびCCM実装は、「wss」URIスキーム[RFC6455]およびトランスポート層セキュリティ（TLS）[RFC8446]をサポートして、間のコントロールプレーンメッセージの交換を保護する必要があります。 NCMとCCM。
For deployment scenarios where client authentication is desired, the WebSocket server can use any client authentication mechanisms available to a generic HTTP server, such as cookies, HTTP authentication, or TLS authentication.
クライアント認証が必要な配備シナリオの場合、WebSocketサーバーは、Cookie、HTTP認証、TLS認証など、一般的なHTTPサーバーで利用可能なクライアント認証メカニズムを使用できます。
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 [RFC4301] [RFC3948]) in the MX Adaptation Layer, for security.
MAMSフレームワークのユーザーデータは、基になるネットワークトランスポートパスのセキュリティに依存しています。このセキュリティを想定できない場合、NCMはセキュリティのためにMXアダプテーションレイヤーでプロトコル（IPsec [RFC4301] [RFC3948]など）の使用を構成します。
The MAMS architecture builds on commonly available functions in clients that can be used to deliver software updates over popular client operating systems, thereby enabling rapid deployment and addressing the large base of deployed clients.
MAMSアーキテクチャは、一般的なクライアントオペレーティングシステムでソフトウェアの更新を配信するために使用できるクライアントで一般的に利用可能な機能に基づいて構築されているため、迅速な展開と、展開されたクライアントの大規模なベースへの対応が可能です。
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) [ETSIMEC], 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.
マルチアクセスエッジコンピューティング（MEC）（以前はモバイルエッジコンピューティングと呼ばれていました）は、欧州電気通信標準化機構（ETSI）[ETSIMEC]で検討されているアクセスエッジクラウドプラットフォームです。セルラー（例えば、LTEのような3GPPテクノロジー）アクセスエッジ、およびスコープは3GPPを超えるアクセステクノロジーをサポートするように拡張されています。このドキュメントで説明されているフレームワークのMECプラットフォームへの適用性は、作成者によってさまざまなネットワーク構成で評価およびテストされています。
The NCM can be hosted on a MEC cloud server that is located in the user-plane path at the edge of the multi-technology access network. The NCM and CCM can negotiate the network path combinations based on an application's needs and the necessary user-plane protocols to be used across the multiple paths. The network conditions reported by the CCM to the NCM can be complemented by a Radio Analytics application [ETSIRNIS] residing at the MEC cloud server to configure the uplink and downlink access paths according to changing radio and congestion conditions.
NCMは、マルチテクノロジーアクセスネットワークの端にあるユーザープレーンパスにあるMECクラウドサーバーでホストできます。 NCMとCCMは、アプリケーションのニーズと、複数のパスで使用される必要なユーザープレーンプロトコルに基づいて、ネットワークパスの組み合わせをネゴシエートできます。 CCMからNCMに報告されるネットワーク状態は、MECクラウドサーバーにあるRadio Analyticsアプリケーション[ETSIRNIS]によって補完され、変化する無線および輻輳状態に従ってアップリンクおよびダウンリンクアクセスパスを構成できます。
The user-plane functional element, N-MADP, can either be collocated with the NCM at the MEC cloud server (e.g., MEC-hosted applications) or placed at a separate network element like a common user-plane gateway across the multiple networks.
ユーザープレーンの機能要素であるN-MADPは、MECクラウドサーバー（MECがホストするアプリケーションなど）でNCMと同じ場所に配置するか、複数のネットワークにまたがる共通のユーザープレーンゲートウェイなどの別のネットワーク要素に配置できます。
Also, even in scenarios where an N-MADP is not deployed, the NCM can be used to augment the traffic-steering decisions at the client.
また、N-MADPが展開されていないシナリオでも、NCMを使用して、クライアントでのトラフィックステアリングの決定を強化できます。
The aim of these enhancements is to improve the end user's QoE by leveraging the best network path based on an application's needs and network conditions, and building on the advantages of significantly reduced latency and the dynamic and real-time exposure of radio network information available at the MEC.
これらの機能強化の目的は、アプリケーションのニーズとネットワークの状態に基づいて最適なネットワークパスを活用し、レイテンシを大幅に削減し、無線ネットワーク情報を動的かつリアルタイムに公開することで、エンドユーザーのQoEを改善することです。 MEC。
The MAMS framework described in this document has been incorporated or is proposed for incorporation as a solution to address multi-access integration in multiple industry forums and standards. This section describes the related work in other industry forums and the standards organizations.
このドキュメントで説明されているMAMSフレームワークは、複数の業界フォーラムおよび標準でのマルチアクセス統合に対処するソリューションとして組み込まれている、または組み込むことが提案されています。このセクションでは、他の業界フォーラムおよび標準化団体での関連作業について説明します。
Wireless Broadband Alliance industry partners have published a white paper that describes the applicability of different technologies for multi-access integration to different deployments as part of their "Unlicensed Integration with 5G Networks" project [WBAUnl5G]. The white paper includes the MAMS framework described in this document as a technology for integrating unlicensed (Wi-Fi) networks with 5G networks above the 5G core network.
ワイヤレスブロードバンドアライアンスの業界パートナーは、「5Gネットワークとの無許可の統合」プロジェクト[WBAUnl5G]の一環として、さまざまな導入へのマルチアクセス統合のためのさまざまなテクノロジーの適用性を説明するホワイトペーパーを公開しています。ホワイトペーパーには、このドキュメントで説明されているMAMSフレームワークが、ライセンスのない（Wi-Fi）ネットワークを5Gコアネットワーク上の5Gネットワークと統合するためのテクノロジーとして含まれています。
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 [ATSSS], contains a number of potential solutions; Solution 1 in [ATSSS] utilizes a separate control plane for the flexible negotiation of user-plane protocols and path measurements in a way that is similar to the MAMS architecture described in this document.
3GPPは、ワークアイテム「アクセストラフィックのステアリング、スイッチング、および分割（ATSSS）に関する研究」の一部として技術レポートを作成しています。そのレポート、TR 23.793 [ATSSS]には、いくつかの潜在的な解決策が含まれています。 [ATSSS]のソリューション1は、このドキュメントで説明されているMAMSアーキテクチャと同様の方法で、ユーザープレーンプロトコルとパス測定の柔軟なネゴシエーションのために個別のコントロールプレーンを利用します。
The Small Cell Forum (SCF) [SCFTECH5G] plans to develop a white paper as part of its work item on LTE/5G and Wi-Fi. There is a proposal to include MAMS in this white paper.
スモールセルフォーラム（SCF）[SCFTECH5G]は、LTE / 5GとWi-Fiに関する作業項目の一部としてホワイトペーパーを開発する予定です。このホワイトペーパーにMAMSを含めるという提案があります。
The ETSI Multi-access Edge Computing Phase 2 technical work is examining many aspects of this work, including use cases for optimizing QoE and resource utilization. The MAMS architecture and procedures outlined in this document are included in the ETSI's use cases and requirements document [ETSIMAMS].
ETSIマルチアクセスエッジコンピューティングフェーズ2の技術作業では、QoEとリソース使用率を最適化するための使用例を含め、この作業の多くの側面を調査しています。このドキュメントで概説されているMAMSのアーキテクチャと手順は、ETSIの使用例と要件のドキュメント[ETSIMAMS]に含まれています。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<https://www.rfc-editor.org/info/rfc4301>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[ANDSF] 3rd Generation Partnership Project, "Access Network Discovery and Selection Function (ANDSF) Management Object (MO)", 3GPP TS 24.312 version 15.0.0, Technical Specification Group Core Network and Terminals, June 2018, <https://www.3gpp.org/ftp//Specs/ archive/24_series/24.312/24312-f00.zip>.
[ANDSF] 3rd Generation Partnership Project、「Access Network Discovery and Selection Function（ANDSF）Management Object（MO）」、3GPP TS 24.312 version 15.0.0、Technical Specification Group Core Network and Terminals、2018年6月、<https：// www .3gpp.org / ftp // Specs / archive / 24_series / 24.312 / 24312-f00.zip>。
[ATSSS] 3rd Generation Partnership Project, "Study on access traffic steering, switch and splitting support in the 5G System (5GS) architecture", Work in Progress, 3GPP TR 23.793 v16.0.0, December 2018, <https://www.3gpp.org/ftp/Specs/ archive/23_series/23.793/>.
[ATSSS] 3rd Generation Partnership Project、「Study on access trafficステアリング、switch and splitting support in 5G System（5GS）architecture」、Work in Progress、3GPP TR 23.793 v16.0.0、2018年12月、<https：// www。 3gpp.org/ftp/Specs/archive/23_series/23.793 />。
[ETSIMAMS] European Telecommunications Standards Institute, "Multi-access Edge Computing (MEC); Phase 2: Use Cases and Requirements", ETSI GS MEC 002 v2.1.1, October 2018, <https://www.etsi.org/deliver/etsi_gs/ MEC/001_099/002/02.01.01_60/gs_MEC002v020101p.pdf>.
[ETSIMAMS] European Telecommunications Standards Institute、「Multi-access Edge Computing（MEC）; Phase 2：Use Cases and Requirements」、ETSI GS MEC 002 v2.1.1、2018年10月、<https://www.etsi.org/deliver / etsi_gs / MEC / 001_099 / 002 / 02.01.01_60 / gs_MEC002v020101p.pdf>。
[ETSIMEC] European Telecommunications Standards Institute, "Multi-access Edge Computing (MEC)", <https://www.etsi.org/technologies/multi-access-edge-computing>.
[ETSIMEC] European Telecommunications Standards Institute、「Multi-access Edge Computing（MEC）」、<https://www.etsi.org/technologies/multi-access-edge-computing>。
[ETSIRNIS] European Telecommunications Standards Institute, "Mobile Edge Computing (MEC) Radio Network Information API", ETSI GS MEC 012 v1.1.1, July 2017, <https://www.etsi.org/deliver/etsi_gs/ MEC/001_099/012/01.01.01_60/gs_MEC012v010101p.pdf>.
[ETSIRNIS] European Telecommunications Standards Institute、「Mobile Edge Computing（MEC）Radio Network Information API」、ETSI GS MEC 012 v1.1.1、2017年7月、<https://www.etsi.org/deliver/etsi_gs/ MEC / 001_099 /012/01.01.01_60/gs_MEC012v010101p.pdf>。
[IEEE-80211] IEEE, "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", IEEE 802.11-2016, <https://ieeexplore.ieee.org/document/7786995>.
[IEEE-80211] IEEE、「IEEE Standard for Information technology-Telecommunications and information between systems-Local and Metropolitan Area Network-Specific requirements-Part 11：Wireless LAN Medium Access Control（MAC）and Physical Layer（PHY）Specifications」、 IEEE 802.11-2016、<https://ieeexplore.ieee.org/document/7786995>。
[INTAREA-GMA] Zhu, J. and S. Kanugovi, "Generic Multi-Access (GMA) Convergence Encapsulation Protocols", Work in Progress, Internet-Draft, draft-zhu-intarea-gma-05, 16 December 2019, <https://tools.ietf.org/html/draft-zhu-intarea-gma-05>.
[INTAREA-GMA] Zhu、J。およびS. Kanugovi、「Generic Multi-Access（GMA）Convergence Encapsulation Protocols」、Work in Progress、Internet-Draft、draft-zhu-intarea-gma-05、2019年12月16日、< https://tools.ietf.org/html/draft-zhu-intarea-gma-05>。
[INTAREA-MAMS] Zhu, J., Seo, S., Kanugovi, S., and S. Peng, "User-Plane Protocols for Multiple Access Management Service", Work in Progress, Internet-Draft, draft-zhu-intarea-mams-user-protocol-09, 4 March 2020, <https://tools.ietf.org/html/ draft-zhu-intarea-mams-user-protocol-09>.
[INTAREA-MAMS] Zhu、J.、Seo、S.、Kanugovi、S。、およびS. Peng、「Multiple Access Management Serviceのユーザープレーンプロトコル」、作業中、インターネットドラフト、draft-zhu-intarea -mams-user-protocol-09、2020年3月4日、<https://tools.ietf.org/html/draft-zhu-intarea-mams-user-protocol-09>。
[ITU-E212] International Telecommunication Union, "The international identification plan for public networks and subscriptions", ITU-T Recommendation E.212, September 2016, <https://www.itu.int/rec/T-REC-E.212-201609-I/en>.
[ITU-E212]国際電気通信連合、「公共ネットワークとサブスクリプションの国際識別計画」、ITU-T勧告E.212、2016年9月、<https://www.itu.int/rec/T-REC-E .212-201609-I / en>。
[QUIC-MULTIPATH] Coninck, Q. and O. Bonaventure, "Multipath Extensions for QUIC (MP-QUIC)", Work in Progress, Internet-Draft, draft-deconinck-quic-multipath-04, 5 March 2020, <https://tools.ietf.org/html/draft-deconinck-quic-multipath-04>.
[QUIC-MULTIPATH] Coninck、Q。およびO. Bonaventure、「QUIC（MP-QUIC）のマルチパス拡張機能」、作業中、インターネットドラフト、draft-deconinck-quic-multipath-04、2020年3月5日、<https ：//tools.ietf.org/html/draft-deconinck-quic-multipath-04>。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, <https://www.rfc-editor.org/info/rfc2784>.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Encapsulation（GRE）」、RFC 2784、DOI 10.17487 / RFC2784、2000年3月、<https ：//www.rfc-editor.org/info/rfc2784>。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, DOI 10.17487/RFC2890, September 2000, <https://www.rfc-editor.org/info/rfc2890>.
[RFC2890] Dommety、G。、「GREのキーとシーケンス番号の拡張」、RFC 2890、DOI 10.17487 / RFC2890、2000年9月、<https://www.rfc-editor.org/info/rfc2890>。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, DOI 10.17487/RFC3948, January 2005, <https://www.rfc-editor.org/info/rfc3948>.
[RFC3948] Huttunen、A.、Swander、B.、Volpe、V.、DiBurro、L。、およびM. Stenberg、「IPsec ESPパケットのUDPカプセル化」、RFC 3948、DOI 10.17487 / RFC3948、2005年1月、<https ：//www.rfc-editor.org/info/rfc3948>。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, <https://www.rfc-editor.org/info/rfc4555>.
[RFC4555] Eronen、P。、「IKEv2 Mobility and Multihoming Protocol（MOBIKE）」、RFC 4555、DOI 10.17487 / RFC4555、2006年6月、<https://www.rfc-editor.org/info/rfc4555>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、Ed。、「Stream Control Transmission Protocol」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<https://www.rfc-editor.org/info/rfc4960>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https://www.rfc-editor.org/info/rfc6347>。
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, <https://www.rfc-editor.org/info/rfc6455>.
[RFC6455] Fette、I。およびA. Melnikov、「The WebSocket Protocol」、RFC 6455、DOI 10.17487 / RFC6455、2011年12月、<https://www.rfc-editor.org/info/rfc6455>。
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, <https://www.rfc-editor.org/info/rfc6824>.
[RFC6824] Ford、A.、Raiciu、C.、Handley、M。、およびO. Bonaventure、「複数のアドレスを使用したマルチパス操作のためのTCP拡張機能」、RFC 6824、DOI 10.17487 / RFC6824、2013年1月、<https：// www.rfc-editor.org/info/rfc6824>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231 >。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P。、およびT. Kivinen、「Internet Key Exchange Protocol Version 2（IKEv2）」、STD 79、RFC 7296、DOI 10.17487 / RFC7296 、2014年10月、<https://www.rfc-editor.org/info/rfc7296>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259]ブレイ、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<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>.
[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。
[SCFTECH5G] Small Cell Forum, "Small Cell Forum", <https://scf.io/>.
[SCFTECH5G]スモールセルフォーラム、「スモールセルフォーラム」、<https://scf.io/>。
[ServDesc3GPP] 3rd Generation Partnership Project, "General Packet Radio Service (GPRS); Service description; Stage 2", 3GPP TS 23.060 version 16.0.0, Technical Specification Group Services and System Aspects, March 2019, <https://www.3gpp.org/ftp/Specs/ archive/23_series/23.060/23060-g00.zip>.
[ServDesc3GPP] 3rd Generation Partnership Project、「General Packet Radio Service（GPRS）; Service description; Stage 2」、3GPP TS 23.060 version 16.0.0、Technical Specification Group Services and System Aspects、2019年3月、<https：// www。 3gpp.org/ftp/Specs/archive/23_series/23.060/23060-g00.zip>。
[TCPM-CONVERTERS] Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S., and B. Hesmans, "0-RTT TCP Convert Protocol", Work in Progress, Internet-Draft, draft-ietf-tcpm-converters-19, 22 March 2020, <https://tools.ietf.org/html/draft-ietf-tcpm-converters-19>.
[TCPM-CONVERTERS] Bonaventure、O.、Boucadair、M.、Gundavelli、S.、Seo、S。、およびB. Hesmans、「0-RTT TCP Convert Protocol」、Work in Progress、Internet-Draft、draft-ietf -tcpm-converters-19、2020年3月22日、<https://tools.ietf.org/html/draft-ietf-tcpm-converters-19>。
[WBAUnl5G] Wireless Broadband Alliance, "Unlicensed Integration with 5G Networks", <https://wballiance.com/resource/unlicensed-integration-with-5g-networks/>.
[WBAUnl5G]ワイヤレスブロードバンドアライアンス、「5Gネットワークとの無許可の統合」、<https://wballiance.com/resource/unlicensed-integration-with-5g-networks/>。
This appendix is informative, and provides indicative information about how MAMS operates.
この付録は参考情報であり、MAMSの動作に関する情報を提供します。
If the connection between the CCM and the NCM over which the MAMS control-plane messages are transported is assumed to be secure, UDP is used as the transport for management and control messages between the NCM and the CCM (see Figure 23).
CMSとMAMSコントロールプレーンメッセージが転送されるNCM間の接続が安全であると想定される場合、UDPはNCMとCCM間の管理および制御メッセージの転送として使用されます（図23を参照）。
+-------------------------------------------------+
| Multi-Access (MX) Control Message |
|-------------------------------------------------|
| UDP |
|-------------------------------------------------|
Figure 23: UDP-Based MAMS Control-Plane Protocol Stack
図23：UDPベースのMAMSコントロールプレーンプロトコルスタック
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.
この付録では、MAMSアプリケーションインターフェイスについて説明します。 MAMSフレームワークまたはプロトコルの定義に関する規範的なテキストは提供しませんが、MAMSフレームワークに基づくシステムを構築するために使用できる追加情報を提供します。
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.
CCMは、アプリケーションが通信してサービスを要求するためのHTTPSサーバーをホストします。このドキュメントでは、セキュリティの観点から、すべてのCCMと通信するアプリケーションインスタンスが単一の管理ドメインでホストされていることを前提としています。
The content of messages is described in JavaScript Object Notation (JSON) format. They offer RESTful APIs for communication.
メッセージの内容は、JavaScript Object Notation（JSON）形式で記述されます。通信用のRESTful APIを提供します。
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.
アプリケーションがCCMのエンドポイントをどのように認識するかに関する正確なメカニズムは、このドキュメントの範囲外です。このメカニズムは、代わりにアプリケーション設定の一部として提供されます。
The documentation of APIs is provided in the OpenAPI format, using Swagger v2.0. See Appendix D.
APIのドキュメントは、Swagger v2.0を使用して、OpenAPI形式で提供されます。付録Dを参照してください。
For every API, there could be an error response if the objective of the API could not be met; see [RFC7231].
すべてのAPIについて、APIの目的を達成できなかった場合、エラー応答が発生する可能性があります。 [RFC7231]を参照してください。
The following subsections describe the APIs exposed by the CCM to the applications.
以下のサブセクションでは、CCMによってアプリケーションに公開されるAPIについて説明します。
The CCM provides an HTTPS GET interface as "/ccm/v1.0/capabilities" for the application to query the capabilities supported by the CCM instance.
CCMは、アプリケーションがCCMインスタンスでサポートされている機能を照会するための「/ccm/v1.0/capabilities」としてHTTPS GETインターフェイスを提供します。
+---------+ +-----------+
| | | |
| App |--------- HTTPS GET / Capabilities -------->| CCM |
| | | |
+---------+ +-----------+
Figure 24: CCM API - GET Procedures
図24：CCM API-GETプロシージャ
The CCM shall provide information regarding its capabilities as follows:
CCMは、その機能に関する情報を次のように提供します。
* Supported Features: One or more of the "Feature Name" values, as defined in the MX Feature Activation List parameter of the MX Capability Request (Appendix C.2.5).
* サポートされる機能：MX機能要求（付録C.2.5）のMX機能アクティベーションリストパラメーターで定義されている1つ以上の「機能名」値。
* Supported Connections: Supported connection types and connection IDs.
* サポートされる接続：サポートされる接続タイプと接続ID。
* Supported MX Adaptation Layers: List of MX Adaptation Layer protocols supported by the N-MADP instance, along with the connection types where these are supported and their respective parameters.
* サポートされているMXアダプテーションレイヤー：N-MADPインスタンスでサポートされているMXアダプテーションレイヤープロトコルのリスト、およびそれらがサポートされている接続タイプとそれぞれのパラメーター。
* Supported MX Convergence Layers: List of supported MX Convergence Layer protocols, along with the parameters associated with the respective convergence technique.
* サポートされているMXコンバージェンスレイヤー：サポートされているMXコンバージェンスレイヤープロトコルのリストと、それぞれのコンバージェンス手法に関連するパラメーター。
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.
CCMは、アプリケーションがアプリケーションデータストリームのニーズをCCMインスタンスにポストするための「/ccm/v1.0/ app_requirements」としてHTTPS POSTインターフェイスを提供します。
+---------+ +-----------+
| | | |
| App |-------- HTTPS POST / App Requirements ---->| CCM |
| | | |
+---------+ +-----------+
Figure 25: CCM API - POST Procedures
図25：CCM API-POST手順
The CCM shall provide for the application to post the following requirements for its different data streams:
CCMは、さまざまなデータストリームについて次の要件をポストするアプリケーションを提供します。
* Number of Data Stream Types.
* データストリームタイプの数。
* For each data stream type, specify the following parameters for the link, which are preferred by the application:
* データストリームタイプごとに、アプリケーションが推奨するリンクの次のパラメータを指定します。
- Protocol Type: Transport-layer protocol associated with the application data stream packets.
- プロトコルタイプ：アプリケーションデータストリームパケットに関連付けられたトランスポート層プロトコル。
- Port Range: Supported connection types and connection IDs.
- ポート範囲：サポートされる接続タイプと接続ID。
- Traffic QoS: Quality of service parameters, as follows:
- トラフィックQoS：次のようなQoSパラメータ。
o Bandwidth
o 帯域幅
o Latency
o 待ち時間
o Jitter
o ジッタ
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.
CCMは、アプリケーションがCCMインスタンスから予測リンクパラメータを取得するためのHTTPS GETインターフェイスを「/ccm/v1.0/ predictive_link_params」として提供します。
+---------+ +-----------+
| | | |
| App |----- HTTPS GET / Predictive Link Params --->| CCM |
| | | |
+---------+ +-----------+
Figure 26: CCM API - Getting Predictive Link Parameters
図26：CCM API-予測リンクパラメーターの取得
The CCM asks the NCM for link parameters via the MAMS Network Analytics Request Procedure (Section 8.12) and includes the information in response to the API invocation.
CCMは、MAMSネットワーク分析要求手順（セクション8.12）を介してNCMにリンクパラメーターを要求し、API呼び出しへの応答として情報を含めます。
* Number of Delivery Connections.
* 配信接続の数。
For each delivery connection, include the following:
配信接続ごとに、以下を含めます。
- Access Link Identifier:
- アクセスリンク識別子：
o Connection Type
o 接続タイプ
o Connection ID
o 接続ID
- Link Quality Indicator
- リンク品質インジケータ
o Bandwidth:
o 帯域幅：
+ Predicted Value (Mbps)
+ 予測値（Mbps）
+ Likelihood (percent)
+ 可能性（パーセント）
+ Prediction Validity (Validity Time, in seconds)
+ 予測有効性（有効時間、秒単位）
o Jitter:
o ジッタ：
+ Predicted Value (in seconds)
+ 予測値（秒）
+ Likelihood (percent)
+ 可能性（パーセント）
+ Prediction Validity (Validity Time, in seconds)
+ 予測有効性（有効時間、秒単位）
o Latency:
o 待ち時間：
+ Predicted Value (in seconds)
+ 予測値（秒）
+ Likelihood (percent)
+ 可能性（パーセント）
+ Prediction Validity (Validity Time, in seconds)
+ 予測有効性（有効時間、秒単位）
o Signal Quality
o 信号品質
+ If delivery connection type is LTE, LTE_RSRP Predicted Value (dBm)
+ 配信接続タイプがLTEの場合、LTE_RSRP予測値（dBm）
+ If delivery connection type is LTE, LTE_RSRQ Predicted Value (dBm)
+ 配信接続タイプがLTEの場合、LTE_RSRQ予測値（dBm）
+ If delivery connection type is 5G NR, NR_RSRP Predicted Value (dBm)
+ 配信接続タイプが5G NRの場合、NR_RSRP予測値（dBm）
+ If delivery connection type is 5G NR, NR_RSRQ Predicted Value (dBm)
+ 配信接続タイプが5G NRの場合、NR_RSRQ予測値（dBm）
+ If delivery connection type is Wi-Fi, WLAN_RSSI Predicted Value (dBm)
+ 配信接続タイプがWi-Fiの場合、WLAN_RSSI予測値（dBm）
+ Likelihood (percent)
+ 可能性（パーセント）
+ Prediction Validity (Validity Time, in seconds)
+ 予測有効性（有効時間、秒単位）
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 [RFC8259].
MAMSコントロールプレーンメッセージは、CCMとNCMの間で交換されます。この非規範的な付録では、JSON [RFC8259]を使用したメッセージの形式と内容について説明しています。
This document uses JSONString, JSONNumber, and JSONBool to indicate the JSON string, number, and boolean types, respectively.
このドキュメントでは、JSONString、JSONNumber、JSONBoolを使用して、それぞれJSON文字列、数値、ブール型を示します。
This document uses an adaptation of the C-style struct notation to describe JSON objects. A JSON object consists of name/value pairs. This document refers to each pair as a field. In some contexts, this document also refers to a field as an attribute. The name of a field/attribute may be referred to as the key. An optional field is enclosed by "[ ]". In the definitions, the JSON names of the fields are case sensitive. An array is indicated by two numbers in angle brackets, <m..n>, where m indicates the minimal number of values and n is the maximum. When this document uses * for n, it means no upper bound.
このドキュメントでは、Cスタイルの構造体表記の改作を使用して、JSONオブジェクトを説明します。 JSONオブジェクトは、名前と値のペアで構成されます。このドキュメントでは、各ペアをフィールドと呼びます。一部のコンテキストでは、このドキュメントではフィールドを属性と呼びます。フィールド/属性の名前はキーと呼ばれることがあります。オプションのフィールドは「[]」で囲みます。定義では、フィールドのJSON名は大文字と小文字が区別されます。配列は山かっこで囲まれた2つの数値<m..n>で示されます。mは最小値を示し、nは最大値です。このドキュメントでnに*を使用している場合、上限がないことを意味します。
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.
たとえば、以下のテキストは新しいタイプType4を説明しており、それぞれ「name1」、「name2」、「name3」の3つのフィールドがあります。 「name3」フィールドはオプションであり、「name2」フィールドは少なくとも1つの値の配列です。
object { Type1 name1; Type2 name2 <1..*>; [Type3 name3;] } Type4;
This document uses subtyping to denote that one type is derived from another type. The example below denotes that TypeDerived is derived from TypeBase. TypeDerived includes all fields defined in TypeBase. If TypeBase does not have a "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).
このドキュメントでは、サブタイプを使用して、あるタイプが別のタイプから派生していることを示しています。以下の例は、TypeDerivedがTypeBaseから派生していることを示しています。 TypeDerivedには、TypeBaseで定義されたすべてのフィールドが含まれます。 TypeBaseに「name1」フィールドがない場合、TypeDerivedには「name1」という新しいフィールドがあります。 TypeBaseにすでに「name1」というフィールドがあるが、タイプが異なる場合、TypeDerivedには、TypeDerivedで定義されたタイプ（例ではType1）の「name1」というフィールドがあります。
object { Type1 name1; } TypeDerived : TypeBase;
Note that, despite the notation, no standard, machine-readable interface definition or schema is provided in this document. Extension documents may describe these as necessary.
表記にかかわらず、このドキュメントでは標準の機械可読なインターフェース定義またはスキーマは提供されていないことに注意してください。拡張ドキュメントでは、必要に応じてこれらについて説明します。
For compatibility with publishing requirements, line breaks have been inserted inside long JSON strings, with the following continuation lines indented. To form the valid JSON example, any line breaks inside a string must be replaced with a space and any other white space after the line break removed.
公開要件との互換性のために、長いJSON文字列内に改行が挿入され、次の継続行がインデントされています。有効なJSONの例を形成するには、文字列内の改行をスペースと他の空白で置き換え、改行を削除する必要があります。
This message is the first message sent by the CCM to discover the presence of NCM in the network. It contains only the base information as described in Appendix C.2.1 with message_type set as mx_discover.
このメッセージは、ネットワーク内のNCMの存在を発見するためにCCMによって送信される最初のメッセージです。付録C.2.1で説明されているように、message_typeがmx_discoverとして設定されている基本情報のみが含まれています。
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
[JSONString MCC_MNC_Tuple;]
} MXDiscover : MXBase;
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 (Appendix C.2.1), it contains the following information:
このメッセージは、NCMがCMSに送信され、NCMがMAMS機能をサポートしていることをエンドポイントに通知します。基本情報（付録C.2.1）に加えて、次の情報が含まれています。
(a) NCM Connections (Appendix C.2.3).
（a）NCM接続（付録C.2.3）。
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
NCMConnections ncm_connections;
} MXSystemInfo : MXBase;
This message is sent by the CCM to the NCM to indicate the capabilities of the CCM instance available to the NCM indicated in the System Info message earlier. In addition to the base information (Appendix C.2.1), it contains the following information:
このメッセージはCCMからNCMに送信され、以前にシステム情報メッセージで示されたNCMが使用できるCCMインスタンスの機能を示します。基本情報（付録C.2.1）に加えて、次の情報が含まれています。
(a) Features and their activation status: See Appendix C.2.5.
（a）機能とそのアクティブ化ステータス：付録C.2.5を参照してください。
(b) Number of Anchor Connections: The number of anchor connections (toward the core) supported by the NCM.
（b）アンカー接続の数：NCMでサポートされている（コアへの）アンカー接続の数。
(c) Anchor connections: See Appendix C.2.6.
（c）アンカー接続：付録C.2.6を参照してください。
(d) Number of Delivery Connections: The number of delivery connections (toward the access) supported by the NCM.
（d）配信接続の数：NCMでサポートされている（アクセスに向かう）配信接続の数。
(e) Delivery connections: See Appendix C.2.7.
（e）配信接続：付録C.2.7を参照してください。
(f) Convergence methods: See Appendix C.2.9.
（f）収束方法：付録C.2.9を参照してください。
(g) Adaptation methods: See Appendix C.2.10.
（g）適応方法：付録C.2.10を参照してください。
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
FeaturesActive feature_active;
JSONNumber num_anchor_connections;
AnchorConnections anchor_connections;
JSONNumber num_delivery_connections;
DeliveryConnections delivery_connections;
ConvergenceMethods convergence_methods;
AdaptationMethods adaptation_methods
} MXCapabilityReq : MXBase;
This message is sent by the NCM to the CCM to indicate the capabilities of the NCM instance and unique session identifier for the CCM. In addition to the base information (Appendix C.2.1), it contains the following information:
このメッセージはNCMからCCMに送信され、NCMインスタンスの機能とCCMの一意のセッション識別子を示します。基本情報（付録C.2.1）に加えて、次の情報が含まれています。
(a) Features and their activation status: See Appendix C.2.5.
（a）機能とそのアクティブ化ステータス：付録C.2.5を参照してください。
(b) Number of Anchor Connections: The number of anchor connections (toward the core) supported by the NCM.
（b）アンカー接続の数：NCMでサポートされている（コアへの）アンカー接続の数。
(c) Anchor connections: See Appendix C.2.6.
（c）アンカー接続：付録C.2.6を参照してください。
(d) Number of Delivery Connections: The number of delivery connections (toward the access) supported by the NCM.
（d）配信接続の数：NCMでサポートされている（アクセスに向かう）配信接続の数。
(e) Delivery connections: See Appendix C.2.7.
（e）配信接続：付録C.2.7を参照してください。
(f) Convergence methods: See Appendix C.2.9.
（f）収束方法：付録C.2.9を参照してください。
(g) Adaptation methods: See Appendix C.2.10.
（g）適応方法：付録C.2.10を参照してください。
(h) Unique Session ID: This uniquely identifies the session between the CCM and the NCM in a network. See Appendix C.2.2.
（h）一意のセッションID：これは、ネットワーク内のCCMとNCM間のセッションを一意に識別します。付録C.2.2を参照してください。
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
FeaturesActive feature_active;
JSONNumber num_anchor_connections;
AnchorConnections anchor_connections;
JSONNumber num_delivery_connections;
DeliveryConnections delivery_connections;
ConvergenceMethods convergence_methods;
AdaptationMethods adaptation_methods
UniqueSessionId unique_session_id;
} MXCapabilityRsp : MXBase;
This message is sent by the CCM to the NCM to indicate acceptance of capabilities advertised by the NCM in an earlier MX Capability Response message. In addition to the base information (Appendix C.2.1), it contains the following information:
このメッセージは、CCMからNCMに送信され、以前のMX機能応答メッセージでNCMによってアドバタイズされた機能の受け入れを示します。基本情報（付録C.2.1）に加えて、次の情報が含まれています。
(a) Unique Session ID: Same identifier as the identifier provided in the MX Capability Response. See Appendix C.2.2.
（a）一意のセッションID：MX機能応答で提供される識別子と同じ識別子。付録C.2.2を参照してください。
(b) Capability Acknowledgment: Indicates either acceptance or rejection of the capabilities sent by the CCM. Can use either "MX_ACCEPT" or "MX_REJECT" as acceptable values.
（b）機能確認：CCMによって送信された機能の受け入れまたは拒否を示します。許容値として「MX_ACCEPT」または「MX_REJECT」を使用できます。
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
UniqueSessionId unique_session_id;
JSONString capability_ack;
} MXCapabilityAck : MXBase;
This message is sent by the NCM to the CCM to configure the user plane for MAMS. In addition to the base information (Appendix C.2.1), it contains the following information:
このメッセージは、MAMSのユーザープレーンを構成するためにNCMからCCMに送信されます。基本情報（付録C.2.1）に加えて、次の情報が含まれています。
(a) Number of Anchor Connections: The number of anchor connections supported by the NCM.
（a）アンカー接続の数：NCMでサポートされているアンカー接続の数。
(b) Setup of anchor connections: See Appendix C.2.11.
（b）アンカー接続のセットアップ：付録C.2.11を参照してください。
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
JSONNumber num_anchor_connections;
SetupAnchorConns anchor_connections;
} MXUPSetupConfigReq : MXBase;
This message is the confirmation of the user-plane setup message sent from the CCM after successfully configuring the user plane on the client. This message contains the following information:
このメッセージは、クライアントでユーザープレーンを正常に構成した後にCCMから送信されたユーザープレーンセットアップメッセージの確認です。このメッセージには、次の情報が含まれています。
(a) Unique Session ID: Same identifier as the identifier provided in the MX Capability Response. See Appendix C.2.2.
（a）一意のセッションID：MX機能応答で提供される識別子と同じ識別子。付録C.2.2を参照してください。
(b) MX probe parameters (included if probing is supported).
（b）MXプローブパラメータ（プローブがサポートされている場合に含まれます）。
(1) Probe Port: UDP port for accepting probe message.
（1）プローブポート：プローブメッセージを受け入れるためのUDPポート。
(2) Anchor connection ID: Identifier of the anchor connection to be used for probe function. Provided in the MX UP Setup Configuration Request.
（2）アンカー接続ID：プローブ機能に使用されるアンカー接続の識別子。 MX UPセットアップ構成要求で提供されます。
(3) MX Configuration ID: This parameter is included only if the MX Configuration ID parameter is available from the user-plane setup configuration. It indicates the MX configuration ID of the anchor connection to be used for probe function.
（3）MX構成ID：このパラメーターは、MX構成IDパラメーターがユーザープレーンセットアップ構成から利用可能な場合にのみ含まれます。プローブ機能に使用されるアンカー接続のMX構成IDを示します。
(c) The following information is required for each delivery connection:
（c）配信接続ごとに次の情報が必要です。
(1) Connection ID: Delivery connection ID supported by the client.
（1）接続ID：クライアントがサポートする配信接続ID。
(2) Client Adaptation-Layer Parameters: If the UDP Adaptation Layer is in use, then the UDP port to be used on the C-MADP side.
（2）クライアント適応層パラメーター：UDP適応層が使用されている場合、C-MADP側で使用されるUDPポート。
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
UniqueSessionId unique_session_id;
[ProbeParam probe_param;]
JSONNumber num_delivery_conn;
ClientParam client_params <1...*>;
} MXUPSetupConfigCnf : MXBase;
Where ProbeParam is defined as follows:
ここで、ProbeParamは次のように定義されています。
object {
JSONNumber probe_port;
JSONNumber anchor_conn_id;
[JSONNumber mx_configuration_id;]
} ProbeParam;
Where ClientParam is defined as follows:
ここで、ClientParamは次のように定義されています。
object {
JSONNumber connection_id;
[AdaptationParam adapt_param;]
} ClientParam;
Where AdaptationParam is defined as follows:
AdaptationParamは次のように定義されています。
object {
JSONNumber udp_adapt_port;
} AdaptationParam;
This message is sent by the CCM to the NCM in the case of reconfiguration of any of the connections from the client's side. In addition to the base information (Appendix C.2.1), it contains the following information:
このメッセージは、クライアント側からの接続が再構成された場合に、CCMからNCMに送信されます。基本情報（付録C.2.1）に加えて、次の情報が含まれています。
(a) Unique Session ID: Identifier for the CCM-NCM association Appendix C.2.2.
（a）一意のセッションID：CCM-NCM関連付けの識別子付録C.2.2。
(b) Reconfiguration Action: The reconfiguration action type can be one of "setup", "release", or "update".
（b）再構成アクション：再構成アクションのタイプは、「セットアップ」、「リリース」、または「更新」のいずれかです。
(c) Connection ID: Connection ID for which the reconfiguration is taking place.
（c）接続ID：再構成が行われている接続ID。
(d) IP address: Included if Reconfiguration Action is either "setup" or "update".
（d）IPアドレス：Reconfiguration Actionが「setup」または「update」の場合に含まれます。
(e) SSID: If the connection type is Wi-Fi, then this parameter contains the SSID to which the client has attached.
（e）SSID：接続タイプがWi-Fiの場合、このパラメーターにはクライアントが接続しているSSIDが含まれます。
(f) MTU of the connection: The MTU of the delivery path that is calculated at the client for use by the NCM to configure fragmentation and concatenation procedures at the N-MADP.
（f）接続のMTU：N-MADPでフラグメンテーションおよび連結手順を構成するためにNCMが使用するためにクライアントで計算される配信パスのMTU。
(g) Connection Status: This parameter indicates whether the connection is currently "disabled", "enabled", or "connected". Default: "connected".
（g）接続ステータス：このパラメータは、接続が現在「無効」、「有効」、または「接続」のいずれであるかを示します。デフォルト：「接続済み」。
(h) Delivery Node ID: Identity of the node to which the client is attached. In the case of LTE, this is an ECGI. In the case of Wi-Fi, this is an AP ID or a MAC address.
（h）配信ノードID：クライアントが接続されているノードのID。 LTEの場合、これはECGIです。 Wi-Fiの場合、これはAP IDまたはMACアドレスです。
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
UniqueSessionId unique_session_id;
JSONString reconf_action;
JSONNumber connection_id;
JSONString ip_address;
JSONString ssid;
JSONNumber mtu_size;
JSONString connection_status;
[JSONString delivery_node_id;]
} MXReconfReq : MXBase;
This message is sent by the NCM to the CCM as a confirmation of the received MX Reconfiguration Request and contains only the base information (as defined in Appendix C.2.1).
このメッセージは、受信したMX再構成要求の確認としてNCMからCCMに送信され、基本情報（付録C.2.1で定義）のみが含まれます。
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
} MXReconfRsp : MXBase;
This message is sent by the NCM toward the CCM to configure the CCM to send MX Path Estimation Results. In addition to the base information (Appendix C.2.1), it contains the following information:
このメッセージは、NCMからCCMに向けて送信され、MXパス推定結果を送信するようにCCMを構成します。基本情報（付録C.2.1）に加えて、次の情報が含まれています。
(a) Connection ID: ID of the connection for which the path estimation report is required.
（a）接続ID：パス推定レポートが必要な接続のID。
(b) Init Probe Test Duration: Duration of initial probe test, in milliseconds.
（b）初期プローブテスト期間：初期プローブテストの期間（ミリ秒単位）。
(c) Init Probe Test Rate: Initial testing rate, in megabits per second.
（c）Init Probe Test Rate：メガビット/秒単位の初期テストレート。
(d) Init Probe Size: Size of each packet for initial probe, in bytes.
（d）初期プローブサイズ：初期プローブの各パケットのサイズ（バイト単位）。
(e) Init Probe-ACK: If an acknowledgment for probe is required. (Possible values: "yes", "no")
（e）Init Probe-ACK：プローブの確認が必要な場合。 （可能な値：「はい」、「いいえ」）
(f) Active Probe Frequency: Frequency, in milliseconds, at which the active probes shall be sent.
（f）アクティブプローブ周波数：アクティブプローブが送信される周波数（ミリ秒単位）。
(g) Active Probe Size: Size of the active probe, in bytes.
（g）アクティブプローブサイズ：バイト単位のアクティブプローブのサイズ。
(h) Active Probe Duration: Duration, in seconds, for which the active probe shall be performed.
（h）アクティブプローブ期間：アクティブプローブが実行される期間（秒単位）。
(i) Active Probe-ACK: If an acknowledgment for probe is required. (Possible values: "yes", "no")
（i）Active Probe-ACK：プローブの確認が必要な場合。 （可能な値：「はい」、「いいえ」）
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
JSONNumber connection_id;
JSONNumber init_probe_test_duration_ms;
JSONNumber init_probe_test_rate_Mbps;
JSONNumber init_probe_size_bytes;
JSONString init_probe_ack_req;
JSONNumber active_probe_freq_ms;
JSONNumber active_probe_size_bytes;
JSONNumber active_probe_duration_sec;
JSONString active_probe_ack_req;
} MXPathEstReq : MXBase;
This message is sent by the CCM to the NCM to report on the probe estimation configured by the NCM. In addition to the base information (Appendix C.2.1), it contains the following information:
このメッセージは、CCMによってNCMに送信され、NCMによって構成されたプローブ推定についてレポートします。基本情報（付録C.2.1）に加えて、次の情報が含まれています。
(a) Unique Session ID: Same identifier as the identifier provided in the MX Capability Response. See Appendix C.2.2.
（a）一意のセッションID：MX機能応答で提供される識別子と同じ識別子。付録C.2.2を参照してください。
(b) Connection ID: ID of the connection for which the MX Path Estimation Results message is required.
（b）接続ID：MXパス推定結果メッセージが必要な接続のID。
(c) Init Probe Results: See Appendix C.2.12.
（c）Initプローブの結果：付録C.2.12を参照してください。
(d) Active Probe Results: See Appendix C.2.13.
（d）アクティブプローブの結果：付録C.2.13を参照してください。
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
JSONNumber connection_id;
UniqueSessionId unique_session_id;
[InitProbeResults init_probe_results;]
[ActiveProbeResults active_probe_results;]
} MXPathEstResults : MXBase;
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 (Appendix C.2.1), it contains the following information:
このメッセージはNCMからCCMに送信され、アップリンクおよびダウンリンク構成で配信側のトラフィックステアリングを有効にします。基本情報（付録C.2.1）に加えて、次の情報が含まれています。
(a) Connection ID: Anchor connection number for which the traffic steering is being defined.
（a）接続ID：トラフィックステアリングが定義されているアンカー接続番号。
(b) MX Configuration ID: MX configuration for which the traffic steering is being defined.
（b）MX構成ID：トラフィックステアリングが定義されているMX構成。
(c) Downlink Delivery: See Appendix C.2.14.
（c）ダウンリンク配信：付録C.2.14を参照してください。
(d) Default UL Delivery: The default delivery connection for the uplink. All traffic should be delivered on this connection in the uplink direction, and the Traffic Flow Template (TFT) filter should be applied only for the traffic mentioned in Uplink Delivery.
（d）デフォルトのUL配信：アップリンクのデフォルトの配信接続。すべてのトラフィックはこの接続でアップリンク方向に配信される必要があり、トラフィックフローテンプレート（TFT）フィルターはアップリンク配信で説明されているトラフィックにのみ適用される必要があります。
(e) Uplink Delivery: See Appendix C.2.15.
(e) Uplink Delivery: See Appendix C.2.15.
(f) Features and their activation status: See Appendix C.2.5.
（f）機能とそのアクティブ化ステータス：付録C.2.5を参照してください。
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
JSONNumber connection_id;
[JSONNumber mx_configuration_id;]
DLDelivery downlink_delivery;
JSONNumber default_uplink_delivery;
ULDelivery uplink_delivery;
FeaturesActive feature_active;
} MXTrafficSteeringReq : MXBase;
This message is a response to an MX Traffic Steering Request from the CCM to the NCM. In addition to the base information (Appendix C.2.1), it contains the following information:
このメッセージは、CCMからNCMへのMXトラフィックステアリングリクエストへの応答です。基本情報（付録C.2.1）に加えて、次の情報が含まれています。
(a) Unique Session ID: Same identifier as the identifier provided in the MX Capability Response. See Appendix C.2.2.
（a）一意のセッションID：MX機能応答で提供される識別子と同じ識別子。付録C.2.2を参照してください。
(b) Features and their activation status: See Appendix C.2.5.
（b）機能とそのアクティブ化ステータス：付録C.2.5を参照してください。
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
UniqueSessionId unique_session_id;
FeaturesActive feature_active;
} MXTrafficSteeringResp : MXBase;
This message is sent by the CCM to the NCM to select MADP instances provided earlier in the MX UP Setup Configuration Request, based on requirements for the applications.
このメッセージは、CCMからNCMに送信され、アプリケーションの要件に基づいて、MX UPセットアップ構成リクエストで以前に提供されたMADPインスタンスを選択します。
In addition to the base information (Appendix C.2.1), it contains the following:
基本情報（付録C.2.1）に加えて、以下が含まれます。
(a) Unique Session ID: This uniquely identifies the session between the CCM and the NCM in a network. See Appendix C.2.2.
（a）一意のセッションID：ネットワーク内のCCMとNCM間のセッションを一意に識別します。付録C.2.2を参照してください。
(b) A list of MX Application MADP Associations, with each entry as follows:
（b）MXアプリケーションMADPアソシエーションのリスト。各エントリは次のとおりです。
(1) Connection ID: Represents the anchor connection number of the MADP instance.
（1）接続ID：MADPインスタンスのアンカー接続番号を表します。
(2) MX Configuration ID: Identifies the MX configuration of the MADP instance.
（2）MX構成ID：MADPインスタンスのMX構成を識別します。
(3) Traffic Flow Template Uplink: Traffic Flow Template, as defined in Appendix C.2.16, to be used in the uplink direction.
（3）トラフィックフローテンプレートアップリンク：付録C.2.16で定義されている、アップリンク方向で使用されるトラフィックフローテンプレート。
(4) Traffic Flow Template Downlink: Traffic Flow Template, as defined in Appendix C.2.16, to be used in the downlink direction.
（4）トラフィックフローテンプレートダウンリンク：付録C.2.16で定義されている、ダウンリンク方向で使用されるトラフィックフローテンプレート。
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
UniqueSessionId unique_session_id;
MXAppMADPAssoc app_madp_assoc_list <1..*>;
} MXAppMADPAssocReq : MXBase;
Where each measurement MXAppMADPAssoc is represented by the following:
各測定MXAppMADPAssocは次のように表されます。
object {
JSONNumber connection_id;
JSONNumber mx_configuration_id
TrafficFlowTemplate tft_ul_list <1..*>;
TrafficFlowTemplate tft_dl_list <1..*>;
} MXAppMADPAssoc;
This message is sent by the NCM to the CCM to confirm the selected MADP instances provided in the MX Application MADP Association Request by the CCM.
このメッセージは、NCMからCCMに送信され、CCMによってMXアプリケーションMADPアソシエーションリクエストで提供された選択されたMADPインスタンスを確認します。
In addition to the base information (Appendix C.2.1), it contains information if the request has been successful.
基本情報（付録C.2.1）に加えて、要求が成功したかどうかの情報が含まれます。
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
JSONBool is_success;
} MXAppMADPAssocResp : MXBase;
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.
このメッセージはNCMからCCMに送信され、ネットワーク側のMAMSエンティティによってサポートされる許可されたSSIDのリストを示します。 SSIDのリストが含まれています。
Each SSID consists of the type of SSID (which can be one of the following: SSID, BSSID, or HESSID) and the SSID itself.
各SSIDは、SSIDのタイプ（SSID、BSSID、またはHESSIDのいずれかです）とSSID自体で構成されます。
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
SSID ssid_list <1..*>;
} MXSSIDIndication : MXBase;
Where each SSID is defined as follows:
各SSIDは次のように定義されています。
object {
JSONString ssid_type;
JSONString ssid;
} SSID;
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:
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:
(a) Connection ID: Connection ID of the delivery connection for which the reporting is being configured.
（a）接続ID：レポートが構成されている配信接続の接続ID。
(b) Connection Type: Connection type for which the reporting is being configured. Can be "LTE", "Wi-Fi", "5G_NR".
（b）接続タイプ：レポートが構成されている接続タイプ。 「LTE」、「Wi-Fi」、「5G_NR」のいずれかです。
(c) Measurement Report Configuration: Actual report configuration based on the Connection Type, as defined in Appendix C.2.17.
（c）測定レポート構成：付録C.2.17で定義されている、接続タイプに基づく実際のレポート構成。
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
MeasReportConf measurement_configuration <1..*>;
} MXMeasReportConf : MXBase;
Where each measurement MeasReportConf is represented by the following:
各測定MeasReportConfは次のように表されます。
object {
JSONNumber connection_id;
JSONString connection_type;
MeasReportConfs meas_rep_conf <1..*>;
} MeasReportConf;
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:
このメッセージは、測定構成後にCCMからNCMに定期的に送信されます。基本情報に加えて、次の情報が含まれています。
(a) Unique Session ID: Same identifier as the identifier provided in the MX Capability Response. Described in Appendix C.2.2.
（a）一意のセッションID：MX機能応答で提供される識別子と同じ識別子。付録C.2.2に記載されています。
(b) Measurement report for each delivery connection is measured by the client as defined in Appendix C.2.18.
（b）各配信接続の測定レポートは、付録C.2.18で定義されているようにクライアントによって測定されます。
The representation of the message is as follows:
The representation of the message is as follows:
object {
UniqueSessionId unique_session_id;
MXMeasRep measurement_reports <1..*>;
} MXMeasurementReport : MXBase;
An MX Keep-Alive Request can be sent from either the NCM or the CCM on expiry of the Keep-Alive timer or a handover event. The peer shall respond to this request with an MX Keep-Alive Response. In the case of no response from the peer, the MAMS connection shall be assumed to be broken, and the CCM shall establish a new connection by sending MX Discover messages.
MXキープアライブ要求は、キープアライブタイマーの終了時またはハンドオーバーイベント時にNCMまたはCCMのいずれかから送信できます。ピアはこの要求にMXキープアライブ応答で応答する必要があります。ピアからの応答がない場合、MAMS接続は切断されていると見なされ、CCMはMX Discoverメッセージを送信して新しい接続を確立します。
In addition to the base information, it contains the following information:
基本情報に加えて、次の情報が含まれています。
(a) Keep-Alive Reason: Reason for sending this message, can be "Timeout" or "Handover".
（a）キープアライブの理由：このメッセージを送信する理由は、「タイムアウト」または「ハンドオーバー」です。
(b) Unique Session ID: Identifier for the CCM-NCM association Appendix C.2.2.
（b）一意のセッションID：CCM-NCM関連付けの識別子付録C.2.2。
(c) Connection ID: Connection ID for which handover is detected, if the reason is "Handover".
（c）接続ID：理由が「ハンドオーバー」の場合に、ハンドオーバーが検出された接続ID。
(d) Delivery Node ID: The target delivery node ID (ECGI or Wi-Fi AP ID/MAC address) to which the handover is executed.
（d）配信ノードID：ハンドオーバーが実行されるターゲット配信ノードID（ECGIまたはWi-Fi AP ID / MACアドレス）。
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
JSONString keep_alive_reason;
UniqueSessionId unique_session_id;
JSONNumber connection_id;
JSONString delivery_node_id;
} MXKeepAliveReq : MXBase;
On receiving an MX Keep-Alive Request from a peer, the NCM/CCM shall immediately respond with an MX Keep-Alive Response on the same delivery path from where the request arrived. In addition to the base information, it contains the unique session identifier for the CCM-NCM association (defined in Appendix C.2.2)
ピアからMXキープアライブ要求を受信すると、NCM / CCMは、要求が到着したところから同じ配信パスでMXキープアライブ応答ですぐに応答します。基本情報に加えて、CCM-NCMアソシエーションの一意のセッション識別子が含まれます（付録C.2.2で定義）。
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
UniqueSessionId unique_session_id;
} MXKeepAliveResp : MXBase;
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".
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".
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
UniqueSessionId unique_session_id;
JSONString reason;
} MXSessionTerminationReq : MXBase;
On receipt of an MX Session Termination Request from a peer, the NCM/ CCM shall respond with MX Session Termination Response on the same delivery path where the request arrived and clean up the MAMS-related resources and settings. The CCM shall reinitiate a new session with MX Discover messages.
ピアからMXセッション終了要求を受信すると、NCM / CCMは、要求が到着したのと同じ配信パスでMXセッション終了応答で応答し、MAMS関連のリソースと設定をクリーンアップします。 CCMはMX Discoverメッセージで新しいセッションを再開します。
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
UniqueSessionId unique_session_id;
} MXSessionTerminationResp : MXBase;
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:
このメッセージはCCMからNCMに送信され、ネットワーク分析機能によって予測された帯域幅、ジッター、遅延、信号品質などのパラメーターを要求します。基本情報に加えて、次のパラメーターが含まれています。
(a) Unique Session ID: Same identifier as the identifier provided in the MX Capability Response. Described in Appendix C.2.2.
（a）一意のセッションID：MX機能応答で提供される識別子と同じ識別子。付録C.2.2に記載されています。
(b) Parameter List: List of parameters in which the CCM is interested: one or more of "bandwidth", "jitter", "latency", and "signal_quality".
（b）パラメーターリスト：CCMが関係するパラメーターのリスト：「帯域幅」、「ジッター」、「待ち時間」、「signal_quality」の1つ以上。
The representation of the message is as follows:
メッセージの表現は次のとおりです。
object {
UniqueSessionId unique_session_id;
JSONString params <1..*>;
} MXNetAnalyticsReq : MXBase;
Where the params object can take one or more of the following values:
paramsオブジェクトは、次の値の1つ以上を取ることができます。
"bandwidth" "jitter" "latency" "signal_quality"
「帯域幅」「ジッター」「待ち時間」「signal_quality」
This message is sent by the NCM to the CCM in response to the MX Network Analytics Request. For each delivery connection that the client has, the NCM reports the requested parameter predictions and their respective likelihoods (between 1 and 100 percent).
このメッセージは、MX Network Analyticsリクエストへの応答としてNCMからCCMに送信されます。 NCMは、クライアントが持つ各配信接続について、要求されたパラメーター予測とそれぞれの可能性（1〜100％）を報告します。
In addition to the base information, it contains the following parameters:
In addition to the base information, it contains the following parameters:
(a) Number of Delivery Connections: The number of delivery connections that are currently configured for the client.
（a）配信接続の数：クライアントに対して現在構成されている配信接続の数。
(b) The following information is provided for each delivery connection:
（b）次の情報は、配信接続ごとに提供されます。
(1) Connection ID: Connection ID of the delivery connection for which the parameters are being predicted.
（1）接続ID：パラメーターが予測されている配信接続の接続ID。
(2) Connection Type: Type of connection. Can be "Wi-Fi", "5G_NR", "MulteFire", or "LTE".
(2) Connection Type: Type of connection. Can be "Wi-Fi", "5G_NR", "MulteFire", or "LTE".
(3) List of Parameters for which Prediction is requested, where each of the predicted parameters consists of the following:
（3）予測が要求されたパラメーターのリスト。予測された各パラメーターは次のもので構成されます。
(a) Parameter Name: Name of the parameter being predicted. Can be one of "bandwidth", "jitter", "latency", or "signal_quality".
（a）パラメータ名：予測されるパラメータの名前。 「bandwidth」、「jitter」、「latency」、または「signal_quality」のいずれかになります。
(b) Additional Parameter: If Parameter name is "signal_quality", then this qualifies the quality parameter like "lte_rsrp", "lte_rsrq", "nr_rsrp", "nr_rsrq", or "wifi_rssi".
(b) Additional Parameter: If Parameter name is "signal_quality", then this qualifies the quality parameter like "lte_rsrp", "lte_rsrq", "nr_rsrp", "nr_rsrq", or "wifi_rssi".
(c) Predicted Value: Provides the predicted value of the parameter and, if applicable, the additional parameter.
(c) Predicted Value: Provides the predicted value of the parameter and, if applicable, the additional parameter.
(d) Likelihood: Provides a stochastic likelihood of the predicted value.
(d) Likelihood: Provides a stochastic likelihood of the predicted value.
(e) Validity Time: The time duration for which the predictions are valid.
（e）有効期間：予測が有効な期間。
The representation of the message is as follows:
The representation of the message is as follows:
object {
MXAnalyticsList param_list <1..*>;
} MXNetAnalyticsResp : MXBase;
Where MXAnalyticsList is defined as follows:
Where MXAnalyticsList is defined as follows:
object {
JSONNumber connection_id;
JSONString connection_type;
ParamPredictions predictions <1..*>;
} MXAnalyticsList;
Where each ParamPredictions item is defined as:
Where each ParamPredictions item is defined as:
object {
JSONString param_name;
[JSONString additional_param;]
JSONNumber prediction;
JSONNumber likelihood;
JSONNumber validity_time;
} ParamPredictions;
This is the base information that every message between the CCM and NCM exchanges shall have as mandatory information. It contains the following information:
これは、CCM交換とNCM交換の間のすべてのメッセージが必須情報として持つ基本情報です。次の情報が含まれています。
(a) Version: Version of MAMS used.
（a）バージョン：使用されるMAMSのバージョン。
(b) Message Type: Message type being sent, where the following are considered valid values:
（b）メッセージタイプ：送信されるメッセージタイプ。以下は有効な値と見なされます。
"mx_discover" "mx_system_info" "mx_capability_req" "mx_capability_rsp" "mx_capability_ack" "mx_up_setup_conf_req" "mx_up_setup_cnf" "mx_reconf_req" "mx_reconf_rsp" "mx_path_est_req" "mx_path_est_results" "mx_traffic_steering_req" "mx_traffic_steering_rsp" "mx_ssid_indication" "mx_keep_alive_req" "mx_keep_alive_rsp" "mx_measurement_conf" "mx_measurement_report" "mx_session_termination_req" "mx_session_termination_rsp" "mx_app_madp_assoc_req" "mx_app_madp_assoc_rsp" "mx_network_analytics_req" "mx_network_analytics_rsp"
"mx_discover" "mx_system_info" "mx_capability_req" "mx_capability_rsp" "mx_capability_ack" "mx_up_setup_conf_req" "mx_up_setup_cnf" "mx_reconf_req" "mx_reconf_rsp" "mx_path_est_req" "mx_path_est_results" "mx_traffic_steering_req" "mx_traffic_steering_rsp" "mx_ssid_indication" "mx_keep_alive_req" "mx_keep_alive_rsp"「mx_measurement_conf "" mx_measurement_report "" mx_session_termination_req "" mx_session_termination_rsp "" mx_app_madp_assoc_req "" mx_app_madp_assoc_rsp "" mx_network_analytics_req "" mx_network_analytics_rsp "
(c) Sequence Number: Sequence number to uniquely identify a particular message exchange, e.g., MX Capability Request/Response/Acknowledge.
（c）シーケンス番号：特定のメッセージ交換を一意に識別するためのシーケンス番号（例：MX機能要求/応答/確認）。
The representation of this data type is as follows:
The representation of this data type is as follows:
object {
JSONString version;
JSONString message_type;
JSONNumber sequence_num;
} MXBase;
This data type represents the unique session ID between a CCM and NCM entity. It contains an NCM ID that is unique in the network and a session ID that is allocated by the NCM for that session. On receipt of the MX Discover message, if the session exists, then the old session ID is returned in the MX System Info message; otherwise, the NCM allocates a new session ID for the CCM and sends the new ID in the MX System Info message.
このデータ型は、CCMとNCMエンティティ間の一意のセッションIDを表します。これには、ネットワーク内で一意のNCM IDと、NCMによってそのセッションに割り当てられたセッションIDが含まれています。 MX Discoverメッセージの受信時に、セッションが存在する場合は、古いセッションIDがMXシステム情報メッセージで返されます。それ以外の場合、NCMはCCMに新しいセッションIDを割り当て、MXシステム情報メッセージで新しいIDを送信します。
The representation of this data type is as follows:
このデータ型の表現は次のとおりです。
object {
JSONNumber ncm_id;
JSONNumber session_id;
} UniqueSessionId;
This data type represents the connection available at the NCM for MAMS connectivity toward the client. It contains a list of NCM connections available, where each connection has the following information:
このデータタイプは、クライアントへのMAMS接続のためにNCMで利用可能な接続を表します。使用可能なNCM接続のリストが含まれ、各接続には次の情報があります。
(a) Connection Information: See Appendix C.2.4.
（a）接続情報：付録C.2.4を参照してください。
(b) NCM Endpoint Information: Contains the IP address and port exposed by the NCM endpoint for the CCM.
（b）NCMエンドポイント情報：CCMのNCMエンドポイントによって公開されたIPアドレスとポートが含まれます。
The representation of this data type is as follows:
このデータ型の表現は次のとおりです。
object {
NCMConnection items <1..*>;
} NCMConnections;
where NCMConnection is defined as:
where NCMConnection is defined as:
object {
NCMEndPoint ncm_end_point;
} NCMConnection : ConnectionInfo;
where NCMEndPoint is defined as:
ここで、NCMEndPointは次のように定義されています。
object {
JSONString ip_address;
JSONNumber port;
} NCMEndPoint;
This data type provides the mapping of connection ID and connection type. It contains the following information:
このデータ型は、接続IDと接続タイプのマッピングを提供します。次の情報が含まれています。
(a) Connection ID: Unique number identifying the connection.
（a）接続ID：接続を識別する一意の番号。
(b) Connection Type: Type of connection can be "Wi-Fi", "5G_NR", "MulteFire", or "LTE".
（b）接続タイプ：接続のタイプは、「Wi-Fi」、「5G_NR」、「MulteFire」、または「LTE」です。
The representation of this data type is as follows:
このデータ型の表現は次のとおりです。
object {
JSONNumber connection_id;
JSONString connection_type;
} ConnectionInfo;
This data type provides the list of all features with their activation status. Each feature status contains the following:
このデータタイプは、すべての機能とそのアクティブ化ステータスのリストを提供します。各機能のステータスには次のものが含まれます。
(a) Feature Name: The name of the feature can be one of the following:
（a）機能名：機能の名前は次のいずれかになります。
"lossless_switching" "fragmentation" "concatenation" "uplink_aggregation" "downlink_aggregation" "measurement"
「lossless_switching」「fragmentation」「concatenation」「uplink_aggregation」「downlink_aggregation」「measurement」
(b) Active status: Activation status of the feature: "true" means that the feature is active, and "false" means that the feature is inactive.
（b）アクティブステータス：機能のアクティブ化ステータス：「true」は機能がアクティブであることを意味し、「false」は機能が非アクティブであることを意味します。
The representation of this data type is as follows:
このデータ型の表現は次のとおりです。
object {
FeatureInfo items <1..*>;
} FeaturesActive;
where FeatureInfo is defined as:
ここで、FeatureInfoは次のように定義されています。
object {
JSONString feature_name;
JSONBool active;
} FeatureInfo;
This data type contains the list of Connection Information items (Appendix C.2.4) that are supported on the anchor (core) side.
このデータ型には、アンカー（コア）側でサポートされる接続情報項目（付録C.2.4）のリストが含まれています。
The representation of this data type is as follows:
このデータ型の表現は次のとおりです。
object {
ConnectionInfo items <1..*>;
} AnchorConnections;
This data type contains the list of Connection Information (Appendix C.2.4) that are supported on the delivery (access) side.
このデータ型には、配信（アクセス）側でサポートされる接続情報（付録C.2.4）のリストが含まれています。
The representation of this data type is as follows:
このデータ型の表現は次のとおりです。
object {
ConnectionInfo items <1..*>;
} DeliveryConnections;
This data type provides the support for a particular convergence or adaptation method. It consists of the following:
This data type provides the support for a particular convergence or adaptation method. It consists of the following:
(a) Method: Name of the method.
（a）メソッド：メソッドの名前。
(b) Supported: Whether the method listed above is supported or not. Possible values are "true" and "false".
（b）サポート：上記の方法がサポートされているかどうか。可能な値は「true」と「false」です。
The representation of this data type is as follows:
このデータ型の表現は次のとおりです。
object {
JSONString method;
JSONBool supported;
} MethodSupport;
This data type contains the list of all convergence methods and their support status. The possible convergence methods are:
このデータ型には、すべての収束方法とそのサポート状況のリストが含まれています。可能な収束方法は次のとおりです。
"GMA" "MPTCP_Proxy" "GRE_Aggregation_Proxy" "MPQUIC"
「GMA」「MPTCP_Proxy」「GRE_Aggregation_Proxy」「MPQUIC」
The representation of this data type is as follows:
このデータ型の表現は次のとおりです。
object {
MethodSupport items <1..*>;
} ConvergenceMethods;
This data type contains the list of all adaptation methods and their support status. The possible adaptation methods are:
このデータ型には、すべての適応方法とそれらのサポート状況のリストが含まれています。可能な適応方法は次のとおりです。
"UDP_without_DTLS" "UDP_with_DTLS" "IPsec" "Client_NAT"
「UDP_without_DTLS」「UDP_with_DTLS」「IPsec」「Client_NAT」
The representation of this data type is as follows:
このデータ型の表現は次のとおりです。
object {
MethodSupport items <1..*>;
} AdaptationMethods;
This data type represents the setup configuration for each anchor connection that is required on the client's side. It contains the following information, in addition to the connection ID and type of the anchor connection:
このデータ型は、クライアント側で必要な各アンカー接続のセットアップ構成を表します。これには、接続IDとアンカー接続のタイプに加えて、以下の情報が含まれています。
(a) Number of Active MX Configurations: If more than one active configuration is present for this anchor, then this identifies the number of such connections.
（a）アクティブなMX構成の数：このアンカーに複数のアクティブな構成が存在する場合は、そのような接続の数を示します。
(b) The following convergence parameters are provided for each active configuration:
（b）次の収束パラメータは、アクティブな構成ごとに提供されます。
(1) MX Configuration ID: Present if there are multiple active configurations. Identifies the configuration for this MADP instance ID.
（1）MX構成ID：アクティブな構成が複数ある場合に存在します。このMADPインスタンスIDの構成を識別します。
(2) Convergence Method: Convergence method selected. Has to be one of the supported convergence methods listed in Appendix C.2.9.
（2）収束方法：選択された収束方法。付録C.2.9にリストされているサポートされている収束方法の1つである必要があります。
(3) Convergence Method Parameters: Described in Appendix C.2.11.1
（3）収束方法パラメーター：付録C.2.11.1に記載
(4) Number of Delivery Connections: The number of delivery connections (access side) that are supported for this anchor connection.
（4）配信接続の数：このアンカー接続でサポートされる配信接続（アクセス側）の数。
(5) Setup of delivery connections: Described in Appendix C.2.11.2.
（5）配信接続のセットアップ：付録C.2.11.2に記載。
The representation of this data type is as follows:
このデータ型の表現は次のとおりです。
object {
SetupAnchorConn items <1..*>;
} SetupAnchorConns;
Where each anchor connection configuration is defined as follows:
各アンカー接続構成は、次のように定義されています。
object {
[JSONNumber num_active_mx_conf;]
ConvergenceConfig convergence_config
} SetupAnchorConn : ConnectionInfo;
where each Convergence configuration is defined as follows:
ここで、各Convergence構成は次のように定義されています。
object {
[JSONNumber mx_configuration_id;]
JSONString convergence_method;
ConvergenceMethodParam convergence_method_params;
JSONNumber num_delivery_connections;
SetupDeliveryConns delivery_connections;
} ConvergenceConfig;
This data type represents the parameters used for the convergence method and contains the following:
このデータ型は、収束方法に使用されるパラメーターを表し、以下を含みます。
(a) Proxy IP: IP address of the proxy that is provided by the selected convergence method.
（a）プロキシIP：選択した収束方法によって提供されるプロキシのIPアドレス。
(b) Proxy Port: Port of the proxy that is provided by the selected convergence method.
(b) Proxy Port: Port of the proxy that is provided by the selected convergence method.
The representation of this data type is as follows:
このデータ型の表現は次のとおりです。
object {
JSONString proxy_ip;
JSONString proxy_port;
JSONString client_key;
} ConvergenceMethodParam;
This is the list of delivery connections and their parameters to be configured on the client. Each delivery connection defined by its connection information (Appendix C.2.4) optionally contains the following:
これは、クライアントで構成する配信接続とそのパラメーターのリストです。接続情報（付録C.2.4）で定義された各配信接続には、オプションで以下が含まれます。
(a) Adaptation Method: Selected adaptation method name. This shall be one of the methods listed in Appendix C.2.10.
（a）適応方法：選択された適応方法名。これは、付録C.2.10にリストされている方法の1つです。
(b) Adaptation Method Parameters: Depending on the adaptation method, one or more of the following parameters shall be provided.
（b）適応方法のパラメータ：適応方法に応じて、以下のパラメータの1つ以上が提供されます。
(1) Tunnel IP address
(1) Tunnel IP address
(2) Tunnel Port number
（2）トンネルポート番号
(3) Shared Secret
（3）共有秘密
(4) MX header optimization: If the adaptation method is UDP_without_DTLS or UDP_with_DTLS, and convergence is GMA, then this flag represents whether or not the checksum field and the length field in the IP header of an MX PDU should be recalculated by the MX Convergence Layer. The possible values are "true" and "false". If it is "true", both fields remain unchanged; otherwise, both fields should be recalculated. If this field is not present, then the default of "false" should be considered.
（4）MXヘッダーの最適化：適応方式がUDP_without_DTLSまたはUDP_with_DTLSで、収束がGMAの場合、このフラグは、MX PDUのIPヘッダーのチェックサムフィールドと長さフィールドをMX収束によって再計算する必要があるかどうかを表します層。可能な値は「true」と「false」です。 「true」の場合、両方のフィールドは変更されません。それ以外の場合は、両方のフィールドを再計算する必要があります。このフィールドが存在しない場合、デフォルトの「false」を検討する必要があります。
The representation of this data type is as follows:
このデータ型の表現は次のとおりです。
object {
SetupDeliveryConn items <1..*>;
} SetupDeliveryConns;
where each "SetupDeliveryConn" consists of the following:
ここで、各「SetupDeliveryConn」は次のもので構成されています。
object {
[JSONString adaptation_method;]
[AdaptationMethodParam adaptation_method_param;]
} SetupDeliveryConn : ConnectionInfo;
where AdaptationMethodParam is defined as:
ここで、AdaptationMethodParamは次のように定義されています。
object {
JSONString tunnel_ip_addr;
JSONString tunnel_end_port;
JSONString shared_secret;
[JSONBool mx_header_optimization;]
} AdaptationMethodParam;
This data type provides the results of the init probe request made by the NCM. It consists of the following information:
This data type provides the results of the init probe request made by the NCM. It consists of the following information:
(a) Lost Probes: Percentage of probes lost.
（a）失われたプローブ：失われたプローブの割合。
(b) Probe Delay: Average delay of probe message, in microseconds.
（b）プローブ遅延：マイクロ秒単位のプローブメッセージの平均遅延。
(c) Probe Rate: Probe rate achieved, in megabits per second.
（c）プローブレート：メガビット/秒単位で達成されたプローブレート。
The representation of this data type is as follows:
このデータ型の表現は次のとおりです。
object {
JSONNumber lost_probes_percentage;
JSONNumber probe_rate_Mbps;
} InitProbeResults;
This data type provides the results of the active probe request made by the NCM. It consists of the following information:
このデータ型は、NCMによって行われたアクティブなプローブ要求の結果を提供します。次の情報で構成されています。
(a) Average Probe Throughput: Average active probe throughput achieved, in megabits per second.
（a）平均プローブスループット：達成された平均アクティブプローブスループット（メガビット/秒）。
The representation of this data type is as follows:
このデータ型の表現は次のとおりです。
object {
JSONNumber avg_tput_last_probe_duration_Mbps;
} ActiveProbeResults;
This data type represents the list of connections that are enabled on the delivery side to be used in the downlink direction.
This data type represents the list of connections that are enabled on the delivery side to be used in the downlink direction.
The representation of this data type is as follows:
このデータ型の表現は次のとおりです。
object {
JSONNumber connection_id <1..*>;
} DLDelivery;
This data type represents the list of connections and parameters enabled for the delivery side to be used in the uplink direction.
このデータタイプは、アップリンク方向で使用される配信側で有効な接続とパラメータのリストを表します。
The uplink delivery consists of multiple uplink delivery entities, where each entity consists of a Traffic Flow Template (TFT) (Appendix C.2.16) and a list of connection IDs in the uplink, where traffic qualifying for such a Traffic Flow Template can be redirected.
アップリンク配信は複数のアップリンク配信エンティティで構成され、各エンティティはトラフィックフローテンプレート（TFT）（付録C.2.16）とアップリンクの接続IDのリストで構成されます。このようなトラフィックフローテンプレートに該当するトラフィックはリダイレクトできます。 。
The representation of this data type is as follows:
このデータ型の表現は次のとおりです。
object {
ULDeliveryEntity ul_del <1..*>;
} ULDelivery;
Where each uplink delivery entity consists of the following data type:
Where each uplink delivery entity consists of the following data type:
object {
TrafficFlowTemplate ul_tft <1..*>;
JSONNumber connection_id <1..*>;
} ULDeliveryEntity;
The Traffic Flow Template generally follows the guidelines specified in [ServDesc3GPP].
トラフィックフローテンプレートは通常、[ServDesc3GPP]で指定されたガイドラインに従います。
The Traffic Flow Template in MAMS consists of one or more of the following:
MAMSのトラフィックフローテンプレートは、次の1つ以上で構成されています。
(a) Remote Address and Mask: IP address and subnet for remote addresses represented in Classless Inter-Domain Routing (CIDR) notation. Default: "0.0.0.0/0".
（a）リモートアドレスとマスク：クラスレスドメイン間ルーティング（CIDR）表記で表されたリモートアドレスのIPアドレスとサブネット。デフォルト： "0.0.0.0/0"。
(b) Local Address and Mask: IP address and subnet for local addresses represented in CIDR notation. Default: "0.0.0.0/0"
（b）ローカルアドレスとマスク：CIDR表記で表されるローカルアドレスのIPアドレスとサブネット。デフォルト： "0.0.0.0/0"
(c) Protocol Type: IP protocol number of the payload being carried by an IP packet (e.g., UDP, TCP). Default: 255.
（c）プロトコルタイプ：IPパケット（UDP、TCPなど）によって伝送されるペイロードのIPプロトコル番号。デフォルト：255。
(d) Local Port Range: Range of ports for local ports for which the Traffic Flow Template is applicable. Default: Start=0, End=65535.
（d）ローカルポート範囲：トラフィックフローテンプレートが適用されるローカルポートのポート範囲。デフォルト：Start = 0、End = 65535。
(e) Remote Port Range: Range of ports for remote ports for which the Traffic Flow Template is applicable. Default: Start=0, End=65535.
(e) Remote Port Range: Range of ports for remote ports for which the Traffic Flow Template is applicable. Default: Start=0, End=65535.
(f) Traffic Class: Represented by Type of Service in IPv4 and Traffic Class in IPv6. Default: 255
（f）トラフィッククラス：IPv4のタイプオブサービスおよびIPv6のトラフィッククラスで表されます。デフォルト：255
(g) Flow Label: Flow label for IPv6, applicable only for IPv6 protocol type. Default: 0.
（g）フローラベル：IPv6のフローラベル。IPv6プロトコルタイプにのみ適用されます。デフォルト：0。
The representation of this data type is as follows:
このデータ型の表現は次のとおりです。
object {
JSONString remote_addr_mask;
JSONString local_addr_mask;
JSONNumber protocol_type;
PortRange local_port_range;
PortRange remote_port_range;
JSONNumber traffic_class;
JSONNumber flow_label;
} TrafficFlowTemplate;
Where the port range is defined as follows:
ポート範囲は次のように定義されています。
object {
JSONNumber start;
JSONNumber end;
} PortRange;
This data type represents the configuration done by the NCM toward the CCM for reporting measurement events.
このデータタイプは、測定イベントを報告するためにNCMがCCMに向けて行った構成を表します。
(a) Measurement Report Parameter: Parameter that shall be measured and reported. This is dependent on the connection type:
（a）測定報告パラメータ：測定および報告されるパラメータ。これは接続タイプによって異なります。
(1) For the connection type of "Wi-Fi", the allowed measurement type parameters are "WLAN_RSSI", "WLAN_LOAD", "UL_TPUT", "DL_TPUT", "EST_UL_TPUT", and "EST_DL_TPUT".
(1) For the connection type of "Wi-Fi", the allowed measurement type parameters are "WLAN_RSSI", "WLAN_LOAD", "UL_TPUT", "DL_TPUT", "EST_UL_TPUT", and "EST_DL_TPUT".
(2) For the connection type of "LTE", the allowed measurement type parameters are "LTE_RSRP", "LTE_RSRQ", "UL_TPUT", and "DL_TPUT".
（2）接続タイプが「LTE」の場合、使用できる測定タイプのパラメーターは「LTE_RSRP」、「LTE_RSRQ」、「UL_TPUT」、および「DL_TPUT」です。
(3) For the connection type of "5G_NR", the allowed measurement type parameters are "NR_RSRP", "NR_RSRQ", "UL_TPUT", and "DL_TPUT".
（3）接続タイプ「5G_NR」の場合、使用できる測定タイプパラメータは「NR_RSRP」、「NR_RSRQ」、「UL_TPUT」、および「DL_TPUT」です。
(b) Threshold: High and low threshold for reporting.
（b）しきい値：レポートの高しきい値と低しきい値。
(c) Period: Period for reporting, in milliseconds.
（c）期間：レポートの期間（ミリ秒単位）。
The representation of this data type is as follows:
このデータ型の表現は次のとおりです。
object {
JSONString meas_rep_param;
Threshold meas_threshold;
JSONNumber meas_period;
} MeasReportConfs;
Where "Threshold" is defined as follows:
「しきい値」は次のように定義されています。
object {
JSONNumber high;
JSONNumber low;
} Threshold;
This data type represents the measurements reported by the CCM for each access network measured. This type contains the connection information, the Delivery Node ID that identifies either the cell (ECGI) or the Wi-Fi Access Point ID or MAC address (or equivalent identifier in other technologies), and the actual measurement performed by the CCM in the last measurement period.
このデータタイプは、測定された各アクセスネットワークのCCMによって報告された測定値を表します。このタイプには、接続情報、セル（ECGI）またはWi-FiアクセスポイントIDまたはMACアドレス（または他のテクノロジーでは同等の識別子）を識別する配信ノードID、および最後にCCMによって実行された実際の測定が含まれます測定期間。
The representation of this data type is as follows:
このデータ型の表現は次のとおりです。
object {
JSONNumber connection_id;
JSONString connection_type;
JSONString delivery_node_id;
Measurement measurements <1..*>;
} MXMeasRep;
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 Appendix C.2.17.
ここでMeasurementは、測定タイプと値のキーと値のペアとして定義されます。特定の接続について報告される正確な測定タイプパラメータは、その接続タイプによって異なります。各接続タイプの測定タイプパラメータは、付録C.2.17で指定されています。
object {
JSONString measurement_type;
JSONNumber measurement_value;
} Measurement;
{
"$schema": "https://json-schema.org/draft-04/schema#",
"definitions": {
"message_type_def": {
"enum": [
"mx_discover",
"mx_system_info",
"mx_capability_req",
"mx_capability_rsp",
"mx_capability_ack",
"mx_up_setup_conf_req",
"mx_up_setup_cnf",
"mx_reconf_req",
"mx_reconf_rsp",
"mx_path_est_req",
"mx_path_est_results",
"mx_traffic_steering_req",
"mx_traffic_steering_rsp",
"mx_ssid_indication",
"mx_keep_alive_req",
"mx_keep_alive_rsp",
"mx_measurement_conf",
"mx_measurement_report",
"mx_session_termination_req",
"mx_session_termination_rsp",
"mx_app_madp_assoc_req",
"mx_app_madp_assoc_rsp",
"mx_network_analytics_req",
"mx_network_analytics_rsp"
],
"type": "string"
},
"sequence_num_def": {
"minimum": 1,
"type": "integer"
},
"version_def": {
"type": "string"
}
},
"id": "https://example.com/mams/mx_base_def.json"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"definitions": {
"adapt_method": {
"enum": [
"UDP_without_DTLS",
"UDP_with_DTLS",
"IPsec",
"Client_NAT"
],
"type": "string"
},
"conv_method": {
"enum": [
"GMA",
"MPTCP_Proxy",
"GRE_Aggregation_Proxy",
"MPQUIC"
],
"type": "string"
},
"supported": {
"type": "boolean"
},
"active": {
"type": "boolean"
},
"connection_id": {
"type": "integer"
},
"feature_name": {
"enum": [
"lossless_switching",
"fragmentation",
"concatenation",
"uplink_aggregation",
"downlink_aggregation",
"measurement"
"probing"
],
"type": "string"
},
"connection_type": {
"enum": [
"Wi-Fi",
"5G_NR",
"MulteFire",
"LTE"
],
"type": "string"
},
"ip_address": {
"type": "string"
},
"port": {
"maximum": 65535,
"minimum": 1,
"type": "integer"
},
"adaptation_method": {
"allOf" : [
{ "$ref": "#/definitions/adapt_method" },
{ "$ref": "#/definitions/supported" }
]
},
"connection": {
"allOf" : [
{ "$ref": "#/definitions/connection_id" },
{ "$ref": "#/definitions/connection_type" }
]
},
"convergence_method": {
"allOf": [
{ "$ref": "#/definitions/conv_method" },
{ "$ref": "#/definitions/supported" }
]
},
"feature_status": {
"allOf": [
{ "$ref": "#/definitions/feature_name" },
{ "$ref": "#/definitions/active" }
]
},
"ncm_end_point": {
"allOf" : [
{ "$ref" : "#/definitions/ip_address" },
{ "$ref" : "#/definitions/port" }
]
},
"capability_acknowledgment" : {
"enum" : [
"MX_ACCEPT",
"MX_REJECT"
],
"type" : "string"
},
"threshold" : {
"high" : {
"type" : "integer"
},
"low" : {
"type" : "integer"
},
"type" : "object"
},
"meas_report_param" : {
"enum" : [
"WLAN_RSSI",
"WLAN_LOAD",
"LTE_RSRP",
"LTE_RSRQ",
"UL_TPUT",
"DL_TPUT",
"EST_UL_TPUT",
"EST_DL_TPUT",
"NR_RSRP",
"NR_RSRQ"
],
"type" : "string"
},
"meas_report_conf" : {
"meas_rep_param" : {
"$ref" : "#definitions/meas_report_param"
},
"meas_threshold" : {
"$ref" : "#definitions/threshold"
},
"meas_period_ms" : {
"type" : "integer"
},
"type" : "object"
},
"ssid_types" : {
"enum" : [
"ssid",
"bssid",
"hessid"
],
"type" : "string"
},
"ip_addr_mask" : {
"type" : "string",
"default" : "0.0.0.0/0"
},
"port_range" : {
"start" : {
"type" : "integer",
"default" : 0
},
"end" : {
"type" : "integer",
"default" : 65535
}
},
"traffic_flow_template" : {
"remote_addr_mask" : {
"$ref" : "#definitions/ip_addr_mask" },
"local_addr_mask" : {
"$ref" : "#definitions/ip_addr_mask" },
"protocol_type" : {
"type" : "integer",
"minimum" : 0,
"maximum" : 255
},
"local_port_range" : {
"$ref" : "#definitions/port_range" },
"remote_port_range" : {
"$ref" : "#definitions/port_range" },
"traffic_class" : {
"type" : "integer",
"default" : 255
},
"flow_label" : {
"type" : "integer",
"default" : 0
}
},
"delivery_node_id" : {
"type" : "string"
},
"unique_session_id" : {
"type" : "object",
"ncm_id" : {
"type" : "integer"
},
"session_id" : {
"type" : "integer"
}
},
"keep_alive_reason" : {
"enum" : [
"Timeout",
"Handover"
],
"type" : "string"
},
"connection_status" : {
"enum" : [
"disabled",
"enabled",
"connected"
],
"type" : "string",
"default" : "connected"
},
"adaptation_param" : {
"udp_adapt_port" : {
"type" : "integer"
}
},
"probe_param" : {
"probe_port" : {
"type" : "integer"
},
"anchor_conn_id" : {
"type" : "integer"
},
"mx_configuration_id" : {
"type" : "integer"
}
},
"client_param" : {
"connection_id" : {
"type" : "integer"
},
"adapt_param" : {
"type" : {"$ref" : "#definitions/adaptation_param" }
}
}
},
"adapt_param": {
"tunnel_ip_addr": {
"type": "string"
},
"tunnel_end_port": {
"type": "integer"
},
"shared_secret": {
"type": "string"
},
"mx_header_optimization": {
"type": "boolean",
"default": false
}
},
"delivery_connection": {
"connection_id": {
"$ref": "#definitions/connection_id"
},
"connection_type": {
"$ref": "#definitions/connection_type"
},
"adaptation_method": {
"$ref": "#definitions/adapt_method"
},
"adaptation_method_param": {
"$ref": "#definitions/adapt_param"
}
},
"app_madp_assoc": {
"anchor_conn_id" : {
"type" : "integer"
},
"mx_configuration_id" : {
"type" : "integer"
}
"ul_tft_list": {
"items": {
"$ref": "#definitions/traffic_flow_template"
},
"type": "array"
},
"dl_tft_list": {
"items": {
"$ref": "#definitions/traffic_flow_template"
},
"type": "array"
}
},
"predict_param_name": {
"enum": [
"validity_time",
"bandwidth",
"jitter",
"latency",
"signal_quality"
],
"type": "string"
},
"predict_add_param_name": {
"enum": [
"WLAN_RSSI",
"WLAN_LOAD",
"LTE_RSRP",
"LTE_RSRQ",
"NR_RSRP",
"NR_RSRQ"
],
"type": "string"
},
"id": "https://example.com/mams/definitions.json"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"id": "https://example.com/mams/mx_discover.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"}
},
"type": "object"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"id": "https://example.com/mams/mx_system_info.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"},
"ncm_connections": {
"type": "array",
"items": [
{"$ref": "definitions.json#/connection"},
{"$ref": "definitions.json#/ncm_end_point"}
]
}
},
"type": "object"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"id": "https://example.com/mams/mx_capability_req.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"},
"adaptation_methods": {
"items": {"$ref": "definitions.json#/adaptation_method"},
"type": "array"
},
"anchor_connections": {
"items": {"$ref": "definitions.json#/connection"},
"type": "array"
},
"convergence_methods": {
"items": {"$ref": "definitions.json#/convergence_method"},
"type": "array"
},
"delivery_connections": {
"items": {"$ref": "definitions.json#/connection"},
"type": "array"
},
"feature_active": {
"items": {"$ref": "definitions.json#/feature_status"},
"type": "array"
},
"num_anchor_connections": {
"type": "integer"
},
"num_delivery_connections": {
"type": "integer"
}
},
"type": "object"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"id": "https://example.com/mams/mx_capability_rsp.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"},
"adaptation_methods": {
"items": {"$ref": "definitions.json#/adaptation_method"},
"type": "array"
},
"anchor_connections": {
"items": {"$ref": "definitions.json#/connection"},
"type": "array"
},
"convergence_methods": {
"items": {"$ref": "definitions.json#/convergence_method"},
"type": "array"
},
"delivery_connections": {
"items": {"$ref": "definitions.json#/connection"},
"type": "array"
},
"feature_active": {
"items": {"$ref": "definitions.json#/feature_status"},
"type": "array"
},
"num_anchor_connections": {
"type": "integer"
},
"num_delivery_connections": {
"type": "integer"
},
"unique_session_id": {
"$ref": "definitions.json#/unique_session_id"
}
},
"type": "object"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"definitions": {},
"id": "https://example.com/mams/mx_capability_ack.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"},
"unique_session_id": {
"$ref": "definitions.json#/unique_session_id"},
"capability_ack": {
"$ref": "definitions.json#/capability_acknowledgment"}
},
"type": "object"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"definitions": {},
"id": "https://example.com/mams/mx_reconf_req.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"},
"unique_session_id": {
"$ref": "definitions.json#/unique_session_id"
},
"connection_id": {"$ref": "definitions.json#/connection_id"},
"ip_address": {"$ref": "definitions.json#/ip_address"},
"mtu_size": {
"maximum": 65535,
"minimum": 1,
"type": "integer"
},
"ssid": {
"type": "string"
},
"reconf_action": {
"enum": [
"release",
"setup",
"update"
],
"id": "/properties/reconf_action",
"type": "string"
},
"connection_status": {
"$ref": "definitions.json#/connection_status"},
"delivery_node_id": {
"$ref": "definitions.json#/delivery_node_id"}
},
"type": "object"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"definitions": {},
"id": "https://example.com/mams/mx_reconf_rsp.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"}
},
"type": "object"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"definitions": {
"convergence_configuration": {
"mx_configuration_id": {"type": "integer"},
"convergence_method": {
"$ref": "definitions.json#/conv_method"},
"convergence_method_params": {
"properties": {
"proxy_ip": {"$ref": "definitions.json#/ip_address"},
"proxy_port": {"$ref": "definitions.json#/port"},
"client_key": {"$ref": "definitions.json#/client_key"}
},
"type": "object"
},
"num_delivery_connections": {
"type": "integer"
},
"delivery_connections": {
"items": {"$ref": "definitions.json#/delivery_connection"},
"type": "array"
}
}
},
"id": "https://example.com/mams/mx_up_setup_conf_req.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"},
"num_anchor_connections": {
"type": "integer"
},
"anchor_connections": {
"items": {
"properties": {
"connection_id": {
"$ref": "definitions.json#/connection_id"},
"connection_type": {
"$ref": "definitions.json#/connection_type"},
"num_active_mx_conf": {"type": "integer"},
"convergence_config": {
"items": {
"$ref": "definitions/convergence_configuration"},
"type": "array"
}
},
"type": "object"
},
"type": "array"
}
},
"type": "object"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"definitions": {},
"id": "https://example.com/mams/mx_up_setup_cnf.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"},
"unique_session_id": {
"$ref": "definitions.json#/unique_session_id"},
"probe_param": {"$ref": "definitions.json#/probe_param"},
"num_delivery_conn": {
"type": "integer"
},
"client_params": {
"type": "array",
"items": [
{"$ref": "definitions.json#/client_param"}
]
}
},
"type": "object"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"definitions": {
"conn_list": {
"items": {"$ref": "definitions.json#/connection_id"},
"type": "array"
},
"ul_delivery": {
"ul_tft": {
"$ref": "definitions.json#/traffic_flow_template"},
"connection_list": {"$ref": "#definitions/conn_list"}
}
},
"id": "https://example.com/mams/mx_traffic_steering_req.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"},
"connection_id": {"$ref": "definitions.json#/connection_id"},
"mx_configuration_id": {"type": "integer"},
"downlink_delivery": {
"items": {"$ref": "definitions.json#/connection_id"},
"type": "array"
},
"feature_active": {
"items": {"$ref": "definitions.json#/feature_status"},
"type": "array"
},
"default_uplink_delivery": {
"type": "integer"
},
"uplink_delivery": {
"items": {"$ref": "#definitions/ul_delivery"},
"type": "array"
}
},
"type": "object"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"definitions": {},
"id": "https://example.com/example.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"},
"unique_session_id": {
"$ref": "definitions.json#/unique_session_id"},
"feature_active": {
"items": {"$ref": "definitions.json#/feature_status"},
"type": "array"
}
},
"type": "object"
}
{
"$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"
}
{
"$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"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"definitions": {},
"id": "https://example.com/mams/mx_path_est_req.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"},
"active_probe_ack_req": {
"enum": [
"no",
"yes"
],
"type": "string"
},
"active_probe_freq_ms": {
"maximum": 10000,
"minimum": 100,
"type": "integer"
},
"active_probe_size_bytes": {
"maximum": 1500,
"minimum": 100,
"type": "integer"
},
"active_probe_duration_sec": {
"maximum": 100,
"minimum": 10,
"type": "integer"
},
"connection_id": {"$ref": "definitions#/connection_id"},
"init_probe_ack_req": {
"enum": [
"no",
"yes"
],
"type": "string"
},
"init_probe_size_bytes": {
"maximum": 1500,
"minimum": 100,
"type": "integer"
},
"init_probe_test_duration_ms": {
"maximum": 10000,
"minimum": 100,
"type": "integer"
},
"init_probe_test_rate_Mbps": {
"maximum": 100,
"minimum": 1,
"type": "integer"
}
},
"type": "object"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"definitions": {},
"id": "https://example.com/mams/mx_path_est_results.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"},
"unique_session_id": {
"$ref": "definitions.json#/unique_session_id"},
"active_probe_results": {
"properties": {
"avg_tput_last_probe_duration_Mbps": {
"maximum":100,
"minimum": 1,
"type": "number"
}
},
"type": "object"
},
"connection_id": {"$ref": "definitions.json#/connection_id"},
"init_probe_results": {
"properties": {
"lost_probes_percentage": {
"maximum": 100,
"minimum": 1,
"type": "integer"
},
"probe_rate_Mbps": {
"maximum": 100,
"minimum": 1,
"type": "number"
}
},
"type": "object"
}
},
"type": "object"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"definitions": {},
"id": "https://example.com/mams/mx_ssid_indication.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"},
"ssid_list": {
"items": {
"properties": {
"ssid_type": {
"$ref": "definitions.json#/ssid_types"},
"ssid_id": {
"type": "integer"
}
}
},
"type": "array"
}
},
"type": "object"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"definitions": {
"meas_conf": {
"connection_id" : {
"$ref": "definitions.json#/connection_id"},
"connection_type": {
"$ref": "definitions.json#/connection_type"},
"meas_rep_conf": {
"items": {
"$ref": "definitions.json#/meas_report_conf"},
"type": "array"
}
}
},
"id": "https://example.com/mams/mx_measurement_conf.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"},
"measurement_configuration": {
"items": {"$ref": "#definitions/meas_conf"},
"type": "array"
}
},
"type": "object"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"definitions": {},
"id": "https://example.com/mams/mx_measurement_report.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"},
"unique_session_id": {
"$ref": "definitions.json#/unique_session_id"},
"measurement_reports": {
"items": {
"properties": {
"connection_id": {
"$ref": "definitions.json#/connection_id"},
"connection_type": {
"$ref": "definitions.json#/connection_type"},
"delivery_node_id": {
"$ref": "definitions.json#/delivery_node_id"},
"measurements": {
"items": {
"properties": {
"measurement_type": {
"$ref": "definitions.json#/meas_report_param"},
"measurement_value": {
"type": "integer"
}
},
"type": "object"
},
"type": "array"
}
},
"type": "object"
},
"type": "array"
}
},
"type": "object"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"id": "https://example.com/mams/mx_keep_alive_req.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"},
"keep_alive_reason": {
"$ref": "definitions.json#/keep_alive_reason"},
"unique_session_id": {
"$ref": "definitions.json#/unique_session_id"},
"connection_id": {
"$ref": "definitions.json#/connection_id"},
"delivery_node_id": {
"$ref": "definitions.json#/connection_id"}
},
"type": "object"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"id": "https://example.com/mams/mx_keep_alive_rsp.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"},
"unique_session_id": {
"$ref": "definitions.json#/unique_session_id"}
},
"type": "object"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"id": "https://example.com/mams/mx_keep_alive_req.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"},
"unique_session_id": {
"$ref": "definitions.json#/unique_session_id"},
"reason": {
"enum": [
"MX_NORMAL_RELEASE",
"MX_NO_RESPONSE",
"INTERNAL_ERROR"
],
"type": "string"
}
},
"type": "object"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"id": "https://example.com/mams/mx_session_termination_rsp.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"},
"unique_session_id": {
"$ref": "definitions.json#/unique_session_id"}
},
"type": "object"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"id": "https://example.com/mams/mx_network_analytics_req.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"},
"unique_session_id": {
"$ref": "definitions.json#/unique_session_id"},
"params": {
"items": {
"$ref": "definitions.json#/predict_param_name"},
"type": "array"
}
},
"type": "object"
}
{
"$schema": "https://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"definitions": {
"ParamPredictions": {
"param_name": {
"$ref": "definitions.json#/predict_param_name"},
"additional_param": {
"$ref": "definitions.json#/predict_add_param_name"},
"prediction": {"type": "integer"},
"likelihood": {"type": "integer"},
"validity_time": {"type": "integer"}
},
"MXAnalyticsList": {
"connection_id": {
"$ref": "definitions.json#/connection_id"},
"connection_type": {
"$ref": "definitions.json#/connection_type"},
"predictions": {
"items": {
"$ref": "#definitions/ParamPredictions"},
"type": "array"
}
}
},
"id": "https://example.com/mams/mx_network_analytics_rsp.json",
"properties": {
"message_type": {"$ref": "mx_base_def.json#/message_type_def"},
"sequence_num": {"$ref": "mx_base_def.json#/sequence_num_def"},
"version": {"$ref": "mx_base_def.json#/version_def"},
"param_list": {
"items": {
"$ref": "#definitions/MXAnalyticsList"},
"type": "array"}
},
"type": "object"
}
{
"version" : "1.0",
"message_type" : "mx_discover",
"sequence_num" : 1
}
{
"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
}
}
]
}
{
"version" : "1.0",
"message_type" : "mx_capability_req",
"sequence_num" : 3,
"feature_active" : [
{
"feature_name" : "lossless_switching",
"active" : true
},
{
"feature_name" : "fragmentation",
"active" : false
}
],
"num_anchor_connections" : 2,
"anchor_connections" : [
{
"connection_id" : 0,
"connection_type" : "LTE"
},
{
"connection_id" : 1,
"connection_type" : "Wi-Fi"
}
],
"num_delivery_connections" : 2,
"delivery_connections" : [
{
"connection_id" : 0,
"connection_type" : "LTE"
},
{
"connection_id" : 1,
"connection_type" : "Wi-Fi"
}
],
"convergence_methods" : [
{
"method" : "GMA",
"supported" : true
},
{
"method" : "MPTCP_Proxy",
"supported" : false
}
],
"adaptation_methods" : [
{
"method" : "UDP_without_DTLS",
"supported" : false
},
{
"method" : "UDP_with_DTLS",
"supported" : false
},
{
"method" : "IPsec",
"supported" : true
},
{
"method" : "Client_NAT",
"supported" : false
}
]
}
{
"version" : "1.0",
"message_type" : "mx_capability_rsp",
"sequence_num" : 3,
"feature_active" : [
{
"feature_name" : "lossless_switching",
"active" : true
},
{
"feature_name" : "fragmentation",
"active" : false
}
],
"num_anchor_connections" : 2,
"anchor_connections" : [
{
"connection_id" : 0,
"connection_type" : "LTE"
},
{
"connection_id" : 1,
"connection_type" : "Wi-Fi"
}
],
"num_delivery_connections" : 2,
"delivery_connections" : [
{
"connection_id" : 0,
"connection_type" : "LTE"
},
{
"connection_id" : 1,
"connection_type" : "Wi-Fi"
}
],
"convergence_methods" : [
{
"method" : "GMA",
"supported" : true
},
{
"method" : "MPTCP_Proxy",
"supported" : false
}
],
"adaptation_methods" : [
{
"method" : "UDP_without_DTLS",
"supported" : false
},
{
"method" : "UDP_with_DTLS",
"supported" : false
},
{
"method" : "IPsec",
"supported" : true
},
{
"method" : "Client_NAT",
"supported" : false
}
],
"unique_session_id" : {
"ncm_id" : 110,
"session_id" : 1111
}
}
{
"version" : "1.0",
"message_type" : "mx_capability_ack",
"sequence_num" : 3,
"unique_session_id" : {
"ncm_id" : 110,
"session_id" : 1111
},
"capability_ack" : "MX_ACCEPT"
}
{
"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"
}
{
"version" : "1.0",
"message_type" : "mx_reconf_rsp",
"sequence_num" : 4
}
{
"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"
}
}
]
}
]
}
{
"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
}
}
]
}
{
"version" : "1.0",
"message_type" : "mx_traffic_steering_req",
"sequence_num" : 6,
"connection_id" : 0,
"mx_configuration_id" : 1,
"downlink_delivery" : [
{
"connection_id" : 0
},
{
"connection_id" : 1
}
],
"default_uplink_delivery" : 0,
"uplink_delivery" : [
{
"ul_tft" : {
"remote_addr_mask" : "10.10.0.0/24",
"local_addr_mask" : "192.168.0.0/24",
"protocol_type" : 6,
"local_port_range" : {
"start" : 100,
"end" : 1000
},
"remote_port_range" : {
"start" : 100,
"end" : 1000
},
"traffic_class" : 20,
"flow_label" : 100
},
"conn_list" : [
{
"connection_id" : 1
}
]
},
{
"ul_tft" : {
"remote_addr_mask" : "10.10.0.0/24",
"local_addr_mask" : "192.168.0.0/24",
"protocol_type" : 6,
"local_port_range" : {
"start" : 2000,
"end" : 2000
},
"remote_port_range" : {
"start" : 100,
"end" : 1000
},
"traffic_class" : 20,
"flow_label" : 50
},
"conn_list" : [
{
"connection_id" : 1
}
]
}
],
"feature_active" : [
{
"feature_name" : "dl_aggregation",
"active" : true
},
{
"feature_name" : "ul_aggregation",
"active" : false
}
]
}
{
"version": "1.0",
"message_type": "mx_traffic_steering_rsp",
"sequence_num": 6,
"unique_session_id": {
"ncm_id": 110,
"session_id": 1111
},
"feature_active": [{
"feature_name": "lossless_switching",
"active": true
},
{
"feature_name": "fragmentation",
"active": false
}
]
}
{
"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
}
}]
}
]
}
{
"version": "1.0",
"message_type": "mx_app_madp_assoc_rsp",
"sequence_num": 6,
"is_success": true
}
{
"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"
}
{
"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
}
}
{
"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"
}
]
}
{
"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
}
]
}
]
}
{
"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
}、{"measurement_type"： "LTE_RSRQ"、 "measurement_value"：-12
}
]
}
]
}
{
"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"
}
{
"version" : "1.0",
"message_type" : "mx_keep_alive_rsp",
"sequence_num" : 12,
"unique_session_id" : {
"ncm_id" : 110,
"session_id" : 1111
}
}
{
"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"
}
{
"version" : "1.0",
"message_type" : "mx_session_termination_rsp",
"sequence_num" : 13,
"unique_session_id" : {
"ncm_id" : 110,
"session_id" : 1111
}
}
{
"version" : "1.0",
"message_type" : "mx_network_analytics_req",
"sequence_num" : 20,
"unique_session_id" : {
"ncm_id" : 110,
"session_id" : 1111
},
"params" : [
"jitter",
"latency"
]
}
{
"version": "1.0",
"message_type": "mx_network_analytics_rsp",
"sequence_num": 20,
"param_list": [{
"connection_id": 1,
"connection_type": "Wi-Fi",
"predictions": [{
"param_name": "jitter",
"prediction": 100,
"likelihood": 50,
"validity_time": 10
},
{
"param_name": "latency",
"prediction": 19,
"likelihood": 40,
"validity_time": 10
}
]
},
{
"connection_id": 2,
"connection_type": "LTE",
"predictions": [{
"param_name": "jitter",
"prediction": 10,
"likelihood": 80,
"validity_time": 10
},
{
"param_name": "latency",
"prediction": 4,
"likelihood": 60,
"validity_time": 10
}
]
}
]
}
Appendix D. Definition of APIs Provided by the CCM to the Applications at the Client
付録D. CCMがクライアントのアプリケーションに提供するAPIの定義
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.
このセクションでは、CCMがクライアント上のアプリケーションに公開するAPIの実装例を提供します。Swagger2.0を使用してOpenAPIで文書化されています。
{
"swagger": "2.0",
"info": {
"version": "1.0.0",
"title": "Client Connection Manager (CCM)",
"description": "API provided by the CCM towards the application
on a MAMS client."
},
"host": "MAMS.ietf.org",
"basePath": "/ccm/v1.0",
"schemes": [
"https"
],
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"paths": {
"/capabilities": {
"get": {
"description": "This API can be used by an application to
request the capabilities of the CCM.",
"produces": [
"application/json",
"text/html"
],
"responses": {
"200": {
"description": "OK",
"schema": {
"$ref": "#/definitions/capability"
}
},
"default": {
"description": "unexpected error",
"schema": {
"$ref": "#/definitions/errorModel"
}
}
}
}
},
"/app_requirements": {
"post": {
"description": "This API is used by the N-MADP to report
any types of MAMS user-specific errors to
the NCM.",
"produces": [
"application/json",
"text/html"
],
"parameters": [
{
"name": "app-requirements",
"in": "body",
"required": true,
"schema": {
"$ref": "#/definitions/app-requirements"
}
}
],
"responses": {
"200": {
"description": "OK"
},
"default": {
"description": "unexpected error",
"schema": {
"$ref": "#/definitions/errorModel"
}
}
}
}
},
"/predictive_link_params": {
"get": {
"description": "This API is used by applications to get the
information about predicted parameters for
each delivery connection.",
"produces": [
"application/json",
"text/html"
],
"responses": {
"200": {
"description": "OK",
"schema": {
"$ref": "#/definitions/link-params"
}
},
"default": {
"description": "unexpected error",
"schema": {
"$ref": "#/definitions/errorModel"
}
}
}
}
}
},
"definitions": {
"connection-id": {
"type": "integer",
"format": "uint8"
},
"connection-type": {
"enum": [
"Wi-Fi",
"5G_NR",
"MulteFire",
"LTE"
],
"type": "string"
},
"features": {
"enum": [
"lossless_switching",
"fragmentation",
"concatenation",
"uplink_aggregation",
"downlink_aggregation",
"measurement"
"probing"
],
"type": "string"
},
"adaptation-methods": {
"enum": [
"UDP_without_DTLS",
"UDP_with_DTLS",
"IPsec",
"Client_NAT"
],
"type": "string"
},
"convergence-methods": {
"enum": [
"GMA",
"MPTCP_Proxy",
"GRE_Aggregation_Proxy",
"MPQUIC"
],
"type": "string"
},
"connection": {
"type": "object",
"properties": {
"conn-id": {
"$ref": "#/definitions/connection-id"
},
"conn-type": {
"$ref": "#/definitions/connection-type"
}
}
},
"convergence-parameters": {
"type": "object",
"properties": {
"conv-param-name": {
"type": "string"
},
"conv-param-value": {
"type": "string"
}
}
},
"convergence-details": {
"type": "object",
"properties": {
"conv-method": {
"$ref": "#/definitions/convergence-methods"
},
"conv-params": {
"type": "array",
"items": {
"$ref": "#/definitions/convergence-parameters"
}
}
}
},
"capability": {
"type": "object",
"properties": {
"connections": {
"type": "array",
"items": {
"$ref": "#/definitions/connection"
}
},
"features": {
"type": "array",
"items": {
"$ref": "#/definitions/features"
}
},
"adapt-methods": {
"type": "array",
"items": {
"$ref": "#/definitions/adaptation-methods"
}
},
"conv-methods": {
"type": "array",
"items": {
"$ref": "#/definitions/convergence-details"
}
}
}
},
"qos-param-name": {
"enum": [
"jitter",
"latency",
"bandwidth"
],
"type": "string"
},
"qos-param": {
"type": "object",
"properties": {
"qos-param-name": {
"$ref": "#/definitions/qos-param-name"
},
"qos-param-value": {
"type": "integer"
}
}
},
"port-range": {
"type": "object",
"properties": {
"start": {
"type": "integer"
},
"end": {
"type": "integer"
}
}
},
"protocol-type": {
"type": "integer"
},
"stream-features": {
"type": "object",
"properties": {
"proto": {
"$ref": "#/definitions/protocol-type"
},
"port-range": {
"$ref": "#/definitions/port-range"
},
"traffic-qos": {
"$ref": "#/definitions/qos-param"
}
}
},
"app-requirements": {
"type": "object",
"properties": {
"num-streams": {
"type": "integer"
},
"stream-feature": {
"type": "array",
"items": {
"$ref": "#/definitions/stream-features"
}
}
}
},
"param-name": {
"enum": [
"bandwidth",
"jitter",
"latency",
"signal_quality"
],
"type": "string"
},
"additional-param-name": {
"enum": [
"lte-rsrp",
"lte-rsrq",
"nr-rsrp",
"nr-rsrq",
"wifi-rssi"
],
"type": "string"
},
"link-parameter": {
"type": "object",
"properties": {
"connection": {
"$ref": "#/definitions/connection"
},
"param": {
"$ref": "#/definitions/param-name"
},
"additional-param": {
"$ref": "#/definitions/additional-param-name"
},
"prediction": {
"type": "integer"
},
"likelihood": {
"type": "integer"
},
"validity_time": {
"type": "integer"
}
}
},
"link-params": {
"type": "array",
"items": {
"$ref": "#/definitions/link-parameter"
}
},
"errorModel": {
"type": "object",
"description": "Error indication containing the error code and
message.",
"required": [
"code",
"message"
],
"properties": {
"code": {
"type": "integer",
"format": "int32"
},
"message": {
"type": "string"
}
}
}
}
}
Appendix E. Implementation Example Using Python for MAMS Client and Server
付録E. MAMSクライアントおよびサーバーにPythonを使用した実装例
A simple client-side implementation using Python can be as follows:
Pythonを使用した簡単なクライアント側の実装は次のようになります。
#!/usr/bin/env python import asyncio import websockets import json import ssl import time import sys
＃！/ usr / bin / env python import asyncio import websockets import json import ssl import time import sys
context = ssl.SSLContext(ssl.PROTOCOL_TLS)
context.verify_mode = ssl.CERT_REQUIRED
context.set_ciphers("RSA")
context.check_hostname = False
context.load_verify_locations("/home/mecadmin/certs/rootca.pem")
discoverMsg = {'version':'1.0',
'message_type':'mx_discover'}
MXCapabilityRes = {'version':'1.0',
'message_type':'mx_capability_res',
'FeatureActive':[{'feature_name':'fragmentation', 'active':'yes'},
{'feature_name':'lossless_switching', 'active':'yes'}],
'num_anchor_connections':1,
'anchor_connections':[{'connection_id':0, 'connection_type':'LTE'}],
'num_delivery_connections':1,
'delivery_connections':[{'connection_id':1,
'connection_type':"Wi-Fi"}],
'convergence_methods':[{'method':'GMA', 'supported':'true'}],
'adaptation_methods':[{'method':'client_nat', 'supported':'false'}]
}
async def hello():
async with websockets.connect('wss://localhost:8765',
ssl=context) as websocket:
try:
loopFlag=False
while True:
await websocket.send(json.dumps(discoverMsg))
json_message = await websocket.recv()
message = json.loads(json_message)
if "message_type" in message.keys():
print("Received message:{}".format(
message["message_type"]),
"version:{}".format(message["version"]))
if message["message_type"] == "mx_capability_req" :
await websocket.send(json.dumps(MXCapabilityRes))
loopFlag=True
while(loopFlag==True):
pass
except:
print("Client stopped")
asyncio.get_event_loop().run_until_complete(hello())
A server-side implementation using Python can be as follows:
Pythonを使用したサーバー側の実装は次のようになります。
#!/usr/bin/env python import asyncio import websockets import json import ssl
＃！/ usr / bin / env python import asyncio import websockets import json import ssl
ctx = ssl.SSLContext(ssl.PROTOCOL_TLS)
#ctx.set_ciphers("RSA-AES256-SHA")
ctx.load_verify_locations("/home/mecadmin/certs/rootca.pem")
certfile = "/home/mecadmin/certs/server.pem"
keyfile = "/home/mecadmin/certs/serverkey.pem"
ctx.load_cert_chain(certfile, keyfile, password=None)
MXCapabilityReq = {'version':'1.0',
'message_type':'mx_capability_req',
'FeatureActive':[{'feature_name':'fragmentation', 'active':'yes'},
{'feature_name':'lossless_switching', 'active':'yes'}],
'num_anchor_connections':1,
'anchor_connections':[{'connection_id':0, 'connection_type':'LTE'}],
'num_delivery_connections':1,
'delivery_connections':[{'connection_id':1,
'connection_type':"Wi-Fi"}],
'convergence_methods':[{'method':'GMA', 'supported':'true'}],
'adaptation_methods':[{'method':'client_nat', 'supported':'false'}]
}
async def hello(websocket, path):
try:
while True:
name = await websocket.recv()
msg = json.loads(name)
if "message_type" in msg.keys():
print("Received message:{}".format(msg["message_type"]),
"version:{}".format(msg["version"]))
if msg['message_type'] == 'mx_discover':
await websocket.send(json.dumps(MXCapabilityReq))
except: print("Client disconnected")
例外：print（ "クライアント切断"）
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")
Acknowledgments
謝辞
This protocol is the outcome of work by many engineers, not just the authors of this document. The people who contributed to this project, listed in alphabetical order by first name, are Barbara Orlandi, Bongho Kim, David Lopez-Perez, Doru Calin, Jonathan Ling, Lohith Nayak, and Michael Scharf.
このプロトコルは、このドキュメントの作成者だけでなく、多くのエンジニアによる作業の成果です。このプロジェクトに貢献した人は、名のアルファベット順で、Barbara Orlandi、Bongho Kim、David Lopez-Perez、Doru Calin、Jonathan Ling、Lohith Nayak、Michael Scharfです。
Contributors
貢献者
The authors gratefully acknowledge the following additional contributors, in alphabetical order by first name: A Krishna Pramod/ Nokia Bell Labs, Hannu Flinck/Nokia Bell Labs, Hema Pentakota/Nokia, Julius Mueller/AT&T, Nurit Sprecher/Nokia, Salil Agarwal/Nokia, Shuping Peng/Huawei, and Subramanian Vasudevan/Nokia Bell Labs. Subramanian Vasudevan has been instrumental in conceptualization and development of solution principles for the MAMS framework. Shuping Peng has been a key contributor in refining the framework and control-plane protocol aspects.
著者は、以下の追加の寄稿者を名のアルファベット順に感謝します：A Krishna Pramod / Nokia Bell Labs、Hannu Flinck / Nokia Bell Labs、Hema Pentakota / Nokia、Julius Mueller / AT＆T、Nurit Sprecher / Nokia、Salil Agarwal / Nokia 、Shuping Peng / Huawei、Subramanian Vasudevan / Nokia Bell Labs。 Subramanian Vasudevanは、MAMSフレームワークのソリューション原則の概念化と開発に尽力してきました。 Shuping Pengは、フレームワークとコントロールプレーンプロトコルの側面を改善する上で重要な役割を果たしてきました。
Authors' Addresses
著者のアドレス
Satish Kanugovi Nokia Bell Labs
サティシュカヌコビノキアベルラボ
Email: satish.k@nokia-bell-labs.com
Florin Baboescu Broadcom
フローリンバボエスクブロードコム
Email: florin.baboescu@broadcom.com
Jing Zhu Intel
Jing Zhu Intel
Email: jing.z.zhu@intel.com
SungHoon Seo Korea Telecom
SungHoon Seo Korea Telecom
Email: sh.seo@kt.com