UNIT 3: INTERNET OF THINGS - COMPREHENSIVE NOTES

1.0 IoT FUNDAMENTALS & ARCHITECTURAL FRAMEWORK

1.1 IoT Definition, Vision & Key Ideas

• Definition: A system of interrelated computing devices, mechanical and digital machines, objects, animals, or people provided with unique identifiers (UIDs) and the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction.

• Vision: To connect "things" to the Internet, making them intelligent and actionable through data.

• Key Ideas: Ubiquitous connectivity, sensing, actuation, pervasive computing, data analytics, automation.

1.2 IoT Ecosystem & Functional Components

The IoT ecosystem is a four-layer model:

1. Things (Physical Layer): Sensors, actuators, devices with embedded systems.

2. Internet (Connectivity Layer): Communication networks (WAN, LAN, PAN) and protocols for data transport.

3. Analytics (Data Processing Layer): Cloud/edge platforms for data storage, processing, and deriving insights.

4. Applications (Service Layer): User-facing applications and services that deliver value (e.g., smart home apps, industrial dashboards).

1.3 IoT Architectural Frameworks (High Priority)

1.3.1 IoT Reference Architecture & Information Model

• A reference architecture provides a standardized, abstract framework for designing IoT systems. It defines components, their relationships, and design principles.

• Common models include:

  • Three-Layer Model: Perception Layer (sensors), Network Layer (connectivity), Application Layer (services).

  • Five-Layer Model: Adds Middleware/Service Layer (data processing, service management) and Business Layer (management, business models).

  • IoT-A (IoT Architecture): A more detailed European reference model with 8-9 layers including Device, Communication, Service, and Application layers.

• Information Model: Defines the structure, relationships, and semantics of data within the IoT system (e.g., using standards like oneM2M, SAREF). It ensures interoperability.

1.3.2 IoT Planes & Enablers (Complex Interdependencies)

IoT systems are often viewed as intersecting planes:

• Device Plane: Physical things, sensors, actuators.

• Communication Plane: Networks, gateways, protocols.

• Service Plane: Service discovery, composition, management.

• Management Plane: Device management, security, configuration.

• Security Plane: Identity, access control, privacy.

• Application Plane: End-user applications.

• Enablers are technologies that support these planes (e.g., Cloud, Big Data, AI, Blockchain). Interdependencies are critical; e.g., security enabler affects all planes.

1.3.3 Service-Oriented Architecture (SOA) for IoT & Challenges

• SOA in IoT: Treats each device/function as a reusable, loosely-coupled "service" with standardized interfaces (often Web Services). Enables dynamic composition of services from heterogeneous devices.

• Challenges:

  • Scalability: Managing millions of service endpoints.

  • Interoperability: Diverse device protocols and data formats.

  • Real-time Requirements: SOA can introduce latency.

  • Resource Constraints: Devices may lack resources for full SOA stacks.

1.3.4 IoT Levels & System Classification (Level 1-4)

Classification based on system complexity and connectivity.

** [!TIP] Exam Focus:** Be prepared to draw and contrast Level 3 vs. Level 4. Level 4 emphasizes edge intelligence, agility, and multi-network orchestration.

1.4 Logical vs. Physical Design of IoT Systems

• Logical Design: Focuses on functional components and data flow. Defines what the system does (e.g., sensors collect data, gateway aggregates, cloud analyzes, app displays). Uses block diagrams, data flow diagrams.

• Physical Design: Focuses on hardware components and their physical interconnections. Defines how it's built (e.g., DHT22 sensor, ESP32 microcontroller, Raspberry Pi gateway, AWS IoT Cloud). Involves schematics, circuit diagrams, placement.

• Key Difference: Logical = functions & data; Physical = hardware & wiring.

1.5 IoT Design Methodology & Steps

A typical iterative process:

1. Requirement Analysis: Define use case, stakeholders, KPIs.

2. System Architecture Design: Choose reference model, define planes, select technologies.

3. Hardware/Software Selection: Pick sensors, actuators, MCUs/SBCs, communication modules, cloud platform.

4. Prototyping & Development: Build proof-of-concept, develop firmware/software.

5. Integration & Testing: Integrate components, test functionality, security, performance.

6. Deployment & Monitoring: Field deployment, continuous monitoring, maintenance.

7. Scalability & Optimization: Plan for scale, optimize for cost/power/performance.

1.6 M2M vs. IoT (High Priority)

1.6.1 Definition of M2M

• Machine-to-Machine (M2M): Point-to-point communication between two machines/devices over a network (often cellular or wired). Primarily for remote monitoring and control. Closed, proprietary systems.

• Example: A vending machine sending a signal to a central server when out of stock.

1.6.2 Reasons for Shifting from M2M to IoT

1.6.3 M2M Service Layer Standardization

• Efforts like oneM2M (global standards body) define a common service layer (application layer) to sit on top of existing M2M technologies (e.g., cellular, ZigBee). This layer provides common functions: device management, data formatting, security, and application enablement, allowing interoperability across different underlying networks.

1.6.4 Differences in Data Analytics Approaches

• M2M Analytics: Descriptive & diagnostic. Focuses on "what happened?" and "why?" (e.g., alert reports, simple dashboards). Data is often siloed.

• IoT Analytics: Predictive & prescriptive. Uses Big Data technologies (Hadoop, Spark) and ML to predict failures ("when will it fail?") and prescribe actions ("optimize this process"). Data is aggregated from diverse sources for holistic insights.

2.0 HARDWARE COMPONENTS: SENSORS, ACTUATORS & MICROCONTROLLERS

2.1 Sensors in IoT (High Priority)

2.1.1 Definition, Function & Role

• Definition: A device that detects or measures a physical property (temperature, light, motion, pressure) and converts it into an electrical signal.

• Function: Transduce physical phenomena into quantifiable data.

• Role: The "senses" of an IoT system. They are the primary source of real-world data.

2.1.2 Common Commercially Available IoT Sensors (Comparison)

2.1.3 Sensor Features & Characteristics

Key parameters for selection:

• Accuracy: Closeness to true value.

• Range/Min/Max: Minimum and maximum measurable values.

• Resolution: Smallest detectable change in input.

• Sensitivity: Ratio of output change to input change.

• Linearity: How closely output follows a straight line.

• Response Time: Time to reach a certain percentage of final output.

• Hysteresis: Difference in output for same input depending on direction (increasing vs. decreasing).

• Drift: Change in output over time for constant input.

• Power Consumption: Critical for battery-operated nodes.

2.1.4 Quantization Error (in Sensing)

• Occurs when converting a continuous analog signal (from sensor) to a discrete digital value (ADC).

• The analog range is divided into $$\displaystyle 2^n $$ levels (where $n$ = bits of ADC).

• Quantization Error = $$\displaystyle \pm \frac{1}{2} \text{ LSB} $$ (Least Significant Bit).

• LSB Size (Step Size) = $$\displaystyle \frac{\text{Full Scale Range}}{2^n} $$.

• Example: A 10-bit ADC (1024 levels) with 0-5V range: LSB = 5/1024 ≈ 4.88mV. Max error = ±2.44mV.

2.2 Actuators in IoT (High Priority)

2.2.1 Definition, Function & Role

• Definition: A device that converts an electrical signal (from controller) into physical action (movement, force, switch).

• Function: Act upon the environment based on control signals.

• Role: The "muscles" of an IoT system. They close the loop from sensing to action.

2.2.2 Types of Actuators

1. Electrical: Motors (DC, Stepper, Servo), Solenoids, Relays, Heaters, LEDs.

2. Mechanical: Gears, linkages, cams (often driven by electrical motors).

3. Pneumatic: Use compressed air/gas. Example: Air cylinders for pushing/pulling.

4. Hydraulic: Use pressurized fluid (oil/water). High force, used in heavy machinery.

5. Soft Actuators: Made from flexible materials (silicone, rubber). Inflate/deflate or change shape with air/fluid. Safe for human interaction.

6. Shape Memory Polymer (SMP) Based: Change shape in response to temperature/light/electrical stimulus. Can return to original shape. Used in biomedical devices, morphing structures.

2.2.3 Four Common Characteristics for Actuator Selection

1. Force/Torque & Stroke/Displacement: The mechanical output capability.

2. Speed & Response Time: How fast it can move/act.

3. Precision & Accuracy: Repeatability and correctness of position/force.

4. Operating Environment & Power Source: Temperature, humidity, explosion risk; available power (voltage, current, air pressure).

2.2.4 Comparison of Actuator Types

2.3 Microcontrollers & Single-Board Computers (High Priority)

2.3.1 Review of Basic Microcontrollers & Interfacing

• Microcontroller (MCU): A single IC containing CPU, memory (RAM/ROM), and I/O peripherals (GPIO, ADC, UART, SPI, I2C). Low-cost, low-power, real-time.

• Interfacing: Connecting sensors/actuators to MCU pins. Common methods:

  • Digital I/O (GPIO): Read/write HIGH/LOW. For buttons, LEDs, relays.

  • Analog-to-Digital Converter (ADC): Read analog sensor voltage (0-Vref).

  • Pulse Width Modulation (PWM): Simulate analog output (e.g., motor speed, LED dimming).

  • Serial Protocols: UART (simple serial), SPI (fast, master-slave), I2C (multi-master, addressable).

2.3.2 Raspberry Pi (Architecture, GPIO, SPI, I2C interfaces, Differences from Desktop Computers)

• Architecture: Single-Board Computer (SBC). Uses a System-on-Chip (SoC) (e.g., Broadcom BCM2711) integrating CPU (ARM cores), GPU, RAM, and peripherals. Runs a full OS (Linux/Raspbian).

• GPIO (General Purpose Input/Output): 40-pin header. Pins can be programmed as digital input/output. Some have PWM, I2C, SPI, UART functions multiplexed.

• SPI (Serial Peripheral Interface): Full-duplex, 4-wire (MOSI, MISO, SCLK, CS). Master (Pi) controls multiple slaves. Fast, simple protocol.

• I2C (Inter-Integrated Circuit): Half-duplex, 2-wire (SDA, SCL). Multi-master, multi-slave using 7-bit addresses. Slower than SPI but uses fewer wires.

• Differences from Desktop Computer:

  | Feature | Raspberry Pi | Typical Desktop | | :--- | :--- | :--- | | Form Factor | Single, compact board | Multiple large components | | CPU | ARM (RISC), low-power | x86/AMD64 (CISC), high-power | | OS | Linux (embedded) | Windows/Linux (full) | | Storage | SD card / eMMC | HDD/SSD (SATA/NVMe) | | I/O | Rich GPIO, USB, HDMI | Limited GPIO (via ports), USB | | Cost & Power | Low cost ($35-$75), low power (2-7W) | High cost, high power (65W+) |

2.3.3 Arduino (Applications & Benefits)

• What: A family of microcontroller boards (ATmega, SAMD, etc.) with simple IDE.

• Benefits:

  • Easy to use: Simple C++-based IDE, vast community.

  • Real-time: No OS overhead, deterministic timing.

  • Low cost & power: Ideal for battery-operated nodes.

  • Huge shield ecosystem: Easy expansion for specific functions (Ethernet, GSM, motor drivers).

• Applications: Prototyping, standalone embedded projects, sensor nodes, real-time control where cloud connectivity is not primary.

2.3.4 Role in IoT System Design (e.g., Smart Home)

• Arduino/MCU: Often used at the edge/node level for direct sensor/actuator interfacing due to low power, real-time response, and cost. Acts as a "dumb" data collector/actuator.

• Raspberry Pi/SBC: Used as an edge gateway/hub. Aggregates data from multiple MCU nodes, performs local processing/analytics, handles protocol translation (e.g., ZigBee/Z-Wave to Wi-Fi/Ethernet), and connects to the cloud. Provides more processing power for complex tasks.

• Smart Home Example: Arduino + DHT22 (temp/humidity) → (via I2C/UART) → Raspberry Pi (gateway) → (via MQTT over Wi-Fi) → Cloud Platform → User Mobile App.

3.0 COMMUNICATION TECHNOLOGIES & PROTOCOLS

3.1 IoT Communication Models & Network Types

3.1.1 Various IoT Communication Models

1. Device-to-Device (D2D): Direct communication between IoT devices (e.g., Bluetooth, ZigBee). No gateway.

2. Device-to-Gateway: Device connects to a local gateway (e.g., sensor → Arduino → Raspberry Pi). Gateway handles protocol translation.

3. Device-to-Cloud: Device connects directly to cloud server (e.g., Wi-Fi/Ethernet sensor → AWS IoT). Simplest but less secure/power-efficient.

4. Back-End-Data-Sharing: Cloud-to-cloud API integration (e.g., AWS IoT data shared with Salesforce).

5. Device-to-Device-to-Cloud: Hybrid. Devices form mesh (D2D) and a gateway connects to cloud.

3.1.2 Network Classification based on Physical Topologies & Connection Types

3.1.3 Issues in IoT LAN Development & Implementation

• Interference & Congestion: Wi-Fi (2.4GHz) crowded with other devices.

• Power Constraints: Many devices battery-powered; Wi-Fi is power-hungry.

• Scalability: Number of devices per access point limit.

• Security: Open nature of Wi-Fi; need for strong encryption (WPA3).

• Coverage Gaps: Dead zones in large buildings.

• Protocol Diversity: Need to support multiple protocols (Wi-Fi, BLE, ZigBee) via gateway.

3.2 Short-Range & Wireless Personal Area Networks (WPAN) (High Priority)

3.2.1 IEEE 802.15.4 Protocol

• Standard: Defines physical (PHY) and medium access control (MAC) layers for low-rate, low-power, low-cost wireless networks.

• Relation to IoT: It is the foundational standard for many IoT protocols (ZigBee, 6LoWPAN, WirelessHART, Thread). Provides the basic radio and channel access rules.

• Key Features: Supports star and peer-to-peer topologies, 250 kbps max rate (2.4GHz), 16 channels, CSMA/CA, optional beacon-enabled mode.

3.2.2 ZigBee (Architecture, Types, Stack, Relation to 802.15.4)

• Architecture:

  • ZigBee Coordinator (ZC): Forms network, stores network info, may be gateway.

  • ZigBee Router (ZR): Extends network range, can route data, may be mains-powered.

  • ZigBee End Device (ZED): Leaf node, low-power, talks only to parent (ZC/ZR), sleeps.

  • DiagramCANVAS: Star/Cluster-tree/Mesh topology with ZC, ZRs, ZEDs

• Stack: Built on IEEE 802.15.4 (PHY/MAC). Adds:

  • Network (NWK) Layer: Routing, addressing.

  • Application (APL) Layer: Includes Application Framework, ZigBee Device Objects (ZDO) for device/service discovery, and Application Objects (vendor-specific).

• Relation to 802.15.4: ZigBee uses 802.15.4 as its PHY/MAC. ZigBee adds network layer and application layer for full stack.

3.2.3 Wireless Sensor Networks (WSN)

• Definition: A network of spatially distributed autonomous sensors to monitor physical/environmental conditions and cooperatively pass data to a central location.

• Relation to IoT: WSN is a key data source and enabling technology for IoT. IoT often uses WSN infrastructure but adds Internet connectivity, cloud integration, and broader applications.

• Applications: Environmental monitoring (forest, agriculture), structural health monitoring, smart metering, military surveillance.

3.2.4 6LoWPAN (Functionality, Adaptation of IPv6, Differences from IPv4/IPv6)

• Functionality: IPv6 over Low-Power Wireless Personal Area Networks. An adaptation layer that allows IPv6 packets to be carried efficiently over IEEE 802.15.4 networks.

• Adaptation of IPv6:

  1. Header Compression: IPv6 header (40 bytes) is compressed to fit within 802.15.4's max frame (127 bytes). Context-based compression.

  2. Fragmentation & Reassembly: IPv6 MTU (1280 bytes) >> 802.15.4 max payload (~102 bytes). 6LoWPAN handles fragmentation at adaptation layer.

  3. Mesh Addressing: Supports mesh routing under IPv6.

• Differences from IPv4/IPv6:

  • vs. IPv4: 6LoWPAN uses IPv6's vast address space (critical for billions of IoT devices). IPv4 address exhaustion is a key driver.

  • vs. Native IPv6: 6LoWPAN is not a new IP version. It's a compression/adaptation layer for constrained links. Native IPv6 packets are too large for 802.15.4.

3.3 Identification & Perception Technologies

3.3.1 RFID (Principles, Features, Components, Link with IoT, Terminology)

• Principles: Uses electromagnetic fields to automatically identify and track tags attached to objects. Tags contain electronically stored information.

• Components:

  • Tag: Microchip + antenna. Passive (no battery, powered by reader's signal), Active (battery-powered), Semi-passive.

  • Reader: Transmits RF signal, receives tag response.

  • Antenna: On reader and tag.

  • Middleware/Backend System: Processes data, integrates with applications.

• Features: Non-line-of-sight reading, unique ID, fast, durable.

• Link with IoT: RFID provides automatic identification and data capture (AIDC), feeding real-time location/identity data into IoT systems (supply chain, inventory, access control).

• Terminology: EPC (Electronic Product Code), RFID Frequency Bands (LF 125-134kHz, HF 13.56MHz, UHF 860-960MHz), Read Range, Writeable/Read-Only.

3.3.2 Near Field Communication (NFC)

• Definition: A set of short-range (≤10 cm) wireless communication standards based on RFID (ISO/IEC 14443). Enables two-way communication.

• Technologies: Operates at 13.56 MHz. Modes: Reader/Writer, Peer-to-Peer, Card Emulation (phone as smart card).

• Applications:

  • Contactless payments (Apple Pay, Google Pay).

  • Access control (door locks).

  • Data exchange (sharing contacts, URLs).

  • IoT configuration (tap-to-pair devices).

3.4 Application Layer Protocols for IoT (Very High Priority)

3.4.1 MQTT (Message Queuing Telemetry Transport)

• Protocol Operations: Publish/Subscribe model.

  • Client: Any device/app.

  • Broker: Central server.

  • Topic: Hierarchical string (e.g., home/livingroom/temp).

  • Client publishes message to a topic. Broker forwards to all clients subscribed to that topic.

  • QoS Levels: 0 (At most once), 1 (At least once), 2 (Exactly once).

• Role in IoT: Lightweight (small header, minimal overhead), asynchronous, bandwidth-efficient, ideal for high-latency/unreliable networks. Decouples producers and consumers.

• Use with WebSockets: MQTT can be transported over WebSockets (TCP-based, full-duplex) to enable browser-based MQTT clients (JavaScript) for web dashboards.

3.4.2 CoAP (Constrained Application Protocol)

• Basic Operations: Request-Response model, similar to HTTP but optimized for constrained devices.

  • Methods: GET, POST, PUT, DELETE.

  • Uses UDP (not TCP) for low overhead.

  • Confirmable (CON) and Non-Confirmable (NON) messages for reliability.

• Use in Constrained Networks: Justification:

  • Small header (4 bytes vs. HTTP's ~20+ bytes).

  • UDP-based: No connection setup overhead.

  • Built-in discovery (/.well-known/core).

  • RESTful design, easy to map to HTTP.

• Relation to HTTP/REST: CoAP is a constrained-node RESTful protocol. Can be proxied to HTTP for web integration. Uses similar semantics (GET resource, PUT to update).

3.4.3 AMQP (Advanced Message Queuing Protocol)

• Features & Components:

  • Wire-level protocol for message orientation, queuing, routing.

  • Components: Publisher, Exchange (routes messages), Queue, Consumer.

  • Exchange Types: direct, fanout, topic, headers.

• Message Attributes & Payload:

  • Payload: Application data (binary).

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

• Frame Types: Protocol frames for methods, content, headers, heartbeats.

3.4.4 XMPP (Extensible Messaging and Presence Protocol) & IoT Service Improvement

• Definition: XML-based protocol for real-time messaging, presence, and request-response services.

• Improves IoT Services by:

  • Decentralized Architecture: No central broker needed (peer-to-peer possible).

  • Built-in Presence: Know if a device is online/offline.

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

  • Security: Native TLS and SASL.

  • Bidirectional Communication: Persistent TCP connection, ideal for control.

3.4.5 SMQTT (Secure MQTT)

• Secure MQTT is not a separate protocol but a security extension for MQTT.

• Secure Message Transfer Mechanism:

  • Uses TLS/SSL for encrypting the entire MQTT connection (port 8883).

  • Provides confidentiality (encryption), integrity (MAC), and authentication (client certificates).

  • Can also use MQTT over WebSockets with TLS (wss://).

  • Addresses MQTT's lack of built-in security.

3.4.6 WebSockets (Role in IoT Communication)

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

• Role in IoT:

  • Enables real-time, bidirectional communication from web browsers to IoT backends.

  • Used to push sensor data/notifications to web dashboards without polling.

  • Can transport other protocols like MQTT or raw JSON.

  • Overcomes HTTP's request-response limitation for live updates.

3.5 IoT Gateways & Ecosystem Functionality

3.5.1 Functionality of IoT Gateways

• Protocol Translation: Converts between device protocols (ZigBee, BLE, Modbus) and Internet protocols (MQTT, HTTP, CoAP).

• Data Filtering & Aggregation: Pre-processes data at the edge, reduces cloud traffic.

• Security: Acts as a firewall, performs device authentication, encrypts data.

• Device Management: Onboarding, configuration, firmware updates for local devices.

• Edge Computing/Offline Operation: Runs local logic/analytics, operates during cloud outage.

• Connectivity: Provides multiple network interfaces (Ethernet, Wi-Fi, Cellular).

3.5.2 How the IoT Ecosystem Works (End-to-end flow)

1. Sensing/Actuation: Sensors collect data, actuators perform actions.

2. Edge Node: MCU/SBC (e.g., Arduino) reads sensor, may do local control.

3. Gateway: Receives data from edge nodes (via ZigBee/RS-485), translates to MQTT/HTTP, sends to cloud. Receives commands from cloud, translates back.

4. Cloud Platform: Ingests data (via MQTT broker/HTTP endpoint), stores (database), processes (analytics engine), manages devices.

5. Application: Web/mobile app subscribes to cloud data (via APIs/WebSockets), displays dashboards, sends user commands.

6. Command Flow: App → Cloud → Gateway → Edge Node → Actuator.

4.0 DATA MANAGEMENT, ANALYTICS & CLOUD INTEGRATION

4.1 IoT Data & Analytics (High Priority)

4.1.1 IoT Analytics Definition & Role of Things/Internet

• Definition: Process of analyzing high-volume, high-velocity, high-variety IoT data to extract meaningful insights, patterns, and knowledge for decision-making.

• Role of Things: Generate raw data streams (sensor readings, events).

• Role of Internet: Provides the connectivity to transport this data to centralized or distributed processing locations (cloud/edge).

4.1.2 Role of Data Analytics in IoT

• Descriptive: "What happened?" (Dashboards, reports).

• Diagnostic: "Why did it happen?" (Root cause analysis).

• Predictive: "What will happen?" (Failure prediction, demand forecasting using ML).

• Prescriptive: "What should we do?" (Optimization, automated decisions).

4.1.3 Edge Streaming Analytics vs. Regular/Cloud Analytics (Advantages of Edge)

• Edge Streaming Analytics: Processing data at or near the source (gateway, device).

  • Advantages:

    • Low Latency: Immediate response (critical for control).

    • Bandwidth Reduction: Only send alerts/aggregates to cloud.

    • Privacy/Security: Sensitive data stays local.

    • Offline Operation: Works without cloud connectivity.

• Cloud Analytics: Centralized processing of all raw data.

  • Advantages: Massive compute/storage, complex ML models, historical data correlation, global view.

4.1.4 Big Data Technologies: Hadoop Ecosystem in IoT Context

• Hadoop Core: HDFS (distributed storage), MapReduce (parallel processing).

• IoT Context Use:

  • HDFS: Stores massive historical IoT sensor data cheaply.

  • MapReduce/YARN: Batch processes historical data for long-term trends, training ML models.

  • Spark: Faster in-memory processing for near-real-time analytics on IoT streams (using Spark Streaming).

  • Hive: SQL-like queries on HDFS data.

  • Kafka: Ingests high-velocity IoT streams into Hadoop ecosystem.

4.2 Cloud Computing for IoT

4.2.1 Usefulness of Cloud for IoT

• Scalability: Elastic resources for millions of devices.

• Cost-Effective: Pay-per-use, no upfront infrastructure.

• Managed Services: Databases, analytics engines, AI tools ready-to-use.

• Global Reach: Data centers worldwide for low-latency access.

• Device Management: Built-in tools for onboarding, monitoring, updating fleets.

4.2.2 Cloud Service Models (IaaS, PaaS, SaaS) in IoT

4.2.3 Cloud Communication APIs for IoT

• RESTful HTTP/HTTPS APIs: For device registration, data retrieval, command sending. Simple, firewall-friendly.

• MQTT over TCP/TLS: Primary protocol for device-to-cloud telemetry. Lightweight, persistent.

• CoAP over UDP: For constrained devices, often proxied to HTTP in cloud.

• WebSockets: For real-time browser-to-cloud dashboards.

• Provider-Specific SDKs: AWS IoT Device SDK, Azure IoT SDKs (in C, Python, JS) that handle MQTT/HTTPS with cloud-specific authentication (X.509, SAS tokens).

4.2.4 Challenges in Cloud-IoT Integration (Example-based)

• Latency: Cloud round-trip (100ms-1s) unsuitable for real-time control. Example: Industrial robot arm control.

• Bandwidth Costs: Sending all raw sensor data to cloud is expensive. Example: Thousands of high-res video cameras.

• Security & Privacy: Data in transit and at rest in cloud; compliance (GDPR). Example: Health data from wearables.

• Vendor Lock-in: Difficulty migrating between cloud providers due to proprietary services/APIs.

• Intermittent Connectivity: Field sites with poor internet. Example: Remote oil pipeline sensors.

5.0 SECURITY & PRIVACY IN IoT

5.1 Why Security is Required in IoT? (Threat Landscape)

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

• Physical Access: Devices deployed in public/unsecured locations.

• Critical Impact: Attacks can cause physical harm (medical devices, industrial control), safety risks (cars, locks), financial loss, privacy violation.

• Botnets: Compromised IoT devices used for DDoS attacks (e.g., Mirai botnet).

• Data Sensitivity: IoT collects intimate data (home habits, health, location).

5.2 Various IoT Security Models

• Perimeter-Based Security: Traditional firewall/VPN. Inadequate for IoT where devices are the perimeter.

• Zero-Trust Model: "Never trust, always verify." Every device/user must authenticate and be authorized for each access request, regardless of location.

• Device-Centric Security: Security built into device hardware (Secure Boot, TPM/SE, hardware encryption).

• Layered Security (Defense-in-Depth): Multiple security layers (device, network, cloud, application) so failure of one doesn't compromise all.

5.3 Vulnerabilities & Attacks on IoT Systems (High Priority)

5.3.1 General IoT Vulnerabilities

• Hardcoded/default passwords.

• Lack of secure update mechanism.

• Insecure network services (open ports).

• Unencrypted communication.

• Insecure web/mobile interfaces.

• Poor physical security.

5.3.2 Attacks on Application/Service Layer (Specifics)

• Man-in-the-Middle (MitM): Intercepting/altering communication between device and cloud/app.

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

• Denial-of-Service (DoS/DDoS): Overwhelming device or cloud service.

• Injection Attacks: SQLi, command injection via web interfaces or APIs.

• Session Hijacking: Stealing session tokens to impersonate a legitimate user/device.

5.3.3 Different Types of Attacks (DoS, etc.)

• Physical Attacks: Tampering, side-channel attacks (power analysis).

• Network Attacks: Sniffing, spoofing, jamming (radio), routing attacks (in WSN).

• Protocol Attacks: Exploiting weaknesses in protocols (e.g., fragmentation attacks in 6LoWPAN).

• Software Attacks: Malware, ransomware on gateway/cloud.

• Privacy Attacks: Traffic analysis, location tracking from device data.

5.4 Security & Privacy Issues in IoT Systems

• Authentication: Strong device/user authentication (certificates, tokens).

• Authorization: Fine-grained access control (what device can do what).

• Confidentiality: Encryption of data in transit (TLS/DTLS) and at rest.

• Integrity: Ensuring data isn't tampered (digital signatures, MACs).

• Privacy: Data minimization, anonymization, user consent, compliance (GDPR, CCPA).

• Resilience: Ability to withstand attacks and recover.

5.5 Security in Specific Protocols (e.g., SMQTT)

• SMQTT: Uses TLS/SSL for encrypting the MQTT connection. Also uses MQTT over WebSockets with TLS (wss://).

• Mechanism:

  1. Handshake: Client and broker establish TLS session (certificate exchange, key negotiation).

  2. Encrypted Channel: All MQTT packets (CONNECT, PUBLISH, SUBSCRIBE) are encrypted within the TLS tunnel.

  3. Authentication: MQTT can use TLS client certificates for mutual authentication, or username/password within the encrypted channel.

• Other Protocols:

  • CoAP: Uses DTLS (Datagram TLS) for security over UDP.

  • HTTPS: Standard TLS for HTTP-based IoT APIs.

  • ZigBee: Uses AES-128 encryption at MAC layer, network/application layer keys.

6.0 IOT PLATFORMS, ENABLERS & APPLICATIONS

6.1 IoT Platforms (General features, examples, role)

• General Features: Device management (onboarding, monitoring, OTA updates), data ingestion (MQTT/HTTP broker), data storage, analytics engine, rule engine, visualization dashboards, API management, security (auth, encryption).

• Examples:

  • Cloud Platforms: AWS IoT Core, Microsoft Azure IoT Hub, Google Cloud IoT Core.

  • Enterprise Platforms: IBM Watson IoT Platform, SAP IoT, PTC ThingWorx.

  • Open Source: Eclipse Kura, ThingsBoard.

• Role: Provide middleware that abstracts infrastructure complexity, enabling developers to focus on application logic and device integration.

6.2 IoT Enablers (Comprehensive list & role)

Technologies that make IoT possible:

1. Sensors & Actuators: Physical interface.

2. Connectivity & Networks: Wi-Fi, Bluetooth, ZigBee, LoRaWAN, Cellular (4G/5G, NB-IoT).

3. Cloud Computing: Scalable backend.

4. Big Data & Analytics: Hadoop, Spark, Stream processing.

5. Machine Learning & AI: Predictive models, anomaly detection.

6. IPv6: Vast address space for devices.

7. RFID & NFC: Identification and proximity.

8. Semantic Web & Ontologies: Machine-understandable data (RDF, OWL).

9. Blockchain: Secure, decentralized transactions/identity.

10. Edge/Fog Computing: Local processing.

11. SDN/NFV: Network programmability and virtualization.

6.3 Application Domains & Case Studies (High Priority)

6.3.1 Smart Home (Design with Raspberry Pi & hardware, Neat sketch, Applications)

• Design:

  • Hub/Gateway: Raspberry Pi 4 running Home Assistant/OpenHAB or custom Python app.

  • Sensors: DHT22 (temp/humidity), PIR (motion), LDR (light), MQ-2 (gas), door/window magnetic switches.

  • Actuators: Relays (for lights/fans), servo motors (locks), IR LEDs (TV control).

  • Communication: Sensors → Arduino (via I2C/UART) → Pi (via USB/Serial) OR sensors → Pi directly (GPIO/SPI/I2C). Pi → Cloud (MQTT over Wi-Fi).

  • User Interface: Mobile app (React Native) or web dashboard (Grafana) accessing cloud API.

• DiagramCANVAS: Smart Home Block Diagram

  
  [Sensors/Actuators] --> [Arduino/MCU Nodes] --> [Raspberry Pi Gateway] --> [Wi-Fi Router] --> [Cloud Platform (MQTT Broker)] --> [Mobile App / Web Dashboard]
  
  

• Applications: Automated lighting/climate, security monitoring, energy management, appliance control.

6.3.2 Smart Parking Architecture

1. Sensors: Ultrasonic/IR sensors in each parking slot to detect occupancy.

2. Edge Nodes: Low-power MCUs (e.g., ESP32) per zone, collect sensor data, use LoRa/Wi-Fi.

3. Gateway: Aggregates zone data, sends to cloud via 4G/Ethernet.

4. Cloud Platform: Stores real-time occupancy map, runs availability prediction.

5. Application: Mobile app/display boards show real-time available slots, allows reservation, payment integration.

6.3.3 Smart Traffic Control

• Sensors: Inductive loops, cameras (video analytics), radar, GPS from vehicles.

• Edge: Traffic signal controllers with MCUs, video analytics at camera edge.

• Gateway/Cloud: Central traffic management system analyzes flow, predicts congestion.

• Actuation: Dynamically adjust signal timing, display variable message signs, route navigation apps.

• Goal: Reduce wait times, fuel consumption, emissions.

6.3.4 Smart Lighting

• Sensors: Ambient light (LDR), occupancy (PIR), daylight harvesting.

• Actuators: LED drivers with dimming (PWM) and on/off (relay).

• Control: Individual or grouped via wireless (ZigBee, Bluetooth Mesh, Wi-Fi).

• Cloud: Schedule, occupancy-based automation, energy consumption reporting.

• Benefits: Energy savings (50-70%), increased lamp life, remote monitoring.

6.3.5 Home Automation Systems

• Core: Centralized control of lighting, HVAC, entertainment, security, appliances.

• Tech: Mix of protocols (ZigBee, Z-Wave, Wi-Fi, Bluetooth) managed by hub (SmartThings, HomePod, custom Pi).

• Automation Rules: "If motion detected after sunset, turn on light."

• Voice Control: Integration with Alexa/Google Assistant.

• Remote Access: Secure cloud connection for away control.

6.3.6 Detailed Case Study Discussion (Example: Smart Agriculture)

• Problem: Inefficient water/fertilizer use, low crop yield monitoring.

• Solution:

  • Sensors: Soil moisture, temperature, humidity, NPK sensors.

  • Network: LoRaWAN for long-range, low-power field coverage. Nodes transmit hourly/daily.

  • Gateway: LoRaWAN gateway (Raspberry Pi + LoRa HAT) forwards data to cloud.

  • Cloud: Stores data, runs analytics (crop water requirement models), triggers alerts.

  • Actuation: Automatically open/close irrigation valves based on soil moisture.

  • App: Farmer dashboard shows field status, recommendations, historical trends.

• Benefits: 20-30% water saving, increased yield, reduced labor.

6.4 Software Defined Networking (SDN) in IoT Context (Maturity, Justification)

• What: Separates control plane (decides where traffic goes) from data plane (forwards traffic). Centralized SDN Controller programs network devices (switches/routers).

• Justification for IoT:

  • Dynamic Management: Easily reconfigure network for different IoT traffic patterns (e.g., bulk sensor upload vs. real-time control).

  • Security: Centralized policy enforcement (firewall rules per device type).

  • Scalability: Simplified management of large, flat IoT networks.

  • QoS: Prioritize critical control traffic over bulk telemetry.

• Maturity: Maturing. Widely used in data centers, telecom. IoT-specific SDN (e.g., for LPWAN, 6LoWPAN) is in research/early adoption due to resource constraints of IoT devices and need for lightweight southbound APIs (e.g., COAP-based instead of OpenFlow). Not yet mainstream in large-scale IoT deployments.

7.0 CROSS-CUTTING & ADVANCED TOPICS

7.1 Challenges & Requirements of IoT Devices (High Priority)

7.2 Structured vs. Unstructured Data in IoT Context

7.3 Machine Learning Role in Internet of Things

• At Edge (TinyML): Run inference on device.

  • Use Cases: Keyword spotting (voice), anomaly detection (vibration), image classification (camera).

  • Benefits: Low latency, privacy, bandwidth saving.

• At Gateway/Edge Server: More complex models.

  • Use Cases: Predictive maintenance (aggregated sensor data), local video analytics.

• In Cloud: Training large models on massive historical data.

  • Use Cases: Demand forecasting, customer behavior analysis, optimizing city-wide systems.

• Key Role: Transform raw IoT data into actionable intelligence (predict, prescribe, automate).

7.4 Pneumatic Actuators (Specific mention in exams)

• Definition: Actuators that use compressed air or gas to produce mechanical motion (linear or rotary).

• Principle: Air pressure applied to a piston or vane creates force.

• Components: Compressor (air source), valves (control direction/pressure), actuator cylinder/motor.

• Characteristics:

  • Advantages: Low cost, simple, safe (no spark, works in explosive environments), high force-to-weight ratio, easy speed/torque control via pressure.

  • Disadvantages: Requires air supply/compressor (not self-contained), slower response than electric, less precise, can leak, noisy.

• IoT Applications: Industrial automation (assembly lines), robotics (grippers), vehicle brakes (trucks), medical devices (ventilators). Often controlled by IoT system via solenoid valves.