Proposal for a TC-2 Protocol Ed Greenberg Greg Kazz Oct /27/20151

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. 11/27/20152

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. 11/27/20153

TC-2 Frame Structure Notes: 1. Frame Delimitation is provided by length field in frame 2. CRC not required but could be useful to add extra frame validation 4 Frame Start ( ASM ) 16 bits Frame Version- 2 bits Type- 2 bits -- Bit 3- Bypass ( 0 ) or Sequence Controlled ( 1 ) Bit 4- Control Command (0) Data or (1) Control Flags- 3 bits – for signaling options and/or future use ( e.g. CRC and/or link security ) Spacecraft ID - 10 bits VCID -- 6 bits Frame Length 10 bits Frame Sequence # 8 bits Data Variable # of bytes ( 0-4k bytes ) CRC Optional ( 16 bits if used ) (not required when coupled with LDPC decoder error notice) Versio n AUTHENTICATION DATA CR C Versio n DATA FIELD Versio n SECURITY HEADER XY X Z X = optional and of variable length Y = of variable length Z = 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 Bit Error Rates ( BER ): --Uncoded 9.6 dB, LDPC Rate=1/2 requires 1.8 dB* – Improved BER Performance from LDPC coding of 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. 11/27/ Note: * Performance data quoted from “Uplink Coding for New TC Standard” – Joint NASA/CNES White Paper Fall 2010 CCSDS Meeting London Oct

Emergency Coding Case LDPC ( Codeblock length options= 64, 128, 256 are under consideration ) – Required Eb/No for 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 of 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. 11/27/20156 Note: * Performance data quoted from “Uplink Coding for New TC Standard” – Joint NASA/CNES White Paper Fall 2010 CCSDS Meeting London Oct

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. 11/27/20157

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.