ISM Congestion - or - How I Learned to Stop Worrying and Love Unlicensed Spectrum

The industrial, scientific and medical (ISM) radio bands are something you rely on daily and yet have probably never heard of before. You are likely more familiar with the devices and technologies that use it:

  • Bluetooth
  • WiFi
  • Zigbee
  • Microwave ovens
  • Wireless doorbells
  • Wireless weather stations
  • Wireless alarm systems
  • Cordless phones
  • Wireless USB
  • Wireless NTSC video links
  • Wireless proprietary HD links
  • Model airplane and car RC controllers
  • etc.

And now, welcome to the party smart power meters!

The FCC first allocated the ISM bands in 1985 with a novel twist - unlike most frequencies, you would not need a license to transmit on these bands. Unlicensed use opened many opportunities in the marketplace, but there was another aspect to the allocation that most people overlooked - ISM devices must tolerate any interference generated by other ISM equipment, and users have no regulatory protection from interference generated by other ISM equipment.

At the time, this was an amazing greenfield of spectrum and manufacturers quickly took advantage of the unlicensed nature of the spectrum (while quietly overlooking the interference limitations) and deployed to consumers the plethora of products on the market today.

WiFi Leads the Charge

In the US, the most commonly used band is 2.4GHz and in the late 1990s, WiFi became by far the most common use of it. As Associate Director for Networking at Texas A&M University at the time, I was beginning to feel the pressure to deploy WiFi. Since the first iterations had no security it was relatively easy build a case against it - for the time being.

While security was a big problem for WiFi for a number of years, it really wasn't the root of my concern. It's taken 10 years for it to play out, but the real problem is the interference clause. At first, you couldn't guarantee the performance of any ISM application and people lived with that. However, the ever increasing congestion is now taking the situation to the point where you might not even be able to guarantee basic operation of an ISM application.

Visualizing Wireless Congestion

In case it is hard to imagine how this situation can exist, consider a room say 20'x20' with 4 people in it. They each are positioned in random locations in the room and are paired up by two in two different conversations. The shared spectrum in this case is the frequencies the human voice can generate and that the human ear can detect. In general, this setup is annoying but should work. You might have to ask someone to repeat something on occasion but the two conversations should be able to continue successfully.

Now take that same 20'x20  room and randomly place 20 people in it with each pair having 10 different conversations. Typically, in the real world, people would just start shouting to each other and limp along. Unfortunately, the ISM band has a power limit - basically restricting everyone to conversational voices at all times and under all conditions. The result in this case is that almost no conversation will progress at all.

That's the situation we are approaching today with the ISM band.

Russian Roulette

In the event industry, WiFi is both a boon and a headache. When you need to deploy computer networking at an event, there's nothing better than wireless. There's no cables to run which means little to no labor and supply costs; what's not to love! The problem is the game of Russian Roulette that gets played when the event gets started. Some of the things that can happen:

  • The venue actively jams you because you did not buy WiFi service from them
  • The 20 other WiFi units deployed by other vendors within 100' of your setup congest the spectrum
  • The 1000 cell phones carried by your visitors with WiFi enabled on them show up after the doors open

The end result is your WiFi network craters and literally will not operate. And due to the "must accept interference" clause, there's absolutely nothing you or the manufacturer of the equipment can do about it. There is literally no way to "make it work". When you explain this to people who don't understand the nature of the situation, they are floored by this fact and actually have a hard time believing you (though this incident educated a whole lot of people).

For me with experience as both a designer, builder and operator of enterprise networks, this is my real problem with ISM applications. There is no way to deploy an ISM application and guarantee the user of it any reasonable level of performance.

For years, the lack of congestion has made the odds of a problem occurring relatively low - basically, there was only one round in the chamber in this game of Russian Roulette. But as ISM congestion gets worse, we are loading more rounds into the gun - as the story about the wireless power meters shows.

Is it all hopeless? Will the ISM equipment market crater as more people play the odds and lose? Or will we all just muddle along and get used to it? Or is there a way out of this mess? There are some technologies on the horizon that might still save the day but that will be the subject of a future post.