AIAA-2000-5295 Internet Technology on Spacecraft James Rash Goddard Space Flight Center Greenbelt, MD 20771 (301) 286-5246 [email protected] Ron Parise, Keith Hogie, Ed Criscuolo, Jim Langston Computer Sciences Corp (CSC) 7700 Hubble Dr. Lanham-Seabrook, MD 20706 (301) 286-3203 [email protected], [email protected], [email protected], [email protected] Abstract. The Operating Missions as Nodes on the Interact (OMNI) project has shown that Interact technology works in space missions through a demonstration using the UoSAT-12 spacecraft. An Interact Protocol (IP) stack was installed on the orbiting UoSAT-12 spacecraft and tests were run to demonstrate Internet connectivity and measure performance. This also forms the basis for demonstrating subsequent scenarios. This approach provides capabilities heretofore either too expensive or simply not feasible such as reconfiguration on orbit. The OMNI project recognized the need to reduce the risk perceived by mission managers and did this with a multi-phase strategy. In the initial phase, the concepts were implemented in a prototype system that includes space similar components communicating over the TDRS (space network) and the terrestrial Intemet. The demonstration system includes a simulated spacecraft with sample instruments. Over 25 demonstrations have been given to mission and project managers, National Aeronautics and Space Administration (NASA), Department of Defense (DoD), contractor technologists and other decisions makers. This initial phase reached a high point with an OMNI demonstration given from a booth at the Johnson Space Center (JSC) Inspection Day 99 exhibition. The proof to mission managers is provided during this second phase with year 2000 accomplishments: testing the use of Interact technologies onboard an actual spacecraR. This was done with a series of tests performed using the UoSAT-12 spacecraft. This spacecraft was reconfigured on orbit at very low cost. The total period between concept and the first tests was only 6 months! On board software was modified to add an IP stack to support basic IP communications. Also added was support for ping, traceroute and network timing protocol (NTP) tests. These tests show that basic Internet functionality can be used onboard spacecraft. The performance of data was measured to show no degradation from current approaches. The cost to implement is much less than current approaches due to the availability of highly reliable and standard Interact tools. Use of standard Interact applications onboard reduces the risk of obsolescence inherent in custom protocols due to extremely wide use across all domains. These basic building blocks provide the framework for building onboard software to support direct user communication with payloads including payload control. Other benefits are payload to payload communication from dissimilar spacecraft, constellations of spacecraft, and reconfigurability on orbit. This work is funded through contract with the National Aeronautics and Space Administration (NASA) Goddard Space Flight Center (GSFC). spacecraft. The objective is to characterize typical IntrOduction mission functions and automated end-to-end transport of data in a dynamic multi-spacecraft environment using oft-the-shelf, low-cost, commodi_,-level This paper will discuss the use of standard Interact standards. These functions and capabilities will applications and routing protocols to meet the become increasingly significant in the years to come as technology challenge of providing dynamic both Earth and space science missions fly more and communication among heterogeneous instruments, more sensors and the present labor-intensive, mission- spacecraft, ground stations, and constellations of specific techniques for processing and routing data become prohibitively expensive. This work is about Copyright ©2000bytheAmericanInstituteofAeronauticsand defining an architecture that allows science missions to Astronautics. Inc.Nocop}right is,assertedinthe UnitedStates underTitle 17.U.S.Code. TheUS. Government hasa royalty-free be deployed "'laster, better, and cheaper'' by using the licensetoexercise allrightst,nderthecopyright claimedherein for technologies that have been extremely successful in Governmental Purposes. Allotherrightsare reservedb_the today's [nternet. copyright o_her. 1 American Institute of Aeronautics and Astronautics Overview of Internet Protocols in Space hardware and software was used to test some of these concepts with an orbiting spacecraft. The goal of tile OMNI project is to define and Benefits demonstrate an end-to-end communication architecture tbr thture space missions. Tile authors have combined Increasingly, future space missions featuring multiple their knowledge and experience in Internet technologies spacecraft are being proposed. This includes and space communication systems in developing the constellations (disjoint or formation-flying), sensor- tbllowing end-to-end data communication concept. webs _ of heterogeneous spacecraft, and collaborative science between spacecraft belonging to different End-to-End Network Concept missions or with ground-based sensors. As the number of spacecraft involved increases, the number of The data communication requirements of many possible end-to-end routes for data goes up advanced space missions involve seamless, transparent geometrically. The present methods utilizing manual connectivity between space-based instruments, data routing, non-interoperable protocol options, and investigators, ground-based instruments and other custom data handling applications are not scalable and spacecraft. The key to an architecture that can satisfy rapidly become unaffordable due to the large amount of these requirements is the use of the lntemet Protocol _ manpower and custom development required. (IP). IP is the technology that drives the public Intemet and therefore draws billions annually in research and Using standard Internet protocols will allow robust, development funds. Most private networks also utilize dynamic, and automated end-to-end data delivery. IP as their underlying protocol. IP provides a basic Using standard Internet applications, such as FTP 6, standardized mechanism for end-to-end communication will allow exchange of data without designing custom between applications across a network. The protocol data handling and translation software. Also, custom provides for automated routing of data through any applications that require direct interaction between number of intermediate network nodes without affecting space-based and ground-based components are easily the endpoints. implemented through a familiar interface. These factors will reduce the risk and development time for Spacecraft environments pose numerous challenges that space missions, increase the accessibility of science have direct analogs in the ground-based mobile IP and data, and enable cost-effective realization of new science wireless networking industries, such as: capabilities such as: • continually intermittent links • Data exchange directly between spacecraft • multiple mobile nodes forming a dynamic network • Correlation of data in space topology • Collaborative science among unrelated sensors • maintaining asingle address for a spacecraft as it within and across missions uses different ground stations • Easy reconfiguration and deployment of new types • highly asymmetric or unidirectional communication links of collaborative science across multiple missions • Direct access to science payloads and data by The increasing populai-ity of laptop computers, principal investigators or collaborators handheld digital assistants, and Internet cell phones has driven the development of protocols to handle mobile Along with these new capabilities, significant benefits nodes, such as Mobile IP" (MIP) and mobile routing. are envisioned across all phases of a mission life-cycle. They are also driving the development of new Significant cost savings and risk reduction are protocols such as Cellular IP_, Dynamic Source achievable in all tile tbllowing areas: Routing 4 (DSR), and other ad-hoc-networking protocols. Mission Design This paper will examine several standard [ntemet Mission designers are currently constrained by the applications and protocols specified by the Intemet narrow range of services provided by the current Engineering Task Force (IETF), and map them to system. Any deviation from the basic telemetry and spacecratt applications. It will also describe how telecommand services i,nmediatelv drives the cost up standard, commercially available communication by requiring added so(t_are development to provide -.) Alncrican Institute or :\ertmautics and A_;tF(m:tuttc>+ functionality already present in the IP network model. Operations Mission design will be laster and simpler using industry, standard communication interlaces. This will All of the advantages from the earlier mission phases allow designers to spend less time doing data also cany over into the mission operation phase. communication system design and focus more on the Lrsing the same communication interthces from initial specific science and mission details. Minimizing design and development through operation allows the mission specific interface control documents (ICDs) same monitoring and control software and knowledge will also expedite design and reduce costs as well ,as bases to be used across the entire mission life-cycle. the risk of errors. This avoids developing and testing separate interfaces and software systems for initial development, Software Development imegration testing, and operation. Most software engineers are already experienced in Seeu rity designing applications that utilize Internet protocols for communications thereby reducing or eliminating the An': suggestion of the use of public networks for data learning curve required for custom protocols. Software dis_,ibution, or common data transmission protocols design and development will be able to take advantage on the space-to-ground link, naturally generate of the large base of software and services already questions regarding security. But this is also a serious defined, documented, implemented, and tested in concern for businesses that use public networks for commercially available operating systems and financial transactions. These businesses safely transfer applications. Custom on:board applications will be trillions of dollars per day over public networks using developed and tested more quickly using familiar commercially developed security solutions. The interfaces. requirements of business users such as these have spurred the development of a suite of IP based security Hardware Design protocols such as IPsec 7, virtual private networks g (VPN), and secure socket layer (SSL). There are currently several on-going projects to develop flight quality versions of standard network components. There arc three basic tools available to provide a secure These components will facilitate a building block link on both the command and telemetry data path approach to spacecraft system design. All subsystems between the spacecraft and the user. These are: can have astandard interface and can be prototyped and built independently without fear of incompatibilities Auth entication later in the overall development. Authentication provides a means of ensuring that data httegration and Test packets received by the user are indeed originating from the desired address (i.e. spacecraft or instrument). This Current integration and test procedures require the use is commonly accomplished through virtual private of specialized hardware and so_vare to simulate the network technology, which is widely available for all interfaces to the spacecraft. Using a common suite of platforms. standard communication interfaces for spacecraft subsystems will allow" laboratory testing of the En cryption subsystems via the same interfaces that will be used in flight. The development of radiation hardened, standard Encryption of data in the IP packets can protect the data local area network components will facilitate all aspects from discovery by unauthorized persons. A wide of the integration and test phases. Using Internet variety of commercial encryption packages are available technology as a common communication mechanism to provide this capability. from spacecraft subsystems to the end user will allow Private Networks very early functional testing of subsystems to identify.' problems long before traditional integration and test. Catching problems earlier can provide significant cost Private networks can provide additional securib' by' savings and risk reduction. eliminating outside access to the data stream. NASA currently uses a closed network between all of its ground stations a_d centers and can provide secure 3 American Institute of Aeronautics and Astronautics connectiotnosthisnetwortkooutsideinvestigatoarts (SMTP) to deliver the files as attachments. For universitieasndotherinstitutions. example, in the commanding case, the control center emails the command load to the spacecraft as an Alloftheabovetoolscanbeemployeidndividuallyor attachment. A mail server at the groundstation stores in anycombinatiotno satisfythemissionspecific the tile until the next contact and then automatically securityrequirementsA.uthenticatioanndencryption transti_rs it to the spacecraft tbr processing. Similarly, canbeimplementeeidthefrromtheusetrotheground- in the data delivery, case, the C&DH processor, or even stationo,rfromtheuserallthewaytothespacecraft a "smart" instrument, emails the data file as an dependinogn the missionrequiremenatsndtht: attachment to a message sent to the principal availabilitoyfon-boarcdomputinrgesourceTsh.eyca'_ investigator. The onboard mail se_'er stores the file beusedontheuplink,downlink,or both,andin until the next contact and then transfers it to the ground conjunctionwith a privatenetworkprovide_m for automatic delivery to the owner of the data. extremeslyecurseystem. The 1P suite supports various commanding scenarios. IP-Based Operations Scenarios When the downlink is not available for acknowledgement, "blind" real-time commands can An IP-based communication architecture can support sent to the spacecraft using UDP. This is required for all existing operations concepts and makes some _Jew, emergency situations such as rescuing a spacecraft from complex concepts realistic. tumbling. For nominal operations, reliable commanding can be achieved by using TCP, which For example, real-time erigineering and housekeeping automatically takes care of performing the handshaking data can be monitored during a pass using UDP/IP and any necessary, retransmissions. packets. This only requires a uni-directional downlink. On the other hand, if a return link is available, These basic capabilities, and the end-to-end network guaranteed reliable delivery of data packets can be addressing capability of IP, can be used to support achieved by using TCP/IP. In both cases, only a new, complex scenarios. These include user simple application layer function needs to be wri:ten for interaction, spacecraft cross-support, and ad-hoc the flight software. collaborations. Recorded science and engineering data can be stored These scenarios also highlight the capabilities needed onboard in files in a standard file system. These files for constellations of spacecraft. Formation flyers could can later be transferred to the ground with guaranteed send messages back and forth to keep their group complete, time-ordered records using an off-the-shelf navigation within specifications. Constellations of application such as FTP. If the round-trip delay times nanosats could message their data to larger members are too great to use a TCP-based protocol such as with the power for delivery, to the ground. FTP, a UDP-based protocol, such as Starbu:st/MFTP, could be used instead. Onboard clock synchronization, typically a thorny Proposed Architecture problem, can be handled by using the Ne:work Time Protocol _' (NTP). NTP can automatically calculate Recognizing the clear benefits of IP as an end-to-end propagation delay times, time variance, and drift rates, relative to one or more reference timeservers. It can set networking protocol, the OMNI project developed a reference system architecture for the space and ground the spacecraft's clock and even perform periodic drift segments of future IP missions. The goals were to mitigation. The NTP protocol is capable of precision maximize the use of COTS hardware and protocols on the order of 240 picoseconds if sufficient bandwidth while avoiding creating any new "space-specific" and CPU speed are available. solutions. A high-level view of this architecture appears in figure 1. Several notable features are present, and are Store-and-fonvard commanding, and data delivery', can discussed in the folto_ing sections. be achieved by using Simple Mail Transport Protocol E') 4 Amt titan Institute c_lAcr(maulics and Astronautics Router Spacecra i ........................................... : [............................................................. • Figure 1 - System Architecture for an IP Mission Onboard Spacecraft IP LAN HDLC Framing One of the key features of this architecture is the Based on its near-universal use on the terrestrial incorporation of an IP stack in the onboard processor, Internet, HDLC framing was chosen for the link-level and the use of peer-to-peer IP networking via an protocol on space-to-ground links. This allows onboard LAN. This allows end-to-end network simple, strai_tforward interfacing with existing addressing, distributed processing and "smart" commercial routers in the groundstation. instruments, while providing for legacy processor- lnteroperability between multiple vendors is assured by controlled "dumb" instruments. The processor, each choosing the IETF encapsulation for multi-protocol "smart" instrument, and the router each have their own over frame-relay/HDLC. IP address on the LAN, and are directly reachable from any node on the network. The router takes care of At the physical layer, HDLC framing is extremely delivering packets to the appropriate address without simple, consisting of only a 1-byte flag pattern, a processor supervision. This is in contrast to the variable number of data bytes, and a 2-byte CRC. conventional master-slave architecture of a typical 1553 During any idle time, successive flag bytes are output bus spacecraft, where the processor must be responsible until the next frame begins. Flag bytes consist of a zero for all bus traffic by managing the bus time-slicing in bit, 6 one bits, and a zero bit. In order to prevent this real time. Candidate LANs include CAN, Ethernet, pattern from occurring in the data, the HDLC hardware IEEE- 1355, and IEEE- 1394 (Firewire). performs "bit stuffing" when sending data. Any sequence of 5 one bits in the data automatically has a Spacecraft Router Function zero bit inserted after it, thus insuring that any sequence of 6consecutive one bits must be a flag byte. At its basic functional level, the router performs simple When receiving, these extra zero bits are automatically conversion from one lirik-tevel interface to another. For removed from the data. example, the spacecraft router in figure 1 could be converting HDLC _ flaming on a serial link into While the primary purpose of "bit stuffÉng" is to Ethernet framing on a LAN. In small, simple ensure the uniqueness of the flag byte, it also has an spacecraft, there may be only a single "dumb" additional benefit. It ensures that a long unbroken processor-controlled instrument. In these cases, a LAN sequence of one bits in the data does not produce a would not be needed, and the spacecraft would have a signal to the transmitter that does not have periodic single IP address for the processor. The remaining transitions. These periodic transitions are important at router functions could then be performed in so_vare on the receiver, where a bit-synchronizer depends on them the processor. This configuration minimizes costs to extract the clock and data bitstreams from the raw while still retaining the benefits of end-to-end IP signal. Along the same lines, the use of standard NRZI networking. coding tbr the HDLC output will insure that _m unbroken sequence of zero bits in the data stream becomes transformed into an alternating sequence of 5 American Institute of Aeronautics and Astronautics onesandzeros.Thus,theuseof"bit stuffing"i,dle telcmetrx and image data in I_DP'IP liom Otlr flag bytes,anti NRZ[ codinginsuresthat the 'Vo._ager spacecraft', via TI)RSS. to a "'mission transmittewrillnevesrendallunmodulatceadrriera,nd operations center" at Goddard Space Flight Center. thereceivewrill seeatransition at least once every' 6 Figure 2 shows our "'spacecraft" in a reD, low bit times. It is important to note that these "space •"parking" orbit. Note the autopointing S-band antenna specific" requirements can be met by standard COTS tm tile root" and tile weather station on the rear. hardware and protocols without inventing any "space Subsequent tests over the next t_w months specific" solutions. It should be further nctted that demonstrated the utility of a wide variety of protocols these solutions are isolated to the lowest layer and are and applications, such as FTP, NTP. NFS _:, and http, transparent to the upper layers. The application layer in spacecraft operations. Scenarios involving does not have to concern itself with generating "fill intermittent contact, station handover, and one-way packets" or "fill frames". links were all successfully demonstrated. Separation of Framing and Coding It is important to note that any forward error correction (FEC) coding, such as Reed-Solomon or convolutional, is performed independently from the framing. This is in accordance with the OSI layered model of networking, where framing iscarried on at the data link layer and coding is down at the physical layer. The coding simply treats the HDLC data as a bit-stream to be protected. Ground-Based Demonstrations In late 1998, the OMNI project began constructing a "proof of concept" ground-based prototype of an IP spacecraft. An instance of the reference architecture was Figure 2 - The OMNi "Spacecraft" constructed using a PowerPC processor and the VxWorks operating system. These are both In August of 1999, we constructed a duplicate system commonly used in actual flight missions. VxWorks and used it to return instrument data and images from comes with a standard IP stack available. An Ethernet- the deck of a ship in the Black Sea that was observing based camera server was used as a "smart" instrument, tile last total solar eclipse of the millennium. The data and a weather station and a GPS receiver were used as was webcast in real time and viewed bv thousands. In serial-port based "dumb" instruments. A small Cisco addition, the system provided SMTP (e-mail) and 1601 router initially handled the interface between the Voice-Over-IP capabilities. Ethernet LAN and the HDLC serial link to the RF gear. Later, it was rep!aced by a 1 1/2" x 1/2" x 2" In November of 1999, the van-mounted system TinyRouter. Inthe lab, the RF gear was replaced with provided support lbr the Johnson Space Center (JSC) an AdTech Data Channel Simulator to provide settable Inspection Day "99 Exhibition. providing real-time delays and error rates. Later, the RF link was provided images and two-way voice from the _an to visitors at by an ECOMM transceiver, going through the NASA the display booth at JSC. Tracking and Data Relay Satellite System (TDRSS) in geosynchronous orbit. At the TDRSS groundstation Space-Based Demonstration in White Sands, NM, the serial data lines to and from the transmitter and receiver were connected to a serial The O*INI project had been looking tbr opportunities port on a router already connected to the Internet by the to demonstrate IP in space tbr the last ',ear. However, South Pole TDRSS Relay (SPTR) project. many of the spacecrali candidates were deemed unsuitable due primaril? to their onboard In Februa_' of 1999. we mounted tile entire IP COlllmtlllicatiotl hardx_are, r:_e ke, issue was to t'ind a spacecmtt prototype in a Plvnlouth Vova,,er minivan, spacecmt't that couM support FtDI.C fiaming in and began condt, cting mobile demos, flowing real-time hard',_are It? a]iti'.', 5illlr@2, ._tr:li_httor,aard interfacing 6 .-\mcrican Institute ofAcr(mau/Jc:-; ,rod..\stn :nautlc', withexistingcommerciraolutcrs.[heserequirements In February 2000, CSC let an initial contract to VyTek madeUoSAT-1(2figure3)anidealtestplatforma,sit Wireless of Pittsburgh, PA, formerly VyTek LLC, to alreadyusedHDLC ti'amingto carryits AX.25 supply the soNvare porting, spacecraft time, and protocol. SinceHDLC[/Ohardwarweasalready ground-station time for a series of flight tests. Initial presenotn-boarodn,lyflightsoftwarcehangewsouldbe tests of IP connectivity were scheduled for early April requiretdoadapUt oSAT-1t2ouseIP.Changetosthe 2000, with tests of spacecraft clock synchronization, groundstationwouldalsobeminimalr,equirinognly reliable file transfer, and blind commanding to follow theadditionofa standarcdommerciaroluteranda in May/June 2000. programmabswleitch.Seefigure4. Follow-on work is planned to demonstrate http file delivery, mobile IP, security, and store-and-tbr,,vard commanding and data delivery using Simple Mail Transfer Protocol (SMTP). These tests are expected to be performed in 3Q/4Q 2000. Spacecraft Implementation Since the UoSAT-12 spacecraft was already in orbit, only software modifications were possible. Because the spacecraft was built to be a flexible prototype test environment, it was straightforward to upload and test new software to support IP over HDLC. Ground Station Implementation Since the SSTL ground station already supported HDLC framing, a standard Internet router was the only addition needed. Figure 4 indicates the basic components of the ground station and where the router Figure 3 - UoSAT-12 Spacecraft was added in parallel with the existing AX.25 communication front-end. In December 1999, the OMNI project contractor, Computer Sciences Corp. (CSC), began negotiations The only station reconfiguration required is to select to have an IP stack ported to one of the spacecraft's which system is connected to the transmitter. This is onboard processors, using HDLC/Frame-Relay for the done with a controllable switch, which supports fully link-layer protocol over the RF communication automated passes for either the IP or AX.25 mode. system. This would allow the ground station to directly connect the receiver to a standard low-cost The SSTL ground station is built on an Ethernet LAN router, providing end-to-end IP connectivity between with firewalls and router connectivity to the lnternet. an IP address on the spacecraft and any node on the Two addresses were used on the ground station LAN lnternet. Further discussions covered porting File to support these tests. One address was used for the Transfer Protocol (FTP) and Network Time Protocol Ethemet interface on the router and the other address (NTP) to the spacecraft's operating system. was assigned to the spacecraft. 7 American [nstitutc of Aeronautics and Astronautics Addition to.support IP,: F ou,er Tmrat ne,r 9.6 Kbps Modem "eceiver FroAnXt-.e2n5d 38.4 Kbps R9-530 Sync Ethernet t Internet Figure 4 - SSTL ground station configuration server running, but disabled from actually changing the Flight Tests spacecraffs clock. The onboard server periodically negotiates with the USNO timeserver to factor out The initial IP tests with UoSAT-12 were designed to network delay. If it is successful, the onboard server verify, the operation of standard Intemet packet routing calculates the offset it thinks it has to apply to the from the spacecraft's operating system to anywhere on spacecraft's clock. This value is sent to the ground in a the Internet. The "ping" utility was used to UDP telemetry stream, where it is logged for later accomplish this and to characterize the basic link analysis. For purposes of this testing, the NTP propagation delay. These tests were successfully negotiation period is set artificially low to 30 seconds completed on April 11, 2000, and are covered in more so that a reasonable number of data points can be detail in a paper presented at the Small Satellite 2010 collected during the 14 minute pass. A short time into conference 13.We believe this to be the first instance of the test, a command is sent to the spacecraft to enable a spacecraft as a fully RFC-compliant node on the NTP to actually change the onboard clock. NTP will lntemet. require two successful offset calculations before it will adjust the clock. Later in the test, a command is sent Subsequent tests were designed to demonstrate to the spacecraft to manually set the onboard clock in implementing clock synchronization (a standard error by a large amount (2-3 seconds). After two operational spacecraft function), using standard IP-based successful offset calculations, NTP should again reset applications. For the clock synchronization tests, a the clock. If the time is offby more than one second, standard NTP client was ported to the UoSAT-12 the spacecraft NTP client adjusts to the proper second spacecraft. It was used to automatically synchronize the during one adjustment period, and adjusts for fractional onboard clock to UTC. On the ground, the US Naval seconds on the next adjustment period. Observatory's timeserver (tick.usno.navy.mil) was used as the reference timeserver. This configuration is shown The results for the test run on April 14, 2000 are in figure 5. This represents somewhat of a worst-case shown in figure 8. The pass began with a spacecraft test, as the USNO is a quarter of the way around the clock offset from UTC of approximately +-300 ms. Two world, over 20 router hops, from the UoSAT-12 calculations after NTP time-changing was enabled, the ground station in Surrey, UK. In a real operations calculated offset dropped to less than two clock ticks environment, a timeserver of the required accuracy (20 ms) and stayed there until it was manually set in would be located at the groundstation to minimize the error from the ground. A ground command was used to network latency and variation that NTP has to factor set the clock ahead by approximately 3.25 seconds. out. However, NTP is designed to deal with these Two otti_et calculations after that. NTP had reset the factors, and the resulting levels of accuracy might be clock to within six clock ticks of UT¢, taking an quite adequate /br many space missions even under additional two offset calculations to settle within two worst case conditions. clock ticks of UTC. Two tests were pertbrmed, both t'ollo_ing tile same scenario. The test starts out with the onboard NTP American Institute _I" .Xerep.mtic'_ and :\stronauttc>; ® tick.usno.navy.mil ' i'. ' Surrey-> UoSAT • PING NTP USNO ....... NTP ' NTP .... P/NGco'nt'rol-(}einet) Figure 5 - NTP test configuration 2.500 Time by Ground Commar_d 2.000 NTP I Time Change I Enabled I- .-L _._ 1.500 NTP NTP 'i\ Time -I I Time _- Correcti0n I. Cbrrectior 0 1.ooo t _ _ O0 l 0.500-_- - - -%- _ -_.- =_- <5 o o o <5 0.000' I I I I I I I I I I 16:25:00 16:27:00 16:29:00 16:31:00 16:33:00 16:35:00 UTC Figure 6 - NTP test result 9 American Institute ofAeronautics and Astronau[ics Current information on test results and future activities Future Work will be posted on the OMNI project web site at http: ipinspace.gst'c.nasa.gov'. Festing of the File Transt_r Protocol (FTP operating Conclusions over the Transmission Control Protocol (TCP)) was initiated after the NTP tests and is currently in progress. Files were successfully transti_rred and work The current activities have demonstrated that standard is currently underway to adjust some of the "standard Internet protocols will function in a space environment TCP tuning parameters to optimize performance. The and are useful and effective in typical spacecraft results are nearing the theoretical maximum operations. throughput, and will be the subject of a future paper. The las[ 18 months of tests and demonstrations have The activities so far have been done in fairly simple shown that HDLC framing and IP packets provide a and controlled configurations. More work is needed to very simple and flexible communication mechanism for investigate additional protocols required to properly space communication. HDLC framing is well deploy Intemet protocols in worldwide, operational supported in a wide range of COTS products and has space communication networks. Implementing HDLC been used on spacecraft for over 10 years. Using the flaming and IP packets on spacecraft and installing Intemet Protocol as a network layer allowed easy touters at ground stations are not major problems. The integration and testing of our end-to-end scenarios. main issues are to deal with network security and the Also. both HDLC and IP required no modifications to highly mobile aspects of spacecraft. operate in intermittent space link conditions. The OMNI project is in the process of expanding its HDLC flaming provides a minimal byte overhead test environment to include multiple spacecraft along with a link level error check. The variable simulators and ground nodes for testing mobile IP and length of HDLC framing also results in very simple mobile routing protocols. These investigations plan to data packing and unpacking since one IP packet use the Linux and VxWorks operating systems on the normally ends up in one HDLC frame. A large UDP spacecraft simulators and Cisco IOS 12.1 or newer packet can be sent, causing IP fragmentation, but this software on the ground routers. is under the application programmer's control and can be completely avoided if desired. The biggest benefit Security solutions based on Internet security protocols of using HDLC is that it is supported on virtually any (lPsec) and virtual private networks (VPNs) will be communication hardware that has serial interfaces. configured and tested along with the mobile IP environment. Using the IETF multiprotocol encapsulation over frame relay has proven to be very robust and supported on The mobile IP and security work will focus on issues ever3' piece of communication equipment we have lbr deploying IP in operational space communication worked with. We have mixed equipment from different networks. Additional work is also planned to identify vendors on serial links, and there have been no spacecraft control and data delivery applications to use compatibility problems. Frame relay equipment can over a space IP network. 'One of the main application also be used to provide basic fo_varding of frames we,as to be investigated will be reliable file _,_sfer in without any IP processing involved. This provides space environments. This will tbcus on file transfer additional flexibility' in deploying communication applications that operate over UDP and that can then systems. operate in communication environments with extremely long round-trip times and link bandwidth While many of the Internet protocols (i.e. TCP, FTP, asymmetry. NTP) work in lull-duplex communication scenarios, we have also successfully used others (i.e. UDP) in Fhe GSFC science user community is organizing a either receive-only or transmit only scenarios. During workshop to discuss lnternet protocols in space, to be the tests described in this paper, a one-way UDP based held at GSFC in November 2000. This will be an telemetry, stream was used for diagnostics and statistics opportunity tbr anyone interested in space Interact data. These one-way data transmission modes must be concepts to discuss issues and propose solutions. For supported in order to deal with spacecraft contingencies current inlbrmation, see http: _iw,_fC.rlasa.gov,. when a full-duplex link is not available. This is just I0 An'icricaI1 Institute o1"eXcr,>nautics and eXstr,mautic-;