How To Save Cellular IoT From Itself


Wireless carriers like to hype new data capabilities. If you know technologies like WiMax or CDPD, you know how the cellular industry can overpromise. And if you are working in the IoT, you are probably hearing industry propaganda about their upcoming “low power wide area networking” (LPWAN) IoT technologies. LTE Cat M1 (especially in the USA) and LTE NB-IoT (Europe and elsewhere) are their emerging radio standards. And to compound the FUD even further, these are soon to be upstaged by a 5G LTE, which you can pre-order today for delivery in Q2 in 2026.

Huge bets are being placed on the success of LTE in the IoT, and while LTE will have success in the LPWAN arena, many investors will be disappointed. Here are a few thoughts on why and one recommendation for shoring things up.

Cellular IoT Will Target Consumer Markets

The strengths that carriers bring to LPWAN’s — and this is just shorthand, you can read more here and here — is going to be in the simplicity of system setup and management, their massive customer installed bases, and the ability to bundle IoT solutions into a customer’s monthly bill with other offerings. Total cost of ownership will be high relative to non-cellular LPWAN substitutes and battery life will disappoint. This has one target segment written all over it: consumers.

Weak battery life and high TCO is something carrier marketing departmetns can finesse with consumers. That monthly bill is a marketer’s Disney World of possibilities. And if they are mad, they can always call customer service …

Industrial + Enterprise Markets Are Challenging for Cellular IoT

Enterprise and industrial customers (I’ll just say enterprise for the sake of brevity) in the overwhelming majority of cases require a different product and ultimately, different distribution channels. But this won’t stop the carrier sales and marketing departments because their new LTE IoT story is a hammer for which there are no nails that are impervious to their pounding.

Addressing enterprise markets with LTE-based LPWAN’s, as I’ve noted previously, is fraught with risks. I won’t say there is no enterprise opportunity, rather it’s just not going to be the sweet spot. And for investors in cellular IoT, this is a problem as the lion’s share of IoT revenues lies not in consumer, but in enterprise/industrial IoT markets.

To Penetrate The Enterprise, Look At Your Stack

So, for the hard-nosed cellular IoT strategists out there who both intend to invade the enterprise but who recognize the weaknesses of the current LTE products, focus first on your networking stack.

TCP/IP was built for AC-powered networks with wires. Like the internet. For streaming huge files via HTTP or FTP. It was not designed for wireless networks and it was most definitely not designed for low power wireless sensor networks. It is bandwidth intensive, power hungry, and by today’s standards, almost comical in the way it establishes a connection between two computers. But legions of developers know TCP/IP so … in their eyes many IoT problems are just nails waiting for the TCP/IP hammer.

Since the LTE community has for years had the luxury of working with large amounts of wireless bandwidth for carrying voice calls or streaming video, we should not be too shocked that they want to try TCP/IP for the IoT.

For AC-powered IoT conections with lots of available wireless bandwidth, this might be fine. In fact, cellular carriers for years have touted their “M2M” capabilities that do just this.

But there’s nothing “low power” about cellular’s M2M past and nothing low power about TCP/IP. But this is not another low power rant — we will all just have to see for ourselves just how many “years” of battery life we see from our forthcoming LTE-based IoT devices, but I tend to think they are talking in dog years while we are talking about human years.

No the real issue with TCP/IP is how it won’t (really) support LTE’s inevitable foray into the enterprise.

Bonus Thought: anyone who uses the term “TCP/IP” in conjunction with “low power wireless networking” is most likely exaggerating battery life and likely in a big way.

Augmenting or Replacing TCP/IP for LPWAN’s

To provide the enterprise with the type of application functionality they need for their LPWAN deployments, the cellular industry must look beyond TCP/IP.

For example, a real-world IoT pain point we at Haystack see every day is how to solve for indoor location using a LPWAN technology. Lately, we’ve seen lots of interest in Semtech’s LoRa product but also other sub-1GHz technologies. Now, we’re being asked to solve for this for LTE. So here are a few slides that describe our approach:

Basically, we advocate the bolt-on of a companion (< 30 KB) real-time low power networking stack to LTE in order to enable real-time indoor location for applications like supply chain, IT asset tracking, healthcare, and much more. In addition, this solves for the problem of the “indoor-outdoor” IoT, where assets, people, and things may move from wide area (WAN) environments and into local area (LAN) environments and still require connectivity and location in both cases. More on this here.

A related problem with using TCP/IP in these cellular devices is peer-to-peer networking. If you are like me and think the cloud is way overhyped as an IoT tool, the ability to interrogate a LTE-based IoT endpoint on a P2P basis and in real-time will be a significant part of your solution. A weakness for the LTE IoT is its inherent “cloud”-centric nature when the rest of the world is moving to “fog” computing. (Or, if you work with Haystack, we take computing all the way to the endpoint, but this is another topic altogether …) The move towards the fog is especially acute in enterprise markets which turns the cloud into a sort of millstone hanging around the neck of an LTE IoT industry that can’t, almost by definition, de-cloud itself.

Final note: telco’s parting ways with the networking stack that got them to the dance will be hard, but with the IoT it’s clearly time to reassess.

Leave a comment

Your email address will not be published. Required fields are marked *