Proposal for a TC-2 ProtocolEd GreenbergGreg Kazz

Oct 2011

04/21/23 1

Why TC 2• Next generation missions require increased uplink performance

partially because of increased contention for communications.– i.e. DSN’s multiple S/C downlinks supported by a single antenna

• The LDPC family of codes can provide substantial coding gains that can be capitalized on for commanding.– High rate coding gains can approach 8 times current rates under same

conditions

• Current TC Protocol is integrated with the BCH code and requires an uncorrectable codeword to delimit the frame and terminate randomization. – Elimination of BCH encoding removes the end of frame detection mechanism and

thus requires a new mechanism. The frame length field provides that function.– Tying the randomization to the LDPC Codeblock provides the means to start and

terminate the Randomization process.

04/21/23 2

Characteristics Desired for TC-2• Maintain the variable frame structure of the link layer and achieve

maximum coding gain using the LDPC family of codes.• Maintain the current TC Protocol state table and actions but modify

the coding to achieve better performance • The coding and the link layer framing need to be asynchronous to

achieve the desired performance and maintain the structural aspects of the frame.

• It is recommended that TC use Randomization and the proposed approach would link the randomization to the LDPC codeblock.

• It is also recommended that we pursue the codification of smaller LDPC codes for use with the constraints of emergency commanding.

• As a compromise the use of the rate 1/2 , 1024 bit LDPC code offers desirable improvements in performance, limited access delay and implementation difficulty for all commanding profiles.

04/21/23 3

TC-2 Frame Structure

Notes:1. Frame Delimitation is provided by length field in frame2. CRC not required but could be useful to add extra frame validation

4

X Y X Z

X = optional and of variable lengthY = of variable lengthZ = optional but fixed at 16 bits

ASM

16 bits

Coding Performance for Cmd and File Uplink

• LDPC (Codeblock length=1024, rate = 1/2 for nominal operations)

– Required Eb/No for 10-5 Bit Error Rates (BER):• --Uncoded 9.6 dB, LDPC Rate=1/2 requires 1.8 dB*

– Improved BER Performance from LDPC coding gains:• @BER of 10-8-- Uncoded requires 12 dB, BCH SEC required 10 db, LDPC requires 2.2 dB*

– Thus the gain for LDPC (1/2, 1204) is close to 8 dB worst case which could increase the data rates by about 6.3 times and significantly better undetected BERs which are especially important for large file transfers.

– Randomization would be applied synchronously with the LDPC Codeword.

04/21/235

Note: * Performance data quoted from “Uplink Coding for New TC Standard” – Joint NASA/CNES White Paper Fall 2010 CCSDS Meeting London Oct 10 2010

Emergency Coding CaseLDPC (Codeblock length options= 64, 128, 256 are under consideration)

– Required Eb/No for 10-5 Bit Error Rates (BER):• --Uncoded 9.6 dB, LDPC k=64, 128, 256 requires 4.8 dB, 4.0 dB, 3.3 dB*

– Improved BER Performance from LDPC coding gains:• --Uncoded 12 dB @BER of 10-8 for 64, 128, 256 LDPC requires 6 dB, 5 dB, 4.1 dB*

– Thus the performance gain for the family of short Rate ½ LDPC codes varies but all provide improved data rates and undetected BERs which are especially important in the low rate emergency mode profile.

– Randomization would be applied synchronously with the LDPC Codeword.

04/21/23 6

Note: * Performance data quoted from “Uplink Coding for New TC Standard” – Joint NASA/CNES White Paper Fall 2010 CCSDS Meeting London Oct 10 2010

Formatting Differences Current TC vs Proposed TC-2

• Eliminating the BCH code– Removes the requirement to add and delete fill bytes within the TC

Frame Data Field– No longer terminate the CLTU by using an erroneous BCH code word– No longer requires CRC (becomes an optional field)– Requires alternative frame and randomization delimitation process

• Would use length field for CLTU delimiting• Would have Randomization applied synchronous with the LDPC codeblock

– Apply the security after the frame is completed (prior to CRC if used)– Apply coding and randomization after frame is completed and security

and CRC included.

04/21/23 7

04/21/23 8

Required Changes in Receiving Process• LDPC decoding requires quantized symbols from the receiver• The Code block requires a sync word with a significant number of bits

• because of the reduced symbol SNR • The combination of the code block sync word followed by the code

block is continuously repeated without any extra inserted bits• to aid the synchronization process

• The derandomization process is initiated immediately following the code sync word and is performed for the entire code block.

• The derandomized data is provided to the code decoder.• The LDPC decoding is then performed.

• if decoding falls then the command decoding process is initialized and all previously received but yet to be processed bits are dumped.

• The decoded bits from the code block are then sent to the command decoder where the frame synchronization process.

• If the CRC is used, the frame validation process is performed.• If security is included then the required frame’s contents is provided to

the security process.• The accepted frame’s contents are then delivered to the command

decoder for processing.