This web page talks about different options we have when building out a network of packet stations and compares each. If you can think of a configuration I missed or can critique this page, please email me at my QRZ-listed address.
The TARPN packet network is made up primarily of low technology digital modems and off-the-shelf radio hardware. Packet radio with this kind of equipment has a bad reputation because packet networks with no design intent, or with poor design, have performed badly. Typically, network operators attempt to fix badly performing networks by insisting on user access policies, regulating who and when access is granted for all or parts of the network. .
I think with good design we can get much better results. For the purposes of this discussion, consistently getting 40 characters per second between any neighboring stations, regardless of number of participants or content, would be good results.
Here is a fiction (based mostly in fact) about how the systems we have seen come and go were implemented.
Practically speaking it is worse than that, because as the number of users grows, not everybody can hear everybody. Take
The grey thick lines are radio paths between the stations. Everybody is on the same frequency.
Sergey can hear Bob and Bimaldo, but not Sigmund or Anna-Mae. That means that Sigmund might start transmitting while Sergey is already on the air.
Before reading further, check out this article: FAQ HTS
If Sergey sends a packet to Bimaldo, and Sigmund goes on the air at the same time, Bimaldo would miss both packets. Sergey will not retry until his FRACK delay runs down. Using TNC default numbers, that's a delay of about 4 seconds. If Sigmund is sending to Bimaldo, his packet also would have to be resent. Sigmund would be able to talk to Anna-Mae, and get acknowledgements despite Sergey's retries. However, when Bimaldo finally does answer Sergey, that could interfere with Anna-Mae and Sigmund's communications. These packet collisions result in retries which result in more transmission time just to keep up with the packets ready to go out. This temporarily decreases the channel available capacity. Also, in order for Bob to talk to Anna-Mae, his packets have to survive the gauntlet of collisions, and the delays of Ppersistence 3 times out, and 3 times back. Even if his packet was the only message in flight, it would take 18 seconds for him to get a response, best case. If the channel was loaded with all five stations being active, it would take much longer than that. Collisions in an HTS environment are really a bad problem.
A more modern management of the stations (employed by AX.25 built into Linux) would use a backoff-and-retry scheme where the time between of retries doubles with each failure and then very slowly shrinks with each success. Mathematically this could eventually reach a situation approaching the Aloha limits where the channel is only 18% busy at each receiver. While this performance is the same as I detailed above, it is automatically scaling. The failure of automatic backoff-and-retry occurs in a mesh system when success is available to the stronger station who captures the target receiver (see capture effect) while a weaker station consistently fails to capture on the same receiver. Eventually the weaker station is forced to slow way down while waiting for the channel to be nearly completely clear, before being able to access the required receiver. A manually (and correctly) configured Ppersistance model would give the weaker transmitter much better access to the required receiver. On a channel with transient users you can't correctly and manually configure the Ppersistance with existing systems, because the Ppersistance would have to change each time a new user joined or left and this information isn't propagated by any of the existing systems.
Mesh On Channel Advantages:
Adding a node or digipeater on the mountaintop makes things better, but only if nobody is actually sending packets through that mountaintop station.
If 3 stations go on the air via the mountain top during the same time-period, the mountaintop makes things much worse for the stations.
It has some social results as well.
Since the mountaintop relay exists, operators no longer need to maximize the antenna at their home station to encompass as much of the network as possible. Instead they can focus on getting a good signal into and out of the mountain. This results in the creation of even more hidden transmitters. Before, when you only had stations operating from their houses, a collision would occur when the several other stations within range of one station were all on the air. Now a collision can occur with any two stations trying to send to the mountain that are not within range of each other.
The mountain-top station may also be located at a site which cannot fall under the same service regimine as the home stations. This is especially true if the access to the mountain is conditional on 3rd parties. Hams tend to fix their own stuff, especially during an emergency and regardless of worsening conditions. Commercial vendors tend to fix the high priority stuff but sometimes not during emergencies. It is not unheard of that the mountaintop site, if commercial or government, would be unusable at the very moment when it is most needed.
Impact of inconsistant channel capacity
Key factors in keeping collisions under control are the Ppersistence and SlotTime figures. The point of these figures is to delay transmission, making it less likely that two stations transmit at the same time. In a local network where everybody can hear everybody else, the SlotTime figure is set to the amount of time that a station is unable to listen when it is switching to transmit. The Ppersistence covers the likelihood that two or more stations might want to go from listening to transmitting at the same time. Once the station is actually transmitting, there is no longer danger that another station my mistake the channel for clear. Ppersistence is calculated from the number of other stations that can collide at the receiver of the message, not the transmitter.
In a situation where the participants are transmitting to a mountain-top relay, the stations will be heard by the mountain-top the entire duration of the transmission but not by most of the stations transmitting to the mountain. If a mountain top location can hear 20 stations currently involved in packet operations, and most stations can't hear the other stations, then every station coming into the mountain needs to set Ppersistence to work out to a chance of one transmission in 20. SlotTime will then be the total duration of the receive to transmit switching time, plus the on-the-air time. That's 4 seconds or so. That could mean that on average, a station will wait for 20 x 4 seconds before transmitting, even if transmitting a retry. That's slow and the participants will never put up with it. Even if agreements were reached to make things work that way, human nature would have some of the participants cheating. The default values for Ppersistence in a KPC-3plus is 64, accounting for 5 stations on the LAN. The default value for SlotTime is 100mS or 1/10th of a second. For a mountain top situation the user station delay numbers are completely ineffective. This means that as soon as there are more than a few stations on-the-air, retries will start occurring, resulting in an even higher loading of the channel. The extra loading will build once it starts, result in all of the packet stations getting disconnected -- 0 characters per second. This is what we call a catastrophic channel meltdown.
Practically speaking this means that the packet channel will only be useful so long as only 2 stations are on the air within the range of the mountain top relay station, or
if the stations sending data are doing it at much less than the channel capacity, leaving the channel 80% empty, from the perspective of the mountaintop receiver,
i.e. as low as 8 character per second. In calculating the channel bandwidth it is not necessary to count the transmissions from the mountaintop relay since
everybody can hear it, but that is only true if there is one and only one mountaintop relay on that frequency and in range of the mountaintops!
Note! One way to dramatically increase channel capacity is to strike the requirement for acknowledgements and retries. This makes collisions much less relavent. This is the mode APRS runs in.
to restate: If the TNCs were set up for optimal operation via the mountaintop relay, the total channel capacity (all users combined) would be about 4 characters per second through the mountain top relay. If the TNCs were set up to default values, the channel capacity would be about 10 characters per second but it would only work if there were only 2 stations plus the mountain. However, the likelihood is that as soon as the hungry packeteers see that the channel is actually working again, they will join in and the capacity now goes back to 0.
Advantages of using a mountaintop relay:
With the repeater in place, Anna-Mae and Bob can see each other's stations on the channel. If they have their Ppersistence and SlotTime set up appropriately (the defaults actually) then the latency on the link will be about 4 seconds and they will be able to send an 80 character packet through in about 4 seconds assuming they are alone on the repeater. If there are five different transmissions with acknowledgements in flight, they will have considerably less throughput, between 20 seconds per packet (4 characters per second) and much slower. Latency would go up to a variable rate between 4 seconds and maybe 30 seconds.
Anna-Mae and Bob can connect through the network to each other. If they go through the hill mountain site they will have a latency of as low as 4 seconds for an 80 character packet and a throughput of better than 40 characters per second. If they went around the mountain through Sergey and Bimaldo the latency goes up to at least 6 seconds but the throughput is still better than 40 characters per second, assuming they are the only channel users. If the channel usership goes up (due to stations elsewhere in the network passing through the same nodes), the latency will increase and the throughput will decrease, but at no point does everybody get dumped. The throughput is deterministic in that there are no multiplicative costs for any particular number of users. Collisions do not occur. Life is good.
There is a timeout on the channel. If it takes more than L4TIMEOUT to transact any single packet across the network, then that connection will get disconnected. L4TIMEOUT is usually quite a bit higher than the typical latency. The disadvantage of a high L4TIMEOUT is that if the link is broken for some reason, it takes you a long time to find out.
Advantages for dedicated links over any other system:
A network with hidden transmitters like that described in the previous paragraph, with a dozen or so users on it at a time, will give a throughput per user measured in fractional single bytes per second. It is mind-bogglingly slow. The cost of station measured in station-cost per throughput is on the order of multiple hundreds of $ per character per second. That's ridiculous. It is a fundamental problem. Even multiplying the bit rate by 48 (i.e. to 56Kbaud) will only increase the available bitrate to 10s of characters per user per second and at a cost which is not much better. If a network was popular, after that upgrade, then it will gain more users which, because of the fundamental problem, will again be brought to its knees.
A dedicated link based network will consistently deliver text in a stream, leave connections up for days, and allow for 10-hop wide networks to have latencies of under a minute, all at 1200 baud. A dedicated link network could be from hundreds of times to thousands of times faster, with the same basic radio and modem equipment. Even with a 4 port node at every station, the cost of bandwidth is only about $1000 divided by 40 characters per second, or $25 per character per second. That would build a network which could reliably deliver bandwidth, assuming links which were set up well enough (and that IS going to be the hard part).
There are ways to fix an old-school network, knowing what we know.
The first is to move some of the devices (users or services) to HTS-free controlled zones, or to repeaters. Or to move some of the devices to dedicated links. Perhaps both fixes would be implemented in stages and in various places. Eventually every system which generates traffic at rates higher than 80 characters (one line) every minute onto a channel with out-of-site stations should be moved to a dedicated link. LANs should be broken up into no-HTS zones of no more than 10 stations.
Moving wholesale to dedicated links had many advantages but is very hard and expensive when considered as a network and all at once. Perhaps the way to start is to work on a whole-new parallel network, maybe not even connected to the existing network, and definitely not connected to the Internet. Once the parallel network gets big enough (and it will take a long time) you can start co-opting services. Getting keyboard-ops (live human operators) over to the parallel network is actually pretty easy if you can find any survivors. Demos of the parallel network are always interesting. It either lights up their eyes or antagonizes the crap out of them.
In this day and age, the biggest real limits to implementing a dedicated link network from scratch are:
Dedicated links give us excellent performance and easy upgrade paths.