CCSDS Space Packet / USDLP Transport Layer GSoC '21 Final Report

This project implements the CCSDS (Consultative Committee for Space Data Systems) recommended protocol USDLP (Unified Space Data Link Protocol).

💡About the project

CCSDS

CCSDS (Consultative Committee for Space Data Systems) was founded in 1982 by various space agencies to discuss and standardize space data and information systems. They have designed specifications for space communications that are being implemented and used by several space agencies worldwide.

Space Packet Protocol

Space packets are fixed-length data units analogous to the IP packets. It contains fields such as the APID (Application process identifier) to identify the contents and source of the packet. The Space Packet Protocol defines methods to insert and extract data from space packets.

USDLP

Based on the OSI model [^1], the CCSDS has specifications for various layers in their networking stack. The Data Link Layer is one such layer that is responsible for data transfer between 2 connected entities. Errors that may occur in the Physical Layer are detected (also corrected) in this layer. Currently, most space communication systems use the TM/TC and AOS [^2] protocols in the data link layer. Each of them provides the capability to transfer various types of data for different purposes. The USDLP is a configurable and relatively new data link layer protocol from CCSDS that unifies all the other data link layer protocols. There are limited implementations of this protocol available right now. My work this summer for Google Summer of Code 2021 at LibreCube Initiative was to implement the USDLP protocol in python.

Overview of USDLP

This protocol provides several services to transfer data units over a space link. These data units are known as the USLP Transfer Frames. Each transfer frame has fields such as the primary header, the transfer frame data zone, the operational control field and the frame error control field. Each of these serves different purposes. For example, the primary header holds several data indicating the type of data the frame is carrying, instructions to decode the frame's contents, length of the frame, etc. The protocol also defines methods from both the sender and receiver's sides. On the sender's side, CCSDS has defined methods to add data into the transfer frames and to multiplex the frames into different channels before sending them to the next layer. Similarly, on the receiver's side, we have methods to demultiplex the incoming stream of bytes and extract the transfer frames and data from the frames if there is no error [^3].

Here is a complete flowchart of the entire USDLP specification from both the sender and receiver sides.

✅What's done!

Space Packet Protocol

USDLP

Other Contributions

👨‍💻What's left? / What's next?

The current USDLP implementation is not complete. As of now, it allows for transfer using the MAP Packet service. Here is a list of things to implement in the future:

• Other MAP services such as the octet stream and access service.
• Communications Operation Procedure Management service
• Transfer Frame Insert Zone Support and service.
• USLP Master Channel Operational Control Field service.
• Frame Error Control Field 32 bit coding procedure.
• Demonstration example of USLP.

⭐Acknowledgements

This project would not have been possible without the guidance of my mentors Artur Scholz and Milenko Starcik. I would also like to thank Shayan Majumder and Sarah Quehl for assisting me throughout the programme. I am grateful to LibreCube and GSoC for giving me this opportunity.

Ciao!

[^1]: The Open Systems Interconnection (OSI) model is an architectural framework for inter-computer communications. [^2]: Telemetry/Telecommand and the Advanced Orbiting Systems protocols. CCSDS Space Data Link Protocols - Greenbook [^3]: Errors in the frame are detected using the frame error control field which is the Cyclic Redundancy Check value computed from the rest of the frame.