Compression & QoS Scheduling — CCSDS 121/122 and Deadline-Aware Forwarding

Compression: Multiplying Effective Bandwidth

On a bandwidth-starved interplanetary link, compression is not optional — it is the difference between delivering a day's science data and losing it. AETHERIX compresses every TrafficItem before it competes for the link, so the scheduler plans against transmitted bytes, not raw bytes.

The compression profiles are representative ratios from CCSDS standards and the data-compression literature:

Key formulas:

reduction_percent = 100 × (1 − 1/ratio)
compressed_bytes  = round(original_bytes / ratio)
tx_time           = (compressed_bytes × 8) / link_rate_bps

Lossless CCSDS 121.0-B-3 (Rice/adaptive coding) is mandatory for telemetry and command data where a single flipped bit is a mission hazard. Lossy CCSDS 122.0-B-2 (wavelet compression) is reserved for imagery and video where a 10× to 50× reduction is worth the fidelity cost. The distinction is not academic: a corrupted command byte could send a rover the wrong instruction, while a slightly degraded panorama is acceptable.

CCSDS 121.0-B-3: Lossless Data Compression

The Rice coder (and its adaptive variant) exploits the fact that many instrument telemetry streams have a predictable low-entropy structure — successive samples are similar, so the residual after prediction is small. Rice coding maps small residuals to short codewords and large residuals to longer ones, achieving 2–4× compression on typical telemetry with zero information loss. The standard is specifically designed for space: low complexity, deterministic execution time, suitable for radiation-hardened processors with limited clock speed.

CCSDS 122.0-B-2: Image Data Compression

The CCSDS wavelet image compressor uses a discrete wavelet transform (DWT) followed by bit-plane encoding. It offers both lossless (integer DWT, ~2× ratio) and lossy (floating-point DWT, up to 10×+ ratio) modes. For Mars imagery, the lossy mode is typically used for panoramas (10× reduction: an 8 GB raw image becomes 800 MB, fitting in a single contact), while lossless is reserved for scientific measurements where every pixel value matters.

The Deadline-Aware QoS Scheduler

QoSScheduler plans a single finite contact window. It is strict-priority and deadline-aware: an item is delivered only if it both fits in the remaining contact time and completes before its own deadline.

The scheduling algorithm:

1. Sort items by (category.rank ASC, deadline_s ASC)
2. t = 0
3. For each item in order:
   remaining = contact_duration - t
   duration  = (item.effective_bytes × 8) / link_rate_bps
   finish    = t + duration

   if remaining ≤ 0:
       DEFER (contact ended)
   elif finish ≤ contact_duration AND finish ≤ item.deadline:
       DELIVER; t = finish
   elif finish > deadline AND duration ≤ remaining:
       DEFER (would miss deadline → let next item try)
   elif item.fragmentable:
       FRAGMENT: send partial, remainder next contact
   else:
       DEFER (NO_FRAGMENT, exceeds window)

The Four Decision Branches

BPv7 Fragmentation: Why Partial Sends Are Safe

When an item is too large for the remaining contact, BPv7 fragmentation allows sending part of it now and the remainder on the next contact. The remainder carries the IS_FRAGMENT flag and is reassembled downstream using the offset and total-length fields in the primary block (RFC 9171 §4.3.1; fragmentation procedure is §5.8). This is what makes the scheduler aggressive about link utilization: it never wastes the last minutes of a contact window — if 60% of a large bundle fits, that 60% is sent.

The TrafficItem dataclass has a fragmentable flag (defaulting to True) that maps to the BPv7 NO_FRAGMENT processing control flag. Items with time-critical content (like emergency alerts) may set fragmentable=False to ensure they are sent complete or not at all.