LECTURE 11

Internet of Things and Smart Device Networks

Duration: 120 min of teaching Level: undergraduate, year III - recommended after Lecture 10 Course: Embedded Systems Associated laboratory: Laboratory 04 PDF: download the notes RO versiunea română

The lecture that closes the series: how an embedded node, with the sensors, energy source and consumption mode discussed in earlier lectures, becomes part of a real distributed system. We go through the layered architecture of an IoT system (device, edge, cloud), the network topologies and their trade-offs, communication technologies from BLE to LoRaWAN, application-layer protocols (MQTT, CoAP), and finally the management and security of a device fleet across its entire lifecycle.

1The subject and structure of the lecture6 min

The Internet of Things (IoT) describes the integration of physical objects, sensors, actuators and embedded systems into communication infrastructures and digital services. Unlike a traditional computer network, where data is mainly entered by users, an IoT system automatically and continuously collects information about real objects and processes.

The IoT loop
physical environment → sensors → processing → network → application → actuators
Recap from earlier lectures
  • A sensor node (Lecture 10) alternates between sleep and active states, with duty cycle D = T_active/T_cycle
  • Radio communication is usually the most energy-costly operation (Lecture 04)
Today we connect that node to the rest of the world - network, protocols, gateway, cloud - and analyze what that changes about the design decisions.

Learning outcomes

  • Describe the layered architecture of an IoT system (device, edge, cloud)
  • Choose a network topology (star, tree, mesh) based on the application requirements
  • Compare IoT communication technologies based on range/rate/consumption
  • Distinguish the MQTT model (publish/subscribe) from the CoAP model (resource-based)
  • Calculate the energy budget of a radio transmission, including retransmissions
  • Describe the lifecycle of an IoT device and the associated security requirements

2From embedded system to IoT node8 min

A traditional embedded system performs a well-defined function and can operate completely in isolation - a temperature controller, a motor drive module. By adding connectivity, the system can transmit measurements, receive configurations, report errors, cooperate with other devices and be updated remotely.

From embedded system to IoT node embedded system + identity + connectivity + services = IoT node. A local thermostat measures temperature and drives the heating; an IoT thermostat can additionally receive remote schedules, transmit consumption history and take part in optimizing the energy use of an entire building. Connectivity, however, introduces new responsibilities: protecting communications, handling network errors, synchronizing data, updating firmware and administering the device identity.

Sensors turn physical quantities into digital data; actuators do the reverse. For a physical quantity x(t), acquisition generates samples x[k] = x(kT_s). The data can be filtered locally, z[k] = F(x[k], x[k-1], ...), and the result can generate a command u[k] = G(z[k], r[k]).

Example - an irrigation system

soil moisture → decision → valve opening. The decision can be made directly by the node, by a local gateway, by an edge application or by a cloud service - where the decision is executed directly affects latency, energy consumption, network dependence and data privacy, exactly the themes that come up throughout the rest of this lecture.

A connected device is not automatically a complete IoT system

To take part in an IoT ecosystem, the device must be integrated into a service that allows at least: identifying the device, collecting or modifying data, communicating over a network, processing the information, and administration throughout its operational life.

3Characteristics and requirements of IoT systems10 min

IoT systems combine resource-constrained devices, heterogeneous networks and distributed services. An architecture must work not just for a prototype with a few nodes, but under real operating conditions: packet loss, power interruptions, unpatched devices, gateway failures, a growing number of nodes.

Scalability

Network traffic volume
For N nodes, each transmitting at frequency f_m: N_messages = N·f_m. With average message length L_m: D = N·f_m·L_m - without including headers, acknowledgments or retransmissions, which significantly increase the real value.

Energy, latency and reliability

The energy of a message and the total latency
E_message = E_wakeup + E_processing + E_TX + E_ack
L_total = L_node + L_access + L_network + L_processing + L_actuation
The trade-offs oppose each other More frequent transmissions reduce latency, but increase traffic and energy consumption. For slow temperature monitoring, a latency of a few seconds may be acceptable; for stopping a machine when a dangerous condition is detected, the decision must be made locally, very close to the process - it cannot wait for a full round trip to the cloud and back.

Local intelligence and autonomy

Local processing reduces the volume of transmitted data and lowers latency - instead of transmitting every sample, the node can send only average, minimum, maximum values, events or the result of a classification.

Decision criterion for local processing
E_processing + E_reduced_message < E_full_message - if local processing is energy-cheaper than transmitting the full data, it is worth applying.

Functional autonomy also implies the ability to keep essential services running while disconnected from the cloud - the node or gateway can temporarily store measurements, apply local rules and retransmit the data once the connection is restored.

4The architecture of an IoT system10 min

A practical model for IoT architecture includes four layers: devices and physical processes, communication, edge and gateway, services and applications - a model for organizing responsibilities, not a single universal standard.

LayerRole
Devicessensors, actuators, microcontrollers, power sources
Communicationdata transport: local technologies, LPWAN, cellular, wired
Edge/Gatewayfiltering, aggregation, protocol conversion, local decisions
Cloudlong-term storage, large-scale analysis, fleet management

The upstream flow carries the data: sensor → node → gateway → service → application. The downstream flow carries configurations, thresholds, commands, updates and acknowledgments - together they form the control loop measurement → decision → command → process.

Commands must be validated, not executed blindly

An actuator must not automatically accept any message received from the network. For every message, the following matter: the source, the destination, the time it was produced, the format version, authenticity and value validity - an unvalidated command is an open door for accidental or intentional manipulation of the physical process.

The role of the gateway

The gateway connects the local device network to the IP or cloud infrastructure: protocol conversion, message aggregation, temporary storage, node authentication, terminating secure connections and handling updates. It is not mandatory in every system - a Wi-Fi or cellular device can talk directly to the cloud - but it becomes useful when the nodes use local protocols, have limited resources, or must operate without Internet access.

The gateway can become a single critical point The design must explicitly consider gateway failure, loss of power, unavailability of the external connection, security compromise and exceeding processing capacity - a single point of failure for every node in the area it serves.
The path of a measured value, from sensor to dashboard

5Smart sensor nodes10 min

The sensor node is the direct interface between the IoT system and the physical environment. The main components are similar regardless of the application: sensors and conditioning circuits, an analog-to-digital converter, a microcontroller, memory, a transceiver, a power management circuit.

The internal flow of a node
acquisition → validation → processing → formatting → transmission

Validation can detect out-of-range values, sensor communication errors, incomplete data or physically impossible variations. A useful message does not contain only the measured value - it usually includes the node identifier, the timestamp, the unit of measure, the battery status and the sequence number.

Example - threshold-triggered transmission

A node can transmit the temperature only if the change exceeds a threshold: |T[k] - T_transmitted| ≥ ΔT_min, with a periodic keep-alive transmission to avoid a very long period without messages. The strategy reduces traffic, but must be designed so the application can distinguish a genuinely constant value from a faulty node that has simply stopped transmitting.

Cyclic operation

Duty cycle and cycle energy
D = T_active / T_cycle; E_cycle = Σ Pᵢtᵢ (exactly the formula used for the consumption profile in Lecture 10).
The net savings from local processing E_savings = E_communication_avoided - E_local_processing. Local processing is energy-advantageous only if E_savings > 0. If an accelerometer generates 1000 samples per second, transmitting all of it can be costly - the node can locally compute an indicator (RMS value, spectral components) and transmit only the result, provided the local processing energy is smaller than the energy saved on transmission.

6Topologies and the organization of IoT networks10 min

Topology describes how devices are logically connected and the paths information travels through - it affects consumption, latency, fault tolerance and the ability to add new nodes. It must be distinguished from the communication technology: a network based on IEEE 802.15.4 can be organized as a star, a tree or a mesh, depending on the protocol used.

TopologyPrincipleAdvantageLimitation
Point-to-pointdirect link between two devicessimplicity, low latencydoes not scale to many nodes
Starall nodes talk to a central hublow node consumption, simple administrationdependence on the central element
Treehierarchical organization, aggregation across levelsscalabilityan intermediate node failure isolates the branch
Meshevery node can talk to several neighborsalternative paths, fault tolerancecomplexity, routing traffic, higher consumption from relaying

In a star topology, the peripheral nodes do not relay other devices' messages - they can stay in low-power modes most of the time, which is why the star topology is common in Wi-Fi, BLE with a central device, LoRaWAN and cellular IoT networks.

The reliability of a mesh path with H hops
Assuming independent links: P_delivery = Π pᵢ, i=1..H. With the same probability p on every link: P_delivery = p^H.
Worked exercise

A message must travel 4 hops in a mesh network, each link having a success probability p = 0.95. What is the end-to-end delivery probability?

See the solution

P_delivery = 0.95⁴ ≈ 0.815

Although each individual link is 95% reliable, the delivery probability across the whole path drops to ~81.5% - adding more hops does not automatically guarantee higher reliability; alternative paths and retransmissions, managed by the routing protocol, are what actually recover the reliability, not the raw number of hops.

The energy of a node with a routing function: E_node = E_own + E_reception + E_relay - nodes placed close to the gateway may relay a significant part of the network traffic and can drain faster than peripheral nodes, an important asymmetry to anticipate at design time.

Choose the right topology for each scenario

7Communication technologies for IoT10 min

The communication technology must be chosen based on the application, not just on the advertised maximum range - the real parameters depend on frequency, transmit power, antenna, obstacles and interference.

Simplified radio link budget
P_R = P_T + G_T + G_R - L_path - L_extra [dB]. The link is possible if the received power exceeds the receiver sensitivity by a sufficient margin.
TechnologyCoverageDominant characteristicApplications
BLElocallow consumption, mobile integrationwearables, personal sensors
Wi-Filocalhigh transfer ratemultimedia, powered equipment
Zigbee / Threadlocal, star or meshdistributed low-power networksbuildings, automation
LoRaWANwide, through gatewayssmall, infrequent messagesagriculture, Smart City
NB-IoTwide, through the carrierlow traffic, cellular coveragemetering, monitoring
LTE-Mwide, through the carriermobility, lower latencylogistics, mobile devices

IEEE 802.15.4 defines only the physical layer and medium access - Zigbee, Thread and 6LoWPAN add network and application functions on top of it. Thread is oriented toward IPv6 (it joins an IP network through a border router); Matter is an application-layer protocol for interoperability, which can run over Thread, Wi-Fi or Ethernet - it is not a new radio technology.

A weak link can cancel the advantage of a low-power technology E_delivery ≈ E_attempt / p_s, where p_s is the success probability of an attempt. If the radio link is weak, the number of retransmissions grows, and the average energy per delivery can significantly exceed the energy of a single ideal transmission - an "efficient" technology on paper can become costly in an environment with difficult propagation.

Technology selection should go through: the distance and propagation environment, the size and frequency of the messages, the acceptable latency, the power source, the available infrastructure, the link and energy budget, and the spectrum and security restrictions - in this order, not starting from a technology preferred in advance.

The energy cost of a transmission, retransmissions included

8IoT protocols and software stacks10 min

The radio technology establishes how bits are transmitted; a complete IoT system needs additional protocols for addressing, routing, transport, security and exchanging information between applications - a layered stack: physical/medium access, network/adaptation, transport, security, application.

IPv6 and 6LoWPAN

IPv6 uses 128-bit addresses (N_IPv6 = 2¹²⁸), but in networks with small frames, transmitting full IPv6 headers produces significant overhead. 6LoWPAN introduces an adaptation layer: header compression, fragmentation and reassembly for reduced frames.

Worked exercise

A 300-byte IP packet must be fragmented into frames with a maximum payload of 80 bytes. What is the minimum number of fragments needed?

See the solution

N_F = ⌈300/80⌉ = ⌈3.75⌉ = 4 fragments

Losing a single fragment can require retransmitting part or all of the packet, depending on the protocol - which is why IoT messages must be kept as compact as possible, directly reducing the number of fragments needed.

MQTT - publish/subscribe

MQTT is based on an intermediary broker: a publisher publishes messages on a topic, and any subscriber subscribed to that topic receives them, without the producer knowing the recipients directly.

// a node publishes to:
agriculture/zone1/node12/temperature

// an application subscribes to:
agriculture/zone1/+/temperature
The three QoS levels of MQTT QoS 0 (at most once - no guarantee), QoS 1 (at least once - may duplicate) and QoS 2 (exactly once at the protocol level). QoS 1 can produce duplicate messages - the application must be able to recognize and safely handle retransmissions, for example through the sequence number included in the message.

CoAP - resource-based model

CoAP (Constrained Application Protocol) is conceptually close to REST, with GET, POST, PUT, DELETE operations on resources addressed by a URI (coap://node12.local/sensors/temperature).

MQTT or CoAP - depends on the architecture, not the message size

A node that periodically transmits measurements to several applications fits the MQTT model (distribution through a broker). A system in which a controller reads an actuator's state directly and modifies its configuration fits better with CoAP (direct access to a resource). The right choice starts from the application's interaction flow.

Regardless of the protocol, a useful message must specify the quantity identifier, the value, the unit of measure, the timestamp and the format version - real interoperability requires compatibility at several levels at once: connectivity, protocol, message structure, and data meaning.

9Edge, gateway and cloud infrastructures8 min

Where the time goes, from sensor to decision

The processing of an IoT system can be distributed among nodes, gateways, edge servers and cloud infrastructures - not all data must be sent to the cloud. Choosing where to process depends on the maximum acceptable latency, the data volume, the available connectivity, privacy and the cost of communication.

LayerTypical functions
Devicesimple filtering, threshold detection, immediate control - minimum latency
Gateway/Edgeaggregation, local correlation, protocol conversion, temporary storage - local context
Cloudhistorical storage, global analysis, reporting, fleet management - scalability
A critical function is not blindly moved to the cloud

L_total = L_device + L_access + L_gateway + L_transport + L_service - if latency or network unavailability could produce a dangerous state, the decision must stay local, no matter how attractive centralizing it in the cloud looks for analysis purposes.

Aggregation and offline operation

Instead of transmitting every sample, the gateway can aggregate: the average, minimum, maximum, standard deviation, event count, or only the values exceeding a threshold - x̄ = (1/N)Σxᵢ.

Minimum offline buffer capacity
C_buffer ≥ R_D · T_offline, where R_D is the data generation rate, and T_offline the estimated maximum duration of the connection interruption.

After communication is restored, the messages must be retransmitted without losing order and without uncontrolled duplication - the timestamp, the sequence number and the retransmission flag are essential for the application to correctly reconstruct the history.

10Managing IoT devices8 min

Administering an IoT fleet covers every operation from manufacturing the device to retiring it from service.

The lifecycle of an IoT device
manufacturing → enrollment → configuration → operation → update → retirement, with repeated cycles between operation and update.

Enrollment assigns the device a verifiable identity - symmetric keys, asymmetric key pairs, digital certificates or an identity stored in a secure element. Every device must have a unique identity: using the same key for an entire product family drastically multiplies the impact of compromising a single unit.

During operation, the firmware version, battery level, communication quality, resets and sensor errors must be monitored - a typical diagnostic message contains exactly these fields, similar to measurement messages, but oriented toward the device's internal state rather than the application's data.

Firmware updates (OTA)

Over-the-air updates allow fixing vulnerabilities without physical access to the device: downloading the image, verifying authenticity and integrity, installing, rebooting, confirming correct operation.

Worked exercise

A 512 KB firmware image must be transmitted in 4 KB blocks. What is the minimum number of blocks needed?

See the solution

N_B = ⌈512/4⌉ = 128 blocks

The update must tolerate a power interruption and connection loss - which is why two firmware partitions are often used, along with a backup image, post-boot confirmation, and automatic rollback to the previous version if the new image fails to confirm correct operation.

When a device is retired, its identities must be revoked and its keys and sensitive data erased - a step often skipped, but just as important as the initial enrollment.

11Security of IoT systems8 min

IoT security must be designed for the whole system and its entire lifecycle - protecting only the communication is not enough if the firmware can be modified or if every device uses the same key.

An attacker can act on the device, the radio link, the gateway, the cloud services, the user application or the update process - the threats include interception, message tampering, replaying old messages, impersonating a node and installing malicious firmware.

The Secure Boot chain of trust
trusted ROM → bootloader → firmware → application, each stage verifying the signature or cryptographic value of the next one - exactly the mechanism discussed for FPGA bitstreams in Lecture 09, applied here to an IoT node's firmware.
Encryption alone does not guarantee authenticity A secure channel must simultaneously provide entity authentication, message integrity, anti-replay protection and confidentiality where needed. To prevent replaying an old message, sequence numbers, monotonic counters, nonces or timestamps are used - without them, an attacker can replay a legitimate old message (for example "open the door") whenever they want.
Acceptance condition for a firmware image
Valid = CorrectSignature ∧ AllowedVersion ∧ CompatiblePlatform - verifying integrity through an unprotected hash is not enough, because an attacker can modify both the image and the associated hash.

The least-privilege principle applies here too: a node that publishes temperature readings must not be able to modify other devices' configuration or administer the broker - every component receives only the rights strictly necessary for its function.

12Representative IoT applications4 min

Representative domains for IoT include industrial automation and predictive maintenance, smart agriculture and environmental monitoring, urban infrastructure (Smart City), smart buildings, digital health and energy management.

The goal is not the volume of data, but its usefulness An IoT system must produce useful information or actions: detecting an anomaly, reducing energy consumption, optimizing a process, preventing a failure, improving safety, or automating a repetitive decision - collecting a large volume of data, with no clear use for it, does not by itself justify the complexity and cost of an IoT system.

Each domain combines the concepts of this lecture differently: agriculture typically combines LoRaWAN (wide coverage, infrequent messages) with local edge processing and offline operation tolerant of connectivity interruptions; industrial automation often combines local mesh networks with gateways that aggregate and transmit only relevant events; smart buildings frequently use Zigbee or Thread for the high node density over a small area.

13Frequent mistakes5 min

  • "A mesh network is more reliable than a star network, because it has more paths." Not automatically - the reliability of a path with H hops is P_delivery = p^H, which decreases with the number of hops if there are no retransmissions or actively managed alternative paths. Evaluate the real reliability of the routing protocol, do not assume that more paths automatically means more reliability.
  • "MQTT and CoAP are interchangeable, the choice depends only on message size." False - the choice depends on the interaction architecture: distribution through a broker (MQTT) vs. direct access to a resource (CoAP), a structural criterion, not just an efficiency one. Analyze the application's real interaction flow before choosing the protocol.
  • "Encrypting the communication is enough for a secure IoT system." No - security must cover the entire lifecycle: Secure Boot, signed updates, unique per-device identities and the least-privilege principle, not just the communication channel. Build the threat model for the entire chain (device → network → gateway → cloud → application), not just for the data transport.

14Summary and glossary5 min

An IoT system extends an embedded node with an identity, connectivity and services - but this extension brings explicit trade-offs between latency, energy, reliability and scalability, which must be evaluated together, not in isolation. The layered architecture (device, edge, cloud) allows intelligent distribution of the processing, and choosing the right location depends on how critical and how time-sensitive a decision is. The network topology (star, tree, mesh) and the communication technology (BLE, Zigbee, LoRaWAN, cellular) must be chosen starting from the application's real requirements - range, rate, energy, available infrastructure - not from the popularity of a technology. MQTT and CoAP cover different interaction models (publish/subscribe versus resource access), and 6LoWPAN adapts IPv6 to resource-constrained networks. Managing an IoT fleet covers the whole lifecycle - enrollment, configuration, OTA updates, retirement - and security must be designed for this complete cycle, not just for the communication channel.

Edge computing
processing data close to the source, before it reaches the cloud.
MQTT
a publish/subscribe protocol, mediated by a broker, for distributing event streams.
CoAP
Constrained Application Protocol - a resource-based model, close to REST.
6LoWPAN
an adaptation layer that compresses and fragments IPv6 packets for networks with small frames.
LoRaWAN
an LPWAN network architecture for small, infrequent messages over long distances.
OTA
Over-The-Air - remote firmware updating, with no physical access.
Secure Boot
a chain that verifies firmware authenticity before execution.

15Self-check questions6 min

  1. What turns an isolated embedded system into an IoT node?
  2. Why should a critical function with strict latency requirements not be moved exclusively to the cloud?
  3. What is the difference between the star and mesh topologies, from the reliability perspective?
  4. Why does the number of hops in a mesh network not automatically guarantee higher reliability?
  5. What is the structural difference between the MQTT model and the CoAP model?
  6. What role does 6LoWPAN play in an IEEE 802.15.4 network?
  7. List the stages of an IoT device's lifecycle.
  8. Why is an unprotected hash not enough for validating a firmware update?

16Closing the series2 min

This was the last lecture of the Embedded Systems series. The eleven lectures have covered the full path - from a processor's architecture and its energy consumption, through synchronization and real-time operating systems, hardware acceleration and harvesting energy from the environment, to integrating a node into a complete IoT network, with its management and security.

The concepts from this lecture - topologies, MQTT, gateways and device management - become real code and real measurements in Laboratory 04, where you build a complete IoT node, from sensor to dashboard.