Skip to main content
Version: 4.0

SCHC by Acklio

🔤 Acronyms? See the Glossary

SCHC (pronounce "chic") is the acronym for Static Context Header Compression, a standard compression and fragmentation mechanism defined by the IPv6 over LPWAN working group (driven by Acklio) at the IETF.

SCHC

Standards​

DesignationIETF StandardUsage
SCHCRFC 8724The global Compression & Fragmentation mechanism
SCHC over LoRaWANRFC 9011The L2 technology adaptation
SCHC for CoAPRFC 8824The application adaptation

Principle​

The principle is to transport legacy protocol data sent by connected objects in IPv6/UDP/DLMS (or IPv6/UDP/CoAP) packets that are compressed and fragmented with the SCHC mechanism, to make them transportable over the LPWAN radio link.

Acklio's SCHC

1️⃣ Static Context​

Prevent from continuous synchronization, save bandwidth.

SCHC architecture prevents continuous synchronization between elements communicating on the network. Synchronization is actually the operation that consumes the most bandwidth.

Communication Context​

In LPWAN networks, the nature of data flows is highly predictable. The communication context is a collection of header fields that are recurring and not relevant, in comparison with the payload that contains the metering data.

Acklio stores these communication contexts both in the device and in the network management platform rather than saturating the bandwidth with such information. By reducing the amount of data transmitted over radio connectivity, using IP becomes possible.

Rules​

SCHC mechanism translates the communication context into rule set having a RuleID. It is shared and pre-provisioned both in the connected objects and in the central network, so that sender and recipient keep a same set of rules to describe the communication. A "static" context assumes that the description of the rule does not change during transmission.

SCHC Adaptation Layer

With this mechanism, IPv6/UDP headers are reduced to a RuleID of 1 byte (in most cases) within the LoRaWAN frame.

Rule sets can be designed in advance and modeled in templates.

2️⃣ Header Compression​

Constraint is frame size.

Data compression is an encoding operation that shortens the size of data transmission and/or storage. The data is restored by a decompression algorithm.

LPWAN technologies have severe constraints concerning the frame size, i.e. the size of messages that can be sent at a time. This is due to their low data rates, frame loss, and regulatory rules.

The IETF already produced compression schemes in the early 2000s (RoHC in 2001, and 6LOPWAN in 2007) but these compression mechanisms cannot be applied "as-is" to LPWAN specific networks.

  • RoHC – This method for compressing IP, UDP, RTP and TCP headers of network packets is complex since the compression depends on a steep learning phase that varies with the network traffic and the data flows.
  • 6LOWPAN – These encapsulation and header compression mechanisms allow IPv6 packets to be sent and received over IEEE 802.15.4 networks. However, the mechanisms are difficult to implement in network sensors and other constrained systems because of the large size of the headers (among others).

Since 2019, SCHC's header compression mechanism however makes it possible to transmit IPv6/UDP/CoAP packets over low-power wide-area networks (LPWANs). By taking advantage of the features of LPWANs (no routing, traffic format, and highly predictable message content) it reduces the overhead to a few bytes and saves network traffic. And solves the difficulty encountered by RoHC and 6LOWPAN mechanisms by the fact.

3️⃣ Fragmentation​

Constraints are frame size and downlink.

Fragmentation is actually a feature of IPv4 and IPv6 that splits an initial packet into smaller fragments named datagrams so that the resulting fragments can be transmitted over a link with a maximum transmission unit smaller than the packet size. Once received by the destination, a reassembly mechanisms reconstructs the packet. Fragmentation and reassembly are allowed for source and destination only.

A datagram is a data packet transmitted with its source and destination addresses over a telecommunications network (WAN) or a local area network (LAN).

  • Constraint is downlink – SCHC includes fragmentation/reassembly to transmit a larger packet size than the LoRaWAN payload size and thus save the downlink.
  • Constraint is physical – SCHC also incorporates a fragmentation for cases where compression is not sufficient to fit the limitations of the underlying technology. In other words, SCHC splits the messages according to the network requirements and manages their transmission in the network.

SCHC's fragmentation mechanisms can work in three different modes: "No-Ack", "Ack-On-Error" (default), or "Ack-Always".

More about the modes
  • No-Ack – In this mode, the SCHC packet is split into several fragments which are blindly sent to the receiver. If the receiver missed a packet, it will not be able to reconstruct the sent packet.
  • Ack-On-Error – In this mode, the concept of "windows" is used. The windows have a predefined size, allowing the receiver to point out which windows or parts of windows have been received. The moment the receiver gets the last fragment sent from the sender, it will calculate which parts of the packets are missing and notify the sender. The sender will then initiate retransmission of the missing packet parts.
  • Ack-Always – In this mode, a retransmission mechanism similar to Ack-On-Error is used, with the difference that the acknowledgment is not made at the end of the transmission but for each window.