MODULE – 3

IoT Connectivity Technologies

7.1.2 IoT Networking Basics

• The introduction highlights the importance of connectivity in IoT systems. IoT devices are extremely diverse, ranging from small sensors and RFID tags to smart appliances and actuators.
• To make these devices function as part of an intelligent ecosystem, networking technologies are required to provide addressing, routing, and communication.
• Unlike traditional networks, IoT networks must handle new challenges, such as constrained energy resources, lightweight hardware, and intermittent data transfer.

• The main aspects of IoT networking include device addressing, efficient data transmission, and scalability to manage millions of nodes.
• Equally important is energy efficiency, since many IoT devices are battery-powered and expected to operate for years without replacement.
• This section makes it clear that Wi-Fi and cellular technologies alone cannot meet all IoT requirements. Instead, alternatives such as IEEE 802.15.4, Zigbee, LoRa, and NB-IoT are essential.

​

7.2 IEEE 802.15.4 (Overview)

IEEE 802.15.4 is a wireless communication standard specifically designed for low-power, short-range applications, and it serves as the foundation for many IoT protocols. It focuses on low-cost, low-data-rate communications, making it ideal for sensor and actuator devices that only need to transmit small packets of data. Operating primarily in the 2.4 GHz ISM band, and sometimes in sub-GHz frequencies like 868 MHz and 915 MHz, it supports data rates between 20 kbps and 250 kbps. This is sufficient for IoT tasks such as transmitting temperature, humidity, or occupancy data.

Figure 7.1 – Protocol Stack

Figure 7.1 shows how the IEEE 802.15.4 protocol stack fits into the OSI model. It defines only the physical (PHY) and medium access control (MAC) layers, while higher-level protocols such as Zigbee, 6LoWPAN, and Thread build on top of it. This layered structure provides flexibility and allows IEEE 802.15.4 to support different IoT applications efficiently.

Figure 7.1 Explanation (Part 1)

• IEEE 802.15.4 is designed for low-data-rate Wireless Personal Area Networks (WPANs). It supports monitoring and control applications requiring low power consumption and long device lifetime.
• The standard directly defines only the first two layers of the OSI model – the Physical (PHY) layer and the Medium Access Control (MAC) sublayer.

Figure 7.1 Explanation (Part 2)

To interact with upper layers, IEEE 802.15.4 adds two sub-layers:

​

1. Logical Link Control (LLC)

2. Service-Specific Convergence Sublayer (SSCS)

​

Higher layers such as Networking, Transport, and Application are not part of IEEE 802.15.4. Instead, protocols like Zigbee, 6LoWPAN, or Thread provide these layers on top of 802.15.4.

Technical Details

• Modulation: Direct Sequence Spread Spectrum (DSSS)

- BPSK for low speed, O-QPSK for higher speed.

• Channel access: CSMA-CA to avoid collisions.

• Energy saving: very short packets, duty cycles less than

1%.

• Typical range: 10–75 m indoors, up to 1000 m outdoors.

​

This makes 802.15.4 ideal for IoT devices like smart meters and environmental sensors.

Example – Smart Home Sensor

Consider a temperature sensor in a smart home:

​

• The sensor uses IEEE 802.15.4 PHY and MAC to transmit

data packets.

• LLC and SSCS adapt these packets to upper protocols.

• A Zigbee network layer routes the data to the home gateway.

• The transport and application layers forward the temperature

reading to a mobile app.

​

This example shows how Figure 7.1 works in practice, with 802.15.4 at the bottom and upper protocols completing the OSI stack.

Figure 7.2 – Device and Network Types

• Figure 7.2 illustrates the types of devices supported in IEEE 802.15.4 networks, such as Full Function Devices (FFD) and Reduced Function Devices (RFD). It also shows how these devices can form different network types including star, peer-to-peer, and mesh topologies, offering flexibility in IoT deployments.

Overview of IEEE 802.15.4 Device and Network Types

• IEEE 802.15.4 supports two main device types: Full Function Devices (FFD) and Reduced Function Devices (RFD). It also defines two network types: Beacon-enabled and Non-Beacon-enabled. This classification helps in designing low-power, cost-effective networks for IoT applications.
• A beacon is like a small “hello, I’m here” signal sent periodically by network devices so that others can find, join, and stay synchronized in the network.�In Zigbee, it’s part of how your coordinator keeps all devices in step; in Wi-Fi, it’s how your router announces the network name; and in Bluetooth, it’s how devices broadcast their presence.

Full Function Devices (FFD)

FFDs can communicate with all types of devices (both FFDs and RFDs). They support the complete IEEE 802.15.4 protocol stack, enabling them to act as coordinators, routers, or general devices. However, FFDs consume more energy and are costlier due to higher processing and memory requirements.

Reduced Function Devices (RFD)

RFDs are simple, low-power devices with minimal memory and processing needs. They can only communicate with FFDs and are designed for end-device roles in the network. Examples include simple sensors that periodically send data to a coordinator.

Beacon-Enabled Networks

In beacon-enabled networks, the PAN coordinator transmits periodic beacons for synchronization. Communication uses slotted CSMA/CA with a superframe structure, which organizes transmissions efficiently. This method ensures better synchronization and power saving for end devices.

Non-Beacon-Enabled Networks

In non-beacon-enabled networks, unslotted CSMA/CA is used for communication. Here, devices communicate without periodic synchronization, leading to contention-based access. Beacons are used only for link discovery rather than for periodic coordination.

Figure 7.3 – Frame Types

Figure 7.3 presents the different frame types defined in IEEE 802.15.4. These include beacon frames, data frames, acknowledgment frames, and MAC command frames. Each frame type has a specific role in ensuring efficient communication, synchronization, and reliable data transfer across the network.

Overview of Frame Types

The IEEE 802.15.4 standard defines different types of frames to ensure reliable and synchronized communication. These frames provide functions for data transfer, acknowledgment, synchronization, and network management. Figure 7.3 illustrates the major frame types supported by the standard.

Beacon Frame

Beacon frames are broadcast by the PAN coordinator in beacon-enabled networks. They are used for synchronization, ensuring that devices wake up at the correct time to send or receive data. This allows devices to save battery power by sleeping during inactive periods.

Data Frame

Data frames carry the actual payload between devices. This could include sensor readings or control commands. They are the most essential frame type and are used in both beacon-enabled and non-beacon-enabled networks.

Acknowledgment (ACK) Frame

Acknowledgment frames are sent by a receiver to confirm that it successfully received a data frame. This ensures reliability in communication by enabling retransmission in case of errors or loss.

MAC Command Frames

MAC command frames are used for management functions within the network. These include association requests, dissociation requests, beacon requests, coordinator realignment, and orphan notifications. They help in establishing and maintaining the network structure.

Example: Smart Home Network

In a smart home network:

​

- A temperature sensor (RFD) sends a Data Frame with readings to

the gateway (FFD).

- The gateway replies with an Acknowledgment Frame to confirm

reception.

- The gateway periodically broadcasts Beacon Frames to

synchronize all devices.

- A new smart switch joining the system sends an Association

Request (Command Frame).

​

This shows how Beacon, Data, ACK, and Command frames work together for reliable IoT communication.

End-to-End Communication: Thread vs Zigbee Smart Home Network

Common Beginning – Office to Cloud

• When you are in your office and realize your home AC is on, you open your smart-home app and tap 'Turn Off AC.' Your phone creates a secure IPv6 message using HTTPS or MQTT over 5G. The packet travels through the 5G tower, inside GTP tunnels, and reaches the public internet. Routers forward it to the smart-home cloud server, which verifies your account and forwards the 'AC off' command to your home network.

Thread Network Story (6LoWPAN)

At home, the message reaches your Thread Border Router (like a Nest Hub). The router converts the IPv6 packet using 6LoWPAN—compressing and fragmenting it to fit IEEE 802.15.4 frames. The fragments travel via Thread’s mesh network using RPL routing. The AC’s Thread module reassembles and decompresses them, reads the CoAP/Matter 'off' command, and cuts power to the relay. An acknowledgment returns through the same mesh, expanded to full IPv6, confirming AC off.

Zigbee Network Story (Non-IP)

If your home uses Zigbee, the same IPv6 'AC off' command reaches your Zigbee gateway via Wi-Fi. Since Zigbee does not understand IPv6, the gateway translates it into a Zigbee frame using the Zigbee Cluster Library (ZCL). The Zigbee frame travels over the 2.4 GHz LR-WPAN mesh. The AC’s Zigbee module decodes it, switches off power, and sends a short acknowledgment. The gateway converts this back to IPv6 and notifies your app that the AC is off.

Comparison: Thread vs Zigbee

• Both use IEEE 802.15.4 LR-WPAN as the radio layer.
• Thread supports IPv6 via 6LoWPAN; Zigbee uses its own network protocol.
• Thread needs no translation; Zigbee relies on a gateway.
• Thread’s mesh uses RPL; Zigbee uses AODV-like routing.
• Thread enables end-to-end IPv6 communication; Zigbee translates IP to its internal addressing system.

End-to-End Flow Summary

1. Phone (5G IPv6 Packet) → Cloud → Home Router

2. Thread: IPv6 compressed (6LoWPAN) → Mesh → AC (native IPv6)

3. Zigbee: IPv6 translated to Zigbee frame → Mesh → AC (non-IP)

​

Wi-Fi and 5G carry full IPv6; Thread compresses it; Zigbee converts it.

7.3 Zigbee Communication in IoT

Based on IEEE 802.15.4 Standard

​

Introduction to Zigbee

• Zigbee enables Wireless Personal Area Networks (WPANs).
• Based on IEEE 802.15.4 standard (Physical & MAC layers).
• Used in sensor and control networks.
• Designed for low cost, low power, and short-range communication.
• Typical range: 10–100 meters.

Zigbee Technical Characteristics

• Operates on 2.4 GHz, 902–928 MHz, and 868 MHz bands.
• Common data rate: 250 kbps (suitable for periodic/intermittent communication).
• PHY and MAC layers support multiple low data rate devices.
• Ideal for monitoring and controlling applications.

Figure 7.4: Zigbee Network Topologies

Zigbee Network Configurations

• Supports master-to-master and master-to-slave communication.
• Network topologies: Star, Mesh, and Cluster Tree.
• Star topology – a single coordinator manages end devices.
• Mesh/Tree topology – multiple routers for extended communication range.

Device Types in Zigbee Network

• Coordinator: Root of the network, initializes and manages devices.
• Router: Intermediate node connecting multiple Zigbee devices.
• End Device: Limited functionality and low power consumption.
• End devices communicate only with parent nodes.

Figure 7.5: Zigbee Protocol Stack

Power Management in Zigbee

• Zigbee operates in different modes to save power.
• Sleep and idle states reduce energy consumption.
• Extends network lifetime for battery-based systems.
• Ideal for IoT sensors and remote applications.

Zigbee Protocol Architecture

• Built on IEEE 802.15.4 PHY and MAC layers.
• PHY Layer: Handles signal modulation and transmission.
• MAC Layer: Manages access control and frame structure.
• Network Layer: Routing and addressing.
• Application Layer: Device profiles and services for interoperability.

• Zigbee is a low-cost, low-power WPAN technology for IoT.
• Supports Star, Mesh, and Cluster Tree topologies.
• Offers reliable and scalable communication.
• Ideal for automation, industrial control, and sensing networks.

Physical Layer

• Responsible for transmitting and receiving signals.
• Performs modulation and demodulation of data.
• Comprises 3 bands and 27 channels:
• - 2.4 GHz: 16 channels at 250 kbps
• - 868.3 MHz: 1 channel at 20 kbps
• - 902–928 MHz: 10 channels at 40 kbps
• Provides foundation for all Zigbee communication.

MAC Layer

• Ensures channel access and reliable data transmission.
• Uses CSMA-CA for collision avoidance and interference control.
• Synchronizes communication through beacon frames.
• Manages acknowledgment and retransmission of data frames.

Network Layer

• Handles network formation and maintenance.
• Manages device joining and leaving the network.
• Performs routing and network configuration.
• Ensures smooth communication between coordinators, routers, and end devices.

Application Support Sub-Layer (APS)

• Acts as a bridge between the Network Layer and Application Layer.
• Provides control and interfacing services.
• Manages Zigbee Device Object (ZDO) and Zigbee Application Objects (ZAO).
• Offers data management and service-based device matching.
• Enables seamless communication between devices.

Application Framework

• Provides two types of data services:
• 1. Key-Value Pair – retrieves attribute values

from application objects.

• 2. Generic Message – developer-defined

message structures.

• Supports application-level communication and data exchange.

​

​

• Allows developers to define custom application behaviors.

Zigbee Operational Modes

• Zigbee supports two-way data transfer using two operational modes:
• 1. Non-Beacon Mode
• 2. Beacon Mode
• Each mode differs in power consumption and coordination mechanisms.

Non-Beacon Mode

• Coordinators and routers stay active continuously.
• More power-intensive as devices monitor the network constantly.
• No provision for coordinators or routers to enter sleep mode.
• Suitable for applications needing continuous communication.

Beacon Mode

• Allows coordinators and routers to enter low-power sleep states.
• Coordinators periodically wake up to transmit beacon signals.
• Reduces power consumption and supports lower duty cycles.
• Ideal for battery-powered, low-energy IoT systems.

Summary

• Zigbee Protocol Stack includes PHY, MAC, Network, APS, and Application Framework layers.
• Provides reliable, low-power communication for IoT devices.
• Supports two operational modes – Beacon and Non-Beacon – based on power and communication needs.
• Designed for energy-efficient, scalable IoT network operation.

7.7 RFID (Radio Frequency Identification)

Introduction to RFID

• RFID stands for Radio Frequency Identification.
• Uses tags and readers for wireless communication.
• Data is digitally encoded onto RFID tags.
• Readers capture this data without physical contact.
• Unlike barcodes, RFID does not require line-of-sight operation.

RFID vs Barcode

• RFID functions similarly to barcodes for data storage and retrieval.
• Data from tags is stored in a database after reading.
• RFID offers greater flexibility as it operates via radio waves.
• Eliminates the need for manual scanning or alignment.
• Enables faster and automated identification of objects.

RFID System Components

RFID is part of the Automatic Identification and Data Capture (AIDC) family.

​

• System tasks include:

- Identifying tags

- Reading data

- Feeding data directly into computer systems via radio

waves.

• Typical RFID systems consist of:

1. RFID Tag or Smart Label

2. RFID Reader

3. Antenna

Figure 7.12: RFID System Components

RFID Tags

• RFID tags consist of an integrated circuit and an antenna.
• Encased for protection against environmental wear and tear.
• Two main types of tags:

1. Passive Tags – Low cost, powered by RFID reader

signal.

2. Active Tags – Have built-in power source, higher

range and cost.

RFID Reader and Host Communication

• RFID Reader (Interrogator) receives data from tags via radio waves.
• Converts radio signals into digital data.
• Host computer accesses the collected data through communication links:

- Wi-Fi

- Ethernet

• The system updates and stores this data in a central database.

Applications of RFID

• RFID is widely used across multiple domains such as:

- Inventory management

- Asset tracking

- Personnel tracking

- Supply chain management

• Provides automation, accuracy, and real-time visibility in operations.

Summary

• RFID technology enables wireless, automatic data capture using tags and readers.
• Offers advantages over barcodes in terms of speed and non-contact reading.
• Active and passive tag options support diverse applications.
• Plays a key role in logistics, manufacturing, and IoT-based smart systems.

7.8 Near Field Communication (NFC)

Introduction to NFC

• Near Field Communication (NFC) is a short-range wireless connectivity standard.
• Jointly developed by Philips and Sony for peer-to-peer (P2P) data exchange.
• Operates on the principle of magnetic induction between nearby devices.
• Enables quick and secure data exchange without manual pairing.

Working Principle

• NFC communication occurs when two devices are brought very close together.
• Operates through magnetic induction and electromagnetic field coupling.
• Typical operating frequency: 13.56 MHz.
• Supports data rates of 106, 212, or 424 kbps.
• Works with other technologies like Wi-Fi after P2P configuration.

NFC Device Types

• NFC devices are categorized into two types:
• 1. Passive NFC Devices
• 2. Active NFC Devices
• Shown in Figure 7.13 along with components and usage.

Passive NFC Devices

• Do not require their own power source for communication.
• Operate by drawing power from the NFC reader’s electromagnetic field.
• Typically include tags and small transmitters.
• Used mainly for storing and transmitting fixed data (e.g., ID, status, or messages).
• Cannot process or modify information.

Active NFC Devices

• Possess their own power source and can initiate communication.
• Can read from and write to both active and passive NFC devices.
• Examples: smartphones, payment terminals, and card readers.
• Enable dynamic data transfer and two-way communication.

Data Transmission via NFC

• The NFC reader emits a small current creating a magnetic field bridge.
• The client device’s coil converts the EM field into electrical impulses.
• These impulses transmit data such as identifiers, messages, and payment details.
• Uses inductive coupling for high-speed, low-latency data exchange.

NFC Communication Modes

• NFC supports three modes of information exchange:

1. Peer-to-Peer Mode

2. Read/Write Mode

3. Card Emulation Mode

Peer-to-Peer Mode

• Enables two NFC devices to exchange information bidirectionally.
• One device acts as transmitter (active) while the other as receiver (passive).
• During reverse transfer, devices swap roles.
• Commonly used in mobile-to-mobile data exchange.

Read/Write Mode

• Supports one-way data transmission.
• An active NFC device reads information stored in a passive device (tag).
• Example: scanning NFC posters, product info, or tickets.

Card Emulation Mode

• Allows an NFC device (e.g., smartphone) to act like a contactless credit card.
• Enables secure, touch-based payments using mobile wallets.
• Widely used in public transport and retail payment systems.

Applications of NFC

• Contactless mobile payments (Google Pay, Apple Pay, etc.).
• Public transport smart cards and ticketing systems.
• Secure access control and authentication.
• Smart posters and data sharing between devices.

Summary

• NFC enables short-range, peer-to-peer data exchange using magnetic induction.
• Operates at 13.56 MHz with data rates up to 424 kbps.
• Supports active and passive device configurations.
• Provides multiple operation modes for payment, data exchange, and reading applications.

Sigfox: Low-Power Connectivity Solution

Section 7.12 Overview

Introduction to Sigfox

Sigfox is a low-power connectivity solution designed for applications such as building automation, security, smart metering, and agriculture. It uses ultra-narrowband (UNB) technology (192 kHz) for spectrum access, achieving data rates of 100–600 bits per second. Binary Phase Shift Keying (BPSK) is used for encoding, with each message being 100 Hz wide.

Spectrum and Communication Features

• Sigfox operates at 868–868.2 MHz in Europe and 902–928 MHz elsewhere. As receivers access only a small spectrum portion, noise effects are minimized. It remains resilient against jamming signals and ensures high-quality service through random access. Each device emits messages at arbitrary frequencies using time-frequency diversity.

Figure 7.19 – Sigfox Network Architecture

Cooperative Reception and Diversity

Sigfox base stations use cooperative reception, monitoring the 192 kHz spectrum for ultra-narrowband transmissions. Messages are received by any nearby base station, following spatial diversity. Combined with time and frequency diversity, this ensures excellent quality of service and reliability.

Explanation of Figure 7.20 – Sigfox Protocol Stack vs OSI Stack

Conceptual Overview and End-to-End Communication Example

What is Sigfox?

Sigfox is a Low-Power Wide-Area Network (LPWAN) communication technology designed for IoT devices that send small amounts of data infrequently over long distances. It operates on unlicensed sub-GHz frequency bands such as 868 MHz in Europe and 902–928 MHz in other regions. Sigfox uses ultra-narrowband modulation for long-range and low-power communication, ideal for smart metering, asset tracking, and agriculture.

Overview of Figure 7.20 – Sigfox vs OSI Stack

Figure 7.20 compares the Sigfox protocol stack to the traditional OSI model. The OSI stack contains seven layers ranging from physical to application, while Sigfox simplifies this structure to just four layers: Physical, Medium Access Control (MAC), Frame, and Application. This simplification minimizes processing and power usage for IoT devices.

OSI Stack Explanation

In the OSI model, communication is divided into seven layers: Physical, Data Link, Network, Transport, Session, Presentation, and Application. Each layer handles a specific function such as physical transmission, error control, routing, session management, and application-level interaction. This structure is ideal for complex and high-speed data communication systems like the Internet and cellular networks.

Sigfox Stack Simplification

Sigfox simplifies the OSI model by merging several layers. It retains only the essential ones for IoT communication. The Physical layer handles modulation and signal transmission, MAC manages access control, the Frame layer combines network and transport functions, and the Application layer holds sensor data. This lightweight stack is power-efficient and supports small, periodic data transmissions.

Layer-wise Description of Sigfox Stack

• Physical Layer – Responsible for transmitting data using BPSK or GFSK

modulation across 868/902 MHz bands.

• GFSK is a form of Frequency Shift Keying (FSK) in which the digital data signal is first passed through a Gaussian filter before frequency modulation is applied.
• The Gaussian filter smooths the data transitions, reducing spectral bandwidth and limiting interference between adjacent channels.

• Medium Access Control (MAC) – Controls channel access and

prevents collisions during message transmission.

• Frame Layer – Packages the payload with device ID, CRC, and

timestamp, ensuring message integrity.

• Application Layer – Contains the actual sensor data and application

logic for user interaction.

End-to-End Example – Smart Agriculture System

In a smart agriculture setup, a soil moisture sensor uses Sigfox to transmit data to a cloud dashboard.

​

1. The microcontroller collects soil moisture data and

sends it to the Sigfox module.

2. The Sigfox module creates a frame (device ID + sensor value

+ CRC).

3. The message is transmitted three times on different

frequencies to ensure reliability.

4. A nearby Sigfox base station receives it and forwards it to

the Sigfox cloud.

5. The cloud decodes the data and displays it on a user

dashboard for farm monitoring.

Data Flow Representation

• The communication flow can be represented as:
• Sensor → Sigfox Device (Frame + PHY) → Sigfox Base Station → Sigfox Cloud → User Application.

​

• This end-to-end flow ensures reliable long-distance communication with minimal power consumption. The device remains in deep sleep most of the time and only wakes to send short data bursts, achieving long battery life.

Advantages of Sigfox Protocol Stack

• Extremely low power consumption – ideal for battery-

powered IoT devices.

• Simplified architecture – only four lightweight layers.

• Long-range communication (up to 50 km in rural areas).

• High reliability due to time-frequency and spatial

diversity.

• Minimal device complexity and maintenance.

• Secure communication using AES-based authentication

and encryption.

Summary of Figure 7.20 – Sigfox Stack

The Sigfox stack achieves efficient IoT communication by removing redundant OSI layers and focusing on minimal, energy-efficient data exchange. Its four-layer structure (Physical, MAC, Frame, Application) ensures reliability, security, and scalability for IoT applications. Sigfox’s design philosophy of simplicity makes it one of the most power-efficient LPWAN technologies for smart city, industrial, and agricultural deployments.

Communication and Message Characteristics

Sigfox supports bi-directional asynchronous communication, but uplink (device to base station) is faster due to simpler device hardware. Message length is limited to 12 bytes, supporting sensor data, event status, GPS coordinates, and application data.

Security and Application Scope

Sigfox ensures authentication, integrity, and anti-replay security using AES. It is ideal for low-data-rate applications that require infrequent small data transmissions. Best suited for indoor deployments and dense networks; mobility support is limited.

LoRa: Long Range Communication Technology

Section 7.13 Overview

Introduction to LoRa

LoRa (Long Range) is a patented wireless communication technology developed by Cycleo, France, for providing cellular-type connectivity to M2M and IoT applications. It operates in sub-GHz frequency bands—169 MHz, 433 MHz, 868 MHz, and 915 MHz—and supports bi-directional links using a 125 kHz spread spectrum for communication.

Key Features and Applications

LoRa supports long-distance communication ranging from 15–20 km with millions of connected devices. It is ideal for smart grid monitoring, asset tracking, and asset management applications. Using chirp spread spectrum modulation, LoRa achieves high receiver sensitivity and extended battery life.

Figure 7.21 – LoRa Network Architecture

Comparison with NB-IoT

Compared to NB-IoT, LoRa provides higher battery life but lower data rates (27–50 kbps) and longer latency. LoRa's chirp coding gain provides resilience to interference. Both LoRa and LoRaWAN enable WAN-level communication, but LoRaWAN adds network routing and message redundancy.

Figure 7.22 – LoRa Protocol Stack

LoRaWAN Overview

LoRaWAN routes messages between end nodes and destinations through gateways. It follows a star topology comprising four main components: End nodes, Gateways, Network Server, and Remote Computer. Messages are received by all nearby base stations, increasing redundancy and network resilience.

Network Entities and Connectivity

End nodes handle sensing and control. Gateways forward messages to the network server via wired or wireless links. The server manages message acknowledgment, data rate adaptation, and redundancy elimination. Remote computers act as control systems and data sinks for collected information.

Security in LoRa Networks

• LoRa ensures strong security through three key mechanisms:
• Network Key – Provides security at the network level.
• Application Key – Ensures end-to-end security between applications.
• Device-Specific Key – Guarantees authentication and integrity per device.
• These features make LoRa highly reliable for industrial and smart infrastructure deployments.

LoRa Example and Comparison with Sigfox

End-to-End Example and Comparative Analysis

LoRa Example – Smart City Waste Management

In a smart city scenario, LoRa-based smart dustbins are deployed across various locations to monitor waste levels. Each dustbin has an ultrasonic sensor that measures how full the bin is and transmits this data through a LoRa module. The communication flow is as follows:

​

1. The ultrasonic sensor detects the waste level and converts it into digital data.

2. The data is transmitted via LoRa modulation (Chirp Spread Spectrum) to the nearest

gateway.

3. The gateway forwards the data over the Internet to the LoRaWAN network server.

4. The network server processes and decrypts the data, removing duplicates.

5. The application server displays the fill levels on a dashboard and alerts the

municipal team when bins are full.

​

This enables efficient waste collection, reduced operational costs, and cleaner urban environments.

LoRa End-to-End Communication Flow

• The end-to-end data flow for the LoRa smart waste management system can be represented as:

​

• Smart Dustbin (End Node) → LoRa Gateway → LoRaWAN Network Server → Application Server (Dashboard)

​

• Each end node communicates over long distances using minimal power. The system supports bidirectional communication, allowing the application to send configuration commands back to the nodes if required.

Comparison Between LoRa and Sigfox

Summary

Both LoRa and Sigfox are LPWAN technologies enabling long-range IoT communication with minimal power consumption. Sigfox emphasizes ultra-narrowband simplicity, focusing on minimal data transmission with long range and high reliability. LoRa provides higher flexibility, supports greater data payloads, and allows two-way communication. The selection depends on the specific IoT application’s data requirements, frequency, and cost constraints.

NB-IoT: Narrowband Internet of Things

Section 7.14 Overview

• NB-IoT (Narrowband Internet of Things) is a cellular communication standard developed by 3GPP(Third Generation Partnership Project).
• The 3GPP is an international organization that defines global standards for mobile communications , including GSM( Global System for Mobile Communications -2G), UMTS (Universal Mobile Telecommunications System- 3G), LTE (Long-Term Evolution - 4G), and 5G.
• It ensures that NB-IoT works seamlessly and globally, maintaining compatibility and interoperability with other cellular technologies.
• It coexists with existing cellular systems (2G/3G/4G/5G), ensuring high interoperability while minimizing power consumption.
• Many NB-IoT applications can support battery life up to 10 years, making it ideal for long-term IoT deployments.

Key Features and Advantages

NB-IoT improves reliability, spectrum efficiency, and system capacity using Orthogonal Frequency Division Multiplexing (OFDM) modulation. OFDM enhances data throughput and spectral efficiency, though device complexity remains high. It supports essential security features such as confidentiality, authentication, and integrity.

Overview of the Figure

Figure 7.23 depicts the placement of the NB-IoT frequency band within the LTE spectrum. It demonstrates how NB-IoT coexists with GSM (2G) and LTE(4G) systems using a narrow 200 kHz channel, ensuring efficient use of spectrum and backward compatibility with existing networks.

GSM Band Representation

The upper section represents GSM bands, where each block denotes a 200 kHz carrier. NB-IoT can be deployed in Standalone Mode by reusing one of these GSM carriers. This allows operators to repurpose legacy GSM spectrum for IoT connectivity without requiring new spectrum licenses.

LongTermEvaluation(LTE) Band and Guard Band Allocation

• The lower portion of the figure shows LTE carriers separated by a small unused frequency gap called the guard band. NB-IoT can operate:
• In-band: occupying one LTE resource block (180 kHz).
• Guard-band: utilizing the 200 kHz unused spectrum between LTE channels.
• This enables simultaneous operation of LTE and NB-IoT without interference.

OFDM Modulation and Its Role

• NB-IoT employs Orthogonal Frequency Division Multiplexing (OFDM) for the downlink, dividing the 200 kHz band into 12 orthogonal subcarriers (each 15 kHz). The uplink uses Single Carrier FDMA (SC-FDMA), which reduces power consumption in IoT devices. OFDM enhances spectral efficiency and allows multiple subcarriers to transmit data simultaneously without interference.

Summary of Figure 7.23 Concepts

Key Takeaways:

​

• NB-IoT efficiently uses 200 kHz within LTE or GSM

bands.

• Supports three deployment modes: Standalone, In-

band, Guard-band.

• Utilizes OFDM for downlink and SC-FDMA for uplink.

• Coexists seamlessly with LTE, enabling massive IoT

device connectivity.

• Provides deep indoor coverage with minimal power

consumption.

Communication and Coverage

NB-IoT supports deployments in indoor environments and dense urban areas. It ensures higher quality of service and reduced latency compared to LoRa. However, NB-IoT is less efficient for large data transmissions and better suited for static use cases like smart metering.

Figure 7.24 – NB-IoT Protocol Stack

Overview of NB-IoT Protocol Stack

Figure 7.24 illustrates the NB-IoT protocol stack across three major entities — User Equipment (UE), Evolved Node B (eNB), and Mobility Management Entity (MME). Each layer in this stack plays a crucial role in managing communication, reliability, and control signaling for IoT devices operating over cellular networks.

User Equipment (UE) Layers

The UE represents IoT end devices such as smart meters or sensors. Its stack layers are:

• PHY (Physical Layer): Handles radio transmission using OFDM/SC-

FDMA.

• MAC (Medium Access Control): Allocates resources and manages

retransmissions.

• RLC (Radio Link Control): Segments and reassembles data for

reliability.

• PDCP (Packet Data Convergence Protocol): Provides header

compression and encryption.

• RRC (Radio Resource Control): Manages connections and signaling.

• NAC (Non-Access Control): Interacts with the MME for session control.

Evolved Node B (eNB) – Base Station

• The eNB mirrors the UE’s stack and serves as a bridge between UE and MME. Its primary functions include:
• Scheduling and resource allocation for connected UEs.
• Managing radio connections and signal encryption.
• Forwarding data between the UE and MME.

​

• Each protocol layer in eNB communicates directly with its counterpart in the UE (e.g., MAC ↔ MAC).

Mobility Management Entity (MME)

• The MME handles the control-plane operations in NB-IoT networks. It manages:

​

• Authentication and session setup.
• Paging and tracking area management.
• Communication via the NAC (Non-Access Control) interface.

​

• The MME does not transmit user data but maintains control signaling and session integrity between the UE and the network core.

Working Principle Illustrated in Figure 7.24

• The figure shows how different layers in UE, eNB, and MME communicate:
• Horizontal arrows represent logical connections between identical layers (e.g., PHY ↔ PHY).
• NAC forms the control-plane path linking UE and MME.
• This layered interaction ensures reliable, low-power, and low-latency communication.

​

• The simplified stack makes NB-IoT suitable for devices with small data transmissions and long battery life.

Summary of NB-IoT Protocol Stack

• UE, eNB, and MME form the three pillars of NB-IoT

communication.

• Protocol layers ensure data reliability, integrity, and

efficient resource use.

• NAC enables control signaling between UE and MME.

• NB-IoT architecture is optimized for small data

volumes, long coverage, and low power consumption.

• It forms the backbone for smart city and industrial IoT

applications.

Deployment and Integration

• NB-IoT can operate in existing 200 kHz GSM bands or within LTE guard bands, allowing seamless integration with current cellular networks. This ensures extensive coverage and easy coexistence with traditional mobile systems.

Data Handling and Applications

NB-IoT supports non-IP applications transmitting small data volumes, typically a few tens to hundreds of bytes daily. It is ideal for static deployments such as energy metering, fixed sensors, and environmental monitoring. Its OFDM modulation provides higher data handling capacity than Sigfox and LoRa.

Security and Reliability

NB-IoT includes advanced security mechanisms ensuring confidentiality, integrity, and authentication. Its reliability and robustness make it suitable for industrial, smart city, and infrastructure IoT applications.

NB-IoT: Narrowband Internet of Things

Example and Comparison with LoRa and Sigfox

What is NB-IoT?

• NB-IoT (Narrowband Internet of Things) is a 3GPP-defined cellular LPWAN technology that enables low-power, low-data-rate, and wide-area IoT communication. It operates on licensed spectrum and provides secure, reliable connections for millions of IoT devices such as smart meters, sensors, and trackers.

NB-IoT Example – Smart Energy Metering

• In a smart energy metering system, electricity meters are connected using NB-IoT modules.

​

1. Each meter measures and stores energy consumption data.

2. The NB-IoT module transmits the data via the LTE base station using

200 kHz bandwidth.

3. The data is routed through the mobile operator’s core network to a

cloud-based utility server.

4. The server stores, processes, and displays energy usage in real-time

dashboards.

​

NB-IoT ensures reliable communication even in basements and dense urban environments.

Comparison: NB-IoT vs LoRa vs Sigfox

Summary

NB-IoT, LoRa, and Sigfox are leading LPWAN technologies with distinct strengths. NB-IoT provides reliable, secure, and licensed cellular connectivity ideal for industrial and utility applications. LoRa offers private network flexibility and moderate data capacity, while Sigfox emphasizes simplicity, long range, and extremely low data usage. Each technology is suited to different IoT use cases based on cost, range, and data needs.

Wi-Fi (IEEE 802.11): Wireless Local Area Networking

Section 7.15 Overview

Introduction to Wi-Fi

Wi-Fi, technically referred to by its IEEE 802.11 standard, is a wireless communication technology that enables local area networking among devices. It operates on 2.4 GHz and 5.8 GHz ISM frequency bands, providing connectivity through multiple channels using time-division multiplexing (TDMA) and CSMA/CA for channel access.

Summary of Figure 7.25

• IEEE 802.11 defines operations at the Physical and Data Link layers.
• It provides wireless connectivity for higher-layer protocols like IP and TCP.
• Wi-Fi enables communication in WLANs, bridging the physical radio medium and network protocols.
• This layered structure ensures modularity, interoperability, and scalability in wireless networking.

Wi-Fi Standards and Frequency Bands

• Wi-Fi operates primarily in two frequency ranges:
• 2.4 GHz Ultra High Frequency (UHF)
• 5.8 GHz Super High Frequency (SHF)

​

• Communication occurs through multiple channels within these bands. Wi-Fi employs TDMA for time-sharing and CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) for channel access control.

IEEE 802.11 Versions and Data Rates

• Different IEEE 802.11 versions define various data rates and operating frequencies:
• IEEE 802.11a – Operates at 5 GHz, uses OFDM, and achieves 54 Mbps.
• IEEE 802.11b – Operates at 2.4 GHz with data rates up to 11 Mbps.
• IEEE 802.11g – Also uses 2.4 GHz but achieves 54 Mbps with OFDM.
• IEEE 802.11n – Operates at 5 GHz, supports MIMO, and provides data rates up to 140 Mbps.

Overview of Wi-Fi Deployment Architecture

Figure 7.26 illustrates a typical Wi-Fi deployment architecture involving multiple routers, access points, and Internet connectivity. The figure demonstrates how multiple hosts (computers or devices) connect wirelessly to routers, which are in turn linked to access points (APs). These APs provide the gateway between the local wireless network and the Internet.

Components of Wi-Fi Deployment

• The Wi-Fi network consists of the following components:
• Hosts (A & B):Devices such as laptops or desktops equipped with Wi-Fi adapters.
• Wireless Routers (1, 2, 3):Manage local wireless communication and forward data to access points.
• Access Points (1 & 2): Act as bridges between routers and the Internet.
• Internet:Provides global network connectivity through access points.

Communication Flow in Wi-Fi Architecture

1. Hosts (A/B) connect wirelessly to their nearest

router using IEEE 802.11 standards.

2. Each router transmits the data to a connected

access point using wired or wireless backhaul

links.

3. The access points are linked to the Internet

backbone, which allows all hosts to exchange

data globally.

4. The architecture ensures smooth communication

between multiple local networks and the Internet.

Wi-Fi Operation Modes in Deployment

• Wi-Fi can operate in the following modes within this architecture:
• Infrastructure Mode:Devices connect to access points for structured communication.
• Ad-Hoc Mode:Devices communicate directly without routers or APs.

​

• In this figure, the network follows Infrastructure Mode, where routers and access points form a hierarchical structure.

Advantages of Wi-Fi Deployment Architecture

• Scalable – Supports multiple routers and hosts.
• Centralized Access – Access points manage Internet connectivity efficiently.
• Flexible – Hosts can move freely within the coverage area.
• Cost-Effective – Reduces the need for wired infrastructure.
• High Connectivity – Enables simultaneous multi-user communication via multiple routers.

Summary of Figure 7.26

Figure 7.26 depicts how Wi-Fi networks enable multi-device communication via routers and access points. The routers manage local wireless connectivity, while the access points link to the Internet, forming a complete wireless LAN infrastructure. This model is the foundation for modern Wi-Fi networks used in homes, offices, and public spaces.

Wi-Fi Network Architecture and Communication

• Wi-Fi-enabled devices connect to a Wireless Access Point (WAP), which forms a Wireless Local Area Network (WLAN). The WLAN acts as an intermediary, managing bidirectional communication between connected devices and the Internet.

​

• Wi-Fi networks can be configured as:
• Infrastructure mode – Devices communicate via an access point.
• Ad-hoc mode – Devices communicate directly without an access point.

Summary of Wi-Fi (IEEE 802.11)

• Wi-Fi follows the IEEE 802.11 family of standards for wireless LAN communication.
• Operates in 2.4 GHz and 5.8 GHz ISM bands.
• Utilizes TDMA and CSMA/CA for efficient multiple access.
• Different versions (a/b/g/n) offer varying data rates and frequency usage.
• WLANs allow devices to access the Internet wirelessly through access points.

Bluetooth (IEEE 802.15.1): Short-Range Wireless Communication

Section 7.16 Overview

Introduction to Bluetooth

Bluetooth, defined under IEEE 802.15.1, is a low-power, short-range wireless communication technology. It was initially developed as a cable replacement for connecting devices like smartphones and laptops. Operating in the 2.4 GHz ISM (Industrial, Scientific, and Medical)  band, Bluetooth enables both voice and data transmission over distances of about 10 meters.

Technical Characteristics of Bluetooth

• Frequency Band: 2.4 GHz ISM band.
• Channels: 79 channels, each 1 MHz wide.
• Modulation Schemes:

- π/4 DQPSK (2 Mbps)

- 8-DPSK (3 Mbps)

• Uses Frequency Hopping Spread Spectrum (FHSS) with Adaptive Frequency Hopping (AFH) at 800 hops per second to minimize interference and improve reliability.

Bluetooth Master–Slave Architecture

Bluetooth follows a master–slave topology where one master device can connect to up to seven slave devices, forming a small network called a piconet. All slave devices synchronize with the master’s clock and frequency hopping pattern. Multiple piconets can interconnect via a bridge device, forming a larger network called a scatternet. Each slave can belong to only one piconet at a time.

Bluetooth Low Energy (BLE)

Bluetooth Low Energy (BLE) is an advanced version designed for lower power consumption and extended range. It operates using 40 channels, each 2 MHz wide. BLE provides low energy usage, low cost, high interoperability, and improved operational range , ideal for IoT and wearable devices.

Overview of the Bluetooth Protocol Stack

Figure 7.28 illustrates the Bluetooth protocol stack, which defines how Bluetooth devices communicate and manage data exchange. The stack consists of multiple layers — from the physical radio interface to application-level protocols — ensuring interoperability, reliability, and efficient communication between Bluetooth-enabled devices.

1. PHY and Baseband Layers

• PHY Radio Layer:Represents the physical transmission medium. It manages modulation, demodulation, frequency hopping, and signal encoding in the 2.4 GHz ISM band.
• Baseband Layer:Responsible for establishing physical and logical links. It controls device addressing, timing, packet framing, and error correction. Together, these layers form the foundation for Bluetooth data transfer.

2. L2CAP (Logical Link Control and Adaptation Protocol)

L2CAP is the core data link layer that multiplexes logical connections between devices. It performs packet segmentation, reassembly, flow control, and Quality of Service (QoS) management. L2CAP ensures data integrity and acts as a bridge between upper and lower layers, enabling multiple simultaneous connections.

3. Middleware and Control Layers

• Above L2CAP, several key middleware components handle specific tasks:
• LLC (Link Layer Control): Manages link setup, configuration, and state transitions.
• RFCOMM: A serial cable emulation protocol that enables virtual serial communication.
• Telephony Control: Handles call control and signaling for voice and telephony applications.
• Service Discovery (Serv. Disc.):Enables device and service discovery, allowing devices to find each other and exchange capabilities.

4. Audio and Control Channels

• Audio Channel: Dedicated to transmitting voice data using synchronous connection-oriented (SCO) links. This supports real-time voice services such as headsets and hands-free devices.
• Control Channel: Manages signaling, synchronization, and link management between devices, ensuring stable communication.

5. Application Layer

The topmost layer of the Bluetooth stack supports various applications and user services. It interacts with the underlying stack to provide features such as file transfer, audio streaming, device pairing, and peripheral connectivity. Applications rely on standardized profiles built on top of lower-level Bluetooth protocols.

Summary of Figure 7.28 – Bluetooth Stack

• The Bluetooth protocol stack provides a modular architecture for short-range wireless communication.
• Lower layers (PHY, Baseband, L2CAP) handle data transmission and link management.
• Middleware layers (RFCOMM, Telephony, SDP) support services and connectivity.
• The Application layer enables end-user interaction and device functionality.

​

• This layered approach ensures Bluetooth’s flexibility, interoperability, and support for diverse applications.

Bluetooth Protocol Stack Overview

• The Bluetooth protocol stack comprises four main categories:
• 1. Core Protocols: LMP, L2CAP, HCI.
• 2. Cable Replacement Protocols:RFCOMM.
• 3. Telephony Control Protocols: TCS BIN.
• 4. Adopted Protocols: SDP, OBEX, etc.

​

• These layers coordinate communication, device discovery, and data exchange across Bluetooth devices.

Core Bluetooth Protocols Explained

• Link Manager Protocol (LMP):Establishes connections, authentication, and configuration between devices.
• Host Controller Interface (HCI):Provides access to hardware status and connects the controller with the link manager.
• L2CAP:Handles logical multiplexing, segmentation, reassembly, and flow control of data.

Service and Communication Protocols

• Service Discovery Protocol (SDP): Enables devices to discover available services and their characteristics.
• Radio Frequency Communication (RFCOMM):Acts as a cable replacement protocol, providing virtual serial communication.
• Telephony Control Protocol (TCS BIN):Manages call signaling for voice and data sessions between devices.

Security and Applications of Bluetooth

• Bluetooth ensures communication security using encryption and service-level authentication. This prevents eavesdropping and unauthorized access.

​

• Common Applications:
• Wireless peripherals (keyboards, mice, speakers)
• IoT and wearable devices
• Vehicle infotainment systems
• File transfer and tethering

Application Layer Protocols

8.4.1: MQTT

• MQTT (Message Queue Telemetry Transport) protocol, which is a lightweight publish–subscribe communication model widely used in IoT. It highlights the roles of publishers, brokers, and subscribers and how they interact to ensure efficient data exchange.
• There can be cloud based brokers or standalone

Introduction to MQTT

MQTT is a simple, lightweight messaging protocol designed for communication between devices in constrained environments. It follows a publish–subscribe architecture, allowing one-to-many message distribution. The protocol is designed to operate efficiently in networks with limited bandwidth or high latency.

MQTT Architecture

The MQTT architecture includes three main components:1. Publishers, 2.Brokers, and 3.Subscribers. Publishers send data in the form of topics to a central broker. The broker then forwards these topics to all devices or applications (subscribers) that have subscribed to those topics. This allows for a decoupled and scalable communication network.

Operational Principle

MQTT works on top of the TCP protocol, ensuring reliable message delivery. When a publisher sends data, it includes both control and data messages. The broker updates its topic list and delivers new messages to all active subscribers. Messages for unsubscribed topics are usually discarded, optimizing data flow and reducing redundancy.

Reliability Features

MQTT includes a 'Last Will and Testament' feature that ensures system continuity. If a publisher disconnects unexpectedly, a pre-defined message can be sent to inform subscribers. Additionally, multiple brokers can interconnect to enhance data delivery reliability.

MQTT Message Structure

MQTT messages vary in size from 2 bytes to 256 MB, with a fixed 2-byte header. The protocol defines 14 control message types, such as CONNECT, PUBLISH, SUBSCRIBE, and DISCONNECT. These messages manage connection establishment, publishing, acknowledgments, and keep-alive signals.

​

*note there are 14 control messages and you are expected to read and understand from the text book

Quality of Service (QoS) Levels

• MQTT supports three QoS levels:

1. At most once – Best-effort delivery, possible

message loss.

2. At least once – Guaranteed delivery but may

cause duplicates.

3. Exactly once – Assured and duplicate-free

message delivery.

• This flexibility allows developers to choose reliability based on application needs.

MQTT in IoT Applications

• MQTT is extensively used in IoT environments such as smart homes, healthcare systems, and industrial automation. It enables low-power devices to communicate effectively using minimal bandwidth, making it ideal for large-scale deployments.

Security Considerations

• MQTT transmits credentials in plain text by default, which poses security risks. To secure communication, MQTT can be implemented over SSL/TLS encryption. Security best practices include authentication, topic access control, and the use of secure brokers.

Figure: MQTT Operation and Its Stakeholders

Diagram: MQTT Operation

The diagram illustrates the three main components: publishers, brokers, and subscribers. Publishers (like refrigerators or tablets) send topic data to the broker. The broker manages these topics and routes them to subscribers (like control panels, lights, and smart home devices). This architecture ensures efficient, asynchronous communication between multiple devices.

Summary

• MQTT simplifies IoT communication using a broker-based publish–subscribe model. It ensures reliable message delivery through configurable QoS levels, supports efficient bandwidth usage, and enables asynchronous communication between devices. With proper encryption and authentication, MQTT forms the backbone of modern IoT systems.

8.4.2 MQTT-SN

MQTT-SN (Message Queue Telemetry Transport for Sensor Networks) is a lightweight version of MQTT, specifically designed for wireless sensor networks. It is optimized for constrained devices operating under low bandwidth, high latency, and high packet loss conditions. MQTT-SN ensures reliable communication among low-power sensor nodes in IoT environments.MQTT-SN is UDP based

​

Key Features of MQTT-SN

• MQTT-SN is robust for unreliable and lossy wireless environments. Its main features include:
• Low bandwidth consumption and minimal overhead.
• Operates efficiently under high link failure conditions.
• Designed for low-power, low-cost constrained nodes and networks.
• Uses topic identifiers (2 bytes) instead of lengthy topic names, reducing communication overhead.
• Supports persistent subscriptions and sleeping nodes for energy efficiency.

Differences between MQTT and MQTT-SN

MQTT-SN differs from MQTT in several key aspects:

1. The CONNECT message in MQTT-SN is divided into three

types, with optional testament communication.

2. MQTT-SN replaces long topic names with 2-byte topic identifiers,

reducing network traffic.

3. A topic registration mechanism exists to map topic names with

identifiers.

4. Predefined topic identifiers eliminate the need for dynamic

registration in certain cases.

5. Discovery process helps nodes find the broker dynamically if no

preconfigured address is available.

6. MQTT-SN supports sleeping clients with buffered message delivery

upon wake-up, unlike standard MQTT.

MQTT-SN Architecture

MQTT-SN acts as a bridge between MQTT and sensor network nodes. The MQTT-SN gateway handles conversion between MQTT-SN and MQTT message formats. It translates communication between sensor nodes and the MQTT broker, ensuring interoperability across different network layers.

Gateway Types in MQTT-SN

There are two primary types of MQTT-SN gateways:

​

1. Transparent Gateway: Each MQTT-SN node

establishes its own direct connection to the

MQTT broker via the gateway.

2. Aggregating Gateway: All MQTT-SN nodes

communicate with the MQTT broker through a

single shared connection managed by the

gateway.

These two types define how efficiently multiple sensor nodes share network resources.

Figure: MQTT-SN Types (Transparent and Aggregating Gateways)

Diagram Explanation: MQTT-SN Gateway Types

• The figure illustrates two types of MQTT-SN gateways:
• (a) Transparent Gateway – Each sensor node (SN-1 to SN-5) maintains an individual session with the MQTT broker through the gateway. This design provides direct communication but increases broker load.
• (b) Aggregating Gateway – The gateway combines data from all nodes and maintains only one session with the broker. This reduces broker connections and network traffic, enhancing scalability and efficiency.

Smart Home Story: MQTT vs MQTT-SN

This presentation explains MQTT and MQTT-SN protocols through a simple smart home example. It highlights how MQTT connects smart devices through a broker and how MQTT-SN enables low-power wireless sensors to communicate via gateways.

MQTT in a Smart Home: The Reliable Messenger

Imagine your smart home: Refrigerator, Thermometer, Microwave, and TV are connected through a Smart Home Hub (Broker). Each device sends messages (publishes) to the broker on specific topics like home/kitchen/temp or home/livingroom/tv.

​

The Broker delivers these messages to subscribers, such as your smartphone app or smart assistant.

​

Example Flow:

1. Refrigerator → Broker: 'Temperature is 4°C.'

2. Broker → Mobile App: 'Temperature is 4°C.'

3. Microwave → Broker: 'Cooking started.'

4. Broker → Control Panel: 'Cooking started.'

​

• ✅ Reliable, topic-based, and efficient for IoT environments.

How MQTT Works (Analogy)

Think of the Broker as a Post Office:

• Devices (Publishers) drop letters (messages) addressed by topic.
• The Post Office (Broker) delivers them to Subscribers interested in those topics.
• Devices never directly talk to each other, ensuring scalability and simplicity.

​

MQTT is built on TCP — ensuring reliability and guaranteed message delivery with QoS levels.

Transition to MQTT-SN: The Lightweight Whisperer

• In your smart home, some devices are too small and battery-powered, such as garden sensors or motion detectors. They can’t handle heavy TCP connections, so they use MQTT-SN, a lighter protocol built for sensor networks.
• MQTT-SN devices communicate using small 2-byte topic identifiers and work over wireless sensor networks (6LoWPAN/UDP).

MQTT-SN Architecture in a Smart Home

• MQTT-SN introduces a Gateway that bridges wireless sensors with the main MQTT broker.

​

• There are two gateway types:

​

1 Transparent Gateway — each sensor node has its

own session with the broker.

2 Aggregating Gateway — all sensors share one

gateway connection to the broker.

​

• This design allows energy-efficient, scalable communication in wireless IoT setups.

Story: MQTT-SN in Action (Transparent Gateway)

• Scenario:
• SN-1 (Garden Moisture Sensor): 'Soil is dry.'
• SN-2 (Temperature Sensor): 'Temperature 30°C.'
• Each sensor connects individually via the Transparent Gateway → Broker → Smart Irrigation System.

​

• Pros: Direct tracking, easy debugging.
• Cons: More connections to broker, slightly higher resource use.

Story: MQTT-SN in Action (Aggregating Gateway)

• Scenario:
• • SN-1 to SN-5 (Sensors) send short messages to a single Aggregating Gateway.
• • The Gateway merges data and sends it to the Broker as one stream.
• • The Smart Irrigation System subscribes to updates and turns ON water pump when needed.

​

• ✅ Pros: Lower bandwidth, less energy usage.
• ⚠️ Cons: Harder to track individual sensor connections.

Summary of Smart Home Communication

• 🏠 MQTT: Perfect for appliances like TVs, microwaves, and refrigerators — reliable, topic-based communication via a broker.

​

• 🌿 MQTT-SN: Perfect for battery-powered garden or motion sensors — lightweight, energy-efficient communication via gateways.

​

• Together, they create a hybrid smart home system that is both powerful and energy-conscious.

Summary

MQTT-SN extends MQTT functionality to constrained wireless networks, providing optimized message delivery, low power consumption, and efficient bandwidth use. Its two gateway types – transparent and aggregating – enable flexible integration of sensor nodes with existing MQTT infrastructures, ensuring interoperability in large-scale IoT deployments.

Introduction to CoAP

The Constrained Application Protocol (CoAP) is a specialized web transfer protocol designed for use in constrained devices and networks. It operates efficiently even in lossy networks with minimal resources such as 8-bit microcontrollers and limited RAM. CoAP ensures reliable communication with low overhead, making it ideal for IoT and M2M environments.

CoAP Characteristics

• CoAP offers several key features:

​

1. Web protocol suitable for IoT integration.

2. UDP-based communication with optional reliability.

3. Asynchronous message exchanges.

4. Small header size for low overhead and reduced

complexity.

5. Supports URIs and Internet media types.

6. Includes Datagram Transport Layer Security (DTLS) binding

for secure communication.

7. Proxy and caching mechanisms to overcome lossy network

issues.

8. Stateless mapping with HTTP for easy integration.

Figure 8.17: Position of CoAP Protocol in a Stack

Position of CoAP in Network Stack

Figure 8.17 shows the position of CoAP in the protocol stack. It sits at the application layer above UDP, functioning with message and request layers. Below UDP lies the Internet protocol and the constrained PHY layer. This structure allows CoAP to operate efficiently on devices with limited power and connectivity.

CoAP Messaging Types

• CoAP defines four main message types:

1. Confirmable (CON): Requires acknowledgment for reliable

delivery.

2. Non-confirmable (NON): No acknowledgment; used for

non-critical data.

3. Acknowledgment (ACK): Confirms receipt of a CON

message.

4. Reset (RST): Sent when a device cannot process a received

message.

• CoAP supports both request and response messaging patterns similar to HTTP.

Operational Principle

CoAP operates through asynchronous exchanges between UDP endpoints. Each message includes a 4-byte binary header followed by optional payloads. A 2-byte message ID helps detect duplicates. Confirmable (CON) messages ensure reliability through retries and ACKs. Non-confirmable (NON) messages are faster but do not require acknowledgment. If a server cannot process a CON message, it responds with a RESET message.

Figure 8.18: CoAP Response–Response Models (CON, Piggyback, Separate)

Response Models in CoAP

CoAP supports three response models as shown in Figure 8.18:

A) CON and NON Messages: The client sends a

confirmable or non-confirmable message, and the

server responds with ACK or no reply.

B) Piggybacked Messages: The server includes response

data directly in the ACK message, reducing

communication steps.

C) Separate Messages: When the response is delayed,

the server sends an empty ACK followed by a separate

CON message containing data.

Multicast and Token Mechanism

• CoAP supports multicast communication over UDP, allowing simultaneous requests to multiple servers. Each CoAP message uses a token to match requests and responses due to its asynchronous nature. This mechanism ensures message integrity even when responses arrive out of order.

Summary

• CoAP provides a lightweight and reliable framework for communication in constrained environments. It supports both confirmable and non-confirmable messaging, integrates seamlessly with HTTP, and offers security via DTLS. With features like caching, multicast, and proxy support, CoAP is a preferred choice for IoT and M2M applications requiring low-power data exchange.

Smart Home Story: CoAP Response Models

• This presentation explains the three CoAP response–response models (Confirmable/Non-confirmable, Piggyback, and Separate) through a simple smart home example involving a mobile app controlling a smart light bulb.

Model A: Confirmable (CON) and Non-Confirmable (NON) Messages

• Scenario: You tap the 'Light ON' button in your Smart Home app.

​

• The app sends a Confirmable (CON) message: 'Hey Light, turn ON!'

• The light bulb receives it, switches ON, and replies with an

Acknowledgment (ACK): 'ACK! Light is ON now.'

​

• This ensures reliability—if the ACK doesn’t arrive, the app retries.

​

• For quick sensor updates (e.g., 'Light is still ON'), Non-Confirmable (NON) messages are used without expecting ACKs.

​

• 💡 CON = Reliable and needs acknowledgment.
• 💡 NON = Fire-and-forget, faster updates.

Model B: Piggyback Messages

Scenario: You tap 'Light OFF' on your app.

​

• The app sends: 'Hey Light, turn OFF.'
• The light processes the request instantly and responds with a Piggyback message combining ACK + Data:
• 'ACK! Done — Light is now OFF.'

​

💡 This model is efficient because acknowledgment and data are

sent together.

💡 Ideal when devices can process and respond immediately.

​

It’s like your smart bulb replying instantly with confirmation and result in one go.

Model C: Separate Messages

Scenario: You send 'Light ON,' but the light bulb is busy.

​

• The bulb first sends an ACK: 'Got your request — please wait.'
• After completing its internal tasks, it sends a separate CON message later: 'Light is now ON.'
• The app acknowledges: 'ACK! Received your update.'

​

💡 Used when the server needs more time to process the request.

💡 ACK is sent first to stop retransmission; actual response follows

later.

​

This ensures reliability and avoids unnecessary network congestion.

8.4.4 :AMQP

• AMQP is an open, application‑layer, message‑oriented middleware protocol that enables interoperable, cross‑vendor messaging between clients and brokers.
• It supports both request–response and publish–subscribe patterns while providing queuing, routing, reliability, and security on top of TCP.

Why AMQP Exists

• AMQP is a wire‑level protocol: messages are defined as a precise byte stream on the network so that any compliant implementation regardless of language can interoperate.
• This design fosters portability across vendors and platforms and allows heterogeneous systems to exchange messages reliably and predictably.

Core Features

• Flow‑controlled, message‑oriented communication ensures producers cannot overwhelm consumers thanks to credit‑based flow control.
• Delivery guarantees include at‑most‑once, at‑least‑once, and exactly‑once semantics, letting architects tune reliability versus throughput.
• Security is supported via authentication and optional SSL/TLS encryption, protecting data in transit over TCP connections.

AMQP Layering

• AMQP is specified across four layers: (1) a type system; (2) a symmetric, asynchronous process‑to‑process transfer protocol; (3) an extensible message format; and (4) a set of extensible messaging capabilities.
• These layers separate concerns: encoding and typing of data, movement of messages, representation of messages, and the higher‑level capabilities such as reliability and transactions.

Frames and Control Flow

• All AMQP interactions are composed of frames—the smallest unit on the wire. Frames open/close connections, start/stop sessions, attach/detach links, transfer messages, and report state.
• Nine frame types exist: Open, Begin, Attach, Transfer, Flow, Disposition, Detach, End, and Close. Together they establish connections, manage sessions and links, move data, throttle producers, and settle delivery outcomes.

Operational Principle (Sessions, Links, Transfer)

• Peers create a link with an ATTACH frame to send messages. A DETACH frame tears the link down. Once attached, messages flow unidirectionally on that link via TRANSFER frames.
• A credit‑based Flow control (FLOW frames) prevents overload. Both peers settle each transfer’s outcome (accepted, released, rejected, modified) and communicate it using DISPOSITION frames to achieve the desired delivery guarantee.

Operational Principle (Connections and Sessions)

• A TCP connection is initiated with an OPEN frame and closed with a CLOSE frame. Within a connection, peers start a bidirectional, ordered session using BEGIN and later terminate it with END.
• Multiple independent sessions can be multiplexed over the same connection, and each session can host several links in each direction, enabling efficient, structured concurrency.

Figure 8.19: AMQP Components and Their Relationships

Explaination for Figure 8.19

• Publishers send messages to the AMQP broker, which acts as the central router and queue manager. Publishers do not push directly to subscribers; instead, they address messages to exchanges/queues managed by the broker.
• Inside the broker, messages are placed into one or more queues based on routing rules. Each queue buffers messages and preserves order for its consumers.
• Subscribers (consumers) pull messages from their bound queues. The broker delivers a copy to each subscribed consumer according to bindings and acknowledges consumption according to the chosen delivery semantics.

Request–Response and Pub–Sub in AMQP

• Publish–subscribe is achieved by routing messages from publishers into multiple queues bound to a common exchange so that multiple subscribers can receive the same message stream.
• Request–response is modeled by having the client publish a request with a reply‑to address and correlation id; the responder publishes the answer to the reply queue, allowing asynchronous, decoupled RPC‑style interactions.

Smart Home Story: AMQP in Action

• Imagine a smart home broker running AMQP in the cloud. Kitchen appliances, sensors, and apps are AMQP clients. The refrigerator publishes status, the oven publishes alarms, and the mobile app subscribes to notifications.
• Each device publishes to an exchange that routes messages into queues: alerts/, telemetry/, and control/. Mobile and wall panels subscribe to alerts/; analytics services consume telemetry/; appliances consume control/ for commands.

Story Flow – From Event to Action

• 1) The oven detects an over‑temperature event and PUBLISHES a message. The broker routes it into the alerts queue and simultaneously copies it to a safety queue bound with a different routing key.
• 2) Subscribers consume: the mobile app receives the alert and notifies the user; a safety microservice also receives it and sends a CONTROL command to turn the oven off by publishing to the control exchange.
• 3) Delivery is settled via DISPOSITION frames. If the mobile app fails to ack, the broker can redeliver to another consumer. Flow control ensures the analytics service cannot be flooded by bursty telemetry.

Why AMQP Fits the Smart Home

• Queues decouple devices from consumers, smoothing bursts and providing back‑pressure with flow control so battery devices are not overwhelmed.
• Delivery guarantees and settlements enable reliable alerting (at‑least‑once) while allowing best‑effort telemetry where appropriate. Security via TLS and authentication keeps household data private.

Key Takeaways

• AMQP offers interoperable, reliable, and secure messaging with explicit control over connections, sessions, links, flow, and delivery outcomes.
• Figure 8.19’s publisher → broker → queues → subscriber pipeline is the heart of AMQP’s design: producers are decoupled from consumers, and the broker enforces routing, buffering, and reliability.

8.4.5: XMPP

• XMPP (Extensible Messaging and Presence Protocol), originally known as Jabber, is an open-source, XML-based protocol designed for real-time messaging, presence detection, and data exchange.
• It is used in instant messaging, VoIP signaling, video transfers, IoT, and smart grid communication. It provides decentralized, federated communication with extensibility and reliability.

XMPP Architecture and Functioning

• XMPP follows a client–server model where clients connect to a central XMPP server for communication.
• Each user has a unique Jabber ID (JID) in the format user@domain/resource. The resource helps identify multiple devices (e.g., phone, laptop).
• Messages without a specific resource are sent to the device with the highest priority, making XMPP suitable for multi-device environments.

Explaining Figure 8.20: XMPP Components

• Figure 8.20 shows how XMPP operates using servers, clients, and components.
• Multiple clients (Client-1A to Client-1D) connect to the XMPP server using plug-ins for message handling, authentication, and presence updates.
• The XMPP server connects to another XMPP server through an XMPP link to allow communication across different domains (federated messaging).
• Direct client-to-client connections are possible via extensions like Jingle, allowing real-time peer-to-peer communication for multimedia transfers.

Core XMPP Technologies

1 Core: Provides XML streaming, TLS encryption, SASL authentication, and UTF-8 encoding for secure, presence-aware communication.

2 Jingle: Enables voice, video, and file transfer through SIP-compatible signaling over TCP, UDP, or RTP.

3 Multi-User Chat (MUC): Supports group chat with moderation and role management.

4 Pub–Sub: Implements publish–subscribe for real-time event updates and notifications in IoT systems.

5 BOSH: Uses HTTP to carry XMPP data streams for real-time browser-based communication.

Operational Principle of XMPP

• Each XMPP client establishes a TCP connection with its server and authenticates using its JID credentials.
• The client then sends XML stanzas—structured text blocks that represent messages, presence updates, and information queries (IQ).
• The server routes these stanzas between users and across servers, ensuring reliable and near real-time data exchange in a distributed manner.

Figure 8.20: XMPP Components and Connections

Smart Home Story: XMPP in Action

• Imagine a smart home ecosystem where XMPP coordinates communication between devices such as smart lights, thermostats, cameras, and mobile apps.
• Each device has its own JID , for example, light1@home.local or cam@home.local and connects to the Home XMPP Server (Hub).
• The hub routes messages, handles presence updates, and ensures that commands from the user’s mobile app reach the correct device.

Smart Home Story: Example Message Flow

Scenario: You use your mobile app to turn ON the living room light.

1 The app sends an XML message to the XMPP server:

'turn light1 ON'.

2 The server authenticates the message and forwards it

to light1@home.local.

3 The light switches ON and sends back a confirmation:

'Light ON confirmed'.

4 The server relays this confirmation to your app and

also publishes a notification to all subscribers of

'home/lighting' using the Pub–Sub feature.

Peer-to-Peer Communication via Jingle

• Some devices (like security cameras and display screens) can use Jingle over XMPP for direct peer-to-peer media streaming.
• The XMPP server helps establish the session and handles authentication, but the actual video or voice stream flows directly between devices.
• This hybrid model ensures lower latency and efficient bandwidth usage while maintaining server control for security.

Summary and Key Insights

• XMPP is a powerful, decentralized protocol that supports secure, extensible communication between devices and users.
• Figure 8.20 demonstrates its client–server–component architecture and ability to handle both federated and peer-to-peer communication.
• In smart homes, XMPP enables real-time coordination, automation, and monitoring with flexible features like Pub–Sub for notifications and Jingle for multimedia.

Detailed Comparison of IoT Communication Protocols (8.4.1 – 8.4.5)

Protocols: MQTT, MQTT-SN, CoAP, AMQP, XMPP

Comparison based on architecture, transport, reliability, and IoT application domain.

MQTT, MQTT-SN, and CoAP Protocols

AMQP and XMPP Protocols