Framing Format¶
The SRS-3 transmits and receives fixed size frames on the radio interface. Payload data size and FEC options are individually configurable through system properties for the transmitter and receiver. The actual length of transmissions is a function of the configured payload data size and FEC options as described below. The maximum payload data size is currently fixed at 1024 bytes.
The figure below shows the frame structures with the default payload data size of 217 bytes. Although the radio interface uses fixed size frames, the data contents can be variable length (up to the configured maximum). A two byte header is always prepended to every frame, to specify the content type and actual length of the data. The system supports encapsulation of two different frame types in the payload field: CSP frames and IP frames. Protocol overhead must also fit in the payload data field, so in the default configuration the maximum CSP MTU is 213 bytes because the CSP header occupies 4 byte of the payload field.
After the header is prepended, the frame is zero-padded to the configured frame size plus the header size (219 bytes in the example). A CRC32C checksum can optionally be appended to the frame for increased error detection.
If the tx.rs
property is set to true
, a (255,223) Reed-Solomon code is used to append 32 parity bytes to the frame as specified by 1 for each block of up to 223 data bytes. If the configured frame size results in fewer than 223 bytes input to the Reed-Solomon encoder, the code block length is shortened using virtual fill. If the frame size is larger than the Reed-Solomon data block size, the input data is divided into (approximately) even blocks, and interleaved according to 1. The interleaving depth is determined from the frame size and can not be changed from I = ⌈size / 223⌉. If the frame size is not a multiple of the interleaving depth, the last block will be shorter. Reed-Solomon parity bytes are then added for each block, using virtual fill if necessary. This ensures that each payload data byte have approximately the same error correction probability. The default 217 byte frame size is chosen such that a maximum length payload frame results in a single RS data block of 223 bytes.
Pseudo-randomization as described in 1, can be applied to ensure a sufficient number of bit transitions in the frame. A 4 byte Attached Sync Marker (ASM, 1ACFFC1D
) is appended before each frame.
Convolutional coding using the r=1/2, constraint length 7 code from 1 can be enabled using the tx.cc
property. One byte zero termination is appended to the input data to return the encoder to the all-zero state, resulting in a coded frame size of 520 bytes in the example. Punctured code rates are not supported.
Finally, a configurable number of preamble bytes (tx.preamble
, default 8) are prepended to the frame before transmission. If more outgoing frames are queued when a transmission completes (or idle frames are enabled), the next frame is transmitted immediately following the last byte of the first frame. A configurable number of midamble bytes can be inserted between the frames and postamble bytes can be appended after the frame transmission, e.g. to flush a streaming Viterbi decoder in the receiver.
Note
Uplink frames must have a minimum of 8 bytes preamble before each frame, also if they are transmitted back-to-back.
Idle frames¶
To conserve power, the SRS-3 does not normally transmit idle frames when no data is queued for transmission. Using the tx.idleframes
property (default 0), the SRS-3 can be configured to continue to transmit a number of idle frames after each data frame. Any data frames queued for transmission while sending idle frames take priority and resets the idle counter to tx.idleframes
. When the idle counter reaches 0, the radio is keyed down. Idle frames consists of all-zero data but with FEC and CRC applied.
Throughput¶
The channel bit rates are configurable through the tx.rate
and rx.rate
properties, but the achievable throughput (“goodput”) depends on configured frame size and FEC options. The preamble and ASM also adds a fixed per-packet overhead, which must be taken into account when calculating the achievable data rate. The figure below shows throughput as a percentage of the channel bit rate, as a function of the packet size and FEC configuration.
In the CRC-only case, the throughput approaches 100% of the channel rate as the frame size is increased, because the overhead is fixed (preamble, ASM and 4 bytes CRC field). The jumps in throughput in the RS cases occur every time the frame size requires a new Reed-Solomon block to hold the data bytes. The throughput approaches the rate of the Reed-Solomon code, RRS = 223/255 ≈ 87.5% of the channel rate. Similarly, when convolutional coding is enabled, the throughput approaches the rate of the concatenated code RRSRCC = 223/255/2 ≈ 43.7%.
As described in the previous section, the default frame size is chosen to exactly fit in a single Reed-Solomon block. For the default frame size, the table below lists the throughputs at the maximum transmit rate of 512 kbps and the maximum receive rate of 128 kbps.
Achievable throughput with default 217 bytes payload data size:
FEC configuration |
Throughput |
Max. TX throughput |
Max. RX throughput |
---|---|---|---|
CRC |
92.3% |
472.8 kbps |
118.2 kbps |
CRC + RS |
81.3% |
416.1 kbps |
104.0 kbps |
CRC + RS + CC |
41.1% |
210.4 kbps |
52.6 kbps |
Protocol overhead of the encapsulating network protocol (CSP or IP) is not included in the calculations above.
Encryption¶
The SRS-3 can optionally encrypt and/or authenticate frames using AES-256-GCM encryption. Encryption is applied after frame padding but before the frame is passed to the CRC and FEC stages.
The 256 bit encryption keys are configured using the tx.crypto.key
and rx.crypto.key
properties. If encryption or authentication is enabled using tx.crypto.encrypt
or tx.crypto.auth
, a 96 bit random nonce/IV is prepended to the frame, thus increasing the frame size by 12 bytes. If tx.crypto.auth
is enabled, a 128 bit tag is appended and the frame size is increased by 16 bytes. Similarly, rx.crypto.decrypt
and rx.crypto.auth
enable decryption and authentication on the receive interface.
Encryption and authentication can be enabled independently on both the RX and TX interfaces. Authentication can be enabled without encryption (GMAC mode) but it is recommended to always enable authentication when encryption is enabled, since the encryption itself does not protect against malicious messages.
- 1(1,2,3,4)
CCSDS, 131.0-B-3 TM Synchronization and Channel Coding, 2017: https://public.ccsds.org/Pubs/131x0b3e1.pdf