UNIT 2: INTERNET OF THINGS (IoT) - SHORT NOTES

1.0 IoT FUNDAMENTALS & CONCEPTUAL FRAMEWORK

1.1 Physical Design of IoT

The physical design represents the tangible components and their interconnections.

• Things/Devices: Physical entities embedded with sensors/actuators (e.g., temperature sensor, smart bulb).

• Connectivity: Enables communication between devices and platforms (e.g., Wi-Fi, Bluetooth, LoRaWAN, cellular).

• Platform: Middleware for device management, data ingestion, and basic processing (e.g., AWS IoT Core, Azure IoT Hub).

• Application: End-user software that delivers specific services (e.g., mobile app for home automation).

• Analytics: Processes collected data to extract insights and enable decisions (e.g., predictive maintenance algorithms).

• User Interface (UI): The point of interaction for humans or other systems (e.g., dashboard, API).

[!TIP] Exam Focus: Be prepared to draw this block diagram and explain the flow of data from the "Thing" to the "User."

1.2 Conceptual Framework & Architecture of IoT

IoT systems are logically structured in layered architectures. Common models are 3-layer, 5-layer, and 7-layer.

• 3-Layer (Basic):

  1. Perception Layer: Physical sensors/actuators that collect data or perform actions.

  2. Network Layer: Transmits data from perception layer to processing systems (uses protocols like MQTT, CoAP, HTTP).

  3. Application Layer: Delivers specific services to end-users (e.g., smart agriculture, health monitoring).

• 5-Layer (Common & Detailed):

  1. Perception Layer

  2. Transport/Network Layer: Handles data transmission over various networks (IP-based, non-IP).

  3. Processing Layer: Stores, processes, and analyzes data (often in the cloud/edge).

  4. Application Layer

  5. Business Layer: Manages the overall IoT system, including business models, profit, and policies.

[!TIP] Exam Focus: The 5-layer model is most frequently asked. You must be able to draw it and explain the function of each layer with examples.

1.3 Characteristics of IoT

The core attributes that define an IoT system:

1. Connectivity: Ability of things to connect to the internet or each other.

2. Things: Physical objects with unique identifiers and sensing/actuating capabilities.

3. Data: The raw information collected by sensors; the fundamental fuel of IoT.

4. Communication: Protocols and technologies enabling data exchange.

5. Intelligence: Capability to process data and make decisions (often via analytics/AI).

6. Action: The result of intelligence—actuation or triggering an event.

7. Ecosystem: The interconnected environment of devices, networks, platforms, and users.

1.4 M2M vs. IoT

[!TIP] Exam Focus: The partitioning into Thing Domain and Information Domain is a frequent 14-mark question topic. Be ready to apply this partition to a given problem (e.g., smart parking, industrial monitoring).

2.0 IOT COMMUNICATION PROTOCOLS & MESSAGING

2.1 Message Communication Protocols

2.1.1 MQTT (Message Queuing Telemetry Transport)

• Model: Lightweight Publish/Subscribe (Pub/Sub) messaging protocol.

• Key Components:

  • Publisher: Sends messages to a Topic.

  • Subscriber: Receives messages from topics it is interested in.

  • Broker: Central server that filters and routes messages from publishers to subscribers.

• Quality of Service (QoS) Levels:

  • QoS 0: "At most once" – fire and forget. No acknowledgment.

  • QoS 1: "At least once" – guaranteed delivery, possible duplicates.

  • QoS 2: "Exactly once" – guaranteed delivery without duplicates (highest overhead).

• Role in IoT: Ideal for constrained networks (low bandwidth, high latency) and remote monitoring due to its small header size and efficient power use.

Example: A temperature sensor (Publisher) publishes {"temp": 25.5} to topic home/livingroom/temp. A mobile app (Subscriber) subscribed to that topic receives the data.

2.1.2 CoAP (Constrained Application Protocol)

• Designed For: Constrained nodes (low power, low memory) and constrained networks.

• Model: RESTful protocol (like HTTP) using Request/Response.

• Methods: GET, POST, PUT, DELETE.

• Key Feature: Observe: Allows a client to observe (long-term subscribe to) a resource on a server. The server sends notifications when the resource changes.

• Comparison with HTTP:

  • Uses UDP (vs. TCP) for lower overhead.

  • Binary header (few bytes vs. HTTP's text headers).

  • Built-in discovery and resource observation.

  • CoAP is NOT a replacement for HTTP but an alternative for constrained IoT scenarios.

2.1.3 HTTP/HTTPS

• Model: Standard Request/Response.

• In IoT Context: Heavyweight due to verbose text headers and TCP handshake overhead. Unsuitable for very constrained devices but used where web compatibility is needed (e.g., smart TVs, gateways).

2.1.4 SOAP

• XML-based protocol with strict standards (WS-*).

• Heavyweight, verbose, and complex. Rarely used in resource-constrained IoT devices; more common in enterprise backend integration.

2.1.5 IP in IoT

• Role: Provides universal addressing and routing. Essential for internet-scale IoT.

• IPv6: Critical due to its massive address space (2^128 addresses).

• 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks): A key adaptation layer that allows IPv6 packets to be carried efficiently over low-power, low-bandwidth networks like IEEE 802.15.4 (used by Zigbee, Thread).

2.2 Protocol Selection Criteria

Selection depends on a trade-off analysis:

3.0 ENABLING TECHNOLOGIES: SENSORS, ACTUATORS & WSN

3.1 Wireless Sensor Networks (WSN)

3.1.1 Single-Node Architecture

A single sensor node ("mote") consists of:

1. Sensing Unit: One or more sensors + ADC.

2. Processing Unit: Microcontroller (MCU) for local computation.

3. Transceiver Unit: Radio for communication (e.g., CC2420 for 802.15.4).

4. Power Unit: Battery (often with power management circuitry).

3.1.2 WSN Network Architecture

• Star: All nodes communicate directly with a central base station. Simple, but base station is a single point of failure.

• Tree (Cluster-Tree): Hierarchical structure with cluster heads routing data. Balances load.

• Mesh: Nodes can relay data for others. Highly robust and scalable, but complex routing.

3.1.3 Benefits & Limitations

3.2 Sensors and Actuators

3.2.1 Sensors

• Definition: A device that detects/measures a physical property and converts it into an electrical signal.

• Common Types in IoT:

  • Temperature: Thermocouples, RTDs, thermistors.

  • Proximity/Motion: PIR (Passive Infrared), ultrasonic, radar.

  • Light/Ambient: Photodiodes, LDRs.

  • Gas/Air Quality: MQ series (CO, LPG), electrochemical.

  • Pressure: Piezoelectric, strain gauge.

  • Humidity: Capacitive, resistive.

  • Accelerometer/Inertial: MEMS-based.

• Key Characteristics: Accuracy, precision, range, sensitivity, resolution, response time, drift.

3.2.2 Actuators

• Definition: A device that converts an electrical/control signal into physical action.

• Function: The "action" part of the IoT loop (Sense -> Process -> Act).

• Types:

  • Electrical: Relays, solenoids, motors (DC, stepper, servo).

  • Hydraulic: Uses fluid pressure (high force, industrial).

  • Pneumatic: Uses compressed air (clean, fast).

  • Thermal/Magnetic: Shape-memory alloys, magnetostrictive.

3.2.3 Participatory Sensing

• Definition: A sensing paradigm where humans with personal devices (smartphones, wearables) act as mobile sensors, contributing data (often context-aware: location, image, sound).

• Importance:

  • Crowdsourcing: Massive-scale data collection at low infrastructure cost.

  • Human Context: Captures subjective or social data (e.g., traffic reports, noise pollution, event witnessing).

  • Real-time Feedback: Enables rapid community response (e.g., disaster reporting, pothole mapping).

3.3 Specific Application: Smart Street Lights

• System Components:

  • Sensors: PIR (motion), ambient light (LDR/photodiode), vibration (for fault detection), weather (optional).

  • Controller: MCU (e.g., Arduino, ESP32) to process sensor inputs.

  • Communication Module: Wi-Fi, LoRa, NB-IoT to send status/receive commands.

  • Light Fixture: LED lamp with dimmable driver.

• Working Principle:

  1. Auto-dimming: Ambient light sensor measures daylight. Low light -> lights turn ON at a base level.

  2. Motion-based Activation: PIR detects movement (vehicle/pedestrian). Controller increases brightness (e.g., from 30% to 100%) for a set duration.

  3. Fault Detection: Vibration sensor or current monitoring detects lamp failure; sends alert to management center.

  4. Remote Management: Central system can override, schedule, or monitor all lights via the communication module.

4.0 IOT SYSTEM DESIGN, PLATFORMS & CLOUD

4.1 IoT Architecture Design Objectives (for Horizontal Systems)

Targeting horizontal (cross-industry) real-world services requires:

• Scalability: Handle millions of devices and data points.

• Interoperability: Support diverse devices, protocols, and applications (use open standards).

• Security: End-to-end security (device, network, cloud, application).

• Manageability: Remote device provisioning, monitoring, firmware updates.

• Cost-effectiveness: Low total cost of ownership (TCO) for deployment and operation.

4.2 Deployment and Operational Views (Parking IoT Example)

• Resources: Physical/virtual entities. Example: The ultrasonic sensor mounted on a parking spot is a resource.

• Services: Capabilities offered by resources. Example: The sensor provides the "parking spot status" service (occupied/vacant).

• Virtual Entities: Digital representations of physical things in the system. Example: A digital twin of "Parking Spot A-101" in the cloud database, updated by the sensor's service.

• Users: Human or system interacting. Example: A driver using a mobile app (user) to find a vacant spot.

How it maps:

1. Physical World: Spot A-101 has an ultrasonic sensor (Resource).

2. Service: Sensor provides spot_status: vacant/occupied.

3. Virtual Entity: Cloud entry {spot_id: "A-101", status: "vacant", last_updated: "10:05"}.

4. User: Driver's app queries the cloud for spots near location, receives list of virtual entities, and navigates to A-101.

[!TIP] Exam Focus: This Parking IoT example is a frequent 7-mark question. Practice explaining all four concepts (Resources, Services, Virtual Entities, Users) using this single, consistent example.

4.3 Cloud of Things (CoT) / IoT Cloud Platforms

• Definition: The integration of IoT devices/data with cloud computing infrastructure and services.

• How it Enables New Value-Added Services:

  1. Massive Scalable Storage: Store petabytes of time-series sensor data.

  2. Elastic Compute & Analytics: Run big data (Hadoop/Spark) and machine learning (TensorFlow) on accumulated data.

  3. Device Management at Scale: Onboard, monitor, and update millions of devices remotely.

  4. Rapid Application Development: PaaS offerings (rules engines, dashboards, APIs) let developers build apps quickly without managing backend.

  5. Global Accessibility: Services and data accessible from anywhere via internet.

4.4 Data Storage in IoT

• Challenges (The 3 V's):

  • Volume: Massive scale (billions of devices, high frequency).

  • Velocity: High-speed, continuous data streams (real-time).

  • Variety: Structured (sensor readings), unstructured (video, logs).

• Storage Options:

  • Edge Storage: Local storage on gateway/device for latency-sensitive apps or intermittent connectivity.

  • Cloud Storage: Object storage (S3, Blob) for raw data; relational/NoSQL databases for processed data.

  • Time-Series Databases (TSDB): Optimized for timestamped data (e.g., InfluxDB, TimescaleDB). Most suitable for IoT sensor data.

  • Data Lakes: Store raw data in native format for future exploration.

5.0 IOT VERTICALS & ADVANCED INFRASTRUCTURE

5.1 IoT Verticals: Domain-Specific Systems

5.1.1 Industrial IoT (IIoT)

• Focus: Manufacturing (Industry 4.0), supply chain, asset tracking, predictive maintenance.

• Key Requirements:

  • High Reliability & Determinism: Production lines cannot fail.

  • Low Latency: Real-time control loops.

  • Robust Security: Protect critical infrastructure from cyber-physical attacks.

  • Integration with Legacy OT: Must work with existing industrial systems (SCADA, PLCs) using protocols like OPC-UA, Modbus.

5.1.2 Automotive IoT (Connected Vehicles)

• Focus: Telematics, infotainment, V2X (Vehicle-to-Everything) communication, autonomous driving.

• Key Requirements:

  • Real-time Performance & Safety-Critical: Braking/steering systems require ultra-low latency and high reliability.

  • High Mobility & Handover: Seamless connectivity across cellular networks (4G/5G) while moving.

  • Massive Data Generation: From dozens of in-vehicle sensors (LiDAR, radar, cameras).

  • Stringent Security & Privacy: Protect vehicle control and user data.

Comparison Table:

5.2 Network & Service Virtualization for IoT

5.2.1 Network Function Virtualization (NFV)

• Concept: Decouples network functions (e.g., firewall, gateway, protocol converter) from proprietary hardware appliances. They run as software (VNFs - Virtual Network Functions) on standard servers.

• Virtualizing IoT Functions:

  • A physical IoT Gateway (hardware) that translates Modbus to MQTT can become a VNF.

  • Benefits: Dynamic scaling (spin up more gateway instances during peak), flexible service chaining (link VNFs in any order), cost reduction (use COTS hardware).

  • Architecture: VNFs are managed by an NFV Orchestrator (NFVO) and run on a NFV Infrastructure (NFVI) (compute, storage, network).

5.2.2 Software-Defined Networking (SDN)

• Concept: Separates the control plane (makes decisions about where traffic goes) from the data plane (forwards traffic). A central SDN Controller has a global view.

• Role in IoT:

  • Centralized Management: Program network behavior for thousands of IoT devices from one point.

  • Flexible Traffic Steering: Direct specific IoT traffic (e.g., CoAP) through security inspection VNFs.

  • Dynamic QoS: Prioritize critical IoT traffic (e.g., medical device data) over less critical (e.g., temperature updates).

  • Security Policy Enforcement: Isolate compromised IoT devices quickly by reprogramming switches.

5.3 IoT Development Platforms & Tools

5.3.1 Arduino

• Hardware: Open-source microcontroller boards (Uno, Nano, Mega). Based on AVR (ATmega328p) or ARM (MKR series). Has digital/analog I/O pins, PWM, communication interfaces (UART, I2C, SPI).

• Software: Arduino IDE (Integrated Development Environment). Programs are called "Sketches" with two mandatory functions:

  • setup(): Runs once at startup. Initialize pins, baud rate, libraries.

  • loop(): Runs repeatedly. Main program logic.

• Example: Ultrasonic Sensor (HC-SR04) for Distance Measurement

  
  const int trigPin = 9;
  
  const int echoPin = 10;
  
  long duration;
  
  int distance;
  
  void setup() {
  
    Serial.begin(9600);
  
    pinMode(trigPin, OUTPUT);
  
    pinMode(echoPin, INPUT);
  
  }
  
  void loop() {
  
    // Clear the trigPin
  
    digitalWrite(trigPin, LOW);
  
    delayMicroseconds(2);
  
    // Set trigPin HIGH for 10 micro-seconds to send pulse
  
    digitalWrite(trigPin, HIGH);
  
    delayMicroseconds(10);
  
    digitalWrite(trigPin, LOW);
  
    // Read echoPin, pulseIn returns sound wave travel time in microseconds
  
    duration = pulseIn(echoPin, HIGH);
  
    // Calculate distance: time * speed of sound (343 m/s) / 2 (go and back)
  
    distance = duration * 0.034 / 2;
  
    Serial.print("Distance: ");
  
    Serial.print(distance);
  
    Serial.println(" cm");
  
    delay(1000);
  
  }
  
  

  • pulseIn(): Measures the time (in µs) for a pulse to return.

  • Formula: distance (cm) = (duration * 0.034) / 2.

[!TIP] Exam Focus: You may be asked to write a simple Arduino code for a common sensor (ultrasonic, DHT11). Remember the setup()/loop() structure and basic pin functions (pinMode, digitalWrite, pulseIn).

6.0 SYNTHESIS & APPLICATION-DRIVEN DESIGN

6.1 Integrated IoT Solution Design (Applied M2M/IoT Architecture)

When given a problem (e.g., "Design a smart irrigation system"), follow this partitioned approach:

1. Define the Problem & Requirements: What to monitor/control? Constraints (power, cost, range)?

2. Partition Architecture:

   • Thing Domain (Edge):

     • Things: Soil moisture sensors, water flow sensors, solenoid valves.

     • Local Controller/ Gateway: Arduino/Raspberry Pi. Performs local logic (e.g., "if moisture < threshold, open valve"). May use local protocols (Zigbee, LoRa).

     • Goal: Immediate response, offline operation, reduce cloud dependency.

   • Information Domain (Cloud/IT):

     • Cloud Platform: Receives aggregated data (soil moisture, weather forecast).

     • Analytics: Runs machine learning to predict irrigation needs based on weather, crop type.

     • Application: Web/mobile dashboard for farmer, API for third-party services.

     • Management: Device management, user authentication, billing.

     • Goal: Long-term insights, remote access, integration with other systems (weather APIs).

3. Select Enabling Technologies:

   • Sensors/Actuators: Choose based on accuracy, durability.

   • Communication: Thing Domain -> Gateway (LoRa, Zigbee). Gateway -> Cloud (Cellular/NB-IoT, Wi-Fi).

   • Protocol: MQTT for cloud comms (lightweight, pub/sub).

   • Platform: AWS IoT Core / ThingsBoard.

4. Address Design Objectives: Ensure scalability (many fields), security (TLS for MQTT), interoperability (standard data formats like JSON).

5. Draw System Architecture: Show clear boundary between Thing Domain (field devices, local gateway) and Information Domain (cloud, apps).

[!TIP] Exam Focus: This is the blueprint for 14-mark design questions. Always explicitly mention and separate the Thing Domain and Information Domain. Use a diagram to visualize the partition.

6.2 Holistic System View

An IoT solution is a chain: Physical Layer (Sensors/Actuators) → Communication Layer (Protocols: MQTT/CoAP over Wi-Fi/LoRa) → Platform Layer (Cloud: ingestion, storage, device management) → Application Layer (User Dashboard, Alerts, APIs).

Trade-off Considerations:

• Power vs. Bandwidth: Frequent high-rate data transmission drains battery.

• Cost vs. Performance: More sensors/analytics increase accuracy but also cost.

• Security vs. Usability: Strong encryption/authentication adds complexity and latency.

• Edge vs. Cloud: Edge computing reduces latency/bandwidth but has limited resources. Cloud offers massive compute but has latency.

Final Design Principle: Make decisions at each layer based on the specific application requirements (e.g., a pacemaker needs ultra-reliable, low-latency communication → prioritize IIoT-like requirements over consumer IoT).