Introduction to Amateur Radio Multicast
by Charles Brabham, N5PVL
Multicast is an unconnected digital protocol like APRS or RTTY. It is also has some kinship with the National Weather Service's EMWIN digital weather data service.
With the multicast protocol, one transmitting station distributes data to an unlimited number of receiving stations simultaneously like EMWIN, but it does so with the added advantage of 100% accurate copy.
Amateur Multicast saw its first significant use by the AMSAT group.
Basics of Multicast Protocol:The Multicast Server ( transmitting ) station sends files that are decoded by the Client ( receiving ) stations and automatically saved on their computers hard drive. Any file type can be distributed, but Text files and HTML are the standard.
The Server transmits the data continuously in an endless loop, serving an unlimited number of Client stations that might tune into and be able to receive the multicast data at any given time.
There is no error correction system utilized with multicast protocol. Instead there is an error detection system in the Client software that prevents a transmitted file from being created on the Client hard-drive unless it is 100% complete and correct.
Incomplete files are stored in a database awaiting the next transmission of that file, when the software will have a chance to fill in any gaps, complete the file and create it on your hard-drive.
To receive the multicast files, all you need besides the AltCast software on your computer is a shortwave receiver of some kind, and a cable to run its audio to your computers audio input or Mic plug. - You could get by in a pinch by putting your computer's microphone close to the radio's speaker, and some digital modes work out fairly well, that way.
How it Works:The Server station divides each file to be sent into DATA blocks of a predetermined size, then transmits all of those DATA blocks in turn, for each file it has queued for distribution. Each DATA block has a checksum included so the Client software can know whether it has received that block intact or not. When the client software has all of the DATA blocks for a particular file intact, then it automatically combines them to create the file on the Client hard drive.
If one or more of the DATA blocks is not received intact by a Client station due to interference, poor propagation, static crashes or whatever, the software keeps the intact DATA blocks it has received in a special database file, and listens for the missing blocks to be transmitted again. When it is able to fill in the gaps for 100% accurate copy, it creates the file.
This is how an unlimited number of receiving stations can get the same transmitted data with 100% accuracy, even though some of them may not have consistently good reception of the Server's signal, may experience interference at some random point, or may not be tuned in to listen until a certain time.
Stations with poorer reception may still get all of the transmitted data, but they would have to wait for fills to arrive, when the data is transmitted again.
Nice Features:Note that when a new, updated version of a file is distributed, it will overwrite any older version of that file that may exist in any Client stations 'incoming' directory. This allows automatic updates of data like weather data, situation reports, warnings and directives - without a clutter of old, obsolete files.
You can of course make a copy, or change the file-name of any file to preserve the data as it is at that moment.
The current amateur multicast software, ALTCAST, features a tiny pop-up browser. When an HTML file is received, it pops up the browser automatically to display the file. This will be useful for alerts, providing a way to grab the Client stations' operator's immediate attention. - The pop-up browser is used instead of your system browser, as a security measure.
Multicast Distribution:
A single multicast server on HF can distribute information to an unlimited number of recipients simultaneously within it's coverage area. In this illustration, a multicast Server in Oklahoma city distributes data to better than a dozen states, simultaneously.
A small number of multicast servers can cover an entire continent, with overlapping areas of coverage.
It is not an unreasonable goal to try for true global coverage with this system, something that would be prohibitively expensive and complicated with the point-to-point messaging systems we are familiar with.
Transmission Content, and the Update Cycle:Any file type can be distributed via multicast, but there are limits to how much data a server can reasonably be expected to distribute within it's
update cycle, the amount of time it takes the Server to send all of its files and start over again on the next loop, or cycle. This is referred to as the update cycle because if a Client misses getting a particular DATA block, this is how long the Client station will have to wait for that block to be transmitted again, so it can fill in the gap and complete the file.
The amount of data that can be sent within a reasonable update cycle is dependent upon the data throughput of the digital mode being used. For example: PSK63 will transmit more data within an allotted amount of time than PSK31 will do. The update cycle should always be as short as possible so that Clients can receive the data and any necessary updates in a timely manner. Modes that offer greater throughput can allow more data to be sent in the same amount of time.
On the other hand, digital modes with greater throughput are also likely to have a much smaller effective coverage area, meaning that far fewer Clients can then be served by that signal. Since the efficiency of multicast protocol is primarily driven by the number of clients served, not by how fast the data is transferred ( as is the case in point-to-point systems ) you will rapidly experience a case of diminishing returns if you place too much emphasis upon the data transfer rate in order to push more multicast data.
So, the smaller the area you wish to distribute to, the faster you can reasonably expect to transfer that data, and of course the more total data you can transfer. UHF multicast for example can utilize much higher data rates and transfer much more data in a given amount of time than is possible on the HF bands. On the other hand, the HF bands allow you to distribute a smaller amount of data at a slower data rate - to an enormously larger number of potential recipients in an enormously larger coverage area.
The larger the coverage area, the less total data you can distribute, to the greater number of recipients.
These is how amateur multicast works. On HF, it offers the highest spectral efficiency - by a wide margin - of
any digital protocol. Quite literally, nothing else can approach it's speed of distribution to a large number of recipients within a large area. This is possible because of, not despite the fact that it may be doing so with a digital mode that has a rather low data transfer rate.
Multicast protocol is fundamentally different from the point-to-point digital messaging systems we are used to working with. This is why a completely different style of operating applies to multicast protocol, and you can expect to lose much of your overall efficiency and/or coverage area on HF when using a faster digital protocol with it.
No other protocol utilized by amateurs has multicast's elegant simplicity and outstanding spectral efficiency. It is a truly amazing new tool for us, one that can allow us to do things today that we could only dream about in the recent past.
Suggested Distributions:News, Emergency Net frequencies and how to utilize them, Amber alerts, Contest schedules and data, Weather data, ARRL propagation and general interest bulletins, AMSAT bulletins, Packet bulletins addressed to ALL@WW and in general, any information of interest to amateurs that is addressed to ALL.
Most of my test transmissions have been of a short text file about multicast, telling where to find out more, and get the software. In addition to this, I generally send a few ARRL bulletins I receive by Packet. Sometimes I send AMSAT bulletins instead, for a bit of variety.
During the Katrina emergency, I altered my test transmissions to send a list of active amateur radio emergency net frequencies, along with a short note on ham radio etiquette as it relates to those stations.
Amateur Multicast Protocol transmissions can ( technically ) be read by anyone who is set up to copy the digital mode being used, but only owners of the Client software can have the files automatically duplicated on their hard-drive as they are received.
Here's what a section of text being sent just once with AMP ( amateur multicast protocol ) in the PSK31 digital mode would look like on regular PSK31 or multimode software:
Start of Transmission N5PVL EL16ck
QST QST QST DE N5PVL, EL16ck
Amateur Multicast Protocol Server
<FILE 9 166>MCAST.TXT
<STAMP 15 231>20060225 145534
<SIZE 5 239>523 5
<MODE 0 0>
<DESC 5 120>MCAST
<DATA 1 128 172>SP SYSOP @ WW < N5PVL $124-N5PVL
HF Multicast Distribution
R:060225/1954Z 124@N5PVL.#STX.TX.USA.NOAM [AltCast Server] $:124-N5<DATA 2 128 112>PVL
From: N5PVL@N5PVL.#STX.TX.USA.NOAM
To : SYSOP@WW
For information about the Amateur Multicast Protocol (AMP) for HF, <DATA 3 128 31>and the
software that is now available for this new protocol, send inquiries to:
multicast@uspacket.org
HF multicast allo<DATA 4 128 202>ws bulletins transmitted by a single server to be received by an
unlimited number of receiving (client) stations simultaneously<DATA 5 11 95>.
/EX
<EOF>
End of Transmission N5PVL EL16ck
As you can see, it is basically readable, but it would be much easier to read without all of those DATA statements, etc. where the Alcast Server talks to the Client stations with commands and info within the <> symbols.
The original file that the AltCast Client software would automatically reconstruct on your computer looks like this:
SP SYSOP @ WW < N5PVL $124-N5PVL
HF Multicast Distribution
R:060225/1954Z 124@N5PVL.#STX.TX.USA.NOAM [AltCast Server] $:124-N5PVL
From: N5PVL@N5PVL.#STX.TX.USA.NOAM
To : SYSOP@WW
For information about the Amateur Multicast Protocol (AMP) for HF, and the
software that is now available for this new protocol, send inquiries to:
multicast@uspacket.org
HF multicast allows bulletins transmitted by a single server to be received by an
unlimited number of receiving (client) stations simultaneously.
/EXNote that this message is ready to be transferred to the Packet Radio network, as an information bulletin.
The same thing can just as easily be done with other text messaging formats useful for EMCOM, but this example outlines how AMP distribution can be a useful addition to our existing HF network.
