1

IP Telephony for Interplanetary Exploration1,2

Thom Stone3, Computer Sciences Corp. (CSC), NASA Ames Research Center, M/S 233-21, Moffett Field, CA 94035-

1000, 650-604-4971, tstone@mail.arc.nasa.govRichard Alena, NASA Ames Research Center, M/S 269-4, Moffett Field, CA 94035-1000, 650-604-0262,

ralena@mail.arc.nasa.govMarjory Johnson

4, Research Institute for Advanced Computer Science (RIACS), M/S 233-21, Moffett Field, CA 94035-

1000, 650-604-6922, mjjohnson@mail.arc.nasa.gov

NAS Technical Report NAS-04-011September 2004

Abs trac t—Voice over IP (VoIP), using techniquesdeveloped for telephony, is a natural method for providingvoice services for planetary explorers. Providing the abilityto make telephone calls over the Internet, VoIP can replaceradio frequency communications in remote environmentsthat are not serviced by a conventional telephone system.VoIP can provide better quality voice than either analogradio or conventional phone. As another benefit, VoIPenables the integration of voice and data applications, thuseliminating the need for separate frequency management andantenna systems.

This paper will provide an overview of IP telephony andwireless LAN concepts and examine VoIP applicability forplanetary exploration. The use of VoIP at the Mars DesertResearch Station (MDRS) will be evaluated. Benefits willbe highlighted and additional features that would bedesirable to incorporate with VoIP will be discussed. Thepaper will conclude with a discussion of VoIP studies thatwill be conducted by the NREN group in the future.

TABLE OF CONTENTS

INTRODUCTION...................................................... 1THE SPEED OF LIGHT—IT’S THE LAW.................... 2WHAT IS VOIP?....................................................... 3NREN VOICE SYSTEMS AT THE MDRS................... 3IP TELEPHONE FRAMEWORK FOR GROUND ANDSPACE.................................................................... 7STANDARDS AND IP PROTOCOL, THE TWOPILLARS OF VOIP FOR SPACE EXPLORATION...... 10FOR FURTHER INVESTIGATION............................ 10CONCLUSIONS ..................................................... 13ACKNOWLEDGEMENTS........................................ 13BIOGRAPHIES....................................................... 13REFERENCES ....................................................... 14

INTRODUCTION

The astronaut and her robot assistant make their wayacross the rocky field in the direction of the red mesa. Therobot follows, positioning its antenna where it provides thebest wireless Ethernet coverage back to the ship. It comesclose to her side to provide sample bags for the rubies shepicks up as well as for the fossils.

She looks up through her visor and says, “Telephoneexobio.” The phone is answered on the first ring. Severalpeople are on the line, but one answers. “Peter here. Howcan I help, Marjory?”

“There is a rather large creature with very big teethcoming off the mesa toward me. What do you make of it?”With that she raises her arm, and like the archetypeShinjuko teenager, shoots a picture with her wrist cellphone. Several people see the image on their phone setsand start to skim through a book. “I found it!” says Julia.“Page 172.” They all know which book.

Peter says, “Don’t worry, it is not a carnivore, but it eatshydrocarbons sometimes . . . Like clear plastic…LIKEYOUR HELMET . . . RUN!”

The above is fiction but the telephone technology describedis not. You may well have a phone in your pocket withmany of the features highlighted above. In late March andearly April of this year, the NASA Research and EducationNetwork (NREN) team from NASA Ames Research Center(ARC) supported NASA exploration technologydevelopment and field science teams in an expedition to theMars Society Desert Research Station (MDRS) nearHanksville, Utah. The MDRS has a “Habitat” structure in arugged extreme environment (simulating Mars) supportingup to six astronauts during two-week mission simulations.

Bill Clancey and Rick Alena from ARC were co-PrincipalInvestigators (PIs) for the “Mobile Agents” experiments.The Mobile Agents project, funded by the NASA IntelligentSystems Program, uses models of human work practice todrive automation of planetary exploration activities. Theseexperiments provide support for simulated planetary extra-vehicular activity (EVA) using mobile intelligent software

1 U.S. Government work not protected by U.S. copyright.2 IEEEAC paper 1547, Version 2, Updated December 9, 20033 Work supported by the NASA Advanced Supercomputing Division

under Task Order A61812D (ITOP Contract DTTS59-D-00437/TO#A61812D) with Advanced Management Technology Incorporated(AMTI).

4 Work supported by the National Aeronautics and SpaceAdministration under Cooperative Agreement NCC 2-1426 with theUniversities Space Research Association (USRA).

2

agents. The Mobile Agents experiment uses voicerecognition software to command the Brahms software thatsupports astronauts in the field. The official charter forM o b i l e A g e n t s f r o m t h e W e b site( http://is.arc.nasa.gov/HCC/tasks/MblAgt.html ) is:

Manned planetary exploration will require on-sitecoordination of astronauts, robotic vehicles, scientificinstruments and intelligent software agents. This task willdevelop a distributed architecture for simulation andcoordination of human-robotic EVA teams, includingmodel-based control of life support, communications, andspoken-language interfaces to rovers. Field data and workpractice analysis from the Haughton-Mars Project(www.marsonearth.org) will guide development.

Aerial View of Habitat

The cast of characters included several groups from ARC, arobot- (ERA- Extra Vehicular Activity Robotic Assistant)wielding group from NASA Johnson Space Center (JSC),and of course, the NREN Transportable Earth Station (TES)satellite support folks from NASA Glenn Research Center(GRC). During these experiments we jointly prototyped theuse of Internet-based phones for field studies.Geosynchronous communications satellites, with a quarter-second round trip time, are usually anathema for voicecommunications due to the high latency. We wanted to hearthe new generation of IP-based telephone systems over thesatellite and judge performance in the field for ourselves.There was also a field operations support role, since therewas no telephone service, not even cellular to that remotepart of Utah.

IP telephony has matured of late. It is no longer just a wayto use a PC to make a cheap phone call at the expense ofquality or a competing mass of standards and pieces thatdon’t quite fit together. Prices are now competitive withPOTS (Plain Old Telephone Service), and features arebecoming inviting.NREN management agreed to support the Mobile Agentexperiments and to supply connectivity via the TES mobilesatellite system. The TES consists of a trailer with a Ku-band satellite system and a van to pull it and to houseequipment for Internet connectivity and support. The

satellite station at GRC in Ohio routes the data from theTES to and from the Internet. The trailer and van areconnected via a 100-Mbps microwave link when deployed. The trailer is kept well away from the experiments becauseof the noise of the generator needed to run it. Figure Aillustrates the topology of the network built for the MobileAgents Experiment.

Transportable Earth Station (TES) in field

The remoteness of the Mobile Agent field experiments madethis a good testbed for communications prototyping. Voiceover Internet Protocol (VoIP) was one of the emergingtechnologies that NREN chose to bring to the desert.

The 2003 Mobile Agents simulations did not take intoaccount the effect of delays caused by light speed. Forexploration of Mars, the 20-minute delay each way will bean obstacle for interaction between people on the Martiansurface and people monitoring the mission on Earth. Therewill also be a habitat on the Martian surface, and referencemission concepts will use it as the primary point of missioncontrol because the habitat can communicate with the fieldparty in real-time.

THE SPEED OF LIGHT—IT’S THE LAW

It is well known that the speed of light will not allow forastronauts on Europa or Mars to carry on voice calls tofriends and family on Earth. However, VoIP technology canbe used for proximity communications between parties on aremote planetary surface, and on orbiters these technologiescan be extended to interplanetary capability by voice mailtechnology and other non real-time but standard commercialofferings.

3

Figure A: Mobile Agents Support Network, Hanksville, Utah

WHAT IS VOIP?

VoIP is a collection of technologies that use InternetProtocols (IP) and techniques to interact with the telephonenetwork. It includes using PCs as phones, using IP tocommunicate between phone switches and replacing voicePBX (private branch exchange) with “soft” IP-based PBX.

The worldwide telephone network is almost completelydigital (except for the link from home phone sets to centraloffices). The technologies used for analog-to-digitalcompression and switching, however, were developed in the1960s and are getting long of tooth.

Using newer voice compression methods saves bandwidth.Packet-switched voice makes more sense than circuitswitched voice where phone calls reserve bandwidth for thewhole call even when no talking is going on. Now, PBXsand other phone switches are being replaced by PC-basedsystems. This not only allows for voice compression thatuses less bandwidth and gives better fidelity, but alsoenables use over a single wide area network. It also allowsfor common equipment and support for both data and voice.IP features, such as multicast and Quality of Service (QoS),can be used to optimize feature sets.

In the present phone network, new voice features (callforwarding, number portability, caller ID, etc.) usuallyrequires new hardware upgrades for phone switches andtraining for technicians. IP switches can implement featureswith just software changes. “IP phones” are now available.Instead of an analog connection, these phones have Ethernetconnectors on them. They connect to IP call managers that

have the same functions as an old PBX. This allows for asingle wiring system for a building, which could result inlarge savings. Even more important, these IP phones canconnect to wireless LANs (WLANs). Wireless, high-speed802.11-type LANs are becoming ubiquitous, and there istalk that this technology may augment or overtake cellphone technology.

NREN VOICE SYSTEMS AT THE MDRS

NASA is interested in evaluating and using a variety ofcommercial products that can fill certain operational roles inNASA missions including voice communications. NRENborrowed an entire voice system from ShorelineC o m m u n i c a t i o n s i n S u n n y v a l e , C A( www.goshoreline.com ). The system consisted of two 24-port switches, the software for voice mail, and configurationmanagement that ran on a NASA-supplied Windowscomputer.

This system supports both IP phones (which attachanywhere on the network via Ethernet) and regular analogphones. Analog phones attach to the ShoreGear voiceswitches with telephone cable and RJ11 connectors.ShoreGear voice switches run a real-time operating systemand provide all call management (PBX) features. Thedecision to use the Shoreline gear was made late in theplanning and was a way for NREN to learn about deployingIP telephony. We did not obtain any Shoreline-compatibleIP phones for the mission, and as a matter of fact, tookseveral old cheap phone sets augmented with some bargainphones that cost up to $10 each.

Vbrick Codec

Glenn Research Center

Mars Society Base, Utah

Shoreline SG-24

Analog Phones

Ames Research

Center

Shoreline SG-24

Windows 2000 Voice Applications Server (Shoreline)

PSTN

NREN

Cisco IP Phones

Windows NT Cisco Call Manager

Vbrick Codecs

TES

Monitor station

Wired PCs in Habitat

Tsunami

6 MHz Ku-band sat. circuit

Wireless LAN

RJ11

RJ11RJ11

RJ45

RJ45

4

ShoreGear Voice Switches

Our system was laid out differently than the usual IP phonetopology where a switch connects to an Ethernet and/ortelephone sets on one side and phone lines on the other.There is no phone service anywhere near the MDRS andelectric power is by generator, so we required a distributedarchitecture. One ShoreGear voice switch was installed inthe Habitat at the MDRS with several voice phonesattached. That switch was attached via Ethernet to a routerthrough a wireless link and then to the satellite system. Thesatellite system was down-linked at GRC where a secondswitch was installed. That switch had one phone and twoanalog phone lines that attached to the phone network inCleveland. Figure B shows the Shoreline networkinfrastructure.

The team set up and configured the switches and server atARC. The most difficult part was setting up the Windowscomputer in a secure manner. The Shoreline system provedto be simple to configure, even for a crew that was not well-versed in telephony.

Astronaut Poses with Shoreline Phone

Astronaut in the Field

We wired the phones into the Shoreline switch in Utah andwaited until the satellite link came up and the configurationwould be uploaded from the server at ARC. Incredibly theswitch and phone network came up and worked immediatelyafter the link went active. We soon called the NREN teamback at ARC and asked for some configuration changesincluding the ability to add more phones. The changes weremade and the new phone lines were activated before wehung up. The Shoreline system provided all the function ofa PBX; all of the phones were extensions that could dialone another with four digits. This included calling from theswitch at the MDRS to the switch at GRC using four digitswithout having to go out over the phone network.

Voice quality over the satellite was our first concern. TheShoreline system voice quality was outstanding—no echo,no clipping and full tonality. It was hard to remember thatone was talking over a satellite link, and thereforeconversations were overrun on occasion. The digital signalprocessing of modern VoIP phone systems eliminatesdistortion and echoes caused by the delay times associatedwith talking over satellite links.

In addition to the Shoreline gear we also brought two CiscoIP phones to the expedition. These were borrowed from theLocal Network support organization at ARC who alsoassisted in the configuration of their call manager hardwareand router back at ARC. The Cisco gear had been obtainedseveral years ago. Much work needed to be done to upgradethe software to support the telephony, and configuration wasdifficult. We were never able to interface the equipmentwith the phone network to make calls from the MDRS. Wewere able to configure the IP phones as intercoms to allowdialing between the two phones in Utah and the phone atARC. Quality on the Cisco phones was good but not asgood as the Shoreline system. A faint echo could be heardon the Cisco IP phones. Figure C shows the Cisco NetworkInfrastructure.

5

Figure B: Shoreline Network Infrastructure

Tsunami 100-Mbwireless system

NREN

Satellite dish

MDRS Habitat, UT

Shoreline 24-portswitch

10 analog phones

Ethernetswitch

Monitor station

1/4 mile

To/From GRC

TESLA EarthStation

To NREN

Van

To/FromMDRS

Trailer

Router Win 2000 VoiceMail andConfigurationServer

EthernetSwitch

Shoreline 24-portswitch

PSTNAnalog phone

Analog telephone ports

Router

ARC, Mountain View, CAGRC, Cleveland, OH

Router

Router

6

Figure C: Cisco Network Infrastructure

ARC, Mountain View, CA

NREN

Satellite

GRC, Cleveland, OH

Lith Canyon, UT

Accesspoint

Cisco IP phone

5 milesPoint-to-Point

802.11b

ToGRC

TESLA EarthStation

To NREN

To/FromMDRS Router

Cisco CallManager

Note: No “outside lines” on Cisco system

Router

Hub

Repeatersite

HabitatBldg.

Cisco IPphone

MDRS, UT100-Mb Tsunamiwireless system

1/4 mile

Router

All TerrainVehicle Ethernet

switch

Monitor station

Van

FromGRC

7

The Mobile Exploration System (MEX) field team,supporting the Mobile Agents simulations, had wired someAll Terrain Vehicles (ATVs) with WiFi wirelessconnections and a computer system. These ATVs acted asrepeaters for the experiments in the field. We thought thattrying to include the Cisco IP phones onto the ATV wouldbe an interesting experiment. When the Mobile Agentsfield management decided that the definitive test of themission would take place over five miles away beyondmany hills, it was quickly determined that the tests wouldtake place out of walkie-talkie radio range. Up to that timeaudio radio communication was used to coordinate testingbetween the remote site and the Habitat. The IP phones,one mounted on an ATV and one connected via a hub in theHabitat, were “volunteered” to replace radiocommunications. At this point we were not sure if theCisco IP phones would even work over the wireless LAN orhow they would interact with the network data since we didnot apply any QoS (Quality of Service) to the WLAN.

Local School Children at Habitat with Shoreline IP Phone

We were rewarded in our faith in IP-based communicationswhen the phone link between the remote ATV and theHabitat worked flawlessly. Voice quality was clear and nodrops occurred—all this over two repeater hops in some ofthe most hostile environments on the planet. This was achallenge since the wireless network backbone couldproduce variable latencies similar to geo-synchronoussatellite links.

As previously mentioned, an important dimension of theMobile Agent experiments was voice recognition. The betterthe fidelity of the voice, the easier it is for the software toget the words correct. On an audio radio circuit the softwareperforms poorly. Telephone lines compress 3 kHz ofbandwidth into 64 kb/sec using the standard PCM (PulseCode Modulation). In contrast, MP-3 stereo audio (I lovemy MP-3) also takes 128-256 kb/sec but gives CD-qualitystereo fidelity. IP telephones compress voice ranging from8-128 kb/sec, and some systems allow you to choose thecompression methods. There will also be packet headeroverhead.

Rick Alena on Cisco Phone at Lith Canyon (5 miles fromHabitat)

We soon realized that using standard phone technologies forhuman exploration of space was a good idea. People areused to phones and their foibles and features. Radiocommunications with the “over and out,” strange buttonsand channels are not natural for modern people. Cellphones, voice mail and conference calls are. In some ways,telephones are simply modern extensions of voice radiotechnology, adding full-duplex communication paths,eliminating complexity, and integrating with thecommunications infrastructure. The marriage of telephonywith Internet technology is a great opportunity for spaceexploration.

IP TELEPHONE FRAMEWORK FOR GROUND AND SPACE

There are several applications for IP telephony at NASAbesides the obvious use as a voice analog PBX replacement:

• For use in NASA’s distributed SpacecraftOperations Center Architecture

At present, a separate network of voice lines isdistributed to special (and expensive) switches thatform “push to talk” voice conference groups ofthose involved in various aspects of monitoringand operating spacecraft (health and safety, payloadoperations, etc.). This is an area where IPtelephony could have a big impact at NASA.

• For use at field studies

For example, where investigators are at remotelocations doing science and need to communicateamong themselves, with a base camp, and with therest of the world. Features of radiocommunications (much like the voice conferencegroups described above) need to be included inVoIP for this to succeed.

• For use in interplanetary explorationAll of the features that are needed for supporting nomadicnetworking and other NASA applications are available now(or are easily added) but not all in the same package from

8

one vendor. NASA can exert some leverage and at leastfind a prototype for this communication.

In fact, NASA has already incorporated one form of modernVoIP equipment aboard the International Space Station. AVoIP phone is set up from Station to Mission Control inHouston allowing the astronauts aboard Station to phonehome! This system was a simple modification of acommercial (Cisco) product to account for the rather longtime delays associated with NASA’s Tracking and DataRelay Satellite (TDRS) system.

Here is a list of VoIP attributes that might be required forNASA field and interplanetary exploration and a briefdiscussion of each.

Wireless LAN phones

IP phones designed for operation over 802.11 (WiFi)wireless LANs are now being marketed. WiFi phones areoptimal for field work. It was well and good to hook awired IP phone to a WiFi repeater via a hub, but thefreedom of a truly wireless phone (with a long battery life)is what is required away from infrastructure. When tryingto match IP phones and VoIP systems, one finds that notall phones work with all systems even though each maysupport several VoIP standards. This maze of standards isone of the obstacles to widespread VoIP deployment. Wewill incorporate such a phone into the ATVs for routinefield team-to-habitat communication in future missions.

VoIP Standards

It is unfortunate that there are still many competingstandards for IP phones. Among them H.323, SIP (SessionInitiation Protocol - RFC 3261 and others) and MGCP(Media Gateway Control Protocol - RFC 2705-3435 andothers). It is important that a good VoIP system support allof them, and support should include all standard phonefeatures, not just dialing and ringing. Some current VoIPswitches also support standard voice phones connected viaRJ11 connectors. This is a plus to hold costs down.

Security

We do not have to worry about our telephony system onMars being hacked into and the Martians making longdistance calls to relatives on Io, but we do need to worryabout securing the terrestrial end of the link and securingany Earth-bound testing. For installations here on Earth,both the telephones and the central equipment need to besecured. Our experience is that the current crop of VoIPsystems is not designed with security in mind. This is anarea where NASA and other federal users can help providerequirements, road maps and access to technology.

Another aspect of the security problem is passing the VoIPinformation through firewalls. VoIP-distributed switchessend information between each other continually, as well assending the actual voice packets. The best way for allowingaccess through the firewall’s rule set is to use standardinterfaces such as SIP or MGCP that can use standardmethods to allow traffic. Otherwise navigating between the

firewalls of NASA Centers and of internal networks to passvoice traffic will be problematic.

Quality of Service (QoS)

Voice traffic requires that the network support trafficprioritization, as well as other QoS methodologies such aspolicing. It is important that IP Phones and VoIPequipment support the existing QoS standards. On theLAN (or WLAN) side, the ability to set the 802.1p (VLANtag) bits is minimal. On the VoIP switch side, the ability toset the DiffServ codepoint (or at least the IP precedence bits)is a requirement. Of course this means that the accesspoints, routers, switches and other exotica must alsosupport the standards. The new WLAN QoS standard(802.11e) will help as will the interoperability standard(802.11f). Internet QoS will allow for VoIP traffic totraverse complex networks without the annoying artifactssuch as clipping and echo. In the past, VoIP traffic waslimited to small single domain networks. DiffServ willallow VoIP traffic to traverse today’s complex networks.

Voicemail

There will be a need for voice communications betweenremote planetary explorers and Earth. Text messages are allwell and good but there is nothing like voice for personalcommunications. Distances make direct conversation viaphone difficult (we can get used to 1- to 2-second delays butnot to 40-minute delays). This is similar to thecommunications problems of some companies where peopleare always away from their desks, or even in families wherekeeping track of members is problematic, especially whentrying to plan an event such as dinner. The solution here onEarth has been voicemail. Although we profess to hate it, ithas become a primary communications media. We are veryused to leaving messages and checking for a reply. Voicemail is a good solution for long-delay situations (suchas interplanetary missions) as it has been for cases whereprojects span multiple, distant time zones.

IP telephony allows for voicemail and e-mail to beinterchangeable. Voicemail can be sent to e-mail accounts,and software exists to turn it into text. In the otherdirection, e-mail can be sent to wireless phones as eithertext messages or synthesized voice messages.

Just one more point about voicemail integration—there arestandard Internet mail interfaces. VoIP systems should notbe tied to a single mail package. It is important that mailintegration is available on many platforms and that itsupport many users’ preferences.

Push-to-talk and walkie-talkie features, conference bridgesand all that

This topic is too big for this paper. A basic facet of NASAmission management is the use of voice loops, with manypeople able to listen in on a large conversation betweenmany different people. Generally mission controllersmonitor several voice loops (i.e., conversations)simultaneously. It takes some practice, but people can makesense of several different conversation tracks at once! The

9

Mobile Agent project requirement for replacing walkie-talkies in the field means users in an interest group all needto be able to communicate in ad-hoc conferences. In aconference call having many participants, there is a real needto manage who is speaking, therefore mute and push-to-talkfeatures are a must for conference phones. Large conferencebridges will also be needed for VoIP operations centers. IPmulticast allows for this and more at a very attractivebandwidth cost. NASA is in a position to offer multicastexpertise to VoIP vendors and to provide test facilities forfeatures.

Compression options

Some IP phone systems have options to use various typesof compression. This document is not the place to discussthese options but only to say that some newer compressionmodes offer better quality at lower bandwidth. Thecompression modes are options between switch nodes andnot always between IP phone sets and associated switches. Some of these by default use 64-kb/sec ADPCM, and someuse more frugal technology. It would be a boon to allowusers to choose the compression method between IP phonesand switches. This is especially true for WLANcommunications where bandwidth can be at a premium.

Features and commodity PBXs

Aside from the great technology die off, the reason for theslow acceptance of VoIP was that conventional voice PBXstechnology had driven down prices and added feature setsthat were hard to surpass. Voice toll rates have alsodeclined to where converting to Internet-based voice couldnot be justified on toll rates alone.

The feature sets on these later generation PBXs haveevolved over the years to provide users with verysophisticated packages that VoIP solutions have only nowbeen able to match. Some of these features include:

• Simple interfaces for station adds moves andchanges

• Networking ability to use voice trunks fortraffic engineering

• Built-in voice mail• Directory services• The dreaded automatic voice response• Public address systems with distributed

speakers• Phone sets with speaker phone, call waiting,

transfer, limited conferencing, caller ID andmore

Early VoIP systems were built on PC Microsoft platformsthat were not reliable and did not include many features. Newer systems are based on real-time O/S and distributedarchitectures.

Voice recognition for phone features, dialing and mobileagents

Four-year-old cell phones have voice recognition. The voicerecognition and database are integrated with the tiny phone.

One large addition to this feature for interplanetaryapplications is that there may need to be intermediary voicerecognition software to segregate phone conversation fromconversation with local mobile agents (e.g., “Take a voicenote, I put the blue rock in bag number 182”).

Camera feature

Cell phones are now able to send snapshots over thenetwork. Because of the limited bandwidth of even “3G”networks, the images are fuzzy and of low resolution. IPphones, even those on WLANs, have more bandwidth towork with, and there is no reason not to take advantage byallowing higher resolution pictures and even video to besent using integrated cameras.

GPS locators

An important requirement for fieldwork in remote parts ofthis planet or others, is the ability to know one’s locationand impart this information to those who might provideassistance in case of an emergency. The Inmarsat satelliteconstellation offers single-button distress calls to marine(shipboard) subscribers. Inmarsat uses satellite triangulationto locate the distress beacon and sends the location andidentification to the nearest search and rescue organization.Cell phone companies are being asked by the FCC and statePUC to provide E-911 service. This will require everymobile phone to provide exact coordinates so the providercan connect to a nearby emergency service switchboard evenif the user’s phone has an area code a continent away.

Locating a mobile phone can be done either by triangulationfrom cellular towers or by providing GPS capabilities tophones. Some mobile phones currently on the marketinclude GPS (as part of a telephony-enabled handheldcomputer). It will be some time before IP telephonystandards are mature enough to allow manufactures to buildVoIP/mobile hybrid phones, but this is in some marketingplans already. When these combination phone sets are sold,they will also be required to impart location information.GPS locators are an option that should be included intoday’s VoIP phones. The technology is available. Locationis required for many field activities, and having anintegrated GPS in an IP phone will mean one less item tocarry.

Of course, GPS is a terrestrial system and would not beavailable on other planets. It could be posited however, thata positioning system of some type would be in orbit whenhumans are sent to explore a new world, and positionreporting can be included in our ideal universal phone.

Standard test procedures and compatibility

VoIP is mature enough that test equipment and software isreadily available, as long as equipment conforms toestablished standards. Equipment is available to simulatephone calls to ensure throughput on VoIP systems.Compatibility of equipment from different vendors is still alarge problem. Phone systems are complex with manyfeatures and these features can come in many flavors.Although equipment may be advertised as supporting

10

phones or other equipment, this support can be minimal andnot provide the service levels expected. There does not seemto be an organization dedicated to testing compliance andinteroperability of VoIP equipment as there is for WiFi.

STANDARDS AND IP PROTOCOL, THE TWO PILLARS OFVOIP FOR SPACE EXPLORATION

Standards: the bedrock

There are many standards that concern VoIP. Many specifythe same functions in different, incompatible ways. Someare incomplete, subject to interpretation that can render“compliant” equipment actually proprietary. The industryneeds to mature to see the benefits that interoperability canbring. Too much of the VoIP business comes from thetelco industry rather than from the Internet communitywhere this lesson was assimilated years ago.

IP Protocol: the common thread

The glue for seamless voice and data networking is theInternet Protocol family. IP provides all the hooks forcommunications so that voice, data, and video can use asingle physical network. It is adaptable over manytechnologies. If one wants to convert from 802.11a, or802.11b, or 802.11g, IP requires that only the physicalnetwork need be changed and no underlying software needsto be modified. Hybrid networks can be built using allthree standards if need be.

It may be that in the deep space environment, majorhardware changes are needed and devices designed forterrestrial use will not work or are not ideal for planetaryexploration. TCP presupposes a return link with low errorsand short roundtrip time. It may not be suitable for the longdelays and intermittent nature of deep space, but UDP-basedcommunication is proven in the space environment. Theuse of IP family protocols means that custom space-ratedhardware can be developed and tested, and the software andfeatures that are used by millions will still work in space.

It may be that instead of the 2.4 or 5 GHz bands, the Kaband, which will deliver very high bandwidth with verysmall antennas, is the best band for Mars communications.However, using IP means that the same telephone featuresavailable at the mall are available to astronauts on Marswith a few changes to the physical layer of devices. Themost difficult and costly portion of system development isthe definition of functions using standards andimplementing the software to perform the desired functions.Special hardware suitable to extreme environments can bedeveloped using the same system standards and softwarefrom commercial products resulting in optimal developmentcosts.

FOR FURTHER INVESTIGATION

NREN is using network monitoring tools to look at VoIPperformance in the field. Protocols and operations will bevetted to insure that distances will not be a problem fornormal operations. Software loads and configurationchanges will be watched to see if they can withstand the

space environment of loss and long delay. NREN is alsolooking at QoS methodologies for mitigating anycongestion issues on WLANs.

NREN has been looking in depth at traffic patterns from theShoreline and Cisco IP telephony systems and plans toextend this analysis to other vendors’ offerings some timein the future. We have found that each vendor’s system hasits own architecture and protocol suite, making comparisonsdifficult. However, the primary objective of our analysis hasbeen to find common patterns that are important forfacilities planning and traffic engineering.

NREN captured data from several field outings andlaboratory settings using our PCMon data collection andreporting system. We have been looking at the protocolflows between devices and wide area and local areanetworks. We will be expanding that to look at WLANtraffic in the near future.

The first part of our analysis will be to outline the protocolsused by the systems. Figure D shows the protocol flow forthe Shoreline network, and Table A is a description of theseveral protocols needed to provide telephone service via theShoreline offering.

The second part of the analysis will be to collect data andpresent it in tabular form. Figure E is an example of somethe output from the PCMon software from the MDRS field-tests. Data has been collected for each device and socket pairon the network from several outings. This data can be usedto answer questions about the bandwidth required for calls,usage patterns and overhead.

Table A: Protocols to Support Shoreline Offering

Protocol Layers Port Purpose

RTP (RealTimeProtocol)

UDP >RTP >G.711 orG.729a

Port5004

Send digitized voicepackets between IPphones and switches,and switches and thevoice mail server.Streams at 2400 or80,000 bi ts persecond

FTP (FileTransferProtocol)

TCP >FTP

Ports20, 21andothers

Send boot data toswitches from theconfiguration serverin case of corruption,and updates tosoftware to IP phonesfrom server

MGCP(MediaGatewayControlProtocol)

UDP >MGCP

Ports2427,2727

Call control for IPphones

SIP(SessionInitiationProtocol)

UDP >SIP

Port5441

Call control betweenShoreline switchesand ConfigurationManager, and betweenShoreline switches

11

Protocol) Manager, and betweenShoreline switches

RPCTraffic(RemoteProcedureCall)

TCP >RPC

Port1024andothers

Applications servicessuch as voice mail,tracking call activity,configurat ion ofswitches and loggingevents

http(HyperTextTransportProtocol)

TCP >http

Port 80 User interface toConfigurationManager

The third part of the project will be to actually use the datato optimize VoIP deployment. Here are some of the areasthat we expect our investigation to impact.

• The placement of hardware elements in ageographically diverse deployment can beoptimized when the protocol requirements areknown. For instance the Cisco Call Manager mustbe involved in each incoming and outgoing call;therefore it needs to be available to all phones andvoice mail systems at all times, but its traffic loadis small. The Shoreline Configuration Manager ismost interactive at startup and not required tocomplete connections. The voice mail server is partof the same physical system and may be verybandwidth intensive in some situations, so thisappliance also must be carefully located in thenetwork.

• A major reason that advanced QoS technology hasnot been widely implemented is the difficulty withderiving policy. It is not so much a question ofhow to classify traffic and expected behavior foroptimizing but of assigning bandwidth limits forthe classes. Knowing the expected traffic load fromthe complex protocols used for VoIP can aid insetting policing limits and discard thresholds.

• Fieldwork almost invariably involves constrainedlinks. Satellite connections and wirelessconnections, especially point-to-point wireless overlong distances, are typical of remote activities (asare sensor nets and other low-speed but persistentemitters). Agile QoS techniques can providefunctionality that allows for success in situationswhere bandwidth haggling could cause failure.Although we usually think of the RTP stream asthe totality of IP telephony, some of the otherprotocols need to be given priority to allow forconnections to be made and configurationscompleted.

• An example is when there are several phones usedin a field test connected via a limited-bandwidthwireless connection. Before and after the actualfield test, many phone calls may be needed tocomplete setup and to analyze results. During the

test, however, phone activity may need to belimited. Service levels can be set up to activatepolicing to limit calls when other real time datatraffic is active, and to “borrow” bandwidth forcalls when the data sources are quiet. This allrequires that traffic patterns are known for eachsource so that the circuit can be engineered toprevent congestion.

• If a link is over subscribed, then drastic measuressuch as using lower bandwidth voice digitizationmethods, RTP header compression or silencesuppression can be implemented. These methodsmay add to the cost, complexity or packet delay ofthe system and may not be available on the fly.Understanding the requirements beforeimplementation will allow for proper engineering.

• One of the most vexing problems with setting upIP telephony is devising proper firewall and routerfilter policy. Understanding of the protocolinteractions and traffic flows can result in moresecure networks and can aid in troubleshootingwhen IP phones do not work when used over a newnetwork topology.

12

Figure D: Communications Between Shoreline IP Phone and Network

Figure E: RTP Traffic from MDRS to GRC 6/24/03

Shoreline IP Phone

MGCP/RTP

Shoreline Switch

Configuration Manager Mail Server

Analog phones or Outside lines (analog or PCM)

• MGCP Media Gateway Control Protocol• PCM Pulse Code Modulation• FTP File Transfer Protocol• RTP Real-Time Protocol• SIP Session Initiation Protocol

RPC/FTP

SIP/RPC/RTP

13

CONCLUSIONS

VoIP technology has many advantages for proximity (on thesurface, or in orbit around a planet, or moon) voicecommunications. Voicemail bundling for interplanetarydistances is practical and is used today for collaborationbetween far away time zones on Earth. Immediate NASAuses include conference voice loops for mission control andcollaborative science teams.

ACKNOWLEDGEMENTS

The following people were instrumental in the VoIP effortfor the Mobile Agents testing:

CSC (Computer Sciences Corporation), ARC

Nichole Boscia and Mark Foster set up and configured theShoreline and Cisco voice system and provided supportfrom ARC. Mark Foster also engineered the PCMonnetwork monitoring system that provided traffic statistics. Thom Stone provided the overall project oversight and fieldsupport for the equipment.

NASA Civil Servants

Ken Freeman of ARC provided overall network oversightfor the NREN effort.

Rick Alena of ARC provided Mobile Exploration Systemhardware support in the field as well as being a MobileAgents co-investigator.

West Kurihara of ARC provided the Cisco VoIP system andtechnical support.

Mike Cauley of GRC, in addition to setting up the TESsatellite link, helped with testing the features of the VoIPsystems.

Vendors

We would like to thank Shoreline Systems, Inc.,(www.goshoreline.com) for their technical support and forthe loan of the equipment for the field activities.

BIOGRAPHIES

Thom Stone is a Senior Computer Scientist with ComputerSciences Corporation. He is attached to the NASA NREN

(NASA Research andEducation Network)project a t AmesResearch Center(ARC). Stone has beena t N A S A ARCemployed by variouscontractors s ince1989. He was anengineer with theNASA Science Internet

(NSI) project office where he led the project that boughtreliable Internet connections to remote locations includingUS bases in Antarctica, McMurdo Station and AmundsonScott South Pole Station. He was principal engineer forcommunications for the NASA Search for ExtraterrestrialIntelligence (SETI) project and was a senior engineer forthe Space Station Biological Research Project (SSBRP).Before his involvement with NASA, Stone was employed inthe computer and communications industry and taughttelecommunications at the undergraduate level.

Dr. Marjory Johnson is deputy manager for the NREN(NASA Research and Education Network) project at NASAAmes Research Center. During her twenty years with

NASA she has beeninvolved in severalnetworking researchprojects, includinglocal area networkingfor the InternationalS p a c e S t a t i o n ,d e v e l o p m e n t o fs t a n d a r d s f o rinternational spacecommunications, the

Bay Area Gigabit Network Testbed, and the NREN testbedproject.

Richard Alena is a computer engineer and the group leadfor the Intelligent Mobile Technologies (IMT) Lab and the

Mobile ExplorationSystem (MEX) testbed atNASA Ames ResearchCenter. The IMT teamin tegra tes mobi lehardware and softwarecomponents into uniquesystems capable ofe x t e n d i n g h u m a nperformance aboardspacecraft during flight

and payload operations. He was principal investigator forthe Wireless Network Experiment flown aboard Shuttle andMir, technology later adopted by the International SpaceStation Program. Alena spent four summers in the

14

Canadian Arctic developing mobile technologies for humanplanetary exploration. He is a co-investigator on theMobile Agents project, which is conducting fieldsimulations in the American southwest. He has aMSEE&CS from University of California, Berkeley.

REFERENCES

[1] Gil Held, Voice and Data Internetworking, New York:McGraw-Hill, 2000.

[2] John Dowding and James Hieronymus, “A SpokenDialogue Interface to a Geologist’s Field Assistant,” 2003Proceedings of HLT-NAACL, Edmonton, May-June 2003.

[3] M. Sierhuis, M. H. Sims, W. J. Clancey, and PascalLee, “Applying Multiagent Simulation to Planetary SurfaceOperations,” L. Chaudron (Ed.), COOP 2000 workshop onModelling Human Activity, Sophia Antipolis, France, pp.19-28, 2000.

[4] R. Alena, D. Evenson, V. Rundquist, “Analysis andTesting of Mobile Wireless Networks,” 2002 IEEEAerospace Conference, March 2002.

[5] R. Alena, B. Gilbaugh, and B. Glass, “CommunicationSystem Architecture for Planetary Exploration,” 2001 IEEEAerospace Conference, March 2001.

[6] W. J. Clancey, M. Sierhuis, C. Kaskiris, and R.vanHoof, Brahms Mobile Agents: Architecture and FieldTests, AAAI Fall Symposium on Human-Robot, 2002

[7] Mark Foster, “PC-based Network Traffic MonitoringOptimizes Existing Bandwidth,” NASA Gridpoints, Fall2000.http://www.nas.nasa.gov/About/Gridpoints/pastgridpoints.html

[8] Internet Engineering Task Force Request for CommentsLibrary, http://www.ietf.org/rfc/

[9] Cisco Systems, http://www.cisco.com

[10] Shoreline Communications,http://www.goshoreline.com

15