Category Archives: IoT

Mighty mioty and a Bit of IoT Knowledge

Like many of you, I get a lot of emails announcing some new thing going on under the general heading of technology. Most get a quick glance, register as either ho-hum or not of particular interest, and then get quietly flushed out my email box’s septic system. But a recent announcement regarding mioty gnawed at me. I wasn’t sure why, and then it hit me…

Why do they not capitalize the M?

Somehow I didn’t know that mioty is a competitor to LoRaWAN when I scanned the email, but I do know that the announcement covered the first “mioty Blueooth Low Energy Dual Stack“. EVERY WORD WAS CAPITALIZED EXCEPT MIOTY AND IT FREAKIN DROVE ME NUTS.

Yeah, I know- that’s probably a weird reason to be paying attention to a new-to-me technology… but truth be told, it was enough to hook me. I started digging in.

So Much to Learn

One of my several during-COVID areas of self-study is IoT. I got into LoRaWAN and a few others, I’m starting down the road of CWNP’s IoT-related certifications, and I give my RF Explorer and other spectrum analyzers/SDRs frequent workouts trying to capture fleeting little low-power pulses from all sorts of gadgets. I do know that “IoT” is one of those oft-abused words that some vendors try to own in their marketing of Wi-Fi systems, but the concept of IoT is far-ranging, very Un-Wi-Fi at times, and maybe even endless, when you think about it.

So.. I’m not completely IoT-ignorant, yet little-m mioty had never registered in my brainpan to date. If you too are in the dark, let me get you started. Think massive IoT. There’s an Alliance. Stolen from the mioty Alliance’s web pages, the following describes what differentiates this technology from others in the space:

The core invention behind the mioty technology is the Telegram Splitting Multiple Access (TSMA) method. As defined by the European Telecommunications Standards Institute (ETSI TS 103 357), Telegram Splitting splits the data packets to be transported in the data stream into small sub-packets at the sensor level.

These sub-packets are then transmitted over different frequencies and time. An algorithm in the base station permanently scans the spectrum for mioty sub-packets and reassembles them into a complete message. Due to sophisticated Forward Error Correction (FEC), the receiver only needs 50% of the radio bursts in order to completely reconstruct the information. This reduces the impact of corrupted or lost bursts due to collisions and increases the resistance to interference.

That should tickle the fancy of anyone who claims to do wireless…

Combine mioty and Bluetooth for Fascinating Scenarios

So now you have a starting point to go learn more about mioty, if you needed one. Let me bring you back to the announcement that started this whole thing for me- a company called BehrTech combining forces with Texas Instraments to put mioty and the latest Bluetooth (BLE 5.2) on a single chip. Remember, Bluetooth operates in 2.4 GHz, and mioty is “sub-Gigahertz” meaning 868 MHz in Europe and 915 MHz here in the states. Hopefully for some of you, just knowing the frequencies involved have your mind going… Bluetooth is a pretty short-range PAN technology, while mioty can go much, much, much farther riding those 915 MHz radio characteristics of distance and penetration. Meaning that mioty can backhaul Bluetooth traffic to other parts of the same network over large distances. All from the same chip.

This is the kind of announcement I like, as it leads to me learning something.

But why the little m?

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.