UNIT 5: INTERNET OF THINGS

1. IoT FUNDAMENTALS & ARCHITECTURAL FRAMEWORKS

IoT Ecosystem & Core Components

• "Things": Physical objects embedded with sensors, software, and connectivity to collect/communicate data (e.g., smart thermostat, wearable).

• "Internet": The communication infrastructure (IP-based networks) enabling data transfer to cloud/application servers.

• Essential Components:

  1. Sensors/Actuators: Interface with physical world.

  2. Connectivity/Networking: Communication protocols (Wi-Fi, BLE, ZigBee, cellular).

  3. Data Processing & Storage: Edge devices or cloud platforms.

  4. Application & Analytics: Software for visualization, decision-making.

  5. Security: Mechanisms for authentication, encryption, integrity.

• Functionality: Interoperable system where "things" sense, communicate, and act with minimal human intervention.

IoT Architectural Models

• Layered Reference Architecture (Common 5-Layer Model):

  1. Perception Layer: Sensors/actuators for physical world interaction.

  2. Network Layer: Data transmission via wired/wireless networks (gateways, routing).

  3. Service Layer: Core IoT services (device management, data management, security).

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

  5. Management Layer: Cross-layer functions (security, management).

• Characteristics: Scalability, Interoperability, Security, Context-awareness, Intelligence.

• Service-Oriented Architecture (SOA): Treats IoT functions as reusable services. Challenges: Resource constraints of devices, service discovery in dynamic environments, security of service interfaces.

• IoT Design Methodology: Steps typically include: Requirement Analysis → Architecture Design → Technology Selection → Prototyping → Testing → Deployment → Maintenance.

• IoT Information Model: Abstract representation of device capabilities, data, and relationships (e.g., using OMA LwM2M, oneDM).

M2M vs. IoT

[!TIP] Exam Focus: M2M is a subset/enabler of IoT. Key differentiator is IP-connectivity and Internet-scale integration.

2. HARDWARE: SENSORS, ACTUATORS & CONTROLLERS

Sensors

• Definition: Device that converts a physical parameter (temperature, light, pressure) into an electrical signal.

• Common IoT Sensors: Temperature (DS18B20), Humidity (DHT22), Motion (PIR), Proximity (Ultrasonic), Gas (MQ series), Accelerometer (MPU6050), GPS.

• Selection Criteria: Accuracy, range, resolution, power consumption, cost, size, interface (analog/digital, I2C/SPI/UART).

• Quantization Error: Error introduced during analog-to-digital conversion (ADC). The difference between actual analog value and its quantized digital representation.

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

where LSB = Least Significant Bit value = $$\displaystyle \frac{\text{Full Scale Range}}{2^n} $$, $n$ = number of bits.

Actuators

• Role: Convert electrical/control signal into physical action (movement, force, control).

• Types:

  • Mechanical: Motors (DC, stepper, servo), relays, solenoids.

  • Electrical: Heaters, coolers (Peltier), LEDs, buzzers.

  • Pneumatic: Use compressed air (cylinders, grippers).

  • Hydraulic: Use fluid pressure (heavy machinery).

  • Soft Actuators: Made from flexible materials (silicone) for safe human interaction.

  • Shape Memory Polymer (SMP): Change shape with temperature/light stimulus.

• Four Selection Characteristics:

  1. Force/Torque Output: Required mechanical power.

  2. Speed/Response Time: How fast it acts.

  3. Precision/Accuracy: Position/force control resolution.

  4. Operating Environment: Temperature, pressure, corrosive conditions.

Single-Board Computers & Platforms

• Raspberry Pi:

  • Architecture: SoC (System-on-Chip) with ARM CPU, GPU, RAM. Runs full OS (Linux).

  • vs Desktop: Lower power, no BIOS, limited I/O, no internal storage (uses SD card).

  • Key Interfaces:

    • GPIO: General Purpose Input/Output for digital control.

    • I2C: Inter-Integrated Circuit (2-wire serial, multiple devices).

    • SPI: Serial Peripheral Interface (4-wire, high-speed).

• Arduino: Microcontroller board (ATmega). Simpler, real-time, lower power, vast I/O/shield ecosystem. Best for dedicated sensor/actuator control.

• IoT Platforms: Cloud-based ecosystems (AWS IoT, Azure IoT, Google Cloud IoT) providing device management, data ingestion, analytics, and application enablement.

[!TIP] Common Pitfall: Raspberry Pi is a microprocessor-based SBC (needs OS), Arduino is a microcontroller (runs firmware directly).

3. ENABLING TECHNOLOGIES & CONNECTIVITY

WPAN & Low-Power Networks

• IEEE 802.15.4: Foundation standard for low-rate WPANs. Defines PHY and MAC layers for low-power, low-data-rate, long-battery-life devices. Role in IoT: Physical/MAC basis for ZigBee, 6LoWPAN.

• Low-Power Lossy Networks (LLNs): Networks with constrained power, memory, processing, and often lossy links (e.g., WSNs). Challenges: Routing in lossy conditions, scalability, security with limited resources.

• 6LoWPAN (IPv6 over Low-Power WPAN): Adaptation layer allowing IPv6 packets to be carried efficiently over 802.15.4 networks.

  • Key Adaptation: Header compression, fragmentation.

  • vs IPv4/IPv6: Enables direct Internet addressing of constrained nodes, unlike IPv4's address scarcity. Uses link-local and global IPv6 addresses.

Specific Wireless Protocols

• ZigBee:

  • Architecture:

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

    • Router (ZR): Extends network, can route.

    • End Device (ZED): Sleeps, talks only to parent.

  • Protocol Stack: Based on 802.15.4 (PHY/MAC) + ZigBee Network (NWK) + Application (APL) layers.

  • Types: ZigBee PRO (most common, mesh), ZigBee IP (for IP-based), ZigBee RF4CE (remote control).

• Bluetooth Low Energy (BLE): Short-range, low-power, star topology (piconet). Used for intermittent data (beacons, wearables).

Identification & Short-Range Communication

• RFID (Radio Frequency Identification):

  • Principle: Uses radio waves to identify tags via readers.

  • Components: Tag (passive/active/battery-assisted), Reader, Antenna, Backend database.

  • Features: Non-line-of-sight, unique ID, fast read, durable.

  • IoT Implementation: Smart inventory, asset tracking, access control.

• NFC (Near Field Communication): Short-range (≤10 cm), high-frequency (13.56 MHz) wireless. Applications: Contactless payments, device pairing, data exchange (tags).

Network Classification

4. APPLICATION LAYER PROTOCOLS

MQTT (Message Queuing Telemetry Transport)

• Concept: Lightweight publish/subscribe messaging protocol.

• Model: Clients (publishers/subscribers) connect to a central Message Broker. Topics are hierarchical strings (e.g., home/livingroom/temp).

• Role in IoT: Efficient for constrained networks (small header, minimal overhead), supports unreliable networks via QoS levels (0,1,2).

• WebSockets: MQTT can be transported over WebSockets for browser-based clients, but not required. Native uses TCP.

CoAP (Constrained Application Protocol)

• Design: RESTful protocol for constrained devices/networks (like HTTP but lightweight). Uses UDP.

• Request-Response Model:

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

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

• Basic Operations: GET, PUT, POST, DELETE (on resources identified by URIs).

• Use in Constrained Network: Devices on same LLN (e.g., 6LoWPAN) can communicate directly using CoAP. A CoAP-to-HTTP proxy enables communication with non-constrained Internet/cloud services.

AMQP (Advanced Message Queuing Protocol)

• Features: Binary, wire-level protocol for reliable, interoperable messaging. Components: Broker, Connections, Channels, Exchanges, Queues, Bindings.

• Message Attributes: Standardized set (content-type, priority, timestamp, etc.).

• Payload Structure: Arbitrary binary data (frame).

• Frame Types: Protocol header, performative (OPEN, BEGIN, ATTACH, SEND, FLOW, DISPOSITION, etc.), and body frames.

Other Protocols

• XMPP (Extensible Messaging and Presence Protocol): XML-based, decentralized, presence-aware. Improves IoT by enabling real-time, bidirectional communication and device discovery/status in a federated network.

• SMQTT (Secure MQTT): MQTT with lightweight cryptography (e.g., ECC) for secure message transfer. Uses two-layer encryption: payload encryption with symmetric key, key exchange with asymmetric.

• WebSockets: Provides full-duplex communication over a single TCP connection. Role in IoT: Enables real-time, low-latency communication between web clients and IoT servers/gateways.

5. CLOUD COMPUTING, DATA ANALYTICS & STREAMING

Cloud for IoT

• Utility:

  • Scalability: Handle massive device/data growth.

  • Storage: Persistent, durable storage for historical data.

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

  • Management: Centralized device provisioning, monitoring, updates.

• Cloud Service Models in IoT:

  • IaaS: Virtual machines/containers for custom IoT platforms.

  • PaaS: Managed services (AWS IoT Core, Azure IoT Hub) for device connectivity, rules engines.

  • SaaS: End-user IoT applications (fleet management, smart building dashboards).

• Cloud Communication APIs: RESTful APIs (HTTP/HTTPS) for device-to-cloud (ingress) and cloud-to-device (command/control) communication.

Data Analytics in IoT

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

• Edge Streaming Analytics vs. Cloud Analytics:

  | Edge Analytics | Cloud Analytics | | :--- | :--- | | Processing at/near data source (gateway/device). | Processing in centralized cloud data centers. | | Low latency, bandwidth efficient, offline capable. | High compute power, big data storage, complex ML. | | Real-time local decisions. | Long-term trends, cross-device correlation. |

• Advantages of Edge Analytics: Reduced latency, bandwidth savings, improved privacy/security (data local), resilience to network failure.

• IoT Analytics: Role of Things & Internet:

  • Things: Generate raw, high-velocity, often noisy data.

  • Internet: Transports data to aggregation/analysis points (edge/cloud).

• Hadoop Ecosystem in IoT: Used for batch processing of vast historical IoT data. Components: HDFS (storage), MapReduce/Spark (processing), Hive (SQL-like querying).

6. SECURITY & PRIVACY IN IoT

Need for Security in IoT

• Vulnerability of Devices: Limited resources hinder strong security (encryption, secure boot).

• Critical Infrastructure: IoT in power grids, healthcare, transport → high-impact attacks.

• Privacy: Continuous sensing collects intimate personal/behavioral data.

• Attack Surface: Massive number of devices increases entry points.

IoT Security Models & Frameworks

• CIA Triad Adapted:

  • Confidentiality: Protect data from unauthorized access (encryption).

  • Integrity: Ensure data/commands are not altered (hashes, signatures).

  • Availability: Ensure services/devices are accessible (DDoS mitigation).

• Identity-Based Security: Strong device identity (certificates, TPM) as foundation for access control.

• Layered/Defense-in-Depth: Security at device, network, cloud, and application layers.

Vulnerabilities & Attacks

• Observed Vulnerabilities:

  • Hardcoded credentials, weak/default passwords.

  • Insecure network services (open ports).

  • Lack of secure update mechanisms.

  • Insecure data transfer (no encryption).

  • Poor physical security.

• Application/Service Layer Attacks:

  • Injection: Malicious commands via APIs (e.g., CoAP/MQTT).

  • Broken Authentication: Exploiting weak device/cloud credentials.

  • Sensitive Data Exposure: Unencrypted storage/transmission.

  • XXE/XXS: Via web-based management interfaces.

• Various IoT Attacks:

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

  • Botnets: Compromise devices for coordinated attacks.

  • Data Theft/Spoofing: Steal or falsify sensor data.

  • Physical Tampering: Direct access to device hardware.

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

Security & Privacy Issues & Measures

• Issues: Device hijacking, privacy erosion, lack of user awareness, regulatory gaps.

• Measures:

  • Authentication/Authorization: Mutual TLS, OAuth 2.0, certificates.

  • Encryption: AES, TLS/DTLS, lightweight ciphers for constrained devices.

  • Secure Boot & Firmware Updates: Signed images, rollback protection.

  • Network Segmentation: Isolate IoT devices from critical networks.

  • Privacy by Design: Data minimization, anonymization, user consent.

• Challenges: Resource constraints, legacy device integration, scalability of key management, patching deployed devices.

7. IoT SYSTEMS DESIGN & CASE STUDIES

IoT Gateway: Functionality & Role

• Functionality:

  1. Protocol Translation: Convert between device protocols (ZigBee, BLE) and Internet protocols (MQTT, HTTP).

  2. Data Aggregation & Filtering: Pre-process data before cloud.

  3. Edge Computing: Run local analytics/control logic.

  4. Security: Firewall, encryption termination, device authentication.

  5. Device Management: Onboarding, monitoring, firmware updates.

• Role: Bridge between constrained device networks and the cloud/Internet. Acts as a local intelligence hub.

Challenges & Requirements of IoT Devices

• Challenges: Power limitation, processing/memory constraints, cost pressure, size/form factor, security implementation, interoperability.

• Requirements: Low power consumption, reliable connectivity, security by design, scalability, ease of integration, cost-effectiveness.

Difficult Cloud IoT Integration & Overcoming Challenges

• Example Challenge: Integrating thousands of legacy industrial devices using Modbus (serial) with a modern cloud IoT platform.

• Overcoming:

  1. Use IoT gateways at the edge for protocol translation (Modbus TCP → MQTT).

  2. Implement edge analytics to filter/aggregate data, reducing cloud load.

  3. Ensure secure tunneling (TLS) from gateway to cloud.

  4. Use device shadows (e.g., AWS IoT Device Shadow) to maintain device state despite intermittent connectivity.

Application Domains / Case Studies

• Smart Home with Raspberry Pi:

  • Hardware: RPi as central gateway/hub. Sensors: DHT22 (temp/humidity), PIR (motion), relays for lights/fans. Actuators: Servos (door locks), smart plugs.

  • Architecture: Sensors → GPIO/I2C/SPI → RPi (runs local server, Node-RED) → Cloud (MQTT broker) → Mobile App.

  • DiagramCANVAS: Sketch showing RPi connected via GPIO to sensors (DHT22, PIR) and relays. RPi connects to home router, then to cloud. Mobile app accesses cloud.

• Smart Parking Architecture:

  • Perception: Ultrasonic/IR sensors in each parking spot detect occupancy.

  • Network: Sensors connect via ZigBee/6LoWPAN to parking zone gateway.

  • Service/Application: Gateway sends occupancy data via MQTT to cloud. User app shows real-time availability, allows reservation/payment.

• Smart Traffic Control:

  • Sensors (cameras, inductive loops) at intersections feed traffic density to edge controller.

  • Edge analytics optimizes traffic light timing dynamically.

  • Data sent to city traffic management cloud for long-term planning.

8. ADVANCED TOPICS & MISCELLANEOUS

IoT Communication Models & Planes

• Communication Models:

  1. Device-to-Device (D2D): Direct communication (BLE, ZigBee).

  2. Device-to-Cloud (D2C): Device sends data directly to cloud (Wi-Fi, cellular).

  3. Device-to-Gateway (D2G): Device talks to local gateway which handles cloud comms (common for constrained devices).

• IoT Planes & Enablers (Complex Interdependencies):

  • Planes: Management, Security, Data, Application, Device, Connectivity.

  • Enablers: Sensors/Actuators, Connectivity Tech (ZigBee, 5G), Cloud Platforms, Analytics, Security Frameworks, Standards (oneM2M, IETF).

  • Block Diagram: Shows planes (horizontal layers) intersecting with enablers (vertical technologies), highlighting their interdependencies.

  • DiagramCANVAS: Layered block diagram (Planes: Device, Connectivity, Data, Application, Management, Security). Overlapping vertical blocks (Enablers: Hardware, Networks, Cloud, Analytics, Security, Standards) intersecting multiple planes.

Physical vs. Logical Design of IoT

• Logical Design: Defines what the system does. Focuses on functions, data flows, software components, protocols (e.g., "sensor sends temperature data via CoAP to broker").

• Physical Design: Defines how it is built. Focuses on hardware selection (sensor model, Raspberry Pi model), physical connections (GPIO pins, wiring), network topology, power supply.

Software Defined Networking (SDN) in IoT

• Concept: Separates control plane (centralized SDN controller) from data plane (switches/routers).

• Role in IoT: Enables flexible, programmable network management for dynamic IoT topologies (e.g., mobile sensors). Can optimize routing for low-power, enforce security policies centrally.

• Maturity: Not fully mature for large-scale IoT due to scalability of controller, overhead in constrained networks, security of southbound APIs.

Specific Terminology

• Pneumatic Actuator: Uses compressed air to produce mechanical motion. Advantages: clean, safe (spark-free), high force-to-weight. Used in manufacturing, robotics.

• Review of Basic Microcontrollers & Interfacing:

  • Microcontroller (MCU): SoC with CPU, memory (RAM/ROM), I/O peripherals (GPIO, ADC, UART, SPI, I2C) on single chip. Runs firmware (no OS).

  • Interfacing: Connecting sensors/actuators to MCU I/O pins.

    • Digital I/O: Simple on/off (buttons, LEDs).

    • Analog Input: ADC for sensors (potentiometer, analog temp).

    • Serial Comms: UART (serial monitor), SPI (high-speed sensors), I2C (multiple low-speed devices).

    • PWM: Pulse Width Modulation for motor speed/LED dimming.

[!TIP] Exam Focus: Be ready to draw ZigBee architecture, IoT planes diagram, and Smart Home/Raspberry Pi hardware sketch. Always define acronyms first (e.g., "MQTT (Message Queuing Telemetry Transport)").