NOS Automatic Beacon System

Overview of the Specifications for a proposed NOS Automated Beacon System

Since this "paper" is really a proposal, many of the code projects, which are in various stages of development from prototyping to QA'ing, will only serve as a source of specification. Some are still just vague "visions" dancing around in the ether. So let's "blue sky" it a bit and see what might be possible as well as feasible...

What is this all about?

The basic concept is very similiar to APRS, and that is: using the broadcast facility of *NOS to send public information to all receiving stations, which are able to capture, read, sort, store, and display this information for easier management, and possibly send selections from that data pool on to other networks for re-broadcast. Here is a list of specifications and functions, some of which are implemented in JNOS and some of which need scripts or servers to complete the enhancements:

• Use the BEACON/ID functions to convey Information via Broadcasts
• Use Scripts and the Trace Server to record packets per interface/device
• Use Scripts/Servers to install "live" messages into Beacons
• Use Scripts/Servers to cross-link Beacon Information

Aside from the "congenial" uses of broadcasting via beacons or ids, this information channel could be put to good use in times of emergency or natural disaster. Situational summaries, weather reports, vehicle location tracking, FYI type alerts, mail and bulletin notices are among just a few of the categories of information that network operators may find useful to obtain without the need to establish a specific connection to other stations. And, this is not meant to replace such standard "channels" as point-to-point contacts, email, or converse protocols, the known strengths of *NOS, but rather to enhance those strengths.

Which Strategy: Re-compile or Add-on?

When you "ramp up" extentions in *NOS, you have two (2) choices. You can obtain the C source code and re-compile the module(s) in question, or you can find the links to JNOS and run the data streams through external programs such as those written in Perl or Java, or even Python. Is one approach any better than any other? I chose the second because of its adaptability to existing code modules and its flexibility. The downside is there may be too much of this flexibility, or too much "rope to hang yourself." (So, discretion should be the better part of valor... )

How does the Receive Module work?

JNOS has a facility called the trace server, which is slighty different from the console trace, in that it can work over a network! This is the link to packet streams via devices for JNOS! A filter program, which just monitors one device at a time, collects data and stores it in a logger file. The filter can be programmed to "see" only certain types of packets; and in this case, it is the BEACON, ID, MAIL, CQ, and QST types. The log file could be called dev-<device>.log, so the implication is that you may set one up for each device you want to log. (A process and a socket are established for each device to be monitored.)

Once the data is captured in the log file, you may then use "viewing" programs, or even shell commands, to display, peruse, or review the data. (This data could even be databased if desired.) The point is that the operator has a "permanent" record of events along times lines for data analysis. This data can be sorted by relevant "keys" or fields and could prove to be a valuable resource to the network either in terms of immediate action or for planning decisions for the future!

Since this system is highly modularized, you may only require the recieving facility, or may wish to begin experimenting with just this part of the system first by capturing the recieved data streams. Sometimes, stations transmit very detailed information in their BEACON/IDs. It would be convenient to have a copy of this information so that it can be read carefully as soon as it arrives, not after the 10th attempted read as the beacons fly by on the screen.

There is code under development for this module, named abscopy.plx. It is currenty under QA testing; however, it is stable and currently on-line. This Perl script opens a socket on JNOS, port 1236, instructs the trace server to copy all packets on the requested device, and then listens for all packets that have BEACON, ID, MAIL, CQ, or QST in the "header" line. If it finds one of these triggers, it then begins to read any message information that follows. When it encounters an EOR, end-of-record mark, which is the name of the interface on a separate line, it stops recording and writes that data to a log file named after the device being monitored.

There are also several minor scripts in development that sort the log file data by last heard time, and display it to the screen. They are prototypes at this point and may need more testing; however, they are stable and working on-line now.

How does the Broadcast Module work?

On the broadcast side, the "link" is established via the scripts facility in JNOS. This is an indirect linkage, not a direct socket connection as in the trace server application. And this is where the Perl "server" automation programs come into play. Since broadcasts are usually given at pre-set times, it is possible to coordinate and syncronize the on-the-fly content of any broadcast text using Perl servers or programs.

These events can be highly syncronized or less so. The more syncronized events require using cron, and the "at" timers in JNOS to "load" the ifconfig broadcast buffers just-in-time before the actual transmission. The more "relaxed" version can use the same facilites, but does not have to be as tightly coupled. (Both approaches have their merits.)

It is also worth mentioning that one of the main features of an ABS system is that the network administrators and operators can decide what the content and formats of the beacons may be. If and when a net is switched into an emergency mode, the beacon broadcast system may change completely! What was casual and nearly random, may now become highly structured and coordinated, perhaps even programmatic, so that certain types of information will be broadcast consistently at pre-assigned time slots.

There is code under development, and now completed, for this module named build_beacon and dataform.plx. Dataform.plx can be run from cron and generates a JNOS script named do_beacon. The latter is set to run via the JNOS AT timers. Dataform.plx can build these do_beacon scripts on-the-fly with "gathered" information. Right now, it is only capturing the local time and UTC time. So it is not hooked into any live data stream; but, potentially, it could be.

Can we get Broadcast and Receive Modules working together?

This of course is the ultimate objective. At present, there is no code under development for this linkage. So, it is pure speculation at this point in time! Those specs would call for a server to parse the log files for "marked" data fields. These in turn would be passed on to the dataform.plx code and built into the beacon formats as required. The simplest case might be similar to an "ACK" where a station responds to an "are you there?" probe, an indication that it is using the NOS-ABS system. (I have begun some code specs for this module...)

An interesting facility might include the ability to "cross-beacon" onto different frequencies. Since operators have control over all the beacon broadcasts coming from their stations, they could determine what categories of information may be shared. In emergency situations, it may be advantageous to dedicate certain frequencies to certain activities, for example, all mail might be transported on one, while all convers or QSOs might be on another. By "cross-beaconing" each group can be alerted to events occurring on other nets...

Closing Observations

NOS systems have traditionally under-emphasized their broadcast/beaconing capability. This brief article attempts to persuade network operators that they can employ NOS broadcasting to very effective ends for emergency or disaster modes. By "attaching" filter code to output data streams, logging and sorting that data, and then perhaps re-transmitting it, a NOS-ABS can be set up which has a wide range of network broadcast applications.

Whether you just want to be able to read, or store, broadcast information more persistently, or compose beacon messages more effectively in real time, or perhaps tie data stream inputs to outputs, you can custom design your own "APRS"-like system to suit the particular needs of your network!