Study smarter with Fiveable
Get study guides, practice questions, and cheatsheets for all your subjects. Join 500,000+ students with a 96% pass rate.
In Edge AI and Computing, you're not just building smart devices—you're building systems that need to communicate efficiently, reliably, and often in real-time. The protocols you choose determine everything from battery life to latency to security. When exam questions ask about IoT architecture, they're testing whether you understand why certain protocols fit certain use cases, not just what each protocol does.
Think of IoT protocols as fitting into a decision matrix: power consumption, bandwidth requirements, latency tolerance, and network topology. Each protocol makes trade-offs across these dimensions. Don't just memorize acronyms—know what problem each protocol solves and when you'd choose one over another. That's what separates a surface-level answer from one that demonstrates real understanding.
These protocols are optimized for constrained environments where bandwidth is limited, power is precious, and devices can't afford the overhead of traditional web communication. They achieve efficiency by stripping down message formats and using clever architectural patterns like publish/subscribe.
Compare: MQTT vs. CoAP—both target constrained devices, but MQTT uses TCP with publish/subscribe while CoAP uses UDP with REST-style requests. Choose MQTT when you need guaranteed delivery across unreliable networks; choose CoAP when you need request/response patterns with minimal latency.
When reliability, complex routing, or microsecond-level timing matters more than power savings, these protocols step in. They're built for scenarios where message loss or delay could mean system failure.
Compare: AMQP vs. DDS—both handle complex messaging, but AMQP uses a broker-centric model ideal for enterprise integration, while DDS uses brokerless peer-to-peer for ultra-low latency. If an exam asks about real-time control systems, DDS is your answer; for business message queuing, go with AMQP.
These protocols leverage existing web infrastructure, making them accessible but often less optimized for constrained IoT devices. They're the bridge between IoT systems and traditional web services.
Compare: HTTP vs. WebSocket—HTTP requires a new request for each data exchange, while WebSocket maintains an open channel. Use HTTP for occasional API calls; use WebSocket when your edge device needs to stream data continuously or receive instant commands.
These protocols define not just how data is formatted, but how it travels through the air. Each makes different trade-offs between range, power consumption, data rate, and network topology.
Compare: BLE vs. Zigbee vs. Wi-Fi—all operate at 2.4 GHz but serve different niches. BLE excels at point-to-point low-power connections, Zigbee builds self-healing mesh networks for automation, and Wi-Fi delivers high bandwidth where power isn't constrained. Match the protocol to your power budget and data requirements.
When devices are spread across kilometers and can't be frequently recharged, these protocols deliver. They sacrifice data rate for extraordinary range and battery life.
Compare: LoRaWAN vs. Wi-Fi—opposite ends of the IoT spectrum. LoRaWAN sends tiny packets over kilometers with minimal power; Wi-Fi sends large amounts of data over tens of meters with significant power. If your sensor is in a remote field reporting once per hour, LoRaWAN wins. If it's streaming video in your living room, Wi-Fi wins.
| Concept | Best Examples |
|---|---|
| Low-power constrained devices | MQTT, CoAP, BLE, Zigbee, LoRaWAN |
| Publish/subscribe architecture | MQTT, DDS, AMQP |
| Real-time/low-latency requirements | DDS, WebSocket, CoAP |
| Enterprise message queuing | AMQP |
| Web service integration | HTTP/HTTPS, WebSocket, CoAP |
| Mesh networking capability | Zigbee |
| Long-range communication | LoRaWAN, (Wi-Fi with limitations) |
| High-bandwidth applications | Wi-Fi, WebSocket |
Which two protocols both use publish/subscribe patterns but differ in their approach to brokers? What are the latency implications of each approach?
You're designing a smart agriculture system with sensors spread across 500 acres that report soil moisture hourly. Which protocol would you choose and why? What would be inappropriate for this use case?
Compare CoAP and HTTP: both are RESTful, so what makes CoAP better suited for constrained IoT devices? Identify at least two specific technical differences.
A hospital needs to network patient monitors that require guaranteed sub-millisecond message delivery with configurable reliability policies. Which protocol fits this requirement, and what feature specifically enables these guarantees?
Explain why you might use WebSocket instead of MQTT for a real-time IoT dashboard, even though MQTT is considered more "IoT-optimized." Under what circumstances would MQTT still be the better choice?