1. CCSDS Next Generation Space Link Protocol (NGSLP) Greg Kazz Peter Shames NASA-JPL 3-31-2014

2. What’s the overall story here? Current and Future Space Link Frames – What is similar, what is different? – What makes NGSLP special? – How does NGSLP do what’s currently done better ? Impact of NGSLP on Future Mission Operations – Cross-Support Services – Optical Communication NGSLP Path to Standardization SLS-Plan Comm - CCSDS Spring 2014 Meeting - Noordwijkerhoot, the Netherlands2

3. Drivers for the NGSLP Will accommodate Higher Data Rates impacting frame handing services – Provides Longer frames to make the frame handling processes more efficient – Provides Longer sequence counter to enable frame ordering from multiple downlinks Takes advantage of decoupling the transfer frame length from the code block size – Requires variable length frame service from coding & synchronization sub-layer – Separates link protocol from coding & synchronization functionality enabling modularity Provides a path to deliver control directives with minimum latency To support such applications as data rate and/or Modulation changes (VCM), Provide aperiodic Telerobotics, launch and decent landing operations directives Provides increased addressing for greater spacecraft population – Need for enlarged S/C ID field and SCID Use Field (Pre vs. Post Launch Data Discriminator) Allows Space Link Layer Security to run under all space links including Proximity-1 Simplifies Mars Communications (direct to/from Earth and In-situ) – Requires only one format for all Lander communication links – NGSLP enables orbiters the means to provide a frame relay service similar to the CSTS forward frame service currently in development We believe NGSLP supports Optical Communications and its Unique Environment – Longer frames to support higher rate data handling – Decoupling frame from codeblock option provides straight forward evolution to next generation of codes for optical links while maintaining same framing structures – Coding/Decoding could be more naturally performed in communication devices not in data system 3

4. NGSLP Frame CCSDS Frames Structures Tailored for short hop communications Variable length frames Separate frames for Control and Data TC uses a short BCH code concatenating code words as needed to capture complete frame Prox uses a Convolutional code for return link Maven Orbiter is equipped with an LDPC where the frames and code blocks are decoupled Initial design for telemetry using CC-RS code Fixed length frames, couples frame to code block Separate frames for Control and Data TC uses a low performance BCH code Prox uses a Convolutional code for return link Upgraded design for telemetry using any long block code but where the code block and frame are coupled Added an Insert Zone for isochronous data transfer Increase the number of Virtual Channels Eliminated the MC counter and increased the VC counter Upgraded design to accommodate long frames, more SCIDs, expanable larger VC counter and integrated the best of all the CCSDS frame formats so that NGSLP can be used for all links. Allows for frames to be either coupled or uncoupled to the frame. Uncoupled approach supports insertion of low latency messages into frames & remove the requirement for Idle frames 4

5. NGSLP Format with Payload Options 1 2 3 4 5

6. NGSLP Format Characteristics 6 Data Driven (contained in Frame Header) Transfer Frame Variable Optional Transfer Frame Data Field ( VCDF_PDU ) Managed VC Content Link Managed Control Parameters: 1.Physical: Frequency (wavelength), Modulation, 2.Link Layer: Coding, Frame-Codeblock coupling, fixed or variable frame size Note: Use of high performance codes with very steep WER/SNR and exceeding low error floors, means that little performance is lost when frames span multiple code words. Frame Header Data supports Cross Support Services: 1.Frame Services: Verify Frame is unmodified then deliver MC and/or VC frames 2.Insert Service: deliver Insert Zone content 3.Operation Control Service: deliver OCF data VC content is managed by VC user: 1.Establish Security Association (or none) 2.Specify VC handling: Sequence Control, VC Sub Channels included, 3.Specify VC and VC Sub-channel content: Packets, Octets, IP Datagrams, DTN, other

7. NGSLP for Proximity or Telecommand Application Plan Comm - CCSDS Spring 2014 Meeting - Noordwijerhoot, the Netherlands7 Version ID 3 bits FECF Size 2 bits OCF Flag 3 bits VC Count size 16 Bits Frame Length 1 bit Destination or Source ID Spacecraft ID 13 bits2 Bits SCID Use Field 1 bit Insert Zone Flag 1 bit 6 Bits Virtual Channel ID VC Count 0-56 Bits Transfer Frame Header FECF Size: Identifies the size of the Frame Error Control Field and the applied algorithm VC Count Size: a one octet field is all required for adequate sequence control a zero octet field is all that is required for bypass and control/configuration directives Up to seven octet field can be used for sequence control, accounting and security for high rates Frame Length: Identifies the length of the frame Destination or Source ID: Set to Destination SCID, SCID: identifies the spacecraft to whom the frame is being sent OCF Flag: provides reporting for Go-Back-N protocols ( one way or bi=directionally ) and/or operational reports VC ID : identifies the rule set to apply for frame acceptance and content handling and routing Insert Zone: 1.can be used to provide source ID to allow recipient to know who sent data 2.can be used to provide access for low latency messages during Launch or Decent & Landing Inclusion of VC Sub channels : 1.provides the same functionality that MAPs and Ports provide in current TC & Prox without segmentation 2.enable the use of a single SA for multiple data streams emanating from the same User facility

8. THE FUTURE 8

9. Cross Support Changes Required for NGSLP Forward Services CSTS F-Frame Service Currently in definition to provide new symmetric forward cross support services. Support NGSLP frame assembly, frame merging and encoding in the ground station. Essential to support space internetworking (DTN); required for high rate forward optical comm. Can be development model for network wide frame multiplexing service for hubs The service will be layered to provide the required functionality: 1)The Frame building layer accepts user supplied data to create the transfer frame. 2)The Frame Multiplexing layer accepts frames from the underlying service and multiplexes them into a stream of frames for uplinking. Frame selection prioritization is a management function. 3)The Coding layer applies error correcting codes to the stream of frames. Depending on the NGSLP option selected either a single ASM is used (coupled) or a separate ASM and CSM is used. 4)The layer closest to the antenna will form the bit stream that will be modulated onto transmission carrier. Plan Comm - CCSDS Spring 2014 Meeting - Noordwijkerhoot, the Netherlands9

10. CCSDS NGSLP Work Plan Timeline 1.October 2013 1.Deliver a White Paper at CCSDS Fall Meeting 2.Get commitment for support from other International agencies 2.October 2013 – April 2014 1.Establish a Project with the SLP Working Group starting the process toward creation of the NGSLP Recommendation including a Concept paper. 2.Generated a Draft Green Book for the Protocol 3.Review the Concept Paper and Green Book at the Spring 2014 CCSDS Meeting 4.Officially sanction NGSLP as a project within SLP WG 3.April 2014 – October 2014 1.Generate a Red 1 Book for the Protocol 2.Review the Red 1 Book at the Fall 2014 CCSDS Meeting (generate RIDs) 4.October 2014 – April 2014 1.Work the RIDs and generate a Red 2 Book for the Protocol 2.Review the Red 2 Book at the Spring 2015 CCSDS Meeting (generate RIDs) 5.April 2014 – Nov 2017 1.Prepare Draft Blue Book 2.Get 2 independent implementations of the Protocol for evaluation (DLR has signed up) 3.Codify and publish the NGSLP Blue Book

11. BACKUP PlanComm - CCSDS Spring 2014 Meeting - Noordwijerhoot, the Netherlands 11

12. LINK PROTOCOL UNIFICATION OR “MISTER CCSDS TEAR DOWN THAT WALL OF INOPERABILITY NOW” CCSDS-NGSLP BB 12

13. NGSLP for Direct with Earth High Rate Links Plan Comm - CCSDS Spring 2014 Meeting - Noordwijerhoot, the Netherlands13 Version ID 3 bits FECF Size 2 bits OCF Flag 3 bits VC Count size 16 Bits Frame Length 1 bit Destination or Source ID Spacecraft ID 13 bits2 Bits SCID Use Field 1 bit Insert Zone Flag 1 bit 6 Bits Virtual Channel ID VC Count 0-56 Bits Transfer Frame Header FECF Size: set to 0 VC Count Size: up to 7 byte –for long term accounting and or as the security count for authentication Frame Length: 1.identifies the length of the frame 2.rubber banding allows TFDF to carry complete user PDUs Destination or Source ID: Set to Source SCID, SCID: identifies the spacecraft that generated the frame OCF Flag: provides reporting for Go-Back-N protocols ( one way or bi=directionally ) VC ID : identifies the rule set to apply for frame acceptance and content description Insert Zone: can be used to provide access for low latency messages Inclusion of VC Sub channels : enables a single SA to protect a VC including all of its Sub channels

14. NGSLP Header CCSDS Transfer Frame Headers 14

15. Telecommand – NGSLP Style Telecommand (TC) Protocol supports Direct From Earth (DFE) communication to a Spacecraft. Variable length frame structure that transports protocol control directives and mission control/operations messages (i.e. sequencing and instrument control). Incorporates a low performance forward error correcting code that doubles as an error detection code. The maximum frame length size is 1024 octets; necessitating the inclusion of a segmentation process. NGSLP can provide the same functionality as TC, but adds additional services. The key features of NGSLP that enables the upgrade of service are: The use of high performance block codes that can be either coupled or uncoupled with the transfer frame. The proposed codes can improve link performance by up to 9 db Longer frames and / or the use of data streaming (as done in TM and AOS) can be used to eliminate segmentation The use of Virtual Channel (VC) Sub channels provides an internal path identifier to direct the received data to a specific element within the spacecraft. Plan Comm - CCSDS Spring 2014 Meeting - Noordwijkerhoot, the Netherlands15

16. Telemetry – NGSLP Style Telemetry Protocol (TM) supports Direct To Earth (DTE) communication from a Spacecraft. Uses a fixed length frame structure that is coupled to a code block. The code and frame use the same synchronization word (ASM). The maximum fixed frame length is 2048 octets. The frame carries both a Master Counter (MC) counter and a Virtual Channel (VC) counter each 8 bits in length. A technique identified here as “streaming” provides a means to allow packets transported in a VC to span frames of the same VC. NGSLP can provide the same functionality as TM, but adds additional services. The key features of NGSLP that enables the upgrade of service are: Longer frame counter (MC) and longer VC counters to support higher data rates, reduce operational frame handling complexities and improve efficiency. Frames may either be coupled or uncoupled from the code blocks. Uncoupling the frame permits greater flexibility in frame length variability and coding choices. It also supports the irregular use of the Insert Zone to transport latency intolerant messages that can be inserted in the next frame that is to radiate. Plan Comm - CCSDS Spring 2014 Meeting - Noordwijkerhoot, the Netherlands16

17. Space Internetworking – NGSLP Style CCSDS has created a Encapsulation Space Packet to provide a shim to support networking protocols The encapsulation packet identifies the protocol data unit (PDU) it contains and as such identifies the network service process to which the PDU is to be delivered. The Virtual Channel process allows packets of from different applications to share the physical channel. This process also allows different packet types to be segregated This process requires a shim entity that can rebuild the network PDU using the packet process when the TM or AOS streaming process places portions of the packet in to multiple frames. NGSLP’s frame length flexibility and Virtual Channels and Virtual Channel Sub-channels provide the means to carry complete network protocol packets. Longer variable length frames that can “rubberband” to contain an integer number of IP, Bundle Fragments or LTP Segments data units. This process allows the frame handling process to extract the collection of complete network PDUs and deliver them to their respective processing entity. PlanComm - CCSDS Spring 2014 Meeting - Noordwijkerhoot, the Netherlands17

18. Other system elements that need to change for Optical Communication New coding, modulation and signaling to handle new optical comm features – Extensions to Service Management standard to schedule, request and configure all of these new link, coding, modulation and signaling features Interaction between receiving and transmitting terminals due to weather and/or slant angle – Uncoupled NGSLP enables the insertion of small control messages into the link either in the Insert Zone of by use of a small control frame Interaction between different ground stations due to weather and/or slant angle – Extensions to Service Management standard to handle station hand-over to deal with weather and “seeing” effects Weather may affect “seeing” at any of the possible ground stations – New standards for weather forecast and weather effects exchanges Plan Comm - CCSDS Spring 2014 Meeting - Noordwijkerhoot, the Netherlands18

19. Transfer Frame Header Transfer Frame Security Header VC Frame Data Field ( VCF_SDU ) Transfer Frame Security Trailer VC Operational Control Field Transfer Frame Error Control Field VC Transfer Frame 6-10 Octets 4 Octets Variable Mandatory Optional VC Data Field Received from SAP and inserted into frame Received from OC Service and Inserted into frame Calculated and entered into frame Computed and entered in frame Generated and entered into frame 1 1 4 4 3 3 2 2 5 5 Note: The number within the circles identifies the order of inclusion in the frame formation process Transfer Frame Assembly Master Channel Insert Zone Variable Optional Variable Optional Virtual Channel Insert Zone

20. Packets Packet Service VCA Service VCA-SDUs OCF Service Virtual Channel (VC) Formulation Add VC Header and increment VC Counter Insert Received VC-SDUs Insert OCF Compute and Add Security Header and Trailer Compute and add FEC( optional ) Master Channel (MC) Formulation Merge Received VC Frames TFDF_PDU ( VC_Frame Data Field ) Virtual_Channel_Frame MC_Frame Physical Channel (PC) Formulation - - Add Idle as required to maintain continuous bit stream Packet SAP Data Sub-layer Sync& Coding Sub-layer Packets Packet Service VCA Service OCF_PDU - Perform Security Process - Deliver Verified VC-Frames - Check VC Continuity - Extract OCF - Delimit Frames using Sync Marker - FEC Decoding and Derandomization - VC_Service Master_Channel_Frame Physical Channel (PC) Reception Acquire symbols Physical Channel Symbol Stream VCS SAP Data Sub-layer Receiving Physical Layer Sync& Coding Sub-layer Transmitting (sending) Side Receiving Side MC Service MC_Frame Virtual Channel Frame Separate MC_Frames Select VCS_SDU VCA SAP Extract Octets Extract Packets TFDF_PDU Creation - Build the TFDF Header - Insert Packet/VCA Data into FDF Extract OCF VC_Frame 1 of many VCS Service Separate VC Frames VCS_SDU Extract TFDF Add Attached Sync Marker Randomize FEC Coding Master_Channel_Frame Merge MC Frames Transmitting Physical Layer Merge VC Frames Separate VCS_PDUs Validate Frame using FEC (when contained) VCA-SDUs PlanComm - CCSDS Spring 2014 Meeting - Noordwijerhoot, the Netherlands 20

21. Pink sheets for separating Coding from Data Transfer Frame.docx 10/15/13 By V. Sank, M. Bertinelli Pink sheets for separating Coding from Data Transfer Frame Purpose Revise several sections, of CCSDS 131.0-B-2 and add one to allow separation of Data Transfer Frame layer and coding layer codes. Introduction The requirement on data Transfer Frames used with LDPC codes have been found to be unnecessarily restricted. Both DVB-S2 and SCCC use a slicing technique proposed here for CCSDS LDPC codes. 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. We have found that in several cases, satellite and transmitter vendors are including the coding in the transmitter and find it easier to not have to synchronize the Data Transfer Frame length with the codeword message length. Scope This pink sheet addresses the use of the LDPC codes. In the bigger picture, we suggest that CCSDS not require that the Data (Transfer) Frame length be of the same length as the codeblock message size. Impact of Slicing on Performance Since a code frame can contain the tail end of one data frame and the beginning of the next, the loss of one code frame can result in the loss of two data frames. However, the codes under consideration, LDPC in particular, but also SCCC, have such steep BER and FER vs Eb/No slopes that the real performance is either error free when slightly above the waterfall threshold or totally unuseable when slightly below the threshold. From a practical point of view, when using CCSDS LDPC, SCCC or DVB-S2 LDPC, there is no significant BER or FER impact. The same statement is not necessarily true for the concatenated RS+Convo codes. Even though the composite curve is also steep, the data must get through the convolutional decoder before it can get handed to the RS decoder. In many receiver implementations the convolutional curve dominates the system due to decoder lock limitations and the actual curve is not as steep as the ideal curve. PlanComm - CCSDS Spring 2014 Meeting - Noordwijerhoot, the Netherlands 21

22. End to End Data Flow and Processes with NGSLP by Ed Greenberg 9/29/2013 All frames use the NGSLP frame format each contain an ASM, a length field and a source S/C ID. The coding (LDPC) is performed in the physical layer in a manner such that the transfer frame is asynchronous to the code block. Thus a Code Synchronization Word (CSM) is required and is inserted between each code block forming a concatenate string of CSM and code block. Lander Frames are transferred to the Orbiter using a “Go back N” reliable transfer protocol. The VC of the received frames can be examined and placed into a designated buffer for selection to downlink. The Orbiter creates its own frames placing them into prioritized buffers for selection to downlink. The Orbiter provides a priority frame delivery service selecting frames from the buffers as required. Thus at the scheduled time to downlink the stored data, the orbiter pulls the framed data from the desired buffer. No processing is added and the stored frames are output serially to the radio where the data is chopped into code block sized pieces and encoded. The encoded code block is randomized then a CSM is prepended to the randomized code block and set up for transmission. This process continues till and the desired amount of data in the buffer is extracted and transferred. At the ground receiving station the received bit stream is searched for the CSM. Once the CSM is located a code block amount of data is derandomized and the passed to the decoder. The decoded octet stream is then searched for the ASM. After the ASM is found the frame length field is located and frame is delimited. The S/C ID and its VC are read from the frame header and using that information is passed to the pre-configured SLE RCF service. The frame is ten delivered to the mission’s data center that is designated for receiving the frames. Note: Lander always transmits the same transfer frame and always receives the same frame. It may also be possible to provide a “bent pipe” mode by injecting low rate Lander frames into the high rate downlink. PlanComm - CCSDS Spring 2014 Meeting - Noordwijerhoot, the Netherlands 22

23. NGSLP Issues 1.The Lander frame size and the Orbiter Frame size may be different. This can cause an impact on the reliable delivery process from the orbiter. The current frame retransmission approach used on MRO requires the operations team to know where the missed frames are located. 2.If the Orbiter and Lander frames are of different length the simplest solution is to store the Lander ASM with its Frame in the buffer. This increases the storage requirement but allows the frames to be extracted from the buffer without complete knowledge of where the frame boundaries are located. PlanComm - CCSDS Spring 2014 Meeting - Noordwijerhoot, the Netherlands 23

24. Protocol Features Format Larger Frame size Increased S/C name space Flexible frame sequence counter sizing allowing significant increase in frame counter size Enables frame counter to be used by security algorithm Inclusion of Sub-channels supports Go-back-N (COP-1) protocol Allows a single Virtual Channel to carry frames with diverse destinations Common format for all links (uplink, downlink and space to space links) Enables a Lander to use the same frames for direct to earth and relay links Provides the way to replace the Telecommand MAPs and Segmentation methodology by providing Sub-channels to replace MAPs and allowing packets to cross frame boundaries as per the current TM and AOS specifications. Coding Allows for the disassociation of the frame and the code block Allows for the use of short code word to be combined to form a code block Enables the coding to be limited to the transceivers as is the mode with commercial equipment (including those being purchased for LandSat Next. PlanComm - CCSDS Spring 2014 Meeting - Noordwijerhoot, the Netherlands 24