[要約] 要約： RFC 8724は、LPWANにおける静的コンテキストヘッダ圧縮（SCHC）とフラグメンテーションのためのUDP/IPv6への適用に関する規格です。この規格の目的は、LPWANネットワークでの効率的な通信を実現するために、ヘッダ圧縮とフラグメンテーションの手法を提供することです。
Internet Engineering Task Force (IETF) A. Minaburo
Request for Comments: 8724 Acklio
Category: Standards Track L. Toutain
ISSN: 2070-1721 IMT Atlantique
C. Gomez
Universitat Politecnica de Catalunya
D. Barthel
Orange Labs
JC. Zuniga
SIGFOX
April 2020
SCHC: Generic Framework for Static Context Header Compression and Fragmentation
SCHC：静的コンテキストヘッダーの圧縮と断片化のための一般的なフレームワーク
Abstract
概要
This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind.
このドキュメントは、ヘッダー圧縮メカニズムとオプションの断片化メカニズムの両方を提供する静的コンテキストヘッダー圧縮および断片化（SCHC）フレームワークを定義します。 SCHCは、低電力ワイドエリアネットワーク（LPWAN）を考慮して設計されています。
SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers.
SCHC圧縮は、LPWANデバイスとネットワークインフラストラクチャ側の両方に保存されている共通の静的コンテキストに基づいています。このドキュメントでは、IPv6 / UDPヘッダーを圧縮するための一般的なヘッダー圧縮メカニズムとそのアプリケーションを定義します。
This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size.
このドキュメントでは、オプションの断片化および再構成メカニズムも指定しています。これは、LPWANテクノロジーを介したIPv6 MTU要件をサポートするために使用できます。 SCHC圧縮後またはそのような圧縮ができなかった場合でも、レイヤ2の最大ペイロードサイズを超えるIPv6データグラムには、フラグメンテーションが必要です。
The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope.
SCHCヘッダーの圧縮と断片化のメカニズムは、それらが使用される特定のLPWANテクノロジーとは無関係です。このドキュメントは、一般的な機能を定義し、パラメータ設定とメカニズムの選択に関して柔軟性を提供します。このドキュメントは、2つのSCHCエンティティ間のLPWANを介した交換を標準化します。テクノロジまたは製品に固有の設定と選択は、他のドキュメントで指定されているプロファイルにグループ化されることが期待されます。コンテキストとプロファイルのデータモデルは範囲外です。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。これは公開レビューを受けており、Internet Engineering Steering Group（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/rfc8724.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8724で入手できます。
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. 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 Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction 2. Requirements Notation 3. LPWAN Architecture 4. Terminology 5. SCHC Overview 5.1. SCHC Packet Format 5.2. Functional Mapping 6. RuleID 7. Compression/Decompression 7.1. SCHC C/D Rules 7.2. Packet Processing 7.3. Matching Operators 7.4. Compression/Decompression Actions (CDA) 7.4.1. Processing Fixed-Length Fields 7.4.2. Processing Variable-Length Fields 7.4.3. Not-Sent CDA 7.4.4. Value-Sent CDA 7.4.5. Mapping-Sent CDA 7.4.6. LSB CDA 7.4.7. DevIID, AppIID CDA 7.4.8. Compute-* 8. Fragmentation/Reassembly 8.1. Overview 8.2. SCHC F/R Protocol Elements 8.2.1. Messages 8.2.2. Tiles, Windows, Bitmaps, Timers, Counters 8.2.3. Integrity Checking 8.2.4. Header Fields 8.3. SCHC F/R Message Formats 8.3.1. SCHC Fragment Format 8.3.2. SCHC ACK Format 8.3.3. SCHC ACK REQ Format 8.3.4. SCHC Sender-Abort Format 8.3.5. SCHC Receiver-Abort Format 8.4. SCHC F/R Modes 8.4.1. No-ACK Mode 8.4.2. ACK-Always Mode 8.4.3. ACK-on-Error Mode 9. Padding Management 10. SCHC Compression for IPv6 and UDP Headers 10.1. IPv6 Version Field 10.2. IPv6 Traffic Class Field 10.3. Flow Label Field 10.4. Payload Length Field 10.5. Next Header Field 10.6. Hop Limit Field 10.7. IPv6 Addresses Fields 10.7.1. IPv6 Source and Destination Prefixes 10.7.2. IPv6 Source and Destination IID 10.8. IPv6 Extension Headers 10.9. UDP Source and Destination Ports 10.10. UDP Length Field 10.11. UDP Checksum Field 11. IANA Considerations 12. Security Considerations 12.1. Security Considerations for SCHC Compression/Decompression 12.1.1. Forged SCHC Packet 12.1.2. Compressed Packet Size as a Side Channel to Guess a Secret Token 12.1.3. Decompressed Packet Different from the Original Packet 12.2. Security Considerations for SCHC Fragmentation/Reassembly 12.2.1. Buffer Reservation Attack 12.2.2. Corrupt Fragment Attack 12.2.3. Fragmentation as a Way to Bypass Network Inspection 12.2.4. Privacy Issues Associated with SCHC Header Fields 13. References 13.1. Normative References 13.2. Informative References Appendix A. Compression Examples Appendix B. Fragmentation Examples Appendix C. Fragmentation State Machines Appendix D. SCHC Parameters Appendix E. Supporting Multiple Window Sizes for Fragmentation Appendix F. ACK-Always and ACK-on-Error on Quasi-Bidirectional Links Acknowledgements Authors' Addresses
1. はじめに2.要件の表記3. LPWANアーキテクチャ4.用語5. SCHCの概要5.1。 SCHCパケット形式5.2。機能マッピング6. RuleID 7.圧縮/解凍7.1。 SCHC C / Dルール7.2。パケット処理7.3。マッチング演算子7.4。圧縮/解凍アクション（CDA）7.4.1。固定長フィールドの処理7.4.2。可変長フィールドの処理7.4.3。未送信CDA 7.4.4。バリューセンテッドCDA 7.4.5。マッピング送信済みCDA 7.4.6。 LSB CDA 7.4.7。 DevIID、AppIID CDA 7.4.8。計算-* 8.断片化/再構成8.1。概要8.2。 SCHC F / Rプロトコル要素8.2.1。メッセージ8.2.2。タイル、ウィンドウ、ビットマップ、タイマー、カウンター8.2.3。完全性チェック8.2.4。ヘッダーフィールド8.3。 SCHC F / Rメッセージ形式8.3.1。 SCHCフラグメントフォーマット8.3.2。 SCHC ACKフォーマット8.3.3。 SCHC ACK REQフォーマット8.3.4。 SCHC Sender-Abort Format 8.3.5。 SCHCレシーバー中止フォーマット8.4。 SCHC F / Rモード8.4.1。非ACKモード8.4.2。 ACK-Alwaysモード8.4.3。エラー時ACKモード9.パディング管理10. IPv6およびUDPヘッダーのSCHC圧縮10.1 IPv6バージョンフィールド10.2 IPv6トラフィッククラスフィールド10.3。フローラベルフィールド10.4。ペイロード長フィールド10.5。次のヘッダーフィールド10.6。ホップ限界フィールド10.7。 IPv6アドレスフィールド10.7.1。 IPv6ソースおよび宛先プレフィックス10.7.2。 IPv6ソースおよび宛先IID 10.8。 IPv6拡張ヘッダー10.9。 UDPソースおよび宛先ポート10.10。 UDP長さフィールド10.11。 UDPチェックサムフィールド11. IANAの考慮事項12.セキュリティの考慮事項12.1 SCHC圧縮/解凍のセキュリティに関する考慮事項12.1.1。偽造SCHCパケット12.1.2。シークレットトークンを推測するためのサイドチャネルとしての圧縮パケットサイズ12.1.3。元のパケットとは異なる解凍パケット12.2 SCHCフラグメンテーション/再構成のセキュリティに関する考慮事項12.2.1。バッファ予約攻撃12.2.2。破損フラグメント攻撃12.2.3。ネットワーク検査をバイパスする方法としてのフラグメンテーション12.2.4。 SCHCヘッダーフィールドに関連するプライバシーの問題13.参考資料13.1。規範的な参考文献13.2。有益な参考資料付録A.圧縮の例付録B.フラグメンテーションの例付録C.フラグメンテーションステートマシン付録D. SCHCパラメータ付録E.フラグメンテーションのための複数のウィンドウサイズのサポート付録F.準双方向リンクでのACK-AlwaysとACK-on-Error確認応答著者のアドレス
This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind.
このドキュメントは、ヘッダー圧縮メカニズムとオプションの断片化メカニズムの両方を提供する静的コンテキストヘッダー圧縮および断片化（SCHC）フレームワークを定義します。 SCHCは、低電力ワイドエリアネットワーク（LPWAN）を考慮して設計されています。
LPWAN technologies impose some strict limitations on traffic. For instance, devices sleep most of the time and may only receive data during short periods of time after transmission, in order to preserve battery. LPWAN technologies are also characterized by a greatly reduced data unit and/or payload size (see [RFC8376]).
LPWANテクノロジーは、トラフィックにいくつかの厳しい制限を課します。たとえば、バッテリーを節約するために、デバイスはほとんどの時間スリープし、送信後の短い期間のみデータを受信する場合があります。 LPWANテクノロジーは、データユニットやペイロードサイズが大幅に削減されていることも特徴です（[RFC8376]を参照）。
Header compression is needed for efficient Internet connectivity to a node within an LPWAN. The following properties of LPWANs can be exploited to get an efficient header compression:
ヘッダー圧縮は、LPWAN内のノードへの効率的なインターネット接続に必要です。 LPWANの次のプロパティを利用して、効率的なヘッダー圧縮を実現できます。
* The network topology is star-oriented, which means that all packets between the same source-destination pair follow the same path. For the needs of this document, the architecture can simply be described as Devices (Dev) exchanging information with LPWAN Application Servers (Apps) through a Network Gateway (NGW).
* ネットワークトポロジはスター指向です。つまり、同じ送信元と宛先のペア間のすべてのパケットは同じパスをたどります。このドキュメントのニーズに対して、アーキテクチャは、ネットワークゲートウェイ（NGW）を介してLPWANアプリケーションサーバー（アプリ）と情報を交換するデバイス（開発）として簡単に説明できます。
* Because devices embed built-in applications, the traffic flows to be compressed are known in advance. Indeed, new applications are less frequently installed in an LPWAN device than they are in a general-purpose computer or smartphone.
* デバイスには組み込みアプリケーションが組み込まれているため、圧縮されるトラフィックフローは事前にわかっています。実際、LPWANデバイスに新しいアプリケーションをインストールする頻度は、汎用のコンピューターやスマートフォンにインストールする場合よりも少なくなります。
SCHC compression uses a Context (a set of Rules) in which information about header fields is stored. This Context is static: the values of the header fields and the actions to do compression/decompression do not change over time. This avoids the need for complex resynchronization mechanisms. Indeed, a return path may be more restricted/expensive, or may sometimes be completely unavailable [RFC8376]. A compression protocol that relies on feedback is not compatible with the characteristics of such LPWANs.
SCHC圧縮は、ヘッダーフィールドに関する情報が格納されるコンテキスト（一連のルール）を使用します。このコンテキストは静的です。ヘッダーフィールドの値と圧縮/解凍を実行するアクションは、時間の経過とともに変化しません。これにより、複雑な再同期メカニズムの必要がなくなります。確かに、リターンパスはより制限された/高価な場合があり、完全に利用できない場合もあります[RFC8376]。フィードバックに依存する圧縮プロトコルは、そのようなLPWANの特性と互換性がありません。
In most cases, a small Rule identifier is enough to represent the full IPv6/UDP headers. The SCHC header compression mechanism is independent of the specific LPWAN technology over which it is used.
ほとんどの場合、小さなルール識別子は、完全なIPv6 / UDPヘッダーを表すのに十分です。 SCHCヘッダー圧縮メカニズムは、それが使用される特定のLPWANテクノロジーから独立しています。
Furthermore, some LPWAN technologies do not provide a fragmentation functionality; to support the IPv6 MTU requirement of 1280 bytes [RFC8200], they require a fragmentation protocol at the adaptation layer below IPv6. Accordingly, this document defines an optional fragmentation/reassembly mechanism to help LPWAN technologies support the IPv6 MTU requirement.
さらに、一部のLPWANテクノロジーはフラグメンテーション機能を提供しません。 1280バイトのIPv6 MTU要件[RFC8200]をサポートするには、IPv6の下のアダプテーション層でフラグメンテーションプロトコルが必要です。したがって、このドキュメントでは、LPWANテクノロジーがIPv6 MTU要件をサポートするのに役立つオプションのフラグメンテーション/再構成メカニズムを定義しています。
This document defines generic functionality and offers flexibility with regard to parameter settings and mechanism choices. Technology-specific settings are expected to be grouped into Profiles specified in other documents.
このドキュメントは、一般的な機能を定義し、パラメータ設定とメカニズムの選択に関して柔軟性を提供します。テクノロジー固有の設定は、他のドキュメントで指定されているプロファイルにグループ化されることが期待されています。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
LPWAN architectures are similar among them, but each LPWAN technology names architecture elements differently. In this document, we use terminology from [RFC8376], which identifies the following entities in a typical LPWAN (see Figure 1):
LPWANアーキテクチャはそれらの間で類似していますが、各LPWANテクノロジはアーキテクチャ要素に異なる名前を付けています。このドキュメントでは、[RFC8376]の用語を使用します。これは、一般的なLPWANの次のエンティティを識別します（図1を参照）。
* Devices (Dev) are the end-devices or hosts (e.g., sensors, actuators, etc.). There can be a very high density of devices per Radio Gateway.
* デバイス（Dev）は、エンドデバイスまたはホスト（センサー、アクチュエーターなど）です。無線ゲートウェイごとに非常に高密度のデバイスが存在する可能性があります。
* The Radio Gateway (RGW) is the endpoint of the constrained link.
* 無線ゲートウェイ（RGW）は、制約されたリンクのエンドポイントです。
* The Network Gateway (NGW) is the interconnection node between the Radio Gateway and the Internet.
* ネットワークゲートウェイ（NGW）は、無線ゲートウェイとインターネット間の相互接続ノードです。
* The Application Server (App) is the endpoint of the application-level protocol on the Internet side.
* アプリケーションサーバー（アプリ）は、インターネット側のアプリケーションレベルプロトコルのエンドポイントです。
() () () |
() () () () / \ +---------+
() () () () () () / \======| ^ | +-----------+
() () () | | <--|--> | |Application|
() () () () / \==========| v |=============| Server |
() () () / \ +---------+ +-----------+
Dev RGWs NGW App
Figure 1: LPWAN Architecture (Simplified from That Shown in RFC 8376)
図1：LPWANアーキテクチャ（RFC 8376に示されているものから簡略化）
This section defines terminology and abbreviations used in this document. It extends the terminology of [RFC8376].
このセクションでは、このドキュメントで使用されている用語と略語を定義します。 [RFC8376]の用語を拡張します。
The SCHC acronym is pronounced like "sheek" in English (or "chic" in French). Therefore, this document writes "a SCHC Packet" instead of "an SCHC Packet".
SCHCの頭字語は、英語では「sheek」（またはフランス語では「chic」）のように発音されます。したがって、このドキュメントでは、「SCHCパケット」ではなく「SCHCパケット」と記述しています。
App: LPWAN Application Server, as defined by [RFC8376]. It runs an application sending/receiving packets to/from the Dev.
アプリ：[RFC8376]で定義されているLPWANアプリケーションサーバー。 Devとの間でパケットを送受信するアプリケーションを実行します。
AppIID: Application Interface Identifier. The IID that identifies the App interface.
AppIID：アプリケーションインターフェイス識別子。アプリインターフェイスを識別するIID。
Compression Residue: The bits that remain to be sent (beyond the RuleID itself) after applying the SCHC compression.
圧縮残差：SCHC圧縮を適用した後、（RuleID自体を超えて）送信される残りのビット。
Context: A set of Rules used to compress/decompress headers, or to fragment/reassemble a packet.
コンテキスト：ヘッダーの圧縮/解凍、またはパケットのフラグメント化/再構成に使用される一連のルール。
Dev: Device, as defined by [RFC8376].
Dev：[RFC8376]で定義されているデバイス。
DevIID: Device Interface Identifier. The IID that identifies the Dev interface.
DevIID：デバイスインターフェイス識別子。 Devインターフェースを識別するIID。
Downlink: From the App to the Dev.
ダウンリンク：アプリから開発者へ。
IID: Interface Identifier. See the IPv6 addressing architecture [RFC7136].
IID：インターフェース識別子。 IPv6アドレス指定アーキテクチャ[RFC7136]を参照してください。
L2: Layer 2. The immediate lower layer that SCHC interfaces with, for example an underlying LPWAN technology. It does not necessarily correspond to the OSI model definition of Layer 2.
L2：レイヤー2。SCHCがインターフェースするすぐ下のレイヤー。たとえば、基礎となるLPWANテクノロジー。レイヤー2のOSIモデル定義に必ずしも対応していません。
L2 Word: This is the minimum subdivision of payload data that the L2 will carry. In most L2 technologies, the L2 Word is an octet. In bit-oriented radio technologies, the L2 Word might be a single bit. The L2 Word size is assumed to be constant over time for each device.
L2ワード：これは、L2が運ぶペイロードデータの最小サブディビジョンです。ほとんどのL2テクノロジーでは、L2ワードはオクテットです。ビット指向の無線技術では、L2ワードは単一ビットである場合があります。 L2ワードサイズは、デバイスごとに一定であると想定されます。
Padding: Extra bits that may be appended by SCHC to a data unit that it passes down to L2 for transmission. SCHC itself operates on bits, not bytes, and does not have any alignment prerequisite. See Section 9.
パディング：SCHCによって、送信のためにL2に渡されるデータユニットに追加される追加のビット。 SCHC自体はバイトではなくビットで動作し、アライメントの前提条件はありません。セクション9を参照してください。
Profile: SCHC offers variations in the way it is operated, with a number of parameters listed in Appendix D. A Profile indicates a particular setting of all these parameters. Both ends of a SCHC communication must be provisioned with the same Profile information and with the same set of Rules before the communication starts, so that there is no ambiguity in how they expect to communicate.
プロファイル：SCHCは、操作方法のバリエーションを提供します。付録Dにいくつかのパラメーターがリストされています。プロファイルは、これらすべてのパラメーターの特定の設定を示します。 SCHC通信の両端には、通信の開始前に、同じプロファイル情報と同じルールセットをプロビジョニングする必要があります。これにより、通信がどのように行われるかが明確になります。
Rule: Part of the Context that describes how a packet is compressed/decompressed or fragmented/reassembled.
ルール：パケットがどのように圧縮/解凍またはフラグメント化/再構成されるかを説明するコンテキストの一部。
RuleID: Rule Identifier. An identifier for a Rule.
RuleID：ルール識別子。ルールの識別子。
SCHC: Static Context Header Compression and fragmentation (SCHC), a generic framework.
SCHC：Static Context Header Compression and Fragmentation（SCHC）、一般的なフレームワーク。
SCHC C/D: SCHC Compressor/Decompressor, or SCHC Compression/ Decompression. The SCHC entity or mechanism used on both sides, at the Dev and at the network, to achieve compression/decompression of headers.
SCHC C / D：SCHC Compressor / Decompressor、またはSCHC Compression / Decompression。ヘッダーの圧縮/解凍を実現するために、開発側とネットワーク側の両方で使用されるSCHCエンティティまたはメカニズム。
SCHC F/R: SCHC Fragmenter/Reassembler or SCHC Fragmentation/ Reassembly. The SCHC entity or mechanism used on both sides, at the Dev and at the network, to achieve fragmentation/reassembly of SCHC Packets.
SCHC F / R：SCHC Fragmenter / ReassemblerまたはSCHC Fragmentation / Reassembly。 SCHCパケットの断片化/再構成を実現するために、開発側とネットワーク側の両方で使用されるSCHCエンティティまたはメカニズム。
SCHC Packet: A packet (e.g., an IPv6 packet) whose header has been compressed as per the header compression mechanism defined in this document. If the header compression process is unable to actually compress the packet header, the packet with the uncompressed header is still called a SCHC Packet (in this case, a RuleID is used to indicate that the packet header has not been compressed). See Section 7 for more details.
SCHCパケット：このドキュメントで定義されているヘッダー圧縮メカニズムに従ってヘッダーが圧縮されたパケット（IPv6パケットなど）。ヘッダー圧縮プロセスで実際にパケットヘッダーを圧縮できない場合でも、非圧縮ヘッダーを含むパケットはSCHCパケットと呼ばれます（この場合、RuleIDはパケットヘッダーが圧縮されていないことを示すために使用されます）。詳細については、セクション7を参照してください。
Uplink: From the Dev to the App.
アップリンク：開発からアプリへ。
Additional terminology for the optional SCHC F/R is found in Section 8.2.
オプションのSCHC F / Rの追加の用語については、セクション8.2を参照してください。
Additional terminology for SCHC C/D is found in Section 7.1.
SCHC C / Dのその他の用語については、セクション7.1を参照してください。
SCHC can be characterized as an adaptation layer between an upper layer (for example, IPv6) and an underlying layer (for example, an LPWAN technology). SCHC comprises two sublayers (i.e., the Compression sublayer and the Fragmentation sublayer), as shown in Figure 2.
SCHCは、上位層（IPv6など）と基礎となる層（LPWANテクノロジなど）の間のアダプテーション層として特徴付けることができます。 SCHCは、図2に示すように、2つのサブレイヤー（つまり、圧縮サブレイヤーと断片化サブレイヤー）で構成されています。
+----------------+
| IPv6 |
+- +----------------+
| | Compression |
SCHC < +----------------+
| | Fragmentation |
+- +----------------+
|LPWAN technology|
+----------------+
Figure 2: Example of Protocol Stack Comprising IPv6, SCHC, and an LPWAN Technology
図2：IPv6、SCHC、およびLPWANテクノロジで構成されるプロトコルスタックの例
Before an upper layer packet (e.g., an IPv6 packet) is transmitted to the underlying layer, header compression is first attempted. The resulting packet is called a "SCHC Packet", whether or not any compression is performed. If needed by the underlying layer, the optional SCHC fragmentation MAY be applied to the SCHC Packet. The inverse operations take place at the receiver. This process is illustrated in Figure 3.
上位層パケット（IPv6パケットなど）が基礎となる層に送信される前に、ヘッダー圧縮が最初に試行されます。結果のパケットは、圧縮が実行されるかどうかに関係なく、「SCHCパケット」と呼ばれます。下層で必要な場合は、オプションのSCHCフラグメンテーションをSCHCパケットに適用できます（MAY）。逆の操作は受信機で行われます。このプロセスを図3に示します。
A packet (e.g., an IPv6 packet)
| ^
v |
+------------------+ +--------------------+
| SCHC Compression | | SCHC Decompression |
+------------------+ +--------------------+
| ^
| If no fragmentation (*) |
+-------------- SCHC Packet -------------->|
| |
v |
+--------------------+ +-----------------+
| SCHC Fragmentation | | SCHC Reassembly |
+--------------------+ +-----------------+
| ^ | ^
| | | |
| +---------- SCHC ACK (+) -------------+ |
| |
+-------------- SCHC Fragments -------------------+
Sender Receiver
送信者受信者
*: the decision not to use SCHC fragmentation is left to each Profile
+: optional, depends on Fragmentation mode
Figure 3: SCHC Operations at the Sender and the Receiver
図3：送信者と受信者でのSCHC操作
The SCHC Packet is composed of the Compressed Header followed by the payload from the original packet (see Figure 4). The Compressed Header itself is composed of the RuleID and a Compression Residue, which is the output of compressing the packet header with the Rule identified by that RuleID (see Section 7). The Compression Residue may be empty. Both the RuleID and the Compression Residue potentially have a variable size, and are not necessarily a multiple of bytes in size.
SCHCパケットは、圧縮ヘッダーと、それに続く元のパケットからのペイロードで構成されます（図4を参照）。圧縮ヘッダー自体は、RuleIDとCompression Residueで構成されます。これは、そのRuleIDで識別されるルールでパケットヘッダーを圧縮した出力です（セクション7を参照）。圧縮残差が空である可能性があります。 RuleIDとCompression Residueはどちらもサイズが可変である可能性があり、サイズがバイトの倍数であるとは限りません。
|------- Compressed Header -------|
+---------------------------------+--------------------+
| RuleID | Compression Residue | Payload |
+---------------------------------+--------------------+
Figure 4: SCHC Packet
図4：SCHCパケット
Figure 5 maps the functional elements of Figure 3 onto the LPWAN architecture elements of Figure 1.
図5は、図3の機能要素を図1のLPWANアーキテクチャ要素にマッピングしています。
Dev App
+----------------+ +----+ +----+ +----+
| App1 App2 App3 | |App1| |App2| |App3|
| | | | | | | |
| UDP | |UDP | |UDP | |UDP |
| IPv6 | |IPv6| |IPv6| |IPv6|
| | | | | | | |
|SCHC C/D and F/R| | | | | | |
+--------+-------+ +----+ +----+ +----+
| +---+ +---+ +----+ +----+ . . .
+~ |RGW| === |NGW| == |SCHC| == |SCHC|..... Internet ....
+---+ +---+ |F/R | |C/D |
+----+ +----+
Figure 5: Architectural Mapping
図5：アーキテクチャマッピング
SCHC C/D and SCHC F/R are located on both sides of the LPWAN transmission, hereafter called the "Dev side" and the "Network Infrastructure side".
SCHC C / DおよびSCHC F / Rは、LPWAN伝送の両側に配置されます。以降、「Dev側」および「Network Infrastructure側」と呼びます。
The operation in the Uplink direction is as follows. The Device application uses IPv6 or IPv6/UDP protocols. Before sending the packets, the Dev compresses their headers using SCHC C/D; if the SCHC Packet resulting from the compression needs to be fragmented by SCHC, SCHC F/R is performed (see Section 8). The resulting SCHC Fragments are sent to an LPWAN Radio Gateway (RGW), which forwards them to a Network Gateway (NGW). The NGW sends the data to a SCHC F/R for reassembly (if needed) and then to the SCHC C/D for decompression. After decompression, the packet can be sent over the Internet to one or several Apps.
アップリンク方向の操作は次のとおりです。デバイスアプリケーションはIPv6またはIPv6 / UDPプロトコルを使用します。パケットを送信する前に、DevはSCHC C / Dを使用してヘッダーを圧縮します。圧縮の結果生じたSCHCパケットをSCHCでフラグメント化する必要がある場合、SCHC F / Rが実行されます（セクション8を参照）。結果のSCHCフラグメントは、LPWAN無線ゲートウェイ（RGW）に送信され、ネットワークゲートウェイ（NGW）に転送されます。 NGWは、データをSCHC F / Rに送信して再構成し（必要な場合）、次にSCHC C / Dに送信して解凍します。解凍後、パケットをインターネット経由で1つまたは複数のアプリに送信できます。
The SCHC F/R and SCHC C/D on the Network Infrastructure side can be part of the NGW or located in the Internet as long as a tunnel is established between them and the NGW. For some LPWAN technologies, it may be suitable to locate the SCHC F/R functionality nearer the NGW, in order to better deal with time constraints of such technologies.
ネットワークインフラストラクチャ側のSCHC F / RおよびSCHC C / Dは、それらとNGWの間にトンネルが確立されている限り、NGWの一部であるか、インターネットに配置できます。一部のLPWANテクノロジでは、このようなテクノロジの時間的制約により適切に対処するために、NGCの近くにSCHC F / R機能を配置することが適切な場合があります。
The SCHC C/Ds on both sides MUST share the same set of Rules. So MUST the SCHC F/Rs on both sides.
両側のSCHC C / Dは、同じルールセットを共有する必要があります。したがって、両側のSCHC F / Rが必要です。
The operation in the Downlink direction is similar to that in the Uplink direction, only reversing the order in which the architecture elements are traversed.
ダウンリンク方向の操作は、アップリンク方向の操作と似ていますが、アーキテクチャ要素がトラバースされる順序を逆にしているだけです。
RuleIDs identify the Rules used for compression/decompression or for fragmentation/reassembly.
RuleIDは、圧縮/解凍または断片化/再構成に使用されるルールを識別します。
The scope of the RuleID of a compression/decompression Rule is the link between the SCHC C/D in a given Dev and the corresponding SCHC C/D in the Network Infrastructure side. The scope of the RuleID of a fragmentation/reassembly Rule is the link between the SCHC F/R in a given Dev and the corresponding SCHC F/R in the Network Infrastructure side. If such a link is bidirectional, the scope includes both directions.
圧縮/解凍ルールのRuleIDのスコープは、特定のDevのSCHC C / Dと、ネットワークインフラストラクチャ側の対応するSCHC C / Dの間のリンクです。断片化/再構成ルールのRuleIDのスコープは、特定のDevのSCHC F / Rと、ネットワークインフラストラクチャ側の対応するSCHC F / Rの間のリンクです。そのようなリンクが双方向の場合、スコープには両方向が含まれます。
The RuleIDs are therefore specific to the Context related to one Dev. Hence, multiple Dev instances, which refer to different Contexts, MAY reuse the same RuleID for different Rules. On the Network Infrastructure side, in order to identify the correct Rule to be applied to Uplink traffic, the SCHC C/D or SCHC F/R needs to associate the RuleID with the Dev identifier. Similarly, for Downlink traffic, the SCHC C/D or SCHC F/R on the Network Infrastructure side first needs to identify the destination Dev before looking for the appropriate Rule (and associated RuleID) in the Context of that Dev.
したがって、RuleIDは、1つのDevに関連するコンテキストに固有です。したがって、異なるコンテキストを参照する複数のDevインスタンスは、異なるRuleに対して同じRuleIDを再利用できます。ネットワークインフラストラクチャ側では、アップリンクトラフィックに適用される正しいルールを識別するために、SCHC C / DまたはSCHC F / RはRuleIDをDev識別子に関連付ける必要があります。同様に、ダウンリンクトラフィックの場合、ネットワークインフラストラクチャ側のSCHC C / DまたはSCHC F / Rは、そのDevのコンテキストで適切なルール（および関連するRuleID）を探す前に、まず宛先Devを識別する必要があります。
Inside their scopes, Rules for compression/decompression and Rules for fragmentation/reassembly share the same RuleID space.
スコープ内では、圧縮/解凍のルールと断片化/再構成のルールが同じRuleIDスペースを共有します。
The size of the RuleIDs is not specified in this document, as it is implementation-specific and can vary according to the LPWAN technology and the number of Rules, among other things. It is defined in Profiles.
RuleIDのサイズは、実装固有であり、特にLPWANテクノロジーやルールの数によって異なるため、このドキュメントでは指定されていません。これはプロファイルで定義されます。
The RuleIDs are used:
RuleIDが使用されます。
* For SCHC C/D, to identify the Rule that is used to compress a packet header.
* SCHC C / Dの場合、パケットヘッダーの圧縮に使用されるルールを識別します。
- At least one RuleID MUST be allocated to tagging packets for which SCHC compression was not possible (i.e., no matching compression Rule was found).
- SCHC圧縮ができなかった（つまり、一致する圧縮ルールが見つからなかった）タグ付けパケットには、少なくとも1つのRuleIDを割り当てる必要があります。
* In SCHC F/R, to identify the specific mode and settings of fragmentation/reassembly for one direction of data traffic (Uplink or Downlink).
* SCHC F / Rで、データトラフィックの一方向（アップリンクまたはダウンリンク）のフラグメンテーション/再構成の特定のモードと設定を識別するため。
- When SCHC F/R is used for both communication directions, at least two RuleID values are needed for fragmentation/ reassembly: one per direction of data traffic. This is because fragmentation/reassembly may entail control messages flowing in the reverse direction compared to data traffic.
- SCHC F / Rが両方の通信方向に使用される場合、断片化/再構成には少なくとも2つのRuleID値が必要です。データトラフィックの方向ごとに1つです。これは、断片化/再構成により、データトラフィックと比較して制御メッセージが逆方向に流れる可能性があるためです。
Compression with SCHC is based on using a set of Rules, which constitutes the Context of SCHC C/D, to compress or decompress headers. SCHC avoids Context synchronization traffic, which consumes considerable bandwidth in other header compression mechanisms such as RObust Header Compression (RoHC) [RFC5795]. Since the content of packets is highly predictable in LPWANs, static Contexts can be stored beforehand. The Contexts MUST be stored at both ends, and they can be learned by a provisioning protocol, by out-of-band means, or by pre-provisioning. The way the Contexts are provisioned is out of the scope of this document.
SCHCによる圧縮は、SCHC C / Dのコンテキストを構成する一連のルールを使用してヘッダーを圧縮または解凍することに基づいています。 SCHCは、RObust Header Compression（RoHC）[RFC5795]などの他のヘッダー圧縮メカニズムでかなりの帯域幅を消費するコンテキスト同期トラフィックを回避します。パケットの内容はLPWANで非常に予測可能であるため、静的コンテキストを事前に保存できます。コンテキストは両端に保存する必要があり、プロビジョニングプロトコル、アウトオブバンド手段、または事前プロビジョニングによって学習できます。コンテキストのプロビジョニング方法は、このドキュメントの範囲外です。
The main idea of the SCHC compression scheme is to transmit the RuleID to the other end instead of sending known field values. This RuleID identifies a Rule that matches the original packet values. Hence, when a value is known by both ends, it is only necessary to send the corresponding RuleID over the LPWAN. The manner by which Rules are generated is out of the scope of this document. The Rules MAY be changed at run-time, but the mechanism is out of scope of this document.
SCHC圧縮方式の主なアイデアは、既知のフィールド値を送信する代わりに、RuleIDを相手側に送信することです。このRuleIDは、元のパケット値と一致するルールを識別します。したがって、両端で値がわかっている場合は、対応するRuleIDをLPWAN経由で送信するだけで済みます。ルールの生成方法は、このドキュメントの範囲外です。ルールは実行時に変更される場合がありますが、メカニズムはこのドキュメントの範囲外です。
The SCHC C/D Context is a set of Rules. See Figure 6 for a high-level, abstract representation of the Context. The formal specification of the representation of the Rules is outside the scope of this document.
SCHC C / Dコンテキストは一連のルールです。コンテキストの高レベルの抽象的な表現については、図6を参照してください。ルールの表現の正式な仕様は、このドキュメントの範囲外です。
Each Rule itself contains a list of Field Descriptors composed of a Field Identifier (FID), a Field Length (FL), a Field Position (FP), a Direction Indicator (DI), a Target Value (TV), a Matching Operator (MO), and a Compression/Decompression Action (CDA).
各ルール自体には、フィールド識別子（FID）、フィールド長（FL）、フィールド位置（FP）、方向インジケーター（DI）、ターゲット値（TV）、マッチング演算子（ MO）、および圧縮/解凍アクション（CDA）。
/-----------------------------------------------------------------\
| Rule N |
/-----------------------------------------------------------------\|
| Rule i ||
/-----------------------------------------------------------------\||
| (FID) Rule 1 |||
|+-------+--+--+--+------------+-----------------+---------------+|||
||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||||
|+-------+--+--+--+------------+-----------------+---------------+|||
||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||||
|+-------+--+--+--+------------+-----------------+---------------+|||
||... |..|..|..| ... | ... | ... ||||
|+-------+--+--+--+------------+-----------------+---------------+||/
||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||
|+-------+--+--+--+------------+-----------------+---------------+|/
| |
\-----------------------------------------------------------------/
Figure 6: A SCHC C/D Context
図6：SCHC C / Dコンテキスト
A Rule does not describe how the compressor parses a packet header to find and identify each field (e.g., the IPv6 Source Address, the UDP Destination Port, or a CoAP URI path option). It is assumed that there is a protocol parser alongside SCHC that is able to identify all the fields encountered in the headers to be compressed, and to label them with a Field ID. Rules only describe the compression/ decompression behavior for each header field, after it has been identified.
ルールでは、コンプレッサーがパケットヘッダーを解析して各フィールド（IPv6送信元アドレス、UDP宛先ポート、CoAP URIパスオプションなど）を見つけて識別する方法は記述されていません。 SCHCの横に、圧縮するヘッダーで検出されたすべてのフィールドを識別し、それらにフィールドIDのラベルを付けることができるプロトコルパーサーがあると想定されています。ルールは、識別された後の各ヘッダーフィールドの圧縮/解凍動作のみを説明します。
In a Rule, the Field Descriptors are listed in the order in which the fields appear in the packet header. The Field Descriptors describe the header fields with the following entries:
ルールでは、フィールド記述子は、フィールドがパケットヘッダーに表示される順序でリストされます。フィールド記述子は、次のエントリでヘッダーフィールドを記述します。
* Field Identifier (FID) designates a protocol and field (e.g., UDP Destination Port), unambiguously among all protocols that a SCHC compressor processes. In the presence of protocol nesting, the Field ID also identifies the nesting.
* フィールド識別子（FID）は、SCHCコンプレッサーが処理するすべてのプロトコル間で、プロトコルとフィールド（UDP宛先ポートなど）を明確に指定します。プロトコルのネストが存在する場合、フィールドIDはネストも識別します。
* Field Length (FL) represents the length of the original field. It can be either a fixed value (in bits) if the length is known when the Rule is created or a type if the length is variable. The length of a header field is defined by its own protocol specification (e.g., IPv6 or UDP). If the length is variable, the type defines the process to compute the length and its unit (bits, bytes...).
* フィールド長（FL）は、元のフィールドの長さを表します。ルールの作成時に長さがわかっている場合は固定値（ビット単位）にするか、長さが可変の場合はタイプにすることができます。ヘッダーフィールドの長さは、独自のプロトコル仕様（IPv6やUDPなど）によって定義されます。長さが可変の場合、タイプは長さとその単位（ビット、バイト...）を計算するプロセスを定義します。
* Field Position (FP): most often, a field only occurs once in a packet header. However, some fields may occur multiple times. An example is the uri-path of CoAP. FP indicates which occurrence this Field Descriptor applies to. The default value is 1. The value 1 designates the first occurrence. The value 0 is special. It means "don't care", see Section 7.2.
* フィールド位置（FP）：ほとんどの場合、フィールドはパケットヘッダーで1回だけ発生します。ただし、一部のフィールドは複数回発生する場合があります。例はCoAPのuriパスです。 FPは、このフィールド記述子が適用されるオカレンスを示します。デフォルト値は1です。値1は最初の発生を示します。値0は特別です。 「気にしない」という意味です。セクション7.2を参照してください。
* A Direction Indicator (DI) indicates the packet direction(s) this Field Descriptor applies to. It allows for asymmetric processing, using the same Rule. Three values are possible:
* 方向インジケーター（DI）は、このフィールド記述子が適用されるパケットの方向を示します。同じルールを使用して、非対称処理を可能にします。 3つの値が可能です。
Up: this Field Descriptor is only applicable to packets traveling Uplink.
Up：このフィールド記述子は、アップリンクを移動するパケットにのみ適用されます。
Dw: this Field Descriptor is only applicable to packets traveling Downlink.
Dw：このフィールド記述子は、ダウンリンクを移動するパケットにのみ適用されます。
Bi: this Field Descriptor is applicable to packets traveling Uplink or Downlink.
Bi：このフィールド記述子は、アップリンクまたはダウンリンクを移動するパケットに適用できます。
* Target Value (TV) is the value used to match against the packet header field. The Target Value can be a scalar value of any type (integer, strings, etc.) or a more complex structure (array, list, etc.). The types and representations are out of scope for this document.
* ターゲット値（TV）は、パケットヘッダーフィールドとの照合に使用される値です。ターゲット値は、任意のタイプ（整数、文字列など）またはより複雑な構造（配列、リストなど）のスカラー値にすることができます。型と表現はこのドキュメントの範囲外です。
* Matching Operator (MO) is the operator used to match the field value and the Target Value. The Matching Operator may require some parameters. The set of MOs defined in this document can be found in Section 7.3.
* 一致演算子（MO）は、フィールド値とターゲット値を一致させるために使用される演算子です。一致演算子には、いくつかのパラメータが必要な場合があります。このドキュメントで定義されているMOのセットは、セクション7.3にあります。
* Compression/Decompression Action (CDA) describes the pair of actions that are performed at the compressor to compress a header field and at the decompressor to recover the original value of the header field. Some CDAs might use parameter values for their operation. The set of CDAs defined in this document can be found in Section 7.4.
* 圧縮/解凍アクション（CDA）は、ヘッダーフィールドを圧縮するためにコンプレッサーで実行され、ヘッダーフィールドの元の値を復元するためにデコンプレッサーで実行されるアクションのペアを示します。一部のCDAは、操作にパラメーター値を使用する場合があります。このドキュメントで定義されているCDAのセットは、セクション7.4にあります。
The compression/decompression process follows several phases:
圧縮/解凍プロセスは、いくつかのフェーズに従います。
Compression Rule selection: the general idea is to browse the Rule set to find a Rule that has a matching Field Descriptor (given the DI and FP) for all and only those header fields that appear in the packet being compressed. The detailed algorithm is the following:
圧縮ルールの選択：一般的なアイデアは、ルールセットを参照して、圧縮されるパケットに表示されるすべてのヘッダーフィールドのみに一致するフィールド記述子（DIおよびFPが指定されている）を持つルールを見つけることです。詳細なアルゴリズムは次のとおりです。
* The first step is to check the FIDs. If any header field of the packet being examined cannot be matched with a Field Descriptor with the correct FID, the Rule MUST be disregarded. If any Field Descriptor in the Rule has a FID that cannot be matched to one of the header fields of the packet being examined, the Rule MUST be disregarded.
* 最初のステップは、FIDをチェックすることです。検査されているパケットのヘッダーフィールドが、正しいFIDを持つフィールド記述子と一致しない場合、ルールは無視される必要があります。ルール内のいずれかのフィールド記述子に、検査対象のパケットのヘッダーフィールドの1つと照合できないFIDがある場合、ルールは無視する必要があります。
* The next step is to match the Field Descriptors by their direction, using the DI. If any field of the packet header cannot be matched with a Field Descriptor with the correct FID and DI, the Rule MUST be disregarded.
* 次のステップは、DIを使用して、方向によってフィールド記述子を照合することです。パケットヘッダーのフィールドが、正しいFIDおよびDIを持つフィールド記述子と一致しない場合、ルールは無視されなければなりません（MUST）。
* Then, the Field Descriptors are further selected according to FP. If any field of the packet header cannot be matched with a Field Descriptor with the correct FID, DI and FP, the Rule MUST be disregarded.
* 次に、FPに従ってフィールド記述子がさらに選択されます。パケットヘッダーのフィールドが、正しいFID、DI、およびFPのフィールド記述子と一致しない場合は、ルールを無視する必要があります。
The value 0 for FP means "don't care", i.e., the comparison of this Field Descriptor's FP with the position of the field of the packet header being compressed returns True, whatever that position. FP=0 can be useful to build compression Rules for protocol headers in which some fields order is irrelevant. An example could be uri-queries in CoAP. Care needs to be exercised when writing Rules containing FP=0 values. Indeed, it may result in decompressed packets having fields ordered differently compared to the original packet.
FPの値0は「ドントケア」を意味します。つまり、このフィールド記述子のFPと、圧縮されるパケットヘッダーのフィールドの位置との比較は、その位置に関係なくTrueを返します。 FP = 0は、一部のフィールドの順序が無関係なプロトコルヘッダーの圧縮ルールを作成するのに役立ちます。 CoAPのURIクエリがその例です。 FP = 0の値を含むルールを作成するときは注意が必要です。実際、元のパケットとは異なる順序でフィールドが並べられた、解凍されたパケットが生じる可能性があります。
* Once each header field has been associated with a Field Descriptor with matching FID, DI, and FP, each packet field's value is then compared to the corresponding TV stored in the Rule for that specific field, using the MO. If every field in the packet header satisfies the corresponding MOs of a Rule (i.e., all MO results are True), that Rule is valid for use to compress the header. Otherwise, the Rule MUST be disregarded.
* 各ヘッダーフィールドが、一致するFID、DI、およびFPを持つフィールド記述子に関連付けられると、各パケットフィールドの値は、MOを使用して、その特定のフィールドのルールに格納されている対応するTVと比較されます。パケットヘッダーのすべてのフィールドがルールの対応するMOを満たしている場合（つまり、すべてのMOの結果がTrueの場合）、そのルールはヘッダーの圧縮に使用できます。それ以外の場合、ルールは無視する必要があります。
This specification does not prevent multiple Rules from matching the above steps and, therefore, being valid for use. Which Rule to use among multiple valid Rules is left to the implementation. As long as the same Rule set is installed at both ends, this degree of freedom does not constitute an interoperability issue.
この仕様は、複数のルールが上記の手順と一致することを妨げないため、使用に有効です。複数の有効なルールの中からどのルールを使用するかは実装に任されています。同じルールセットが両端にインストールされている限り、この自由度は相互運用性の問題を構成しません。
* If no valid compression Rule is found, then the packet MUST be sent uncompressed using the RuleID dedicated to this purpose (see Section 6). The entire packet header is the Compression Residue (see Figure 4). Sending an uncompressed header is likely to require SCHC F/R.
* 有効な圧縮ルールが見つからない場合は、この目的専用のRuleIDを使用してパケットを圧縮せずに送信する必要があります（セクション6を参照）。パケットヘッダー全体が圧縮残差です（図4を参照）。非圧縮ヘッダーを送信するには、SCHC F / Rが必要になる可能性があります。
Compression: if a valid Rule is found, each field of the header is compressed according to the CDAs of the Rule. The fields are compressed in the order that the Field Descriptors appear in the Rule. The compression of each field results in a residue, which may be empty. The Compression Residue for the packet header is the concatenation of the non-empty residues for each field of the header, in the order the Field Descriptors appear in the Rule. The order in which the Field Descriptors appear in the Rule is therefore semantically important.
圧縮：有効なルールが見つかった場合、ヘッダーの各フィールドは、ルールのCDAに従って圧縮されます。フィールドは、フィールド記述子がルールに表示される順序で圧縮されます。各フィールドの圧縮により、空になる場合がある残差が生じます。パケットヘッダーの圧縮残差は、ヘッダーにある各フィールドの空ではない残差を、フィールド記述子がルールに表示される順序で連結したものです。したがって、フィールド記述子がルールに現れる順序は、意味的に重要です。
|------------------- Compression Residue -------------------|
+-----------------+-----------------+-----+-----------------+
| field 1 residue | field 2 residue | ... | field N residue |
+-----------------+-----------------+-----+-----------------+
Figure 7: Compression Residue Structure
図7：圧縮残差の構造
Sending: The RuleID is sent to the other end jointly with the Compression Residue (which could be empty) or the uncompressed header, and directly followed by the payload (see Figure 4). The way the RuleID is sent will be specified in the Profile and is out of the scope of the present document. For example, it could be included in an L2 header or sent as part of the L2 payload.
送信：RuleIDは、圧縮残差（空の場合もあります）または非圧縮ヘッダーと一緒に相手側に送信され、その後にペイロードが直接続きます（図4を参照）。 RuleIDの送信方法はプロファイルで指定され、現在のドキュメントの範囲外です。たとえば、L2ヘッダーに含めたり、L2ペイロードの一部として送信したりできます。
Decompression: when decompressing, on the Network Infrastructure side, the SCHC C/D needs to find the correct Rule based on the L2 address of the Dev. On the Dev side, only the RuleID is needed to identify the correct Rule since the Dev typically only holds Rules that apply to itself.
解凍：解凍するとき、ネットワークインフラストラクチャ側で、SCHC C / DはDevのL2アドレスに基づいて正しいルールを見つける必要があります。 Dev側では、Devは通常、自身に適用されるルールのみを保持するため、正しいルールを識別するためにRuleIDのみが必要です。
This Rule describes the compressed header format. From this, the decompressor determines the order of the residues, the fixed-size or variable-size nature of each residue (see Section 7.4.2), and the size of the fixed-size residues.
このルールは、圧縮されたヘッダー形式を記述します。これから、デコンプレッサは、残基の順序、各残基の固定サイズまたは可変サイズの性質（セクション7.4.2を参照）、および固定サイズの残基のサイズを決定します。
Therefore, from the received compressed header, it can retrieve all the residue values and associate them to the corresponding header fields.
したがって、受信した圧縮ヘッダーから、すべての残差値を取得して、対応するヘッダーフィールドに関連付けることができます。
For each field in the header, the receiver applies the CDA action associated with that field in order to reconstruct the original header field value. The CDA application order can be different from the order in which the fields are listed in the Rule. In particular, Compute-* MUST be applied after the application of the CDAs of all the fields it computes on.
ヘッダーの各フィールドについて、レシーバーはそのフィールドに関連付けられたCDAアクションを適用して、元のヘッダーフィールド値を再構築します。 CDAアプリケーションの順序は、フィールドがルールにリストされている順序とは異なる場合があります。特に、Compute- *は、計算するすべてのフィールドのCDAの適用後に適用する必要があります。
MOs are functions used at the compression side of SCHC C/D. They are not typed and can be applied to integer, string or any other data type. The result of the operation can either be True or False. The following MOs are defined:
MOはSCHC C / Dの圧縮側で使用される関数です。これらは型付けされておらず、整数、文字列、またはその他のデータ型に適用できます。操作の結果は、TrueまたはFalseのいずれかになります。次のMOが定義されています。
equal: The match result is True if the field value in the packet matches the TV.
equal：パケットのフィールド値がTVと一致する場合、一致結果はTrueです。
ignore: No matching is attempted between the field value in the packet and the TV in the Rule. The result is always True.
無視：パケット内のフィールド値とルール内のTVの間のマッチングは試行されません。結果は常にTrueです。
MSB(x): A match is obtained if the most significant (leftmost) x bits of the packet header field value are equal to the TV in the Rule. The x parameter of the MSB MO indicates how many bits are involved in the comparison. If the FL is described as variable, the x parameter must be a multiple of the FL unit. For example, x must be multiple of 8 if the unit of the variable length is bytes.
MSB（x）：パケットヘッダーフィールド値の最上位（左端）xビットがルールのTVと等しい場合、一致が取得されます。 MSB MOのxパラメータは、比較に含まれるビット数を示します。 FLが変数として記述されている場合、xパラメーターはFLユニットの倍数でなければなりません。たとえば、可変長の単位がバイトの場合、xは8の倍数でなければなりません。
match-mapping: With match-mapping, TV is a list of values. Each value of the list is identified by an index. Compression is achieved by sending the index instead of the original header field value. This operator matches if the header field value is equal to one of the values in the target list.
match-mapping：match-mappingでは、TVは値のリストです。リストの各値は、インデックスによって識別されます。圧縮は、元のヘッダーフィールド値の代わりにインデックスを送信することで実現されます。この演算子は、ヘッダーフィールドの値がターゲットリストの値のいずれかに等しい場合に一致します。
The CDA specifies the actions taken during the compression of header fields and the inverse action taken by the decompressor to restore the original value. The CDAs defined by this document are described in detail in Section 7.4.3 to Section 7.4.8. They are summarized in Table 1.
CDAは、ヘッダーフィールドの圧縮中に実行されるアクションと、元の値を復元するために解凍プログラムが実行する逆のアクションを指定します。このドキュメントで定義されているCDAについては、7.4.3項から7.4.8項で詳しく説明しています。それらを表1に要約します。
+--------------+------------------------+-----------------------+
| Action | Compression | Decompression |
+==============+========================+=======================+
| not-sent | elided | use TV stored in Rule |
+--------------+------------------------+-----------------------+
| value-sent | send | use received value |
+--------------+------------------------+-----------------------+
| mapping-sent | send index | retrieve value from |
| | | TV list |
+--------------+------------------------+-----------------------+
| LSB | send least significant | concatenate TV and |
| | bits (LSB) | received value |
+--------------+------------------------+-----------------------+
| compute-* | elided | recompute at |
| | | decompressor |
+--------------+------------------------+-----------------------+
| DevIID | elided | build IID from L2 Dev |
| | | addr |
+--------------+------------------------+-----------------------+
| AppIID | elided | build IID from L2 App |
| | | addr |
+--------------+------------------------+-----------------------+
Table 1: Compression and Decompression Actions
表1：圧縮と解凍のアクション
The first column shows the action's name. The second and third columns show the compression and decompression behaviors for each action.
最初の列は、アクションの名前を示しています。 2番目と3番目の列は、各アクションの圧縮と解凍の動作を示しています。
If the field is identified in the Field Descriptor as being of fixed length, then applying the CDA to compress this field results in a fixed amount of bits. The residue for that field is simply the bits resulting from applying the CDA to the field. This value may be empty (e.g., not-sent CDA), in which case the field residue is absent from the Compression Residue.
フィールド記述子でフィールドが固定長であると識別された場合、CDAを適用してこのフィールドを圧縮すると、固定ビット数になります。そのフィールドの剰余は、単にCDAをフィールドに適用した結果のビットです。この値は空の場合があります（たとえば、送信されていないCDA）。この場合、フィールドの残差は圧縮残差にありません。
|- field residue -|
+-----------------+
| value |
+-----------------+
Figure 8: Fixed-Size Field Residue Structure
図8：固定サイズのフィールド残差構造
If the field is identified in the Field Descriptor as being of variable length, then applying the CDA to compress this field may result in a value of fixed size (e.g., not-sent or mapping-sent) or of variable size (e.g., value-sent or LSB). In the latter case, the residue for that field is the bits that result from applying the CDA to the field, preceded with the size of the value. The most significant bit of the size is stored to the left (leftmost bit of the residue field).
フィールド記述子でフィールドが可変長であると識別された場合、CDAを適用してこのフィールドを圧縮すると、固定サイズ（たとえば、送信されない、またはマッピング送信される）または可変サイズ（たとえば、値）の値になる可能性があります。 -sentまたはLSB）。後者の場合、そのフィールドの剰余は、フィールドにCDAを適用した結果のビットであり、値のサイズが前に付きます。サイズの最上位ビットは左側に格納されます（剰余フィールドの左端のビット）。
|--- field residue ---|
+-------+-------------+
| size | value |
+-------+-------------+
Figure 9: Variable-Size Field Residue Structure
図9：可変サイズのフィールド残差構造
The size (using the unit defined in the FL) is encoded on 4, 12, or 28 bits as follows:
サイズ（FLで定義された単位を使用）は、次のように4、12、または28ビットでエンコードされます。
* If the size is between 0 and 14, it is encoded as a 4-bit unsigned integer.
* サイズが0〜14の場合、4ビットの符号なし整数としてエンコードされます。
* Sizes between 15 and 254 are encoded as 0b1111 followed by the 8-bit unsigned integer.
* 15〜254のサイズは、0b1111とそれに続く8ビットの符号なし整数としてエンコードされます。
* Larger sizes are encoded as 0xfff followed by the 16-bit unsigned integer.
* より大きいサイズは、0xfffの後に16ビットの符号なし整数が続くようにエンコードされます。
If the field is identified in the Field Descriptor as being of variable length and this field is not present in the packet header being compressed, size 0 MUST be sent to denote its absence.
フィールド記述子でフィールドが可変長であると識別され、このフィールドが圧縮されるパケットヘッダーに存在しない場合、サイズ0が送信されていないことを示す必要があります。
The not-sent action can be used when the field value is specified in a Rule and, therefore, known by both the Compressor and the Decompressor. This action SHOULD be used with the "equal" MO. If MO is "ignore", there is a risk of having a decompressed field value that is different from the original field that was compressed.
not-sentアクションは、フィールド値がルールで指定されている場合に使用でき、したがって、CompressorとDecompressorの両方で認識されます。このアクションは、「等しい」MOで使用する必要があります（SHOULD）。 MOが「無視」されている場合、圧縮された元のフィールドとは異なる解凍されたフィールド値が存在するリスクがあります。
The compressor does not send any residue for a field on which not-sent compression is applied.
コンプレッサーは、送信されていない圧縮が適用されているフィールドの残留物を送信しません。
The decompressor restores the field value with the TV stored in the matched Rule identified by the received RuleID.
デコンプレッサは、受信したRuleIDで識別される一致したルールに格納されているTVを使用してフィールド値を復元します。
The value-sent action can be used when the field value is not known by both the Compressor and the Decompressor. The field is sent in its entirety, using the same bit order as in the original packet header.
値送信アクションは、フィールド値がコンプレッサーとデコンプレッサーの両方で認識されていない場合に使用できます。フィールドは、元のパケットヘッダーと同じビットオーダーを使用して、全体が送信されます。
If this action is performed on a variable-length field, the size of the residue value (using the units defined in FL) MUST be sent as described in Section 7.4.2.
このアクションが可変長フィールドで実行される場合、（FLで定義された単位を使用して）残余値のサイズは、セクション7.4.2で説明されているように送信される必要があります。
This action is generally used with the "ignore" MO.
このアクションは通常、「無視」MOで使用されます。
The mapping-sent action is used to send an index (the index into the TV list of values) instead of the original value. This action is used together with the "match-mapping" MO.
マッピング送信アクションは、元の値の代わりにインデックス（値のTVリストへのインデックス）を送信するために使用されます。このアクションは、「一致マッピング」MOと一緒に使用されます。
On the compressor side, the match-mapping MO searches the TV for a match with the header field value. The mapping-sent CDA then sends the corresponding index as the field residue. The most significant bit of the index is stored to the left (leftmost bit of the residue field).
コンプレッサー側では、マッチマッピングMOがヘッダーフィールド値との一致をテレビで検索します。マッピング送信されたCDAは、対応するインデックスをフィールド残差として送信します。インデックスの最上位ビットは左に格納されます（剰余フィールドの左端のビット）。
On the decompressor side, the CDA uses the received index to restore the field value by looking up the list in the TV.
デコンプレッサ側では、CDAは受信したインデックスを使用して、TVでリストを検索することによりフィールド値を復元します。
The number of bits sent is the minimal size for coding all the possible indices.
送信されるビット数は、可能なすべてのインデックスをコーディングするための最小サイズです。
The first element in the list MUST be represented by index value 0, and successive elements in the list MUST have indices incremented by 1.
リストの最初の要素はインデックス値0で表す必要があり、リストの後続の要素は1ずつ増加するインデックスを持つ必要があります。
The LSB action is used together with the "MSB(x)" MO to avoid sending the most significant part of the packet field if that part is already known by the receiving end.
LSBアクションは、「MSB（x）」MOとともに使用され、パケットフィールドの最も重要な部分が受信側で既知である場合に、その部分の送信を回避します。
The compressor sends the LSBs as the field residue value. The number of bits sent is the original header field length minus the length specified in the MSB(x) MO. The bits appear in the residue in the same bit order as in the original packet header.
コンプレッサーは、LSBをフィールド残差値として送信します。送信されるビット数は、元のヘッダーフィールドの長さからMSB（x）MOで指定された長さを引いたものです。ビットは、元のパケットヘッダーと同じビット順序で剰余に現れます。
The decompressor concatenates the x most significant bits of the TV and the received residue value.
デコンプレッサは、TVの最上位xビットと受信された残差値を連結します。
If this action is performed on a variable-length field, the size of the residue value (using the units defined in FL) MUST be sent as described in Section 7.4.2.
このアクションが可変長フィールドで実行される場合、（FLで定義された単位を使用して）残余値のサイズは、セクション7.4.2で説明されているように送信される必要があります。
These actions are used to process the DevIID and AppIID of the IPv6 addresses, respectively. AppIID CDA is less common since most current LPWAN technologies frames contain a single L2 address, which is the Dev's address.
これらのアクションは、IPv6アドレスのDevIIDおよびAppIIDをそれぞれ処理するために使用されます。現在のほとんどのLPWANテクノロジーフレームには、Devのアドレスである単一のL2アドレスが含まれているため、AppIID CDAはあまり一般的ではありません。
The DevIID value MAY be computed from the Dev ID present in the L2 header, or from some other stable identifier. The computation is specific to each Profile and MAY depend on the Dev ID size.
DevIID値は、L2ヘッダーにあるDev IDから、またはその他の安定した識別子から計算される場合があります。計算は各プロファイルに固有であり、Dev IDのサイズに依存する場合があります。
In the Downlink direction, at the compressor, the DevIID CDA may be used to generate the L2 addresses on the LPWAN, based on the packet's Destination Address.
ダウンリンク方向では、コンプレッサーで、DevIID CDAを使用して、パケットの宛先アドレスに基づいて、LPWAN上にL2アドレスを生成できます。
Some fields can be elided at the compressor and recomputed locally at the decompressor.
一部のフィールドは、コンプレッサーで省略でき、デコンプレッサーでローカルに再計算できます。
Because the field is uniquely identified by its FID (e.g., IPv6 length), the relevant protocol specification unambiguously defines the algorithm for such computation.
フィールドはそのFID（IPv6の長さなど）によって一意に識別されるため、関連するプロトコル仕様はそのような計算のアルゴリズムを明確に定義します。
An example of a field that knows how to recompute itself is IPv6 length.
自身を再計算する方法を知っているフィールドの例は、IPv6の長さです。
In LPWAN technologies, the L2 MTU typically ranges from tens to hundreds of bytes. Some of these technologies do not have an internal fragmentation/reassembly mechanism.
LPWANテクノロジでは、L2 MTUの範囲は通常数十から数百バイトです。これらのテクノロジーの一部には、内部の断片化/再構成メカニズムがありません。
The optional SCHC F/R functionality enables such LPWAN technologies to comply with the IPv6 MTU requirement of 1280 bytes [RFC8200]. It is OPTIONAL to implement per this specification, but Profiles may specify that it is REQUIRED.
オプションのSCHC F / R機能により、このようなLPWANテクノロジは、1280バイトのIPv6 MTU要件[RFC8200]に準拠できます。この仕様に従って実装することはオプションですが、プロファイルはそれが必須であることを指定する場合があります。
This specification includes several SCHC F/R modes, which allow for a range of reliability options such as optional SCHC Fragment retransmission. More modes may be defined in the future.
この仕様にはいくつかのSCHC F / Rモードが含まれており、オプションのSCHCフラグメント再送信などの信頼性オプションの範囲を可能にします。今後、さらに多くのモードが定義される可能性があります。
The same SCHC F/R mode MUST be used for all SCHC Fragments of a given SCHC Packet. This document does not specify which mode(s) must be implemented and used over a specific LPWAN technology. That information will be given in Profiles.
特定のSCHCパケットのすべてのSCHCフラグメントに同じSCHC F / Rモードを使用する必要があります。このドキュメントでは、特定のLPWANテクノロジで実装および使用する必要があるモードを指定していません。その情報はプロファイルで提供されます。
SCHC allows transmitting non-fragmented SCHC Packet concurrently with fragmented SCHC Packets. In addition, SCHC F/R provides protocol elements that allow transmitting several fragmented SCHC Packets concurrently, i.e., interleaving the transmission of fragments from different fragmented SCHC Packets. A Profile MAY restrict the latter behavior.
SCHCは、断片化されていないSCHCパケットを断片化されたSCHCパケットと同時に送信することを可能にします。さらに、SCHC F / Rは、いくつかの断片化されたSCHCパケットを同時に送信する、つまり、異なる断片化されたSCHCパケットからの断片の送信をインターリーブできるようにするプロトコル要素を提供します。プロファイルは後者の振る舞いを制限してもよい（MAY）。
The L2 Word size (see Section 4) determines the encoding of some messages. SCHC F/R usually generates SCHC Fragments and SCHC ACKs that are multiples of L2 Words.
L2ワードサイズ（セクション4を参照）は、一部のメッセージのエンコーディングを決定します。 SCHC F / Rは通常、L2ワードの倍数であるSCHCフラグメントおよびSCHC ACKを生成します。
This subsection describes the different elements that are used to enable the SCHC F/R functionality defined in this document. These elements include the SCHC F/R messages, tiles, windows, bitmaps, counters, timers, and header fields.
このサブセクションでは、このドキュメントで定義されているSCHC F / R機能を有効にするために使用されるさまざまな要素について説明します。これらの要素には、SCHC F / Rメッセージ、タイル、ウィンドウ、ビットマップ、カウンター、タイマー、ヘッダーフィールドが含まれます。
The elements are described here in a generic manner. Their application to each SCHC F/R mode is found in Section 8.4.
ここでは、要素について一般的な方法で説明します。各SCHC F / Rモードへの適用については、セクション8.4を参照してください。
SCHC F/R defines the following messages:
SCHC F / Rは次のメッセージを定義します。
SCHC Fragment: A message that carries part of a SCHC Packet from the sender to the receiver.
SCHCフラグメント：送信者から受信者へのSCHCパケットの一部を運ぶメッセージ。
SCHC ACK: An acknowledgement for fragmentation, by the receiver to the sender. This message is used to indicate whether or not the reception of pieces of, or the whole of, the fragmented SCHC Packet was successful.
SCHC ACK：受信者から送信者へのフラグメンテーションの確認。このメッセージは、断片化されたSCHCパケットの一部または全体の受信が成功したかどうかを示すために使用されます。
SCHC ACK REQ: A request by the sender for a SCHC ACK from the receiver.
SCHC ACK REQ：受信者からのSCHC ACKに対する送信者による要求。
SCHC Sender-Abort: A message by the sender telling the receiver that it has aborted the transmission of a fragmented SCHC Packet.
SCHC Sender-Abort：断片化されたSCHCパケットの送信を中止したことを受信者に知らせる送信者によるメッセージ。
SCHC Receiver-Abort: A message by the receiver to tell the sender to abort the transmission of a fragmented SCHC Packet.
SCHC Receiver-Abort：断片化されたSCHCパケットの送信を中止するように送信者に通知するための、受信者によるメッセージ。
The format of these messages is provided in Section 8.3.
これらのメッセージの形式は、セクション8.3に記載されています。
The SCHC Packet is fragmented into pieces, hereafter called "tiles". The tiles MUST be non-empty and pairwise disjoint. Their union MUST be equal to the SCHC Packet.
SCHCパケットは断片に断片化され、以降「タイル」と呼ばれます。タイルは空でなく、ペアごとにばらばらである必要があります。それらの結合は、SCHCパケットと等しくなければなりません。
See Figure 10 for an example.
例については、図10を参照してください。
SCHC Packet
+----+--+-----+---+----+-+---+-----+...-----+----+---+------+
Tiles | | | | | | | | | | | | |
+----+--+-----+---+----+-+---+-----+...-----+----+---+------+
Figure 10: SCHC Packet Fragmented in Tiles
図10：タイルで断片化されたSCHCパケット
Modes (see Section 8.4) MAY place additional constraints on tile sizes.
モード（セクション8.4を参照）は、タイルサイズに追加の制約を課す場合があります。
Each SCHC Fragment message carries at least one tile in its Payload, if the Payload field is present.
ペイロードフィールドが存在する場合、各SCHCフラグメントメッセージのペイロードには少なくとも1つのタイルが含まれます。
Some SCHC F/R modes may handle successive tiles in groups, called windows.
一部のSCHC F / Rモードでは、ウィンドウと呼ばれるグループ内の連続したタイルを処理できます。
If windows are used:
ウィンドウを使用する場合：
* all the windows of a SCHC Packet, except the last one, MUST contain the same number of tiles. This number is WINDOW_SIZE.
* 最後のものを除くSCHCパケットのすべてのウィンドウには、同じ数のタイルが含まれている必要があります。この数はWINDOW_SIZEです。
* WINDOW_SIZE MUST be specified in a Profile.
* WINDOW_SIZEはプロファイルで指定する必要があります。
* the windows are numbered.
* ウィンドウには番号が付けられています。
* their numbers MUST increment by 1 from 0 upward, from the start of the SCHC Packet to its end.
* それらの番号は、SCHCパケットの開始から終了まで、0から1まで増分する必要があります。
* the last window MUST contain WINDOW_SIZE tiles or less.
* 最後のウィンドウには、WINDOW_SIZE以下のタイルを含める必要があります。
* tiles are numbered within each window.
* タイルには各ウィンドウ内で番号が付けられています。
* the tile indices MUST decrement by 1 from WINDOW_SIZE - 1 downward, looking from the start of the SCHC Packet toward its end.
* SCHCパケットの先頭から末尾に向かって、タイルインデックスはWINDOW_SIZE-1から1ずつ減少する必要があります。
* therefore, each tile of a SCHC Packet is uniquely identified by a window number and a tile index within this window.
* したがって、SCHCパケットの各タイルは、ウィンドウ番号とこのウィンドウ内のタイルインデックスによって一意に識別されます。
See Figure 11 for an example.
例については、図11を参照してください。
+---------------------------------------------...-----------+
| SCHC Packet |
+---------------------------------------------...-----------+
Tile# | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 |3|
Window# |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|- 28-|
Figure 11: SCHC Packet Fragmented in Tiles Grouped in 29 Windows, with WINDOW_SIZE = 5
図11：WINDOW_SIZE = 5で、29のウィンドウにグループ化されたタイルに断片化されたSCHCパケット
Appendix E discusses the benefits of selecting one among multiple window sizes depending on the size of the SCHC Packet to be fragmented.
付録Eでは、フラグメント化するSCHCパケットのサイズに応じて、複数のウィンドウサイズから1つを選択する利点について説明します。
When windows are used:
ウィンドウを使用する場合：
* Bitmaps (see Section 8.2.2.3) MAY be sent back by the receiver to the sender in a SCHC ACK message.
* ビットマップ（セクション8.2.2.3を参照）は、SCHC ACKメッセージで受信者から送信者に送り返される場合があります。
* A Bitmap corresponds to exactly one Window.
* ビットマップは正確に1つのウィンドウに対応します。
Each bit in the Bitmap for a window corresponds to a tile in the window. Therefore, each Bitmap has WINDOW_SIZE bits. The bit at the leftmost position corresponds to the tile numbered WINDOW_SIZE - 1. Consecutive bits, going right, correspond to sequentially decreasing tile indices. In Bitmaps for windows that are not the last one of a SCHC Packet, the bit at the rightmost position corresponds to the tile numbered 0. In the Bitmap for the last window, the bit at the rightmost position corresponds either to the tile numbered 0 or to a tile that is sent/received as "the last one of the SCHC Packet" without explicitly stating its number (see Section 8.3.1.2).
ウィンドウのビットマップの各ビットは、ウィンドウのタイルに対応しています。したがって、各ビットマップにはWINDOW_SIZEビットがあります。左端のビットは、WINDOW_SIZE-1の番号が付けられたタイルに対応します。連続するビットは、右に向かって、タイルのインデックスが順次減少することに対応します。 SCHCパケットの最後のビットではないウィンドウのビットマップでは、右端のビットは番号0のタイルに対応します。最後のウィンドウのビットマップでは、右端のビットは番号0またはタイルのいずれかに対応します。番号を明示的に示さずに「SCHCパケットの最後の1つ」として送受信されるタイル（8.3.1.2を参照）。
At the receiver:
受信機で：
* a bit set to 1 in the Bitmap indicates that a tile associated with that bit position has been correctly received for that window.
* ビットマップでビットが1に設定されている場合、そのビット位置に関連付けられているタイルがそのウィンドウで正しく受信されたことを示します。
* a bit set to 0 in the Bitmap indicates that there has been no tile correctly received, associated with that bit position, for that window. Possible reasons include that the tile was not sent at all, not received, or received with errors.
* ビットマップでビットが0に設定されている場合、そのウィンドウに対して、そのビット位置に関連付けられているタイルが正しく受信されていないことを示します。考えられる理由としては、タイルがまったく送信されなかった、受信されなかった、エラーで受信されたなどがあります。
Some SCHC F/R modes can use the following timers and counters:
一部のSCHC F / Rモードは、次のタイマーとカウンターを使用できます。
Inactivity Timer: a SCHC Fragment receiver uses this timer to abort waiting for a SCHC F/R message.
非アクティブタイマー：SCHCフラグメントレシーバーはこのタイマーを使用して、SCHC F / Rメッセージの待機を中止します。
Retransmission Timer: a SCHC Fragment sender uses this timer to abort waiting for an expected SCHC ACK.
再送信タイマー：SCHCフラグメント送信者はこのタイマーを使用して、予期されるSCHC ACKの待機を中止します。
Attempts: this counter counts the requests for SCHC ACKs, up to MAX_ACK_REQUESTS.
試行：このカウンターは、MAX_ACK_REQUESTSまでのSCHC ACKの要求をカウントします。
The integrity of the fragmentation-reassembly process of a SCHC Packet MUST be checked at the receive end. A Profile MUST specify how integrity checking is performed.
SCHCパケットのフラグメンテーション再構成プロセスの整合性は、受信側でチェックする必要があります。プロファイルは、整合性チェックの実行方法を指定する必要があります。
It is RECOMMENDED that integrity checking be performed by computing a Reassembly Check Sequence (RCS) based on the SCHC Packet at the sender side and transmitting it to the receiver for comparison with the RCS locally computed after reassembly.
整合性チェックは、送信側でSCHCパケットに基づいて再組み立てチェックシーケンス（RCS）を計算し、再組み立て後にローカルで計算されたRCSと比較するために受信側に送信することで実行することをお勧めします。
The RCS supports UDP checksum elision by SCHC C/D (see Section 10.11).
RCSは、SCHC C / DによるUDPチェックサム省略をサポートします（セクション10.11を参照）。
The CRC32 polynomial 0xEDB88320 (i.e., the reversed polynomial representation, which is used in the Ethernet standard [ETHERNET]) is RECOMMENDED as the default algorithm for computing the RCS.
CRC32多項式0xEDB88320（つまり、イーサネット標準[ETHERNET]で使用される逆多項式表現）は、RCSを計算するためのデフォルトのアルゴリズムとして推奨されています。
The RCS MUST be computed on the full SCHC Packet concatenated with the padding bits, if any, of the SCHC Fragment carrying the last tile. The rationale is that the SCHC reassembler has no way of knowing the boundary between the last tile and the padding bits. Indeed, this requires decompressing the SCHC Packet, which is out of the scope of the SCHC reassembler.
RCSは、最後のタイルを運ぶSCHCフラグメントのパディングビットがあれば、それと連結された完全なSCHCパケットで計算される必要があります。理論的根拠は、SCHCリアセンブラーが最後のタイルとパディングビットの間の境界を知る方法がないということです。実際、これにはSCHCパケットを解凍する必要がありますが、これはSCHCリアセンブラの範囲外です。
The concatenation of the complete SCHC Packet and any padding bits, if present, of the last SCHC Fragment does not generally constitute an integer number of bytes. CRC libraries are usually byte oriented. It is RECOMMENDED that the concatenation of the complete SCHC Packet and any last fragment padding bits be zero-extended to the next byte boundary and that the RCS be computed on that byte array.
最後のSCHCフラグメントの完全なSCHCパケットとパディングビット（存在する場合）の連結は、通常、整数バイトを構成しません。 CRCライブラリは通常バイト指向です。完全なSCHCパケットと最後のフラグメントパディングビットの連結を次のバイト境界までゼロ拡張し、RCSをそのバイト配列で計算することをお勧めします。
The SCHC F/R messages contain the following fields (see the formats in Section 8.3):
SCHC F / Rメッセージには、次のフィールドが含まれます（セクション8.3のフォーマットを参照）。
RuleID: this field is present in all the SCHC F/R messages. The Rule identifies:
RuleID：このフィールドは、すべてのSCHC F / Rメッセージに存在します。ルールは以下を識別します。
* that a SCHC F/R message is being carried, as opposed to an unfragmented SCHC Packet,
* 断片化されていないSCHCパケットとは対照的に、SCHC F / Rメッセージが運ばれていること、
* which SCHC F/R mode is used,
* どのSCHC F / Rモードが使用されているか
* in case this mode uses windows, what the value of WINDOW_SIZE is, and
* このモードがウィンドウを使用する場合、WINDOW_SIZEの値は
* what other optional fields are present and what the field sizes are.
* 他にどのようなオプションフィールドが存在し、フィールドサイズは何か。
The Rule tells apart a non-fragmented SCHC Packet from SCHC Fragments. It will also tell apart SCHC Fragments of fragmented SCHC Packets that use different SCHC F/R modes or different parameters. Therefore, interleaved transmission of these is possible.
ルールは、断片化されていないSCHCパケットとSCHCフラグメントを区別します。また、異なるSCHC F / Rモードまたは異なるパラメーターを使用する断片化されたSCHCパケットのSCHCフラグメントを区別します。したがって、これらのインターリーブ送信が可能です。
All SCHC F/R messages pertaining to the same SCHC Packet MUST bear the same RuleID.
同じSCHCパケットに関連するすべてのSCHC F / Rメッセージは、同じRuleIDを持つ必要があります。
Datagram Tag (DTag): This field allows differentiating SCHC F/R messages belonging to different SCHC Packets that may be using the same RuleID simultaneously. Hence, it allows interleaving fragments of a new SCHC Packet with fragments of a previous SCHC Packet under the same RuleID.
データグラムタグ（DTag）：このフィールドでは、同じRuleIDを同時に使用している可能性のある異なるSCHCパケットに属するSCHC F / Rメッセージを区別できます。したがって、同じRuleIDの下で、新しいSCHCパケットのフラグメントを前のSCHCパケットのフラグメントとインターリーブすることができます。
The size of the DTag field (called "T", in bits) is defined by each Profile for each RuleID. When T is 0, the DTag field does not appear in the SCHC F/R messages and the DTag value is defined as 0.
DTagフィールドのサイズ（「T」と呼ばれ、ビット単位）は、各RuleIDの各プロファイルによって定義されます。 Tが0の場合、DTagフィールドはSCHC F / Rメッセージに表示されず、DTag値は0として定義されます。
When T is 0, there can be no more than one fragmented SCHC Packet in transit for each fragmentation RuleID.
Tが0の場合、フラグメント化RuleIDごとに送信中のフラグメント化されたSCHCパケットは1つだけです。
If T is not 0, DTag:
Tが0でない場合、DTag：
* MUST be set to the same value for all the SCHC F/R messages related to the same fragmented SCHC Packet, and
* 同じ断片化されたSCHCパケットに関連するすべてのSCHC F / Rメッセージに対して同じ値に設定する必要があります。
* MUST be set to different values for SCHC F/R messages related to different SCHC Packets that are being fragmented under the same RuleID and whose transmission may overlap.
* 同じRuleIDでフラグメント化され、送信が重複する可能性のある異なるSCHCパケットに関連するSCHC F / Rメッセージの異なる値に設定する必要があります。
W: The W field is optional. It is only present if windows are used. Its presence and size (called "M", in bits) is defined by each SCHC F/R mode and each Profile for each RuleID.
W：Wフィールドはオプションです。ウィンドウが使用されている場合にのみ存在します。その存在とサイズ（ビットでは "M"と呼ばれます）は、各SCHC F / Rモードと各RuleIDの各プロファイルによって定義されます。
This field carries information pertaining to the window a SCHC F/R message relates to. If present, W MUST carry the same value for all the SCHC F/R messages related to the same window. Depending on the mode and Profile, W may carry the full window number, or just the LSB or any other partial representation of the window number.
このフィールドには、SCHC F / Rメッセージが関連するウィンドウに関する情報が含まれます。存在する場合、Wは同じウィンドウに関連するすべてのSCHC F / Rメッセージに対して同じ値を保持する必要があります。モードとプロファイルに応じて、Wはウィンドウ番号全体、またはLSBまたはウィンドウ番号のその他の部分的な表現のみを運ぶ場合があります。
Fragment Compressed Number (FCN): The FCN field is present in the SCHC Fragment Header. Its size (called "N", in bits) is defined by each Profile for each RuleID.
フラグメント圧縮番号（FCN）：FCNフィールドはSCHCフラグメントヘッダーにあります。そのサイズ（「N」と呼ばれ、ビット単位）は、各RuleIDの各プロファイルによって定義されます。
This field conveys information about the progress in the sequence of tiles being transmitted by SCHC Fragment messages. For example, it can contain a partial, efficient representation of a larger-sized tile index. The description of the exact use of the FCN field is left to each SCHC F/R mode. However, two values are reserved for special purposes. They help control the SCHC F/R process:
このフィールドは、SCHCフラグメントメッセージによって送信されるタイルのシーケンスの進行に関する情報を伝えます。たとえば、より大きなサイズのタイルインデックスの部分的で効率的な表現を含めることができます。 FCNフィールドの正確な使用法の説明は、各SCHC F / Rモードに任されています。ただし、2つの値は特別な目的のために予約されています。 SCHC F / Rプロセスの制御に役立ちます。
* The FCN value with all the bits equal to 1 (called "All-1") signals that the very last tile of a SCHC Packet has been transmitted. By extension, if windows are used, the last window of a packet is called the "All-1" window.
* すべてのビットが1のFCN値（「All-1」と呼ばれる）は、SCHCパケットの最後のタイルが送信されたことを示します。拡張により、ウィンドウが使用される場合、パケットの最後のウィンドウは「All-1」ウィンドウと呼ばれます。
* If windows are used, the FCN value with all the bits equal to 0 (called "All-0") signals the last tile of a window that is not the last one of the SCHC packet. By extension, such a window is called an "All-0 window".
* ウィンドウが使用されている場合、すべてのビットが0のFCN値（ "All-0"と呼ばれる）は、SCHCパケットの最後のタイルではないウィンドウの最後のタイルを通知します。拡大すると、このようなウィンドウは「All-0ウィンドウ」と呼ばれます。
Reassembly Check Sequence (RCS): This field only appears in the All-1 SCHC Fragments. Its size (called "U", in bits) is defined by each Profile for each RuleID.
Reassembly Check Sequence（RCS）：このフィールドは、All-1 SCHC Fragmentsにのみ表示されます。そのサイズ（「U」と呼ばれ、ビット単位）は、各RuleIDの各プロファイルによって定義されます。
See Section 8.2.3 for the RCS default size, default polynomial and details on RCS computation.
RCSのデフォルトサイズ、デフォルトの多項式、およびRCS計算の詳細については、セクション8.2.3を参照してください。
C (integrity Check): C is a 1-bit field. This field is used in the SCHC ACK message to report on the reassembled SCHC Packet integrity check (see Section 8.2.3).
C（整合性チェック）：Cは1ビットのフィールドです。このフィールドは、SCHC ACKメッセージで使用され、再構築されたSCHCパケットの整合性チェックについてレポートします（セクション8.2.3を参照）。
A value of 1 tells that the integrity check was performed and is successful. A value of 0 tells that the integrity check was not performed or that it was a failure.
値1は、整合性チェックが実行され、成功したことを示します。値0は、整合性チェックが実行されなかったか、失敗したことを示します。
Compressed Bitmap: The Compressed Bitmap is used together with windows and Bitmaps (see Section 8.2.2.3). Its presence and size is defined for each SCHC F/R mode for each RuleID.
圧縮ビットマップ：圧縮ビットマップは、ウィンドウおよびビットマップと一緒に使用されます（8.2.2.3項を参照）。その存在とサイズは、各RuleIDのSCHC F / Rモードごとに定義されます。
This field appears in the SCHC ACK message to report on the receiver Bitmap (see Section 8.3.2.1).
このフィールドはSCHC ACKメッセージに表示され、受信者のビットマップについてレポートします（セクション8.3.2.1を参照）。
This section defines the SCHC Fragment formats, the SCHC ACK format, the SCHC ACK REQ format and the SCHC Abort formats.
このセクションでは、SCHCフラグメント形式、SCHC ACK形式、SCHC ACK REQ形式、およびSCHC Abort形式を定義します。
A SCHC Fragment conforms to the general format shown in Figure 12. It comprises a SCHC Fragment Header and a SCHC Fragment Payload. The SCHC Fragment Payload carries one or several tile(s).
SCHCフラグメントは、図12に示す一般的なフォーマットに準拠しています。SCHCフラグメントは、SCHCフラグメントヘッダーとSCHCフラグメントペイロードで構成されます。 SCHCフラグメントペイロードは、1つまたは複数のタイルを伝送します。
+-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~
| Fragment Header | Fragment Payload | padding (as needed)
+-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~
Figure 12: SCHC Fragment General Format
図12：SCHCフラグメントの一般的な形式
The Regular SCHC Fragment format is shown in Figure 13. Regular SCHC Fragments are generally used to carry tiles that are not the last one of a SCHC Packet. The DTag field and the W field are OPTIONAL, their presence is specified by each mode and Profile.
通常のSCHCフラグメントのフォーマットを図13に示します。通常のSCHCフラグメントは、SCHCパケットの最後のタイルではないタイルを運ぶために一般的に使用されます。 DTagフィールドとWフィールドはオプションであり、それらの存在は各モードとプロファイルによって指定されます。
|-- SCHC Fragment Header ----|
|-- T --|-M-|-- N --|
+-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~
| RuleID | DTag | W | FCN | Fragment Payload | padding (as needed)
+-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~
Figure 13: Detailed Header Format for Regular SCHC Fragments
図13：通常のSCHCフラグメントの詳細なヘッダー形式
The FCN field MUST NOT contain all bits set to 1.
FCNフィールドには、1に設定されたすべてのビットを含めることはできません。
Profiles MUST ensure that a SCHC Fragment with FCN equal to 0 (called an "All-0 SCHC Fragment") is distinguishable by size, even in the presence of padding, from a SCHC ACK REQ message (see Section 8.3.3) with the same RuleID value and with the same T, M, and N values. This condition is met if the Payload is at least the size of an L2 Word. This condition is also met if the SCHC Fragment Header is a multiple of L2 Words.
プロファイルは、FCNが0のSCHCフラグメント（「All-0 SCHCフラグメント」と呼ばれる）が、パディングが存在する場合でも、サイズがSCHC ACK REQメッセージ（セクション8.3.3を参照）と区別できることを保証する必要があります。同じRuleID値と同じT、M、およびN値。この条件は、ペイロードが少なくともL2ワードのサイズである場合に満たされます。この条件は、SCHCフラグメントヘッダーがL2ワードの倍数である場合にも満たされます。
The All-1 SCHC Fragment format is shown in Figure 14. The sender uses the All-1 SCHC Fragment format for the message that completes the emission of a fragmented SCHC Packet. The DTag field, the W field, the RCS field and the Payload are OPTIONAL, their presence is specified by each mode and Profile. At least one of RCS field or Fragment Payload MUST be present. The FCN field is all ones.
All-1 SCHCフラグメントフォーマットを図14に示します。送信者は、フラグメント化されたSCHCパケットの送信を完了するメッセージにAll-1 SCHCフラグメントフォーマットを使用します。 DTagフィールド、Wフィールド、RCSフィールド、およびペイロードはオプションであり、それらの存在は各モードとプロファイルによって指定されます。 RCSフィールドまたはフラグメントペイロードの少なくとも1つが存在する必要があります。 FCNフィールドはすべて1です。
|------- SCHC Fragment Header -------|
|-- T --|-M-|-- N --|-- U --|
+-- ... -+- ... -+---+- ... -+- ... -+-----...-----+~~~~~~~~~~~~~~~~~
| RuleID | DTag | W | 11..1 | RCS | FragPayload | pad. (as needed)
+-- ... -+- ... -+---+- ... -+- ... -+-----...-----+~~~~~~~~~~~~~~~~~
(FCN)
Figure 14: Detailed Header Format for the All-1 SCHC Fragment
図14：All-1 SCHCフラグメントの詳細なヘッダー形式
Profiles MUST ensure that an All-1 SCHC Fragment message is distinguishable by size, even in the presence of padding, from a SCHC Sender-Abort message (see Section 8.3.4) with the same RuleID value and with the same T, M, and N values. This condition is met if the RCS is present and is at least the size of an L2 Word or if the Payload is present and is at least the size an L2 Word. This condition is also met if the SCHC Sender-Abort Header is a multiple of L2 Words.
プロファイルは、パディングが存在する場合でも、All-1 SCHCフラグメントメッセージが、同じRuleID値と同じT、Mを持つSCHC Sender-Abortメッセージ（セクション8.3.4を参照）とサイズで区別できることを保証する必要があります。およびN値。この条件は、RCSが存在し、少なくともL2ワードのサイズである場合、またはペイロードが存在し、少なくともL2ワードのサイズである場合に満たされます。この条件は、SCHC Sender-AbortヘッダーがL2ワードの倍数である場合にも満たされます。
The SCHC ACK message is shown in Figure 15. The DTag field and the W field are OPTIONAL, their presence is specified by each mode and Profile. The Compressed Bitmap field MUST be present in SCHC F/R modes that use windows and MUST NOT be present in other modes.
SCHC ACKメッセージを図15に示します。DTagフィールドとWフィールドはオプションであり、それらの存在は各モードとプロファイルによって指定されます。圧縮ビットマップフィールドは、ウィンドウを使用するSCHC F / Rモードに存在する必要があり、他のモードには存在してはなりません（MUST NOT）。
|--- SCHC ACK Header ----|
|-- T --|-M-| 1 |
+-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~
| RuleID | DTag | W |C=1| padding as needed (success)
+-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~
+-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~
| RuleID | DTag | W |C=0|Compressed Bitmap| pad. as needed (failure)
+-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~
Figure 15: Format of the SCHC ACK Message
図15：SCHC ACKメッセージのフォーマット
The SCHC ACK Header contains a C bit (see Section 8.2.4).
SCHC ACKヘッダーにはCビットが含まれています（セクション8.2.4を参照）。
If the C bit is set to 1 (integrity check successful), no Bitmap is carried.
Cビットが1に設定されている場合（整合性チェックは成功）、ビットマップは伝送されません。
If the C bit is set to 0 (integrity check not performed or failed) and if windows are used, a Compressed Bitmap for the window referred to by the W field is transmitted as specified in Section 8.3.2.1.
Cビットが0に設定されている（整合性チェックが実行されない、または失敗した）場合、ウィンドウが使用されると、8.3.2.1で指定されているように、Wフィールドで参照されるウィンドウの圧縮ビットマップが送信されます。
For transmission, the Compressed Bitmap in the SCHC ACK message is defined by the following algorithm (see Figure 16 for a follow-along example):
送信の場合、SCHC ACKメッセージ内の圧縮ビットマップは、次のアルゴリズムによって定義されます（以下の例については、図16を参照してください）。
* Build a temporary SCHC ACK message that contains the Header followed by the original Bitmap (see Section 8.2.2.3 for a description of Bitmaps).
* ヘッダーとそれに続く元のビットマップを含む一時的なSCHC ACKメッセージを作成します（ビットマップの説明については、セクション8.2.2.3を参照してください）。
* Position scissors at the end of the Bitmap, after its last bit.
* 最後のビットの後、ビットマップの最後にハサミを配置します。
* While the bit on the left of the scissors is 1 and belongs to the Bitmap, keep moving left, then stop.
* はさみの左側のビットが1でビットマップに属している間、左に移動して停止します。
* Then, while the scissors are not on an L2 Word boundary of the SCHC ACK message and there is a Bitmap bit on the right of the scissors, keep moving right, then stop.
* 次に、ハサミがSCHC ACKメッセージのL2ワード境界上になく、ハサミの右側にビットマップビットがある間、右に移動して停止します。
* At this point, cut and drop off any bits to the right of the scissors.
* この時点で、はさみの右側のビットを切り落とします。
When one or more bits have effectively been dropped off as a result of the above algorithm, the SCHC ACK message is a multiple of L2 Words; no padding bits will be appended.
上記のアルゴリズムの結果として1つ以上のビットが効果的にドロップオフされた場合、SCHC ACKメッセージはL2ワードの倍数になります。パディングビットは追加されません。
Because the SCHC Fragment sender knows the size of the original Bitmap, it can reconstruct the original Bitmap from the Compressed Bitmap received in the SCHC ACK message.
SCHCフラグメント送信者は元のビットマップのサイズを知っているため、SCHC ACKメッセージで受信した圧縮ビットマップから元のビットマップを再構築できます。
Figure 16 shows an example where L2 Words are actually bytes and where the original Bitmap contains 17 bits, the last 15 of which are all set to 1.
図16は、L2ワードが実際にバイトであり、元のビットマップに17ビットが含まれ、最後の15ビットがすべて1に設定されている例を示しています。
|--- SCHC ACK Header ----|-------- Bitmap --------|
|-- T --|-M-| 1 |
+-- ... -+- ... -+---+---+---------------------------------+
| RuleID | DTag | W |C=0|1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
+-- ... -+- ... -+---+---+---------------------------------+
next L2 Word boundary ->|
Figure 16: SCHC ACK Header Plus Uncompressed Bitmap
図16：SCHC ACKヘッダーと非圧縮ビットマップ
Figure 17 shows that the last 14 bits are not sent.
図17は、最後の14ビットが送信されていないことを示しています。
|--- SCHC ACK Header ----|CpBmp|
|-- T --|-M-| 1 |
+-- ... -+- ... -+---+---+-----+
| RuleID | DTag | W |C=0|1 0 1|
+-- ... -+- ... -+---+---+-----+
next L2 Word boundary ->|
Figure 17: Resulting SCHC ACK Message with Compressed Bitmap
図17：結果のSCHC ACKメッセージと圧縮されたビットマップ
Figure 18 shows an example of a SCHC ACK with tile indices ranging from 6 down to 0, where the Bitmap indicates that the second and the fourth tile of the window have not been correctly received.
図18は、6から0までのタイルインデックスを持つSCHC ACKの例を示しています。ビットマップは、ウィンドウの2番目と4番目のタイルが正しく受信されなかったことを示しています。
|--- SCHC ACK Header ----|--- Bitmap --|
|-- T --|-M-| 1 |6 5 4 3 2 1 0| (tile #)
+--------+-------+---+---+-------------+
| RuleID | DTag | W |C=0|1 0 1 0 1 1 1| uncompressed Bitmap
+--------+-------+---+---+-------------+
next L2 Word boundary ->|<-- L2 Word --->|
+--------+-------+---+---+-------------+~~~~+
| RuleID | DTag | W |C=0|1 0 1 0 1 1 1|pad.| transmitted SCHC ACK
+--------+-------+---+---+-------------+~~~~+
next L2 Word boundary ->|<-- L2 Word --->|
Figure 18: Example of a SCHC ACK Message, Missing Tiles
図18：SCHC ACKメッセージの例、タイルがない
Figure 19 shows an example of a SCHC ACK with tile indices ranging from 6 down to 0, where integrity check has not been performed or has failed and the Bitmap indicates that there is no missing tile in that window.
図19は、6から0までの範囲のタイルインデックスを持つSCHC ACKの例を示しています。この場合、整合性チェックは実行されていないか失敗しており、ビットマップはそのウィンドウに欠落しているタイルがないことを示しています。
|--- SCHC ACK Header ----|--- Bitmap --|
|-- T --|-M-| 1 |6 5 4 3 2 1 0| (tile #)
+--------+-------+---+---+-------------+
| RuleID | DTag | W |C=0|1 1 1 1 1 1 1| with uncompressed Bitmap
+--------+-------+---+---+-------------+
next L2 Word boundary ->|
+-- ... -+- ... -+---+---+-+
| RuleID | DTag | W |C=0|1| transmitted SCHC ACK
+-- ... -+- ... -+---+---+-+
next L2 Word boundary ->|
Figure 19: Example of a SCHC ACK Message, No Missing Tile
図19：SCHC ACKメッセージの例、欠落タイルなし
The SCHC ACK REQ is used by a sender to request a SCHC ACK from the receiver. Its format is shown in Figure 20. The DTag field and the W field are OPTIONAL, their presence is specified by each mode and Profile. The FCN field is all zero.
SCHC ACK REQは、送信者が受信者にSCHC ACKを要求するために使用されます。そのフォーマットを図20に示します。DTagフィールドとWフィールドはオプションであり、それらの存在は各モードとプロファイルによって指定されます。 FCNフィールドはすべてゼロです。
|--- SCHC ACK REQ Header ----|
|-- T --|-M-|-- N --|
+-- ... -+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~
| RuleID | DTag | W | 0..0 | padding (as needed) (no payload)
+-- ... -+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~
Figure 20: SCHC ACK REQ Format
図20：SCHC ACK REQフォーマット
When a SCHC Fragment sender needs to abort an ongoing fragmented SCHC Packet transmission, it sends a SCHC Sender-Abort message to the SCHC Fragment receiver.
SCHCフラグメント送信者は、進行中の断片化されたSCHCパケット送信を中止する必要がある場合、SCHC送信者中止メッセージをSCHCフラグメント受信者に送信します。
The SCHC Sender-Abort format is shown in Figure 21. The DTag field and the W field are OPTIONAL, their presence is specified by each mode and Profile. The FCN field is all ones.
SCHC Sender-Abortフォーマットを図21に示します。DTagフィールドとWフィールドはオプションであり、それらの存在は各モードとプロファイルによって指定されます。 FCNフィールドはすべて1です。
|--- Sender-Abort Header ----|
|-- T --|-M-|-- N --|
+-- ... -+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~
| RuleID | DTag | W | 11..1 | padding (as needed)
+-- ... -+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~
Figure 21: SCHC Sender-Abort Format
図21：SCHC送信機アボートフォーマット
If the W field is present:
Wフィールドが存在する場合：
* the fragment sender MUST set it to all ones. Other values are RESERVED.
* フラグメント送信者はそれをすべて1に設定する必要があります。その他の値は予約済みです。
* the fragment receiver MUST check its value. If the value is different from all ones, the message MUST be ignored.
* フラグメントレシーバーはその値をチェックする必要があります。値がすべてのものと異なる場合は、メッセージを無視する必要があります。
The SCHC Sender-Abort MUST NOT be acknowledged.
SCHC Sender-Abortは承認されてはなりません。
When a SCHC Fragment receiver needs to abort an ongoing fragmented SCHC Packet transmission, it transmits a SCHC Receiver-Abort message to the SCHC Fragment sender.
SCHCフラグメント受信者は、進行中の断片化されたSCHCパケット送信を中止する必要がある場合、SCHC受信者中止メッセージをSCHCフラグメント送信者に送信します。
The SCHC Receiver-Abort format is shown in Figure 22. The DTag field and the W field are OPTIONAL, their presence is specified by each mode and Profile.
SCHC Receiver-Abortフォーマットを図22に示します。DTagフィールドとWフィールドはオプションであり、それらの存在は各モードとプロファイルによって指定されます。
|-- Receiver-Abort Header ---|
|--- T ---|-M-| 1 |
+--- ... --+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+
| RuleID | DTag | W |C=1| 1..1| 1..1 |
+--- ... --+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+
next L2 Word boundary ->|<-- L2 Word -->|
Figure 22: SCHC Receiver-Abort Format
図22：SCHCレシーバーアボートフォーマット
If the W field is present:
Wフィールドが存在する場合：
* the fragment receiver MUST set it to all ones. Other values are RESERVED.
* フラグメント受信者はそれをすべて1に設定する必要があります。その他の値は予約済みです。
* if the value is different from all ones, the fragment sender MUST ignore the message.
* 値がすべてのものと異なる場合、フラグメント送信者はメッセージを無視する必要があります。
The SCHC Receiver-Abort has the same header as a SCHC ACK message. The bits that follow the SCHC Receiver-Abort Header MUST be as follows:
SCHC Receiver-Abortには、SCHC ACKメッセージと同じヘッダーがあります。 SCHC Receiver-Abortヘッダーに続くビットは、次のようにする必要があります。
* if the Header does not end at an L2 Word boundary, append bits set to 1 as needed to reach the next L2 Word boundary.
* ヘッダーがL2ワード境界で終了しない場合、次のL2ワード境界に到達するために、必要に応じて1に設定されたビットを追加します。
* append exactly one more L2 Word with bits all set to ones.
* ビットをすべて1に設定して、L2ワードをもう1つ追加します。
Such a bit pattern never occurs in a legitimate SCHC ACK. This is how the fragment sender recognizes a SCHC Receiver-Abort.
このようなビットパターンは、正当なSCHC ACKでは発生しません。これは、フラグメント送信者がSCHC受信者中止を認識する方法です。
The SCHC Receiver-Abort MUST NOT be acknowledged.
SCHCレシーバアボートは確認されてはなりません。
This specification includes several SCHC F/R modes that:
この仕様には、以下のSCHC F / Rモードがいくつか含まれています。
* allow for a range of reliability options, such as optional SCHC Fragment retransmission.
* オプションのSCHCフラグメント再送信など、さまざまな信頼性オプションを可能にします。
* support various LPWAN characteristics, such as links with variable MTU or unidirectional links.
* 可変MTUを持つリンクや単方向リンクなど、さまざまなLPWAN特性をサポートします。
More modes may be defined in the future.
今後、さらに多くのモードが定義される可能性があります。
Appendix B provides examples of fragmentation sessions based on the modes described hereafter.
付録Bは、これから説明するモードに基づくフラグメンテーションセッションの例を示しています。
Appendix C provides examples of Finite State Machines implementing the SCHC F/R modes described hereafter.
付録Cは、以下で説明するSCHC F / Rモードを実装する有限状態機械の例を示しています。
The No-ACK mode has been designed under the assumption that data unit out-of-sequence delivery does not occur between the entity performing fragmentation and the entity performing reassembly. This mode supports L2 technologies that have a variable MTU.
No-ACKモードは、フラグメント化を実行するエンティティと再構成を実行するエンティティの間でデータユニットのシーケンス外配信が発生しないことを前提に設計されています。このモードは、可変MTUを持つL2テクノロジーをサポートします。
In No-ACK mode, there is no communication from the fragment receiver to the fragment sender. The sender transmits all the SCHC Fragments without expecting any acknowledgement. Therefore, No-ACK does not require bidirectional links: unidirectional links are just fine.
No-ACKモードでは、フラグメント受信者からフラグメント送信者への通信はありません。送信者は、確認を期待せずにすべてのSCHCフラグメントを送信します。したがって、No-ACKは双方向リンクを必要としません。単方向リンクで十分です。
In No-ACK mode, only the All-1 SCHC Fragment is padded as needed. The other SCHC Fragments are intrinsically aligned to L2 Words.
No-ACKモードでは、All-1 SCHCフラグメントのみが必要に応じてパディングされます。他のSCHCフラグメントは、本質的にL2ワードに揃えられています。
The tile sizes are not required to be uniform. Windows are not used. The Retransmission Timer is not used. The Attempts counter is not used.
タイルのサイズは均一である必要はありません。窓は使用していません。再送信タイマーは使用されません。 Attemptsカウンターは使用されません。
Each Profile MUST specify which RuleID value(s) corresponds to SCHC F/R messages operating in this mode.
各プロファイルは、このモードで動作するSCHC F / Rメッセージに対応するRuleID値を指定する必要があります。
The W field MUST NOT be present in the SCHC F/R messages. SCHC ACK MUST NOT be sent. SCHC ACK REQ MUST NOT be sent. SCHC Sender-Abort MAY be sent. SCHC Receiver-Abort MUST NOT be sent.
WフィールドはSCHC F / Rメッセージに存在してはならない（MUST NOT）。 SCHC ACKを送信してはなりません。 SCHC ACK REQを送信してはならない（MUST NOT）。 SCHC Sender-Abortが送信される場合があります。 SCHC Receiver-Abortは送信してはなりません（MUST NOT）。
The value of N (size of the FCN field) is RECOMMENDED to be 1.
N（FCNフィールドのサイズ）の値は1にすることをお勧めします。
Each Profile, for each RuleID value, MUST define:
各RuleID値の各プロファイルは、以下を定義する必要があります。
* the size of the DTag field,
* DTagフィールドのサイズ
* the size and algorithm for the RCS field, and
* RCSフィールドのサイズとアルゴリズム、および
* the expiration time of the Inactivity Timer.
* 非活動タイマーの有効期限。
Each Profile, for each RuleID value, MAY define
各プロファイルは、各RuleID値に対して、定義してもよい（MAY）
* a value of N different from the recommended one, and
* 推奨値とは異なるNの値、および
* the meaning of values sent in the FCN field, for values different from the All-1 value.
* FCNフィールドで送信される値の意味（All-1値と異なる値の場合）。
For each active pair of RuleID and DTag values, the receiver MUST maintain an Inactivity Timer. If the receiver is under-resourced to do this, it MUST silently drop the related messages.
RuleID値とDTag値のアクティブなペアごとに、レシーバーは非アクティブタイマーを維持する必要があります。これを行うためにリソースが不足している場合、受信者は関連するメッセージを静かにドロップしなければなりません（MUST）。
At the beginning of the fragmentation of a new SCHC Packet, the fragment sender MUST select a RuleID and DTag value pair for this SCHC Packet.
新しいSCHCパケットのフラグメンテーションの開始時に、フラグメント送信者はこのSCHCパケットのRuleIDとDTag値のペアを選択する必要があります。
Each SCHC Fragment MUST contain exactly one tile in its Payload. The tile MUST be at least the size of an L2 Word. The sender MUST transmit the SCHC Fragments messages in the order that the tiles appear in the SCHC Packet. Except for the last tile of a SCHC Packet, each tile MUST be of a size that complements the SCHC Fragment Header so that the SCHC Fragment is a multiple of L2 Words without the need for padding bits. Except for the last one, the SCHC Fragments MUST use the Regular SCHC Fragment format specified in Section 8.3.1.1. The SCHC Fragment that carries the last tile MUST be an All-1 SCHC Fragment, described in Section 8.3.1.2.
各SCHCフラグメントは、ペイロードにタイルを1つだけ含める必要があります。タイルは少なくともL2ワードのサイズでなければなりません。送信者は、タイルがSCHCパケットに表示される順序でSCHCフラグメントメッセージを送信する必要があります。 SCHCパケットの最後のタイルを除いて、各タイルはSCHCフラグメントヘッダーを補完するサイズである必要があり、そのためSCHCフラグメントはパディングビットを必要としないL2ワードの倍数になります。最後のものを除いて、SCHCフラグメントはセクション8.3.1.1で指定された通常のSCHCフラグメント形式を使用する必要があります。最後のタイルを運ぶSCHCフラグメントは、セクション8.3.1.2で説明されているAll-1 SCHCフラグメントである必要があります。
The sender MAY transmit a SCHC Sender-Abort.
送信者はSCHC Sender-Abortを送信してもよい（MAY）。
Figure 39 shows an example of a corresponding state machine.
図39に、対応するステートマシンの例を示します。
Upon receiving each Regular SCHC Fragment:
通常のSCHCフラグメントを受信すると、次のようになります。
* the receiver MUST reset the Inactivity Timer.
* レシーバーは、非アクティブタイマーをリセットする必要があります。
* the receiver assembles the payloads of the SCHC Fragments.
* レシーバーはSCHCフラグメントのペイロードを組み立てます。
On receiving an All-1 SCHC Fragment:
All-1 SCHCフラグメントを受信すると：
* the receiver MUST append the All-1 SCHC Fragment Payload and the padding bits to the previously received SCHC Fragment Payloads for this SCHC Packet.
* 受信者は、All-1 SCHCフラグメントペイロードとパディングビットを、このSCHCパケットの以前に受信したSCHCフラグメントペイロードに追加する必要があります。
* the receiver MUST perform the integrity check.
* 受信者は整合性チェックを実行する必要があります。
* if integrity checking fails, the receiver MUST drop the reassembled SCHC Packet.
* 整合性チェックが失敗した場合、受信者は再構成されたSCHCパケットをドロップする必要があります。
* the reassembly operation concludes.
* 再組み立て操作は終了します。
On expiration of the Inactivity Timer, the receiver MUST drop the SCHC Packet being reassembled.
非アクティブタイマーの期限が切れると、レシーバーは再構成されているSCHCパケットをドロップする必要があります。
On receiving a SCHC Sender-Abort, the receiver MAY drop the SCHC Packet being reassembled.
SCHC Sender-Abortを受信すると、レシーバーは再構成されているSCHCパケットをドロップする場合があります。
Figure 40 shows an example of a corresponding state machine.
図40に、対応するステートマシンの例を示します。
The ACK-Always mode has been designed under the following assumptions:
ACK-Alwaysモードは、以下の前提の下で設計されています。
* Data unit out-of-sequence delivery does not occur between the entity performing fragmentation and the entity performing reassembly,
* データユニットの順不同配信は、フラグメント化を実行するエンティティと再構成を実行するエンティティの間では発生しません。
* The L2 MTU value does not change while the fragments of a SCHC Packet are being transmitted, and
* L2 MTU値は、SCHCパケットのフラグメントが送信されている間は変化しません。
* There is a feedback path from the reassembler to the fragmenter. See Appendix F for a discussion on using ACK-Always mode on quasi-bidirectional links.
* リアセンブラからフラグメンタへのフィードバックパスがあります。準双方向リンクでACK-Alwaysモードを使用する方法については、付録Fを参照してください。
In ACK-Always mode, windows are used. An acknowledgement, positive or negative, is transmitted by the fragment receiver to the fragment sender at the end of the transmission of each window of SCHC Fragments.
ACK-Alwaysモードでは、ウィンドウが使用されます。 SCHCフラグメントの各ウィンドウの送信の最後に、肯定応答または否定応答がフラグメント受信者によってフラグメント送信者に送信されます。
The tiles are not required to be of uniform size. In ACK-Always mode, only the All-1 SCHC Fragment is padded as needed. The other SCHC Fragments are intrinsically aligned to L2 Words.
タイルは均一なサイズである必要はありません。 ACK-Alwaysモードでは、All-1 SCHCフラグメントのみが必要に応じて埋め込まれます。他のSCHCフラグメントは、本質的にL2ワードに揃えられています。
Briefly, the algorithm is as follows: after a first blind transmission of all the tiles of a window, the fragment sender iterates retransmitting the tiles that are reported missing until the fragment receiver reports that all the tiles belonging to the window have been correctly received or until too many attempts were made. The fragment sender only advances to the next window of tiles when it has ascertained that all the tiles belonging to the current window have been fully and correctly received. This results in a per-window lock-step behavior between the sender and the receiver.
簡単に言うと、アルゴリズムは次のとおりです。ウィンドウのすべてのタイルの最初のブラインド送信の後、フラグメント送信者は、フラグメント受信者がウィンドウに属するすべてのタイルが正しく受信されたと報告するまで、欠落が報告されたタイルの再送信を繰り返します。あまりにも多くの試みがなされるまで。フラグメント送信者は、現在のウィンドウに属するすべてのタイルが完全かつ正しく受信されたことを確認した場合にのみ、次のタイルウィンドウに進みます。これにより、送信者と受信者の間でウィンドウごとのロックステップ動作が発生します。
Each Profile MUST specify which RuleID value(s) correspond to SCHC F/ R messages operating in this mode.
各プロファイルは、このモードで動作するSCHC F / Rメッセージに対応するRuleID値を指定する必要があります。
The W field MUST be present and its size M MUST be 1 bit.
Wフィールドが存在しなければならず、そのサイズMは1ビットでなければなりません。
Each Profile, for each RuleID value, MUST define:
各RuleID値の各プロファイルは、以下を定義する必要があります。
* the value of N,
* Nの値
* the value of WINDOW_SIZE, which MUST be strictly less than 2^N,
* WINDOW_SIZEの値。厳密には2 ^ N未満でなければなりません。
* the size and algorithm for the RCS field,
* RCSフィールドのサイズとアルゴリズム
* the value of T,
* Tの値
* the value of MAX_ACK_REQUESTS,
* MAX_ACK_REQUESTSの値、
* the expiration time of the Retransmission Timer, and
* 再送信タイマーの有効期限、および
* the expiration time of the Inactivity Timer.
* 非活動タイマーの有効期限。
For each active pair of RuleID and DTag values, the sender MUST maintain:
RuleIDとDTag値のアクティブなペアごとに、送信者は以下を維持する必要があります：
* one Attempts counter
* 1つの試行カウンター
* one Retransmission Timer
* 1つの再送信タイマー
For each active pair of RuleID and DTag values, the receiver MUST maintain
RuleID値とDTag値のアクティブなペアごとに、受信者は維持する必要があります
* one Inactivity Timer, and
* 1つの非アクティブタイマー、および
* one Attempts counter.
* 1つの試行カウンター。
At the beginning of the fragmentation of a new SCHC Packet, the fragment sender MUST select a RuleID and DTag value pair for this SCHC Packet.
新しいSCHCパケットのフラグメンテーションの開始時に、フラグメント送信者はこのSCHCパケットのRuleIDとDTag値のペアを選択する必要があります。
Each SCHC Fragment MUST contain exactly one tile in its Payload. All tiles with the index 0, as well as the last tile, MUST be at least the size of an L2 Word.
各SCHCフラグメントは、ペイロードにタイルを1つだけ含める必要があります。インデックス0のすべてのタイルと最後のタイルは、少なくともL2ワードのサイズでなければなりません。
In all SCHC Fragment messages, the W field MUST be filled with the LSB of the window number that the sender is currently processing.
すべてのSCHCフラグメントメッセージで、Wフィールドには、送信者が現在処理しているウィンドウ番号のLSBを入力する必要があります。
For a SCHC Fragment that carries a tile other than the last one of the SCHC Packet:
SCHCパケットの最後のタイル以外のタイルを運ぶSCHCフラグメントの場合：
* the Fragment MUST be of the Regular type specified in Section 8.3.1.1.
* フラグメントは、セクション8.3.1.1で指定された通常のタイプである必要があります。
* the FCN field MUST contain the tile index.
* FCNフィールドにはタイルインデックスを含める必要があります。
* each tile MUST be of a size that complements the SCHC Fragment Header so that the SCHC Fragment is a multiple of L2 Words without the need for padding bits.
* 各タイルは、SCHCフラグメントヘッダーを補完するサイズである必要があります。これにより、SCHCフラグメントは、パディングビットを必要としないL2ワードの倍数になります。
The SCHC Fragment that carries the last tile MUST be an All-1 SCHC Fragment, described in Section 8.3.1.2.
最後のタイルを運ぶSCHCフラグメントは、セクション8.3.1.2で説明されているAll-1 SCHCフラグメントである必要があります。
The fragment sender MUST start by transmitting the window numbered 0.
フラグメント送信者は、0の番号が付いたウィンドウを送信することから開始する必要があります。
All message receptions being discussed in the rest of this section are to be understood as "matching the RuleID and DTag pair being processed", even if not spelled out, for brevity.
このセクションの残りの部分で説明されているすべてのメッセージ受信は、簡潔にするために、綴られていなくても、「処理されているRuleIDとDTagのペアを一致させる」と理解されます。
The sender starts by a "blind transmission" phase, in which it MUST transmit all the tiles composing the window, in decreasing tile index order.
送信者は「ブラインド送信」フェーズで開始します。このフェーズでは、ウィンドウを構成するすべてのタイルをタイルインデックスの順序で送信する必要があります。
Then, it enters a "retransmission phase" in which it MUST initialize an Attempts counter to 0, it MUST start a Retransmission Timer and it MUST await a SCHC ACK.
次に、「再送信フェーズ」に入り、試行カウンタを0に初期化する必要があります。再送信タイマーを開始する必要があり、SCHC ACKを待機する必要があります。
* Then, upon receiving a SCHC ACK:
* 次に、SCHC ACKを受信すると：
- if the SCHC ACK indicates that some tiles are missing at the receiver, then the sender MUST transmit all the tiles that have been reported missing, it MUST increment Attempts, it MUST reset the Retransmission Timer, and MUST await the next SCHC ACK.
- SCHC ACKが一部のタイルがレシーバーで欠落していることを示している場合、送信者は欠落が報告されたすべてのタイルを送信する必要があり、試行をインクリメントし、再送信タイマーをリセットし、次のSCHC ACKを待機する必要があります。
- if the current window is not the last one and the SCHC ACK indicates that all tiles were correctly received, the sender MUST stop the Retransmission Timer, it MUST advance to the next fragmentation window, and it MUST start a blind transmission phase as described above.
- 現在のウィンドウが最後のウィンドウではなく、SCHC ACKがすべてのタイルが正しく受信されたことを示している場合、送信者は再送信タイマーを停止し、次の断片化ウィンドウに進み、上記のようにブラインド送信フェーズを開始する必要があります。
- if the current window is the last one and the SCHC ACK indicates that more tiles were received than the sender sent, the fragment sender MUST send a SCHC Sender-Abort, and it MAY exit with an error condition.
- 現在のウィンドウが最後のウィンドウであり、送信者よりも多くのタイルが受信されたことをSCHC ACKが示している場合、フラグメント送信者はSCHC Sender-Abortを送信する必要があり、エラー状態で終了する場合があります。
- if the current window is the last one and the SCHC ACK indicates that all tiles were correctly received, yet the integrity check was a failure, the fragment sender MUST send a SCHC Sender-Abort, and it MAY exit with an error condition.
- 現在のウィンドウが最後のウィンドウであり、SCHC ACKがすべてのタイルが正しく受信されたことを示しているにもかかわらず、整合性チェックが失敗した場合、フラグメント送信者はSCHC Sender-Abortを送信する必要があり、エラー状態で終了する場合があります。
- if the current window is the last one and the SCHC ACK indicates that integrity checking was successful, the sender exits successfully.
- 現在のウィンドウが最後のウィンドウであり、SCHC ACKが整合性チェックが成功したことを示している場合、送信者は正常に終了します。
* on Retransmission Timer expiration:
* 再送信タイマーの期限切れ時：
- if Attempts is strictly less that MAX_ACK_REQUESTS, the fragment sender MUST send a SCHC ACK REQ and MUST increment the Attempts counter.
- AttemptsがMAX_ACK_REQUESTSよりも厳密に小さい場合、フラグメント送信者はSCHC ACK REQを送信する必要があり、Attemptsカウンターをインクリメントする必要があります。
- otherwise, the fragment sender MUST send a SCHC Sender-Abort, and it MAY exit with an error condition.
- それ以外の場合、フラグメント送信者はSCHC Sender-Abortを送信する必要があり、エラー状態で終了する場合があります。
At any time:
いつでも：
* on receiving a SCHC Receiver-Abort, the fragment sender MAY exit with an error condition.
* SCHC Receiver-Abortを受信すると、フラグメント送信者はエラー状態で終了する場合があります。
* on receiving a SCHC ACK that bears a W value different from the W value that it currently uses, the fragment sender MUST silently discard and ignore that SCHC ACK.
* 現在使用しているW値とは異なるW値を持つSCHC ACKを受信すると、フラグメント送信者はそのSCHC ACKを静かに破棄して無視する必要があります。
Figure 41 shows an example of a corresponding state machine.
図41に、対応するステートマシンの例を示します。
On receiving a SCHC Fragment with a RuleID and DTag pair not being processed at that time:
RuleIDとDTagのペアがその時点で処理されていないSCHCフラグメントを受信すると、次のようになります。
* the receiver SHOULD check if the DTag value has not recently been used for that RuleID value, thereby ensuring that the received SCHC Fragment is not a remnant of a prior fragmented SCHC Packet transmission. The initial value of the Inactivity Timer is the RECOMMENDED lifetime for the DTag value at the receiver. If the SCHC Fragment is determined to be such a remnant, the receiver MAY silently ignore it and discard it.
* 受信者は、そのRuleID値にDTag値が最近使用されていないかどうかを確認して、受信したSCHCフラグメントが以前の断片化されたSCHCパケット送信の残骸ではないことを確認する必要があります。非アクティビティタイマーの初期値は、受信側でのDTag値の推奨ライフタイムです。 SCHCフラグメントがそのような残りであると決定されるならば、受信機はそれを黙って無視して、それを破棄するかもしれません。
* the receiver MUST start a process to assemble a new SCHC Packet with that RuleID and DTag value pair.
* 受信者は、そのRuleIDとDTag値のペアで新しいSCHCパケットをアセンブルするプロセスを開始する必要があります。
* the receiver MUST start an Inactivity Timer for that RuleID and DTag pair. It MUST initialize an Attempts counter to 0 for that RuleID and DTag pair. It MUST initialize a window counter to 0. If the receiver is under-resourced to do this, it MUST respond to the sender with a SCHC Receiver-Abort.
* 受信者は、RuleIDとDTagのペアの非アクティブタイマーを開始する必要があります。 RuleIDとDTagのペアのAttemptsカウンターを0に初期化する必要があります。ウィンドウカウンターを0に初期化する必要があります。これを行うためにリソースが不足している場合は、SCHCレシーバーアボートで送信者に応答する必要があります。
In the rest of this section, "local W bit" means the least significant bit of the window counter of the receiver.
このセクションの残りの部分では、「ローカルWビット」は、受信機のウィンドウカウンターの最下位ビットを意味します。
On reception of any SCHC F/R message for the RuleID and DTag pair being processed, the receiver MUST reset the Inactivity Timer pertaining to that RuleID and DTag pair.
処理中のRuleIDとDTagペアのSCHC F / Rメッセージを受信すると、受信者は、そのRuleIDとDTagペアに関連する非アクティブタイマーをリセットする必要があります。
All message receptions being discussed in the rest of this section are to be understood as "matching the RuleID and DTag pair being processed", even if not spelled out, for brevity.
このセクションの残りの部分で説明されているすべてのメッセージ受信は、簡潔にするために、綴られていなくても、「処理されているRuleIDとDTagのペアを一致させる」と理解されます。
The receiver MUST first initialize an empty Bitmap for the first window then enter an "acceptance phase", in which:
受信者は、最初のウィンドウの空のビットマップを最初に初期化しなければならず、次に「受け入れフェーズ」に入る必要があります。
* on receiving a SCHC Fragment or a SCHC ACK REQ, either one having the W bit different from the local W bit, the receiver MUST silently ignore and discard that message.
* SCHCフラグメントまたはSCHC ACK REQ（ローカルWビットとは異なるWビットを持っているもの）を受信すると、受信者はそのメッセージを黙って無視して破棄しなければなりません（MUST）。
* on receiving a SCHC ACK REQ with the W bit equal to the local W bit, the receiver MUST send a SCHC ACK for this window.
* ローカルWビットに等しいWビットを持つSCHC ACK REQを受信すると、受信者はこのウィンドウに対してSCHC ACKを送信する必要があります。
* on receiving a SCHC Fragment with the W bit equal to the local W bit, the receiver MUST assemble the received tile based on the window counter and on the FCN field in the SCHC Fragment, and it MUST update the Bitmap.
* WビットがローカルWビットと等しいSCHCフラグメントを受信すると、受信機はウィンドウカウンターとSCHCフラグメントのFCNフィールドに基づいて受信したタイルをアセンブルする必要があり、ビットマップを更新する必要があります。
- if the SCHC Fragment received is an All-0 SCHC Fragment, the current window is determined to be a not-last window, the receiver MUST send a SCHC ACK for this window and it MUST enter the "retransmission phase" for this window.
- 受信したSCHCフラグメントがAll-0 SCHCフラグメントである場合、現在のウィンドウは最後でないウィンドウであると判断され、受信者はこのウィンドウのSCHC ACKを送信しなければならず、このウィンドウの「再送信フェーズ」に入る必要があります。
- if the SCHC Fragment received is an All-1 SCHC Fragment, the current window is determined to be the last window, the padding bits of the All-1 SCHC Fragment MUST be assembled after the received tile, the receiver MUST perform the integrity check and it MUST send a SCHC ACK for this window. Then:
- 受信したSCHCフラグメントがAll-1 SCHCフラグメントである場合、現在のウィンドウは最後のウィンドウであると判断され、受信したタイルの後にAll-1 SCHCフラグメントのパディングビットをアセンブルする必要があり、受信者は整合性チェックを実行する必要があります。このウィンドウに対してSCHC ACKを送信する必要があります。次に：
o If the integrity check indicates that the full SCHC Packet has been correctly reassembled, the receiver MUST enter the "clean-up phase" for this window.
o 完全性チェックにより、完全なSCHCパケットが正しく再構成されたことが示された場合、受信者はこのウィンドウの「クリーンアップフェーズ」に入る必要があります。
o If the integrity check indicates that the full SCHC Packet has not been correctly reassembled, the receiver enters the "retransmission phase" for this window.
o 完全性チェックで完全なSCHCパケットが正しく再構成されていないことが示された場合、受信機はこのウィンドウの「再送信フェーズ」に入ります。
In the "retransmission phase":
「再送信フェーズ」では：
* if the window is a not-last window:
* ウィンドウが最後でないウィンドウの場合：
- on receiving a SCHC Fragment that is not All-0 or All-1 and that has a W bit different from the local W bit, the receiver MUST increment its window counter and allocate a fresh Bitmap, it MUST assemble the tile received and update the Bitmap, and it MUST enter the "acceptance phase" for that new window.
- All-0またはAll-1ではなく、ローカルWビットとは異なるWビットを持つSCHCフラグメントを受信すると、受信者はウィンドウカウンターをインクリメントし、新しいビットマップを割り当てなければなりません。受信したタイルをアセンブルして更新する必要があります。ビットマップ、そしてそれはその新しいウィンドウの「受け入れ段階」に入る必要があります。
- on receiving a SCHC ACK REQ with a W bit different from the local W bit, the receiver MUST increment its window counter and allocate a fresh Bitmap, it MUST send a SCHC ACK for that new window, and it MUST enter the "acceptance phase" for that new window.
- ローカルWビットとは異なるWビットのSCHC ACK REQを受信すると、受信者はそのウィンドウカウンターをインクリメントし、新しいビットマップを割り当てなければならず、その新しいウィンドウにSCHC ACKを送信しなければなりません。また、「受け入れフェーズ」に入る必要があります。その新しいウィンドウのために。
- on receiving a SCHC All-0 Fragment with a W bit different from the local W bit, the receiver MUST increment its window counter and allocate a fresh Bitmap, it MUST assemble the tile received and update the Bitmap, it MUST send a SCHC ACK for that new window, and it MUST stay in the "retransmission phase" for that new window.
- ローカルWビットとは異なるWビットのSCHC All-0 Fragmentを受信すると、受信者はそのウィンドウカウンターをインクリメントし、新しいビットマップを割り当てる必要があります。受信したタイルをアセンブルしてビットマップを更新する必要があり、SCHC ACKを送信する必要がありますその新しいウィンドウ、およびその新しいウィンドウの「再送信フェーズ」にとどまる必要があります。
- on receiving a SCHC All-1 Fragment with a W bit different from the local W bit, the receiver MUST increment its window counter and allocate a fresh Bitmap; it MUST assemble the tile received, including the padding bits; it MUST update the Bitmap and perform the integrity check; it MUST send a SCHC ACK for the new window, which is determined to be the last window. Then:
- ローカルのWビットとは異なるWビットのSCHC All-1 Fragmentを受信すると、受信者はウィンドウカウンターをインクリメントし、新しいビットマップを割り当てる必要があります。パディングビットを含め、受け取ったタイルをアセンブルする必要があります。ビットマップを更新して整合性チェックを実行する必要があります。最後のウィンドウであると判断された新しいウィンドウに対してSCHC ACKを送信する必要があります。次に：
o If the integrity check indicates that the full SCHC Packet has been correctly reassembled, the receiver MUST enter the "clean-up phase" for that new window.
o 完全性チェックで完全なSCHCパケットが正しく再構成されたことが示された場合、受信者はその新しいウィンドウの「クリーンアップフェーズ」に入る必要があります。
o If the integrity check indicates that the full SCHC Packet has not been correctly reassembled, the receiver enters the "retransmission phase" for that new window.
o 完全性チェックで完全なSCHCパケットが正しく再構成されていないことが示された場合、受信者はその新しいウィンドウの「再送信フェーズ」に入ります。
- on receiving a SCHC Fragment with a W bit equal to the local W bit:
- ローカルWビットと等しいWビットのSCHCフラグメントを受信すると、次のようになります。
o if the SCHC Fragment received is an All-1 SCHC Fragment, the receiver MUST silently ignore it and discard it.
o 受信したSCHCフラグメントがAll-1 SCHCフラグメントである場合、受信者はそれを黙って無視し、破棄しなければなりません（MUST）。
o otherwise, the receiver MUST assemble the tile received and update the Bitmap. If the Bitmap becomes fully populated with 1's or if the SCHC Fragment is an All-0, the receiver MUST send a SCHC ACK for this window.
o それ以外の場合、受信者は受信したタイルを組み立ててビットマップを更新する必要があります。ビットマップが完全に1で埋められた場合、またはSCHCフラグメントがAll-0の場合、受信者はこのウィンドウに対してSCHC ACKを送信する必要があります。
- on receiving a SCHC ACK REQ with the W bit equal to the local W bit, the receiver MUST send a SCHC ACK for this window.
- ローカルWビットに等しいWビットを持つSCHC ACK REQを受信すると、受信者はこのウィンドウに対してSCHC ACKを送信する必要があります。
* if the window is the last window:
* ウィンドウが最後のウィンドウである場合：
- on receiving a SCHC Fragment or a SCHC ACK REQ, either one having a W bit different from the local W bit, the receiver MUST silently ignore and discard that message.
- SCHCフラグメントまたはSCHC ACK REQ（ローカルWビットとは異なるWビットを持っているもの）を受信すると、受信者はメッセージを黙って無視して破棄しなければなりません（MUST）。
- on receiving a SCHC ACK REQ with the W bit equal to the local W bit, the receiver MUST send a SCHC ACK for this window.
- ローカルWビットに等しいWビットを持つSCHC ACK REQを受信すると、受信者はこのウィンドウに対してSCHC ACKを送信する必要があります。
- on receiving a SCHC Fragment with a W bit equal to the local W bit:
- ローカルWビットと等しいWビットのSCHCフラグメントを受信すると、次のようになります。
o if the SCHC Fragment received is an All-0 SCHC Fragment, the receiver MUST silently ignore it and discard it.
o 受信したSCHCフラグメントがAll-0 SCHCフラグメントである場合、受信機はそれを黙って無視して破棄しなければなりません（MUST）。
o otherwise, the receiver MUST update the Bitmap, and it MUST assemble the tile received. If the SCHC Fragment received is an All-1 SCHC Fragment, the receiver MUST assemble the padding bits of the All-1 SCHC Fragment after the received tile, it MUST perform the integrity check and:
o それ以外の場合、レシーバーはビットマップを更新する必要があり、受信したタイルをアセンブルする必要があります。受信したSCHCフラグメントがAll-1 SCHCフラグメントである場合、受信機は受信したタイルの後にAll-1 SCHCフラグメントのパディングビットをアセンブルする必要があり、整合性チェックを実行しなければなりません。
+ if the integrity check indicates that the full SCHC Packet has been correctly reassembled, the receiver MUST send a SCHC ACK and it enters the "clean-up phase".
+ 完全性チェックにより、完全なSCHCパケットが正しく再構成されたことが示された場合、受信者はSCHC ACKを送信する必要があり、「クリーンアップフェーズ」に入ります。
+ if the integrity check indicates that the full SCHC Packet has not been correctly reassembled:
+ 完全性チェックで、完全なSCHCパケットが正しく再構成されていないことが示された場合：
* if the SCHC Fragment received was an All-1 SCHC Fragment, the receiver MUST send a SCHC ACK for this window.
* 受信したSCHCフラグメントがAll-1 SCHCフラグメントである場合、受信者はこのウィンドウに対してSCHC ACKを送信する必要があります。
In the "clean-up phase":
「クリーンアップ段階」：
* On receiving an All-1 SCHC Fragment or a SCHC ACK REQ, either one having the W bit equal to the local W bit, the receiver MUST send a SCHC ACK.
* All-1 SCHCフラグメントまたはSCHC ACK REQのいずれかを受信すると、WビットがローカルのWビットと等しい場合、受信者はSCHC ACKを送信する必要があります。
* Any other SCHC Fragment received MUST be silently ignored and discarded.
* 受信した他のSCHCフラグメントは、通知なく無視されて破棄される必要があります。
At any time, on sending a SCHC ACK, the receiver MUST increment the Attempts counter.
いつでも、SCHC ACKを送信すると、受信者は試行カウンタをインクリメントする必要があります。
At any time, on incrementing its window counter, the receiver MUST reset the Attempts counter.
いつでも、そのウィンドウカウンターをインクリメントするときに、レシーバーは試行カウンターをリセットする必要があります。
At any time, on expiration of the Inactivity Timer, on receiving a SCHC Sender-Abort or when Attempts reaches MAX_ACK_REQUESTS, the receiver MUST send a SCHC Receiver-Abort, and it MAY exit the receive process for that SCHC Packet.
いつでも、非アクティブタイマーの満了時、SCHC送信者中止の受信時、または試行がMAX_ACK_REQUESTSに達した場合、受信者はSCHC受信者中止を送信する必要があり、そのSCHCパケットの受信プロセスを終了する場合があります。
Figure 42 shows an example of a corresponding state machine.
図42に、対応するステートマシンの例を示します。
The ACK-on-Error mode supports L2 technologies that have variable MTU and out-of-order delivery. It requires an L2 that provides a feedback path from the reassembler to the fragmenter. See Appendix F for a discussion on using ACK-on-Error mode on quasi-bidirectional links.
ACK-on-Errorモードは、可変MTUと順不同配信を持つL2テクノロジーをサポートします。リアセンブラからフラグメンタへのフィードバックパスを提供するL2が必要です。疑似双方向リンクでACK-on-Errorモードを使用する方法については、付録Fを参照してください。
In ACK-on-Error mode, windows are used.
ACK-on-Errorモードでは、ウィンドウが使用されます。
All tiles except the last one and the penultimate one MUST be of equal size, hereafter called "regular". The size of the last tile MUST be smaller than or equal to the regular tile size. Regarding the penultimate tile, a Profile MUST pick one of the following two options:
最後のタイルと最後から2番目のタイルを除くすべてのタイルは同じサイズである必要があり、以下「レギュラー」と呼びます。最後のタイルのサイズは、通常のタイルサイズ以下でなければなりません。最後から2番目のタイルに関して、プロファイルは次の2つのオプションのいずれかを選択する必要があります。
* The penultimate tile size MUST be the regular tile size, or
* 最後から2番目のタイルサイズは、通常のタイルサイズである必要があります。
* the penultimate tile size MUST be either the regular tile size or the regular tile size minus one L2 Word.
* 最後から2番目のタイルサイズは、通常のタイルサイズまたは通常のタイルサイズから1 L2ワードを引いたものでなければなりません。
A SCHC Fragment message carries one or several contiguous tiles, which may span multiple windows. A SCHC ACK reports on the reception of exactly one window of tiles.
SCHCフラグメントメッセージは、1つまたは複数の連続したタイルを伝送します。これらのタイルは、複数のウィンドウにまたがることがあります。 SCHC ACKは、タイルのウィンドウを1つだけ受信したことを報告します。
See Figure 23 for an example.
例については、図23を参照してください。
+---------------------------------------------...-----------+
| SCHC Packet |
+---------------------------------------------...-----------+
Tile# | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 |3|
Window# |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|- 28-|
SCHC Fragment msg |-----------|
Figure 23: SCHC Packet Fragmented in Tiles, ACK-on-Error Mode
図23：タイルで断片化されたSCHCパケット、ACK-on-Errorモード
The W field is wide enough that it unambiguously represents an absolute window number. The fragment receiver sends SCHC ACKs to the fragment sender about windows for which tiles are missing. No SCHC ACK is sent by the fragment receiver for windows that it knows have been fully received.
Wフィールドは、ウィンドウの絶対数を明確に表すのに十分な幅です。フラグメント受信者は、タイルが欠落しているウィンドウに関するSCHC ACKをフラグメント送信者に送信します。 SCHC ACKは、完全に受信されたことがわかっているウィンドウに対してフラグメントレシーバーから送信されません。
The fragment sender retransmits SCHC Fragments for tiles that are reported missing. It can advance to next windows even before it has ascertained that all tiles belonging to previous windows have been correctly received, and it can still later retransmit SCHC Fragments with tiles belonging to previous windows. Therefore, the sender and the receiver may operate in a decoupled fashion. The fragmented SCHC Packet transmission concludes when:
フラグメント送信者は、欠落が報告されているタイルのSCHCフラグメントを再送信します。前のウィンドウに属するすべてのタイルが正しく受信されたことを確認する前でも、次のウィンドウに進むことができます。また、前のウィンドウに属するタイルを含むSCHCフラグメントを後で再送信することもできます。したがって、送信側と受信側は分離して動作する場合があります。断片化されたSCHCパケット送信は、次の場合に終了します。
* integrity checking shows that the fragmented SCHC Packet has been correctly reassembled at the receive end, and this information has been conveyed back to the sender, or
* 整合性チェックにより、断片化されたSCHCパケットが受信側で正しく再構成され、この情報が送信者に戻されたか、または
* too many retransmission attempts were made, or
* 再送信の試行回数が多すぎる、または
* the receiver determines that the transmission of this fragmented SCHC Packet has been inactive for too long.
* 受信者は、この断片化されたSCHCパケットの送信が長時間非アクティブであると判断します。
Each Profile MUST specify which RuleID value(s) corresponds to SCHC F/R messages operating in this mode.
各プロファイルは、このモードで動作するSCHC F / Rメッセージに対応するRuleID値を指定する必要があります。
The W field MUST be present in the SCHC F/R messages.
WフィールドはSCHC F / Rメッセージに存在する必要があります。
Each Profile, for each RuleID value, MUST define:
各RuleID値の各プロファイルは、以下を定義する必要があります。
* the tile size (a tile does not need to be multiple of an L2 Word, but it MUST be at least the size of an L2 Word),
* タイルサイズ（タイルはL2ワードの倍数である必要はありませんが、少なくともL2ワードのサイズである必要があります）、
* the value of M,
* Mの値、
* the value of N,
* Nの値、
* the value of WINDOW_SIZE, which MUST be strictly less than 2^N,
* WINDOW_SIZEの値。厳密には2 ^ N未満でなければなりません。
* the size and algorithm for the RCS field,
* RCSフィールドのサイズとアルゴリズム
* the value of T,
* Tの値
* the value of MAX_ACK_REQUESTS,
* MAX_ACK_REQUESTSの値、
* the expiration time of the Retransmission Timer,
* 再送信タイマーの有効期限
* the expiration time of the Inactivity Timer,
* 非活動タイマーの有効期限
* if the last tile is carried in a Regular SCHC Fragment or an All-1 SCHC Fragment (see Section 8.4.3.1), and
* 最後のタイルが通常のSCHCフラグメントまたはAll-1 SCHCフラグメントで運ばれる場合（セクション8.4.3.1を参照）、および
* if the penultimate tile MAY be one L2 Word smaller than the regular tile size. In this case, the regular tile size MUST be at least twice the L2 Word size.
* 最後から2番目のタイルが通常のタイルサイズよりも1 L2ワード小さい場合があります。この場合、通常のタイルサイズは少なくともL2ワードサイズの2倍でなければなりません。
For each active pair of RuleID and DTag values, the sender MUST maintain:
RuleIDとDTag値のアクティブなペアごとに、送信者は以下を維持する必要があります：
* one Attempts counter, and
* 1つの試行カウンタ、および
* one Retransmission Timer.
* 1つの再送信タイマー。
For each active pair of RuleID and DTag values, the receiver MUST maintain:
RuleIDとDTagの値のアクティブなペアごとに、レシーバーは以下を維持する必要があります。
* one Inactivity Timer, and
* 1つの非アクティブタイマー、および
* one Attempts counter.
* 1つの試行カウンター。
At the beginning of the fragmentation of a new SCHC Packet:
新しいSCHCパケットの断片化の初めに：
* the fragment sender MUST select a RuleID and DTag value pair for this SCHC Packet. A Rule MUST NOT be selected if the values of M and WINDOW_SIZE for that Rule are such that the SCHC Packet cannot be fragmented in (2^M) * WINDOW_SIZE tiles or less.
* フラグメント送信者は、このSCHCパケットのRuleIDとDTag値のペアを選択する必要があります。 SCHCパケットが（2 ^ M）* WINDOW_SIZEタイル以下にフラグメント化できないようなルールのMおよびWINDOW_SIZEの値である場合、ルールを選択してはなりません（MUST NOT）。
* the fragment sender MUST initialize the Attempts counter to 0 for that RuleID and DTag value pair.
* フラグメント送信者は、そのRuleIDとDTag値のペアのAttemptsカウンターを0に初期化する必要があります。
A Regular SCHC Fragment message carries in its payload one or more tiles. If more than one tile is carried in one Regular SCHC Fragment:
通常のSCHCフラグメントメッセージは、ペイロードに1つ以上のタイルを含みます。 1つの通常のSCHCフラグメントに複数のタイルが含まれている場合：
* the selected tiles MUST be contiguous in the original SCHC Packet, and
* 選択されたタイルは、元のSCHCパケットで隣接している必要があります。
* they MUST be placed in the SCHC Fragment Payload adjacent to one another, in the order they appear in the SCHC Packet, from the start of the SCHC Packet toward its end.
* それらは、互いに隣接するSCHCフラグメントペイロードに、SCHCパケットの先頭から末尾に向かって、SCHCパケットに出現する順序で配置する必要があります。
Tiles that are not the last one MUST be sent in Regular SCHC Fragments specified in Section 8.3.1.1. The FCN field MUST contain the tile index of the first tile sent in that SCHC Fragment.
最後のものではないタイルは、セクション8.3.1.1で指定された通常のSCHCフラグメントで送信する必要があります。 FCNフィールドには、そのSCHCフラグメントで送信される最初のタイルのタイルインデックスが含まれている必要があります。
In a Regular SCHC Fragment message, the sender MUST fill the W field with the window number of the first tile sent in that SCHC Fragment.
通常のSCHCフラグメントメッセージでは、送信者はWフィールドにそのSCHCフラグメントで送信された最初のタイルのウィンドウ番号を入力する必要があります。
A Profile MUST define if the last tile of a SCHC Packet is sent:
プロファイルは、SCHCパケットの最後のタイルが送信されるかどうかを定義する必要があります。
* in a Regular SCHC Fragment, alone or as part of a multi-tiles Payload,
* 通常のSCHCフラグメントで、単独で、またはマルチタイルペイロードの一部として、
* alone in an All-1 SCHC Fragment, or
* All-1 SCHCフラグメントに単独で、または
* with any of the above two methods.
* 上記の2つの方法のいずれかを使用します。
In an All-1 SCHC Fragment message, the sender MUST fill the W field with the window number of the last tile of the SCHC Packet.
All-1 SCHCフラグメントメッセージでは、送信者はWフィールドにSCHCパケットの最後のタイルのウィンドウ番号を入力する必要があります。
The fragment sender MUST send SCHC Fragments such that, all together, they contain all the tiles of the fragmented SCHC Packet.
フラグメント送信者は、すべて一緒に、フラグメント化されたSCHCパケットのすべてのタイルを含むようにSCHCフラグメントを送信する必要があります。
The fragment sender MUST send at least one All-1 SCHC Fragment.
フラグメント送信者は、少なくとも1つのAll-1 SCHCフラグメントを送信する必要があります。
In doing the two items above, the sender MUST ascertain that the receiver will not receive the last tile through both a Regular SCHC Fragment and an All-1 SCHC Fragment.
上記の2つの項目を実行する際、送信者は、受信者が通常のSCHCフラグメントとAll-1 SCHCフラグメントの両方を介して最後のタイルを受信しないことを確認する必要があります。
The fragment sender MUST listen for SCHC ACK messages after having sent:
フラグメント送信者は、送信後にSCHC ACKメッセージをリッスンする必要があります。
* an All-1 SCHC Fragment, or
* All-1 SCHCフラグメント、または
* a SCHC ACK REQ.
* SCHC ACK REQ。
A Profile MAY specify other times at which the fragment sender MUST listen for SCHC ACK messages. For example, this could be after sending a complete window of tiles.
プロファイルは、フラグメント送信者がSCHC ACKメッセージをリッスンしなければならない他の時間を指定してもよい（MAY）。たとえば、タイルの完全なウィンドウを送信した後などです。
Each time a fragment sender sends an All-1 SCHC Fragment or a SCHC ACK REQ:
フラグメント送信者がAll-1 SCHCフラグメントまたはSCHC ACK REQを送信するたび：
* it MUST increment the Attempts counter, and
* Attemptsカウンターをインクリメントする必要があります。
* it MUST reset the Retransmission Timer.
* 再送信タイマーをリセットする必要があります。
On Retransmission Timer expiration:
再送信タイマーの有効期限：
* if the Attempts counter is strictly less than MAX_ACK_REQUESTS, the fragment sender MUST send either the All-1 SCHC Fragment or a SCHC ACK REQ with the W field corresponding to the last window,
* AttemptsカウンターがMAX_ACK_REQUESTSよりも厳密に小さい場合、フラグメント送信者は、All-1 SCHCフラグメントまたは最後のウィンドウに対応するWフィールドを持つSCHC ACK REQのいずれかを送信する必要があります。
* otherwise, the fragment sender MUST send a SCHC Sender-Abort, and it MAY exit with an error condition.
* それ以外の場合、フラグメント送信者はSCHC Sender-Abortを送信する必要があり、エラー状態で終了する場合があります。
All message receptions being discussed in the rest of this section are to be understood as "matching the RuleID and DTag pair being processed", even if not spelled out, for brevity.
このセクションの残りの部分で説明されているすべてのメッセージ受信は、簡潔にするために、綴られていなくても、「処理されているRuleIDとDTagのペアを一致させる」と理解されます。
On receiving a SCHC ACK:
SCHC ACKを受信すると：
* if the W field in the SCHC ACK corresponds to the last window of the SCHC Packet:
* SCHC ACKのWフィールドがSCHCパケットの最後のウィンドウに対応する場合：
- if the C bit is set, the sender MAY exit successfully.
- Cビットが設定されている場合、送信側は正常に終了する場合があります。
- otherwise:
- さもないと：
o if the Profile mandates that the last tile be sent in an All-1 SCHC Fragment:
o プロファイルが最後のタイルをAll-1 SCHCフラグメントで送信することを義務付けている場合：
+ if the SCHC ACK shows no missing tile at the receiver, the sender:
+ SCHC ACKが受信側で欠落しているタイルを示さない場合、送信側：
* MUST send a SCHC Sender-Abort, and
* SCHC Sender-Abortを送信する必要があります。
* MAY exit with an error condition.
* エラー状態で終了する場合があります。
+ otherwise:
+ さもないと：
* the fragment sender MUST send SCHC Fragment messages containing all the tiles that are reported missing in the SCHC ACK.
* フラグメント送信者は、SCHC ACKで欠落していると報告されているすべてのタイルを含むSCHCフラグメントメッセージを送信する必要があります。
* if the last of these SCHC Fragment messages is not an All-1 SCHC Fragment, then the fragment sender MUST in addition send after it a SCHC ACK REQ with the W field corresponding to the last window.
* これらのSCHCフラグメントメッセージの最後がAll-1 SCHCフラグメントでない場合、フラグメント送信者はさらに、最後のウィンドウに対応するWフィールドを持つSCHC ACK REQを送信する必要があります。
* in doing the two items above, the sender MUST ascertain that the receiver will not receive the last tile through both a Regular SCHC Fragment and an All-1 SCHC Fragment.
* 上記の2つの項目を行う場合、送信者は、受信者が通常のSCHCフラグメントとAll-1 SCHCフラグメントの両方を介して最後のタイルを受信しないことを確認する必要があります。
o otherwise:
o さもないと：
+ if the SCHC ACK shows no missing tile at the receiver, the sender MUST send the All-1 SCHC Fragment
+ SCHC ACKが受信側で欠落しているタイルを示さない場合、送信側はAll-1 SCHCフラグメントを送信する必要があります
+ otherwise:
+ さもないと：
* the fragment sender MUST send SCHC Fragment messages containing all the tiles that are reported missing in the SCHC ACK.
* フラグメント送信者は、SCHC ACKで欠落していると報告されているすべてのタイルを含むSCHCフラグメントメッセージを送信する必要があります。
* the fragment sender MUST then send either the All-1 SCHC Fragment or a SCHC ACK REQ with the W field corresponding to the last window.
* フラグメント送信者は、最後のウィンドウに対応するWフィールドを含むAll-1 SCHCフラグメントまたはSCHC ACK REQを送信する必要があります。
* otherwise, the fragment sender:
* それ以外の場合、フラグメント送信者：
- MUST send SCHC Fragment messages containing the tiles that are reported missing in the SCHC ACK.
- SCHC ACKで欠落していると報告されているタイルを含むSCHCフラグメントメッセージを送信する必要があります。
- then, it MAY send a SCHC ACK REQ with the W field corresponding to the last window.
- 次に、最後のウィンドウに対応するWフィールドを持つSCHC ACK REQを送信する場合があります。
See Figure 43 for one among several possible examples of a Finite State Machine implementing a sender behavior obeying this specification.
この仕様に従って送信者の動作を実装する有限状態機械の考えられる例の1つについては、図43を参照してください。
On receiving a SCHC Fragment with a RuleID and DTag pair not being processed at that time:
RuleIDとDTagのペアがその時点で処理されていないSCHCフラグメントを受信すると、次のようになります。
* the receiver SHOULD check if the DTag value has not recently been used for that RuleID value, thereby ensuring that the received SCHC Fragment is not a remnant of a prior fragmented SCHC Packet transmission. The initial value of the Inactivity Timer is the RECOMMENDED lifetime for the DTag value at the receiver. If the SCHC Fragment is determined to be such a remnant, the receiver MAY silently ignore it and discard it.
* 受信者は、そのRuleID値にDTag値が最近使用されていないかどうかを確認して、受信したSCHCフラグメントが以前の断片化されたSCHCパケット送信の残骸ではないことを確認する必要があります。非アクティビティタイマーの初期値は、受信側でのDTag値の推奨ライフタイムです。 SCHCフラグメントがそのような残りであると決定されるならば、受信機はそれを黙って無視して、それを破棄するかもしれません。
* the receiver MUST start a process to assemble a new SCHC Packet with that RuleID and DTag value pair. The receiver MUST start an Inactivity Timer for that RuleID and DTag value pair. It MUST initialize an Attempts counter to 0 for that RuleID and DTag value pair. If the receiver is under-resourced to do this, it MUST respond to the sender with a SCHC Receiver-Abort.
* 受信者は、そのRuleIDとDTag値のペアで新しいSCHCパケットを組み立てるためのプロセスを開始する必要があります。受信者は、RuleIDとDTag値のペアに対して非アクティブタイマーを開始する必要があります。 RuleIDとDTagの値のペアに対して、試行カウンタを0に初期化する必要があります。これを行うために受信者のリソースが不足している場合は、SCHC受信者アボートで送信者に応答する必要があります。
On reception of any SCHC F/R message for the RuleID and DTag pair being processed, the receiver MUST reset the Inactivity Timer pertaining to that RuleID and DTag pair.
処理中のRuleIDとDTagペアのSCHC F / Rメッセージを受信すると、受信者は、そのRuleIDとDTagペアに関連する非アクティブタイマーをリセットする必要があります。
All message receptions being discussed in the rest of this section are to be understood as "matching the RuleID and DTag pair being processed", even if not spelled out, for brevity.
このセクションの残りの部分で説明されているすべてのメッセージ受信は、簡潔にするために、綴られていなくても、「処理されているRuleIDとDTagのペアを一致させる」と理解されます。
On receiving a SCHC Fragment message, the receiver determines what tiles were received, based on the payload length and on the W and FCN fields of the SCHC Fragment.
SCHCフラグメントメッセージを受信すると、ペイロード長とSCHCフラグメントのWおよびFCNフィールドに基づいて、受信者は受信したタイルを決定します。
* if the FCN is All-1, if a Payload is present, the full SCHC Fragment Payload MUST be assembled including the padding bits. This is because the size of the last tile is not known by the receiver; therefore, padding bits are indistinguishable from the tile data bits, at this stage. They will be removed by the SCHC C/D sublayer. If the size of the SCHC Fragment Payload exceeds or equals the size of one regular tile plus the size of an L2 Word, this SHOULD raise an error flag.
* FCNがAll-1の場合、ペイロードが存在する場合、パディングビットを含む完全なSCHCフラグメントペイロードをアセンブルする必要があります。これは、最後のタイルのサイズが受信者に認識されていないためです。したがって、この段階では、パディングビットはタイルデータビットと区別できません。それらはSCHC C / Dサブレイヤーによって削除されます。 SCHCフラグメントペイロードのサイズが1つの通常のタイルのサイズにL2ワードのサイズを加えたサイズ以上である場合、これはエラーフラグを発生させる必要があります（SHOULD）。
* otherwise, tiles MUST be assembled based on the a priori known tile size.
* それ以外の場合は、アプリオリに既知のタイルサイズに基づいてタイルをアセンブルする必要があります。
- If allowed by the Profile, the end of the payload MAY contain the last tile, which may be shorter. Padding bits are indistinguishable from the tile data bits, at this stage.
- プロファイルで許可されている場合、ペイロードの最後には、より短い可能性がある最後のタイルが含まれる場合があります。この段階では、パディングビットはタイルデータビットと区別できません。
- The payload may contain the penultimate tile that, if allowed by the Profile, MAY be exactly one L2 Word shorter than the regular tile size.
- ペイロードには最後から2番目のタイルが含まれる場合があり、プロファイルで許可されている場合は、通常のタイルサイズよりもL2ワード1つ短くなる場合があります。
- Otherwise, padding bits MUST be discarded. This is possible because:
- それ以外の場合は、パディングビットを破棄する必要があります。これは次の理由で可能です。
o the size of the tiles is known a priori,
o タイルのサイズは事前にわかっています。
o tiles are larger than an L2 Word, and
o タイルがL2ワードよりも大きい
o padding bits are always strictly less than an L2 Word.
o パディングビットは常に厳密にL2ワードよりも小さくなります。
On receiving a SCHC ACK REQ or an All-1 SCHC Fragment:
SCHC ACK REQまたはAll-1 SCHCフラグメントを受信すると：
* if the receiver knows of any windows with missing tiles for the packet being reassembled, it MUST return a SCHC ACK for the lowest-numbered such window:
* レシーバーは、再構成されているパケットのタイルが欠落しているウィンドウを知っている場合、そのようなウィンドウの最も小さい番号のSCHC ACKを返さなければなりません（MUST）。
* otherwise:
* さもないと：
- if it has received at least one tile, it MUST return a SCHC ACK for the highest-numbered window it currently has tiles for,
- 少なくとも1つのタイルを受信した場合は、現在タイルがある最大番号のウィンドウに対してSCHC ACKを返さなければなりません。
- otherwise, it MUST return a SCHC ACK for window numbered 0.
- それ以外の場合は、ウィンドウ番号0のSCHC ACKを返す必要があります。
A Profile MAY specify other times and circumstances at which a receiver sends a SCHC ACK, and which window the SCHC ACK reports about in these circumstances.
プロファイルは、レシーバーがSCHC ACKを送信する他の時間と状況、およびこれらの状況でSCHC ACKが報告するウィンドウを指定する場合があります。
Upon sending a SCHC ACK, the receiver MUST increase the Attempts counter.
SCHC ACKを送信すると、受信者は試行カウンタを増加する必要があります。
After receiving an All-1 SCHC Fragment, a receiver MUST check the integrity of the reassembled SCHC Packet at least every time it prepares for sending a SCHC ACK for the last window.
All-1 SCHCフラグメントを受信した後、受信者は、少なくとも最後のウィンドウにSCHC ACKを送信する準備をするたびに、再構成されたSCHCパケットの整合性をチェックする必要があります。
Upon receiving a SCHC Sender-Abort, the receiver MAY exit with an error condition.
SCHC Sender-Abortを受信すると、レシーバーはエラー状態で終了する場合があります。
Upon expiration of the Inactivity Timer, the receiver MUST send a SCHC Receiver-Abort, and it MAY exit with an error condition.
非アクティブタイマーの期限が切れると、受信者はSCHC受信者アボートを送信する必要があり、エラー状態で終了する場合があります。
On the Attempts counter exceeding MAX_ACK_REQUESTS, the receiver MUST send a SCHC Receiver-Abort, and it MAY exit with an error condition.
MAX_ACK_REQUESTSを超えるAttemptsカウンターでは、受信者はSCHC受信者アボートを送信する必要があり、エラー状態で終了する場合があります。
Reassembly of the SCHC Packet concludes when:
SCHCパケットの再構成は、次の場合に終了します。
* a Sender-Abort has been received, or
* Sender-Abortが受信された、または
* the Inactivity Timer has expired, or
* 非活動タイマーの期限が切れている、または
* the Attempts counter has exceeded MAX_ACK_REQUESTS, or
* AttemptsカウンターがMAX_ACK_REQUESTSを超えている、または
* at least an All-1 SCHC Fragment has been received and integrity checking of the reassembled SCHC Packet is successful.
* 少なくともAll-1 SCHCフラグメントが受信されており、再構成されたSCHCパケットの整合性チェックが成功しています。
See Figure 44 for one among several possible examples of a Finite State Machine implementing a receiver behavior obeying this specification. The example provided is meant to match the sender Finite State Machine of Figure 43.
この仕様に従うレシーバーの動作を実装する有限状態機械のいくつかの可能な例の1つについては、図44を参照してください。提供されている例は、図43の送信側の有限状態機械と一致するように意図されています。
SCHC C/D and SCHC F/R operate on bits, not bytes. SCHC itself does not have any alignment prerequisite. The size of SCHC Packets can be any number of bits.
SCHC C / DおよびSCHC F / Rは、バイトではなくビットで動作します。 SCHC自体には、配置の前提条件はありません。 SCHCパケットのサイズは、任意のビット数にすることができます。
If the L2 constrains the payload to align to coarser boundaries (for example, bytes), the SCHC messages MUST be padded. When padding occurs, the number of appended bits MUST be strictly less than the L2 Word size.
L2がペイロードをより粗い境界（バイトなど）に揃えるように制約する場合は、SCHCメッセージをパディングする必要があります。パディングが発生する場合、追加されるビットの数は、L2ワードサイズより厳密に小さくなければなりません。
If a SCHC Packet is sent unfragmented (see Figure 24), it is padded as needed for transmission.
SCHCパケットが断片化されずに送信される場合（図24を参照）、送信のために必要に応じてパディングされます。
If a SCHC Packet needs to be fragmented for transmission, it is not padded in itself. Only the SCHC F/R messages are padded as needed for transmission. Some SCHC F/R messages are intrinsically aligned to L2 Words.
SCHCパケットを送信用にフラグメント化する必要がある場合、それ自体はパディングされません。 SCHC F / Rメッセージのみが、送信のために必要に応じて埋め込まれます。一部のSCHC F / Rメッセージは、本質的にL2ワードに揃えられています。
A packet (e.g., an IPv6 packet)
| ^ (padding bits
v | dropped)
+------------------+ +--------------------+
| SCHC Compression | | SCHC Decompression |
+------------------+ +--------------------+
| ^
| If no fragmentation, |
+---- SCHC Packet + padding as needed ----->|
| | (integrity
v | checked)
+--------------------+ +-----------------+
| SCHC Fragmentation | | SCHC Reassembly |
+--------------------+ +-----------------+
| ^ | ^
| | | |
| +--- SCHC ACK + padding as needed --+ |
| |
+------- SCHC Fragments + padding as needed---------+
Sender Receiver
送信者受信者
Figure 24: SCHC Operations, Including Padding as Needed
図24：必要に応じてパディングを含むSCHC操作
Each Profile MUST specify the size of the L2 Word. The L2 Word might actually be a single bit, in which case no padding will take place at all.
各プロファイルは、L2ワードのサイズを指定する必要があります。 L2ワードは実際には単一ビットである場合があり、その場合、パディングはまったく行われません。
A Profile MUST define the value of the padding bits if the L2 Word is wider than a single bit. The RECOMMENDED value is 0.
L2ワードが単一ビットより広い場合、プロファイルはパディングビットの値を定義する必要があります。推奨値は0です。
This section lists the IPv6 and UDP header fields and describes how they can be compressed. An example of a set of Rules for UDP/IPv6 header compression is provided in Appendix A.
このセクションでは、IPv6およびUDPヘッダーフィールドを一覧表示し、それらの圧縮方法について説明します。 UDP / IPv6ヘッダー圧縮のルールセットの例を付録Aに示します。
The IPv6 version field is labeled by the protocol parser as being the "version" field of the IPv6 protocol. Therefore, it only exists for IPv6 packets. In the Rule, TV is set to 6, MO to "ignore" and CDA to "not-sent".
IPv6バージョンフィールドは、プロトコルパーサーによってIPv6プロトコルの「バージョン」フィールドとしてラベル付けされます。したがって、IPv6パケットにのみ存在します。ルールでは、TVは6、MOは「無視」、CDAは「送信しない」に設定されています。
If the Diffserv field does not vary and is known by both sides, the Field Descriptor in the Rule SHOULD contain a TV with this well-known value, an "equal" MO, and a "not-sent" CDA.
Diffservフィールドが変化せず、両側で既知である場合、ルールのフィールド記述子には、この既知の値を持つTV、「等しい」MO、および「送信されない」CDAが含まれる必要があります（SHOULD）。
Otherwise (e.g., ECN bits are to be transmitted), two possibilities can be considered depending on the variability of the value:
それ以外の場合（たとえば、ECNビットが送信される場合）、値の変動性に応じて2つの可能性が考えられます。
* One possibility is to not compress the field and send the original value. In the Rule, TV is not set to any particular value, MO is set to "ignore", and CDA is set to "value-sent".
* 1つの可能性は、フィールドを圧縮せずに元の値を送信することです。ルールでは、TVは特定の値に設定されておらず、MOは「無視」に設定されており、CDAは「値送信」に設定されています。
* If some upper bits in the field are constant and known, a better option is to only send the LSBs. In the Rule, TV is set to a value with the stable known upper part, MO is set to MSB(x), and CDA to LSB.
* フィールドの一部の上位ビットが一定で既知である場合、LSBのみを送信することをお勧めします。ルールでは、TVは安定した上部が既知の値に設定され、MOはMSB（x）に設定され、CDAはLSBに設定されます。
ECN functionality depends on both bits of the ECN field, which are the 2 LSBs of this field; hence, sending only a single LSB of this field is NOT RECOMMENDED.
ECN機能は、このフィールドの2 LSBであるECNフィールドの両方のビットに依存します。したがって、このフィールドのLSBを1つだけ送信することはお勧めしません。
If the flow label is not set, i.e., its value is zero, the Field Descriptor in the Rule SHOULD contain a TV set to zero, an "equal" MO, and a "not-sent" CDA.
フローラベルが設定されていない場合、つまりその値がゼロの場合、ルールのフィールド記述子には、ゼロに設定されたTV、「等しい」MO、および「送信されていない」CDAが含まれる必要があります（SHOULD）。
If the flow label is set to a pseudorandom value according to [RFC6437], in the Rule, TV is not set to any particular value, MO is set to "ignore", and CDA is set to "value-sent".
[RFC6437]に従ってフローラベルが疑似ランダム値に設定されている場合、ルールでは、TVは特定の値に設定されず、MOは「無視」に設定され、CDAは「値送信」に設定されます。
If the flow label is set according to some prior agreement, i.e., by a flow state establishment method as allowed by [RFC6437], the Field Descriptor in the Rule SHOULD contain a TV with this agreed-upon value, an "equal" MO, and a "not-sent" CDA.
フローラベルが事前の合意に従って設定されている場合、つまり、[RFC6437]で許可されているフロー状態確立方法によって設定されている場合、ルールのフィールド記述子には、この合意された値である「等しい」MOを持つTVが含まれる必要があります（SHOULD）。 「未送信」のCDA。
This field can be elided for the transmission on the LPWAN. The SCHC C/D recomputes the original payload length value. In the Field Descriptor, TV is not set, MO is set to "ignore", and CDA is "compute-*".
このフィールドは、LPWANでの送信では省略できます。 SCHC C / Dは、元のペイロード長の値を再計算します。フィールド記述子では、TVは設定されておらず、MOは「無視」に設定されており、CDAは「compute- *」です。
If the Next Header field does not vary and is known by both sides, the Field Descriptor in the Rule SHOULD contain a TV with this Next Header value, the MO SHOULD be "equal", and the CDA SHOULD be "not-sent".
次のヘッダーフィールドが変化せず、両側で認識されている場合、ルールのフィールド記述子には、この次のヘッダー値を持つTVが含まれている必要があり、MOは「等しい」であり、CDAは「送信されていない」必要があります（SHOULD）。
Otherwise, TV is not set in the Field Descriptor, MO is set to "ignore", and CDA is set to "value-sent". Alternatively, a matching-list MAY also be used.
それ以外の場合、TVはフィールド記述子で設定されず、MOは「無視」に設定され、CDAは「値送信」に設定されます。あるいは、matching-listも使用できます。
The field behavior for this field is different for Uplink and Downlink. In Uplink, since there is no IP forwarding between the Dev and the SCHC C/D, the value is relatively constant. On the other hand, the Downlink value depends on Internet routing and can change more frequently. The DI can be used to distinguish both directions:
このフィールドのフィールド動作は、アップリンクとダウンリンクで異なります。アップリンクでは、DevとSCHC C / Dの間にIP転送がないため、値は比較的一定です。一方、ダウンリンク値はインターネットルーティングに依存し、より頻繁に変更される可能性があります。 DIは両方向を区別するために使用できます。
* in an Up Field Descriptor, elide the field: the TV is set to the known constant value, the MO is set to "equal" and the CDA is set to "not-sent".
* アップフィールドディスクリプタで、フィールドを除外します。TVは既知の定数値に設定され、MOは「等しい」に設定され、CDAは「送信されない」に設定されます。
* in a Dw Field Descriptor, the Hop Limit is elided for transmission and forced to 1 at the receiver, by setting TV to 1, MO to "ignore" and CDA to "not-sent". This prevents any further forwarding.
* Dwフィールド記述子では、TVを1に、MOを「無視」に、CDAを「送信しない」に設定することで、ホップリミットが送信から除外され、受信側で強制的に1に設定されます。これにより、それ以上の転送が防止されます。
As in 6LoWPAN [RFC4944], IPv6 addresses are split into two 64-bit-long fields; one for the prefix and one for the Interface Identifier (IID). These fields SHOULD be compressed. To allow for a single Rule being used for both directions, these values are identified by their role (Dev or App) and not by their position in the header (source or destination).
6LoWPAN [RFC4944]と同様に、IPv6アドレスは64ビット長の2つのフィールドに分割されます。 1つはプレフィックス用、もう1つはインターフェイス識別子（IID）用です。これらのフィールドは圧縮する必要があります。単一のルールを両方向で使用できるようにするために、これらの値は、ヘッダー内の位置（ソースまたは宛先）ではなく、役割（DevまたはApp）によって識別されます。
Both ends MUST be configured with the appropriate prefixes. For a specific flow, the source and destination prefixes can be unique and stored in the Context. In that case, the TV for the source and destination prefixes contain the values, the MO is set to "equal" and the CDA is set to "not-sent".
両端は適切なプレフィックスで設定する必要があります。特定のフローでは、送信元と宛先のプレフィックスを一意にして、コンテキストに保存できます。その場合、送信元と宛先のプレフィックスのTVに値が含まれ、MOは「等しい」に設定され、CDAは「送信されない」に設定されます。
If the Rule is intended to compress packets with different prefix values, match-mapping SHOULD be used. The different prefixes are listed in the TV, the MO is set to "match-mapping" and the CDA is set to "mapping-sent". See Figure 26.
ルールが異なるプレフィックス値を持つパケットを圧縮することを目的としている場合、マッチマッピングを使用する必要があります（SHOULD）。さまざまなプレフィックスがTVにリストされ、MOは「match-mapping」に設定され、CDAは「mapping-sent」に設定されます。図26を参照してください。
Otherwise, the TV is not set, the MO is set to "ignore", and the CDA is set to "value-sent".
そうでない場合、TVは設定されず、MOは「無視」に設定され、CDAは「値送信」に設定されます。
If the Dev or App IID are based on an L2 address, then the IID can be reconstructed with information coming from the L2 header. In that case, the TV is not set, the MO is set to "ignore" and the CDA is set to "DevIID" or "AppIID". On LPWAN technologies where the frames carry a single identifier (corresponding to the Dev), AppIID cannot be used.
DevまたはAppのIIDがL2アドレスに基づいている場合、L2ヘッダーからの情報を使用してIIDを再構築できます。その場合、TVは設定されず、MOは「無視」に設定され、CDAは「DevIID」または「AppIID」に設定されます。フレームが単一の識別子（Devに対応）を運ぶLPWANテクノロジーでは、AppIIDは使用できません。
As described in [RFC8065], it may be undesirable to build the Dev IPv6 IID out of the Dev address. Another static value is used instead. In that case, the TV contains the static value, the MO operator is set to "equal" and the CDA is set to "not-sent".
[RFC8065]で説明されているように、DevアドレスからDev IPv6 IIDを構築することは望ましくない場合があります。代わりに別の静的な値が使用されます。その場合、TVには静的な値が含まれ、MO演算子は「等しい」に設定され、CDAは「送信されない」に設定されます。
If several IIDs are possible, then the TV contains the list of possible IIDs, the MO is set to "match-mapping" and the CDA is set to "mapping-sent".
いくつかのIIDが可能である場合、TVには可能なIIDのリストが含まれ、MOは「match-mapping」に設定され、CDAは「mapping-sent」に設定されます。
It may also happen that the IID variability only expresses itself on a few bytes. In that case, the TV is set to the stable part of the IID, the MO is set to "MSB" and the CDA is set to "LSB".
また、IIDの変動性が数バイトでしか表現されない場合もあります。その場合、TVはIIDの安定部分に設定され、MOは「MSB」に設定され、CDAは「LSB」に設定されます。
Finally, the IID can be sent in its entirety on the L2. In that case, the TV is not set, the MO is set to "ignore", and the CDA is set to "value-sent".
最後に、IID全体をL2に送信できます。その場合、TVは設定されず、MOは「無視」に設定され、CDAは「値送信」に設定されます。
This document does not provide recommendations on how to compress IPv6 extension headers.
このドキュメントでは、IPv6拡張ヘッダーの圧縮方法に関する推奨事項は提供していません。
To allow for a single Rule being used for both directions, the UDP port values are identified by their role (Dev or App) and not by their position in the header (source or destination). The SCHC C/D MUST be aware of the traffic direction (Uplink, Downlink) to select the appropriate field. The following Rules apply for Dev and App port numbers.
単一のルールを両方向で使用できるようにするために、UDPポート値は、ヘッダー内の位置（ソースまたは宛先）ではなく、役割（DevまたはApp）によって識別されます。 SCHC C / Dは、適切なフィールドを選択するためにトラフィックの方向（アップリンク、ダウンリンク）を認識している必要があります。以下のルールは、DevおよびAppのポート番号に適用されます。
If both ends know the port number, it can be elided. The TV contains the port number, the MO is set to "equal", and the CDA is set to "not-sent".
両端がポート番号を知っている場合は、省略できます。 TVにはポート番号が含まれ、MOは「等しい」に設定され、CDAは「送信されない」に設定されています。
If the port variation is on few bits, the TV contains the stable part of the port number, the MO is set to "MSB", and the CDA is set to "LSB".
ポートのバリエーションが数ビットの場合、TVにはポート番号の安定した部分が含まれ、MOは「MSB」に設定され、CDAは「LSB」に設定されます。
If some well-known values are used, the TV can contain the list of these values, the MO is set to "match-mapping", and the CDA is set to "mapping-sent".
一部の既知の値が使用されている場合、TVにはこれらの値のリストを含めることができ、MOは「match-mapping」に設定され、CDAは「mapping-sent」に設定されます。
Otherwise, the port numbers are sent over the L2. The TV is not set, the MO is set to "ignore" and the CDA is set to "value-sent".
それ以外の場合、ポート番号はL2経由で送信されます。 TVは設定されず、MOは「無視」に設定され、CDAは「値送信」に設定されます。
The parser MUST NOT label this field unless the UDP Length value matches the Payload Length value from the IPv6 header. The TV is not set, the MO is set to "ignore", and the CDA is set to "compute-*".
UDPの長さの値がIPv6ヘッダーからのペイロードの長さの値と一致しない限り、パーサーはこのフィールドにラベルを付けてはなりません（MUST NOT）。 TVは設定されておらず、MOは「無視」に設定されており、CDAは「計算-*」に設定されています。
The UDP checksum operation is mandatory with IPv6 for most packets, but there are exceptions [RFC8200].
UDPチェックサム操作は、ほとんどのパケットに対してIPv6で必須ですが、例外があります[RFC8200]。
For instance, protocols that use UDP as a tunnel encapsulation may enable zero-checksum mode for a specific port (or set of ports) for sending and/or receiving. [RFC8200] requires any node implementing zero-checksum mode to follow the requirements specified in "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936].
たとえば、UDPをトンネルカプセル化として使用するプロトコルでは、特定のポート（またはポートのセット）のゼロチェックサムモードを送信および/または受信用に有効にすることができます。 [RFC8200]は、ゼロチェックサムモードを実装するノードが、「ゼロチェックサムを使用したIPv6 UDPデータグラムの使用に関する適用性ステートメント」[RFC6936]で指定された要件に従う必要があります。
6LoWPAN Header Compression [RFC6282] also specifies that a UDP checksum can be elided by the compressor and recomputed by the decompressor when an upper layer guarantees the integrity of the UDP payload and pseudo-header. A specific example of this is when a message integrity check protects the compressed message between the compressor that elides the UDP checksum and the decompressor that computes it, with a strength that is identical or better to the UDP checksum.
6LoWPANヘッダー圧縮[RFC6282]では、上位層でUDPペイロードと疑似ヘッダーの整合性が保証されている場合、UDPチェックサムを圧縮プログラムで省略し、圧縮解除プログラムで再計算できることも指定されています。これの具体的な例は、UDPチェックサムと同じかそれ以上の強さで、メッセージ整合性チェックがUDPチェックサムを回避するコンプレッサーとそれを計算する解凍器の間の圧縮メッセージを保護する場合です。
Similarly, a SCHC compressor MAY elide the UDP checksum when another layer guarantees at least equal integrity protection for the UDP payload and the pseudo-header. In this case, the TV is not set, the MO is set to "ignore", and the CDA is set to "compute-*".
同様に、SCHCコンプレッサーは、別のレイヤーがUDPペイロードと疑似ヘッダーに対して少なくとも同等の完全性保護を保証する場合に、UDPチェックサムを省略してもよい（MAY）。この場合、TVは設定されておらず、MOは「無視」に設定されており、CDAは「計算-*」に設定されています。
In particular, when SCHC fragmentation is used, a fragmentation RCS of 2 bytes or more provides equal or better protection than the UDP checksum; in that case, if the compressor is collocated with the fragmentation point and the decompressor is collocated with the packet reassembly point, and if the SCHC Packet is fragmented even when it would fit unfragmented in the L2 MTU, then the compressor MAY verify and then elide the UDP checksum. Whether and when the UDP Checksum is elided is to be specified in the Profile.
特に、SCHCフラグメンテーションが使用される場合、2バイト以上のフラグメンテーションRCSは、UDPチェックサムと同等以上の保護を提供します。その場合、コンプレッサーがフラグメンテーションポイントと同じ場所にあり、デコンプレッサーがパケット再構成ポイントと同じ場所にあり、SCHCパケットがL2 MTUに断片化されていない場合でも断片化されている場合、コンプレッサーは検証してから除外することができます（MAY）。 UDPチェックサム。 UDPチェックサムが省略されるかどうか、およびいつ除去されるかは、プロファイルで指定されます。
Since the compression happens before the fragmentation, implementers should understand the risks when dealing with unprotected data below the transport layer and take special care when manipulating that data.
圧縮は断片化の前に行われるため、実装者は、トランスポート層の下にある保護されていないデータを処理する際のリスクを理解し、そのデータを操作するときに特別な注意を払う必要があります。
In other cases, the checksum SHOULD be explicitly sent. The TV is not set, the MO is set to "ignore" and the CDA is set to "value-sent".
他の場合では、チェックサムは明示的に送信されるべきです（SHOULD）。 TVは設定されず、MOは「無視」に設定され、CDAは「値送信」に設定されます。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
As explained in Section 5, SCHC is expected to be implemented on top of LPWAN technologies, which are expected to implement security measures.
セクション5で説明したように、SCHCは、セキュリティ対策の実装が期待されるLPWANテクノロジの上に実装されることが期待されています。
In this section, we analyze the potential security threats that could be introduced into an LPWAN by adding the SCHC functionalities.
このセクションでは、SCHC機能を追加することでLPWANに導入される可能性のある潜在的なセキュリティ脅威を分析します。
Let's assume that an attacker is able to send a forged SCHC Packet to a SCHC decompressor.
攻撃者が偽造されたSCHCパケットをSCHCデコンプレッサに送信できると仮定します。
Let's first consider the case where the RuleID contained in that forged SCHC Packet does not correspond to a Rule allocated in the Rule table. An implementation should detect that the RuleID is invalid and should silently drop the offending SCHC Packet.
まず、その偽造されたSCHCパケットに含まれるRuleIDが、ルールテーブルに割り当てられたルールに対応していない場合を考えてみましょう。実装はRuleIDが無効であることを検出し、問題のあるSCHCパケットを静かにドロップする必要があります。
Let's now consider that the RuleID corresponds to a Rule in the table. With the CDAs defined in this document, the reconstructed packet is, at most, a constant number of bits bigger than the SCHC Packet that was received. This assumes that the compute-* decompression actions produce a bounded number of bits, irrespective of the incoming SCHC Packet. This property is true for IPv6 Length, UDP Length, and UDP Checksum, for which the compute-* CDA is recommended by this document.
RuleIDがテーブル内のRuleに対応していると考えてみましょう。このドキュメントで定義されているCDAでは、再構築されたパケットは、多くても、受信されたSCHCパケットよりも大きい一定のビット数です。これは、着信SCHCパケットに関係なく、compute- *解凍アクションが制限された数のビットを生成すると想定しています。このプロパティは、IPv6の長さ、UDPの長さ、およびUDPチェックサムに当てはまります。このドキュメントでは、compute- * CDAが推奨されています。
As a consequence, SCHC decompression does not amplify attacks, beyond adding a bounded number of bits to the SCHC Packet received. This bound is determined by the Rule stored in the receiving device.
結果として、SCHC解凍は、受信したSCHCパケットに制限されたビット数を追加することを超えて、攻撃を増幅しません。この境界は、受信デバイスに格納されているルールによって決定されます。
As a general safety measure, a SCHC decompressor should never reconstruct a packet larger than MAX_PACKET_SIZE (defined in a Profile, with 1500 bytes as generic default).
一般的な安全対策として、SCHCデコンプレッサはMAX_PACKET_SIZE（プロファイルで定義され、一般的なデフォルトとして1500バイト）より大きいパケットを再構築してはなりません。
12.1.2. Compressed Packet Size as a Side Channel to Guess a Secret Token
12.1.2. シークレットトークンを推測するためのサイドチャネルとしての圧縮パケットサイズ
Some packet compression methods are known to be susceptible to attacks, such as BREACH and CRIME. The attack involves injecting arbitrary data into the packet and observing the resulting compressed packet size. The observed size potentially reflects correlation between the arbitrary data and some content that was meant to remain secret, such as a security token, thereby allowing the attacker to get at the secret.
BREACHやCRIMEなど、一部のパケット圧縮方法は攻撃を受けやすいことが知られています。攻撃には、パケットに任意のデータを挿入し、結果の圧縮パケットサイズを観察することが含まれます。観測されたサイズは、任意のデータと、セキュリティトークンなどの秘密にしておくべきコンテンツとの相関を潜在的に反映しているため、攻撃者は秘密を取得できます。
By contrast, SCHC compression takes place header field by header field, with the SCHC Packet being a mere concatenation of the compression residues of each of the individual field. Any correlation between header fields does not result in a change in the SCHC Packet size compressed under the same Rule.
対照的に、SCHC圧縮はヘッダーフィールドごとに行われ、SCHCパケットは個々のフィールドのそれぞれの圧縮残差の単なる連結です。ヘッダーフィールド間の相関により、同じルールで圧縮されたSCHCパケットサイズが変更されることはありません。
If SCHC C/D is used to compress packets that include a secret information field, such as a token, the Rule set should be designed so that the size of the compression residue for the field to remain secret is the same irrespective of the value of the secret information. This is achieved by, e.g., sending this field in extenso with the "ignore" MO and the "value-sent" CDA. This recommendation is disputable if it is ascertained that the Rule set itself will remain secret.
SCHC C / Dを使用して、トークンなどの秘密情報フィールドを含むパケットを圧縮する場合、フィールドが秘密のままである圧縮残差のサイズが、値に関係なく同じになるようにルールセットを設計する必要があります秘密の情報。これは、たとえば、このフィールドを「無視」MOと「値送信」CDAを含むエクステンソで送信することによって実現されます。この推奨事項は、ルールセット自体が秘密のままであることが確認された場合、異議を唱えられます。
As explained in Section 7.2, using FPs with value 0 in Field Descriptors in a Rule may result in header fields appearing in the decompressed packet in an order different from that in the original packet. Likewise, as stated in Section 7.4.3, using an "ignore" MO together with a "not-sent" CDA will result in the header field taking the TV value, which is likely to be different from the original value.
セクション7.2で説明したように、ルールのフィールド記述子で値0のFPを使用すると、元のパケットとは異なる順序で解凍されたパケットにヘッダーフィールドが表示される可能性があります。同様に、セクション7.4.3で述べたように、「無視」MOを「送信されていない」CDAと一緒に使用すると、ヘッダーフィールドにTV値が設定され、元の値とは異なる可能性があります。
Depending on the protocol, the order of header fields in the packet may or may not be functionally significant.
プロトコルによっては、パケットのヘッダーフィールドの順序が機能的に重要な場合とそうでない場合があります。
Furthermore, if the packet is protected by a checksum or a similar integrity protection mechanism, and if the checksum is transmitted instead of being recomputed as part of the decompression, these situations may result in the packet being considered corrupt and dropped.
さらに、パケットがチェックサムまたは同様の整合性保護メカニズムによって保護されており、チェックサムが解凍の一部として再計算されるのではなく送信される場合、これらの状況により、パケットは破損していると見なされ、ドロップされる可能性があります。
Let's assume that an attacker is able to send a forged SCHC Fragment to a SCHC reassembler.
攻撃者が偽造されたSCHCフラグメントをSCHCリアセンブラに送信できると仮定します。
A node can perform a buffer reservation attack: the receiver will reserve buffer space for the SCHC Packet. If the implementation has only one buffer, other incoming fragmented SCHC Packets will be dropped while the reassembly buffer is occupied during the reassembly timeout. Once that timeout expires, the attacker can repeat the same procedure, and iterate, thus, creating a denial-of-service attack. An implementation may have multiple reassembly buffers. The cost to mount this attack is linear with the number of buffers at the target node. Better, the cost for an attacker can be increased if individual fragments of multiple SCHC Packets can be stored in the reassembly buffer. The finer grained the reassembly buffer (down to the smallest tile size), the higher the cost of the attack. If buffer overload does occur, a smart receiver could selectively discard SCHC Packets being reassembled based on the sender behavior, which may help identify which SCHC Fragments have been sent by the attacker. Another mild countermeasure is for the target to abort the fragmentation/reassembly session as early as it detects a non-identical SCHC Fragment duplicate, anticipating for an eventual corrupt SCHC Packet, so as to save the sender the hassle of sending the rest of the fragments for this SCHC Packet.
ノードはバッファ予約攻撃を実行できます。受信者はSCHCパケット用にバッファスペースを予約します。実装にバッファが1つしかない場合、再構成タイムアウト中に再構成バッファが占有されている間、他のフラグメント化された着信SCHCパケットはドロップされます。タイムアウトの期限が切れると、攻撃者は同じ手順を繰り返して繰り返すことができるため、サービス拒否攻撃が作成されます。実装には、複数の再構成バッファーがある場合があります。この攻撃を開始するためのコストは、ターゲットノードのバッファ数に比例します。複数のSCHCパケットの個々のフラグメントを再構成バッファーに格納できる場合、攻撃者のコストが増加する可能性があります。再構成バッファーの粒度を細かくすると（最小のタイルサイズまで）、攻撃のコストが高くなります。バッファーオーバーロードが発生した場合、スマートレシーバーは送信者の動作に基づいて再構成されているSCHCパケットを選択的に破棄する可能性があり、攻撃者が送信したSCHCフラグメントを特定するのに役立ちます。もう1つの穏やかな対策は、同一でないSCHCフラグメントの重複を検出し、最終的に破損したSCHCパケットを予測して、断片化/再組み立てセッションをターゲットが中止することです。これにより、送信者は残りのフラグメントを送信する手間を省くことができます。このSCHCパケット用。
Let's assume that an attacker is able to send a forged SCHC Fragment to a SCHC reassembler. The malicious node is additionally assumed to be able to hear an incoming communication destined to the target node.
攻撃者が偽造されたSCHCフラグメントをSCHCリアセンブラに送信できると仮定します。さらに、悪意のあるノードは、ターゲットノード宛ての着信通信を聞くことができると想定されます。
It can then send a forged SCHC Fragment that looks like it belongs to a SCHC Packet already being reassembled at the target node. This can cause the SCHC Packet to be considered corrupt and to be dropped by the receiver. The amplification happens here by a single spoofed SCHC Fragment rendering a full sequence of legitimate SCHC Fragments useless. If the target uses ACK-Always or ACK-on-Error mode, such a malicious node can also interfere with the acknowledgement and repetition algorithm of SCHC F/R. A single spoofed ACK, with all Bitmap bits set to 0, will trigger the repetition of WINDOW_SIZE tiles. This protocol loop amplification depletes the energy source of the target node and consumes the channel bandwidth. Similarly, a spoofed ACK REQ will trigger the sending of a SCHC ACK, which may be much larger than the ACK REQ if WINDOW_SIZE is large. These consequences should be borne in mind when defining profiles for SCHC over specific LPWAN technologies.
次に、ターゲットノードですでに再構成されているSCHCパケットに属しているように見える偽造SCHCフラグメントを送信できます。これにより、SCHCパケットが破損していると見なされ、レシーバーによってドロップされる可能性があります。ここでは、単一の偽装されたSCHCフラグメントによって増幅が発生し、正当なSCHCフラグメントの完全なシーケンスが役に立たなくなります。ターゲットがACK-AlwaysモードまたはACK-on-Errorモードを使用している場合、このような悪意のあるノードは、SCHC F / Rの確認および反復アルゴリズムにも干渉する可能性があります。すべてのビットマップビットが0に設定された単一のスプーフィングされたACKは、WINDOW_SIZEタイルの繰り返しをトリガーします。このプロトコルループ増幅は、ターゲットノードのエネルギー源を使い果たし、チャネル帯域幅を消費します。同様に、スプーフィングされたACK REQはSCHC ACKの送信をトリガーします。これは、WINDOW_SIZEが大きい場合、ACK REQよりはるかに大きくなる可能性があります。特定のLPWANテクノロジーを介してSCHCのプロファイルを定義するときは、これらの結果に留意する必要があります。
Fragmentation is known for potentially allowing one to force through a Network Inspection device (e.g., firewall) packets that would be rejected if unfragmented. This involves sending overlapping fragments to rewrite fields whose initial value led the Network Inspection device to allow the flow to go through.
断片化は、断片化されていない場合に拒否されるネットワーク検査デバイス（ファイアウォールなど）パケットを強制的に通過させる可能性があることで知られています。これには、オーバーラップするフラグメントを送信してフィールドを書き換え、その初期値によってネットワーク検査デバイスがフローを通過できるようにする必要があります。
SCHC F/R is expected to be used over one LPWAN link, where no Network Inspection device is expected to sit. As described in Section 5.2, even if the SCHC F/R on the Network Infrastructure side is located in the Internet, a tunnel is to be established between it and the NGW.
SCHC F / Rは、ネットワーク検査デバイスが設置されていないことが予想される1つのLPWANリンク上で使用されることが想定されています。セクション5.2で説明したように、ネットワークインフラストラクチャ側のSCHC F / Rがインターネットに配置されている場合でも、それとNGWの間にトンネルが確立されます。
SCHC F/R allocates a DTag value to fragments belonging to the same SCHC Packet. Concerns were raised that, if DTag is a wide counter that is incremented in a predictable fashion for each new fragmented SCHC Packet, it might lead to a privacy issue, such as enabling tracking of a device across LPWANs.
SCHC F / Rは、DTag値を同じSCHCパケットに属するフラグメントに割り当てます。 DTagが新しい断片化されたSCHCパケットごとに予測可能な方法で増分されるワイドカウンターである場合、LPWAN全体でデバイスの追跡を有効にするなど、プライバシーの問題につながる可能性があるという懸念が提起されました。
However, SCHC F/R is expected to be used over exactly one LPWAN link. As described in Section 5.2, even if the SCHC F/R on the Network Infrastructure side is located in the Internet, a tunnel is to be established between it and the NGW. Therefore, assuming the tunnel provides confidentiality, neither the DTag field nor any other SCHC-introduced field is visible over the Internet.
ただし、SCHC F / Rは、厳密に1つのLPWANリンクで使用されることが想定されています。セクション5.2で説明したように、ネットワークインフラストラクチャ側のSCHC F / Rがインターネット内にある場合でも、それとNGWの間にトンネルが確立されます。したがって、トンネルが機密性を提供すると仮定すると、DTagフィールドも他のSCHCで導入されたフィールドもインターネット上では見えません。
[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>。
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, <https://www.rfc-editor.org/info/rfc6936>.
[RFC6936] Fairhurst、G。およびM. Westerlund、「ゼロチェックサムを使用したIPv6 UDPデータグラムの使用に関する適用性声明」、RFC 6936、DOI 10.17487 / RFC6936、2013年4月、<https://www.rfc-editor.org / info / rfc6936>。
[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>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https://www.rfc-editor.org / info / rfc8200>。
[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>.
[RFC8376] Farrell、S。、編、「低電力ワイドエリアネットワーク（LPWAN）の概要」、RFC 8376、DOI 10.17487 / RFC8376、2018年5月、<https://www.rfc-editor.org/info/ rfc8376>。
[ETHERNET] IEEE, "IEEE Standard for Ethernet", DOI 10.1109/IEEESTD.2012.6419735, IEEE Standard 802.3-2012, December 2012, <https://ieeexplore.ieee.org/document/6419735>.
[ETHERNET] IEEE、「イーサネットのIEEE標準」、DOI 10.1109 / IEEESTD.2012.6419735、IEEE標準802.3-2012、2012年12月、<https://ieeexplore.ieee.org/document/6419735>。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <https://www.rfc-editor.org/info/rfc4944>.
[RFC4944]モンテネグロ、G。、クシャルナガル、N。、ホイ、J。、およびD.キュラー、「IEEE 802.15.4ネットワークを介したIPv6パケットの送信」、RFC 4944、DOI 10.17487 / RFC4944、2007年9月、<https： //www.rfc-editor.org/info/rfc4944>。
[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>.
[RFC5795] Sandlund、K.、Pelletier、G。、およびL-E。 Jonsson、「The RObust Header Compression（ROHC）Framework」、RFC 5795、DOI 10.17487 / RFC5795、2010年3月、<https://www.rfc-editor.org/info/rfc5795>。
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <https://www.rfc-editor.org/info/rfc6282>.
[RFC6282]ホイ、J、エド。およびP. Thubert、「IEEE 802.15.4ベースのネットワーク上のIPv6データグラムの圧縮形式」、RFC 6282、DOI 10.17487 / RFC6282、2011年9月、<https://www.rfc-editor.org/info/rfc6282>。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <https://www.rfc-editor.org/info/rfc6437>.
[RFC6437] Amante、S.、Carpenter、B.、Jiang、S。、およびJ. Rajahalme、「IPv6 Flow Label Specification」、RFC 6437、DOI 10.17487 / RFC6437、2011年11月、<https：//www.rfc- editor.org/info/rfc6437>。
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, <https://www.rfc-editor.org/info/rfc7136>.
[RFC7136] Carpenter、B。およびS. Jiang、「Significance of IPv6 Interface Identifiers」、RFC 7136、DOI 10.17487 / RFC7136、2014年2月、<https://www.rfc-editor.org/info/rfc7136>。
[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, February 2017, <https://www.rfc-editor.org/info/rfc8065>.
[RFC8065]ターラー、D。、「IPv6アダプテーションレイヤーメカニズムのプライバシーに関する考慮事項」、RFC 8065、DOI 10.17487 / RFC8065、2017年2月、<https://www.rfc-editor.org/info/rfc8065>。
This section gives some scenarios of the compression mechanism for IPv6/UDP. The goal is to illustrate the behavior of SCHC.
このセクションでは、IPv6 / UDPの圧縮メカニズムのいくつかのシナリオを示します。目標は、SCHCの動作を説明することです。
The mechanisms defined in this document can be applied to a Dev that embeds some applications running over CoAP. In this example, three flows are considered. The first flow is for the device management based on CoAP using Link Local IPv6 addresses and UDP ports 123 and 124 for Dev and App, respectively. The second flow is a CoAP server for measurements done by the Dev (using ports 5683) and Global IPv6 Address prefixes alpha::IID/64 to beta::1/64. The last flow is for legacy applications using different ports numbers, the destination IPv6 address prefix is gamma::1/64.
このドキュメントで定義されているメカニズムは、CoAPで実行されている一部のアプリケーションを埋め込むDevに適用できます。この例では、3つのフローが考慮されます。最初のフローは、リンクローカルIPv6アドレスと、それぞれDevおよびAppのUDPポート123および124を使用するCoAPに基づくデバイス管理用です。 2番目のフローは、Dev（ポート5683を使用）およびグローバルIPv6アドレスプレフィックスalpha :: IID / 64からbeta :: 1/64によって行われた測定のためのCoAPサーバーです。最後のフローは、異なるポート番号を使用するレガシーアプリケーション用で、宛先IPv6アドレスプレフィックスはgamma :: 1/64です。
Figure 25 presents the protocol stack. IPv6 and UDP are represented with dotted lines since these protocols are compressed on the radio link.
図25にプロトコルスタックを示します。これらのプロトコルは無線リンクで圧縮されているため、IPv6とUDPは点線で表されています。
Management Data
+----------+---------+---------+
| CoAP | CoAP | legacy |
+----||----+---||----+---||----+
. UDP . UDP | UDP |
................................
. IPv6 . IPv6 . IPv6 .
+------------------------------+
| SCHC Header compression |
| and fragmentation |
+------------------------------+
| LPWAN L2 technologies |
+------------------------------+
Dev or NGW
Figure 25: Simplified Protocol Stack for LP-WAN
図25：LP-WANの簡略化されたプロトコルスタック
Rule 0 Special RuleID used to tag an uncompressed UDP/IPV6 packet.
ルール0非圧縮UDP / IPV6パケットのタグ付けに使用される特別なRuleID。
Rule 1
+----------------+--+--+--+---------+--------+------------++------+
| FID |FL|FP|DI| TV | MO | CDA || Sent |
| | | | | | | ||[bits]|
+----------------+--+--+--+---------+---------------------++------+
|IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || |
|IPv6 Diffserv |8 |1 |Bi|0 | equal | not-sent || |
|IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || |
|IPv6 Length |16|1 |Bi| | ignore | compute-* || |
|IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || |
|IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || |
|IPv6 DevPrefix |64|1 |Bi|FE80::/64| equal | not-sent || |
|IPv6 DevIID |64|1 |Bi| | ignore | DevIID || |
|IPv6 AppPrefix |64|1 |Bi|FE80::/64| equal | not-sent || |
|IPv6 AppIID |64|1 |Bi|::1 | equal | not-sent || |
+================+==+==+==+=========+========+============++======+
|UDP DevPort |16|1 |Bi|123 | equal | not-sent || |
|UDP AppPort |16|1 |Bi|124 | equal | not-sent || |
|UDP Length |16|1 |Bi| | ignore | compute-* || |
|UDP checksum |16|1 |Bi| | ignore | compute-* || |
+================+==+==+==+=========+========+============++======+
Figure 26: Context Rules - Rule 0 and Rule 1
図26：コンテキストルール-ルール0およびルール1
Rule 2
+----------------+--+--+--+---------+--------+------------++------+
| FID |FL|FP|DI| TV | MO | CDA || Sent |
| | | | | | | ||[bits]|
+----------------+--+--+--+---------+--------+------------++------+
|IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || |
|IPv6 Diffserv |8 |1 |Bi|0 | equal | not-sent || |
|IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || |
|IPv6 Length |16|1 |Bi| | ignore | compute-* || |
|IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || |
|IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || |
|IPv6 DevPrefix |64|1 |Bi|[alpha/64, match- |mapping-sent|| 1 |
| | | | |fe80::/64] mapping| || |
|IPv6 DevIID |64|1 |Bi| | ignore | DevIID || |
|IPv6 AppPrefix |64|1 |Bi|[beta/64,| match- |mapping-sent|| 2 |
| | | | |alpha/64,| mapping| || |
| | | | |fe80::64]| | || |
|IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || |
+================+==+==+==+=========+========+============++======+
|UDP DevPort |16|1 |Bi|5683 | equal | not-sent || |
|UDP AppPort |16|1 |Bi|5683 | equal | not-sent || |
|UDP Length |16|1 |Bi| | ignore | compute-* || |
|UDP checksum |16|1 |Bi| | ignore | compute-* || |
+================+==+==+==+=========+========+============++======+
Figure 27: Context Rules - Rule 2
図27：コンテキストルール-ルール2
Rule 3
+----------------+--+--+--+---------+--------+------------++------+
| FID |FL|FP|DI| TV | MO | CDA || Sent |
| | | | | | | ||[bits]|
+----------------+--+--+--+---------+--------+------------++------+
|IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || |
|IPv6 Diffserv |8 |1 |Bi|0 | equal | not-sent || |
|IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || |
|IPv6 Length |16|1 |Bi| | ignore | compute-* || |
|IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || |
|IPv6 Hop Limit |8 |1 |Up|255 | ignore | not-sent || |
|IPv6 Hop Limit |8 |1 |Dw| | ignore | value-sent || 8 |
|IPv6 DevPrefix |64|1 |Bi|alpha/64 | equal | not-sent || |
|IPv6 DevIID |64|1 |Bi| | ignore | DevIID || |
|IPv6 AppPrefix |64|1 |Bi|gamma/64 | equal | not-sent || |
|IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || |
+================+==+==+==+=========+========+============++======+
|UDP DevPort |16|1 |Bi|8720 | MSB(12)| LSB || 4 |
|UDP AppPort |16|1 |Bi|8720 | MSB(12)| LSB || 4 |
|UDP Length |16|1 |Bi| | ignore | compute-* || |
|UDP checksum |16|1 |Bi| | ignore | compute-* || |
+================+==+==+==+=========+========+============++======+
Figure 28: Context Rules - Rule 3
図28：コンテキストルール-ルール3
Figures 26 to 28 describe an example of a Rule set.
図26〜28に、ルールセットの例を示します。
In this example, 0 was chosen as the special RuleID that tags packets that cannot be compressed with any compression Rule.
この例では、圧縮ルールで圧縮できないパケットにタグを付ける特別なRuleIDとして0が選択されています。
All the fields described in Rules 1-3 are present in the IPv6 and UDP headers. The DevIID value is inferred from the L2 header.
ルール1〜3で説明されているすべてのフィールドは、IPv6およびUDPヘッダーにあります。 DevIID値はL2ヘッダーから推測されます。
Rules 2-3 use global addresses. The way the Dev learns the prefix is not in the scope of the document.
ルール2〜3はグローバルアドレスを使用します。開発者がプレフィックスを学習する方法は、ドキュメントの範囲外です。
Rule 3 compresses each port number to 4 bits.
ルール3は、各ポート番号を4ビットに圧縮します。
This section provides examples for the various fragment reliability modes specified in this document. In the drawings, Bitmaps are shown in their uncompressed form.
このセクションでは、このドキュメントで指定されているさまざまなフラグメント信頼性モードの例を示します。図面では、ビットマップは非圧縮形式で示されています。
Figure 29 illustrates the transmission in No-ACK mode of a SCHC Packet that needs 11 SCHC Fragments. FCN is 1 bit wide.
図29は、11個のSCHCフラグメントを必要とするSCHCパケットの非ACKモードでの送信を示しています。 FCNは1ビット幅です。
Sender Receiver
|-------FCN=0-------->|
|-------FCN=0-------->|
|-------FCN=0-------->|
|-------FCN=0-------->|
|-------FCN=0-------->|
|-------FCN=0-------->|
|-------FCN=0-------->|
|-------FCN=0-------->|
|-------FCN=0-------->|
|-------FCN=0-------->|
|-----FCN=1 + RCS --->| Integrity check: success
(End)
Figure 29: No-ACK Mode, 11 SCHC Fragments
図29：非ACKモード、11 SCHCフラグメント
In the following examples, N (the size of the FCN field) is 3 bits. The All-1 FCN value is therefore 7.
次の例では、N（FCNフィールドのサイズ）は3ビットです。したがって、All-1 FCN値は7です。
Figure 30 illustrates the transmission in ACK-on-Error mode of a SCHC Packet fragmented in 11 tiles, with one tile per SCHC Fragment, WINDOW_SIZE=7 and no lost SCHC Fragment.
図30は、11タイルに断片化されたSCHCパケットのACK-on-Errorモードでの送信を示しています。SCHCフラグメントごとに1つのタイル、WINDOW_SIZE = 7があり、失われたSCHCフラグメントはありません。
Sender Receiver
|-----W=0, FCN=6----->|
|-----W=0, FCN=5----->|
|-----W=0, FCN=4----->|
|-----W=0, FCN=3----->|
|-----W=0, FCN=2----->|
|-----W=0, FCN=1----->|
|-----W=0, FCN=0----->|
(no ACK)
|-----W=1, FCN=6----->|
|-----W=1, FCN=5----->|
|-----W=1, FCN=4----->|
|--W=1, FCN=7 + RCS-->| Integrity check: success
|<-- ACK, W=1, C=1 ---| C=1
(End)
Figure 30: ACK-on-Error Mode, 11 Tiles, One Tile per SCHC Fragment, No Lost SCHC Fragment
図30：ACK-on-Errorモード、11タイル、SCHCフラグメントごとに1タイル、失われたSCHCフラグメントなし
Figure 31 illustrates the transmission in ACK-on-Error mode of a SCHC Packet fragmented in 11 tiles, with one tile per SCHC Fragment, WINDOW_SIZE=7, and three lost SCHC Fragments.
図31は、11タイルに断片化されたSCHCパケットのACK-on-Errorモードでの送信を示しています。SCHCフラグメントごとに1つのタイル、WINDOW_SIZE = 7、および3つの失われたSCHCフラグメントがあります。
Sender Receiver
|-----W=0, FCN=6----->|
|-----W=0, FCN=5----->|
|-----W=0, FCN=4--X-->|
|-----W=0, FCN=3----->|
|-----W=0, FCN=2--X-->|
|-----W=0, FCN=1----->|
|-----W=0, FCN=0----->| 6543210
|<-- ACK, W=0, C=0 ---| Bitmap:1101011
|-----W=0, FCN=4----->|
|-----W=0, FCN=2----->|
(no ACK)
|-----W=1, FCN=6----->|
|-----W=1, FCN=5----->|
|-----W=1, FCN=4--X-->|
|- W=1, FCN=7 + RCS ->| Integrity check: failure
|<-- ACK, W=1, C=0 ---| C=0, Bitmap:1100001
|-----W=1, FCN=4----->| Integrity check: success
|<-- ACK, W=1, C=1 ---| C=1
(End)
Figure 31: ACK-on-Error Mode, 11 Tiles, One Tile per SCHC Fragment, Lost SCHC Fragments
図31：ACK-on-Errorモード、11タイル、SCHCフラグメントごとに1タイル、失われたSCHCフラグメント
Figure 32 shows an example of a transmission in ACK-on-Error mode of a SCHC Packet fragmented in 73 tiles, with N=5, WINDOW_SIZE=28, M=2, and three lost SCHC Fragments.
図32は、73タイルにフラグメント化されたSCHCパケットのACK-on-Errorモードでの送信の例を示しています。N= 5、WINDOW_SIZE = 28、M = 2、3つのSCHCフラグメントが失われています。
Sender Receiver
|-----W=0, FCN=27----->| 4 tiles sent
|-----W=0, FCN=23----->| 4 tiles sent
|-----W=0, FCN=19----->| 4 tiles sent
|-----W=0, FCN=15--X-->| 4 tiles sent (not received)
|-----W=0, FCN=11----->| 4 tiles sent
|-----W=0, FCN=7 ----->| 4 tiles sent
|-----W=0, FCN=3 ----->| 4 tiles sent
|-----W=1, FCN=27----->| 4 tiles sent
|-----W=1, FCN=23----->| 4 tiles sent
|-----W=1, FCN=19----->| 4 tiles sent
|-----W=1, FCN=15----->| 4 tiles sent
|-----W=1, FCN=11----->| 4 tiles sent
|-----W=1, FCN=7 ----->| 4 tiles sent
|-----W=1, FCN=3 --X-->| 4 tiles sent (not received)
|-----W=2, FCN=27----->| 4 tiles sent
|-----W=2, FCN=23----->| 4 tiles sent
^ |-----W=2, FCN=19----->| 1 tile sent
| |-----W=2, FCN=18----->| 1 tile sent
| |-----W=2, FCN=17----->| 1 tile sent
|-----W=2, FCN=16----->| 1 tile sent
s |-----W=2, FCN=15----->| 1 tile sent
m |-----W=2, FCN=14----->| 1 tile sent
a |-----W=2, FCN=13--X-->| 1 tile sent (not received)
l |-----W=2, FCN=12----->| 1 tile sent
l |---W=2, FCN=31 + RCS->| Integrity check: failure
e |<--- ACK, W=0, C=0 ---| C=0, Bitmap:1111111111110000111111111111
r |-----W=0, FCN=15----->| 1 tile sent
|-----W=0, FCN=14----->| 1 tile sent
L |-----W=0, FCN=13----->| 1 tile sent
2 |-----W=0, FCN=12----->| 1 tile sent
|<--- ACK, W=1, C=0 ---| C=0, Bitmap:1111111111111111111111110000
M |-----W=1, FCN=3 ----->| 1 tile sent
T |-----W=1, FCN=2 ----->| 1 tile sent
U |-----W=1, FCN=1 ----->| 1 tile sent
|-----W=1, FCN=0 ----->| 1 tile sent
| |<--- ACK, W=2, C=0 ---| C=0, Bitmap:1111111111111101000000000001
| |-----W=2, FCN=13----->| Integrity check: success
V |<--- ACK, W=2, C=1 ---| C=1
(End)
Figure 32: ACK-on-Error Mode, Variable MTU
図32：エラー時ACKモード、可変MTU
In this example, the L2 MTU becomes reduced just before sending the "W=2, FCN=19" fragment, leaving space for only one tile in each forthcoming SCHC Fragment. Before retransmissions, the 73 tiles are carried by a total of 25 SCHC Fragments, the last nine being of smaller size.
この例では、L2 MTUは、「W = 2、FCN = 19」フラグメントを送信する直前に減少し、次の各SCHCフラグメントに1つのタイルのみのスペースを残します。再送信する前に、73のタイルは合計25のSCHCフラグメントによって運ばれ、最後の9タイルはより小さいサイズです。
Note: other sequences of events (e.g., regarding when ACKs are sent by the Receiver) are also allowed by this specification. Profiles may restrict this flexibility.
注：この仕様では、他の一連のイベント（ACKがレシーバーによっていつ送信されるかなど）も許可されています。プロファイルはこの柔軟性を制限する場合があります。
Figure 33 illustrates the transmission in ACK-Always mode of a SCHC Packet fragmented in 11 tiles, with one tile per SCHC Fragment, with N=3, WINDOW_SIZE=7, and no loss.
図33は、11タイルに断片化されたSCHCパケットのACK-Alwaysモードでの送信を示しています。SCHCフラグメントごとに1つのタイルがあり、N = 3、WINDOW_SIZE = 7で、損失はありません。
Sender Receiver
|-----W=0, FCN=6----->|
|-----W=0, FCN=5----->|
|-----W=0, FCN=4----->|
|-----W=0, FCN=3----->|
|-----W=0, FCN=2----->|
|-----W=0, FCN=1----->|
|-----W=0, FCN=0----->|
|<-- ACK, W=0, C=0 ---| Bitmap:1111111
|-----W=1, FCN=6----->|
|-----W=1, FCN=5----->|
|-----W=1, FCN=4----->|
|--W=1, FCN=7 + RCS-->| Integrity check: success
|<-- ACK, W=1, C=1 ---| C=1
(End)
Figure 33: ACK-Always Mode, 11 Tiles, One Tile per SCHC Fragment, No Loss
図33：ACK常時モード、11タイル、SCHCフラグメントごとに1タイル、損失なし
Figure 34 illustrates the transmission in ACK-Always mode of a SCHC Packet fragmented in 11 tiles, with one tile per SCHC Fragment, N=3, WINDOW_SIZE=7 and three lost SCHC Fragments.
図34は、11タイルに断片化されたSCHCパケットのACK-Alwaysモードでの送信を示しています。SCHCフラグメントごとに1つのタイル、N = 3、WINDOW_SIZE = 7、3つの失われたSCHCフラグメントがあります。
Sender Receiver
|-----W=0, FCN=6----->|
|-----W=0, FCN=5----->|
|-----W=0, FCN=4--X-->|
|-----W=0, FCN=3----->|
|-----W=0, FCN=2--X-->|
|-----W=0, FCN=1----->|
|-----W=0, FCN=0----->| 6543210
|<-- ACK, W=0, C=0 ---| Bitmap:1101011
|-----W=0, FCN=4----->|
|-----W=0, FCN=2----->|
|<-- ACK, W=0, C=0 ---| Bitmap:1111111
|-----W=1, FCN=6----->|
|-----W=1, FCN=5----->|
|-----W=1, FCN=4--X-->|
|--W=1, FCN=7 + RCS-->| Integrity check: failure
|<-- ACK, W=1, C=0 ---| C=0, Bitmap:11000001
|-----W=1, FCN=4----->| Integrity check: success
|<-- ACK, W=1, C=1 ---| C=1
(End)
Figure 34: ACK-Always Mode, 11 Tiles, One Tile per SCHC Fragment, Three Lost SCHC Fragments
図34：ACK常時モード、11タイル、SCHCフラグメントごとに1タイル、3つの失われたSCHCフラグメント
Figure 35 illustrates the transmission in ACK-Always mode of a SCHC Packet fragmented in six tiles, with one tile per SCHC Fragment, N=3, WINDOW_SIZE=7, three lost SCHC Fragments, and only one retry needed to recover each lost SCHC Fragment.
図35は、6つのタイルに断片化されたSCHCパケットのACK-Alwaysモードでの送信を示しています。SCHCフラグメントごとに1つのタイル、N = 3、WINDOW_SIZE = 7、3つの失われたSCHCフラグメント、および失われた各SCHCフラグメントを回復するために必要な再試行は1つだけです。 。
Sender Receiver
|-----W=0, FCN=6----->|
|-----W=0, FCN=5----->|
|-----W=0, FCN=4--X-->|
|-----W=0, FCN=3--X-->|
|-----W=0, FCN=2--X-->|
|--W=0, FCN=7 + RCS-->| Integrity check: failure
|<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001
|-----W=0, FCN=4----->| Integrity check: failure
|-----W=0, FCN=3----->| Integrity check: failure
|-----W=0, FCN=2----->| Integrity check: success
|<-- ACK, W=0, C=1 ---| C=1
(End)
Figure 35: ACK-Always Mode, Six Tiles, One Tile per SCHC Fragment, Three Lost SCHC Fragments
図35：ACK常時モード、6タイル、SCHCフラグメントごとに1タイル、3つの失われたSCHCフラグメント
Figure 36 illustrates the transmission in ACK-Always mode of a SCHC Packet fragmented in six tiles, with one tile per SCHC Fragment, N=3, WINDOW_SIZE=7, three lost SCHC Fragments, and the second SCHC ACK lost.
図36は、6つのタイルに断片化されたSCHCパケットのACK-Alwaysモードでの送信を示しています。SCHCフラグメントごとに1つのタイル、N = 3、WINDOW_SIZE = 7、3つの失われたSCHCフラグメント、および2番目のSCHC ACKが失われます。
Sender Receiver
|-----W=0, FCN=6----->|
|-----W=0, FCN=5----->|
|-----W=0, FCN=4--X-->|
|-----W=0, FCN=3--X-->|
|-----W=0, FCN=2--X-->|
|--W=0, FCN=7 + RCS-->| Integrity check: failure
|<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001
|-----W=0, FCN=4----->| Integrity check: failure
|-----W=0, FCN=3----->| Integrity check: failure
|-----W=0, FCN=2----->| Integrity check: success
|<-X-ACK, W=0, C=1 ---| C=1
timeout | |
|--- W=0, ACK REQ --->| ACK REQ
|<-- ACK, W=0, C=1 ---| C=1
(End)
Figure 36: ACK-Always Mode, Six Tiles, One Tile per SCHC Fragment, SCHC ACK Loss
図36：ACK常時モード、6タイル、SCHCフラグメントごとに1タイル、SCHC ACK損失
Figure 37 illustrates the transmission in ACK-Always mode of a SCHC Packet fragmented in six tiles, with N=3, WINDOW_SIZE=7, with three lost SCHC Fragments, and one retransmitted SCHC Fragment lost again.
図37は、3つのSCHCフラグメントが失われ、1つの再送信されたSCHCフラグメントが再び失われた、N = 3、WINDOW_SIZE = 7の6つのタイルにフラグメント化されたSCHCパケットのACK-Alwaysモードでの送信を示しています。
Sender Receiver
|-----W=0, FCN=6----->|
|-----W=0, FCN=5----->|
|-----W=0, FCN=4--X-->|
|-----W=0, FCN=3--X-->|
|-----W=0, FCN=2--X-->|
|--W=0, FCN=7 + RCS-->| Integrity check: failure
|<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001
|-----W=0, FCN=4----->| Integrity check: failure
|-----W=0, FCN=3----->| Integrity check: failure
|-----W=0, FCN=2--X-->|
timeout| |
|--- W=0, ACK REQ --->| ACK REQ
|<-- ACK, W=0, C=0 ---| C=0, Bitmap: 1111101
|-----W=0, FCN=2----->| Integrity check: success
|<-- ACK, W=0, C=1 ---| C=1
(End)
Figure 37: ACK-Always Mode, Six Tiles, Retransmitted SCHC Fragment Lost Again
図37：ACK常時モード、6タイル、再送されたSCHCフラグメントが再び失われる
Figure 38 illustrates the transmission in ACK-Always mode of a SCHC Packet fragmented in 28 tiles, with one tile per SCHC Fragment, N=5, WINDOW_SIZE=24, and two lost SCHC Fragments.
図38は、28タイルに断片化されたSCHCパケットのACK-Alwaysモードでの送信を示しています。SCHCフラグメントごとに1つのタイル、N = 5、WINDOW_SIZE = 24、および2つの失われたSCHCフラグメントがあります。
Sender Receiver
|-----W=0, FCN=23----->|
|-----W=0, FCN=22----->|
|-----W=0, FCN=21--X-->|
|-----W=0, FCN=20----->|
|-----W=0, FCN=19----->|
|-----W=0, FCN=18----->|
|-----W=0, FCN=17----->|
|-----W=0, FCN=16----->|
|-----W=0, FCN=15----->|
|-----W=0, FCN=14----->|
|-----W=0, FCN=13----->|
|-----W=0, FCN=12----->|
|-----W=0, FCN=11----->|
|-----W=0, FCN=10--X-->|
|-----W=0, FCN=9 ----->|
|-----W=0, FCN=8 ----->|
|-----W=0, FCN=7 ----->|
|-----W=0, FCN=6 ----->|
|-----W=0, FCN=5 ----->|
|-----W=0, FCN=4 ----->|
|-----W=0, FCN=3 ----->|
|-----W=0, FCN=2 ----->|
|-----W=0, FCN=1 ----->|
|-----W=0, FCN=0 ----->|
| |
|<--- ACK, W=0, C=0 ---| Bitmap:110111111111101111111111
|-----W=0, FCN=21----->|
|-----W=0, FCN=10----->|
|<--- ACK, W=0, C=0 ---| Bitmap:111111111111111111111111
|-----W=1, FCN=23----->|
|-----W=1, FCN=22----->|
|-----W=1, FCN=21----->|
|--W=1, FCN=31 + RCS-->| Integrity check: success
|<--- ACK, W=1, C=1 ---| C=1
(End)
Figure 38: ACK-Always Mode, 28 Tiles, One Tile per SCHC Fragment, Lost SCHC Fragments
図38：ACK常時モード、28タイル、SCHCフラグメントごとに1タイル、失われたSCHCフラグメント
The fragmentation state machines of the sender and the receiver, one for each of the different reliability modes, are described in the following figures:
次の図では、さまざまな信頼性モードごとに1つずつ、送信側と受信側のフラグメンテーションステートマシンについて説明しています。
+===========+
+------------+ Init |
| FCN=0 +===========+
| No Window
| No Bitmap
| +-------+
| +========+==+ | More Fragments
| | | <--+ ~~~~~~~~~~~~~~~~~~~~
+--------> | Send | send Fragment (FCN=0)
+===+=======+
| last fragment
| ~~~~~~~~~~~~
| FCN = 1
v send fragment+RCS
+============+
| END |
+============+
Figure 39: Sender State Machine for the No-ACK Mode
図39：No-ACKモードの送信側ステートマシン
+------+ Not All-1
+==========+=+ | ~~~~~~~~~~~~~~~~~~~
| + <--+ set Inactivity Timer
| RCV Frag +-------+
+=+===+======+ |All-1 &
All-1 & | | |RCS correct
RCS wrong | |Inactivity |
| |Timer Exp. |
v | |
+==========++ | v
| Error |<-+ +========+==+
+===========+ | END |
+===========+
Figure 40: Receiver State Machine for the No-ACK Mode
図40：No-ACKモードのレシーバーステートマシン
+=======+
| INIT | FCN!=0 & more frags
| | ~~~~~~~~~~~~~~~~~~~~~~
+======++ +--+ send Window + frag(FCN)
W=0 | | | FCN-
Clear lcl_bm | | v set lcl_bm
FCN=max value | ++==+========+
+> | |
+---------------------> | SEND |
| +==+===+=====+
| FCN==0 & more frags | | last frag
| ~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~
| set lcl_bm | | set lcl_bm
| send wnd + frag(all-0) | | send wnd+frag(all-1)+RCS
| set Retrans_Timer | | set Retrans_Timer
| | |
|Recv_wnd == wnd & | |
|lcl_bm==recv_bm & | | +----------------------+
|more frag | | | lcl_bm!=rcv-bm |
|~~~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~ |
|Stop Retrans_Timer | | | Attempt++ v
|clear lcl_bm v v | +=====+=+
|window=next_window +====+===+==+===+ |Resend |
+---------------------+ | |Missing|
+----+ Wait | |Frag |
not expected wnd | | Bitmap | +=======+
~~~~~~~~~~~~~~~~ +--->+ ++Retrans_Timer Exp |
discard frag +==+=+===+=+==+=+| ~~~~~~~~~~~~~~~~~ |
| | | ^ ^ |reSend(empty)All-* |
| | | | | |Set Retrans_Timer |
| | | | +--+Attempt++ |
C_bit==1 & | | | +-------------------------+
Recv_window==window & | | | all missing frags sent
no more frag| | | ~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~| | | Set Retrans_Timer
Stop Retrans_Timer| | |
+=============+ | | |
| END +<--------+ | |
+=============+ | | Attempt > MAX_ACK_REQUESTS
All-1 Window & | | ~~~~~~~~~~~~~~~~~~
C_bit ==0 & | v Send Abort
lcl_bm==recv_bm | +=+===========+
~~~~~~~~~~~~ +>| ERROR |
Send Abort +=============+
Figure 41: Sender State Machine for the ACK-Always Mode
図41：ACK-Alwaysモードの送信側ステートマシン
Not All- & w=expected +---+ +---+w = Not expected
~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~
Set lcl_bm(FCN) | v v |discard
++===+===+===+=+
+---------------------+ Rcv +--->* ABORT
| +------------------+ Window |
| | +=====+==+=====+
| | All-0 & w=expect | ^ w =next & not-All
| | ~~~~~~~~~~~~~~~~~~ | |~~~~~~~~~~~~~~~~~~~~~
| | set lcl_bm(FCN) | |expected = next window
| | send lcl_bm | |Clear lcl_bm
| | | |
| | w=expected & not-All | |
| | ~~~~~~~~~~~~~~~~~~ | |
| | set lcl_bm(FCN)+-+ | | +--+ w=next & All-0
| | if lcl_bm full | | | | | | ~~~~~~~~~~~~~~~
| | send lcl_bm | | | | | | expected = nxt wnd
| | v | v | | | Clear lcl_bm
| |w=expected& All-1 +=+=+=+==+=++ | set lcl_bm(FCN)
| | ~~~~~~~~~~~ +->+ Wait +<+ send lcl_bm
| | discard +--| Next |
| | All-0 +---------+ Window +--->* ABORT
| | ~~~~~ +-------->+========+=++
| | snd lcl_bm All-1 & w=next| | All-1 & w=nxt
| | & RCS wrong| | & RCS right
| | ~~~~~~~~~~~~~~~~~| | ~~~~~~~~~~~~~~~~~~
| | set lcl_bm(FCN)| |set lcl_bm(FCN)
| | send lcl_bm| |send lcl_bm
| | | +----------------------+
| |All-1 & w=expected | |
| |& RCS wrong v +---+ w=expected & |
| |~~~~~~~~~~~~~~~~~~~~ +====+=====+ | RCS wrong |
| |set lcl_bm(FCN) | +<+ ~~~~~~~~~~~~~~ |
| |send lcl_bm | Wait End | set lcl_bm(FCN)|
| +--------------------->+ +--->* ABORT |
| +===+====+=+-+ All-1&RCS wrong|
| | ^ | ~~~~~~~~~~~~~~~|
| w=expected & RCS right | +---+ send lcl_bm |
| ~~~~~~~~~~~~~~~~~~~~~~ | |
| set lcl_bm(FCN) | +-+ Not All-1 |
| send lcl_bm | | | ~~~~~~~~~ |
| | | | discard |
|All-1&w=expected & RCS right | | | |
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v +----+All-1 |
|set lcl_bm(FCN) +=+=+=+=+==+ |~~~~~~~~~ |
|send lcl_bm | +<+Send lcl_bm |
+-------------------------->+ END | |
+==========+<---------------+
--->* ABORT
In any state on receiving a SCHC ACK REQ Send a SCHC ACK for the current window
SCHC ACKの受信時に任意の状態でREQ現在のウィンドウにSCHC ACKを送信
Figure 42: Receiver State Machine for the ACK-Always Mode
図42：ACK-Alwaysモードのレシーバーステートマシン
+=======+
| |
| INIT |
| | FCN!=0 & more frags
+======++ ~~~~~~~~~~~~~~~~~~~~~~
Frag RuleID trigger | +--+ Send cur_W + frag(FCN);
~~~~~~~~~~~~~~~~~~~ | | | FCN--;
cur_W=0; FCN=max_value;| | | set [cur_W, cur_Bmp]
clear [cur_W, Bmp_n];| | v
clear rcv_Bmp | ++==+==========+ **BACK_TO_SEND
+->+ | cur_W==rcv_W &
**BACK_TO_SEND | SEND | [cur_W,Bmp_n]==rcv_Bmp
+-------------------------->+ | & more frags
| +----------------------->+ | ~~~~~~~~~~~~
| | ++==+==========+ cur_W++;
| | FCN==0 & more frags| |last frag clear [cur_W, Bmp_n]
| | ~~~~~~~~~~~~~~~~~~~~~~~| |~~~~~~~~~
| | set cur_Bmp; | |set [cur_W, Bmp_n];
| |send cur_W + frag(All-0);| |send cur_W + frag(All-1)+RCS;
| | set Retrans_Timer| |set Retrans_Timer
| | | | +---------------------------------+
| | | | |cur_W == |
| |Retrans_Timer expires & | | | rcv_W & [cur_W,Bmp_n]!=rcv_Bmp|
| |more Frags | | | ~~~~~~~~~~~~~~~~~~~ |
| |~~~~~~~~~~~~~~~~~~~~ | | | Attempts++; W=cur_W |
| |stop Retrans_Timer; | | | +--------+ rcv_W==Wn &|
| |[cur_W,Bmp_n]==cur_Bmp; v v | | v [Wn,Bmp_n]!=rcv_Bmp|
| |cur_W++ +=====+==+=+=+==+ +=+=========+ ~~~~~~~~~~~|
| +-------------------+ | | Resend | Attempts++;|
+----------------------+ Wait x ACK | | Missing | W=Wn |
+--------------------->+ | | Frags(W) +<-----------+
| rcv_W==Wn &+-+ | +======+====+
| [Wn,Bmp_n]!=rcv_Bmp| ++=+===+===+==+=+ |
| ~~~~~~~~~~~~~~| ^ | | | ^ |
| send (cur_W,+--+ | | | +------------+
| ALL-0-empty) | | | all missing frag sent(W)
| | | | ~~~~~~~~~~~~~~~~~
| Retrans_Timer expires &| | | set Retrans_Timer
| No more Frags| | |
| ~~~~~~~~~~~~~~| | |
| stop Retrans_Timer;| | |
|(re)send frag(All-1)+RCS | | |
+-------------------------+ | |
cur_W==rcv_W&| |
[cur_W,Bmp_n]==rcv_Bmp&| | Attempts > MAX_ACK_REQUESTS
No more Frags & RCS flag==OK| | ~~~~~~~~~~
~~~~~~~~~~~~~~~~~~| | send Abort
+=========+stop Retrans_Timer| | +===========+
| END +<-----------------+ +->+ ERROR |
+=========+ +===========+
Figure 43: Sender State Machine for the ACK-on-Error Mode
図43：ACK-on-Errorモードの送信側ステートマシン
This is an example only. It is not normative. The specification in Section 8.4.3.1 allows for sequences of operations different from the one shown here.
これは単なる例です。それは規範的ではありません。セクション8.4.3.1の仕様では、ここに示されているものとは異なる一連の操作が可能です。
+=======+ New frag RuleID received
| | ~~~~~~~~~~~~~
| INIT +-------+cur_W=0;clear([cur_W,Bmp_n]);
+=======+ |sync=0
|
Not All* & rcv_W==cur_W+---+ | +--+
~~~~~~~~~~~~~~~~~~~~ | | | | (E)
set[cur_W,Bmp_n(FCN)]| v v v |
++===+=+=+==+=+
+----------------------+ +--+ All-0&Full[cur_W,Bmp_n]
| ABORT *<---+ Rcv Window | | ~~~~~~~~~~
| +-------------------+ +<-+ cur_W++;set Inact_timer;
| | +->+=+=+=+=+=+===+ clear [cur_W,Bmp_n]
| | All-0 empty(Wn)| | | | ^ ^
| | ~~~~~~~~~~~~~~ +----+ | | | |rcv_W==cur_W & sync==0;
| | sendACK([Wn,Bmp_n]) | | | |& Full([cur_W,Bmp_n])
| | | | | |& All* || last_miss_frag
| | | | | |~~~~~~~~~~~~~~~~~~~~~~
| | All* & rcv_W==cur_W|(C)| |sendACK([cur_W,Bmp_n]);
| | & sync==0| | | |cur_W++; clear([cur_W,Bmp_n])
| |&no_full([cur_W,Bmp_n])| |(E)|
| | ~~~~~~~~~~~~~~~~ | | | | +========+
| | sendACK([cur_W,Bmp_n])| | | | | Error/ |
| | | | | | +----+ | Abort |
| | v v | | | | +===+====+
| | +===+=+=+=+===+=+ (D) ^
| | +--+ Wait x | | |
| | All-0 empty(Wn)+->| Missing Frags |<-+ |
| | ~~~~~~~~~~~~~~ +=============+=+ |
| | sendACK([Wn,Bmp_n]) +--------------+
| | *ABORT
v v
(A)(B)
(D) All* || last_miss_frag
(C) All* & sync>0 & rcv_W!=cur_W & sync>0
~~~~~~~~~~~~ & Full([rcv_W,Bmp_n])
Wn=oldest[not full(W)]; ~~~~~~~~~~~~~~~~~~~~
sendACK([Wn,Bmp_n]) Wn=oldest[not full(W)];
sendACK([Wn,Bmp_n]);sync--
ABORT-->* Uplink Only &
Inact_Timer expires
(E) Not All* & rcv_W!=cur_W || Attempts > MAX_ACK_REQUESTS
~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~
sync++; cur_W=rcv_W; send Abort
set[cur_W,Bmp_n(FCN)]
(A)(B)
| |
| | All-1 & rcv_W==cur_W & RCS!=OK All-0 empty(Wn)
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-+ ~~~~~~~~~~
| | sendACK([cur_W,Bmp_n],C=0) | v sendACK([Wn,Bmp_n])
| | +===========+=++
| +--------------------->+ Wait End +-+
| +=====+=+====+=+ | All-1
| rcv_W==cur_W & RCS==OK | | ^ | & rcv_W==cur_W
| ~~~~~~~~~~~~~~~~~~~~~~ | | +---+ & RCS!=OK
| sendACK([cur_W,Bmp_n],C=1) | | ~~~~~~~~~~~~~~~~~~~
| | | sendACK([cur_W,Bmp_n],C=0);
| | | Attempts++
|All-1 & Full([cur_W,Bmp_n]) | |
|& RCS==OK & sync==0 | +-->* ABORT
|~~~~~~~~~~~~~~~~~~~ v
|sendACK([cur_W,Bmp_n],C=1) +=+=========+
+---------------------------->+ END |
+===========+
Figure 44: Receiver State Machine for the ACK-on-Error Mode
図44：ACK-on-Errorモードのレシーバーステートマシン
This section lists the information that needs to be provided in the LPWAN technology-specific documents.
このセクションでは、LPWANテクノロジー固有のドキュメントで提供する必要がある情報を示します。
* Most common uses cases, deployment scenarios.
* 最も一般的な使用例、展開シナリオ。
* Mapping of the SCHC architectural elements onto the LPWAN architecture.
* SCWANアーキテクチャ要素のLPWANアーキテクチャへのマッピング。
* Assessment of LPWAN integrity checking.
* LPWAN整合性チェックの評価。
* Various potential channel conditions for the technology and the corresponding recommended use of SCHC C/D and SCHC F/R.
* テクノロジのさまざまな潜在的なチャネル条件と、SCHC C / DおよびSCHC F / Rの対応する推奨される使用法。
This section lists the parameters that need to be defined in the Profile.
このセクションには、プロファイルで定義する必要のあるパラメーターがリストされています。
* RuleID numbering scheme, fixed-size or variable-size RuleIDs, number of Rules, the way the RuleID is transmitted.
* RuleIDの番号付け方式、固定サイズまたは可変サイズのRuleID、ルールの数、RuleIDの送信方法。
* maximum packet size that should ever be reconstructed by SCHC decompression (MAX_PACKET_SIZE). See Section 12.
* SCHC圧縮解除によって再構築される必要がある最大パケットサイズ（MAX_PACKET_SIZE）。セクション12を参照してください。
* Padding: size of the L2 Word (for most LPWAN technologies, this would be a byte; for some technologies, a bit).
* パディング：L2ワードのサイズ（ほとんどのLPWANテクノロジーの場合、これは1バイトです。一部のテクノロジーでは、ビットです）。
* Decision to use SCHC fragmentation mechanism or not. If yes, the document must describe:
* SCHCフラグメンテーションメカニズムを使用するかどうかの決定。はいの場合、文書は以下を説明する必要があります。
- reliability mode(s) used, in which cases (e.g., based on link channel condition).
- 使用される信頼性モード。この場合（リンクチャネルの状態に基づくなど）。
- RuleID values assigned to each mode in use.
- 使用中の各モードに割り当てられたRuleID値。
- presence and number of bits for DTag (T) for each RuleID value, lifetime of DTag at the receiver.
- 各RuleID値のDTagの存在とビット数（T）、受信側でのDTagの寿命。
- support for interleaved packet transmission, to what extent.
- インターリーブされたパケット送信をどの程度サポートします。
- WINDOW_SIZE, for modes that use windows.
- WINDOW_SIZE、ウィンドウを使用するモード用。
- number of bits for W (M) for each RuleID value, for modes that use windows.
- ウィンドウを使用するモードの場合、各RuleID値のW（M）のビット数。
- number of bits for FCN (N) for each RuleID value, meaning of the FCN values.
- 各RuleID値のFCNのビット数（N）、つまりFCN値の意味。
- what makes an All-0 SCHC Fragment and a SCHC ACK REQ distinguishable (see Section 8.3.1.1).
- All-0 SCHCフラグメントとSCHC ACK REQを区別できるようにするもの（8.3.1.1を参照）。
- what makes an All-1 SCHC Fragment and a SCHC Sender-Abort distinguishable (see Section 8.3.1.2).
- All-1 SCHCフラグメントとSCHC Sender-Abortを区別できるようにするもの（8.3.1.2を参照）。
- for RuleIDs that use ACK-on-Error mode: when the last tile of a SCHC Packet is to be sent in a Regular SCHC Fragment, alone in an All-1 SCHC Fragment or with any of these two methods.
- ACK-on-Errorモードを使用するRuleIDの場合：SCHCパケットの最後のタイルがAll-1 SCHCフラグメントで単独で、またはこれら2つの方法のいずれかで、通常のSCHCフラグメントで送信される場合。
- for RuleIDs that use ACK-on-Error mode: if the penultimate tile of a SCHC Packet is of the regular size only or if it can also be one L2 Word shorter.
- ACK-on-Errorモードを使用するRuleIDの場合：SCHCパケットの最後から2番目のタイルが通常のサイズのみである場合、またはL2ワード1つ短くなる場合もあります。
- for RuleIDs that use ACK-on-Error mode: times at which the sender must listen for SCHC ACKs.
- ACK-on-Errorモードを使用するRuleIDの場合：送信者がSCHC ACKをリッスンする必要がある時間。
- size of RCS and algorithm for its computation, for each RuleID, if different from the default CRC32. Byte fill-up with zeroes or other mechanism, to be specified. Support for UDP checksum elision.
- デフォルトのCRC32と異なる場合、各RuleIDのRCSのサイズとその計算アルゴリズム。指定する、ゼロまたはその他のメカニズムによるバイトの充てん。 UDPチェックサム省略のサポート。
- Retransmission Timer duration for each RuleID value, if applicable to the SCHC F/R mode.
- SCHC F / Rモードに適用可能な場合、各RuleID値の再送信タイマー期間。
- Inactivity Timer duration for each RuleID value, if applicable to the SCHC F/R mode.
- SCHC F / Rモードに適用可能な場合、各RuleID値の非アクティブタイマー期間。
- MAX_ACK_REQUESTS value for each RuleID value, if applicable to the SCHC F/R mode.
- SCHC F / Rモードに適用可能な場合、各RuleID値のMAX_ACK_REQUESTS値。
* if L2 Word is wider than a bit and SCHC fragmentation is used, value of the padding bits (0 or 1).
* L2ワードがビットより広く、SCHCフラグメンテーションが使用されている場合、パディングビットの値（0または1）。
A Profile may define a delay to be added after each SCHC message transmission for compliance with local regulations or other constraints imposed by the applications.
プロファイルは、ローカル規制やアプリケーションによって課されるその他の制約に準拠するために、各SCHCメッセージ送信の後に追加される遅延を定義する場合があります。
* In some LPWAN technologies, as part of energy-saving techniques, Downlink transmission is only possible immediately after an Uplink transmission. In order to avoid potentially high delay in the Downlink transmission of a fragmented SCHC Packet, the SCHC Fragment receiver may perform an Uplink transmission as soon as possible after reception of a SCHC Fragment that is not the last one. Such Uplink transmission may be triggered by the L2 (e.g., an L2 ACK sent in response to a SCHC Fragment encapsulated in a L2 PDU that requires an L2 ACK) or it may be triggered from an upper layer. See Appendix F.
* 一部のLPWANテクノロジーでは、省エネ技術の一部として、ダウンリンク送信はアップリンク送信の直後にのみ可能です。断片化されたSCHCパケットのダウンリンク送信で潜在的に高い遅延を回避するために、SCHCフラグメント受信機は、最後のものではないSCHCフラグメントの受信後、できるだけ早くアップリンク送信を実行します。このようなアップリンク送信は、L2（L2 ACKを必要とするL2 PDUにカプセル化されたSCHCフラグメントに応答して送信されるL2 ACKなど）によってトリガーされるか、上位層からトリガーされます。付録Fを参照してください。
* the following parameters need to be addressed in documents other than this one but not necessarily in the LPWAN technology-specific documents:
* 次のパラメータは、これ以外のドキュメントで対処する必要がありますが、必ずしもLPWANテクノロジ固有のドキュメントで対処する必要はありません。
- The way the Contexts are provisioned.
- コンテキストがプロビジョニングされる方法。
- The way the Rules are generated.
- ルールの生成方法。
For ACK-Always or ACK-on-Error, implementers may opt to support a single window size or multiple window sizes. The latter, when feasible, may provide performance optimizations. For example, a large WINDOW_SIZE should be used for packets that need to be split into a large number of tiles. However, when the number of tiles required to carry a packet is low, a smaller WINDOW_SIZE and, thus, a shorter Bitmap, may be sufficient to provide reception status on all tiles. If multiple window sizes are supported, the RuleID signals what WINDOW_SIZE is in use for a specific packet transmission.
ACK-AlwaysまたはACK-on-Errorの場合、実装者は単一のウィンドウサイズまたは複数のウィンドウサイズをサポートすることを選択できます。後者は、可能であれば、パフォーマンスの最適化を提供します。たとえば、多数のタイルに分割する必要があるパケットには、大きなWINDOW_SIZEを使用する必要があります。ただし、パケットの伝送に必要なタイルの数が少ない場合は、WINDOW_SIZEを小さくして、ビットマップを短くすることで、すべてのタイルで受信ステータスを提供できます。複数のウィンドウサイズがサポートされている場合、RuleIDは、特定のパケット送信に使用されているWINDOW_SIZEを通知します。
The ACK-Always and ACK-on-Error modes of SCHC F/R are bidirectional protocols: they require a feedback path from the reassembler to the fragmenter.
SCHC F / RのACK-AlwaysモードとACK-on-Errorモードは双方向プロトコルです。これらのモードでは、リアセンブラからフラグメンタへのフィードバックパスが必要です。
Some LPWAN technologies provide quasi-bidirectional connectivity, whereby a Downlink transmission from the Network Infrastructure can only take place right after an Uplink transmission by the Dev.
一部のLPWANテクノロジーは準双方向接続を提供します。これにより、ネットワークインフラストラクチャからのダウンリンク送信は、Devによるアップリンク送信の直後にのみ実行できます。
When using SCHC F/R to send fragmented SCHC Packets Downlink over these quasi-bidirectional links, the following situation may arise: if an Uplink SCHC ACK is lost, the SCHC ACK REQ message by the sender could be stuck indefinitely in the Downlink queue at the Network Infrastructure, waiting for a transmission opportunity.
SCHC F / Rを使用して断片化されたSCHCパケットダウンリンクをこれらの準双方向リンク経由で送信すると、次の状況が発生する可能性があります。アップリンクSCHC ACKが失われた場合、送信者によるSCHC ACK REQメッセージがダウンリンクキューで無期限にスタックする可能性があります。送信機会を待っているネットワークインフラストラクチャ。
There are many ways by which this deadlock can be avoided. The Dev application might be sending recurring Uplink messages such as keep-alive, or the Dev application stack might be sending other recurring Uplink messages as part of its operation. However, these are out of the control of this generic SCHC specification.
このデッドロックを回避する方法はたくさんあります。 Devアプリケーションがキープアライブなどの定期的なアップリンクメッセージを送信しているか、Devアプリケーションスタックがその操作の一部として他の定期的なアップリンクメッセージを送信している可能性があります。ただし、これらはこの汎用SCHC仕様では制御できません。
In order to cope with quasi-bidirectional links, a SCHC-over-foo specification may want to amend the SCHC F/R specification to add a timer-based retransmission of the SCHC ACK. Below is an example of the suggested behavior for ACK-Always mode. Because it is an example, [RFC2119] language is deliberately not used here.
準双方向リンクに対処するために、SCHC-over-foo仕様では、SCHC F / R仕様を修正して、SCHC ACKのタイマーベースの再送信を追加することができます。以下は、ACK-Alwaysモードの推奨される動作の例です。 [RFC2119]言語は例であるため、ここでは意図的に使用していません。
For Downlink transmission of a fragmented SCHC Packet in ACK-Always mode, the SCHC Fragment receiver may support timer-based SCHC ACK retransmission. In this mechanism, the SCHC Fragment receiver initializes and starts a timer (the UplinkACK Timer) after the transmission of a SCHC ACK, except when the SCHC ACK is sent in response to the last SCHC Fragment of a packet (All-1 fragment). In the latter case, the SCHC Fragment receiver does not start a timer after transmission of the SCHC ACK.
ACK-Alwaysモードでのフラグメント化されたSCHCパケットのダウンリンク送信の場合、SCHCフラグメント受信機は、タイマーベースのSCHC ACK再送信をサポートできます。このメカニズムでは、SCHCフラグメントレシーバーは、パケットの最後のSCHCフラグメント（All-1フラグメント）に応答してSCHC ACKが送信される場合を除いて、SCHC ACKの送信後にタイマー（UplinkACKタイマー）を初期化して開始します。後者の場合、SCHCフラグメント受信機は、SCHC ACKの送信後にタイマーを開始しません。
If, after transmission of a SCHC ACK that is not an All-1 fragment, and before expiration of the corresponding UplinkACK timer, the SCHC Fragment receiver receives a SCHC Fragment that belongs to the current window (e.g., a missing SCHC Fragment from the current window) or to the next window, the UplinkACK timer for the SCHC ACK is stopped. However, if the UplinkACK timer expires, the SCHC ACK is resent and the UplinkACK timer is reinitialized and restarted.
All-1フラグメントではないSCHC ACKの送信後、対応するUplinkACKタイマーの期限が切れる前に、SCHCフラグメントレシーバーが現在のウィンドウに属するSCHCフラグメントを受信した場合（たとえば、現在のSCHCフラグメントが欠落している） window）または次のウィンドウへ、SCHC ACKのUplinkACKタイマーが停止します。ただし、UplinkACKタイマーが期限切れになると、SCHC ACKが再送信され、UplinkACKタイマーが再初期化されて再起動されます。
The default initial value for the UplinkACK Timer, as well as the maximum number of retries for a specific SCHC ACK, denoted MAX_ACK_REQUESTS, is to be defined in a Profile. The initial value of the UplinkACK timer is expected to be greater than that of the Retransmission timer, in order to make sure that a (buffered) SCHC Fragment to be retransmitted finds an opportunity for that transmission. One exception to this recommendation is the special case of the All-1 SCHC Fragment transmission.
UplinkACKタイマーのデフォルトの初期値と、MAX_ACK_REQUESTSで示される特定のSCHC ACKの最大再試行回数は、プロファイルで定義されます。 UplinkACKタイマーの初期値は、再送信される（バッファされた）SCHCフラグメントがその送信の機会を見つけることを確実にするために、再送信タイマーの初期値よりも大きいと予想されます。この推奨事項の1つの例外は、All-1 SCHCフラグメント送信の特殊なケースです。
When the SCHC Fragment sender transmits the All-1 SCHC Fragment, it starts its Retransmission Timer with a large timeout value (e.g., several times that of the initial UplinkACK Timer). If a SCHC ACK is received before expiration of this timer, the SCHC Fragment sender retransmits any lost SCHC Fragments as reported by the SCHC ACK, or if the SCHC ACK confirms successful reception of all SCHC Fragments of the last window, the transmission of the fragmented SCHC Packet is considered complete. If the timer expires, and no SCHC ACK has been received since the start of the timer, the SCHC Fragment sender assumes that the All-1 SCHC Fragment has been successfully received (and possibly, the last SCHC ACK has been lost: this mechanism assumes that the Retransmission Timer for the All-1 SCHC Fragment is long enough to allow several SCHC ACK retries if the All-1 SCHC Fragment has not been received by the SCHC Fragment receiver, and it also assumes that it is unlikely that several ACKs become all lost).
SCHCフラグメント送信者がAll-1 SCHCフラグメントを送信すると、大きなタイムアウト値（たとえば、最初のUplinkACKタイマーの数倍）で再送信タイマーが開始されます。このタイマーの期限が切れる前にSCHC ACKが受信された場合、SCHCフラグメント送信者は、SCHC ACKによって報告されたすべての失われたSCHCフラグメントを再送信します。または、SCHC ACKが最後のウィンドウのすべてのSCHCフラグメントの正常な受信を確認した場合、フラグメント化されたフラグメントの送信SCHCパケットは完全と見なされます。タイマーの期限が切れ、タイマーの開始以降にSCHC ACKが受信されなかった場合、SCHCフラグメント送信者は、All-1 SCHCフラグメントが正常に受信されたと見なします（そして、最後のSCHC ACKが失われた可能性があります。このメカニズムは、 All-1 SCHCフラグメントの再送信タイマーは、All-1 SCHCフラグメントがSCHCフラグメントレシーバーで受信されなかった場合に複数のSCHC ACK再試行を許可するのに十分な長さであり、いくつかのACKがすべてになる可能性は低いと想定している失われた）。
Acknowledgements
謝辞
Thanks to (in alphabetical order) Sergio Aguilar Romero, David Black, Carsten Bormann, Deborah Brungard, Brian Carpenter, Philippe Clavier, Alissa Cooper, Roman Danyliw, Daniel Ducuara Beltran, Diego Dujovne, Eduardo Ingles Sanchez, Rahul Jadhav, Benjamin Kaduk, Arunprabhu Kandasamy, Suresh Krishnan, Mirja Kuehlewind, Barry Leiba, Sergio Lopez Bernal, Antoni Markovski, Alexey Melnikov, Georgios Papadopoulos, Alexander Pelov, Charles Perkins, Edgar Ramos, Alvaro Retana, Adam Roach, Shoichi Sakane, Joseph Salowey, Pascal Thubert, and Eric Vyncke for useful design considerations, reviews and comments.
おかげで（アルファベット順）セルジオアギラルロメロ、デビッドブラック、カルステンボルマン、デボラブランガード、ブライアンカーペンター、フィリップクラヴィエ、アリッサクーパー、ローマダニーリュー、ダニエルデュクアラベルトラン、ディエゴデュヨブネ、エドゥアルドイングレスサンチェス、ラーフルジャダフ、ベンジャプラカドゥク、アベンジャープラカドゥクカンダサミー、スレシュクリシュナン、ミルハキュールウィンド、バリーレイバ、セルジオロペスベルナル、アントニマルコフスキー、アレクセイメルニコフ、ゲオルギオスパパドプロス、アレクサンダーペロフ、チャールズパーキンス、エドガーラモス、アルバロレタナ、アダムローチ、酒根翔一、ジョセフサロウィー、パスカルトゥカルVynckeは、有用な設計上の考慮事項、レビュー、コメントを提供しています。
Carles Gomez has been funded in part by the Spanish Government (Ministerio de Educacion, Cultura y Deporte) through the Jose Castillejo grant CAS15/00336 and by the ERDF and the Spanish Government through project TEC2016-79988-P. Part of his contribution to this work has been carried out during his stay as a visiting scholar at the Computer Laboratory of the University of Cambridge.
カルレスゴメスは、ホセカスティレホ助成金CAS15 / 00336を通じてスペイン政府（教育省、文化センター）から、プロジェクトTEC2016-79988-Pを通じてERDFとスペイン政府から一部資金提供を受けています。この作品への彼の貢献の一部は、ケンブリッジ大学のコンピュータ研究所の客員研究員としての滞在中に行われました。
Authors' Addresses
著者のアドレス
Ana Minaburo Acklio 1137A avenue des Champs Blancs 35510 Cesson-Sevigne Cedex France
Ana Minaburo Acklio 1137A avenue des Champs Blancs 35510 Cesson-Sevigne Cedex France
Email: ana@ackl.io
Laurent Toutain IMT Atlantique 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France
Laurent Toutain IMT Atlantique 2 rue de la Chataigneraie CS 17607 35576セッソンセビニェセデックスフランス
Email: Laurent.Toutain@imt-atlantique.fr
Carles Gomez Universitat Politecnica de Catalunya C/Esteve Terradas, 7 08860 Castelldefels Spain
Carles Gomez Universitat Politecnica de Catalunya C / Esteve Terradas、7 08860 Castelldefels Spain
Email: carlesgo@entel.upc.edu
Dominique Barthel Orange Labs 28 chemin du Vieux Chene 38243 Meylan France
Dominique Barthel Orange Labs 28 chemin du Vieux Chene 38243メランフランス
Email: dominique.barthel@orange.com
Juan Carlos Zuniga SIGFOX 425 rue Jean Rostand 31670 Labege France
フアンカルロススニガSIGFOX 425 rue Jean Rostand 31670ラベージュフランス
Email: JuanCarlos.Zuniga@sigfox.com