Internet of Things: Architecture, Protocols, and CS Foundations

The Internet of Things (IoT) describes the class of networked physical devices that collect, transmit, and act on data without requiring continuous human interaction. This page covers the layered architecture that defines IoT systems, the communication protocols that move data between devices and platforms, and the computer science foundations — spanning embedded systems, distributed systems, and computer networking fundamentals — that govern how these deployments are designed and analyzed. Understanding IoT at a structural level matters because deployment failures frequently trace to mismatches between protocol selection, resource constraints, and security assumptions rather than hardware defects.

Definition and scope

IoT encompasses computing devices embedded in physical objects — sensors, actuators, industrial controllers, consumer electronics, and infrastructure components — that communicate over networks to exchange data with other devices or centralized platforms. The National Institute of Standards and Technology (NIST) defines IoT in NIST Special Publication 800-183 as a network of uniquely identifiable "things" with sensing or actuation capabilities and communication interfaces. NIST SP 800-183 further decomposes IoT into five primitives: sensors, aggregators, communication channels, external utilities, and decision triggers — a taxonomy that distinguishes IoT from general-purpose computing.

The operational scope spans four primary deployment domains:

  1. Consumer IoT — smart home devices, wearables, connected appliances
  2. Industrial IoT (IIoT) — manufacturing automation, predictive maintenance, SCADA integration
  3. Smart infrastructure — traffic management, utility metering, building automation systems
  4. Healthcare IoT — connected medical devices, remote patient monitoring, implantable sensors

Each domain carries distinct latency requirements, power budgets, and security postures. A consumer thermostat tolerates seconds of latency; an industrial actuator controlling a pressurized line may require sub-100-millisecond response times. These constraints directly determine protocol and architecture choices.

How it works

Architectural layers

IoT systems are most rigorously described using a three-layer or five-layer reference model. The Internet Architecture Board (IAB) addressed IoT architectural challenges in RFC 7452, which categorizes device types by capability and connectivity pattern. The functional layers are:

  1. Perception layer — physical sensors and actuators that interface with the environment; examples include temperature sensors (e.g., thermistors), accelerometers, and relay modules
  2. Network layer — communication hardware and protocols that transport data; includes radio transceivers, gateways, and protocol stacks
  3. Application layer — platforms, data pipelines, and services that process and act on device data; may include cloud platforms, edge nodes, or on-premises systems

In the five-layer model, the perception and network layers are subdivided to isolate middleware (data aggregation and device management) and a business logic layer handling analytics and decision triggers.

Protocol landscape

Protocol selection is determined by three axes: bandwidth requirements, power consumption constraints, and network topology. The Internet Engineering Task Force (IETF) has standardized multiple IoT-targeted protocols:

MQTT vs. CoAP is the most consequential protocol comparison in constrained IoT design. MQTT requires a persistent TCP connection and a broker intermediary, making it appropriate when device count is moderate and a managed broker is available. CoAP operates connectionlessly over UDP, making it preferable when devices number in the thousands, multicast addressing is required, or TCP overhead is prohibitive given a device's power budget.

Edge computing and data flow

Data flows in three patterns: device-to-cloud, device-to-gateway-to-cloud (edge processing), and device-to-device (peer). Edge computing — processing data at or near the device rather than transmitting raw sensor output to a central platform — reduces latency, conserves bandwidth, and limits exposure of raw data to transit-layer interception. NIST addresses edge computing architecture in NIST SP 800-207 in the context of zero-trust network design, noting that edge nodes introduce additional trust boundary management requirements.

Common scenarios

Smart metering (utility IoT): Electric and gas meters transmit consumption data over mesh radio networks (commonly using IEEE 802.15.4g or LoRaWAN) to utility collection points at intervals ranging from 15 minutes to 1 hour. Aggregated data feeds demand-response programs and fraud detection systems.

Predictive maintenance in manufacturing: Vibration sensors attached to rotating machinery sample at rates between 1 kHz and 10 kHz, feeding FFT-based anomaly detection models. Data is processed at edge gateways to avoid transmitting high-frequency time-series data over constrained backhaul links. NIST's Cyber-Physical Systems reference architecture (NIST SP 1500-201) provides a framework for classifying these industrial sensing architectures.

Connected medical devices: The FDA regulates software in IoT-connected medical devices under its Software as a Medical Device (SaMD) framework, which aligns with guidance from the International Medical Device Regulators Forum (IMDRF). Firmware update mechanisms, data integrity, and authentication requirements are governed by the FDA's 2023 Cybersecurity Guidance for Medical Devices.

Building automation systems (BAS): HVAC, lighting, and access control subsystems communicate over BACnet (defined in ASHRAE Standard 135) or LonWorks, with integration layers translating to IP-based protocols. Security vulnerabilities in BAS deployments have been documented by CISA in multiple Industrial Control Systems advisories.

Decision boundaries

Several architectural decisions have downstream consequences that are difficult to reverse after deployment at scale.

Constrained vs. unconstrained device classification: IETF RFC 7228 (Terminology for Constrained-Node Networks) defines three device classes by RAM and flash storage — Class 0 (less than 10 KiB RAM, less than 100 KiB flash), Class 1 (approximately 10 KiB RAM, 100 KiB flash), and Class 2 (approximately 50 KiB RAM, 250 KiB flash). Class 0 devices cannot run TCP/IP stacks and require protocol translation at gateways. Misclassifying a deployment target as Class 2 when actual hardware is Class 0 causes protocol incompatibilities that cannot be resolved with firmware changes alone.

Centralized vs. edge-first processing: Centralized architectures simplify data governance and model management but create single points of failure and impose latency. Edge-first architectures require distributing compute resources across potentially thousands of nodes, increasing firmware lifecycle management complexity. The choice interacts directly with cloud computing concepts and parallel computing principles when multi-node aggregation is involved.

Security architecture selection: The NIST IoT Cybersecurity Guidance (NISTIR 8259A) identifies six core device cybersecurity capabilities: device identification, device configuration, data protection, logical access to interfaces, software updates, and cybersecurity state awareness. Deployments that omit device identity management — a common cost-cutting decision in Class 0 constrained devices — foreclose authenticated firmware update channels, creating unpatched device populations at scale.

The broader computer science principles underlying these decisions — covering areas such as algorithms and data structures, operating systems fundamentals, and cybersecurity fundamentals — are documented in depth across the reference properties indexed at the Computer Science Authority index.

References

Read Next

Blockchain Technology: Computer Science Principles and Applications Next in Networking, Systems, and Cloud Cryptography in Computer Science: Algorithms, Keys, and Protocols Previous in Networking, Systems, and Cloud