Data, Error Rates, and Availability

At a high level, your ground-to-space and space-to-ground system has five factors: data rate, bit error rate, end-to-end delay, link availability, and security. Security includes antijamming, antispoofing, verification of data integrity, and potentially (but unlikely for CubeSats) encryption.

The data rate is discussed in detail in pretty much every other chapter. It includes the issues of signal strength, bandwidth, data packet format, and many other considerations. It is basically the end goal of your comm system.

The bit error rate (BER) is the probability that some data will have errors. A BER of 10³ means that 1 in 1000 bits will be incorrect. Voice communications systems can usually handle that level of glitchiness. Compressed data, which often uses algorithms that require 100% data fidelity, require BERs of 10¹⁰ or better. For most CubeSats, where data losses are acceptable and compression and encryption are rarely used, we can go with a BER of 10³.

But there’s more to data fidelity than just the bit error rate. How can you can tell if data packets are bad? Can you request a retransmission of data if you determine some of it was bad? BER and data fidelity is even more crucial on the uplink of commands to the spacecraft and in the downlink of status messages on the satellite health, than in the downlink of spacecraft data. One key quality of data is that not all data requires the same fidelity.

One way that BER can be accommodated is by choosing a data packet format that includes a periodic checksum. The checksum is a final number that is computed based on the values of the preceding data. The checksum is computed by the sender before transmitting the data, then included at the end of that batch of data. The receiver then computers a checksum based on data received, and compares that with the suggested checksum. If it doesn’t match, there was a transmission error and a retransmission can be requested.

A very simple checksum might be, for example, that I send a sequence of four numbers plus a checksum that is “the tally of numbers that were odd.” So the data set of 4 1 3 6 would have a checksum of 2 (two numbers were odd). I then transmit 4 1 3 6 2—but assume there was an error and the receiver only got 4 1 3 5 2. When they calculate their checksum, they get 3, which does not match the transmitted 2, so they know an error occurred, even though they do not know what the error was. It it sufficient to just know it occurred and therefore not act on the data sent, just flag it as “bad data” and ask for a retransmit.

In practice, checksums are more detailed but follow the schema given as an example. A checksum typically indicates whether a given block of data was successfully transmitted; the recipient can then decide how to handle any blocks that fail the checksum check. A typical response for data is request a retransmit; a required response for actual command sequences is ignore and request a retransmit. Again, different data has different fidelity needs.

Given that command uploads and telemetry downloads are usually much smaller in data volume than actual instrument or image data, we can still maintain a reliable system with our lower BER.

End-to-end (E/E) delay is almost irrelevant for most CubeSat missions. The E/E delay is the time between message transmission and receipt by the ground. Because CubeSats rarely do real-time commanding or live relaying of communications, delays of seconds are fine. In low earth orbit, there is minimal light speed lag—even in geosynchronous orbits 35,785 km up, the delay is only 0.12 seconds. However, there may also be processing delays or the need for a remote ground station to relay its data to a central command office. Designing a mission so it does not need any synchronous communication is therefore ideal to avoid requiring higher E/E standards.

If you are using a data packet protocol that includes error checking and automatic requests for retransmission of bad packets, the E/E rate will hinder the ability to get a timely retransmit. Retransmissions might have to wait until the next contact pass. One common method is to schedule your contact passes so the first items are both the smallest yet most important for mission health, closing out with the longer transmission of the larger science data.

Link availability is exactly what it sounds like: how often the ground and satellite can communication with each other. Link availability includes both orbital and schedule issues as well as unexpected interruptions. Schedule issues typical with LEO CubeSats is that a single ground station will have only a 4 to 10 minute window per orbit, at best, to talk with the satellite. Unexpected issues can include items such as thunderstorms that interfere with the radio signal, or power outages that knock the ground station out. For a tumbling CubeSat, link availability may also include whether the changing satellite orientation affects the radio signal strength due to antenna pointing, causing dropouts or weaker signals.

Security

Security includes communications security (COMSEC) and transmission security (TRANSEC). COMSEC protects the data, through encryption and checksums and validation. TRANSEC is ensuring the signals, once sent, arrive safely and intact between ground and satellite.

Encryption is usable if your frequency allocation or comm provider allows it. Amateur ham radio is not allowed to use encryption, on the basis that you are sharing a public resource. Licensed or private communications each have their own Terms of Service (ToS) on whether encryption is allowed. Bear in mind that encryption generally adds to your data overhead—makes your data bigger. If you encrypt, you will get less data down than if you sent it in the clear.

For TRANSEC, anti-jamming is ensuring that someone else cannot block your transmission, for example by broadcasting at the same frequency as you but with higher power. For CubeSats, this is not a concern we can address; our transmissions tend to be on shared spectrum and in the clear. We typically rely on national agencies such as the FCC and IARU to police any cases where someone accidentally or deliberately blocks our attempts to communicate with our satellites.

The TRANSEC issue of anti-spoofing and the COMSEC issue of verification of data integrity are more crucial issues, though currently both are rarely seen with amateur satellites. Spoofing is where someone either pretends to be a legitimate ground station to try to take control of your satellite without permission, or fakes being your satellite to send you fake telemetry and data.

Users will probably try to see if they can hack your satellite and operate it. Two ways around this are security by obscurity and by the use of validation codes (passwords). Security by obscurity means you simply don’t tell anyone what your satellite commands are, so they can’t send their own commands.

One way to implement this is to have predefined command mnemonics that trigger satellite operations. If you don’t send a proper mnemonic, the satellite will ignore the command. So perhaps the sequence chsx1001 is the eight-character mnemonic for transmit health and safety now, and cmode1x1 tells the satellite to switch instrument 1 to a predefined mode1.

The downside of security by obscurity is that, if someone gets your list of allowed commands, they can now operate your satellite. The upside is that you will probably define mnemonics anyway, because they are a very efficient way to command your satellite. From a security point of view, though, they are not enough.

Passwords and validation codes are a second layer for security. A password is just like for a computer account—if the password isn’t at the start of your transmission, the satellite ignores it. The downside of passwords is, if you are transmitting them in the clear (unencrypted, in plain text), anyone that finds them out, again, has access to your satellite. Finding out can mean listening in to your radio transmissions, or asking someone on your team (social engineering).

One security method is to have an algorithmic component to the password, similar to a checksum, such that even someone intercepting a message still will not gain access. A simple example might be to start each message with a two-number code, which is based on the time at the start of the communication (using the clock onboard the spacecraft). So if the spacecraft thinks it is 05:47 when the transmission is received, it would expect the code 54 for a valid ground command, otherwise it will ignore it. Of course, this limits you to only a 10-minute window to transmit that command.

Security is not my field, and there are much more robust schemes out there, but this hopefully gives you a primer on basic communications concerns. One final concern is that you should be sure to physically secure your ground station. Restricting physical access to documentation and protocols goes a long way towards maintaining communications security.