An Internet of Things (IoT) system connects physical objects to digital services so that conditions can be sensed, data can be exchanged, decisions can be supported, and actions can be performed. A connected device is therefore only one part of an IoT solution. A complete system also requires communications, data processing, applications, security, operations, and a business or organisational purpose.
Reference architectures provide an organised way to describe these parts. They are not usually construction plans for one particular product. Instead, they are conceptual models that help engineers identify responsibilities, interfaces, data flows, control flows, security boundaries, and technology choices. This chapter introduces the device, gateway, network, platform, application, and business layers through four influential views:
the three-layer IoT model;
the five-layer IoT model;
the IoT World Forum (IoTWF) reference model; and
the oneM2M functional architecture.
The models use different numbers of layers because they emphasise different design concerns. They should be understood as complementary rather than as competing descriptions of a single compulsory architecture.
Learning Objectives
By the end of this chapter, a learner should be able to:
explain the functions of devices, gateways, networks, platforms, applications, and business systems;
distinguish the three-layer and five-layer IoT models;
describe the seven layers of the IoT World Forum reference model;
explain the roles of application entities, common service entities, and network service entities in oneM2M;
trace sensing data and control commands through an end-to-end IoT system;
identify practical, security, governance, and reliability issues in IoT architecture selection.
1. From Connected Objects to IoT Systems
An IoT system normally contains the following functional elements:
Element
Main responsibility
Typical examples
Device
Senses or affects the physical world
temperature sensor, motor, smart meter
Gateway
Connects local devices and may translate, filter, or control data
industrial gateway, home hub
Network
Transfers information between components
Ethernet, Wi-Fi, LPWAN, cellular, the Internet
IoT platform
Registers devices, stores and processes data, exposes services
device-management and analytics platform
Application
Presents information and supports operational decisions
energy dashboard, fleet application
Business layer
Defines objectives, policies, processes, and value
maintenance policy, billing, compliance
These elements can be physically combined. For example, a smart thermostat may contain a sensor, processor, network interface, control algorithm, and user interface. Conversely, a large industrial installation may distribute these functions across hundreds of devices, several gateways, cloud services, and enterprise systems.
Devices
A device interacts directly with the physical environment. A sensor converts a physical quantity into a measurable signal; an actuator converts a digital command into a physical effect. Devices may also perform local computation, time-stamping, buffering, encryption, and event detection.
Important device design factors include measurement accuracy, sampling frequency, power consumption, environmental protection, identity, firmware update capability, and failure behaviour. A sensor reading without a timestamp, unit, device identity, and quality indicator may be difficult to interpret reliably.
Gateways and Edge Nodes
A gateway aggregates local devices and connects them to another network or platform. It may translate protocols, such as Bluetooth Low Energy to IP, or Modbus to MQTT. It may also authenticate devices, cache data during network outages, reduce traffic by filtering or summarising readings, and execute time-critical control logic.
The terms gateway and edge node overlap but are not identical. A gateway is primarily a connectivity and protocol boundary; an edge node is any nearby computing resource that processes data close to its source. A gateway can therefore be an edge node, but edge computing can also be performed by an industrial computer, local server, or intelligent device.
Networks
IoT networks include short-range personal-area networks, local-area networks, wide-area networks, cellular systems, and the Internet. Network selection depends on range, data rate, latency, reliability, mobility, spectrum, energy consumption, cost, and regulatory conditions.
A network transports data; it does not automatically give the data business meaning. A packet containing the value 24.5 is useful only when the receiving system knows what was measured, in which unit, at what time, and by which device.
Platforms
An IoT platform commonly provides device registration, identity management, message ingestion, storage, rules, analytics, dashboards, APIs, monitoring, and software-update services. Platforms can be located in a public cloud, a private data centre, at the edge, or in a hybrid arrangement.
A platform should not be treated as a single magic product. It is a collection of capabilities whose interfaces and operational responsibilities must be defined. Important architectural questions include who owns the data, how long it is retained, how services scale, how devices are provisioned, and how the platform behaves when connectivity is lost.
Applications and Business Systems
An IoT application uses processed information to support a human or an organisational process. Examples include a building-energy dashboard, predictive-maintenance application, cold-chain alert service, or automated irrigation controller.
The business layer is broader than the application interface. It includes objectives, processes, key performance indicators, policies, risk controls, legal duties, cost models, and decisions about responsibility. A technically successful sensor deployment may still fail if it does not improve a process or create sufficient value.
2. The Three-Layer IoT Model
The three-layer model is a simple introductory abstraction:
Perception layer – senses and acts on the physical environment.
Network layer – transports data and commands.
Application layer – delivers services to users or organisations.
Three-layer IoT architecture showing devices, networks, and applications with two-way arrows
Figure: Three-layer IoT architecture showing devices, networks, and applications with two-way arrows
Figure: The three-layer model represents sensing and actuation, communication, and service delivery.
The model is valuable because it is easy to communicate and useful for initial system scoping. However, it hides important distinctions. Data processing, storage, management, and business decisions are compressed into the application layer. Security is also not a separate layer; it must be applied across all layers.
3. The Five-Layer IoT Model
The five-layer model expands the simple view:
Perception layer: captures physical observations and performs actuation.
Transport layer: moves data between perception devices, processing systems, and applications using networks such as Wi-Fi, cellular, or wired links.
Processing layer: stores, filters, analyses, and manages data. This layer is often implemented by cloud and edge platforms.
Application layer: provides domain services such as healthcare monitoring, smart agriculture, or industrial control.
Business layer: manages the complete IoT system from an organisational perspective, including business models, policies, performance monitoring, and governance.
The processing layer makes an important distinction. Transport answers “How does information move?” Processing answers “How is information stored, interpreted, and made available?” The business layer answers “Why does the system exist, and how is its performance judged?”
The five-layer model is useful when designing interfaces. For instance, a sensor may publish measurements to a transport service; a processing platform may validate and store them; an application may display an alarm; and the business layer may trigger a maintenance procedure and record compliance evidence.
The layers are logical, not necessarily separate machines. A gateway may perform perception, transport, and processing functions. A cloud service may perform processing and application functions. This is called functional decomposition: responsibilities are separated conceptually even when hardware or software is combined.
4. The IoT World Forum Reference Model
The IoT World Forum (IoTWF) model presents seven layers, moving from physical devices toward collaboration and business processes:
Layer
Main concern
1. Physical devices and controllers
Sensors, actuators, machines, and embedded control
2. Connectivity
Reliable and secure movement of data
3. Edge computing
Local filtering, analysis, and immediate control
4. Data accumulation
Converting data in motion into data at rest
5. Data abstraction
Normalisation, integration, aggregation, and access
6. Applications
Monitoring, control, visualisation, and domain services
7. Collaboration and processes
People, organisations, workflows, and business outcomes
This model is especially useful for tracing what happens to data. A device produces a measurement at layer 1. Connectivity moves it at layer 2. Edge computing may reject invalid values or react locally at layer 3. Data accumulation stores it at layer 4. Data abstraction gives it a consistent model and makes it accessible at layer 5. An application uses it at layer 6, and people or business processes act on it at layer 7.
The model also helps identify design gaps. An organisation may have excellent sensors and connectivity but no process for responding to alarms. Alternatively, it may have a sophisticated dashboard but poor data abstraction, causing inconsistent units and device identifiers.
Security, management, and monitoring are cross-cutting concerns. Identity, confidentiality, integrity, availability, privacy, logging, and software maintenance must be addressed across all seven layers rather than assigned to only one layer.
5. oneM2M Functional Architecture
oneM2M is a standards-based approach for interoperable machine-to-machine and IoT systems. It uses a horizontal architecture rather than a simple vertical stack. The principal functional entities are:
Application Entity (AE): application logic that provides an IoT service, such as a smart-meter application or a fleet-monitoring application. Each AE has an application entity identifier.
Common Services Entity (CSE): a set of common service functions used by applications. These can include registration, discovery, security, device management, data storage, subscription and notification, and group management.
Network Services Entity (NSE): services supplied by an underlying network, such as location, device triggering, or connectivity-related capabilities.
A CSE may be located in a device, gateway, or infrastructure platform. oneM2M commonly distinguishes an Application Service Node (ASN), an Application Service Node Middle Node (MN), and an Infrastructure Node (IN). An ASN may contain an AE and CSE in a field device. An MN may be a gateway serving a local area. An IN is typically a central platform or cloud node.
Important reference points include:
Mca: interface between an AE and a CSE;
Mcn: interface between a CSE and an NSE;
Mcc: interface between two CSEs.
The oneM2M resource-oriented approach represents information and services through addressable resources. An application can create, retrieve, update, or delete resources and can subscribe to changes. This promotes interoperability because application functions use common service capabilities rather than relying on one proprietary vertical system.
oneM2M does not prescribe one radio technology or one cloud provider. It can operate over different underlying networks. Its value lies in common service functions and standardised interactions between applications, service platforms, and networks.
6. Comparing the Models
Concern
Three-layer
Five-layer
IoTWF
oneM2M
Main purpose
Basic teaching abstraction
Separates processing and business
Detailed data and process flow
Interoperable functional entities and interfaces
Device view
Perception
Perception
Physical devices/controllers
AE/CSE in node types
Gateway view
Usually network layer
Transport or processing
Connectivity and edge
Often a middle node containing a CSE
Data processing
Hidden in application
Explicit processing layer
Edge, accumulation, abstraction
Common services such as storage and discovery
Business processes
Mostly application
Explicit business layer
Collaboration and processes
Implemented by applications and connected systems
No model alone answers every engineering question. The three-layer model is effective for an introductory overview. The five-layer model is useful for teaching processing and governance. IoTWF is strong for end-to-end data-flow analysis. oneM2M is useful when standardised service functions and interoperability are central requirements.
7. End-to-End Data and Control Flow
Consider a greenhouse that measures temperature and soil moisture and controls ventilation and irrigation.
Upstream data flow
A sensor measures soil moisture and temperature.
The device attaches an identity, timestamp, unit, and quality status.
A local gateway receives the measurement over a short-range protocol.
The gateway validates the range, buffers data if the backhaul is unavailable, and may calculate a local average.
A network transports the message to an IoT platform.
The platform authenticates the source, stores the raw observation, and converts it into a standard data model.
A rule engine evaluates the observation against configured conditions.
An application displays current conditions, trends, and alarms.
A grower or maintenance process responds to the information.
Downstream control flow
The application or rule engine creates a command, such as “open vent to 60%.”
The platform authorises the command and records its origin and time.
The command is sent through the network to the gateway.
The gateway checks that the target device is registered and reachable.
The actuator receives the command and changes the vent position.
A feedback sensor reports the resulting position or environmental change.
The platform records whether the command succeeded, failed, or timed out.
A control loop is stronger when it includes feedback. Sending a command is not equivalent to achieving the desired physical state. The system should distinguish command requested, command accepted, command executed, and outcome observed.
Worked data-volume example
Suppose 40 sensors send one reading every 60 seconds. Each encoded application message is 180 bytes, excluding lower-layer overhead. The daily application payload is:
V = n × r × s × t
where V is volume in bytes, n is the number of sensors, r is readings per second, s is message size in bytes, and t is time in seconds. For one day, n = 40, r = 1/60 s⁻¹, s = 180 bytes, and t = 86,400 s.
V = 40 × (1/60) × 180 × 86,400 = 5,184,000 bytes
This is approximately 5.184 MB using decimal units, before protocol overhead, retransmissions, metadata, and storage replication. The calculation applies only to the stated fixed-rate payload assumption. Event-driven devices, retries, compression, and variable message sizes require a different estimate.
8. Illustrative Case: Cold-Chain Monitoring
Background. A pharmaceutical distributor transports temperature-sensitive medicines from a warehouse to clinics. Regulations and product specifications require temperature records throughout transport.
Problem. Manual checks are infrequent, batteries are limited, network coverage is intermittent, and an alarm must reach staff quickly when temperature exceeds a permitted range.
Analysis. A sensor placed in each container measures temperature. A gateway in the vehicle collects readings from several containers and uses cellular connectivity when available. Because connectivity may fail, the gateway must store readings locally. A cloud platform provides device identity, time-series storage, alert rules, and an audit trail.
Approach. The architecture can be described using the five-layer model. Sensors belong to the perception layer; the vehicle gateway and cellular connection support transport; local buffering and cloud storage belong to processing; the monitoring dashboard is the application; and quality assurance, incident response, and regulatory reporting belong to the business layer. In IoTWF terms, local alarm evaluation is edge computing, reliable local recording is data accumulation, and standard temperature records are data abstraction.
The gateway should generate an immediate local alert if a dangerous threshold is crossed, rather than depending entirely on cloud connectivity. When the network returns, buffered records are uploaded with their original timestamps. The platform should detect missing intervals, authenticate devices, restrict access by role, encrypt communications, and record any change to alarm thresholds.
Outcome. The distributor gains continuous evidence, faster intervention, and clearer responsibility. However, the system does not guarantee product safety by itself. Sensors require calibration, batteries require replacement, and staff must have a defined procedure for responding to alarms.
Learning points. The case demonstrates that architecture must address physical measurement, connectivity failure, local control, data integrity, application usability, and organisational process together. A dashboard without governance is not a complete IoT solution.
9. Security, Privacy, and Governance
IoT systems expand the attack surface because many devices are physically accessible, constrained in memory and power, and deployed for long periods. Good practice includes unique device identities, secure onboarding, least-privilege access, encrypted communication, signed firmware updates, vulnerability management, secure defaults, logging, and a documented decommissioning process.
Security objectives can be expressed as confidentiality, integrity, and availability. Integrity is particularly important in control systems: an altered sensor value or command may create physical harm. Availability must be considered at several levels, including device power, network coverage, gateway operation, platform capacity, and human response.
Privacy is relevant when IoT data can identify people, infer behaviour, or reveal sensitive locations. Organisations should collect only necessary data, define retention periods, control access, explain uses, and apply relevant data-protection law. Environmental and industrial data may also be commercially sensitive even when it is not personal data.
Governance assigns responsibility. It should specify who owns data, who approves devices, who can issue commands, who responds to alarms, how suppliers are assessed, and how incidents are reported. Standards and regulations vary by sector and jurisdiction, so architecture teams must consult applicable legal and industry requirements rather than assuming that a generic platform is compliant.
10. Design Guidance and Limitations
A practical architecture process should begin with the physical and organisational problem, not with a preferred product. Identify measurements, required response times, control consequences, data ownership, environmental conditions, and failure modes. Then allocate functions among device, gateway, network, platform, application, and business systems.
Use edge processing when latency, bandwidth, privacy, or resilience requires local action. Use cloud or central processing when large-scale storage, cross-site analysis, or shared management is important. In many systems, the appropriate answer is hybrid.
Avoid confusing interoperability with compatibility. Two systems may both use IP yet disagree about data meaning, identity, commands, or security. Interoperability requires compatible communication, information models, service semantics, and operational agreements.
Reference models also have limitations. Their boundaries are conceptual and may overlap in real products. They do not automatically determine deployment topology, performance, cost, or safety. A model can organise thought, but testing, threat modelling, monitoring, and field validation are still necessary.
Contemporary Developments
Current IoT architectures increasingly combine edge AI, digital twins, event-driven platforms, and zero-trust security. Edge AI can detect anomalies locally, reducing latency and bandwidth, but models must be updated, monitored for drift, and protected from manipulation. Digital twins provide a structured representation of an asset and its state; they are useful only when the underlying data is timely and trustworthy. Event-driven systems allow applications to react to changes rather than repeatedly polling devices.
These developments do not replace the reference models. They occupy or cross several logical layers. For example, an anomaly-detection model may run at the edge, use platform-managed data, and trigger an application-level maintenance process.
Chapter Summary
IoT is a complete system of devices, gateways, networks, platforms, applications, and business processes. The three-layer model provides a simple view of perception, network, and application functions. The five-layer model separates perception, transport, processing, application, and business concerns. The IoT World Forum model provides seven layers that trace data from physical devices through connectivity, edge computing, accumulation, abstraction, applications, and organisational processes. oneM2M presents interoperable application entities, common services entities, and network services entities connected through standard reference points.
An end-to-end IoT design must trace both upstream data and downstream control. It must also account for feedback, local operation, data meaning, security, privacy, reliability, governance, and measurable business outcomes. Reference architectures support clear communication and design analysis, but they do not remove the need for engineering judgement and operational validation.
Key Terms
Device: A physical or embedded component that senses, computes, or acts.
Sensor: A component that measures a physical quantity.
Actuator: A component that produces a physical effect in response to a command.
Gateway: A node that connects local devices to another network or service.
Edge computing: Processing performed near the source of data.
Network: A communication infrastructure that transfers information.
IoT platform: Services for device management, ingestion, storage, processing, and access.
Application: Software that delivers an IoT service to users or organisations.
Business layer: Objectives, policies, processes, governance, and value measures.
Perception layer: The layer responsible for sensing and actuation.
Transport layer: The five-layer function that moves data between components.
Processing layer: The function that stores, analyses, and manages IoT data.
IoTWF: The IoT World Forum seven-layer reference model.
oneM2M: A standards-based architecture for interoperable IoT and machine-to-machine services.
Application Entity (AE): oneM2M logic that provides an application service.
Common Services Entity (CSE): oneM2M entity providing shared service capabilities.
Network Services Entity (NSE): Network-provided services used by a CSE.
Data accumulation: Converting data in motion into stored data.
Data abstraction: Normalising and integrating data for meaningful access.
Control flow: The movement of commands and feedback through a system.
Review Questions
Short Answer Questions
What are the three layers of the basic IoT model?
State two functions commonly performed by an IoT gateway.
Why is the processing layer explicit in the five-layer model?
What is the purpose of an Application Entity in oneM2M?
Why is feedback important in an IoT control loop?
Long Answer Questions
Explain the device, gateway, network, platform, application, and business elements of an IoT system.
Compare the three-layer and five-layer IoT models, including their strengths and limitations.
Describe all seven layers of the IoT World Forum reference model.
Explain oneM2M entities and reference points and discuss how they support interoperability.
Discuss security, privacy, and governance requirements for a connected industrial system.
Analytical / Application Questions
Design a layered architecture for a smart-building system that monitors occupancy and controls ventilation. Justify where sensing, edge processing, storage, applications, and business policies should be located.
A remote water pump must continue operating when cellular connectivity fails. Analyse which functions should be placed at the device or gateway and which can remain in the cloud.
Trace the complete data and control flow for an IoT fire-alarm system, identifying possible failures and the controls needed to maintain safety.
Multiple Choice Questions with Answers
Question 1
Which layer of the three-layer IoT model directly interacts with the physical environment?
A. Perception layer
B. Network layer
C. Application layer
D. Business layer
Correct Answer: A. Perception layer
Question 2
What is a primary function of an IoT gateway?
A. Replacing every sensor battery automatically
B. Translating protocols and aggregating local device data
C. Defining all business policies
D. Eliminating the need for security
Correct Answer: B. Translating protocols and aggregating local device data
Question 3
Which layer in the five-layer model is responsible for storing and analysing IoT data?
A. Perception
B. Transport
C. Processing
D. Business
Correct Answer: C. Processing
Question 4
In the IoT World Forum model, which layer converts data in motion into data at rest?
A. Connectivity
B. Edge computing
C. Data accumulation
D. Applications
Correct Answer: C. Data accumulation
Question 5
Which oneM2M entity provides common functions such as registration, discovery, and data storage?
A. Application Entity
B. Common Services Entity
C. Network Services Entity
D. Sensor Entity
Correct Answer: B. Common Services Entity
Question 6
What does the oneM2M Mca reference point connect?
A. An AE and a CSE
B. Two sensors only
C. A CSE and a battery
D. Two unrelated business departments
Correct Answer: A. An AE and a CSE
Question 7
Why might a gateway perform local processing in an IoT system?
A. To increase dependence on continuous cloud connectivity
B. To reduce latency and continue limited operation during outages
C. To remove the need for device identity
D. To prevent all data storage
Correct Answer: B. To reduce latency and continue limited operation during outages
Question 8
A system has 40 sensors, each sending one 180-byte message every 60 seconds. Approximately how many decimal megabytes of payload are generated per day?
A. 0.5184 MB
B. 5.184 MB
C. 51.84 MB
D. 518.4 MB
Correct Answer: B. 5.184 MB
Question 9
Which statement best distinguishes a command from a successful control outcome?
A. A command is always proof that the actuator changed state
B. A successful outcome requires feedback or evidence that the physical state changed
C. Commands do not need authorisation
D. Feedback is relevant only to dashboards
Correct Answer: B. A successful outcome requires feedback or evidence that the physical state changed
Question 10
Which is an example of a cross-cutting IoT concern?
A. Device colour
B. Security and identity management
C. A single dashboard button label
D. One specific sensor brand
Correct Answer: B. Security and identity management