Friday, 26 February 2016

802.3af Is Dead (For Surveys)

I’ve recently been involved with a project that has brought me into contact with a number of wireless engineers who are performing WLAN survey work using the traditional “AP on a stick” (APOAS) survey method. Yes, there are plenty of people out there who still prefer this method, or have customers who demand it.


One thing that has become apparent is that a number of people are still using power sources (generally a battery pack) for their survey AP that still only supports the 802.3af POE (power over Ethernet) standard.


The time has come for those using these legacy power supplies to make an investment and  upgrade their AP power packs to support the higher power provided by the 802.3at standard. The next generation of wireless access points simply won’t allow the continued use of 802.3af power packs, due to the enhanced power requirements of modern APs.


Background


Until relatively recently, many Enterprise grade wireless access points have been able to work with the power budget imposed by the 802.3af POE standard. This means that they are able to work with a power draw of 15.4W or less.


This was sufficient for many APs until the advent of the next generation 802.11ac (“Gigabit Wireless”), back in late 2013. Even after the emergence of this first "wave" of 802.11ac APs, some models could just about fit within the 15.4W power budget of 802.3af POE, or at least run with a reduced feature set that would allow it to be used for a basic RF passive survey.


Example of the types of power pack previously used included the Terrawave battery pack and the Pointsource POE Injector. Whilst these were a reasonable choice as an 802.3af power source, they simply can’t provide the power requirements of newer wireless APs.


802.11ac Wave 2


With the emergence of the “latest and greatest” 802.11ac “Wave 2” access points, the lowly 802.3af POE supply can no longer be used for APOAS surveying.


The additional power requirements of “Wave 2” APs means that a 802.3at power pack must now be available for survey work. This new generation of APs have additional features such as MU-MIMO (multi-user MIMO) and additional radio chains that mean that the legacy 802.3af (15W) power budget simply isn’t enough.

(Note: You may also see 802.3at referred to as "POE+" in some documents)


So, the time has come to put our old, trusty 802.3af power packs out to pasture and ensure we have a power supply that can support 802.3at, and is able to meet the higher power budgets of this next generation of APs.


Power packs that support the 802.3at standard will be able to supply a power draw in excess of 25W, providing a significant increase from the previous 15.4W that we could achieve with 802.3af.


Suggested Power Packs
A quick “Google” around the Internet doesn’t yield any useful results when trying to find a 802.3at POE battery pack - well none that I have found so far with my great sausage fingers…. (update: see end of this article for some suggestions)


A great solution is a home-brew solution that is the subject of a great blog article by Scott Stapleton. It details how to create a 802.3at power pack using a lithium battery pack and POE DC-DC converter. I suggest you get along to his article to find out how to build your own 802.3at power supply. It’s very straightforward to build and turns out to be smaller, lighter and has a higher capacity than the previous lead-acid battery based solutions.


If anyone has any other suggestions for any “off the shelf” 802.3at POE power pack solutions suitable for surveying, please include them in the comments section of this article.


My Power Pack
Here are some pictures of my current AP power pack, based on Scott’s great article, so you can get an idea of what a build-your-own solution might look like. Admittedly, mine looks a little “home made”, but it does the job and lasts many hours on-site - you can get a full day out of a pack like this, depending on the battery you buy, AP power settings etc.


Battery_Pack1.jpg
Fig 1 - Yes, I have to label everything


Fig 2 - A side-on view so that you can appreciate the full beauty of this work of art

(Note: the cut-off RJ45 lug is to stop me plugging the AP into the non-POE port, which causes me to swear under my breath)


I’m sure there are plenty of you out there that could come up with something far more aesthetically pleasing (and that looks less like a bomb…)


References


Get along to Scott’s blog article for full details of how to build your own 802.3at survey power pack.


My components:
  • Battery: Aukey 28000mAH External Battery Pack (UK Amazon link)
  • Converter: Tycon Power 24v-48V DC To DC Gigabit POE (UK Supplier Link)
  • Lots of gaffer tape


References


Here are some off the shelf survey batteries you might also like to take a look at:


Tuesday, 9 February 2016

How Fast Is My Wi-Fi Client?

In the Wi-Fi For Beginners podcast, I've spent a lot of time talking about WLAN clients. Understanding their characteristics, capabilities and behavior is crucial when designing and deploying a wireless LAN. Without understanding the clients on your network, you will not be able to anticipate their demands on your WLAN infrastructure and the level of performance that you will be able to realistically be able to provide to end users.

The discussion about WLAN clients is fairly extensive and spans a number of episodes as this is such an important topic. In the podcast I highlight the importance of understanding the capabilities of the clients that connect to a WLAN. Just because you buy yourself a nice new shiny smartphone that (you hope) supports 802.11ac, doesn't mean you are going to get 1.3Gbps of throughput when you hook it up to your Wi-Fi network. Unless you understand its capabilities in terms of 802.11 amendment support, number of streams available etc., then you can never anticipate its demands on your WLAN and the level of throughput you might reasonably expect to achieve with that device. 

However, you may be wondering how you actually find out about a clients' capabilities. In this article we take a quick look at a number of methods to determine the capabilities of devices that you may be using (or plan to use) on your WLAN.

As a an example to demonstrate the process, I took an Apple iPhone 5c and put on my detective hat to try to find out the capabilities of the phone from a Wi-Fi networking perspective. With this information, I will be able to anticipate the maximum speed I could realistically expect to achieve on a Wi-Fi network. 

MCS Rates
There's one piece of additional information we need before we start on our investigation: a suitable MCS table to cross reference our results. MCS tables are used to provide information about possible connection speeds for 802.11n and 802.11ac devices. You can find the relevant information here:


Once we discover the 802.11 amendment, number of spatial streams and channel width our device supports, we can use the MCS tables to lookup the available connection speeds for each  stream/width combination.

The table for 802.11n shows all possible MCS combinations that are available for all combinations of stream count and channel width.

The table for 802.11ac MCS table shows the available connection speeds for a variety of channel widths, but only for a single spatial stream. To determine the connection speed for a multi-stream device, simply multiply the data rate value for a single stream by the number of streams the device supports.

Two important caveats:
  • the capabilities of your client device must be matched by your WLAN access points - if your access point doesn't have equivalent (or better) capabilities, then you will be limited by the speed capabilities of the access point (e.g. an 802.11ac client device is never going to give you gigabit Wi-Fi if your AP only supports 802.11a)
  • Although we may determine the maximum connection speed of a client device using the methods outlined in this article, please remember that this is the RF connection speed of the device, NOT the data throughput of the device. The actual device throughout is likely to be closer to 50% of the RF connection speed that we discover, due to the half duplex nature of Wi-Fi connections and various other overheads inherent in the WLAN protocol.

Manufacturers Documentation
The most obvious place to start when trying to understand the capabilities of a client device is the vendor documentation or web site of the client that we're investigating.

Unfortunately, the information provided by many support pages is lacking in any real technical real detail. Sure, you may get information about the WLAN bands supported and the headline 802.11 amendment information, but there is generally little low-level detail for items such as channel width support, guard interval support and number of streams. 

Here is the information I was able to find on the Apple support pages for the iPhone 5c:


We can see from the support information that the 5c operates on the 2.4GHz and 5GHz bands. It also supports all 802.11 PHY amendments up to 802.11n. But, without knowing its channel width support and the number of streams it can support, we have no understanding of the maximum connection speed we might achieve with this device on our WLAN.

Although this is useful information, it provides only part of the answer we are seeking.

Wi-Fi Alliance (WFA) Product Finder
A great place to find detailed information about wireless LAN clients is the Wi-Fi Alliance Product Finder. (https://www.wi-fi.org/product-finder)

As many WLAN products are certified to verify their interoperability with various 802.11 amendments, WFA interoperability certificates are a great source of data about WLAN clients.

The Product Finder tool allows you to enter details about the device you'd like to know more about, and will (hopefully) allow you to find the WFA certificate for the device you're investigating.

For our investigation I hit the jackpot for the iPhone 5c by looking at its WFA certificate. I've shown a couple of screen grabs of the type of information you can find on the WFA certificates, highlighting the pertinent information:



Although the first part of the certificate shows us very similar information to the support page from Apple, the second page shows us the number of spatial streams the 5c supports, channel width support and guard interval support.

The 'guard interval' gives a small, but useful, bump in performance if we have short guard interval support. It's nice to have, but to keep things simple, we'll focus mainly on channel width and spatial stream capabilities in this article.

We'll have a look at the end of this article at how we determine our maximum connection speed from the information shown above.

FCC Web Site
Unfortunately, not all devices go through the WFA certification process so may not appear on the WFA product finder. There may also be a time-delay between devices being released and obtaining their WFA certification.

Another alternative is to take a look through the FCC ID database (https://fccid.io/).

Each wireless device that is used in the USA must be tested to ensure that it meets various RF-related requirements before it can be used. The testing that is conducted by the FCC on each type of device is recorded and made available as s series of documents on a searchable database. To find the test documentation, you need the FCC ID off the device. In the case of the iPhone 5c, I simply read it off the rear of the iPhone's case: BCG-E2694B 

I then typed the ID in to the FCC search form:


When the search results are returned, the number of results can be a little overwhelming, There are a whole series of documents that cover different aspects of the device's operation and testing. To find documents that will most likely be of interest, look for documents that are  in the 'Available Exhibits' section and are listed as 'Type': 'Test Report'.

Looking through these documents can take some detective work and is certainly not as easy as the WFA product finer. There are test documents for different RF bands and technologies, so finding what you need takes a little digging. However, there is also some very interesting information buried in there about how the devices are tested and other aspects of the devices performance which are fascinating. 

As an example of what I turned up in a very short space of time, here is a table I found in a test document for the 5GHz band. It shows me that the on 5GHz band we support the 802.11n amendment, 20 & 40 MHz channels and that there is single spatial stream support (SISO = single inout, single output). You can see the document yourself here: https://fccid.io/document.php?id=2841731



With a bit more time spent digging around I could also find the 2.4GHz information and various other aspects of device support if I need them. I'll leave this as an exercise for you, the reader, to complete :)

(Side-note: have a look through the FCC documents - there is some fascinating information in there)

As the testing is completed by the FCC, it obviously relates to operation within the USA. However, many aspects of a devices capabilities will apply across the globe. One area that will be significantly different from country to country is the channels used on the WLAN RF bands (i.e. the same channels may not be available for use or be subject to the same power restrictions) - remember this when reviewing the FCC report data.

(Tip: Check out this page for Apple devices, which has direct links to FCC documentation)

Controller or Management System Information
Another potentially useful source of client capability information is the wireless LAN controller(s) or management system that runs your WLAN network.

Many systems will provide good information about clients that are associated with your network. If you can attach the client to your network the you may be able to inspect its properties to understand its capabilities. The type and quality of information will vary form system to system. Again, some detective work my be required to find the information you are seeking, but it's likely to be buried somewhere on the system GUI or in some CLI output.

As an example, I associated the iPhone 5C with a test SSID on a Merkai AP I have in my lab. I took a look a the client information that was available for the iPhone from the Meraki cloud management GUI. You can see the partial output in the screen grab below (pertinent information is highlighted):


The Meraki dashboard does a good job of showing us that we have 802.11n support on the 2.4GHz & 5GHz bands. It also shows that we have 40MHz channel width support and that the client supports one spatial stream.  It also shows us that the maximum connection speed is 150Mbps, which is what we could expect when using a single stream device with a 40MHz channel width. The only area that this falls down is that it is unlikely that the iPhone supports 40MHz channel widths on the 2.4GHz band (which could be inferred from the information shown).  

Wireless Packet Capture
Another way to understand the capabilities of a client device is to capture a few frames from the device and to look at some of the fields in an Association Request frame that is sent from the client to an access point. This method is quite tricky to complete in terms of both technical complexity and interpretation (but is more fun for most geeks).

To capture the required frames, you need a wireless NIC that can operate in monitor mode to capture all frames heard over the air on a partticular channel. Getting hold of a suitable NIC and drivers can be very challenging. If you have a commercial product such as Omnipeek or AirMagnet Analyzer, then this is a trivial task as they are built to perform this type of capture. However, it you don't have access to these tools, then you can use a MacBook with its native NIC and Wireshark, or on Windows you might like to try a trial version of the Acrylic wireless analyzer. There is no doubt support wireless capture in various Linux flavours, but you'll have to rely on Google for help with that :) 

(Side note: Windows support for wireless NICs that can be put in to monitor mode is very rare, making wireless captures very difficult on Windows for free tools such as Wireshark).

You can generally capture an association request by connecting the iPhone to the target SSID while having your analyzer configured to capture frames on the target SSID (AP) channel. Then, you can filter out the Association request frames with the Wireshark filter 'wlan.fc.type_subtype == 0x0.

A sample frame is shown below for my iPhone 5C on the 5GHz band (remember capabilities may vary between bands):

Understanding the frame and interpreting its content requires some background knowledge of WLAN frame analysis, but is very interesting if you're a real geek :) (and its' a GREAT way to learn more about WLAN technology - if you want to know more, get hold of a copy of the CWNP CWAP certification book - new version coming out first quarter 2016).

Looking at the example above, as we have HT capabilities, then  by implication, this is an 802.11n device. In the HT capabilities fields, we have indications that 40MHz operation is supported and that the device uses a single spatial stream. The eagle-eyed among you may also spot that Short Guard interval is also supported (HT Short GI for 20MHz: Supported).

From the frames, we can deduce the same information that we saw in the WFA certificate. It's harder to find this way, but a lot more fun :)

Google
The last port of call, I guess, is to Google for the information. In my experience, this won't usually turn up much beyond the usual marketing data sheets, or vendor support page. But, give it a try of all else fails :) 

Converting Your Data In To Maximum Connection Speeds
Once you've obtained the required data from your Internet sleuthing, it's time to run the data through the MCS rates table we spoke about earlier, to determine our theoretical maximum connection speed.

We determined that our capabilities on 5GHz were: single stream, 40MHz channel and short guard interval support. If we take a look at the 802.11n MCS table we come up with the following when determining our maximum connection rate:

Note that this is an extract from the table - there are also values for 2, 3 and 4 spatial streams in the full MCS rates table. We can see that the maximum connection speed we can achieve with our 802.11n device supporting a single spatial stream, a 40MHz channel and the short guard interval is 150mbps. Remember, this is the RF connection speed of the client to the access point NOT ,the throughput speed of the client (which is likely to be closer to 50% of the RF connection speed)

You may be wondering a few things when looking at this table:

  • What are all those other values below 150bmps? These are other data rates available for use by various combinations of modulation type, channel width and guard interval. Although we have determined the maximum connection speed, as your client physically moves around and factors such as signal level and error rates vary, the rate used may drop to suit the conditions that a client experiences. Remember, we have determined the theoretical maximum rate a client can achieved, not its guaranteed data rate on your WLAN.
  • What about old clients that only support 802.11b, 802.11g, or 802.11a? MCS rates only apply to 802.11n & 802.11ac clients. The maximum for 802.11b clients is 11mbps and 802.11a & 802.11g have a 54mbps maximum connection speed.
  • What are those 800ns GI and 400 ns GI figures? 800ns is the long guard interval, 400ns is the short guard interval.

Hopefully you'll now have enough information to know how to find the maximum connection speed for most devices that you'll hook up to your wireless LAN. Don't forget that for 802.11ac devices you need to check out the rates in the 802.11ac MCS table and multiply the rate for your device by the number of streams that it supports. Also remember that the physical rate you derive using the information above is not the throughput rate of the device (you need to assume around 50% of the physical rate). Finally. remember that the rate we have looked at in this article is the maximum rate - the actual rate your client will achieve will vary with the RF conditions it experiences in your environment.

If you've found this article useful, you might like to check out my Wi-Fi For Beginners Podcast.


Feedback
When I post a new blog entry, I often get some great nuggets of useful feedback. I'll post any useful items here:
  • Excellent reference for Apple device Wi-Fi capabilites from Henry Stukenborg on apple web site: http://help.apple.com/deployment/ios/#/ior65f75e248
  • Great site for Apple device FCC docs (thanks for the tip Scott McDermott): https://www.theiphonewiki.com/wiki/Models