## 3 Technical Background on SCHC and Cellular IoT
### SCHC Framework  
Static Context Header Compression and fragmentation (SCHC) is a generic framework that provides compression and fragmentation mechanisms. The framework is standardized in [37], taking into consideration constrained environments and constrained devices, which are typically found in LPWANs. Figure 1 shows the SCHC architecture. On the transmitter side, a protocol analyzer parses the packet, itemizes and labels each field and extracts its value. The protocol analyzer should be able to work with the adapted protocol stack (e.g., the DLMS/UDP/IP). However, the way it is implemented is not specified in the SCHC standard and is left to the implementer. Once the fields (and their values) of the protocols are identified, they are matched with the stored compression rules. The same compression rules are stored in advance in both the transmitter and the receiver. Then, the packet is compressed if the packet matches one of the stored rules. Otherwise, it is sent uncompressed. The result of these operations is called a SCHC packet. Fragmentation is applied if the SCHC packet is more than the Maximum Transmission Unit (MTU) supported by L2 layer. Figure 2 shows the compression and fragmentation mechanisms applied to a packet. As shown, the compression of headers yields a rule identifier (RuleID) and a compression residue. Fragmentation, if needed, adds its own headers to the chunk of the SCHC packets to form fragments. SCHC is based on using a set of rules that are defined in advance for communication. They describe the context for compressing or decompressing headers or structured data. Since the content of LPWAN packets is usually highly predictable, static contexts can be derived and stored. Indeed, the context must be stored ahead of time in both the sender (the compressor) and receiver (the decompressor). Note that the way the context is provisioned and shared is not standardized yet. Once the context is shared by the two sides of communication, the sender transmits the rule identifier (RuleID), which describes the rule used to compress the packet, followed by the compression residue, which consists of the remainder of bits after compression. Every rule contains a list of field descriptors, composed of  
* A Field Identifier (FID), which designates a protocol and field, such as a UDP Destination Port. * The Field Length (FL), which represents the length of the field. The length can be either fixed or variable. * The Field Position (FP), which represents the occurrence of the field. In most cases, a field only occurs once in a packet header. However, some fields may occur multiple times, such as in CoAP. * A Direction Indicator (DI), which indicates the packet direction. * The Target Value (TV), which is the value used to match against the field. The TV can be a scalar value of any type or a more complex structure, such as an array. * A Matching Operator (MO), which is the operator used to match the field value and the TV. * The Compression/Decompression Action (CDA), which describes the actions that are performed at the compressor to compress the field and at the decompressor to recover the original value of the field. An example of a rule for compressing the headers of IPv6/UDP is presented in Table 2. The table shows the fields of the IPv6 and UDP headers with the corresponding field descriptors, including the Field Identifier (FID), Field Length (FL), Field Position (FP), Direction Indicator (DI), Target Value (TV), Matching Operator (MO) and Compression/Decompression Action (CDA). In this example, the compression rule is designed for packets between a device (Dev) and an application (App) with global IPv6 address prefixes (alpha:IID/64 to gamma:1/64). While several fields have static values, such as IPv6 version, the value of some fields can be ignored, such as IPv6 length. As such, their values can be elided (not sent) at the transmitter and can be retrieved at the receiver from the compression rule or through computation.