Designing for Voice – How Much Coverage?


This blog post expands upon a recent question I posted in the CWNP’s CWAP/CWDP study forum relating to the practice of providing coverage overlap for voice grade Wi-Fi deployments:- Why is specifying 2 or more APs with Sig’ Strength of -6xdBm best practice for Voice over Wi-Fi?
It was sparked off by a the suggestion that as a design guide, -6x dBm coverage from 2 or more APs is required over the space you are looking to cover with voice grade Wi-Fi. (Where x can be -65/67 depending who you talk to).

Note: I wrote a whole ream on the subject exploring different roaming scenarios ; this post is a cut down version of that ream and makes a whole bunch of assumptions in order to get to the core of the argument… I’ll try and polish-and-post the original soon!

From the The Ideal – Wi-Fi Coverage In Theory.

The Ideal

The image above shows how these things are often represented, and her you can quickly see the logic for suggesting 2 APs at -67 dBm. As shown, anywhere where the cells ‘touch’ will have to APs at about -67dBm. I’d call this “zero overlap” and would be met by a primary design specification of “coverage at -67 dBm over 95% of the internal area” or something like that.

To the The Real – Wi-Fi Coverage In Practice.

But what happens when we try to do this in the real world.
More often than not we have a scenario like the one pictured below:-

Simple Real World

Meet our actual (simulated) room, with concrete walls and a single door leading out into a corridor.

Ekahau here is showing anything covered with -65dBm or above.

To meet our “2 APs at -65dBm or above” specification to support voice, we’d have to install another AP somewhere in that room.

Anywhere outside is going to fail to cover some part of that – even an AP put outside the door (shown as blue) does not cover that room entirely:-
AP outside door

So What’s the point of 2 x -67dBm?

So, why would we want to do this?

Replicate it for each room in a facility and soon you’ve got loads of APs which IMO are mostly just serving to add Co-Channel Interference.
There is only one way out of that room (not even a window for the truly adventurous) so there isn’t anywhere for a client to go except into the corridor. If we’ve designed to -6x dBm there will be an AP for us to roam to as soon as we leave the room to provide coverage in the corridor. (Even if it’s far down the corridor, as long as coverage meets the spec’, it should be more than adequate.

(Sure, i’m making some assumptions here – that APs are pretty sturdy and don’t fail often; that there is plenty of capacity available, but hopefully the scenario i’ve outlined is enough to illustrate my point)

If you’re reading this and have an opinion, I’d really like to know!


  1. Your example of a small room, surrounded by concrete walls could rightly be called a corner (special ) case.
    I doubt any predictive software or rational site survey would propose such a solution.
    These numbers are obviously recommended in roaming situations. You would not be roaming within a room this small.
    It’s more power than I would design to, but as a rule of thumb I think it is a valid starting point for a design.

  2. Sorry – this became a novel but VoWiFi is complex so its hard to discuss it in isolation :)

    You’re line of thinking was similar to mine in the past. As mentioned in the previous comment though, this scenario is more the exception. If we take the three most common traditional VoWiFi verticals (healthcare, logistics, retail) to work with…In a modern hospital the majority of walls are going to be plaster-board and therefore not very high attenuation like the example above. The walls on that room must be in the realm of 10dB+ attention I’d think. In a modern hospital I’d only see that sort of attenuation in plant rooms, exterior walls, etc. Even in radiology the walls I’ve seen are actually not nearly as high in attenuation than I expected (higher than standard plaster, but not typically nearly as high as exterior walls (10dB+). So for the majority of the hospital, 2 x APs @ -6x dBm works well (I’ll use Cisco’s -67 dBm for clarity of reading but insert VoWiFi vendor recommendation in place (-65 to -70 is the variaton I’ve seen across the major VoWiFi handset vendors). When I do have rooms like that above (a coolroom is a good example) typically I won’t put in 2 x APs unless it were mission critial (and even then it would depend on specifics). But for the rest of the site, I would design to the 2 x APs @ -67 dBm (or more critically, 25 dB SNR).

    In logitics (a warehouse) and retail it is typically quite open and so achieving 2 x APs @ -67 dBm is quite doable except for coolrooms and a few other exceptions.

    Obviously older buildings with thick walls do make things harder – I had a 100+ year (which is old in Australia ;)) old mental health building where I needed an AP in every second (small) room due to very high attenuation. In this case I am less concerned about achieving 2 x APs @ -67 dBm as it very difficult.

    To take a step back, 2 x APs @ -67 dBm actually provides more cell overlap than is needed to allow for the complete roaming transition period (at least in ideal conditions). If you think of the mid-point between the 2 x APs its going to be sufficient to allow roaming and more overlap than you may actually require *as long as the client sees a smooth drop-off in 1st AP signal and a smooth increase in 2nd AP signal*. In this scenario you could possibly get away with 1 x AP @ -67 dBm & the 2nd AP @ -70 or possibly even -72 dBm. Based on past experience -72 is too low and I’d go no lower than -70 for the 2nd AP. The main problem with doing this instead of 2 x APs @ -67 dBm is that often you won’t always have a smooth drop in signal and smooth increase. You can try to account for this in the design but its not always possible. For example, sometimes you’re signal will drop off very quickly such as when going through a fire door or when going from indoor VoWiFi to outdoor VoWiFi. The VoWiFi client may go from -50 dBm (where it isn’t even considering roaming due to the high signal) to -67 dBm very quickly as it passes through a high attenuation wall. At this point its on the cell edge of the associated AP and needs to roam very quickly. As mentioned, in these cases I try to ensure there is an AP closeish to both sides of the high attenuation area to lessen the impact. If there is another AP very close on the other side its an obvious choice to associate to that AP. This is another reason to limit the number of channels supported in 5 GHz VoWiFi. If UNII-3 can be used (not in the EU) I do UNII-1 and UNII-3 so the VoWiFi client doesn’t waste as much time scanning through channels. UNII-2 support is an issue due to the inability to send probes and listening for beacons is much slower. In the EU, you’d need to use UNII-1 and UNII-2 though and deal with the lack of probing ability (due to DFS requirements). Its also important to limit the client to only scanning channels that the AP is using for the same sort of reasoning. Also the roaming algorithm of the handset plays a big role so up to date firmware on the handset is important (of course there’s been updates that have caused problems by negatively altering the algorithm).

    Another issue (on the Cisco 792x handsets at least, which is still a bit part of the handset market) with not having 2 x APs @ -67 dBm I’ve found is the lack of 5 GHz diversity antennas. If the handset has line of sight to the AP (eg a nurse walking down a corridor with the AP in the corridor) then the dropoff in signal is smooth. If the APs are in the rooms, due to the lack of diversity the signal is all over the place! (multipath) and therefore it makes it difficult for the handset to know when to roam. For this reason, in hospitals, in addition to the APs in the rooms (assuming I’m able to) I recommend putting a small number of APs in corridors with the 5 GHz radio enabled and ideally the 2.4 GHz radio in a listen only mode. This way the 2.4 GHz radio can still serve RTLS/wIPS functions if they’r being done. As Cisco APs didn’t support this per-radio the only option was to disable the 2.4 GHz on this particular corridor APs (or leaving them transmitting depending on minimum data rate and other particulars). Apparently per-radio monitor mode is support on the new 3800 APs though. Yay!

    The above just addressed overlap however the 2nd AP @ -67 dBm also serves redundancy purposes. Basically, 2nd AP coverage provides two things, 1) Cell overlap and 2) Radio redundancy. There are a long list of redundancy reasons that I want a 2nd AP @ -67 dBm (or more importantly 25 – 30 dB SNR) – having radio redundancy is mandatory is 90% of designs today imo (VoWiFi or otherwise) for the following reasons:
    * AP hardware can fail (not common for enterprise hardware but it can happen)
    * AP software failure (eg – reboot); much more common than hardware from what I’ve seen
    * Radios can fail – if client is dual-band and not restricted, this may be less of an issue but if its VoWiFi and locked to 5 GHz, this is a concern
    * Patching issue (someone knocks a patch cable out etc. – easy to do in the mess that is more comms closets).
    * Switch hardware or software failure (assuming your redundant AP has been patched to another switch and its unaffected by the failed switch issue.
    * Radar detection – if the AP moves to a non-DFS channel then not such an issue. If the AP moves to a DFS channel, there will be an outage or more likely breakup in call quality if the client can’t hear another AP strong enough
    * WLCs can also fail so if adjacent APs are spread between WLCs this can help. I don’t like APs across WLCs where possible though so the VoWiFi would have to be critical for me to consider it
    * … and finally, by far the biggest reason in all deployments (data and smartphone based voice), client 5 GHz channel support is a huge mess and only going to get worse as UNII-2B and UNII-4 are eventually released. Having a redundant 5 GHz radio ensures a client can (hopefully) see that radio, if its on a channel it supports. Obviously an (unrestricted) dual-band client could roam to the 2.4 Ghz radio and that may be ok depending on how clean the 2.4 GHz channel is / client throughput requirements, etc.

    When you have 2 x APs @ (5 GHz) -67 (or 65 or 25 dB SNR or 30 dB SNR or whatever is appropriate) you will have more channel reuse (CCI) at 2.4 GHz. HOWEVER, just having multiple radios on the same channel does NOT neccessarily cause problems. Yes, if you have 2 x 2.4 GHz radios on the same channel (within -82 dBm earshot) you will only get the capacity of one of those channels – thats a given. As long as you don’t expect more capacity than that one channel then it isn’t the end of the world. The problem that it causes is the increase in channel utilisation due to the management frames (primarily beacons). This is only an big issue if you don’t disable low rates. Simply put, as long as I don’t have *too* many APs on the same channel (ideally under 3) AND my lowest data rate is high (12 Mbps to 24 Mbps) then the increase in channel utilisation is minimal and so I’m not that worried about CCI. The lower the data rate I need to support and/or the more APs on the same channel, the more of an issue CCI becomes. It’s very difficult to do 5 GHz HD data or 5 GHz VoWiFi and not end up with a couple of 2.4 GHz radios on the same channel for the reasons mentioned + others. As long as the rest of the design is solid (low rates, etc.) This isn’t the end of the world. It’s not always as simple as disabling 2.4 GHz radios for the reasons mentioned + others and often not require or desirable!

    • Many thanks for taking the time to write a novel Scott :)

      Certainly lots of food for thought there – especially on the point of “AP resilience”. I’ve always tended towards thinking it was pretty much un-necessary as APs are pretty solid and if one fails you can quickly swap it out instead of looking to deploy a whole bunch of extra hardware ‘just in case’. But you’ve illustrated a whole bunch of other reasons it IS worthwhile deploying a more resilient configuration… Which I will definitely ponder on! On the surface of things 5GHz seems quite wonderful compared to 2.4, but it’s actually a bit of a complicated mess!

      Also a good point regarding leaving on those “spare” 2.4GHz radios – they might well be providing a fallback for issues with 5GHz.

      I’m not quite sure I understand the point about diversity antennas – I thought that MIMO was pretty good at making use of multipath and effectively replaced antenna diversity?

      Thanks again for taking the time to share your thoughts.

      • Well MIMO provides more throughput but besides laptops (and in the last ~2 years, some smartphones and tablets), pretty much no other client form factor supports MIMO. Even if you do have a 2SS client, that will provide an increase in throughput but as the second antenna is being used for that purpose, it’s not helping with diversity so you need a third antenna on the AP then.. and of course 802.11n introduced a whole bunch of new diversity and associated methods of increasing signal strength on either the client or AP side.

        But in my example I was talking about the Cisco 792x phones which is a/b/g and the issue is the lack of diversity on the phone itself so they don’t handle multipath as well without LOS to the AP.

        • Ah, got you… I was focused a bit blindly on the AP side of things without considering the capabilities of clients; thanks.

  3. Nice post Jon. Interesting reading as its a question I have pondered myself in design. Scott’s comments about AP resiliency are good and valid but, as I work in the same role as you, there is a fine line between what we can justify to a customer and what just looks like milking the cow in a competitive tender environment. Personally how I have settled on my designs is manufacturers recommended RSSI everywhere required with the secondary RSSI in any location that roaming needs to occur. So in your example, inside the classroom there is no need to roam only on entering or leaving so if the secondary RSSI is met at the doorway I see it as requirement met. In 99% of the scenarios this works for me.


Submit a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>