SLS-CS_13-03 Separating Coding from Framing Fall Technical Meeting, Bordeaux (BOD) 4/15-18/2013 SLS-CS_13-03 Separating Coding from Framing 4-15-13 V. Sank, H. Garon - NASA/GSFC/MEI W. Fong, W. Horne – NASA/GSFC E. Greenberg – NASA/JPL M. Bertinelli - ESA 1 4/2/13 8:40

Sliced Data Transfer Frame with LDPC Purpose Revise section 7.3.5, 7.4.3.1, and 10.8 of CCSDS 131.0-B-2. Introduction Requirement on data Transfer Frames used with LDPC codes are unnecessarily restricted. Background Section 10.8 of CCSDS 131.0-B-2 requires that the Transfer Frame lengths must match the information block length for the selected LDPC code and that the data Transfer Frame is synchronized to the start of the LDPC codeword. Scope This presentation addresses the use of the LDPC codes. In the bigger picture, we suggest that CCSDS separates Data (Transfer) Framing from Coding.

Sliced Data Transfer Frame with LDPC Rationale (1 of 2) Reed-Solomon (RS) code block allows the used to adjust its size to the fit the the Data Transfer Frame by selecting the Interleave and the shortening. Thirty years ago when the RS code block was codified, there was good reason to keep the Transfer frame and code frame synchronized (Frame synch and error rate). With today’s codes, more capable hardware/firmware, and significantly higher data rates, there is good reason to separate the two. These include: Hardware simplification, reduced cost of testing and ease of inheritance Ability to match the frame size to the data rate allowing longer frames for higher rates The SCCC and DVB-S2 are examples of where CCSDS has approved the use of slicing the data transfer frame with its ASM and placing it in the codeword. Missions using the Proximity-1 protocol intend to have the message data placed asynchronously in the message area of the LDPC codeword.

Sliced Data Transfer Frame with LDPC Rationale (2 of 2) The 7/8 LDPC code is intended for very high data rate, (many hundred Mbps to Gbps). Transmitter vendors have been asked to put the encoder in the transmitter, rather than the C&DH. They avoid the need to synchronize the data transfer frame with the codeword by slicing the data frame and placing the bytes in the codeword message area.  A code synchronization word Is added. LDCM and is on orbit and IRIS is soon to follow. Both are using LDPC with commercial receivers at the ground station that support the sliced arrangement.   Projects that do not currently use coding will be able to migrate to CCSDS by using CCSDS coding while keeping their current data system.   The JPL Mars Program has always been saying that they support separating the frame layer from the coding layer. Mainly because it removes the constraint that the transfer frames have to be the same size as the codeblocks. The Electra transceiver which goes into all the Mars orbiter missions (and many of the lander/rover missions), including ESA 2016 TGO implements it this way.

CCSDS 131.0-B-2 Sliced Data Transfer Frame with LDPC Section 7.3.5 1) The encoder shall accept as input a Telemetry Transfer Frame of 7136 bits (i.e. 892 octets matching the length and dimension of (255,223) I=4 Reed-Solomon), Eliminate this item or Change to: 1) The encoder shall accept 7136 bits that are either synchronized to a frame boundary of not. Synchronizing the code block with the frame is only an option not a requirement. When the Transfer Frame is not of length 7136 bits, it shall be sliced as shown in Figure (slide 7) Section 7.4.3.1 The encoder shall accept as input a Telemetry Transfer Frame of length k as per table 7-5. The encoder shall accept as input a Transfer Frame of length k as per table 7-5, that are either synchronized to a frame boundary of not. Synchronizing the code block with the frame is only an option not a requirement.. When the Telemetry Transfer Frame is not of length k, it shall be slices as shown in Figure (slide 7)

CCSDS 131.0-B-2 Sliced Data Transfer Frame with LDPC Section 10.8 CASE 6: LDPC 10.8.1 The Transfer Frame lengths must match the information block lengths for the selected LDPC code. NOTE – The LDPC Codes specified in section 7 of this Recommended Standard are block codes. 10.8.2 When the rate-7/8 LDPC code is used, the only allowable Transfer Frame length is 892 octets. 10.8.3 When the 1/2-, 2/3-, and 4/5-rate LDPC codes are used, the allowable Transfer Frame lengths are 128 octets, 512 octets, or 2048 octets. Proposed Change: Remove this section completely. It is unnecessary and is redundant with earlier sections (see previous slide)

Sliced Data Transfer Frame Inserted Into Code Frame Attached Synchronization Marker (ASM) 1ACFFC1D (32 bits) CCSDS 732.0-B-2 page 4-2 Transfer Frame Data Field Primary Header (48 bits) CCSDS 131.0-B-2, 8.3.4 CCSDS 131.0-B-2 sect 8.6 Randomized Codeword Code Synch Marker (CSM) (32 or 64 symbols) Codeword Message Area Codeword Parity Area Parity CSM Codeword Message Area Data Transfer Frame (Data Link Protocol Sublayer) Codeword (Coding Sublayer) CSM CCSDS 131.0-B-2 section 8.3.4 and 8.6 for rate 7/8 LDPC code using 32 bit CSM. For 32 symbol case :1ACFFC1D for case where data area of codeword is randomized , 352EF853 if not randomized. For 64 symbol case: 034776C7272895B0 (used with Deep Space (lower rate than 7/8) LDPC codes) Data Transfer Frame Data Transfer Frame is “sliced” and placed in Codeword (frame) Codeword (Frame) Physical Channel Data Unit (PCDU) Parity Code Synch Marker (CSM) (32 or 64 symbols) 7 3/29/13

Conclusion: Sliced Data Transfer Frame with LDPC Remove or rewrite section 7.3.5 item 1) Remove or rewrite section 7.4.3.1 Eliminate section 10.8 entirely (or have it point to 7.3.5 and 7.4.3.1) And Add the definition of a code block that provides for multiple code words to be concatenated with a single ASM to form the physical channel data unit (PCDU). (For the lower rate codes, this reduces the inefficiency of the 64 symbol ASM and for the high rate code, it removes the need to define a 32 symbol ASM (CSM) for each codeword) 8

Sliced Data Transfer Frame with LDPC Back Up 9

Sliced Data Transfer Frame Inserted Into Code Frame ASM and CSM Using the same pattern for both the Data Transfer Frame ASM and codeword ASM (CSM): LDPC is a “systematic” code, which means that the message data Transfer frame and its ASM is not changed when encoded, only parity is added. Randomization is applied after the coding is done so the Data Transfer Frame ASM gets randomized. Are there ever instances when we want to turn off the CCSDS randomizer?   CCSDS requires randomization for the LDPC codes. The basic assumption of CCSDS randomization is that it is either always ON or always OFF. During I&T or during debug it may be off. Even if it is turned off, this doesn’t preclude using the same pattern for both the ASM and CSM.   The distance between each ASM will be different for ASM and CSM. This allows the frame synchronizer to find the correct frame. If the two frames were the same length, they could and should be made synchronous with only a single ASM (no CSM) So we assume that they are not the same length. Decoding When using a Cortex XXL ground receiver there are several options on how the data is handed from the code sub level to the data sub level. All code frames (codewords) can be handed to the next higher level, the data level, even if the decoder fails to correct all of the errors. Or, the receiver can be set up to drop the code frames that are not fully decoded. When the code frame and data frame are not the same length and not aligned (asynchronous), a failure to correct all errors at the decoding level of a single code frame, can result in one or many data frames with errors, depending on the size of the code and data frame. If all code frames are passed to the data level, it is suggested that the CCSDS CRC is used so that at the data sublevel, the corrupted data frames can be identified. If the CCSDS CRC is not used, it is recommended that the receiver be set to not pass all code frames to the data level. This way the missing bits will cause the data frame synchronizer to drop lock. The operations center may be able to have the missing data frames, and a few on both sides, retransmitted. It is important to retransmit at least one frame prior to the point where frame synch was lost because the frame just prior to the loss of frame synch may also contain errors. 10