[要約] RFC 9391 は、Static Context Header Compression (SCHC) 仕様とNB-IoTを組み合わせたもので、3GPPとの連携を目的としています。normative部分ではSCHCのNB-IoT上での使用を規定し、informational部分では3GPPがSCHCをアーキテクチャ内で使用する際の値を推奨しています。
Internet Engineering Task Force (IETF) E. Ramos
Request for Comments: 9391 Ericsson
Category: Standards Track A. Minaburo
ISSN: 2070-1721 Acklio
April 2023
This document describes Static Context Header Compression and fragmentation (SCHC) specifications, RFCs 8724 and 8824, in combination with the 3rd Generation Partnership Project (3GPP) and the Narrowband Internet of Things (NB-IoT).
このドキュメントでは、第3世代パートナーシッププロジェクト（3GPP）および狭帯域インターネット（NB-Iot）と組み合わせて、静的コンテキストヘッダー圧縮とフラグメンテーション（SCHC）仕様、RFCS 8724および8824について説明します。
This document has two parts: one normative part that specifies the use of SCHC over NB-IoT and one informational part that recommends some values if 3GPP wants to use SCHC inside their architectures.
このドキュメントには2つの部分があります。3GPPがアーキテクチャ内でSCHCを使用したい場合に何らかの値を推奨するNB-IOTよりもSCHCの使用を指定する1つの規範的な部分です。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc9391.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9391で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Conventions and Definitions
3. Terminology
4. NB-IoT Architecture
5. Data Transmission in the 3GPP Architecture
5.1. Normative Scenarios
5.1.1. SCHC over Non-IP Data Delivery (NIDD)
5.2. Informational Scenarios
5.2.1. Use of SCHC over the Radio Link
5.2.2. Use of SCHC over the Non-Access Stratum (NAS)
5.2.3. Parameters for Static Context Header Compression and
Fragmentation (SCHC) for the Radio Link and DoNAS Use
Cases
6. Padding
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. NB-IoT User Plane Protocol Architecture
A.1. Packet Data Convergence Protocol (PDCP)
A.2. Radio Link Protocol (RLC)
A.3. Medium Access Control (MAC)
Appendix B. NB-IoT Data over NAS (DoNAS)
Acknowledgements
Authors' Addresses
This document defines scenarios where Static Context Header Compression and fragmentation (SCHC) [RFC8724] [RFC8824] are suitable for 3rd Generation Partnership Project (3GPP) and Narrowband Internet of Things (NB-IoT) protocol stacks.
このドキュメントでは、静的コンテキストヘッダー圧縮と断片化（SCHC）[RFC8724] [RFC8824]が第3世代パートナーシッププロジェクト（3GPP）および狭帯域インターネット（NB-IOT）プロトコルスタックに適しているシナリオを定義します。
In the 3GPP and the NB-IoT networks, header compression efficiently brings Internet connectivity to the Device UE (Dev-UE), the radio (RGW-eNB) and network (NGW-MME) gateways, and the Application Server. This document describes the SCHC parameters supporting SCHC over the NB-IoT architecture.
3GPPおよびNB-Iotネットワークでは、ヘッダー圧縮により、インターネット接続がデバイスUE（DEV-UE）、ラジオ（RGW-ENB）およびネットワーク（NGW-MME）ゲートウェイ、およびアプリケーションサーバーに効率的にもたらされます。このドキュメントでは、NB-IotアーキテクチャよりもSCHCをサポートするSCHCパラメーターについて説明します。
This document assumes functionality for NB-IoT of 3GPP release 15 [R15-3GPP]. Otherwise, the text explicitly mentions other versions' functionality.
このドキュメントでは、3GPPリリース15 [R15-3GPP]のNB-OITの機能を想定しています。それ以外の場合、テキストは他のバージョンの機能について明示的に言及しています。
This document has two parts: normative end-to-end scenarios describing how any application must use SCHC over the 3GPP public service and informational scenarios about how 3GPP could use SCHC in their protocol stack network.
このドキュメントには、3GPP公共サービスでSCHCを使用する方法を説明する規範的なエンドツーエンドシナリオと、3GPPがプロトコルスタックネットワークでSCHCを使用する方法に関する情報シナリオを説明する規範的なエンドツーエンドシナリオの2つの部分があります。
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 will follow the terms defined in [RFC8724], [RFC8376], and [TR23720].
この文書は、[RFC8724]、[RFC8376]、および[TR23720]で定義されている用語に従います。
Capillary Gateway:
キャピラリーゲートウェイ：
Facilitates seamless integration because it has wide-area connectivity through cellular and provides wide-area access as a proxy to other devices using LAN technologies (BT, Wi-Fi, Zigbee, or others).
Cellularを介した広範なエリア接続を備えており、LANテクノロジー（BT、Wi-Fi、Zigbeeなど）を使用して他のデバイスへのプロキシとして広範なエリアアクセスを提供するため、シームレスな統合を促進します。
Cellular IoT Evolved Packet System (CIoT EPS):
Cellular IoT Evolved Packet System（CIOT EPS）：
A functionality to improve the support of small data transfers.
小さなデータ転送のサポートを改善する機能。
Device UE (Dev-UE):
デバイスUE（dev-ue）：
As defined in [RFC8376], Section 3.
[RFC8376]で定義されているように、セクション3。
Data over Non-Access Stratum (DoNAS):
非アクセス層（DONAS）に関するデータ：
Sending user data within signaling messages over the NAS functional layer.
NAS機能層を介したシグナリングメッセージ内のユーザーデータの送信。
Evolved Packet Connectivity (EPC):
進化したパケット接続（EPC）：
Core network of 3GPP LTE systems.
3GPP LTEシステムのコアネットワーク。
Evolved Universal Terrestrial Radio Access Network (EUTRAN):
普遍的な陸生ラジオアクセスネットワーク（Eutran）の進化：
Radio access network of LTE-based systems.
LTEベースのシステムの無線アクセスネットワーク。
Hybrid Automatic Repeat reQuest (HARQ):
ハイブリッドオートマチックリピートリクエスト（HARQ）：
A combination of high-rate Forward Error Correction (FEC) and Automatic Repeat reQuest (ARQ) error control.
高速順方向エラー補正（FEC）と自動リピートリクエスト（ARQ）エラーコントロールの組み合わせ。
Home Subscriber Server (HSS):
Home Subscriber Server（HSS）：
A database that contains users' subscription data, including data needed for mobility management.
モビリティ管理に必要なデータを含むユーザーのサブスクリプションデータを含むデータベース。
IP address:
IPアドレス：
IPv6 or IPv4 address used.
使用されるIPv6またはIPv4アドレス。
InterWorking Service Capabilities Exposure Function (IWK-SCEF):
インターワーキングサービス機能露出関数（IWK-SCEF）：
Used in roaming scenarios, is located in the Visited PLMN, and serves for interconnection with the Service Capabilities Exposure Function (SCEF) of the Home PLMN.
ローミングシナリオで使用され、訪問されたPLMNに位置し、Home PLMNのサービス機能露出関数（SCEF）との相互接続に役立ちます。
Layer 2 (L2):
レイヤー2（L2）：
L2 in the 3GPP architectures includes MAC, RLC, and PDCP layers; see Appendix A.
3GPPアーキテクチャのL2には、Mac、RLC、およびPDCPレイヤーが含まれます。付録Aを参照してください。
Logical Channel ID (LCID):
論理チャネルID（LCID）：
The logical channel instance of the corresponding MAC SDU.
対応するMac SDUの論理チャネルインスタンス。
Medium Access Control (MAC) protocol:
ミディアムアクセスコントロール（MAC）プロトコル：
Part of L2.
L2の一部。
Non-Access Stratum (NAS):
非アクセス層（NAS）：
Functional layer for signaling messages that establishes communication sessions and maintains the communication while the user moves.
ユーザーが移動している間、通信セッションを確立し、通信を維持するシグナリングメッセージの機能レイヤー。
Narrowband IoT (NB-IoT):
ナローバンドIoT（NB-OIT）：
A 3GPP Low-Power WAN (LPWAN) technology based on the LTE architecture but with additional optimization for IoT and using a Narrowband spectrum frequency.
LTEアーキテクチャに基づいた3GPP低電力WAN（LPWAN）テクノロジーは、IoTの追加の最適化と狭帯域スペクトル周波数を使用しています。
Network Gateway - CIoT Serving Gateway Node (NGW-CSGN):
ネットワークゲートウェイ-CIOTサービングゲートウェイノード（NGW -CSGN）：
As defined in [RFC8376], Section 3.
[RFC8376]で定義されているように、セクション3。
Network Gateway - Cellular Serving Gateway (NGW-CSGW):
ネットワークゲートウェイ - セルラーサービングゲートウェイ（NGW -CSGW）：
Routes and forwards the user data packets through the access network.
アクセスネットワークを介してユーザーデータパケットをルートと転送します。
Network Gateway - Mobility Management Entity (NGW-MME):
ネットワークゲートウェイ - モビリティ管理エンティティ（NGW -MME）：
An entity in charge of handling mobility of the Dev-UE.
Dev-ueのモビリティの処理を担当するエンティティ。
Network Gateway - Packet Data Network Gateway (NGW-PGW):
ネットワークゲートウェイ - パケットデータネットワークゲートウェイ（NGW -PGW）：
An interface between the internal and external network.
内部ネットワークと外部ネットワーク間のインターフェイス。
Network Gateway - Service Capability Exposure Function (NGW-SCEF):
ネットワークゲートウェイ - サービス機能エクスポージャー関数（NGW -SCEF）：
EPC node for exposure of 3GPP network service capabilities to third party applications.
3GPPネットワークサービス機能をサードパーティアプリケーションに露出するためのEPCノード。
Non-IP Data Delivery (NIDD):
非IPデータ配信（NIDD）：
End-to-end communication between the UE and the Application Server.
UEとアプリケーションサーバー間のエンドツーエンド通信。
Packet Data Convergence Protocol (PDCP):
パケットデータ収束プロトコル（PDCP）：
Part of L2.
L2の一部。
Public Land-based Mobile Network (PLMN):
公共の陸上モバイルネットワーク（PLMN）：
A combination of wireless communication services offered by a specific operator.
特定のオペレーターが提供するワイヤレス通信サービスの組み合わせ。
Protocol Data Unit (PDU):
プロトコルデータユニット（PDU）：
A data packet including headers that are transmitted between entities through a protocol.
プロトコルを介してエンティティ間で送信されるヘッダーを含むデータパケット。
Radio Link Protocol (RLC):
ラジオリンクプロトコル（RLC）：
Part of L2.
L2の一部。
Radio Gateway - evolved Node B (RGW-eNB):
ラジオゲートウェイ - 進化したノードB（RGW -ENB）：
Base Station that controls the UE.
UEを制御するベースステーション。
Service Data Unit (SDU):
サービスデータユニット（SDU）：
A data packet (PDU) from higher-layer protocols used by lower-layer protocols as a payload of their own PDUs.
低層プロトコルが独自のPDUのペイロードとして使用する高層プロトコルからのデータパケット（PDU）。
The NB-IoT architecture has a complex structure. It relies on different Network Gateways (NGWs) from different providers. It can send data via different paths, each with different characteristics in terms of bandwidth, acknowledgments, and L2 reliability and segmentation.
NB-iotアーキテクチャには複雑な構造があります。さまざまなプロバイダーのさまざまなネットワークゲートウェイ（NGW）に依存しています。さまざまなパスを介してデータを送信できます。各パスは、帯域幅、謝辞、L2の信頼性とセグメンテーションに関して異なる特性を持つ可能性があります。
Figure 1 shows this architecture, where the Network Gateway - Cellular IoT Serving Gateway Node (NGW-CSGN) optimizes co-locating entities in different paths. For example, a Dev-UE using the path formed by the Network Gateway - Mobility Management Entity (NGW-MME), the NGW-CSGW, and the Network Gateway - Packet Data Network Gateway (NGW-PGW) may get a limited bandwidth transmission from a few bytes/s to one thousand bytes/s only.
図1は、ネットワークゲートウェイ-Cellular IoTのゲートウェイノード（NGW-CSGN）が異なるパスでの共同配位エンティティを最適化するこのアーキテクチャを示しています。たとえば、ネットワークゲートウェイ - モビリティマネジメントエンティティ（NGW-MME）、NGW-CSGW、およびネットワークゲートウェイ - パケットデータネットワークゲートウェイ（NGW-PGW）によって形成されたパスを使用する開発者は、帯域幅の伝送が限られている場合があります。数バイト/sから1,000バイト/sのみ。
Another node introduced in the NB-IoT architecture is the Network Gateway - Service Capability Exposure Function (NGW-SCEF), which securely exposes service and network capabilities to entities external to the network operator. The Open Mobile Alliance (OMA) [OMA0116] and the One Machine to Machine (OneM2M) [TR-0024] define the northbound APIs. [TS23222] defines architecture for the common API framework for 3GPP northbound APIs. [TS33122] defines security aspects for a common API framework for 3GPP northbound APIs. In this case, the path is small for data transmission. The main functions of the NGW-SCEF are path connectivity and device monitoring.
NB-Iotアーキテクチャで導入された別のノードは、ネットワークゲートウェイ - サービス機能露出機能（NGW-SCEF）です。これは、ネットワークオペレーターの外部のエンティティにサービスとネットワーク機能を安全に公開します。Open Mobile Alliance（OMA）[OMA0116]および1つのマシンへのマシン（ONEM2M）[TR-0024]は、北行きのAPIを定義します。[TS23222] 3GPPノースバウンドAPIの一般的なAPIフレームワークのアーキテクチャを定義します。[TS33122]は、3GPPノースバウンドAPIの一般的なAPIフレームワークのセキュリティ側面を定義します。この場合、データ送信のパスは小さいです。NGW-SCEFの主な機能は、パス接続とデバイスの監視です。
+---+ +---------+ +------+
|Dev| \ | +-----+ | ---| HSS |
|-UE| \ | | NGW | | +------+
+---+ | | |-MME |\__
\ / +-----+ | \
+---+ \+-----+ /| | | +------+
|Dev| ----| RGW |- | | | | NGW- |
|-UE| |-eNB | | | | | SCEF |---------+
+---+ /+-----+ \| | | +------+ |
/ \ +------+| |
/ |\| NGW- || +-----+ +-----------+
+---+ / | | CSGW |--| NGW-|---|Application|
|Dev| | | || | PGW | | Server |
|-UE| | +------+| +-----+ +-----------+
+---+ | |
|NGW-CSGN |
+---------+
Figure 1: 3GPP Network Architecture
図1：3GPPネットワークアーキテクチャ
NB-IoT networks deal with end-to-end user data and in-band signaling between the nodes and functions to configure, control, and monitor the system functions and behaviors. The signaling uses a different path with specific protocols, handling processes, and entities but can transport end-to-end user data for IoT services. In contrast, the end-to-end application only transports end-to-end data.
NB-Iotネットワークは、エンドツーエンドのユーザーデータとノードと関数間の帯域内シグナリングを扱い、システム機能と動作を構成、制御、監視します。シグナリングは、特定のプロトコル、処理プロセス、およびエンティティを使用して別のパスを使用しますが、IoTサービスのエンドツーエンドユーザーデータを輸送できます。対照的に、エンドツーエンドアプリケーションはエンドツーエンドのデータのみを輸送します。
The recommended 3GPP MTU size is 1358 bytes. The radio network protocols limit the packet sizes over the air, including radio protocol overhead, to 1600 bytes; see Section 5.2.3. However, the recommended 3GPP MTU is smaller to avoid fragmentation in the network backbone due to the payload encryption size (multiple of 16) and the additional core transport overhead handling.
推奨される3GPP MTUサイズは1358バイトです。無線ネットワークプロトコルは、無線プロトコルのオーバーヘッドを含む空中のパケットサイズを1600バイトに制限しています。セクション5.2.3を参照してください。ただし、推奨される3GPP MTUは、ペイロード暗号化サイズ（16の倍数）と追加のコアトランスポートオーバーヘッドハンドリングにより、ネットワークバックボーンの断片化を避けるために小さくなります。
3GPP standardizes NB-IoT and, in general, the interfaces and functions of cellular technologies. Therefore, the introduction of SCHC entities to Dev-UE, RGW-eNB, and NGW-CSGN needs to be specified in the NB-IoT standard.
3GPPは、NB-Iotを標準化し、一般に、細胞技術のインターフェイスと機能を標準化します。したがって、Dev-ue、RGW-ENB、およびNGW-CSGNへのSCHCエンティティの導入は、NB-Iot標準で指定する必要があります。
This document identifies the use cases of SCHC over the NB-IoT architecture.
このドキュメントは、NB-iotアーキテクチャを介したSCHCのユースケースを識別します。
The first use case is of the radio transmission (see Section 5.2.1) where the Dev-UE and the RGW-eNB can use the SCHC functionalities.
最初のユースケースは、DEV-UUEとRGW-ENBがSCHC機能を使用できる電波伝送（セクション5.2.1を参照）です。
The second is where the packets transmitted over the control path can also use SCHC when the transmission goes over the NGW-MME or NGW-SCEF (see Section 5.2.2).
2つ目は、送信されたパケットが送信がNGW-MMEまたはNGW-SCEFを越えたときにSCHCを使用できる場所です（セクション5.2.2を参照）。
These two use cases are also valid for any 3GPP architecture and not only for NB-IoT. And as the 3GPP internal network is involved, they have been put in the informational part of this section.
これらの2つのユースケースは、NB-IOTだけでなく、3GPPアーキテクチャに対しても有効です。また、3GPP内部ネットワークが関与しているため、このセクションの情報部分に配置されています。
And the third covers the SCHC over Non-IP Data Delivery (NIDD) connection or at least up to the operator network edge (see Section 5.1.1). In this case, SCHC functionalities are available in the application layer of the Dev-UE and the Application Servers or a broker function at the edge of the operator network. NGW-PGW or NGW-SCEF transmit the packets that are Non-IP traffic, using IP tunneling or API calls. It is also possible to benefit legacy devices with SCHC by using the Non-IP transmission features of the operator network.
3番目は、非IPデータ配信（NIDD）接続を介したSCHCをカバーするか、少なくともオペレーターネットワークのエッジまでです（セクション5.1.1を参照）。この場合、SCHC機能は、DEV-UUEのアプリケーションレイヤーと、オペレーターネットワークの端にあるアプリケーションサーバーまたはブローカー機能で利用できます。NGW-PGWまたはNGW-SCEFは、IPトンネリングまたはAPI呼び出しを使用して、非IPトラフィックであるパケットを送信します。また、オペレーターネットワークの非IP伝送機能を使用して、SCHCを使用してレガシーデバイスに利益をもたらすこともできます。
A Non-IP transmission refers to an L2 transport that is different from NB-IoT.
非IPトランスミッションとは、NB-iotとは異なるL2輸送を指します。
These scenarios do not modify the 3GPP architecture or any of its components. They only use the architecture as an L2 transmission.
これらのシナリオは、3GPPアーキテクチャまたはそのコンポーネントのいずれかを変更しません。アーキテクチャはL2トランスミッションとしてのみ使用します。
This section specifies the use of SCHC over NIDD services of 3GPP. The NIDD services of 3GPP enable the transmission of SCHC packets compressed by the application layer. The packets can be delivered between the NGW-PGW and the Application Server or between the NGW-SCEF and the Application Server, using IP-tunnels or API calls. In both cases, as compression occurs before transmission, the network will not understand the packet, and the network does not have context information of this compression. Therefore, the network will treat the packet as Non-IP traffic and deliver it to the other side without any other protocol stack element, directly over L2.
このセクションでは、3GPPのNIDDサービスを介したSCHCの使用を指定しています。3GPPのNIDDサービスにより、アプリケーションレイヤーによって圧縮されたSCHCパケットの送信が可能になります。パケットは、NGW-PGWとアプリケーションサーバー間、またはIP-TunnelsまたはAPI呼び出しを使用して、NGW-SCEFとアプリケーションサーバーの間で配信できます。どちらの場合も、送信前に圧縮が発生すると、ネットワークはパケットを理解せず、ネットワークにはこの圧縮のコンテキスト情報がありません。したがって、ネットワークはパケットを非IPトラフィックとして扱い、L2を直接他のプロトコルスタック要素なしで反対側に配信します。
In the two scenarios using NIDD compression, SCHC entities are located almost on top of the stack. The NB-IoT connectivity services implement SCHC in the Dev-UE, an in the Application Server. The IP tunneling scenario requires that the Application Server send the compressed packet over an IP connection terminated by the 3GPP core network. If the transmission uses the NGW-SCEF services, it is possible to utilize an API call to transfer the SCHC packets between the core network and the Application Server. Also, an IP tunnel could be established by the Application Server if negotiated with the NGW-SCEF.
NIDD圧縮を使用した2つのシナリオでは、SCHCエンティティはスタックのほぼ上にあります。NB-iot Connectivity Servicesは、アプリケーションサーバーであるDev-ueにSCHCを実装しています。IPトンネルのシナリオでは、アプリケーションサーバーが3GPPコアネットワークによって終了したIP接続上に圧縮パケットを送信する必要があります。送信がNGW-SCEFサービスを使用している場合、API呼び出しを使用して、コアネットワークとアプリケーションサーバー間でSCHCパケットを転送することができます。また、NGW-SCEFと交渉した場合、アプリケーションサーバーによってIPトンネルを確立できます。
+---------+ XXXXXXXXXXXXXXXXXXXXXXXX +--------+
| SCHC | XXX XXX | SCHC |
|(Non-IP) +-----XX........................XX....+--*---+(Non-IP)|
+---------+ XX +----+ XX | | +--------+
| | XX |SCEF+-------+ | | |
| | XXX 3GPP RAN & +----+ XXX +---+ UDP |
| | XXX CORE NETWORK XXX | | |
| L2 +---+XX +------------+ | +--------+
| | XX |IP TUNNELING+--+ | |
| | XXX +------------+ +---+ IP |
+---------+ XXXX XXXX | +--------+
| PHY +------+ XXXXXXXXXXXXXXXXXXXXXXX +---+ PHY |
+---------+ +--------+
Dev-UE Application
Server
Figure 2: End-to-End Compression: SCHC Entities Placed when Using Non-IP Delivery (NIDD) 3GPP Services
図2：エンドツーエンドの圧縮：非IP配信（NIDD）3GPPサービスを使用するときに配置されたSCHCエンティティ
These scenarios MAY use the SCHC header compression capability to improve the transmission of IPv6 packets.
これらのシナリオは、SCHCヘッダー圧縮機能を使用して、IPv6パケットの送信を改善する場合があります。
* SCHC Context Initialization
* SCHCコンテキスト初期化
* The application layer handles the static context. Consequently, the context distribution MUST be according to the application's capabilities, perhaps utilizing IP data transmissions up to context initialization. Also, the static context delivery may use the same IP tunneling or NGW-SCEF services used later for the transport of SCHC packets.
* アプリケーションレイヤーは静的コンテキストを処理します。したがって、コンテキストの分布はアプリケーションの機能に従って、おそらくコンテキストの初期化までのIPデータ送信を利用する必要があります。また、静的コンテキスト配信は、SCHCパケットの輸送に後で使用される同じIPトンネリングまたはNGW-SCEFサービスを使用する場合があります。
* SCHC Rules
* SCHCルール
* For devices acting as a capillary gateway, several rules match the diversity of devices and protocols used by the devices associated with the gateway. Meanwhile, simpler devices may have predetermined protocols and fixed parameters.
* キャピラリーゲートウェイとして機能するデバイスの場合、いくつかのルールは、ゲートウェイに関連付けられたデバイスで使用されるデバイスとプロトコルの多様性と一致します。一方、よりシンプルなデバイスには、所定のプロトコルと固定パラメーターがある場合があります。
* RuleID
* Roolid
* This scenario can dynamically set the RuleID size before the context delivery, for example, by negotiating between the applications when choosing a profile according to the type of traffic and application deployed. Transmission optimization may require only one Physical Layer transmission. SCHC overhead SHOULD NOT exceed the available number of effective bits of the smallest physical Transport Block (TB) available to optimize the transmission. The packets handled by 3GPP networks are byte-aligned. Thus, to use the smallest TB, the maximum SCHC header size is 12 bits. On the other hand, more complex NB-IoT devices (such as a capillary gateway) might require additional bits to handle the variety and multiple parameters of higher-layer protocols deployed. The configuration may be part of the agreed operation profile and content distribution. The RuleID field size may range from 2 bits, resulting in 4 rules, to an 8-bit value, yielding up to 256 rules for use by operators. A 256-rule maximum limit seems to be quite reasonable, even for a device acting as a NAT. An application may use a larger RuleID, but it should consider the byte alignment of the expected Compression Residue. In the minimum TB size case, 2 bits of RuleID leave only 6 bits available for Compression Residue.
* このシナリオは、たとえば、展開されたトラフィックとアプリケーションのタイプに従ってプロファイルを選択するときにアプリケーション間で交渉することにより、コンテキスト配信の前にRuleIDサイズを動的に設定できます。トランスミッションの最適化には、1つの物理層伝送のみが必要になる場合があります。SCHCオーバーヘッドは、伝送を最適化するために利用可能な最小の物理輸送ブロック（TB）の有効なビットの利用可能な数を超えてはなりません。3GPPネットワークによって処理されるパケットはバイトアリーングです。したがって、最小のTBを使用するには、最大SCHCヘッダーサイズは12ビットです。一方、より複雑なNB-OITデバイス（キャピラリーゲートウェイなど）は、展開された高層プロトコルの多様性と複数のパラメーターを処理するために追加のビットが必要になる場合があります。構成は、合意された操作プロファイルとコンテンツ分布の一部である場合があります。RuleIDフィールドサイズは、2ビットから4つのルールになり、8ビット値になり、オペレーターが使用するための最大256のルールを生成します。256ルールの最大制限は、NATとして機能するデバイスであっても、非常に妥当なようです。アプリケーションはより大きなRuleIDを使用する場合がありますが、予想される圧縮残基のバイトアライメントを考慮する必要があります。最小TBサイズの場合、2ビットのRoolidは、圧縮残基に使用可能な6ビットのみを残します。
* SCHC MAX_PACKET_SIZE
* SCHC MAX_PACKET_SIZE
* In these scenarios, the maximum RECOMMENDED MTU size is 1358 bytes since the SCHC packets (and fragments) are traversing the whole 3GPP network infrastructure (core and radio), not only the radio as in the IP transmissions case.
* これらのシナリオでは、SCHCパケット（およびフラグメント）が3GPPネットワークインフラストラクチャ全体（コアおよびラジオ）全体を横断しているため、最大推奨されるMTUサイズは1358バイトです。
* Fragmentation
* 断片化
* Packets larger than 1358 bytes need the SCHC fragmentation function. Since the 3GPP uses reliability functions, the No-ACK fragmentation mode MAY be enough in point-to-point connections. Nevertheless, additional considerations are described below for more complex cases.
* 1358バイトを超えるパケットには、SCHCフラグメンテーション関数が必要です。3GPPは信頼性関数を使用するため、ポイントツーポイント接続ではNO-ackフラグメンテーションモードで十分である可能性があります。それにもかかわらず、より複雑なケースについては、以下に追加の考慮事項を説明します。
* Fragmentation Modes
* 断片化モード
* A global service assigns a QoS to the packets, e.g., depending on the billing. Packets with very low QoS may get lost before arriving in the 3GPP radio network transmission, e.g., in between the links of a capillary gateway or due to buffer overflow handling in a backhaul connection. The use of SCHC fragmentation with the ACK-on-Error mode is RECOMMENDED to secure additional reliability on the packets transmitted with a small trade-off on further transmissions to signal the end-to-end arrival of the packets if no transport protocol takes care of retransmission. Also, the ACK-on-Error mode could be desirable to keep track of all the SCHC packets delivered. In that case, the fragmentation function could be activated for all packets transmitted by the applications. SCHC ACK-on-Error fragmentation MAY be activated in transmitting Non-IP packets on the NGW-MME. A Non-IP packet will use SCHC reserved RuleID for non-compressing packets as [RFC8724] allows it.
* グローバルサービスは、請求に応じて、Qosをパケットに割り当てます。QoSが非常に低いパケットは、3GPP無線ネットワークトランスミッションに到着する前に紛失する可能性があります。ACKオンエラーモードでのSCHC断片化の使用は、トランスポートプロトコルがない場合にパケットのエンドツーエンドの到着を知らせるために、さらなる送信で小さなトレードオフで送信されたパケットの追加の信頼性を確保するために推奨されます再送信の。また、ACKオンエラーモードは、配信されるすべてのSCHCパケットを追跡するために望ましい場合があります。その場合、アプリケーションによって送信されるすべてのパケットに対して、フラグメンテーション関数をアクティブにすることができます。SCHC ACK-ON-ERRORの断片化は、NGW-MME上の非IPパケットの送信で活性化される場合があります。非IPパケットは、[RFC8724]が許可するため、非圧縮パケットにSCHC予約済みのRuleIDを使用します。
* Fragmentation Parameters
* 断片化パラメーター
* SCHC profile will have specific Rules for the fragmentation modes. The rule will identify which fragmentation mode is in use, and Section 5.2.3 defines the RuleID size.
* SCHCプロファイルには、フラグメンテーションモードの特定のルールがあります。ルールは、どの断片化モードが使用されているかを識別し、セクション5.2.3でRuleIDサイズを定義します。
SCHC parametrization considers that NB-IoT aligns the bit and uses padding and the size of the Transfer Block. SCHC will try to reduce padding to optimize the compression of the information. The header size needs to be a multiple of 4. The Tiles MAY keep a fixed value of 4 or 8 bits to avoid padding, except for when the transfer block equals 16 bits as the Tiles may be 2 bits. The transfer block size has a wide range of values. Two configurations are RECOMMENDED for the fragmentation parameters.
SCHCのパラメーター化は、NB-iotがビットを調整し、パディングと転送ブロックのサイズを使用することを考慮しています。SCHCは、情報の圧縮を最適化するためにパディングを削減しようとします。ヘッダーサイズは4の倍数である必要があります。タイルは、パディングを避けるために、パディングを避けるために4ビットまたは8ビットの固定値を維持できます。転送ブロックサイズには、幅広い値があります。フラグメンテーションパラメーターには2つの構成が推奨されます。
* For Transfer Blocks smaller than or equal to 304 bits using an 8-bit Header_size configuration, with the size of the header fields as follows:
* 8ビットheader_size構成を使用して304ビット以下の移動ブロックの場合、次のようにヘッダーフィールドのサイズを使用して：
- RuleID from 1 - 3 bits
- 1-3ビットからのRoolid
- DTag 1 bit
- DTAG 1ビット
- FCN 3 bits
- FCN 3ビット
- W 1 bits
- W 1ビット
* For Transfer Blocks bigger than 304 bits using a 16-bit Header_size configuration, with the size of the header fields as follows:
* 16ビットHeader_size構成を使用して304ビットを超える転送ブロックの場合、ヘッダーフィールドのサイズは次のとおりです。
- RulesID from 8 - 10 bits
- 8〜10ビットからのRulesId
- DTag 1 or 2 bits
- DTAG 1または2ビット
- FCN 3 bits
- FCN 3ビット
- W 2 or 3 bits
- W 2または3ビット
* WINDOW_SIZE of (2^N)-1 is RECOMMENDED.
* （2^n）-1のwindow_sizeが推奨されます。
* Reassembly Check Sequence (RCS) will follow the default size defined in Section 8.2.3 of [RFC8724], with a length equal to the L2 Word.
* 再組み立てチェックシーケンス（RCS）は、[RFC8724]のセクション8.2.3で定義されたデフォルトサイズに続き、長さはL2ワードに等しくなります。
* MAX_ACK_REQ is RECOMMENDED to be 2, but applications MAY change this value based on transmission conditions.
* MAX_ACK_REQは2になることをお勧めしますが、アプリケーションは送信条件に基づいてこの値を変更する場合があります。
The IoT devices communicate with small data transfers and use the Power Save Mode and the Idle Mode Discontinuous Reception (DRX), which govern how often the device wakes up, stays up, and is reachable. The use of the different modes allows the battery to last ten years. Table 10.5.163a in [TS24008] defines the radio timer values with units incrementing by N. The units of N can be 1 hour or 10 hours. The range used for IoT is of N to 3N, where N increments by one. The Inactivity Timer and the Retransmission Timer can be set based on these limits.
IoTデバイスは、小さなデータ転送と通信し、Power Saveモードとアイドルモードの不連続受信（DRX）を使用します。さまざまなモードを使用すると、バッテリーが10年間続くことができます。[TS24008]の表10.5.163aは、Nによって増加するユニットを持つ無線タイマーの値を定義します。Nの単位は1時間または10時間になる可能性があります。IoTに使用される範囲はn〜3nで、nは1つずつ増加します。不活動タイマーと再送信タイマーは、これらの制限に基づいて設定できます。
These scenarios show how 3GPP could use SCHC for their transmissions.
これらのシナリオは、3GPPが送信にSCHCを使用する方法を示しています。
Deploying SCHC over the Radio Link only would require placing it as part of the protocol stack for data transfer between the Dev-UE and the RGW-eNB. This stack is the functional layer responsible for transporting data over the wireless connection and managing radio resources. There is support for features such as reliability, segmentation, and concatenation. The transmissions use link adaptation, meaning that the system will optimize the transport format used according to the radio conditions, the number of bits to transmit, and the power and interference constraints. That means that the number of bits transmitted over the air depends on the selected Modulation and Coding Schemes (MCSs). Transport Block (TB) transmissions happen in the Physical Layer at network-synchronized intervals called Transmission Time Interval (TTI). Each TB has a different MCS and number of bits available to transmit. The MAC layer [TR36321] defines the characteristics of the TBs. The Radio Link stack shown in Figure 3 comprises the Packet Data Convergence Protocol (PDCP) [TS36323], the Radio Link Protocol (RLC) [TS36322], the Medium Access Control protocol (MAC) [TR36321], and the Physical Layer [TS36201]. Appendix A gives more details about these protocols.
SCHCを無線リンク上に展開するには、Dev-ueとRGW-ENBの間のデータ転送のためにプロトコルスタックの一部として配置する必要があります。このスタックは、ワイヤレス接続上でデータを輸送し、無線リソースを管理する機能層です。信頼性、セグメンテーション、連結などの機能をサポートしています。トランスミッションはリンクの適応を使用します。つまり、システムは、電波条件、送信するビット数、および電力と干渉の制約に従って使用される輸送形式を最適化します。つまり、空気上に送信されるビットの数は、選択した変調およびコーディングスキーム（MCS）に依存します。トランスポートブロック（TB）送信は、伝送時間間隔（TTI）と呼ばれるネットワーク同期間隔で物理層で発生します。各TBには異なるMCSと送信可能なビット数があります。MACレイヤー[TR36321]は、TBSの特性を定義します。図3に示す無線リンクスタックは、パケットデータ収束プロトコル（PDCP）[TS36323]、無線リンクプロトコル（RLC）[TS36322]、中アクセス制御プロトコル（MAC）[TR36321]、および物理層[TS362011]。付録Aでは、これらのプロトコルの詳細について説明します。
+---------+ +---------+ |
|IP/Non-IP+------------------------------+IP/Non-IP+->+
+---------+ | +---------------+ | +---------+ |
| PDCP +-------+ PDCP | GTP|U +------+ GTP-U |->+
| (SCHC) + + (SCHC)| + + | |
+---------+ | +---------------+ | +---------+ |
| RLC +-------+ RLC |UDP/IP +------+ UDP/IP +->+
+---------+ | +---------------+ | +---------+ |
| MAC +-------+ MAC | L2 +------+ L2 +->+
+---------+ | +---------------+ | +---------+ |
| PHY +-------+ PHY | PHY +------+ PHY +->+
+---------+ +---------------+ +---------+ |
C-Uu/ S1-U SGi
Dev-UE RGW-eNB NGW-CSGN
Radio Link
Figure 3: SCHC over the Radio Link
図3：無線リンク上のSCHC
The 3GPP architecture supports Robust Header Compression (ROHC) [RFC5795] in the PDCP layer. Therefore, the architecture can deploy SCHC header compression entities similarly without the need for significant changes in the 3GPP specifications.
3GPPアーキテクチャは、PDCP層の堅牢なヘッダー圧縮（ROHC）[RFC5795]をサポートします。したがって、アーキテクチャは、3GPP仕様の大幅な変更を必要とせずに、SCHCヘッダー圧縮エンティティを同様に展開できます。
The RLC layer has three functional modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). The mode of operation controls the functionalities of the RLC layer. TM only applies to signaling packets, while AM or UM carry signaling and data packets.
RLCレイヤーには、透明モード（TM）、未充填モード（UM）、および確認モード（AM）の3つの機能モードがあります。動作モードは、RLC層の機能を制御します。TMは、信号パケットにのみ適用されますが、AMまたはCARRYシグナリングとデータパケット。
The RLC layer takes care of fragmentation except for the TM. In AM or UM, the SCHC fragmentation is unnecessary and SHOULD NOT be used. While sending IP packets, the Radio Link does not commonly use the RLC TM. However, if other protocol overhead optimizations are targeted for NB-IoT traffic, SCHC fragmentation may be used for TM transmission in the future.
RLC層は、TMを除き、断片化を処理します。AMまたはUMでは、SCHCの断片化は不要であり、使用しないでください。IPパケットを送信している間、ラジオリンクは一般にRLC TMを使用しません。ただし、他のプロトコルオーバーヘッドの最適化がNB-IOTトラフィックの対象となる場合、SCHCの断片化は将来のTM伝送に使用される場合があります。
This section consists of IETF suggestions to the 3GPP. The NGW-MME conveys mainly signaling between the Dev-UE and the cellular network [TR24301]. The network transports this traffic on top of the Radio Link.
このセクションは、3GPPへのIETF提案で構成されています。NGW-MMEは、主にDev-ueとセルラーネットワーク[TR24301]の間でシグナル伝達を伝えます。ネットワークは、このトラフィックを無線リンクの上に輸送します。
This kind of flow supports data transmissions to reduce the overhead when transmitting infrequent small quantities of data. This transmission is known as Data over Non-Access Stratum (DoNAS) or Control Plane CIoT EPS optimizations. In DoNAS, the Dev-UE uses the pre-established security, can piggyback small uplink data into the initial uplink message, and uses an additional message to receive a downlink small data response.
この種のフローは、データ送信をサポートして、まれな少量のデータを送信するときにオーバーヘッドを減らします。この伝送は、非アクセス層（DONAS）またはコントロールプレーンCIOT EPSの最適化に関するデータとして知られています。DONASでは、Dev-ueが事前に確立されたセキュリティを使用し、小さなアップリンクデータを初期のアップリンクメッセージに豚肉に乗せることができ、追加のメッセージを使用してダウンリンクの小さなデータ応答を受信します。
The NGW-MME performs the data encryption from the network side in a DoNAS PDU. Depending on the data type signaled indication (IP or Non-IP data), the network allocates an IP address or establishes a direct forwarding path. DoNAS is regulated under rate control upon previous agreement, meaning that a maximum number of bits per unit of time is agreed upon per device subscription beforehand and configured in the device.
NGW-MMEは、Donas PDUのネットワーク側からデータ暗号化を実行します。シグナル付き表示（IPデータまたは非IPデータ）に応じて、ネットワークはIPアドレスを割り当てるか、直接転送パスを確立します。DONASは、以前の契約に応じて料金管理下で規制されています。つまり、デバイスごとに最大時間単位のビット数が事前にデバイスのサブスクリプションごとに合意され、デバイスで構成されています。
The system will use DoNAS when a terminal in a power-saving state requires a short transmission and receives an acknowledgment or short feedback from the network. Depending on the size of the buffered data to be transmitted, the Dev-UE might deploy the connected mode transmission instead. The connected mode would limit and control the DoNAS transmissions to predefined thresholds, and it would be a good resource optimization balance for the terminal and the network. The support for mobility of DoNAS is present but produces additional overhead. Appendix B gives additional details of DoNAS.
電力節約状態の端末が短い送信を必要とし、ネットワークからの確認または短いフィードバックを受け取る場合、システムはDONAを使用します。送信されるバッファーデータのサイズに応じて、Dev-ueは代わりに接続モード伝送を展開する場合があります。接続モードは、Donasの送信を事前定義されたしきい値に制限および制御し、端末とネットワークの優れたリソース最適化バランスになります。ドナスの移動性のサポートは存在しますが、追加のオーバーヘッドが生成されます。付録Bでは、ドナスの追加の詳細を示します。
SCHC resides in this scenario's Non-Access Stratum (NAS) protocol layer. The same principles as for Section 5.2.1 apply here as well. Because the NAS protocol already uses ROHC [RFC5795], it can also adapt SCHC for header compression. The main difference compared to the Radio Link (Section 5.2.1) is the physical placing of the SCHC entities. On the network side, the NGW-MME resides in the core network and is the terminating node for NAS instead of the RGW-eNB.
SCHCは、このシナリオの非アクセス層（NAS）プロトコル層に存在します。セクション5.2.1と同じ原則もここにも適用されます。NASプロトコルはすでにROHC [RFC5795]を使用しているため、SCHCをヘッダー圧縮に適応させることもできます。無線リンク（セクション5.2.1）と比較した主な違いは、SCHCエンティティの物理的な配置です。ネットワーク側では、NGW-MMEはコアネットワークに存在し、RGW-ENBの代わりにNASの終端ノードです。
+--------+ +--------+--------+ + +--------+
| IP/ +--+-----------------+--+ IP/ | IP/ +-----+ IP/ |
| Non-IP | | | | Non-IP | Non-IP | | | Non-IP |
+--------+ | | +-----------------+ | +--------+
| NAS +-----------------------+ NAS |GTP-C/U +-----+GTP-C/U |
|(SCHC) | | | | (SCHC) | | | | |
+--------+ | +-----------+ | +-----------------+ | +--------+
| RRC +-----+RRC |S1|AP+-----+ S1|AP | | | | |
+--------+ | +-----------+ | +--------+ UDP +-----+ UDP |
| PDCP* +-----+PDCP*|SCTP +-----+ SCTP | | | | |
+--------+ | +-----------+ | +-----------------+ | +--------+
| RLC +-----+ RLC | IP +-----+ IP | IP +-----+ IP |
+--------+ | +-----------+ | +-----------------+ | +--------+
| MAC +-----+ MAC | L2 +-----+ L2 | L2 +-----+ L2 |
+--------+ | +-----------+ | +-----------------+ | +--------+
| PHY +--+--+ PHY | PHY +--+--+ PHY | PHY +-----+ PHY |
+--------+ +-----+-----+ +--------+--------+ | +--------+
C-Uu/ S1 SGi
Dev-UE RGW-eNB NGW-MME NGW-PGW
*PDCP is bypassed until AS security is activated TGPP36300.
Figure 4: SCHC Entities Placement in the 3GPP CIOT Radio Protocol Architecture for DoNAS Transmissions
図4：Donas Transmissionsの3GPP CIOTラジオプロトコルアーキテクチャへのSCHCエンティティの配置
If 3GPP incorporates SCHC, it is recommended that these scenarios use the SCHC header compression [RFC8724] capability to optimize the data transmission.
3GPPにSCHCが組み込まれている場合、これらのシナリオはSCHCヘッダー圧縮[RFC8724]機能を使用してデータ送信を最適化することをお勧めします。
* SCHC Context Initialization
* SCHCコンテキスト初期化
* The Radio Resource Control (RRC) protocol is the main tool used to configure the parameters of the Radio Link. It will configure SCHC and the static context distribution as it has been made for ROHC operation [RFC5795] [TS36323].
* 無線リソースコントロール（RRC）プロトコルは、無線リンクのパラメーターを構成するために使用される主なツールです。ROHC操作[RFC5795] [TS36323]のために行われているように、SCHCと静的コンテキスト分布を構成します。
* SCHC Rules
* SCHCルール
* The network operator defines the number of rules in these scenarios. For this, the network operator must know the IP traffic the device will carry. The operator might supply rules compatible with the device's use case. For devices acting as a capillary gateway, several rules match the diversity of devices and protocols used by the devices associated with the gateway. Meanwhile, simpler devices may have predetermined protocols and fixed parameters. The use of IPv6 and IPv4 may force the operator to develop more rules to deal with each case.
* ネットワークオペレーターは、これらのシナリオのルールの数を定義します。このため、ネットワークオペレーターは、デバイスが携帯するIPトラフィックを知っている必要があります。オペレーターは、デバイスのユースケースと互換性のあるルールを提供する場合があります。キャピラリーゲートウェイとして機能するデバイスの場合、いくつかのルールは、ゲートウェイに関連付けられたデバイスで使用されるデバイスとプロトコルの多様性と一致します。一方、よりシンプルなデバイスには、所定のプロトコルと固定パラメーターがある場合があります。IPv6とIPv4の使用により、オペレーターは各ケースに対処するためのより多くのルールを開発するように強制する場合があります。
* RuleID
* Roolid
* There is a reasonable assumption of 9 bytes of radio protocol overhead for these transmission scenarios in NB-IoT, where PDCP uses 5 bytes due to header and integrity protection and where RLC and MAC use 4 bytes. The minimum physical TBs that can withhold this overhead value, according to the 3GPP Release 15 specification [R15-3GPP], are 88, 104, 120, and 144 bits. As for Section 5.1.1.2, these scenarios must optimize the Physical Layer where the smallest TB is 12 bits. These 12 bits must include the Compression Residue in addition to the RuleID. On the other hand, more complex NB-IoT devices (such as a capillary gateway) might require additional bits to handle the variety and multiple parameters of higher-layer protocols deployed. In that sense, the operator may want flexibility on the number and type of rules independently supported by each device; consequently, these scenarios require a configurable value. The configuration may be part of the agreed operation profile with the content distribution. The RuleID field size may range from 2 bits, resulting in 4 rules, to an 8-bit value, yielding up to 256 rules for use with the operators. A 256-rule maximum limit seems to be quite reasonable, even for a device acting as a NAT. An application may use a larger RuleID, but it should consider the byte alignment of the expected Compression Residue. In the minimum TB size case, 2 bits of RuleID leave only 6 bits available for Compression Residue.
* PDCPがヘッダーと整合性保護のために5バイトを使用し、RLCとMACが4バイトを使用しているため、PDCPが5バイトを使用するNB-Iotでは、9バイトの無線プロトコルオーバーヘッドの合理的な仮定があります。3GPPリリース15仕様[R15-3GPP]によると、このオーバーヘッド値を差し控えることができる最小の物理TBSは、88、104、120、および144ビットです。セクション5.1.1.2については、これらのシナリオは、最小のTBが12ビットの物理層を最適化する必要があります。これらの12ビットには、RuleIDに加えて圧縮残基を含める必要があります。一方、より複雑なNB-OITデバイス（キャピラリーゲートウェイなど）は、展開された高層プロトコルの多様性と複数のパラメーターを処理するために追加のビットが必要になる場合があります。その意味で、オペレーターは、各デバイスで独立してサポートされているルールの数と種類の柔軟性を必要とする場合があります。したがって、これらのシナリオには構成可能な値が必要です。構成は、コンテンツ分布を備えた合意された操作プロファイルの一部である場合があります。RuleIDフィールドサイズは2ビットから4つのルールになり、8ビット値になり、オペレーターで使用するために最大256のルールが生成されます。256ルールの最大制限は、NATとして機能するデバイスであっても、非常に妥当なようです。アプリケーションはより大きなRuleIDを使用する場合がありますが、予想される圧縮残基のバイトアライメントを考慮する必要があります。最小TBサイズの場合、2ビットのRoolidは、圧縮残基に使用可能な6ビットのみを残します。
* SCHC MAX_PACKET_SIZE
* SCHC MAX_PACKET_SIZE
* The Radio Link can handle the fragmentation of SCHC packets if needed, including reliability. Hence, the packet size is limited by the MTU that is handled by the radio protocols, which corresponds to 1600 bytes for the 3GPP Release 15.
* 無線リンクは、信頼性を含め、必要に応じてSCHCパケットの断片化を処理できます。したがって、パケットサイズは、3GPPリリース15の1600バイトに対応する無線プロトコルによって処理されるMTUによって制限されます。
* Fragmentation
* 断片化
* For the Radio Link (Section 5.2.1) and DoNAS (Section 5.2.2) scenarios, the SCHC fragmentation functions are disabled. The RLC layer of NB-IoT can segment packets into suitable units that fit the selected TB for transmissions of the Physical Layer. The block selection is made according to the link adaptation input function in the MAC layer and the quantity of data in the buffer. The link adaptation layer may produce different results at each TTI, resulting in varying physical TBs that depend on the network load, interference, number of bits transmitted, and QoS. Even if setting a value that allows the construction of data units following the SCHC tiles principle, the protocol overhead may be greater or equal to allowing the Radio Link protocols to take care of the fragmentation intrinsically.
* 無線リンク（セクション5.2.1）およびDonas（セクション5.2.2）のシナリオの場合、SCHC断片化関数は無効になります。NB-IOTのRLC層は、パケットを物理層の送信用に選択したTBに適合する適切なユニットにセグメント化できます。ブロック選択は、MACレイヤーのリンク適応入力関数とバッファーのデータの量に従って行われます。リンク適応層は、各TTIで異なる結果を生成する可能性があり、その結果、ネットワークの負荷、干渉、送信されたビット数、およびQoSに依存する物理的なTBが変化します。SCHCタイルの原則に従ってデータユニットの構築を可能にする値を設定したとしても、プロトコルのオーバーヘッドは、無線リンクプロトコルが断片化を本質的に処理できるようにすることに等しくなる可能性があります。
* Fragmentation in RLC TM
* RLC TMの断片化
* The RLC TM mostly applies to control signaling transmissions. When RLC operates in TM, the MAC layer mechanisms ensure reliability and generate overhead. This additional reliability implies sending repetitions or automatic retransmissions.
* RLC TMは、主に信号送信を制御することに適用されます。RLCがTMで動作する場合、MACレイヤーメカニズムは信頼性を確保し、オーバーヘッドを生成します。この追加の信頼性は、繰り返しまたは自動再送信を送信することを意味します。
* The ACK-Always fragmentation mode of SCHC may reduce this overhead in future operations when data transmissions may use this mode. The ACK-Always mode may transmit compressed data with fewer possible transmissions by using fixed or limited TBs compatible with the tiling SCHC fragmentation handling. For SCHC fragmentation parameters, see Section 5.1.1.2.
* SCHCのACK-alwaysフラグメンテーションモードは、データ送信がこのモードを使用する可能性がある場合、将来の操作でこのオーバーヘッドを減らす可能性があります。ACK-Alwaysモードは、タイリングSCHCフラグメンテーション処理と互換性のある固定または限定されたTBSを使用することにより、可能な送信で圧縮データを送信する場合があります。SCHCの断片化パラメーターについては、セクション5.1.1.2を参照してください。
NB-IoT and 3GPP wireless access, in general, assumes a byte-aligned payload. Therefore, the L2 Word for NB-IoT MUST be considered 8 bits, and the padding treatment should use this value accordingly.
一般に、NB-iotおよび3GPPワイヤレスアクセスは、バイトアリードペイロードを想定しています。したがって、NB-IOTのL2ワードは8ビットと見なされ、パディング処理はそれに応じてこの値を使用する必要があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
This document does not add any security considerations and follows [RFC8724] and the 3GPP access security document specified in [TS33122].
このドキュメントでは、セキュリティ上の考慮事項は追加されず、[RFC8724]と[TS33122]で指定された3GPPアクセスセキュリティドキュメントに従います。
[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>.
[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>.
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zuniga, "SCHC: Generic Framework for Static Context Header
Compression and Fragmentation", RFC 8724,
DOI 10.17487/RFC8724, April 2020,
<https://www.rfc-editor.org/info/rfc8724>.
[RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static
Context Header Compression (SCHC) for the Constrained
Application Protocol (CoAP)", RFC 8824,
DOI 10.17487/RFC8824, June 2021,
<https://www.rfc-editor.org/info/rfc8824>.
[OMA0116] Open Mobile Alliance, "Common definitions for RESTful
Network APIs", Version 1.0, January 2018,
<https://www.openmobilealliance.org/release/
REST_NetAPI_Common/V1_0-20180116-A/OMA-TS-
REST_NetAPI_Common-V1_0-20180116-A.pdf>.
[R15-3GPP] 3GPP, "Release 15", April 2019, <https://www.3gpp.org/
specifications-technologies/releases/release-15>.
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
Header Compression (ROHC) Framework", RFC 5795,
DOI 10.17487/RFC5795, March 2010,
<https://www.rfc-editor.org/info/rfc5795>.
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/info/rfc8376>.
[TR-0024] OneM2M, "3GPP_Interworking", TR-0024-V4.3.0, March 2020,
<https://ftp.onem2m.org/work%20programme/WI-0037/TR-0024-
3GPP_Interworking-V4_3_0.DOCX>.
[TR23720] 3GPP, "Study on architecture enhancements for Cellular
Internet of Things", 3GPP TR 23.720 V13.0.0, March 2016,
<https://www.3gpp.org/ftp/Specs/
archive/23_series/23.720/23720-d00.zip>.
[TR24301] 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved
Packet System (EPS); Stage 3", 3GPP TS 24.301 V15.8.0,
December 2019, <https://www.3gpp.org/ftp//Specs/
archive/24_series/24.301/24301-f80.zip>.
[TR36321] 3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); Medium Access Control (MAC) protocol
specification", 3GPP TS 36.321 V13.2.0, June 2016,
<https://www.3gpp.org/ftp/Specs/
archive/36_series/36.321/36321-d20.zip>.
[TS23222] 3GPP, "Functional architecture and information flows to
support Common API Framework for 3GPP Northbound APIs;
Stage 2", 3GPP TS 23.222 V15.6.0, September 2022,
<https://www.3gpp.org/ftp/Specs/
archive/23_series/23.222/23222-f60.zip>.
[TS24008] 3GPP, "Mobile radio interface Layer 3 specification; Core
network protocols; Stage 3", 3GPP TS 24.008 V15.5.0,
December 2018, <https://www.3gpp.org/ftp//Specs/
archive/24_series/24.008/24008-f50.zip>.
[TS33122] 3GPP, "Security aspects of Common API Framework (CAPIF)
for 3GPP northbound APIs", 3GPP TS 33.122 V15.3.0, March
2019, <https://www.3gpp.org/ftp//Specs/
archive/33_series/33.122/33122-f30.zip>.
[TS36201] 3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); LTE physical layer; General description", 3GPP
TS 36.201 V15.1.0, June 2018,
<https://www.3gpp.org/ftp/Specs/
archive/36_series/36.201/36201-f10.zip>.
[TS36322] 3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); Radio Link Control (RLC) protocol
specification", 3GPP TS 36.322 V15.0.1, April 2018,
<https://www.3gpp.org/ftp/Specs/
archive/36_series/36.322/36322-f01.zip>.
[TS36323] 3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); Packet Data Convergence Protocol (PDCP)
specification", 3GPP TS 36.323 V13.2.0, June 2016,
<https://www.3gpp.org/ftp/Specs/
archive/36_series/36.323/36323-d20.zip>.
[TS36331] 3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); Radio Resource Control (RRC); Protocol
specification", 3GPP TS 36.331 V15.5.1, April 2019,
<https://www.3gpp.org/ftp//Specs/
archive/36_series/36.331/36331-f51.zip>.
Each of the Radio Bearers (RBs) is associated with one PDCP entity [TS36323]. Moreover, a PDCP entity is associated with one or two RLC entities, depending on the unidirectional or bidirectional characteristics of the RB and RLC mode used. A PDCP entity is associated with either a control plane or a user plane with independent configuration and functions. The maximum supported size for NB-IoT of a PDCP SDU is 1600 octets. The primary services and functions of the PDCP sublayer for NB-IoT for the user plane include:
各無線ベアラー（RBS）は、1つのPDCPエンティティ[TS36323]に関連付けられています。さらに、PDCPエンティティは、使用されるRBおよびRLCモードの単方向または双方向の特性に応じて、1つまたは2つのRLCエンティティに関連付けられています。PDCPエンティティは、独立した構成と機能を備えたコントロールプレーンまたはユーザープレーンのいずれかに関連付けられています。PDCP SDUのNB-OITの最大サポートサイズは1600オクテットです。ユーザープレーンのNB-IotのPDCPサブレイヤーの主要なサービスと機能は次のとおりです。
* Header compression and decompression using ROHC [RFC5795]
* ROHCを使用したヘッダー圧縮と減圧[RFC5795]
* Transfer of user and control data to higher and lower layers
* ユーザーと制御データのより高いレイヤーへの転送
* Duplicate detection of lower-layer SDUs when re-establishing connection (when RLC with Acknowledge Mode is in use for User Plane only)
* 接続を再確立するときの下層SDUの重複検出（確認モードを備えたRLCがユーザープレーンのみで使用されている場合のみ）
* Ciphering and deciphering
* 暗号化と解読
* Timer-based SDU discard in uplink
* アップリンクでタイマーベースのSDU廃棄
RLC [TS36322] is an L2 protocol that operates between the User Equipment (UE) and the base station (eNB). It supports the packet delivery from higher layers to MAC, creating packets transmitted over the air, optimizing the TB utilization. RLC flow of data packets is unidirectional, and it is composed of a transmitter located in the transmission device and a receiver located in the destination device. Therefore, to configure bidirectional flows, two sets of entities, one in each direction (downlink and uplink), must be configured and effectively peered to each other. The peering allows the transmission of control packets (e.g., status reports) between entities. RLC can be configured for a data transfer in one of the following modes:
RLC [TS36322]は、ユーザー機器（UE）とベースステーション（ENB）の間で動作するL2プロトコルです。高レイヤーからMacへのパケット配信をサポートし、空中に送信されるパケットを作成し、結核の使用率を最適化します。データパケットのRLCフローは単方向であり、送信デバイスにある送信機と宛先デバイスにある受信機で構成されています。したがって、双方向フローを構成するには、各方向に1つ（ダウンリンクとアップリンク）の2つのエンティティを構成し、互いに効果的に覗き込む必要があります。ピアリングにより、エンティティ間で制御パケット（ステータスレポートなど）を送信できます。RLCは、次のモードのいずれかでデータ転送用に構成できます。
* Transparent Mode (TM)
* 透明モード（TM）
* RLC does not segment or concatenate SDUs from higher layers in this mode and does not include any header with the payload. RLC receives SDUs from upper layers when acting as a transmitter and transmits directly to its flow RLC receiver via lower layers. Similarly, upon reception, a TM RLC receiver would not process the packets and only deliver them to higher layers.
* RLCは、このモードの高層からSDUをセグメント化または連結しておらず、ペイロードにヘッダーを含めません。RLCは、送信機として作用するときに上層からSDUを受け取り、下層を介してそのフローRLCレシーバーに直接送信します。同様に、受信後、TM RLCレシーバーはパケットを処理せず、高レイヤーにのみ配信します。
* Unacknowledged Mode (UM)
* 未承認モード（um）
* This mode provides support for segmentation and concatenation of payload. The RLC packet's size depends on the indication given at a particular transmission opportunity by the lower layer (MAC) and is octet-aligned. The packet delivery to the receiver does not include reliability support, and the loss of a segment from a packet means a complete packet loss. Also, in lower-layer retransmissions, there is no support for re-segmentation in case the radio conditions change and trigger the selection of a smaller TB. Additionally, it provides PDU duplication detection and discards, out-of-sequence reordering, and loss detection.
* このモードは、ペイロードのセグメンテーションと連結をサポートします。RLCパケットのサイズは、下層層（MAC）によって特定の伝送の機会で与えられた適応症に依存し、オクテットアリグムです。受信機へのパケット配信には信頼性のサポートが含まれておらず、パケットからセグメントを失うと、完全なパケット損失があります。また、低層の再送信では、無線条件が変化し、より小さな結核の選択をトリガーした場合、再セグメント化のサポートはありません。さらに、PDUの重複検出と破棄、順序外の並べ替え、および損失検出を提供します。
* Acknowledged Mode (AM)
* 確認されたモード（AM）
* In addition to the same functions supported by UM, this mode also adds a moving windows-based reliability service on top of the lower-layer services. It also supports re-segmentation, and it requires bidirectional communication to exchange acknowledgment reports, called RLC Status Reports, and to trigger retransmissions. This model also supports protocol-error detection. The mode used depends on the operator configuration for the type of data to be transmitted. For example, data transmissions supporting mobility or requiring high reliability would be most likely configured using AM. Meanwhile, streaming and real-time data would be mapped to a UM configuration.
* UMでサポートされている同じ機能に加えて、このモードは、下層サービスの上に移動するWindowsベースの信頼性サービスも追加します。また、再セグメント化をサポートしており、RLCステータスレポートと呼ばれる承認レポートを交換し、再送信をトリガーするために双方向通信が必要です。このモデルは、プロトコルエラーの検出もサポートしています。使用されるモードは、送信されるデータのタイプの演算子構成によって異なります。たとえば、モビリティをサポートしたり、高い信頼性を必要とするデータ送信は、AMを使用して構成されている可能性が最も高くなります。一方、ストリーミングとリアルタイムのデータは、UM構成にマッピングされます。
MAC [TR36321] provides a mapping between the higher layers abstraction called Logical Channels (which are comprised by the previously described protocols) and the Physical Layer channels (transport channels). Additionally, MAC may multiplex packets from different Logical Channels and prioritize which ones to fit into one TB if there is data and space available to maximize data transmission efficiency. MAC also provides error correction and reliability support through Hybrid Automatic Repeat reQuest (HARQ), transport format selection, and scheduling information reported from the terminal to the network. MAC also adds the necessary padding and piggyback control elements, when possible, as well as the higher layers data.
MAC [TR36321]は、論理チャネル（前述のプロトコルで構成されている）と呼ばれる高層抽象抽象化と物理層チャネル（輸送チャネル）との間のマッピングを提供します。さらに、MACは、さまざまな論理チャネルから多重パケットをマルチプレックスし、データ送信効率を最大化するために利用可能なデータとスペースがある場合、1つのTBに適合するものを優先順位付けすることができます。MACは、ターミナルからネットワークに報告されたハイブリッドオートマチックリピートリクエスト（HARQ）、輸送形式の選択、およびスケジューリング情報を介して、エラー修正と信頼性のサポートも提供します。Macは、可能であれば、必要に応じて必要なパディングとピギーバック制御要素、および高層データも追加します。
<Max. 1600 bytes>
+---+ +---+ +------+
Application |AP1| |AP1| | AP2 |
(IP/Non-IP) |PDU| |PDU| | PDU |
+---+ +---+ +------+
| | | | | |
PDCP +--------+ +-------- +-----------+
|PDCP|AP1| |PDCP|AP1| |PDCP| AP2 |
|Head|PDU| |Head|PDU| |Head| PDU |
+--------+ +--------+ +--------+--\
| | | | | | | | |\ `--------\
+---------------------------+ | |(1)| `-------\(2)\
RLC |RLC |PDCP|AP1|RLC |PDCP|AP1| +-------------+ +----|---+
|Head|Head|PDU|Head|Head|PDU| |RLC |PDCP|AP2| |RLC |AP2|
+-------------|-------------+ |Head|Head|PDU| |Head|PDU|
| | | | | +---------|---+ +--------+
| | | LCID1 | | / / / / /
/ / / _/ _// _/ _/ / LCID2 /
| | | | | / _/ _/ / ___/
| | | | || | | / /
+------------------------------------------+ +-----------+---+
MAC |MAC|RLC|PDCP|AP1|RLC|PDCP|AP1|RLC|PDCP|AP2| |MAC|RLC|AP2|Pad|
|Hea|Hea|Hea |PDU|Hea|Hea |PDU|Hea|Hea |PDU| |Hea|Hea|PDU|din|
|der|der|der | |der|der | |der|der | | |der|der| |g |
+------------------------------------------+ +-----------+---+
TB1 TB2
(1) Segment One
(2) Segment Two
Figure 5: Example of User Plane Packet Encapsulation for Two Transport Blocks
図5：2つの輸送ブロックのユーザープレーンパケットカプセル化の例
The Access Stratum (AS) protocol stack used by DoNAS is specific because the radio network still needs to establish the security associations and reduce the protocol overhead so that the PDCP is bypassed until the AS security is activated. By default, RLC uses the AM. However, depending on the network's features and the terminal, RLC may change to other modes by the network operator. For example, the TM does not add any header nor process the payload to reduce the overhead, but the MTU would be limited by the TB used to transmit the data, which is a couple of thousand bits maximum. If UM (only terminals compatible with 3GPP Release 15 [R15-3GPP]) is used, the RLC mechanisms of reliability are disabled, and only the reliability provided by the MAC layer by HARQ is available. In this case, the protocol overhead might be smaller than the AM case because of the lack of status reporting, but the overhead would have the same support for segmentation up to 1600 bytes. NAS packets are encapsulated within an RRC [TS36331] message.
無線ネットワークがセキュリティ関連を確立し、プロトコルオーバーヘッドを削減して、ASセキュリティがアクティブ化されるまでPDCPがバイパスされるように、無線ネットワークがセキュリティ関連を確立し、プロトコルオーバーヘッドを削減する必要があるため、Donasが使用するアクセス層（AS）プロトコルスタックは具体的です。デフォルトでは、RLCはAMを使用します。ただし、ネットワークの機能と端末に応じて、RLCはネットワークオペレーターによって他のモードに変更される場合があります。たとえば、TMはヘッダーを追加したり、ペイロードを処理してオーバーヘッドを減らすことはありませんが、MTUはデータの送信に使用されるTBによって制限されます。これは最大数千ビットです。UM（3GPPリリース15 [R15-3GPP]と互換性のある端子のみ）が使用されている場合、信頼性のRLCメカニズムは無効になり、HARQがMACレイヤーによって提供される信頼性のみが利用可能です。この場合、ステータスレポートが不足しているため、プロトコルオーバーヘッドはAMの場合よりも小さくなる可能性がありますが、オーバーヘッドは最大1600バイトまでのセグメンテーションに同じサポートを持っています。NASパケットは、RRC [TS36331]メッセージ内にカプセル化されています。
Depending on the data type indication signaled (IP or Non-IP data), the network allocates an IP address or establishes a direct forwarding path. DoNAS is regulated under rate control upon previous agreement, meaning that a maximum number of bits per unit of time is agreed upon per device subscription beforehand and configured in the device. The use of DoNAS is typically expected when a terminal in a power-saving state requires a short transmission and is receiving an acknowledgment or short feedback from the network. Depending on the size of buffered data to be transmitted, the UE might be instructed to deploy the connected mode transmissions instead, limiting and controlling the DoNAS transmissions to predefined thresholds and a good resource optimization balance for the terminal and the network. The support for mobility of DoNAS is present but produces additional overhead.
シグナル付きのデータ型表示（IPまたは非IPデータ）に応じて、ネットワークはIPアドレスを割り当てるか、直接転送パスを確立します。DONASは、以前の契約に応じて料金管理下で規制されています。つまり、デバイスごとに最大時間単位のビット数が事前にデバイスのサブスクリプションごとに合意され、デバイスで構成されています。通常、DONAの使用は、電力状態の端末が短い送信を必要とし、ネットワークからの確認または短いフィードバックを受け取っている場合に予想されます。送信されるバッファーデータのサイズに応じて、UEは代わりに接続されたモード送信を展開するように指示され、Donas送信を定義済みのしきい値に制限および制御し、ターミナルとネットワークの優れたリソース最適化バランスを制限します。ドナスの移動性のサポートは存在しますが、追加のオーバーヘッドが生成されます。
+--------+ +--------+ +--------+
| | | | | | +-----------------+
| UE | | C-BS | | C-SGN | |Roaming Scenarios|
+----|---+ +--------+ +--------+ | +--------+ |
| | | | | | |
+----------------|------------|+ | | P-GW | |
| Attach | | +--------+ |
+------------------------------+ | | |
| | | | | |
+------|------------|--------+ | | | |
|RRC connection establishment| | | | |
|with NAS PDU transmission | | | | |
|& Ack Rsp | | | | |
+----------------------------+ | | | |
| | | | | |
| |Initial UE | | | |
| |message | | | |
| |----------->| | | |
| | | | | |
| | +---------------------+| | |
| | |Checks Integrity || | |
| | |protection, decrypts || | |
| | |data || | |
| | +---------------------+| | |
| | | Small data packet |
| | |------------------------------->
| | | Small data packet |
| | |<-------------------------------
| | +----------|---------+ | | |
| | Integrity protection,| | | |
| | encrypts data | | | |
| | +--------------------+ | | |
| | | | | |
| |Downlink NAS| | | |
| |message | | | |
| |<-----------| | | |
+-----------------------+ | | | |
|Small data delivery, | | | | |
|RRC connection release | | | | |
+-----------------------+ | | | |
| |
| |
+-----------------+
Figure 6: DoNAS Transmission Sequence from an Uplink Initiated Access
図6：UPLINK開始アクセスからのDONAS送信シーケンス
+---+ +---+ +---+ +----+
Application |AP1| |AP1| |AP2| |AP2 |
(IP/Non-IP) |PDU| |PDU| |PDU| ............... |PDU |
+---+ +---+ +---+ +----+
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| |/ / | \ | |
NAS /RRC +--------+---|---+----+ +---------+
|NAS/|AP1|AP1|AP2|NAS/| |NAS/|AP2 |
|RRC |PDU|PDU|PDU|RRC | |RRC |PDU |
+--------+-|-+---+----+ +---------|
| | | | |
| |\ | | |
|<--Max. 1600 bytes-->|__ |_ |
| | \__ \___ \_ \
| | \ \ \__ \
| | \ | | \_
+---------------|+-----|----------+ \ \
RLC |RLC | NAS/RRC ||RLC | NAS/RRC | +----|-------+
|Head| PDU(1/2)||Head | PDU (2/2)| |RLC |NAS/RRC|
+---------------++----------------+ |Head|PDU |
| | | \ | +------------+
| | LCID1 | \ | | /
| | | \ \ | |
| | | \ \ | |
| | | \ \ \ |
+----+----+----------++-----|----+---------++----+---------|---+
MAC |MAC |RLC | RLC ||MAC |RLC | RLC ||MAC | RLC |Pad|
|Head|Head| PAYLOAD ||Head |Head| PAYLOAD ||Head| PDU | |
+----+----+----------++-----+----+---------++----+---------+---+
TB1 TB2 TB3
Figure 7: Example of User Plane Packet Encapsulation for Data over NAS
図7：NAS上のデータのユーザープレーンパケットカプセル化の例
The authors would like to thank (in alphabetic order): Carles Gomez, Antti Ratilainen, Pascal Thubert, Tuomas Tirronen, and Éric Vyncke.
著者は、（アルファベット順に）カルルズ・ゴメス、アントティ・ラティライン、パスカル・ツバート、トゥオマス・ティレノン、エリック・ヴィンケに感謝したいと思います。
Edgar Ramos
Ericsson
Hirsalantie 11
FI-02420 Jorvas, Kirkkonummi
Finland
Email: edgar.ramos@ericsson.com
Ana Minaburo
Acklio
1137A Avenue des Champs Blancs
35510 Cesson-Sevigne Cedex
France
Email: ana@ackl.io