1. Next Generation Uplink Options already within our Grasp
Greg Kazz
Ed Greenberg
NASA/JPL
May 16, 2011
Spring 2011 CCSDS - Berlin

2. Possible Upgrades (minimal effect on TC)
New uplink coding for performance improvement in non-emergency situations.
Coding gains of up to 6 dB (CC/BCH) and 8.5 dB (LDPC/BCH)
CC with TED replacing TED provides 6 dB; CC with TED replacing SEC gives 4 dB
Based upon CNES (Myriades) 5 dB improvement for CC with TED
Using current CCSDS recommendations for:
CC rate ½ k=7 and LDPC rate ½ (1k or 4k code words)
New uplink coding for performance improvement in emergency situations.
Coding gains of up to 5 dB (If ~100 bit block LDPC codes used)
JPL proposals for a LDPC outer code
Significant improvement in time correlation for deep space missions using regenerative ranging utilizing current CCSDS PN ranging specification
Tens of milliseconds to units of microseconds
5/17/11
Spring 2011 CCSDS Meeting - Berlin

3. Spring 2011 CCSDS Meeting - Berlin
Uplink Coding
TC currently requires use of the BCH (56,63) code in either of 2 modes:
Triple Error Detection (TED) provides only error detection
Requires 7 code bits and a 1 parity bit for each 8 bytes of the frame
Not recommended for burst environment
Required Eb/No at BER = 1e-5 is dB
Single Error Correction (SEC)
Required Eb/No at BER = 1e-5 is 8.75 dB
Adding CC could provide a performance gain of 6 dB over BCH TED
CC decoding creates a burst error environment which is incompatible with BCH SEC mode. TED is required for detecting end of CLTU for current TC recommendation.
Adding LDPC (½, 1024) could provide a performance gain of 8.5 dB over BCH TED
LDPC is a block code and can only be used with TC when used as an outer code with its own synchronization field (code block sync).
LDPC used in physical layer
5/17/11
Spring 2011 CCSDS Meeting - Berlin

4. Overall Uplink Coding Performance (provided by JPL Coding Group)
LDPC
Rate ½ Block size bits
Rate ½ Block size 1024
1/2, 1024 LDPC with BCH TED
LDPC Rate 4/5 Block size 16384
BCH
SEC
TED
GSFC-LDPC
(8176,7156)

5. Spring 2011 CCSDS Meeting - Berlin
Implications (1-2)
Any coding scheme that is used to improve performance without effecting the TC specification must be used as an outer code.
Use of outer coding would limit the use of BCH code to the triple error detection (TED) mode.
Current TC protocol requires uses of BCH to identify end of a CLTU
Maintaining TED imposes a 0.6 dB penalty on performance gain obtainable by the added outer code.
Requires the inclusion of a decoder for the outer code in the flight transponder, but does not effect the current command decoder processor firmware.
The … pattern should not be used for acquisition when the convolutional code is used for TC.  The acquisition process is confused by the pattern and can allow the  decoder to lock up in an incorrect node synch.  Recommend using an acquisition pattern of repeated 352EF853 instead.
Regenerative ranging requires inclusion of sophisticated correlating hardware in the flight transponder and the time-tagging of the spacecraft clock at the PN climax.
5/17/11
Spring 2011 CCSDS Meeting - Berlin

6. Other Possible Upgrades
There are requirements for very high rate uplinks that require coding to improve link performance to obtain the data rate.
The LDPC code is the best code for the required performance and for which a practical flight decoder can be implemented
This code would most likely be used with AOS – uplink
The probability is that these data rates will not be cross-supported but if AOS is used it will likely be used at much lower rates that maybe cross-supported
This code could be used with a modified TC protocol that eliminates the BCH code
HDLC encoding could be used to delimit the CLTU given the error free environment
New uplink coding for performance improvement in emergency support.
Small block codes that may require a new uplink protocol.
See Performance Curves
5/17/11
Spring 2011 CCSDS Meeting - Berlin

7. Spring 2011 CCSDS Meeting - Berlin
Implications (2-2)
Use of AOS requires fill frames to be inserted into the uplink stream when a frame is not available for transmission rather than just inserting idle bits as in TC.
This requires changes to idle generation equipment in the station to add fill frames also requiring changes to service management to define idle.
Cross support of AOS uplink at low rate can be accommodated by current SLE-CLTU service if the SLE-CLTU SDU is an AOS Coded frame with its attached sync marker.
2. The enhancement of the Forward CLTU service (see CCSDS Draft Orange book) allows synchronous space link protocol data units (SL-PDUs) as well as asynchronous PL- CLTUs to be transferred via the service.
5/17/11
Spring 2011 CCSDS Meeting - Berlin

8. Spring 2011 CCSDS Meeting - Berlin
References
“Uplink Coding for New TC Standard”. White paper submitted at Fall 2010 CCSDS Meeting London Oct 10, 2010 by Fabrizio Pollara, Ken Andrews, Bruce Moison, Jon Hamkins (NASA/JPL).
“Concatenating the convolutional (7,1/2) code with the BCH in TED mode with CRC for improved TC link in the CNES Myriades satellite family”. White paper submitted at Fall 2010 CCSDS Meeting London Oct 10, 2010 by Guy Lesthievent, Emmanuel Robert , Jean-Louis Carayon, Florence Duchevet, Henri Darnes (CNES).
5/17/11
Spring 2011 CCSDS Meeting - Berlin

9. Spring 2011 CCSDS Meeting - Berlin
Backup
5/17/11
Spring 2011 CCSDS Meeting - Berlin

10. Spring 2011 CCSDS Meeting - Berlin
General Requirements
The service must individually support the following:
The current CCSDS FCLTU Service
The CCSDS Orange book for EFCLTU Service
A DTN node located at the SCaN station that places DTN packets into a TBD frame structure.
An IP Router located at the SCaN station that uses a serial output and formats it data in MPoFR protocol encoded with HDLC.
An encrypted virtual bitstream
The service should also support the multiplexing of multiple FCLTU services or multiple EFCLTU services from multiple sources for the same uplink. (an example for its use would be to support different agencies controlling the commanding to their laboratories onboard the ISS)
5/17/11
Spring 2011 CCSDS Meeting - Berlin

11. Adding Coding to our Current Uplinks
The current command for non-manned has been limited to TC commanding using the BCH code. This gives practically no coding gain. The use of the rate 1/2 Convolutional Code could add up to 5 db coding gain while adding the LDPC or CC-Reed Solomon code could add another 2 db.
This coding gain can only be achieved if the receiving system provides quantized symbol outputs. For supporting TC or IP or DTN the coding could be provided transparently in the physical layer so as not to require changes to the link layer protocols.
5/17/11
Spring 2011 CCSDS Meeting - Berlin

12. SCaN Forward Command Service
EFCLTU Service
User
EFCLTU Service
Provision
CCSDS
Frame
Forward
Data
Channel
Production
EFCLTU Service
User
EFCLTU Service
Provision
CCSDS
Frame
DTN Bundle
Agent
DTN
Frame ?
Forward
Physical
Channel
Production
IP Router
MPoFR
Frame
Forward
Physical
Channel
CFDP Agent
CCSDS
Frame
Idle
Idle
Data
Other
(i.e. Ranging)
-- The EFCLTU Services connect the User facility with the Station (Provisioning Facility) delivering user data for inclusion in the Forward Data Channel and reporting on the process.
-- The Forward Data Channel Production Unit interfaces to all data sources and by prioritization rules accepts data from the sources and produces a forward channel bit stream (coded as configured). It is anticipated that only one frame type will be multiplexed onto the data channel per scheduled production.
5/17/11
Spring 2011 CCSDS Meeting - Berlin

13. EFCLTU Service Data Flow
FCLTU-SDU
Contained Parameters:
Release Time
Window Close Time
EFCLTU SLE SERVICE USER
FCLTU-DU
Report/Status
Notes:
FCLTU-SDU
Contained Parameters:
Sequence Number
Release Time
Window Close Time
Command Data Flow
FCLTU-DU
Control Data Flow
EFCLTU SLE
SERVICE
PROVISION
EFCLTU SLE
SERVICE
PRODUCTION
FCLTU-DU
S/C
RF Modulated Synchronous Bitstream
IDLE-DU
5/17/11
Spring 2011 CCSDS Meeting - Berlin

14. Spring 2011 CCSDS Meeting - Berlin
EFCLTU Data Flow
USER
EFCLTU Service
FCLTU-IDU
Contained Parameters:
Release Time
Window Close Time
EFCLTU SLE SERVICE USER
FCLTU-DU
Notes:
FCLTU-SDU
Contained Parameters:
Sequence Number
Release Time
Window Close Time
Command Data Flow
FCLTU-DU
Control Data Flow
FCLTU-DU
EFCLTU SLE
SERVICE
PROVISION
EFCLTU SLE
SERVICE
PRODUCTION
S/C
RF Modulated Synchronous Bitstream
IDLE-DU
User passes an FCLTU-DU contained within an FCLTU-IDU that contains the allowable window for radiation to the EFCLTU Service User Agent.
EFCLTU Service User Agent binds to EFCLTU SLE Service Provision and forwards the FCLTU-DU to the EFCLTU Service Provision within a FCLTU-SDU.
EFCLTU Service Provision makes the FCLTU-DU available to the EFCLTU Service Production, if the release time window if an FCLTU-DU expires the FCLTU-DU is dropped and an Error Event is reported. An Error Event can cause a halt to the service or not depending upon the configuration.
The EFCLTU Service Production will select FCLTU-DU for processing or if no FCLTU-DU is available will accept an IDLE-DU. The EFCLTU Service Production process will, as preconditioned, prepare the DU for inclusion in the RF Modulated Synchronous Bitstream.
5/17/11
Spring 2011 CCSDS Meeting - Berlin

15. Forward Data Channel Production
Block-encode?
convolutional
encoding
Forward
Channel
Octet Stream
yes no
“Data Unit”
Selection
And Octet stream Formulation
FCLTU-DU
symbols to
RF Modulator OR OR no
yes
Other-DU
Convolutionally-
encode?
Forward
Data
Blocker
divide for
specified encoder
R-S
encoding
Segment
Initiate
Streaming
Bit Counter
IDLE-DU
Add
ASM
Randomize OR
LDPC
encoding
Notes:
Data Unit Selection will accept a data unit when the forward data channel is available based on configuration rules.
The Blocker will divide the forward channel octet stream into code block information size blocks (as required)
Block encoding path automatically includes Randomization and adds ASM (as required)
CC encoding can not be used with LDPC encoding and should not be used with BCH SEC encoding (as required)
A Segment Pulse is sent to the Blocker after the desired number of ”fwd channel octets” are output.
This provides the ability to synchronize the frame and codeblock when required
5/17/11
Spring 2011 CCSDS Meeting - Berlin

16. Production – Provision Interface
Provisioning side
A data unit is placed into a serial buffer
This is the Serial “Data” interface to Production
The number of bits/bytes is loaded into the countdown register
When user data is ready for output the number of data bits is loaded into the counter. Whenever the count is non-zero, data is available for transfer and the “Available” interface goes HIGH
Production side
When production needs data to fill the uplink it uses priority selection to find the highest priority provision entity whose “Available” interface is HIGH.
The order in which a User’s data is selected is based on provided rules with production
A shift data clock is provided to the selected user to acquire the data
The number of bits received is obtained by counting the clock pulse required to drive the provision countdown register to zero. This signals that all the data has been transferred and is available within the production entity.
5/17/11
Spring 2011 CCSDS Meeting - Berlin

17. Data Transfer Interface
Production
Provision A
Serial Register
Serial Register
Shift in
Data
Shift out
UP Count Register
Count UP
Clock
Select User C
Shift Clock B
Down Count
Countdown Register
Data Available (high)
Data A 1 1 1 1
This simple example demonstrates how an 8 bit 1/0 data byte is output from Provision to Production.
Data Available (high) B
5/17/11
Shift Clock C
Spring 2011 CCSDS Meeting - Berlin

18. Production Options (TC)
Standard TC as currently provided
FCLTU_DU is a fully encoded TC frame (CLTU)
IDLE –DU is one or two octets of alternate 1/0s
ALL production options are set to off
Next Generation TC using CC encoding
FCLTU_DU is a TC frame (with or without BCH encoding)
Only CC encoding production option is set on
Next Generation TC using Block encoding
Block encoding production option is set on
Note that the ASM for the Block code needs to be removed by receiving decoder
only FCLTU-DU and idle octets are forwarded
CC encoding option will be set on only if R-S is configured
5/17/11
Spring 2011 CCSDS Meeting - Berlin

19. Production Options (AOS)
Standard AOS
FCLTU-DU contains one or more AOS frames (without ASM)
IDLE–DU is one IDLE AOS Frame (without ASM)
Block encoding production option is set on and encoding is synchronized to the AOS frame
CC encoding option will be set on only if R-S is configured
5/17/11
Spring 2011 CCSDS Meeting - Berlin

20. Production Options (Encrypted/Non-CCSDS)
Totally Encrypted/Non-CCSDS discontinuous frames using CC encoding
FCLTU_DU is a non-CCSDS frame (encrypted or not)
IDLE –DU is one or two octets in desired format
Only CC encoding production option is set on
Totally Encrypted/Non-CCSDS Units using Block encoding
Block encoding production option is set on
Note that the ASM for the Block code needs to be removed by the receiving decoder
CC encoding option will be set on only if R-S is configured
Continuous non-delimited Bit stream
FCLTU_DU is a series of bits that are buffered to prevent gaps during delivery
IDLE–DU is not required because uncoded uplink contains only user data
Production options can be set on or off dependent on the need see 5 or 6 above.
5/17/11
Spring 2011 CCSDS Meeting - Berlin