Static Context Header Compression and Fragmentation (SCHC) over LoRaWAN
Extracted elements (26)
The DTag field size is set to 0 bits (not used) because a LoRaWAN device cannot interleave several fragmented SCHC datagrams on the same FPort. Multiple SCHC gateways can still be addressed using distinct sets of FPorts.
The IID is derived from AES-128-CMAC over the DevEUI using the AppSKey, rather than being derived directly from the DevEUI. Since AppSKey is renewed at each LoRaWAN join, the IID changes over time, mitigating location tracking and preventing attackers from using the manufacturer OUI to target devices.
The profile does not define a delay after each LoRaWAN frame to comply with local spectrum regulations; compliance is expected to be enforced by the underlying LoRaWAN stack rather than the SCHC layer.
Recommended fragmentation RuleID values are: RuleID=20 (FPortUp, uplink fragmentation), RuleID=21 (FPortDown, downlink fragmentation), and RuleID=22 for uncompressible packets where no matching compression Rule was found.
All padding bits MUST be 0.
Following an All-0 downlink SCHC Fragment, the Class A device MUST transmit the SCHC ACK message and MUST transmit up to MAX_ACK_REQUESTS SCHC ACK messages before aborting.
For battery-powered devices, the SCHC receiver SHOULD send a SCHC ACK after every window even if there are no missing tiles, and the SCHC sender SHOULD wait for the SCHC ACK before sending tiles from the next window. This avoids useless uplinks when network coverage is lost.
Implementations MUST implement and SHOULD use an IID computation algorithm: key = AppSKey, cmac = aes128_cmac(key, DevEUI), IID = cmac[0..7]. This mitigates risks from RFC 8064 and RFC 8065 regarding stable and privacy-preserving interface identifiers.
SCHC_ACK_REQ_DN_OPPORTUNITY MUST be greater than 1. Its recommended value is 2. This allows higher-priority downlinks to be delivered before the SCHC ACK REQ message.
SCHC implementations MUST be compatible with both the per-window ACK behavior and the end-of-all-windows ACK behavior; the selection is part of the rule context.
The device MUST keep the SCHC ACK message in memory until it receives a downlink SCHC Fragmentation Message (with FPort == FPortDown) that is not a SCHC ACK REQ, which indicates the SCHC gateway has received the SCHC ACK.
The FPending bit in the LoRaWAN protocol SHOULD NOT be used for the SCHC-over-LoRaWAN protocol; it may be set by the Network Gateway for other purposes but not for SCHC needs.
The Network Gateway MUST identify devices by a unique 64-bit DevEUI when communicating with the SCHC gateway. The 32-bit DevAddr used over the air is translated to DevEUI at the Network Gateway.
The RuleID MUST be 8 bits and encoded in the LoRaWAN FPort field. The uplink and downlink fragmentation FPorts MUST be different to distinguish fragmented datagram directions.
The SCHC C/D and SCHC F/R in the device and the SCHC gateway MUST share the same set of rules. Without shared rules, compression and decompression cannot function correctly across the LoRaWAN link.
Deriving the IID from the AppSKey and DevEUI ensures no correlation between the hardware identifier (DevEUI) and the IID. The IID changes with each LoRaWAN session join, mitigating location tracking and long-term correlation attacks.
Downlink fragmentation parameters: ACK-Always mode for unicast, No-ACK for multicast (OPTIONAL for gateway, REQUIRED for device). RuleID 8 bits in FPort, DTag 0 bits, FCN N=1 bit (WINDOW_SIZE=1 tile), Window index M=1 bit, MAX_ACK_REQUESTS=8. Tile size equals current available MTU.
The LoRaWAN FPort field (8 bits, values 1–223) serves as the RuleID in the SCHC-over-LoRaWAN profile. The SCHC C/D and F/R SHALL concatenate FPort with LoRaWAN payload to recompose the SCHC Message.
Uplink fragmentation parameters: ACK-on-Error mode, SCHC header 2 bytes (FPort + 1 byte), RuleID 8 bits in FPort, DTag 0 bits, Window index M=2 bits (4 windows), FCN N=6 bits (WINDOW_SIZE=63 tiles), tile size 10 bytes, MAX_ACK_REQUESTS=8. MTU = 4×63×10 = 2520 bytes.
Uplink fragmentation uses ACK-on-Error mode; downlink fragmentation uses ACK-Always mode for unicast and No-ACK for multicast. A LoRaWAN device cannot support simultaneous interleaved fragmented datagrams in the same direction.
SCHC data (LoRaWAN payload) is protected at the LoRaWAN level by AES-128 encryption using a session key shared by the device and the SCHC gateway. These session keys are renewed at each LoRaWAN session (each join or rejoin). This document introduces no new security issues beyond those identified in RFC 8724.
Downlink All-1 fragment (last): FPort/RuleID (8 bits) | W (1 bit) | FCN=b'1 (1 bit) | RCS (32 bits) | Payload (6 to X bits) | Optional padding (0–7 bits).
Downlink regular fragment (all but last): FPort/RuleID (8 bits) | W (1 bit) | FCN=b'0 (1 bit) | Payload (X bytes + 6 bits). SCHC header is 10 bits including FPort.
Uplink All-1 SCHC fragment (last fragment, with optional last tile): FPort/RuleID (8 bits) | W (2 bits) | FCN=All-1 (6 bits) | RCS (32 bits) | Last tile (1–80 bits, optional) | Optional padding (0–7 bits).
Uplink Receiver-Abort format: FPort/RuleID (8 bits) | W=b'11 (2 bits) | C=1 (1 bit) | b'11111 (5 bits) | 0xFF (8 bits, one full L2 Word after the L2 Word boundary).
Uplink regular fragment (all except last): FPort/RuleID (8 bits) | W (2 bits) | FCN (6 bits) | Payload. Total SCHC header is 16 bits including FPort.