IoT Networking

Traditional networks assume abundance. Bandwidth is plentiful. Power comes from the wall. Devices have gigabytes of memory and processors that can handle complex protocols. When something needs updating, someone can walk over and fix it.

IoT networking assumes scarcity. A sensor might run on a coin cell battery for five years. It might have kilobytes of memory, not gigabytes. It might sit on a pipeline in the desert or embedded in concrete. And there might be millions of them.

This changes everything.

The Constraints That Define IoT

Traditional networks ask: "How fast can we go?" IoT networks ask: "How little can we spend—in power, in money, in complexity—and still communicate?"

Power dominates every decision. A WiFi radio might drain a coin cell battery in hours. IoT devices need to run for years. This means sleeping most of the time, waking briefly to transmit a few bytes, then sleeping again. Every protocol decision, every network architecture choice, filters through this constraint.

Scale breaks traditional management. When you have ten thousand devices, you can't manually configure them. When you have ten million, you can't even manually monitor them. Everything must be automated—provisioning, updates, failure detection, recovery.

Cost compounds at scale. Adding $1 to a device costs $1 million when you're deploying a million of them. This pressure strips IoT devices down to the minimum viable hardware, which limits what networking stacks they can run.

Compute and memory are scarce. Full TCP/IP stacks assume resources that many IoT devices don't have. Protocols must be lean enough to run on microcontrollers with kilobytes of RAM.

These constraints don't just influence IoT networking—they define it.

Two Worlds: Long Range vs. Short Range

IoT splits into two fundamentally different networking problems.

Long-Range: Covering Miles with Milliwatts

Low-Power Wide-Area Networks (LPWAN) solve an almost impossible problem: communicate over kilometers using barely any power.

LoRaWAN can reach 10+ kilometers in rural areas on a battery that lasts years. The tradeoff is speed—data rates measured in kilobits per second, sometimes less. But for a soil moisture sensor reporting once an hour, that's plenty.

NB-IoT and LTE-M use cellular infrastructure, trading the unlicensed spectrum freedom of LoRaWAN for the coverage and reliability of existing cell networks. They're more expensive per device but require no network buildout.

LPWAN is for devices spread across farms, cities, and infrastructure—places where running power and Ethernet isn't practical, but where you need to know what's happening.

Short-Range: Dense and Local

When devices cluster in buildings or homes, different protocols make sense.

Bluetooth Low Energy connects wearables and beacons within a room. Zigbee and Thread create mesh networks where devices relay messages for each other, extending range without additional infrastructure. WiFi serves devices with power budgets generous enough to handle higher bandwidth.

The mesh topology is elegant: add more devices and the network gets more resilient, not more strained. But mesh introduces complexity—routing decisions, network formation, the overhead of forwarding other devices' traffic.

The IP Question

Should IoT devices speak Internet Protocol?

IP-based devices can talk directly to cloud services without translation. They're easier to integrate with existing Internet infrastructure. IPv6, with its vast address space, can give every sensor its own address.

But IP wasn't designed for devices with 2KB of RAM. 6LoWPAN compresses IPv6 headers to make them viable for constrained devices, but there's still overhead.

Non-IP protocols can be simpler and more efficient, but they need gateways to translate to IP for Internet connectivity. This adds infrastructure, cost, and potential failure points.

The industry is moving toward IP—interoperability wins in the long run—but the most constrained devices still use proprietary protocols.

Protocols Built for Constraint

Standard web protocols assume too much. IoT developed its own.

MQTT uses publish-subscribe messaging. Devices publish to topics; applications subscribe. The broker handles delivery, including queuing messages for sleeping devices. It's remarkably lightweight—a minimal MQTT implementation fits in kilobytes.

CoAP brings REST to constrained devices. It looks like HTTP—GET, PUT, POST—but with UDP transport and binary encoding that shrinks messages dramatically. A CoAP request might be 10 bytes where an HTTP request would be 500.

These protocols assume intermittent connectivity. Devices will disappear and reappear. Messages might need to wait. The network must handle this gracefully.

The Security Paradox

IoT security faces a contradiction that has no clean solution.

Strong encryption requires computational resources. IoT devices are resource-constrained. The devices most vulnerable to attack—deployed in physical locations anyone can access, running for years without updates—are exactly the devices least capable of defending themselves.

The results have been predictable. Consumer IoT devices with default passwords and no update mechanisms became the Mirai botnet, launching some of the largest DDoS attacks in history. Medical devices, industrial sensors, and building systems have all been compromised.

The honest assessment: securing IoT requires accepting that some devices can't be fully secured. Defense in depth—network segmentation, gateway-level security, anomaly detection—becomes essential because endpoint security alone isn't sufficient.

Gateways: The Bridge Between Worlds

Most IoT deployments don't connect devices directly to the Internet. They connect devices to gateways, and gateways to the Internet.

Gateways translate protocols—converting Zigbee or LoRaWAN to IP. They aggregate data—collecting readings from hundreds of sensors before transmitting a batch to the cloud. They process locally—running logic that needs to respond faster than cloud round-trips allow.

And critically, gateways provide a security boundary. The IoT network can be isolated from the Internet, with the gateway as the only entry point.

Managing at Scale

You cannot manually manage a million devices. The approaches that work for traditional networks—SSHing into servers, physically swapping failed hardware—don't scale.

Zero-touch provisioning means devices configure themselves when powered on. They find the network, authenticate, download their configuration, and start operating. No human touches them.

Over-the-air updates push firmware remotely. This is essential for security patches but terrifying at scale—a bad update can brick a million devices simultaneously.

Automated monitoring detects failures through patterns and anomalies rather than individual device inspection. When a device stops reporting, the system notices and responds—potentially dispatching repair or rerouting around the failure.

The Architecture Stack

IoT architectures typically layer:

Devices sense the physical world or act on it. They're where the constraints are harshest.

Network moves data using whatever combination of LPWAN, cellular, and short-range protocols fits the deployment.

Platform manages devices, stores data, and provides services. Often cloud-based, increasingly offering edge capabilities for latency-sensitive processing.

Application delivers value to users—the dashboard, the alerts, the automation.

Each layer has its own networking challenges. But the fundamental tension—connecting constrained devices to an Internet built for powerful ones—runs through all of them.