Internet of Things (ME-702 (B)) - Unit 2 Short Notes

1. IoT Fundamentals and Ecosystem

Definition and Core Concept

• IoT (Internet of Things): A network of physical objects ("things") embedded with sensors, software, and connectivity to exchange data with other devices and systems over the internet.

• Core Idea: Extend internet connectivity beyond traditional devices (computers, smartphones) to everyday objects, enabling remote monitoring, control, and intelligent decision-making.

IoT Ecosystem and Stakeholders

Logical vs. Physical Design of IoT

Key Characteristics of IoT Systems

• Interoperability: Devices from different vendors can communicate.

• Scalability: Supports massive numbers of connected devices.

• Connectivity: Reliable, often low-power, wireless/wired links.

• Dynamic & Self-Adapting: Devices may change state or network topology.

• Security & Privacy: Critical due to sensitive data and physical world impact.

• Intelligence & Automation: Data analytics enable autonomous actions.

Role of "Things" and Internet in IoT

• "Things": Physical entities (sensors, actuators, vehicles, appliances) that sense (collect data) or act (execute commands). They are the data source/actuation point.

• Internet: Provides global, standardized connectivity and addressing (via IP). Enables cloud integration, remote access, and large-scale data processing.

IoT Analytics Overview

• Purpose: Extract meaningful insights from vast, often real-time, IoT data streams.

• Types:

  • Descriptive: What happened? (e.g., average temperature last hour).

  • Diagnostic: Why did it happen? (e.g., correlation between humidity and mold).

  • Predictive: What will happen? (e.g., machine failure prediction).

  • Prescriptive: What action to take? (e.g., adjust HVAC automatically).

• Challenges: Volume, velocity, variety (3Vs) of data; often requires edge preprocessing.

IoT Enablers Overview

[!TIP] Exam Focus: Logical/Physical design, IoT characteristics, and enablers are frequently asked (Jun 2025, May 2024, May 2022). Be ready to draw/compare the two designs.

2. IoT Architectural Frameworks

IoT Reference Architecture and Information Model

• Reference Architecture: A standardized, layered blueprint defining components, interfaces, and interactions. Common models:

  • 3-Layer: Perception (sensing), Network (communication), Application (services).

  • 5-Layer: Adds Middleware (data processing, device management) and Business (profit models, policies).

  • IoT-A (European): Includes Process, Service, Application, Network, Device layers.

• Information Model: Defines data structures, metadata, and relationships for IoT entities (e.g., "sensor" has attributes: ID, location, measurement type, unit). Enables semantic interoperability.

IoT Planes and Enablers with Interdependencies

• Planes (Logical Separation):

  • Management Plane: Device onboarding, configuration, security policies.

  • Data Plane: Actual data flow from sensors to cloud/analytics.

  • Control Plane: Commands from applications to actuators.

  • Security Plane: Authentication, encryption, access control across all planes.

• Interdependencies: Security policies (Security Plane) affect data routing (Data Plane); device management (Management Plane) requires control messages (Control Plane). Complexity arises from cross-plane interactions.

Service-Oriented Architecture (SOA) for IoT and Challenges

• SOA in IoT: Treats each device/function as a service with standardized interfaces (e.g., RESTful APIs). Enables composition of complex services from simple ones.

• Challenges:

  • Resource Constraints: Devices have limited CPU/memory for full SOA stacks.

  • Dynamic Discovery: Devices join/leave frequently; need lightweight service registries.

  • Latency: SOAP/HTTP overhead may be too high for real-time IoT.

  • Scalability: Millions of services strain traditional SOA registries.

IoT Levels (Level 3 vs. Level 4 Systems)

IoT Communication Models

1. Device-to-Device (D2D): Direct communication (e.g., Bluetooth, ZigBee).

2. Device-to-Gateway: Device talks to a gateway that proxies to cloud (common in constrained networks).

3. Device-to-Cloud: Direct IP connection to cloud service (e.g., Wi-Fi sensor sending MQTT to AWS).

4. Cloud-to-Device: Cloud sends commands/configurations to devices (downlink).

5. Cloud-to-Cloud: Integration between different cloud platforms (e.g., Azure IoT Hub to Salesforce).

Building Blocks of IoT

1. Sensors/Actuators (Perception).

2. Connectivity (Network: short/long-range, IP/non-IP).

3. Edge/Gateway Computing (Local preprocessing, protocol translation).

4. Cloud Platform (Scalable storage, processing, device management).

5. Applications & Analytics (User interfaces, business logic, insights).

6. Security Framework (Across all blocks).

M2M vs. IoT: Differences and Shift

M2M Service Layer Standardization

• Goal: Provide common service capabilities (e.g., device management, data routing) over diverse M2M access technologies.

• Key Standard: oneM2M (global consortium). Defines:

  • Common Service Layer (CSL): Functions like registration, security, data storage.

  • Resource-oriented architecture: Everything is a "resource" (URI-based).

  • Interworking with other standards (e.g., OMA LWM2M, ZigBee).

• Benefit: Enables cross-vendor M2M/IoT systems, avoids fragmentation.

[!TIP] Exam Focus: M2M vs IoT and IoT Levels are high-frequency (Dec 2024, May 2022). Be prepared to draw Level 3/4 architectures and list 3-4 key differences.

3. Hardware Components and Enablers

Sensors

• Types in IoT Networks:

  • By Measurand: Temperature, humidity, pressure, light, motion (PIR), gas (CO₂), sound, proximity.

  • By Output: Analog (voltage/current), Digital (I2C/SPI/UART), Pulse/Frequency.

  • By Power: Active (require external power), Passive (energy harvesting).

• Common Commercially Available Sensors:

  • DHT22: Temperature & humidity (digital, ~$5).

  • MQ-2: Gas (smoke, LPG, butane) (analog/digital).

  • PIR (HC-SR501): Motion detection.

  • Ultrasonic (HC-SR04): Distance measurement.

  • BMP180: Barometric pressure & temperature.

• Sensor Features & Characteristics:

  • Accuracy: Closeness to true value.

  • Precision: Repeatability of measurements.

  • Resolution: Smallest detectable change.

  • Range: Min/max measurable values.

  • Sensitivity: Output change per input change.

  • Drift: Output change over time for constant input.

  • Response Time: Time to reach % of final value.

• Quantization Error in Sensing:

  • Cause: Analog-to-Digital Converter (ADC) maps continuous analog signal to discrete digital levels.

  • Formula: $$\displaystyle \text{Quantization Error} = \pm \frac{\text{LSB}}{2} $$, where LSB (Least Significant Bit) = $$\displaystyle \frac{\text{Full Scale Range}}{2^n} $$, $n$ = bits.

  • Example: 10-bit ADC, 0-5V range → LSB = 5V/1024 ≈ 4.88mV → Max error = ±2.44mV.

Actuators

• Types:

  • Mechanical: Motors (DC, stepper, servo), relays, solenoids. High force/speed, wear out.

  • Soft: Silicone, rubber-based. Deformable, safe for human interaction (e.g., soft grippers).

  • Shape Memory Polymer (SMP): Changes shape with temperature/light. Slow, high strain, reusable.

  • Pneumatic: Air pressure driven. Fast, clean, requires compressor.

• Four Common Characteristics for Selection:

  1. Force/Torque Output: Required mechanical work.

  2. Speed/Response Time: How fast it must act.

  3. Accuracy & Resolution: Precision of positioning/movement.

  4. Operating Environment: Temperature, humidity, explosive/sterile conditions.

• Comparison of Actuator Types:

  | Type | Principle | Advantages | Disadvantages | IoT Applications | |----------|---------------|----------------|-------------------|----------------------| | Mechanical | Electromagnetic, electric motor | High power, precise, mature | Noise, wear, maintenance | Industrial robots, valves | | Soft | Deformable elastomers | Compliance, safety, low cost | Low force, slow, hard to model | Wearables, medical devices | | SMP | Phase change (thermal/light) | Large strain, remote activation | Slow, limited cycles, expensive | Biomedical stents, deployable structures |

Microcontrollers and Single-Board Computers

• Review of Basic Microcontrollers:

  • Definition: Integrated circuit with CPU, memory (RAM/Flash), I/O peripherals (GPIO, ADC, UART, SPI, I2C).

  • Examples: Arduino Uno (ATmega328P, 8-bit, 32KB Flash), ESP32 (32-bit, Wi-Fi/BLE, 520KB RAM).

  • Use in IoT: Low-cost, low-power, real-time control at edge.

• Interfacing Techniques:

  • SPI (Serial Peripheral Interface): Full-duplex, synchronous, master-slave. 4 wires (MOSI, MISO, SCK, SS). High speed, short distance.

  • I2C (Inter-Integrated Circuit): Half-duplex, synchronous, multi-master/multi-slave. 2 wires (SDA, SCL). Address-based, moderate speed.

  • GPIO (General Purpose Input/Output): Simple digital pins for on/off or reading digital signals.

• Raspberry Pi vs. Desktop Computer:

  • Raspberry Pi: ARM-based SoC (System-on-Chip), low power (5V), no internal storage (SD card), no BIOS, runs Linux, GPIO headers for hardware interfacing.

  • Desktop: x86 architecture, high power, internal HDD/SSD, full BIOS/UEFI, Windows/Linux, no direct GPIO.

  • Use in IoT Projects: Pi acts as edge gateway—aggregates sensor data (via GPIO/SPI/I2C), runs local analytics, connects to cloud via Wi-Fi/Ethernet.

RFID (Radio Frequency Identification)

• Principles and Concepts:

  • Tags: Passive (no battery, powered by reader's RF), Active (battery-powered), Semi-passive.

  • Readers: Emit RF signal, receive tag response.

  • Frequency Bands: LF (125-134 kHz), HF (13.56 MHz), UHF (860-960 MHz), Microwave (2.4 GHz).

  • Coupling: Inductive (LF/HF), Electromagnetic (UHF).

• RFID Features and Terminology:

  • Read Range: Passive (cm to m), Active (up to 100m).

  • Data Capacity: Tags store ID (EPC), possibly user memory.

  • Anti-Collision: Algorithms to read multiple tags simultaneously (ALOHA, binary tree).

  • EPCglobal: Standard for electronic product codes.

• Implementation in Smart Things/IoT:

  • Asset Tracking: Supply chain, inventory (warehouses, retail).

  • Access Control: RFID cards for doors.

  • Payment Systems: Contactless cards (NFC is subset of RFID at 13.56 MHz).

  • Integration: RFID reader connects to microcontroller (UART) or directly to network gateway; data sent to cloud via MQTT/HTTP.

Gateways

• Functionality and Role:

  • Protocol Translation: Convert between device-level protocols (ZigBee, BLE, Modbus) and IP-based protocols (MQTT, HTTP).

  • Data Aggregation & Filtering: Collect from multiple sensors, preprocess (e.g., average, thresholding) to reduce cloud traffic.

  • Security Edge: Firewall, TLS termination, device authentication.

  • Local Control & Buffering: Run rules/scripts offline; store data during network outage.

  • Device Management: Onboarding, firmware updates, health monitoring.

• Position in Ecosystem: Edge layer between perception (sensors) and network/cloud. Acts as "intelligent bridge".

Other Enablers Summary

[!TIP] Exam Focus: Sensors (types, quantization error), Actuators (selection characteristics, comparison), RFID (features, implementation), and Gateways (functionality) are repeatedly asked (Jun 2025, May 2024, May 2023). Know commercial sensor examples and actuator trade-offs.

4. Communication Technologies and Network Layer

Wireless Sensor Networks (WSN)

• Relation between WSN and IoT: WSN is a key enabler for IoT. WSN provides the sensing infrastructure (dense, collaborative nodes) that feeds data into the broader IoT ecosystem (cloud, applications). IoT extends WSN by adding IP connectivity, cloud integration, and scalable services.

• Example: A WSN of temperature/humidity sensors in a farm (using ZigBee) sends data to a gateway, which publishes via MQTT to an IoT cloud platform for irrigation control.

• Applications:

  • Environmental monitoring (forest fires, pollution).

  • Industrial automation (predictive maintenance).

  • Smart agriculture (soil moisture).

  • Health monitoring (wearable sensor networks).

IEEE 802.15.4 Protocol

• Overview: Standard for low-rate wireless personal area networks (LR-WPANs). Defines physical (PHY) and medium access control (MAC) layers.

• Key Features:

  • Data Rates: 250 kbps (2.4 GHz), 40 kbps (915 MHz), 20 kbps (868 MHz).

  • Topologies: Star, peer-to-peer, mesh (via network layer).

  • Power: Very low-power, battery-operated for years.

  • Frame Structure: Beacon-enabled (synchronized) or non-beacon (unsynchronized).

• Relation to IoT: Serves as the foundation for higher-layer protocols like ZigBee, 6LoWPAN, and WirelessHART. Provides the raw wireless link for constrained IoT devices.

6LoWPAN

• Role in IoT: IPv6 over Low-Power Wireless Personal Area Networks. Adaptation layer that enables IPv6 packets to be carried efficiently over IEEE 802.15.4 networks.

• Why Needed? IPv6 packets (1280 bytes) are too large for 802.15.4's max frame size (127 bytes). 6LoWPAN performs:

  • Header Compression: Reduces IPv6/UDP headers from 40+ bytes to ~10 bytes.

  • Fragmentation & Reassembly: Splits large packets.

• Differences from IPv4/IPv6:

  | Aspect | IPv4 | IPv6 | 6LoWPAN | |------------|----------|----------|-------------| | Address Size | 32-bit | 128-bit | Uses IPv6 but compresses headers | | Header | 20-60 bytes, variable | 40 bytes fixed | Compressed to ~10 bytes | | Fragmentation | Done at source/router | Source-only | Done at adaptation layer | | Designed For | General Internet | General Internet (large MTU) | Constrained networks (small MTU, low power) |

ZigBee

• Architecture and Components (based on IEEE 802.15.4):

  
  [[DIAGRAM: CANVAS: 
  
  ZigBee Network Architecture:
  
  - Coordinator (one per network): Forms network, stores network info, can be gateway to IP.
  
  - Router (multiple): Extends network range, routes packets, can be mains-powered.
  
  - End Device (many): Sleeps most of time, talks only to parent (coordinator/router), battery-powered.
  
  Topologies: Star (coordinator only), Tree (routers/end devices), Mesh (routers relay).
  
  ]]
  
  

• Types of ZigBee:

  • ZigBee PRO (ZigBee 2007+): Standard for general IoT (lighting, home automation). Supports mesh, large networks (65k nodes).

  • ZigBee IP: Uses IPv6 and 6LoWPAN; aimed at IP-based IoT.

  • ZigBee RF4CE: Consumer electronics (remote controls), low latency.

  • ZigBee Green Power: Energy harvesting devices (no battery).

Near Field Communication (NFC)

• Technologies:

  • Frequency: 13.56 MHz, range ≤10 cm.

  • Modes: Reader/Writer (read tags), Peer-to-Peer (device-to-device), Card Emulation (phone as smart card).

  • Standards: ISO/IEC 14443 (proximity cards), ISO/IEC 18092 (peer-to-peer).

• Applications:

  • Contactless payments (Apple Pay, Google Pay).

  • Device pairing (Bluetooth/Wi-Fi handover).

  • Access control (door locks, transit tickets).

  • Smart posters (URLs via tags).

  • IoT: Simple configuration (tap to pair sensor with phone).

Network Topologies and Connection Types

• Classification by Physical Topology:

  | Topology | Diagram | IoT Use Case | |--------------|-------------|------------------| | Star |

  DiagramSEARCH: star network topology diagram
  | Hub-and-spoke (e.g., Wi-Fi access point to sensors). | | Mesh |
  DiagramSEARCH: mesh network topology diagram
  | ZigBee, Thread; robust, self-healing (smart lighting). | | Tree |
  DiagramSEARCH: tree network topology diagram
  | Hierarchical (coordinator→routers→end devices). | | Bus |
  DiagramSEARCH: bus network topology diagram
  | Wired (Ethernet), legacy. | | Ring |
  DiagramSEARCH: ring network topology diagram
  | Less common in IoT; some industrial networks. |

• Connection Types:

  • Wired: Ethernet, RS-485 (industrial). Reliable, high bandwidth, fixed.

  • Wireless: WPAN (Bluetooth, ZigBee), WLAN (Wi-Fi), LPWAN (LoRaWAN, NB-IoT), Cellular (4G/5G).

IoT LAN Development Issues

• Factors Affecting Development & Implementation:

  1. Interference: Wi-Fi, Bluetooth, microwave ovens (2.4 GHz congestion).

  2. Coverage & Range: Physical obstacles, building materials; may need repeaters/mesh.

  3. Power Constraints: Battery life vs. transmission power/duty cycle.

  4. Scalability: Number of devices per gateway/access point.

  5. Security: Unencrypted wireless traffic vulnerable to eavesdropping/jamming.

  6. Protocol Suitability: Data rate, latency, power consumption trade-offs.

  7. Regulatory: Frequency band licensing (e.g., ISM bands vs. licensed spectrum).

Software Defined Networking (SDN)

• Explanation: Separates control plane (routing decisions, centralized controller) from data plane (packet forwarding, distributed switches). Controller programs switches via OpenFlow.

• Maturity in IoT Context:

  • Potential Benefits: Centralized management of heterogeneous IoT networks, dynamic QoS for critical traffic, security policy enforcement.

  • Challenges/Maturity:

    • Controller Scalability: Millions of IoT devices overwhelm controller.

    • Latency: Centralized decisions may add latency for real-time IoT.

    • Security: Controller is single point of failure/attack.

    • Resource Constraints: IoT devices cannot run SDN switch logic.

    • Maturity: Not mature for large-scale IoT. Mostly in research/testbeds and controlled environments (e.g., enterprise IoT networks). Edge computing (fog) often more practical for IoT.

[!TIP] Exam Focus: 6LoWPAN (role, differences), ZigBee architecture (draw & explain), IEEE 802.15.4, and SDN maturity are very frequent (Jun 2025, May 2024, May 2022). Practice drawing ZigBee network with coordinator/router/end devices.

5. Application Layer Protocols

MQTT (Message Queuing Telemetry Transport)

• Role in IoT: Publish/Subscribe messaging protocol designed for low-bandwidth, high-latency, unreliable networks. Lightweight header (2 bytes), uses TCP for reliability.

• Example: Temperature sensor (publisher) sends sensors/temp1 topic with value 25.5 to broker. Mobile app (subscriber) receives it.

• Components: Client (device/app), Broker (server), Topic (string hierarchy), QoS (0: at most once, 1: at least once, 2: exactly once).

• Use of WebSockets with MQTT: Enables MQTT over HTTP/HTTPS ports (80/443), bypassing firewalls. Browser-based IoT apps can use MQTT via WebSocket connection to broker.

CoAP (Constrained Application Protocol)

• Basic Operations: RESTful (GET, PUT, POST, DELETE) like HTTP, but UDP-based (lower overhead). Uses confirmable (CON) and non-confirmable (NON) messages.

• Request-Response Model:

  1. Client sends CON/NON request to server (resource URI, e.g., coap://sensor/temp).

  2. Server responds with ACK (for CON) or separate response. Can include Observe option for notifications (publish-subscribe like).

• Use Between Devices on Same Constrained Network:

  • Justification: CoAP is designed for constrained nodes (minimal header, UDP, no TLS by default). On a local constrained network (e.g., 6LoWPAN), devices can communicate directly without gateway translation, reducing latency and power. MQTT requires a broker (often in cloud), adding hops. CoAP's multicast support (e.g., coap://[ff02::1] for all nodes) is efficient for local commands.

AMQP (Advanced Message Queuing Protocol)

• Features and Components:

  • Wire-level protocol for message-oriented middleware.

  • Components: Sender → Exchange (routes messages) → Queue (stores messages) → Receiver.

  • Exchange Types: Direct (routing key), Topic (pattern), Fanout (broadcast), Headers.

  • Guaranteed Delivery: Persistent messages, acknowledgments, transactions.

• Message Attributes and Payload:

  • Attributes: routing-key, content-type, delivery-mode (persistent/transient), priority, timestamp, message-id.

  • Payload: Arbitrary binary data (application-specific).

• Frame Types (AMQP 1.0):

  • OPEN, BEGIN, ATTACH, FLOW, TRANSFER, DISPOSITION, CLOSE. (~7 core frame types).

XMPP (Extensible Messaging and Presence Protocol)

• How It Improves IoT Services:

  • Decentralized: No central broker needed; devices can communicate peer-to-peer.

  • Presence & Discovery: Built-in presence (online/offline) and service discovery (XMPP Disco).

  • Extensibility: XMPP Extension Protocols (XEPs) for IoT (e.g., XEP-0323: IoT Sensors, XEP-0325: IoT Control).

  • Security: SASL authentication, TLS encryption.

  • Use Case: Chat-like interaction with devices, multi-user control (e.g., family controlling smart home).

SMQTT (Secure MQTT)

• Secure Message Transfer Mechanisms:

  • TLS/SSL: Encrypts entire MQTT connection (MQTTS on port 8883).

  • Client Certificate Authentication: Mutual TLS for device authentication.

  • Access Control Lists (ACLs): Broker enforces topic-level permissions.

  • Payload Encryption: Application-level encryption (e.g., AES) for end-to-end security, even if broker is compromised.

  • Key Management: Pre-shared keys or PKI for constrained devices.

WebSockets

• Role in IoT Communication:

  • Provides full-duplex, persistent TCP connection between client and server over HTTP.

  • Use Cases:

    • Real-time web dashboards (browser receives live sensor data).

    • Bi-directional control (user sends commands, device acknowledges instantly).

    • Fallback for MQTT: When MQTT over TCP is blocked, MQTT over WebSockets can be used.

  • Advantage over HTTP Polling: Reduces overhead, latency; server can push data.

[!TIP] Exam Focus: CoAP in constrained networks, MQTT vs AMQP, ZigBee architecture, and SMQTT are highly frequent (Jun 2025, Dec 2024, May 2024). Know CoAP's UDP advantage for local networks and MQTT's QoS levels.

6. Security in IoT

Why Security is Required in IoT

• Physical World Impact: Attacks can cause real harm (e.g., medical device tampering, industrial sabotage).

• Data Sensitivity: Personal data (home, health), corporate secrets.

• Large Attack Surface: Billions of devices, often poorly secured.

• Critical Infrastructure: IoT in power grids, transportation.

• Privacy: Constant sensing can violate user privacy.

Various Security Models for IoT

1. CIA Triad Adaptation:

   • Confidentiality: Encryption (TLS, DTLS, AES).

   • Integrity: Message Authentication Codes (HMAC), digital signatures.

   • Availability: DDoS mitigation, redundant systems.

2. Defense-in-Depth: Multiple security layers (device, network, cloud, application).

3. Zero Trust: "Never trust, always verify." Continuous authentication/authorization.

4. Privacy by Design: Embed privacy into system architecture (data minimization, anonymization).

5. IoT-Specific Models:

   • Lightweight Cryptography: Algorithms for constrained devices (e.g., PRESENT, SPECK).

   • Trusted Platform Module (TPM): Hardware root of trust for device identity.

Vulnerabilities Observed in IoT Systems

Attacks on IoT Systems (Application/Service Layer)

• Message Spoofing/Injection: Fake sensor data sent to cloud/app (e.g., false temperature reading).

• Replay Attacks: Capturing valid message and retransmitting later (e.g., replaying "unlock door" command).

• Denial-of-Service (DoS/DDoS): Overwhelming broker (MQTT) or application server (e.g., botnet sending malformed CoAP requests).

• Man-in-the-Middle (MitM): Intercepting/modifying messages between device and cloud (if no TLS).

• Broker/Server Compromise: Attacking central IoT platform (e.g., AWS IoT) to control many devices.

• Topic Hijacking (MQTT): Subscribing to sensitive topics due to weak ACLs.

Security and Privacy Issues

• Security Issues:

  • Device Authentication: How to uniquely identify billions of devices? (Certificates vs. PSK).

  • Key Management: Distributing/rotating keys on constrained devices.

  • Software Updates: Secure, over-the-air (OTA) updates without bricking devices.

  • Supply Chain: Malicious hardware/firmware inserted during manufacturing.

• Privacy Issues:

  • Data Ownership: Who owns sensor data? User, device maker, cloud provider?

  • Surveillance: Always-on sensors (cameras, mics) in private spaces.

  • Profiling: Aggregating data to infer habits, preferences, location.

  • Consent: Informed consent for data collection often absent.

Comprehensive Security Concerns and Challenges

1. Scale: Securing billions of devices is unprecedented.

2. Heterogeneity: Diverse hardware, OS, protocols—no one-size-fits-all security.

3. Resource Constraints: Limited CPU/memory for crypto; trade-off between security and battery life.

4. Lifecycle Management: Devices deployed for 5-10 years; must support security updates.

5. Physical Exposure: Devices in public/unattended locations (tampering).

6. Regulatory Gap: Lack of mandatory security standards (unlike medical/auto industries).

7. User Awareness: Consumers don't understand IoT risks (default passwords).

[!TIP] Exam Focus: Security models, vulnerabilities, and attacks (especially application layer) are extremely frequent (Jun 2025, May 2024, May 2023, May 2022). Be ready to list 4-5 vulnerabilities and corresponding attacks.

7. Cloud Computing, Data Analytics and Integration

Cloud Service Models in IoT Context

Cloud Communication APIs for IoT

• RESTful HTTP/HTTPS: Simple request-response (e.g., device shadow GET/PUT). High overhead.

• MQTT over TCP/TLS: Publish-subscribe, lightweight. Standard for device-to-cloud.

• CoAP over UDP/DTLS: For constrained devices directly to cloud (less common due to NAT/firewall).

• Proprietary APIs: Vendor-specific (e.g., AWS IoT Device SDKs for various languages).

• Key Operations: Device Onboarding (provisioning), Telemetry Send (sensor data), Shadow Update (desired/reported state), Command Send (actuator control).

Usefulness of Cloud for IoT

1. Scalability: Handles millions of devices/data points.

2. Cost-Effective: Pay-per-use; no upfront infrastructure.

3. Global Reach: Data centers worldwide, low-latency access.

4. Advanced Analytics: Built-in ML/AI services (e.g., AWS SageMaker, Azure Stream Analytics).

5. Device Management: Fleet management, OTA updates, monitoring.

6. Integration: Easy to connect with other enterprise systems (ERP, CRM).

Cloud IoT Integration Challenges (with Example)

• Example Challenge: Legacy Industrial System Integration.

  • Scenario: Factory has old PLCs (Programmable Logic Controllers) using Modbus RTU (serial). Want to send data to AWS IoT.

  • Challenges:

    1. Protocol Translation: Modbus → MQTT/HTTP. Need edge gateway with protocol converter.

    2. Data Format: PLC data is binary/register-based; must map to JSON for cloud.

    3. Latency: Real-time control requires <100ms; cloud round-trip may be 200ms+ → need edge analytics.

    4. Security: PLCs have no security; gateway must authenticate to cloud and isolate PLC network.

    5. Cost: Cloud data ingestion/storage costs for high-frequency sensor data.

  • Overcoming: Use edge gateway (e.g., Raspberry Pi + Modbus library) to preprocess, aggregate, and send only relevant data via MQTT. Implement local rules for time-critical actions.

Role of Data Analytics in IoT

• From Data to Decisions:

  1. Data Ingestion: Collect from millions of devices (streams).

  2. Data Processing: Clean, filter, aggregate (often at edge).

  3. Analytics:

     • Real-time: Anomaly detection (e.g., machine vibration spike).

     • Batch: Historical trend analysis (e.g., seasonal energy use).

     • Predictive: ML models (e.g., failure prediction from sensor drift).

     • Prescriptive: Optimization (e.g., dynamic pricing based on demand).

  4. Visualization & Action: Dashboards, alerts, automated control.

• Value: Operational efficiency, predictive maintenance, new revenue streams.

Differences in Data Analytics Approaches: M2M vs. IoT

[!TIP] Exam Focus: Cloud usefulness, integration challenges, and Data Analytics role are regularly asked (Dec 2024, May 2024, May 2023). Be ready to give a concrete example of integration challenge (like legacy system) and how analytics differs from M2M.

8. Applications, Platforms and Case Studies

Smart Home Automation Design with Raspberry Pi

• System Sketch:

  
  [[DIAGRAM: CANVAS:
  
  Smart Home System with Raspberry Pi:
  
  1. Raspberry Pi 4 (Edge Gateway/Hub):
  
     - Runs Linux, Node-RED/Home Assistant.
  
     - Interfaces: GPIO (for direct sensors), USB (ZigBee USB dongle), Wi-Fi/Ethernet (to cloud).
  
  2. Sensors (Perception Layer):
  
     - DHT22 (temp/humidity) → GPIO
  
     - PIR motion → GPIO
  
     - MQ-2 gas → GPIO
  
     - Door/window magnetic switch → GPIO
  
  3. Actuators:
  
     - Relay module → GPIO (controls lights, fans)
  
     - Servo motor → GPIO (door lock)
  
  4. Communication:
  
     - Short-range: ZigBee (for battery sensors), Bluetooth (phone pairing).
  
     - Long-range: Wi-Fi (Pi to cloud).
  
  5. Cloud/App:
  
     - MQTT broker (e.g., Mosquitto on Pi or cloud).
  
     - Mobile app (React Native) subscribes to topics.
  
     - Rules: "If motion detected after 10 PM → turn on light."
  
  6. Security: TLS for MQTT, VPN for remote access, strong passwords.
  
  ]]
  
  

• Applications in Home Automation:

  • Lighting Control: Auto on/off based on motion/time.

  • Climate Control: Thermostat adjustment from temp/humidity.

  • Security: Intrusion detection (PIR + camera), gas leak alert.

  • Energy Management: Smart plugs, monitor appliance usage.

  • Entertainment: Voice control (integrate Alexa/Google Home).

IoT Platforms Overview and Characteristics

• Definition: Integrated suite of services for device management, data ingestion, processing, and application enablement.

• Characteristics:

  • Device Management: Onboarding, provisioning, monitoring, OTA updates.

  • Data Ingestion: Support for MQTT, CoAP, HTTP; high throughput.

  • Rules Engine: Simple "if-then" logic (e.g., "temperature > 30 → send alert").

  • Analytics & Storage: Time-series databases, built-in analytics, integration with big data tools.

  • Security: Authentication, authorization, encryption at rest/in transit.

  • Ecosystem: APIs, SDKs, marketplace for third-party apps.

• Examples:

  • Public Cloud: AWS IoT Core, Azure IoT Hub, Google Cloud IoT Core.

  • Industrial: PTC ThingWorx, Siemens MindSphere.

  • Open Source: Eclipse Kura, ThingsBoard.

Case Study: Smart Agriculture (Precision Farming)

• Detailed Discussion:

  • Objective: Optimize water usage, increase crop yield, reduce labor.

  • Architecture:

    • Sensors: Soil moisture (capacitive), temperature/humidity (DHT22), rain gauge, NDVI camera (drone) for crop health.

    • Network: LPWAN (LoRaWAN) for long-range, low-power field sensors; Wi-Fi for gateway and camera.

    • Gateway: Raspberry Pi aggregates LoRa data, sends via MQTT to cloud.

    • Cloud Platform: AWS IoT Core (device registry, MQTT broker), DynamoDB (time-series data), Lambda (serverless functions for rules).

    • Analytics: Predict irrigation needs based on weather forecast + soil data; detect pests from camera images (ML).

    • Application: Farmer dashboard (web/mobile) shows field map, alerts, irrigation control.

  • Challenges: Wide area coverage (LoRa gateways), power for sensors (solar), data accuracy, farmer adoption.

  • Outcomes: 20-30% water savings, 10-15% yield increase.

Other Applications Overview

• Industrial IoT (IIoT): Predictive maintenance, asset tracking, safety monitoring.

• Smart Cities: Traffic management, waste management, air quality monitoring.

• Healthcare: Remote patient monitoring, asset tracking in hospitals.

• Retail: Inventory management, personalized offers (beacons).

• Transportation: Fleet tracking, telematics, connected vehicles.

[!TIP] Exam Focus: Smart Home design with sketch and IoT platforms are very common (Jun 2025, Dec 2024, May 2023). Practice drawing the Raspberry Pi-based smart home block diagram. For case study, know one in depth (e.g., smart agriculture or smart city) with architecture, challenges, benefits.

Final Note: This condensed guide covers all high-frequency topics from past RGPV papers (Jun 2025–May 2022). Focus on comparisons (M2M vs IoT, actuator types, protocols), diagrams (ZigBee, IoT levels, smart home), and security/attacks. Use the boxed formulas and definitions for quick revision. Good luck!