The False God of dB

The False God of dB

By CWNP On 05/02/2009 - 3 Comments

In the Wireless LAN (WLAN) world, we have started to worship in front of the False God of dB.

Books, white papers, study guides, and design manuals have touted the value of the RSSI (dB) so much we have used this as a sole way of designing and evaluating our Wi-Fi Networks. dB is a false god and we need to mature and move past having ‘Signal’ be our main goal in WLAN designs!

Signal is Immensely Important!

I’m not in the least bit saying Signal levels – RSSI – is not terribly important in our WLAN designs. It is critical, required, and even mandatory. But RSSI alone is not sufficient.

To give an analogy of a wired network, consider connectivity.  It’s the ability of copper pairs to conduct electricity at a certain level, and it’s paramount in getting wired networks to work.  

dBm is to a WLAN what connectivity is to a Cat6 cable. It is a base level requirement. Without it, nothing works.

Compared with Category 6 Cabling

But just as connectivity in a Cat6 cable isn’t the only factor in determining whether or not a cable run meets the design characteristics, RSSI (signal strength) isn’t the only factor in determining whether or not a wireless network meets its design characteristics.

Cat6 cable actually means cable that meets the Category 6 physical requirements as defined by the TIA/EIA organization.  These requirements include:

•    Connectivity
•    near-side crosstalk
•    far-side crosstalk
•    pin-outs
•    cable twist ratios
•    and more

Much more than simple connectivity alone!

In a WLAN design, a certain level of signal strength is required, but signal strength alone is not sufficient.  We have yet to find a wireless industry group to take on the responsibility of defining the specifications for a ‘voice-grade’ WLAN or a ‘video-grade’ WLAN, let alone even a generic ‘data-grade’ WLAN. We are still in the early stages, and each vendor is still defining their own specifications.

WLAN Design Specifications

I’ve started a new project working with other CWNEs to develop a WLAN Design Matrix to help codify and analyze the various vendor recommendations for design parameters to make their client devices work on WLANs. As an example, VoWiFI devices need specific dB, overlap, jitter, latency, packet loss, DTIM intervals, etc.

In this early stage of the process, we have already defined nearly one hundred unique identifiers and specifications collected from the various WLAN vendors.  Of course the first one is always ‘RSSI’ – or Signal Strength defined in dB - but that is merely a baseline.  On top of the Signal Strength, there are many more categories of WLAN requirements.

Some vendors require an ‘Overlap’ (see my blog post on the fallacy of channel overlap ).  Other vendors specify the co-channel interference at very specific levels.  Still others add data rate support, number of devices per AP, minimum MCS requirement, and many more.

Some of the requirements are based on designs for the STAs (clients), and others are specifications for the Access Points and cabling.  Together all these requirements must be met in order to deliver a WLAN infrastructure that will work with the vendor’s devices.

Do you know all the design specs for your Wi-Fi enabled client devices?

How can you tell if your WLAN meets those specs?

Car Analogy

In my consulting practice and WLAN training classes, I like to give the following analogy concerning the design of WLANs.

While working with a vendor in the auto industry in Detroit, I was frustrated by their lack of understanding of why their WLAN, which was originally designed for data and was currently working well, was failing so miserably as a VoWiFi network.  My explanation led to the following analogy:

You are an automobile designer, and your boss comes to you and asks for a new vehicle design.  A vehicle is defined as a system of wheels/tires, engine/transmission, seats, frame, and chassis. They have asked for a vehicle that can carry two adults, travel at freeway speeds, and carry a 2200 lb payload. You might answer, “That’s easy.  I’ll build you a truck!”  The truck would meet all their design specs, and everyone would be happy.

If, at a later time, your boss asks you to design a vehicle that can do 0—60 mph in less than 5 seconds, with great cornering characteristics and a very low drag coefficient, then you would likely design a small, lightweight, high-powered, sports car.  All would certainly be pleased.

Finally your boss requests a vehicle that can comfortably carry seven adults with their luggage, has lots of cup holders, and allows easy entry.  You would likely design them a mini-van.  Again, all would be pleased.

The problem surfaces when the truck owner thinks to himself, ‘Since my truck is a vehicle, it should go from 0-60 mph in 4.2 seconds.’  Almost as an afterthought the truck owner asks you to make his truck become a fast sports car.  

Sure, it’s possible, but at a significant cost.  You could take out the old engine and replace it with a much stronger one, but since the truck was originally designed for carrying a heavy payload, it is built with a heavy suspension and dual-I-beam construction.  In order to get it to have a fast race time, you’d also have to replace many of the ‘guts’ with carbon fiber composite parts!

Even after all that work, it would no longer be a good truck, nor a fast sportscar.

 

Certified Magazine Readers

Sometimes our bosses are like the bosses in the above vehicle analogy. They have read something in a magazine about WLANs doing Voice over IP, Video, or even Location Tracking.  They come to the IT folks asking to simply ‘add’ this feature to the existing WLAN infrastructure.

Many of the design characteristics of these newly requested services require, indeed demand, mutually exclusive design goals!  

For example, the VoWiFi WLAN might be the sports car design since it doesn’t carry a lot of payload.  Yet the VoWiFi network needs to have very high tolerance and characteristics for the small set of data it does carry.  

For example, VoWiFi vendors define the following detailed specifications:

• Minimum RSSI    >= -65dBm
• Backup/Second AP at     >= -65dBm
• Signal to Noise Ratio    > 19dBm
• Maximum Noise Floor    < -90dBm
• Maximum Jitter    < 5msec
• Maximum Latency    < 50msec
• Maximum Packet Loss    < 1%
• Total End to End Delivery    < 150ms
• DTIM Interval    2
• Channel Overlap    25%
• Roaming Time    < 150msec
• Required Data Rate    1Mbs
• Co Channel Separation    > 19dBm
• Roam to 2nd AP if    >= 5dBm higher
• Roam back to 1st AP if    >= 10dBm higher
• 802.11e QoS    Required
• Fast Roaming    Required
• Multicast Enabled    Required
• Specific Codec    Required
• Maximum Calls per AP    <= 7
• 
  
• And even more…
  

Obviously the minimum RSSI in dB must be met, but note all the other detail specifications that also must be met.

Designing networks with just dB in mind will no longer work!

Web Surfing and large file transfers are more concerned with the size of the ‘pipe’ and can easily live with retries and temporary changes in the quality of the pipe.  (the Truck)

RFID tagging and location tracking needs to have lots of access points in specific locations to support accurate triangulation, but those extra APs can cause more co-channel interference and make larger collision domains, thus lowering throughput. (the Mini Van)

Just because your boss read in a magazine about another company’s fast sports car, doesn’t mean your company’s truck will be a good vehicle to use in drag racing!

Know Your Design Requirements

My clients constantly amaze me when I ask them to specify (list) the design requirements of their WLAN devices.  They rarely know what the design characteristics are for their own devices!

I ask you: If you don’t know what you are designing your WLAN for, how can you know when you’ve achieved the proper WLAN design?

In the automobile industry, no designer would willingly take on the job of designing a ‘vehicle’ without first understanding the detailed characteristics that are being requested.  

In the wired network world, no ‘cable-puller’ would start pulling barbed-wire to each desktop!  Barbed wire will easily meet the ‘connectivity’ goal, but obviously not any of the other Cat6 specs!  

Yet somehow in the wireless LAN world, we allow ourselves to do just that.  We design our WLANs without specific design goals, we design for only ‘coverage’ (dB), and then we later wonder why the WLAN doesn’t work…

If you don’t know the specific design parameters your client stations require, your WLAN can NEVER meet those goals!

Conclusions

Yes, Yes, Yes, and Yes… dB is VERY IMPORTANT! But it is NOT the ONLY goal around which you should be designing.

You don’t design wired networks with ‘barbed-wire’; so don’t design your WLANs with ONLY dB!

Additional Articles for Supporting WLAN Site Surveys
- 7 Rules for Accurate Site Surveys
- How to 'Cheat' On A Survey - Don't be a Victim
- How to Properly Analyze Survey Data
- The Fallacy of Channel Overlap
- Predictive Survey vs Onsite Survey - What's the Big Deal?
- How to 'Spec' your Network's Physical Layer
- Want, Don't Want, Don't Care - Meeting Design Specs
- The Truth about SNR - Where Did that 'N' Come From Anyway?
- What is an Access Point Anyway - Hub, Bridge, Switch or Router?
- Passive vs Active - What's All the Fuss About
- The False God of dB
- Meeting All Device Design Parameters

http://wlaniconoclast.blogspot.com

Blog Disclaimer: The opinions expressed within these blog posts are solely the author’s and do not reflect the opinions and beliefs of the Certitrek, CWNP or its affiliates.