73% Payload Reduction on Live NB-IoT Hardware: Validating ALEC Compression on Nordic nRF9151

NB-IoT and satellite IoT deployments face a bandwidth problem that conventional compression cannot solve: messages are too small, too frequent, and must be transmitted immediately without buffering.

This article presents the hardware validation of ALEC v1.3.1 — an open-source streaming codec for IoT sensor time-series — running on a Nordic nRF9151 development kit under Zephyr OS. Across 300+ messages on a live NB-IoT link, ALEC achieved a stable 73 percent payload reduction versus JSON, outputting 17 bytes per message from a 5-channel sensor frame. The full demo stack — firmware, backend decoder, and Grafana dashboard — is open source.

The Problem: JSON on Constrained Networks

When you deploy a battery-powered IoT sensor over NB-IoT or satellite, the dominant engineering concerns are signal coverage and battery life. But there is a third variable quietly draining both: the payload format.

A typical 5-channel sensor reading serialized as JSON — temperature, humidity, pressure, timestamp, sequence — produces approximately 62 bytes per message. On NB-IoT, this triggers an RRC connection cycle for each transmission. More bytes means longer connection time, higher radio power draw, and greater retransmission risk at marginal signal quality.

General-purpose compression algorithms (gzip, LZ4, zstd) cannot help here. They require large input buffers to build dictionaries and achieve meaningful ratios. On 40–62 byte payloads transmitted one at a time, they expand the data rather than compress it. The environments most in need of compression are precisely where traditional methods fail.

ALEC: Asymmetric Streaming Compression

ALEC (Adaptive Lazy Evolving Compression) is a streaming codec designed specifically for IoT sensor time-series. Its core insight is that sensor data is temporally correlated — temperature does not jump 10°C between readings, pressure drifts slowly, humidity follows diurnal patterns. Rather than treating each message in isolation, ALEC exploits this predictability.

The architecture is deliberately asymmetric:

• On-device encoder: A minimal Rust library (no_std, C FFI) compiled for thumbv8m.main-none-eabi. No heap beyond initial allocation. Links directly into Zephyr firmware.
• Server-side decoder: Full Rust std, maintaining evolving context across messages. All computationally intensive work stays off the battery.

As the encoder accumulates context — observing how each channel evolves over time — it selects progressively more efficient per-channel encoding strategies: Repeated (0 bytes when value unchanged), Delta8 (1 byte for small changes), Delta16 (2 bytes for moderate changes), Raw32 (fallback). The shared context persists across messages, eliminating per-message dictionary overhead.

Figure 1: ALEC demo stack architecture. The nRF9151 encoder outputs 17 B/message over NB-IoT; the server-side decoder reconstructs full sensor data and feeds Prometheus metrics to Grafana.

Hardware Validation: Nordic nRF9151 / Zephyr OS / NB-IoT

The validation used a Nordic nRF9151 SMA-DK development kit running Zephyr OS v3.7, transmitting over a live NB-IoT connection to an MQTT broker (HiveMQ public). The test simulated a deterministic slow-drift 5-channel sensor — representative of real-world industrial or agricultural monitoring.

Test configuration:

• 5 channels: temperature (°C), humidity (%RH), pressure (kPa), timestamp (Unix), sequence number
• Message cadence: 5 seconds
• Total messages validated: 300+
• ALEC version: 1.3.1 (alec + alec-ffi crates, crates.io)

Results — per-message payload size:

• JSON equivalent: 61–62 B
• Packed binary struct: 20 B (~68 percent savings)
• ALEC v1.3.1 compressed: 17 B (73 percent savings) ✓

Message #0 (cold start, full context initialization) outputs 47 bytes. By message #1, the encoder has sufficient context to apply Delta encoding, dropping to 16 bytes. From message #13 onward, the output stabilizes at 17 bytes with zero variance — the encoder has fully characterized each channel's drift pattern. This stability held across the entire 300+ message run with no outliers.

Figure 2: Live Grafana dashboard during validation run. Savings vs JSON panel (bottom) shows a 73 percent reduction flat across the full run, with a peak reaching 80 percent during favorable encoding conditions. Message count: 306.

What Changed in v1.3.1

This release focused on protocol-level efficiency improvements:

• Header: 13 B → 10 B — sequence field reduced from u32 to u16, context_version serialized in 3 bytes instead of 4
• name_id: 2 B → 1 B per channel — saves 5 B on a 5-channel frame
• Timestamp bug fix — was storing milliseconds instead of Unix seconds, causing a 49-day overflow on sequence numbers

Total saving versus v1.3.0: up to 8 bytes per frame on a 5-channel payload. Small numbers at the message level; meaningful at scale across thousands of devices transmitting continuously.

Why This Matters for NB-IoT and Satellite IoT

On NB-IoT, airtime cost is dominated by RRC connection overhead, not raw data volume. But smaller payloads directly reduce connection duration and retransmission probability — particularly at the cell edge where the signal is marginal, and every additional byte increases the chance of requiring a retransmit.

On satellite IoT (LoRaWAN-from-space, NB-NTN), the economics are starker. Link budgets are constrained by orbital geometry, and per-byte costs at the application layer reflect real infrastructure cost. A 73 percent reduction is not a benchmark curiosity — it changes the economic model for continuous monitoring use cases.

The critical distinction from general-purpose compression is the per-message guarantee: ALEC achieves positive compression on individual 17-byte outputs without any buffering. gzip on a 17-byte input produces 35 bytes. This is the threshold where traditional codecs fail, and ALEC operates.

Open Source Demo Stack

The complete validation stack is open source and reproducible:

• Firmware (Zephyr C + alec-ffi): github.com/zeekmartin/alec-nrf9151-demo
• Codec library: crates.io/crates/alec (v1.3.1, AGPL-3.0)
• C FFI bindings: crates.io/crates/alec-ffi (v1.3.1)
• Live simulation (no hardware required): demo.alec-codec.com

The backend uses a Rust MQTT decoder service exposing Prometheus metrics, consumed by Grafana. The Docker Compose stack deploys in a single command.

What's Next: v1.4 Pattern and Interpolated Encoding

The current 73 percent result is achieved with Delta encoding — efficient on slowly drifting signals, but still transmitting a delta byte for every channel every message. The next release will implement two additional encoding strategies:

• Pattern encoding (EncodingType::Pattern): targets 80–95 percent compression on periodic signals — day/night cycles, consumption curves, HVAC patterns — by encoding channel behavior as a repeating template.
• Interpolated encoding (EncodingType::Interpolated): outputs near-zero bytes when exponential moving average prediction converges with the actual value — targeting smooth sensor curves in stable environments.

The honest claim for the current release is 65–73 percent on single-message NB-IoT. The 80–95 percent figure applies to gateway-level batching or v1.4 pattern encoding on periodic signals — not yet validated on hardware.

Conclusion

ALEC v1.3.1 delivers validated 73 percent payload compression on live NB-IoT hardware — stable, lossless, and operating per-message without buffering. The validation confirms the core value proposition: a minimal on-device Rust encoder produces dramatically smaller payloads that reduce airtime, battery draw, and transmission cost on constrained networks. 

The full stack is open source under AGPL-3.0, with commercial licensing available for embedded integration. Documentation and live simulation at alec-codec.com.