When people hear "IoT," most picture a smart thermostat or a fitness tracker. They think it is about connecting a device to the internet and reading the data on a phone. That is a bit like describing a highway as "where cars go." Technically true. Completely misses the point.
IoT is a communication problem. And communication, whether between people or machines, has real physics behind it, real constraints, real tradeoffs. Ignore those and your product breaks in the field. Understand them and you start making decisions that actually hold up at scale.
I have been building IoT products for 15 years. Water meters that run on a battery for a decade. Rail sensor networks that communicate across kilometers. Security cameras that process video locally and push only what matters upstream. Every single one of those projects came down to the same core challenge: how do these devices talk to each other and to the outside world reliably, efficiently, and cheaply?
This post is the start of a series where I break down how IoT communication actually works, from the physics up. No spec sheet summaries. Just the real picture, with the tradeoffs spelled out.
Start here: communication is physical
Think about shouting to someone across a field. When they are close, you speak normally. As they move further away, you raise your voice. The further they get, the louder you have to shout, and the faster your throat gets tired.
Your device does the same thing. The further it needs to transmit, the more power it burns doing it. This is not a software limitation you can optimize away. It is physics. The radio inside your device is spending energy to push a signal through the air, and distance works against you every time.
This is why range and power consumption are always discussed together in wireless protocols. They are not separate specs. They are two sides of the same equation.
Bandwidth: a shared resource
Now imagine a crowded room where everyone is trying to have a conversation at the same time. The noise builds up. People start talking over each other. You have to repeat yourself. Some conversations break down entirely.
Wireless spectrum works the same way. The radio frequencies your device uses are shared with every other device in the area. Wi-Fi, Bluetooth, Zigbee, your neighbor's microwave: they all compete for the same airspace. When too many devices try to transmit at once in the same band, they collide, and data gets lost.
This is why protocols have channel access schemes: ways of taking turns so devices do not constantly talk over each other. Some use fixed time slots. Some listen before they speak. Some hop between frequencies to avoid congestion. Each approach has tradeoffs in latency, reliability, and complexity.
The further the device transmits, the more energy it burns.
Protocol structure decides who talks when, so data does not collide.
Why structure matters more than people think
Here is something I have noticed: people are comfortable with structure in everyday life without realizing it. You shake hands before a meeting. You say goodbye before hanging up the phone. You wait for someone to finish speaking before you respond. These rituals feel natural because they make communication reliable.
Device communication needs the same thing. A device cannot just blast data into the air and hope the server catches it. There needs to be a handshake, an acknowledgment, a way to know that the message arrived and arrived correctly. Without that structure, you end up with data loss, duplicate messages, out-of-order packets, and systems that look fine in the lab and fall apart in the field.
This is what wireless protocols are, at their core. They are structured agreements between devices about how to talk to each other. When to transmit, how long to listen, how to handle errors, how to authenticate. The protocol is the rulebook that makes communication reliable at scale.
The three constraints every IoT product lives inside
Range. How far does the device need to communicate? A sensor in a factory talks to a gateway 20 meters away. A water meter buried in the ground talks to a gateway 2 kilometers away. These are completely different problems requiring completely different protocols.
Power. How long does the device need to run on a battery? A product that lives on mains power can afford to keep its radio on all the time. A sensor running on two AA batteries for five years cannot. The protocol choice, the antenna design, the firmware architecture: all of it flows from this constraint.
Cost. What does the radio hardware cost at the volume you are shipping? A $4 BLE module is fine for 1,000 units. A $12 cellular module might not be. And the module is only part of it. You also pay for the antenna, the RF design work, the certification testing, and in the case of cellular, a monthly data plan per device for the life of the product.
These three constraints, range, power, and cost, are what make protocol selection genuinely hard. There is no protocol that wins on all three. LoRaWAN gives you incredible range and excellent power efficiency, but low data rate and shared network infrastructure. BLE is cheap and ubiquitous, but short range. LTE gives you global coverage and reliable connectivity, but it costs money every month and burns power fast.
What is coming in this series
Over the next several months I will go through each major wireless protocol in detail: LoRaWAN, BLE, Wi-Fi, LTE Cat-M1, and Zigbee. For each one I will cover how it actually works, what the PCB design implications are, what the real power numbers look like in production, and when you should walk away from it.
Then I will compare them side by side and put together a practical framework for picking the right one for your product.
If you are building connected hardware, or evaluating whether to, this series is for you. Follow along on LinkedIn for the short version each week, or read the full breakdowns here.
Next up: What makes an IoT product actually production-ready? There is a big difference between a prototype that works in your office and a product that survives in the field for five years.