[FADCA] Lessons Learned - Hurricanes Charley and Frances 2004

[Chuck Hast]

Bud,
Indeed you and the others win the boobie prize for the sidestep of the
century. We here in Tampa were sweating bullets for a while, and though
we did not joy in others misery we were most certainly happy it did not
continue our way.

In dealing with all of these network issues there is one thing that stands
out, we do not have a system for "registering" a unit on a a data channel.

In the commercial world this is one of the most basic functions of any
data or for that matter voice device today in the RF world. Case in point
as soon as you turn your cellphone on and it does it's logic check it
tries to register with the network once it finds one that it is allowed on.

Same goes for wireless data gear, and even trunked systems. As soon
as you turn the radio on, it does some sort of self check and scans for
a control channel looks for a slot and sticks it's hand up and registers.

We need to look at incorporating that concept into our network. Indeed
there is a big piece of it already there in the Linux FPAC code. It is the
white pages that allows a user to connect to the local switch and issue
a connect to another user out on the network, providing that user is
on another Linux FPAC switch. The "whitepages" have the ability to
exchange heard list data so that switches know where users are. In the
past we have sort of avoided this because of bw issues and the fact
that the broadcasting of node data is the real weak point of NR type
networks. But if we have 9k6 or faster links and we set the timers up
properly so that this data is exchanged at a reasonable rate then the
network should be able to handle the added overhead.

Now if we add to that a piece in the switch that sends out sort of a 
QRZ? packet, every so often and any station who has just come on
channel can then stick up it's hand and register, then the part that is
already there, the white pages part can kick in and move that data
through the network. We will need some additional smarts in the user
end code so that it can send out a short packet to register with the
network off of that switch. There is already bits and pieces of it in the
TNC code. Indeed most TNC's have a command that will cause them
to respond with a UI frame that contains of course the call and perhaps
some short message. The TNC will allow you to program the call that
will respond to the QRZ? packet. So really all we need to do is set up
the switches to send the QRZ? packets on a periodic basis in order to
allow devices to register with the local switch.

Now here is the other side of this bit of really common magic, if the
switch can insert into the QRZ? packet some basic info such as call
(we no longer need to worry about X.121 address unless we are trying
to force a connect to some place that either is still running FPAC DOS
or we need to get to something we know is on the network but just does
not show up for some reason) X.121 address and any other data that
would allow the subscriber end to automaticly register the network
data with it so when the user needs to send something the connecting
and sending is all done in the background. Indeed if Linux FPAC handles
UI frames as some have told me we no longer need to even establish
a connection if the path is good to the switch, it can just be handled
as UI frames and the registration if for routing reasons only.

Here is a summary of this bit.
------------ Network Side
1. LINUX FPAC already has the bits and pieces to handle the promulgation
    of user location data across the network. So we already have the
    ears end of the registration process.
2. The software can use a simple beacon which sends local switch data
     i.e. access point call and if needed X.121 address.
3. The switch probably should send some sort of "your registered" packet
     so the subscriber unit will not continue to attempt to reply to QRZ?
    packets. This could be a list of hashed callsigns in the QRZ? packet,
    so the registered devices will see their call and stop responding. When
   the call drops out of the list, they reregister.
It would appear that we can probably do most of the access point side stuff
already if I recall the switch setup correctly.

------------- Subscriber Side.
1. TNC or AX.25 driver on subscriber PC must be able to capture and process
     Switch network data from QRZ? packets
2. TNC or AX.25 driver when it hears QRZ? packet should respond with a
     packet with of course subscriber call and other data that the network can
     use. This piece is in part of whole already in some TNC's, I know that the
     PacComm units have it. I will have to see what it responds to.
3.  The QRZ? data should be passed to the subscriber PC so that the client
     can automaticly establish the connection through the network with no
      user intervention. It gets all the pertinent data out of the
QRZ'? packets.
4.  The subscriber unit would look for it's call in the subscriber list in the
     QRZ? packet when it hears it it no longer attempts to respond.

What is funny is a good part of this is already there, all we need to do is look
at what is missing and add it. Just this small modification would allow for real
mobile data, as you would move from switch to switch and register with
the nearest switch you are on.

Ohh, but it gets better, you could also insert a neighbor list into some control
packets and as the mobile moves away from the switch it is registered to it
starts to see it's BER drop, it then (this requires a programmable radio) goes
and checks the neighboring switches to check for the one that has the lowest
BER and if it finds a better signal registers on the new switch.

Again most of this is already out there all we need to do is add it to
the software
I do not know about the ham radio boxes but with the Tait boxes the radio
programming is offered as part of the developers kit, and you can take total
control of the radio via a RS-232 port.  If you had your switch list programmed
into your software all it has to do is go see who the neigbors are and stuff
each one of those channels into the radio jump channels and send a WRU?
packet, the switch on hearing it would reply with a QRZ? and register the
new device. The white pages would update and put the subscriber on the
new location.
Long summary...








-- 
Chuck Hast 
To paraphrase my flight instructor;
"the only dumb question is the one you DID NOT ask resulting in my going
out and having to identify your bits and pieces in the midst of torn
and twisted metal."