Latest News

by David Hahn, Thomas T. Griffith and Stefan J. Van Rafelghem

Imagine having the ability to upload instructions to a satellite or other space system via electronic mail. Or retrieving a space system’s latest image, status, or data files as if one were selecting a hypertext link on a Web page. Now imagine doing these operations without updating your desktop capabilities.

These and other applications are becoming a strong possibility as the demand for global connectivity continues to increase. This demand is causing an explosion in the satellite communications industry, including the increased use of low earth orbit (LEO) constellations. In the space research industry, the Mars Pathfinder, International Space Station and other recent missions are demonstrating increased information transfer requirements between ground and space systems. This demand relates to telemetry, tracking and control (TT&C) information as well as payload traffic.

Previous space systems were developed with specific communications architectures and protocols to support their individual mission requirements. These protocols define the structure, format, and procedures to transfer information between two locations. The ability to use a common suite of protocols, much like the Internet’s TCP/IP suite, would definitely simplify future space system designs and provide greater interoperability. However, the space environment poses numerous challenges to providing efficient, reliable transfer, including large propagation delays, bandwidth constraints, rate control requirements, intermittent connectivity conditions, and packet loss sources. To minimize the corresponding impacts, the TCP/IP suite must be optimized for these conditions.

The Satellite Communications Protocol Standards (SCPS) provide specific enhancements to the TCP/IP suite for space environment characteristics. SCPS is an open standard that has been accepted by the International Standards Organization (ISO). The goal of SCPS is to provide an accepted standard protocol suite similar to TCP/IP for maximum commonality and reusability. Since SCPS offers these enhancements as TCP/IP service extensions, they are fully compatible with TCP/IP. Some extensions alter the TCP/IP specification, thereby requiring a conversion between SCPS and TCP/IP, while others do not affect interoperability. Figure 1 depicts the SCPS protocols with respect to a TCP/IP implementation model and an International Organization for Standardization (ISO) Reference Model. SCPS (http://www.scps.org) offer several protocols and services for space communications.

First, there is a file handling protocol (the SCPS file protocol, or SCPS-FP) that is based upon the Internet’s file transfer protocol (FTP) and is optimized for the uploading of spacecraft commands and software as well as the downloading of collections of telemetry data. SCPS-FP provides the ability to retrieve and update complete files or portions of those files as well as retransmission mechanisms during link outage and transfer failure events.

Also, an underlying retransmission control protocol (the SCPS transport protocol, or SCPS-TP) is based upon the Internet’s transmission control protocol (TCP). SCPS-TP is optimized to provide reliable end-to-end delivery of spacecraft command and telemetry messages between computers communicating over a network containing one or more potentially unreliable space data transmission paths.

A networking protocol (the SCPS network protocol, or SCPS-NP) is based upon the Internet protocol (IP) and supports both connectionless and connection-oriented routing of these messages through networks containing space or other wireless data links.

Finally, a data protection mechanism (the SCPS security protocol, or SCPS-SP) provides the end-to-end security and integrity of such message exchange and is derived from the IP security encryption and authentication protocols.

The SCPS are being progressed towards full ISO standards via the sponsoring of the Consultative Committee for Space Data Systems (CCSDS). SCPS received ISO final recommendation status in May 1999. CCSDS (http://www.ccsds.org) defines specific formatting and framing specifications for TT&C telecommands and telemetry data. As such, CCSDS supports SCPS-based information transfers between ground control centers and spacecraft via wireless communications channels.

It should be noted that receiving ISO standardization is not to be confused with having the status as an Internet standard. The Internet is governed by separate organizations, the Internet Architecture Board (IAB) and Internet Engineering Task Force (IETF), that progress proposed improvements into standards for the Internet. The IETF’s recommendations for using TCP over satellite environments are focused upon minimizing the impacts of large propagation delays through faster congestion condition identification and resolution techniques. They state that corruption loss detection is a research issue, and they propose using “higher-quality” links or forward error correction (FEC) encoding algorithms (e.g., Reed-Solomon) to reduce the effects of high bit error rate (BER) on the link, thereby correlating any packet loss to be the result of link congestion.

The remainder of this article focuses upon the benefits of SCPS-TP for communications with satellites and other spacecraft as well as location and deployment alternatives for SCPS-TP protocols.

Scps-Tp Modifications And Differences From Tcp

The most critical area for optimization of TCP/IP for space communications resides within TCP. TCP is responsible for providing reliable information transfer between two end devices. SCPS-TP resembles TCP, but incorporates extensions and modifications that have been optimized to improve operation over a network containing at least one potentially unreliable data transmission path. These modifications have improved significantly performance over error-prone and highly asymmetric link conditions that frequently occur in the space and mobile wireless environments.

One major consideration is optimizing TCP’s identification of packet loss sources in this environment and its respective reaction to this event. At a basic level, TCP will transmit a small portion of the data, known as a segment, and await an acknowledgement from the recipient to confirm its proper receipt. After transmitting the segment, the TCP process sets an internal timer for when that acknowledgement should be returned. If an acknowledgement is not returned, TCP considers the packet as “lost” and reacts to the event by retransmitting the packet.

Current TCP implementations reflect transmission over existing terrestrial cables and links, where the existence of bit errors are rare. Under such an environment, packet loss is most likely due to a congestion situation somewhere within the network. Congestion occurs when a device that is routing and/or transferring the data within the network is overloaded with traffic. The result is a bottleneck that will delay packet delivery to the recipient and likewise will delay the return of the acknowledgement to the sending location. Therefore, if the timer expires without receiving the acknowledgement, the sending device assumes that the transfer is being subjected to network congestion and responds by halving its current transmission rate and retransmitting all data that has yet to be acknowledged.

Within a space or wireless environment, packet loss is more likely to be caused by error-induced corruption (due to noise on the communications channel) than network congestion. Within this type of environment, requiring the sender to react the same way as it does for terrestrial TCP may significantly reduce information transfer rates and lower the effective utilization of the space communications link. SCPS-TP expands TCP’s current capabilities by differentiating between (and respectively responding to) corruption-induced losses and network congestion situations. In both laboratory and satellite experiments, SCPS-TP’s extensions have demonstrated significant improvements in throughput and link utilization over TCP.

Another SCPS-TP feature is the ability to identify specific TCP segments that require retransmission. The feature is embodied in a special form of an acknowledgement (ACK) message, known as selective negative acknowledgement, or SNACK. When the recipient receives a corrupted packet, SNACK provides the recipient with the ability to request retransmission of the respective packet immediately, rather than waiting for the retransmission timer to expire. Using SNACK, the sender can retransmit specific segments of data and reset the respective retransmission timers for those segments to avoid unnecessarily invoking congestion identification and reaction mechanisms. The result is more efficient use of the link.

To minimize effects of the significant propagation delays associated with space communications, both the IETF’s Satellite Working Group and SCPS recommend the use of window scaling. To provide efficiency, a sender will transmit more than one segment while awaiting an ACK. The proper window size (or number of segments permitted) is generated from the product of the link bandwidth and the link’s propagation delay. Terrestrial TCP implementations will not exceed a transmission window size of 64 KB. While this may be sufficient for shared traffic volumes on the ground, it is not for a ground-to-space link where propagation delays are much greater. Transmitting more than 64 KB under good operating conditions is vital to achieving efficient communications. However, blindly expanding to a maximum value (delay*bandwidth product) is not always best either.

A better alternative, window scaling, permits the sending device to increase and decrease the size of its transmission window based upon the most recent ACK response times and congestion condition information as well as the current quantity of unacknowledged segments. Such a mechanism (referred to as a “leaky-bucket” method) uses a concept of “credit” to determine how many additional segments may be transmitted by the sending device at a given time.

Most space communications channels are configured asymmetrically, most likely where the downlink (or forward link) rate is significantly greater than the uplink (or return link) rate, where a ratio of 1000:1 is not uncommon. SCPS-TP provides header compression and special ACK mechanisms to offset the impacts of significantly asymmetric configurations and the respective link capacity. The goal here is to provide mechanisms to avoid saturating a link with information that it cannot handle. Current TCP implementations will generate an ACK for (at least) every other TCP segment received. In the event that the spacecraft is reliably transferring information over the communications channel to the ground, the volume of ACKs generated by such a transfer may saturate the return link. Thus, SCPS-TP provides a configurable ACK return rate based upon a calculated estimate of the round trip time (RTT). Furthermore, SCPS-TP provides a rate control mechanism to meter out the sending of data to compensate for potential retransmission impacts associated by the delayed ACK delivery.

For spacecraft in non-geostationary orbits, connectivity on a given communications link is usually intermittent. Contact may be interrupted for several reasons, including ground station handovers, antenna obscurations, and weather. The behavior of a spacecraft’s transition between two ground stations is similar to a cellular hand-off between two base stations, although the handover time is probably much longer. During this event, connectivity may be interrupted, temporarily causing a link outage.

TCP’s response to such an outage as well as the corresponding absence of ACKs will be to invoke its congestion control mechanisms discussed above. Under SCPS-TP, when a ground station or spacecraft detects a link outage, the respective device will generate a special Internet control message protocol (ICMP) message denoting the link outage and transmit it to any host on its side of the link. The sending SCPS-TP’s response to a link outage signal is to cease its transmission, suspend its timers, and send periodic probe packets. Upon the receipt of a “link-restored” ICMP message from the ground station (or when one of the probes gets through and is acknowledged), the sending SCPS-TP can infer that the link is restored and resume transmission from information on the original link outage ICMP message.

Through features such as corruption packet loss consideration, SNACK, window scaling, and rate control, SCPS-TP demonstrates greater use of overall link capacity on space communications channels. The ability to distinguish between congestion- and corruption-induced packet loss permits SCPS-TP to retransmit the necessary data segments without the requirement of halving the sender’s transmission rate and invoking a congestion avoidance mechanism. Performing these steps when packet loss is due to corruption results in a constant “draining” of the communications channel, which severely under-utilizes the link. Similar complications occur during link outage events, so SCPS-TP’s ability to identify and suspend transfer operations and timers during such intervals also avoids unnecessary congestion avoidance mechanism reactions. Finally, incorporating SNACK provides a faster resolution to retransmission requests, thereby improving transmission window advancement and performance.

Implementing And Testing Initiatives

The SCPS reference implementation was originally developed for several UNIX operating systems and is currently being implemented under Microsoft Windows NT via a U.S. Air Force Small Business Innovative Research (SBIR) contract. In addition to numerous laboratory simulation experiments, SCPS-TP has been subjected to several experiments over actual satellite communications links.

The purpose of these experiments was to assess SCPS-TP’s as well as regular TCP’s performance with respect to several space environment conditions (e.g., excessively high bit error rates, asymmetric channels, long propagation delays). Satellites used for these experiments included NASA’s Advanced Communication Technology Satellite (ACTS) over a U.S. DoD satellite communications link and the United Kingdom’s Science and Technology Research Vehicle (STRV). In each experiment initiative, SCPS-TP consistently demonstrated significant performance improvements over normal TCP using error-prone and highly asymmetric link conditions that frequently occur in the space environment.

While the majority of SCPS experiments have used experimental spacecraft, preparations are currently underway for a commercial satellite experiment. As part of this effort, SCPS will be implemented on the spacecraft’s real-time operating system (RTOS) and deployed to the spacecraft. In addition, the use of a ground station-based SCPS gateway implementation is also being considered for this experiment. This latest experiment initiative will demonstrate SCPS capabilities to support the satellite communication market in both current and future terms.

Scps-Tp Deployment Alternatives

While the benefits of SCPS-TP may appear overwhelmingly positive for efficient, reliable information transfer over a noisy communications channel, the actual implementation and location of those features must be considered prior to deployment. While an end-to-end SCPS-TP communication path may offer the highest reliability for ground-to-spacecraft communications, deploying a SCPS-TP process to every end station in a ground control network can quickly become a logistical nightmare as the number of end stations expand.

A more logical scenario is to use TCP/IP within the terrestrial (or wired) ground control network, use SCPS services within the wireless environment, and deploy SCPS to TCP/IP gateway conversion services in close proximity to the ground station. These gateway configurations occur at the TCP and IP layers and can either be implemented within the same platform or different platforms based upon normal operations. For instance, if the ground station is communicating with a geostationary spacecraft, configuring gateway services for both layers within a single platform at or near the ground station makes sense.

For spacecraft that are subject to ground station handoffs or small transmission windows, implementing the IP layer gateway service near the ground station and implementing the TCP layer gateway services in regional locations may be the better option. In doing so, SCPS-TP can determine link outage/handoff events, complete its current transmission window, and suspend further transmissions until the next ground station assumes contact with the spacecraft, at which point, SCPS-TP continues the transmission via the new ground station.

The advantage to a gateway implementation is the high use of commercial-off-the-shelf (COTS) products, including TCP/IP devices, within the existing terrestrial network. The disadvantage of a gateway implementation is that the transport layer’s end-to-end semantics are not preserved between the two environments (due to the protocol conversion). However, higher layer semantics (such as the application layer) are preserved.

In addition, a gateway implementation can provide benefits to enterprise networks using a satellite communications channel to connect to disparate networks, or supply reliability for terrestrial link outage events. Similar benefits exist under this scenario, including localizing the gateway service deployment and using SCPS within the wireless space segment while maintaining TCP/IP configurations in the terrestrial network segments.

Conclusions

The largest obstacles that the SCPS face at this time are industry acceptance and IETF adoption. Continued commercialization of the SCPS protocols and independent testing and evaluation by potential user communities and network providers alike is vital to achieving these goals. Specific investigation and experiments with respect to SCPS-TP’s congestion avoidance capabilities over shared communications channels appears necessary to satisfy the IETF Satellite Working Group and achieve mainstream use of SCPS to deliver payload information. In the meantime, SCPS-TP offers significant benefits to providing reliable information transfer between ground control networks and spacecraft to support TT&C as well as specific mission requirements.

David D. Hahn is director of sales and marketing for Avtec Systems, an engineering consulting firm, in Fairfax, VA. Thomas T. Griffith and Stefan J. Van Rafelghem are senior engineers at Avtec.


Get the latest Via Satellite news!

Subscribe Now