Category Archives: IoT

It’s Time for YOU to Get Wise About CBRS

CBRS search

It stands for Citizens Broadband Radio Service, and has nothing to do with CB radio despite the similarities in the acronym. It’s time for my fellow Wi-Fi types to start paying attention to CBRS for real, and I’ll explain why in a bit.

A Quick Look Back to 2105

The CBRS thing been simmering for at least a half-dozen years. Let me quickly take you back to 2015, where I sat in on a related session at Wireless Network Field Day 8, by Dave Wright. Back then, Dave worked for Ruckus Wireless, now he’s the Director of Regulatory Affairs & Network Standards at CommScope, and President of the CBRS Alliance. Dave’s a fantastic gent, if you ever get the chance to talk with him. But even though that 2015 presentation could not have been delivered by anyone better, it still felt kinda faraway and foreign to the ears of a room full of Wi-Fi folks.

Almost There- 2019

But 2015 gave way to the future, and Dave’s vision very much would come to fruition. Sticking with Field Day, I was fortunate enough to go to Mobility Field Day 4 in 2019. This time the presenting vendor on the topic was startup Celona (new company, but staffed with some deep wireless experience and familiar names to us in the WLAN industry). At the time Celona presented, CBRS had long since advanced from being a twinkle in the eye of folks like Dave Wright, but still wasn’t quite ready for market as a production option for Private LTE and other applications. (What other applications? There’s a good paragraph on that in this Network World article.)

Early 2020- The FCC Opens the Floodgates for CBRS

Just a few weeks ago (it’s mid-February as I write this), the FCC delivered the news that everyone with a stake in CBRS, Private LTE, and in-building cellular was waiting for: the 3.5 GHz spectrum was officially available for sharing for these applications. Here’s a good article on that, along with the FCC’s own reference pages on 3.5 GHz.

Now things are moving… and we get to why we as Wi-Fi folks need to start paying attention.

Our Turf is Soon to Be Trampled On

I find the marketing blather that has 5G making Wi-Fi extinct, or that has Wi-Fi 6 making cellular irrelevant, to be pretty asinine. But then again…marketers. Whatever. It’s pretty clear that several trains have left the station, and they all will impact our environments and possibly/hopefully our employment, skills, and project opportunities.

Wi-Fi 6 is a given- it’s what comes next for us WLAN doers. 5G has new relevance given that a small cell will need to bolted up to every street light, cactus, bus stop and homeless person to get the coverage and performance that the mobile industry is promising out of Millimeter-wave 5G systems. Bringing 5G (or even 4G) inside of modern RF-unfriendly buildings gets us back to discussions of CBRS and private LTE. And so does the notion of industrial settings where maybe LTE-style wireless makes more sense than Wi-Fi for wireless connectivity, for a number of reasons.

We need to not only understand the changing wireless landscape, but also to embrace it and try to stake our claims in it.

Get Educated

There are no shortage of general-information articles out there for CBRS, private-LTE, etc. here’s a great one from Corning (I just spoke with them on this topic, but that will be it’s own blog). And there is certainly a lot of marketing floofypoo to be stepped around.

But if you want more formalized learning, check out this offering from CommScope. I have not taken it yet, but have heard good things from esteemed colleagues who have. Coursera also has a CBRS offering, and I have every reason to believe that CBRS will eventually manifest itself through CWNP’s excellent training materials in some form or fashion.

So… why care about CBRS? It’s here, for real, for starters. It’s being deployed. Someone needs to design it’s coverage, and tools like iBwave are already being used by many of us to do Wi-Fi. Why not get a piece of the new pie? If we don’t, someone else will. People are gonna luuuuuuv their Wi-Fi 6, yet are still going to demand rock-sold in-building cellular after spending fat coin on those $1K+ mobile devices and as more devices become “wireless” in every possible definition of the word.

This is the new world, my friends. Digital transformation, blah blah blah. There’s no escaping it.

One Example of the Just How Clueless and Misleading Wireless Device Makers Can Be

Sigh… Stop me if you’ve heard this one- A wireless device maker sells something to an unwitting customer on, shall we say, some stretched truth. The pitch that led to the sale isn’t quite the proverbial pack of lies, but certainly left out key information that may have doomed the deal if the customer had a clue about what questions to ask (or had involved their IT staff before writing the check). A fairly limited-capability WLAN client shows up, and suddenly the network has to flex itself in unsound ways to accommodate devices that arguably shouldn’t have been purchased. Can anyone relate?

Security “Lite”… or is it Security “None”?

Here’s my current problem child.

54512AA0-8B15-4C5F-A874-FA66062FFAD6

That’s a time and attendance clock. It’s networked, and it talks to a server out in the cloud. It can use a wired Ethernet connection, or dual-band wireless (we’ll talk about that in a moment). Yay! Cloud! Yay! Wireless! Perfect for just throwing several dozen in and and off they go, because you have a wireless network- it’s a slam dunk, baby!

But it’s not a slam dunk. Because the network it’s likely to land on very well might just be an Enterprise-secure WLAN. That means it doesn’t use living room grade pre-share-based wireless security. Yet the best you will get out of this particular time clock IS living room grade security. It doesn’t support 802.1X authentication or WPA2-Enterprise CCKM encryption.

What happens if you don’t have, and don’t want, a PSK-only Wi-Fi network in a large secure enterprise environment just because someone made a questionable purchase of a WLAN feature-constrained time clock? You don’t have a lot of choices, and the couple that you do have smell and taste bad. Ah well- at least it’s DUAL-BAND WIRELESS.

Yeah… sure it is.

Radios in a Lil’ Faraday Cagey Kinda Thing

I was pleased to hear that the clock was at least an 802.11ac device. Because the environment it will work in does NOT have a PSK network and the clock can’t do enterprise security, it will go on an open guest network with MAC exception so it can bypass the guest gateway (relying on application-layer security to encrypt the data involved). So, I needed the wireless MAC address to set up the exception on the test unit. It was not printed on the clock or packaging, so I opened the device to see if I could find it inside.

I did locate the WLAN adapter’s MAC address, but had to remove the adapter to read it. The clock uses a StarTech USB433WACDB which is in fact dual-band .11ac in spec. But the environment needs to be right for wireless thingies to work to their max performance spec, and things are far from environmentally right in this clock enclosure. The little USB adapter has no external antenna that might help the situation, and sits behind a circuit board and a metal plate inside the clock, with the back of the enclosure and ultimately the wall that the clock will mount on behind it.

Given the RF-unfreiendly location of the adapter inside the clock, I was curious if it would connect at 5 GHz. Here’s where I will admit that my testing was not exactly methodical, but I’ll tell you what I saw and did.

This clock came to life about five feet away from a dual-band access point in the same room, with a couple more dual-band APs beyond other walls but still within range. It first connected on 2.4 GHz. I moved it right next to the AP, and it again connected at 2.4 GHz. I disabled the 2.4 GHz radio on that closest AP, and the clock connected to a farther away AP, using 2.4 GHz. So… it doesn’t look good for “dual band” here. I did not sniff packets to see if the clock is trying in 5 GHz, so I can’t say that maybe it’s not a driver or dodgy band-steering issue. But I can say that in initial testing the clock certainly doesn’t appear to be realistically dual-band despite the adapter spec.

And so it goes…

At the end of the day, this is far from my biggest problem. I’ll hold my nose and get the clocks to work, but it is work calling out the reality that not only are not all wireless clients ready for the business WLAN, sometimes they aren’t even what they claim to be at all in spec because of the way they have been built.

We are collectively in the 5th generation of major Wi-Fi technology with .11ac, with .11ax around the corner. Our WLAN infrastructure systems are advancing with rediculously rich feature sets beefed up with every code release, yet the client device makers seemingly operate on another planet where getting in sync with business WLAN requirements doesn’t seem all that important, given that these clocks are just one very typical example.

Ah well. I realize that nothing told in this narrative is news, but at the same time it needs to be talked about once in a while. Part of that discussion is hoping for better days on the client device front. And part of it is channeling a rant into a story that you can share with others so that they know they are not alone in their own frustrations.