[FADCA] LINUX White Pages / QRZ Stuff

[bud thompson]

Original message is after this response.

Note change of subject...

Chuck- All that sounds fine- and would certainly be of major benefit in 
general and especially during emergency exercises when we would have 
stations pop up that had not been on the network in a long time (and the 
operators of which did not know much about navigating the network).

I believe this "WP" feature of LINUX FPAC has been mentioned before - some 
of it is above my head, but if it means that a packet station could issue a 
simple connect to call letters or alias only without any routing information 
in the connect script and from any LAN and the network would make the 
connection - that would be slick for sure.

Once we might have this working throughout the state - which might be a 
while yet as we have no FPAC LINUX experience at all - I'm confident the 
WL2K Development team would take advantage of it and recommend programs in 
the Paclink computer to take advantage.

Meanwhile - to be sure the existing system is understood - Paclink AGW 
stations only connect to Telpac nodes to find a PMBO or to a PMBO packet 
port.  There is presently no function for Paclink AGW to Paclink AGW e-mail 
exchanges.  So for the while, all the network needs to know is that a Telpac 
node or PMBO packet station is active and both can presently put out a 
conventional Beacon, and both are generally non mobile.

bud



----- Original Message ----- 
From: "Chuck Hast" <wchast at gmail.com>
To: "Florida Amateur Digital Communication Association" 
<fadca at mailman.qth.net>
Sent: Wednesday, September 15, 2004 23:50
Subject: Re: [FADCA] Lessons Learned - Hurricanes Charley and Frances 2004


> 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."
> _______________________________________________
> FADCA mailing list
> FADCA at mailman.qth.net
> http://mailman.qth.net/mailman/listinfo/fadca