Static Context Header Compression

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Static Context Header Compression" – news · newspapers · books · scholar · JSTOR (November 2020) (Learn how and when to remove this message)

Static Context Header Compression (SCHC) is a standard compression and fragmentation mechanism defined in the IPv6 over LPWAN working group at the IETF. It offers compression and fragmentation of IPv6/UDP/CoAP packets to allow their transmission over the Low-Power Wide-Area Networks (LPWAN).

Low-Power Wide-Area Network (LPWAN) gathers the connectivity technologies tailored for Internet of Things (IoT), allowing for:

• long-range communication (up to 40 km),
• very low energy consumption (on the device side),
• and energy efficiency (for networks).

The trade-off for achieving these features includes severe limitation in terms of throughput and packet size supported.^[1] Also, LPWAN come with limitations on transmission modalities since, in order to save battery, devices are dormant most of the time and wake up only episodically to transmit and receive data for a short time window.

As a result, the LPWAN use their specific protocols, each adapted to their own specificities. Most importantly, they cannot carry IPv6, which was designed to allocate addresses to the billions of IoT connected devices.

In the early 2000s, the IETF produced the first wave of mature standards for compression and fragmentation:

• RoHC (Robust Header Compression) in 2001,
• and 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks) in 2007.

Yet, these compression schemes cannot fit the LPWAN specificities.^[2][3][4]

SCHC associates the benefits of the RoHC context, which provides high flexibility in the fields processing, and of the 6LoWPAN operations to avoid transiting fields that are known by the other side.^[4]

SCHC takes advantage of the LPWAN characteristics (no routing, highly predictable traffic format and content of messages) to reduce the overhead to a few bytes and save network traffic.

The SCHC compression is based on the notion of context. A context is a set of rules that describes the communication context, meaning the header fields. It is shared and pre-provisioned in both the end-devices and the core network. The "static context" assumes that the rule description does not change during transmission. Thanks to this mechanism, IPv6/UDP headers are in most cases reduced to a small identifier.

When compression is not enough, SCHC provides a fragmentation mechanism that works in 3 different ways:

In this mode the SCHC packet is separated in multiple fragments that are blindly sent to the receiver, if the receiver missed any one packet then it won't be able to re build the sent packet.

In this mode the concept of "windows" is used, windows have a predefined size, allowing the receiver to keep a count of which windows or windows parts have been received, at the moment the receiver gets the last fragment from the sender it will calculate which parts of the packets it has missed and send a message describing that to the sender. The sender will then initialize the retransmission of the missing packet parts.

In Ack-Always mode the same retransmission mechanism as for Ack-On-Error is used except that it is not done at the end of the transmission but for each window.

The Generic Framework for Static Context Header Compression and Fragmentation, RFC 8724 has been published in April 2020. It describes the generic framework that can be used on all LPWAN technologies, and more generally on all Internet networks.

Additional work is dedicated to the definition of standard parameter settings and modes of operation to optimize SCHC's performance according to the implemented protocols and the underlying LPWAN technologies:  

• RFC 9011: SCHC over LoRaWAN
• RFC 8824: SCHC for CoAP
• RFC 9363: YANG Data Model for SCHC
• RFC 9391: SCHC over NB-IoT
• SCHC over Sigfox
• SCHC over IEEE 802.15.4 networks
• OAM for LPWAN using SCHC

On May 17, 2022, The LoRa Alliance (global association of companies backing the open LoRaWAN® standard for the internet of things low-power wide-area networks) announced that LoRaWAN now seamlessly supports Internet Protocol version 6 (IPv6) from end-to-end.^[5] By expanding the breadth of device-to-application solutions with IPv6, LoRaWAN's addressable IoT market is also broadened to include internet based standards required in smart electricity metering and new applications in smart buildings, industries, logistics, and homes. The Alliance released a technical specification TS 10–1.0.0 to explain how to use SCHC as an adaptation layer to enable LoRaWAN end-devices to use IPv6-based stacks over LoRaWAN^[6] and expands its certification program to include SCHC over LoRaWAN® Enabling IPv6 Solutions.^[7]

In addition, SCHC is being adopted in a joint standardization effort carried out by the DLMS User Association and the LoRa Alliance for the smart metering industries.^[8][9]

• LPWAN: Low Power Wide Area Networks
• IPv6: Version 6 of the Internet Protocol
• 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Networks
• RoHC: Robust Header Compression
• CoAP: Constrained Application Protocol

• IPv6 over Low Power Wide-Area Networks (LPWAN) Working group at IETF
• RFC 8724 – SCHC: Generic Framework for Static Context Header Compression and Fragmentation
• RFC 9011 – SCHC over LoRaWAN
• RFC 8824 – SCHC for CoAP
• RFC 9363 – YANG Data Model for SCHC
• RFC 8376 – Low-Power Wide Area Network (LPWAN) Overview