1
\$\begingroup\$

I'm working on designing a point to point communications link for a cubesat. I just want to confirm some of my understanding.

In my opinion it is only necessary to have physical layer and data link layer functionality. Why would we need an IP address or a transport layer for a single point to point link? But perhaps there is issues I am not aware of. I understand that we need to be able to keep track of packets that arrive out of order, or don't arrive at all. This is obviously an extremely challenging issue for a large network like the internet, but for a single point to point link, it seems reasonable to implement a simple packet reassembly scheme for ourselves.

Our mission is to monitor arctic sea ice using GNSS reflectometry data from GPS signals reflected off the surface of the earth. The more data we can downlink, the better. Hence, we are motivated to use protocols with as little overhead as possible.

Our transceiver is a microhard n290 transceiver, which has been flown on satellites in the past. It is not compatible with existing amateur satellite stations, we had no intent to interface with these existing networks. It provides FEC in hardware and a rate of up to 1.2Mbps uplink or downlink.

We know that we need a protocol that will expose a "packet interface" to us. That is, we need a link layer protocol to packetize the serial data stream.

Since we don't have any kind of network, we don't need an IP layer. As for a transport layer, we do need to be able to reassemble the data packets in the right order, and to ask for retransmissions. Is it possible to put something like TCP directly on top of the link layer, and cut out IP? This still seems like overkill to me though. Our telemetry and status data will fit into a single packet. As for the payload data, AFAICT all we need to do is break it up, label the data, and provide an order field. Is there any reason not to do this ourselves? It does not seem like a difficult task. I've done it in Python using google protocol buffers - I'm able to serialize a file, shuffle the order, and then reassemble it. I would need to put repeat requests on top of this, but everything else should be handled by the link layer.

I've been looking at the Saratoga protocol (http://saratoga.sourceforge.net/), but it is transport layer. So, doesn't seem like a good choice.

Point to point protocol (https://en.wikipedia.org/wiki/Point-to-Point_Protocol) seems to be the most sensible way to go. Right? It is as lightweight as it gets.

Thanks for any guidance :)

\$\endgroup\$
  • \$\begingroup\$ Could you give more details about what it is a cube sat ? \$\endgroup\$ – Stefan Merfu Jan 12 '16 at 1:07
  • \$\begingroup\$ Edited to add a link. It is a small satellite. Ours is actually a 3U cube sat meaning it's 10cm x 10cm x 30cm. So, the availability of the link will be periodic. \$\endgroup\$ – RJTK Jan 12 '16 at 2:22
  • \$\begingroup\$ you can use ipx, like udp but less headers and is an existing protocol. and is point to point, doesnt go through routers...really though if you are controlling both ends, it should be somewhat trivial, sync pattern (perhaps not needed depends on the physical layer), length, data checksum... \$\endgroup\$ – old_timer Jan 12 '16 at 2:36
  • \$\begingroup\$ add a packet number if needed. look at xmodem for example. \$\endgroup\$ – old_timer Jan 12 '16 at 2:36
  • \$\begingroup\$ Why do you write "We know that we need a protocol that will expose a "packet interface" to us. That is, we need a link layer protocol to packetize the serial data stream."? Wouldn't an error-free stream be more useful, or is there something else happening that I have missed? \$\endgroup\$ – gbulmer Jan 12 '16 at 5:12
4
\$\begingroup\$

Why do you not intend to use an existing protocol?

AFAICT, there are a bunch of protocols already in use, developed over many years, that have solved many of the problems, based on research and experience. So I'd use something that works and has been debugged unless you are doing research. If it is research, you need to describe the complete use-case, and not just some specific features of the use-case.

Old protocols may survive simply because the technology in satellites not only has to work, but also needs to be tested, characterised and 'certified' to work in space. That is an expensive, specialised and slow process. So saving cost and time by using something that is already known to work reliably makes even more sense than the usual Earth-bound engineering projects.

Is this for an commercial, research, or amateur project?

I know the amateurs have built the equivalent of a global network of ground stations, which hand-off to the next station as the satellite orbits (a bit like the ground-station network NASA or other space agencies have, but using equipment made available for parts of a day [the owners of the equipment use it too, themselves, for their own purposes] by enthusiastic amateurs). Are you trying to solve that problem?

In which case it might not be a single point-to-point communication. It may be multiple Earth-based stations each trying to talk to the same satellite. Or it may be multiple Earth-based stations trying to talk to multiple satellites.

If it is an amateur project, contact groups directly. The UK Amateur Satellite group is friendly, and members collaborated with colleagues in AMSAT-NL, in the creation of the software and network for the amateur-radio-based international network of ground-stations. They also built the low-cost radio hardware used to track their FUNCube CubeSat.

One of the earliest packet wireless networks ALOHnet went on to influence Ethernet and Inmarsat. So, for example, some of the successful ideas may be retained from that work. As long as it works, has no significant disadvantages, has been proven to work in space, and has hardware available, which is tested and space 'certified', what motivation is there to change?

Edit:

There are some papers on high-latency, and even a stackoverflow question Networking with extremely high latency which might give some inspiration.

There are old protocols with debugged implementations. These have the benefit that they are so old the machines they ran on had few resources, and so may be well suited to your application.

For example, the Kermit Protocol. That wikipedia article says "Kermit software has been used for tasks ranging from simple student assignments to solving compatibility problems aboard the International Space Station." So it has some useful pedigree :-)

It supports a 'sliding window protocol' which supports selective retransmission. That should help recover from errors and do re-assembly of damaged streams of data.

It is Open Source, and had C implementations. So you might be able to get the source and port it. Kermit ran on machines with less than 64k address space. So it might fit onto your hardware.

Even if Kermit is not a good fit, I would recommend looking at old (circa 1980's) protocols and implementations because the machine constraints may be comparable to the constraints of your in-flight hardware; even if your hardware is less constrained than the 1980's, your power budget might be helped by a low-resource protocol implementation.

|improve this answer|||||
\$\endgroup\$
  • \$\begingroup\$ It is an amateur project, we are a University team. ---------- We don't have the manpower to design our own transceivers, so we are using COTS devices which are not compatible with the existing amateur satellite stations. ---------- We are planning to use an already implemented protocol: Point to Point Protocol. We want to avoid using an IP and transport layer protocol because it will just add a ton of mostly useless overhead. My hope is that the application can keep track of how it split up it's data into the packets and then reassemble them. Telemetry and etc will fit in 1 packet. \$\endgroup\$ – RJTK Jan 12 '16 at 4:14
  • \$\begingroup\$ @RJTK - so are those COTS devices are 'certified' as space-worthy? What protocol have they 'flown with' in their previous expeditions? I would expect a resource-constrained project to use as much proven technology as feasible. so it might help us to give answers if you update your question and explain why you want to use a different protocol. (I am assuming the protocol implementation that has previously been used with the COTS transmitters is available for both ends) \$\endgroup\$ – gbulmer Jan 12 '16 at 4:19
  • \$\begingroup\$ I've added details. The n290 modem we are using has flown in space before. I don't know what software stack has been used with it. \$\endgroup\$ – RJTK Jan 12 '16 at 4:47
  • \$\begingroup\$ @RJTK - Thanks. Hopefully that will help people offer better answers. I have updated my answer a bit more. I think maybe digging through a few old, Open Source projects (for networking or file transfer) might get you a ready-made, tested, solution. \$\endgroup\$ – gbulmer Jan 12 '16 at 5:10
1
\$\begingroup\$

You DO have a network, whether you acknowledge it or not. Yours will not be the only cubesat in orbit, nor is it likely to be the only one on your allocated channel. Somehow your cubesat's messages must be identifiable from others, and relying on ephemeris data (yours should be overhead about ... now ...) is fragile.

Ditto the groundstation. Especially if you want to handle large volumes of data, you will want more than one groundstation. Cubesats often use a network of amateur groundstations, and if some guy in Woomera or Yakutsk picked up the packets you lost due to fading, great! But you probably only want your own groundstation to control the satellite, so you need to identify groundstations as well as satellites.

You can solve all of these issues by creating your own protocol ... with its own addressing system ... but re-using one is likely to be less work and increase cooperation with others.

I think you'll need more than PPP - perhaps TCP (without IP) would be a good candidate.

|improve this answer|||||
\$\endgroup\$
0
\$\begingroup\$

tftp? - small, light and well known.

(Simple) compression techniques may save sufficient packet length to make IP feasible, and allow you to reassign manpower to more interesting parts of the project.

Come back to IP removal once the protocol, device and application are working and fully tested using existing stacks.

|improve this answer|||||
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.