Amateur Multicasting Protocol (AMP)

by Walt Fair, Jr., W5ALT

One application for digital communications systems is the distribution of bulletins and information useful to the general amateur population. Rather than send 100 or 1000 copies of a single message or bulletin to individual hams, a logical alternative is to send a single message or bulletin and let those who are interested receive it. Such a system would have application in the distribution of weather warnings, Amber Alerts, hamfest and meeting announcements and much more. If binary data transfers were implemented, software could be made available and common compression techniques could be used to improve data throughput. The use of such a broadcast system would save bandwidth and make more efficient use of our precious band allocations.

To conserve bandwidth, narrow digital modes should be used. Additionally it would be useful to allow for error detection and correction, thereby enhancing the accuracy of the system. With these goals in mind, a so-called "multicasting" system has been designed and implemented for use on the amateur HF bands.

A previous attempt at such a system, called RadioMirror, was designed in the mid-1990's by John Hansen, W2FS, using packet radio as the communications layer and normal TNC's in KISS mode. Unfortunately it appears that information on the RadioMirror system is no longer available.

Multicasting Protocol Considerations

To begin the design of a system to be used especially on HF for the dissemination of general interest messages, bulletins and files, a mode familiar to many hams should be chosen as the communications layer. Since speed is not the overriding concern in such a system, a high baud rate is not generally neccesary. In addition, since the original concept was for the multicasting station to repeatedly send information in a loop, error correction can be done quite simply by waiting for the next transmission to correct any errors in reception. Therefore error detection is required in the transmitted protocol, but error correction is not required.

These days many hams have access to and regularly use the so-caled "sound card digital modes." Perhaps the most popular of these modes is PSK31, developed by Peter Martinez, G3PLX, and its modifications, QPSK and PSK63. These modes are normally meant for keyboard to keyboard communications, occupy extremely narrow bandwidths, are efficient under the poor QRN and QSB conditions often encountered on HF, and normally do not require high power to maintain reliable communications. In addition, QPSK contains fairly good error correction by the use of 5 level Viterbi coding. For those reasons and the observation that rapid baud rates are not needed for real time operations, the use of PSK31 and its derivatives was chosen for the multicasting system.

Since multicasting will be a non-connected protocol where the receiving stations are totally passive, there is no need for hand shaking and related complications. The server simply repeatedly sends files, with enough information to allow them to be identified, checked for errors and stored. The client or receiving system, likewise, has no need to transmit, but simply listens for any files of interest, receives and saves them and checks for errors. If errors are found, the receiver simply waits until the file is sent again and attempts to retrieve the portion that was bad.

In addition, to make the system useful for the largest number of hams, it seems beneficial to keep most parts of the data transmission in normal text rather than use a complicated encoding scheme. As noted by G3PLX, the Varicode character set used in PSK31 is already optimized for the transmission of English text and unless there is sufficient compression advantage, there is a significant reason to keep the transmissions unencoded: Any passing ham could read the messages with normal PSK31 software and know what is being sent and by whom.

In order to transmit files for remote reception, the minimum information needed seems to be the name of the file, whether it is text or binary, the method for uncompressing the file (if compressed), and the data contained in the file. To allow automatic file updating, the time stamp and file size are also useful and should be included in the protocol specification. In addition, since error detection is needed, some sort of checksum and number of characters is needed to reasonably ensure accuracy of reception.

But since the transmission is to be done using commonly available systems, there is an advantage for further identifying or describing the information. Of course, as in all ham communications, there is also the legal necessity of station identification, too.

These considerations therefore define the protocol requirements to a large extent. The only thing remaining is the implementation and definition of specific formats and protocol elements.

Amateur Multicast Protocol Definition

The official specifications and definition of the AMP protocol are maintained by The Society for the Preservation of Amateur Radio (SPAR) and can be found on the SPAR web site. Note that SPAR does not provide software or software support for the protocol implementation.

Comments on this protocol are welcome. All dicussion and protocol revisions should take place on the SPAR Forum