APEX stands for "APrs EXtended"; It will be a new protocol which expands on and fixes most of the issues in the older APRS protocol while still remaining backwards compatible.

APEX defines both a new protocol and a new paradigm. Since much of the new protocol will not run on existing hardware APEX also includes a Python reference implementation that will provide a full APEX application out of the box. Since APEX is backwards compatible with APRS it can fully utilize existing APRS hardware to route APEX packets across the network. Though only APEX capable stations would be able to make full use of the information in an APEX packet.

The software for the project can currently be found at the APEX GitHub page.

APEX Routing Paradigm

The APEX routing paradigm defines a few new routing identifiers in addition to the common ones such as "WIDE2-2", and a few new behaviors on how the paths are consumed.

The problems with the current APRS model are numerous. One problem is that aside from the use of WIDE and GATE there isn't much flexibility on how we can route packets when we don't know the explicit digipeaters with which to specify; Using WIDEN-n is more of a sledgehammer when we need a scalpel. It is also completely ineffective at being able to route a VHF message across HF channels which may be critical during an emergency. A similar problem occurs when we consider multiple HF nets across multiple bands; as it stands right now there is no paradigm that defines cross-band digipeating paths. The closest we have is the GATE path which is generally used to only digipeat from HF into VHF. This has some limited usefulness at best. As such the initial release of the APEX reference application attempts to address these problems (though testing and feedback may change the details of the specification as described here).

Cross-band Path Routing

In order to facilitate cross-band routing the APEX protocol defines several new designators as well as includes many of the old ones. Obviously WIDEN-n, GATE, and your own callsign will behave similarly to how they behaved in the old paradigm. However the new band-specific designators will have a form of ##M### or ###M## where # represents any digit 0 to 9. The first group of numbers specifies the band ID, while the second group of numbers is the net ID and is optional. In this way the designator 30M would represent the 30 meter band as a whole (specifically any nets on that band the station is capable of). When 30M is specified in a path, a station will digipeat that packet out on any port which is tuned to the 30M band. Similarly 30M1 would specify a frequency (net) that resides within the 30M band. The list of identifiers for the various nets will be updated periodically as new nets show up. However right now 30M1 would specify the world wide FSK based APRS network residing on 10.1476 Mhz USB; similarly 30M2 would specify the world wide Robust Packet Radio based APRS network which resides on 10.1473 Mhz USB. similarly other designations would be chosen for other networks throughout the world. A complete list would have to be compiled.

Using these new designators in a path would be relatively straight forward. If, for example, you wanted a packet to take one hop, then move over to the 30 meter Robust Packet Radio channel, then move back to ordinary VHF for its last hop, and you dont care what the specific frequency on that hop, then you would construct your path as follows:

WIDE1-1,30M2,2M

Notice the last hop is just 2M with no number suffix. This is because we just want it to gate into 2M network and don't care which frequency on that band it is gating into. As a side note the GATE specifier would actually perform the same function as the 2M specifier.

Preemptive Routing

Preemptive routing is unique to APEX and also made it into the initial release of the APEX reference implementation. With preemptive routing a digipeater can respond to certain specifiers in the path even when they are not the next hop in the path. With the cross-band path specifier mentioned above, ###M##, an optional ssid can be added to the end. If the ssid is not 0 then it specifies that the path should be treated preemptively. Essentially what that means is if it is the next hop then treat it normally however if it is a future hop you can skip all the hops in between and go straight to the hop, assuming the station is capable of operating that band (otherwise it is ignored).

For example say we wanted to create a path where I get a packet out over HF and thats all I want to do. Consider the following path:

WIDE1-1,WIDE2-2,30M-1

In this case since 30M-1 is preemptive then the packet will hop across the WIDE path but every station that hears it along the way that is capable of 30M band transmission will emit the packet on that port as well. Contrast this without preemptive paths where it would look like:

WIDE1-1,WIDE2-2,30M

In this case the packet would follow the WIDE path and even if they are capable at digipeating on 30M it will not do so. Only the very last stations that hear the packet after the WIDE portion of the path is spent will actually be the ones to digipeat over to 30M. This would cause far fewer emissions on the 30M band while still ensuring the transmitting stations are geographically spread out. In an emergency this might be a good way to send an emergency packet out.

When a path specifier has a non-zero ssid it is preemptive. The value of the ssid indicates its priority. So when there is a long path with several preemptive routes specified it is always the one that is the highest priority and when there is a tie it is always the right-most (last in the path) specifier that gets triggered. For example say we had the following path:

ECHO*,80M-2,WIDE1,30M-2,80M-1

In this case if the packet is received from a all-band capable station then it would emit the path for 30M-2 when digipeating the packet. The reason is that 2 is a higher priority than 1 and of those of equal priority the 30M-2 was the later one in the path.

Also important to note is that when preemptive pathing is executed all the intermediary paths that were skipped get dropped from the path entirely. So the above path, once digipeated, would be transformed to the following path:

ECHO*,WI2ARD-1*,30M-2*,80M-1

Another interesting twist is how preemptive routing handles the other types of path specifiers. Basically the WIDEN-n type specifiers are never treated preemptively. However specifiers which reflect the stations own callsign are always treated preemptively. callsigns, unlike cross-band specifiers do not have their priority reflected by the presence of an ssid; they are also still treated as preemptive even when they have an ssid of 0.

When there is a mix of callsign and cross-band preemptive specifiers in the same path then first the cross-band preemptive specifier is determined as before, second the right most occurrence of the station's callsign is determined. Which ever of the two occur right most in the path is the one that wins. For example:

WIDE2-2,WI2ARD-1,30M-1

In this case the preemptive path would jump to 30M1. However if instead we had the following:

WIDE2-2,30M-1,WI2ARD-1

In this case the preemptive pathing would jump right to the WI2ARD-1 path.

APEX Reference Implementation

As part of the APEX initiative the project includes an APEX and APRS client that acts as the APEX reference implementation. It is extensible and anyone with python experience can write plugins to expand it and hook their own software into it. This allows for lots of opportunities from the community to get involved and contribute to the project.

Currently the reference implementation implements all the features I described here so far. It also includes the transmitting beacon, status, and id packets, and digipeating. So everything is ready to be played with. As new features roll out they will be added to the APEX Reference Implementation as well. It is a command line Python 3 application and you can find it on github. It is very simple to run and you just need to configure a few things in the config file to get it up and running.

Below is a screenshot showing it digipeating packets as they come in across two TNCs.

What's Next?

There are many features that have yet to be implemented and we have some pretty lofty goals in store for APEX. A lot of this is brainstorming from the team so it is subject to change as well. But here are the ideas we have so far on what needs to get implemented into APEX and defined within the protocol.

• Ability to send a signal check packet. These will never get digipeated. Instead you send a packet which contains some diagnostic information about the antenna (HAAT, Power, gain, etc). Next any station which directly heard you will respond immediately with information regarding their own antenna information. Also if possible data will be encoded to indicate received signal strength of the received packet (on most setups this information wont be encoded). The signal test request packet will also specify if they desire the reply packet to be over the air, or through APRS-IS or both. In this way the information can be used for someone to probe band conditions as well as objectively try to configure a new antenna installation.

• When possible encapsulate all existing AX.25 packets in FX.25 packets instead, thereby introducing backwards-compatible Forward Error Correction.

• Provide throttling to prevent congestion. Packets are given priority based on several factors such as the length of the packet, and how frequent the sender sends packets, to determine a packets priority. Higher packets go through while lower priority packets get dropped. Misbehaving nodes, or out of date notes not running APEX would be potential reasons to give a packet a lower priority in addition to traffic statistics.

• Include the ability to send images and other media, potentially across multiple packets.

• Optionally request acks at the packet level. This is particularly useful when using callsign paths. Though for WIDE paths it is still useful to know what paths a packet took for diagnostic reasons and path discovery reasons. In this way an initial packet in a series can use wide but once the paths are discovered then the explicit paths can be used for the subsequent packets. This would reduce network congestion.

• Subscribe-to-callsign: a mechanism whereby a request can be sent to a normally out-of-range station to send me periodic updates to their beacon or other similar packets (comment, id). This is useful for tracking a friend when the station doesnt have internet access of their own.

• Improve or replace the IGATE system so that multiple instances of the same packet can be reported to it (with different paths)

• Rolling beacon ranges. Stations will move over to a store and forward approach. Essentially they will cache as much information about the system as possible. The longer it stays on the net the more information it should receive from distance nodes. This is accomplished with rolling beacons. Basically every station will keep track of how many times they have heard a beacons from the various stations. Any time a beacon is heard more than 'D' times where the receiving station is the last hop, then it will digipeat the beacon, and reset the counter. The value of D is an integer representing decay rate. A higher letter for D and stronger the decay rate. What this will cause is a beacon from a station that has been on a long time will get their beacon across the world hundreds of hops, but very slowly. Because the packets decay with distance this also wont cause a lot of net congestion. For example you might hear a beacon on VHF come from across the continent, but such occurrences would be very rare as well. So it may be exciting to follow rare DX like that. Using this system even if the network went down across the world (not an expected occurrence) it would still be possible for systems to communicate across long distance APRS links, by leveraging the stores cache of beacons every station has they can easily form a path.

• Smart routing for internet capable stations. When considering #8 combined with IGATE access it makes smart routing a possibility. Smart routing would be the process where the route of a packet to reach its destination can be discovered from the fixed stations in a region. The idea is that if the internet goes down these stations still have a cache locally of where the stations are around the world and in their area. This information can be used to create more direct route for message-type packets with a specific destination. This will significantly help congestion since these packets no longer need to try to follow WIDE type paths. Plus a system like this will be more resilient in situations where you have wide spread internet outages.

• Enforcement of certain behavioral rules for stations and to react automatically to a misbehaving station. For example if a beacon rate is too high then all beacons above the accepted rate will be dropped. This will also penalize the priority that station gets when routing its packets.

• Proper standards defined and implemented to encode the protocol version into the packets.

• Geographic routing: We want to add the ability to route packets to approximate geographic coordinates, either in an attempt to send a specific message or to transmit a WIDE message at that location to seek contact with anyone who may be actively listening.

• Better software messages for responding to various types of messaging: CQ, Bulletins, and messages need a nice clean GUI to work with or command line tool

• Delay Tolerant Networks - The general use case is to leverage moving cars for long-distance packets where latency isnt a top concern. It can transport high volumes of data long distance where normal packets could not.

• Retry packets from partial path: When a packet doesnt get to its destination, since stations will be expected to a have a large cache of packets heard, delivery can be retried by the closest node that successfully received the packet. This would make long-distance packets far more feasible.

• Mobile stations can announce stationary "home station". Once geographic packet routing is in place then two mobile stations can stay in touch by simply knowing their route to the home station at anytime. This simplifies discovering routes that would otherwise be impossible between two mobile stations without the use of the internet.

• Formalize the use of ID packets to clearly specify the various path identifiers that can be used with the station and their effects. for example "WI2ARD/30M2 IGATE" might specify I have a station with ID WI2ARD on 30 meter robust packet radio, and it is also igate capable. This, along with position beacons, should make it possible to discover paths dynamically.

Jeffrey Phillips Freeman

Data scientist, open-source innovator, and three-time founder who writes about graphs, radios, and the occasional impossibility. Allegedly just another data scientist. Say hello →