IOT LAB (EC-705) - Unit 2 Short Notes

UNIT 2: IOT COMMUNICATION PROTOCOLS, CLOUD INTEGRATION & SECURITY

Based on common IoT Lab curricula, this unit covers the practical implementation of communication protocols, cloud platform integration, and foundational security concepts essential for building end-to-end IoT systems.

2.1. Core IoT Communication Protocols & Hands-On Implementation

2.1.1. Short-Range Wireless Protocols

• Bluetooth Low Energy (BLE)

  • Concept: Ultra-low-power variant of Bluetooth for periodic, small data transfers.

  • Key Terms:

    • Advertising: Broadcasting small packets (no connection required). Used for beaconing or discovery.

    • GATT (Generic Attribute Profile): Defines how data is organized and exchanged after connection. Uses Services (collections of characteristics) and Characteristics (data points with properties like Read, Write, Notify).

    • Connection Establishment: Central device scans, connects to a Peripheral. Data exchange happens via GATT.

  • Lab Focus: Using ESP32/Arduino 101/NRF52 boards to create a BLE beacon (advertising) or a simple sensor service (GATT server) readable by a phone app (nRF Connect).

• Wi-Fi (ESP32/ESP8266)

  • Modes:

    • Station (STA): Device connects to an existing Wi-Fi router/AP.

    • Access Point (AP): Device creates its own Wi-Fi network for others to join.

  • Communication Sockets:

    • TCP: Connection-oriented, reliable. Used for HTTP, MQTT.

    • UDP: Connectionless, faster, no guarantee. Used for simple telemetry or CoAP.

  • Lab Focus: Programming ESP32 to connect to Wi-Fi (STA mode), send HTTP GET/POST requests to a web server, and establish a raw TCP/UDP socket connection.

• Zigbee/Z-Wave (Overview)

  • Architecture: Mesh network. Devices (End Devices, Routers) form a self-healing network with a Coordinator (creates network) and possibly a Router (extends network).

  • Key: Low power, high reliability, but requires a gateway/hub to communicate with the IP world (cloud/phone).

  • Comparison: Zigbee (open standard, 2.4 GHz), Z-Wave (proprietary, sub-GHz, less interference).

2.1.2. Long-Range/LPWAN Protocols

• LoRaWAN (Long Range Wide Area Network)

  • Architecture: Star-of-stars.

    1. End-Device: Sensor/actuator with LoRa radio.

    2. Gateway: Simple forwarder (packet radio <-> IP). Multiple gateways can hear one device.

    3. Network Server (NS): Core logic. De-duplicates packets from multiple gateways, handles security (join procedure), adaptive data rate (ADR).

    4. Application Server (AS): Receives decoded payloads from NS.

  • Key Parameters:

    • Spreading Factor (SF): Trade-off between data rate and range/power. Higher SF = longer range, slower data, more airtime.

    • Data Rate (DR): Set by region (e.g., EU868, US915). Determined by SF and bandwidth.

  • Link Budget Equation (Simplified):

$$P_{rx} = P_{tx} + G_{tx} + G_{rx} - L_{path}$$

    Where $$\displaystyle P_{rx} $$ is receiver sensitivity, $$\displaystyle P_{tx} $$ is transmitter power, $G$ is antenna gain, $$\displaystyle L_{path} $$ is path loss. LoRa's high link budget (~150 dB) enables km-range.

*   **Class Types:** Class A (lowest power, RX windows after TX), Class B (scheduled RX), Class C (almost always RX).

*   **Exam Focus:** Differentiate between LoRa (physical layer modulation) and LoRaWAN (MAC layer protocol). Understand the role of the Network Server.

• NB-IoT (Narrowband IoT)

  • Concept: Cellular-based LPWAN standard. Uses licensed spectrum (LTE bands), co-exists with GSM/3G/4G.

  • Key Features: Excellent coverage (20 dB gain over GSM), low power, low cost. Requires SIM card and subscription from Mobile Network Operator (MNO).

  • Power Saving Modes: PSM (Power Saving Mode) - device sleeps, wakes for paging. eDRX (extended Discontinuous Reception) - longer sleep cycles with known wake-up times for paging.

2.1.3. IoT Application Layer Protocols

• MQTT (Message Queuing Telemetry Transport)

  • Model: Publish/Subscribe. Decouples producers (publishers) from consumers (subscribers).

  • Broker: Central server. Handles all message routing.

  • Topic: Hierarchical string (e.g., home/livingroom/temp). Publishers send to a topic, subscribers subscribe to topics.

  • QoS (Quality of Service) Levels:

    • 0 (At most once): "Fire and forget." Fastest, least reliable.

    • 1 (At least once): Guaranteed delivery, may have duplicates.

    • 2 (Exactly once): Guaranteed, no duplicates. Slowest, most overhead.

  • Retained Message: Broker stores last message on a topic. New subscribers get it immediately.

  • Last Will & Testament (LWT): Client sets a message & topic that broker publishes if client disconnects ungracefully.

  • Lab Focus: Using mosquitto_pub/sub command line, or Python paho-mqtt library to publish sensor data and subscribe to control commands.

• CoAP (Constrained Application Protocol)

  • Model: RESTful (like HTTP). Uses GET, PUT, POST, DELETE on Resources (URIs).

  • Designed for: Constrained devices (low memory, low power). Uses UDP.

  • Key Feature: Observe mechanism. Client can "observe" a resource; server sends notifications when resource changes (replaces polling).

  • Comparison with HTTP/MQTT:

    | Feature | HTTP | MQTT | CoAP | | :--- | :--- | :--- | :--- | | Model | Request/Response | Pub/Sub | Request/Response (REST) | | Transport | TCP | TCP | UDP | | Header Size | Large | Small | Very Small | | Designed For | Web | Pub/Sub messaging | Constrained devices |

  • Lab Focus: Using libcoap tools or Python coapthon to GET a sensor value from a CoAP server.

• HTTP/REST APIs

  • Concept: Standard web protocol. Used when IoT device has enough resources or via a gateway.

  • Method: GET (retrieve), POST (create), PUT (update), DELETE.

  • Data Format: JSON (most common), XML.

  • Lab Focus: ESP32 making an HTTP POST request with JSON payload to a webhook (e.g., IFTTT, custom server).

[!TIP] Exam Tip: Be prepared to draw a simple diagram of the MQTT Publish/Subscribe model showing Publisher, Broker, and multiple Subscribers on different topics. Know the use-case for each QoS level (e.g., QoS 0 for frequent non-critical sensor data, QoS 2 for critical actuator commands).

2.2. IoT Cloud Platforms & Integration

2.2.1. Platform Architecture & Services

• Core Components:

  1. Device Management: Onboarding (provisioning), monitoring, firmware updates (OTA).

  2. Data Ingestion: Secure endpoint (MQTT/HTTP) to receive device data.

  3. Data Storage: Time-series database (for sensor data), NoSQL/Relational DB (for metadata).

  4. Rules Engine/Processing: Trigger actions based on data (e.g., "if temp > 30, send email").

  5. Analytics & Visualization: Dashboards, charts, basic analytics.

• Popular Platforms Overview:

  • AWS IoT Core: Device gateway (MQTT/HTTP), Device Shadows (virtual device state), Rules Engine (to Lambda, Kinesis, S3), Device Management.

  • Azure IoT Hub: Device-to-cloud & cloud-to-device messaging (MQTT/AMQP/HTTP), Device Twins (similar to Shadows), IoT Edge integration.

  • Google Cloud IoT Core: (Note: Service deprecated, but concepts apply to other GCP services). MQTT/HTTP bridge, Device Manager, Cloud Pub/Sub integration.

  • ThingsBoard (Open Source): All-in-one. Device management, telemetry, rules, dashboards. Can be self-hosted.

  • Blynk: Mobile-app-centric, rapid prototyping. Uses its own protocol over Wi-Fi/Cellular.

2.2.2. End-to-End Integration Lab

• Typical Flow:

  1. Device: ESP32 reads DHT22 sensor.

  2. Connectivity: ESP32 connects to Wi-Fi.

  3. Protocol: ESP32 publishes JSON {"temp":25.5, "hum":60} to MQTT topic v1/devices/me/telemetry.

  4. Cloud: Cloud platform (e.g., ThingsBoard) MQTT broker receives message.

  5. Processing: Rule chain: "If temp > 40, send email via integration."

  6. Dashboard: Real-time chart and gauge widget display latest temp and hum values.

• Key Steps: Provision device (get credentials/access token), write firmware to connect & publish, configure platform's rule chain/dashboard.

[!TIP] Common Pitfall: Forgetting to configure the correct MQTT topic and payload format expected by the cloud platform. Always check the platform's documentation for the exact endpoint URL, port, and JSON structure.

2.3. IoT Security Fundamentals & Practical Considerations

2.3.1. Threat Landscape & Attack Surfaces

2.3.2. Security Mechanisms & Best Practices

• Authentication & Authorization:

  • X.509 Certificates: Strongest method for device authentication. Each device has a unique certificate signed by a CA. Used by AWS IoT, Azure IoT Hub.

  • Pre-Shared Keys (PSK): Symmetric key stored on device and server. Simpler but less scalable/secure than certs.

  • Token-Based (JWT): JSON Web Tokens for stateless API auth.

  • Principle of Least Privilege: Devices/Apps should have only the permissions they need (e.g., a temperature sensor should only publish, not subscribe to control topics).

• Encryption:

  • TLS/DTLS: Provides confidentiality (encryption) and integrity (tamper detection). Mandatory for all communication (MQTT over TLS = MQTTS, port 8883; HTTPS = port 443).

  • Implementation: Requires device to handle TLS handshake (computationally heavy for constrained devices). Often uses pre-shared keys or lightweight certificates.

• Secure Lifecycle:

  • Secure Boot: Device only boots signed firmware.

  • Firmware Signing & OTA Updates: Updates must be cryptographically signed. OTA process must be secure (authenticated, encrypted).

  • Hardware Security Modules (HSM)/Secure Elements: Store keys securely (e.g., ATECC608A chip).

• Network Security: Firewalls, network segmentation (IoT devices on separate VLAN), disable unused ports/services.

[!TIP] Exam Focus: You may be asked to identify security vulnerabilities in a given IoT system diagram or description. Look for: plaintext communication, hard-coded keys, no device authentication, open ports, default credentials.

2.4. Data Management & Analytics for IoT

2.4.1. Handling High-Velocity, High-Volume IoT Data

• Time-Series Databases (TSDB): Optimized for timestamped data. High write/read throughput, efficient compression, time-based queries.

  • Examples: InfluxDB, TimescaleDB (PostgreSQL extension), AWS Timestream.

  • vs. Traditional DB: Relational (MySQL) poor for high-frequency inserts. NoSQL (MongoDB) can work but lacks time-series optimizations (downsampling, retention policies).

• Data Preprocessing:

  • At Edge/Fog: Filter noise, aggregate (e.g., average last 10 readings), normalize units. Reduces bandwidth & cloud cost.

  • At Cloud: Cleanse, enrich, transform data before storage/analytics.

2.4.2. Basic Analytics & Visualization

• Stream Processing: Process data in motion.

  • Tools: AWS IoT Analytics (pipelines), Azure Stream Analytics (SQL-like queries), Apache Kafka/Spark Streaming.

  • Simple Use-Case: "Calculate 5-minute rolling average of temperature from each sensor."

• Statistical Analysis: Mean, median, min/max, standard deviation over time windows.

• Threshold-Based Alerts: Rule: IF temperature > 50°C FOR 2 minutes THEN trigger alarm. Implemented in cloud rules engine or stream processor.

• Visualization: Line charts (time-series), gauges (current value), heat maps (geographic), histograms (distribution).

[!TIP] Exam Tip: Know why a Time-Series Database is preferred for IoT sensor data: (1) Efficient storage of timestamped points, (2) Fast time-range queries, (3) Built-in functions for downsampling and retention.

2.5. Edge Computing & Fog Computing Concepts

2.5.1. Edge vs. Cloud Processing Trade-offs

2.5.2. Edge Frameworks & Implementation

• Concept: Run compute/storage/analytics closer to data source (on gateway or device itself).

• Frameworks:

  • AWS Greengrass: Run AWS Lambda functions, Docker containers, or pre-built "components" on edge devices. Can sync with cloud, operate offline.

  • Azure IoT Edge: Deploy containers (Docker) as "modules" to edge devices. Modules can be Azure services (Stream Analytics, Functions) or custom code.

  • EdgeX Foundry (Open Source): Hardware-agnostic edge platform. Provides device services, core services, and support services.

• Common Edge Tasks:

  • Local Filtering/Aggregation: Send only anomalies or hourly averages.

  • Local Inference: Run ML model (TensorFlow Lite) for real-time object detection on camera feed.

  • Protocol Translation: Convert Zigbee/Z-Wave to MQTT for cloud.

  • Local Control: Act on sensor data immediately (e.g., shut off valve if leak detected) without waiting for cloud.

[!TIP] Exam Focus: Be able to justify moving a specific workload to the edge. Example: "A video analytics system for detecting safety violations should run at the edge because (1) sending raw video to cloud uses too much bandwidth, (2) latency of 2 seconds is unacceptable for immediate alerts, (3) privacy concerns about streaming video to cloud."

UNIT 2 QUICK RECAP (BOXED)

\boxed{

\begin{array}{l}

\textbf{1. Protocols:} \

\quad \bullet \text{ BLE: Advertising (broadcast) vs GATT (connected, services/characteristics).} \

\quad \bullet \text{ MQTT: Publish/Subscribe, Broker, QoS 0/1/2, Retain, LWT.} \

\quad \bullet \text{ LoRaWAN: End-Device $$\displaystyle \rightarrow $$ Gateway $$\displaystyle \rightarrow $$ Network Server $$\displaystyle \rightarrow $$ App Server.} \

\quad \bullet \text{ CoAP: RESTful, UDP, Observe mechanism.} \

\

\textbf{2. Cloud Integration:} \

\quad \bullet \text{ Flow: Device $\xrightarrow{\text{MQTT/HTTP}}$ Cloud Ingest $$\displaystyle \rightarrow $$ Rules $$\displaystyle \rightarrow $$ Dashboard.} \

\quad \bullet \text{ Key Platform Services: Device Mgmt, Data Store (TSDB), Rules Engine.} \

\

\textbf{3. Security:} \

\quad \bullet \text{ MUST use TLS for all communication.} \

\quad \bullet \text{ Device Auth: X.509 Certs (best) or PSK.} \

\quad \bullet \text{ Principle of Least Privilege for topics/permissions.} \

\

\textbf{4. Data:} \

\quad \bullet \text{ Use Time-Series DB (InfluxDB) for sensor data.} \

\quad \bullet \text{ Preprocess at edge to reduce bandwidth.} \

\

\textbf{5. Edge Computing:} \

\quad \bullet \text{ Trade-off: Cloud (power) vs Edge (latency/bandwidth/privacy).} \

\quad \bullet \text{ Frameworks: AWS Greengrass, Azure IoT Edge.}

\end{array}

}