First read FAQ HTS and FAQ CSMA
Networking on Purpose -- by Tadd, KA2DEW
By the late 80s it was possible to configurate a packet network router with two or more radios.
It was now possible to have sites to site communications which would happen without that communications impacting or being heard by another site.
Having multiple channels upped the cost of the network routers, made some stations not see each other since they'd be on different channels, and made network routing difficult.
However, having the ability to select frequencies gave us the opportunity to pick and plan networking strategies and to ease congestion.
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.
Typical solutions using packet radio try to legislate the problem away by specifying who, or what-for, and when, certain parts of the network may be used.
I think with good design we can get much better results.
For the purposes of this discussion, 80 characters per second between any two stations would be good results.
Here is a fiction (based mostly in fact) about how the systems we have seen come and go were implemented.
Five hams make a packet network -- mesh-on-channel
If you have five people sharing a single 1200 baud channel, each using a radio and a TNC, it looks like the group would have a maximum of 1200 bits per
second (max of about 90 characters per second in packets) to share between the five people.
But, because the stations would naturally transmit at the same time if you let them, each of the five stations is set up to implement
CSMA using SlotTime and Ppersistence calculations.
Even with no collisions, an 80 character packet message and acknowledgement takes 5 seconds to exchange on this shared channel.
So the group of five is now sharing 16 characters per second. If there was a magical supervisor guiding the stations to transmit at the appropriate times,
the channel could achieve 90 characters per second, but there is no magic here. Instead we have Ppersistance and SlotTime.
Practically speaking it is worse than that, because as the number of users grows, not everybody can hear everybody. Take
this example:
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.
Advantages:
- trivial to implement
- trivial to reconfigure
- automatic best-radio-link selection is easy, i.e. MESH
- all operators are of equal priority. No server vs user relationship.
- Serving as a relay point is trivial and built in to the basic equipment. This invites competition to provide relay capability.
Disadvantages:
- works badly when multiple stations active if stations don't use Ppersistance and SlotTime effectively.
- network will be slow when used for long-range multi-hop connects
- subject to catastrophic network failure when usership grows
- alignment (fine tuning/audio adjustment) of radio and TNC are with many unknowns so performance will be much reduced
- extremely difficult path to upgrade since all hams must upgrade together
- interference source or jamming would require coordination to spot.
No avoidance would be possible due to fixed frequency.
One feature which is worth noting is that Bob and Sergey can converse without interfering with Anna-Mae and Sigmund.
Mountain top relay -- mesh-on-channel
Historically, the next advancement for this little network would be to activate a relay station on Hill Mountain, enabling
Bob to talk to Anna-Mae by way of the hilltop.
The mountaintop situation makes things better, but only if nobody is actually sending packets. If 3 stations become
active generating packets, the mountaintop makes things much worse for individuals.
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 takes to move from listening to the channel to transmitting on
the channel. The Ppersistence covers the likelihood that some other station will go on the air. Ppersistence must be calculated from
the number of other stations that can collide at the receiver of the message, not the transmitter. Thus if a mountain top
location can hear 20 stations currently involved in packet operations, then every station coming into the mountain needs to set Ppersistence to work out to a chance of one
transmission in 20. SlotTime is supposed to be the slowest time of any participating station going from receive to transmit,
i.e. switching off its receiver during PTT until its transmitter actually starts putting out packet noise.
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. SlotTime needs to be the length of the entire transmission.
That's 4 seconds or so. That could mean that on average, a station will wait for 20 x 4 seconds before transmitting.
That's slow, but also the participants will never put up with that.
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 likely hood 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:
- trivial to implement
- trivial to configure, except for Ppersist and Slottime
- since all users are set on the same frequency, fallback in case of mountaintop relay failure is easier
- automatic best-radio-path selection is easy, i.e. MESH
Disadvantages:
- works badly in all cases where channel into the mountaintop relay gets more than 20% saturation
- in real-use situations the mountaintop can often hear another mountaintop on the same frequency, drastically reducing available bandwidth
- very difficult to come up with reasonable Ppersist & SlotTime settings
- impossible to assure that bullies don't grab the channel and cause jamming (unintentional or otherwise)
- no path to upgrade since all hams using the mountaintop relay must upgrade together
- value of mountaintop relay creates a development trend where low-profile users no longer work on range to neighbors, resulting in more HTS problems and less survivability
- mountaintop relay is subject to Exposed Receiver Syndrome making it nearly useless during prime time
- interference source or jamming impacts the relay or could impact other users and would require coordination to spot. No avoidance would be possible due to fixed frequency.
- due to high coverage, the mountaintop becomes a required asset causing apparent loss of value of 'normal' locations
- mountaintop location, achieving high importance to the network, would devastate local emergency preparedness if it has limited service access due to security and management control
- supports a sysop vs users class system
Digital repeater as packet relay
One solution for the hidden transmitter problem is to convert the Hill Mtn site into a repeater. The repeater would use a TNC modem for reception
and for transmission but no error checking would be done. Very low latency is required to permit CSMA to operate.
Advantage to a repeater vs a single-frequency relay:
- everybody on the channel can hear everybody else -- no hidden transmitters
- latency is very good since the packet is not decoded and resent by the repeater. Everybody is the same distance
- alignment (fine tuning/audio adjustment) of user station equipment need only be optimized to talk to the repeater receiver and transmitter, allowing for optimal audio alignment at the user stations
- the TNC default timing values for CSMA are now within the realm they need to be to work correctly
- CSMA system can actually work. It still depends on PPersistence being approximately lined up with the number of stations on the air at a time
- likelihood for catastrophic melt-down is very much reduced compared to the single frequency solution
The
total capacity of a repeater channel is about 20 characters per second with five users if the stations are setting Ppersistence correctly.
Disadvantages:
- individual packet stations are now built without a requirement for being able to reach any neighbors directly.
The discipline and expertise required for surviving a mountaintop site outage are not practiced.
- automatic best-radio-path selection is not possible since client radio is not on shared frequency outside of repeater LAN
- the repeater is also likely to be located at a site not serviceable by most of the hams, or any, depending on the site.
Emergency survivability is not assured.
The radios used by most of the hams are set for duplex to operate the repeater.
This means the radios at the user site can't ever be used as relays themselves anymore unless they are manually reconfigured.
- repeater users have to set Ppersistence and SlotTime appropriately and thus to not hog the channel
- channel occupancy still has to be somewhat low. If the system is set up for five users then you would see about 4 seconds or more per packet
- exponential throughput degradation as user population increases
- interference source or jamming impacts all users and would be difficult to spot
- no path to upgrade since all hams using the mountaintop relay must upgrade together
- supports a sysop vs users class system
- requires specialized node hardware and configuration -- some station or stations in the network needs to be using a network routing system in order to get traffic in and out of the repeater LAN.
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 chars per second) and much slower. Latency would go up to a variable rate between 4 seconds and maybe 30 seconds.
TARPN dedicated point‑to‑point links
The TARPN solution is to use Dedicated point‑to‑point Links. Every channel has only two stations on it in any give area. The TNCs are
set up so Ppersistence and SlotTime are removed from the equation. The rate of packet transfer is one packet every 2 seconds giving us
a throughput of from 40 to 90 characters per second depending on radio tx/rx/tx switchover times and depending on size of packet.
Now, while Hill Mountain may still be applied as a hilltop relay, we're using it only as a link between Bob and Anna-Mae. This doubles
the throughput around the mountain but is not unique in that if it were to go away, the stations still have the other route.
The latency across any link is depending on packet backlog but generally works out to about 2 seconds per hop for a large packet and 1 second per hop
for short packets. There aren't any collisions or load-cause catastrophic channel meltdowns. The cost of the system is about twice what it
would cost for single radios at each site but the throughput is from 5 to 500 times as good, depending on loading. Each of the network sites is notionally
expandable by adding more radios, though doing so at a commercial tower site can be a bit hard. Adding links at the individual ham-shack level is pretty
easy.
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:
- no magic supervisor needed to get best case performance
- pairs of transceiver/TNC combinations could be optimized for each other. Frequencies chosen, antennas aimed, timing and levels customized
- no collisions ever
- no need to use Ppersistence or SlotTime.
- power levels can be reduced to whatever is needed for a link, instead of max all-the-time
- interference source or jamming only impacts one link and could be trivially configured out via a frequency change or antenna change
- at 1200 baud, 40 characters per second is easy, 90 is possible
- increases in traffic just increases latency, but never results in catastrophic meltdowns
- excessive retries or other failures are trivial to diagnose since there is only one other station
- automatic routing is performed within the context of the defined radio paths
- everybody gets to run a backbone connected node. No sysop vs users mechanism imposed
- path to upgrade involves only two stations at a time so this can even be done experimentally
- hilltops, while still valuable, only get unique value if an around the hill network is impractical -- there is justification for linking around the hill
Disadvantages:
- requires specialized node hardware and configuration
- all connections are pre-arranged -- while this increases camaraderie, it doesn't come naturally
- non-portable in the context of one station moving to a new location
- automatic best-radio-path selection is not practical since pointing a radio at a new destination radio (and frequency and direction) necessarily removes the radio from prior agreed upon link
- since all stations are relay points and always up, this ties up station radios even if the ham isn't on packet
- antennas are also tied up in the packet operation
- bands are (at least partially) tied up due to use of multiple bands at same site just for packet. There are only so many ham bands
Pre-arranging connections, and tying up radios, are the big objections for most poll respondents.
In this day and age, the biggest real limits to implementing a dedicated link network are:
- interested stations tend to be too far apart for non-hilltop connections
- needing multiple radios at the relay location at a hilltop or tower may be difficult to get approved.
Certainly existing leftover commercial antennas are not going to be enough to support a multi-band relay device
- since hams these days tend to think of vhf and uhf as talking-to-the-repeater, they are not prepared to own and operate, much less dedicate, decent terrestrial antennas.
This is probably the biggest problem with making a terrestrial-only packet radio dedicated link system.
TARPN project -- FAQ: Dedicated Point‑to‑Point Links summary
The TARPN project aims to make setting up networks of dedicated links practical.
We want friendly, easy, cheap, reliable, and expandable. We're prepared to try it without commercial tower locations though that may not be reasonable in mountainous environs.
Dedicated links give us excellent performance and easy upgrade paths.