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

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

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 11.04 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

Overall Uplink Coding Performance (provided by JPL Coding Group) LDPC Rate ½ Block size 16 384 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)

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 101010… pattern should not be used for acquisition when the convolutional code is used for TC.  The acquisition process is confused by the 101010 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

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

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 912.1 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

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

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

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

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

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

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

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

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

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

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

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

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

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