


                                          
            PACSAT Protocol Suite - An overview
                                             
                                             
                      Harold E. Price, NK6K
                       Jeff Ward, G0/K8KA
          


                            ABSTRACT

          

     A Low Earth Orbiting ``Pacsat'' has been described in the past  as 
     an   orbiting   bulletin   board  system.   This   is   an   over-
     simplification.  A PACSAT is a multi-channel, full duplex  device, 
     with  short, periodic access times dictated by orbital  mechanics.  
     These  attributes mandate a different approach than  the  standard 
     command-line  interpreter style of BBS if the full potential of  a 
     PACSAT is to be realized.

     The  authors  propose  a new methodology for a  PACSAT,  and  have 
     developed  several new protocols to implement more  efficient  ac-
     cess.  These protocols all use AX.25, either in connected mode  or 
     with  UI frames.  This paper provides a description of the  access 
     model, and an overview of the new protocols.


Background

The authors have been struggling with the question ``How can we make the best 
use of a bandwidth-limited low earth orbiting digital store-and-forward system 
with a worldwide, unstructured, heterogeneous user base'' since an amateur 
Packet Radio satellite was first discussed in 1982.  We began on air experi-
mentation with the UoSAT-2 (UO-11) Digital Communications Experiment in Decem-
ber, 1984.  In the following five and one half years, we've looked at where a 
resource like a PACSAT best fits in to the network as a whole.  As a result of 
our study, we are proposing the use of a broadcast protocol as the basic 
downlink method, and a ``file server'' rather than a BBS application as the 
basic service offered.  This document provides a brief overview of these 
conclusions, the companion specification documents provide the implementation 
details.

This paper and the companion protocol specification papers assume that the 
reader has a basic understanding of the current packet radio satellites, for 
additional background, see references [1] through [6].

PACSAT

PACSAT is generic term in the amateur radio service for a low earth orbiting 
spacecraft which carries a large on-board memory for the purpose of data 
storage and retrieval by groundstations.  A PACSAT can be the entire mission 
of a spacecraft, such as AMSAT-NA's AO-16, or a minor adjunct, such as the DCE 
on UO-11.   The paper refers to the current ``PACSAT'' spacecraft - the Uni-
versity of Surrey's UoSAT-3 (UO-14) and the AMSAT Microsats AO-16 and LO-19.  
These spacecraft will be the hosts of software developed by the authors which 
implements the protocols described herein.  

Each of these spacecraft are different.  AO-16 and LO-19 are the most closely 
related, based on AMSAT's Microsat design.  From the user's point of view, 
they have four 1200 bps uplinks and one 1200 bps downlink.  These are switcha-
ble to 4800 bps, but no ground modems exist at this time.  UO-14 has a single 
uplink and downlink, at 9600 bps.  Although the onboard computers are differ-
ent, they are compatible at the application software level, permitting the 
same software to be used on all three.  

In spite of these differences, all of these spacecraft share the following 
attribute: each is a bandwidth limited device.  The number of uplinks and 
downlinks is much less than the number of users, and the capacity of the link 
is much less than the offered load.  Each is only visible to a particular user 
for about 14 minutes, four or five times a day at middle latitudes.  We feel 
that this is the critical design driver, and the access methods must be opti-
mized with this in view.

Keep in mind, however, that even while subject to access time limitations, the 
satellites can still move a prodigious amount of data, especially when com-
pared to the current amateur radio long haul network standards.  A typical 
gateway station, moving traffic from the US to the UK on 20MHz at 300 baud, 
assuming the band is open for 16 hours, could move 1.7 million bytes of data 
per day, if the link was 100% efficient.  The average HF link is not 100% 
efficient, at best it is perhaps 30% efficient.  The link is only half duplex, 
so this data transfer is only way only.

UO-14, even with only 56 minutes of access time per day at 9600 baud, can move 
3.2 million bytes of data in one direction.  The excellent link quality of the 
current PACSATs, combined with their full duplex nature and the protocols we 
are proposing, can approach 90% efficiency.  Full duplex means transfers can 
occur in both directions simultaneously, so that UO-14 could move nearly 5.7 
million bytes of data between the US and the UK in a 24 hour period, vs. .5 
million bytes over an HF circuit.

The desire to realize this potential is the reason we choose some non-
traditional (for the amateur radio service) access methods for PACSAT.  These 
methods, broadcasting and file server, are discussed below.

Broadcasting

A spacecraft is inherently a broadcast device.  It transmits from on high, and 
many users can hear it at the same time.

To optimize the available downlink time, we are recommending the use of a 
broadcast protocol.  This protocol adds information to the basic AX.25 data 
frame to permit many stations to make simultaneous use of a single file down-
load session.  When one station in Maryland requests the current orbital 
element sets, there is no need for stations in Toronto and Miami to do the 
same, they should be able to make use of the information as it is downlinked 
to Maryland if they are all in view of the satellite at the same time.  To 
make use of a broadcasted frame of data, each frame must be tagged with the 
file it belongs to and the position within that file that the data belongs in.

There should also be enough information for a station to determine if it has 
all of the data belonging to a file, and if not, to request that just the 
missing parts of the file be retransmitted. The specification titled ``PACSAT 
Broadcast Protocol'' describes a method of providing this additional informa-
tion.

With a broadcast protocol, a groundstation can simply monitor the downlink and 
accumulate files of data.  Since files gathered in this way will have been 
unsolicited, the format of the contents may not be known to the user.  For 
example, if one asked for a file of NASA format orbital elements, one can make 
a good guess that the resulting file contains NASA format orbital elements. 
However, if a ``random'' file is captured, its contents may not be understand-
able simply from inspection.  Some addition information, such as a file name, 
data type, description, creation date, etc., may be required.  Each broadcast-
ed file, therefore, needs a header in a standard format with this information.  
The specification titled ``PACSAT File Header Definition'' describes a method 
of providing this information.

We hope that the broadcast protocol promote efficient use of the downlink.  It 
should reduce the number of requests for files of general interest.  It should 
also reduce the uplink loading, since a broadcasted file does not receive an 
ack for each frame or group of frames.  In the best case, only one ``ack'' is 
sent for an entire file, and that would be the request to stop broadcasting 
it.

Even though the sky-to-ground link is broadcast in nature, the ground-to-sky 
link is not.  PACSAT ``sees'' many ground stations at one time.  For this 
reason, a connected-mode, non broadcast file transfer method is also defined, 
and is described in the paper on ``PACSAT File Transfer Level 0''.

File Server

As a data transfer and storage device, a PACSAT can serve a multitude of 
purposes.  It can store telemetry, digitized voice and video images, personal 
mail, forwarded mail, or anything else the can be stored in a computer file.  
Mail forwarding is a good example of an excellent use of a PACSAT.  AO-16's 
1200 baud link could easily be used to transfer 240k bytes of uncompressed 
forwarded mail in each direction between California and England in 24 hours, 
with just one morning and evening pass over each location. UO-14's 9600 baud 
link could move 1.6 Mb of data in the same time.  A PACSAT can store up to 8Mb 
of data.  This would make a powerful addition to the current HF relay network.

The problem, however, is that the current amateur network is in a state of 
flux.  New addressing schemes are proposed every few weeks, new routes and new 
ways of routing are proposed, tried, discarded or modified.  This is good.  
Implementing the software on a spacecraft to follow these shifting designs is 
difficult, however.  The testing required for the spacecraft is more rigorous, 
especially on the Microsats, where the same computer is used for the BBS and 
to keep the batteries charged.  Faulty forwarding code could crash the comput-
er, which could cause damage to the batteries or reduce their life expectancy.

The amount of program memory is limited on the spacecraft as well.  To counter 
the effects of high energy particles above the earth's atmosphere which cause 
memory bits to be changed, the PACSATs use 12 bits to store 8 bits of program 
data.  The extra bits are used to correct for single bit errors.  To keep the 
cost down, and to reduce the power used (AO-16's CPU uses about 500 milli-
watts, on average), only 256k bytes of program space is available.  (This 
should not be confused with the message storage space, which is much larger 
than the program memory, and is protected with a software algorithm using 
three 3 bytes to protect 253 bytes of data.  Because this memory is protected 
with software, it is not suitable for storing a running program, since a 
program can not protect its executing instruction.)

We have a desire, then, to keep the spacecraft code simple and stable, while 
still allowing it to be a useful part of the changing amateur network.

We propose that the spacecraft be primarily used as a file server, moving data 
files from one point to another.  The PACSAT would have no knowledge of the 
contents of the files, nor would it take an active role in the forwarding of 
mail messages. Groundbased software could, however, make the PACSAT system 
look like a familiar BBS to the user, and it could intelligently forward mail.

A PACSAT will know how to receive and transmit a standard file format.  All 
files will have a standard header, the same one that is used by the broadcast 
protocol.  It will also know how to select files for transmission based on the 
contents of the header.  This feature can then be used by groundstation soft-
ware to emulate any desired user interface.

For example, assume that a user wanted to send a personal mail message to a 
friend.  In the current terrestrial environment, he would connect to a BBS, 
which would lead him in a question and answer session something like this:


            Remote Computer User



            What do you want?   Send message

            To whom?       Fred

            Title?         Club meeting

            Message?       Meeting at 8 p.m.

            What do you want?   Read new mail.

            Message #200

            . . . . .




Using the PACSAT system, exactly the same exchange would take place, except 
that the conversation is between the user and his local computer.  The message 
is stored for later transmission to a PACSAT.  The read new mail request is 
also stored.  The next time the PACSAT comes overhead, the computer does the 
following:

1) builds a file with a standard PACSAT header.  The header says that the file 
contains a mail message, from you, to Fred.  

2)  The file is compressed, and sent to PACSAT.  

3)  The local computer then sends a message to PACSAT that says ``send the 
next file who's header meets the following criteria:  it's a mail message 
type, the destination is me, and the file number is bigger than x''.

``x'' is the number of the last file received on the ground, and is kept by 
the local computer.  After the pass, the local computer can now print any new 
mail received.  To the user, it looked pretty much the same.

What about file forwarding?  A gateway would need to know what type of mail it 
could forward.  Let's assume that the routing scheme of the week is based on a 
hierarchical string containing states, like nk6k.ca.usa, and this gateway han-
dles mail to CA, NV, and OR.  The gateway would send a message to PACSAT 
containing the following request:

``Send the next file who's header meets the following criteria:  it's a for-
warded message, and the destination string contains '?.ca.?' or '?.nv.?' or 
'?.or.?', and the download count is 0.''

The file would be received, decompressed, and imported into the standard BBS 
program after the pass.

In this way, the ground program can be as simple or as complex as required, 
the PACSAT only needs to know how to select a file for transmission based on 
the contents of fields in the standard file header.

Summary

These two ideas, broadcasting and file server, are certainly different than 
the current common usage of packet radio on the amateur bands.  We feel that 
this is the best approach for the special case of a PACSAT, however, and that 
with suitable groundstation software, these concepts can be integrated into 
the mainstream.  

Implementation Status

Prototype implementations of all of the protocols discussed in this group of 
papers are running on UO-14 as of late July, they should be running on the 
Microsats by the time of the ARRL conference.  Prototype ground software is 
also running.  We plan to make the source code for simple versions of the 
ground portion of the system available asap.  Executable versions for the IBM 
PC will be made available as shareware, with the proceeds going to AMSAT-UK 
and AMSAT-NA to further developement of future PACSATs.  Fully integrated, 
automated, color graphic, ``all singing and dancing'' software will be avail-
able for sale by AMSAT-UK and AMSAT-NA later in the year.  Like QUICKTRAK and 
InstantTrak, the proceeds from this commerical quality software will go to 
finance future amateur satellite endevours.

We hope that other software authors will use the documentation and source to 
develop support for non IBM PC systems.  The contents of these papers are 
sufficient to allow programmers to begin implementing their own software now.


Correspondence

The authors may be reached at:
Telemail:            HPRICE or UOSAT
Compuserve:          71635,1174
Packet:              NK6K @ WB6YMH or
                    G0K8KA @ GB2UP
Internet:            71635.1174
                    @COMPUSERVE.COM
Mail:               Jeff Ward
                    UoSAT Unit
                    University of Surrey
                    Guildford, Surrey  GU2 5XH
                    UK

REFERENCES
[1]  Loughmiller D.,   and McGwier, R., ``Microsat: The next Generation of 
OSCAR Satellites - Part 1'', QST, May 1989, pp. 37-40.

[2]  Loughmiller D.,   and McGwier, R., ``Microsat: The next Generation of 
OSCAR Satellites - Part 2'', QST, June 1989, pp. 53-54,70.

[3]  Clark, T., ``Amsat's Microsat/Pacsat Program'', ARRL 7th Computer Net-
working Conference, pp. 41-47, Columbia, Maryland, 1 October 1988.

[4] Ward, J., ``The UoSAT-D Packet Communications Experiment'', ARRL 7th 
Computer Networking Conference, pp. 186-193, Columbia, Maryland, 1 October 
1988.

[5]  Price, H., and McGwier, R., ``Pacsat Software'', ARRL 7th Computer Net-
working Conference, pp. 145-149, Columbia, Maryland, 1 October 1988.

[6]  Johnson, L., and Green, C., ``Microsat Project - Flight CPU hardware'', 
ARRL 7th Computer Networking Conference, pp. 186-193, Columbia, Maryland, 1 
October 1988.

