I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`STORE-AND-FORWARD MESSAGE RELAY USING
`MICROSATELLITES:
`THE UOSAT-3 PACSAT COMMUNICATIONS PAYLOAD
`
`Jeffrey W. Ward1
`
`One of the most promising applications for small satellites
`in the 10-50 kg class is store-and-forward message relay. A
`single store-and-forward message relay satellite in a polar
`orbit can provide a global communications network carrying
`electronic mail, digitised vOice, images or computer data.
`With appropriate choice of link characteristics, small, low(cid:173)
`cost ground terminals can be used. When designing an
`inexpensive microsatellite system to provide store-and(cid:173)
`forward communications to small ground terminals, the
`engineer must challenge the standard assumptions made
`concerning such things as link frequency, modulation
`techniques, error-control, and multiple-access arbitration.
`
`Beginning with experiments on its UoSAT-2 satellite, the
`Spacecraft Engineering Research Unit at the University of
`Surrey (UK) -
`in collaboration with AMSAT and VITA - has
`been investigating store-and-forward communications using
`microsatellites. The UoSAT-2 store-and-forward transponder
`used a relatively slow 8-bit CPU with only 96 kbytes of
`message store, but it has been used by stations world-wide,
`demonstrating system feasibility. The latest experiments
`undertaken by Surrey will qualify a commercial-capacity
`microsatellite store-and-forward system.
`The onboard
`transponder is based on a 8-MHz, 16-bit, 80C186 CPU, multi(cid:173)
`tasking operating software and 4 Mbytes of RAM message
`store. The UoSAT/SST modular microsatellite bus provides
`9600 baud FSK communications links and other support
`facilities for the store and forward mission. This payload
`was launched on the UoSAT-3 satellite in January 1990, and
`is now successfully operating in orbit.
`
`1. Research Fellow and PhD candidate, UoSAT Spacecraft
`Engineering Research Unit, University of Surrey, Guildford,
`United Kingdom, GU2 5XH.
`
`Canon Inc. et al., Petitioners' Reply Exhibit 1217
`
`

`

`IHTRODUCTIOR
`
`History of store-and-Forward satellites
`
`The desire for real-time telephony spanning the continents and the
`oceans drove the early satellite communications market. After initial
`experimentation, little thought was given to the use of low-Earth orbits
`for communications satellites. Before the exodus to the "Clark belt",
`however, engineers had demonstrated that store-and-forward message relay
`using non-geostationary satellites could be useful.
`In 1958, the first
`ever satellite communications was a store-and-forward relay using a tape
`recorder on the SCORE satellite.
`The second communications satellite,
`Courier, was also a store-and-forward system, with three on-board tape
`recorders which could be commanded to record and play back digital or
`analogue messages. The teletypes of the 1950s and 1960s were not
`matched to the high-bandwidth, limited-duration communications links
`provided by a
`'moving' satellite, and so the technique was abandoned in
`favour of real-time relay using GEO.
`
`The expanding use of computers in the 1970s led to renewed interest
`in store-and-forward message relay - initially through terrestrial
`networks (e.g. ARPANET).
`In 1973, MITRE Corporation published a paper
`proposing a "message courier" satellite which bears striking resrmblance
`to the systems which were eventually implemented a decade later.
`This
`was the only published reference to store-and-forward satellites until
`the 1980s, when microcomputers and solid-state memories became reliable
`and sophisticated enough to implement the ideas.
`
`The development of operational civilian store-and-forward
`communications satellites was pioneered by two groups: satellite
`builders in the Amateur Radio Satellite Service, and relief/development
`agencies working in developing countries. These groups have a common
`interest in spreading communications facilities beyond the limits of
`existing public telephone networks. Amateur Radio satellite builders
`were designing and operating increasingly sophisticated, inexpensive
`microsatellites. For example, the UoSAT-l satellite launched in 1981
`carried two microprocessors which could be re-programmed in orbit. At
`the same time, Y. Pal proposed using a store-and-forward satellite for
`United Nations communications in equatorial regions. 2 This concurrence
`of interests resulted in the construction of a Digital Communications
`Experiment (DCE) for launch on the UoSAT-2 satellite in 1984. The DCE
`was deSigned and built by AMSAT in North America, funded by the
`Volunteers In Technical Assistance (VITA - an international development
`organisation based in the U.S.A.),
`The host satellite was built by the
`Spacecraft Engineering Research Unit at the University of Surrey, which
`has long-standing ties with the Amateur Satellite Service.
`
`The UoSAT-2 Digital CoIIaunications Experiment
`
`The UoSAT-2 DCE was the first modern civilian store-and-forward
`satellite transponder. It used an NSC-800 CPU, 28 kbytes of program
`memory, and 96 kbytes of memory for message storage. Despite this
`Simplicity (relative to today's desktop microcomputers), the DCE
`conclusively demonstrated that a single, small (60 kg) low-cost
`(approximately f500k) satellite could be combined with inexpensive
`groundstation equipment to form an effective global communications
`network. Fixed stations in England, the U.S.A., Australia, New Zealand,
`
`2
`
`I
`I
`I
`I
`I
`I
`I
`I
`
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`Canon Inc. et al., Petitioners' Reply Exhibit 1217
`
`

`

`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`the U.S.S.R., West Germany, Italy, South Africa, and Nicaragua, as well
`as isolated stations in Pakistan and the Antarctic, regularly use the
`UoSAT-2 DCE. During the winter of 1988, the DCE was used for the first
`store-and-forward satellite communications from the Antarctic, and in
`1988 and 1989 the ad-hoc network of Amateur Radio stations using the DCE
`passed 4 Mbytes of traffic.
`
`TwO other store-and-forward microsatellites were launched in the
`1980s.
`In 1985, the Global Low Orbiting Message Relay satellite (GLOMR)
`was released from a Space Shuttle Getaway Special Canister. GLOMR was
`built by Defence Systems Inc. for DARPA, and little technical
`information about the mission has been made publicly available. The
`onboard computer was from the RCA 1802 family, and the communications
`links were 9.6 kbps phase-shift keying.
`The other store-and-forward
`mission was FUJI-OSCAR-12, an Amateur Radio communications satellite
`launched on a Japanese H-1
`launcher in 1986. The FO-12 transponder uses
`an NSC-800 CPU and 1 Mbyte of dynamic RAM. Between 1987 and 1989, FO-12
`was available for general access to all stations in the Amateur Radio
`service, and was used by more than 300 groundstations.
`
`AS a result of three successful store-and-forward microsatellite
`missions in the 1980s, several similar missions have already been
`launched in 1990, and more are planned. Using the experience gained
`from the UoSAT-2 DCE and the FO-12 store-and-forward mission, satellite
`engineers from AMSAT-NA and the University of Surrey independently
`developed two new store-and-forward transponder designs. Five of the 6
`microsatellites launched on Ariane V35 in January were equipped with
`these "second-generation" store-and-forward communications transponders,
`which involve new microprocessor and memory technologies. Four of these
`were the AMSAT-NA Microsats. The fifth was Surrey Satellite
`Technology's UoSAT-3, carrying the PACSAT Communications Experiment.
`
`'!'HE PACSAT COIDmNICATIONS EXPERIMENT HARDWARE
`
`The primary payload on the UoSAT-3 satellite is the PACSAT
`Communications Experiment (PCE). The University of Surrey's company
`Surrey Satellite Technology designed the payload, under a development
`contract with VITA, who propose to use similar transponders on a
`dedicated VITA store-and-forward satellite. Thus, the UoSAT-3 PCE is
`proving hardware and software for upcoming commercial store-and-forward
`missions. To provide a realistic traffic load for these tests, the PCE
`operates in both the Amateur Satellite Service (funded by AMSAT-UK) and
`on experimental non-amateur frequencies licensed by the FCC for VITA's
`pilot tests.
`
`The specific integrated circuit devices chosen for the PCE were
`selected to provide the desired level of communications service (with
`some margin for expansion), to be compatible with existing software and
`hardware development systems, and to support widely-used link-level
`communications protocols. Demonstrated reliability in space was not one
`of the selection criteria, since 8-bit microprocessors and asynchronous
`communications devices were not deemed capable of serving upcoming
`operational missions. A miniaturised design using surface-mounted
`components and multi-layer PC boards was also ruled out. These
`techniques would have significantly increased the cost and development
`time for the transponder. Since the UoSAT-3 modular bus provided 1600
`cm2 area for the transponder PCBs, we could afford the convenience of
`
`3
`
`Canon Inc. et al., Petitioners' Reply Exhibit 1217
`
`

`

`through-hole mounted devices on double-sided PCBs. A block-diagram of
`the final design is shown in Figure 1.
`
`PROCESS I~ UH IT
`
`"ESSAGE STORE
`
`S8C1SE>
`CPU
`
`25& kbyte
`EDAC
`SRM
`
`Cntrl
`
`Sector
`Addressing
`and
`Control
`Logic
`
`1 I'Ibyte SHAt!
`
`1 "byte SRAI'I
`
`Boot'
`Loader
`PRO"
`
`Data
`
`1 I'Ibyte SRAI'I
`
`1 I'Ibyte SRAI'I
`
`TELEMETRV
`
`SWITCHED 5-u LIHES FRO" BUS
`
`Fig. 1 - Block Diagra. of OOSAT-3 PCB
`
`Central Processing Unit
`
`We selected the Intel 80C186 CPU over two other contenders, the
`NEC-V40 and the Intel 80C188. All three of these processors are
`software compatible with the Intel 8088 - a great advantage when one
`considers the wealth of development tools resulting from the popularity
`of the IBM PC. The 80C186 and 80C188 CPUs provide on-chip
`counter/timers, memory select logic, clock oscillators and direct memory
`access (DMA) controllers. These built-in peripherals reduce the
`complexity of the hardware design, increasing the overall reliability of
`the payload. Since UoSAT-3 was being designed for an early 1989
`launch, device availability influenced the final selection. The V40 was
`available only in a standard temperature range component. Only samples
`of the 80C188 were available. The 80C186, though, was available in a
`commercial temprrature range device, with the prospect of a full MIL-883
`device to come.
`
`Prograa MaIory
`
`The 80C186 requires a full 16-bit wide memory data bus, rather than
`the 8-bit data path needed by the V40 and 80C188. This increases the
`number of components in the circuit, but provides a greater memory
`bandwidth.
`
`1. The M80C186, a MIL 883C compliant version of the 80C186 has since become
`available from Intel.
`
`4
`
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`Canon Inc. et al., Petitioners' Reply Exhibit 1217
`
`

`

`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`We needed enough program memory to run a multitasking operating
`system and several tasks, and estimated that 256 kbytes would serve.
`CMOS static RAMS were chosen over dynamics, due to their lower power
`consumption and lower single-event upset senSitivity. Error-detection
`and correcti~n (EDAC) circuits similar to those used on the UoSAT-2 DCE
`were chosen.
`These circuits use a 4-bit Hamming code to protect the 8
`data bits of each byte. Since a 16-bit data bus was to be protected, we
`investigated more efficient 16-bit EDAC systems, but all of those
`identified required significant additional hardware. 1 We chose 32k X 8-
`bit CMOS SRAMs to fit 256 kbytes of RAM with Hamming code EDAC into the
`available area.
`
`EDAC
`CODE
`STORAGE
`
`DATA
`BYTE
`STORAGE
`
`FROM . . . . . . .
`CPU
`00-7
`
`32k
`X
`8
`SRAM
`
`Fig. 2 - Block diagra.. showing half of the EDAC RAM.
`
`Theoretically we needed only 24 bits of memory (three 8-bit wide
`SRAMs) for a 16-bit data bus and two 4-bit Hamming code words.
`In
`practice, however, Intel processors do not always write 16-bit data
`words; they sometimes use only half of the bus. To accommodate this
`byte write cycle, each of the Hamming code words must be independently
`updatable, so they cannot both be stored in the same SRAM. Hence, the
`PCE program RAM is implemented as two independent 8-bit, EDAC-protected
`In each half of the memory, one 8-bit wide SRAM stores the
`memories.
`data bits, and another stores the 4 Hamming code bits. The 4 remaining
`bits of the code RAM are unused (Fig. 2).
`
`Where possible, the PCE design does not rely on a single type of
`component from a single manufacturer. The PCE program memory uses 32
`kbyte SRAMs from 3 different manufacturers (Hybrid/Hitachi, EDH, and
`NEC), to provide some protection against systematic failure.
`If one of
`
`1. CMOS versions of VLSI EDAC chips are now becoming available.
`For example, the 54PCT633 from Performance Semiconductor Company
`is being used in one of the onboard computers on the UoSAT-F
`microsatellite.
`
`5
`
`Canon Inc. et al., Petitioners' Reply Exhibit 1217
`
`

`

`the EDAC decoders or code word RAMs fails, the EDAC system can be
`bypassed. This would allow some operation of the payload, albeit
`without protection against SEUs.
`
`Serial Input/outPUt
`
`The serial I/O devices selected for the UoSAT-3 PCE had to support
`both asynchronous communications (used for the onboard data handling
`network), and synchronous communications (used for the packet radio user
`access protocols). The operating system chosen for the PCE already
`included software drivers for the Zilog 80C30 serial communications
`controller (SCC), and this chip would have been the natural choice.
`Unfortunately 80C30s were not available in time for the UoSAT-3 mission
`so the similar 85C30 was used. Neither of these chips is a perfect
`match for the 80C186, and an undesirable amount of 'glue logic' was used
`to interface the SCCs to the Intel bus. The two 85C30 SCCs provide 4
`bidirectional I/O channels, which can be operated at any standard speed
`from 1200 bits/sec. to 64 kbits/sec. Two channels are used for
`synchronous communications with groundstations, one of the remaining
`channels is used for the 9.6 kbits/sec. onboard data handling network,
`and the fourth is used as a dedicated link to the spacecraft's
`telecommand subsystem. The synchronous communications channels are
`connected to the 80C186 DMA controllers, providing simultaneous DMA
`transfers for uplink and downlink. Multiplexers in the PCE and in the
`UoSAT-3 bus allow re-assignment of serial input sources and output
`destinations under on-board or groundstation command.
`
`Parallel l!!m!t L output
`
`The PCE uses parallel I/O to receive data from the navigation
`magnetometer, to request and receive spacecraft telemetry measurements,
`to set the battery charge regulator, and to control the 4-mbyte message
`storage memory. Three Harris 82C55 parallel I/O devices provide 72
`programmable lines. The 82C55 was used on the UoSAT-2 DCE and continues
`to perform flawlessly afte~ five and a half years in orbit.
`
`Message Storage Subsystea
`
`We calculated that several megabytes (mbytes) of message storage
`would be required on an operational store-and-forward satellite. We
`considered only CMOS SRAM for this storage, although tape-recorders or
`bubble memory could have been used. Data from UoSAT-2 shows that SRAMs
`are reliable, and that the SEUs - even in large devices - can be
`corrected by software EDAC. Thus, SRAMs have no disadvantages. They
`have no moving parts, consume negligible power when idle, and require no
`special interface circuits. The PCE includes four mbytes of message
`storage SRAM, enough to store just over 2000 pages of compressed text.
`
`Although we did not want to manufacture our own PCBs with surface
`mount components, several mbytes of through-hole mounting SRAM simply
`would not fit in the available area. The solution was to use hybrids,
`consisting of four or eight surface mounted SRAMs on a PCB carrier_ The
`carrier then mounts to the host PCB with standard through-hole pins.
`Hybrid Memory Products manufactured the hybrids for the PCE. We used
`both 256 kbyte vertical-mounting single-inline packages and 128 kbyte
`dual-inline packages. The surface mounted monolithics used on the
`hybrid carriers are Hitachi and Toshib~ 32 kbyte SRAMs. Four mbytes of
`
`6
`
`I
`I
`I
`I
`I
`I
`I
`I
`
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`Canon Inc. et al., Petitioners' Reply Exhibit 1217
`
`

`

`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`hybrid SRAM, with associated buffering, fit easily on the 300 rom X 270
`rom PCB. 1
`
`The 80C186 CPU cannot directly address more than one mbyte of
`memory. Therefore, the message storage RAM must be paged into the main
`memory space or connected through some other interface. Paging into the
`main memory space has the advantage of fast access and operational
`flexibility. The disadvantages of paging are close electrical coupling
`of the message memory with the CPU main address and data bus (decreasing
`reliability of this critical bus), and increased physical complexity of
`the interface (16 data lines, 10 or more address lines and handshaking).
`As an alternative to paging, we used a bidirectional parallel I/O port
`between the PCE CPU and the message memory. Accessing the message
`memory is similar to accessing a disk-drive: the CPU writes a sector
`address to the interface port, and then reads or writes a block of data
`from the storage RAM. The interface uses eight data lines and five
`handshaking lines provided by one of the 82CSS parallel I/O chips.
`
`Within the message storage subsystem, the four mbytes are divided
`into four 1-mbyte banks. Each bank has its own switched power supply
`from the spacecraft bus, and the banks are isolated from one another by
`bidirectional buffers.
`Internal subdivision means that none of the
`memory chips is a single point failure node for the entire memory
`system.
`If destructive latchup occurs, perhaps shorting the ground and
`power rails, the offending bank can simply be turned off. This also
`allows banks to be turned off when not in use, either for power savings
`or as protection against radiation dose gate pollution.
`
`Figure 3 - OoSAT Module Box, approximately 300 X 300 mm.
`
`1. The advance from 32 kbyte to 128 kbyte CMOS SRAMs since the
`design of UoSAT-3 will allow us to quadruple storage capacity
`without changing volume. The UoSAT-F message storage subsystem
`will provide 16 mbytes of RAM.
`
`7
`
`Canon Inc. et al., Petitioners' Reply Exhibit 1217
`
`

`

`Mechanical Characteristics
`
`The PCE comprises two 290 X 320 mm PCBs, each of which fits into a
`standard UoSAT module box (Fig. 3). One PCB carries the CPU, program
`memory and I/O systems. The other carries the message storage memory.
`The main spacecraft wiring harness interconnects the PCE PCBs and
`connects them to the UoSAT-3 spacecraft bus.
`
`Electrical Characteristics
`
`It is difficult to reliably measure the current consumption of a
`device which has a high-frequency variable duty cycle - such as an a-MHz
`CPU and memory subsystem. Filtering characteristics and response time
`of the telemetry system make absolute measurements difficult to obtain.
`The table (Fig. 4) provides approximate indication of power consumption
`in the CPU module during different operating regimes. Running the
`bootloader, the CPU is executing from ROM and continuously polling the
`all four I/O channels. The kernel, on the other hand, halts the CPU
`when there are no tasks ready to run. Thus, the bootloader measurements
`show the highest power consumption for the payload, while the lightly(cid:173)
`loaded kernel shows the idle condition.
`
`Operating Mode
`
`PCB current
`(IIA at 5-v)
`
`PCB CPU Ta.p.
`(C)
`
`I Alabient I Temp.
`(C)
`
`Bootloader
`Kernel
`
`130
`60
`
`20
`17
`
`7
`7
`
`Figure " - PeE CPU CUrrent CoDSUIIPtion and Tearperature.
`
`Theraal Characteristics
`
`When we were preparing flight model PCE for thermal vacuum tests
`(conducted at the Royal Aerospace Establishment), we were made aware of
`a general concern about heat dissipation in onboard computers. Gough
`and Wolliscroft state that "heat dissipation can be a major problem on
`both rocket and satellite flights. Even CMOS microprocessors when
`running at high clock rates can dissipate a few hundred
`milliwatts ... this requires thermally conducting heat sinks to the main
`structure.,,4 The only heat conducting path from the PCE 80C186 to the
`spacecraft structure is through the 67 pins of the pin-grid array to the
`PCB. Although we had experienced no problems with the two NSC800s on
`UoSAT-2 or the COP 1802s on UoSAT-1 and -2, we wondered if the a MHz
`clock speed of the 80C186 might result in undesirable heat buildup. To
`answer. this question, a temperature sensor was added directly to the
`80C186 CPU. Temperature measurements made during thermal vacuum tests
`and also in orbit show that the CPU runs between 10 and 13 degrees C
`hotter than the surrounding stack; well within the CPU's +850 C maximum
`temperature limit.
`
`A store-and-forward 'transponder' is actually an appropriately
`equipped onboard computer programmed for message switching and packet
`communications.
`In this case the design, selection and implementation
`
`8
`
`I
`I
`I
`I
`I
`I
`I
`I
`
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`Canon Inc. et al., Petitioners' Reply Exhibit 1217
`
`

`

`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`of the system software are as important as the flight hardware. As with
`both previous UoSAT satellites, we load all operational software after
`launch. There is only a bootstrap loader in ROM, and no programs are
`kept loaded in RAM during the launch. This approach has several
`desirable consequences. Because the software can be uploaded after
`launch, it can be modified to take advantage unexpected experimental
`opportunities or to respond to changing mission characteristics.
`Especially when the time between mission commencement and launch is
`short, it is important to be able to continue software development after
`launch. Because we do not need to keep software loaded during launch,
`we can launch the satellite without any onboard computers running. The
`power to all onboard systems is routed through a switch which remains
`open until the satellite is safely separated from the launcher, at which
`time the satellite is under the control of hardware telemetry and
`te1ecommand systems. This is a simple and safe configuration to adopt,
`and has significantly eased the concerns of primary payload customers
`considering UoSATs as secondary payloads on their launches. For all of
`these reasons, the only software on the PCE at launch is a robust
`bootstrap loader in PROM. Both the multi-tasking operating system and
`the communications application software are loaded after the satellite
`is in orbit.
`
`The QuadrOll Multi-Tasling Operating Systell
`
`The UoSAT-2 DCE uses a single application program and no underlying
`"operating system", but the flexibility of multi-tasking systems was
`demonstrated on the AMSAT Phase-III satellites and on the UoSAT-2 aBC.
`We wanted a multi-tasking operating system for the new PCE onboard
`computer. H. Price - a principal in UoSAT's store-and-forward
`communications experiments since UoSAT-2 - made available an 80186
`operating system tailored to real-time communications applications. The
`operating s1stem was developed by Price and others at Quadron Service
`Corporation, to run on the IBM Real-time Interface Co-Processor (RIC),
`an 80186-based communications card for IBM PC family computers. Through
`a memorandum of understanding between Surrey Satellite Technology and
`Quadron, the operating system was tailored to the UoSAT-3 PCE (as well
`as to the AMSAT-NA V-40 onboard computer).
`
`The operating system - Quadron Communications Facility or qCF -
`provides a preemptive multi-tasking scheduler, inter-task communications
`using named pipes, and comprehensive drivers for character and frame(cid:173)
`based I/O. qCF provides a powerful development environment for
`applications programmers. Applications are written in the C language,
`compiled and linked by an unmodified Microsoft C compiler. For the
`first time, onboard computer programmers can write in a widely known,
`high-level programming language, calling operating system services
`through a rich applications programmer's interface. Tasks can be
`designed and debugged on a standard IBM-compatible PC, using source(cid:173)
`level symbolic debuggers. For more thorough ground testing, the multi(cid:173)
`tasking kernel and all tasks can be run on an ~BM RIC card and monitored
`in-situ by the developer's PC. Then, by linking the program with special
`libraries, a satellite-ready executable file can be created.
`
`1. Quadron Service Corporation, 133 E. De La Guerra, Suite #10,
`Santa Barbara, CA 93101.
`
`9
`
`Canon Inc. et al., Petitioners' Reply Exhibit 1217
`
`

`

`The effectiveness of this approach has already been proven. Since
`launch, a team of programmers in the U.K. and the U.S.A. (most working
`part time) has produced and debugged the following:
`
`AX.25 protocol driver which supplies level-2 communications link
`facilities to any other task;
`
`File system for the mass storage memory, accessed through C library
`functions (e.g. fopen), with software EDAC protection against SEUs;
`
`Housekeeping tasks customized for each of the five microsatellites
`running qCFi
`
`UoSAT-3 Cosmic Particle and Total Dose Experiment server which uses
`the onboard data handling networki
`
`Store-and-forward message switching system (alpha version).
`
`Figure 5 shows the tasks currently running on the PCE - comprising
`nearly 256 kbytes of executable code.
`
`Stor_and(cid:173)
`Foruard
`tie_age
`Switch
`
`Housekeeping
`Serl/ices
`Task
`
`COSNic Particle and
`Tota I Dose Exper iMent
`Data Gathering
`Task
`
`AX.25
`Protocol
`Server
`
`File
`Systetll
`Server
`
`Tel __ by
`Sa.,.pling
`Server
`
`FlIes in
`SRAI1
`
`Tel_etry
`Syst_
`I/O
`
`Onboard
`Data
`Handling
`Bus
`
`Figure 5 _ .. PCE Software Tasks and Inter-Task Links
`
`PRO'l"OCOL DEYELOPKEN'1'
`
`When developing a low-cost satellite communications system, it is
`important to take advantage of existing components and subsystems. This
`is especially important when offering a facility in the Amateur
`Satellite Service. Although in some areas we have been forced away from
`proven, available groundstation systems (e.g. in our choice of 9.6
`kbit/sec. FSK modulation), available items are suitable in other areas.
`The AX.25 communications link protocol is a good example of this. AX.25
`
`10
`
`I
`I
`I
`I
`I
`I
`I
`I
`
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`Canon Inc. et al., Petitioners' Reply Exhibit 1217
`
`

`

`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`is a: version of the CCITT X.2S Level 2 protocgl which has been modified
`to work in a multi-station radio environment. Many relatively low-cost
`AX.2S packet assembler/disassemblers are available, and the protocol has
`had wide acceptance outside of the amateur service.
`
`Using both the connected mode and datagram features ofAX.2S, we
`are implementing a suite of protocols tailored to satellite store-and(cid:173)
`forward message relay. The satellite's downlink is, naturally, a
`broadcast medium, and so a point-to-multipoint Broadcast Protocol has
`been developed to transmit messages of wide interest (e.g. satellite
`ephemeris). On the uplink, and for certain downlink transactions, a
`virtual circuit protocol is required. For this we are using a full(cid:173)
`duplex binary file transfer protocol on top of the AX.2S connected mode.
`In both instances the satellite acts as a message transfer agent in an
`electronic mail system, and standard message encapsulation headers have
`been defined. User agent software in the ground terminals can scan the
`message data-base on the satellite, to find messages of interest to
`specific users. A query and selection system has been defined for this
`purpose.
`
`These protocols have all been tailored for the specific environment
`in which they will be used. As a result, they are not intended for open
`interconnection with terrestrial networks, but they use uplink and
`downlink bandwidth, onboard storage, and onboard processing power
`efficiently. The author and H. Price designed and specified these
`protocols, and are currently implementing both spacecraft server and
`groundstation client software. 6
`
`IIul tiple-Access Protocols
`
`The uplinks of a store-and-forward communications satellite are
`multiple-acc;ss channels, with many stations wishing to share limited
`bandwidth. A multiple-access protocol must be selected to manage access
`to this uplink in an efficient and/or equitable manner. While multiple(cid:173)
`access protocols for GEO satellite networks, packet-radio networks, and
`hard-wired computer networks have been studied extensively over the
`years, the case of a lOW-Earth orbiting message store-and-forward
`satellite is sufficiently different to merit its own investigation, and
`this is the subject of the author's doctoral research.
`
`The simplest approach to channel sharing is for each station to
`ignore the others and transmit whenever it needs to. When two stations
`transmit simultaneously, both frames are destroyed. The destroyed
`frames are not acknowledged, and they are eventually re-transmitted.
`This is the pure ALOHA protocol, developed for a packet radio network at
`the University of Hawaii in the 1970s. 7 The classic throughput analysis
`of an ALOHA shows that the maximum throughput is just over 18% of the
`channel bandwidth. By synchronising packet transmissions, slotted ALOHA
`can achieve 36\ throughput. Neither of these figures is acceptable when
`one consid~rs a satellite with a 10-minute visibility window.
`
`One can increase the throughput efficiency of random access
`channels by avoiding collisions. Unfortunately, the simplest collision
`avoidance scheme - carrier sense multiple access - is not useful for a
`store-and-forward satellite system, since contending ground stations
`will not usually be able to hear one another's carriers (due to
`frequency separation or geographical distribution). Busy-tone multiple
`
`11
`
`Canon Inc. et al., Petitioners' Reply Exhibit 1217
`
`

`

`access (BTMA) could be used on a store-and-forward satellite; the
`satellite would transmit a busy tone on the downlink whenever the uplink
`was occupied, and stations wishing to transmit would only do so when the
`busy tone was not present. Unfortunately, the upper bound on throughput
`of a BTMA uplink for a satellite in an 850 km LEO is 49.8\. This does
`not seem high enough to justify inclusion of a busy tone generator on
`the satellite and detectors in the groundstations.
`
`To increase uplink throughput efficiency, collisions must be
`reduced or eliminated by assigning a specific fraction of the uplink
`resources to each groundstation. Time division multiple access (TDMA)
`assigns all of the uplink RF bandwidth to one groundstation for a
`limited time, whilst frequency division multiple access (FDMA) divides
`the RF bandwidth into several uplink channels and assigns each channel
`to one groundstation.
`TDMA and FDMA protocols can use either fixed(cid:173)
`assignments or demand-assignments. Fixed assignments, wherein each
`station is permanently assigned a specific time or frequency slot, are
`inappropriate for LEO store-and-forward message relay, because the
`number and identity of the groundstations in the satellite footprint
`changes continuously. Contention-free access for a LEO store-and(cid:173)
`forward satellite must use demand assignment, providing variable uplink
`allocations to groundstations as they enter and leave the satellite's
`footprint.
`
`A central station can control channel assignments, or all stations
`can implement a distributed control algorithm. Distributed control
`protocols are require broadcast channels (i.e. GEO satellite
`transponders), and are not suitable for LEO message store-and-forward
`satellites. LEO store-and-forward satellites are better equipped for
`centrally controlled demand assignment protocols, with the onboard
`computer assigning uplink capacity. The primary argument against
`central control in communications networks is that failure of the
`central node means failure of the network. This argument carries no
`weight in the present Situation, because the network already depends
`upon the satellite's onboard computer for message storage and retrieval.
`Using this computer to manage uplink assignments does not create a new
`single-