Cubesat Space Protocol

CubeSat Space Protocol
Original author(s) AAUSAT3
Developer(s) AAUSAT3, GomSpace
Initial release 26 April 2010
Stable release
1.4 / April 7, 2015 (2015-04-07)
Written in C, Python
Operating system FreeRTOS, Linux, Mac OS X, Microsoft Windows
Type Protocol
License GNU Lesser General Public License
Website http://www.libcsp.org

CubeSat Space Protocol (CSP) is a small network-layer delivery protocol designed for CubeSats. The idea was developed by a group of students from Aalborg University in 2008, and further developed for the AAUSAT3 CubeSat mission that was launched in 2013. The protocol is based on a 32-bit header containing both network and transport layer information. Its implementation is designed for embedded systems such as the 8-bit AVR microprocessor and the 32-bit ARM and AVR from Atmel. The implementation is written in C and is ported to run on FreeRTOS and POSIX and pthreads-based operating systems such as Linux. Support for Mac OS X and Microsoft Windows will be available in version 1.1. The three-letter acronym CSP was adopted as an abbreviation for CAN Space Protocol because the first MAC-layer driver was written for CAN-bus. The physical layer has since been extended to include several other technologies, and the name was therefore extended to the more general CubeSat Space Protocol without changing the abbreviation.

The protocol and the implementation is actively maintained by the students at Aalborg University and the spin-off company GomSpace. The source code is available under an LGPL license and hosted on GitHub.

Description

The CubeSat Space Protocol enables distributed embedded systems to deploy a service-oriented network topology. The layering of CSP corresponds to the same layers as the TCP/IP model. The implementation supports a connection oriented transport protocol (Layer 4), a router-core (Layer 3), and several network-interfaces (Layer 1–2). A service-oriented topology eases the design of satellite subsystems, since the communication bus itself is the interface to other subsystems. This means that each subsystem developer only needs to define a service-contract, and a set of port-numbers his system will be responding on. Furthermore, subsystem inter-dependencies are reduced, and redundancy is easily added by adding multiple similar nodes to the communication bus.

Key features include:

Operating systems supported

CSP should compile on all platforms that have a recent version of the gcc compiler. CSP requires support for C99 features such as inline functions and designated initializers.

Physical layer drivers

CSP supports several physical layer technologies. The LGPL licensed source code contains an implementation of a fragmenting CAN interface and drivers for SocketCAN and the Atmel AT90CAN128, AT91SAM7A1 and AT91SAM7A3 processors. From version 1.1 onwards, CSP also includes interfaces for I2C and RS-232. Interfaces need only to implement a function to transmit a packet, and insert received packets into the protocol stack with the csp_new_packet function. CSP has been successfully tested with the following physical layers.

Protocol header

Version 1

The port range is divided into three adjustable segments. Ports 0 to 7 are used for general services such as ping and buffer status, and are implemented by the CSP service handler. The ports from 8 to 47 are used for subsystem specific services. All remaining ports, from 48 to 63, are ephemeral ports used for outgoing connections. The bits from 28 to 31 are used for marking packets with HMAC, XTEA encryption, RDP header and CRC32 checksum.

CSP Header 1.0+
Bit offset 31302928272625242322212019181716151413121110 9 8 7 6 5 4 3 2 1 0
0 Priority Source Destination Destination
Port
Source
Port
Reserved H
M
A
C
X
T
E
A
R
D
P
C
R
C
32 Data (0 – 65535 bytes)

References

External links

This article is issued from Wikipedia - version of the 7/29/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.