UNIT 2 - INTERNET OF THINGS (CE-703 A) - EXAM-FOCUSED NOTES

Based on rigorous analysis of RGPV past papers (2022-2025). Only topics from UNIT 2 are included.

1.0 IoT FUNDAMENTALS & ECOSYSTEM (High Frequency)

1.1 IoT Definition & Core Concept

• IoT Definition: A system of interrelated computing devices, mechanical/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.

• Core Concept: The synergy of "Things" (physical objects with sensors/actuators) and the "Internet" (connectivity infrastructure) enabling data analytics for intelligent decision-making.

• IoT Analytics: Process of examining raw data from connected devices to discover trends, answer questions, and draw conclusions. Essential for deriving value from IoT deployments.

1.2 M2M vs. IoT

[!TIP] Exam Key: M2M is a subset/enabler of IoT. The shift is from isolated telemetry to connected intelligence.

1.3 IoT Ecosystem & Functional View

• Components/Stakeholders:

  • Things/Devices: Sensors, actuators, embedded systems.

  • Connectivity: Networks (WPAN, WAN), protocols, gateways.

  • Platforms: IoT platforms (cloud/edge) for device management, data ingestion, analytics.

  • Applications: End-user services (smart home apps, industrial dashboards).

  • Analytics & Business Intelligence: Tools to derive insights.

  • Security:贯穿所有层的安全机制。

• Complex Interdependencies: Changes in one layer (e.g., new sensor type) impact device management, data formats, application logic, and security policies.

1.4 IoT Architectural Frameworks

1.4.1 IoT Reference Architecture (Layered)

Common 5-layer model:

1. Perception Layer: Physical sensors/actuators. Data acquisition from environment.

2. Network Layer: Transmits data from perception layer to processing systems. Uses WPAN (ZigBee, BLE), WAN (Cellular, LoRaWAN), Ethernet.

3. Service Layer / Middleware: Core processing. Device management, data storage, analytics engine. Provides APIs to applications. Often implemented in Cloud/Edge.

4. Application Layer: User-facing applications. Specific use-cases (smart agriculture, health monitoring).

5. Management Layer: Cross-cutting. Security, privacy, device lifecycle management, QoS management.

1.4.2 IoT Planes

• Functional Plane: Defines what functions each component performs (sensing, communication, processing).

• Information Plane: Defines how data is represented, stored, and flows (data models, formats).

• Communication Plane: Defines how components connect (protocols, network topologies).

• Business Plane: Defines why – business models, stakeholders, value propositions.

• Management Plane: Defines control – security, configuration, monitoring.

1.4.3 IoT Levels/System Types

[!TIP] Exam Focus: Level 3 & 4 are most asked. Be ready to draw and explain with examples. Level 3 = "Constrained device network + Gateway". Level 4 = "System of systems".

1.4.4 Service-Oriented Architecture (SOA) for IoT

• Principle: Expose IoT capabilities (sensor data, actuator control) as loosely-coupled, reusable services.

• Components:

  • Service Provider: Device/gateway exposing functionality (e.g., getTemperature()).

  • Service Broker/Registry: Directory where services are published/discovered.

  • Service Consumer: Application that uses the service.

• Challenges: Resource constraints on devices, service discovery in dynamic networks, security of service interfaces, interoperability standards.

1.4.5 Logical vs. Physical Design of IoT

[!TIP] Common Pitfall: Students often confuse these. Remember: Logical = "What & How it communicates", Physical = "What chips & wires".

2.0 IoT DEVICES & HARDWARE PLATFORMS (Very High Frequency)

2.1 Sensors & Sensing

2.1.1 Sensor Types & Characteristics

• Common IoT Sensors:

  • Environmental: Temperature (DHT22, DS18B20), Humidity, Pressure (BMP280), Gas (MQ series), Air Quality (PMS5003).

  • Motion/Proximity: PIR (Passive Infrared), Accelerometer (MPU6050), Gyroscope, Ultrasonic (HC-SR04).

  • Positioning: GPS (Neo-6M), RFID reader.

  • Optical: Camera (Raspberry Pi Camera), Light (BH1750).

• Selection Characteristics:

  • Accuracy & Precision, Range, Resolution, Response Time, Power Consumption, Size/Form Factor, Cost, Interface (Analog, Digital, I2C, SPI), Environmental Robustness.

2.1.2 Sensor Interface & Signal Conditioning

• Analog vs. Digital Sensors: Analog outputs continuous voltage/current; Digital outputs discrete values (I2C, SPI, UART).

• Quantization Error: Error introduced during Analog-to-Digital Conversion (ADC). The continuous analog signal is approximated by discrete digital levels.

$$ \text{Quantization Error} = \pm \frac{1}{2} \text{ LSB} $$

Where **LSB (Least Significant Bit)** = $$\displaystyle \frac{\text{Full Scale Range}}{2^n} $$, `n` = ADC resolution (bits).

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

2.2 Actuators

2.2.1 Actuator Types

2.2.2 Selection Characteristics (Four Key)

1. Force/Torque: Output mechanical strength required.

2. Stroke/Displacement: Distance or angle of movement needed.

3. Response Time: How fast it activates/deactivates (critical for control loops).

4. Power Consumption: Especially vital for battery-powered edge devices.

2.3 Microcontrollers & Interfacing

2.3.1 Review of Basic Microcontrollers

• Arduino (Uno/Nano): ATmega328P, 5V, 32KB Flash, easy IDE. Good for prototyping.

• ESP32: Dual-core 32-bit, Wi-Fi & Bluetooth built-in, 520KB SRAM, 16MB Flash. Dominant in IoT due to connectivity.

• Raspberry Pi (See 2.4): Not a microcontroller; a microprocessor (full OS).

2.3.2 Interfacing Concepts (Communication Protocols)

[!TIP] Memory Aid: I2C = "I want 2 communicate" (2 wires). SPI = "Serial Peripheral Interface" (fast, separate lines for in/out).

2.4 Edge/Compute Platforms

2.4.1 Raspberry Pi vs. Desktop Computer

• Raspberry Pi Interfaces:

  • GPIO: Digital I/O, PWM, SPI, I2C, UART.

  • SPI/I2C: On the GPIO header for connecting sensors/expanders.

  • USB: For peripherals (camera, modem, storage).

  • Ethernet/Wi-Fi/BT: Network connectivity.

2.4.2 IoT Gateway Functionality

• Role: Bridge between constrained device networks (ZigBee, BLE, Z-Wave) and the IP-based internet/cloud.

• Key Functions:

  1. Protocol Translation: e.g., ZigBee ↔ MQTT over Wi-Fi/Ethernet.

  2. Data Aggregation & Filtering: Collects data from multiple devices, pre-processes, reduces cloud traffic.

  3. Local Processing/Edge Analytics: Runs logic locally (if-then rules), reduces latency.

  4. Device Management: Onboarding, configuration, security enforcement for attached devices.

  5. Security: Acts as a firewall, provides secure tunnel to cloud.

2.5 IoT Device Challenges & Requirements

3.0 COMMUNICATION & NETWORKING TECHNOLOGIES (Very High Frequency)

3.1 Wireless Personal Area Networks (WPAN) & IoT

3.1.1 IEEE 802.15.4

• Standard: Defines PHY (Physical) and MAC (Medium Access Control) layers for low-rate, low-power, low-cost wireless networks.

• Relation to IoT: Foundation for ZigBee, 6LoWPAN, Thread. Provides the basic radio link (2.4 GHz ISM band, 915 MHz, 868 MHz).

• Key Features: Star/peer-to-peer topologies, CSMA/CA, support for beacon-enabled and non-beacon modes.

3.1.2 ZigBee

• Architecture (Layered):

  • Physical/MAC: Based on IEEE 802.15.4.

  • Network (NWK): Defines topologies (star, tree, mesh), routing (AODV), device roles.

  • Application (APL): Defines device types and application objects.

• Device Types:

  • Coordinator (ZC): Forms network, stores network info, often a gateway.

  • Router (ZR): Can route traffic, extend network, may be mains-powered.

  • End Device (ZED): Can only talk to parent (Router/Coordinator), sleeps to save power. Most common in sensor networks.

• ZigBee Types:

  • ZigBee PRO (ZigBee 2007/Pro): Most common. For mesh sensor/control networks (lighting, home automation).

  • ZigBee IP: Uses IPv6 and 6LoWPAN. For IP-based applications.

  • ZigBee RF4CE: For consumer electronics (remote controls).

• Features: Low power, large network size (65k+ nodes), self-healing mesh, low data rate (250 kbps @ 2.4GHz).

3.1.3 6LoWPAN (IPv6 over Low-Power WPAN)

• Role in IoT: Adaptation layer that allows IPv6 packets to be carried efficiently over IEEE 802.15.4 networks (which have small MTU ~127 bytes).

• Key Mechanism: Header Compression (RFC 6282) and Fragmentation/Reassembly of IPv6 packets to fit 802.15.4 frames.

• Difference from IPv4/IPv6:

  • Not a new IP version. It's a how-to for running standard IPv6 on constrained links.

  • IPv6 is mandatory for IoT scale (vast address space). 6LoWPAN makes it feasible on low-power networks.

  • IPv4 address exhaustion and overhead make it unsuitable for IoT.

3.2 Wireless Sensor Networks (WSN)

3.2.1 WSN vs. IoT

3.2.2 WSN Architecture & Applications

• Node Structure: Sensor + MCU + Radio + Power. Often multi-hop.

• Topologies: Star (single-hop to sink), Tree, Mesh (most common for reliability).

• Applications: Environmental monitoring (forest, agriculture), structural health (bridge), industrial (machine monitoring), smart home.

3.3 Network Classification

3.4 IoT Communication Models

1. Device-to-Device (D2D): Direct communication (e.g., Bluetooth, ZigBee). No gateway/internet needed.

2. Device-to-Gateway: Device talks to a local gateway (e.g., sensor → ZigBee → Raspberry Pi gateway).

3. Device-to-Cloud: Device connects directly to cloud (e.g., Wi-Fi smart plug → AWS IoT).

4. Device-to-Server: Device connects to a specific application server (may not be a full cloud platform).

3.5 Other Enablers

3.5.1 RFID (Radio Frequency Identification)

• Principle: Uses electromagnetic fields to automatically identify and track tags attached to objects.

• Components:

  • Tag: Passive (no battery, powered by reader's signal, short range) or Active (battery-powered, long range, expensive).

  • Reader: Emits signal, receives tag response.

  • Middleware: Filters/aggregates tag reads, connects to backend apps.

• Link with IoT: RFID provides automatic identification & location data – a key "sensing" source for IoT systems (supply chain, inventory).

3.5.2 NFC (Near Field Communication)

• Definition: Short-range (~10 cm) wireless technology, subset of RFID, operating at 13.56 MHz.

• Applications: Contactless payments, data exchange (tap to share contact), device pairing (Bluetooth/Wi-Fi handover).

3.5.3 Software Defined Networking (SDN)

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

• Relevance to IoT: Enables flexible, programmable network management for dynamic, large-scale IoT deployments. Can implement fine-grained security policies per device type.

• Maturity Assessment: Mature in data centers/enterprise networks. Emerging in IoT due to complexity of managing diverse, constrained devices. Not yet standard in low-power IoT networks.

4.0 APPLICATION LAYER PROTOCOLS (Very High Frequency)

4.1 MQTT (Message Queuing Telemetry Transport)

• Concept: Lightweight publish/subscribe messaging protocol. Uses a central Broker.

• Operation:

  • Client (device/app) publishes message to a Topic (e.g., home/livingroom/temp).

  • Broker filters and forwards to all subscribers of that topic.

  • Subscriber receives message.

• Message Structure: Fixed header (topic, QoS), Variable header, Payload.

• QoS Levels:

  • 0 (At most once): Fire-and-forget.

  • 1 (At least once): Acknowledgment, may duplicate.

  • 2 (Exactly once): 4-step handshake, no duplicates.

• WebSockets: MQTT can be encapsulated in WebSockets to traverse web proxies/firewalls and enable browser-based MQTT clients.

4.2 CoAP (Constrained Application Protocol)

• Concept: RESTful protocol designed for constrained nodes and networks. Based on HTTP semantics (GET, PUT, POST, DELETE) but UDP-based, binary, smaller headers.

• Request-Response Model:

  • Confirmable (CON): Requires ACK. Reliable (like TCP).

  • Non-Confirmable (NON): No ACK. Unreliable, low overhead (like UDP).

  • Separate (SEP): Response sent in separate message.

• Use Between Devices on Same Constrained Network (Peer-to-Peer):

  • CoAP is ideal for device-to-device communication within a local, constrained network (e.g., a 6LoWPAN mesh).

  • No need for a central broker (unlike MQTT). Devices can directly GET/PUT resources on each other.

  • Example: A temperature sensor (CoAP server) exposes resource /sensors/temp. A nearby actuator (CoAP client) can GET this value directly to decide on cooling.

4.3 AMQP (Advanced Message Queuing Protocol)

• Features & Components:

  • Wire-level protocol for reliable, interoperable messaging.

  • Components: Sender/Receiver, Exchange (routes messages), Queue (stores messages), Binding (rules linking exchange to queue).

  • Message Attributes: routing-key, priority, timestamp, message-id.

  • Payload: Application data (any format).

• Frame Types Overview: AMQP frames are the basic unit. Key types: OPEN (connection), BEGIN (session), ATTACH (link), FLOW (flow control), TRANSFER (message transfer), DISPOSITION (settlement), CLOSE (end).

4.4 XMPP (Extensible Messaging and Presence Protocol)

• How it Improves IoT Services:

  1. Federation: XMPP servers can federate (like email). IoT devices/services on different domains/owners can communicate securely.

  2. Presence: Built-in presence information (online/offline, status). Enables context-aware services (e.g., "only control lights when user is home").

  3. Extensibility: XMPP extensions (XEPs) can define IoT-specific features (sensor data, control).

4.5 SMQTT (Secure MQTT)

• Mechanism for Secure Message Transfer:

  • Lightweight security extension for MQTT.

  • Uses symmetric-key cryptography (AES) for payload encryption.

  • Key Management: Pre-shared keys or key distribution via a trusted third party.

  • Goal: Provide confidentiality for MQTT messages with minimal overhead compared to full TLS/SSL.

4.6 WebSockets

• Role in IoT: Provides full-duplex, persistent TCP connection between client (often browser) and server.

• Use Case: Enables real-time, bidirectional communication from a web dashboard to an IoT device/gateway. Often used as a transport for MQTT (MQTT over WebSockets) to allow browser-based IoT control.

5.0 CLOUD INTEGRATION & DATA ANALYTICS (High Frequency)

5.1 Cloud Computing for IoT

5.1.1 Why Cloud is Useful for IoT

• Scalability: Handle millions of devices and petabytes of data.

• Storage: Massive, durable storage for historical data.

• Processing Power: On-demand compute for complex analytics (ML, AI).

• Management: Centralized device provisioning, monitoring, firmware updates.

• Cost-Effective: Pay-as-you-go, no upfront infrastructure cost.

5.1.2 Cloud Service Models in IoT Context

5.1.3 Cloud Communication APIs

• RESTful APIs: Primary method for cloud-to-device (commands) and device-to-cloud (data) communication. Uses HTTP methods (GET, POST, PUT, DELETE).

• Device-to-Cloud Messaging: Devices publish telemetry to a cloud endpoint (e.g., MQTT topic mapped to cloud service).

• Cloud-to-Device Messaging: Cloud sends commands/updates to specific devices (e.g., via MQTT publish to device-specific topic, or HTTP POST to device shadow).

5.2 Data Analytics in IoT

• Role & Necessity: Transform raw data into information, insight, and action. Enables predictive maintenance, optimization, automation.

• Analytics Approaches:

  1. Stream Processing: Real-time analysis of data in motion (e.g., Apache Flink, Kafka Streams). Detect anomalies instantly.

  2. Edge Analytics: Process data at the gateway/device to reduce latency, bandwidth, and cloud cost. Filter, aggregate, simple rules.

  3. Big Data Platforms: Batch processing of historical data for deep insights, ML model training (e.g., Hadoop, Spark on cloud data lakes).

5.3 IoT Platforms (Major Examples)

• AWS IoT Core: Device connectivity, device shadow, rules engine, integration with AWS analytics (Kinesis, Lambda, SageMaker).

• Microsoft Azure IoT Hub: Device-to-cloud/cloud-to-device messaging, device twins, integration with Azure Stream Analytics, Power BI.

• Google Cloud IoT Core: (Note: Scheduled for deprecation Aug 2023, but conceptually important) MQTT/HTTP bridge, integration with BigQuery, Dataflow.

• Others: IBM Watson IoT, Cisco IoT Cloud Connect, ThingWorx (PTC).

6.0 SECURITY & PRIVACY IN IoT (Very High Frequency)

6.1 Why Security is Required in IoT

• Unique Vulnerabilities:

  • Physical Access: Devices often in public/unsecured locations (easily tampered).

  • Resource Constraints: Limited CPU/memory for strong crypto.

  • Heterogeneity: Diverse hardware/OS/software, inconsistent security.

  • Large Attack Surface: Millions of endpoints.

  • Lifecycle: Long deployment (10+ years) with infrequent updates.

6.2 IoT Security Models

• Perimeter-Based Security: Traditional "castle-and-moat". Trust inside network, distrust outside. Fails in IoT due to insider threats and device compromise.

• Zero-Trust Security: "Never trust, always verify". Every device/user/transaction must be authenticated/authorized. Essential for IoT.

• Life-Cycle Security: Security must be integrated from design (Security-by-Design) through manufacturing, deployment, operation, maintenance, decommissioning.

6.3 IoT Vulnerabilities & Attacks

6.3.1 Common Vulnerabilities

• Hardcoded/weak/default passwords.

• Insecure network services (open ports).

• Lack of secure update mechanism.

• Insecure data transfer/rest (no encryption).

• Poor physical security.

6.3.2 Attacks on Application/Service Layer

• Injection (SQL, command): Malicious data sent to cloud app/database.

• Denial-of-Service (DoS/DDoS): Flood device/cloud with requests (Mirai botnet).

• Message Tampering/Replay: Alter or replay valid messages (e.g., replay "unlock door" command).

• Man-in-the-Middle (MITM): Intercept/alter communication between device and cloud.

6.3.3 Attacks on Other Layers

• Network Layer: Routing attacks (sinkhole, wormhole), jamming.

• Physical Layer: Device tampering, side-channel attacks (power analysis), hardware trojans.

6.4 Security Concerns & Privacy Issues

• Confidentiality: Prevent unauthorized data access (encryption).

• Integrity: Ensure data not altered (digital signatures, hashing).

• Availability: Ensure system/service is accessible (DDoS mitigation).

• Privacy: User data (location, habits) collected by IoT can reveal intimate details. Requires data minimization, anonymization, user consent, transparent policies.

6.5 Security Challenges

• Scalability: Securing millions of devices.

• Heterogeneity: Different security capabilities.

• Resource Constraints: Lightweight crypto (ECC vs RSA), secure key storage.

• Key Management: Secure distribution/rotation of keys for vast number of devices.

• Legacy Devices: Insecure devices already deployed with no update path.

7.0 IoT APPLICATIONS & CASE STUDIES (High Frequency)

7.1 Smart Home

7.1.1 Design with Raspberry Pi & Hardware

• Core: Raspberry Pi as central gateway/hub.

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

• Actuators: Relays (to control AC lights/fans), servo motors (door lock), LED indicators.

• Connectivity:

  • Sensors to Pi: Via GPIO (digital) or I2C/SPI (multiple sensors).

  • Pi to Cloud/Internet: Wi-Fi/Ethernet.

• Software: Pi runs Node-RED (visual flow-based programming) or custom Python scripts. Integrates with MQTT broker (local or cloud) and cloud platforms (Home Assistant, AWS IoT).

7.1.2 Typical Applications

• Lighting Control: Automated/remote control based on time/light/motion.

• HVAC: Thermostat control based on occupancy & temp.

• Security: Motion-triggered cameras, door sensors, alarm.

• Appliance Control: Smart plugs for remote on/off.

7.1.3 Neat Sketch of System Architecture

7.2 Other Use Cases (Brief)

• Industrial IoT (IIoT): Predictive maintenance, asset tracking, process optimization. High reliability, low latency requirements.

• Smart Cities: Smart lighting, traffic management, waste management, environmental monitoring.

• Healthcare (IoMT): Remote patient monitoring, wearable sensors, asset tracking in hospitals.

• Agriculture (Smart Farming): Soil moisture sensors, automated irrigation, livestock monitoring.

7.3 Case Study Analysis (Example: Smart Grid)

• Objective: Modernize electricity grid for efficiency, reliability, sustainability.

• IoT Components:

  • Smart Meters: At consumer premises, send usage data (AMI - Advanced Metering Infrastructure).

  • Distribution Sensors: Monitor voltage, current, fault on power lines (PMUs - Phasor Measurement Units).

  • Renewable Integration: Monitor solar/wind farm output.

• Architecture: Level 4 System. Millions of meters/sensors (often using PLC, RF, or cellular), multiple edge gateways at substations, central cloud platform for analytics.

• Analytics: Demand forecasting, outage detection & prediction, fault location, dynamic pricing.

• Benefits: Reduced outages, efficient load balancing, integration of renewables, consumer empowerment.

[!TIP] For Case Studies: Structure answer as: 1. Problem/Objective, 2. IoT Components/Devices Used, 3. Communication/Architecture (Level?), 4. Analytics/Processing, 5. Benefits/Challenges.