noone <noone@all.com> hath wroth:

>I'm a systems engineer involved in the design of unmanned vehicles and I
>am soooo frustrated with 802.11.

Why? What problems are you seeing with 802.11?

>The limitations of 802.11, especially in
>unlicensed bands, are a common problem in applications where real-time
>wireless control is a requirement. There is currently some research in
>using QOS enhancements and multi-radio-diversity to get around the
>unpredictable latency problems of 802.11 but those avenues will fall short
>of the end goal: reliable high bandwidth communications in a
>non-line-of-sight environment.

Latency? I get <3msec latency on almost all my short range LAN links.
The bulk of the latency I see is the result of retransmissions caused
by interference. If this is a problem, decrease the fragmentation
threshold in the access point to where you're sending fairly small
(256 bytes) packets. It will improve the reliability but will slow
down the thruput. What you're really dealing with is interference
mitigation and recovery. That's going to be a problem with any shared
wireless system. If you want a clear channel, buy one from the FCC or
one of auction winners.

>I played around a bit with ATM in the mid-90s and am wondering if any of
>the researchers or vendors are continuing the path of bringing ATM to the
>wireless world.

Wireless ATM circa 1995:
<http://www.cs.wustl.edu/~jain/cis788-95/ftp/wireless_atm/index.html>

Wireless telecom links are not sold as "wireless ATM" but rather as
"wireless OC-3", "wireless SONET", etc. See:
<http://www.winncom.com/products/category/WTPP/list.html>
for some typical examples. They're probably ATM compatible, but I'm
not sure how or to what degree.

>I know from my own experience that because of the ACK/NAK
>802.11 facilities large datagrams are statistically more likely to fail
>and retries will bog down the network.

You can easily reduce the size of the datagrams at the expense of
thruput by adjusting the maximum packet size through the access point
fragmentation threshold setting.

>The small cell characteristics of
>ATM, combined with FEC (forward error correction) would seem to be a step
>in the right direction if a better link layer protocol was implemented.

Nope. The small cell size was selected so that the loss of single
cells would not be perceptible on a voice transmission. It certainly
wasn't for thruput as the "ATM tax" and small packet size is a real
performance hit. UDP works in roughly the same way at ATM, where no
response it necessary.

There are FEC systems available with other protocols (i.e. 802.16
WiMax) along with randomization, interleaving, and symbol juggling. If
you really think ATM + FEC will be an improvement in real time
response, you should consider building a Matlab model and compare it
with 802.11. I have no clue as to your performance expectations or
what exact problem you're trying to solve, so I can't predict the
outcome.

I suggest you read a marginally related article on mesh networks at:
<http://pdos.csail.mit.edu/roofnet/doku.php?id=interesting>
What I find relevant is the statistical analysis of the delivery
probability of a single packet in the presence of noise, other users,
and interference. The probe data graph shows that with 1500 byte
packets at 11Mbits/sec, the average delivery probability is between
zero and 20%. Go to 1Mbit/sec and 200 byte packets, and the
probability increases to about 70%. Perhaps your system is suffering
from similar low delivery reliability?

>Can anyone shed some light on whether wireless ATM is an active research
>area? or point me to some links? A lot of the links I've seen are from
>research that is many years old.

Sorry, I can't help much. I don't do much research. Try searching
with:
<http://scholar.google.com>
using "wireless ATM" as a search key. Hit the "recent" button near
the top. I skimmed some of the articles found and noticed that none
of them involved 802.11. They all used proprietary modulation and
timing schemes to avoid the built in limitations of 802.11. Looks
like acm.org has some articles.

>Some may consider the question to be off-topic, but the technology would
>be applicable to wireless internet too.

It's more interesting than the usual wireless setup and config
problems.

--
Jeff Liebermann jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558