[要約] RFC 8822は、5Gワイヤレスワイヤーライン収束ユーザープレーンカプセル化（5WE）に関する標準仕様です。このRFCの目的は、5Gネットワークにおけるユーザーデータの効率的な伝送を実現することです。
Internet Engineering Task Force (IETF) D. Allan, Ed.
Request for Comments: 8822 Ericsson
Category: Informational D. Eastlake 3rd
ISSN: 2070-1721 Futurewei Technologies
D. Woolley
Telstra Corporation
April 2021
5G Wireless Wireline Convergence User Plane Encapsulation (5WE)
5Gワイヤレスワイヤーラインコンバージェンスユーザープレーンカプセル化（5WE）
Abstract
概要
As part of providing wireline access to the 5G Core (5GC), deployed wireline networks carry user data between 5G residential gateways and the 5G Access Gateway Function (AGF). The encapsulation method specified in this document supports the multiplexing of traffic for multiple PDU sessions within a VLAN-delineated access circuit, permits legacy equipment in the data path to inspect certain packet fields, carries 5G QoS information associated with the packet data, and provides efficient encoding. It achieves this by specific points of similarity with the Point-to-Point Protocol over Ethernet (PPPoE) data packet encapsulation (RFC 2516).
5Gコア（5GC）への有線アクセスを提供する部分として、展開された有線ネットワークは、5Gの住宅ゲートウェイと5G Access Gateway関数（AGF）の間でユーザーデータを運びます。このドキュメントで指定されたカプセル化方法は、VLANデリネートアクセス回路内の複数のPDUセッションのトラフィックの多重化をサポートし、データパス内の従来の機器を特定のパケットフィールドを検査することを許可し、パケットデータに関連付けられている5G QoS情報を搬送し、効率的なものを提供します。エンコーディング。これは、ポイントツーポイントプロトコル（PPPOE）データパケットカプセル化（RFC 2516）との特定の類似点によってこれを達成します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。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/rfc8822.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8822で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
1.2. Acronyms
2. Data Encapsulation Format
3. Security Considerations
4. IANA Considerations
5. References
5.1. Normative References
5.2. Informative References
Acknowledgements
Authors' Addresses
Converged 5G ("fifth generation") wireline networks carry user data between 5G residential gateways (5G-RGs) and the 5G Access Gateway Function (identified as a Wireline-AGF (W-AGF) by 3GPP in [TS23316]) across deployed access networks based on Broadband Forum [TR101] and [TR178]. This form of wireline access is considered to be trusted non-3GPP access by the 5G system.
収束5G（「5番目の世代」）のWireline Networksは、5Gの住宅用ゲートウェイ（5G-RGS）と5G Access Gateway機能（TS23316]では、展開されたアクセスで3GPP（Wire-AGF（W-AGF）として識別されています。ブロードバンドフォーラム[TR101]と[TR178]に基づくネットワーク。この形式の有線アクセスは、5Gシステムによる信頼されていない非3GPPアクセスと見なされます。
The transport encapsulation used needs to meet a variety of requirements, including the following:
使用されるトランスポートカプセル化は、次のようなさまざまな要件を満たす必要があります。
* The ability to multiplex multiple logical connections (Protocol Data Unit (PDU) sessions as defined by 3GPP) within a VLAN-identified point-to-point logical circuit between a 5G-RG and a W-AGF.
* 5G-RGとW-AGFとの間のVLAN識別されたポイントツーポイント論理回路内で、複数の論理接続（3GPPで定義されているプロトコルデータユニット（PDU）セッション）を多重化する機能。
* To allow unmodified legacy equipment in the data path to identify the encapsulation and inspect specific fields in the payload. Some access nodes in the data path between the 5G-RG and the W-AGF (such as digital subscriber loop access multiplexers (DSLAMs) and optical line terminations (OLTs)) currently inspect packets identified by specific Ethertypes to identify protocols such as the Point-to-Point Protocol over Ethernet (PPPoE), IP, ARP, and IGMP. This may be for the purpose of enhanced QoS, the policing of identifiers, and other applications. Some deployments are dependent upon this inspection. Such devices are able to do this for PPPoE or IP-over-Ethernet (IPoE) packet encodings but would be unable to do so if a completely new encapsulation, or an existing encapsulation using a new Ethertype, were used.
* データパス内の変更されていない従来の機器を識別し、ペイロード内の特定のフィールドを検査することを許可する。5G-RGとW-AGFとの間のデータパス（デジタル加入者ループアクセスマルチプレクサ（DSLAM）および光回線終端（OLT）の間のデータ経路内のいくつかのアクセスノードは現在、ポイントのようなプロトコルを識別するために特定のEtherTypesによって識別されるパケットを検査している。 - ポイントプロトコルオーバーイーサネット（PPPoE）、IP、ARP、およびIGMP。これは、強化されたQoS、識別子のポリシング、およびその他のアプリケーションの目的であり得る。この検査に依存しています。このようなデバイスは、PPPoEまたはIP-Over-Ethernet（iPoE）パケットエンコーディングに対してこれを行うことができますが、まったく新しいカプセル化、または新しいEtherTypeを使用した既存のカプセル化が使用されていない場合があります。
* To carry per-packet 5G QoS information.
* パケットごとの5G QoS情報を運ぶ。
* An encapsulation that minimizes processing since fixed access residential gateways are sensitive to the complexity of packet processing. While not a strict requirement, this is an important consideration.
* 固定アクセス住宅ゲートウェイがパケット処理の複雑さに敏感であるため、処理を最小限に抑えるカプセル化。厳格な要件ではないが、これは重要な考慮事項です。
A data encapsulation that uses a common Ethertype and has certain fields appearing at the same offset as the PPPoE data encapsulation [RFC2516] can address these requirements. This data encapsulation is referred to as the 5G WWC user plane encapsulation or 5WE. Currently deployed access nodes do not police the VER, TYPE, or CODE fields of an RFC 2516 PPPoE header and only perform limited policing of stateful functions with respect to the procedures documented in RFC 2516. Therefore, these fields have a different definition for 5WE and are used to:
一般的なEtherTypeを使用し、PPPoEデータカプセル化[RFC2516]と同じオフセットで表示される特定のフィールドを持つデータカプセル化がこれらの要件に対処できます。このデータカプセル化は、5G WWCユーザプレーンカプセル化または5WEと呼ばれる。現在デプロイされているアクセスノードは、RFC 2516 PPPoEヘッダーのVer、Type、またはCodeフィールドを警察しません。これにより、RFC 2516に記載されている手順に関してステートフル関数の限られたポリシングのみを実行します。したがって、これらのフィールドは5WEの定義を異なります。に慣れた：
* Identify that the mode of operation for packets encapsulated in such a fashion uses 5G WWC session establishment based on non-access stratum (NAS, a logical control interface between user equipment (UE) and a 5th Generation Core Network (5GC) as specified by 3GPP) and life-cycle maintenance procedures as documented in [TS23502] and [TS23316] instead of legacy PPP/PPPoE session establishment procedures [RFC2516] (i.e., PADI discipline, LCP, NCP, etc.). In this scenario, "discovery" is performed by means outside the scope of this document.
* このような方法でカプセル化されたパケットの動作モードが、非アクセス層（NAS、ユーザ機器間の論理制御インタフェース、および第5世代コアネットワーク（5GC）に基づく5G WWCセッション確立を使用することを特定する。（TS23502]および[TS23316]の代わりに[TS23502]および[TS23316]で記述されたライフサイクルメンテナンス手順[RFC2516]（すなわち、PADI規律、LCP、NCPなど）。このシナリオでは、この文書の範囲外の手段によって「発見」が行われます。
* Permit the session ID field to be used to identify the 5G PDU session the encapsulated packet is part of.
* セッションIDフィールドを使用して、5G PDUセッションを識別することを許可します。カプセル化されたパケットがの一部です。
* Communicate per-packet 5G QoS Flow Identifier (QFI) and Reflective QoS Indication (RQI) information from the 5GC to the 5G-RG.
* 5GCから5G-RGへのパケットごとの5G QoSフロー識別子（QFI）および反射QoS表示（RQI）情報を通信します。
This 5G-specific redesign of fields not inspected by deployed equipment results in an encapsulation uniquely applicable to the requirements for the communication of PDU session traffic between the subscriber premises and the 5G system over wireline networks. The 6-byte RFC 2516 data packet header followed by a 2-byte PPP protocol ID is also the most frugal of the encapsulations that are currently supported by legacy access equipment that could be adapted to meet these requirements.
展開された機器によって検査されていないフィールドのこの5G特有のフィールドの再設計は、加入者徴収者と5Gシステムの上の5Gシステム間のPDUセッショントラフィックの通信の要件に一意に適用されます。6バイトのRFC 2516データパケットヘッダーとそれに続く2バイトのPPPプロトコルIDは、これらの要件を満たすように適合させることができるレガシーアクセス装置によって現在サポートされているカプセル化の最もフルガルである。
This encapsulation is expected to be used in environments where RFC 2516 is deployed. Therefore, implementations MUST examine the version number:
このカプセル化は、RFC 2516が展開されている環境で使用されることが予想されます。したがって、実装はバージョン番号を調べなければなりません。
* If the version number is 1 and PPPoE [RFC2516] is supported, process the frame further; else, silently discard it.
* バージョン番号が1でPPPoE [RFC2516]がサポートされている場合は、さらにフレームを処理してください。そうでなければ、それを静かに捨てる。
* If the version number is 2 and 5WE is supported, process the frame further; else, silently discard it.
* バージョン番号が2と5WEがサポートされている場合は、さらにフレームを処理してください。そうでなければ、それを静かに捨てる。
In both cases, frames for the supported version number should have session IDs corresponding to established sessions for the respective protocol models. A 5WE frame with an unrecognized session ID MUST be silently discarded.
どちらの場合も、サポートされているバージョン番号のフレームには、それぞれのプロトコルモデルの確立されたセッションに対応するセッションIDがあります。認識されないセッションIDを持つ5WEフレームは、静かに破棄されなければなりません。
This encapsulation may have MTU issues when used for Ethernet multiplexing in networks where the underlying Ethernet payload is limited to 1500 bytes.
このカプセル化は、基盤となるイーサネットペイロードが1500バイトに制限されているネットワーク内のイーサネット多重化に使用される場合、MTUの問題を持つことがあります。
This encapsulation is not suitable for other network environments, e.g., general use over the public Internet.
このカプセル化は、他のネットワーク環境、例えば公衆インターネット上の一般的な使用には適していません。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document uses the following acronyms:
この文書は次の頭字語を使用しています。
3GPP 3rd Generation Partnership Project
3GPP第3世代パートナーシッププロジェクト
5WE 5G Wireless Wireline Convergence User Plane Encapsulation
5WAW 5Gワイヤレスワイヤラインコンバージェンスユーザープレーンカプセル化
5GC 5th Generation Core (network)
5GC第5世代コア（ネットワーク）
DSLAM Digital Subscriber Loop Access Multiplexer
DSLAMデジタル加入者ループアクセスマルチプレクサ
W-AGF Wireline Access Gateway Function
W-AGF有線アクセスゲートウェイ機能
IPoE IP over Ethernet
イーサネット上のiPoe IP
NAS Non-Access Stratum
NAS非アクセス層
OLT Optical Line Termination
OLT光回線終端
PDU Protocol Data Unit
PDUプロトコルデータユニット
PPPoE PPP over Ethernet
イーサネット上のPPPoE PPP
QFI QoS Flow Identifier
QFI QoSフロー識別子
QoS Quality of Service
QoSサービス品質
RG Residential Gateway
RG住宅用ゲートウェイ
RQI Reflective QoS Indicator
RQI反射QoSインジケータ
WWC Wireless Wireline Convergence
WWCワイヤレスワイヤーインコンバージェンス
The Ethernet payload [IEEE802] for PPPoE [RFC2516] is indicated by an Ethertype of 0x8864. The information following that Ethertype uses a value of 2 in the VER field for the repurposing of the PPPoE data encapsulation as the 5G WWC user plane encapsulation (5WE). The 5G WWC user plane encapsulation is structured as follows:
PPPoE [RFC2516]のイーサネットペイロード[IEEE802]は、0x8864のEtherTypeによって示されています。EtherTypeが、PPPoEデータカプセル化を5G WWCユーザプレーンカプセル化（5WE）として再利用するためにVERフィールドに2の値を使用する。5G WWCユーザプレーンのカプセル化は次のように構成されています。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VER | TYPE | QFI |R|0| SESSION_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LENGTH | PROTOCOL ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DATA PAYLOAD ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
The description of each field is as follows:
各フィールドの説明は次のとおりです。
VER: The version. It MUST be set to 0x02.
Ver：バージョン。0x02に設定する必要があります。
TYPE: The message type. It MUST be set to 0x01.
タイプ：メッセージタイプ。0x01に設定する必要があります。
QFI: Encodes the 3GPP 5G QoS Flow Identifier [TS38415] to be used for mapping 5G QoS to IP DSCP/802.1 P-bits [IEEE802].
QFI：5G QoSをIP DSCP / 802.1 P-BITS [IEEE802]にマッピングするために使用される3GPP 5G QoSフロー識別子[TS38415]をエンコードします。
R: (Short for Reflective QoS Indication [TS38415]) Encodes the one-bit RQI. It is set by the network-side 5WE termination for downstream traffic and ignored by the network for upstream traffic.
R :(反射QoS表示のための短い短縮[TS38415]）1ビットRQIを符号化します。これは、下流のトラフィックのネットワーク側5WE終端によって設定され、アップストリームトラフィックのネットワークによって無視されます。
0: Indicates the bit(s) that MUST be sent as zero and ignored on receipt.
0：ゼロとして送信されなければならず、受信時に無視されなければならないビットを示します。
SESSION_ID: A 16-bit unsigned integer in network byte order. It is used to distinguish different PDU sessions that are in the VLAN-delineated multiplex. A value of 0xffff is reserved for future use and MUST NOT be used.
session_id：ネットワークバイト順に16ビットの符号なし整数。それは、VLAN描写された多重化された多重化された異なるPDUセッションを区別するために使用されます。0xFFFFの値は将来の使用のために予約されており、使用しないでください。
LENGTH: The length in bytes of the data payload, including the initial Protocol ID. It is 16 bits in network byte order.
長さ：初期プロトコルIDを含むデータペイロードの長さの長さ。ネットワークバイトオーダーで16ビットです。
PROTOCOL ID: The 16-bit identifier of the data payload type encoded using values from the IANA "PPP DLL Protocol Numbers" registry <https://www.iana.org/assignments/ppp-numbers>.
プロトコルID：IANA "PPP DLLプロトコル番号"レジストリ<https://ww.iana.org/assignments/ppp-numbers>からの値を使用してエンコードされたデータペイロードタイプの16ビット識別子。
The following values are valid in this field for 5G WWC use:
5G WWCの使用のために、次の値がこのフィールドで有効です。
* 0x0021: IPv4
* 0x0021：IPv4
* 0x0031: Bridging PDU (Ethernet)
* 0x0031：PDU（イーサネット）のブリッジング
* 0x0057: IPv6
* 0x0057：IPv6.
Packets received that do not contain one of the above protocol IDs are silently discarded.
上記のプロトコルIDのうちの1つを含まない受信したパケットは、静かに廃棄されています。
DATA PAYLOAD: Encoded as per the protocol ID.
データペイロード：プロトコルIDに従ってエンコードされました。
5G NAS procedures used for session life-cycle maintenance employ ciphering and integrity protection [TS23502]. They can be considered a more secure session establishment discipline than existing RFC 2516 procedures, at least against on-path attackers. The design of the 5WE encapsulation will not circumvent existing anti-spoofing and other security procedures in deployed equipment. The existing access equipment will be able to identify fields that they normally process and police as per existing RFC 2516 traffic.
セッションライフサイクルメンテナンスに使用される5G NAS手順は、暗号化と完全性保護を採用しています[TS23502]。それらは、少なくともOn-Path攻撃者に対して、既存のRFC 2516手順よりも安全なセッション設立規律と見なすことができます。5WEカプセル化の設計は、展開された機器において既存のスプーフィング防止およびその他のセキュリティ手順を回避しません。既存のアクセス機器は、既存のRFC 2516トラフィックごとに、通常、それらが通常プロセスおよび警察するフィールドを識別することができます。
Therefore, the security of a fixed access network using 5WE will be equivalent or superior to current practice.
したがって、5WEを使用して固定アクセスネットワークのセキュリティは、現在の練習よりも同等または優れています。
5WE-encapsulated traffic is used on what the 5GC considers to be trusted non-3GPP interfaces; therefore, it is not ciphered. 5WE is not suitable for use over an untrusted non-3GPP interface.
5GCが信頼されていない3GPPインタフェースを信頼できると考える5WA - カプセル化されたトラフィックが使用されます。したがって、暗号化されていません。5Weは、信頼できない非3GPPインターフェースでの使用には適していません。
The security requirements of the 5G system are documented in [TS33501].
5Gシステムのセキュリティ要件は[TS33501]に記載されています。
IANA has created the following registry on the "Point-to-Point (PPP) Protocol Field Assignments" page:
IANAは、「ポイントツーポイント（PPP）プロトコルフィールド割り当て」ページで次のレジストリを作成しました。
Registry Name: PPP Over Ethernet Versions
レジストリ名：PPPオーバーイーサネットバージョン
Registration Procedure: Specification Required
登録手順：指定が必要です
References: [RFC2516] [RFC8822]
参照：[RFC2516] [RFC8822]
+======+=================================+===========+
| VER | Description | Reference |
+======+=================================+===========+
| 0 | Reserved | [RFC8822] |
+------+---------------------------------+-----------+
| 1 | PPPoE | [RFC2516] |
+------+---------------------------------+-----------+
| 2 | 5G WWC User Plane Encapsulation | [RFC8822] |
+------+---------------------------------+-----------+
| 3-15 | unassigned | |
+------+---------------------------------+-----------+
Table 1: PPP Over Ethernet Versions
表1：Ethernetバージョン上のPPP
IANA has added this document as an additional reference for Ethertype 0x8864 in the "Ether Types" registry on the IANA "IEEE 802 Numbers" page <https://www.iana.org/assignments/ieee-802-numbers>.
IANAは、IANA "IEEE 802番号"ページ<https：//www.iana.org/ashignments/ieee-802-numbers>の "Ether Types"レジストリのEthertype 0x8864の追加の参照としてこの文書を追加しました。
[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, February 1999, <https://www.rfc-editor.org/info/rfc2516>.
[RFC2516]ママコス、L.、Lidl、K.、Evarts、J.、Carrel、D.、Simone、D.、R.Waller、「PPPを介したPPPの送信方法」、RFC 2516、DOI10.17487 / RFC2516、1999年2月、<https：//www.rfc-editor.org/info/rfc2516>。
[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>。
[TS23316] 3GPP, "Wireless and wireline convergence access support for the 5G System (5GS)", Release 16, TS 23.316, December 2018.
[TS23316] 3GPP、「5Gシステム（5GS）」、リリース16、TS 23.316、TS 23.316、TS 23.316、2018年12月に。
[TS23502] 3GPP, "Procedures for the 5G System (5GS)", Release 15, TS 23.502, December 2016.
[TS23502] 3GPP、「5Gシステム（5GS）」、リリース15、TS 23.502、2016年12月の手順。
[TS38415] 3GPP, "NG-RAN; PDU session user plane protocol", Release 15, TS 38.415, March 2018.
[TS38415] 3GPP、「NG-RAN; PDUセッションユーザープレーンプロトコル」、リリース15、TS 38.415、2018年3月。
[IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Networks: Overview and Architecture", Std 802-2014, DOI 10.1109/IEEESTD.2014.6847097, June 2014, <https://doi.org/10.1109/IEEESTD.2014.6847097>.
[IEEE802] IEEE、「地元の首都ネットワークのIEEE規格：概要と建築」、STD 802-2014、DOI 10.1109 / IEEESTD.2014.6847097、2014年6月、<https：//doi.org/10.1109/ieeestd.2014.6847097>。
[TR101] Broadband Forum, "Migration to Ethernet Based Broadband Aggregation", TR-101, issue 2, July 2011.
[TR101]ブロードバンドフォーラム、「イーサネットベースブロードバンドアグリゲーションへの移行」、TR-101、2011年7月2日。
[TR178] Broadband Forum, "Multi-service Broadband Network Architecture and Nodal Requirements", TR-178, issue 1, September 2014.
[TR178]ブロードバンドフォーラム、「マルチサービスブロードバンドネットワークアーキテクチャとノーダル要件」、TR-178、2014年9月1日。
[TS33501] 3GPP, "Security architecture and procedures for 5G System", Release 16, TS 33.501, December 2019.
[TS33501] 3GPP、「5Gシステムのセキュリティアーキテクチャと手続き」、リリース16、TS 33.501、2019年12月。
Acknowledgements
謝辞
This memo is a result of comprehensive discussions by the Broadband Forum's Wireline Wireless Convergence Work Area. The authors would also like to thank Joel Halpern and Dirk Von Hugo for their detailed review of this document.
このメモは、ブロードバンドフォーラムの有線無線収束作業領域による包括的な議論の結果です。著者らはまた、この文書の詳細なレビューのためにJoel HalpernとDirk Von Hugoに感謝します。
Authors' Addresses
著者の住所
Dave Allan (editor) Ericsson 2455 Augustine Drive San Jose, CA 95054 United States of America
Dave Alan（編集）Ericsson 2455オーガスティーンドライブサンノゼ、CA 95054アメリカ
Email: david.i.allan@ericsson.com
Donald E. Eastlake 3rd Futurewei Technologies 2386 Panoramic Circle Apopka, FL 32703 United States of America
Donald E.イーストレイク3RDフューチャーワイテクノロジーズ2386パノラマサークルアポッカ、FL 32703アメリカ合衆国
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
David Woolley Telstra Corporation 242 Exhibition St Melbourne 3000 Australia
David Woolley Telstra Corporation 242展St Melbourne 3000オーストラリア
Email: david.woolley@team.telstra.com