The Internet of Things (IoT) is a system of connected physical devices that collect data from the real world, transmit it across communication networks, and then use it in applications or processing systems to make a decision or execute an action.
The "thing" may be a small temperature sensor, an electricity meter, a smartwatch, an industrial machine, a car, a camera, an irrigation system, or a medical device. But a device's internet connection alone does not make it a complete IoT system.
The system usually consists of a connected chain that starts in the physical world itself, where sensors and devices capture real measurements such as temperature, humidity, and motion. These measurements cross the connectivity layer toward a gateway or edge node that aggregates, cleans, and perhaps processes the data locally before uploading it, and then reach a cloud or on-premises platform that handles processing and analytics, turning raw data into meaningful information. At the top of the chain stands the application, which translates this information into a decision, and the action or automation that executes the decision in the real world, completing a cycle that began with a sensor and ends with a motor, a valve, or a notification.
The real value does not come merely from "connecting things," but from turning measurements into information, and then into a decision or action.
How Does the Internet of Things Work? The Loop of a Smart Irrigation System
The logic of IoT becomes clear when we follow a smart irrigation system step by step. The loop begins with sensing: a sensor in the soil measures moisture, temperature, and perhaps light. Then comes conversion to data, where physical measurements become digital values, such as soil moisture at 21% and temperature at 31°C.
Next comes connectivity, as the device sends its data using a suitable technology, whether Bluetooth LE, Wi-Fi, Zigbee, Thread, LoRaWAN, NB-IoT, LTE-M, or 5G. The data then moves to processing, reaching a local gateway, an edge server, a cloud platform, or an in-house system.
Then comes the decision: the system may apply a simple rule, such as turning irrigation on when soil moisture drops below a defined threshold, or use a more complex analysis combining soil condition, weather, crop, water consumption, and historical data. Finally, actuation: a command is sent to the water valve to start irrigation.
This loop, sensing, then connecting, then processing, then deciding, then acting, is the essence of a large number of IoT systems.
The Core Components of an IoT System
Devices and Sensors
These are the point of contact with the real world, and they may measure temperature, humidity, pressure, vibration, light, location, speed, flow, air quality, and vital signs. They may also include actuators that execute commands such as opening a valve, starting a motor, changing a temperature, locking a door, or stopping a machine.
The Controller or Embedded Computer
It receives sensor data and processes part of it, and may be a microcontroller, a system on chip (SoC), a PLC, an Embedded Linux device, or an industrial controller. It is not necessary to send every raw reading to the cloud.
The Connectivity Layer
It moves data between devices and the rest of the system, and the choice made here changes power consumption, range, cost, speed, latency, battery life, and ease of deployment.
The Gateway
Some devices do not connect to the cloud directly. A short-range BLE sensor may connect to a nearby gateway that receives its transmissions, and the gateway then forwards the data across the internet to the cloud, where it is stored and processed. With this arrangement, the sensor benefits from a low-power protocol that cannot sustain a direct internet connection, while the gateway carries the heavier processing load and its higher cost. A gateway can also aggregate data from several devices, translate between protocols, filter data, enforce security policies, and run local logic.
Edge Computing
Edge computing processes data close to its source instead of sending everything to a distant data center, and it helps when we need fast response, less bandwidth consumption, continued operation when the internet is weak, local video processing, or less transmission of sensitive data.
Cloud / Backend
It may handle data storage, device management, analytics, alerts, APIs, user management, AI models, and monitoring dashboards.
The Application
This is what the user or another system sees, and it may be a dashboard, a mobile app, a maintenance system, a monitoring center, an API, an ERP system, a digital twin, or an automation engine.
IoT Is Not a Single Layer
A common mistake is talking about IoT as if it were a single protocol, when in reality it is stacked layers, each with its own options:
| Layer | Examples |
|---|---|
| Application | MQTT / CoAP / HTTP / AMQP / Matter |
| Transport | TCP / UDP / QUIC |
| Network | IPv4 / IPv6 |
| Link / Radio | Wi-Fi / BLE / Thread / Zigbee / Cellular / LoRa |
Not all of these options come together in every device. That is why we must always distinguish between the radio or connectivity technology, the network protocol, the application protocol, and the data model.
IoT Connectivity Technologies
No single connectivity technology suits every use, and each has its natural place.
Wi-Fi
Wi-Fi suits cases that need relatively high bandwidth and a direct IP network connection, in a home, office, or facility that has Wi-Fi infrastructure, such as cameras, home appliances, displays, and gateways. Its potential limitations are higher power consumption than low-power technologies, dependence on access-point infrastructure, and range and congestion depending on the environment.
Bluetooth Low Energy — BLE
Bluetooth LE was designed to operate with high energy efficiency and supports more than one communication mode: point-to-point, broadcast, and mesh. It is common in wearables, personal medical devices, sensors, proximity applications, and setting up smart devices. Current Bluetooth SIG documents also point to its growing role in Ambient IoT, where some future devices may rely on energy harvested from the environment instead of traditional batteries.
Zigbee
Zigbee is built on the IEEE 802.15.4 standard and is known for low-power mesh networks, used in smart homes, lighting, buildings, sensing, and control. In November 2025, the Connectivity Standards Alliance announced Zigbee 4.0, which added improvements in security and compatibility and support for Sub-GHz bands through Suzi, along with improvements in setup and operation. Zigbee has not stood still at the old versions that appear in many IoT explainers.
Thread
Thread is a low-power, IP-based mesh protocol designed for the Internet of Things. It relies on IPv6, operates as a mesh network that does not depend on a single central hub that could become a point of failure, suits low-power devices, is used in modern smart home ecosystems, and is one of the most important network layers that Matter runs on.
LoRa and LoRaWAN
There is an important difference between the two terms: LoRa is the radio and modulation technology, while LoRaWAN is the network protocol that organizes communication among end devices, gateways, and network servers.
LoRaWAN suits applications that need long distances, little data, long battery life, and non-continuous transmission, such as agriculture, environmental monitoring, infrastructure, and some city applications. The LoRaWAN 1.0.4 specification describes the protocol as optimized for battery-powered devices, whether fixed or mobile.
NB-IoT
A cellular LPWAN technology especially suited to smart meters, infrastructure sensors, and low-data devices, with wide cellular coverage and long battery life.
LTE-M
LTE-M offers more flexibility than NB-IoT for some applications, especially mobile devices, tracking, wearables, relatively higher data rates, and some voice cases. By the end of 2025, combined active NB-IoT and LTE-M connections worldwide surpassed one billion connections according to the GSMA, confirming that they are not merely transitional technologies whose role has ended.
5G and RedCap
5G matters for classes of IoT that need higher bandwidth, lower latency under certain conditions, private industrial networks, high device density, and advanced quality of service, but it is not necessary for all IoT. RedCap/eRedCap, meanwhile, aims to deliver part of 5G's capabilities with lower complexity, lower power, and lower cost than full-capability 5G.
The detailed relationship between 5G and the Internet of Things deserves its own explanation, which we devote to the article 5G and the Internet of Things.
Comparing IoT Connectivity Technologies
| Technology | Typical Range | Power Consumption | Data Volume | Example Uses |
|---|---|---|---|---|
| BLE | Short | Very low | Low–medium | Wearables and sensors |
| Wi-Fi | Local | Medium–high | High | Cameras and home appliances |
| Zigbee | Short–medium/Mesh | Low | Low | Lighting and buildings |
| Thread | Local mesh | Low | Low–medium | IP-based smart home |
| LoRaWAN | Long | Very low | Very low | Agriculture and monitoring |
| NB-IoT | Wide cellular | Low | Low | Meters and infrastructure |
| LTE-M | Wide cellular | Low | Low–medium | Tracking and wearables |
| RedCap/eRedCap | Wide cellular | Medium | Medium | Mid-tier IoT |
| Full 5G NR | Wide cellular | Higher | High | Video, industry, and high-performance applications |
This is a conceptual comparison; real performance varies by device, spectrum, implementation, and environment.
How Do You Choose a Connectivity Technology?
The choice starts with specific questions: How much data is there? How often will the device transmit? How many years must the battery last? What is the distance? Is the device mobile? Is Wi-Fi or a cellular network available? What latency is required? How many devices are there? What do the hardware and connectivity fees cost? How sensitive is the data? And what happens if the connection drops?
A moisture sensor in a field is not treated like an industrial quality camera. The first may need LoRaWAN or NB-IoT, a battery lasting years, and small messages; the second may need Ethernet, Wi-Fi, or 5G with edge processing.
IoT Application Protocols
Above the connectivity layer come the application protocols that define how devices and services exchange their messages.
MQTT
MQTT 5.0 is an OASIS standard based on the Publish / Subscribe model. Instead of each device connecting directly to every consumer of the data, the sensor publishes its temperature messages to a central broker, which in turn distributes them to all subscribers, such as a monitoring dashboard and an alerting service, without the publisher knowing any of them. This decoupling allows new consumers to be added without touching the device, and the device to be changed without updating the consumers, because the only contract they share is the topic name, not an address.
Its advantages include decoupling producers from consumers, relatively lightweight messages, three quality-of-service (QoS) levels, and suitability for distributed systems.
But describing MQTT as "automatically saving power" is inaccurate; power consumption also depends on the radio link, keep-alive messages, message rate, TLS, the device, and session design.
CoAP
CoAP was designed for constrained nodes and networks, and is a web-style protocol that usually runs over UDP. The important point here:
Relying on UDP does not simply mean CoAP is "unreliable."
CoAP has mechanisms such as Confirmable Messages and retransmission when needed, and it can be secured with mechanisms such as DTLS or OSCORE depending on the architecture.
HTTP
HTTP is useful when we need web APIs, easy integration with cloud services, a REST architecture, and broad system support, but it may be heavier than MQTT or CoAP on highly constrained devices. Reducing it to "running on TCP" is also no longer accurate for all its versions; HTTP/1.1 and HTTP/2 are usually tied to TCP, while HTTP/3 uses QUIC over UDP.
AMQP
AMQP is a standard OASIS messaging protocol focused on reliable messaging, middleware, enterprise systems, and message exchange between services. It may suit backends or enterprise IoT platforms, but it is usually more complex than MQTT for very small IoT nodes.
MQTT, CoAP, or HTTP?
| Question | MQTT | CoAP | HTTP |
|---|---|---|---|
| Pattern | Pub/Sub | Web-like Request/Response | Request/Response |
| Constrained devices | Good | Excellent | Depends on the device |
| Broker | Usually yes | Not required | No |
| Weak networks | Suitable | Very suitable | May be heavier |
| Web integration | Via intermediary services or WebSockets | Can be bridged to the web | Direct |
| Push/telemetry | Strong | Possible | Less natural |
| Traditional APIs | Possible but not its main goal | REST-like | Excellent |
There is no "best IoT protocol" in absolute terms.
Matter and Interoperability
Where Does Matter Fit?
Matter is not a replacement for Wi-Fi, Thread, or Bluetooth, but an IP-based application protocol focused especially on interoperability in the smart home. It runs on top of network technologies such as Wi-Fi, Thread, and Ethernet, and uses Bluetooth LE in setup (commissioning) scenarios. In June 2026, Matter 1.6 was released, adding improvements in setup, management across multiple ecosystems, and the exchange of device capabilities and states.
Matter's importance lies in the fact that it addresses a different problem from the radio problem:
Not just "how does the packet arrive?" but "how does a device from company A understand a device from company B in a standardized way?"
The Challenge the Network Alone Cannot Solve
Two devices may both use Wi-Fi and still not understand each other. Interoperability requires agreement on discovery, identity, data models, commands, security, and semantics. This is where Matter, Zigbee profiles, Thread with IP, open standards, and APIs and data models become important. The problem is not just having a connection, but having a shared meaning for data and commands.
Applications of the Internet of Things
Smart Cities
IoT is used in lighting, water, parking, air monitoring, traffic, waste, and infrastructure. But the phrase "smart city" does not mean a single network; a city may use LoRaWAN for simple sensors, NB-IoT for meters, fiber for core systems, and 5G or Wi-Fi for video.
Healthcare
Its uses include wearables, remote monitoring, home measurement devices, equipment tracking, and alerts. But health data is sensitive, and no medical IoT device should be considered a diagnostic system merely because it can measure; healthcare applications need clinical validation where applicable, strong security, identity management, privacy protection, and compliance with local laws.
Smart Industry
Industrial IoT supports condition monitoring, predictive maintenance, asset tracking, energy monitoring, quality control, and digital twins. A practical example illustrates this: sensors on an industrial motor stream their measurements to analytics running at the edge near the production line; these analytics detect anomaly patterns in vibration or temperature as soon as they appear and push the result directly to the maintenance system, which opens a work order before the fault turns into a breakdown. Raw data does not travel to a distant data center, and the critical decision is made close to its source.
This is where the direct relationship with the digital twin appears: IoT data can feed a digital model of a real asset so that it can be monitored, simulated, and optimized.
Transport and Logistics
This includes fleet management, asset tracking, the cold chain, vehicle telemetry, and smart traffic systems.
Energy
This includes smart meters, grid monitoring, demand response, energy management inside buildings, and renewable energy monitoring. Matter itself has begun expanding into home energy management, with capabilities added during its recent releases.
Agriculture
This includes soil moisture, local weather, irrigation, livestock tracking, equipment monitoring, and precision agriculture. In this field, low power, long range, and rural coverage usually matter more than high speed.
AIoT: Where the Internet of Things Meets Artificial Intelligence
AIoT stands for Artificial Intelligence of Things, and its idea is that IoT collects the data, and artificial intelligence analyzes it or uses it to make decisions: detecting a fault in a machine, predicting motor failure, spotting anomalies in energy consumption, analyzing video at the edge, forecasting irrigation needs, or classifying sensor events. AI can run in three locations:
| Location | How It Works |
|---|---|
| Cloud AI | Data is sent to the cloud for analysis |
| Edge AI | The model runs close to the device |
| TinyML | Very small models run on the microcontroller itself |
The closer processing moves to the source, the more latency, bandwidth, and transfer of sensitive data can be reduced, but with additional challenges such as updating models, limited memory, power constraints, and performance monitoring.
Security: Part of the Design, Not an Afterthought
Why the Whole Lifecycle Must Be Considered
An IoT device may stay in service for many years, during which it faces new vulnerabilities, changes of ownership, aging firmware, leaked credentials, expiring certificates, backend changes, and attacks on APIs. That is why a device's design must account for its entire lifecycle.
What Does NIST Recommend?
In April 2026, NIST released the revision NISTIR 8259 Rev.1, updating the foundational activities IoT product manufacturers should consider. NISTIR 8259A also defines a baseline of device capabilities, including Device Identification, Device Configuration, Data Protection, Logical Access to Interfaces, Software Update, and Cybersecurity State Awareness. Current NIST catalogs add more detailed capabilities, including Device Security.
A Practical Security Checklist
| Principle | What It Means in Practice |
|---|---|
| A unique identity | The device must be reliably identifiable |
| No shared default passwords | And no fixed credentials across thousands of devices |
| Data encryption | In transit, and at rest where needed |
| Secure updates | Verifying firmware, signing updates, preventing dangerous downgrades, and planning for end of support |
| Least privilege | Do not grant the device more access than it needs |
| Closing unnecessary services | Every extra interface can become an attack surface |
| Secret management | Do not store sensitive keys in an easily extractable way |
| Logging and security state | Knowing whether the device is updated, whether logins have failed, whether the configuration changed, or whether an abnormal state appeared |
| A post-sale plan | Defining the support period, the vulnerability reporting process, the update method, and end of life |
Security does not end on product launch day.
Privacy in IoT
A small device may collect highly sensitive data, such as location, health, voice, video, behavior inside the home, and consumption patterns. That is why clear questions must be asked: Do we need this data at all? Can it be processed locally? How long do we keep it? Who can access it? Does the user know what is collected? Can it be deleted? And is it used for another purpose? Data Minimization remains the core principle:
Do not collect data you do not need.
Scale and Reliability
Scaling Is Not Just "Number of Devices"
A system may look excellent at 50 devices and then fail at 50,000. Scalability covers provisioning, identity, certificates, messaging, broker capacity, database writes, over-the-air (OTA) updates, observability, device inventory, and failover.
A well-known example is power returning after a widespread outage, when a million devices try to connect to the server at the same moment, causing a Reconnect Storm. That is why system behavior must be tested under network outages, power restoration, broker loss, a cloud region failure, and mass firmware updates.
What Does Reliability Mean in IoT?
Not every message is equally important. A periodic temperature reading can occasionally lose one of its copies, but a machine-stop command or a medical alert may need delivery guarantees, acknowledgment, retries, redundancy, a timeout, and escalation. Reliability is designed at the application level, not by relying on a protocol's name alone.
The Future of IoT: What Is Changing in 2026?
Interoperability Matters More
Recent examples include Matter 1.6, Zigbee 4.0, Thread, and IP-based protocols, as the market tries to shrink the isolated islands between devices.
AI Moves to the Edge
Instead of sending all data to the cloud, more analysis happens inside the device itself, on the gateway, or at the edge.
Ambient IoT
Devices that run on extremely low power, some relying on energy harvesting instead of a large traditional battery, and the Bluetooth SIG considers Bluetooth LE an important technology on this path.
Cellular Massive IoT Continues
NB-IoT and LTE-M surpassed one billion active connections worldwide by the end of 2025 according to the GSMA, while RedCap/eRedCap expands IoT options on 5G.
6G / IMT-2030 Is Still a Standards Future
In 2026, there is no mature commercial 6G network that can be relied on as the foundation for an IoT project. The ITU is currently working on IMT-2030, and announced in March 2026 that the expert group had agreed on draft performance requirements for the next generation, with the approval and evaluation process still ongoing. So figures such as terabits per second, sub-millisecond latency, or millions and billions of devices should not be presented as final, confirmed commercial characteristics today; the precise characteristics will be determined as the standards and evaluations are completed.
How Do You Start an IoT Project the Right Way?
Do not start by buying a sensor or choosing a cloud, but from the required decision, then progress through the following steps:
| Step | What It Defines |
|---|---|
| 1. Define the problem | For example: we want to detect rising motor vibration before failure |
| 2. Define the required data | Vibration, temperature, and revolutions per minute (RPM) |
| 3. Define the sampling rate | Every millisecond, every second, or every hour? This changes the architecture entirely |
| 4. Decide where processing happens | On the device, the gateway, the edge, or the cloud |
| 5. Choose connectivity | Based on data, power, range, cost, mobility, and latency |
| 6. Choose the application protocol | MQTT, CoAP, HTTP, or others depending on the system |
| 7. Design security before implementation | Identity, keys, encryption, updates, permissions, and lifecycle |
| 8. Design operations | How will you know a device has stopped, firmware is outdated, a battery is low, a certificate is about to expire, or the data does not make sense? |
| 9. Test failure | Do not stop at the happy path; test offline operation, packet loss, reboots, network stress, thousands of devices, and upgrade failure |
How Do We Choose Between Cloud and Edge?
| Start with the Cloud When | Start with the Edge When |
|---|---|
| Latency is not highly sensitive | Fast response matters |
| You need aggregated analytics | The data is large |
| You need central storage | External connectivity is weak |
| The connection is stable | Privacy matters |
| The system must keep running offline |
In many projects, the design is hybrid, combining both.
Must Every Device Connect to the Internet Directly?
No. In many systems, it is better for the sensor to connect to a local network, and from there to a gateway that handles the internet connection, rather than the sensor connecting to the internet directly. The gateway can hide internal devices, aggregate data, manage protocols, reduce consumption, enforce security policies, and keep working locally when the cloud is unavailable.
For a hands-on example of the local loop that comes before the internet, see our ultrasonic water tank level monitoring project: an Arduino reads the sensor and sends the level percentage to a phone app over Bluetooth with no cloud platform — adding a gateway or Wi-Fi link is the step that would turn it into a full IoT system. In our actual build of this project, temporary Bluetooth dropouts appeared when the distance increased or interference was present, and we noted that factors such as temperature and humidity can affect the ultrasonic sensor's reading, so correcting readings had to be accounted for during development.
Conclusion
The Internet of Things is not a smart device or a single protocol, but a complete system that links the physical world to software through sensing, connectivity, processing, decision-making, and actuation. A system's success depends on a carefully considered balance among sensors, compute, connectivity, protocols, the split of processing between edge and cloud, interoperability, security, power, cost, and lifecycle.
The most important question when designing any project is not "What is the newest technology we could use?" but:
What is the least complex architecture that can meet the application's requirements securely, reliably, and maintainably over the device's lifetime?
Sources and References
NIST — NISTIR 8259 Series
https://www.nist.gov/itl/applied-cybersecurity/nist-cybersecurity-iot-program/nistir-8259-seriesNIST — IoT Device Cybersecurity Capability Core Baseline (NISTIR 8259A)
https://csrc.nist.gov/pubs/ir/8259/a/finalOASIS — MQTT Version 5.0
https://www.oasis-open.org/standard/mqtt-v5-0-os/IETF / RFC Editor — RFC 7252: The Constrained Application Protocol (CoAP)
https://www.rfc-editor.org/info/rfc7252/IETF / RFC Editor — RFC 9110: HTTP Semantics
https://www.rfc-editor.org/info/rfc9110/OASIS — AMQP Version 1.0
https://www.oasis-open.org/standard/amqp/Bluetooth SIG — Bluetooth Low Energy Primer
https://www.bluetooth.com/bluetooth-le-primer/Connectivity Standards Alliance — Zigbee 4.0
https://csa-iot.org/newsroom/the-connectivity-standards-alliance-announces-zigbee-4-0-and-suzi-empowering-the-next-generation-of-secure-interoperable-iot-devices/Thread Group — Thread
https://threadgroup.org/LoRa Alliance — LoRaWAN 1.0.4 Specification
https://lora-alliance.org/resource_hub/lorawan-104-specification-package/GSMA — One billion NB-IoT and LTE-M connections
https://www.gsma.com/solutions-and-impact/technologies/internet-of-things/billion-lpwan-connections/Connectivity Standards Alliance — Matter 1.6
https://csa-iot.org/newsroom/matter-1-6-enables-more-intuitive-setup-multi-ecosystem-experiences-and-context-driven-control/Connectivity Standards Alliance — Matter specifications
https://csa-iot.org/developer-resource/specifications-download-request/ITU — IMT-2030 technical requirements for the 6G future
https://www.itu.int/hub/2026/03/imt-2030-technical-requirements-for-the-6g-future/
Official documentation & standards
Frequently Asked Questions
What is the Internet of Things in a nutshell?
It is an ecosystem of physical devices that collect data and exchange it over networks with processing systems or applications for monitoring, analysis, control, or automation.
Is every internet-connected device considered IoT?
Not necessarily. The concept of IoT usually refers to physical devices that sense or act and exchange data within a broader ecosystem.
What is the difference between LoRa and LoRaWAN?
LoRa is the radio/modulation technology, while LoRaWAN is the network protocol that governs communication between devices, gateways, and servers.
What is the difference between MQTT and CoAP?
MQTT usually relies on publish/subscribe through a broker, while CoAP offers a web-like model for constrained devices and networks and typically runs over UDP.
Is CoAP unreliable because it uses UDP?
It is not that simple. CoAP provides confirmable messages and retransmission when needed, and the message pattern appropriate to the application can be chosen.
Is MQTT the best choice for every IoT use case?
No. MQTT excels at telemetry and pub/sub, but some systems fit CoAP, HTTP, industrial, or custom protocols better.
What is Matter, and does it replace Wi-Fi?
No. Matter is an IP-based application protocol for interoperability among smart-home devices and runs over networks such as Wi-Fi, Thread, and Ethernet.
Is Zigbee still used?
Yes. The Connectivity Standards Alliance released Zigbee 4.0 in 2025 with improvements in security, interoperability, and range.
What is the difference between NB-IoT and LTE-M?
NB-IoT focuses more on small data, low power, and coverage, while LTE-M offers greater mobility flexibility and a relatively higher data rate for some applications.
Does IoT need 5G?
Not always. The choice depends on power, data, range, mobility, latency, and cost. Many IoT devices run on other, more suitable technologies.
Technical Discussion (0)
Sign in to join the discussion, reply and like comments.
