Static Context Header Compression

Les réseaux étendus à faible consommation d'énergie (LPWAN) regroupent les technologies de connectivité adaptées à l'Internet des objets (IoT), permettant :

• une communication très longue portée (jusqu'à 40 km),
• une très faible consommation d'énergie (côté objet connecté),
• et efficacité énergétique (côté réseaux).

Pour atteindre ces fonctionnalités, un compromis est réalisé sur les débits et la taille des paquets pris en charge (RFC 8376[2]). De plus, les LPWAN comportent des limitations sur les modalités de transmission car, afin d'économiser la batterie, les appareils sont dormants la plupart du temps et ne se réveillent que de manière épisodique pour transmettre et recevoir des données pendant une courte période.

De ce fait, les LPWAN utilisent leurs protocoles spécifiques, chacun adapté à ses propres spécificités. Plus important encore, ils ne peuvent pas transporter IPv6, qui à la base a été conçu pour attribuer des adresses aux milliards d'appareils connectés à l'IoT.

Au début des années 2000, l'IETF a produit la première vague de normes matures pour la compression et la fragmentation :

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

Pourtant, ces schémas de compression ne peuvent pas s'appliquer aux spécificités LPWAN[3] - [4] - [5]

SCHC associe les avantages du contexte RoHC, qui offre une grande flexibilité dans le traitement des champs et des opérations 6LoWPAN, pour éviter le transit de champs déjà connus par l'autre partie.[5]

Dans ce mode, le paquet SCHC est séparé en plusieurs fragments qui sont envoyés aveuglément au récepteur. Si le récepteur a manqué un paquet, il ne sera pas en mesure de reconstruire le paquet envoyé.

Dans ce mode, on utilise le concept de "fenêtres". Les fenêtres ont une taille prédéfinie, permettant au récepteur de pointer quelles fenêtres ou parties de fenêtres qui ont été reçues. Au moment où le récepteur obtient le dernier fragment envoyé par l'expéditeur, il calculera quelles parties des paquets sont manquantes et en informera l'expéditeur. L'expéditeur initialisera alors la retransmission des parties de paquet manquantes.

En mode Ack-Always, un mécanisme de retransmission similaire à Ack-On-Error est utilisé à la différence que l'acquittement n'est pas effectué à la fin de la transmission mais pour chaque fenêtre.