[FADCA] More on HF Gateways

[bud thompson]

Subject Changed from Re: Gateway, Anyone? (AUTHOR'S RETRACTION)
It's next year now, my penance is over, so I'm back at it!

The Florida layered network does not 'cover' the entire state which includes
not only some remote, generally unpopulated areas, but also some populated
areas where there are ham communities (i.e. ARES groups) that do not
have radio access as the vhf network does not 'reach' them yet.  This will
continue until additional LANS and connecting backbones can be established.

Until something better comes along . . .

I believe a vhf/HF packet node/switch could, in some areas, be a workable
solution to bring outlying areas into the more densely populated packet
network where there are more TelPac nodes available.  Even more simple would
be to have HF TelPac nodes where internet connection is available.

In the case of the Florida Layered Packet Network that would just be another
layer, thus increasing the overall available bandwidth.  A 40M packet port
at three or four strategically located switch sites (or ham's QTHs) would do
the trick here.  Whether those should all be on a single-frequency WAN could
be the topic of much debate as there are good points for that and for
putting them on individual frequencies.

Assuming a good S/N range of 110-150 miles on 40M during the daylight, I
would expect a reasonable throughput on 300 baud packet as there would be
little QRM.  Nighttime operations might be moved to 80M, but on the other
hand, considering the tactical nature of operating in the boonies, perhaps
there would be less use at night- even hams have to sleep.

The major advantage of using individual frequencies would be greater overall
bandwidth as more pipes would be available for simultaneous use.

Scene1:  Telpac Node(s) on HF (40M) that will cover the area.  These HF
sites would require internet connection.

Scene2:  KAM+ KA-NODE/Gateway HF / VHF to the local packet
network. (Or this could be accomplished using two TNCs and X1-J.)

In Scene1 there is no chance of full automatic unattended operation or
anyone making an outgoing call on HF.  Thus, no concern over unattended
automatic operation.  This I believe is classified as semi-automatic
operation where the user making the call is 'live' and responsible for
listening first.  All of WL2K presently operates this way on HF PMBO, VHF
PMBO, TelPac, and Packlink.  I've not studied the R&Rs lately; the HF
frequency might have to be in a special sub band.

In Scene2 there is now a chance that a station on the packet LAN could make
a call through the gateway out to HF. This raises the concern over (1) lack
of monitoring the HF frequency and (2) unauthorized use by those who do not
have HF privileges.  So long as these are packet only gateways, the AX.25
protocol handles the QRM/interference concern using DCD.  Unauthorized use
can be controlled by using BUDLIST/BUDCALLS/CONLIST/SUPLIST perhaps others -
I've not worked out the logic, but it is there.

Chuck has been considering TelPac Nodes at LINUX FPAC sites where internet
connection is available.  These could just as well be on HF as vhf.

Until something better comes along . . .

In the near term, that would be SCAMP that is presently being Beta tested.
If the HF hardware were already in place, it would be straightforward to
covert the HF port from packet to SCAMP.  This will, however, require
running SCAMP on a computer at the HF sites, rather than TelPac.  I believe
the long-term plans call for a SCAMP-'PMBO' - that would work similar to the
current PacTOR PMBOs for exchanging e-mail messages.

This leads to these SCAMP PMBOs being located at EOCs where possible in
hardened sites where they can be sponsored by the local ARES/served agency
group.  If we consider HF TelPac nodes to help extend coverage in Florida,
it might be beneficial to have some of them at EOCs in preparation for SCAMP
PMBOs.  That said, the more of these HF sites we have available, the less
critical 'hardness' is and some could just as well be at ham's QTHs as HF
PMBOs are now.

Happy New Year.

bud N0IA