UNIT 4: INTERNET OF THINGS (CY-504 B) - EXAM-FOCUSED NOTES

I. IoT FUNDAMENTALS AND ARCHITECTURAL FRAMEWORKS

IoT Definition, Ecosystem, and Core Concepts

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

Role of "Things" and "Internet":

IoT Ecosystem Components:

1. Devices/Things: Sensors, actuators, embedded systems.

2. Connectivity: Networks (Wi-Fi, LPWAN, cellular).

3. Gateways: Protocol translation, data aggregation.

4. Cloud/Platform: Data storage, processing, management.

5. Analytics: Data processing for insights.

6. Applications: User interfaces, dashboards, automation rules.

7. Security: Identity, encryption, access control.

IoT Analytics: Process of examining IoT-generated data to uncover patterns, trends, and insights for decision-making. Purpose: Predictive maintenance, operational efficiency, real-time monitoring.

IoT Reference Architecture and Information Models

Standard Reference Models:

• IETF (Internet Engineering Task Force): Focuses on standard protocols (e.g., CoAP, 6LoWPAN).

• ISO/IEC 30141: Provides a common IoT reference architecture with domains: Application, Communication, Information, Device, Management & Security.

Information Models: Standardized way to represent device capabilities, data formats, and relationships (e.g., using OMA LwM2M, oneM2M). Enables interoperability.

Service-Oriented Architecture (SOA) for IoT

SOA Principles:

• Services are self-contained, loosely coupled.

• Services communicate via standardized interfaces (APIs).

• Reusability and interoperability.

Challenges in IoT-SOA:

• Resource constraints of devices (limited CPU/memory).

• Heterogeneous protocols and data formats.

• Real-time performance requirements.

• Scalability for massive device counts.

Level-Based IoT System Architectures

IoT Planes, Enablers, and Interdependencies

Functional Planes:

• Management Plane: Device provisioning, monitoring, updates.

• Security Plane: Authentication, encryption, access control.

• Data Plane: Actual data flow between devices/cloud.

• Control Plane: Routing, signaling, network management.

IoT Enablers:

• Technologies: RFID, WSN, NFC, LPWAN.

• Platforms: AWS IoT, Azure IoT, Google Cloud IoT.

• Standards: oneM2M, OMA LwM2M, IEEE 802.15.4.

Interdependencies:

Security Plane depends on Management Plane for device identity; Data Plane relies on Communication Enablers; all planes interact with the Application Layer.

IoT Design Methodology

Steps:

1. Requirement Analysis: Define use case, stakeholders, constraints.

2. Logical Design: Abstract system architecture, data models, communication flows (technology-agnostic).

3. Physical Design: Select specific hardware (sensors, MCU), communication protocols, cloud platform.

4. Prototyping & Testing: Build PoC, validate performance.

5. Deployment & Scaling: Roll-out, monitor, optimize.

Logical vs. Physical Design:

IoT Device-Level Considerations

Challenges & Requirements:

• Power: Battery-operated → low-power modes (sleep, duty cycling).

• Processing: Limited CPU → lightweight OS (FreeRTOS), efficient code.

• Memory: Small RAM/Flash → optimized data structures, OTA updates.

• Connectivity: Intermittent network → store-and-forward, local buffering.

• Security: Hard to patch → secure boot, hardware roots of trust.

IoT Platforms

Characteristics:

• Device management (onboarding, monitoring).

• Data ingestion & storage.

• Rule engines & analytics.

• Application enablement (SDKs, APIs).

• Security services.

Components: Device SDKs, gateway software, cloud backend, dashboard.

IoT Communication Models

Communication Patterns:

• Publish-Subscribe: Topics; decouples producers/consumers (MQTT, AMQP).

• Request-Response: Client-server query (CoAP, HTTP).

IoT System Building Blocks

1. Sensing/Actuation Layer: Physical interaction.

2. Network Layer: Connectivity (WSN, LPWAN, IP).

3. Middleware/Platform Layer: Data management, device management.

4. Application Layer: End-user services.

5. Security Layer: Cross-cutting concern.

II. M2M VS. IoT

Machine-to-Machine (M2M) Communication

M2M Service Layer Standardization: ETSI M2M, oneM2M. Defines common service functions (device management, data storage) over diverse networks.

M2M Architecture: Typically point-to-point, siloed systems. Device ↔ Application via proprietary/cellular network. Limited scalability, closed ecosystems.

Limitations:

• Vertical integration (vendor lock-in).

• No standard data models.

• Centralized, not internet-scale.

• Minimal analytics.

Evolution from M2M to IoT

Reasons for Shift:

1. Scalability: IoT uses IP for billions of devices vs. M2M's thousands.

2. Interoperability: Standard protocols (CoAP, MQTT) vs. proprietary.

3. Data-Centric: IoT focuses on data aggregation/analytics; M2M on connectivity.

4. Cloud Integration: IoT leverages cloud platforms; M2M often on-premise.

5. Ecosystem: Open standards vs. closed solutions.

Key Differences:

Data Analytics: M2M vs. IoT

• M2M: Operational data, simple alerts, rule-based. Objective: Monitoring/control.

• IoT: Big Data, predictive analytics, ML integration. Objective: Insights, automation, new services.

III. HARDWARE COMPONENTS

Sensors

Types:

• By Measurand: Temperature, pressure, humidity, motion (PIR), image (camera), gas (MQ-series).

• By Output: Analog (voltage), digital (I2C/SPI), pulse (Hall effect).

Common Commercially Available Sensors:

• DHT11/DHT22: Temperature & humidity.

• MQ-2: Gas (LPG, smoke).

• PIR (HC-SR501): Motion detection.

• Ultrasonic (HC-SR04): Distance.

• BMP180/BMP280: Barometric pressure.

• Camera Modules: OV7670, Raspberry Pi Camera.

Sensor Features & Selection Criteria:

• Accuracy & Precision

• Range & Resolution

• Power Consumption

• Response Time

• Interface (Analog/Digital)

• Cost & Size

• Environmental Robustness

Quantization Error: Error introduced when converting analog signal to digital. It is half of the least significant bit (LSB) value: $$\displaystyle \boxed{E_q = \pm \frac{1}{2} \text{ LSB}} $$. Mitigated by higher ADC resolution.

Actuators

Types:

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

2. Soft: Silicone-based, flexible, for biomedical/soft robotics.

3. Shape Memory Polymer (SMP): Change shape with temperature/light; used in medical stents, deployable structures.

4. Pneumatic: Use compressed air; fast, clean, high force-to-weight. Applications: factory automation, robotics.

Four Common Selection Characteristics:

1. Force/Torque Output: Required mechanical work.

2. Speed/Response Time: How fast actuation occurs.

3. Power Source: Electric, pneumatic, hydraulic.

4. Precision & Control: Position/velocity control resolution.

Microcontrollers and Single-Board Computers

Basic Microcontrollers: 8/16-bit (e.g., 8051, AVR, PIC). Low cost, low power, real-time. Interfacing: GPIO, ADC, UART, SPI, I2C.

Raspberry Pi:

• Architecture: ARM Cortex-A (application processor), runs Linux.

• Differences from Desktop: SoC (System-on-Chip), lower power, no BIOS, GPIO headers, embedded-focused.

• Interfaces:

  • SPI (Serial Peripheral Interface): Full-duplex, synchronous, master-slave. Chip select lines.

  • I2C (Inter-Integrated Circuit): Multi-master, 2-wire (SDA, SCL), addressing.

  • GPIO (General Purpose Input/Output): Software-configurable pins for digital I/O, PWM, etc.

Arduino:

• Applications: Prototyping, education, embedded control.

• Benefits: Simple IDE, large community, vast shields (add-on boards), robust GPIO, analog inputs.

IoT Gateways

Functionality:

• Protocol Translation: e.g., ZigBee/Z-Wave ↔ MQTT over Wi-Fi/Ethernet.

• Data Aggregation & Filtering: Pre-process sensor data.

• Edge Computing: Local analytics, rule execution.

• Security: Firewall, TLS termination, device authentication.

• Offline Operation: Buffering during cloud outage.

Gateway Protocols: MQTT, CoAP, HTTP/HTTPS, Modbus, BACnet.

IV. ENABLING TECHNOLOGIES

Radio Frequency Identification (RFID)

Principles: Uses electromagnetic fields to automatically identify and track tags attached to objects. Tags contain electronically stored information.

Features:

• Passive Tags: No battery, powered by reader's RF. Short range, cheap.

• Active Tags: Battery-powered, longer range, more expensive.

• Frequencies: LF (125-134 kHz), HF (13.56 MHz), UHF (860-960 MHz).

Terminology:

• Tag (Transponder): Attached to object.

• Reader (Interrogator): Emits RF, receives tag response.

• Middleware: Software between reader and application, filters/aggregates data.

• EPC (Electronic Product Code): Unique identifier standard.

Implementation in Smart Things: RFID tags on inventory items → readers at warehouses → data sent to IoT platform for real-time tracking.

Wireless Sensor Networks (WSN)

Concepts: Network of spatially distributed autonomous sensors to monitor physical/environmental conditions. Cooperate to relay data to a central location.

Relation to IoT: WSN is a key enabling technology for IoT, providing the "sensing" layer. Often operates in constrained, low-power modes.

Applications:

• Environmental monitoring (forest fires, pollution).

• Precision agriculture.

• Structural health monitoring.

• Smart metering.

Near Field Communication (NFC)

Definition: Short-range (≤10 cm), low-speed wireless communication technology. Based on RFID (ISO/IEC 14443). Operates at 13.56 MHz.

Applications in IoT:

• Device Pairing: Tap-to-pair (e.g., Bluetooth/Wi-Fi setup).

• Access Control: Smart locks, ticketing.

• Data Exchange: Contactless payment, smart posters.

• Configuration: Transfer network credentials to IoT device.

IEEE 802.15.4 Protocol

Role & Relevance: Defines PHY and MAC layers for low-rate wireless personal area networks (LR-WPANs). Foundation for ZigBee, 6LoWPAN, Thread. Key features: low power, low data rate (250 kbps), star/mesh topologies.

Relation to Higher-Layer Protocols:

• ZigBee: Adds network (mesh routing) and application layers over 802.15.4.

• 6LoWPAN: Adaptation layer enabling IPv6 packets over 802.15.4's small MTU (127 bytes).

Low Power Lossy Networks (LLNs)

Characteristics:

• Low Power: Battery-operated, years of operation.

• Lossy: High packet loss in noisy/unstable RF environments.

• Constrained: Limited memory, processing, bandwidth.

• Large Scale: Thousands of nodes per network.

• Typically Mesh: Multi-hop routing for reliability/coverage.

Use Cases: Smart metering, industrial monitoring, environmental sensing.

V. COMMUNICATION PROTOCOLS

Application Layer Protocols

Constrained Application Protocol (CoAP)

• Basic Operations: GET (read), POST (create), PUT (update), DELETE.

• Request-Response Model: Similar to HTTP but lightweight. Uses confirmable (CON) and non-confirmable (NON) messages.

• Use in Constrained Networks: Designed for devices with limited resources. Uses UDP (not TCP) to reduce overhead. Supports multicast. Often used between devices on the same constrained network (e.g., sensor → gateway) for efficient local communication before aggregation.

Message Queuing Telemetry Transport (MQTT)

• Example: topic: "home/livingroom/temp" → message: {"value": 24.5, "unit": "C"}

• Role in IoT: Publish-subscribe protocol. Lightweight, ideal for unreliable networks. Brokers handle message routing.

• WebSockets: MQTT can run over WebSockets (ws:// or wss://) to traverse web proxies/firewalls and enable browser-based IoT apps.

Advanced Message Queuing Protocol (AMQP)

• Features: Binary, wire-level protocol. Guaranteed delivery, rich messaging patterns (queues, topics), security (TLS/SASL).

• Components: Container (host), Node (endpoint), Link (connection), Session, Channel.

• Frame Types:

  1. Header Frame (message properties).

  2. Body Frame (message payload chunks).

  3. Trailer Frame (optional, e.g., for signatures).

• Message Attributes: message-id, user-id, content-type, delivery-mode (persistent/transient).

• Payload Structure: Arbitrary binary data (often JSON, XML, Protobuf).

Extensible Messaging and Presence Protocol (XMPP)

• How it Improves IoT Services: Built on XML, provides presence (online/offline status), roster (contact list), and extensibility via XEPs (XMPP Extension Protocols). Enables device-to-device chat, real-time control, and federation between IoT domains.

Secure MQTT (SMQTT)

• Secure Message Transfer: Uses attribute-based encryption (ABE). Messages encrypted with access policy (e.g., "sensor_type=temperature AND location=room1"). Only devices with attributes satisfying policy can decrypt. Provides fine-grained, scalable access control without per-device keys.

Network and Adaptation Layer Protocols

IPv6 and 6LoWPAN

• Role of 6LoWPAN: Adaptation layer enabling IPv6 packets over IEEE 802.15.4 (and other LLNs). Performs header compression (RFC 6282) and fragmentation/reassembly to fit IPv6's 1280-byte minimum MTU into 802.15.4's 127-byte frame.

• Differences from IPv4/Native IPv6:

  | IPv4 | Native IPv6 | 6LoWPAN IPv6 | |----------|----------------|------------------| | 32-bit addr | 128-bit addr | 128-bit addr (compressed) | | No built-in security | IPsec mandatory (optional) | Often uses DTLS at app layer | | No auto-config | SLAAC, DHCPv6 | Often uses 6LoWPAN-ND (Neighbor Discovery) | | Large MTU (1500+) | 1280-byte min MTU | Fragmented over small frames |

• Impact on IoT Development: Enables end-to-end IP connectivity from sensor to cloud without gateways doing NAT/protocol translation. Facilitates seamless integration with internet infrastructure.

ZigBee

• Architecture (Layers):

  1. Physical (PHY): Based on IEEE 802.15.4 (O-QPSK, DSSS).

  2. MAC: CSMA/CA, beacon management, security.

  3. Network: Mesh routing (AODV), star, tree topologies. Handles device joining/leaving.

  4. Application: Defines objects (clusters, attributes). ZigBee Device Objects (ZDO) for service discovery/management.

• Types:

  • ZigBee PRO (most common): For mesh networks (lighting, sensors).

  • ZigBee IP: IPv6-based, uses 6LoWPAN.

  • ZigBee RF4CE: Remote control (consumer electronics).

• Relation to IEEE 802.15.4: ZigBee's PHY/MAC are exactly 802.15.4. ZigBee adds network and application layers.

Network Topologies and Connection Types

Classification by Physical Topology:

Wired vs. Wireless:

VI. DATA MANAGEMENT AND CLOUD INTEGRATION

Data Analytics in IoT

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

Edge Streaming Analytics vs. Regular (Cloud) Analytics:

Advantages of Edge Analytics:

1. Reduced bandwidth cost.

2. Enhanced privacy (sensitive data stays local).

3. Improved reliability (local decision-making).

4. Compliance with data sovereignty laws.

Machine Learning in IoT:

• On-device ML: TinyML (TensorFlow Lite Micro) for anomaly detection on microcontroller.

• Cloud ML: Train complex models (deep learning) on aggregated data; deploy inferences to edge.

• Applications: Predictive maintenance (vibration analysis), image recognition (CCTV), demand forecasting.

Structured vs. Unstructured Data in IoT:

Cloud Computing for IoT

Usefulness & Benefits:

• Scalability: Handle millions of devices/data points.

• Cost-Effective: Pay-as-you-go, no upfront infrastructure.

• Managed Services: Device management, databases, analytics engines.

• Global Reach: Data centers worldwide.

• Integration: Easy to connect with other enterprise systems.

Cloud Communication APIs:

• REST/HTTP: Standard web APIs (JSON over HTTPS).

• MQTT: Native IoT protocol, broker often in cloud (AWS IoT Core, EMQX).

• CoAP: Often translated to HTTP/2 at gateway or via proxy in cloud.

Cloud Service Models for IoT:

| IaaS (Infrastructure) | Virtual machines, networks, storage. (e.g., AWS EC2 for IoT backend) | | PaaS (Platform) | Managed IoT platforms (Azure IoT Hub, GCP IoT Core) with device management, rules, integration. | | SaaS (Software) | End-user IoT applications (e.g., smart building management SaaS). |

Cloud IoT Integration Challenges:

• Security: Securing device-to-cloud communication (TLS, certificates).

• Data Volume & Velocity: Ingesting high-frequency sensor data.

• Protocol Translation: Gateways needed for non-IP devices.

• Vendor Lock-in: Proprietary cloud APIs.

Example: Smart factory: PLCs (Modbus) → Gateway (translates to MQTT) → AWS IoT Core → Lambda (processing) → DynamoDB (storage) → QuickSight (dashboard).

Big Data Technologies

Hadoop Ecosystem Role:

• HDFS (Hadoop Distributed File System): Stores massive IoT data (logs, sensor readings).

• MapReduce/YARN: Batch processing of historical IoT data for analytics.

• Hive: SQL-like queries on HDFS data.

• Spark: In-memory processing for faster iterative ML on IoT data streams.

• Kafka: Ingests high-volume IoT data streams into Hadoop/Spark.

VII. SECURITY IN IoT

Need for Security and Privacy in IoT

IoT-Specific Security Requirements:

• Device Authentication: Ensure only legitimate devices connect.

• Data Confidentiality & Integrity: Encrypt data in transit/at rest.

• Secure Updates: OTA firmware updates with signature verification.

• Privacy: Anonymize user data (e.g., location from wearables).

• Resilience: Devices should withstand attacks and fail safely.

Security Models in IoT

1. Layered Security: Apply security at each layer (device, network, platform, application).

2. End-to-End Security: Security from sensor to cloud application (e.g., DTLS from device to broker).

3. Zero Trust: "Never trust, always verify." Authenticate/authorize every request.

4. Privacy by Design: Embed privacy into system architecture from start (data minimization).

Vulnerabilities in IoT Systems

Application/Service Layer Vulnerabilities:

• Injection Flaws (SQL, command): Unsanitized user input in cloud APIs.

• Broken Authentication: Weak token management, session fixation.

• Sensitive Data Exposure: Logging of secrets, insecure storage.

• XML External Entities (XXE): In XML-based protocols (XMPP).

• Security Misconfiguration: Default cloud service permissions.

Attacks on IoT Systems

VIII. IoT APPLICATIONS AND CASE STUDIES

Smart Home

Design with Raspberry Pi and Hardware Devices:

Neat Sketch Description: Draw a central Raspberry Pi 4 as gateway/hub. Connect via GPIO/I2C to:

• DHT22 (temp/humidity sensor) on GPIO4.

• PIR motion sensor on GPIO17.

• Relay module (for light/fan control) on GPIO27.

• Pi Camera via CSI port.

Raspberry Pi runs Node-RED or Python script (with paho-mqtt library). Publishes sensor data to MQTT broker (local or cloud like Mosquitto). Subscribes to control topics to toggle relay. User accesses web dashboard (Flask/React) hosted on Pi or cloud for monitoring/control. All MQTT traffic secured with TLS.

Applications & Benefits:

• Applications: Lighting control, HVAC, security (cameras, door sensors), appliance automation.

• Benefits: Energy savings, convenience, enhanced security, remote monitoring.

Smart City Applications

Smart Parking Architecture:

• Sensors: Ultrasonic/IR in each parking spot → detect occupancy.

• Gateway: Per zone aggregates sensor data (via ZigBee/ LoRa) → sends to cloud via MQTT.

• Cloud Platform: Processes occupancy map, predicts availability.

• Application: Mobile app/display boards show real-time vacant spots, enable reservation/payment.

Smart Traffic Control:

• Sensors: Inductive loops, cameras, GPS from buses.

• Edge Analytics: Traffic light controller adjusts timing based on real-time flow.

• Integration: Emergency vehicle preemption, adaptive signal control.

Smart Lighting Systems:

• Sensors: PIR, ambient light sensors on lamp posts.

• Communication: PLC (Power Line Communication) or RF mesh (ZigBee).

• Control: Dim/brighten based on presence/daylight. Remote monitoring of lamp status/failure.

General IoT Case Study (Example: Smart Agriculture)

Detailed Analysis:

• Problem: Optimize irrigation, reduce water waste, monitor crop health.

• Solution:

  • Devices: Soil moisture sensors (capacitive), temperature/humidity sensors, drones with multispectral cameras.

  • Network: LoRaWAN for long-range, low-power sensor data → gateway → cloud.

  • Platform: AWS IoT Core (device management), S3 (storage), QuickSight (dashboards).

  • Analytics: ML model predicts irrigation needs based on weather forecast + soil data. Edge gateway triggers valve control if soil moisture < threshold.

  • Actuation: Motorized valves control drip irrigation.

• Outcomes: 30% water saving, increased yield, early disease detection.

IX. ADDITIONAL TOPICS

IoT LAN Development Issues

Factors Affecting Development & Implementation:

1. Interference: Wi-Fi/BLE/ZigBee in 2.4 GHz band → coexistence issues.

2. Scalability: Number of devices per access point/gateway.

3. Power Management: Battery life for sensor nodes.

4. Security: Securing local network (WPA3, network segmentation).

5. Protocol Diversity: Supporting multiple RF protocols (ZigBee, BLE, Z-Wave) in one LAN.

6. Reliability: Mesh vs. star reliability in indoor environments.

Software Defined Networking (SDN) in IoT

Concept: Separate control plane (centralized SDN controller) from data plane (switches/routers). Controller programs forwarding rules via OpenFlow.

Maturity for IoT:

• Pros: Flexible network management, dynamic QoS for IoT traffic, easier security policy enforcement.

• Cons: Controller is single point of failure; overhead for constrained devices; not yet widely deployed in large-scale IoT. Maturity: Emerging/Research phase for IoT-specific SDN controllers (e.g., SDN for WSN).

Web Sockets

Role in Real-Time IoT Communication:

• Provides full-duplex communication channel over single TCP connection.

• Enables server push (cloud → browser/dashboard) without polling.

• Used with MQTT over WebSockets for web-based IoT dashboards (e.g., HiveMQ Web Client).

• Low latency, efficient for live updates (stock tickers, sensor dashboards).

Other Short-Notice Topics

Pneumatic Actuators (Covered in III.B.2): Use compressed air. Fast, clean, high power/weight. Applications: factory automation, medical devices.

Quantization Error (Covered in III.A.4): $$\displaystyle \boxed{E_q = \pm \frac{1}{2} \text{ LSB}} $$. Inherent in ADC conversion.

IoT Platforms (Covered in I.H): Characteristics: device management, data ingestion, analytics, APIs. Examples: AWS IoT, Azure IoT Suite.

Exam Tips & Common Pitfalls:

• Logical vs Physical Design: Often asked. Logical = "what" (abstract), Physical = "how" (components).

• CoAP for Same Network: Emphasize UDP, multicast, low overhead for local device-to-device/gateway comms.

• 6LoWPAN vs IPv6: Key difference is header compression & fragmentation for small MTU.

• ZigBee Architecture: Must draw layers (PHY/MAC/Network/App) and mention relation to 802.15.4.

• AMQP Frame Types: Header, Body, Trailer (3 types).

• SMQTT: Attribute-Based Encryption for fine-grained access.

• Edge vs Cloud Analytics: Edge = low latency, bandwidth saving; Cloud = heavy compute.

• Security Models: Know Layered, End-to-End, Zero Trust definitions.

• Smart Home Sketch: Show Pi, sensors, relays, cloud connection, MQTT flow.

• M2M vs IoT: Focus on scale, IP, interoperability, analytics.