OnHub: The Killer AP for K-12 Wi-Fi

Let's start by talking about what OnHub, Google's supercharged 802.11ac wireless router (made by TP-Link, actually) can not do.

OnHub does not allow you to create multiple SSIDs.  Creating multiple SSIDs is nice because it allows a guest network to be created.  That way guests don't have to be given the Wi-Fi passphrase for the internal network.  (On the other hand, multiple SSIDs slow down Wi-Fi performance because each SSID has it's own set of Beacon frames.)

OnHub does not allow you to choose your channel.  APs choosing their own channel often limits performance.  The best channel at a user's desk may be different from the best channel nearby the AP.  Usually selecting the best channel at the users' locations makes Wi-Fi work best.  (On the other hand, when the AP selects its own channel that means that the AP has the ability to change channels if a high-powered interference source is detected.)

OnHub does not allow you to adjust AP transmit power.  Setting AP transmit power as close to device transmit power as possible is a great way to improve Wi-Fi consistency and performance.  OnHub doesn't allow for that.  The AP chooses it's own transmit power level.  (On the other hand, many Wi-Fi networks support a variety of devices and, thus, a variety of device transmit power levels.  Letting the AP choose transmit power could work out if the AP chooses wisely.)

OnHub has no Power over Ethernet (PoE) support.  PoE support is essential for mounting APs on ceilings or walls, as is often done in enterprise Wi-Fi deployments.  (On the other hand, OnHub is designed to look sleek so that it can be placed out in the open, near a power outlet.)

OnHub also had an issue when servicing devices that are behind walls.  To test the OnHub's performance, I set it up in the production office of Rough & Tumble Films.  (A friend is a Producer for Rough & Tumble, and he assured me that he didn't mind if people could find his production office's location by using Wigle to search for the "Rough & Tumble" SSID.)  I used Rough & Tumble's office because it has thick concrete walls.  (The building was built by Howard Hughes, who at the time was entering the more, ahem, eccentric phase of his life.)  My friend's desk is in a different room than the Internet modem, thus making performance-though-walls an important factor in choosing a Wi-Fi solution.

I tested the OnHub's performance by running typical office applications on my iPhone 5.  (I always like to use a less-capable device when testing, so the fact that the iPhone 5 supports neither MIMO nor antenna diversity makes it a good choice.)  When I first looked at my protocol analyzer (I used Wireshark because I was too lazy to boot into Windows so that I could run OmniPeek or AirMagnet), I saw good news:

That capture shows two things, one relevant and one irrelevant.  The relevant thing is that the AP was using the maximum available rate of 72.2 Mbps, which is great.  (I know that sounds low for a big, bad 802.11ac AP like the OnHub, but 72.2 Mbps is the maximum data rate available to non-MIMO devices [like my iPhone 5] if you're using 20 MHz wide channels, like you should be in the enterprise.)  The irrelevant thing is that my Wireshark capture was showing an RSSI right around -45 dBm, which would be good if it were relevant.  (Reading RSSI in a protocol analyzer capture [or a spectrum analyzer, for that matter] is IRRELEVANT.  The only RSSI readings that matter come from Discovery software RUNNING ON PRODUCTION DEVICES.  [I know that's a lot of capitalization, but it's an important point that often gets overlooked, even by Wi-Fi professionals.])

"Great," I thought.  "The OnHub is using the highest possible data rate, even when sending data to a device that is behind a thick concrete wall."

But then I thought (as I so often think), "Wait, let's check the Retries."

To find a Retry percentage in Wireshark, you have to go to the Statistics menu and then select Summary.  My statistics summary showed this:

That's 19.69 GB of Wi-Fi traffic sent to my iPhone 5.

Once you view the statistics summary for your device's overall traffic, you then need to add the "and wlan.fc.retry == 1" expression to your Wireshark filter and then go back to the statistics summary.  Here's what that showed me:

That's 2.60 GB of retried Wi-Fi traffic sent to my iPhone 5.

If you divide the 2.60 GB of retried traffic by the 19.69 GB of total traffic, that yields a 13.2% retry percentage.  A 13.2% retry percentage would be acceptable for high density environments or difficult RF environments, but in an ordinary office environment 13.2% is a sign of trouble.  When an event of some kind happens and the office gets crowded, the Wi-Fi will likely fail.

In fairness, OnHub did improve it's walled office performance after a while.  Later in the capture, I saw this:

That's OnHub dropping it's data rates (first to 58.5 Mbps, then to the 52 Mbps that is shown in the screenshot above) in an effort to reduce retries and, thus, improve Wi-Fi consistency.  

It's good to see that OnHub eventually dropped its rates, but the fact that it took a while made me feel that OnHub is currently less than idea for environments with heavy obstructions.

OnHub's uneven data rate choices, along with the aforementioned limitations regarding PoE, transmit power, channel selection and multiple SSIDs, means that it is an inappropriate AP for most enterprise Wi-Fi environments.

There is, however, one Wi-Fi environment where OnHub's positives probably outweigh its negatives: K-12 education.  Many K-12 deployments have a requirement that one AP be installed in each classroom.  (I'm not saying that I necessarily agree with that requirement, but that's a separate discussion for a different blog post.)  If one AP is going to be installed in each classroom, then OnHub could be an elegant solution.  It wouldn't need PoE because every K-12 classroom has an electrical outlet somewhere in the room.  It might not need manual selection of channel and transmit power, because Google purports to be able to change OnHub's channel and transmit power as RF conditions warrant.  And it wouldn't necessarily need multiple SSIDs because most K-12 Wi-Fi can be deployed adequately with teachers, students, administrators and visitors sharing one SSID.

OnHub is so new that it is best to use caution when attempting to draw broad conclusions.  But if I were in charge of a K-12 deployment, I would try it.  A cost of $200 per classroom is a heck of a lot less than most elementary, middle and high schools pay for Wi-Fi.  OnHub's unique antenna array and Google-powered RF control may make it so that good K-12 Wi-Fi can be deployed at that relatively low cost.

***

If you like my blog, you can support it by shopping through my Amazon link.  You can also donate Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU or to my QR code:

Twitter: @Ben_SniffWiFi

ben at sniffwifi dot com