Showing posts with label fcc. Show all posts
Showing posts with label fcc. Show all posts

Wednesday, March 20, 2013

802.11ac Channel Planning

The forthcoming 802.11ac Gigabit Wi-Fi amendment will bring with it support for larger channels at 80 MHz and 160 MHz widths. This is one of the primary drivers behind the increased peak performance and bandwidth of wireless APs and clients. Therefore, careful consideration of channel widths allowed on APs and the channel plan for WLAN deployments must be made prior to an enterprise deployment.

Channel Numbering
First, let's tackle how channels are numbered and referenced in 802.11ac. The standard method to denote 5 GHz channels has been to always use the 20 MHz center channel frequencies for both 20 MHz and 40 MHz wide channels. Starting with 802.11n, 40 MHz channels were referenced as the primary 20 MHz channel plus an extension channel either above or below the primary channel. An example would be a 40 MHz channel consisting of channel 36 (primary) + 40 (extension above).

802.11ac changes how we reference larger channel widths. Instead of continuing to reference the 20 MHz extension channel(s), we will now reference the center channel frequency for the entire 20, 40, 80 or 160 MHz wide channel.

The valid channel numbers for various channel widths are:

Channel Width Valid Channel Numbers
20 MHz 36, 40, 44, 48, 52, 56, 60, 64, 100, 104, 108, 112, 116,
120, 124, 128, 132, 136, 140, 144, 149, 153, 161, 165, 169
40 MHz 38, 46, 54, 62, 102, 110, 118, 126, 134, 142, 151, 159
80 MHz 42, 58, 106, 122, 138, 155
160 MHz 50, 114

This results in channel numbers that may look unfamiliar to most WLAN administrators. Simply remember that channel numbers increment by one for every 5 MHz increase in frequency. This will probably be easier to reference through a graphic for most people. In the graphic below, identify the center of each 80 MHz and 160 MHz channel block, follow it up to the 20 MHz IEEE channel numbers, then split the difference between the two 20 MHz channel numbers that it falls between. For example, the 80 MHz channel block in UNII-1 is centered between channels 40 and 44; splitting the difference gives us channel 42.

5 GHz Channels, with DFS and TDWR Restrictions
Non-Overlapping Channels
As I previously detailed in my post on the impact of 802.11ac on enterprise networks, these wide channel widths may not be realistic to use in an enterprise environment where multiple access points are deployed on non-overlapping channels and co-channel interference must be minimized. To recap:
  • 80 MHz wide channels allow for five (5) non-overlapping channels in the U.S. and five (5) in the UK/EU (channels 149 and higher require light licensing for outdoor use only) when DFS is used, but only two (2) channels in the U.S. and one (1) in UK/EU without DFS.
  • 160 MHz wide channels allow for one (1) non-overlapping channel in the U.S. and two (2) in the UK/EU, with DFS being mandatory for their use in all circumstances.
Note - In the U.S. channels 120-128 are prohibited due to TDWR restrictions, and in the UK/EU channels in Band C (equivalent to UNII-3) require "light" licensing an are restricted to outdoor use.

I'm purposely going to skip the 160 MHz wide channels that are possible using 80+80 MHz discontiguous channels for simplicity at this point.

It's clear that 80 MHz channels will be hard to implement in an enterprise setting that requires high capacity due to issues with channel re-use and minimizing co-channel interference. Even when DFS is used, only 4 or 5 non-overlapping channels will be available. And forget about using 160 MHz channels in the enterprise... leave those for home use where only one AP will be deployed (and hopefully you're neighbors don't live too close to cause interference)!

However, it's not quite as dire a situation as that. There is a saving grace that will allow enterprises to take advantage of these wider channels on a "best-effort" basis. Let's step back for a moment - with 802.11n, 40 MHz channels were an all-or-nothing proposition. The APs channel width was statically set at 20 or 40 MHz.  On the other hand, 802.11ac allows per-frame channel width and bandwidth signaling. Practically, this means that WLAN administrators can allow the use of wider channels by APs and clients when all of the constituent smaller channels are clear. If a portion of the large channel is busy at the point in time when a frame needs to be transmitted, for instance a neighboring AP or WLAN is actively using a 20 or 40 MHz portion, then the AP or client can simply back down and use the primary 20 or 40 MHz portion of the larger channel that is clear. For the next frame transmission, if the entire 80/160 MHz channel is clear then the AP or client can ramp back up and use the full channel width.

Critical to this dynamic per-frame channel width procedure is the notion of the primary and secondary channels. The WLAN administrator must designate which 20 MHz segment within a 40, 80, or 160 MHz wide channel is the primary 20 MHz channel. This channel forms the core frequency segment that the BSS (basic service set) or AP radio operates on. Based on the channel blocks depicted in the table above, the BSS will then automatically designate the primary 40 MHz and primary 80 MHz channels by extending the primary 20 MHz channel (moving downward through the table). Only the 40 MHz and 80 MHz channels pictured in the table are allowed. For example primary 20 MHz channel 56 can only be expanded into 40 MHz channel 54 (combining channel 56 and 52); combination with channel 60 is not allowed. For easy reference, just use the channels as depicted :)

802.11ac Primary and Secondary Channels
(Image from 802.11ac: A Survival Guide)

For example, consider a 160 MHz channel in UNII-1 / UNII-2 where the WLAN admin has selected channel 60 as the primary 20 MHz channel. The primary 40 MHz channel will be 62, and the primary 80 MHz channel will be 58. If any portion of the secondary 80 MHz channel (ch42) is busy then the frame can use the primary 80 MHz channel (ch58). If any portion of the secondary 40 MHz channel (ch54) is busy then the frame can use the primary 40 MHz channel (ch62). And if any portion of the secondary 20 MHz channel (ch64) is busy then the frame can use the primary 20 MHz channel (ch60). This allows an AP or client to dynamically fallback to narrower channel widths in the presence of co-channel interference or noise that only affects a portion of the larger channel.

This has some interesting implications for channel planning!

Developing a Channel Plan
Since eliminating co-channel interference is one of the main objectives in designing a WLAN channel plan, you'll want to carefully consider how you select the operating channel width and primary 20 MHz channels for APs in order to avoid co-channel interference.

First, determine if DFS channels can be used in your environment based on proximity to radar systems and client device support. DFS client support with 802.11a/n has been spotty at best. Hopefully 802.11ac clients will support DFS channels since 5 GHz support is mandated by the amendment and the FCC has eased DFS band adoption by clients since they no longer have to implement radar detection if they passively scan (listen-only) for an AP before transmitting any frames. In essence, they are relying on the AP to perform the radar detection and begin operating on a DFS channel if allowed. But until the time comes when a majority of clients support DFS channels, administrators must verify what channels the client devices on their network support so they don't cause coverage holes by having APs operate on channels that clients can't use.

Second, determine the channel width that you want to attempt to "guarantee" to client devices, which needs to be free of co-channel interference as much as possible. This needs to be based on the density of your AP deployment as well as client device capabilities. Remember - 802.11ac certified clients must support 80 MHz channel width, while 160 MHz channel width is optional. The key is to ensure that every AP has fewer neighboring APs within radio range than non-overlapping channels available.
  • In high-density areas, this should be 20 MHz (stadiums, large event centers, urban areas with many neighboring WLANs, etc.).
  • In normal-density areas, this is likely to be 40 MHz channels (large building office space). 
  • In low-density areas this could be 80 MHz channels (small buildings, few neighbors, etc.).  
  • In single-AP areas, this could be 160 MHz channels (such as homes or very small offices).

Third, make a list of the acceptable primary 20 MHz channels that results in non-overlapping channels at the "guaranteed" channel width. This will maximize the likelihood of transmitting at the wider channel width without causing interference with other APs. For example, if attempting to guarantee non-overlapping 80 MHz channels, limit the allowed subset of primary 20 MHz channels to 36, 52, 100, 116, 132, and 149. The specific 20 MHz channels could be different than I have listed in this example, but the key point is that only ONE primary 20 MHz channel be allowed within each "guaranteed" wider channel width.

Finally, channels will be configured by WLAN administrators in two steps:
  1. Select a channel width (20, 40, 80, 160 MHz) for AP or WLAN operation
    This should be the "guaranteed" channel width, at minimum. It could be larger than the "guaranteed" channel width if you want to allow APs and clients to achieve higher peak performance when the network is fairly idle. Since this can be done on a per-frame basis and clear-channel assessment is performed prior to transmission, allowing dynamic use of wider bandwidth shouldn't result in significantly more collisions. But it will result in more co-channel interference (sharing of bandwidth) between neighboring APs. The exact impact of per-frame channel width and co-channel interference in a multi-AP environment will require more in-depth testing once 802.11ac equipment is released. I would stick with using the "guaranteed" channel width until you are able to test in your own environment.

  2. Assign the primary 20 MHz channel to each AP (or allow auto-assignment)
    The primary 40 MHz and 80 MHz channels will be determined automatically based on the primary 20 MHz channel selected. If "Auto" channel planning is used, which is common in enterprise WLAN equipment, ensure the subset of primary 20 MHz channels allowed to be assigned to APs is limited to those in your list.
Final Thoughts
802.11ac offers exciting prospects for "Gigabit" Wi-Fi. However, most of the benefit of the first wave of products centers around the use of ever-wider channels. Two barriers to the use of these wider channels exist for enterprise WLANs:
  1. Limited spectrum, resulting in insufficient channels to facilitate a re-use plan that effectively allows wider channels without excessive co-channel interference.
  2. Greater reliance on DFS channels to provide more spectrum and channels, which many Wi-Fi clients do not support today.
Luckily, the engineers designing 802.11ac learned from 802.11n's shortcomings and devised a clever method to minimize co-channel interference through per-frame channel width adaptation and the designation of primary channels. This presents a fundamental shift in how administrators should approach WLAN channel planning. Administrators should be careful in selecting primary 20 MHz channels that result in non-overlapping channels at the larger channel widths that they wish to use in their environments. Also, a heavier reliance on DFS channels is required to realize the benefits that 802.11ac has to offer in an enterprise environment. Enterprises will need to evaluate what devices are in use on their WLANs to determine if 5 GHz DFS channel use is feasible. This can be especially problematic with personal devices where the organization has little control over the devices being used. However, consumer device lifecycles are typically shorter than enterprise lifecycles, so the adoption of 802.11ac capable client devices should occur relatively quickly (~2 years).

From an implementation perspective, most enterprises should plan around non-overlapping 40 MHz channels, or even 20 MHz channels in high-density areas. If the FCC frees up an additional 195 MHz of shared spectrum in late 2014 or early 2015 then designing around non-overlapping 80 MHz channels (or possibly even 160 MHz channels) in the U.S. will become much more practical.

Cheers,
Andrew


802.11ac Gigabit Wi-Fi Series:

Thursday, March 8, 2012

Apple iPad 3 Wi-Fi Specifications


Update 15-March-2012 - As I mentioned, I'd have more information once iFixit performed their teardown of the new unit. Well they're doing it right now... Wi-Fi, Bluetooth, FM chipset - confirmed it's a Broadcom BCM4330. Sadly, it doesn't look like 40MHz support will be possible :(


So, Apple announced "the new iPad" yesterday (aka - the iPad 3). I've done some digging on it at the FCC for Wi-Fi specifications and here is what I've found out.

First, the new iPad models fall under the following FCC IDs:
  • Wi-Fi Only FCC ID is BCGA1416
  • Verizon LTE FCC ID is BCGA1403
  • AT&T LTE FCC ID is BCGA1430

I'm only interested in the Wi-Fi specs, so I've looked up the Wi-Fi only model (A1416) at the FCC OET Equipment Authorization database. It's worth noting that much of the Bluetooth and Wi-Fi testing and certification was performed on the Verizon LTE model (A1403) and covers the other two models as well.

Wi-Fi and Bluetooth Capabilities
From the FCC test reports we can gather the following certification details:

  • 1x1:1 MIMO (1 spatial stream)
  • 20 MHz wide channels only
  • 65 Mbps max raw data rate (likely)
  • Bluetooth 4.0 including Low Energy mode and High Speed alternate MAC/PHY (leveraging the Wi-Fi chipset to offload large data transfer)

The combo Wi-Fi and Bluetooth chipset used by the iPad 3 is definitely NOT the same Broadcom chip used in the iPad 2 and iPhone 4 (which used the Broadcom BCM43291HKUBC). We won't know for sure what chipset is being used because the FCC internal photos are currently marked "Confidential" until 05-Aug-2012. However, once iPad 3 devices start shipping on 16-Mar there should be an iFixit teardown to give us insight.

My guess is that there are significant hardware improvements under the hood, which Apple may not be leveraging at time of initial release but may drop an update later on down the road. We know for sure from the FCC test reports that it support Bluetooth 4.0, which should be a major improvement over 2.1 + EDR found in the iPad 2. If Apple is using another Broadcom combo chip, which is highly likely, it could be the BCM4334 which is designed for smartphones and tablets. Broadcom product literature even includes very "Apple-esque" verbiage around highly mobile devices and push-email. This would be an intriguing choice since that chip offers single-stream 802.11n, dual-band operation, and 40MHz wide channels. Broadcom also lists concurrent dual-band capability for Wi-Fi client access on one band while simultaneously using Wi-Fi Direct or Wireless Display on the other band using what they call "advanced switching techniques."

If Apple does drop a software update at a later date for the iPad 3, we could see Wi-Fi specs bumped to:
  • 1x1:1 MIMO (1 spatial stream)
  • 40 MHz wide channels
  • Short Guard Interval (SGI) support
  • 150 Mbps max raw data rate
However, this may or may not happen. Support for 40 MHz channels would be a nice upgrade to enhance the product as it ages and keep it relevant. But it could have significant battery life implications which may make Apple hesitant to adopt. Also, SGI support is possible but unlikely since the chipsets used in the iPad 1 and iPad 2 were similarly capable but was not implemented by Apple (as Keith Parsons did an excellent job of analyzing on his blog).

iPad 3 Supported
Frequency Bands
Frequency Bands Supported
Note - All frequency ranges reference center channel frequencies from low to high channel.

Bluetooth:
ISM (2402 - 2480 MHz) - Bluetooth Frequency Hopping (FHSS)
ISM (2402 - 2480 MHz) - Bluetooth 4.0 Low Energy (BT LE)

Wi-Fi:
ISM (2412 - 2462 MHz)
ISM (5745 - 5825 MHz)

UNII-1 (5180 - 5240 MHz)
UNII-2 (5260 - 5320 MHz)
UNII-2 Extended (5500 - 5700 MHz)
UNII-3 (5745 - 5805 MHz)

The good news here is that the iPad will support operation using 20 of 23 available UNII channels. This should help enterprise network administrators plan for infrastructure deployments that can utilize the UNII-2 Extended frequency band. The 3 channels that are disabled (ch 120-128) in the 5600 - 5650 MHz range are disallowed for operation in the U.S. by the FCC DFS regulations due to Terminal Doppler Weather Radar (TDWR) systems.

Administrators have been reluctant to enable use of these channels in their networks because few clients have supported it. Enabling it on the APs would therefore result in "black holes" where clients would not be able to connect to the network. However, as more clients support this band administrators should look to verify client compatibility across the range of devices they support and, if possible, enable use of this band for greater Wi-Fi network capacity to meet the growing need for high-density deployments.

Additionally, channel 165 (ISM 5825 MHz) is available for use in the new iPad 3. However, few if any network administrators typically enable support for this channel in their deployments.

Antenna Gain
Here you can see the internal antenna gain in the iPad 3:

iPad 3 Integrated Wi-Fi Antennas

Power Output
Power output varies based on the exact frequency of transmission or channel of operation due to FCC regulations that limit spurious side-band emissions. Therefore, power output is usually lower on frequencies at the lower and upper edges of the bands. For simplicity, I will provide the range of power output values reported by the FCC across each band. For detailed information, see the FCC test reports.

Bluetooth
FHSS - 10.80 to 11.90 dBm
Bluetooth 4.0 Low Energy - 8.70 - 8.90 dBm

Wi-Fi
The Wi-Fi values get even more complicated because of the variations in spectral masks used by different 802.11 physical layer technologies. I've summarized the FCC test results into the following table for easier reference.

iPad 3 Wi-Fi Output Power (Average)

FCC Regulations Update
It appears that in May 2011, the FCC adopted new requirements for client device operation in the UNII-2 and UNII-2 Extended bands with regards to radar detection capabilities (or lack thereof). It reads:

Devices to be approved as UNII clients need to show compliance with the general requirements of Section 15.202, in addition to the technical requirements of Part 15E.  According to the requirements of Section 15.202, a client device must rely on a master device to initiate a network if the client device does not have radar detection capability.  Such a client device cannot initiate, or be configured to initiate, any transmissions including transmissions from probes, beacons or support ad-hoc modes of operation.  The operation of a device as a Group Owner for Wi-Fi Direct in the bands is therefore limited only where it is approved as a master according to the requirements of Section 15.202 (see KDB # 594280).

So, a client device can avoid implementing radar detection as long as the manufacturer certifies that it will not operate in ad-hoc or peer-to-peer mode. The device must only perform passive scanning to find a "master device" (e.g. an access point) that is capable of radar detection and is already operating on the frequency. In addition, this also applies to Wi-Fi Direct operation by the device.

Apple and other device manufacturers are now required to submit a DFS Attestation, similar to the following: 

Apple iPad 3 (A1416) DFS Attestation Letter

Conclusion
Although at first glance the iPad 3 appears to be similarly capable as the iPad 2, the underlying hardware could be much more powerful. Whether or not Apple decides to release a software update to unleash greater Wi-Fi transfer speeds at a later date is unknown, but could form the basis for a strategy to keep the iPad 3 unit relevant as a low-end option once the next version of the iPad is released, likely supporting 802.11ac for even greater speeds.

Additionally, the support for DFS channels in both the UNII-2 and UNII-2 Extended bands is a great sign for Wi-Fi networks to enable greater capacity.

Cheers,
Andrew vonNagy