LPWAN Static Context Header Compression (SCHC) for IPv6 and UDP

Headers compression is mandatory to bring the internet protocols to the node within a LPWA network . Nevertheless, LPWA networks offer good properties for an efficient header compression: Topology is star oriented, therefore all the packets follows the same path. For the needs of this draft, the architecture can be summarized to End-Systems (ES) exchanging information with LPWAN Application Server (LA). The exchange goes trhough a single LPWA Compressor (LC). In most of the cases, End Systems and LC form a star topology. ESs and LC maintain a static context for compression. Static context means that context information is not learned during the exchange. Traffic flows are mostly deterministic, since End-Systems embed built-in applications. Contrary to computers or smartphones, new applications cannot be easily installed. First mechanisms such as RoHC use a context to store header field values and send smaller incremental differences on the link. The first version of RoHC targeted IP/UDP/RTP stack. RoHCv2 extends the principle to any protocol and introduces a formal notation describing the header and associating compression functions to each field. To be efficient the sender and the receiver must check that the context remains synchronized (i.e. contains the same values). Context synchronization imposes to periodically send a full header or at least dynamic fields. If fully compressed, the header can be compatible with LPWA constraints. However, the first exchanges or context resynchronisations impose to send uncompressed headers, which may be bigger than the original one. This will force the use of inefficient fragmentation mechanisms. For some LPWA technologies, duty cycle limits can also delay the resynchronization. illustrates this behavior.

| | t| | | +--+ | header size of sent packets | +--+ | +------------+ +------------+ ]]> On the other hand, 6LoWPAN is context-free based on the fact that IPv6, its extensions or UDP headers do not contain incremental fields. The compression mechanism described in is based on sending a 2-byte bitmap, which describes how the header should be decompressed, either using some standard values or sending information after this bitmap. also allows for UDP compression. In the best case, when Hop limit is a standard value, flow label, DiffServ fields are set to 0 and Link Local addresses are used over a single hop network, the 6LoWPAN compressed header is reduced to 4 bytes. This compression ratio is possible because the IID are derived from the MAC addresses and the link local prefix is known from both sides. In that case, the IPv6 compression is 4 bytes and UDP compression is 2 bytes, which fills half of the payload of a SIGFOX frame, or more than 10% of a LoRaWAN payload (with spreading factor 12). The Static Context Header Compression (SCHC) combines the advantages of RoHC context, which offers a great level of flexibility in the processing of fields, and 6LoWPAN behavior to elide fields that are known from the other side. Static context means that values in the context field do not change during the transmission, avoiding complex resynchronization mechanisms, incompatible with LPWA characteristics. In most of the cases, IPv6/UDP headers are reduced to a small context identifier.

Static Context Header Compression (SCHC) avoids context synchronization, which is the most bandwidth-consuming operation in RoHC. Based on the fact that the nature of data flows is highly predictable in LPWA networks, a static context may be stored on the End-System (ES). The other end, the LPWA Compressor (LC) can learn the context through a provisioning protocol during the identification phase (for instance, as it learns the encryption key). The context contains a list of rules (cf. ). Each rule contains itself a list of field descriptions composed of a target value (TV), a matching operator (MO) and a Compression/Decompression Function (CDF).

The rule does not describe the compressed/decompressed packet format which must be known from the compressor/decompressor. The rule just describes the compression/decompression behavior for a field. The main idea of the compression scheme is to send the rule number (or rule id) to the other end instead of known field values. Matching a field with a value and header compression are related operations; If a field matches a rule containing the value, it is not necessary to send it on the link. Since contexts are synchronized, reading the rule's value is enough to reconstruct the field's value at the other end. On some other cases, the value need to be sent on the link to inform the other end. The field value may vary from one packet to another, therefore the field cannot be used to select the rule id.

A simple header is composed of 3 fields (F1, F2, F3). The compressor receives a packet containing respectively [F1:0x00, F2:0x1230, F3:0xABC0] in those fields. The Matching Operators (as defined in ) allow to select Rule 5 as represented in ; F1 value is ignored and F2 and F3 packet field values are matched with those stored in the rule Target Values.

The Compression/Decompression Function (as defined in describes how the fields are compressed. In this example, all the fields are elided and only the rule number has to be sent to the other end. The decompressor receives the rule number and reconstructs the header using the values stored in the Target Value column. Note that F1 value will be set to 0x00 by the decompressor, even if the original header field was carrying a different value. To allow a range of values for field F2 and F3, the MSB() Matching Operator and LSB() Compression/Decompression Function can be used (as defined in and ). In that case the rule will be rewritten as defined in .

In that case, if a packet with the following header fields [F1:0x00, F2:0x1234, F3:0xABCD] arrives to the compressor, the new rule 5 will be selected and sent to the other end. The compressed header will be composed of the single byte [0x4D]. The decompressor receives the compressed header and follows the rule to reconstruct [0x00, 0x1234, 0xABCD] applying a OR operator between the target value stored in the rule and the compressed field value sent.

The compression/decompression process follows several steps: compression rule selection: the goal is to identify which rule will be used to compress the headers. To each field is associated a matching rule for compression. Each header field's value is compared to the corresponding target value stored in the rule for that field using the matching operator. If all the fields satisfied the matching operator, the packet is processed using this Compression Decompression Function functions. Otherwise the next rule is tested. If no eligible rule is found, then the packet is dropped. sending: The rule number is sent to the other end followed by data resulting from the field compression. The way the rule number is sent depends of the layer two technology and will be specified in a specific document. For exemple, it can either be included in a Layer 2 header or sent in the first byte of the L2 payload. decompression: The receiver identifies the sender through its device-id (e.g. MAC address) and select the appropriate rule through the rule number. It applies the compression decompression function to reconstruct the original header fields.

It may exist some intermediary cases, where part of the value may be used to select a field and a variable part has to be sent on the link. This is true for Least Significant Bits (LSB) where the most significant bit can be used to select a rule id and the least significant bits have to be sent on the link. Several matching operators are defined: equal: a field value in a packet matches with a field value in a rule if they are equal. ignore: no check is done between a field value in a packet and a field value in the rule. The result is always true. MSB(length): a field value of length T in a packet matches with a field value in a rule if the most significant "length" bits are equal.

The Compression Decompression Functions (CDF) describe the action taken during the compression and inversely the action taken by the decompressor to restore the original value.

lists all the functions defined to compress and decompress a field. The first column gives the function's name. The second and third columns outlines the compression/decompression process. As with 6LoWPAN, the compression process may produce some data, where fields that were not compressed (or were partially compressed) will be sent in the order of the original packet. Information added by the compression phase must be aligned on byte boundaries, but each individual compression function may generate any size.

gives an example of function assignment to IPv6/UDP fields.

The compressor do not sent the field value on the link. The decompressor restore the field value with the one stored in the matched rule.

The compressor send the field value on the link, if the matching operator is "=". Otherwise the matching operator indicates the information that will be sent on the link. For a LSB operator only the Least Significant Bits are sent.

The compressor sends the "length" Least Significant Bits. The decompressor combines with a OR operator the value received with the Target Value.

These functions are used to process respectively the End System and the LA Device Identifier (DID). The IID value is computed from device ID present in the Layer 2 header. The computation depends on the technology and the device ID size.

These functions compute the field value based on received information. They are elided during the compression and reconstructed during the decompression. compute-ipv6-length: compute the IPv6 length field as described in . compute-udp-length: compute the IPv6 length field as described in . compute-udp-checksum: compute the IPv6 length field as described in .

This section gives some scenarios of the compression mechanism for IPv6/UDP. The goal is to illustrate the SCHC behavior.

The most common case will be a LPWA end-system embeds some applications running over CoAP. In this example, the first flow is for the device management based on CoAP using Link Local addresses and UDP ports 123 and 124. The second flow will be a CoAP server for measurements done by the end-system (using ports 5683) and Global Addresses alpha::IID/64 to beta::1/64. The last flow is for legacy applications using different ports numbers, the destination is gamma::1/64. presents the protocol stack for this end-system. IPv6 and UDP are represented with dotted lines since these protocols are compressed on the radio link.

Note that in some LPWA technologies, only End Systems have a device ID . Therefore it is necessary to define statically an IID for the Link Local address for the LPWA Compressor.

All the fields described in the three rules are present in the IPv6 and UDP headers. The ESDevice-ID value is found in the L2 header. The second and third rules use global addresses. The way the ES learn the prefix is not in the scope of the document. One possible way is to use a management protocol to set up in both end rules the prefix used on the LPWA network. The third rule compresses port numbers on 4 bits. This value is selected to maintain alignment on byte boundaries for the compressed header.

Thanks to Dominique Barthel, Arunprabhu Kandasamy, Antony Markovski, Alexander Pelov, Juan Carlos Zuniga for useful design consideration.