[要約] このRFCは、LPWAN（低電力広域ネットワーク）の一つであるSigfoxネットワークにおいて、ヘッダー圧縮技術「SCHC」を適用するための具体的なプロファイルを定義しています。Sigfox特有の極めて小さいペイロードサイズと厳格なデューティサイクルに合わせて、パケットの断片化ルール、再送パラメータ、およびタイマー設定を最適化し、Sigfox経由でのIPv6/UDP/CoAP通信を効率的に実現します。
Internet Engineering Task Force (IETF) JC. Zúñiga
Request for Comments: 9442
Category: Standards Track C. Gomez
ISSN: 2070-1721 S. Aguilar
Universitat Politècnica de Catalunya
L. Toutain
IMT-Atlantique
S. Céspedes
Concordia University
D. Wistuba
NIC Labs, Universidad de Chile
J. Boite
Unabiz (Sigfox)
July 2023
The Static Context Header Compression (SCHC) and fragmentation specification (RFC 8724) describes a generic framework for application header compression and fragmentation modes designed for Low-Power Wide Area Network (LPWAN) technologies. This document defines a profile of SCHC over Sigfox LPWAN and provides optimal parameter values and modes of operation.
静的コンテキストヘッダー圧縮（SCHC）およびフラグメンテーション仕様（RFC 8724）は、低電力ワイドエリアネットワーク（LPWAN）テクノロジー向けに設計されたアプリケーションヘッダー圧縮および断片化モードの一般的なフレームワークを説明しています。このドキュメントでは、SIGFOX LPWANを介したSCHCのプロファイルを定義し、最適なパラメーター値と動作モードを提供します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9442.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9442で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction 2. Terminology 3. SCHC over Sigfox 3.1. Network Architecture 3.2. Uplink 3.3. Downlink 3.3.1. SCHC ACK on Downlink 3.4. SCHC Rules 3.5. Fragmentation 3.5.1. Uplink Fragmentation 3.5.2. Downlink Fragmentation 3.6. SCHC over Sigfox F/R Message Formats 3.6.1. Uplink No-ACK Mode: Single-Byte SCHC Header 3.6.2. Uplink ACK-on-Error Mode: Single-Byte SCHC Header 3.6.3. Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 1 3.6.4. Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 2 3.6.5. Downlink ACK-Always Mode: Single-Byte SCHC Header 3.7. Padding 4. Fragmentation Rules Examples 4.1. Uplink Fragmentation Rules Examples 4.2. Downlink Fragmentation Rules Example 5. Fragmentation Sequence Examples 5.1. Uplink No-ACK Examples 5.2. Uplink ACK-on-Error Examples: Single-Byte SCHC Header 5.3. SCHC Abort Examples 6. Security Considerations 7. IANA Considerations 8. References 8.1. Normative References 8.2. Informative References Acknowledgements Authors' Addresses
The Generic Framework for Static Context Header Compression (SCHC) and Fragmentation specification [RFC8724] can be used in conjunction with any of the four LPWAN technologies described in [RFC8376]. These LPWANs have similar characteristics, such as star-oriented topologies, network architecture, connected devices with built-in applications, etc.
SCHC offers a considerable degree of flexibility to accommodate all these LPWAN technologies. Even though there are a great number of similarities between them, some differences exist with respect to the transmission characteristics, payload sizes, etc. Hence, there are optimal parameters and modes of operation that can be used when SCHC is used in conjunction with a specific LPWAN technology.
SCHCは、これらすべてのLPWANテクノロジーに対応するためにかなりの柔軟性を提供します。それらの間には非常に多くの類似点がありますが、伝送特性、ペイロードサイズなどに関していくつかの違いがあります。したがって、SCHCを特定のものと組み合わせて使用する場合に使用できる最適なパラメーターと動作モードがあります。LPWANテクノロジー。
Sigfox is an LPWAN technology that offers energy-efficient connectivity for devices at a very low cost. Complete Sigfox documentation can be found in [sigfox-docs]. Sigfox aims to provide a very wide area network composed of Base Stations that receive short Uplink messages (up to 12 bytes in size) sent by devices over the long-range Sigfox radio protocol, as described in [RFC8376]. Base Stations then forward messages to the Sigfox Cloud infrastructure for further processing (e.g., to offer geolocation services) and final delivery to the customer. Base Stations also relay Downlink messages (with a fixed 8-byte size) sent by the Sigfox Cloud to the devices, i.e., Downlink messages are being generated when devices explicitly request these messages with a flag in an Uplink message. With SCHC functionalities, the Sigfox network offers more reliable communications (including recovery of lost messages) and is able to convey extended-size payloads (allowing for fragmentation/reassembly of messages) [sigfox-spec].
Sigfoxは、非常に低コストでデバイスのエネルギー効率の高い接続を提供するLPWANテクノロジーです。完全なsigfoxドキュメントは[Sigfox-docs]にあります。Sigfoxは、[RFC8376]に記載されているように、長距離SIGFOXラジオプロトコルを介してデバイスによって送信される短いアップリンクメッセージ（最大12バイト）を受け取るベースステーションで構成される非常に広いエリアネットワークを提供することを目指しています。その後、ベースステーションは、顧客へのさらなる処理（たとえば、ジオロケーションサービスを提供するために）と最終配信のために、Sigfoxクラウドインフラストラクチャにメッセージを転送します。また、ベースステーションは、Sigfoxクラウドからデバイスに送信されるダウンリンクメッセージ（固定8バイトサイズ）をデバイスにリレーします。つまり、デバイスがアップリンクメッセージのフラグを使用してこれらのメッセージを明示的に要求すると、ダウンリンクメッセージが生成されます。SCHC機能により、SIGFOXネットワークはより信頼性の高い通信（失われたメッセージの回復を含む）を提供し、拡張サイズのペイロード（メッセージの断片化/再組み立てを可能にする）を伝えることができます[SIGFOX-SPEC]。
This document describes the parameters, settings, and modes of operation to be used when SCHC is implemented over a Sigfox LPWAN. The set of parameters forms a "SCHC over Sigfox Profile". The SCHC over Sigfox Profile is applicable to the Sigfox Radio specification versions up to v1.6/March 2022 [sigfox-spec] (support for future versions would have to be assessed).
このドキュメントでは、SCHCがSIGFOX LPWANで実装されたときに使用される操作モード、操作モードについて説明します。パラメーターのセットは、「SIGFOXプロファイルを超えるSCHC」を形成します。SIGFOXプロファイルを介したSCHCは、2022年3月[SIGFOX-SPEC]（将来のバージョンのサポートを評価する必要がある）までのSIGFOX無線仕様バージョンに適用できます。
The Generic SCHC Framework described in [RFC8724] takes advantage of previous knowledge of traffic flows existing in LPWAN applications to avoid context synchronization.
[RFC8724]で説明されている一般的なSCHCフレームワークは、LPWANアプリケーションに存在するトラフィックフローの以前の知識を利用して、コンテキストの同期を回避します。
Contexts need to be stored and pre-configured on both ends. This can be done either by using a provisioning protocol, by out-of-band means, or by pre-provisioning them (e.g., at manufacturing time). For example, the context exchange can be done by using the Network Configuration Protocol (NETCONF) [RFC6241] with Secure Shell (SSH), RESTCONF [RFC8040] with secure HTTP methods, and CoAP Management Interface (CORECONF) [CORE-COMI] with the Constrained Application Protocol (CoAP) [RFC7252] as provisioning protocols. The contexts can be encoded in XML under NETCONF, in JSON [RFC8259] under RESTCONF, and in Concise Binary Object Representation (CBOR) [RFC8949] under CORECONF. The way contexts are configured and stored on both ends is out of the scope of this document.
コンテキストは、両端に保存および事前に構成する必要があります。これは、プロビジョニングプロトコルを使用して、帯域外の手段によって、またはそれらを前に進化すること（製造時間など）によって行うことができます。たとえば、コンテキスト交換は、セキュアシェル（SSH）、retsConf [RFC8040]を使用して、セキュアHTTPメソッド、およびCoAP管理インターフェイス（CoreCONF）[Core-comi]を使用して、ネットワーク構成プロトコル（NetConf）[RFC6241]を使用して実行できます。プロビジョニングプロトコルとしての制約付きアプリケーションプロトコル（CoAP）[RFC7252]。コンテキストは、NetConfの下のXML、JSON [RFC8259]のretsconfの下で、およびCoreconfの下で簡潔なバイナリオブジェクト表現（CBOR）[RFC8949]でエンコードできます。コンテキストの構成と両端に保存される方法は、このドキュメントの範囲外です。
Figure 1 represents the architecture for Compression/Decompression (C/D) and Fragmentation/Reassembly (F/R) based on the terminology defined in [RFC8376], where the Radio Gateway (RGW) is a Sigfox Base Station and the Network Gateway (NGW) is the Sigfox cloud-based Network.
図1は、[RFC8376]で定義されている用語に基づいて、圧縮/解凍（C/D）および断片化/再組み立て（F/R）のアーキテクチャを表しています。ここで、無線ゲートウェイ（RGW）はSIGFOXベースステーションとネットワークゲートウェイ（ネットワークゲートウェイ）です。NGW）は、SIGFOXクラウドベースのネットワークです。
Sigfox Device Application
+----------------+ +--------------+
| APP1 APP2 APP3 | |APP1 APP2 APP3|
+----------------+ +--------------+
| UDP | | | | UDP |
| IPv6 | | | | IPv6 |
+--------+ | | +--------+
| SCHC C/D & F/R | | |
| | | |
+-------+--------+ +--------+-----+
$ .
$ +---------+ +--------------+ +---------+ .
$ | | | Network | | Network | .
+~~ |Sigfox BS| | Gateway | | SCHC | .
| (RGW) | === | (NGW) | ... |C/D & F/R|.....
| | | Sigfox Cloud | | | IP-based
+---------+ +--------------+ +---------+ Network
------- Uplink message ------>
<------- Downlink message ------
Legend:
$, ~ : Radio link
= : Internal Sigfox Network
. : External IP-based Network
Figure 1: Network Architecture
図1：ネットワークアーキテクチャ
In the case of the global Sigfox network, RGWs (or Base Stations) are distributed over multiple countries wherever the Sigfox LPWAN service is provided. The NGW (or cloud-based Sigfox Core Network) is a single entity that connects to all RGWs (Sigfox Base Stations) in the world, hence providing a global single star Network topology.
グローバルSIGFOXネットワークの場合、RGWS（またはベースステーション）は、SIGFOX LPWANサービスが提供されていれば、複数の国に配布されます。NGW（またはクラウドベースのSigfoxコアネットワーク）は、世界のすべてのRGW（Sigfoxベースステーション）に接続する単一のエンティティであり、グローバルなシングルスターネットワークトポロジを提供します。
The Sigfox Device sends application packets that are compressed and/ or fragmented by a SCHC C/D + F/R to reduce header size and/or fragment the packet. The resulting SCHC message is sent over a layer two (L2) Sigfox frame to the Sigfox Base Stations, which then forward the SCHC message to the NGW. The NGW then delivers the SCHC message and associated gathered metadata to the Network SCHC C/D + F/R.
SIGFOXデバイスは、SCHC C/D F/Rによって圧縮および/または断片化されたアプリケーションパケットを送信して、ヘッダーサイズを縮小したり、パケットをフラグメントしたりします。結果のSCHCメッセージは、レイヤー2（L2）SIGFOXフレームを介してSIGFOXベースステーションに送信され、SCHCメッセージがNGWに転送されます。次に、NGWはSCHCメッセージを配信し、関連する収集されたメタデータをネットワークSCHC C/D F/Rに配信します。
The Sigfox cloud-based Network communicates with the Network SCHC C/D + F/R for compression/decompression and/or for fragmentation/ reassembly. The Network SCHC C/D + F/R shares the same set of Rules as the device SCHC C/D + F/R. The Network SCHC C/D + F/R can be collocated with the NGW or it could be located in a different place, as long as a tunnel or secured communication is established between the NGW and the SCHC C/D + F/R functions. After decompression and/or reassembly, the packet can be forwarded over the Internet to one (or several) LPWAN Application Server(s) (App(s)).
SIGFOXクラウドベースのネットワークは、圧縮/解凍および/または断片化/再組み立てのために、ネットワークSCHC C/D F/Rと通信します。ネットワークSCHC C/D F/Rは、デバイスSCHC C/D F/Rと同じルールセットを共有しています。NGWとSCHC C/D F/R機能の間にトンネルまたはセキュリティされた通信が確立されている限り、ネットワークSCHC C/D F/RはNGWと協力するか、別の場所に配置できます。解凍および/または再組み立ての後、パケットはインターネットを介して1つ（または複数の）LPWANアプリケーションサーバー（APP（s））に転送できます。
The SCHC C/D + F/R processes are bidirectional, so the same principles are applicable on both Uplink (UL) and Downlink (DL).
SCHC C/D F/Rプロセスは双方向であるため、同じ原則がアップリンク（UL）とダウンリンク（DL）の両方に適用されます。
Uplink Sigfox transmissions occur in repetitions over different times and frequencies. Besides time and frequency diversities, the Sigfox network also provides spatial diversity, as potentially an Uplink message will be received by several Base Stations. The Uplink message application payload size can be up to 12 bytes.
Uplink Sigfoxの送信は、さまざまな時間と周波数にわたって繰り返しで発生します。時間と頻度の多様性に加えて、Sigfoxネットワークは、いくつかのベースステーションがアップリンクメッセージを受信する可能性があるため、空間的多様性も提供します。アップリンクメッセージアプリケーションのペイロードサイズは、最大12バイトにすることができます。
Since all messages are self-contained and Base Stations forward all these messages back to the same Sigfox network, multiple input copies can be combined at the NGW, providing for extra reliability based on the triple diversity (i.e., time, space, and frequency).
すべてのメッセージは自己完結型であり、ベースステーションはこれらすべてのメッセージを同じSigfoxネットワークに戻すため、NGWで複数の入力コピーを組み合わせることができ、トリプルダイバーシティ（つまり、時間、スペース、頻度）に基づいて追加の信頼性を提供します。。
A detailed description of the Sigfox radio protocol can be found in [sigfox-spec].
SIGFOX無線プロトコルの詳細な説明は、[Sigfox-spec]にあります。
Messages sent from the device to the Network are delivered by the Sigfox cloud-based Network to the Network SCHC C/D + F/R through a callback/API with the following information:
デバイスからネットワークに送信されたメッセージは、SigfoxクラウドベースのネットワークによってネットワークSchc C/D F/Rに配信されます。
* Device ID
* デバイスID
* Message Sequence Number
* メッセージシーケンス番号
* Message Payload
* メッセージペイロード
* Message Timestamp
* メッセージタイムスタンプ
* Device Geolocation (optional)
* デバイスジオロケーション（オプション）
* Received Signal Strength Indicator (RSSI) (optional)
* 受信信号強度インジケーター（RSSI）（オプション）
* Device Temperature (optional)
* デバイス温度（オプション）
* Device Battery Voltage (optional)
* デバイスバッテリー電圧（オプション）
The Device ID is a globally unique identifier assigned to the device, which is included in the Sigfox header of every message. The Message Sequence Number is a monotonically increasing number identifying the specific transmission of this Uplink message, and it is also part of the Sigfox header. The Message Payload corresponds to the payload that the device has sent in the Uplink transmission. Battery Voltage, Device Temperature, and RSSI values are sent in the confirmation control message, which is mandatorily sent by the device after the successful reception of a Downlink message (see [sigfox-callbacks], Section 5.2).
デバイスIDは、すべてのメッセージのSigfoxヘッダーに含まれるデバイスに割り当てられたグローバルに一意の識別子です。メッセージシーケンス番号は、このアップリンクメッセージの特定の伝送を識別する単調に増加する数字であり、Sigfoxヘッダーの一部でもあります。メッセージペイロードは、デバイスがアップリンク送信で送信したペイロードに対応します。バッテリー電圧、デバイス温度、およびRSSI値は、ダウンリンクメッセージの受信が成功した後にデバイスによって強制的に送信される確認コントロールメッセージに送信されます（[Sigfox-Callbacks]、セクション5.2を参照）。
The Message Timestamp, Device Geolocation, RSSI, Device Temperature, and Device Battery Voltage are metadata parameters provided by the Network.
メッセージタイムスタンプ、デバイスジオロケーション、RSSI、デバイス温度、およびデバイスバッテリー電圧は、ネットワークが提供するメタデータパラメーターです。
A detailed description of the Sigfox callbacks/APIs can be found in [sigfox-callbacks].
Sigfoxコールバック/APIの詳細な説明は、[Sigfox-Callbacks]に記載されています。
Only messages that have passed the L2 Cyclic Redundancy Check (CRC) at Network reception are delivered by the Sigfox network to the Network SCHC C/D + F/R.
ネットワークレセプションでL2環状冗長チェック（CRC）に合格したメッセージのみが、SIGFOXネットワークによってネットワークSCHC C/D F/Rに配信されます。
The L2 Word size used by Sigfox is 1 byte (8 bits).
Sigfoxが使用するL2ワードサイズは1バイト（8ビット）です。
Figure 2 shows a SCHC message sent over Sigfox, where the SCHC message could be a full SCHC Packet (e.g., compressed) or a SCHC Fragment (e.g., a piece of a bigger SCHC Packet).
図2は、SIGFOXを介して送信されたSCHCメッセージを示しています。SCHCメッセージは、完全なSCHCパケット（たとえば、圧縮）またはSCHCフラグメント（たとえば、より大きなSCHCパケットの一部）である可能性があります。
| Sigfox Header | Sigfox Payload |
+---------------+---------------- +
| SCHC Message |
Figure 2: SCHC Message in Sigfox
図2：SigfoxのSCHCメッセージ
Downlink transmissions are device-driven and can only take place following an Uplink communication that indicates Downlink communication can be performed. Hence, a Sigfox Device explicitly indicates its intention to receive a Downlink message (with a size of 8 bytes) using a Downlink request flag when sending the preceding Uplink message to the Network. The Downlink request flag is part of the Sigfox protocol headers. After completing the Uplink transmission, the device opens a fixed window for Downlink reception. The delay and duration of the reception opportunity window have fixed values. If there is a Downlink message to be sent for this given device (e.g., either a response to the Uplink message or queued information waiting to be transmitted), the Network transmits this message to the device during the reception window. If no message is received by the device after the reception opportunity window has elapsed, the device closes the reception window opportunity and gets back to the normal mode (e.g., continue Uplink transmissions, sleep, standby, etc.).
ダウンリンク送信はデバイス駆動型であり、ダウンリンク通信を実行できることを示すアップリンク通信に続いてのみ行うことができます。したがって、SIGFOXデバイスは、前のアップリンクメッセージをネットワークに送信する際にダウンリンクリクエストフラグを使用して、ダウンリンクメッセージ（サイズ8バイトの）を受信する意図を明示的に示しています。ダウンリンクリクエストフラグは、SIGFOXプロトコルヘッダーの一部です。アップリンク送信を完了した後、デバイスはダウンリンクレセプション用の固定ウィンドウを開きます。レセプション機会ウィンドウの遅延と期間には固定値があります。この指定されたデバイスに対して送信されるダウンリンクメッセージがある場合（たとえば、アップリンクメッセージへの応答または送信を待っているキューに登録された情報のいずれか）、ネットワークは受信ウィンドウ中にこのメッセージをデバイスに送信します。レセプション機会ウィンドウが経過した後にデバイスからメッセージが受信されない場合、デバイスは受信ウィンドウの機会を閉じて通常モードに戻ります（たとえば、アップリンク送信、睡眠、スタンバイなど）。
When a Downlink message is sent to a device, a reception acknowledgement is generated by the device, sent back to the Network through the Sigfox radio protocol, and reported in the Sigfox network backend.
ダウンリンクメッセージがデバイスに送信されると、デバイスによってレセプションの確認が生成され、SIGFOXラジオプロトコルを介してネットワークに送信され、SIGFOXネットワークバックエンドで報告されます。
A detailed description of the Sigfox radio protocol can be found in [sigfox-spec], and a detailed description of the Sigfox callbacks/ APIs can be found in [sigfox-callbacks]. A Downlink request flag can be included in the information exchange between the Sigfox network and Network SCHC.
SIGFOXラジオプロトコルの詳細な説明は[Sigfox-Spec]に記載されており、Sigfoxコールバック/ APIの詳細な説明は[Sigfox-callbacks]にあります。ダウンリンクリクエストフラグは、SIGFOXネットワークとネットワークSCHCの間の情報交換に含めることができます。
As explained previously, Downlink transmissions are driven by devices and can only take place following a specific Uplink transmission that indicates and allows a following Downlink opportunity. For this reason, when SCHC bidirectional services are used (e.g., ACK-on-Error fragmentation mode), the SCHC protocol implementation needs to consider the times when a Downlink message (e.g., SCHC Acknowledgement (ACK)) can be sent and/or received.
前に説明したように、ダウンリンク送信はデバイスによって駆動され、次のダウンリンクの機会を示して可能にする特定のアップリンク伝送を続けてのみ行うことができます。このため、SCHCの双方向サービスを使用する場合（例：ACKオンエラーフラグメンテーションモード）、SCHCプロトコルの実装では、ダウンリンクメッセージ（たとえば、SCHC謝辞（ACK））を送信できる時間を考慮する必要があります。受け取った。
For the Uplink ACK-on-Error fragmentation mode, a Downlink opportunity MUST be indicated by the last fragment of every window, which is signalled by a specific value of the Fragment Compressed Number (FCN) value, i.e., FCN = All-0 or FCN = All-1. The FCN is the tile index in a specific window. The combination of the FCN and the window number uniquely identifies a SCHC Fragment, as explained in [RFC8724]. The device sends the fragments in sequence and, after transmitting FCN = All-0 or FCN = All-1, it opens up a reception opportunity. The Network SCHC can then decide to respond at that opportunity (or wait for a further one) with a SCHC ACK, indicating that there are missing fragments from the current or previous windows. If there is no SCHC ACK to be sent, or if the Network decides to wait for a further Downlink transmission opportunity, then no Downlink transmission takes place at that opportunity and the Uplink transmissions continue after a timeout. Intermediate SCHC Fragments with FCNs that are different from All-0 or All-1 MUST NOT use the Downlink request flag to request a SCHC ACK.
アップリンクACKオンエラーフラグメンテーションモードの場合、すべてのウィンドウの最後のフラグメントでダウンリンクの機会を示す必要があります。これは、フラグメント圧縮数（FCN）値の特定の値、つまりFCN = ALL-0またはfcn = all-1。FCNは、特定のウィンドウのタイルインデックスです。[RFC8724]で説明されているように、FCNとウィンドウ番号の組み合わせは、SCHCフラグメントを一意に識別します。デバイスはフラグメントを順番に送信し、FCN = ALL-0またはFCN = ALL-1を送信した後、レセプションの機会を開きます。ネットワークSCHCは、SCHC ACKでその機会に応答する（またはさらに1つを待つ）ことを決定することができます。SCHC ACKが送信されない場合、またはネットワークがさらにダウンリンク送信の機会を待つことを決定した場合、その機会にダウンリンク送信は行われず、アップリンク送信はタイムアウト後も続きます。ALL-0またはALL-1とは異なるFCNを使用した中間SCHCフラグメントは、ダウンリンク要求フラグを使用してSCHC ACKを要求してはなりません。
The RuleID MUST be included in the SCHC header. The total number of Rules to be used directly affects the RuleID field size, and therefore the total size of the fragmentation header. For this reason, it is RECOMMENDED to keep the number of Rules that are defined for a specific device to the minimum possible. Large RuleID sizes (and thus larger fragmentation headers) are acceptable for devices without significant energy constraints (e.g., a sensor that is powered by the electricity grid).
RuleIDはSCHCヘッダーに含める必要があります。使用するルールの総数は、直接的なフィールドサイズに直接影響し、したがってフラグメンテーションヘッダーの総サイズに影響します。このため、特定のデバイスに対して可能な限り定義されているルールの数を最小限に抑えることをお勧めします。大幅なエネルギーの制約のないデバイス（たとえば、電気グリッドを搭載したセンサー）には、大きなRuleIDサイズ（およびより大きなフラグメンテーションヘッダー）が許容されます。
RuleIDs can be used to differentiate data traffic classes (e.g., QoS, control vs. data, etc.) and data sessions. They can also be used to interleave simultaneous fragmentation sessions between a device and the Network.
RuleIDを使用して、データトラフィッククラス（QoS、コントロール対データなど）およびデータセッションを区別できます。また、デバイスとネットワーク間の同時断片化セッションを挿入するためにも使用できます。
The SCHC specification [RFC8724] defines a generic fragmentation functionality that allows sending data packets or files larger than the maximum size of a Sigfox payload. The functionality also defines a mechanism to reliably send multiple messages by allowing to selectively resend any lost fragments.
SCHC仕様[RFC8724]は、SIGFOXペイロードの最大サイズよりも大きいファイルを送信できる一般的な断片化機能を定義します。この機能は、失われたフラグメントを選択的に再送信できるようにすることにより、複数のメッセージを確実に送信するメカニズムを定義します。
The SCHC fragmentation supports several modes of operation. These modes have different advantages and disadvantages, depending on the specifics of the underlying LPWAN technology and application use case. This section describes how the SCHC fragmentation functionality should optimally be implemented when used over a Sigfox LPWAN for the most typical use case applications.
SCHCフラグメンテーションは、いくつかの動作モードをサポートしています。これらのモードには、基礎となるLPWANテクノロジーとアプリケーションのユースケースの詳細に応じて、さまざまな利点と短所があります。このセクションでは、最も典型的なユースケースアプリケーションでSIGFOX LPWANを介して使用する場合、SCHCフラグメンテーション機能を最適に実装する方法について説明します。
As described in Section 8.2.3 of [RFC8724], the integrity of the fragmentation-reassembly process of a SCHC Packet MUST be checked at the receiver end. Since only Uplink/Downlink messages/fragments that have passed the Sigfox CRC-check are delivered to the Network/Sigfox Device SCHC C/D + F/R, integrity can be guaranteed when no consecutive messages are missing from the sequence and all FCN bitmaps are complete. With this functionality in mind, and in order to save protocol and processing overhead, the use of a Reassembly Check Sequence (RCS), as described in Section 3.5.1.5, MUST be used.
[RFC8724]のセクション8.2.3で説明されているように、SCHCパケットの断片化修正プロセスの整合性をレシーバー端で確認する必要があります。SIGFOX CRC-Checkに合格したアップリンク/ダウンリンクメッセージ/フラグメントのみがネットワーク/SIGFOXデバイスSCHC C/D F/Rに配信されるため、シーケンスから連続したメッセージが欠落していない場合、すべてのFCNビットマップが完了すると、整合性を保証できます。。この機能を念頭に置いて、プロトコルとオーバーヘッドの処理を保存するには、セクション3.5.1.5で説明するように、再組み立てチェックシーケンス（RCS）の使用を使用する必要があります。
Sigfox Uplink transmissions are completely asynchronous and take place in any random frequency of the allowed Uplink bandwidth allocation. In addition, devices may go to deep sleep mode and then wake up and transmit whenever there is a need to send information to the Network, as there is no need to perform any Network attachment, synchronization, or other procedures before transmitting a data packet.
Sigfox Uplink送信は完全に非同期であり、許容されるアップリンク帯域幅の割り当てのランダム頻度で発生します。さらに、データパケットを送信する前にネットワーク添付ファイル、同期、またはその他の手順を実行する必要がないため、デバイスはディープスリープモードに移動してから、ネットワークに情報を送信する必要があるときはいつでも起動して送信できます。
Since Uplink transmissions are asynchronous, a SCHC Fragment can be transmitted at any given time by the device. Sigfox Uplink messages are fixed in size, and as described in [RFC8376], they can carry a payload of 0-12 bytes (0-96 bits). Hence, a single SCHC Tile size, per fragmentation mode, can be defined so that every Sigfox message always carries one SCHC Tile.
アップリンクの送信は非同期であるため、SCHCフラグメントはいつでもデバイスによって送信できます。Sigfoxアップリンクメッセージのサイズは固定されており、[RFC8376]で説明されているように、0〜12バイト（0〜96ビット）のペイロードを搭載できます。したがって、断片化モードごとに単一のSCHCタイルサイズを定義できるように、すべてのSigfoxメッセージに常に1つのSCHCタイルが付与されるようにできます。
When the ACK-on-Error mode is used for Uplink fragmentation, the SCHC Compound ACK defined in [RFC9441] MUST be used in the Downlink responses.
ACKオンエラーモードがアップリンクの断片化に使用される場合、[RFC9441]で定義されたSCHC化合物ACKをダウンリンク応答で使用しなければなりません (MUST)。
As defined in [RFC8724], a SCHC Sender-Abort can be triggered when the number of SCHC ACK REQ attempts is greater than or equal to MAX_ACK_REQUESTS. In the case of SCHC over Sigfox, a SCHC Sender-Abort MUST be sent if the number of repeated All-1s sent in sequence, without a Compound ACK reception in between, is greater than or equal to MAX_ACK_REQUESTS.
[RFC8724]で定義されているように、SCHC ACK REQの試行の数がMAX_ACK_REQUESTS以上である場合、SCHC Sender-Abortをトリガーできます。SIGFOXを介したSCHCの場合、SCHC Sender-Abortを送信しなければなりません (MUST)。
As defined in [RFC8724], a SCHC Receiver-Abort is triggered when the receiver has no RuleID and DTag pairs available for a new session. In the case of this profile, a SCHC Receiver-Abort MUST be sent if, for a single device, all the RuleIDs are being processed by the receiver (i.e., have an active session) at a certain time and a new one is requested or if the RuleID of the fragment is not valid.
[RFC8724]で定義されているように、レシーバーにRuleIDペアとDTAGペアが新しいセッションで利用できる場合、SCHCレシーバーアボートがトリガーされます。このプロファイルの場合、単一のデバイスの場合、すべてのRuleIDがレシーバーによって処理されている場合（つまり、アクティブなセッションがある）、特定の時間にSCHCレシーバーアボートを送信しなければなりません (MUST)。フラグメントのRuleIDが有効でない場合。
A SCHC Receiver-Abort MUST be triggered when the Inactivity Timer expires.
非アクティブタイマーの有効期限が切れたときに、SCHCレシーバーアボートをトリガーしなければなりません (MUST)。
MAX_ACK_REQUESTS can be increased when facing high error rates.
MAX_ACK_REQUESTSは、高いエラー率に直面すると増加する可能性があります。
Although a SCHC Receiver-Abort can be triggered at any point in time, a SCHC Receiver-Abort Downlink message MUST only be sent when there is a Downlink transmission opportunity.
SCHCレシーバーアボートはいつでもトリガーできますが、SCHCレシーバー - アボートのダウンリンクメッセージは、ダウンリンク送信の機会がある場合にのみ送信しなければなりません (MUST)。
Single-byte SCHC Header No-ACK mode MUST be used for transmitting short, non-critical packets that require fragmentation and do not require full reliability. This mode can be used by Uplink-only devices that do not support Downlink communications or by bidirectional devices when they send non-critical data. Note that sending non-critical data by using a reliable fragmentation mode (which is only possible for bidirectional devices) may incur unnecessary overhead.
シングルバイトのSCHCヘッダーを使うNo-ACKモードは、フラグメント化が必要で完全な信頼性を必要としない、短く重要度の低いパケットを送信するために使用しなければなりません (MUST)。このモードは、ダウンリンク通信をサポートしないアップリンク専用のデバイスや、重要度の低いデータを送信する際の双方向デバイスで使用できます。信頼性のあるフラグメント化モード（双方向デバイスでのみ可能）を使用して重要度の低いデータを送信すると、不要なオーバーヘッドが生じる場合があることに注意してください。
Since there are no multiple windows in the No-ACK mode, the W bit is not present. However, it MUST use the FCN field to indicate the size of the data packet. In this sense, the data packet would need to be split into X fragments and, similarly to the other fragmentation modes, the first transmitted fragment would need to be marked with FCN = X-1. Consecutive fragments MUST be marked with decreasing FCN values, having the last fragment marked with FCN = (All-1). Hence, even though the No-ACK mode does not allow recovering missing fragments, it allows implicitly indicating the size of the expected packet to the Network and hence detects whether all fragments have been received or not at the receiver side. In case the FCN field is not used to indicate the size of the data packet, the Network can detect whether all fragments have been received or not by using the integrity check.
NO-ACKモードに複数のウィンドウがないため、Wビットは存在しません。ただし、FCNフィールドを使用して、データパケットのサイズを示さなければなりません (MUST)。この意味で、データパケットはxフラグメントに分割する必要があり、他のフラグメンテーションモードと同様に、最初の送信フラグメントにFCN = x-1でマークする必要があります。連続したフラグメントは、FCN値の減少でマークしなければならず (MUST)、FCN =（ALL-1）で最後のフラグメントをマークします。したがって、NO-ackモードでは欠落したフラグメントの回復を許可していない場合でも、予想されるパケットのサイズを暗黙的に示すことができ、したがって、すべてのフラグメントが受信側で受信されたかどうかを検出します。FCNフィールドを使用してデータパケットのサイズを示すために使用されない場合、ネットワークは、整合性チェックを使用してすべてのフラグメントが受信されたかどうかを検出できます。
When using the Single-byte SCHC Header for Uplink fragmentation, the fragmentation header MUST be 8 bits in size and is composed as follows:
アップリンクのフラグメント化にシングルバイトのSCHCヘッダーを使用する場合、フラグメント化ヘッダーのサイズは8ビットでなければならず (MUST)、次のように構成されます。
* RuleID size: 3 bits
* Roolidサイズ：3ビット
* DTag size (T): 0 bits
* DTAGサイズ（T）：0ビット
* Fragment Compressed Number (FCN) size (N): 5 bits
* フラグメント圧縮数（fcn）サイズ（n）：5ビット
Other F/R parameters MUST be configured as follows:
他のF/Rパラメーターは、次のように構成しなければなりません (MUST)。
* As per [RFC8724], in the No-ACK mode, the W (window) field is not present.
* [RFC8724]によると、NO-ACKモードでは、W（ウィンドウ）フィールドは存在しません。
* Regular tile size: 11 bytes
* 通常のタイルサイズ：11バイト
* All-1 tile size: 0 to 10 bytes
* すべて1タイルサイズ：0〜10バイト
* Inactivity Timer: Application-dependent. The default value is 12 hours.
* 非アクティブタイマー：アプリケーション依存。デフォルト値は12時間です。
* RCS size: 5 bits
* RCSサイズ：5ビット
The maximum SCHC Packet size is 340 bytes.
最大SCHCパケットサイズは340バイトです。
Section 3.6.1 presents SCHC Fragment format examples, and Section 5.1 provides fragmentation examples, using Single-byte SCHC Header No-ACK mode.
セクション3.6.1は、SCHCフラグメント形式の例を示し、セクション5.1は、シングルバイトSCHCヘッダーNO-ACKモードを使用して、断片化の例を示しています。
ACK-on-Error with a single-byte header MUST be used for short- to medium-sized packets that need to be sent reliably. ACK-on-Error is optimal for reliable SCHC Packet transmission over Sigfox transmissions, since it leads to a reduced number of ACKs in the lower-capacity Downlink channel. Also, Downlink messages can be sent asynchronously and opportunistically. In contrast, ACK-Always would not minimize the number of ACKs, and No-ACK would not allow reliable transmission.
シングルバイトヘッダーを使うACK-on-Errorは、信頼性をもって送信する必要のある短〜中サイズのパケットに使用しなければなりません (MUST)。ACK-on-Errorは、容量の小さいダウンリンクチャネルでのACKの数を減らせるため、Sigfoxの伝送上で信頼性のあるSCHCパケットを伝送するのに最適です。また、ダウンリンクメッセージは非同期的かつ機会を見て送信できます。これに対し、ACK-AlwaysではACKの数を最小化できず、No-ACKでは信頼性のある伝送ができません。
Allowing transmission of packets/files up to 300 bytes long, the SCHC Uplink fragmentation header size is 8 bits in size and is composed as follows:
最大300バイトの長さのパケット/ファイルの送信を可能にするSCHCアップリンクフラグメンテーションヘッダーサイズのサイズは8ビットで、次のように構成されています。
* RuleID size: 3 bits
* Roolidサイズ：3ビット
* DTag size (T): 0 bits
* DTAGサイズ（T）：0ビット
* Window index (W) size (M): 2 bits
* ウィンドウインデックス（w）サイズ（m）：2ビット
* Fragment Compressed Number (FCN) size (N): 3 bits
* フラグメント圧縮数（fcn）サイズ（n）：3ビット
Other F/R parameters MUST be configured as follows:
他のF/Rパラメーターは、次のように構成しなければなりません (MUST)。
* MAX_ACK_REQUESTS: 5
* MAX_ACK_REQUESTS：5
* WINDOW_SIZE: 7 (i.e., the maximum FCN value is 0b110)
* WINDOW_SIZE：7（つまり、最大FCN値は0B110です）
* Regular tile size: 11 bytes
* 通常のタイルサイズ：11バイト
* All-1 tile size: 0 to 10 bytes
* すべて1タイルサイズ：0〜10バイト
* Retransmission Timer: Application-dependent. The default value is 12 hours.
* 再送信タイマー：アプリケーション依存。デフォルト値は12時間です。
* Inactivity Timer: Application-dependent. The default value is 12 hours.
* 非アクティブタイマー：アプリケーション依存。デフォルト値は12時間です。
* RCS size: 3 bits
* RCSサイズ：3ビット
Section 3.6.2 presents SCHC Fragment format examples, and Section 5.2 provides fragmentation examples, using ACK-on-Error with a single-byte header.
セクション3.6.2は、SCHCフラグメント形式の例を示し、セクション5.2は断片化の例を示し、ACKオンエラーをシングルバイトヘッダーで使用しています。
ACK-on-Error with a two-byte header MUST be used for medium- to large-sized packets that need to be sent reliably. ACK-on-Error is optimal for reliable SCHC Packet transmission over Sigfox, since it leads to a reduced number of ACKs in the lower-capacity Downlink channel. Also, Downlink messages can be sent asynchronously and opportunistically. In contrast, ACK-Always would not minimize the number of ACKs, and No-ACK would not allow reliable transmission.
2バイトヘッダーを使うACK-on-Errorは、信頼性をもって送信する必要のある中〜大サイズのパケットに使用しなければなりません (MUST)。ACK-on-Errorは、容量の小さいダウンリンクチャネルでのACKの数を減らせるため、Sigfox上で信頼性のあるSCHCパケットを伝送するのに最適です。また、ダウンリンクメッセージは非同期的かつ機会を見て送信できます。これに対し、ACK-AlwaysではACKの数を最小化できず、No-ACKでは信頼性のある伝送ができません。
In order to allow transmission of medium to large packets/files up to 480 bytes long, the SCHC Uplink fragmentation header size is 16 bits in size and is composed as follows:
最大480バイトの中程度のパケット/ファイルの送信を可能にするために、SCHCアップリンクフラグメンテーションヘッダーサイズのサイズは16ビットで、次のように構成されています。
* RuleID size: 6 bits
* Roolidサイズ：6ビット
* DTag size (T): 0 bits
* DTAGサイズ（T）：0ビット
* Window index (W) size (M): 2 bits
* ウィンドウインデックス（w）サイズ（m）：2ビット
* Fragment Compressed Number (FCN) size (N): 4 bits
* フラグメント圧縮数（fcn）サイズ（n）：4ビット
* RCS size: 4 bits
* RCSサイズ：4ビット
Other F/R parameters MUST be configured as follows:
他のF/Rパラメーターは、次のように構成しなければなりません (MUST)。
* MAX_ACK_REQUESTS: 5
* MAX_ACK_REQUESTS：5
* WINDOW_SIZE: 12 (with a maximum value of FCN=0b1011)
* WINDOW_SIZE：12（最大値FCN=0b1011）
* Regular tile size: 10 bytes
* 通常のタイルサイズ：10バイト
* All-1 tile size: 1 to 10 bytes
* すべて1タイルサイズ：1〜10バイト
* Retransmission Timer: Application-dependent. The default value is 12 hours.
* 再送信タイマー：アプリケーション依存。デフォルト値は12時間です。
* Inactivity Timer: Application-dependent. The default value is 12 hours.
* 非アクティブタイマー：アプリケーション依存。デフォルト値は12時間です。
Note that WINDOW_SIZE is limited to 12. This is because 4 windows (M = 2) with bitmaps of size 12 can be fitted in a single SCHC Compound ACK.
WINDOW_SIZEは12に制限されていることに注意してください。これは、サイズ12のビットマップがある4つのWindows（m = 2）が単一のSCHC化合物ACKに取り付けられるためです。
Section 3.6.3 presents SCHC Fragment format examples, using ACK-on-Error with two-byte header Option 1.
セクション3.6.3は、2バイトヘッダーオプション1を使用してACKオンエラーを使用して、SCHCフラグメント形式の例を示します。
In order to allow transmission of very large packets/files up to 2400 bytes long, the SCHC Uplink fragmentation header size is 16 bits in size and is composed as follows:
最大2400バイトの非常に大きなパケット/ファイルの送信を可能にするために、SCHCアップリンクフラグメンテーションヘッダーサイズのサイズは16ビットで、次のように構成されています。
* RuleID size: 8 bits
* Roolidサイズ：8ビット
* DTag size (T): 0 bits
* DTAGサイズ（T）：0ビット
* Window index (W) size (M): 3 bits
* ウィンドウインデックス（w）サイズ（m）：3ビット
* Fragment Compressed Number (FCN) size (N): 5 bits
* フラグメント圧縮数（fcn）サイズ（n）：5ビット
* RCS size: 5 bits
* RCSサイズ：5ビット
Other F/R parameters MUST be configured as follows:
他のF/Rパラメーターは、次のように構成しなければなりません (MUST)。
* MAX_ACK_REQUESTS: 5
* MAX_ACK_REQUESTS：5
* WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)
* WINDOW_SIZE：31（最大値FCN=0b11110）
* Regular tile size: 10 bytes
* 通常のタイルサイズ：10バイト
* All-1 tile size: 0 to 9 bytes
* すべて1タイルサイズ：0〜9バイト
* Retransmission Timer: Application-dependent. The default value is 12 hours.
* 再送信タイマー：アプリケーション依存。デフォルト値は12時間です。
* Inactivity Timer: Application-dependent. The default value is 12 hours.
* 非アクティブタイマー：アプリケーション依存。デフォルト値は12時間です。
Section 3.6.4 presents SCHC Fragment format examples, using ACK-on-Error with two-byte header Option 2.
セクション3.6.4は、2バイトヘッダーオプション2を使用してACKオンエラーを使用して、SCHCフラグメント形式の例を示します。
For ACK-on-Error, as defined in [RFC8724], it is expected that the last SCHC Fragment of the last window will always be delivered with an All-1 FCN. Since this last window may not be full (i.e., it may be composed of fewer than WINDOW_SIZE fragments), an All-1 fragment may follow a value of FCN higher than 1 (0b01). In this case, the receiver cannot determine from the FCN values alone whether there are or are not any missing fragments right before the All-1 fragment.
[RFC8724]で定義されているACKオンエラーの場合、最後のウィンドウの最後のSCHCフラグメントは常にALL-1 FCNで配信されると予想されます。この最後のウィンドウがいっぱいではない可能性があるため（つまり、WINDOW_SIZEフラグメントよりも少ない可能性があります）、All-1フラグメントは1（0b01）を超えるFCNの値に従う場合があります。この場合、受信機は、All-1フラグメントの直前に欠落しているフラグメントがあるかどうかだけであるかどうかだけであるFCN値だけから決定できません。
For Rules where the number of fragments in the last window is unknown, an RCS field MUST be used, indicating the number of fragments in the last window, including the All-1. With this RCS value, the receiver can detect if there are missing fragments before the All-1 and hence construct the corresponding SCHC ACK Bitmap accordingly and send it in response to the All-1.
最後のウィンドウのフラグメントの数が不明なルールの場合、RCSフィールドを使用しなければなりません (MUST)。これは、ALL-1を含む最後のウィンドウのフラグメントの数を示します。このRCS値を使用すると、受信機はAll-1の前に断片が欠落しているかどうかを検出し、それに応じて対応するSCHC ACKビットマップを構築し、ALL-1に応答して送信します。
In some LPWAN technologies, as part of energy-saving techniques, Downlink transmission is only possible immediately after an Uplink transmission. This allows the device to go in a very deep sleep mode and preserve battery without the need to listen to any information from the Network. This is the case for Sigfox-enabled devices, which can only listen to Downlink communications after performing an Uplink transmission and requesting a Downlink.
一部のLPWANテクノロジーでは、省エネのテクニックの一部として、ダウンリンク伝送はアップリンク送信の直後にのみ可能です。これにより、デバイスは非常に深い睡眠モードで移動し、ネットワークから情報を聞く必要なくバッテリーを保存できます。これは、Sigfox対応デバイスの場合です。これは、アップリンク送信を実行してダウンリンクを要求した後にのみダウンリンク通信を聞くことができます。
When there are fragments to be transmitted in the Downlink, an Uplink message is required to trigger the Downlink communication. In order to avoid a potentially high delay for fragmented datagram transmission in the Downlink, the fragment receiver MAY perform an Uplink transmission as soon as possible after reception of a Downlink fragment that is not the last one. Such an Uplink transmission MAY be triggered by sending a SCHC message, such as a SCHC ACK. However, other data messages can equally be used to trigger Downlink communications. The fragment receiver MUST send an Uplink transmission (e.g., empty message) and request a Downlink every 24 hours when no SCHC session is started. Whether this Uplink transmission is used (and the transmission rate, if used) depends on application-specific requirements.
ダウンリンクに断片が送信される場合、ダウンリンク通信をトリガーするためにアップリンクメッセージが必要です。ダウンリンクでの断片化されたデータグラム伝送の潜在的に高い遅延を回避するために、フラグメントレシーバーは、最後のものではないダウンリンクフラグメントを受信した後、できるだけ早くアップリンク送信を実行できます。このようなアップリンク送信は、SCHC ACKなどのSCHCメッセージを送信することによりトリガーされる場合があります。ただし、他のデータメッセージを使用して、ダウンリンク通信をトリガーすることができます。フラグメントレシーバーは、アップリンク送信（空のメッセージなど）を送信し、SCHCセッションが開始されない24時間ごとにダウンリンクを要求する必要があります。このアップリンク送信が使用されるかどうか（および使用する場合）は、アプリケーション固有の要件に依存します。
Sigfox Downlink messages are fixed in size, and as described in [RFC8376] they can carry a payload of 0-8 bytes (0-64 bits). Hence, a single SCHC Tile size per mode can be defined so that every Sigfox message always carries one SCHC Tile.
Sigfoxのダウンリンクメッセージのサイズは固定されており、[RFC8376]で説明されているように、0〜8バイト（0〜64ビット）のペイロードを搭載できます。したがって、モードごとに単一のSCHCタイルサイズを定義できるため、すべてのSIGFOXメッセージには常に1つのSCHCタイルが搭載されます。
For reliable Downlink fragment transmission, the ACK-Always mode SHOULD be used. Note that ACK-on-Error does not guarantee Uplink feedback (since no SCHC ACK will be sent when no errors occur in a window), and No-ACK would not allow reliable transmission.
信頼性の高いダウンリンクフラグメントトランスミッションには、ACK-alwaysモードを使用すべきです (SHOULD)。ACKオンエラーは、アップリンクフィードバックを保証しないことに注意してください（ウィンドウにエラーが発生しない場合はSCHC ACKが送信されないため）。
The SCHC Downlink fragmentation header size is 8 bits in size and is composed as follows:
SCHCダウンリンクフラグメンテーションヘッダーサイズのサイズは8ビットで、次のように構成されています。
* RuleID size: 3 bits
* Roolidサイズ：3ビット
* DTag size (T): 0 bits
* DTAGサイズ（T）：0ビット
* Window index (W) size (M): 0 bits
* ウィンドウインデックス（w）サイズ（m）：0ビット
* Fragment Compressed Number (FCN) size (N): 5 bits
* フラグメント圧縮数（fcn）サイズ（n）：5ビット
Other F/R parameters MUST be configured as follows:
他のF/Rパラメーターは、次のように構成しなければなりません (MUST)。
* MAX_ACK_REQUESTS: 5
* MAX_ACK_REQUESTS：5
* WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)
* WINDOW_SIZE：31（最大値FCN=0b11110）
* Regular tile size: 7 bytes
* 通常のタイルサイズ：7バイト
* All-1 tile size: 0 to 6 bytes
* すべて1タイルサイズ：0〜6バイト
* Retransmission Timer: Application-dependent. The default value is 12 hours.
* 再送信タイマー：アプリケーション依存。デフォルト値は12時間です。
* Inactivity Timer: Application-dependent. The default value is 12 hours.
* 非アクティブタイマー：アプリケーション依存。デフォルト値は12時間です。
* RCS size: 5 bits
* RCSサイズ：5ビット
This section depicts the different formats of SCHC Fragment, SCHC ACK (including the SCHC Compound ACK defined in [RFC9441]), and SCHC Abort used in SCHC over Sigfox.
このセクションでは、SCHCフラグメントのさまざまな形式、SCHC ACK（[RFC9441]で定義されているSCHC化合物ACKを含む）、およびSCHCでSIGFOXを介して使用されるSCHC Abortを示しています。
Figure 3 shows an example of a Regular SCHC Fragment for all fragments except the last one. As tiles are 11 bytes in size, padding MUST NOT be added. The penultimate tile of a SCHC Packet is of regular size.
図3は、最後のフラグメントを除くすべてのフラグメントの通常のSCHCフラグメントの例を示しています。タイルのサイズは11バイトなので、パディングを追加してはなりません (MUST NOT)。SCHCパケットの最後から2番目のタイルは通常のサイズです。
|- SCHC Fragment Header -|
+------------------------+---------+
| RuleID | FCN | Payload |
+------------+-----------+---------+
| 3 bits | 5 bits | 88 bits |
Figure 3: Regular SCHC Fragment Format for All Fragments except the Last One
図3：最後のフラグメントを除くすべてのフラグメントの通常のSCHCフラグメント形式
Figure 4 shows an example of the All-1 message. The All-1 message MAY contain the last tile of the SCHC Packet. Padding MUST NOT be added, as the resulting size is a multiple of an L2 Word.
図4は、ALL-1メッセージの例を示しています。All-1メッセージには、SCHCパケットの最後のタイルが含まれている場合があります (MAY)。結果のサイズはL2ワードの倍数であるため、パディングを追加してはなりません (MUST NOT)。
The All-1 messages Fragment Header includes a 5-bit RCS, and 3 bits are added as padding to complete 2 bytes. The payload size of the All-1 message ranges from 0 to 80 bits.
All-1メッセージフラグメントヘッダーには5ビットRCSが含まれており、3ビットが2バイトを完成するためのパディングとして追加されています。ALL-1メッセージのペイロードサイズの範囲は0〜80ビットです。
|-------- SCHC Fragment Header -------|
+--------------------------------------+--------------+
| RuleID | FCN=ALL-1 | RCS | b'000 | Payload |
+--------+-----------+--------+--------+--------------+
| 3 bits | 5 bits | 5 bits | 3 bits | 0 to 80 bits |
Figure 4: All-1 SCHC Message Format with the Last Tile
図4：最後のタイルを備えたAll-1 SCHCメッセージフォーマット
As per [RFC8724], the All-1 must be distinguishable from a SCHC Sender-Abort message (with the same RuleID and N values). The All-1 MAY have the last tile of the SCHC Packet. The SCHC Sender-Abort message header size is 1 byte with no padding bits.
[RFC8724]によると、ALL-1はSCHC Sender-Abortメッセージ（同じRuleIDおよびN値を使用）と区別できる必要があります。All-1には、SCHCパケットの最後のタイルがあります。SCHC Sender-Abortメッセージヘッダーサイズは、パディングビットのない1バイトです。
For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST be 1 byte (only header with no padding). This way, the minimum size of the All-1 is 2 bytes, and the Sender-Abort message is 1 byte.
ALL-1メッセージが送信者とアボートのメッセージと区別できる場合、送信者アボートメッセージは1バイト（パディングのないヘッダーのみ）でなければなりません (MUST)。これにより、All-1の最小サイズは2バイトで、送信者アボートメッセージは1バイトです。
Sender-Abort
|------ Header ------|
+--------------------+
| RuleID | FCN=ALL-1 |
+--------+-----------+
| 3 bits | 5 bits |
Figure 5: SCHC Sender-Abort Message Format
図5：SCHC Sender-Abortメッセージフォーマット
Figure 6 shows an example of a Regular SCHC Fragment for all fragments except the last one. As tiles are 11 bytes in size, padding MUST NOT be added.
図6は、最後の断片を除くすべてのフラグメントの通常のSCHCフラグメントの例を示しています。タイルのサイズは11バイトなので、パディングを追加してはなりません (MUST NOT)。
|-- SCHC Fragment Header --|
+--------------------------+---------+
| RuleID | W | FCN | Payload |
+--------+--------+--------+---------+
| 3 bits | 2 bits | 3 bits | 88 bits |
Figure 6: Regular SCHC Fragment Format for All Fragments except the Last One
図6：最後のフラグメントを除くすべてのフラグメントの通常のSCHCフラグメント形式
The SCHC ACK REQ MUST NOT be used, instead the All-1 SCHC Fragment MUST be used to request a SCHC ACK from the receiver (Network SCHC). As per [RFC8724], the All-0 message is distinguishable from the SCHC ACK REQ (All-1 message). The penultimate tile of a SCHC Packet is of regular size.
SCHC ACK REQを使用してはなりません。代わりに、ALL-1 SCHCフラグメントを使用して、受信機（ネットワークSCHC）からSCHC ACKを要求する必要があります。[RFC8724]によると、ALL-0メッセージはSCHC ACK Req（ALL-1メッセージ）と区別できます。SCHCパケットの最後から2番目のタイルは通常のサイズです。
Figure 7 shows an example of the All-1 message. The All-1 message MAY contain the last tile of the SCHC Packet. Padding MUST NOT be added, as the resulting size is L2-word-multiple.
図7は、All-1メッセージの例を示しています。All-1メッセージには、SCHCパケットの最後のタイルが含まれている場合があります (MAY)。結果のサイズはL2ワードマルチプルであるため、パディングを追加してはなりません (MUST NOT)。
|------------- SCHC Fragment Header -----------|
+-----------------------------------------------+--------------+
| RuleID | W | FCN=ALL-1 | RCS |b'00000 | Payload |
+--------+--------+-----------+--------+--------+--------------+
| 3 bits | 2 bits | 3 bits | 3 bits | 5 bits | 0 to 80 bits |
Figure 7: All-1 SCHC Message Format with the Last Tile
図7：最後のタイルを備えたAll-1 SCHCメッセージフォーマット
As per [RFC8724], the All-1 must be distinguishable from a SCHC Sender-Abort message (with same RuleID, M, and N values). The All-1 MAY have the last tile of the SCHC Packet. The SCHC Sender-Abort message header size is 1 byte with no padding bits.
[RFC8724]によると、ALL-1はSCHC Sender-Abortメッセージ（同じRuleID、M、およびN値を使用）と区別できる必要があります。All-1には、SCHCパケットの最後のタイルがあります。SCHC Sender-Abortメッセージヘッダーサイズは、パディングビットのない1バイトです。
For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST be 1 byte (only header with no padding). This way, the minimum size of the All-1 is 2 bytes, and the Sender-Abort message is 1 byte.
ALL-1メッセージが送信者とアボートのメッセージと区別できる場合、送信者アボートメッセージは1バイト（パディングのないヘッダーのみ）でなければなりません (MUST)。これにより、All-1の最小サイズは2バイトで、送信者アボートメッセージは1バイトです。
Figure 8 shows the SCHC ACK format when all fragments have been correctly received (C=1). Padding MUST be added to complete the 64-bit Sigfox Downlink frame payload size.
図8は、すべてのフラグメントが正しく受信されたときのSCHC ACK形式を示しています（C=1）。パディングを追加して、64ビットのSigfoxダウンリンクフレームペイロードサイズを完成させなければなりません (MUST)。
|---- SCHC ACK Header ----|
+-------------------------+---------+
| RuleID | W | C=b'1 | b'0-pad |
+--------+--------+-------+---------+
| 3 bits | 2 bits | 1 bit | 58 bits |
Figure 8: SCHC Success ACK Message Format
図8：SCHC成功ACKメッセージ形式
In case SCHC Fragment losses are found in any of the windows of the SCHC Packet (C=0), the SCHC Compound ACK defined in [RFC9441] MUST be used. The SCHC Compound ACK message format is shown in Figure 9.
SCHCフラグメントの損失がSCHCパケットの任意のウィンドウ（C=0）に見られる場合、[RFC9441]で定義されているSCHC化合物ACKを使用しなければなりません (MUST)。SCHC化合物ACKメッセージ形式を図9に示します。
|--- SCHC ACK Header ---|- W=w1 -|...|----- W=wi ------|
+------+--------+-------+--------+...+--------+--------+------+-------+
|RuleID| W=b'w1 | C=b'0 | Bitmap |...| W=b'wi | Bitmap | b'00 |b'0-pad|
+------+--------+-------+--------+...+--------+--------+------+-------+
|3 bits| 2 bits | 1 bit | 7 bits |...| 2 bits | 7 bits |2 bits|
Figure 9: SCHC Compound ACK Message Format
図9：SCHCコンパウンドACKメッセージ形式
Losses are found in windows W = w1,...,wi, where w1 < w2 <...< wi.
損失はWindows w = w1、...、wi、w1 <w2 <... <wiで見つかります。
|---- Sender-Abort Header ----|
+-----------------------------+
| RuleID | W=b'11 | FCN=ALL-1 |
+--------+--------+-----------+
| 3 bits | 2 bits | 3 bits |
Figure 10: SCHC Sender-Abort Message Format
図10：SCHC Sender-Abortメッセージフォーマット
|- Receiver-Abort Header -|
+---------------------------------+-----------------+---------+
| RuleID | W=b'11 | C=b'1 | b'11 | 0xFF (all 1's) | b'0-pad |
+--------+--------+-------+-------+-----------------+---------+
| 3 bits | 2 bits | 1 bit | 2 bit | 8 bit | 48 bits |
next L2 Word boundary ->| <-- L2 Word --> |
Figure 11: SCHC Receiver-Abort Message Format
図11：SCHC Receiver-Abortメッセージフォーマット
Figure 12 shows an example of a Regular SCHC Fragment for all fragments except the last one. The penultimate tile of a SCHC Packet is of the regular size.
図12は、最後の断片を除くすべてのフラグメントの通常のSCHCフラグメントの例を示しています。SCHCパケットの最後から2番目のタイルは、通常のサイズです。
|------- SCHC Fragment Header ------|
+-----------------------------------+---------+
| RuleID | W | FCN | b'0000 | Payload |
+--------+--------+--------+--------+---------+
| 6 bits | 2 bits | 4 bits | 4 bits | 80 bits |
Figure 12: Regular SCHC Fragment Format for All Fragments except the Last One
図12：最後のフラグメントを除くすべてのフラグメントの通常のSCHCフラグメント形式
The SCHC ACK REQ MUST NOT be used, instead the All-1 SCHC Fragment MUST be used to request a SCHC ACK from the receiver (Network SCHC). As per [RFC8724], the All-0 message is distinguishable from the SCHC ACK REQ (All-1 message).
SCHC ACK REQを使用してはなりません。代わりに、ALL-1 SCHCフラグメントを使用して、受信機（ネットワークSCHC）からSCHC ACKを要求する必要があります。[RFC8724]によると、ALL-0メッセージはSCHC ACK Req（ALL-1メッセージ）と区別できます。
Figure 13 shows an example of the All-1 message. The All-1 message MUST contain the last tile of the SCHC Packet.
図13は、ALL-1メッセージの例を示しています。ALL-1メッセージには、SCHCパケットの最後のタイルを含めなければなりません (MUST)。
The All-1 message Fragment Header contains an RCS of 4 bits to complete the two-byte size. The size of the last tile ranges from 8 to 80 bits.
ALL-1メッセージフラグメントヘッダーには、2バイトサイズを完了するために4ビットのRCSが含まれています。最後のタイルのサイズは8〜80ビットの範囲です。
|--------- SCHC Fragment Header -------|
+--------------------------------------+--------------+
| RuleID | W | FCN=ALL-1 | RCS | Payload |
+--------+--------+-----------+--------+--------------+
| 6 bits | 2 bits | 4 bits | 4 bits | 8 to 80 bits |
Figure 13: All-1 SCHC Message Format with the Last Tile
図13：最後のタイルを備えたAll-1 SCHCメッセージフォーマット
As per [RFC8724], the All-1 must be distinguishable from the SCHC Sender-Abort message (with same RuleID, M, and N values). The All-1 MUST have the last tile of the SCHC Packet that MUST be at least 1 byte. The SCHC Sender-Abort message header size is 2 bytes with no padding bits.
[RFC8724]によると、ALL-1はSCHC Sender-Abortメッセージ（同じRuleID、M、およびN値を使用）と区別できる必要があります。ALL-1には、少なくとも1バイトでなければならないSCHCパケットの最後のタイルが必要です。SCHC Sender-Abortメッセージヘッダーサイズは、パディングビットのない2バイトです。
For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST be 2 bytes (only header with no padding). This way, the minimum size of the All-1 is 3 bytes, and the Sender-Abort message is 2 bytes.
All-1メッセージが送信者とアボートのメッセージと区別できるためには、送信者アボートメッセージは2バイトでなければなりません (MUST)（パディングのないヘッダーのみ）。これにより、All-1の最小サイズは3バイトで、送信者アボートメッセージは2バイトです。
Figure 14 shows the SCHC ACK format when all fragments have been correctly received (C=1). Padding MUST be added to complete the 64-bit Sigfox Downlink frame payload size.
図14は、すべてのフラグメントが正しく受信されたときのSCHC ACK形式を示しています（C=1）。パディングを追加して、64ビットのSigfoxダウンリンクフレームペイロードサイズを完成させなければなりません (MUST)。
|---- SCHC ACK Header ----|
+-------------------------+---------+
| RuleID | W | C=b'1 | b'0-pad |
+--------+--------+-------+---------+
| 6 bits | 2 bits | 1 bit | 55 bits |
Figure 14: SCHC Success ACK Message Format
図14：SCHC成功ACKメッセージ形式
The SCHC Compound ACK message MUST be used in case SCHC Fragment losses are found in any window of the SCHC Packet (C=0). The SCHC Compound ACK message format is shown in Figure 15. The SCHC Compound ACK can report up to 4 windows with losses, as shown in Figure 16.
SCHCフラグメント損失がSCHCパケットの任意のウィンドウ（C=0）に見られる場合、SCHC化合物ACKメッセージを使用しなければなりません (MUST)。SCHC化合物ACKメッセージ形式を図15に示します。SCHC化合物ACKは、図16に示すように、損失を伴う最大4つのウィンドウを報告できます。
When sent in the Downlink, the SCHC Compound ACK MUST be 0 padded (padding bits must be 0) to complement the 64 bits required by the Sigfox payload.
ダウンリンクで送信すると、SCHC化合物ACKは0パッドで必要です（パディングビットは0でなければなりません）。
|--- SCHC ACK Header ---|- W=w1 -|...|---- W=wi -----|
+--------+------+-------+--------+...+------+--------+------+-------+
| RuleID |W=b'w1| C=b'0 | Bitmap |...|W=b'wi| Bitmap | b'00 |b'0-pad|
+--------+------+-------+--------+...+------+--------+------+-------+
| 6 bits |2 bits| 1 bit | 12 bits|...|2 bits| 12 bits|2 bits|
Figure 15: SCHC Compound ACK Message Format
図15：SCHCコンパウンドACKメッセージ形式
Losses are found in windows W = w1,...,wi, where w1 < w2 <...< wi.
損失はWindows w = w1、...、wi、w1 <w2 <... <wiで見つかります。
|- SCHC ACK Header -|- W=0 -| |- W=1 -|...
+------+------+-----+-------+------+-------+...
|RuleID|W=b'00|C=b'0|Bitmap |W=b'01|Bitmap |...
+------+------+-----+-------+------+-------+...
|6 bits|2 bits|1 bit|12 bits|2 bits|12 bits|...
... |- W=2 -| |- W=3 -|
...+------+-------+------+-------+---+
...|W=b'10|Bitmap |W=b'11|Bitmap |b'0|
...+------+-------+------+-------+---+
...|2 bits|12 bits|2 bits|12 bits|
Figure 16: SCHC Compound ACK Message Format Example with Losses in All Windows
図16：すべてのウィンドウに損失があるSCHCコンパウンドACKメッセージフォーマットの例
Losses are found in windows W = w1,...,wi, where w1 < w2 <...< wi.
損失はWindows w = w1、...、wi、w1 <w2 <... <wiで見つかります。
|---- Sender-Abort Header ----|
+-----------------------------+
| RuleID | W | FCN=ALL-1 |
+--------+--------+-----------+
| 6 bits | 2 bits | 4 bits |
Figure 17: SCHC Sender-Abort Message Format
図17：SCHC Sender-Abortメッセージフォーマット
|- Receiver-Abort Header -|
+---------------------------------+-----------------+---------+
| RuleID | W=b'11 | C=b'1 | 0x7F | 0xFF (all 1's) | b'0-pad |
+--------+--------+-------+-------+-----------------+---------+
| 6 bits | 2 bits | 1 bit | 7 bit | 8 bit | 40 bits |
next L2 Word boundary ->| <-- L2 Word --> |
Figure 18: SCHC Receiver-Abort Message Format
図18：SCHC Receiver-Abortメッセージフォーマット
Figure 19 shows an example of a Regular SCHC Fragment for all fragments except the last one. The penultimate tile of a SCHC Packet is of the regular size.
図19は、最後の断片を除くすべてのフラグメントの通常のSCHCフラグメントの例を示しています。SCHCパケットの最後から2番目のタイルは、通常のサイズです。
|-- SCHC Fragment Header --|
+--------------------------+---------+
| RuleID | W | FCN | Payload |
+--------+--------+--------+---------+
| 8 bits | 3 bits | 5 bits | 80 bits |
Figure 19: Regular SCHC Fragment Format for All Fragments except the Last One
図19：最後のフラグメントを除くすべてのフラグメントの通常のSCHCフラグメント形式
The SCHC ACK REQ MUST NOT be used, instead the All-1 SCHC Fragment MUST be used to request a SCHC ACK from the receiver (Network SCHC). As per [RFC8724], the All-0 message is distinguishable from the SCHC ACK REQ (All-1 message).
SCHC ACK REQを使用してはなりません。代わりに、ALL-1 SCHCフラグメントを使用して、受信機（ネットワークSCHC）からSCHC ACKを要求する必要があります。[RFC8724]によると、ALL-0メッセージはSCHC ACK Req（ALL-1メッセージ）と区別できます。
Figure 20 shows an example of the All-1 message. The All-1 message MAY contain the last tile of the SCHC Packet.
図20は、ALL-1メッセージの例を示しています。All-1メッセージには、SCHCパケットの最後のタイルが含まれている場合があります (MAY)。
The All-1 message Fragment Header contains an RCS of 5 bits and 3 padding bits to complete a 3-byte Fragment Header. The size of the last tile, if present, ranges from 8 to 72 bits.
All-1メッセージフラグメントヘッダーには、3バイトのフラグメントヘッダーを完成させるために、5ビットと3つのパディングビットのRCが含まれています。最後のタイルのサイズは、存在する場合、8〜72ビットの範囲です。
|-------------- SCHC Fragment Header -----------|
+-----------------------------------------------+--------------+
| RuleID | W | FCN=ALL-1 | RCS | b'000 | Payload |
+--------+--------+-----------+--------+--------+--------------+
| 8 bits | 3 bits | 5 bits | 5 bits | 3 bits | 8 to 72 bits |
Figure 20: All-1 SCHC Message Format with the Last Tile
図20：最後のタイルを備えたAll-1 SCHCメッセージフォーマット
As per [RFC8724], the All-1 must be distinguishable from the SCHC Sender-Abort message (with same RuleID, M, and N values). The SCHC Sender-Abort message header size is 2 bytes with no padding bits.
[RFC8724]によると、ALL-1はSCHC Sender-Abortメッセージ（同じRuleID、M、およびN値を使用）と区別できる必要があります。SCHC Sender-Abortメッセージヘッダーサイズは、パディングビットのない2バイトです。
For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST be 2 bytes (only header with no padding). This way, the minimum size of the All-1 is 3 bytes, and the Sender-Abort message is 2 bytes.
All-1メッセージが送信者とアボートのメッセージと区別できるためには、送信者アボートメッセージは2バイトでなければなりません (MUST)（パディングのないヘッダーのみ）。これにより、All-1の最小サイズは3バイトで、送信者アボートメッセージは2バイトです。
Figure 21 shows the SCHC ACK format when all fragments have been correctly received (C=1). Padding MUST be added to complete the 64-bit Sigfox Downlink frame payload size.
図21は、すべてのフラグメントが正しく受信されたときのSCHC ACK形式を示しています（C=1）。パディングを追加して、64ビットのSigfoxダウンリンクフレームペイロードサイズを完成させなければなりません (MUST)。
|---- SCHC ACK Header ----|
+-------------------------+---------+
| RuleID | W | C=b'1 | b'0-pad |
+--------+--------+-------+---------+
| 8 bits | 3 bits | 1 bit | 52 bits |
Figure 21: SCHC Success ACK Message Format
図21：SCHC成功ACKメッセージ形式
The SCHC Compound ACK message MUST be used in case SCHC Fragment losses are found in any window of the SCHC Packet (C=0). The SCHC Compound ACK message format is shown in Figure 22. The SCHC Compound ACK can report up to 3 windows with losses.
SCHCフラグメント損失がSCHCパケットの任意のウィンドウ（C=0）に見られる場合、SCHC化合物ACKメッセージを使用しなければなりません (MUST)。SCHC化合物ACKメッセージ形式を図22に示します。SCHC化合物ACKは、損失を伴う最大3つのウィンドウを報告できます。
When sent in the Downlink, the SCHC Compound ACK MUST be 0 padded (padding bits must be 0) to complement the 64 bits required by the Sigfox payload.
ダウンリンクで送信すると、SCHC化合物ACKは0パッドで必要です（パディングビットは0でなければなりません）。
|-- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----|
+------+------+-------+--------+...+------+--------+------+-------+
|RuleID|W=b'w1| C=b'0 | Bitmap |...|W=b'wi| Bitmap | 000 |b'0-pad|
+------+------+-------+--------+...+------+--------+------+-------+
|8 bits|3 bits| 1 bit | 31 bits|...|3 bits| 31 bits|3 bits|
Figure 22: SCHC Compound ACK Message Format
図22：SCHCコンパウンドACKメッセージ形式
Losses are found in windows W = w1,...,wi, where w1 < w2 <...< wi.
損失はWindows w = w1、...、wi、w1 <w2 <... <wiで見つかります。
|---- Sender-Abort Header ----|
+-----------------------------+
| RuleID | W | FCN=ALL-1 |
+--------+--------+-----------+
| 8 bits | 3 bits | 5 bits |
Figure 23: SCHC Sender-Abort Message Format
図23：SCHC Sender-Abortメッセージフォーマット
|-- Receiver-Abort Header -|
+-----------------------------------+-----------------+---------+
| RuleID | W=b'111 | C=b'1 | b'1111 | 0xFF (all 1's) | b'0-pad |
+--------+---------+-------+--------+-----------------+---------+
| 8 bits | 3 bits | 1 bit | 4 bit | 8 bit | 40 bits |
next L2 Word boundary ->| <-- L2 Word --> |
Figure 24: SCHC Receiver-Abort Message Format
図24：SCHC Receiver-Abortメッセージフォーマット
Figure 25 shows an example of a Regular SCHC Fragment for all fragments except the last one. The penultimate tile of a SCHC Packet is of the regular size.
図25は、最後のフラグメントを除くすべてのフラグメントの通常のSCHCフラグメントの例を示しています。SCHCパケットの最後から2番目のタイルは、通常のサイズです。
SCHC Fragment
|-- Header --|
+-----------------+---------+
| RuleID | FCN | Payload |
+--------+--------+---------+
| 3 bits | 5 bits | 56 bits |
Figure 25: Regular SCHC Fragment Format for All Fragments except the Last One
図25：最後のフラグメントを除くすべてのフラグメントの通常のSCHCフラグメント形式
The SCHC ACK MUST NOT be used, instead the All-1 SCHC Fragment MUST be used to request a SCHC ACK from the receiver. As per [RFC8724], the All-0 message is distinguishable from the SCHC ACK REQ (All-1 message).
SCHC ACKを使用してはなりません。代わりに、ALL-1 SCHCフラグメントを使用して、受信機からSCHC ACKを要求する必要があります。[RFC8724]によると、ALL-0メッセージはSCHC ACK Req（ALL-1メッセージ）と区別できます。
Figure 26 shows an example of the All-1 message. The All-1 message MAY contain the last tile of the SCHC Packet.
図26は、ALL-1メッセージの例を示しています。All-1メッセージには、SCHCパケットの最後のタイルが含まれている場合があります (MAY)。
The All-1 message Fragment Header contains an RCS of 5 bits and 3 padding bits to complete a 2-byte Fragment Header. The size of the last tile, if present, ranges from 8 to 48 bits.
All-1メッセージフラグメントヘッダーには、2バイトフラグメントヘッダーを完成させるために、5ビットのRCと3つのパディングビットが含まれています。最後のタイルのサイズは、存在する場合、8〜48ビットの範囲です。
|--------- SCHC Fragment Header -------|
+--------------------------------------+--------------+
| RuleID | FCN=ALL-1 | RCS | b'000 | Payload |
+--------+-----------+--------+--------+--------------+
| 3 bits | 5 bits | 5 bits | 3 bits | 0 to 48 bits |
Figure 26: All-1 SCHC Message Format with the Last Tile
図26：最後のタイルを備えたAll-1 SCHCメッセージフォーマット
As per [RFC8724], the All-1 must be distinguishable from the SCHC Sender-Abort message (with same RuleID and N values). The SCHC Sender-Abort message header size is 1 byte with no padding bits.
[RFC8724]によると、ALL-1はSCHC Sender-Abortメッセージ（同じRuleIDおよびN値を使用）と区別できる必要があります。SCHC Sender-Abortメッセージヘッダーサイズは、パディングビットのない1バイトです。
For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST be 1 byte (only header with no padding). This way, the minimum size of the All-1 is 2 bytes, and the Sender-Abort message is 1 bytes.
ALL-1メッセージが送信者とアボートのメッセージと区別できる場合、送信者アボートメッセージは1バイト（パディングのないヘッダーのみ）でなければなりません (MUST)。これにより、All-1の最小サイズは2バイトで、送信者アボートメッセージは1バイトです。
Figure 27 shows the SCHC ACK format when all fragments have been correctly received (C=1). Padding MUST be added to complete 2 bytes.
図27は、すべてのフラグメントが正しく受信されたときのSCHC ACK形式を示しています（C=1）。パディングを追加するには、2バイトを完全に追加しなければなりません (MUST)。
SCHC ACK
|-- Header --|
+----------------+---------+
| RuleID | C=b'1 | b'0-pad |
+--------+-------+---------+
| 3 bits | 1 bit | 4 bits |
Figure 27: SCHC Success ACK Message Format
図27：SCHC成功ACKメッセージ形式
The SCHC ACK message format is shown in Figure 28.
SCHC ACKメッセージ形式を図28に示します。
|---- SCHC ACK Header ----|
+--------+-------+--------+---------+
| RuleID | C=b'0 | Bitmap | b'0-pad |
+--------+-------+--------+---------+
| 3 bits | 1 bit | 31 bits| 5 bits |
Figure 28: SCHC Compound ACK Message Format
図28：SCHCコンパウンドACKメッセージ形式
Sender-Abort
|---- Header ----|
+--------------------+
| RuleID | FCN=ALL-1 |
+--------+-----------+
| 3 bits | 5 bits |
Figure 29: SCHC Sender-Abort Message Format
図29：SCHC Sender-Abortメッセージ形式
Receiver-Abort
|--- Header ---|
+----------------+--------+-----------------+
| RuleID | C=b'1 | b'1111 | 0xFF (all 1's) |
+--------+-------+--------+-----------------+
| 3 bits | 1 bit | 4 bit | 8 bit |
Figure 30: SCHC Receiver-Abort Message Format
図30：SCHC Receiver-Abortメッセージフォーマット
The Sigfox payload fields have different characteristics in Uplink and Downlink.
Sigfoxペイロードフィールドは、アップリンクとダウンリンクに異なる特性を持っています。
Uplink messages can contain a payload size from 0 to 12 bytes. The Sigfox radio protocol allows sending zero bits, one single bit of information for binary applications (e.g., status), or an integer number of bytes. Therefore, for 2 or more bits of payload, it is required to add padding to the next integer number of bytes. The reason for this flexibility is to optimize transmission time and hence save battery consumption at the device.
アップリンクメッセージには、0〜12バイトのペイロードサイズを含めることができます。SIGFOXラジオプロトコルにより、ゼロビット、バイナリアプリケーションの1つの単一の情報（ステータスなど）、または整数数のバイトを送信できます。したがって、2ビット以上のペイロードについては、次の整数数のバイトにパディングを追加する必要があります。この柔軟性の理由は、送信時間を最適化し、デバイスでバッテリー消費を節約するためです。
On the other hand, Downlink frames have a fixed length. The payload length MUST be 64 bits (i.e., 8 bytes). Hence, if less information bits are to be transmitted, padding MUST be used with bits equal to 0. The receiver MUST remove the added padding bits before the SCHC reassembly process.
一方、ダウンリンクフレームの長さは固定されています。ペイロード長は64ビット（つまり、8バイト）でなければなりません (MUST)。したがって、情報ビットが少ない場合は、0に等しいビットでパディングを使用しなければなりません (MUST)。SCHC再組み立てプロセスの前に、受信機は追加されたパディングビットを取り外さなければなりません (MUST)。
This section provides an example of RuleID configuration for interoperability between the F/R modes presented in this document. Note that the RuleID space for Uplink F/R is different than the one for Downlink F/R; therefore, this section is divided in two subsections: Rules for Uplink fragmentation and Rules for Downlink fragmentation.
このセクションでは、このドキュメントに示されているF/Rモード間の相互運用性のRuleID構成の例を示します。Uplink F/RのRuleIDスペースは、ダウンリンクF/Rのスペースとは異なることに注意してください。したがって、このセクションは、アップリンクの断片化のルールとダウンリンク断片化のルールの2つのサブセクションに分割されています。
For Uplink F/R, multiple header lengths were described in Section 3.5. All of them are part of the SCHC over Sigfox Profile and offer not only low protocol overhead for small payloads (single byte header) but also extensibility to transport larger payloads with more overhead (2-byte header, Options 1 and 2). The usage of the RuleID space for each header length is an implementation choice, but we provide an example of it in the following section. This illustrates implementation choices made in order to 1) identify the different header length and 2) finally parse the RuleID field to identify the RuleID value and execute the associated treatment.
アップリンクF/Rの場合、セクション3.5で複数のヘッダーの長さについて説明しました。それらはすべてSIGFOXプロファイルを介したSCHCの一部であり、小さなペイロード（単一バイトヘッダー）の低いプロトコルオーバーヘッドだけでなく、より多くのオーバーヘッド（2バイトヘッダー、オプション1および2）で大きなペイロードを輸送する拡張性も提供します。各ヘッダー長のRuleIDスペースの使用は実装の選択肢ですが、次のセクションでその例を示します。これは、1）異なるヘッダーの長さを特定し、2）RuleIDフィールドを解析してRuleID値を特定し、関連する治療を実行するために行われた実装の選択を示しています。
The RuleID field for Uplink F/R modes has different sizes depending on the header length. In order to identify the header length and then the value of the RuleID, the RuleID field is interpreted as follows:
アップリンクF/RモードのRuleIDフィールドは、ヘッダーの長さに応じてサイズが異なります。ヘッダーの長さを識別し、次にRuleIDの値を識別するために、Roolidフィールドは次のように解釈されます。
* The RuleID field is the first one to be parsed in the SCHC header, starting from the leftmost bits.
* RuleIDフィールドは、左端のビットから始まるSCHCヘッダーに解析された最初のフィールドです。
* For Single-byte SCHC Header F/R modes, a RuleID field of 3 bits is expected:
* シングルバイトSCHCヘッダーF/Rモードの場合、3ビットのRureIDフィールドが予想されます。
- If the first 3 leftmost bits have a value different than 0b'111, then it signals a Single-byte SCHC Header F/R mode.
- 最初の3つの左端ビットの値が0B'111とは異なる値を持っている場合、シングルバイトSCHCヘッダーF/Rモードを通知します。
- If their value is 0b'111, then it signals a Two-byte SCHC Header F/R mode.
- それらの値が0B'111の場合、2バイトSCHCヘッダーF/Rモードを通知します。
* For Single-byte SCHC Header F/R modes:
* シングルバイトSCHCヘッダーF/Rモードの場合：
- There are 7 RuleIDs available (with values from 0b'000-0b'110); the RuleID with value 0b'111 is reserved to indicate a Two-byte SCHC Header.
- 利用可能な7つのRuleIDがあります（0b'000-0b'110からの値）。値0B'111のRuleIDは、2バイトのSCHCヘッダーを示すために予約されています。
- This set of Rules is called "standard rules", and it is used to implement Single-byte SCHC Header modes.
- この一連のルールは「標準ルール」と呼ばれ、シングルバイトSCHCヘッダーモードを実装するために使用されます。
- Each RuleID is associated with a set of properties defining if Uplink F/R is used and which Uplink F/R mode is used. As an example, the RuleID 0b'000 is mapped onto Uplink No-ACK Mode: Single-byte SCHC Header, and the RuleIDs 0b'001 and 0b'002 are mapped onto Uplink ACK-on-Error mode: Single-byte SCHC Header (2 RuleIDs to allow for SCHC Packet interleaving).
- 各Roolidは、アップリンクF/Rが使用され、どのアップリンクF/Rモードが使用されるかを定義する一連のプロパティに関連付けられています。例として、RuleID 0B'000はUplink No-ackモードにマッピングされます：シングルバイトSchcヘッダー、およびRuleIDs 0B'001および0B'002はアップリンクACKオンエラーモードにマッピングされます：シングルバイトSCHCヘッダー（SCHCパケットインターリーブを許可する2つのRoolids）。
* For Two-byte SCHC Header F/R modes, at least 6 bits for the RuleID field are expected:
* 2バイトSCHCヘッダーF/Rモードの場合、RoolIDフィールドの少なくとも6ビットが予想されます。
- The 3 first leftmost bits are always 0b'111.
- 3つの最初の左端ビットは常に0B'111です。
o If the following 3 bits have a different value than 0b'111, then it signals the Two-byte SCHC Header Option 1.
o 次の3ビットが0B'111とは異なる値を持っている場合、2バイトのSCHCヘッダーオプション1を通知します。
o If the following 3 bits are 0b'111, then it signals the Two-byte SCHC Header Option 2.
o 次の3つのビットが0B'111の場合、2バイトSCHCヘッダーオプション2を通知します。
- For the Two-byte SCHC Header Option 1, there are 7 RuleIDs available (0b'111000-0b'111110), 0b'111111 being reserved to indicate the Two-byte SCHC Header Option 2. This set of Rules is called "extended rules", and it is used to implement the Uplink ACK-on-Error mode: Two-byte SCHC Header Option 1.
- 2バイトのSCHCヘッダーオプション1の場合、利用可能な7つのRuleID（0B'111000-0B'1110）、0B'111111は2バイトのSCHCヘッダーオプションを示すために予約されています。「そして、それはアップリンクACKオンエラーモードの実装に使用されます：2バイトSCHCヘッダーオプション1。
- For the Two-byte SCHC Header Option 2, there are 2 additional bits to parse as the RuleID, so 4 RuleIDs are available (0b'11111100-0b'11111111). This set of Rules is used to cover specific cases that previous RuleIDs do not cover. As an example, RuleID 0b'00111111 is used to transport uncompressed IPv6 packets using the Uplink ACK-on-Error mode: Two-byte SCHC Header Option 2.
- 2バイトのSCHCヘッダーオプション2の場合、RuleIDとして解析するための2つの追加ビットがあるため、4つのRuleIDが利用可能です（0B'1111100-0B'111111111111111111111111111111111111111年）。この一連のルールは、以前のRuleIDがカバーしていない特定のケースをカバーするために使用されます。例として、RuleID 0B'00111111は、アップリンクACKオンエラーモードを使用して、圧縮されていないIPv6パケットを輸送するために使用されます。2バイトSCHCヘッダーオプション2。
For the Downlink ACK-Always Mode: Single-byte SCHC Header, RuleIDs can get values in ranges from 0b'000 to 0b'111.
ダウンリンクACK-Alwaysモード：シングルバイトSCHCヘッダーの場合、Roolidsは0b'000から0b'111の範囲で値を取得できます。
In this section, some sequence diagrams depict message exchanges for different fragmentation modes and use cases are shown. In the examples, 'Seq' indicates the Sigfox Sequence Number of the frame carrying a fragment.
このセクションでは、いくつかのシーケンス図には、さまざまな断片化モードのメッセージ交換とユースケースが表示されています。例では、「seq」はフラグメントを運ぶフレームのSigfoxシーケンス番号を示します。
The FCN field indicates the size of the data packet. The first fragment is marked with FCN = X-1, where X is the number of fragments the message is split into. All fragments are marked with decreasing FCN values. The last packet fragment is marked with FCN = All-1 (1111).
FCNフィールドは、データパケットのサイズを示します。最初のフラグメントにはfcn = x-1でマークされています。ここで、xはメッセージが分割されるフラグメントの数です。すべてのフラグメントには、FCN値の減少がマークされています。最後のパケットフラグメントには、FCN = ALL-1（1111）がマークされています。
*Case No Losses - All fragments are sent and received successfully.*
*ケース損失なし - すべてのフラグメントが送信され、正常に受信されます。*
Sender Receiver
|-------FCN=6,Seq=1-------->|
|-------FCN=5,Seq=2-------->|
|-------FCN=4,Seq=3-------->|
|-------FCN=3,Seq=4-------->|
|-------FCN=2,Seq=5-------->|
|-------FCN=1,Seq=6-------->|
|-------FCN=15,Seq=7------->| All fragments received
(End)
Figure 31: Uplink No-ACK No-Losses
図31：UPLINK NO-ACK NOLOSSES
When the first SCHC Fragment is received, the receiver can calculate the total number of SCHC Fragments that the SCHC Packet is composed of. For example, if the first fragment is numbered with FCN=6, the receiver can expect six more messages/fragments (i.e., with FCN going from 5 downwards and the last fragment with an FCN equal to 15).
最初のSCHCフラグメントを受信すると、受信機はSCHCパケットが構成されているSCHCフラグメントの総数を計算できます。たとえば、最初のフラグメントにFCN=6で番号が付けられている場合、受信機はさらに6つのメッセージ/フラグメントを期待できます（つまり、FCNが5から下向きになり、最後のフラグメントはFCNが15に等しい）。
*Case Losses on Any Fragment except the First*
*最初を除く断片のケースロス*
Sender Receiver
|-------FCN=6,Seq=1-------->|
|-------FCN=5,Seq=2----X |
|-------FCN=4,Seq=3-------->|
|-------FCN=3,Seq=4-------->|
|-------FCN=2,Seq=5-------->|
|-------FCN=1,Seq=6-------->|
|-------FCN=15,Seq=7------->| Missing Fragment Unable to reassemble
(End)
Figure 32: Uplink No-ACK Losses (Scenario 1)
図32：Uplink no-ack損失（シナリオ1）
The Single-byte SCHC Header ACK-on-Error mode allows sending up to 28 fragments and packet sizes up to 300 bytes. The SCHC Fragments may be delivered asynchronously, and Downlink ACK can be sent opportunistically.
シングルバイトSCHCヘッダーACKオンエラーモードにより、最大28のフラグメントとパケットサイズを最大300バイト送信できます。SCHCフラグメントは非同期に配信される場合があり、ダウンリンクACKは日和見的に送信できます。
*Case No Losses*
*ケースなしの損失*
The Downlink flag must be enabled in the sender Uplink message to allow a Downlink message from the receiver. The Downlink Enable in the figures shows where the sender MUST enable the Downlink and wait for an ACK.
受信側からのダウンリンクメッセージを可能にするため、送信側のアップリンクメッセージでDownlinkフラグを有効にする必要があります。図中の「Downlink Enable」は、送信側がダウンリンクを有効にし、ACKを待たなければならない (MUST) 箇所を示しています。
Sender Receiver
|-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2----->|
|-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4----->|
|-----W=0,FCN=2,Seq=5----->|
|-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7----->|
(no ACK)
|-----W=1,FCN=6,Seq=8----->|
|-----W=1,FCN=5,Seq=9----->|
|-----W=1,FCN=4,Seq=10---->|
DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received
|<- Compound ACK,W=1,C=1 --| C=1
(End)
Figure 33: Uplink ACK-on-Error No-Losses
図33：Uplink Ack-on-errorノーロス
*Case Fragment Losses in the First Window*
*最初のウィンドウでのケースフラグメント損失*
In this case, fragments are lost in the first window (W=0). After the first All-0 message arrives, the receiver leverages the opportunity and sends a SCHC ACK with the corresponding bitmap and C=0.
この場合、最初のウィンドウ（W=0）でフラグメントが失われます。最初のALL-0メッセージが届いた後、レシーバーは機会を活用し、対応するビットマップとC=0でSCHC ACKを送信します。
After the loss fragments from the first window (W=0) are resent, the sender continues transmitting the fragments of the following window (W=1) without opening a reception opportunity. Finally, the All-1 fragment is sent, the Downlink is enabled, and the SCHC ACK is received with C=1. Note that the SCHC Compound ACK also uses a Sequence Number.
最初のウィンドウからの損失フラグメント（W=0）がresした後、送信者はレセプションの機会を開くことなく、次のウィンドウ（W=1）のフラグメントを送信し続けます。最後に、ALL-1フラグメントが送信され、ダウンリンクが有効になり、SCHC ACKがC=1で受信されます。SCHC化合物ACKもシーケンス番号を使用していることに注意してください。
Sender Receiver
|-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2--X |
|-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4----->|
|-----W=0,FCN=2,Seq=5--X | __
|-----W=0,FCN=1,Seq=6----->| | W=0
DL Enable |-----W=0,FCN=0,Seq=7----->| Missing Fragments<- FCN=5,Seq=2
|<- Compound ACK,W=0,C=0 --| Bitmap:1011011 | FCN=2,Seq=5
|-----W=0,FCN=5,Seq=9----->| --
|-----W=0,FCN=2,Seq=10---->|
|-----W=1,FCN=6,Seq=11---->|
|-----W=1,FCN=5,Seq=12---->|
|-----W=1,FCN=4,Seq=13---->|
DL Enable |-----W=1,FCN=7,Seq=14---->| All fragments received
|<-Compound ACK,W=1,C=1 ---| C=1
(End)
Figure 34: Uplink ACK-on-Error Losses in the First Window
図34：最初のウィンドウでACKオンエラーの損失をアップリンクする
*Case Fragment All-0 Lost in the First Window (W=0)*
*ケースフラグメントALL-0最初のウィンドウで失われた（W=0）*
In this example, the All-0 of the first window (W=0) is lost. Therefore, the receiver waits for the next All-0 message of intermediate windows or All-1 message of last window to generate the corresponding SCHC ACK, which indicates that the All-0 of window 0 is absent.
この例では、最初のウィンドウ（W=0）のすべてが失われます。したがって、受信者は、中間ウィンドウの次のALL-0メッセージまたは最後のウィンドウのALL-1メッセージを待って、対応するSCHC ACKを生成します。これは、ウィンドウ0のALL0が存在しないことを示します。
The sender resends the missing All-0 messages (with any other missing fragment from window 0) without opening a reception opportunity.
送信者は、レセプションの機会を開くことなく、欠落しているAll-0メッセージ（ウィンドウ0からの他の失われたフラグメントを使用）を再送信します。
Sender Receiver
|-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2----->|
|-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4----->|
|-----W=0,FCN=2,Seq=5----->|
|-----W=0,FCN=1,Seq=6----->| DL Enable
|-----W=0,FCN=0,Seq=7--X |
(no ACK)
|-----W=1,FCN=6,Seq=8----->|
|-----W=1,FCN=5,Seq=9----->| __
|-----W=1,FCN=4,Seq=10---->| |W=0
DL Enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<- FCN=0,Seq=7
|<-Compound ACK,W=0,C=0 ---| Bitmap:1111110 |__
|-----W=0,FCN=0,Seq=13---->| All fragments received
DL Enable |-----W=1,FCN=7,Seq=14---->|
|<-Compound ACK,W=1,C=1 ---| C=1
(End)
Figure 35: Uplink ACK-on-Error All-0 Lost in the First Window
図35：最初のウィンドウでACKオンエラーのALL-0をUPLINK ACK-ON-E-0
In the following diagram, besides the All-0, there are other fragment losses in the first window (W=0).
次の図では、All-0に加えて、最初のウィンドウに他のフラグメント損失があります（W=0）。
Sender Receiver
|-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2--X |
|-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4--X |
|-----W=0,FCN=2,Seq=5----->|
|-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7--X |
(no ACK)
|-----W=1,FCN=6,Seq=8----->|
|-----W=1,FCN=5,Seq=9----->| __
|-----W=1,FCN=4,Seq=10---->| |W=0
DL Enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<- FCN=5,Seq=2
|<--Compound ACK,W=0,C=0 --| Bitmap:1010110 |FCN=3,Seq=4
|-----W=0,FCN=5,Seq=13---->| |FCN=0,Seq=7
|-----W=0,FCN=3,Seq=14---->| --
|-----W=0,FCN=0,Seq=15---->| All fragments received
DL Enable |-----W=1,FCN=7,Seq=16---->|
|<-Compound ACK,W=1,C=1 ---| C=1
(End)
Figure 36: Uplink ACK-on-Error All-0 and Other Fragments Lost in the First Window
図36：最初のウィンドウで失われたアップリンクACKオンエラーおよびその他のフラグメント
In the next examples, there are fragment losses in both the first (W=0) and second (W=1) windows. The retransmission cycles after the All-1 is sent (i.e., not in intermediate windows) MUST always finish with an All-1, as it serves as an ACK Request message to confirm the correct reception of the retransmitted fragments.
次の例では、最初の（W=0）と2番目の（W=1）ウィンドウの両方にフラグメント損失があります。All-1が送信された後の再送信サイクル（つまり、中間ウィンドウではなく）は常にALL-1で終了しなければなりません (MUST)。これは、再送信されたフラグメントの正しい受信を確認するACKリクエストメッセージとして機能するためです。
Sender Receiver
|-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2--X |
|-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4--X | __
|-----W=0,FCN=2,Seq=5----->| |W=0
|-----W=0,FCN=1,Seq=6----->| |FCN=5,Seq=2
DL Enable |-----W=0,FCN=0,Seq=7--X | |FCN=3,Seq=4
(no ACK) |FCN=0,Seq=7
|-----W=1,FCN=6,Seq=8--X | |W=1
|-----W=1,FCN=5,Seq=9----->| |FCN=6,Seq=8
|-----W=1,FCN=4,Seq=10-X | |FCN=4,Seq=10
DL Enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<-|__
|<-Compound ACK,W=0,1,C=0--| Bitmap W=0:1010110
|-----W=0,FCN=5,Seq=13---->| W=1:0100001
|-----W=0,FCN=3,Seq=14---->|
|-----W=0,FCN=0,Seq=15---->|
|-----W=1,FCN=6,Seq=16---->|
|-----W=1,FCN=4,Seq=17---->| All fragments received
DL Enable |-----W=1,FCN=7,Seq=18---->|
|<-Compound ACK,W=1,C=1----| C=1
(End)
Figure 37: Uplink ACK-on-Error All-0 and Other Fragments Lost in the First and Second Windows (1)
図37：最初のウィンドウと2番目のウィンドウで失われたUplink ACK-ON-ERROR ALL-0およびその他のフラグメント（1）
The figure below is a similar case as above but with fewer fragments in the second window (W=1).
以下の図は、上記と同様のケースですが、2番目のウィンドウ（W=1）のフラグメントが少ないです。
Sender Receiver
|-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2--X |
|-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4--X |
|-----W=0,FCN=2,Seq=5----->| __
|-----W=0,FCN=1,Seq=6----->| |W=0
DL Enable |-----W=0,FCN=0,Seq=7--X | |FCN=5,Seq=2
(no ACK) |FCN=3,Seq=4
|-----W=1,FCN=6,Seq=8--X | |FCN=0,Seq=7
DL Enable |-----W=1,FCN=7,Seq=9----->| Missing Fragment--> W=1
|<-Compound ACK,W=0,1, C=0-| Bitmap W=0:1010110,|FCN=6,Seq=8
|-----W=0,FCN=5,Seq=11---->| W=1:0000001 |__
|-----W=0,FCN=3,Seq=12---->|
|-----W=0,FCN=0,Seq=13---->|
|-----W=1,FCN=6,Seq=14---->| All fragments received
DL Enable |-----W=1,FCN=7,Seq=15---->|
|<-Compound ACK, W=1,C=1---| C=1
(End)
Figure 38: Uplink ACK-on-Error All-0 and Other Fragments Lost in the First and Second Windows (2)
図38：最初のウィンドウと2番目のウィンドウ（2）で失われたUplink Ack-on-error all-0およびその他のフラグメント
*Case SCHC ACK is Lost*
*ケースSCHC ACKは失われました*
SCHC over Sigfox does not implement the SCHC ACK REQ message. Instead, it uses the SCHC All-1 message to request a SCHC ACK when required.
SCHC Over Sigfoxは、SCHC ACK Reqメッセージを実装していません。代わりに、SCHC ALL-1メッセージを使用して、必要に応じてSCHC ACKを要求します。
Sender Receiver
|-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2----->|
|-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4----->|
|-----W=0,FCN=2,Seq=5----->|
|-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7----->|
(no ACK)
|-----W=1,FCN=6,Seq=8----->|
|-----W=1,FCN=5,Seq=9----->|
|-----W=1,FCN=4,Seq=10---->|
DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received
| X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=13---->| RESEND ACK
|<-Compound ACK,W=1,C=1 ---| C=1
(End)
Figure 39: Uplink ACK-on-Error ACK Lost
図39：Uplink Ack-on-error ACKが失われました
*Case SCHC Compound ACK at the End*
*最後にケースSCHCコンパウンドACK*
In this example, SCHC Fragment losses are found in both windows 0 and 1. However, the sender does not send a SCHC Compound ACK after the All-0 of window 0. Instead, it sends a SCHC Compound ACK indicating fragment losses on both windows.
この例では、SCHCフラグメントの損失はWindows 0と1の両方にあります。ただし、送信者はウィンドウ0のAll-0の後にSCHC化合物ACKを送信しません。代わりに、両方のウィンドウでフラグメント損失を示すSCHC化合物ACKを送信。
Sender Receiver
|-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2--X |
|-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4--X |
|-----W=0,FCN=2,Seq=5----->|
|-----W=0,FCN=1,Seq=6----->| __
DL Enable |-----W=0,FCN=0,Seq=7----->| Waits for |W=0
(no ACK) next DL opportunity |FCN=5,Seq=2
|-----W=1,FCN=6,Seq=8--X | |FCN=3,Seq=4
DL Enable |-----W=1,FCN=7,Seq=9----->| Missing Fragment<-- W=1
|<-Compound ACK,W=0,1, C=0-| Bitmap W=0:1010110 |FCN=6,Seq=8
|-----W=0,FCN=5,Seq=11---->| W=1:0000001 --
|-----W=0,FCN=3,Seq=12---->|
|-----W=1,FCN=6,Seq=13---->| All fragments received
DL Enable |-----W=1,FCN=7,Seq=14---->|
|<-Compound ACK, W=1, C=1 -| C=1
(End)
Figure 40: Uplink ACK-on-Error Fragments Lost in the First and Second Windows with One Compound ACK
図40：1つの複合ACKで最初と2番目のウィンドウで失われたUplink Ack-on-errorフラグメント
The number of times the same SCHC ACK message will be retransmitted is determined by the MAX_ACK_REQUESTS.
同じSCHC ACKメッセージが再送信される回数は、MAX_ACK_REQUESTSによって決定されます。
*Case SCHC Sender-Abort*
*ケースSCHC SENDER-ABORT*
The sender may need to send a Sender-Abort to stop the current communication. For example, this may happen if the All-1 has been sent MAX_ACK_REQUESTS times.
送信者は、現在の通信を停止するために送信者 - アボートを送信する必要がある場合があります。たとえば、これはAll-1がMAX_ACK_REQUESTS TIMESを送信された場合に発生する可能性があります。
Sender Receiver
|-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2----->|
|-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4----->|
|-----W=0,FCN=2,Seq=5----->|
|-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7----->|
(no ACK)
|-----W=1,FCN=6,Seq=8----->|
|-----W=1,FCN=5,Seq=9----->|
|-----W=1,FCN=4,Seq=10---->|
DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received
| X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=13---->| RESEND ACK (1)
| X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=15---->| RESEND ACK (2)
| X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=17---->| RESEND ACK (3)
| X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=18---->| RESEND ACK (4)
| X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=19---->| RESEND ACK (5)
| X--Compound ACK,W=1,C=1 -| C=1
DL Enable |----Sender-Abort,Seq=20-->| exit with error condition
(End)
Figure 41: Uplink ACK-on-Error Sender-Abort
図41：Uplink Ack-on-error Sender-Abort
*Case Receiver-Abort*
*case receiver-abort*
The receiver may need to send a Receiver-Abort to stop the current communication. This message can only be sent after a Downlink Enable.
受信者は、現在の通信を停止するために受信機アボートを送信する必要がある場合があります。このメッセージは、ダウンリンク有効化後にのみ送信できます。
Sender Receiver
|-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2----->|
|-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4----->|
|-----W=0,FCN=2,Seq=5----->|
|-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7----->|
|<------ RECV ABORT ------| under-resourced
(Error)
Figure 42: Uplink ACK-on-Error Receiver-Abort
図42：Uplink Ack-on-error Receiver-Abort
The radio protocol authenticates and ensures the integrity of each message. This is achieved by using a unique Device ID and an AES-128-based message authentication code, ensuring that the message has been generated and sent by the device (see [sigfox-spec], Section 3.8) or Network (see [sigfox-spec], Section 4.3) with the ID claimed in the message [sigfox-spec].
ラジオプロトコルは、各メッセージの整合性を認証および保証します。これは、一意のデバイスIDとAES-128ベースのメッセージ認証コードを使用して達成され、メッセージがデバイス（[sigfox-spec]、セクション3.8を参照）またはネットワーク（[sigfox-を参照）によって生成および送信されるようにします。Spec]、セクション4.3）メッセージ[Sigfox-spec]で請求されているID。
Application data may or may not be encrypted at the application layer, depending on the criticality of the use case. This flexibility allows a balance between cost and effort versus risk. AES-128 in counter mode is used for encryption. Cryptographic keys are independent for each device. These keys are associated with the Device ID, and separate integrity and encryption keys are pre-provisioned. An encryption key is only provisioned if confidentiality is to be used (see [sigfox-spec], Section 5.3; note that further documentation is available at Sigfox upon request).
アプリケーションデータは、ユースケースの重要性に応じて、アプリケーションレイヤーで暗号化される場合とされない場合があります。この柔軟性により、コストと努力とリスクのバランスが得られます。カウンターモードのAES-128は、暗号化に使用されます。暗号化キーは、デバイスごとに独立しています。これらのキーはデバイスIDに関連付けられており、個別の整合性と暗号化キーが事前に導入されています。暗号化キーは、機密性を使用する場合にのみプロビジョニングされます（[Sigfox-spec]、セクション5.3を参照してください。リクエストに応じてSigfoxでさらなるドキュメントが利用可能であることに注意してください）。
The radio protocol has protections against replay attacks, and the cloud-based core Network provides firewall protection against undesired incoming communications [sigfox-spec].
ラジオプロトコルにはリプレイ攻撃に対する保護があり、クラウドベースのコアネットワークは、望ましくない着信通信[SIGFOX-SPEC]に対するファイアウォール保護を提供します。
The previously described security mechanisms do not guarantee end-to-end security between the device SCHC C/D + F/R and the Network SCHC C/D + F/R; potential security threats described in [RFC8724] are applicable to the profile specified in this document.
前述のセキュリティメカニズムは、デバイスSCHC C/D F/RとネットワークSCHC C/D F/Rの間のエンドツーエンドセキュリティを保証するものではありません。[RFC8724]で説明されている潜在的なセキュリティの脅威は、このドキュメントで指定されたプロファイルに適用できます。
In some circumstances, sending device location information is privacy sensitive. The Device Geolocation parameter provided by the Network is optional; therefore, it can be omitted to protect this aspect of the device privacy.
状況によっては、デバイスの位置情報を送信することはプライバシーに敏感です。ネットワークによって提供されるデバイスジオロケーションパラメーターはオプションです。したがって、デバイスのプライバシーのこの側面を保護することは省略できます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, April 2020, <https://www.rfc-editor.org/info/rfc8724>.
[RFC9441] Zúñiga, JC., Gomez, C., Aguilar, S., Toutain, L., Céspedes, S., and D. Wistuba, "Static Context Header Compression (SCHC) Compound Acknowledgement (ACK)", RFC 9441, DOI 10.17487/RFC9441, July 2023, <https://www.rfc-editor.org/info/rfc9441>.
[sigfox-spec]
Sigfox, "Sigfox Device Radio Specifications",
<https://build.sigfox.com/sigfox-device-radio-
specifications>.
[CORE-COMI]
Veillette, M., Ed., van der Stok, P., Ed., Pelov, A.,
Bierman, A., and C. Bormann, Ed., "CoAP Management
Interface (CORECONF)", Work in Progress, Internet-Draft,
draft-ietf-core-comi-12, 13 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
comi-12>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[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>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.
[sigfox-callbacks]
Sigfox, "Sigfox Callbacks",
<https://support.sigfox.com/docs/callbacks-documentation>.
[sigfox-docs]
Sigfox, "Sigfox Documentation",
<https://support.sigfox.com/docs>.
Carles Gomez has been funded in part by the Spanish Government through the TEC2016-79988-P grant and the PID2019-106808RA-I00 grant (funded by MCIN / AEI / 10.13039/501100011033) and by Secretaria d'Universitats i Recerca del Departament d'Empresa i Coneixement de la Generalitat de Catalunya through 2017 grant SGR 376 and 2021 grant SGR 00330.
Carles Gomezは、TEC2016-79988-P GrantとPID2019-106808RA-I00助成金（MCIN / AEI / 10.13039 / 501100011033によって資金提供）およびSecrecearia D'Universitats I Recerca del Departament D 'd'によるスペイン政府によって部分的に資金提供を受けています。Empresa I Coneixement de la generalitat de catalunyaから2017年の助成金Sgr 376および2021 Grant Sgr 00330。
Sergio Aguilar has been funded by the ERDF and the Spanish Government through project TEC2016-79988-P and project PID2019-106808RA-I00, AEI/FEDER, EU (funded by MCIN / AEI / 10.13039/501100011033).
Sergio Aguilarは、プロジェクトTEC2016-79988-PおよびProject PID2019-106808ra-I00、AEI/FEDER、EU（MCIN / AEI / 10.13039 / 501100011033によって資金提供）を通じてERDFとスペイン政府によって資金提供されています。
Sandra Cespedes has been funded in part by the ANID Chile Project FONDECYT Regular 1201893 and Basal Project FB0008.
サンドラ・セスペデスは、Anid Chile Project Fondecyt Regular 1201893およびBasal Project FB0008によって部分的に資金提供されています。
Diego Wistuba has been funded by the ANID Chile Project FONDECYT Regular 1201893.
ディエゴ・ウィスバは、アニッド・チリ・プロジェクトFondecyt Regular 1201893によって資金提供されています。
The authors would like to thank Ana Minaburo, Clement Mannequin, Rafael Vidal, Julien Boite, Renaud Marty, and Antonis Platis for their useful comments and implementation design considerations.
著者は、アナ・ミナブロ、クレメント・マネキン、ラファエル・ヴィダル、ジュリアン・ボイト、ルノー・マーティ、アントニス・プラティスの有用なコメントと実装の設計上の考慮事項に感謝したいと思います。
Juan Carlos Zúñiga
Montreal QC
Canada
Email: j.c.zuniga@ieee.org
Carles Gomez
Universitat Politècnica de Catalunya
C/Esteve Terradas, 7
08860 Castelldefels
Spain
Email: carles.gomez@upc.edu
Sergio Aguilar
Universitat Politècnica de Catalunya
C/Esteve Terradas, 7
08860 Castelldefels
Spain
Email: sergio.aguilar.romero@upc.edu
Laurent Toutain
IMT-Atlantique
CS 17607
2 rue de la Chataigneraie
35576 Cesson-Sevigne Cedex
France
Email: Laurent.Toutain@imt-atlantique.fr
Sandra Céspedes
Concordia University
1455 De Maisonneuve Blvd. W.
Montreal QC H3G 1M8
Canada
Email: sandra.cespedes@concordia.ca
Diego Wistuba
NIC Labs, Universidad de Chile
Av. Almte. Blanco Encalada 1975
Santiago
Chile
Email: research@witu.cl
Julien Boite
Unabiz (Sigfox)
Labege
France
Email: juboite@free.fr
URI: https://www.sigfox.com/