openskills.info
Course catalog
Open Course

IoT Connectivity Protocols

IoT connectivity protocols are the rules that let sensors, actuators, gateways, and services exchange data. A working design combines a physical link, a network path, and an application protocol that fit the device's power, range, data, and reliability limits.

itComputer architecture and hardware

Don't Panic — IoT Connectivity Protocols

IoT connectivity is not a single protocol that gets stamped onto a sensor like a postage mark. It is a stack: a link gets a device to its first neighbor, a network moves packets, transport carries an exchange, and an application protocol decides what the exchange means. The hardware brochure may list three radios and a heroic range number. It has not, sadly, designed the system.

Start at the workload. A remote meter that reports a small value occasionally has different needs from a nearby wearable, a building controller, or a mobile tracker. Range, energy, available infrastructure, message age, and the radio environment choose the lower layers. Only then does it make sense to ask about MQTT, brokered publish-and-subscribe messaging, or CoAP, resource-oriented request and response for constrained nodes.

The names that cause the most trouble occupy different floors of the building. Bluetooth Low Energy carries nearby wireless communication. Thread makes an IPv6 mesh over IEEE 802.15.4. Zigbee adds its own network and application model over the same radio family. LoRaWAN sends small, infrequent wide-area messages through gateways. MQTT can sit above several of those paths. Comparing MQTT with Bluetooth is rather like comparing a filing system with a bicycle. Both may be present. Neither answers the other's question.

The middle boxes also deserve labels. A border router forwards IP packets between links. A gateway terminates or translates one application model into another. An MQTT broker accepts sessions and routes publications by topic. One appliance can perform all three jobs, which is convenient until a missing measurement turns up and everyone stares at the same appliance with different theories.

Security needs a similarly unromantic map. Link security protects local peers. TLS or DTLS protects a transport connection. OSCORE can protect CoAP application data across an intermediary. Encryption tells you where plaintext may exist; authorization still decides which identity may use a topic or resource. Secure boot, credential rotation, update integrity, and decommissioning remain waiting outside the protocol boundary with clipboards.

The surprise is that normal traffic is often the easy part. A complete energy cycle includes waking, joining, handshakes, listening, retries, and reconnecting. An outage can make a fleet retry together, drain batteries, and overload gateways or brokers. Bound queues and message age, use backoff, and make repeated commands safe.

Read the slides when you need the layer map and the decision path. Use the cheatsheet to compare links, MQTT delivery, CoAP behavior, security placement, and diagnostic signals. The practice reference supplies safe commands for observing MQTT and CoAP boundaries. The exercise then makes the brokered fan-out and duplicate-handling problem visible on a local broker, where the only thing at risk is a small amount of afternoon.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources