Skip to main content

Is there a need for a Spectrum Policy within the Enterprise?

I recently came across this some equipment that interfered with Wi-Fi in the worst way – well, that’s my opinion, and I will let you be the judge.

 

We’ll first start out with stating the obvious.  The 5GHz UNII bands are license free, which means it is a free-for-all when it comes to who is doing what.  Most of us (the folks reading our blogs) all understand that.  However, when an Enterprise environment has millions and millions of square feet of office, retail, healthcare or manufacturing space, I think the Company’s Enterprise IT department owes it to their internal customers to have a Spectrum Policy to keep the spectrum in check.  Letting the company buy whatever they want, whenever they want, and deploying it randomly as they see fit, doesn’t work well, as you will see if you continue reading.

 

I recently came across a surgery center consisting of 8+ operating rooms, and the Wi-Fi was at the core of the complaints.  Nurses had to move their mobile workstations outside of the operating rooms in order to maintain a connection.

 

We went in with protocol analyzers at midnight and saw nothing.  We went in at 6pm, and saw nothing.  Then we went in during working hours with our Spectrum Analyzers, and that is when we saw a big difference!  We observed channel 40, in the 5GHz range, pegged at 90+ percent duty cycle, for well over an hour. 

 

Okay, so what, you think.  One channel – no big deal, right?  Most Enterprises use UNII-1,2 &3, so there is likely another channel readily available at a -67dBm. 

 

 

It took us a while to track down the equipment, as we didn’t want to go into an operating room while they were doing their business.  After several days of intermittent troubleshooting, we finally came to the conclusion that our source was mobile.  We tracked it down to Operating Room “towers”, which were mobile Endoscopy equipment.  The gear has a wireless transmitter and a remote monitor or two, and those remote monitors were connected via the 5GHz spectrum.  This equipment was moved around to whichever Operating Room need it.

 

 

 

 

Then we discovered something else.  When the equipment was turned on, it searched for a channel to use.  Not in a very Wi-Fi friendly way, though.  It seems as if it always starts on channel 36, then works its way around the first eight channels until it finds “home”.

 

 

 

 

What does this do to your Wi-Fi when this is happening?  If the RED color doesn’t spell it out for you, then nothing will!

 

Just to prove our point, we took our active survey access point (yes, we actually do “active” site surveys still) and put it on channel 36 and associated three clients with continuous pings to it.  We turned on the Stryker gear, and not only did the pings cease, the three clients no longer saw our site survey SSID, and then decided to join another WLAN on another channel.

 

In a nutshell, it obliterated the channel for however long it decided to rest there. As you can see from our swept spectrogram, there is no real pattern.

 

We also used two different spectrum analyzers that we happened to have in our kits that week.  Not saying that one is better than the other, and if we didn’t use one that isn’t here, it isn’t because we don’t like it.  We just happened to have both of these with us, and that’s what we used.

 

The screenshots below are from just one transmitter and one receiver pair.  Imagine a surgery center with ten operating rooms along with five of these units online, coupled with the different schedules and the appearance of random Wi-Fi issues.  When these units boot up, they search for the channel they want, obliterating the spectrum as they go.

 

 

 

 

 

 

 

If there was a Spectrum Policy, this kind of thing might be avoided.  The 5GHz bands can be divided up within an Enterprise, with UNII 1,2&3 reserved for Wi-Fi, and UNII-2e further divided up for cameras and other gear.

 

What are your thoughts?  Is it worth the investment to put together and enforce a Spectrum Policy?

 

 

 

 

 

 

 

 

Comments

Post a Comment

Popular posts from this blog

Build your own Ekahau ePerf & Speedtest.mini server!

One a recent forklift project, we decided to replace our aging 802.11a/g hardware and deploy new 802.11ac WLAN gear.   We designed the building with Ekahau’s ESS - our default WLAN survey and design tool.  After designing the WLAN to meet our healthcare requirement (in this case, Aeroscout tags, Vocera badges, 5GHz Voice and data) we installed the gear and then validated the WLAN.   For this initial 802.11ac deployment, we decided to do both passive and throughput validations.  With throughput surveys, we measure actual data, such as packet loss and jitter.   On a side note - for some time now, we have said to ourselves, “I wish we had a portable Ookla Speedtest server”.   Spoiler alert!   We needed a throughput server that would be both simple to use and portable.  After talking with our Ekahau team, we decided to use the Odroid C2, and configure it for two purposes.  (It turns out that Ekahau has done the homewor...
1 comment
Read more

5GHz WLAN Site Survey AP power settings - What you want, don't want, and don't care about.

  I often see the requirement that a WLAN site survey and design must be done by the AP-on-a-stick method.  That said, you’ll want to use the same AP for your survey that you will use in production – or one that is similar.  In this case, we are going to convert a lightweight access point to Autonomous, so that we can use it without a WLAN Controller.  The new survey rig is a Cisco 3602i, configured with 5GHz channel 157, set to 40 MHz. How did we turn the lightweight AP into an Autonomous and do the quick and drity configuration?  The short answer is, we followed Richard McIntosh’s directions.  His blog, and a great “HowTo” is here: https://ciscotophat.wordpress.com/2013/01/05/configuring-a-3602-for-wireless-surveying/   Thanks again, Richard, for putting that out there for everyone to read. We altered the power output of the new survey rig as sort of an experiment to see how the signal propagated, and where our -67dBm an...
Post a Comment
Read more

Proving "It's not the Wi-Fi network"

  We’ve all been there – or at least most of us have, anyway.  The Wi-Fi network appears to be misbehaving and users are frustrated.   Your users will be working for several hours, and then, it looks to them as if someone shut the entire WLAN off.  Their workstation’s Wi-Fi icon, when hovered, states “no Wi-Fi connections are available”.   Now comes the fun part – well, to me it’s fun, anyway.  Let’s start out with what the normal operation of the WLAN client looks like.  This particular client is stationary.  It’s a laptop that is used like a stationary desktop, and is cabled to the desk via lock and key.  I wanted to clarify that because you won’t see any roaming in this packet capture, and you shouldn’t see any.   Since the client is associated to an AP on channel 36, I set my protocol analyzer to only look at that channel, and then set a filter to only look at the clie...
Post a Comment
Read more