Housekeeping Compression

Conformance Statement for pkg/rhc, CCSDS 124.0-B-1

This standard carries its own Implementation Conformance Statement proforma in annex A, which is normative. What follows fills it in, and then adds the detail the five-item requirements list does not have room for.

A2.1 GENERAL INFORMATION

A2.1.1 Identification of ICS

A2.1.2 Identification of Implementation Under Test

A2.1.3 Identification of Supplier

A2.1.4 Identification of Specification

Every mandatory requirement is supported. The exceptions section below records what is not in the standard and therefore had to be decided here.

A2.2 REQUIREMENTS LIST

Table A-1: Requirement List (the standard's own)

Table A-2: Parameters (the standard's own)

A2.3 DETAIL BEYOND THE PROFORMA

The five-item list above is coarse, so this section breaks each item down.

Table B-1: Input and parameters (clause 3)

Table B-2: Mask update (clause 4)

Table B-3: Encoding functions (clause 5.2)

Table B-4: Encoding step (clause 5.3)

A2.4 EXCEPTIONS AND THINGS THE STANDARD LEAVES OPEN

The bit extraction order of equation 11

Equation 11 defines the bit extraction as

Two readings are possible, and they produce different bit streams. Since g_0 is the first selected position in transmission order, the concatenation as written leads with the bit at the last selected position, but an implementer could suspect the subscripts of merely reflecting clause 1.6.1's downward bit numbering, in which case a forward scan would be intended.

This implementation takes the reversed reading, on two grounds:

1. clause 1.6.1 fixes what the concatenation means. Equation 1 writes the left shift as a« = {ȧ_{N−2}, …, ȧ_1, ȧ_0, 0} and gives the worked example '10111' -> '01110', which is only consistent if the first listed term is the first transmitted bit. Applying the same convention to equation 11, BE transmits ȧ_{g(H−1)} first: the forward scan, reversed. The subscripts-are-just-numbering reading would need the example to come out '11100', and it does not.
2. Independent implementations agree. The VisionSpace PocketPlus C++ implementation reverses the extracted sequence at every bit-extraction site.

So Vector.Extract emits the reverse of the forward scan, at all three BE sites: k_t (equation 17/19) and the two compressed u_t branches (equation 22). The derived decompressor mirrors the reversal when consuming them. An earlier revision of this package used the forward reading; streams it produced do not decode against this one where a k_t or compressed u_t of two or more differing bits is involved.

No published test vector arbitrates the point (see below) so the reading rests on the two grounds given.

The decompressor is derived, not transcribed

CCSDS 124.0-B-1 specifies the compressor and nothing else. Its normative sections are clause 3, clause 4 and clause 5; the requirements list in annex A2.2.1 has five items and every one is an encoder item. There is no decoder section.

The decompressor here is the encoder run backwards. Clause 2.1 lists what a decompressor needs (the last reconstructed vector, a synchronized mask, and the unpredictable bit values) and the encoding is losslessly invertible, so the derivation is sound. But it is a derivation, and no published vector confirms it. What stands behind it instead:

• round trips across vector lengths from 1 to 1000 bits, all robustness levels, and every combination of the three flags;
• a mask-tracking test asserting the decompressor's mask equals the compressor's after every cycle, which catches drift long before it changes a reconstructed byte;
• the loss test below;
• two fuzz targets.

No test vectors are published

The standard contains no worked example of a complete output vector, and no companion Green Book exists (124x0g1.pdf returns 404). What could be pinned to published material has been: table 5-1, figure 5-1's counts, and the vector operation examples in clause 1.6.1's text. Everything above that level is verified by round trip and by hand-derived arithmetic with the equation cited.

Loss detection is the mission's, and this changes the API

Clause 2.2 says the standard "does not provide a mechanism for identifying the number of sequential output binary vectors that were lost", and suggests packet sequence counters. So Decompressor.NotifyLoss exists: the caller reports gaps, and only then can the decompressor tell whether the next output reaches back far enough.

Without NotifyLoss, a decompressor fed a stream with holes will reconstruct wrong bytes and not know. That is the standard's division of responsibility, not a defect here, but it is the single most important thing for an integrator to get right.

Likewise clause 2.2 disclaims sync markers: a corrupt or foreign vector that happens to parse will be accepted as genuine. Framing with a length field (space packets, for instance) is assumed.

The loss test drives this: 300-vector streams, robustness 0 through 7, drop rates 5% to 50%, gaps reported through NotifyLoss. Every vector the decompressor returns is asserted byte-identical to its original. It is allowed to refuse; it is never allowed to be wrong.

The trust model, and strict mode

The recovery gate above has a trust assumption worth stating plainly. After a reported gap, the decompressor accepts the next output when the gap is at most that output's effective robustness level V_t, a field the output vector declares about itself (clause 5.3.2.2), which nothing in the format lets a decompressor verify. The standard offers no integrity mechanism at all: no checksum, no signature, no sync marker. So the model is:

• Transport is trusted to deliver what was sent. Corruption and forgery are for the layers below, CRCs and FECFs on the space link, SDLS if the mission needs cryptographic integrity.
• The caller is trusted to report every gap. clause 2.2 makes loss detection the mission's job; NotifyLoss is how it is reported here.
• Given both, the output vector's own fields are believed: V_t included. A hostile or corrupt vector that survives the layers below can claim a reach of up to 15 and be believed, and the reconstruction it produces will be wrong.

For callers who will not extend the third trust across a gap, Config.Strict narrows the gate: after any reported loss (NotifyLoss, or an output that failed to parse), a strict decompressor refuses everything except an uncompressed output, the one kind that proves itself by carrying the whole input vector, rather than claiming a reach back to state the decompressor no longer has. The cost is availability: outputs between the gap and the next uncompressed one are refused even when their V_t is honest. Strict mode is this package's addition, not the standard's, and is off by default. Pinned by TestStrictModeWaitsForUncompressed.

Mission-tunable knobs exposed as configuration

Clause 3.3.2 makes three flags user-specified at every cycle and says nothing about when to set them. Rather than invent a policy, the flags are exposed directly through CompressWith and ForceNewMask/ForceSendMask/ForceUncompressed, with simple periodic knobs in Config for the common case:

No adaptive or loss-aware scheduling is built in. That is a mission heuristic and belongs above this package.

Vector length must be known in advance

Clause 3.3.2's note lists the parameters a decompressor need not be told: M0, R_t and the three flags. F is deliberately not among them, so Config.VectorLength is required on both sides. Where an uncompressed output carries F, it is checked against the configuration and a disagreement is ErrVectorLengthMismatch.

Implementation-defined limits