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

Reply to
noone
Loading thread data ...

noone hath wroth:

Why? What problems are you seeing with 802.11?

Latency? I get Can anyone shed some light on whether wireless ATM is an active research

Sorry, I can't help much. I don't do much research. Try searching with:

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.

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

Reply to
Jeff Liebermann

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.

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

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

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

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

been doing that already.

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.

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

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

Reply to
noone

snipped-for-privacy@all.com hath wroth:

Duz ping look like this?

fping 192.168.1.50 -c Fast pinger version 2.16 (c) Wouter Dhondt

formatting link
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:

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.

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

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?

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.

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.

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.

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?

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.

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.

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.

I agree with the vendor.

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:

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

Reply to
Jeff Liebermann

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.

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

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

deployment guide for the WLAN phone:

formatting link
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....
Reply to
stephen

Jeff Liebermann hath wroth:

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

Reply to
Jeff Liebermann

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.