Difference between revisions of "APRS digipeaters"

Latest revision as of 13:03, 19 December 2011

APRS Digipeaters

APRS Digipeater Background

APRS was designed as a new way of playing with packet radio. Instead of one to one communications Bob Bruninga created APRS as a one to many protocol. With that concept, new ways of getting the packets out beyond simplex range of the station was required. To fulfill the "Automatic" portion of the acronym, the operation of the station needed to be able to work without user intervention. With the existing packet network, each station had a unique identifier, be it a callsign, or a unique alias. This wouldn't work for APRS if the station were mobile, and moving about the network. The idea of using a single generic alias that would be implemented in every digipeater solved this issue. If every digipeater responded to WIDE, then a station using an outgoing path of WIDE would get digipeated as it moved between digipeater coverage areas. This works fine until you use a path with 3 or more of the same alias in a row. Running WIDE,WIDE,WIDE with just 2 digipeaters creates a ping-pong effect, where digi1 acts on the first WIDE, digi2 acts on the second WIDE, and the digi1 acts on the third WIDE. Adding more digipeaters compounds the issue. With just 3 digipeaters that can hear each other, you will end up with 27 digipeats of the packet.

UIFLOOD

In an effort to solve the ping-pong issue Kantronics implemented a routine in the KPC-3 line of TNCs. The algorithm in the KPC-3 was called UIFLOOD. This allows the operator to set up an alias that has a numbered suffix in the format ALIASn-N, where the values of 'n' and 'N' would be set by the APRS user to indicate the number of hops they would like their packet to travel across the APRS network. AX.25 limitations allow for a maximum number of hops of 7, so subsequently the maximum 'N' value would be 7. Each time a digipeater acts upon the packet, the 'N' value would be decremented until 'N' equals 0. A checksum of the packet callsign and payload is kept by the digipeater, and is checked against a table of previously handled packets before a packet is digipeated. If the checksum is already in the table, the packet is dropped. This keeps the ping-pong effect previously seen from happening.

The generic alias of WIDE was again used as the base alias for this routine, leading to some confusion when people talk about a digipeater path of WIDE versus WIDEn-N.

UITRACE

UITRACE is a close cousin to UIFLOOD, except that each digipeater that the packet passes through inserts its own callsing into the path portion of the packet, allowing one to observe the path the packet traveled through the digipeater network.

New n-N Paradigm

As APRS developed, a number of changes were made... RELAY, WIDE, and TRACE aliases came and went, new fancy WIDEn-N and TRACEn-N routines were added. A wholesale change to the APRS network was finally made when RELAY, WIDE, TRACE, and TRACEn-N aliases were dropped, and the New Paradigm settings were introduced. The generic alias to be used in this new configuration would be WIDEn-N, with an alternate choice of SSn-N where the SS portion would be replaced by the 2 letter state abbreviation.

APRS Packet Density

In the early days of APRS, there was not a lot of activity, and long paths could be handled easily by the network. However as APRS popularity gained momentum, packet throughput reliability began to suffer. In an effort to help alleviate some of the congestion seen, the concept of trapping large hop values was implemented. In the Kantronics line, the only way to implement this was to use the UIDIGI algorithm and program it with large value WIDEn-N aliases. With a limited number of UIDIGI aliases available, the decision was made to trap the most common initial n-N values. WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7 are usually trapped. This trap actually gives a single hop through the digipeater, and then replaces the path with the callsign of the digipeater.

This is a less than perfect solution unfortunately. If a packet arrives with some combination other than those implemented in the UIDIGI trap, the packet gets acted upon, and the longer paths can still get through. A better solution needs to be in place.

FLOODING and TRAPS

For the sake of this discussion, UIFLOOD and UITRACE both act in a similar manner, decrementing the final 'N' value. Callsign insertion is not relevant, and will be ignored.

In a network of Kantronics KPC-3 TNCs, with UIFLOOD setup to act upon WIDE, with packets entering the network with standard 'n-N' values you see something like this as the packet moves through the network:

With UDIGI traps enabled on WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7, we should be able to stop those long paths.

However, an issue arises when the 'n-N' values are not equal. This can be due to a digipeater that is not set up to trap the large initial values, an intial path request of WIDE7-7 gets turned into WIDE7-6, and sneaks in under the UIDIGI traps in the digipeater.

Another issue is if the user deliberately uses a non-standard 'n-N' combination where the value of 'N' is larger than 'n' such as WIDE4-7.

college admission essays