Embedded Systems for IoT

Chapter 9
IoT Connectivity and Messaging

Diploma in IOT
Embedded Systems for IoT   •   Diploma

IoT Connectivity and Messaging

Introduction

An Internet of Things (IoT) system is useful only when its devices can exchange information reliably, economically and securely. Connectivity provides the communication path between sensors, actuators, gateways, cloud platforms and users. Messaging defines how application data is represented, delivered and acknowledged across that path.

Connectivity decisions are rarely based on range alone. A designer must consider bandwidth, latency, power consumption, topology, reliability, installation environment, security, device density, operating cost and regulatory constraints. For example, a battery-powered soil sensor may favour LoRaWAN, while an industrial controller may require Ethernet and a smart-home light may use Thread or Wi-Fi.

This chapter compares major IoT networking technologies and explains the relationship between local links, IP networking and application protocols. It also presents practical selection methods and an applied smart-building case.

Learning Objectives

After studying this chapter, the learner should be able to:

  1. Compare Wi-Fi, Bluetooth Low Energy (BLE), Zigbee, Thread, LoRaWAN, cellular IoT and Ethernet.
  2. Explain range, bandwidth, topology, power, reliability and operating-cost trade-offs.
  3. Describe the roles of TCP, UDP, IPv4, IPv6 and common IoT application protocols.
  4. Apply MQTT, CoAP and HTTP to suitable IoT scenarios.
  5. Design a basic connectivity and messaging architecture.
  6. Identify security, regulatory, operational and ethical issues in IoT communication.

1. Communication Architecture of an IoT System

IoT communication is commonly described in layers:

  • Device layer: sensors, actuators, microcontrollers and embedded radios.
  • Link layer: the local physical and radio technology, such as Ethernet, Wi-Fi, BLE or IEEE 802.15.4.
  • Network and transport layers: IP addressing, routing and end-to-end transport using TCP or UDP.
  • Application layer: data exchange using MQTT, CoAP, HTTP or another protocol.
  • Platform and application layer: storage, analytics, dashboards, automation and device management.

A gateway may translate between non-IP devices and an IP network. For example, a BLE sensor can communicate with a phone or gateway, which then publishes data to an MQTT broker over Wi-Fi or cellular service. Thread devices, in contrast, are IP-based and can communicate using IPv6 through a border router.

A useful distinction is between communication technology and messaging protocol. Wi-Fi is a network access technology; MQTT is an application messaging protocol. They are not direct alternatives. MQTT can run over TCP on Wi-Fi, Ethernet or cellular IP networks. CoAP normally uses UDP, while HTTP normally uses TCP or, in modern deployments, QUIC over UDP.

2. Criteria for Selecting Connectivity

Range and propagation

Range depends on transmit power, antenna design, frequency, receiver sensitivity, obstacles, interference and regulatory limits. A quoted range is not a guaranteed indoor distance. Walls, metal structures and human bodies can substantially reduce performance.

Bandwidth and payload

Bandwidth is the data-carrying capacity of a link, usually measured in bit/s. IoT devices often transmit small payloads but may require occasional firmware updates, images or audio. A low-bandwidth technology can support periodic temperature readings but is unsuitable for video.

Latency and responsiveness

Latency is the time between sending information and receiving a response. Alarm systems, motor control and interactive applications need low and predictable latency. A technology with high nominal bandwidth may still provide poor control performance if its latency is variable.

Power consumption

Battery life depends on radio current, transmission duration, sleep current, sensor activity, processing and battery characteristics. A simple energy relationship is:

E = P × t

where E is energy in joules, P is power in watts and t is time in seconds. This equation applies when power is approximately constant. For varying power, total energy is represented by the integral of power over time. Radio duty cycle is important: a device that sleeps for most of its life may consume far less energy than an always-listening device.

Reliability and availability

Reliability is influenced by link budget, interference, retransmission, route diversity, congestion, power failure and service-provider coverage. A system should define acceptable packet loss, delay and recovery time rather than treating “connected” as a binary condition.

Topology

Common topologies include:

  • Point-to-point: one device communicates with one peer.
  • Star: devices communicate through a central access point or gateway.
  • Mesh: devices forward traffic for one another, improving coverage but increasing routing complexity and energy use.
  • Cellular wide-area: devices communicate through operator infrastructure.
  • Bus or switched Ethernet: devices share or use a managed wired infrastructure.

Cost

Operating cost includes hardware, installation, spectrum or subscription charges, energy, maintenance, gateways, cloud services and security updates. A free unlicensed radio may still be expensive if it requires frequent battery replacement or site visits.

3. Comparison of Major Connectivity Technologies

3.1 Ethernet

Ethernet is a wired LAN technology commonly used in buildings, factories, servers and gateways. It offers high throughput, low and predictable latency, strong physical stability and mature diagnostics. Power over Ethernet (PoE) can deliver electrical power and data through suitable cabling.

Its disadvantages are installation cost, limited mobility and vulnerability to cable damage. Ethernet is especially appropriate for fixed gateways, cameras, industrial controllers and infrastructure requiring deterministic or highly reliable communication.

3.2 Wi-Fi

Wi-Fi provides high data rates and convenient IP connectivity through an access point. It is widely available in homes, offices and campuses, making deployment relatively easy. It supports cloud access, firmware updates and multimedia better than low-power wide-area technologies.

However, Wi-Fi radios and access-point associations can consume considerable energy. Shared spectrum, interference, building materials and access-point congestion affect reliability. Wi-Fi is suitable for mains-powered sensors, cameras, gateways and devices that need frequent or high-volume communication. Low-power Wi-Fi modes can improve battery operation, but design must still account for association time and network availability.

3.3 Bluetooth Low Energy

BLE is designed for short-range, low-power communication. A central device, such as a smartphone or gateway, commonly communicates with peripheral devices. BLE also supports broadcast advertising and, through Bluetooth Mesh, many-to-many managed flooding.

BLE is appropriate for wearables, beacons, configuration interfaces, medical accessories and nearby sensors. Its strengths include very low energy use for short transactions, widespread smartphone support and inexpensive hardware. Its limitations include short practical range in obstructed environments, dependence on a gateway for Internet access in many deployments, and limited suitability for continuous high-rate traffic.

3.4 Zigbee

Zigbee is commonly associated with low-power mesh networking based on IEEE 802.15.4 radios. End devices can sleep, while routers forward packets and a coordinator or gateway manages the network. Mesh routing extends coverage beyond a single radio link.

Zigbee is used in lighting, home automation and building sensors. It offers low energy operation and modest data rates. A mesh requires careful placement of powered routers, channel planning and reliable commissioning. Interoperability can be affected by profiles, product certification and vendor implementation.

3.5 Thread

Thread is a low-power, IPv6-based mesh networking technology built on IEEE 802.15.4. Devices communicate using IPv6, and a Thread border router connects the mesh to other IP networks. Thread separates the mesh network from application layers, allowing protocols such as Matter or other IPv6 applications to operate above it.

Thread is attractive where low-power mesh networking and IP-based integration are required. It still requires careful radio planning, powered routers and commissioning. A border router is necessary for communication beyond the Thread mesh.

3.6 LoRaWAN

LoRaWAN is a low-power wide-area networking system designed for small payloads over long distances. End devices communicate with gateways, which forward traffic to a network server. The gateway does not normally act as a conventional IP router for each sensor; it is part of the LoRaWAN infrastructure.

LoRaWAN provides long range and low energy use, particularly for infrequent uplinks. It is suitable for agriculture, environmental monitoring, metering and asset tracking. Its limitations include low data rate, constrained downlink capacity, variable latency, duty-cycle or regulatory restrictions in some regions, and dependence on gateway coverage. It is not suitable for video, continuous audio or rapid closed-loop control.

3.7 Cellular IoT

Cellular IoT includes conventional cellular data and purpose-designed categories such as LTE-M and NB-IoT. Cellular networks provide wide-area coverage, managed quality of service and mobility. SIM or eSIM identity and operator infrastructure simplify large geographic deployments.

The disadvantages are subscription cost, dependence on operator coverage and policy, modem energy consumption, and sometimes more complex certification. LTE-M generally supports greater mobility and throughput than NB-IoT, while NB-IoT is optimized for small, relatively infrequent data exchanges and deep coverage. The exact capabilities depend on network deployment and operator support.

3.8 Summary comparison

TechnologyTypical topologyRelative rangeRelative bandwidthPower profileCommon applications
EthernetSwitched wiredBuilding-wide through cablingHighMains/PoEControllers, gateways, cameras
Wi-FiStarRoom to buildingHighMedium to highAppliances, gateways, video
BLEPoint-to-point/starShortLow to mediumVery low for short exchangesWearables, beacons, setup
ZigbeeMeshRoom to buildingLowLowLighting, sensors
ThreadIPv6 meshRoom to buildingLowLowSmart-home and building devices
LoRaWANStar of gatewaysWide areaVery lowVery low for infrequent trafficMetering, agriculture
Cellular IoTOperator networkWide areaLow to mediumMediumTracking, remote monitoring

The values are qualitative because actual performance depends on implementation, environment and service configuration.

4. TCP/IP and IPv6 Foundations

The Internet protocol suite divides communication responsibilities. IP provides addressing and routing but does not guarantee delivery. TCP provides a connection-oriented, ordered and reliable byte stream. It uses acknowledgements, sequence numbers, retransmission and congestion control. These mechanisms introduce overhead and may increase latency and energy use.

UDP is connectionless and provides datagrams without built-in delivery or ordering guarantees. It is useful when low overhead, multicast, rapid exchange or application-controlled reliability is important. CoAP commonly uses UDP and can add confirmable messages when delivery acknowledgement is required.

IPv4 uses 32-bit addresses, whereas IPv6 uses 128-bit addresses. IPv6 provides a very large address space, hierarchical addressing, standardised neighbour mechanisms and support for efficient end-to-end addressing. IPv6 does not automatically make a system secure; firewalls, authentication, encryption and correct configuration remain necessary.

A simplified packet path is:

Sensor application → MQTT/CoAP/HTTP → TCP or UDP → IP → link technology → gateway/router → network/cloud

Address planning should distinguish device identity, network reachability and application identity. An MQTT client identifier, for example, is not a replacement for an IP address, and neither is a substitute for authenticated device credentials.

5. IoT Messaging Protocols

5.1 MQTT

MQTT is a lightweight publish/subscribe protocol commonly transported over TCP. Devices publish messages to topics, and subscribers receive messages matching those topics through a broker. This decouples producers from consumers: a sensor need not know which applications use its data.

A topic may be structured as building/3/floor/2/temperature. Topic design should be stable, meaningful and governed. Payloads may use JSON for readability or a compact binary format for efficiency.

MQTT quality of service levels are:

  • QoS 0: at most once; no protocol-level delivery assurance.
  • QoS 1: at least once; duplicates are possible.
  • QoS 2: exactly once at the MQTT protocol transaction level; greater overhead is required.

“Exactly once” does not guarantee that a business action occurs only once if an application repeats an operation incorrectly. Critical commands should be idempotent, uniquely identified and audited. MQTT security commonly uses TLS, authentication, authorisation and certificate or credential management.

5.2 CoAP

The Constrained Application Protocol is designed for constrained devices and networks. It follows a REST-like model with resources and methods such as GET, POST, PUT and DELETE. CoAP normally uses UDP and supports confirmable and non-confirmable messages. It can use proxying, multicast and observe mechanisms for monitoring resource changes.

CoAP is appropriate for constrained local or low-power IP networks. DTLS or OSCORE may be used for security depending on the architecture. Because UDP does not provide TCP-style reliability, the designer must understand retransmission, duplicate detection and application semantics.

5.3 HTTP

HTTP is widely understood, supported by web infrastructure and convenient for APIs, dashboards and cloud services. REST APIs commonly use HTTP methods and status codes. HTTP is usually more verbose than MQTT or CoAP and may be inefficient for tiny, frequent messages, but it is an excellent choice for configuration, firmware distribution, integration with enterprise systems and occasional device requests.

5.4 Selecting a messaging protocol

RequirementSuitable first choiceReason
Many consumers of changing sensor dataMQTTBrokered publish/subscribe
Constrained IP device and resource modelCoAPLow overhead and REST semantics
Web or enterprise API integrationHTTPMature tooling and interoperability
Critical commandMQTT or CoAP with application safeguardsDelivery policy plus idempotency and audit
Large firmware transferHTTP or specialised transfer methodBetter support for large objects

The best choice depends on network quality, device memory, security architecture, payload frequency and integration requirements.

6. Design and Reliability Considerations

A professional design begins with requirements rather than a preferred technology. Specify message size, reporting interval, maximum latency, acceptable loss, battery life, coverage, mobility, installation constraints and cost.

For periodic sensing, approximate daily payload volume can be estimated as:

D = n × s × f × T

where D is transmitted payload volume, n is the number of devices, s is payload size in bytes, f is messages per unit time, and T is the duration in the same time unit. This is only a payload estimate; headers, acknowledgements, retries, keep-alives and protocol overhead must be added for capacity planning.

For example, 100 sensors sending a 40-byte payload every 5 minutes produce:

D = 100 × 40 × 12 × 24 = 1,152,000 bytes/day

This is approximately 1.15 MB/day of payload before overhead. The result is modest for Wi-Fi or cellular data but may require careful planning for a constrained LPWAN, especially if downlinks and retransmissions are significant.

Reliability practices include sequence numbers, timestamps, buffering during outages, retry limits, exponential backoff, duplicate detection, watchdogs, health messages and store-and-forward gateways. Time synchronisation is important for event ordering and security certificates. A system should also define what happens when the cloud is unavailable: safe local control is often preferable to indefinite waiting.

7. Security, Governance and Ethics

IoT connectivity expands the attack surface. Threats include eavesdropping, rogue devices, credential theft, replay, denial of service, malicious firmware and unauthorised control. Security controls should include:

  • device identity and mutual authentication;
  • encryption in transit and, where appropriate, at rest;
  • least-privilege topic or API authorisation;
  • secure boot and signed firmware;
  • protected key storage and credential rotation;
  • vulnerability management and update capability;
  • network segmentation and monitoring;
  • logging without unnecessary personal data.

Privacy is particularly important when connectivity reveals occupancy, movement, health, energy use or workplace behaviour. Designers should minimise collection, explain purposes, control retention and comply with applicable data-protection law. Radio use must follow national spectrum rules, certified power limits and relevant electromagnetic compatibility requirements.

Reliability also has an ethical dimension. A connected actuator controlling a door, heater or medical device should fail safely. Automated decisions should be explainable to operators, and responsibility should remain clear when a cloud service or network fails.

8. Applied Case: Illustrative Smart-Building Retrofit

Background

A three-floor educational building requires temperature, occupancy and energy monitoring. Existing electrical rooms have Ethernet, classrooms have Wi-Fi coverage, and installing new power cables to every sensor is expensive. The system must provide dashboards, detect abnormal energy use and continue basic heating control during an Internet outage.

Problem

The building team initially proposes Wi-Fi for every sensor. Analysis shows that many battery-powered sensors would need frequent maintenance, while some electrical rooms contain metal cabinets that weaken radio signals. The system also requires integration with a cloud analytics service and a local building-management controller.

Analysis

Temperature and occupancy messages are small and periodic. The building has many rooms, so a mesh can reduce the number of direct links to a central access point. Ethernet is already available for fixed gateways and controllers. Cloud integration requires IP connectivity and a manageable application protocol.

Approach and solution

Battery-powered room sensors use Thread mesh devices. Mains-powered devices act as Thread routers, and one or more border routers connect the Thread network to the building IP network. Fixed controllers use Ethernet, while Wi-Fi is retained for commissioning and selected mains-powered equipment. The border router publishes normalised sensor events to an MQTT broker over the building network. The local controller subscribes to relevant topics and continues operating basic rules if the cloud connection fails. HTTP is used by the cloud dashboard and for firmware distribution.

Topic permissions prevent a room sensor from publishing commands to heating equipment. Each message includes device identity, timestamp, sequence number and measurement quality. The gateway stores messages during network interruptions and forwards them when service returns. Firmware is signed, and devices receive credentials during controlled commissioning.

Outcome

The hybrid design reduces battery maintenance, uses existing Ethernet, supports local autonomy and preserves cloud integration. It is more complex than using one technology everywhere, but the complexity is managed through gateways, standard IP interfaces and clear operational ownership.

Learning points

  1. A single radio technology is not always optimal for an entire site.
  2. Power and maintenance costs can dominate hardware price.
  3. Local control is important when Internet connectivity is unreliable.
  4. Messaging permissions and safe failure modes must be designed from the start.
  5. Protocol selection should reflect application semantics, not popularity alone.

9. Contemporary Developments and Best Practices

Matter is increasing the use of interoperable IP-based application models across smart-home ecosystems, often relying on Thread, Wi-Fi and Ethernet. Edge computing is placing filtering, anomaly detection and control closer to devices, reducing latency and cloud traffic. Private cellular networks are being considered for industrial sites requiring managed mobility and coverage. Time-sensitive and deterministic Ethernet technologies are relevant to demanding industrial applications.

Artificial intelligence can assist with adaptive sampling, anomaly detection and predictive maintenance, but AI does not remove the need for dependable connectivity. A model trained on missing or delayed data can produce unsafe conclusions. Systems should report data quality, distinguish measured values from predictions and provide human oversight for consequential actions.

Recommended practice is to:

  • document requirements before choosing a technology;
  • perform a site survey and interference assessment;
  • estimate payload, overhead, energy and maintenance costs;
  • use IPv6 and standards-based interfaces where appropriate;
  • separate telemetry from command permissions;
  • design for outages, duplicates and delayed messages;
  • secure identity, transport, firmware and operations;
  • test at realistic scale and under interference;
  • monitor battery, link quality, latency and packet loss;
  • plan technology replacement and end-of-life support.

Chapter Summary

IoT connectivity joins devices to gateways, networks and services, while messaging protocols define how application information is exchanged. Ethernet and Wi-Fi provide strong throughput and IP integration; BLE supports nearby low-power devices; Zigbee and Thread provide low-power mesh networking; LoRaWAN offers long-range, small-payload communication; and cellular IoT provides operator-managed wide-area coverage. Each technology involves trade-offs among range, bandwidth, topology, power, reliability and cost.

TCP provides reliable ordered transport, UDP provides lightweight datagrams, and IPv6 supplies scalable addressing. MQTT is effective for brokered publish/subscribe telemetry, CoAP suits constrained REST-like devices, and HTTP is valuable for web and enterprise integration. Reliable IoT systems use buffering, sequence numbers, controlled retries, duplicate handling, secure identity, signed updates and safe local behaviour during outages. A hybrid architecture is often superior to a single technology, provided that gateways, permissions and operational responsibilities are clearly designed.

Key Terms

Connectivity: The communication capability linking an IoT device to another device or network.

Bandwidth: The capacity of a communication channel, usually measured in bit/s.

Latency: The time delay between transmission and reception or response.

Topology: The logical or physical arrangement of network connections.

Mesh network: A network in which nodes can forward traffic for other nodes.

Gateway: A device that connects networks or translates between protocols.

IPv6: The Internet Protocol version using 128-bit addresses.

TCP: A connection-oriented transport protocol providing ordered, reliable delivery.

UDP: A lightweight datagram transport protocol without built-in reliable delivery.

MQTT: A brokered publish/subscribe messaging protocol commonly carried over TCP.

CoAP: A constrained application protocol with REST-like methods, commonly using UDP.

HTTP: A widely used request-response protocol for web and API communication.

QoS: A communication policy describing delivery assurance or service characteristics.

LoRaWAN: A low-power wide-area networking system for small, long-range messages.

BLE: Bluetooth Low Energy, designed for short-range, low-power communication.

Thread: An IPv6-based low-power mesh networking technology.

Duty cycle: The proportion of time a device or radio is active.

Idempotency: A property whereby repeating an operation does not create an unintended additional effect.

Edge computing: Processing data near its source instead of relying entirely on a remote cloud.

Review Questions

Short Answer Questions

  1. Distinguish a connectivity technology from a messaging protocol.
  2. State two advantages and two limitations of Wi-Fi for IoT.
  3. What is the principal difference between TCP and UDP?
  4. Why is MQTT described as a publish/subscribe protocol?
  5. Give two reasons why local control is important in a connected building.

Long Answer Questions

  1. Compare Ethernet, Wi-Fi, BLE, Zigbee, Thread, LoRaWAN and cellular IoT using range, bandwidth, topology, power and cost.
  2. Explain MQTT, CoAP and HTTP and recommend a suitable use for each.
  3. Describe how IPv6, gateways and border routers can operate together in an IoT architecture.
  4. Discuss reliability mechanisms for an IoT system operating during intermittent connectivity.
  5. Explain the security, privacy and regulatory issues that should be addressed before deployment.

Analytical / Application Questions

  1. A farm has battery-powered soil sensors that send small readings every 30 minutes across several square kilometres. Choose a connectivity technology and justify the choice, including limitations.
  2. Design a messaging architecture for a smart classroom containing occupancy sensors, lighting actuators and a cloud dashboard. Specify suitable connectivity and application protocols.
  3. A factory requires low-latency control, mobile equipment tracking and environmental monitoring. Propose a hybrid architecture and explain how you would validate reliability and operating cost.

Multiple Choice Questions with Answers

Question 1

Which technology is primarily designed for long-range, low-power transmission of small IoT payloads?

A. LoRaWAN

B. Ethernet

C. BLE

D. Wi-Fi

Correct Answer: A. LoRaWAN

Question 2

Which MQTT quality-of-service level permits duplicate delivery but provides at-least-once delivery?

A. QoS 0

B. QoS 1

C. QoS 2

D. HTTP 1.1

Correct Answer: B. QoS 1

Question 3

Which transport protocol provides an ordered, reliable byte stream?

A. UDP

B. IP

C. TCP

D. CoAP

Correct Answer: C. TCP

Question 4

A system has 100 sensors, each sending 40 bytes 12 times per day. What is the daily payload volume?

A. 4,800 bytes

B. 48,000 bytes

C. 115,200 bytes

D. 1,152,000 bytes

Correct Answer: D. 1,152,000 bytes

Question 5

Which technology is IPv6-based and designed for low-power mesh networking?

A. Thread

B. Traditional Bluetooth Classic only

C. LoRaWAN

D. Analog Ethernet

Correct Answer: A. Thread

Question 6

Which protocol is most directly suited to a brokered publish/subscribe telemetry architecture?

A. MQTT

B. FTP

C. ARP

D. Ethernet

Correct Answer: A. MQTT

Question 7

Which choice is generally most appropriate for a fixed industrial controller requiring predictable, high-reliability wired communication?

A. BLE

B. Ethernet

C. LoRaWAN

D. Zigbee only

Correct Answer: B. Ethernet

Question 8

What is a major limitation of using Wi-Fi for small battery-powered sensors?

A. It cannot carry IP traffic

B. It has no security mechanisms

C. Radio operation and association can consume relatively high energy

D. It cannot communicate through an access point

Correct Answer: C. Radio operation and association can consume relatively high energy

Question 9

Which practice helps prevent unintended repeated effects when commands are retried?

A. Removing device identity

B. Using idempotent command design and unique identifiers

C. Disabling all acknowledgements

D. Increasing payload size

Correct Answer: B. Using idempotent command design and unique identifiers

Question 10

What is the principal role of a Thread border router?

A. To convert every sensor reading into an analog signal

B. To connect the Thread mesh to other IP networks

C. To replace all application protocols

D. To provide LoRaWAN spectrum licensing

Correct Answer: B. To connect the Thread mesh to other IP networks

Embedded Systems for IoT
Chapter 9 of 15