Internet to RF Messaging Via APRServe

It is now possible to send messages via the internet to stations on the VHF APRS network. This paper describes the methods used to accomplish this feat, what you need to do to participate, and covers some of the potential problems that may crop up.

The Internet portion of APRS has become very popular over the last year. There are more than 40 users most of the time, and the server averages more than 500 connects a day. Many people have been using the system as a keyboarding medium. When first created, the Internet Gates (IGates) were strictly one way. Data flowed from the RF network to the Internet, but not in the other direction. For the most part, this is a good thing, as the internet traffic would overload any 1200 baud VHF channel. However, the possibility of carefully controlled gating in the other direction has been envisioned since the beginning.

The first Internet to RF gating feature to be implemented is directed messaging. With this feature, stations in widely separated areas are able to communicate without internet connections themselves.

The Protocol

The first step in developing the messaging system was extension of the APRS protocol. We settled on a single, fairly simple method that will work not just for messages, but any APRS packet. The essence is to take an APRS packet, and preceed it with the symbol '}'. This makes it easy for the client programs to decode, when a packet is received that starts with '}', the remainder of the packet is recursively passed through the parser.

In practice, the processing before transmission is a little bit more complex than that. The path information in the original packet is of no use, so it is stripped out, and replaced with a more descriptive path. The following is an example...Imagine WU2Z sends a message to K4HG-8 on VHF with a path of RELAY,WIDE... 

WU2Z>APRSM,RELAY,WIDE:K4HG-8   :Hello Steve!{1

This message goes through 2 digis, before being picked up by the KB2EAR IGate. It then gets sent in the internet stream as: 

WU2Z>APRSM,RELAY,WIDE*:K4HG-8   :Hello Steve!{1

This message is analyzed by each IGate, and the APRServe machine (KD4DDO-2) in Miami decides that since it is hearing K4HG-8 on VHF, and not hearing WU2Z on VHF, it will retransmit the message. The old path is stripped out, a new path added, and the message is sent in the new format, using the unproto path of the IGate (in this case WIDE,WIDE): 

KD4DDO-2,WIDE,WIDE:}WU2Z>APRSM,TCPIP,KD4DDO-2*:K4HG-8   :Hello Steve!{1

The coolest thing about this system is the ACK gets sent just as before, and it works in reverse in the same fashion. No operator intervention is needed, this all occurs behind the scenes. Another extension of the idea will be the transmission of a single position packet at the same time the first message is gated from the internet to RF. In this way, the recipient of the message will be able to see the position of the sender of the message.

Validation Protocol

The next problem that needed to be addressed is user validation. Under FCC rules, only hams may initiate a transmission on amateur frequencies. With non-hams having access to the internet, there needs to be a way to limit the rf to internet gating to non-hams. We accomplish this with a validation number, sent as a logon message to APRServe. Users without a valid registration will still be able to send data to the internet stream, but it will be marked in such a way as to prevent it from being gated to RF. Furthermore, such unvalidated users will be unable to feed any other data into the stream.

Users who connect to APRServer and are either unknown or unvalidated will receive a message from APRServe informing them of their status.

The validation number will be generated by the client programs (Mac/WinAPRS, APRS+SA, etc). See the documention of your client program for the applicable registration policies.

Potential Problems

The biggest problem that may occur with the new IGating system is QRM. In its present implementation, no check is made for the existance of multiple IGates in an area. Therefore, if an area has multiple IGates enabled to retransmit messages, a message to a local station will cause all of them to transmit it. We think we have a way for the system to deal with this problem, but it will take a while to get it implemented. In the mean time, it is up to local users to be aware of who the other IGates are, and to coordinate with them.

Route problems

An IGate needs to decide if a station is local to it. At present, this decision is made based on the number of digipeaters the packet goes through, and the specific calls listed in the path. Specifically, a station that went through a GATE or TCPIP, or more than two digis, is not a local station. Areas that have rf gates that use an alias other than GATE may cause erroneous retransmission of messages. If this turns out to be a problem, we may add something like a budlist, a list of aliases which would be considered non-local.

This is experimental!

Keep in mind that although the pieces work in testing, there is no way to test this fully without going live. It is likely that there will be problems. Please let me know if something isn't working, or causing too much QRM. Given all the programs that are interconnected, it would probably be eaiest to send problem reports to me, and let me pass out the blame.
Mail comments/corrections k4hg@tapr.org