any recent research in wireless ATM?

I'm a systems engineer involved in the design of unmanned vehicles and I
am soooo frustrated 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.

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. 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. 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.

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.

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

Thanks

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

On Sun, 03 Dec 2006 22:30:14 -0800, Jeff Liebermann wrote:

> 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?

latency...lots of packet loss...queuing up of commands because of a
wireless retry bottleneck...ethernets lack of QOS causes problems when a
single pipe is transmitting audio video and command and control signals
bidirectionally.


>
>>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.

Bingo! the unlicensed bands are 'garbage bands'. What more can be said
on that point?

> 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.

Understood...been doing that and it is the only thing that helps...but
still only marginally.

> 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.

Been thru this point many times. Goes back to the engineering triangle:
cheap, quick, to spec...pick any two.

>>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>

thanks...I'll look at the reference.


>>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.

been doing that already.


>>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.

I don't consider yours and mine comments above to be mutually exclusive.
From my perspective it goes back to the unreliable shared medium problem.
smaller packets get thru more easily. what I find unacceptable is the
ACK/NAK retries issue in 802.11.



> 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.

point taken...just investigating alternatives at this point. 802.11 is
not designed for bursty low-latency transmission where QOS is important.

> 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?

yes...this is a known problem...the customer wants reliable non-line-of-
sight at distances that are at the outer edge of the ranges and rates
advertised to the less than knowledgeable public. packet drop is not a
problem...what is a problem is that run of the mill 802.11 devices don't
let the end user fine tune retry or rate negotiation strategies.

and dropping the MTU size is problematic in my current architecture
because some of our 802.11 bridge hardware doesn't comply with the RFC
regarding MTU negotiation. The vendor states that as a pure ethernet
bridge they don't have to. I see their point but it still pisses me off.

tanks

noone@all.com hath wroth:

>> Why? What problems are you seeing with 802.11?

>latency.

Duz ping look like this?

fping 192.168.1.50 -c
Fast pinger version 2.16
(c) Wouter Dhondt (http://www.kwakkelflap.com)
Pinging 192.168.1.50 with 32 bytes of data every 1000 ms:
Reply[1] from 192.168.1.50: bytes=32 time=70.7 ms TTL=127
Reply[2] from 192.168.1.50: bytes=32 time=2.4 ms TTL=127
Reply[3] from 192.168.1.50: bytes=32 time=18.1 ms TTL=127
Reply[4] from 192.168.1.50: bytes=32 time=28.2 ms TTL=127
Reply[5] from 192.168.1.50: bytes=32 time=2.4 ms TTL=127
Reply[6] from 192.168.1.50: bytes=32 time=2.4 ms TTL=127
Reply[7] from 192.168.1.50: bytes=32 time=2.4 ms TTL=127
Reply[8] from 192.168.1.50: bytes=32 time=2.3 ms TTL=127

If so, you have interference problems, probably from other 802.11
devices on your own system. You can learn quite a bit about
interference from watching pings go by. Also see list of probable
sources of junk at:
<http://wireless.wikia.com/wiki/Wi-Fi#Interference>

>..lots of packet loss...

Packet loss at the IP level (using netstat) is indicative of a serious
problems. The wireless link will attempt retransmissions at the MAC
level which will not be visible on the IP level unless the number of
retransmissions exceeds a reasonable number of retries. This varies
with speeds, but is usually 3 or 4 retransmissions. If you're seeing
IP packet loss, there's something seriously broken.

>queuing up of commands because of a
>wireless retry bottleneck...

Sure. That's the inevitable result of packet loss, which is the
inevitable result of interference, multipath, or bad system planning.

>ethernets lack of QOS causes problems when a
>single pipe is transmitting audio video and command and control signals
>bidirectionally.

You can't fix packet loss with QoS. The best you can do is prioritize
packets and hope the time critical packets make it through. If you're
running real time video (30 frames per second) through a wireless
pipe, depending on compression type (MPEG4?) and picture size, you're
probably exceeding the channel bandwidth. If you're trying to do
video with TCP instead of UDP, you're probably filling the pipe with
retransmissions. These increase exponentially with ethernet after a
specific threshold (about 70% of full bandwidth). Give me some
numbers and I'll tell you where you've gone wrong. Ever consider
using a different channel or system for video and command/control?

>Bingo! the unlicensed bands are 'garbage bands'. What more can be said
>on that point?

Nope. You get what you didn't pay for. However, it's usually nowhere
near as bad as what you seem to be experiencing. Something else is
wrong.

>> If you want a clear channel, buy one from the FCC or one of auction
>> winners.
>
>Been thru this point many times. Goes back to the engineering triangle:
>cheap, quick, to spec...pick any two.

I've solved more problems by re-writing the specs than by engineering.
Back when I was burning myself with a soldering iron on a daily basis,
I was forced to actually make things work. These days, it's so much
easier to just question the specs and requirements. It's often
amazingly useful to negotiate performance specs to realistic levels.

>I don't consider yours and mine comments above to be mutually exclusive.
>From my perspective it goes back to the unreliable shared medium problem.
>smaller packets get thru more easily. what I find unacceptable is the
>ACK/NAK retries issue in 802.11.

Take a step backwards and consider what 802.11 is really doing. It's
encapsulating 802.3 ethernet packets. Ethernet has its own collision
detection and recovery mechanism, which is probably causing your
current problems. Suggestion.... unplug the 802.11 and just run it on
ethernet at 10baseT HDX (half duplex). That should be fairly close to
typical wireless performance but without the timing issues of
wireless. If that does not work (and I predict that it won't), then
you have fundamental system design problems that have nothing to do
with wireless.

>point taken...just investigating alternatives at this point. 802.11 is
>not designed for bursty low-latency transmission where QOS is important.

Actually, it is but not continuously. It's your video that's probably
causing the constipation and retransmissions. 802.11 was not designed
for streaming media and does it very badly. Hint: Got any NTSC UHF
TV xmitters handy?

>yes...this is a known problem...the customer wants reliable non-line-of-
>sight at distances that are at the outer edge of the ranges and rates
>advertised to the less than knowledgeable public.

In my never humble opinion, NLOS is pure hype and baloney. Even those
that have claimed Non-Line of Sight features are now changing the
acronym to Near Line of Sight to cover their posteriors. You can get
NLOS to work, but you can't make it reliable. It will work one day
and fail the next. It's incredibly sensitive to changeing
environmental conditions and always demonstrates lousy link
reliability.

>packet drop is not a
>problem...what is a problem is that run of the mill 802.11 devices don't
>let the end user fine tune retry or rate negotiation strategies.

Wrong. You can use one of the Linux based alternative firmware
implimentation and tweak the hell out of just about everything. With
the proper NDA and license, you can get source to the MAC layer and
really make a big mess. Don't think it's not being done. MERU
Networks got caught by Cisco tweaking holdoff timing values to make
their products look better when dealing with 802.11 interference.
<http://www.networkcomputing.com/channels/wireless/showArticle.jhtml?articleID=194400865>

>and dropping the MTU size is problematic in my current architecture
>because some of our 802.11 bridge hardware doesn't comply with the RFC
>regarding MTU negotiation.

MTU negotiates the MAXIMUM packet size, not the minimum. If you
fragment the hell out of the 802.3 ethernet packets, 802.11 will just
package them into a 1500 byte encapsulated packet. Of course, you can
shrink that with the fragmentation threshold. The do not fragment
flag only applys to larger packets, not smaller. If you force
everything to smaller packets, the MTU negotiation does nothing.

>The vendor states that as a pure ethernet
>bridge they don't have to. I see their point but it still pisses me off.

I agree with the vendor.

>tanks

I think you have a major system design problem here with all the worst
case conditions. My guess(tm) is you have a high bandwidth video
requirement, a real time response requirement, an uncontrolled and RF
polluted environment, and an unreasonable NLOS requirement. Take the
wireless out of the puzzle and see if it still works. If you're
lucky, and it does, find a data imparement tester to simulate the crap
you'll see with any wireless system. I use Dummynet:
http://info.iet.unipi.it/~luigi/ip_dummynet/
If the system works without wireless, then lets talk about what
wireless system is appropriate. I don't think it can be done with a
single radio system.

--
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

<noone@all.com> wrote in message
news:pan.2006.12.04.17.32.32.973984@all.com...
> On Sun, 03 Dec 2006 22:30:14 -0800, Jeff Liebermann wrote:
>
> > 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?
>
> latency...lots of packet loss...queuing up of commands because of a
> wireless retry bottleneck...ethernets lack of QOS causes problems when a
> single pipe is transmitting audio video and command and control signals
> bidirectionally.
>
why not run 2 links?

put the video on a separate links - no extra traffic on the control loop
means minimal delay thru queues

if cross interference is an issue then run 1 channel 802.11g and 1 on
802.11a

if it helps - cisco and others make dual channel access points, and dual
channel interface modules.
http://www.cisco.com/en/US/products/...ers_guide.html

The cisco stuff supports multiple logical networks separated by VLAN / SSID,
so you should be able to separate the channels - if not 2 sets of kit....
>
> >
> >>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.
>
> Bingo! the unlicensed bands are 'garbage bands'. What more can be said
> on that point?
>
> > 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.
>
> Understood...been doing that and it is the only thing that helps...but
> still only marginally.
>
> > 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.
>
> Been thru this point many times. Goes back to the engineering triangle:
> cheap, quick, to spec...pick any two.
>
> >>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>
>
> thanks...I'll look at the reference.
>
>
> >>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.
>
> been doing that already.
>
>
> >>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.
>
> I don't consider yours and mine comments above to be mutually exclusive.
> From my perspective it goes back to the unreliable shared medium problem.
> smaller packets get thru more easily. what I find unacceptable is the
> ACK/NAK retries issue in 802.11.
>
>
>
> > 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.
>
> point taken...just investigating alternatives at this point. 802.11 is
> not designed for bursty low-latency transmission where QOS is important.

since they support their WLAN phones, the Cisco stuff also does some QoS
bits that may help

deployment guide for the WLAN phone:
http://www.cisco.com/en/US/products/...0802a029a.html

these work pretty well - i have seen an office with a couple of APs, 15 to
20 phones and 20 PCs on wireless all running happily (and this was a
recruitment company, so the users would have been unforgiving of voice
problems). OTOH i am not sure how much the QoS helps....

>
> > 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?
>
> yes...this is a known problem...the customer wants reliable non-line-of-
> sight at distances that are at the outer edge of the ranges and rates
> advertised to the less than knowledgeable public. packet drop is not a
> problem...what is a problem is that run of the mill 802.11 devices don't
> let the end user fine tune retry or rate negotiation strategies.
>
> and dropping the MTU size is problematic in my current architecture
> because some of our 802.11 bridge hardware doesn't comply with the RFC
> regarding MTU negotiation. The vendor states that as a pure ethernet
> bridge they don't have to. I see their point but it still pisses me off.
>
> tanks
>
--
Regards

stephen_hope@xyzworld.com - replace xyz with ntl

Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> hath wroth:

>MTU negotiates the MAXIMUM packet size, not the minimum. If you
>fragment the hell out of the 802.3 ethernet packets, 802.11 will just
>package them into a 1500 byte encapsulated packet.

Oops. Maximum packet size for 802.11 is 4096 bytes. 1500 bytes is
maximum for 802.3 ethernet.

--
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