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

UNIT 5: Internet of Things (IoT)

1. Fundamentals of IoT

Characteristics of IoT

IoT systems are defined by:

• Connectivity: Seamless connection of physical objects to the internet/network.

• Sensing/Actuation: Ability to sense environment data and perform actions.

• Scalability: Can expand to millions of devices.

• Heterogeneity: Diverse devices, platforms, and protocols.

• Dynamic Nature: Devices and contexts change constantly.

• Intelligence: Data analytics and decision-making capabilities.

• Architecture: Often layered (perception, network, application).

Physical Design of IoT

The physical "thing" consists of:

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

2. Embedded Processors: Low-power microcontrollers (e.g., Arduino, ESP32) for local processing.

3. Communication Modules: Wi-Fi, Bluetooth, Zigbee, LoRa, cellular (NB-IoT) for connectivity.

4. Power Source: Batteries (often with energy harvesting) or mains power.

Conceptual Framework of IoT

A high-level view describing:

• Things: Physical objects with unique IDs.

• Communication: Protocols for data exchange.

• Computation: Cloud/edge processing.

• Services: Applications built on processed data.

• Semantics: Meaning and context of data.

2. IoT Architecture

Conceptual Architecture & Components (Three-Layer)

A common reference model:

1. Perception Layer (Edge): Sensors, actuators, RFID. Function: Data acquisition & control.

2. Network Layer (Transport): Gateways, communication networks (Wi-Fi, 5G). Function: Data transmission.

3. Application Layer (Services): Cloud platforms, analytics, user interfaces. Function: Data processing & service delivery.

[!TIP] Exam often asks for a neat diagram. Draw the three layers with examples of components in each and data flow arrows.

Design Objectives for Horizontal IoT Systems

Targeting systems applicable across multiple domains (e.g., smart building tech used in homes, offices, factories):

• Interoperability: Work with diverse devices/vendors.

• Scalability: Handle growth in devices/data.

• Security & Privacy: End-to-end protection.

• Modularity: Components can be upgraded independently.

• Manageability: Easy deployment, monitoring, and maintenance.

• Cost-Effectiveness: For mass deployment.

Applied Architecture: Partitioning into Domains

• Solution Domain: Problem-specific. Defines what the system does for a use-case (e.g., "smart parking").

• Architectural Domain: Generic, reusable. Defines how to build it (e.g., IoT platform, security framework, data model).

Key Idea: Separate the business logic (solution) from the technical foundation (architecture) for reusability.

Deployment & Operational View: Parking IoT Example

Using oneM2M standard as reference:

• Resources: The physical parking spots, sensors, cameras.

• Services: "Find Parking," "Pay by Mobile," "Occupancy Analytics."

• Virtual Entities: Digital twins/representations of each parking spot in the platform.

• Users: Driver (app), Parking Authority (dashboard), Payment System.

How it works: Sensor → Gateway → IoT Platform (creates/updates Virtual Entity for spot) → Service Application → User App.

System Architecture for Real-World Services

Must incorporate:

• Edge/Fog Computing: For low-latency local processing (e.g., traffic light control).

• Cloud Backend: For heavy analytics, storage, and global management.

• APIs & Microservices: For flexible service composition.

• Device Management: Lifecycle management of IoT devices.

3. Enabling Technologies

Wireless Sensor Networks (WSN)

• Single-Node Architecture:

  DiagramCANVAS: Draw a block diagram. Central block: "Sensor Node" with arrows from: 1) Power Unit (Battery/Solar), 2) Sensing Unit (Sensor + ADC), 3) Processing Unit (Microcontroller), 4) Communication Unit (Transceiver).

  • Sensing Unit: Measures physical parameter (temp, light) via sensor, converts analog to digital (ADC).

  • Processing Unit: Microcontroller runs firmware, processes data, controls other units.

  • Communication Unit: Radio transceiver (e.g., IEEE 802.15.4) for sending/receiving data.

  • Power Unit: Battery, often with power management circuitry.

• Benefits: Flexible deployment, low cost, self-organizing (ad-hoc).

• Limitations: Limited power/battery life, limited bandwidth, constrained computation, vulnerable to security attacks.

Sensors & Actuators

• Sensors in Smart Street Lights:

  • Types: PIR (motion), ambient light (LDR/photodiode), weather (rain, humidity), noise, air quality (PM2.5, CO2), GPS.

  • System Operation: Sensors continuously monitor. Data sent to gateway/cloud. Logic: IF (motion detected OR ambient light < threshold) AND (no rain) THEN turn ON light to 50% ELSE turn OFF. Enables adaptive dimming, fault detection.

• Actuators: Types & Use in IoT

  • Types: Electrical (relays, motors), hydraulic, pneumatic, thermal (heaters/coolers), piezoelectric.

  • IoT Use: Convert digital command to physical action. E.g., Relay to switch light, motor to open valve, heater to adjust temperature.

Participatory Sensing

• Definition: A sensing paradigm where human users (with their mobile devices) voluntarily contribute sensor data (GPS, camera, microphone) to a collective dataset.

• Importance:

  • Scale & Coverage: Leverages ubiquitous smartphones for large-area monitoring (noise maps, traffic).

  • Cost-Effective: No need to deploy dedicated sensor infrastructure.

  • Human Context: Data often includes social context (user reports, images).

  • Challenges: Data reliability, user privacy, incentive mechanisms.

4. Communication Protocols for IoT

Overview of Message Communication Protocols

• HTTP/HTTPS: Request-response, heavy, not ideal for constrained devices.

• MQTT: Lightweight publish-subscribe model. Ideal for low-bandwidth, high-latency networks.

• CoAP: Lightweight request-response (like HTTP) for constrained nodes/networks. Uses UDP.

• SOAP: XML-based, heavy, used in enterprise/web services, less common in resource-constrained IoT.

• IP (IPv6): Essential for global addressing. Challenges: header overhead, routing complexity for low-power devices (solved by 6LoWPAN adaptation layer).

Constrained Application Protocol (CoAP)

• Designed for: Simple, constrained devices (memory, power, bandwidth).

• Key Features:

  • RESTful (like HTTP: GET, PUT, POST, DELETE).

  • Uses UDP (low overhead) with optional reliability.

  • Observe mechanism for resource state monitoring (long-polling alternative).

  • Binary header (compact).

  • Built-in blockwise transfer for large payloads.

• Typical Use: Sensor data reading, simple control commands.

MQTT Protocol

• Role: De facto standard for IoT machine-to-machine (M2M) messaging where network bandwidth is limited.

• Core Model: Publish-Subscribe

  • Broker: Central server that routes messages.

  • Publisher: Client that sends (publishes) a message to a topic (e.g., home/livingroom/temp).

  • Subscriber: Client that expresses interest in a topic. Broker delivers all messages for that topic to the subscriber.

• Example: Temperature sensor (publisher) sends to sensors/temp1. Mobile app (subscriber) gets all updates from that topic automatically.

• QoS Levels:

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

  • 1 (At least once): Acknowledgment required, possible duplicates.

  • 2 (Exactly once): Handshake ensures single delivery.

HTTP in IoT

• Role: Used when IoT device needs to interact with standard web services/APIs (cloud platforms).

• Drawbacks: Verbose headers (text-based), TCP connection overhead, power-intensive. Not suitable for very constrained nodes.

• Use Case: Device sending data to a cloud REST API endpoint.

SOAP in IoT

• Role: Primarily in enterprise/IoT integrations where formal contracts (WSDL), security (WS-Security), and ACID transactions are critical.

• Drawbacks: Very heavy (XML envelope), complex, high processing/memory needs. Rare in device-to-device IoT.

IP in IoT (IPv6)

• Addressing: IPv6 provides ~3.4×10³⁸ addresses, solving IPv4 exhaustion. Essential for unique device identification.

• Challenges:

  • Header Size: 40-byte IPv6 header is large for tiny packets (6LoWPAN compresses it).

  • Routing: Traditional IP routing is complex/power-hungry. Use RPL (Routing Protocol for Low-Power and Lossy Networks) in LLNs.

  • Security: IPsec can be heavy; often implemented at gateway/network layer.

5. Infrastructure and Virtualization

Cloud of Things (IoT + Cloud)

• Enabler for Value-Added Services: Cloud provides the scalable backend for IoT data.

  DiagramCANVAS: Draw three layers. Bottom: "IoT Devices & Gateways" (sensors, actuators). Middle: "Cloud Platform" (blocks: Data Ingestion, Storage, Analytics, Device Management, APIs). Top: "Applications & Services" (Smart City Dashboard, Predictive Maintenance App, Consumer App). Arrows: Devices -> Cloud (up), Cloud -> Apps (down).

• Key Cloud Services Used:

  • IaaS: Virtual machines for custom IoT platforms.

  • PaaS: AWS IoT Core, Azure IoT Hub (managed device connectivity, rules engine).

  • SaaS: Ready-made analytics applications.

  • Big Data/ML: Hadoop, Spark, SageMaker for insights.

• Value-Added Services: Remote monitoring, predictive maintenance, real-time analytics, device fleet management.

Network Function Virtualization (NFV) in IoT

• Concept: Decouples network functions (like firewall, routing, gateway) from proprietary hardware, running them as software instances (VNFs) on standard servers.

• Virtualizing IoT Devices/Gateways:

  DiagramCANVAS: Left: "Traditional IoT" - each device type (sensor, camera) connects to a dedicated hardware gateway. Right: "NFV for IoT" - all devices connect to a generic, powerful edge server/cloud. On server, show virtual machines/containers: "Virtual Gateway 1 (for sensors)", "Virtual Gateway 2 (for cameras)", "Virtual Firewall", "Virtual Analytics Engine".

• Benefits for IoT:

  • Flexibility: Deploy/update gateway functions (protocol translation, security) via software.

  • Cost: Use commodity hardware.

  • Scalability: Spin up new virtual gateways on demand.

  • Multi-tenancy: Host multiple isolated IoT solutions on same infrastructure.

Software Defined Networking (SDN) in IoT

• Concept: Separates control plane (decides where traffic goes) from data plane (forwards traffic). Centralized SDN Controller has global view.

• Role in IoT:

  • Dynamic Traffic Management: Prioritize critical sensor data over firmware updates.

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

  • Network Slicing: Create separate virtual networks for different IoT applications (e.g., one slice for medical devices, one for smart meters).

  • Simplified Management: Program network behavior via APIs.

6. Domain-Specific IoT Applications

Industrial IoT (IIoT) vs Automotive IoT

Smart City Applications

• Parking IoT System (Deployment View):

  • Perception: Magnetic/ultrasonic sensors in each parking spot.

  • Network: Sensors → (LoRaWAN/Zigbee) → Gateway → (Cellular/Ethernet) → Cloud.

  • Application: Cloud platform maps spot status → Driver app shows availability → Payment integration.

  • Management: Remote sensor health monitoring, data analytics for pricing.

• Smart Street Lights:

  • Sensors: PIR (motion), ambient light, weather, GPS.

  • Actuator: LED dimmer/controller.

  • Operation: Lights ON only when needed (motion + low light), dim to 30% when no motion. Report faults (bulb out) automatically. Centralized scheduling for events.

7. Implementation and Programming

Arduino Platform & Arduino IDE

• Arduino Board: Open-source microcontroller board (Uno, Nano, Mega). Contains:

  • Microcontroller (ATmega328P on Uno).

  • Digital I/O pins, Analog input pins.

  • USB serial interface for programming/power.

  • Power jack (7-12V DC).

• Arduino IDE: Integrated Development Environment.

  • Sketch: Program file (.ino).

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

  • Libraries: Pre-written code for sensors, displays, communication (e.g., DHT.h, WiFi.h).

  • Compiler/Uploader: Converts code to machine language and flashes to board via USB.

Programming Arduino with Ultrasonic Sensor (HC-SR04)

• Principle: Triggers sound pulse, measures echo return time. Distance = (Time × Speed of Sound) / 2.

• Pin Connections:

  • VCC → 5V

  • Trig → Digital Pin (e.g., 9)

  • Echo → Digital Pin (e.g., 10)

  • GND → GND

• Code Logic:

  1. Set Trig LOW for 2µs, then HIGH for 10µs (trigger pulse).

  2. Read Echo pulse duration (in microseconds) using pulseIn().

  3. Calculate distance: distance = duration * 0.034 / 2; (Sound speed ≈ 340 m/s = 0.034 cm/µs).

  4. Print/send distance.

const int trigPin = 9;

const int echoPin = 10;

long duration;

float distanceCm;

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);

  distanceCm = duration * 0.034 / 2;

  

  Serial.print("Distance: ");

  Serial.print(distanceCm);

  Serial.println(" cm");

  delay(1000);

}

8. Data Management in IoT

Data Storage Approaches in IoT

[!TIP] Exam may ask to compare approaches. Focus on trade-offs: Latency vs. Scale, Cost vs. Capability, Centralized vs. Distributed. Mention data life cycle: raw data at edge, aggregated/processed data in cloud.