0018-9162/97/$10.00 © 1997 IEEE44 Computer

cations; a global standard based on these findingsis now under development.

FIRST-GENERATION GEOSEarly satellite systems, such as Intelsat and

Inmarsat, were designed primarily to support asmall number of users at a high data rate (in theneighborhood of megabits per second). Their con-stellations (groups of satellites) typically consistedof one or more large, heavy satellites deployed in ageostationary orbit. At an altitude of 35,785 km, ageostationary orbit corresponds to one sidereal dayat an inclination of zero degrees, placing it alwaysat the equator. Thus the satellite appears to be sta-tionary from the surface of the Earth, thereby pro-viding continuous communications services over agiven area. Assuming a minimum ground antennaelevation angle of 10 degrees, a single satellite ingeostationary orbit can cover about 34 percent ofthe Earth’s surface.

Basically, these first-generation satellites arerepeaters, which translate the uplink frequency ofa received waveform and reamplify it for downlinktransmission. They employ bent-pipe transpondersand basically handle only radio frequency wave-forms, which means that systems engineers havefocused only on layers 1 and 2 (the physical anddata-link layers) of the OSI reference model.

Unfortunately, the altitude of a geostationarysatellite results in a one-way, single-hop time delayof at least 0.25 seconds, caused by the speed-of-light transmission delay. Signal processing adds fur-ther delays, and the aggregate delay is called thecommunications propagation loss. Geostationarysatellites, therefore, are less attractive for voicecommunication. The higher the satellite altitude,

Demand for sophisticated personal communication services has changedcommunications satellite design. Satellites have moved closer to the Earthto improve communication speed and enable personal communication services. But in so doing, they require more computing resources and moresophisticated protocols to handle intersatellite communications.

Trends in MobileSatellite Technology

Satellites have been used for decades, forweather forecasting, navigation, reconnais-sance, and communications, among other

things. Until recently, however, constraints onpower, weight, and volume have made a space-craft’s computing resources so minimal that littleemphasis has been placed on satellite communica-tions and networking techniques. Now, however,this kind of support is in demand for use in today’ssophisticated personal communication services.

Increased demand for these services, coupled withadvances in technology, has changed approaches tosatellite design. The mindset of satellite systemsdesigners over the past 30 years has been to keepcomplexity on the ground. Among other reasons,this minimizes catastrophic system failures shouldsomething happen to the satellite. Today, however,economies of scale have made possible the deploy-ment of larger satellite constellations that can toler-ate the failure of one or more satellites. Satelliteorbits have also moved closer to the Earth, improv-ing communication speed and enabling PCS services.But in moving to lower orbits, these next-generationsystems have increased on-board complexity as satel-lites must now perform multiple satellite handoversto provide continuous coverage of the Earth. Thus,increased amounts of on-board computing resourcesand more sophisticated communication protocolsmust address the resulting increase in complexity.

This article examines the trends in communica-tions satellite deployment and the resulting require-ments for network protocols that are intended tosupport space communications. We report the find-ings of a joint DoD/NASA effort to identify whatparts of the seven-layer OSI protocol model can beadapted to support more sophisticated space appli-

GaryComparettoandRafolsRamirezThe MitreCorporation

Co

ver

Fe

atu

re

sist of 36 satellites, each one weighing 85 pounds anddesigned to last for four years. (The final constellationarchitecture is still under development and may includeonly 26 satellites.) Space-to-ground communication isvia VHF; 148-150.05 MHz for the uplink and 137-138 MHz for the downlink. OrbComm’s users willbuy a handheld unit for between $100 and $500. Theunit will be capable of transmitting at a burst rate of2,400 bps and receiving at a burst rate of 4,800 bps,with an effective throughput of about 300 bps.

the greater the delay, as Figure 1 shows. The plot inFigure 1a, derived from the equation shown, assumesan operating frequency of 2 GHz, the frequency rangeallocated to mobile satellite services. As the figureshows, the propagation loss is significantly higher forgeostationary satellites than for low Earth orbit (LEO)satellites, which have an altitude of about 1,850 kmor less.

Figure 1b shows the maximum achievable data rateas a function of satellite altitude, assuming the para-meters shown. The figure compares three types oftransmission antennas: 1- and 3-meter parabolicdishes and an omni, which is similar to a cellularantenna. As the figure shows, not only does the max-imum achievable data rate decrease with satellite alti-tude, it also increases proportionally to the size of thetransmit antenna.

Within five years, the minimum data rate requiredto support toll-quality voice communication is expectedto drop to about 2,400 bps. If this is true, and if theomni is the only available transmit antenna for hand-held, mobile communications, it becomes clear thatsatellites must move into the LEO range—geostation-ary satellites require prohibitively large antennas.

NEXT-GENERATION LEOSThe advent of personal communication services has

created a demand for low-delay voice and data trans-mission systems capable of supporting many users.Thus, the philosophy governing satellite deploymentis changing, and providers are moving away fromdeploying a few large geostationary satellites todeploying tens, even hundreds, of smaller lightweightsatellites. Furthermore, the altitudes are either low (upto about 1,850 km) or medium (up to about 18,500km).

These LEOs have satellite periods that range fromabout 1.5 to 10 hours. They also have high inclina-tion angles to the Earth and so typically appear over-head only twice a day; thus they require more satellitesper constellation to achieve continuous coverage.There are three basic types: nonvoice little LEOs, full-service big LEOs, and the newest, broadband LEOs.

Little LEOsRecent technological advancements in antenna

design, signal reception, and miniaturization havemade feasible mobile communications systems thatsupport 100- to 300-bps transmission. These littleLEOs, which can operate at a frequency below 1 GHz,are therefore appropriate only for nonvoice, store-and-forward mobile satellite services.

Orbital Sciences Corporation’s OrbComm is anexample. OrbComm is designed to provide full-time,global, two-way digital communications services: mes-saging, emergency alerts, position determination, andremote data collection. In space, OrbComm will con-

Figure 1. Factors forcing communication satellites into lower orbits. (a) Propagationloss, as computed by the formula provided, where Lfs is the free space propagationloss, z is the user-to-satellite distance, f is the operating frequency, and c is the speedof light. (b) Maximum achievable data rate, assuming the parameters provided. Noisetemperature reflects noise due to the thermal motion of electrons, galactic noise, inter-fering signals, and so on. Other link losses might be caused by multipath fading, rain,and atmospheric absorption.

February 1997 45

Lzf

cfs =

42π

Pro

pag

atio

n lo

ss (

dB

)

190

180

170

160

1500 7,400 14,800 22,200

Altitude (km)

29,600 37,000

Max

imu

m d

ata

rate

(Kb

ps)

100,000

10,000

1,000

100

1

0.01

10

0.1

0.0010 9,250 18,500 27,750

Altitude (km)

37,000

Frequency: 2 GHz

Transmit power:Antenna diameter:

Antenna noisetemperature:

1 W0.33 M

750 K

Other link losses:Required signal-

to-noise ratio:Link margin:

6 dB

10 dB3 dB

Operating frequency: 2 GHz

Assumed parameters

3 m

1 m

(a)

(b)

omni

Basically, OrbComm is a store-and-forward mail-box in the sky. Messages will be sent via OrbCommsatellites to gateway stations on the Earth, which willeither forward the message directly to the destinationvia leased lines or store it for access on demand. The

46 Computer

satellites are very simple, small, and easily deployed(current expectations are that eight satellites will bedeployed per launch, on Pegasus missiles). The effec-tive throughput is low, but the global servicesOrbComm can support are much in demand.

In October 1994, the US Federal CommunicationsCommission granted OrbComm a license to construct,launch, and operate a network of up to 36 LEO satel-lites—the first FCC license granted for a commercialLEO service. OCS launched the first two OrbCommsatellites in April 1995, and is now offering limitedservices.

Big LEOsThe big LEOs include Motorola’s Iridium, Loral

and Qualcomm’s Globalstar, and TRW’s Odyssey.1,2

(Constellation Communication’s Aries and Ellipsat’sEllipso are not described here because their level oftechnical and financial maturity is much lower thanthe three systems discussed below.) All these systemswill provide the full range of mobile satellite services—voice and data—and operate between 1 and 3 GHz.The FCC awarded operational licenses for Iridium,Globalstar, and Odyssey in January 1995.

The big LEOs deploy more satellites, as economiesof scale have reduced the impact of losing a singlesatellite. And in the case of Iridium, these are morecomplex satellites that perform more on-board pro-cessing: They not only translate a waveform’s fre-quency and reamplify it before retransmission; theyalso process waveforms down to the bit level (the base-band), performing decoding, deinterleaving, demod-ulation, and so forth. As a result, these satellites cansupport a variety of packet-oriented services, includ-ing routing, flow control, and error detection and cor-rection.

As Figure 2 illustrates, these networking servicesmove satellite communications systems into higherlayers of the OSI protocol model. Hence the effort todetermine if new protocols are necessary to supportthese OSI layer 3 through 7 services.

Iridium. On-board processing is a major design fea-ture of Iridium. Figure 3 shows the web of 66 LEOsatellites, which will orbit in six equally dividedplanes, or rings, at an altitude of 785 km.

Motorola is aiming to be the first vendor to use somenew techniques in a commercial satellite system: Iridiumis the only big LEO that will try to circumvent the needto downlink voice and data traffic to intervening hubstations. To do so, Iridium will use satellite-to-satellitecrosslinks. Each satellite will have four crosslinks: oneforward within a plane, one backward within a plane,and two across planes. The crosslinks will operate at25 Mbps at between 22.55 and 23.55 GHz.

Iridium’s on-board processing and satellite crosslinkcapability will allow it to be more flexible in how it

Figure 2. OSI seven-layer protocol model. Layer 7 - Application

User application process andmanagement functions

Layer 6 - PresentationData interpretation, format, and

code transformation

Layer 5 - SessionAdministration and control ofsessions between two entities

Layer 4 - TransportTransparent data transfer, end-to-end

control, multiplexing, mapping

Layer 3 - NetworkRouting, switching, segmenting,

blocking, error recovery, flow control

Layer 2 - LinkEstablish, maintain, and release data

links, error, and flow control

Layer 1 - PhysicalElectrical, mechanical, functional

control of data circuits

Net

wo

rkin

g p

ersp

ecti

veR

F p

ersp

ecti

ve

Figure 3. Iridiumsatelliteconstellation.

routes messages, at the expense of design complexity.For example, it may be a challenge to track Iridiumsatellites because the satellites in adjacent planes travelin opposite directions. These features also add weight:At 1,100 pounds, Iridium’s satellites are heavier thanGlobalstar’s, primarily because of the payload requiredfor on-board processing and satellite crosslinks.

Each Iridium satellite enjoys the largest throughputof the three, at 3,840 full-duplex circuits. Note thatper-satellite capacity is not cumulative, due to self-interference and beam overlap.

Iridium was scheduled to begin launching satellites,each of which has a mission life of five to 15 years, inNovember 1996. The launch was rescheduled forJanuary 1997.

Globalstar. Loral Aerospace Corporation andQualComm are developing Globalstar, which con-sists of 48 LEO satellites at an altitude of 1,401 kmand equally divided into eight orbital planes.

Like Odyssey, Globalstar will use traditional bent-pipe transponders instead of on-board processing. EachGlobalstar satellite weighs about 704 pounds and hasa capacity of 2,800 full-duplex circuits. The vendorsplan to begin launching satellites, each of which has amission life of between five and 15 years, in July 1997.

Odyssey.TRW’s Odyssey comprises 12 MEO satel-lites at an altitude of 10,354 km and equally dividedinto 3 orbital planes. Because its satellites’ altitudesare significantly higher, Odyssey requires fewer satel-lites to cover the globe. This was a major factor in

TRW’s decision to choose a MEO altitude, but thischoice came at the expense of size: Each Odysseysatellite weights 2,703 pounds. At higher altitudes,satellites need larger antennas as well as larger solararrays and additional shielding to protect againstincreased radiation levels, all of which add weight.

Odyssey satellites have a capacity of 2,300 full-duplex circuits and have a mission life of between fiveand 15 years. They are expected to launch in late 1997.

Multiple accessAs the sidebar “Battle for Access Standards” briefly

describes, there are three basic ways to let multipleusers share link capacity: frequency-division multipleaccess (FDMA), time-division multiple access(TDMA), and code-division multiple access (CDMA).The choice of one over another is not as important asthe compatibility issues that arise when differentschemes are used: TDMA and CDMA are more com-patible than FDMA with digital transmission schemes,but they can’t share the same frequency spectrum.

Globalstar and Odyssey will use CDMA, whileIridium will use TDMA. As a result, in 1993 the FCCencouraged the proposers to reach a consensus onhow to share the limited spectrum. Agreement waseventually reached on limiting interference amongspectrums, but not on intraband sharing. This is a crit-ical impediment—TDMA is inherently unable tocoexist with CDMA on a single frequency band. Inthe end, the FCC developed a “spectrum-sharing solu-

February 1997 47

Battle for Access StandardsThere are three basic techniques for shar-

ing link capacity: frequency-division mul-tiple access (FDMA), time-division multipleaccess (TDMA), and code-division multi-ple access (CDMA).

In FDMA systems, each user isassigned a unique center frequency withinthe operational bandwidth and multiplesignals can simultaneously access thesatellite amplifier. In a bent-pipe trans-ponder configuration, the satellite trans-lates the entire RF frequency spectrum toform a downlink. To receive the signal,the ground station tunes to the properband in the downlink spectrum. FDMArepresents the simplest way to achievemultiple access, and the required systemstechnology and hardware are readilyavailable. The key limitation of usingFDMA is the need to operate the satelliteamplifier at approximately half its max-imum output to avoid the generation of

unwanted interference.In TDMA systems, all users transmit on

the same frequency and each is assignedthe total available bandwidth for a limitedamount of time. Unused time regionsbetween slot assignment—guard times—allow for some time uncertainty and actas buffers to reduce interference. TDMAsystems segment time into frames, andeach frame is further partitioned intoassignable time slots. The frame structurerepeats so that a fixed TDMA assignmentconstitutes one or more slots that period-ically appear during each frame. Eachtransmitter sends its data in a burst, timedso as to arrive at the satellite transponderat the assigned time slot. This requiresaccurate timing and terminal-satellitedistance data for all TDMA users. Themajor advantage of TDMA over FDMAis efficiency, because the satellite ampli-fier can be operated at maximum outputpower since only one carrier arrives at

the satellite transponder at any giventime.

In CDMA systems, all users transmitsimultaneously and at the same frequency,with each being assigned a unique pseudo-random noise code. The data is first phase-modulated by a carrier and then the carrieris biphase-modulated with a pseudoran-dom noise code that is at a much higher ratethan the data traffic. This generates a widebandwidth, low-energy spread spectrumsignal. Each user, in effect, behaves as alow-level interferer to each other user. Thereceived signal is then “despread” by apply-ing the same code to the received datastream. The maximum number of CDMAusers is limited by their aggregate back-ground noise level. CDMA systems sufferfrom the complexity associated with syn-chronizing the transmit and receive codesand from a limitation in the maximumnumber of users a given bandwidth cansupport.

munications CEO Craig McCaw and MicrosoftChairman and CEO Bill Gates. Teledesic plans to offerglobal fixed satellite service, meaning that the user isstationary, enabling the use of parabolic directionalantennas for higher data rates.

The most interesting feature of Teledesic is that it doesnot plan to cater to the mobile communications market.Instead, it is positioning itself as AT&T did before thebreakup—a wholesaler of communications capacity andbulk network capability, selling to retail telecommuni-cations providers such as US West and Nynex. Teledesichas been called “real-time wireless bandwidth ondemand,” the “global Internet,” and “AT&T in the sky.”

Figure 4 shows the space component of Teledesic,840 satellites in a sun-synchronous altitude at 700 km.Its satellites will employ on-board processing tech-niques and support packet-switched asynchronoustransfer mode (ATM) communications. Figure 5shows the current architecture: Each satellite will haveeight crosslinks supporting a nominal data rate of155.2 Mbps with a maximum supportable data rateof 1.244 Gbps. The crosslink frequency band is 59-64 GHz. Connectivity with the ground is in the Kafrequency band, with 30 GHz (nominal) for the uplinkand 20 GHz (nominal) for the downlink.

Teledesic’s maximum achievable data rate to theground is 1.244 Gbps, to both user terminals and gate-ways (“GigaLink” terminals). There is not much infor-mation available about Teledesic’s ground components.We do know that it will be compatible withATM/Sonet technology and protocols under develop-ment and will interface with existing public and pri-vate networks.

tion,” which assigns the lower 5.15 MHz of theuplink frequency band to TDMA and the upper 11.35MHz to CDMA. The full 16 MHz of the downlinkwill be shared among CDMA systems.

Broadband LEOsThe newest contender for a piece of tomorrow’s

satellite communications pie is Teledesic,3 whose prin-cipal shareholders include McCaw Cellular Com-

48 Computer

Figure 4. Teledesicsatelliteconstellation.

Space

• 840 satellites• On-board processing• Packet-switched ATM• About 700-km altitude• Sun-synchronous

• 8 crosslinks/satellites• 155.2 Mbps (up to 1.24416 Gbps)• 59-64 GHz

Ka-band30/20 GHz (nominal)

16 Kbps to 2.048 Mbps(Special: up to 1.24416 Gbps)

Ka-band30/20 GHz (nominal)Up to 1.24416 Gbps

User

Land-basedcommunication systems

Ground

"GigaLink" terminals

Gateway to satellitesand public networks

NOCCs and COCCS(very limited detail available)

Figure 5. ProposedTeledesicarchitecture.

Within the context of this article, Teledesic is thebest example of where satellite communicationappears to be going. Specifically, it exploits servicesaddressed by OSI layers 3 through 7. Other thanIridium, all the other systems are applying proventechnology to new applications, with only limited useof services addressed by the higher OSI layers.

SATELLITE NETWORKINGThere is little public information about the net-

work protocols being developed for commercial sys-tems. However, we can begin to appreciate thechallenges they face by examining the work beingdone by the military and by civil organizations suchas NASA and the Consultative Committee for SpaceData Systems. CCSDS is the recognized internationalstandards organization for space communications.It issues recommendations that can be subsequentlyapproved by ISO as standards. CCSDS recommen-dation 701.0-B-2 allows both an optional layer 3Internet service using the ISO 8473 connectionlessnetwork protocol and a special-purpose path service.Each of these two services allows the applicationlayer to access the data-link layer without addingintervening functionality.

However, neither of these services can meet futuremission requirements: They can’t efficiently supportend-to-end networking, data protection, reliable deliv-ery, and file handling. As a result, the US Departmentof Defense and NASA are undertaking the SpaceCommunications Protocol Standards (SCPS) project,to develop more flexible higher layer protocol optionsfor space communications.

SCPS, which is designed to extend existing capa-bilities,4 focuses on the end-to-end aspects of applica-tions that (1) monitor and command space vehiclesand their payloads and (2) return data to the Earth.However, it is expected that SCPS will also apply tosatellite communications, where a space vehicle isused as a repeater with communication end points onthe ground or in space.

SCPS will focus on online data communications func-tions at OSI layers 3 through 7. It is assumed that theprotocols will operate over layer 2, the data-link layer,which provides services equivalent to those offered byexisting CCSDS recommendations and military proto-cols (coding, framing, multiplexing packets, and so on).

Essentially, there are four types of space applications:telemetry (reporting status of equipment within thespace vehicle); command (controlling the space vehicleor its payload); mission data (sending payload data tothe ground); and the upload or dumping of programsand data tables to and from space vehicles.

Space vehicle environmentA space vehicle’s characteristics affect the commu-

nications protocols that can be used.

Computing resources. Space vehicles have only somuch power, volume, and weight, so their process-ing capacity and online memory are limited. In gen-eral, only 0.15 to 4 MIPS and 0.15 to 4 Mbytes areavailable for layer 3 through 7 protocols. Futurerestrictions on power, volume, and weight will be lesssevere, but processing capacity and online memorywill continue to be more limited on a space vehiclethan in ground systems. The available processingcapacity available for layers 3 through 7 protocols isexpected to be no more than 8 MIPS and online mem-ory is expected to be no more than 8 Mbytes.

Communications architecture. Most space vehiclesnow have a communications front end that interfaceswith the data links and distributes data to other mod-ules. In the future, we can expect a distributed com-munications architecture in which communicationelements are connected via regular local area networks.

Transmit power. Currently, transmit power is rela-tively low, resulting in low-to-moderate data trans-mission rates. Advances in technology are expectedthat will allow the transmit power to increase, result-ing in moderate-to-high data transmission rates.

Network environmentThe characteristics of the space network environ-

ment have an impact on the communications proto-cols that would support space applications. Thissection addresses only the characteristics that affectlayer 3 through 7 protocols.

Connectivity.Whereas geostationary space vehiclescan be accessed continuously from the same point onEarth, LEOs are typically accessible on a periodicbasis for only a few minutes at a time from the samepoint on Earth. Thus, systems consisting solely ofLEO vehicles have a time-variant connectivity withthe ground (each connectivity pattern lasts only a fewminutes) where specific connectivity patterns arerepeated periodically. With very few exceptions, thereare no crosslinks in current space systems.

Delays. One-way delays between end points, due topropagation, are typically less than or equal to 0.125second per space-ground link. Interleaving-deinter-leaving of a space-ground link can significantly increasethe one-way delay by an additional 0.25 to 0.50 sec-ond. One-way delays for crosslinks, due to propaga-tion and interleaving-deinterleaving respectively, areexpected to be less than for space-ground links.

Errors. Transmission errors are due to congestion,corruption, and link outages. Error rates due to cor-ruption can be random or bursty. Currently, the ran-dom error rates visible by the network layer canfluctuate between 10-9 and 10-5. The burst error ratescan be between 10-5 and 10-4. In the future, these ratesare expected to improve by an order of magnitude.

Link occupancy. Currently, link occupancy is typi-cally low-to-moderate in telemetry and control links

There is littlepublicinformationabout the network protocolsbeing developed for commercialsystems.However, wecan begin toappreciatethechallengesthey face byexamining thework beingdone bymilitary and civil organizations.

February 1997 49

50 Computer

and moderate-to-high in both mission data links andlinks carrying communications traffic between pointson the ground. In the future, link occupancy isexpected to stay the same because the increase in datatraffic is expected to be proportionate to the increasein data transmission rate.

SPACE PROTOCOLSSpace protocols must meet four key requirements due

to constraints within the space vehicle environment:

• They must support small programs. Imple-mentations must use as little code as possible anduse memory buffers efficiently to reduce onlinememory needs.

• They must allow uncomplicated programs.Simple finite state machines will reduce process-ing complexity.

• They should impose a low overhead. Their head-ers and trailers must be kept to a minimum size.

• They must support end-to-end communications.Individual addressing of each end system withineach space vehicle will truly implement end-to-end communications.

In addition, to work in a network environment, theprotocols must support

• routing algorithms that both efficiently handledynamically changing connectivity and maxi-mize the probability of reaching the intended des-tinations within the required time;

• mechanisms to efficiently handle the combina-tion of high delays and high error rates; and

• the suspension, resumption, and completion oflarge transactions in the presence of periodicshort contact times separated by fairly long non-contact times.

The preferred solution to meeting the above require-ments is to adopt existing terrestrial commercial stan-dards without modifying them. If that is not feasible,then existing standards would be modified. If an exist-ing standard would have to be changed extensively,then, and only then, a custom protocol would have tobe developed.

Existing standardsThere are two predominant protocol reference mod-

els for data communications: the OSI (Open SystemsInterconnection) and Internet (which used to be calledthe DoD Reference Model). And there are two corre-sponding protocol suites: the OSI and Internet proto-col suites. The standards in both of these suites arebased on a set of assumptions about availableresources and environment conditions that do notapply to space communications:

• Resources. Typical commercial communicationsare not highly constrained; nor are their end sys-tems unequal in terms of processing power. Incontrast, space-based resources are highly con-strained. In addition, they are much more expen-sive, so typically the ground and space ends ofthe system are very unequal in terms of comput-ing (processing and memory) resources.

• Environment. Commercial communications envi-ronments enjoy fairly stable connectivity and expe-rience few errors, caused mostly by congestion.They also have a high bandwidth in local net-works, and moderate bandwidth and delay inwide-area networks. In contrast, space communi-cations have dynamic, intermittent connectivity;high and variable delays; restricted bandwidth;and high error rates due to congestion, corruption,and link outage.

Table 1 shows the existing standards that mostclosely match the protocol requirements. The SCPSproject evaluated the functionality in each existingstandard against the requirements to determine

• if the functionality was required or could be eas-ily omitted,

• if it would work in space or could be easily mod-ified to work, and

• if it had been—or could be—efficiently imple-mented.

The SCPS project also identified missing functions.On the basis of this evaluation, they determined if a

Table 1. Communications protocols evaluated by SCPS.

Functional category OSI IPS Other

File handling FTAM FTP SSFTTransport TP4, CLTP TCP, UDP XTP, NetBLTData protection NLSP, TLSP I-NLSP, IPv6 SP3, SP3’Network CLNP IP, IPv6 BE, Path

Definitions:BE = Brilliant Eyes custom network protocol

CCSDS = Consultative Committee Space Data Systems

CLNP = Connectionless Network ProtocolCLTP = Connectionless Transport ProtocolFTAM = File Transfer, Access, and Management

FTP = File Transfer ProtocolI-NLSP = Internet Network Layer Security Protocol

IP = Internet Protocol version 4IPS = Internet Protocol Suite

IPv6 = Internet Protocol version 6NetBLT = Network Block Transfer ProtocolNLSP = Network Layer Security ProtocolOSI = Open Systems InterconnectionPath = CCSDS network protocolSP3 = Security Protocol at Layer 3SP3’ = Low-overhead SP3SSFT = Space Station File Transfer Protocol

TCP = Transmission Control ProtocolTLSP = Transport Layer Security ProtocolTP4 = Transport Protocol Class 4UDP = User Datagram ProtocolXTP = Express Transfer Protocol

• full delivery reliability,• best-effort delivery reliability,• minimal delivery reliability,• multicasting,• precedence handling,• segmentation,• operation over a wide range of network envi-

ronment conditions,• graceful closing of connections, and• a different response to congestion and to cor-

ruption.

Data protection. SCPS-SP is a reduced-overhead ver-sion of SP3 and NLSP. It will offer

• access control,• source authentication,• command authentication,• integrity, and• confidentiality.

February 1997 51

standard could be adopted “as is” or could beadapted, or if a new standard had to be developed.

For example, SCPS considered four standards as thestrongest transport candidates: Transport ProtocolClass 4 (TP4) and Transmission Control Protocol(TCP) for connection-oriented operation, andConnectionless Transport Protocol (CLTP) and UserDatagram Protocol (UDP) for connectionless opera-tion. TP4 and CLTP are OSI standards; TCP and UDPare Internet standards and were selected as the base-line. The space characteristics inherent in satellite com-munications necessitated the following modifications toTCP/UDP:

• enhanced functions (a response to congestionshould be different than a response to corruption),

• additional functions (including selective negativeacknowledgment),

• mechanisms for the efficient use of bandwidth(header compression),

• memory conservation (support for minimalimplementation size and efficient memory bufferhandling), and

• mechanisms for the efficient handling of highdelay and high error conditions (such as handlinglarger amounts of outstanding data).

Critical to the performance of TCP in the space envi-ronment is the use of a selective negative acknowl-edgment, which allows packets received out ofsequence to be acknowledged individually. This func-tion would increase throughput in environments thatexperience long delays.

Proposed protocols On the basis of an assessment of existing standards,

SCPS proposed protocols for space communications,as shown in Figure 6.

File handling. SCPS-FP will be interoperable withthe existing FTP when the space enhancements (initalics below) are not invoked. It will offer

• operations on entire files,• two-party file transfer,• proxy file transfer,• file-handling security, • user-initiated interrupt and abort,• operations on file records,• recognition of system-detected interrupt notifi-

cation,• manual and automatic resumption after interrupt,• integrity over operations on entire files, and• integrity over operations on file records.

Transport. SCPS-TP will be interoperable with theexisting TCP and UDP when the space enhancements(in italics) are not invoked. It will offer

OSI

Application

Presentation

Session

Transport

Network

Data link

Physical

7

6

5

4

"3.5"

3

2

1

Internet SCPS protocols

Application SCPS-FP

End-to-end SCPS-TP

SCPS-SP

Internetwork SCPS-NP

Networkaccess

Existing military/civil protocols

Status of SCPS ProgramInitial versions of the SCPS protocol suite have been

tested extensively in a laboratory environment, as wellas in operational satellite environments. Additionaltesting is scheduled later in 1997. The SCPS develop-ment effort is nearing completion with a scheduledrelease of the initial Reference Implementation (thatis, C-code representing the integrated SCPS protocolsuites) in February 1997 and the final ReferenceImplementation in September 1997. Additionally, theSCPS protocols are being documented as MIL STDsand CCSDS (Consultative Committee on Space DataSystems) Blue books that will be submitted as ISOstandards. Interested readers can contact the authorsfor information on how to obtain a copy of the SCPSReference Implementation.

Figure 6. Proposedspace protocols.

Network. SCPS-NP, a custom protocol, can eitherbe encapsulated by or translated into a commercialnetwork protocol for ground distribution. It willoffer

• support for multicasting, • support for multiple routing options, • packet lifetime support via time stamps with

automatic discard, • separate reporting of congestion and corruption, • support for precedence handling, and • differentiation between real and test data.

The proposed protocols are undergoing specifica-tion generation, laboratory implementation andsimulation, formal validation, and testing to ensure

that they meet the requirements of civil and militaryspace systems. They have been submitted to both theUS government and CCSDS for approval as recognizedstandards. If successful, the result will be open globalstandards that stimulate vendors to produce commer-cial products.

The commercial space, military tactical, and wire-less personal communications markets may also ben-efit from the technology of these space protocols

because they have system and environment constraintsin some cases similar to space communications. ❖

AcknowledgmentWe thank Lloyd Wood of the Centre for Satellite

Engineering Research at the University of Surrey, UK,for permission to reproduce the satellite constellationimages rendered using SaVi, the satellite visualizationtool authored by Robert Thurman and PatrickWorfolk at the Geometry Center, University ofMinnesota. (More on constellations at http://www.sat-net.com/L.Wood/constellations.)

References1. G. Comparetto and N. Hulkower, “Global Mobile Satel-

lite Communications: A Review of Three Contenders,”Proc. 15th Int’l Comm. Satellite Systems Conf., Am.Inst. of Aeronautics and Astronautics, Virginia, 1994.

2. G. Comparetto, “A Technical Description of SeveralGlobal Mobile Satellite Communications Systems,” J.Space Comm., Oct. 1993, pp. 97-104.

3. “Application of Teledesic Corporation for a Low EarthOrbit Satellite System in the Domestic and InternationalFixed Satellite Services,” filed by Teledesic Corporationwith the Federal Communications Commission on Mar.21, 1994.

4. R. Durst, G. Miller, and E. Travis, “TCP Extensions forSpace Communications,” Proc. Mobicom, ACM Press,New York, 1996.

Gary Comparetto is a senior principal engineer andassociate department head with the Mitre Corpora-tion, performing satellite communications analysis forthe United States Space Command. He also teachescommunications courses in the graduate program atthe University of Colorado, Colorado Springs, andthe University of Denver. Comparetto received a BSin electrical engineering from Bucknell University, anMS in nuclear engineering from Pennsylvania StateUniversity, and an MS in electrical engineering fromthe Georgia Institute of Technology with a specialemphasis in digital communications and optics.

Rafols Ramirez is a lead engineer at the Mitre Cor-poration, where he has been involved in the genera-tion of standardized protocol profiles forground-based data communications systems and thedevelopment of national/international protocol stan-dards for space data communications. Prior to join-ing Mitre, he worked for Bell Laboratories and ITTTelecommunications. Ramirez received a BSEE fromthe University of Puerto Rico and an MSEE fromOhio State University. He is a member of the IEEEand the IEEE Communications Society.

Contact the authors at the Mitre Corporation, 1150Academy Park Loop, Ste. 212, Colorado Springs, CO80910; {compare, rram}@mitre. org.

Order from the our secure web site at http://computer.org/cspress

Call +1-800-CS-BOOKS

Industrial StrengthSoftwareEffective ManagementUsing Measurementby Lawrence H. Putnam and Ware Myers

Presents the valuable informationyou need for ensuring theeffective management of projects,the attainment of reliable

products, and the continuing improvement of the soft-ware process. With this book, you will be able to over-come the chaos normally associated with developingsoftware by using a well-managed, defined, planned,and disciplined process. The book provides you withthe metrics and measures to more effectively deal withthe progress of individual projects, reliability of theprocess, and long-run improvement of thedevelopment process itself. 328 pages. Softcover. February 1997. ISBN 0-8186-7532-2.Catalog # BP07532 — $35.00 Members / $42.00 List

.