Home > News & Events > MITRE Publications > The Edge >

Satellites have traditionally brought with them limits on power, weight, and volume. To deal with these limits, it has been common practice to customize space communications systems. Each mission or set of missions has been more or less self-contained, with interoperability not an issue. Now, however, as cooperation among missions, agencies, and even nations grows, interoperability becomes increasingly important. At the same time, shrinking budgets and rising manpower costs are making custom development less feasible. A standardized suite of data communications protocols, then, would provide a common infrastructure to help solve these problems. Such protocols must satisfy a broad range of requirements and meet civil and military needs.

Recognizing the benefits of such standards, the Defense Department, NASA, and the National Security Agency have jointly designed, specified, implemented, and are testing a set of protocols known as the Space Communications Protocols Standards (SCPS). Four protocols have been developed: file handling, transport, security, and network. It is the transport protocol, SCPS-TP, that is the focus of this article. SCPS-TP (pronounced "skips tip") is actually the Internet protocol TCP (Transport Control Protocol), modified and enhanced to work in space. TCP, of course, is the well-known, well-tested transport protocol that, along with IP, is the backbone of the Internet. Transport protocols tell you what mode you are sending packets in. For instance, if you want every packet to be received by the destination, then the transport protocol can transmit in that mode. On the other hand, if you want most packets to be received as quickly as possible and losing a couple of them is not important, you can tell that to the transport protocol, and it will transmit packets that way.

The terrestrial environment for which TCP was designed, however, is markedly different from that of space. The response of TCP to an event in a wired environment would very likely be inappropriate if that same event occurred in space. SCPS-TP corrects those undesired behaviors in the space environment.

Note that the characteristics of space (intermittent connectivity, asymmetric links, long delay, multiple sources of data loss, and limited memory and CPU capacity) are like those of the tactical, mobile, and wireless environments. These can be referred to as "stressed environments," and the SCPS Protocol can work for tactical and mobile environments as well as space. Therefore, for the rest of this article, "stressed" and "space" will be used interchangeably.

As an example of the different responses taken by TCP and SCPS-TP to the same problem, consider the default response to packet loss. In the wired terrestrial environment, it is fair to assume that the loss of any packet can be attributed to congestion in the network. The right response of TCP is for the sending entity to reduce its transmission rate to lighten the congestion. In space, packet loss can likewise come from congestion, but it can also be caused by the satellite going over the horizon or by ratty links. (Calling a link "ratty" means that it has a high-bit error rate caused by not having the protection of a wired network, where the wire works as a pipe, keeping the protected link inside "clean." Ratty links in space can be caused by rain, solar flares, or interference from other signals or satellites.) The point is that recovery times from errors caused by ratty links or by a satellite disappearing over the horizon are usually long. Therefore, reducing the transmission rate in stressed environments is exactly the wrong response.

SCPS-TP uses a congestion control algorithm that does not depend on packet loss as a way to signal congestion in the network. In addition, SCPS-TP can react to explicit signals of the three sources of packet loss (congestion, ratty links, and the satellite disappearing over the horizon). The ability for SCPS-TP to tailor its response to the nature of the loss allows for better network utilization and better end-to-end performance without harming the overall network stability.

Testing
MITRE's SCPS team has conducted many experiments in the laboratory and the field to measure and verify the performance of SCPS-TP. (Whenever possible, TCP was also tested to gauge the relative performance of SCPS-TP vs. TCP.) Among these experiments have been three with live satellites: two "bent-pipe" tests (in which the spacecraft served as a passive relay) and one on-board test in which the spacecraft hosted the SCPS software. These tests examined SCPS-TP's use of various options and their behavior under real conditions. Close agreement was shown between the live tests and equivalent tests run in the lab. The results proved that SCPS-TP is well suited to the long-delay, potentially high bit-error rate environment of satellites. Using options such as Header Compression, Selective Negative Acknowledgment (SNACK), and TCP Timestamps produces varying effects under different conditions. (Detailed discussions of these experiments can be found on the SCPS web page mentioned at the end of the article.)

Figure 1. Use of TCP-SCPS Gateway

In addition to testing, the SCPS team developed high-fidelity simulation models of SCPS-TP and TCP using the OPNET simulation package. The validity of the models was corroborated by results previously obtained in the laboratory and field testing discussed above. The simulated results matched within 7.5 percent of the live measurements.

Test and simulation results for corruption (ratty links) and high data rate show that SCPS-TP performs up to 20 times better than TCP. Results under corruption and low data rate show that SCPS-TP performs up to 10 times better than TCP. The specific performance improvement in each instance depends on the value of system and transport protocol parameters, including data and error rates, file size, and packet size.

SCPS-TP Gateway
To allow hosts that do not support SCPS-TP to benefit from the protocol, the team built a gateway between TCP and SCPS, which connects wired and stressed environments without changing the user application. Figure 1 shows how the TCP-SCPS gateway might be used. The rear echelon wants to communicate with a forward deployment of vehicles. To do so, the sender initiates a TCP connection to a vehicle end system (ES). Router advertisements have made sure that any traffic to the vehicles will travel through the gateway. The gateway terminates the TCP connection, opens its own SCPS-TP connection to the end system, and relays traffic between the two. Neither the sending application nor the end system knows it is communicating through a gateway, yet both are benefiting from the ability to use the appropriate protocol for each environment.

For more information, please contact Mary Jo Zukoski using the employee directory.

Solutions That Make a Difference.®
Copyright © 1997-2013, The MITRE Corporation. All rights reserved.
MITRE is a registered trademark of The MITRE Corporation.
Material on this site may be copied and distributed with permission only.

Privacy Policy | Contact Us