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.
2
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.
3
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.
4
Sliced Data Transfer Frame with LDPC
CCSDS 131.0-B-2
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.
Eliminate this item or Change to:
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)
5
Sliced Data Transfer Frame with LDPC
CCSDS 131.0-B-2
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)
6
Sliced Data Transfer Frame Inserted Into Code Frame
CCSDS 131.0-B-2, 8.3.4
CCSDS 732.0-B-2 page 4-2
Attached Synchronization
Marker (ASM) 1ACFFC1D
(32 bits)
Transfer Frame
Primary Header
(48 bits)
Transfer Frame
Data Field
Data Transfer Frame is “sliced” and placed in Codeword (frame)
CCSDS 131.0-B-2 sect 8.6
Data Transfer Frame
Data Transfer Frame
Data Transfer Frame
Data Transfer Frame (Data Link Protocol Sublayer)
Codeword (Coding Sublayer)
Parity CSMCodeword Message
Area
Parity CSM
Codeword Message
Area
Parity CSM
Codeword (Frame)
Code Synch Marker
(CSM)
(32 or 64 symbols)
Codeword Message
Area
Codeword Message
Parity CSM
Area
Parity
Physical Channel Data Unit (PCDU)
Codeword Message Area
Codeword Parity Area
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)
Code Synch Marker
(CSM)
(32 or 64 symbols)
Randomized Codeword
7
3/29/13
Sliced Data Transfer Frame with LDPC
Conclusion:
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
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