Appox. 1 Month ago, one of my closest friend asked me for help. His CubeSAT Project runs into a HR-Shortage, lacking greatly on responsible for the design and implementation for a satellite transport protocol.
MOVEII is a CubeSAT, developed @ WARR, TU Munich which is completely under the supervision of students. It has a designed mission duration of 6 months @ orbit 600km. This is the 2. Satellite project carried out by students @TU Munich and shall carry some scientific payload for verification purpose. This Satellite is going to have a VHF/UHF 10kbps symmetric duplex link and a 1Mbps single direction downlink.
On MOVE I, TCP is used a transport protocol. Due to the fact of congestion control and flow control, in combination with the high runtime of SATCOM systems, it is very inefficient. The full headers and network layer is way too complicated and heavy to be efficient, even using UDP.
Therefore, we decided to create a customised protocol.
I’ve some experience with Airbone Transport Layer protocols, which is mostly based either on some kind of bus (MILBUS/CAN) for onboard communication, or by extended/modified IP stacks. Also, I think about lwIP, which i have used for the ECU Simulation on Cars. Both solution is less feasible for the SATCOM System, since every bit is quite valuable. Therefore the header region of the whole protocol is designed to be minimum, while keeping some extensibility.
The L2 Layer of MOVEII is providing a reliable link, with automatic retransmission request feature. Therefore, we decided to remove any feature regarding to retransmission. This shall be done on L2 and no redundancy implementation is provided to limit the header size.
One of the hard-requirement is reordering of packets. This is required since the L2 does not guarantee the in-order transmission of our packets within the transmission buffer of 256 packets. Therefor we choose a 8bit-number and a termination indication bit (a total of 9 bit) for global sequence numbering.
Another key target of this system is high reliability. This is what why we decided to run our system in user space and providing a centralized Deamon for service. This deamon is design to provide up to 128 slots(ports) for 128 applications, using another 7 bits of header space. By separation process queues in ports, it is guaranteed that blocking operation on some queue does not block the whole transmission system, which is quite comfortable.
The maximum transfer unit is 1000 bytes. This is chosen to leave other layer extensibility. This consumes 10 bit of space.
2 Bit is used for control message, for example for sequence number synchronisation. 16 bit is used to store CRC16 data to keep data integrity of both header and payload.
8 bit is used to process fragmentation number for reassembly of packets.
A total of 8 bytes is therefore used for the header, supporting CRC, reordering, synchronisation, fragmentation, 128 ports and 1000 bytes packet length, while leaving 4 bits for other control message and thus good extensibility.
Because I only have limited time, we found a nice student to support the implementation work. This whole program is written in C++ and providing service using linux domain socket. A separate programming library is used to talk to the domain socket.
We are currently investigation whether the speed is enough to carry out a TAP-Device to tunnel IP Traffic over our protocol, which will enable downwards compatibility and compatibility of standard network utilities.
The code of S3TP can be found here: