Internet of Things (IoT) (EC-703 (B)) - Unit 3 Short Notes

UNIT 3: Internet of Things (IoT)

I. IoT Foundations and Conceptual Framework

Characteristics of IoT

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

• Key Characteristics (High Frequency):

  • Dynamic & Self-Adapting: Devices and systems can adjust to changing contexts and environments.

  • Interoperable: Enables seamless communication and operation across diverse technologies and platforms.

  • Unique Identity: Each physical entity (thing) has a unique identifier (UID) like an IP address or RFID.

  • Integrated: Combines information from multiple devices and systems to create new insights.

  • Scalable: Can scale from a few devices to millions.

  • Context-Aware: Can sense, interpret, and react to changes in the physical environment.

[!TIP] Exam Focus: Be prepared to list and briefly explain each characteristic with a real-world IoT example (e.g., Smart Watch: Unique Identity, Context-Aware, Interoperable).

IoT Conceptual Framework

A model describing the logical components and their interactions.

• Physical Layer: Things (sensors/actuators), devices, and connectivity (gateways).

• Network Layer: Communication infrastructure (IP networks, protocols) for data transport.

• Application Layer: Applications that process data and deliver services to users.

• Management Layer: Security, device management, and data management services.

• Service Layer: Provides APIs and platforms for developing and deploying IoT services.

Physical Design of IoT (Device-level)

Focuses on the hardware components of an IoT node.

• Core Components:

  1. Sensors/Actuators: Interface with the physical world.

  2. Microcontroller/Microprocessor (e.g., Arduino, ESP32): The brain for local processing.

  3. Communication Module: Wi-Fi, Bluetooth, LoRa, GSM for connectivity.

  4. Power Supply: Batteries, energy harvesting, or mains power.

  5. Memory: For storing firmware and temporary data.

II. IoT Architecture and Design Principles

Design Objectives for Horizontal Real-World Services (Very High Frequency)

Goals for an IoT architecture that serves multiple application domains (horizontal) vs. a single domain (vertical).

• Abstraction: Hide complexity of underlying devices and networks.

• Reusability: Components (services, data models) should be reusable across applications.

• Interoperability: Standardized interfaces (e.g., oneM2M) to connect devices from different vendors.

• Scalability: Handle growth in number of devices and data volume.

• Security & Privacy: Built-in from the start, not an add-on.

• Modularity: Loose coupling of components for independent evolution.

[!TIP] Common Pitfall: Do not confuse "horizontal" (cross-industry, like a generic parking solution) with "vertical" (domain-specific, like a factory-specific predictive maintenance system).

IoT Architectural Models

• Layered Architectures (e.g., 3-Layer, 5-Layer, 7-Layer):

  • Perception Layer: Sensors/actuators for data acquisition.

  • Network Layer: Data transmission via various networks (Wi-Fi, 5G, LPWAN).

  • Middleware/Service Layer: Core IoT platform functions (device management, data management, service discovery).

  • Application Layer: Domain-specific applications (smart home, smart health).

  • Business Layer: Business models, rules, and processes.

• Service-Oriented Architecture (SOA) & Cloud-Centric: IoT devices expose capabilities as services consumed by cloud applications.

Applied Architecture in M2M/IoT: Partitioning into Solution and Architectural Domains (14m Focus)

• Architectural Domain (AD): Defines the standardized, reusable building blocks (e.g., device templates, data models, service definitions). It's generic and technology-agnostic.

• Solution Domain (SD): Uses the AD components to build a specific, concrete IoT solution for a particular use case (e.g., a smart parking system). It involves configuration, integration, and application development.

• Key Benefit: Separation allows the AD to evolve independently, promoting interoperability and reducing time-to-market for SDs.

[!TIP] Exam Answer Structure for 14m: 1) Define AD & SD. 2) Explain their roles and relationship (AD provides the "what", SD provides the "how" for a specific case). 3) Use Parking IoT as the running example: AD defines a generic "ParkingSpot" device model; SD configures it for a specific city's parking lot, integrates with payment gateway, and builds the user app.

Deployment and Operational Views (Very High Frequency)

A way to describe an IoT system from different perspectives. Based on the oneM2M standard.

• Resources: The fundamental building blocks (e.g., <container> for data, <contentInstance> for a data item). Everything is a resource.

• Services: Capabilities offered by resources (e.g., CREATE, RETRIEVE, UPDATE, DELETE - CRUD operations).

• Virtual Entities (VEs): Digital representations (twins) of physical entities (e.g., a VE for a specific parking spot #A1). VEs are composed of resources.

• Users: Human or system entities that interact with VEs via applications.

• Case Study: Parking IoT System

  • Physical: Parking spot sensor (ultrasonic/IR) -> IoT Device (ESP32) -> Gateway -> Internet.

  • Deployment View (AD): Define a ParkingSpot resource structure (status: free/occupied, timestamp).

  • Operational View (SD):

    • Resource: A specific <container> instance for Spot #A1.

    • Service: Mobile app RETRIEVE the status of Spot #A1's container.

    • Virtual Entity: VE_ParkingSpot_A1 linked to that container.

    • User: Driver uses app to find and reserve VE_ParkingSpot_A1.

System Design for Interference/Challenges

• Co-channel Interference: Occurs when two transmitters use the same frequency channel in adjacent cells.

• Design Mitigation:

  • Frequency Reuse Pattern: Use a cluster size (N) > 1 (e.g., N=7) to separate co-channel cells.

  • Reduction Factor (q): The ratio of the distance between co-channel cells (D) to the cell radius (R). For hexagonal cells, $$\displaystyle D/R = \sqrt{3N} $$.

  • Power Control: Reduce transmit power to limit signal spillover.

  • Antenna Techniques: Use directional antennas to focus signal and reduce interference to/from specific directions.

III. Communication Protocols in IoT

Constrained Application Protocol (CoAP) (Very High Frequency)

• Purpose: Specialized web transfer protocol for constrained nodes (low power, low memory) and networks.

• Key Features:

  • RESTful Model: Similar to HTTP (GET, PUT, POST, DELETE) but optimized.

  • UDP-based: No connection setup overhead, low latency.

  • Message Types: Confirmable (CON), Non-Confirmable (NON), Acknowledgement (ACK), Reset (RST).

  • Observe Pattern: For resource state monitoring (server pushes updates to client).

  • Security: Datagram Transport Layer Security (DTLS) for end-to-end security.

• Message Format: Compact binary header (4 bytes) followed by optional token and options.

MQTT Protocol (High Frequency)

• Purpose: Lightweight publish/subscribe messaging transport protocol.

• Core Components:

  • Publisher: Sends messages to a Topic.

  • Subscriber: Receives messages from topics it's subscribed to.

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

• QoS Levels:

  • QoS 0: "At most once" (fire and forget).

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

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

• Retained Messages: Broker stores last message on a topic for new subscribers.

• Last Will & Testament (LWT): Pre-defined message sent by broker if client disconnects ungracefully.

[!TIP] Key Difference: CoAP is request/response (like HTTP) for direct device interaction. MQTT is pub/sub for asynchronous, many-to-many communication via a broker.

IV. IoT Devices, Sensors, and Actuators

Arduino Platform (High Frequency)

• What: Open-source electronics platform based on easy-to-use hardware (microcontroller boards) and software (Arduino IDE).

• Arduino IDE: Integrated Development Environment for writing, compiling, and uploading code (sketches) to Arduino boards.

  • Core Functions: setup() (runs once), loop() (runs repeatedly).

• Code Example: Ultrasonic Sensor (HC-SR04)

  
  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() {
  
    digitalWrite(trigPin, LOW);
  
    delayMicroseconds(2);
  
    digitalWrite(trigPin, HIGH);
  
    delayMicroseconds(10);
  
    digitalWrite(trigPin, LOW);
  
    duration = pulseIn(echoPin, HIGH);
  
    distance = duration * 0.034 / 2; // Speed of sound = 340 m/s
  
    Serial.print("Distance: ");
  
    Serial.print(distance);
  
    Serial.println(" cm");
  
    delay(1000);
  
  }
  
  

Sensors in IoT

• Definition: Devices that detect and measure physical properties (light, heat, motion, pressure) and convert them into electrical signals.

• Smart Street Lights: Specific Sensors & Operation

  • Sensors Used:

    1. PIR (Passive Infrared) Motion Sensor: Detects human/vehicle movement.

    2. Ambient Light Sensor (LDR/Photodiode): Measures surrounding light intensity.

    3. Weather Sensor (Rain, Humidity): For adaptive control.

  • System Operation:

    1. Low Light + No Motion: Lights OFF or at minimum dim level.

    2. Low Light + Motion Detected: Lights ON to full brightness.

    3. Sufficient Ambient Light: Lights remain OFF regardless of motion.

    4. Data Reporting: Sensor data sent to central controller/gateway for monitoring and analytics.

Actuators in IoT

• Definition: Devices that convert an electrical signal into a physical action (movement, force, control).

• Types & Applications:

  • Electrical Actuators: Relays, solenoids (control ON/OFF of lights, motors).

  • Pneumatic/Hydraulic Actuators: Motors, cylinders (industrial robotics, valves).

  • Thermal/Magnetic Actuators: Shape-memory alloys, magnetostrictive (micro-positioning).

  • Smart Actuators: Integrated with sensors and communication (e.g., smart valve with position feedback).

Wireless Sensor Networks (WSN) (High Frequency)

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

• Single-Node Architecture (Diagram Expected):

  
  [[DIAGRAM: CANVAS: Draw a block diagram of a single WSN node.
  
  Components: 1) Sensing Unit (Sensor + ADC), 2) Processing Unit (Microcontroller/CPU), 3) Communication Unit (Transceiver - e.g., CC2420 for 802.15.4), 4) Power Unit (Battery + Power Management), 5) Optional: Location Finding System, Mobilizer.
  
  Show data flow: Sensor -> ADC -> MCU -> Transceiver. Power to all units.]]
  
  

• Benefits:

  • Access to inhospitable/dangerous areas.

  • High spatial resolution of data.

  • Flexible deployment.

  • Collaborative processing.

• Limitations:

  • Severe Energy Constraints: Battery-powered, often impossible to replace.

  • Limited Computation & Memory.

  • Unreliable Network: High packet loss, dynamic topology.

  • Scalability Challenges: With thousands of nodes.

  • Security Vulnerabilities: Resource constraints limit strong cryptography.

V. IoT Application Domains and Use Cases

Smart Cities: Smart Street Lights (Detailed System)

• System Components:

  • Perception: PIR, Light, Weather sensors on each pole.

  • Network: LPWAN (LoRaWAN/NB-IoT) or Mesh (Zigbee) for sensor data; fiber/cellular for backbone.

  • Platform: IoT platform for device management, data ingestion, and rule engine.

  • Application: Dashboard for city management, maintenance alerts, energy analytics.

  • Actuation: LED driver with dimming capability in each street light fixture.

• Workflow: Sensors -> Local MCU (simple logic: if dark & motion -> ON) -> Periodic data to cloud -> Cloud analytics (detect faulty lights, optimize schedules) -> Commands to groups of lights.

Participatory Sensing

• Definition: A sensing paradigm where individuals, often using their personal mobile devices (phones, wearables), contribute sensor data (GPS, audio, image, environmental) to a collective dataset.

• Importance:

  • Cost-Effective: Leverages existing user devices.

  • Large-Scale Coverage: Potential for massive spatial/temporal data.

  • Human-in-the-Loop: Captures context only humans can provide (e.g., crowd sentiment, subjective noise levels).

  • Crowdsourcing: Enables large-scale scientific and civic projects (e.g., noise mapping, traffic reporting).

Industrial IoT (IIoT) vs. Automotive IoT (Very High Frequency)

[!TIP] Differentiation Key: IIoT is about optimizing industrial processes (OT/control focus). Automotive IoT is about connecting vehicles and enhancing mobility (connectivity/user experience focus).

VI. Enabling Technologies for IoT

Cloud of Things (IoT Cloud Integration) (Very High Frequency)

• Role: Provides the scalable compute, storage, and analytics platform for massive IoT data. It's the backbone for value-added services.

• How it Enables Value-Added Services:

  1. Data Aggregation & Storage: Ingests vast streams from millions of devices.

  2. Big Data Analytics: Processes data to extract insights (ML/AI for predictions, patterns).

  3. Device Management: Remote provisioning, monitoring, firmware updates.

  4. Application Enablement: Provides APIs and SDKs for developers to build apps without managing infrastructure.

  5. Visualization: Dashboards and reporting tools.

• Architecture Diagram (Expected):

  
  [[DIAGRAM: CANVAS: Draw a layered diagram.
  
  Bottom Layer: "Things" (Sensors/Actuators) with connectivity (gateways).
  
  Next Layer: "Edge/Fog Computing" (optional, for local preprocessing).
  
  Middle Layer: "IoT Cloud Platform" (box containing: Ingestion, Storage, Analytics, Device Management, Application Enablement).
  
  Top Layer: "Value-Added Services & Applications" (e.g., Predictive Maintenance App, Smart City Dashboard, Consumer App).
  
  Arrows show data flow upward from Things to Cloud and commands/insights downward to Applications/Things.]]
  
  

Network Function Virtualization (NFV) in IoT (Very High Frequency)

• Core Idea: Decouple network functions (like firewalls, load balancers, routers) from proprietary hardware appliances and run them as software instances (VNFs - Virtual Network Functions) on standard high-volume servers.

• Virtualization of IoT Devices:

  • Problem: Proprietary IoT gateways/hubs are inflexible.

  • Solution: The gateway's functionality (protocol translation, security, data filtering) is implemented as VNFs.

  • Architecture: A virtualized IoT gateway runs on a general-purpose compute node (in the cloud or at the network edge). Multiple VNFs (e.g., one for CoAP-to-HTTP translation, one for intrusion detection) can be chained together.

• Diagram (Expected):

  
  [[DIAGRAM: CANVAS: Draw two parts.
  
  Left (Traditional): Proprietary Hardware Gateway box with "Firmware" inside, connecting specific IoT devices to the IP network.
  
  Right (NFV-based): Standard Server/Compute Node. Inside, show multiple "VNF" containers (VNF1: Protocol Translator, VNF2: Security, VNF3: Data Aggregator) connected in a chain. IoT devices connect to this virtual gateway. Highlight flexibility: VNFs can be added/removed/updated via software.]]
  
  

• Benefits for IoT: Flexibility, faster innovation, cost reduction, dynamic scaling of gateway functions.

Software Defined Networking (SDN) for IoT

• Core Idea: Separates the control plane (decides where traffic goes) from the data plane (forwards traffic). A central SDN Controller has a global view and programs the forwarding tables of SDN Switches.

• Application in IoT:

  • Dynamic Network Management: Controller can prioritize traffic (e.g., emergency sensor data over routine updates).

  • Security: Controller can quickly isolate compromised IoT devices by reprogramming switches.

  • Mobility Management: Seamless handoff for mobile IoT nodes (e.g., in vehicles) as controller manages flows centrally.

  • Resource Optimization: Efficient use of bandwidth in low-power networks.

• Limitation: Controller is a single point of failure/attack; scalability of control messages for massive IoT.

VII. Data Management in IoT

Data Storage Strategies in IoT

• Challenges: Volume (high velocity, huge variety), Velocity (real-time streams), Veracity (noisy, uncertain data), Value (extracting insights).

• Strategies (Tiered Approach):

  1. Edge/Fog Storage: Local storage at gateway/node for ultra-low latency access, preprocessing, and offline operation. (e.g., SQLite on Raspberry Pi).

  2. Cloud Storage (Centralized): For long-term, large-scale historical data. Uses:

     • NoSQL Databases: (e.g., Cassandra, MongoDB) for unstructured/semi-structured time-series data.

     • Time-Series Databases (TSDB): (e.g., InfluxDB, TimescaleDB) optimized for timestamped sensor data.

     • Data Lakes: (e.g., on HDFS, S3) for raw, unprocessed data of all types.

  3. Stream Processing Engines: (e.g., Apache Kafka, Flink, Spark Streaming) for real-time processing before storage. They filter, aggregate, and route live data.

  4. Hybrid Model: Critical real-time data processed at edge/fog, aggregated summaries sent to cloud, raw data archived.

[!TIP] Exam Pattern: You may be asked to compare strategies or choose one for a given scenario (e.g., "For a real-time industrial alarm system, which storage strategy is most appropriate and why?"). Answer: Edge/Fog storage + stream processing for immediate action, with cloud for long-term analysis.