sniffwifi

Just another WordPress.com site

Archive for the ‘High density WiFi’ Category

What’s New (and Missing) in the WiFi for iPhone 6

with 3 comments

Two years ago tomorrow Apple introduced the iPhone 5.  It was a big deal.  It was a big deal for gadget folks who wanted a bigger iPhone.  It was a big deal for wireless LAN folks who wanted users to use smartphones with speedier WiFi.  

Now the iPhone 6 has been announced and it appears to be more of the same.  Gadgeteers get their bigger iPhone.  Wireless folks get their faster speeds.  Problem is, the faster wireless speeds likely won’t mean anything for high capacity wireless deployments.

The big news about the iPhone 6 is 802.11ac.  Yippee!  Apple has finally adopted the latest and greatest WiFi standard in a mobile device.

802.11ac has data rates as high as 6.9 Gbps in the standard, but wireless LAN folks know that’s not what happens in real life.  Real 802.11ac devices top out at a 1.3 Gbps data rate when multiple input-multiple output (MIMO) antenna systems are supported, while non-MIMO devices top out at 433 Mbps.

The iPhone 6 and iPhone 6 Plus are non-MIMO 802.11ac devices.  That means a top rate of 433 Mbps.  That is higher than the top rate of the 802.11n-supporting iPhone 5 and iPhone 5S, which is 150 Mbps.  And that is where Apple gets the nerve justification for putting this on their site:

You see, 433/150 = almost 3.  That means three times faster wireless!  Except it doesn’t.
802.11ac is basically the same thing as 802.11n.  I know that 433 and 150 seem like very different numbers, but in most real world cases, they’re actually the same.
Here’s how it works:
802.11n = 150 Mbps –>

–> Normal 802.11ac = 150 Mbps –>

–> 802.11ac with clear line of sight and a distance less than 30ft/10m = 200 Mbps –>
(That’s because when you’re that close and there are no obstructions, then 802.11ac can use a technology called 256-QAM, which allows waves to carry 8 bits of data rather than 6 bits.  8/6 = 200/150, so that means that adding 256-QAM boosts the top data rate to 200 Mbps.)
–> 802.11ac with clear line of sight and a distance less than 30ft/10m and 80 MHz channels enabled = 433 Mbps
(80 MHz channels are no good for high capacity WiFi.  Instead of being able to split users up amongst 9 [if disabling dynamic frequency selection {DFS}] or 21 [if enabling DFS] channels, an 80 MHz wireless network only has 2 [non-DFS] or 4 [DFS] channels.  And here in the U.S. of A., our beloved FCC regulatory commission just made it a whole lot harder to use DFS channels because of Item 67 in the 2014 updates to UNII rules.)

Think about the average high-capacity wireless network.  Do the users have a line of sight to the APs?  Usually, No.  Are the users within thirty feet (ten meters) of the APs?  Often, No.  Is it better to spread users out among four or five times as many channels?  Definitely, Yes.  If you agree with these answers, then 802.11ac in the iPhone 6 and iPhone 6 Plus reverts to the 150 Mbps data rates used in the iPhone 5 and iPhone 5S.

A year ago, yours truly wrote that non-MIMO devices were going to be around for a while.  MIMO drains battery life faster and it can cause a device to heat up.  So, the lack of MIMO in the new iPhones is no surprise.  But it is disappointing.  And it comes down to this:

802.11n w/ MIMO > 802.11ac w/o MIMO

The iPad Air, which has been out for about a year now, is a mobile device from Apple that supports MIMO.

In a typical high capacity WiFi environment, the iPad Air or iPad Mini is going to get as high as 300 Mbps in the 5 GHz band or 144 Mbps in the 2.4 GHz band.  The iPhone 6 or iPhone 6 Plus is going to get as high as 150 Mbps in 5 GHz, or 72 Mbps in 2.4 GHz.  That’s big.  It’s big for users of the gadgets and it’s even bigger for the WLAN folks who have to manage those networks.  Apple may have done a solid for people who want to be able to see five Tweets on their screen at a time instead of four, but for wireless folks who have to deal with high capacity networks they didn’t help us out as much as they could have.

***
If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

ben at sniffwifi dot com

Twitter: @Ben_SniffWiFi


Written by sniffwifi

September 17, 2014 at 7:04 pm

Why Are You Slowing Down My WiFi, Apple? To Make Things Better?

with 4 comments

I defend Apple a lot.  When Network World wrongly accused the original iPhone of flooding Duke University’s network, I defended Apple.  (It was later found to be a Cisco problem.)  When a health care provider I was doing some work for blamed SIP-enabled iPhones for a VoIP problem, I eventually found out that the APs were to blame.  (The APs were failing to respond to WiFi frames tagged as “Background” QoS.)  Time and time again networking folks blame device makers like Apple, and time and time again the problem ends up being the network.

There are times, however, when it really is Apple’s fault.  When the network is operating just fine.  This is one of those times.  The problem is that I just don’t know why.

802.11n (HT) and 802.11ac (VHT) networks operate in co-existence with first generation (802.11a/b/g, that is) WiFi a lot.  When that happens, the HT or VHT access point operates in mixed mode.

There are all sorts of ramifications when a WiFi network operates in mixed mode, but one of the bigger ones (a ramification that usually results in a throughput loss between 25% and 40%) is the protection mechanism.  When the the AP operates in mixed mode, it transmits data using the protection mechanism and it uses Beacon and Probe Response frames to tell WiFi devices to use the protection mechanism.  An AP or device using the protection mechanism will precede its data frame transmissions with the transmission of a non-data carrying frame called a request to send (RTS) or a clear to send (CTS).  The RTS and CTS frames are always sent at a data rate that the legacy devices can understand.  For example, a WiFi network with a mix of 802.11a and 802.11ac devices would see 802.11a (24 Mbps, typically) RTS and/or CTS frames sent in advance of data that would be sent using VHT rates (up to 1,300 Mbps with today’s gear).

An important note in all of this is that if there is no mixed mode, then there doesn’t need to be any protection mechanism.  If you’ve got a bunch of HT devices all associated to an HT AP, then there shouldn’t be any RTS or CTS frames slowing down the data.

Rough & Tumble Films (a movie production company whose owners I’m friends with and who have a little country noir called “We Gotta Get Out Of This Place” airing on the Starz network later this year) has a WiFi network with an HT AP and all HT (or VHT) devices.  (See the Probe Request frame below showing the “R&T” network indicating that all devices are HT-capable.)

The R&T WiFi network should see HT data frames going across the WiFi channel without any RTS and/or CTS frames slowing it down.  That is not, however, what shows up in my WildPackets OmniPeek capture.  (See that the highlighted data frames below are sent at HT rates of 243 Mbps and 300 Mbps, but they are surrounded by RTS and CTS frames sent at 24 Mbps.)

What gives, I wondered?  Are the Probe Response frames coming from the AP giving me bad information?  Are devices acting up?  My initial capture was done on data going to and from my laptop (MacBook Air using dual-band, two-stream 802.11n), so I wanted to add my phone to the network to see if anything was different.

When I added my phone (iPhone 5 using dual-band, single-stream 802.11n), the same behavior occurred.  More 24 Mbps RTS and CTS frames were surrounding my HT (this time 135 Mbps or 150 Mbps) data.

I noticed a trend when investigating all of this protection mechanism traffic on my friends’ non-mixed mode WiFi.  I noticed that the RTS frames were only being sent by my devices.  The APs were never sending an RTS frame.  Beyond that, I noticed that when the AP was the transmitter of a data frame, neither an RTS or a CTS preceded that data frame.  In short, I noticed that the AP was not using the protection mechanism, which my laptop and phone were.

I know, then, that Apple devices (both iOS and OS X) slow down the channels they are using by acting like it’s mixed mode even when it’s not.  What I don’t know is, Why?  Did Apple make a mistake?  Is there some HT or VHT protocol that I am unaware of that causes devices to use the protection mechanism even when APs don’t?  Or is Apple doing this on purpose because someone at Apple thinks that their devices function better when the protection mechanism is always on?

After seeing Apple devices voluntarily engage in the protection mechanism, it made me think back to a question that I received while doing a Reddit AMA last year.  A person asked about RTS/CTS being used to manage network traffic and getting devices to cooperate.  The person from Reddit mentioned that he (sorry ladies, but when his Reddit handle is “ShadowHawk109” and he posts about beer, WiFi and William Shatner, it’s got to be a guy) did work in academia, so I just assumed that he didn’t know what he was talking about.  Maybe he was on to something.  Maybe Apple believes that their devices will have a more consistent data connection over WiFi if RTS/CTS frames are being used all the time, and so they’ve enabled it in their devices.  Maybe Apple doesn’t care that much if their devices cause the maximum available throughput to be lower on the channel.

Whatever the reason may be that Apple devices have been programmed to use RTS/CTS frames, WiFi professionals are going to have to deal with the impact.  It could mean that our throughput tests mean even less and that our ability to support high density deployments has been expanded.

***
If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

Written by sniffwifi

May 30, 2014 at 12:00 am