Skip to content
book.derekmolloy.ie

1.4 Edge, fog, and cloud: from the computing continuum to collaborating things

Once you have both microcontroller leaf nodes and Embedded Linux gateways in your system, the next architectural question is where each stage of the Information Value Loop should execute. When a vibration sensor or a camera captures a frame, should the filtering, feature extraction, and decision-making happen on the microcontroller, on the local Linux gateway, on an on-premise server, or in a remote cloud data centre?

Distinguishing edge, fog, and cloud computing

Section titled “Distinguishing edge, fog, and cloud computing”

In early IoT deployments, networks were designed only to move bytes from sensors to a remote cloud server, where all storage, analysis, and configuration lived. As device populations grew and industrial applications demanded millisecond control loops, pushing every raw sample through a Wide Area Network (WAN) became untenable.

Modern distributed systems partition work across three layers, moving storage, control, and configuration progressively closer to the physical data source:

  • Cloud computing (Centralised, global scale): Hyperscale or private data centres located tens to thousands of kilometres from the physical site. The cloud excels at long-term historical archiving, fleet-wide device management, training large machine-learning models, and cross-site business analytics, at the cost of 20 ms to 200 ms+ round-trip network latency, continuous WAN bandwidth expenses, and exposure to internet outages.
  • Fog computing (Network-centric, LAN and gateway level): A term introduced by Cisco (Bonomi et al., 2012)1 to describe the intermediate layer of Embedded Linux gateways, industrial routers, and on-premise micro-servers sitting on the Local Area Network (LAN) between the field nodes and the cloud. Fog computing is network-centric: a single fog gateway aggregates traffic from dozens of heterogeneous leaf nodes across BLE, Thread, Zigbee, or CAN, bridges them to IP, and maintains local operation when the WAN link to the cloud fails.
  • Edge computing (Device-centric, appliance and leaf level): Processing that occurs directly on the physical machine, controller, or sensor node (sometimes called the far edge or mist when referring specifically to constrained microcontrollers)2. Edge computing is device-centric: an ESP32 running a 1 kHz PID loop or a TinyML anomaly detector processes the signal inside the appliance itself, before a packet ever hits the local network.

Control plane versus data plane in the fog gateway

Section titled “Control plane versus data plane in the fog gateway”

When you configure a Raspberry Pi as a fog gateway in Part IV of this book, its software responsibilities split cleanly into two logical planes:

PlanePurpose on the Fog GatewayConcrete EEN1071 components
Fog Data PlaneHigh-throughput, low-latency movement, caching, and transformation of live sensor and actuator payloads at wire speed.Local Mosquitto MQTT broker routing pub/sub topics between leaf nodes; local client-to-client bridging (e.g., an ESP32 sensor triggering an actuator without leaving the LAN); ring-buffer caching and local time-series storage (InfluxDB / SQLite) during WAN outages.
Fog Control PlaneConfiguration, session management, device identity, access policy, and orchestration across the local fleet.NetworkManager, systemd, and OpenThread Border Router (otbr-agent) managing network interfaces; mTLS certificate and access-control list (ACL) enforcement; Node-RED or supervisory control logic; NTP/PTP time synchronisation; and staging OTA firmware images for connected leaf nodes.

The Cloud–Edge–IoT computing continuum

Section titled “The Cloud–Edge–IoT computing continuum”

Rather than treating the leaf node, the gateway, and the cloud as isolated silos, European systems research frames them as a single Cloud–Edge–IoT Computing Continuum. In its strategy paper The next generation Internet of Things (digital-strategy.ec.europa.eu)7, the European Commission outlines why shifting computation toward the far edge is central to industrial resilience, data sovereignty, and environmental sustainability:

  1. Mission-critical latency and operational resilience: Autonomous vehicles, smart energy grids, and surgical or manufacturing equipment cannot tolerate cloud round-trip delays or stop functioning when an external fibre link is cut. Processing data at the edge keeps safety-critical loops local.
  2. Privacy, data sovereignty, and European data spaces: Keeping raw video, patient biometrics, and proprietary factory telemetry inside the local premise simplifies compliance with the General Data Protection Regulation (GDPR) and the EU Data Act, sharing only authorised, aggregated insights across sectoral data spaces (such as agriculture, mobility, and energy under the Digital Europe and Open DEI frameworks).
  3. Energy and carbon-footprint reduction: In line with the AI+HW 2035 memory and communication wall (Section 1.1), filtering and compressing data on low-power edge silicon avoids the energy cost of transmitting terabytes of raw telemetry across core networks and cooling hyperscale cloud servers.

To turn this continuum into practical software infrastructure, the European Commission’s Horizon Europe programme (World Leading Data and Computing Technologies: From Cloud to Edge to IoT) invested €64 million across a cluster of six next-generation meta-operating system research projects (ICOS, FluiDOS, NEMO, NebulOus, aeROS, and NEPHELE, coordinated through OpenContinuum, Unlock-CEI, and HiPEAC)8. A meta-operating system sits above individual node operating systems (such as Zephyr on microcontrollers and Linux on gateways) to provide a unified orchestration layer that can discover heterogeneous nodes, monitor energy and latency budgets, and migrate containerised or sandboxed workloads across the continuum from far-edge swarms to the cloud.

Beyond vertical offloading: the Internet of Collaborating Things (IoCT)

Section titled “Beyond vertical offloading: the Internet of Collaborating Things (IoCT)”

Even with fog gateways in place, almost all commercial IoT platforms today (such as AWS IoT Greengrass or Azure IoT Edge) are still built around a vertical interaction model (Figure 1.7a): leaf devices are treated as passive data sources that funnel telemetry upward through a static hierarchy of on-premise gateways, edge servers, and cloud data centres managed by a single organisation.

In their position paper The Internet of Collaborating Things: Agentic Edge AI for Autonomous Cross-Domain Collaboration, Hanafy, Sehatbakhsh, Irwin, Srivastava, and Shenoy (UMass Amherst and UCLA, June 2026, arXiv:2609.10542v1)9 argue that this vertical offload paradigm cannot scale for the next decade of connected embedded systems, for two structural reasons:

  1. The scale and capability inversion: The number of connected IoT devices exceeded 20 billion in 2025 and is on a trajectory toward an Internet of a Trillion Things (IoTT) over the coming decade. At the same time, modern edge devices integrate multi-core processors, neural accelerators, cameras, and LiDAR, often matching or exceeding the compute capability of the on-premise gateways they connect to, while the number of devices dwarfs the number of servers available to ingest their streams.
  2. Mobile devices crossing trust domains: Physical AI workloads involve mobile, transient devices (autonomous delivery robots, drones, connected vehicles, wearable AR headsets, and portable medical equipment) that move continuously through physical spaces owned by different administrative domains.

To replace vertical offloading, Hanafy et al. (2026)9 define a horizontal paradigm called the Internet of Collaborating Things (IoCT) (Figure 1.7b), in which co-located devices communicate and collaborate directly as peers, pooling their sensing, compute, networking, and actuation capabilities into dynamic, cross-domain clusters.

Figure 1.7

Vertical offload versus collaborating things

Click any block or link to see what it does.

(a) Vertical offload hierarchy

One owner, data flows up

(b) Internet of Collaborating Things
Domain A: resident
Domain B: visiting

Two owners, peers collaborate directly

Select a device or a link to see its role.

Figure 1.7. Contrasting (a) the conventional vertical offload hierarchy, where devices funnel raw data upward to servers within a single administrative silo, with (b) the horizontal Internet of Collaborating Things (IoCT) proposed by Hanafy et al. (2026)9, where resident and visiting devices pool sensing, compute, and actuation directly across administrative trust boundaries.

Resident versus visiting devices: the delivery-robot scenario

Section titled “Resident versus visiting devices: the delivery-robot scenario”

Hanafy et al. (2026)9 illustrate how horizontal cross-domain collaboration works using three scenarios: a delivery robot entering an apartment building, frequent visitors (such as a babysitter) to a smart home, and collaborative AR gaming:

  • The common structural pattern: A visiting device (operated by Administrative Domain B) physically enters a space (such as an apartment lobby or a home governed by Administrative Domain A) that contains a population of resident devices (cameras, environmental sensors, elevators, smart locks, and on-premise compute servers).
  • Concrete example (Last-mile autonomous delivery): An autonomous delivery robot (the visiting device, owned by a logistics courier) arrives at the lobby of an apartment building to deliver a package to a fourth-floor flat. The robot has no prior trust relationship with the building, lacks an internal map of the corridors, cannot see around blind hallway corners, and cannot physically press the elevator buttons or unlock the recipient’s front door. Conversely, the building’s resident devices include lobby and hallway cameras, an automated elevator controller, an apartment smart lock, and an on-premise Linux server.
  • Routing this interaction vertically through two separate corporate clouds introduces latency, privacy exposure, and single points of failure if WAN connectivity drops. Under IoCT, the visiting robot discovers the building’s local control plane upon entering the lobby, proves its identity and delivery authorisation, receives temporary, least-privilege permission to query the building’s hallway cameras for obstacle-free navigation, offloads heavy path-planning compute to the building’s server, calls the elevator, actuates the fourth-floor delivery lock, and has all permissions revoked automatically the moment it departs.

The four technical challenges of IoCT

Section titled “The four technical challenges of IoCT”

Enabling opportunistic, cross-domain collaboration across embedded hardware raises four core systems challenges identified by Hanafy et al. (2026)9:

  1. Device discovery and capability profiling: Because mobile nodes arrive and depart continuously, the local network must detect new devices automatically, query what sensors, actuators, and compute accelerators they offer, and configure network routing without human intervention (extending zero-configuration networking such as mDNS/DNS-SD across domains; Chapter 15).
  2. Cross-domain security, attestation, and access control: A building cannot blindly trust a visiting robot, nor can a visiting medical device blindly trust a host network. Every session requires cryptographic authentication of device identity, remote hardware attestation of both the executing code and shared data (using hardware roots of trust and Trusted Execution Environments; Chapter 19), and least-privilege, time-bounded access policies that grant only the exact resources needed for the visit and expire immediately upon departure.
  3. Heterogeneity-aware orchestration: Unlike homogeneous cloud server racks, an IoCT space contains a mix of 32-bit microcontrollers (ESP32, Cortex-M), 64-bit Linux gateways (Cortex-A), GPUs, and neural accelerators. The runtime must map computational tasks onto compatible hardware dynamically and re-allocate them when a device moves out of range or its battery runs low.
  4. Constrained execution: Physical AI workloads must run within tight SRAM, flash, battery, and thermal budgets, requiring runtime model partitioning, quantisation, or split inference between the leaf device and nearby gateways (Chapters 13 and 21).

Separation of the IoCT data plane and agentic control plane

Section titled “Separation of the IoCT data plane and agentic control plane”

To solve these four challenges without putting slow reasoning models in the real-time loop, Hanafy et al. (2026)9 split the IoCT architecture into two complementary layers (Figure 1.8):

Figure 1.8

IoCT control plane and data plane

Click any block or link to see what it does.

Agentic control plane: reasoning and policy, out-of-band
Data plane: wire-speed execution

Select a component or one of the two flows between the planes.

Figure 1.8. Separation of the Agentic Control Plane and the Data Plane in the Internet of Collaborating Things (adapted from Hanafy et al., 2026)9. Reasoning, cross-domain attestation, and policy generation happen out-of-band in the control plane, while the data plane enforces signed capability tokens at wire speed over MQTT/CoAP brokers and portable Wasm/TEE sandboxes.

  • The IoCT Data Plane (Nanotasks and Nanoservices): Applications are expressed as portable dataflow graphs composed of two building blocks:
    • Nanotasks: Platform-independent units of computation (such as an image-filtering step or a path-planning kernel) packaged in lightweight, isolated sandboxes such as WebAssembly (Wasm) paired with hardware Trusted Execution Environments (for example, WaTZ10 for Arm TrustZone remote attestation and Fortress for securing peripheral access). Because Wasm bytecode is portable, the same nanotask can be scheduled onto an Embedded Linux gateway or a microcontroller without recompiling the application.
    • Nanoservices: Well-defined network interfaces that expose a device’s physical sensors or actuators (for example, a lobby camera frame stream, an elevator-call service, or a smart-lock actuation primitive).
  • The IoCT Agentic Control Plane: Deciding which visiting device is allowed to use which resident nanoservice under changing physical context requires automated reasoning. Each administrative domain runs an orchestrator agent that communicates with its local control-plane registry via the Model Context Protocol (MCP) and negotiates as a peer with visiting domain orchestrators using structured Agent-to-Agent (A2A) protocol Agent Cards. Crucially, the AI agent never sits in the real-time data path: once the control plane verifies hardware attestations and agrees on a collaboration policy, it compiles that decision into short-lived, cryptographically signed capability tokens and pushes them to the data-plane message brokers (such as MQTT v5 brokers), which enforce access at wire speed.

This clean separation between high-level policy orchestration and deterministic, hardware-enforced data-plane execution is a core design principle you will apply throughout this book.

🧩 Knowledge Check

Section titled “🧩 Knowledge Check”
Concept Match

Match the layer of the computing continuum
Quiz
Select 0/2

Which of these Raspberry Pi gateway tasks belong to the fog control plane rather than the data plane?
Quiz
Select 0/1

Section 1.3 calls the Raspberry Pi an edge gateway. In this section's device-centric terms, what is it?
Quiz
Select 0/1

In the IoCT architecture of Hanafy et al. (2026), why does the orchestrator agent never sit in the real-time data path?

Footnotes

Section titled “Footnotes”

  1. F. Bonomi, R. Milito, J. Zhu, and S. Addepalli, “Fog Computing and Its Role in the Internet of Things,” in Proc. First Edition of the MCC Workshop on Mobile Cloud Computing, Helsinki, Finland, Aug. 2012, pp. 13–16, doi: 10.1145/2342509.2342513. ↩ ↩2

  2. W. Shi, J. Cao, Q. Zhang, Y. Li, and L. Xu, “Edge Computing: Vision and Challenges,” IEEE Internet of Things Journal, vol. 3, no. 5, pp. 637–646, Oct. 2016, doi: 10.1109/JIOT.2016.2579198. ↩

  3. IEEE Standards Association, IEEE Standard for Adoption of OpenFog Reference Architecture for Fog Computing, IEEE Std 1934-2018, June 2018. ↩

  4. M. Iorga, L. Feldman, R. Barton, M. J. Martin, N. Goren, and C. Mahmoudi, Fog Computing Conceptual Model, NIST Special Publication 500-325, National Institute of Standards and Technology, Mar. 2018, doi: 10.6028/NIST.SP.500-325. ↩

  5. European Telecommunications Standards Institute (ETSI), Multi-access Edge Computing (MEC); Framework and Reference Architecture, ETSI GS MEC 003. ↩

  6. LF Edge, Sharpening the Edge: Overview of the LF Edge Taxonomy and Framework, Linux Foundation White Paper, 2020. ↩

  7. European Commission, Directorate-General for Communications Networks, Content and Technology, The Next Generation Internet of Things — Shaping Europe’s Digital Future, Brussels, https://digital-strategy.ec.europa.eu/en/policies/next-generation-internet-things. ↩

  8. European Union Cloud-Edge-IoT (EUCEI) Initiative / OpenContinuum, Horizon Europe Meta-Operating Systems for the Cloud-Edge-IoT Continuum (ICOS, FluiDOS, NEMO, NebulOus, aeROS, NEPHELE), https://eucloudedgeiot.eu/. ↩

  9. W. A. Hanafy, N. Sehatbakhsh, D. Irwin, M. Srivastava, and P. Shenoy, “The Internet of Collaborating Things: Agentic Edge AI for Autonomous Cross-Domain Collaboration,” arXiv preprint arXiv:2609.10542v1, June 2026. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  10. J. Ménétrey, M. Pasin, P. Felber, and V. Schiavoni, “WaTZ: A Trusted WebAssembly Runtime Environment with Remote Attestation for TrustZone,” in Proc. IEEE 42nd International Conference on Distributed Computing Systems (ICDCS), July 2022, pp. 1177–1189. ↩

© 2026 Derek Molloy, Dublin City University. All rights reserved.