SCHC Convergence Profile
Universitat Politecnica de CatalunyaC/Esteve Terradas, 708860 CastelldefelsSpainsergio.aguilar.romero@upc.eduUniversitat Politecnica de CatalunyaC/Esteve Terradas, 708860 CastelldefelsSpaincarles.gomez@upc.eduUniversitat Politecnica de CatalunyaC/Esteve Terradas, 708860 CastelldefelsSpainrafael.vidal@upc.eduschc Working GroupThe 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. The Static Context Header Compression and fragmentation (SCHC) specification
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 , SCHC over Sigfox
and SCHC over NB-IoT 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 , 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 and
in .
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 , 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:Generic SCHC F/R Profile for implementation of SCHC to test over a new technology. SCHC out-of-the-box F/R modes.Multi-radio devices: Devices implementing more than one LPWAN radio.Multi-network applications: Applications deployed over more than one LPWAN.Network Redundancy:
Devices using another LPWAN as backup,
devices sending the same SCHC Fragment in different networks to increase the probability of successful fragmented packet reception.
Increased device duty-cycle as more networks are available, e.g., if SCHC Packet transmission is not possible over LoRaWAN due to duty-cycle restriction, SCHC Packet transmission may be performed over Sigfox or NB-IoT. This applies also for SCHC Fragments.
Devices sending SCHC Fragments over different LPWANs to check available coverage.
overviews the LoRaWAN, Sigfox, and NB-IoT protocols and their network architectures.
More specifically, maps the network architecture entities between LoRaWAN and LPWAN, as described in .
Similarly, and for Sigfox and NB-IoT performs the same mapping for Sigfox and NB-IoT, respectively.
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.
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.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: LoRaWAN: DevIDSigfox: DeviceIDNB-IoT: IMEI presents a diagram of the SCHC over All architecture including the Single SCHC device ID translation table. 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 , SCHC over Sigfox and SCHC over NB-IoT 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:2-byte SCHC Fragmentation Header size.10-byte tile size.2-byte Rule ID size.No DTagDifferences between the SCHC over LoRaWAN and SCHC over Sigfox (Two-byte Option 2) uplink fragmentation profiles include:WINDOW_SIZE (tiles per window).M size (maximum number of windows).N size (tiles per window).Different RCS size and algoritm.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 , 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:Rule ID size is: 8 bitsDTag size (T) is: 0 bitsWindow index (W) size (M): 3 bits Fragment Compressed Number (FCN) size (N): 5 bits.MAX_ACK_REQUESTS: 5WINDOW_SIZE: 31 (with a maximum value of FCN=0b1011)Regular tile size: 10 bytesAll-1 tile size: 1 to 10 bytesRetransmission Timer: Application-dependent. The RECOMMENDED value is 12 hours.Inactivity Timer: Application-dependent. The RECOMMENDED value is 12 hours.RCS size: 32 bitsWhen 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 and , 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 ), SCHC Aborts and ACK Request used in SCHC over All Uplink ACK-on-Error mode. 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. 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).SCHC Compound ACKThe present document describes an extension to the SCHC (Static Header Compression and Fragmentation) protocol. It defines a SCHC Compound ACK message
format, which is intended to reduce the number of Downlink transmissions (i.e., SCHC ACKs) by accumulating bitmaps of several windows in a single SCHC message
(i.e., the SCHC Compound ACK). The message format is generic, and can be used for instance by any the four LWPAN technologies defined in , being Sigfox, LoRaWAN, NB-IoT and IEEE 802.15.4w. SCHC over Sigfox LPWANThe Generic Framework for Static Context Header Compression and
Fragmentation (SCHC) specification describes two mechanisms: i) an
application header compression scheme, and ii) a frame fragmentation
and loss recovery functionality. SCHC offers a great level of
flexibility that can be tailored for different Low Power Wide Area
Network (LPWAN) technologies.
The present document provides the optimal parameters and modes of
operation when SCHC is implemented over a Sigfox LPWAN. This set of
parameters are also known as a "SCHC over Sigfox profile. SCHC over NBIoTThe Static Context Header Compression and Fragmentation (SCHC)
specification, RFC8724, describes header compression and
fragmentation functionalities for Low Power Wide Area Networks
(LPWAN) technologies. The 3rd Generation Partnership Project (3GPP)
and the Narrowband Internet of Things (NB-IoT) architectures may
adopt SCHC to improve their capacities.
This I-D describes the use of SCHC over the NB-IoT architecture and
provides the configuration in each case. If 3GPP adopts SCHC, then
this I-D recommends some values.