by Charles Brabham, N5PVL
The Amateur Multicast Protocol (AMP) is designed to allow a single AMP server to transmit information to an unlimited number of client ( receiving ) stations simultaneously. In many ways it is similar to the National Weather Service's EMWIN transmissions which also utilizes a single transmitting station to distribute data to an unlimited number of passive receiving stations. AMP is also similar to APRS in that it is a connectionless digital protocol.
Multicast transmissions are theoretically possible with most digital modes. The initial experiments were with VHF/UHF AX25 Packet and the current AMP software, Walt Fair Jr.'s 'AltCast' can be used with either of several PSK modes: PSK31, QPSK31 or PSK63.
This article will explore ways we can get a higher data transfer rate for multicast reception. There are a number of ways this can happen with PSK streams, involving both the client and server systems. Some of these techniques could be applied to other digital modes, but the discussion here will be about PSK streams.
Amateur Multicast Protocol server stations will tend to transmit at an established AMP 'watering hole'... In other words they will all tend to operate at or around an established frequency in much the same way that the familiar PSK31 watering hole on 14.070 USB works. The 'watering hole' is defined as the entire usable passband when you run PSK software centered on the agreed upon frequency.
Not much starting and stopping, just a number of continuous data streams
to tap into.
Many PSK31 enthusiasts have seen or used software that will receive and decode ten or more stations at the same time... For PSK31 enthusiasts this is a fun, interesting way to monitor a busy passband.
When AMP client software utilizes this same trick though, it can increase the data transfer rate for multicast reception by a factor of ten. - You can receive ten or more multicast transmissions at the same time instead of just one. Even if you can only receive two multicast servers though, you will still be getting twice the data transfer rate you would with just one.
This is a significant increase in the recipient's received data rate, and what it needs to work are for single-stream PSK AMP servers to operate at and around a known frequency, while recipients use special software that allows them to receive data from multiple servers at the same time.
This system uses operating practices and software capabilities that we are already familiar with. No new technology would really be needed in order for us to increase the data transfer rate for multicast recipients significantly. - To do this, we would need some new multi-stream PSK capture software compatible with AltCast and AMP.
Another way to increase the data transfer rate for multicast recipients would be to soup up the individual transmitted signal by utilizing multiple PSK streams. Again, this is not new technology... Q15x25 mode for example utilizes fifteen PSK streams to deliver a 2500bps data transfer rate.
Experiments with Q15x25 mode on HF have not been encouraging though... When a good connection is made in Q15x25 mode the throughput is impressive, but several performance drawbacks emerged during testing, the worst of which being the reduced signal strength achieved when driving fifteen carriers. - You do not get good range, or the ability to shrug off noisy operating conditions with Q15x25. As the sunspot cycle bottomed out and HF band conditions worsened, interest in Q15x25 also waned.
Because of the lessons we learned with Q15x25 mode, I will limit myself here to schemes that utilize three or four PSK streams at the most. - I would be skeptical of trying to use more streams than that in any case, as multicast's efficiency is primarily driven by coverage area and the number of recipients per server, not the data transfer rate.
Note that while limiting the number of streams is an sensible consideration for HF multicast, this is not so critical in the VHF and UHF bands where there is more bandwidth to work with, and more consistent radio propagation conditions.
So with the above in mind, here is a thumbnail description of how a single PSK stream works, followed by a few ways to utilize multiple PSK streams within single transmission.
In the above illustration, the yellow bar is a single PSK stream shown horizontally, and the text inside the yellow bar represents the data being transmitted. The stream flows from right to left. PSK streams and data in the rest of this article's illustrations are represented this way.
Here two PSK streams from a single server are shown. One stream starts at the beginning of the data to be sent, while the other stream starts off in the middle. In other words, One stream sends the first half at the same time that the other stream starts sending the second half.
Here the concept is taken one step further with three PSK streams, and the total data being sent from three different starting points simultaneously. Note that each PSK stream is sending the entire database continuously, over and over. If all is recieved well, the data is transferred three times faster than a single stream would do it. If one of the data blocks out of either PSK stream is corrupted or incomplete, the wait for an update is only one-third as long as would be the case with a single PSK stream.
This is also the point where we start to lose efficiency due to the reduced range and coverage area we must expect when a single transmitter sends multiple PSK streams on HF. The effects of this should be noticable with three streams, and I would expect it to become easy to spot by the time four streams are employed.
As noted before, these limits we run across in the HF environment do not usually hold true when operating on VHF and UHF frequencies, where bandwidth and propagation conditions are generally more favorable. You can get away with running more PSK streams at the higher frequencies than you can on HF.
The idea here is to move messages and data as usual, while also providing a "back channel" for high priority data, internal network communications, a command channel or any other special application for a low data volume, high speed backchannel.
In this example, the top two streams are carrying routine traffic while the bottom stream carries higher priority data.
In the example above, you may be wondering why the routine traffic gets two channels or data streams while the priority traffic only gets one of them. The reason for this is that the total size of the routine traffic is assumed to be many times greater than the priority traffic, which really should be limited to just a few lines of text.
The amount of time it takes the multicast server to send all of the data it has and start over at the beginning again is called the update cycle. It is called the update cycle because this is also the amount of time it takes to get an update if a data block is not received correctly for some reason or another, and you have to wait for that data block to cycle around to be transmitted again.
The more data you try to send overall, the longer the update cycle will be and the longer it will take to distribute that data. Because the priority channel only sends a few lines of text, it has an extremely short update cycle and because of this, those few lines of text will be distributed very quickly and surely compared to the routine traffic. Also, updates or changes to the priority traffic are propagated quickly for all recipients.
This principle of speeding things up by reducing the total amount of data sent applies to multicast operation as a standard rule of thumb because it is something the operator of an AMP server must always keep in mind. I described its application for a priority backchannel as this would be where keeping the size of the data sent to a bare minimum would make the most difference.
Multicast protocol presents amateurs with a new and unique facet of the radio art. It is so new and different in fact that I am confident that I will be coming back here soon to update this article with more materiel. Check back later and refresh your browser!
Charles Brabham, N5PVL