CCSDS Next Generation Space Link Protocol (NGSLP)

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 Netherlands

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 decouplingthe transfer frame length from the code block size • Requires variable length frame service from coding & synchronization sub-layer • Separates link protocol from coding & synchronizationfunctionality 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) • AllowsSpace 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 naturallyperformed in communication devices not in data system

4. 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 NGSLP Frame

5. NGSLP Format with Payload Options 1 2 3 4

6. NGSLP Format Characteristics Data Driven (contained in Frame Header) Transfer Frame Managed VC Content Transfer Frame DataField (VCDF_PDU) Variable Optional • Link Managed Control Parameters: • Physical: Frequency (wavelength), Modulation, • 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: • Frame Services: Verify Frame is unmodified then deliver MC and/or VC frames • Insert Service: deliver Insert Zone content • Operation Control Service: deliver OCF data • VC content is managed by VC user: • Establish Security Association (or none) • Specify VC handling: Sequence Control, VC Sub Channels included, • Specify VC and VC Sub-channel content: Packets, Octets, IP Datagrams, DTN, other

7. NGSLP for Proximityor Telecommand Application Transfer Frame Header Destination or Source ID Insert Zone Flag VC Count size SCID Use Field Virtual Channel ID VC Count FECF Size OCF Flag Version ID Frame Length Spacecraft ID 16 Bits 1 bit 2 Bits 13 bits 6 Bits 3 bits 2bits 3bits 1 bit 1 bit 0-56 Bits • 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: • can be used to provide source ID to allow recipient to know who sent data • can be used to provide access for low latency messages during Launch or Decent & Landing • Inclusion of VC Sub channels: • provides the same functionality that MAPs and Ports provide in current TC & Prox without segmentation • enable the use of a single SA for multiple data streams emanating from the same User facility Plan Comm - CCSDS Spring 2014 Meeting - Noordwijerhoot, the Netherlands

8. The Future

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: • The Frame building layer accepts user supplied data to create the transfer frame. • 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. • 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. • 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 Netherlands

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

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

12. CCSDS-NGSLP BB Link Protocol unificationor “Mister CCSDS Tear down that wall of Inoperability NOW”

13. NGSLP for Direct with Earth High Rate Links Transfer Frame Header Destination or Source ID Insert Zone Flag VC Count size SCID Use Field Virtual Channel ID VC Count FECF Size OCF Flag Version ID Frame Length Spacecraft ID 16 Bits 1 bit 2 Bits 13 bits 6 Bits 3 bits 2bits 3bits 1 bit 1 bit 0-56 Bits • 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: • identifies the length of the frame • 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 Plan Comm - CCSDS Spring 2014 Meeting - Noordwijerhoot, the Netherlands

14. CCSDS Transfer Frame Headers NGSLP Header

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 Netherlands

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) countereach 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 Netherlands

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 Netherlands

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 Netherlands

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

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

21. Pink sheets for separating Coding from Data Transfer Frame.docx10/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 vsEb/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

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

23. NGSLP Issues 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. 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

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