Saturday, 24 May 2014

WiFi Free Space Loss Calculator


I often like to do a quick FSPL calculation to understand how far a WiFi signal might travel and usually have to search around to find an FSPL calculator. So, I put my own together so save me the search next time.

To understand what a signal level might be over a particular distance, simply select the channel you are interested in, enter the EIRP of your AP and the distance involved. Then hit the 'Calc' button:

Enter Frequency (Ghz):

EIRP: (dBm) Distance: (m) Signal Level (dBm):
Loss (dB):



(Caveat: this is a theoretical signal loss in free space, once you have obstructions, all bets are off. The actual signal level received by the client will depend on the gain (or loss) of its antenna)

(Not Working? You probably have Javascript disabled)

Thursday, 15 May 2014

802.11ac & 5GHz: The Emperors New Clothes? - Part 3


After previously looking at the challenges we may face with 802.11ac due to the restrictions of the 5GHz band (see part 1 and part 2 of this series), in this final installment, I suggest how we may mitigate the challenges we may face, together with a possible (but no doubt controversial) solution.

The Solution?

I'm not aware of any "magic bullet" to solve all of the challenges outlined in this series of articles (sorry). More spectrum will certainly help things. But, time-scales for the allocation and adoption of new spectrum are not clear at this point in time, though many agencies around the world are considering ways to free up more spectrum to improve WiFi capacity.

Though spectrum may become available in relatively short time-frames, there will still, no doubt, be a significant time-lag before this permeates through in to the world of vendor and consumer WiFi products (remember the issues raised around UNII-2e support?) 

The best way to mitigate the issues discussed in this series of articles is through:
  • a thorough understanding of the clients that will be using a wireless LAN - for instance, do they support UNII-2e/DFS channels, do they support 802.11ac, how many spatial streams do they support, what channel widths do they support?
  • careful planning of the channels to be used throughout a facility, taking account of channels used, channel widths and DFS considerations
  • a good wireless design/survey taking account of channel planning and co-channel interference/contention - this is more important than ever!
As I said, there's no magic bullet - just careful consideration of the points raised in this series of articles, which ends up being a series of carefully planned compromises due to the challenges that 5GHz presents.

Many of the points raised in this article have been an issue since the introduction of 802.11n, with it's 40MHz channels and the increased emphasis by vendors and manufacturers on 5GHz. However, there is now even more focus on the 5GHz band (specifically) with the introduction of 802.11ac. I'm still surprised how many people who I speak to who are still unaware of the 5GHz band for WiFi usage, so there are plenty of folks who are still new to all of this information.

Many folks have likely adopted default settings for their WiFi equipment without really giving too much consideration to channel planning. Many will have accepted a default of perhaps 8 x 20MHz channels operating on channels 36 - 64, which has worked just fine for them. With the advent of 802.11ac, this approach no longer suffices - more thought and planning is required if the true benefits of 802.11ac are to be realized.

To wrap up this discussion, 802.11ac is not simply about a wholesale migration to the 5GHz band to deliver ubiquitous Gigabit WiFi connectivity for your organisation. It requires careful planning and consideration (despite what the marketing boys may tell you).

Depending on your client devices and attitude to (DFS) risk, you will be somewhere on a spectrum of marginal improvements over your existing WiFi solution, to amazingly fast WiFi. To quote a well know policeman: "...you’ve got to ask yourself one question: 'Do I feel lucky?' Well, do ya, punk?"

An Alternative?

There is an alternative approach that I would not be surprised to see some manufacturers start to more seriously consider: single channel architecture (yep...there, I said it).

In a single channel architecture (SCA) solution, all APs and clients operate on the same channel. Note that this is used by a wireless systems specifically designed to operate in an SCA mode, you can't just flip all of your existing APs on to the same channel.

Some manufacturers already provide an SCA solution, though they are currently regarded in some quarters as being something of a 'niche', 'non-standard' solution. However, they are certified by the WiFi alliance, so this  is something of an unfair label to apply to them.

There is no doubt (in my mind anyhow) that a SCA can never perform to the same level as a traditional, well-designedwell-deployed 'multichannel' architecture (MCA). If you start to consider the amount of capacity available to each non-overlapping cell in a MCA solution, the maths speak for themselves - the capacity is proportional to the number of non-contending cells available in a network. However, there are three key assumptions underlying the MCA vs SCA argument:
  1. There are a reasonable number of channels available to allow an MCA solution to be deployed
  2. All AP cells in an MCA are sufficiently isolated from other AP cells on the same channel that they do not suffer co-channel interference/contention (hence cutting the potential capacity of two cells by a significant factor)
  3. The MCA solution has been well designed and deployed (i.e. cell sizing, channel planning and co-channel contention considerations are all well implemented)
Given the limitations of the 5GHz band once we start to consider the wider channels that 802.11ac brings, and the fact that very few WiFi networks are particularly well designed in the real world (in my experience), then I believe that the SCA approach has significant merit.

Although it will not be able to hit the potential theoretical throughput that an MCA solution could provide, it can provide a ubiquitous solution that uses an 80MHz channel on non-DFS channels - a feat that cannot be achieved by MCA systems.

I believe it has more chance of delivering the promise of 802.11ac, as it allows the use of the wider channels and the accompanying benefits. Many MCA solutions will have to compromise by reducing channel widths and negate a significant advantage that 802.11ac delivers.  Though multi-user MIMO should certainly deliver increased throughput capabilities in environments with many single-stream devices, the underlying channel width issues will remain. 

WiFi gurus out there will no doubt be able to plan and tweak their WiFi networks to the nth degree and get a super-high throughput network operating on MCA. If they can find organisations who will pay for that level of expertise and commissioning (and are able to maintain their network), that's great. They will no doubt achieve excellent results.

For the vast majority of everyone else deploying WiFi, with customers who want a solution in a working in a timely and affordable manner, then it might be time to at least consider an alternative (and for vendors to start providing that option). SCA certainly isn't the solution for every environment, but is worthy of consideration in many scenarios.

I know that the proposition I'm putting forwards here won't be popular with many WiFi professionals, but I think that SCA is at least worthy of consideration as an option by more WiFi vendors. 


If you've been in the networking industry for a while, you might remember two competing LAN technologies: token ring and ethernet.

Token ring was faster, providing 16mbps LAN speeds, compared to the paltry 10mbps of Ethernet. It used an efficient, well-ordered token passing mechanism, compared to the rather inefficient and erratic random back-off and collision detection methods of Ethernet.

In many ways, token ring was a  technically superior, better-performing solution than ethernet.

It's flaw: it was complex, expensive to maintain and difficult to deploy in comparison to the ease and simplicity of rolling out UTP hubs to create an ethernet LAN. Despite its advantages, people simply got fed up with the complexity and expense of deploying and maintaining token ring networks, resulting in Ethernet winning the LAN technology battle. 

Sound familiar..?



(Thanks to Andrew (@revolutionwifi) for allowing me to use the image featured in this article. It is taken from his original article: 802.11ac Channel Planning

Wednesday, 14 May 2014

802.11ac & 5GHz: The Emperors New Clothes? - Part 2

In part one of this series looking at 802.11ac challenges, we looked at the issues that the use of the 5GHz band brings, particularly around DFS. In this second installment, we look at further challenges to designing and deploying 802.11ac networks.

Extended Channel (UNII-2e) Device Support

Although we may be located well away from any obvious sources of radar interference, there may be other obstacles to the 5GHz nirvana outlined in the 802.11ac marketing briefs. One ugly fact affecting WiFi networks on the 5GHz band is that not all devices that use the 5GHz band support all of the unlicensed channels available in our region. 

For instance, I recently purchased a Nexus 7 tablet and was extremely disappointed to find that it only supports channels 36 to 64 (for the UK). The remaining available channels, 100 - 140 are not supported at all.

I think that this variation in support for channels was originally rooted in a lack of support for devices in the UNII-2e channels (channels 100 - 140). Why this trend still persists in some devices is a mystery to me, but there is no doubt an economic consideration at work here (i.e. lower cost chip-sets). Nonetheless, it still persists with some new devices and is certainly an issue with many older devices.

It's certainly true that UNII-2e channel support among WiFi clients has increased significantly over recent years, but there is still no guarantee that all devices that may use your wireless network will be able to use all possible 5GHz channels. This has an impact if you decide to try to use all 20+ channels across your wireless network. If a wireless client that doesn't support UNII-2e channels is in an area where all APs use UNII-2e channels, then the client will simply not be able to connect. As a work-around, it is possible to alternate AP cells in such a way as to distribute UNII-2e channels amongst AP cells using UNII1,2,3 channels, so that clients may still be able to find a supported channel. But, this is still a workaround, and not an optimum design. Making an SSID available on the 2.4GHz could also be a last-ditch fall-back, but of course, we're no longer able to use our 802.11ac speeds.

(Peter Thorneycroft did a great presentation which touches on this - you can find it here)

Whichever way you look at it, having clients that do not support UNII-2e channels in a wireless network that uses UNII-2e channels is not a great situation and requires careful planning and consideration. 

Voice Over WiFi Clients

Unfortunately, the woes around DFS channels don't end there. I recently became aware of another effect of using DFS channels recently when I attended the Wireless LAN Pros conference and saw this presentation from Martin Ericson: http://www.wlanpros.com/ten-talks-martin-ericson-vofi-phones-dfs-channels/

In summary, when using wireless voice handsets, you want to keep your roaming times between access points very low as you move around a building. If the roam time between APs is too long, this can cause poor audio quality or perhaps even drop the call. Therefore, being able to make a timely roaming decision is critical for wireless handsets. 

Wireless clients use two methods for finding new APs to roam to:
  • Passive scanning - they listen to beacons which are sent every 102mS by APs and build a list of potential APs to roam to
  • Active scanning - they send out probes across all channels to more rapidly find a new AP to roam to
Although the 102mS of passive scanning sounds like a short period of time, it is actually quite a long period compared to what can be achieved using active scanning. When relying on passive scanning alone, the period taken to roam between APs is too long and will cause the quality and connectivity issues we discussed previously.

The DFS process dictates that only the access point on a wireless network has to be able to detect to radar. Clients do not detect radar blasts. For this reason, clients are not allowed to probe on DFS channels, as they may be probing (and hence causing interference) on a channel that is in use by a radar system.

Given this restriction, it does not make sense to use WiFi voice clients on DFS channels. Again, we are impeded in our channel selections for 5GHz for our WiFi network, as utilizing just the non-DFS channels is our best option.

Channel Widths

One of the key strengths of the 802.11ac standard is the speed increases that it delivers. This increase in speed itself is a nice-to-have, but it's not a huge game-changer for the average mobile client. The real advantages are in the increased spectral efficiency the speed increase it can deliver (i.e. how quickly a client can use and free-up the RF medium), which delivers higher WLAN capacity and greater battery savings for mobile devices.

One of the mechanisms used to deliver this additional speed boost is channel bonding. This isn't new - in the 802.11n standard, two standard width 20MHz channels could be bound in to a single 40MHz channel to double the speed of the wireless communication between the AP and client. But, as we double up on our channels, we have less unique channels available overall for our WLAN. The diagram below shows the effect on varying channel widths within the 5GHz band:



You can see that in this diagram (for the USA), we have 25 x 20MHz channels available. This shrinks down to a total of 12 channels when we are using 40MHz channel widths. (The actual numbers available are lower than this, as the weather radar channels aren't generally used, but lets keep things simple for now) 

When considering 802.11ac, which allows the use of 80MHz channels, you can see that the number of usable channels falls again to just six (but, again, the caveat around weather radar channels reduces this). 

Unfortunately, in the real-world, we are probably looking at being able to use 5 or less (in Europe) 80MHz channels on the 5GHz band for 802.11ac devices. And, once we consider legacy devices that perhaps don't support the UNII-2e channels, we're down to just one or two channels that all devices will be able to support. 

Anyone with a basic knowledge of building 802.11 networks will quickly see that having such a small number of available usable channels is not going to work at all well. Having so few channels talks us right back to same issues we had with co-channel interference (or contention) that we've always had on the 2.4GHz band.

So, we're back in to the land of compromise. We have to reduce our channel widths and lose many of the speed benefits that 802.11ac provides. We have to take a chance on using DFS/UNII-2e channels and hope that we don't suffer with any of the potential pitfalls I have outlined above. The 802.11ac story doesn't quite stand up to close scrutiny after all. 

Many vendors are pointing to the white knight on the horizon in the form of 802.11ac wave 2. Wave 2 will allow up to 3 (or maybe 4) single stream clients (e.g. tablets, smartphones) to connect simultaneously to an AP using a technique called multi user MIMO (MU-MIMO). This should provide a significant improvement in performance in environments where single stream devices abound. But there are again caveats: the clients have to be spatially far enough apart for the beam-forming to work correctly and the clients themselves must support beam-forming (which is not mandatory in 802.11ac). Even with these improvements, none of the obstacles outlined previously magically disappear. It's also worth considering that MU-MIMO is only a mechanism that works downstream from AP to clients - it won't be possible for 4 clients to all use the same channel at the same time.



In the third and final installment of article series, we'll look at a solutions to the issues presented in parts 1 and 2. 

Tuesday, 13 May 2014

802.11ac & 5GHz: The Emperors New Clothes? - Part 1

The WiFi industry has been buzzing with excitement around the recently ratified 802.11ac standard. The promise of higher speeds, lower battery usage for mobile devices and the enforced move to the higher-capacity 5GHz band is enough to put a smile on the face of even the most curmudgeonly members of the WiFi fraternity.

I've been giving some serious thought recently to what the best approaches might be in terms of designing and deploying 802.11ac networks. There are obviously challenges as we move through the transition from legacy standards to the shiny new 802.11ac standard: 
  • new cabling requirements for higher uplink speeds to 802.11ac APs
  • Increased power requirements for our 802.11ac APs
  • accommodating the mix of new and legacy clients
  • figuring out exactly how we plan our channels for the brave new world of 802.11ac

The 802.11ac standard mandates that access points and clients using the new standard will only be supported on the 5GHz band, which is great news...right? We can still use our legacy 802.11g and 802.11n standards on good old 2.4GHz, but 802.11ac is 5GHz only. 

The 5GHz band offers us far more channels that the noisy cesspit which is the 2.4GHz band. It provides around 20+ channels (depending on where you are in the world), compared to the pitiful 3 useable channels of the 2.4GHz band. 5Ghz is currently used by fewer (non-WiFi) devices, so has less noise and interference than it's noisy cousin down on 2.4GHz. As we have more channels to play with on 5GHz, we can also start bonding them together to get 40MHz (double-width) and 80MHz (quad-width) channels to get even faster throughput for our 802.11ac clients.

On the face of it, we are in easy-street on 5GHz compared to 2.4GHz. Faster speeds (for faster transfers and better spectral efficiency), together with lower noise and more channels for easier planning and higher capacity.

But, not so fast. 5GHz has a few little 'gotchas'' that maybe the marketing boys didn't tell you about...

DFS

When the 802.11 standards were created and the 2.4GHz and 5GHz bands were allocated for use by WiFi traffic, there was some difficulty surrounding existing services that already used the 5GHz band. Particularly in Europe, there was the issue of weather and airport radar systems that already used parts of the 5GHz band. Though this was initially confined to Europe, it is now a consideration in many areas of the world.

Unless protection mechanisms were put in place, there was a danger that a WiFi network on specific channels within the 5GHz band could interfere with these radar systems.  Therefore, it was decided to implement a protection system to guard against radar system interference: Dynamic Frequency Selection (DFS).

DFS ensures that if a WiFi network detects an RF signature that looks like a radar pulse on the channel on which an access point is operating, it will cease all transmissions on that channel and move to a new channel. This has a disruptive effect on associated wireless clients, who will also need to switch channels. This might cause a relatively short 'blip' for clients not carrying time-sensitive data (e.g. for simple web browsing, files transfers etc.). But, for latency sensitive traffic (e.g. voice & video), this channel switch will have significant effects, such as dropping established voice calls over WiFi.

To find out more about DFS, take a look at a great series of articles from Jennifer Minella at Network Computing.

Fortunately, the DFS mechanism does not apply to all channels within the 5GHz band. In many parts of the world, the first 4 channels of the 5GHz band for WiFi may operate without being subject to DFS (non-DFS channels). These are channels 36,40,44,48. This means we can confidently use these channels without any fear of service interruption due to radar detection events. (Note that in the USA, there are 9 non-DFS channels)

Unless you are near an obvious radar source (e.g. an airport), it may be difficult to determine if your network is going to affected by radar. Often, the first time this becomes apparent is when a wireless network has been deployed and radar blasts are reported by the wireless network. Due to the nature of the radar pulse width, radar systems tend not to detected during a wireless survey, even if using a spectrum analyser.

In addition to detection of genuine radar systems, there may also occasionally be local interference from non-radar systems which inadvertently trigger the DFS mechanism. This is due to the generation of a pulse of RF energy that looks similar to a radar pulse.

In the real world, reports from other wireless professionals I've spoken to suggest that actual radar events affecting WiFi networks tend to be rare. However, in very high density deployments, the incidence of false-positives from mis-behaving clients is not unusual.

In summary, although radar detection is infrequent, it may be unpredictable and may cause significant disruption when using a WiFi system on 5GHz near a radar source. The effects of DFS may be completely mitigated by using only non-DFS channels, but this will reduce our usable channels from our original 20+ channels down to just four (OK, maybe 9 if you're in the USA...).


In part 2 of this article series, we'll look at more restrictions impacting the use of the 5GHz band and 802.11ac.

Monday, 12 May 2014

Performing A WiFi Survey For A Building That Doesn't Exist (Yet)

I was recently involved in some work for an organization that had a newly constructed building to expand their, already sizable, campus. The building was a new, state-of-the-art facility that would require ubiquitous WiFi network coverage for a range of devices, including wireless voice handsets.

Like many organisations, they were faced with the challenge of specifying the wireless equipment that they would require long before the building had even started construction. In order to secure the funding they would need for the new wireless infrastructure components (i.e. APs, wireless controllers, licensing), they had to try to anticipate what the new wireless network would look like, taking account of the services that they would require.

The organisation realised that they would require a few more access points than might be usually expected for basic data services over wireless, but had taken a best guess at how many APs they might require and where they might go. When we walked in to the new facility with all of the APs deployed as per their "best guess", it was immediately obvious that the APs were all too close together and there was massive co-channel interference throughout the facility. Turning off a few radios relieved some of the immediate pain, but it was obvious a major re-think of the 'design' would be required, with many APs requiring a move or even removing altogether.

In a brand new facility that had just been handed over from the building contractor, this was definitely not good news. It's amazing how unpopular you can become when you have to move APs and juggle brand new ceiling tiles that already have holes drilled through them to for AP data cables. The same applies for breaching and making-good fire-breaks between rooms in a new-build, just because you need to move an AP between rooms to a new position.

This experience reminded me that not everyone may have heard about predictive wireless surveying, or even if they have, they may not understand its value or how it is achieved.

In summary, a predictive wireless survey allows complete a wireless survey of a building or area by using scaled plans of the area that requires WiFi coverage. It requires specialist survey software that allows building plans to be imported, obstructions (such as walls) to be added to the plans and 'virtual' APs to be added to the plan. The survey software then performs some very fancy calculations to give a modelled view of what the WiFi coverage of the APs might look like.

This is obviously a great approach when having to design a wireless network for a building that hasn't even been built yet. By carefully modelling the environment that the wireless network will be deployed into, a reasonably accurate network can be designed just from building plans. This method isn't going to create a survey report with the same accuracy as a physical survey performed on-site, but it's going to give you a very good indication of the final network is likely to look like. It will certainly allow you to build a very accurate bill of materials for the final deployment.

Although there will generally be a charge for a survey of this type, the cost is likely to be very minor compared to the costs of over or under-provisioning that a 'best guess' approach will yield. There are also the additional costs down the line around re-deployment, additional cabling, additional licensing etc. that you will avoid with a well planned design method. The cost of a predictive survey is likely to be dwarfed by the cost of an poorly designed/anticipated wireless network - this could be many thousands, or tens of thousands of dollars in wasted hardware, licensing and man-hours, compared to the very modest cost of a predictive survey.

The one caveat I would advise when choosing a supplier to provide a you with a predictive survey (also known as a desktop survey) is to use one that uses staff with at least CWNA certifications. Many less-qualified suppliers may get hold of a copy of wireless survey software and 'give it their best shot'. But, to use the tools effectively, you really do need to understand RF propagation, WiFi design principles (such as capacity planning) and best-practice approaches (e.g. avoiding co-channel interference, hidden node issues etc.). Without wanting to labour the point too much, don't be swayed too much by suppliers who claim to have 'vendor-level' certifications that enable them to perform survey work - the vast majority still have very little in terms of survey knowledge and a pitiful level of RF (...you have be warned).

A Predictive Survey

So, how do we actually perform a wireless survey for a building that doesn't exist yet? I'll present a number of screen-shots from the Ekahau wireless planner survey tool. The Ekahau survey tool allows both on-site surveys using a traditional "AP-on-a-stick" surveys, together with (predictive) desktop surveys that we have discussed above.

To perform a predictive survey, one thing we absolutely must have is building plans of the area to be covered by the new wireless deployment. Without accurate building plans that can be scaled to represent the final real-world building, it is not possible to accurately model the final environment and correctly show the coverage and performance of the WiFi network.

Once we have an electronic copy of the floor-plans for our survey area, we can import it in to the Ekahau tool. The first thing was have to do is to calibrate the plans so that we have an accurate indication of the size of the area being surveyed - this is usually done by entering a measurement for one wall of the building. Without this initial accurate measurement, the predicted coverage areas for the survey are pretty much meaningless. The software calculations for RF signal levels rely on the distance of each area on the floor plan from the access point - if the distance is incorrectly calibrated then the RF coverage will be inaccurate.


Fig 1 - Imported Floor Plan (with calibration of one wall shown)

In the example we're going to look at, we're going to do a very quick and dirty survey to show the principles of the predictive technique. In our case, we're going to be looking for coverage in all office areas, providing basic RF coverage down to -67dBm in all areas on the 5GHz band. We're looking for an SNR of 25dB (or better) in all areas too. A real survey would be a little more specific than this, but this will be good enough for the purposes of our example.

The next thing we need to do is to draw in the building structure of the floor plan to build up a model which will start to reflect the actual construction of the building (as closely as we can). Walls, doors, windows, lift shafts etc. can be added across the floor plan by tracing their outline with the appropriate building material that is provided in the survey software. The survey software provides typical losses that will be experienced through each type of material so that the RF losses around the building may be calculated by the survey software.

In our example, I've added in the outline of the building, together with some internal walls and doors (the gray and brown lines overlaid on the plan).


Fig 2 - Floor plan with building materials added

Once we have added in the building structure, our next step is to start to add in some access points to start to see the coverage we might achieve as we place them in various positions. The first thing that I need to do is to select the AP and antenna that I intend to deploy. The Ekahau tool has a massive range of access points and antennas to choose from. In this case, I'm going to select a Cisco AP2600i, which has an internal antenna.

In the screen-shot below, I've placed an AP in the top left of the plan to see the coverage that it gives me. The graduated colours show the signal strength as the RF signal radiates out from the AP, going from high (green) to low (red). Where the coloured coverage pattern ends is where edge of our cell may be found - note the legend in the bottom right of the graphic which shows our -67dBm cut-off selection (which is one of our design criteria):


Fig 3 - Initial Access point placement

This coverage is probably a little more than I would ideally like, so I'd like to reduce the coverage area of the AP. I can quickly edit the transmit power of the AP and see the effect on coverage as I wind the power down by 3dB:


Fig 4 - Initial Access Point Placement (reduced power)


I can now proceed with adding a few more access points to give me the level of coverage I'm looking for. As well as adjusting the transmit power for each access point, I can also assign channel number for both the 2.4GHz and 5GHz bands. This is useful in assessing my co-channel interference, to understand if I can achieve a viable channel plan across the building.

In the screen-shot below, you can see a number of APs placed across the floor-plan with the appropriate channels settings displayed for both bands:


Fig 5 - All APs placed showing signal coverage for 5GHz

Now that we've placed our APs, we can see the coverage that they would provide when deployed in these positions. We can now look at other aspects of the predicted deployment to see if it meets our design criteria. For instance, do we meet the 25dB SNR requirement across the floor? If we switch the display filter to show signal to noise ratio (SNR), we can see what the predicted SNR might look:



Fig 6 - Signal to Noise Ratio

Again, looking at the legend at the bottom right of the screen-shot, we can see that our lower cut-off (which is a design minimum) is set to 25dB.  The red areas show where we are close to our lower limit. Although we are close to our limit in a number of areas, we nonetheless meet the design criteria in all office areas.

Finally, we'll do a quick check to see if our channel plan is causing any co-channel interference between access points . Co-channel interference (CCI) is caused when a coverage area has two or more APs on the same channel that may be heard by a client in that area. CCI is undesirable as it causes contention across the APs and clients within that area, lowering the overall throughput on that particular channel. In our example, we can see that we have no co-channel interference on the 5GHz band (again, note the legend showing that only 1 AP can be heard in all areas):


Fig 7 - Co-channel Interference on 5GHz

As this doesn't make a very interesting result, here's the same screen for the 2.4GHz band. The yellow blobs indicate where we might experience co-channel interference. We might like to look at moving our APs, adjusting power levels or maybe even turning off some of our 2.4GHz radios if we decide that this an issue for us:


Fig 8- Co-channel Interference on 2.4GHz

Well that's pretty much all I want to cover around doing a predictive survey. We've really only scratched the surface of what is possible with predictive surveys, but you can hopefully begin to understand how we can build a model of the RF environment for a building and then how a WiFi network would be deployed and might perform in that environment. There are many more aspects that we could consider around other factors such as capacity planning and 3 dimensional building planning (for multi-floor deployments), but we'll leave those for another time (or, even better see further examples over on the Ekahau web site)

It has to be emphasized that the results of a predictive survey are only as good as the data that is supplied to the RF model that is built. Unless the walls and obstructions traced on the report are accurate, then the clever RF calculations performed by the survey software  to show RF coverage and other characteristics will be inaccurate. 

A predictive survey is generally unlikely to be as accurate as a physical survey conducted on site, but it certainly provides a very good indication of what might be expected for a building that has yet to be built. This can be invaluable for putting together an initial bill of materials, together with estimates for cabling and switch infrastructure requirements for the new wireless network.

Hopefully, this has given you a 'taster' of the value of predictive surveys for buildings that have yet to be built, or perhaps buildings that are undergoing a major refurb and are not accessible at the time when new kit needs to be specified and ordered.

Sunday, 11 May 2014

Spectrum Allocation Plans for WiFi in the UK (2014)

Plans for new spectrum allocation for WiFi networks in North America are regular fodder for many blog and news articles that I  see scrolling past in the many RSS feeds that I monitor for WiFi related news.

However, information about plans for additional spectrum allocation within the UK isn't quite so widely covered (in fact, I'd go so far as to say that it is largely ignored). But, here in the UK we still face the same issues as many other areas of the world: an explosion in mobile devices, massive deployment of WiFi networks in homes and businesses, and an ongoing increase in bandwidth demands.

WiFi in the UK operates on both the 2.4GHz and 5GHz bands. We have 13 channels allocated for WiFi on 2.4GHz, but for practical purposes, only 3 may be used across a wireless LAN. On the 5GHz band, we have 19 channels allocated to WiFi, but are generally limited to using only 16 of those channels due to restrictions in supporting 3 channels that may interfere with weather radar systems.

The latest and greatest WiFi standard, 802.11ac, will (theoretically) provide Gigabit WiFi speeds which will hopefully keep up with the growing demand for bandwidth via WiFi neworks. 

However, 802.11ac only operates on the 5GHz band. This is in recognition of the fact that the 5GHz band has much greater capacity than the 2.4GHz band (16 channels vs 3 channels) and so will be able to support the greater bandwidth required for the higher data rates that 802.11ac brings. Additionally, the 5GHz band generally has much lower noise and interference (compared to the 2.4GHz band) from other co-existing devices and services, making it more suitable for high speed services.

In April 2014, OFCOM (the UK communications regulator) published a report that outlines the current considerations around the use of RF spectrum by WiFi networks in the UK. It also discusses considerations for M2M (Machine to Machine) communications and the IoT (Internet of Things), but my interest was limited to the WiFi aspects of the report. It provides some interesting insight in to the services currently using the 5GHz band and considerations for making more spectrum available within the band.

If you'd like to take a look at the report, you can get hold of it here: "The future role of spectrum sharing for mobile and wireless data services  - Licensed sharing, Wi-Fi, and dynamic spectrum access" (section 3 is the main area of interest from a WiFi perspective)

Here are the highlights of the report around current and future WiFi spectrum usage here in the UK:
  • WiFi usage is growing rapidly and there is a need to keep pace with the increasing speeds of broadband connectivity in to homes and businesses.
  • The requirement for increased speed will have to leverage the new 802.11ac standard (for example being able to leverage the 80MHz and 160Mhz channel widths that 802.11ac provides)
  • WiFi networks using more spectrum in close proximity to other homes and  businesses will require more available channels to be able to use the required access speeds
  • Other alternatives (below) are available within homes and businesses, but WiFi is the only viable option for wireless devices
    • limited to a single room: WiGig (802.11ad) and Li-Fi
    • Around home/business: Powerline adapters (depends of quality of wiring), Ethernet cabling (expensive/disruptive) - both still require wireless access points to connect wireless devices
  • There is insufficient bandwidth in 2.4GHz band for higher speed WiFi standards
  • Proposals to extend the allocation for WiFi within the  5GHz band are being considered in preparation for the World Radiocommunication Conference in 2015. The extensions under consideration is shown in the figure below:

  • From studies carried out, it is expected that the current spectrum allocation in 2.4GHz and 5GHz is likely to be under pressure (from a capacity perspective) by 2020.
  • The report also highlights concerns from a number of other interested parties who already have services existing in the areas of proposed spectrum expansion and may be impacted by WiFi co-existing in their area of spectrum. It provides the following illustration of existing services in the 5GHz band that may be affected by any spectrum allocation expansion:

  • Due to the requirement for co-existence with these existing services, work is being undertaken to consider technical solutions for sharing the spectrum. These include dynamic frequency selection (DFS), transmit power control (TPC), restriction to indoor-use only and geolocation databases
  • Some concerns have been raised by existing users of the areas of spectrum that are proposed for sharing (e.g. ESSS - earth exploration satellite services), as they rely on equipment which detects low level signals which has incurred significant investment and cannot be modified once deployed.
  • Ofcom is carrying out a number of technical studies in preparation for the World Radiocommunication Conference in 2015 to understand the viability of spectrum sharing. However, at this time, there has been no definitive opinion formed by Ofcom around whether or not they should support the proposed extensions.
In summary, it is interesting to see that Ofcom are actively considering expanding the provision of spectrum on 5GHz for WiFi services within the UK. However, it is unclear at this point if more spectrum will be made available, or how much additional spectrum will be allocated. It looks as though we will be waiting until the World Radiocommunication Conference in 2015 before any decisions will be made.


References: