The world's leading source of technology news and analysis
Search Spectrum IEEEXplore Digital Library Submit
Font Size: A A A
IEEE
Home [Alt + 1] Magazine [Alt + 2] Bioengineering [Alt + 3] Computing [Alt + 4] Consumer [Alt + 5] Power/Energy [Alt + 6] Semiconductors [Alt + 7] Communications [Alt + 8] Transportation [Alt + 9]

The Interplanetary Internet Continued By Joab Jackson

emailEmail PrintPrint CommentsComments ()  ReprintsReprints NewslettersNewsletters

Engineers at NASA's Goddard Space Flight Center thought they had proven that Internet protocols could be extended into outer space in a February 2003 Columbia shuttle experiment. Sadly, that mission was Columbia's last. Four days later, the spaceship came apart over Texas during reentry.

Earlier in that mission, the NASA engineers had transferred a file between Goddard and the shuttle, which was soaring almost 600 km above Earth. It was the first time that a file from outer space made its way back to a terrestrial command center without having its route set ahead of time. To receive that small but historic transmission, technicians had to orchestrate things so that the communications link with the orbiting spacecraft was handed off, like a cellphone transmission, from one ground station to the next. In other words, the equipment on the Columbia handed the data over to the network, and the network delivered the data to its destination.

The experiment was called CANDOS, for Communication and Navigation Demonstration on Shuttle. It had been a long time coming for Goddard engineer Keith Hogie, whose wire-rim glasses, mop-top haircut, and generally youthful demeanor belie his 54 years. Since the mid-1970s, the lanky engineer has been writing one complicated software program after another, all to do more or less the same thing—download and sort telemetry and other data. Each program worked with a unique piece of hardware, so it had to be written from scratch. But, fortunately for Hogie, a lot of the communications protocols he wrote were pretty generic.

After reinventing this wheel at least four times by the early 1990s, Hogie came to understand the power of the Internet Protocol. IP is the lingua franca for data communications. It's not just the way bits are packaged for transmission on the Internet but also how they are routed from machine to machine. As happens all the time on the Internet, two computer systems using wildly different hardware—a Hewlett-Packard PDA and an IBM mainframe, say—can pass the data back and forth, so long as they both speak IP.

For Hogie and the rest of NASA's telecommunications programmers, IP promises to greatly reduce the number of hours spent ensuring that NASA's diverse spacecraft can communicate with one another and with ground stations. If NASA were to adopt a common platform, along with standards on how data should be formatted, missions could use off-the-shelf communications software packages rather than requiring people like Hogie to write new ones. The success of the Internet over the past two decades has led to some assumptions about how data communications would work everywhere. On Earth, the Internet passes information in the form of data packets, whose bits may represent a Web page or an e-mail. Messages seem to flit from place to place instantaneously.

That isn't true in space. Message speed is capped by the speed of light, a limitation unnoticeable here but obvious out in space. It takes over a second for light to travel to the moon; light from Mars takes anywhere from 3 to 15 minutes to reach Earth, depending on the two planets' positions. Hopping through relay satellites, as most transmissions do, might double the transit time. As it turns out, those kinds of delays would doom a space connection using the standard protocols that govern Internet communication, because they require that the sending computer get a confirmation from the recipient machine that each data packet has been received.

IP doesn't include a mechanism to ensure that packets arrive at their destination, so it's never used by itself. Almost all Internet communication uses a second protocol as well, the Transmission Control Protocol, or TCP. Cerf and a colleague, Robert Kahn, introduced the pair in a paper in the May 1974 issue of IEEE Transactions on Communications. Telecommunications protocols are usually thought of as being stacked on top of one another, and in Cerf and Kahn's scheme, IP lies near the bottom of the stack, just above the physical connection between two devices (cables, radio waves, and so on). TCP operates at the next layer up.

On the Internet, TCP ensures a communications link between two parties by setting up a stream of acknowledgments between them. The receiving computer sends a receipt for each set of packets it gets. If the sending computer doesn't get these acknowledgments promptly, it assumes the network is congested and slows down the transmission rate, eventually resending the packets it hasn't heard back about. TCP made the Internet what it is today—always busy but almost never congested to the point of collapse.

The file transfer from the Columbia on that cold night in 2003 was not NASA's first attempt at extending TCP/IP into the heavens. Spacecraft had made simple connections with Earth, using Internet protocols, several times before. These experiments worked well, but they skirted another major challenge of space communications via Internet protocols: the need to go through multiple ground stations, and the handing-off difficulties this inevitably entailed. As the world rotates on its axis, only a few of the many ground stations scattered around the globe can communicate with an individual spacecraft, itself in motion. Relay satellites can improve a communications link with a ground station, as they remain in line of sight with the craft for longer periods of time. But the problem remains: to get a command to a spacecraft, a control center needs to know which ground station has a "view" of the craft at any given time.

So NASA planners painstakingly calculate ahead of time which ground station their craft can contact at any given moment. The chore involves writing out a timetable of sorts, either on a computer or on a whiteboard. With a craft's scheduled trajectory in hand, the NASA personnel calculate when it will be in contact with each ground station and schedule a communication session through that particular station. This is work that will grow ever more tedious as NASA puts more craft in flight. Wouldn't it be great to automate it?

CANDOS showed how Internet technologies could help. On Earth, messages and Web pages don't travel by precalculated routes. Data are packaged and then volleyed over the Internet by a series of routers—devices that relay packets from one network to another. A router examines the destination of a packet and then forwards it to a connecting router, based on two factors—which routers are closer to that packet's ultimate destination and which paths have the most bandwidth available at the moment.

On Earth, Internet servers (the machines that store Web pages, e-mail, and other data) sit in offices and data centers, as do routers. In space, though, satellites, probes, and other vehicles will have to act as their own servers, and they will always be on the move. So CANDOS tested a new protocol, called Mobile IP. Developed by the Internet Engineering Task Force (an influential volunteer group that sets Internet standards), Mobile IP allows servers to roam through space and still be reached.

NASA's scattered ground stations are positioned so that a spacecraft can always be in contact with one of them. So for Goddard's experiment, the team set up routers at ground stations on the island of Guam and at three U.S. locations: White Sands, N.M.; Wallops Island, Va.; and Merritt Island, Fla. The Goddard facility, near Washington, D.C., connected to these routers through an internal NASA network. That done, it could communicate with the shuttle regardless of where it was in orbit or which ground station happened to have the shuttle in sight [see diagram, "The Nasa Net"].

To prove how powerful this concept of using IP in space could be, the Goddard team set up a log-in account—a user name and a password—for some colleagues at the Marshall Space Flight Center, in Huntsville, Ala., so they, too, could access the ill-fated shuttle's computer. Without a standard TCP/IP connection, Marshall might have had to commission someone like Hogie to write the software that would make the connections to give access to its engineers. But with TCP/IP, accessing the shuttle was as easy as using an AOL account. Once logged on, technicians could upload or download files, check the logs to see how the onboard server was running, or do anything else the staff at Goddard could do.

The CANDOS trial was so successful that NASA engineers are starting to incorporate some of its technology into the agency's existing communication networks. CANDOS project manager David Israel and his team are working on something they call NASA Space Network IP Services, based on a set of permanent routers placed at NASA ground stations that will offer researchers the same IP connections that the Goddard and Marshall teams enjoyed. By 2007, these services will allow mission teams to turn their spacecraft into additional network nodes. Researchers on Earth will be able to manipulate onboard instruments, monitor the craft's well-being, and perhaps even route another spacecraft's data through it.

That assumes, of course, that these spacecraft will run Internet software and use Internet protocols in deep space. And that's something that will happen only if Goddard engineers can conquer the vociferous doubts of a team at NASA's Jet Propulsion Laboratory.


« Previous Page 2 of 3 Next »
emailEmail PrintPrint CommentsComments ()  ReprintsReprints NewslettersNewsletters