High Speed CCSDS Data Formatter

Ulrich Lonsdorfer; Franz Josef Rombeck

Astrium GmbH
Electronics
D-88039 Friedrichshafen, Germany
Tel: ++49-7545-8 4144, Fax: ++49-7545-8 3332,
E-mail: [email protected]

Tel: ++49-7545-8 9051, Fax: ++49-7545-8 3332,

E-mail: [email protected]

1 Introduction
Actual high resolution SAR instruments or multispectral cameras are characterised by their
increased user data volume. Generally these amounts of data are stored in Solid State Mass
Memories to be downlinked during a short contact window to the ground station. The relation
between high user data volumes (up to 1 TBit) and the short downlink time (max. 8 min)
leads to extreme downlink data rate requirements. State of the art X-band transmitters
provide a capacity of up to 300 Mbps. For secure transmission and coordinated reception in
ground station, data must be formatted. Two different approaches are possible:

• Storing of preformatted data in memory

• On line formatting during downlink

Since the first solution additionally consumes nearly 18% of memory capacity due to
formatting overhead and allows access to data only in the preformatted sequence, Astrium
GmbH decided to develop a high speed online Telemetry Formatter Encryptor (TMFE), which
allows random access to user data and avoids unnecessary storing of format data.
Thanks to the availability of radiation tolerant and space qualified high density programmable
logic arrays it is possible to implement the complete formatter in 2 different FPGA’s which are
assembled together with some LSI and VLSI support circuits on one single Double Europe
sized board (233 x 160 mm²). It provides functions like:

• Data Formatting in CCSDS compatible Channel Access Data Units ‘CADU’ [1]
• Secure Data Transmission by high data rate Encryption
• Reed Solomon Encoding of ‘CADU’ frames of encrypted or un-encrypted data [2]
• Scrambling of telemetry data for downlink preparation [2]
• High speed sequencing and control function

Challenging performance requirement of the TMFE unit is the high throughput and
processing frequency of 150 Mbps. The TMFE Block diagram is shown in Figure 1-1
TMFEE Block Diagram

-1–
 from
Data I
Input CADU- RS- Scrambler to QPSK
Routing Encryption Q
Buffer Generator Encoder -Serialiser Modulator
Network Clk

CMD & CTL

Sequencer & Control
by Supervisor

Figure 1-1 TMFEE Block Diagram

The TMFE board contains a telemetry data processing chain able to receive unformatted
data or already formatted data in CCSDS standard Source Packets of variable length. Data
reception will be performed at a maximum data rate of 250 Mbps. The input buffer is used to
decouple the external TMFE data stream from the internal processing activities. The
generation of CCSDS conform Channel Access Data Units ‘CADU’ is the next processing
step. The complete Virtual Channel Data Units ‘VCDU’ includes the generation of Reed
Solomon symbols.
The final step of the TMFE board functionality is to scramble the CADU data stream in order
to provide a pseudo randomised data stream according to the CCSDS standard. The
randomised data pattern is required by the subsequent QPSK modulator. The input data
stream to the QPSK modulator is further subdivided in I- and Q-data.
TMFE has been realized as Engineering Model for the TOPAS SAR On-Board Processing
Demonstrator and in FM quality for the CryoSat SSMM. For the TerraSAR SSMM an
enhanced version with 300 Mbps data rate is under development.

2 Data Encryptor

Encryption of the data is performed by XORing data with a pseudo random code which is
provided by the Encryption code generator. The pseudo random code is calculated
depending on the information given by the secrete keys. The encryption function uses two
128-bit wide words as secrete keys. The keys are used for initialisation of the code
generation as well as for continuous alteration of the generation rule.
Encryption of systematic data with repeating structures generally reveals the encryption
scheme. To prevent unauthorised decryption only arbitrary user data is encrypted. Usually
the Secondary Header of the Source Packet contains systematic data like time tags or
positions. Nevertheless this data shall not be transmitted in open form. Therefore Encryption
comprises an additional randomising function independent from the main encryption code.
Control of encryption or randomising process is done by the Controller Sequencer. The SC
decides which part of the data stream will be bypassed, encrypted or masked and encrypted.
Furthermore the sequencer provides a key management to provide user-controlled
encryption of individual data sets. Figure 2-1 Encryptor Logical Block Diagram gives an overview
about the encryptor functions.

-2–
 Stream Ciphering
Input Data (2-Byte-wise) Output

CCU Key Ciphering Pad

M-Key based Generation
control Control

Key Management Master Key Encryptor

PSRG1 PSRG2
Session Key Pseudo Random
Initializatio
Code
n

Clock Generation and Sequencing

Figure 2-1 Encryptor Logical Block Diagram

3 CCSDS Channel Access Data Unit Generator

The main function of the CADU Generator is to assemble the lower layer protocol of data to
be transferred continuously through the physical channel. A CADU consists of Virtual
Channel Data Unit (VCDU) that has been prefixed and delimited by a Synchronisation
Marker. An overview of the CADU formation process is shown in Figure 4-1.
At the input side delimited user data units of variable length whose structure and header
information is specified by the CCSDS standard [1] are accepted. These data units which are
in the following called Source Packets, have to comply with the following characteristics:

• The length of the Source Packets is variable with an upper limit of max. 64 kByte
(including the secondary header information).
• The secondary header consists of auxiliary S/C data, instrument specific parameters
and datation data. Details are evaluated and defined within the Definition Phase.

The Source Packet header is compiled to extract the secondary header flag, Application
Process Identifier (APID), packet length and the packet sequence counter.
In a final step the CADU-Blocks are generated by appending the VCDU’s to a ‘SYNC CODE’
of length 32 bits. During transmission through the Physical Channel, each VCDU is carried
synchronously within one "Channel Access Data Unit" (CADU). The CADU’s provide fixed-
length "channel access slots" which occur at precise time intervals that are synchronised with
the transmitted bit rate, and whose boundaries are delimited using the ‘SYNC CODE’. The
commutated sequence of VCDU’s/CVCDU’s is transmitted so that all of the synchronous
channel access slots are occupied. In situations where no valid user data are available, a
VCDU/CVCDU containing "Fill" data packets are inserted. The ‘SYNC CODE’ pattern will be
defined within the Definition Phase.
The resulting CADU stream then is supplied to the scrambler/pseudo-randomiser

-3–
 CADU
Attached Sync. Marker VCDU
32 bits 10200 bits

Reed-Solomon Codeblock
Reed-Solomon Data Space Reed Solomon Check Symbols
8920 bits 1280 bits

Transfer Frame
Transfer Frame Header Transfer Frame Data Field
Frame Identification Master Virtual Frame Data Field Status End of First ....... Last Begin of
Channel Channel previou complete complete next
Version Space Virtual Operational Frame Frame Sec. Sync. Packet Segment First s Packet in Packet in Packet
Number craft ID Channel Control Field Count Count Header Flag Order Length ID Header Packet Data Data
ID Flag Flag Flag Pointer Field Field

2 bits 10 bits 3 bits 1 bit 8 bits 8 bits 1 bit 1 bit 1 bit 2 bits 11 bits 8872 bits

Source Packet
Packet Header Packet Data Field

Packet Sequence Packet Data Source Data

Packet Identification
Control Length Field
Header
Version Type Data Field Application Segmen- Source
Number Header Flag Process tation Sequence
Identifier Flags Count

3 bits 1 bit 1 bit 11 bits 2 bits 14 bits 16 bits Variable (max. 65 536 bytes)

Figure 3-1 CCSDS Data Formatting Flow

4 Reed Solomon Coder

Reed-Solomon encoding is a powerful burst error correcting code. In addition, the code
proposed has an extremely low undetected error rate. This means that the decoder can
reliably indicate whether it can make the proper corrections or not. To achieve this reliability,
proper codeblock synchronisation is mandatory. The TFME performs Reed-Solomon (RS)
encoding according to the CCSDS standard (see [2]).

-4–
In the following the main preliminary RS-encoder characteristics are summarised which are
subject for detailed evaluation/confirmation within the frame of the Definition Phase.

• There are 8 bits per R-S symbol.

• 16 R-S symbol error correction capability within a Reed-Solomon codeword.
• There are 255 symbols per R-S codeword.
• Encoding systematic: The first 223 symbols transmitted are information symbols and
the last 32 symbols transmitted are check symbols.
• Symbol Interleaving: The value of interleaving depth is I= 5.

5 Scrambler / PSEUDO-Randomiser

In order to maintain bit (or symbol) synchronisation with the received telemetry signal, every
ground station system requires that the incoming signal have a minimum bit transition
density. In order to ensure a sufficient bit transition density a Scrambler/Pseudo-Randomiser
in accordance to the CCSDS standard [2] is needed.
The scrambling function is implemented by exclusive-OR each bit of the CADU block with a
standard pseudo-random sequence. The pseudo random generator will be reset upon
detection of the synchronisation marker. Scrambling will not be applied to the
synchronisation marker itself.
On the receiving end, the same pseudo-random sequence is applied to de-randomise the
receive data. After locating the synchronisation marker in the received data stream, the
pseudo-random sequence is exclusive-ORed with the data bits immediately following the
synchronisation marker.
The pseudo-random sequence is generated using the following polynominal:

h(x) = x8 + x7 + x5 + x3 + 1

This sequence begins at the first bit of the Codeblock or Transfer Frame and repeats after
255 bits, continuing repeatedly until the end of the Codeblock or Transfer Frame. The
sequence generator is initialised to the all-ones state at the start of each Codeblock or
Transfer Frame.
Figure 6-1 represents a possible generator implementation for the specified sequence.

Scrambled
Data In + Data Out

+ + +

8 7 6 5 4 3 2 1
X X X X X X X X Pseudo-
Random
Sequence
Initialize to `all ones` upon sync. marker detection

+ XOR single bit delay

Figure 5-1 Pseudo-Randomiser Logic Diagram

-5–
6 TMFE Datasheet

The TMFE data sheet summarizes major abilities.

Functions: Remark
Built In Self Test
Input Buffer
Reed Solomon Coder Interleave 5
Transfer Frame Generator
Scrambler/Serializer

Performance
Data Rate 150 Mbps

Interfaces
Input Data 8 Bit parallel LVTH
Command 8 Bit parallel LVTH
Output Data Serial (I/Q/Clk 150 MHz) ECL / LVDS

General Remark
Implementation 2 Radiation Hard FPGAs
Power Supply 3,3 V / 2,8 W
5.0 V / 2,3 W
-5,2V / 2,1 W In case of ECL
Dimension 233 x 160 mm² Double Euro
Mass 350 g

Table 1 TMFE Datasheet

-6–