This paper describes a new feature implemented within the APRS system, which allows transparent messaging between stations on the Internet and RF sides of the network, as well as on two distant RF networks using the Internet as a link.

In a paper presented at the Digital Communication Conference in 1997 I described the genesis of the Internet portion of the Automatic Position Reporting System (APRS) network. This is done with the APRServe software, which serves as the hub for interconnection of APRS users around the world. My work on APRServe has continued, and this paper will detail the Internet to RF messaging system made operational over the last year.

APRS remains one of the most vibrant and exciting aspects of amateur radio. Beginning on HF and VHF, the system has expanded to include an Internet portion, which enables the display of a thousand or more APRS stations nationwide. This is accomplished with a linked backbone of servers running APRServe software, and Internet Gateways, or IGates, which pass data to the backbone. Until recently, these IGates were one way–data could get from the RF network to the Internet, but there was no way for information to flow in the opposite direction.

With an addition to the APRS protocol and modifications to the Internet gateway software and the client programs, it is now possible to send a message from the Internet to a station on RF. Furthermore, it is possible to send a message between stations on two different VHF networks. This is done transparently to the user.

There are two problems that a bi-directional link between RF and the Internet could introduce into the APRS network. First, the volume of traffic handled by APRServe could easily overwhelm the capacity of the 1200-baud VHF network and the 300-baud HF network. Second, in order to ensure compliance with FCC regulations, the IGates must be certain that a message to be passed onto RF was originated by a licensed amateur.

The Internet has vastly greater bandwidth than the RF network, making it necessary to very carefully limit data coming through the gateway. In order to do this, each IGate keeps a list of "local" stations, where local is defined as stations being within a certain number of hops. The optimum number of hops will vary based on specific local network configurations, but generally 2 or 3 is used. Only messages destined for "local" stations are transmitted by an IGate. The system also does not pass messages that are both from and to a local station, which prevents local RF QSOs from being echoed from the Internet.

Since the HF network consists of a single 300-baud channel that is shared between all users in the country, no messages are gated from the Internet to HF.

When initially implemented, APRServe accepted any data that was passed to it, acting like a gigantic party line. However, in order to comply with FCC regulations it is necessary to make certain that only hams can initiate a transmission. The Sprouls and I worked out a method to do this with as little impact to the user as possible. All APRS client programs now send a logon message, which identifies the callsign of the user, the version of the program, and optionally includes a validation number. Based on this message, APRS places each connection into one of three classes. Read only access is granted to those connections, which do not send a logon message. This can occur with obsolete version of the software and with telnet clients. Internet-only access goes to those users who have sent a logon message without a validation number. This class of connection allows users to send their own position reports and messages to internet users, but does not allow any of this data to be sent over RF. Each packet from such a user is identified as untrusted, and every IGate checks to be sure a packet is trusted before sending it on RF. Finally, a logon message which includes a validation number which matches the callsign provides a user with full access.

While a full discussion of the APRS protocol is beyond the scope of this paper, an understanding of the system in general is necessary to understand how the messaging works. Unlike other packet radio systems, APRS utilizes the unconnected format within AX.25. While unconnected packets are well known to be inefficient for transmission of data from one station to another, APRS uses them for the dissemination of data from one station to many. This is far more efficient than creating a connection between each APRS user within an area.

When the APRS protocol was first designed, no provision was made for a station to forward data from another station (other than the standard AX.25 digipeating protocol). We added a packet format we call "third party" to handle this situation. It is important to note that this is not the same as the meaning as "Third Party" used in the FCC rules, which refers to messages from non-hams.

In keeping with the other APRS formats, which stress human readability, the other APRS authors and myself chose to simply allow the inclusion of any legal APRS packet in the form it comes out of the TNC while in monitor mode. For example, the following is a typical message packet as seen on the APRS network:

By using this simple method of encapsulation, we have enabled the retransmission of any APRS packet. This also turns out to be simple to parse, since it is only necessary to send the text following the ‘}’ recursively to the parser. In practice, we also modify the path info to be more descriptive of how the packet got retransmitted, so it would become:

In order to avoid overloading local area RF networks, we have not allowed the IGating of position reports. The thousand or more position reports seen on the Internet would overwhelm even the emptiest RF network. However, since a user involved in a QSO with another ham would like to see that person’s position on the map, an IGate sends a position report once every 15 minutes.

As is my custom I will close with a prediction of what I will be presenting at next year’s DCC. I expect to expand this messaging system to include email, so that a user anywhere on an APRS network will be able to send short email messages to anyone in the world. This should greatly increase the utility of APRS in disaster communications.

APRS now has of seamless integration of its RF and Internet networks. This produces a much more capable and robust system, and has some interesting uses in emergency communications. It is now possible to set up a link in a disaster area using APRS, and provide Internet messaging to all users within that area.