| Internet-Draft | SCHC Convergence | May 2023 |
| Aguilar, et al. | Expires 12 November 2023 | [Page] |
The present document defines a profile of Static Context Header Compression and fragmentation (SCHC) [RFC8724] for multi-radio devices or multi-network application. This profile can be used simultaneously over LoRaWAN, Sigfox, NB-IoT and any other technology that may use SCHC Fragmentation/Reassembly functionality.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 12 November 2023.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
The Static Context Header Compression and fragmentation (SCHC) specification [RFC8724] provides generic adaptation layer functionality, including Compression/Decompression (C/D) and Fragmentation and Reassembly (F/R) functionality. The latter offers three different modes, providing different features.¶
SCHC over LoRaWAN [RFC9011], SCHC over Sigfox [I-D.lpwan-schc-over-sigfox] and SCHC over NB-IoT [I-D.lpwan-schc-over-nbiot] are technology-specific SCHC profiles, which provide an optimal configuration of SCHC over the corresponding technologies. However, the F/R functionalities of these profiles are not compatible. Therefore, multi-radio devices (e.g., supporting LoRaWAN, Sigfox and NB-IoT interfaces on the same device) require multiple implementations of the SCHC F/R sublayer, one for each technology.¶
Moreover, multi-network solutions, where the same application is deployed over different LPWAN technologies also require multiple implementations of the SCHC F/R sublayer, one for each deployment.¶
To reduce implementation complexity, and enable a single convergent F/R sublayer, this document provides the F/R details for a SCHC profile that can be used over all the LPWAN technologies overviewed in [RFC8376], leveraging the benefits of the Compound ACK. This profile can also be used over other technologies that may use SCHC Fragmentation/Reassembly functionality.¶
It is assumed that the reader is familiar with the terms and mechanisms defined in [RFC8376] and in [RFC8724].¶
IoT applications running over LPWAN devices are tied up to the selected LPWAN technology. The LPWAN constrains influence the design of the IoT application itself. This presents problems when migrating to other LPWANs or networks, as it may imply redesigning the complete IoT application (from device code to backend code). The LPWAN, as a Layer 2 (L2), should be transparent to IoT application (and developers), as it is in the IP domain.¶
Current advances in the adoption of IPv6 over LPWAN achieved interoperability for application thanks to SCHC [RFC8724], and a single SCHC C/D sublayer. However, each LPWAN technology requires a different implementation of the SCHC F/R sublayer, with different (but actually very similar) F/R modes. Therefore, an IoT application using multiple LPWANs (multiple radios o multiple networks) will require multiple SCHC F/R implementation in device and backend code. This is not the case for the C/D sublayer.¶
To reduce code complexity and maintenance, and achieve a single convergent SCHC F/R sublayer, this document provides a SCHC Profile which considers the singularities of LoRaWAN, Sigfox and NB-IoT, while providing general F/R modes that work over all of these technologies simultaneously.¶
The SCHC over All profile has several use cases:¶
[RFC8376] overviews the LoRaWAN, Sigfox, and NB-IoT protocols and their network architectures. More specifically, [RFC9011] maps the network architecture entities between LoRaWAN and LPWAN, as described in [RFC8724]. Similarly, [I-D.lpwan-schc-over-sigfox] and [I-D.lpwan-schc-over-nbiot] for Sigfox and NB-IoT performs the same mapping for Sigfox and NB-IoT, respectively.¶
Figure 1 shows the architecture when using several SCHC F/R implementations, one for each LPWAN technology. In this case, it is possible to send SCHC Packets over different LPWAN networks.¶
() () () | | () () () () / \/ \ +---------+ +---------+ () () () () () / / \ \====| Network |===|SCHC over|=== () () () () | Gateway | | NB-IoT | || () () () () () | (NB-IoT)| +---------+ || () () () () +---------+ || () () () () || +-----------+ () () () | | || |Application| () () () () / \/ \ +---------+ +---------+ || +-----------+ () () () () () / / \ \====| Network |===|SCHC over|====| SCHC C/D | () () () () | Core | | Sigfox | || +-----------+ () () () () () | (Sigfox)| +---------+ || () () () () +---------+ || () () () () || () () () | | +---------+ +---------+ || () () () () / \/ \ | Network | |SCHC over| || () () () () / / \ \====| Server |===| LoRaWAN |=== () () () () |(LoRaWAN)| +---------+ () () () () +---------+ End devices Radio Gateways Network Server SCHC C/D and F/R (devices) (RGW) (NGW)
Figure 2 presents the SCHC over All architecture, with a single SCHC C/D and F/R sublayer. This architecture provides a single implementation of the SCHC F/R sublayer.¶
() () () | |
() () () () / \/ \ +---------+
() () () () () / / \ \====| Network |==========
() () () () | Gateway | ||
() () () () () | (NB-IoT)| ||
() () () () +---------+ ||
() () () () () +---------+
() () () | | |SCHC C/D |
() () () () / \/ \ +---------+ |---------| +-----------+
() () () () () / / \ \====| Network |===|SCHC over|==|Application|
() () () () | Core | | All | +-----------+
() () () () () | (Sigfox)| +---------+
() () () () +---------+ ||
() () () () ||
() () () | | ||
() () () () / \/ \ +---------+ ||
() () () () () / / \ \====| Network |==========
() () () () | Server |
() () () () () |(LoRaWAN)|
() () () () +---------+
End devices Radio Gateways Network Server SCHC C/D and F/R
(devices) (RGW) (NGW) Server
In the SCHC over All Profile, as devices have a single SCHC F/R implementation, F/R RuleIDs are the same, independently of the LPWAN technology used, reducing the device memory and complexity requirements when compared to multiple SCHC F/R implementation.¶
To simplify the access to RuleIDs and to converge the different device IDs provided by the networks involved, a device needs to have a new identifier called the single SCHC ID.¶
A device ID translation table maps the network device ID to single SCHC ID. Then, with the single Device ID, it is possible to look up the Rules set and identify the corresponding Rules for such device. This dissociates the network device ID form the Rules, allowing to use the same Rule set for the same device independently of the access network.¶
The network device IDs used by the LPWAN technologies included in this Profile are:¶
Figure 3 presents a diagram of the SCHC over All architecture including the Single SCHC device ID translation table.¶
+-----------+
| Table |==========
| Device ID | ||
|translation| ||
+-----------+ ||
+---------+
|SCHC C/D |
+---------+ +-----------+
(from All LPWANs) ===|SCHC over|==|Application|
| All | +-----------+
+---------+
ACK-on-Error mode is RECOMMENDED for the transmission of Uplink SCHC Packets that require fragmentation and need to be sent reliably. ACK-on-Error mode is optimal, since it leads to a reduced number of ACKs in the lower capacity Downlink channel as Downlink messages can be sent asynchronously and opportunistically. Moreover, ACK-on-Error mode supports variable MTU (which is critical for changing from one LPWAN technology to another when sending SCHC Fragments spread across different LPWANs), and out-of-order delivery (in case SCHC Fragments are received out-of-order at the SCHC F/R receiver).¶
SCHC over LoRaWAN [RFC9011], SCHC over Sigfox [I-D.lpwan-schc-over-sigfox] and SCHC over NB-IoT [I-D.lpwan-schc-over-nbiot] provide uplink fragmentation SCHC profiles. At the SCHC Fragment level, these profiles are not compatible with one another. However, one of the SCHC over Sigfox uplink fragmentation modes (Two-bytes Option 2) has several similarities with the ACK-on-Error SCHC over LoRaWAN profile. Such similarities include:¶
Differences between the SCHC over LoRaWAN and SCHC over Sigfox (Two-byte Option 2) uplink fragmentation profiles include:¶
SCHC over LoRaWAN ACK-on-Error includes a WINDOW_SIZE of 64 tiles. This allows feedback from receiver to sender with larger ACKs. Larger ACKs provide better performance in error-prone environments.¶
On the other hand, SCHC over Sigfox leverages the Compound ACK with a WINDOW_SIZE of 32, allowing more downlink opportunities, and enabling larger ACKs, notifying more than one window, in error-prone environments and smaller ACKs, notifying one window.¶
Therefore, the SCHC over All Profile uses smaller WINDOW_SIZE values than the ones proposed in SCHC over LoRaWAN [RFC9011], as it uses the Compound ACK to accomplish larger ACK size, while still having the option of smaller ACKs and more downlink opportunities.¶
In error-prone environments, larger ACKs pool more fragment error in a single ACK, reducing the total number of ACKs, compared to the increase in ACK size. Smaller ACKs performed better when error are scatter, as ACKs will be small and less frequent.¶
In order to take advance of the similarities of the different LPWAN profiles, the SCHC Uplink Fragmentation Header size is RECOMMENDED to have a size of 16 bits and be composed as follows:¶
When fragmentation is performed in the Uplink, the Compound ACK allows to optimally manage receiver acknowledgements, as the number of windows and the moment the Compound ACK is transferred can be freely selected, e.g., depending on network conditions or capacity. This advantage, compared with [RFC8724] and [RFC9011], benefits smaller windows sizes, as smaller windows sizes provide more downlink opportunities than a larger windows for the same number of tiles.¶
The RuleID MUST be 8 bits. In LoRaWAN it MUST be encoded in the LoRaWAN FPort.¶
This section depicts the different formats of SCHC Fragment, SCHC ACK (including the SCHC Compound ACK defined in [I-D.ietf-lpwan-schc-compound-ack]), SCHC Aborts and ACK Request used in SCHC over All Uplink ACK-on-Error mode.¶
Figure 4 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.¶
+ ------ + -------------------------- + | RuleID | W | FCN | Payload | + ------ + ------ + ------ + -------- + | 8 bits | 3 bits | 5 bits | Variable |
+ ------ + ---------------------------- + | RuleID | W | FCN=All-1 | RCS | + ------ + ------ + --------- + ------- + | 8 bits | 3 bits | 5 bits | 32 bits |
+ ------ + ---------------------------------------------------------- + | RuleID | W | FCN=All-1 | RCS | Last tile | Opt. padding | + ------ + ------ + --------- + ------- + ------------ + ------------ + | 8 bits | 3 bits | 5 bits | 32 bits | 1 to X bits | 0 to 7 bits
+ ------ + --------------------------+ | RuleID | W | C = 1 | padding | + ------ + ----- + ----- + --------- + | 8 bits | 3 bit | 1 bit | X bits |
| FPort | LoRaWAN payload |
+ ------ + --------------------------------- + ---------------- +
| RuleID | W | C = 0 | Compressed bitmap | Optional padding |
| | | | (C = 0) | (b'0...0) |
+ ------ + ----- + ----- + ----------------- + ---------------- +
| 8 bits | 2 bit | 1 bit | 5 to 63 bits | 0, 6 or 7 bits |
|-- 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|
Losses are found in windows W = w1,...,wi; where w1<w2<...<wi
|-- 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 | X bits |
next L2 Word boundary ->| <-- L2 Word --> |
|---- Sender-Abort Header ----|
+-----------------------------+
| RuleID | W | FCN=ALL-1 |
+--------+--------+-----------+
| 8 bits | 3 bits | 5 bits |
|------- ACK Request Header -------| +------- +------------------------ + | RuleID | W | FCN = b'00000 | + ------ + ------ + -------------- + | 8 bits | 3 bits | 5 bits |
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 2017 through grant SGR 376.¶
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).¶