[hfsig] Re: Call for comments on open protocols

[Larry Gadallah]

On 2/27/07, linlink-request at wetnet.net <linlink-request at wetnet.net> wrote:

> Message: 6
> Date: Mon, 26 Feb 2007 23:41:31 -0600
> From: Tim Gorman <ab0wr at ab0wr.net>
> Subject: Re: Call for comments on open protocols
> To: linlink at wetnet.net
> Message-ID: <200702262341.31940.ab0wr at ab0wr.net>
> Content-Type: text/plain;  charset="iso-8859-1"
>
> My guess is that you will never get a straight answer from the ARRL on
> anything concerning this request for information.
>
> It is pretty obvious that they are looking for a way to redeem WL2K by
> moving
> from Pactor to something else. That doesn't address the issues associated
> with WL2K turning amateur radio into a common carrier for
> emergency/disaster
> agencies and I sincerely doubt that you will see a straightforward
> discussion
> from the ARRL on that subject. However that *IS* the question they should
> be
> asking - whether using amateur radio spectrum to provide telecom common
> carrier links for carrying third party to third party traffic with no
> amateur
> in the middle except for providing the equipment and spectrum is where
> amateur radio should be going.
>

Hear, hear. Too bad it's bloody unlikely they'll ever simply ask this
question directly.

If they *ARE* wanting to move away from Pactor then they need to state this
> right up front because it constrains the solutions being offered to
> something
> that will work with an automated operation carrying record type traffic
> instead of a keyboard-to-keyboard operation.


As I mentioned earlier, I was hoping that any proposal offered could divorce
itself from the application, so that live or automated applications could be
equally well served.

Busy detection schemes on HF are typically a problem for automated
> operation,
> especially in a crowded spectrum with ionospheric propagation. CSMA/CD
> type
> operation only works well in a scenario where all participants can hear
> each
> other. The hidden transmitter effect coupled with propagation at HF makes
> the
> ability of all participants hearing each other a pipedream. Pactor
> overcomes
> this by just plain bullying everyone else off the spectrum it wants to
> use.
> If automated operations like WL2K truly move to an operation using good
> busy
> detection they will find their throughput badly limited with sessions
> running
> in hiccups. They will quickly find out why everyone else is so adverse to
> Pactor once their own operation is negatively impacted by on-channel
> interference.
>
> It would be much better if the ARRL were asking about the feasiblity of a
> token ring type operation using out-of-band signaling (i.e. a psk31
> control
> channel coupled with a faster data channel) to coordinate entry into and
> out
> of the ring as well as use of a hub to control whose turn it is to
> transmit.


HF should not be treated any differently with respect to the hidden terminal
problem.  Again, Phil Karn wrote up a reasonable proposal to deal with this
quite some time ago. See http://www.ka9q.net/papers/maca.html.

I'm not convinced the ARRL even has an understanding of what it means to
> operate in a shared spectrum environment. Adapting coding and modulation
> to
> to maximize throughput does NOT maximize spectrum efficiency in a shared
> spectrum environment -- UNLESS it can be done without impacting signal
> bandwidth. And if you can do it without impacting signal bandwidth then
> why
> bother with the adaptivity in the first place? Just pick the fastest
> method
> and go with it. If busy detection on a channel is hard to do just how hard
> will it be to tell if the adjacent +/- .75 khz (as an example) is signal
> free
> so you can determine if you can expand your signal bandwidth to increase
> throughput? That's one of the big problems Pactor has today. It expands
> its
> bandwidths when propagation is good -- and of course it interferes with
> anyone using the adjacent frequencies when it does so. How can this be
> good
> for spectrum efficiency? Expanding bandwidth used when propagation is good
> and lots of other users can be interfered with?
>
> Many of the ideas underlying these questions are based on the way Pactor
> operates today and it is designed for use on an ASSIGNED channel with a
> specific bandwidth dedicated to the channel. What you do inside of this
> channel to maximize operational efficiency is irrelevant to your neighbors
> who are assigned separate channels with their own spectrum. When it comes
> to
> sharing spectrum, however, you can't just expand your occupied bandwidth
> without impacting someone else.


I can visualize a situation where two correspondents could go through a
"training" sequence where they manipulated some combination of their
bandwidth, power, and symbol alphabets to obtain the maximum throughput and
if/when their bandwidth started to impinge on neighboring channels, their
throughput would not increase due to QRM and they would back off one "notch"
on their bandwidth setting.

Nonetheless, the question that problems with current Pactor operations
raises is this: Is it possible to devise a system that can configure itself
on a crowded band under dynamic conditions without user input? I agree that
Pactor and similar HF data systems have historically been designed for use
on dedicated channels, which are not a good fit for real amateur operations.
My understanding is that even the ALE protocols that are currently in use on
HF only deal with propagation concerns, not channel occupancy.

Yet the ARRL didn't even bother to include spectrum efficiency and
> interference mitigation as items to be considered under the "Adaptivity"
> question -- only throughput and "efficiency in two-way contacts".



Hmmm. When ARRL puts it that way, it sounds like Pactor and QRO is the way
to go. Just run over anyone  who's in your way, which sounds like state of
the art :-(. Seems to me that they also left out power management and
control.

I would respectfully disagree with you on the need for wideband data modes
> on
> HF. Heck, on 80m and 20m you don't have enough available bandwidth to even
> slip in a 10khz channel without wreaking such havoc on other users that
> the
> 95% or so of the amateur community that don't care about wideband data
> will
> be out cruising the streets looking for you. Think about it. There isn't
> enough total bandwidth available on HF to provide anything near real-time
> streaming video or anything like it. That means that most communications
> will
> be either real-time, adhoc keyboard-to-keyboard sessions or time-delayed
> messaging (e.g. text messages, SSTV, etc) sessions of some kind. Once you
> have made the conceptual leap to using time-delayed messaging then where
> does
> the need for wideband data come in? The delay only becomes an issue if you
> are using semi-automated operation where you have to sit and wait for a
> big
> backlog of messages to download over a slow channel. For this type of
> operation fully AUTOMATED operation of both client and hub are the only
> way
> to go. That way your messages can be on YOUR computer waiting for you when
> you are ready. The only spectrum efficient way for this to really work is
> to
> have the traffic passed to local hubs via the internet and then for your
> computer to pick it up from there -- i.e. VHF/UHF operation. And,
> fortuitously, this also happens to be where the spectrum space exists to
> handle fast data.


As I've mentioned before, I think we should treat the available bandwidth as
an arbitrary number, and ensure that the protocol makes the best use of
whatever is available. What I think would be _really_ cool but unlikely
would be some sort of DS spread spectrum on HF, but that's another can of
worms, even though it could solve a number of self-configuration and QRM
issues.

It just isn't spectrum efficient to use HF to operate in this manner. The
> hue
> and outcry about the interference caused by WL2K to other users should
> stand
> as mute evidence of this to everyone. Unless someone really has a true
> breakthru to offer the ARRL, any new "protocol" is just going to turn out
> to
> be as hot of a frying pan as the one Pactor now is.


The interesting question here is: What constitutes a real breakthrough? It
seems like from ARRL's point of view, a breakthrough would be some
replacement for Pactor that would allow Winlink nodes to continue operating
without generating an uproar about the QRM.

As far as proposals that address the real needs? How about something that
> doesn't turn the Amateur Radio Service into the Amateur Radio Common
> Carrier
> Service?


These are much broader questions. Given the association of amateur radio
with emergency communications, it seems clear that "clients" of amateur
radio in such situations could care less _how_ it works, all they will care
about (and remember, particularly when they are testifying in front of your
Congress-person who just pocketed a nice cheque from Big-Cell Co.) is
whether their messages got through. It's a much larger job to convert that
into a set of real needs.

Cheers,
-- 
Larry Gadallah, VE6VQ/W7                          lgadallah AT gmail DOT com
PGP Sig: 616D 4E52 CF1F 3FEC FFFB  F11B 7DB9 C79A EA7E B25B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/hfsig_lists.tapr.org/attachments/20070227/3f219a0c/attachment.html>