what is "interference robustness"?

I've been trying to track down an explanation of "interference
robustness", which can be chosen as a communication option in several
wifi routers (e.g. Airport). As a result of some small scale digging,
it looks to me like this is some standard microwave communication
protocol, rather than a marketing phrase from, e.g. Apple. Can someone
provide me with or point me to an explanation? Does this involve
bandwidth capping, frequency hopping, or what? Bottom line is, why
would one ever *not* want to choose this option?

On 17 Jul 2004 11:05:50 -0700, (E-Mail Removed) (Doug Lassiter)
wrote:

>I've been trying to track down an explanation of "interference
>robustness", which can be chosen as a communication option in several
>wifi routers (e.g. Airport). As a result of some small scale digging,
>it looks to me like this is some standard microwave communication
>protocol, rather than a marketing phrase from, e.g. Apple. Can someone
>provide me with or point me to an explanation? Does this involve
>bandwidth capping, frequency hopping, or what? Bottom line is, why
>would one ever *not* want to choose this option?

It's marketing speak for techy terms such as jamming immunity, fade
margin, error correction, and science fiction adaptive protocols.
There are also interference susceptability issues with co-channel
users and other services (Bluetooth, WiMax, Frequeny Hoppers, video
extensions, microwave ovens, welders, cordless phones, ad nasuium).
It's difficult to determine out of context which of these are an issue
here. There certainly is no single measureable number for
"interference robustness".

Reading between the line, it looks like some kind of mumbo-jumbo for
forcing the access point to use small packets and short preambles.
Small packets has the statistical advantage of having a greater
probability of delivery as compared to larger packets. If you get a
noise hit in the middle of a large packet, the whole monster packet
will need to be resent. Chop the big packet into smaller pieces and
only the piece that gets hit will need to be resent. Of course,
there's a price. The overhead and inter-packet spaces increase
resulting in lousy thruput. Most access points do this automatically.
I'm rather surprised that Apple has it as a manual control.

Hint: You'll get better answers if you kindly disclose what you're
trying to accomplish and what hardware/software you have available.


--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 AE6KS 831-336-2558

>
> Hint: You'll get better answers if you kindly disclose what you're
> trying to accomplish and what hardware/software you have available.

I appreciate your ideas about this. My question is really an academic
one, and pretty specific. I just think it's kind of peculiar for the
Apple Airport Extreme router (which I have) to offer "Interference
Robustness" as an option when, well, you wouldn't think that anyone
would ever NOT want it. In all the Apple newsgroups I've looked in,
there is essentially no understanding of this checkbox in the Airport
Admin Utility application, except that, yes, it seems to many as if it
offers some immunity against microwave ovens and 2.4GHz phones. So
it's doing something, and while Apple perceives a tradeoff here, they
haven't told us what it is!

My understanding is that there is what is called a MIR (microwave
interference robustness) protocol, but I've never seen it explained,
and I really don't know if that's what is being switched on.

The packet size idea is an interesting one. What disadvantages would
small packet size produce? Others have suggested spread spectrum,
channel switching, bandwidth capping, and even transmitter power
reduction (yeah, sounds odd to me ...). Was just curious if anyone
here just knew the answer.

On 17 Jul 2004 20:34:05 -0700, (E-Mail Removed) (Doug Lassiter)
wrote:

>I just think it's kind of peculiar for the
>Apple Airport Extreme router (which I have) to offer "Interference
>Robustness" as an option when, well, you wouldn't think that anyone
>would ever NOT want it.

See the Orinoco article at:
http://www.orinocowireless.com/suppo...ins/TB-035.pdf
It makes sense because Orinoco (Lucent) designed the Apple Airport.

>In all the Apple newsgroups I've looked in,
>there is essentially no understanding of this checkbox in the Airport
>Admin Utility application, except that, yes, it seems to many as if it
>offers some immunity against microwave ovens and 2.4GHz phones. So
>it's doing something, and while Apple perceives a tradeoff here, they
>haven't told us what it is!

Juggling the packet timing to correspond to the 120Hz microwave oven
blasts is nothing new. The 802.11 protocol timing was designed to
interleave transmissions and adjust packet size to accomidate periodic
(repetative waveform) intereference.

>My understanding is that there is what is called a MIR (microwave
>interference robustness) protocol, but I've never seen it explained,
>and I really don't know if that's what is being switched on.

The Lucent/Orinoco/Avaya/Agere/Proxim/Wavelan article cited above
seems to explain it quite well. The basic idea is to NOT revert back
to slower 1Mbit/sec speeds upon receiving interference because that
will extend the air time per packet, which in turn will increase the
probability that a microwave oven pulse will clobber the packet.
Better to stay at the higher speeds and use very small packets. All
of them will not get through, but a much larger number will pass than
with huge packets or slow data rate.

In effect, you're locking the transmission speed of the access point
and client radios to higher speeds. I consider this a good thing.
However, I don't know if enabling MIR also forces small packets on a
continuous basis. This is a bad idea as it reduces thruput. I can
sniff and check when I get to the office as the neighbors have an
Lucent/Orinoco/whatever access point.

>The packet size idea is an interesting one. What disadvantages would
>small packet size produce?

Crappy thruput. Each packet has a considerable overhead burden.
There's a preamble, CTS/RTS flow control, header information, and
extra space between packets. If you want performance (i.e. speed) you
send big packets. If you want to fight your way through interference,
use small packets.

>Others have suggested spread spectrum,
>channel switching, bandwidth capping, and even transmitter power
>reduction (yeah, sounds odd to me ...). Was just curious if anyone
>here just knew the answer.

I read some of that in various online weblogs and mailing lists. Much
of it was baloney. One person speculated that it reduced receiver
sensitivity. So much for the collective wisdom of the internet.


--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 AE6KS 831-336-2558

>
> See the Orinoco article at:
> http://www.orinocowireless.com/suppo...ins/TB-035.pdf
> It makes sense because Orinoco (Lucent) designed the Apple Airport.
>

Many thanks. That's exactly what I was looking for. Now, it would have
been so simple for Apple to point us to that Orinoco tech bulletin.
Sounds like if you are fighting interference you may not see a speed
drop if you turn on interference robustness (and you might see a speed
increase), but if you aren't fighting it, the packet overhead will
ding your bandwidth. This would argue to use it if you need it, but
not if you don't. Also sounds like the robustness option is aimed
specifically at microwave oven power timing. I can imagine that it
might also help against 2.4GHz phones, but that goes back to the
general idea that "smaller packets get through more often".

> I read some of that in various online weblogs and mailing lists. Much
> of it was baloney. One person speculated that it reduced receiver
> sensitivity. So much for the collective wisdom of the internet.

Yes, the collective wisdom of the internet requires a lot of
selectivity. My red flag for baloney was going up a lot. Much of the
wisdom out there about it is that "interference robustness" is the
protocol that makes your system more robust to interference. Duh.

Again, my thanks for the most cogent explanation I've seen on this.