Internet of Things (CY-504 (B)) - Unit 1 Short Notes

UNIT 1: Internet of Things (IoT) - Comprehensive Notes

Based on analysis of RGPV past papers (Jun 2025, Dec 2024, May 2024, May 2023, May 2022, Nov 2022).

I. IoT Fundamentals & Architectural Frameworks

Core Definition & Concept

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

• Ecosystem Components:

  1. Things/Devices: Sensors/Actuators with embedded electronics.

  2. Gateways: Local aggregation, protocol translation, security.

  3. Data: Raw information from sensors.

  4. Cloud/Network: Transport & storage infrastructure.

  5. Analytics: Processing data to extract insights.

  6. People: End-users & applications.

• IoT vs. M2M:

  | Aspect | M2M (Machine-to-Machine) | IoT (Internet of Things) | | :--- | :--- | :--- | | Connectivity | Point-to-point, proprietary networks. | IP-based, standardized, uses the Internet. | | Scale | Limited, closed systems. | Massive, open, global scale. | | Architecture | Siloed, application-specific. | Layered, service-oriented, platform-based. | | Data | Used for specific automation. | Collected, aggregated, analyzed for intelligence. | | Paradigm Shift | Device-centric communication. | Data-centric, cloud-integrated services. |

[!TIP] Exam Focus: M2M vs IoT comparison is a very frequent 7-mark question. Emphasize the shift from point-to-point to IP-based, scalable, data-driven architecture.

IoT Architectural Models

• IoT Reference Architecture (Layered Model):

  
  [Business Layer] - Process management, business rules, dashboards.
  
        |
  
  [Service/Application Layer] - Apps, analytics, APIs.
  
        |
  
  [Network/Transport Layer] - Internet, WAN, LAN, routing.
  
        |
  
  [Perception Layer] - Sensors, actuators, physical world interface.
  
  

  • Perception Layer: Physical sensors/actuators, data acquisition.

  • Network Layer: Connects devices to the cloud/other devices (Wi-Fi, ZigBee, cellular).

  • Service/Application Layer: Delivers services to users (dashboards, alerts).

  • Business Layer: Manages overall system, business models, privacy.

• IoT Service-Oriented Architecture (SOA):

  • Services are loosely coupled, reusable components (e.g., "temperature service", "location service").

  • Challenges: Service discovery, composition, security in highly dynamic, constrained environments.

• IoT Architectural Levels (Level 1-4 Systems):

  | Level | Description | Example | | :--- | :--- | :--- | | Level 1 | Single device, no internet. | Standalone thermostat. | | Level 2 | Device + local connectivity (no cloud). | Bluetooth-connected fitness tracker to phone. | | Level 3 | Device + Gateway + Cloud. Gateway handles protocol translation. | Smart home hub (e.g., Samsung SmartThings). | | Level 4 | Cloud-centric. Devices connect directly to cloud. | Cellular-connected asset tracker. |

• IoT "Planes" & Enablers:

  • Planes: Management, Security, Data, Application, Device planes operate across layers.

  • Enablers: Technologies that make IoT possible (e.g., Cloud Computing, Big Data, Wireless Sensors, RFID, IPv6, M2M).

  • Interdependencies: Security plane must be integrated across all planes; Data plane relies on Device and Network planes.

Logical vs. Physical Design of IoT

[!TIP] Common Pitfall: Students often confuse the two. Remember: Logical = Function/Software; Physical = Hardware/Implementation.

IoT Design Methodology (Steps)

1. Requirement Analysis: Define purpose, stakeholders, constraints (cost, power, range).

2. Technology Selection: Choose sensors, MCU/MPU, communication protocol (e.g., BLE vs. LoRaWAN), cloud platform.

3. Prototyping: Build proof-of-concept (often using Arduino/Raspberry Pi).

4. Deployment & Testing: Field testing, scalability, security validation.

5. Maintenance & Updates: OTA updates, monitoring.

Application Block Diagram Example: Smart Parking

[Parking Spot Sensor (Ultrasonic/IR)]

        |

    [Microcontroller (Arduino/ESP32)]

        |

[Wireless Link (Wi-Fi/ZigBee)] --> [Gateway] --> [Cloud Server]

                                          |

                                    [Mobile App/Web Dashboard]

                                          |

                                    [Notification to User]

II. IoT Devices & Hardware (Things)

Sensors & Sensing

• Common IoT Sensors:

  • Temperature: DHT11/DHT22, DS18B20.

  • Humidity: DHT series, capacitive sensors.

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

  • Pressure: BMP180/BMP280 (barometric).

  • Gas/Air Quality: MQ series (MQ-2, MQ-135).

  • Light/Color: LDR, TCS3200/TCS34725.

  • Acceleration/Tilt: ADXL345, MPU6050.

• Sensor Characteristics:

  • Accuracy: Closeness to true value.

  • Precision: Repeatability of measurements.

  • Range: Min/Max measurable values.

  • Resolution: Smallest detectable change.

  • Sensitivity: Output change per input change.

  • Error: Quantization Error in ADC: $$\displaystyle V_q = \frac{V_{ref}}{2^n} $$ (where $n$ = bits). This is the inherent error due to digitizing an analog signal.

Actuators

• Role: Convert electrical signal into physical action (e.g., turn on motor, open valve).

• Types:

  | Type | Principle | IoT Example | Key Selection Char. | | :--- | :--- | :--- | :--- | | Mechanical | Gears, levers, motors. | Servo motor in robot arm. | Force, Stroke, Speed, Power. | | Soft | Flexible materials (silicone), pneumatic/hydraulic. | Soft gripper for delicate objects. | Flexibility, Compliance. | | Shape Memory Polymer (SMP) | Changes shape with temperature/light. | Self-deploying structure. | Transition temperature, Recovery force. | | Pneumatic | Uses compressed air. | Air cylinder in automated door. | Force, Stroke, Air pressure req. |

• Four Common Selection Characteristics:

  1. Force/Torque: Required output strength.

  2. Stroke/Displacement: Required movement distance.

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

  4. Power Source: Electrical (voltage/current), pneumatic, hydraulic.

Processing & Interface Hardware

• Microcontroller (MCU) vs. Microprocessor (MPU):

  | Feature | MCU | MPU | | :--- | :--- | :--- | | Core | CPU + RAM/Flash/Peripherals on single chip. | CPU only; requires external RAM, storage. | | OS | Bare-metal, RTOS (no MMU). | Full OS (Linux, Windows, Android). | | Power | Low power, battery-friendly. | High power. | | Cost | Low. | Higher. | | Use in IoT | Edge nodes, sensors, simple control. | Gateways, edge analytics, complex HMI. |

• Raspberry Pi (vs. Desktop):

  • Differences: ARM architecture (vs. x86), lower power, no built-in HDD/display (vs. all-in-one), GPIO pins for hardware interfacing.

  • Key Interfaces:

    • GPIO (General Purpose Input/Output): Digital pins for reading sensors (buttons) or controlling LEDs/motors.

    • I2C (Inter-Integrated Circuit): Serial, 2-wire (SDA, SCL), multi-master/multi-slave, used for many sensors (e.g., BMP280).

    • SPI (Serial Peripheral Interface): Serial, 4-wire (MOSI, MISO, SCLK, CS), full-duplex, high-speed, used for displays, SD cards.

  • Role in IoT Prototyping: Acts as a gateway or edge node. Can run Linux, host MQTT brokers, process data, and interface with sensors via GPIO/I2C/SPI.

• Arduino: Simple, robust, vast library support, ideal for sensor interfacing and real-time control in early prototyping. Easier than Pi for bare-metal programming.

[!TIP] High-Yield: "Review of basic microcontrollers and interfacing" (GPIO, I2C, SPI) appears repeatedly. Be ready to draw pin connections for a sensor (e.g., DHT22 to Arduino/RPi).

III. Communication & Networking Technologies

Networking Fundamentals for IoT

• Wireless Sensor Networks (WSNs): Network of spatially distributed autonomous sensors to monitor physical/environmental conditions.

  • Characteristics: Limited power, low bandwidth, large node count, dynamic topology, data-centric.

  • Applications: Environmental monitoring, military surveillance, smart agriculture.

• Low-Power Lossy Networks (LLNs): Networks with low-power devices and unreliable, low-bandwidth links (prone to loss). WSNs are a type of LLN.

  • Key Protocols: 6LoWPAN (over IEEE 802.15.4), RPL (routing).

• Network Classification (Physical Topologies):

  • Bus: Single cable, all nodes share. (Ethernet coax legacy).

  • Star: All nodes connect to central hub/switch. (Wi-Fi, ZigBee coordinator).

  • Ring: Nodes in closed loop. (Legacy Token Ring).

  • Mesh: Nodes connect to multiple neighbors, multi-hop. (ZigBee, Thread, WSNs).

  • Tree: Hierarchical, combination of star/bus. (ZigBee cluster-tree).

  • Hybrid: Combination of above (e.g., star-mesh).

• Issues in IoT LAN Development:

  • Interference (2.4 GHz band crowded).

  • Limited range of low-power radios.

  • Power constraints on battery devices.

  • Scalability (hundreds of nodes).

  • Security in open wireless medium.

IP & Adaptation Layer Protocols

• IPv6 in IoT:

  • Why? 128-bit address space (~$$\displaystyle 3.4 \times 10^{38} $$ addresses) solves IPv4 exhaustion for billions of devices.

  • Features: Autoconfiguration (SLAAC), built-in security (IPsec), efficient header.

• 6LoWPAN (IPv6 over Low-Power WPAN):

  • Role: Adaptation layer between IPv6 and IEEE 802.15.4 (or other LLN link layer). Enables IPv6 packets to be carried efficiently over networks with small MTU (~127 bytes).

  • Key Functionality:

    1. Header Compression: Compresses 40-byte IPv6 header to few bytes.

    2. Fragmentation/Reassembly: Splits IPv6 packet to fit 802.15.4 frame.

  • Differences from IPv4/IPv6:

    | Aspect | IPv4/IPv6 | 6LoWPAN | | :--- | :--- | :--- | | Layer | Network Layer. | Adaptation Layer (between Network & Data Link). | | MTU | 1500+ bytes (Ethernet). | Fits small 802.15.4 frames (127B). | | Header | Fixed 40B (IPv6). | Compressed headers. | | Fragmentation | Done at lower layers (IP). | Explicitly handled by 6LoWPAN. |

• IEEE 802.15.4:

  • Definition: Standard for low-rate wireless personal area networks (LR-WPANs). Defines PHY (modulation, frequencies) and MAC (channel access, frame structure) layers.

  • Relation to IoT: Foundation for ZigBee, 6LoWPAN, Thread. Provides the basic low-power, low-data-rate radio link.

Application Layer Messaging & Communication Protocols

• MQTT (Message Queuing Telemetry Transport):

  • Concept: Lightweight Publish/Subscribe (pub/sub) messaging protocol.

  • Architecture: Clients (devices/apps) and a central Broker. Clients publish to topics (e.g., home/living/temp) and subscribe to topics.

  • Role in IoT: Ideal for constrained networks, low bandwidth, high latency. Decouples producers/consumers.

  • QoS Levels:

    0: At most once (fire-and-forget).

    1: At least once (acknowledged).

    2: Exactly once (handshake).

  • Use with WebSockets: Enables MQTT over TCP/IP web connections for browser-based apps.

• CoAP (Constrained Application Protocol):

  • Concept: RESTful protocol for constrained devices (like HTTP but lightweight). Uses Request-Response model.

  • Message Types:

    • Confirmable (CON): Requires ACK (reliable).

    • Non-Confirmable (NON): No ACK (unreliable, low overhead).

  • Use in same constrained network: Devices can communicate directly using CoAP without a proxy. A CoAP Proxy can be used for translation to HTTP or for caching.

• AMQP (Advanced Message Queuing Protocol):

  • Concept: Wire-level protocol for message-oriented middleware. More feature-rich, enterprise-focused than MQTT.

  • Components:

    • Exchange: Receives messages from producers.

    • Queue: Stores messages.

    • Binding: Rule connecting exchange to queue.

  • Message Attributes: Routing key, delivery mode (persistent/transient), priority, timestamp.

  • Frame Types: 8 types (e.g., OPEN, BEGIN, ATTACH, SEND, FLOW, CREATE, CLOSE, ERROR).

• XMPP (Extensible Messaging and Presence Protocol):

  • Improves IoT Services by adding Presence (knowing if a device is online/offline) and Federation (inter-domain communication between different XMPP networks). Good for chat-like IoT interactions.

• SMQTT (Secure MQTT):

  • Mechanism: Uses Message Authentication Code (MAC) and AES encryption for secure message transfer. Provides confidentiality, integrity, authentication at the message level, not just transport layer (TLS).

[!TIP] Frequent Comparison: MQTT vs. AMQP vs. CoAP is a classic question.

• MQTT: Pub/sub, broker-centric, lightweight, all QoS.

• AMQP: Broker-centric, rich features (exchanges, queues), enterprise.

• CoAP: Request/response (like HTTP), for device-device, supports multicast.

Specific Wireless Technologies

• ZigBee:

  • Definition: Low-power, low-data-rate, short-range wireless standard based on IEEE 802.15.4.

  • Architecture (Layers):

    • PHY/MAC: From 802.15.4.

    • NWK (Network): Mesh routing, addressing.

    • APL (Application): Application framework, profiles (e.g., Home Automation, Smart Energy).

  • Types:

    • ZigBee PRO (ZigBee 2007/Pro): Most common, for large networks (lighting, sensors).

    • ZigBee IP: Uses IPv6 & 6LoWPAN, for IP-based applications.

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

  • Device Roles: Coordinator (forms network), Router (routes, extends), End Device (sleeps, talks to parent).

• RFID (Radio Frequency Identification):

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

  • Components:

    • Tag: Microchip + antenna (Passive [no battery], Active [battery], Semi-passive).

    • Reader: Emits RF signal, receives tag response.

    • Middleware: Filters/aggregates data, connects to backend.

  • Link to IoT: RFID provides unique ID and location data for "things," making them "smart" and addressable—a foundational IoT enabler for supply chain, inventory.

• NFC (Near Field Communication):

  • Definition: Short-range (≤10 cm), high-frequency (13.56 MHz) wireless technology.

  • Applications: Contactless payments (Apple Pay), access control, data exchange between devices (Android Beam), device pairing.

[!TIP] Exam Drawings: Be prepared to draw and explain ZigBee architecture (layers + device roles) and RFID system block diagram.

IV. Data Management, Cloud & Analytics

Cloud Computing for IoT

• Usefulness:

  • Scalability: Handle millions of devices/data points.

  • Storage: Massive, durable storage for time-series data.

  • Processing: On-demand compute for batch/stream analytics.

  • Managed Services: Device management, security, monitoring.

• Cloud Communication APIs:

  • RESTful APIs (HTTP/HTTPS): Most common for device-cloud communication (e.g., AWS IoT Publish API).

  • MQTT/CoAP APIs: Native protocol support in cloud IoT platforms.

  • WebSockets: For real-time browser-based dashboards.

• Cloud Service Models in IoT Context:

  • IaaS (Infrastructure as a Service): Rent VMs, storage (e.g., AWS EC2, S3). User manages OS, runtime, apps.

  • PaaS (Platform as a Service): Platform for developing, testing, deploying IoT apps (e.g., AWS IoT Core, Azure IoT Hub, Google Cloud IoT Core). Manages infrastructure, connectivity, device management.

  • SaaS (Software as a Service): Ready-to-use IoT applications (e.g., Salesforce IoT Cloud, predictive maintenance apps).

IoT Data Analytics

• Role: Transform raw sensor data into actionable insights (predictive maintenance, anomaly detection, optimization).

• Edge/Streaming Analytics vs. Regular (Cloud) Analytics:

  | Edge/Streaming Analytics | Cloud (Batch) Analytics | | :--- | :--- | | Location: At/near the data source (gateway, device). | In centralized cloud data center. | | Latency: Very low (milliseconds). | Higher (seconds/minutes/hours). | | Bandwidth: Reduces data sent to cloud (pre-process). | Requires all raw data to be sent. | | Use Case: Real-time control, immediate alerts. | Long-term trends, complex ML models. | | Advantage: Privacy (sensitive data stays local), Reliability (works offline). | Power: More compute resources, large storage. |

• Hadoop Ecosystem (Brief): For big data processing in IoT.

  • HDFS: Distributed storage.

  • MapReduce/YARN: Processing framework/resource manager.

  • Hive/Impala: SQL-like querying.

  • Spark: In-memory processing, faster than MapReduce for iterative analytics (common in IoT ML).

IoT Platforms (Overview)

• AWS IoT Core: Device connectivity, security, integration with AWS analytics (Kinesis, SageMaker).

• Microsoft Azure IoT Hub: Device management, bi-directional messaging, integration with Azure Stream Analytics, Power BI.

• Google Cloud IoT Core: Managed MQTT/HTTP service, integrates with BigQuery, Dataflow, TensorFlow.

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

V. Security & Privacy in IoT

Need for Security in IoT

• Vulnerable Surfaces:

  • Device: Weak/default passwords, unpatched firmware, physical tampering.

  • Network: Insecure communication (no encryption), vulnerable protocols.

  • Cloud/Application: Insecure APIs, web app vulnerabilities (XSS, SQLi).

  • Privacy: Massive personal data collection (location, habits) without consent.

• Consequences: Data breaches, device hijacking (botnets like Mirai), physical harm (medical devices), service disruption (DDoS).

IoT Security Models

• Adapted CIA Triad:

  • Confidentiality: Encrypt data at rest & in transit (AES, TLS).

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

  • Availability: Protect against DoS, ensure uptime.

• Trust Models:

  • Device Identity: Unique cryptographic IDs (X.509 certificates).

  • Chain of Trust: From hardware root of trust to bootloader to OS to app.

  • Zero Trust: "Never trust, always verify" for every access request.

Vulnerabilities & Attacks on IoT Systems

• Common Vulnerabilities (OWASP IoT Top 10):

  • Weak, guessable, or hard-coded passwords.

  • Insecure network services (open ports).

  • Insecure ecosystem interfaces (cloud/web APIs).

  • Lack of secure update mechanism.

  • Use of outdated or insecure components.

• Attacks Exploiting Application/Service Layer:

  • Injection (SQL, OS command) via device APIs.

  • Broken Authentication: Bypassing login.

  • Sensitive Data Exposure: Stealing data from cloud storage.

  • XML External Entities (XXE): Parsing malicious XML.

  • Broken Access Control: Unauthorized function calls.

• General Attack Types:

  • DoS/DDoS: Overwhelm device/network/cloud (Mirai botnet).

  • Spoofing: Fake device identity (MAC/IP spoofing).

  • Eavesdropping/Sniffing: Intercept unencrypted traffic.

  • Physical Tampering: Direct access to device hardware.

  • Man-in-the-Middle (MitM): Intercept/alter communication.

[!TIP] High-Yield: "Various attacks on IoT systems" and "security and privacy issues" are very frequent. Structure answer: Device -> Network -> Cloud/App -> Privacy, with examples for each.

VI. Applications & Case Studies

Smart Home (Design with Raspberry Pi)

• Block Diagram / Sketch:

  
  [Sensors: DHT22 (Temp/Hum), PIR (Motion), Relay Module]
  
              |
  
          [Raspberry Pi (Gateway/Controller)]
  
              |
  
  [Communication: Wi-Fi/Ethernet] --> [Cloud (e.g., AWS IoT)] --> [Mobile App/Web]
  
              |
  
  [Local Control: GPIO -> Actuators: LED, Buzzer, Servo]
  
  

• Applications: Lighting control, HVAC automation, security (cameras, alarms), entertainment, energy management.

• Role of RPi: Acts as central hub, runs MQTT broker/client, hosts local web server, interfaces with sensors/actuators via GPIO/I2C/SPI.

Smart City Applications

• Smart Parking Architecture:

  1. Perception: Ultrasonic/IR sensors in each parking spot.

  2. Network: Sensors -> Gateway (LoRaWAN/Cellular) -> Internet.

  3. Platform: Cloud (AWS/Azure) receives occupancy data.

  4. Application: Mobile app/display boards show real-time availability; automated billing.

• Smart Traffic Control:

  • Sensors (inductive loops, cameras, GPS from buses) collect flow data.

  • Edge gateway/cloud analytics optimize traffic light timing dynamically.

  • Apps provide route guidance to avoid congestion.

• Smart Lighting:

  • Street lights with motion sensors (PIR) and ambient light sensors.

  • Lights dim/brighten based on presence/natural light.

  • Central management for scheduling, fault detection.

General IoT Applications

• Healthcare: Remote patient monitoring (wearables), smart pills, asset tracking.

• Agriculture: Precision farming (soil moisture sensors, drone imaging), livestock monitoring.

• Industrial (IIoT): Predictive maintenance, supply chain tracking, smart factories.

Case Study (Example: Smart Agriculture)

• Objective: Optimize irrigation, increase yield, reduce water waste.

• Things: Soil moisture sensors, temperature/humidity sensors, weather station, automated valves.

• Network: Sensors use LoRaWAN (long range, low power) to gateway.

• Gateway/Cloud: Gateway aggregates data, sends to cloud platform (e.g., Azure IoT Hub).

• Analytics: Cloud runs ML model (based on soil data, weather forecast) to predict irrigation needs.

• Action: Cloud sends command back via gateway to open/close valves automatically.

• User Interface: Farmer dashboard (web/mobile) shows field status, alerts, historical data.

[!TIP] For case studies, structure: Problem -> IoT Components (Sensors/Actuators) -> Network -> Cloud/Analytics -> Outcome/Benefits. Be ready to draw a simple block diagram.