Internet of Things (IT-703 (B)) - Unit 4 Short Notes

UNIT 4: Internet of Things - Exam-Focused Short Notes

1. IoT Conceptual and Architectural Framework

IoT Ecosystem and Key Components

The IoT ecosystem connects physical "things" to the Internet via a layered architecture:

1. Things/Devices: Sensors/actuators with embedded controllers.

2. Communication Infrastructure: Networks (WPAN, WAN, IP-based).

3. Gateways: Protocol translation, data aggregation, edge processing.

4. Cloud/Data Platform: Storage, analytics, application enablement.

5. Applications: User-facing services (mobile/web dashboards).

6. Management & Security: Device management, identity, security policies.

IoT Reference Architectures

IoT Planes and Interdependencies

• Perception Plane: Physical sensing/actuation. Depends on device capabilities (power, cost).

• Network Plane: Data transport. Depends on perception plane data rate & power, and application plane latency needs.

• Application Plane: Service logic. Depends on network reliability and data format from processing plane.

• Processing/Management Plane: Data handling, device mgmt. Sits between all planes, enforcing security & QoS policies.

Interdependency Example: A low-power sensor (Perception) using 6LoWPAN (Network) for a real-time alert app (Application) requires careful coordination across all planes for battery life and latency.

Characteristics of IoT

• Connectivity: Ubiquitous network access.

• Heterogeneity: Diverse devices, OS, protocols.

• Scalability: Supports massive device counts.

• Dynamic & Self-Adapting: Devices/network topology can change.

• Interoperability: Ability to work across systems.

• Security & Privacy: Critical challenges due to physical exposure.

IoT vs M2M vs WoT: Evolution

IoT System Levels (1 to 4)

Service-Oriented Architecture (SOA) for IoT

• Concept: Treats device capabilities (e.g., "read temperature," "turn on pump") as services discoverable and invocable over the network.

• Components:

  • Service Provider: Device exposing its functionality.

  • Service Registry: Directory (e.g., CoAP .well-known/core) where services are listed.

  • Service Consumer: Application requesting a service.

• Challenges:

  • Resource Constraints: Limited memory/CPU on devices for full SOAP/WS-* stacks.

  • Dynamic Discovery: Devices join/leave frequently.

  • Lightweight Protocols: Need RESTful (CoAP) or publish-subscribe (MQTT) alternatives.

  • Service Composition: Orchestrating services from many heterogeneous devices.

IoT Enablers and Technologies

• Hardware: Microcontrollers (Arduino, ESP32), SBCs (Raspberry Pi), SoCs, low-power sensors/actuators.

• Communication: WPAN (ZigBee, BLE, 802.15.4), LPWAN (LoRaWAN, NB-IoT), IP-based (6LoWPAN, IPv6).

• Identification: RFID, NFC, QR codes, barcodes.

• Middleware/Cloud: IoT Platforms (AWS IoT, Azure IoT, ThingsBoard), Edge Computing frameworks.

• Data & Analytics: Stream processing (Apache Kafka, Flink), Time-series DBs (InfluxDB), ML/AI services.

• Standards: OneM2M, ETSI, IETF (CoAP, MQTT).

2. Devices and Things in IoT

Device Challenges & Requirements

Sensors

• Types:

  • Scalar: Measure single magnitude (e.g., temperature, humidity).

  • Vector: Measure magnitude & direction (e.g., accelerometer, compass).

  • Analog: Continuous output (voltage/current). Requires ADC.

  • Digital: Discrete output (I2C, SPI, UART). Easier interfacing.

• Common IoT Sensors: DHT11/DHT22 (Temp/Humidity), PIR (Motion), MQ series (Gas), BMP180 (Pressure), Ultrasonic HC-SR04 (Distance), Photoresistor (Light).

• Sensor Node Features: Sensing unit, processing unit (MCU), transceiver, power source, memory.

• Sensor Errors:

  • Bias: Systematic offset from true value.

  • Drift: Output changes over time at constant input.

  • Hysteresis: Different output for same input depending on history (increasing vs decreasing).

  • Quantization Error: Difference between analog input and digital output due to finite resolution of ADC. $$\displaystyle \text{Error}_{max} = \pm \frac{1}{2} \text{LSB} $$.

Actuators

• Types & Selection Characteristics:

  | Type | Principle | Selection Characteristics (Force, Speed, Precision, Env. Suitability) | | :--- | :--- | :--- | | Mechanical | Electric motor, solenoid. | High force, moderate speed, good precision. Suitable for clean, dry environments. | | Soft | Elastomers, fluids (pneumatic/hydraulic). | Low force, high speed, compliant. Good for delicate/human interaction. | | Shape Memory Polymer (SMP) | Material changes shape with temp/light. | Moderate force, slow, high precision. Biocompatible, silent. | | Pneumatic | Compressed air. | Very high force/speed, low precision. Dirty, noisy, needs air supply. |

• Role in IoT: Convert digital commands into physical action (e.g., turn valve, move robot arm, adjust thermostat). Forms the "control" loop.

Microcontrollers & SBCs

• Basic Microcontrollers (AVR, ARM, PIC):

  • AVR (Atmel): 8-bit, simple, used in Arduino Uno (ATmega328P).

  • ARM Cortex-M: 32-bit, dominant in industry (low-power, high-performance). STM32, nRF52.

  • PIC (Microchip): 8/16/32-bit, robust, good analog peripherals.

  • Interfacing Techniques:

    • SPI (Serial Peripheral Interface): Full-duplex, master-slave, high-speed. 4 wires (MOSI, MISO, SCK, SS).

    • I2C (Inter-Integrated Circuit): Half-duplex, multi-master, 2 wires (SDA, SCL). Uses addressing.

    • GPIO (General Purpose Input/Output): Simple digital high/low for buttons, LEDs.

• Raspberry Pi vs Desktop:

  • Pi: ARM-based SBC, low-power (~5W), no BIOS, boots from SD card, GPIO headers, runs Linux. For IoT: Edge processing, gateway, prototyping.

  • Desktop: x86/64, high-power, full OS (Windows/Linux), expansion slots, no native GPIO.

• Arduino: Simple IDE, vast community, real-time operation (no OS), huge shield ecosystem. For IoT: Rapid prototyping of sensor/actuator nodes.

Identification Technologies

• RFID (Radio-Frequency Identification):

  • Principle: Tag (with ID) reflects/modulates radio signal from reader. Passive (no battery, powered by reader's signal) vs Active (battery-powered, longer range).

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

  • Applications: Asset tracking, access control, inventory, payment (NFC is subset).

  • IoT Integration: RFID reader acts as a sensor node, sending tag ID to IoT platform for context (e.g., "pallet of milk arrived at warehouse").

• NFC (Near Field Communication):

  • Definition: Short-range (~10 cm) wireless tech based on RFID standards (ISO 14443, 18092). Operates at 13.56 MHz.

  • Technologies/Modes: Reader/Writer (phone reads tag), Peer-to-Peer (two phones), Card Emulation (phone acts as smart card).

  • IoT Applications: Device pairing (Bluetooth/Wi-Fi handover), secure access (door lock), contactless payment, configuration (tap to setup).

3. Communication Infrastructure and Protocols

Fundamentals of Wireless Communication

• Modulation: Encoding data on carrier wave (e.g., ASK, FSK, PSK).

• Multiplexing: Sharing medium. FDM (frequency), TDM (time), CDMA (code).

• Spread Spectrum: Spread signal over wide band for interference resistance & security. FHSS (frequency hopping), DSSS (direct sequence).

• Propagation & Channel: Path loss, multipath fading, shadowing. Channel characteristics (bandwidth, noise, delay spread) dictate protocol design.

WPAN Technologies for IoT

• IEEE 802.15.4:

  • Specification: Defines PHY (O-QPSK in 2.4 GHz, BPSK in 868/915 MHz) and MAC (CSMA/CA, beacon-enabled/non-beacon).

  • IoT Relevance: Foundation for ZigBee, 6LoWPAN, Thread. Low-rate, low-power, low-cost. Max 250 kbps @ 2.4 GHz.

• ZigBee:

  • Architecture: Based on 802.15.4. Adds Network (NWK) and Application (APL) layers.

  • Device Types: Coordinator (forms network), Router (extends network), End Device (sleeps, talks to parent).

  • Topology: Star, Tree, Mesh (self-healing, multi-hop).

  • Types: ZigBee PRO (general, mesh), ZigBee IP (IPv6-based, for larger networks).

  • Applications: Home automation, industrial monitoring, smart lighting.

• Bluetooth & BLE:

  • Bluetooth Classic: High throughput (3 Mbps), high power. For audio/file transfer.

  • BLE (Bluetooth Low Energy): Key IoT tech. Low power, sleep modes, advertising packets. Topology: Star (piconet). Used in wearables, beacons, phone-to-device.

• NFC: As above, for very short-range, simple transactions.

IP-Based Networking for IoT

• IPv6: 128-bit address ($$\displaystyle 2^{128} $$ addresses). Role in IoT: Provides vast address space for billions of devices. Features: autoconfiguration, built-in security (IPsec), efficient header.

• 6LoWPAN (IPv6 over Low-Power WPAN):

  • Functionality: Adaptation layer between IPv6 and 802.15.4 MAC. Compresses IPv6 headers (HC1, HC2) and fragments packets to fit 802.15.4's small MTU (127 bytes).

  • Differences: Not a new protocol. Enables standard IPv6 on constrained links. IPv4 has no such adaptation; native IPv6 is too large for 802.15.4.

Wireless Sensor Networks (WSN)

• Architecture & Node: Hundreds/thousands of resource-constrained sensor nodes (sensor, MCU, radio, battery) deployed to monitor area. Often multi-hop to Sink/Base Station which connects to Internet.

• WSN vs IoT Relationship:

  • WSN is a subset/enabler of IoT. WSN focuses on data collection from a field (often isolated).

  • IoT integrates WSN with Internet, cloud, applications, and bidirectional control (actuation).

  • Example: A WSN monitors soil moisture in a farm. The IoT system uses that WSN data, combines it with weather API, and automates irrigation valves.

• Applications: Environmental monitoring, precision agriculture, structural health, military surveillance.

Network Topologies & IoT LAN Issues

• Physical Topologies:

  • Star: All nodes to central hub. Simple, single point of failure.

  • Mesh: Nodes interconnect. Robust, self-healing, complex routing.

  • Tree: Hierarchical. Balance of star/mesh.

  • Bus: Single shared medium. Simple but collision-prone.

• Issues in IoT LAN Development:

  • Interference: 2.4 GHz band crowded (Wi-Fi, BLE, ZigBee).

  • Scalability: Mesh routing tables grow; network management overhead.

  • Power vs Performance: Deep sleep reduces throughput/latency.

  • Security: Physical access to nodes, wireless eavesdropping.

  • Heterogeneity: Integrating devices using different protocols (ZigBee, BLE, Wi-Fi).

Software Defined Networking (SDN) for IoT

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

• For IoT: Enables centralized, flexible management of diverse, dynamic IoT networks. Can implement QoS for critical traffic, security policies, efficient routing in large WSN/IoT deployments.

• Maturity: Emerging. Challenges: controller scalability for massive IoT devices, southbound protocol overhead on constrained nodes, security of the controller itself.

4. Application Layer Protocols and Messaging Standards

5. Data Management, Cloud Integration, and Analytics

Role of Data Analytics in IoT

• Insight Extraction: Turns raw sensor data into actionable information (e.g., "machine will fail in 48h").

• Real-time Processing: Stream processing for immediate alerts (e.g., security breach, temperature spike).

• Predictive Maintenance: ML models on historical data to predict failures.

• Optimization: Analyze usage patterns to optimize resource consumption (energy, water).

• Context Awareness: Combine sensor data with external sources (weather, calendar) for smarter decisions.

Cloud Computing for IoT

• Service Models in IoT Context:

  • IaaS (Infrastructure): Rent VMs/storage. IoT Use: Host custom IoT platform, databases.

  • PaaS (Platform): Cloud provider manages OS/middleware. IoT Use: AWS IoT Core, Azure IoT Hub—handle device connectivity, rules, basic analytics.

  • SaaS (Application): Ready-to-use apps. IoT Use: Pre-built dashboards (e.g., Grafana Cloud), asset management suites.

• Cloud Storage Models for IoT Data:

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

  • NoSQL Databases: Cassandra, MongoDB. For semi-structured device data, high write throughput.

  • Data Lakes (Object Storage): AWS S3, Azure Blob. Store raw, unstructured data for later batch analysis.

  • Relational (RDBMS): For structured metadata (device registry, user info).

• Communication APIs for IoT-Cloud:

  • Device-to-Cloud: MQTT, HTTP, CoAP over TLS. Cloud provides endpoint (e.g., mqtt://<region>.iot.aws.amazon.com).

  • Cloud-to-Device: Same protocols for commands. Cloud APIs (REST) for app-to-cloud.

IoT Platforms

• Overview: Integrated software/hardware suites for device management, data ingestion, analytics, and application development.

• Key Features:

  • Device Management: Onboarding, provisioning, monitoring, OTA updates.

  • Connectivity: Support for multiple protocols (MQTT, HTTP, LoRaWAN).

  • Data Processing & Storage: Stream processing, database integration.

  • Analytics & Visualization: Built-in dashboards, rule engines, ML integration.

  • Security: Authentication, authorization, encryption.

• Role: Accelerate development, provide scalability, ensure interoperability, reduce operational overhead. Examples: AWS IoT, Azure IoT, Google Cloud IoT Core, ThingsBoard, Kaa.

6. Security and Privacy in IoT

Need for Security in IoT (Threat Landscape)

• Expanded Attack Surface: Billions of physically accessible, often poorly secured devices.

• Critical Impact: Attacks can move from cyber to physical world (e.g., tampering with medical device, industrial control system).

• Privacy Violations: Sensors collect intimate data (home, health, location).

• Botnets: Compromised IoT devices used for DDoS (e.g., Mirai).

Security Models for IoT

1. Layered Security: Apply controls at each layer (device, network, cloud, application).

2. Identity-Centric: Strong device identity (certificates, TPM) as foundation for authentication/authorization.

3. Zero Trust: "Never trust, always verify." Continuous authentication, least privilege access.

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

Vulnerabilities in IoT Devices & Networks

• Device: Hardcoded passwords, unpatched firmware, lack of secure boot, physical tampering.

• Network: Unencrypted traffic, weak Wi-Fi/WPA2, open ports, lack of network segmentation.

• Cloud/App: Insecure APIs, weak authentication, poor data storage practices.

Attacks on IoT Systems (Application/Service Layer)

• MQTT-Specific: Topic Injection (publish to unauthorized topic), Broker Hijacking (compromise broker to read all messages).

• CoAP-Specific: Replay Attacks (re-send captured CON messages), DoS via flooding (NON messages are unconfirmable).

• General Application Layer: Injection Attacks (SQLi, command injection in web interface), Broken Authentication (default credentials), Insecure Deserialization.

• Protocol-Level: DTLS Downgrade (force weaker cipher), Certificate Spoofing.

Privacy Concerns & Mitigation

• Concerns: Continuous surveillance, profiling, data misuse, lack of user consent/control.

• Mitigation:

  • Data Minimization: Collect only necessary data.

  • Anonymization/Pseudonymization: Remove direct identifiers.

  • User Consent & Transparency: Clear privacy policies, opt-in.

  • Local Processing (Edge): Process data on device/gateway; send only insights to cloud.

  • Regulations: GDPR, CCPA compliance.

Security Features in Protocols

• SMQTT: End-to-end encryption (ECC) of payload.

• CoAP: Typically secured with DTLS (Datagram TLS) for UDP, providing confidentiality, integrity, authentication.

• MQTT: Uses TLS (over TCP) for transport security. Does not encrypt payload by default.

• General: Use of X.509 certificates for device identity, OAuth 2.0 for app authorization.

7. IoT Applications and Case Studies

Smart Home Design with Raspberry Pi (Example Sketch)

DiagramCANVAS: A block diagram showing: 1) Raspberry Pi 4 as central gateway/hub connected via Wi-Fi/Ethernet to home router and cloud. 2) Pi's GPIO pins connected to: a) DHT22 sensor (temp/humidity), b) Relay module controlling a lamp, c) PIR motion sensor. 3) Smartphone with an app (e.g., custom Flask/Django web app or MQTT client like MQTT Explorer) connecting to Pi's broker (Mosquitto) over local network/Internet. 4) Cloud platform (e.g., AWS IoT) receiving data from Pi and sending commands back. Arrows show sensor data flow (GPIO->Pi->Cloud->App) and command flow (App->Cloud->Pi->GPIO->Relay).

Components & Role:

• Raspberry Pi: Gateway & Controller. Runs Linux, hosts MQTT broker (Mosquitto), Python scripts for sensor reading/relay control, connects to cloud.

• DHT22: Sensor Node. Provides environmental data.

• Relay Module: Actuator. Isolates high-voltage lamp from Pi's GPIO.

• PIR Sensor: Sensor Node. Detects motion for security/automation.

• MQTT: Protocol. Lightweight pub/sub between Pi (broker), sensors (publishers), app (subscriber), and cloud (bridge).

• Cloud Platform: Remote Access & Analytics. Enables control from outside home, stores history, sets automation rules.

• Mobile App: User Interface. Dashboard for real-time data, manual control, notifications.

Applications: Remote lighting control, temperature monitoring, motion-triggered alerts, integration with voice assistants (via cloud).

Practical IoT Applications (Domains)

• Healthcare: Remote patient monitoring (wearables), smart pills, asset tracking in hospitals.

• Agriculture: Precision farming (soil moisture sensors, automated irrigation), livestock monitoring.

• Industry (IIoT): Predictive maintenance (vibration sensors), asset tracking, supply chain visibility, digital twins.

• Smart Cities: Smart parking, waste management (fill-level sensors), environmental monitoring (air quality), intelligent traffic systems.

• Retail: Inventory management (RFID), personalized offers (beacons), smart shelves.

Detailed Case Study: Smart Waste Management (Example)

• Objective: Optimize waste collection routes, reduce costs.

• System:

  • Sensors: Ultrasonic sensors in bins measure fill level. Powered by battery/solar.

  • Network: LPWAN (LoRaWAN) for long-range, low-power transmission to city-wide gateway.

  • Gateway: LoRaWAN gateway forwards data to cloud via cellular/Ethernet.

  • Cloud Platform: Ingests data, runs analytics (fill rate prediction), stores history.

  • Application: Web dashboard for sanitation department. Shows real-time bin status on map. Algorithm generates optimal daily collection routes only for bins >80% full.

• IoT Tech Used: Sensors (ultrasonic), LPWAN (LoRaWAN), Cloud (AWS IoT), GIS application.

• Benefits: 30-50% reduction in collection trips, fuel savings, reduced emissions, cleaner streets.

8. Additional IoT Concepts and Design Aspects

IoT Gateway: Functionality & Role

• Functionality:

  1. Protocol Translation: Converts between device protocols (ZigBee, BLE, Modbus) and IP-based protocols (MQTT, HTTP) for cloud.

  2. Data Aggregation & Filtering: Collects data from multiple devices, filters/compresses before sending to cloud (reduces bandwidth/cost).

  3. Edge Processing/Computing: Runs local analytics, rules engine. Enables offline operation and low-latency response.

  4. Security: Acts as firewall, performs device authentication, encrypts data to cloud.

  5. Device Management: Onboards, configures, updates connected devices.

• Role in Ecosystem Integration: Bridge between the "things" world and the IT/cloud world. Enables legacy/non-IP devices to join IoT. Provides a point for local control and security enforcement.

Physical vs Logical Design of IoT Systems

IoT Network Components Overview (The Chain)

1. Things/Devices: Endpoints with sensors/actuators (e.g., temperature sensor node).

2. Communication Modules: Radio chips/modules within devices (e.g., ESP32 Wi-Fi/BLE, nRF52840 BLE).

3. Gateways: Local aggregators/translators (e.g., Raspberry Pi running Mosquitto and Node-RED).

4. Communication Infrastructure: The networks themselves (Wi-Fi router, cellular tower, LoRaWAN network server, Internet backbone).

5. Cloud Platform: Centralized data hub and processing engine (AWS IoT, Azure IoT Hub).

6. Applications: Consumer/enterprise software (mobile app, web dashboard, ERP integration).

UNIT 4 EXAM TIPS & COMMON PITFALLS:

• Distinguish Clearly: M2M vs IoT, WSN vs IoT, Logical vs Physical design, ZigBee types (PRO vs IP), CoAP vs MQTT (UDP vs TCP, request-response vs pub/sub), AMQP vs MQTT (enterprise vs lightweight).

• Draw Diagrams: For ZigBee architecture (coordinator, router, end device in mesh), IoT level 3/4 systems, Smart Home sketch (as above), WSN architecture.

• Know Acronyms: Be ready to expand and explain 6LoWPAN, CoAP, AMQP, XMPP, SMQTT, LPWAN, WPAN, SOA.

• Security Focus: Always link vulnerabilities to possible attacks (e.g., "default passwords" -> "brute force login" -> "device hijacking"). Mention DTLS for CoAP, TLS for MQTT, SMQTT for E2E encryption.

• "How" Questions: For "How does 6LoWPAN differ from IPv6?" – Focus on header compression and fragmentation in the adaptation layer. For "How CoAP used on same constrained network?" – Emphasize direct device-to-device communication without gateway using UDP and multicast.

• Numerical/Formula: Only Quantization Error ($$\displaystyle \pm \frac{1}{2} \text{LSB} $$) is formulaic. Understand LSB concept.

• Past Paper Priority: Highest frequency: IoT Architecture/Levels, M2M vs IoT, 6LoWPAN, ZigBee, MQTT/CoAP/AMQP/XMPP/SMQTT, Security Models/Attacks, Sensors/Actuators, Smart Home (RPi), WSN, RFID/NFC, Cloud for IoT. Allocate study time accordingly.