Skip to content
CampusPrep
IT-703 (B) · Internet of Things/Quick Revision Short Notes

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

UNIT 2: Internet of Things - Comprehensive Study Notes

Based on rigorous analysis of RGPV past examination papers (Jun 2025, Dec 2024, May 2024, May 2023, May 2022, Dec 2024, Nov 2023).

1. IoT ARCHITECTURAL FRAMEWORKS & DESIGN

IoT Reference Models & Architectures

  • IoT Conceptual Framework: Defines core entities (Things, Gateways, Network, Cloud/Enterprise) and their interactions.

  • IoT Reference Architectures:

    • Three-Layer Architecture: Perception Layer (sensors/actuators), Network Layer (connectivity), Application Layer (user interfaces/services).

    • Five-Layer Architecture: Adds Middleware/Service Layer (orchestration, data processing) and Business Layer (management, analytics).

    • IoT-A (IoT Architecture): A European research project reference model focusing on IoT-A Reference Model, IoT-A Reference Architecture, and IoT-A Information Model.

  • IoT Information Model: A standardized, abstract representation of IoT devices, their capabilities, data, and relationships (e.g., using OCF, LwM2M). Enables interoperability.

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

Design Paradigms

  • Logical Design vs. Physical Design:

    • Logical Design: What the system does. Defines functional blocks, data flows, protocols, and software architecture. (e.g., "Sensor data → MQTT Broker → Cloud App").

    • Physical Design: How it's built. Specifies hardware components, physical connections, power requirements, and deployment layout.

  • IoT Ecosystem & Functionality: A complex network of device manufacturers, platform providers, application developers, and service consumers. Functionality spans from data acquisition to actionable intelligence.

  • IoT "Planes" & Enablers:

    • Planes: Management Plane, Data Plane, Control Plane, Security Plane.

    • Enablers: Communication protocols, Cloud platforms, Analytics engines, Security frameworks, Standardization bodies.

    • Interdependencies: Security enabler affects all planes; Analytics depends on Data Plane; Management Plane controls all.

    [!TIP] Expect a question asking to draw and explain the IoT planes/enablers block diagram.

  • IoT Levels: Level 3 vs. Level 4 Systems:

    | Feature | Level 3 (Device-Centric) | Level 4 (Cloud-Centric) | | :--- | :--- | :--- | | Primary Intelligence | On the device/gateway | In the cloud | | Data Processing | Local, limited | Massive-scale, complex | | Example | Smart thermostat with local scheduling | Smart city platform aggregating traffic, weather, energy data |

M2M vs. IoT

  • M2M (Machine-to-Machine): Point-to-point or point-to-central communication between machines for specific, often closed, applications (e.g., SCADA, telemetry). Standalone, vertical solutions.

  • Shift from M2M to IoT: Driven by IP adoption, cloud computing, big data analytics, and the need for interoperability across diverse devices and applications.

  • Key Differences:

    | Aspect | M2M | IoT | | :--- | :--- | :--- | | Connectivity | Often proprietary, point-to-point | Standard IP-based, networked | | Scale | Limited, dedicated | Massive, dynamic | | Data | Simple, operational | Complex, contextual, big data | | Architecture | Siloed, vertical | Integrated, horizontal, service-oriented |

  • Data Analytics: M2M analytics is typically descriptive (what happened) and diagnostic (why). IoT analytics is predictive (what will happen) and prescriptive (what should we do) due to data volume, velocity, and variety.

2. IOT DEVICE COMPONENTS: SENSORS & ACTUATORS

Sensors

  • Sensor Node: A complete unit containing a sensor, microcontroller, communication module, and power source.

  • Key Features: Sensitivity, accuracy, range, resolution, repeatability, response time, stability, power consumption.

  • Types:

    • Scalar Sensors: Measure a single physical quantity (e.g., temperature sensor, pressure gauge).

    • Vector Sensors: Measure magnitude and direction (e.g., accelerometer, magnetometer, gyroscope - often combined as IMU).

    • Common Types: Temperature, Humidity, Proximity, Gas (MQ series), Motion (PIR), Optical (LDR, camera), Sound.

  • Analog vs. Digital Sensors:

    | Feature | Analog Sensor | Digital Sensor | | :--- | :--- | :--- | | Output | Continuous voltage/current signal | Discrete digital values (I2C, SPI, UART) | | Interface | Requires ADC (Analog-to-Digital Converter) | Direct MCU interfacing | | Noise Immunity | Susceptible to noise | More robust | | Examples | Thermistor, LM35 | DHT11 (temp/humidity), DS18B20 |

  • Sensor Characteristics for Selection:

    • Bias: Systematic deviation from true value (offset error).

    • Drift: Change in output over time for a constant input.

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

    • Quantization Error: Error due to discretization of analog signal by ADC. For an n-bit ADC with Full Scale (FS), max error is $$\displaystyle \boxed{Q_e = \pm \frac{FS}{2^{n+1}}} $$.

  • Review of Basic Microcontrollers & Interfacing: Low-power MCUs (e.g., ARM Cortex-M, AVR, PIC) are the "brain" of a sensor node. They interface with sensors via GPIO, ADC, and communication buses (I2C, SPI, UART). Interfacing involves signal conditioning, power management, and protocol handling.

Actuators

  • Role & Function: Convert electrical/control signals into physical action (motion, force, heat, light). The "effectors" of an IoT system.

  • Types:

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

    • Soft: Made of flexible materials (silicone, rubber), change shape with pressure/fluid. Used in robotics, medical devices.

    • Shape Memory Polymer (SMP): Change shape in response to temperature/light, then revert. Used in biomedical stents, deployable structures.

    • Pneumatic: Use compressed air/gas to produce motion. Fast, clean, high force-to-weight ratio.

  • Four Common Selection Characteristics:

    1. Force/Torque Output: Required mechanical work.

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

    3. Power Consumption & Source: Voltage/current needs, battery vs. mains.

    4. Precision & Control Resolution: Fine control needed? (e.g., servo vs. simple on/off relay).

3. IOT HARDWARE & EMBEDDED PLATFORMS

Microcontroller Boards

  • Arduino:

    • Features: Simple, open-source, large community, rich I/O (digital/analog pins), limited OS (no native OS), C/C++ based IDE.

    • Role in IoT: Rapid prototyping, sensor interfacing, control tasks. Best for deterministic, real-time, low-complexity applications.

  • Raspberry Pi (e.g., Pi 3):

    • Features: Full-fledged microprocessor (SoC), runs Linux OS (Raspbian), high processing power, RAM, USB, Ethernet, HDMI, Wi-Fi/Bluetooth.

    • Role in IoT: Gateway, edge analytics node, complex application host, multimedia tasks.

  • Raspberry Pi vs. Desktop Computer:

    • Pi is low-power, ARM-based, embedded, lacks BIOS/legacy support, designed for 24/7 operation in constrained environments. Desktop is x86, high-power, general-purpose.

  • Raspberry Pi Interfaces:

    • GPIO (General Purpose Input/Output): 40-pin header for digital I/O, PWM, SPI, I2C, UART.

    • SPI (Serial Peripheral Interface): Synchronous, full-duplex, master-slave. Use: High-speed communication with peripherals (ADC, display).

    • I2C (Inter-Integrated Circuit): Synchronous, multi-master, multi-slave, 2-wire (SDA, SCL). Use: Connecting multiple low-speed sensors/EEPROMs.

Case Study: Smart Home Design with Raspberry Pi

[!TIP] Exam Question: "Construct the Design of Smart home with Raspberry Pi and other hardware devices with neat sketch."

  • Central Hub: Raspberry Pi 3/4 running Home Assistant/OpenHAB.

  • Sensors: DHT22 (temp/humidity), PIR (motion), MQ-2 (gas), LDR (light), door/window magnetic switches.

  • Actuators: Relay modules (control lights/fans), servo motors (door lock), IR blaster (control TV/AC).

  • Connectivity:

    • Pi connects to home Wi-Fi router.

    • Sensors/actuators connect to Pi's GPIO via modules (e.g., relay board) or via short-range protocols (ZigBee/Z-Wave dongle attached to Pi's USB).

  • DiagramCANVAS: Sketch showing Raspberry Pi at center. Arrows from Pi to: 1) Wi-Fi Router (cloud), 2) ZigBee Coordinator dongle, 3) Direct GPIO connections to relay module and sensor cluster (DHT22, PIR). Label all components clearly.

  • Workflow: Sensors → GPIO/ZigBee → Pi (processes data, applies rules) → Actuators/Cloud Notification.

4. COMMUNICATION TECHNOLOGIES (NETWORK & CONNECTIVITY)

Wireless Personal Area Networks (WPAN) & Standards

  • IEEE 802.15.4:

    • Features: Low-rate, low-power, low-cost WPAN standard. Defines PHY and MAC layers. Operates in 2.4 GHz (global), 915 MHz (Americas), 868 MHz (Europe). Supports star, peer-to-peer, mesh topologies.

    • Relation to IoT: Foundation for higher-layer protocols like ZigBee, 6LoWPAN, and WirelessHART. Provides the robust, low-power radio link.

  • ZigBee:

    • Architecture:

      DiagramSEARCH: ZigBee network topology star tree ring

      • Coordinator: Forms network, stores network info, may be trust center.

      • Router: Extends network range, allows child nodes, can relay data.

      • End Device: Leaf node, sleeps to save power, communicates only with parent (coordinator/router).

    • Types:

      • ZigBee PRO (ZigBee 2007/Pro): Most common. Mesh networking, low power, for large networks (home automation, lighting).

      • ZigBee IP: Adds IPv6 networking, designed for internet connectivity.

      • ZigBee RF4CE: For consumer electronics (remote controls).

    • Features: Self-healing mesh, low power, large network capacity (>65,000 nodes), secure (AES-128).

  • Bluetooth in IoT Context:

    • Bluetooth Low Energy (BLE / Bluetooth Smart): Optimized for low power, intermittent data transmission. Key for wearables, beacons. Uses advertising packets for connectionless data.

    • Bluetooth 5: Increased range (4x), speed (2x), broadcast capacity (8x). Enables IoT mesh networking (Bluetooth Mesh).

  • Near Field Communication (NFC):

    • Concept: Very short-range (≤10 cm), 13.56 MHz RFID-based wireless technology. Passive tags powered by reader's field.

    • IoT Applications: Device pairing (tap-to-pair), contactless payments, smart posters (URL/tag access), access control, configuration handover.

IP-Based Networking for Constrained Devices

  • IPv6 & IoT Impact:

    • Vast address space ($$\displaystyle 2^{128} $$) solves IPv4 exhaustion, enabling unique IP for every "thing".

    • Built-in features like autoconfiguration (SLAAC), security (IPsec), multicast efficiency.

    • Enables direct device-to-device and device-to-cloud communication without complex NAT.

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

    • Role: Adaptation layer between IPv6 and IEEE 802.15.4 (or other low-power links).

    • Functionality:

      1. Header Compression: Compresses 40-byte IPv6 header to ~1-2 bytes.

      2. Fragmentation/Reassembly: IPv6 MTU (1280 bytes) > 802.15.4 max frame (127 bytes). 6LoWPAN handles fragmentation.

      3. Mesh Addressing: Supports mesh routing under IPv6.

    • Difference from IPv4/IPv6: Not a new IP version. It's an adaptation layer that makes standard IPv6 packets run efficiently over constrained links. IPv4 has no such standardized adaptation for low-power networks.

Network Topologies & Types

  • Classification:

    | Physical Topology | Connection Type | Diagram | IoT Relevance | | :--- | :--- | :--- | :--- | | Bus | Single backbone cable |

    DiagramSEARCH: bus network topology diagram
    | Rare in IoT (collision issues) | | Star | All nodes connect to central hub |
    DiagramSEARCH: star network topology diagram
    | Common: Wi-Fi access point, hub-and-spoke WSN | | Ring | Nodes connected in a closed loop |
    DiagramSEARCH: ring network topology diagram
    | Token Ring legacy; some industrial IoT | | Mesh | Nodes interconnected, multiple paths |
    DiagramSEARCH: mesh network topology diagram
    | Key for IoT: ZigBee, Thread, 6LoWPAN. Self-healing, robust. | | Tree/Hierarchical | Parent-child hierarchy |
    DiagramSEARCH: tree network topology diagram
    | Common: Cluster-tree WSN, ZigBee. |

  • Issues Affecting IoT LAN Development:

    • Scalability: Network size vs. protocol overhead (e.g., mesh routing tables).

    • Interoperability: Mixing standards (ZigBee vs. BLE vs. Wi-Fi).

    • Power Management: Battery-powered nodes require sleep modes, affecting network availability.

    • Security Overhead: Encryption/authentication consumes bandwidth/power.

    • Physical Constraints: RF interference, building materials affecting signal.

Wireless Sensor Networks (WSN)

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

  • Relation to IoT: WSN is a key enabling technology and subset of IoT. IoT extends WSN by adding internet connectivity, cloud integration, and broader application scope.

    • Example: A WSN of soil moisture sensors in a farm (data hops to a gateway) → Gateway (with 6LoWPAN) → Internet → Cloud analytics → Irrigation control (IoT system).

  • Applications: Environmental monitoring (forest fires, floods), industrial automation (predictive maintenance), smart agriculture, health monitoring, structural health monitoring.

5. APPLICATION LAYER PROTOCOLS & MESSAGING

Message Queueing & Broker-Based Protocols

  • MQTT (Message Queuing Telemetry Transport):

    • Role in IoT: De facto standard for lightweight, publish-subscribe messaging over TCP/IP. Ideal for constrained networks and remote locations.

    • Key Components:

      • Broker: Central server handling message routing.

      • Client: Any device/app publishing or subscribing.

      • Topic: String-based message channel (e.g., home/livingroom/temp). Hierarchical.

      • Session: Connection state with clean/dirty session flag.

      • QoS (Quality of Service):

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

        • 1 (At least once): Acknowledged delivery, possible duplicates.

        • 2 (Exactly once): Four-step handshake, guaranteed single delivery.

    • Basic Operations: CONNECT, PUBLISH, SUBSCRIBE, UNSUBSCRIBE, DISCONNECT, PINGREQ/PINGRESP.

    • WebSockets?: Yes. MQTT can run over WebSockets (ws:// or wss://) to enable browser-based clients.

  • AMQP (Advanced Message Queuing Protocol):

    • Features & Components: Binary, feature-rich, wire-level protocol for enterprise messaging. Components: Exchanges (route messages), Queues (store messages), Bindings (rules linking exchange to queue), Messages (attributes + payload).

    • Message Attributes: Routing key, priority, TTL, delivery mode (persistent/transient), message ID, timestamp.

    • Frame Types: AMQP is a framed protocol. Key Frame Types:

      1. Method Frames: Perform protocol operations (e.g., queue.declare).

      2. Header Frames: Carry message metadata (attributes).

      3. Body Frames: Carry message payload (can be multiple).

      4. Heartbeat Frames: Keep connection alive.

      \boxed{\text{Total Primary Frame Types: 4 (Method, Header, Body, Heartbeat)}}

  • SMQTT (Secure MQTT): Extension of MQTT using Symmetric-key based lightweight encryption (e.g., AES) for payload. Provides confidentiality for constrained devices where TLS is too heavy. Uses a shared key between publisher/subscriber and broker.

Constrained & Web-Oriented Protocols

  • CoAP (Constrained Application Protocol):

    • Use on same constrained network: Designed for resource-constrained devices (low power, low bandwidth, small code footprint). Uses UDP (not TCP), binary header, simple RESTful model. Justification: Minimal overhead, supports multicast, easily proxies to HTTP for internet access. Ideal for device-to-device within a low-power mesh (e.g., 6LoWPAN).

    • Basic Operations: GET, POST, PUT, DELETE (RESTful).

    • Message Types:

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

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

      • Acknowledgement (ACK): Response to CON.

      • Reset (RST): Indicates error or unrecognized message.

    • Request-Response Model:

      1. Client sends CON or NON request to server (URI path).

      2. Server responds with ACK (for CON) containing response code (e.g., 2.05 Content) and optional payload.

      3. For CON, if no ACK, client retransmits after timeout.

      4. Server can also send separate CON/NON response later (separate).

  • XMPP (Extensible Messaging and Presence Protocol):

    • Role in IoT: XML-based, client-server protocol for real-time, bidirectional communication. Improves IoT services by enabling:

      • Device Presence & Discovery: "Available/Offline" status.

      • Direct Device-to-Device Messaging: Via server routing.

      • Rich Metadata & Extensibility: Custom XML stanzas for device control/data.

      • Use Case: Social IoT, collaborative device interaction (e.g., shared whiteboard with IoT devices).

  • WebSockets:

    • Role: Provides full-duplex, persistent TCP connection between client and server over a single HTTP upgrade request. Enables real-time, low-latency push from server to client (browser). In IoT: Used by web-based dashboards to receive live sensor data from cloud broker (e.g., MQTT-over-WebSockets).

RFID (Radio Frequency Identification)

  • Principles & Working:

    1. Tag: Contains microchip (ID/data) and antenna. Passive (no battery, powered by reader's RF field) or active (battery-powered).

    2. Reader/Interrogator: Emits RF energy, receives tag's response.

    3. Backscatter: Passive tag modulates reflected signal to send data.

    4. Middleware: Filters/aggregates tag reads, sends to application.

  • Features: Non-line-of-sight reading, fast, durable, unique ID, various form factors.

  • Link between RFID & IoT: RFID identifies and tracks physical objects automatically. This "smart thing" with unique ID becomes an IoT node when its read events are networked, timestamped, and integrated into an information system (e.g., supply chain visibility, inventory management).

  • Concepts & Terminology:

    • EPC (Electronic Product Code): Unique identifier for physical items.

    • Reader Collision: Multiple readers interfering.

    • Tag Collision: Multiple tags responding simultaneously (anti-collision protocols: ALOHA, binary tree).

    • Read Range: Depends on frequency (LF: cm, HF: m, UHF: m, Microwave: m).

6. CLOUD INTEGRATION, DATA & PLATFORMS

Cloud Computing for IoT

  • Usefulness:

    • Storage: Massive, scalable storage for time-series sensor data (e.g., AWS S3, Azure Blob).

    • Processing: Elastic compute for batch/stream analytics (e.g., AWS Lambda, Azure Stream Analytics), machine learning.

    • Device Management: Scale, monitor, update millions of devices.

  • Cloud Service Models:

    • IaaS (Infrastructure as a Service): VMs, storage, networks. (e.g., AWS EC2). IoT Use: Host custom IoT platforms.

    • PaaS (Platform as a Service): Runtime environment, DBs, middleware. (e.g., AWS IoT Core, Azure IoT Hub). IoT Use: Primary model for IoT - provides device management, messaging, rules engine.

    • SaaS (Software as a Service): End-user applications. (e.g., Salesforce). IoT Use: IoT analytics dashboards, field service apps.

  • Storage Models:

    • Structured: SQL/NoSQL DBs for metadata, device state.

    • Time-Series DBs: InfluxDB, TimescaleDB for sensor data.

    • Object Storage: For raw data blobs, logs.

    • Cold/Hot Storage: Tiered based on access frequency.

  • Cloud Communication APIs & Role: RESTful APIs, MQTT/AMQP endpoints, WebSockets. Role: Secure, standardized interface for devices/gateways to send data to cloud and for applications to send commands to devices. Handle authentication (X.509, tokens), throttling, protocol translation.

  • Difficult Cloud IoT Integration & Solutions:

    • Challenge 1: Legacy Device Integration. Devices using proprietary protocols.

      • Solution: Use gateway with protocol translation (e.g., Raspberry Pi running Node-RED to convert Modbus to MQTT).

    • Challenge 2: Massive Scale & Bursty Data. Millions of devices sending intermittent bursts.

      • Solution: Use cloud-native, serverless ingestion (AWS IoT Core rules → Lambda/Kinesis) with auto-scaling. Implement edge filtering.

    • Challenge 3: Security & Compliance. Data sovereignty, device authentication.

      • Solution: Use cloud provider's IoT Hub with X.509 certs, per-device credentials, VPC endpoints, and regional data centers.

IoT Platforms

  • What are IoT Platforms?: Integrated software/hardware suites providing device management, data ingestion, storage, analytics, and application enablement. Act as middleware between devices and business applications.

  • How they facilitate development & management:

    • Device SDKs & Agents: Simplify device connectivity.

    • Device Registry & Shadow: Track device state, even when offline (device shadow).

    • Rules Engine: Route data to cloud services based on conditions.

    • Dashboard & Visualization: Build operator interfaces quickly.

    • Examples: AWS IoT Core, Microsoft Azure IoT Hub, Google Cloud IoT Core, IBM Watson IoT, open-source (ThingsBoard, Kaa).

Data Analytics in IoT

  • Role & Significance: Transforms raw, high-volume, high-velocity IoT data into actionable insights. Enables:

    • Predictive Maintenance: Anomaly detection from sensor streams.

    • Operational Efficiency: Optimize processes (energy, logistics).

    • New Business Models: Product-as-a-Service, usage-based insurance.

  • Contribution to Effectiveness:

    1. Real-time Processing: Stream analytics (Apache Flink, Spark Streaming) for immediate alerts.

    2. Batch Analytics: Historical trend analysis, model training.

    3. Edge Analytics: Pre-process data at source to reduce bandwidth/latency.

    4. Machine Learning: Build predictive/prescriptive models from IoT data patterns.

7. SECURITY & PRIVACY IN IOT

Need for Security

  • Why Required?:

    • Physical World Impact: Compromised IoT can cause physical harm (medical devices, industrial controls).

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

    • Large-Scale Attacks: Insecure IoT devices form botnets (Mirai) for DDoS.

    • Economic Loss: Theft, fraud, service disruption.

    • Loss of Trust: Fundamental barrier to IoT adoption.

Security Models

  • Adapted CIA Triad:

    • Confidentiality: Encrypt data at rest/in transit (AES, TLS/DTLS).

    • Integrity: Ensure data not altered (HMAC, digital signatures).

    • Availability: Ensure systems/network accessible (DDoS mitigation, redundancy).

  • Extended Principles: Authentication (device, user), Authorization (access control), Non-repudiation.

  • Trust Models:

    • Centralized: Single CA (Certificate Authority) issues certificates. Simple but single point of failure.

    • Distributed/Web-of-Trust: Peer-based trust (like PGP). Complex for large IoT.

    • Blockchain-based: Decentralized, tamper-proof identity/transaction ledger. Emerging for IoT.

Vulnerabilities & Attacks

  • Kinds of Vulnerabilities:

    • Hardware: Physical tampering, side-channel attacks.

    • Software/Firmware: Unpatched bugs, hardcoded credentials, insecure update mechanisms.

    • Network: Insecure protocols, open ports, lack of encryption.

    • Cloud/API: Weak authentication, insecure APIs, data leakage.

  • Attacks on IoT Systems:

    • General: DoS/DDoS (flooding), Eavesdropping/Sniffing, Man-in-the-Middle (MitM), Replay Attacks.

    • Application/Service Layer Specific:

      • Injection Attacks (SQL, command) via cloud APIs.

      • API Abuse: Rate limiting bypass, credential stuffing.

      • Firmware Reverse Engineering to find exploits.

  • Attack Spectrum (Social/Identity):

    • Impersonation: Pretending to be a legitimate device/user.

    • Profile Cloning: Copying a legitimate device's identity (e.g., RFID tag cloning).

    • Profile Hijacking: Taking over an existing device's session/profile.

    • Profile Porting: Moving a profile (e.g., SIM, certificate) to another device to masquerade.

Privacy Issues

  • Major Issues:

    • Informed Consent: Users unaware of data collection by always-on sensors.

    • Data Aggregation & Profiling: Combining data from multiple sources to infer sensitive information (e.g., health status from smart home data).

    • Secondary Use: Data sold/used for purposes beyond original consent.

    • Lack of Anonymization: Raw data tied to individuals.

    • Surveillance: Potential for mass surveillance via IoT networks.

8. CROSS-CUTTING & ADVANCED TOPICS

IoT vs. Web of Things (WoT)

  • IoT: Focuses on connecting physical things to the internet. Underlying technologies: sensors, LPWAN, embedded systems.

  • WoT: A subset/application layer of IoT. Focuses on integrating IoT devices into the World Wide Web using web standards (HTTP, REST, JSON, WebSockets, Semantic Web). Goal: Make things "first-class citizens" of the web, discoverable and usable via web browsers/apps. Key Enabler: Web-based description standards (W3C WoT Thing Description).

Software Defined Networking (SDN) in IoT

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

  • Maturity Justification: Mature in enterprise/data centers, but immature for IoT due to:

    • Overhead: SDN controller communication adds latency/power cost.

    • Scalability: Millions of IoT devices challenge centralized controller.

    • Resource Constraints: IoT nodes cannot run SDN agents.

    • Use Case: SDN can manage IoT gateways/aggregation points or in industrial IoT segments with more powerful edge nodes.

Communication Models

  • Various IoT Communication Models:

    1. Device-to-Device (D2D): Direct communication (e.g., BLE, ZigBee). Low latency, no cloud dependency.

    2. Device-to-Gateway: Device talks to local hub/gateway (e.g., sensor → Raspberry Pi). Protocol translation, local processing.

    3. Device-to-Cloud: Device connects directly to cloud (e.g., Wi-Fi sensor → AWS IoT). Simple, global access.

    4. Gateway-to-Cloud: Gateway aggregates data and sends to cloud.

    5. Device-to-Enterprise: Device communicates directly with enterprise backend (rare, security risk).

    [!TIP] Be prepared to draw these models showing devices, gateways, cloud, enterprise.

Case Studies & Applications

  • Smart Home Automation Systems (Applications):

    • Lighting Control: Smart bulbs (Philips Hue) via ZigBee/BLE.

    • Climate Control: Smart thermostats (Nest) with learning algorithms.

    • Security: Smart locks, cameras with motion detection, video doorbells.

    • Entertainment: Multi-room audio, TV control via voice assistants.

    • Appliances: Smart fridge (inventory tracking), washing machine (remote start/notify).

  • Any One Detailed IoT Case Study (Example: Smart Agriculture):

    • Objective: Optimize irrigation, fertilization, yield.

    • Sensors: Soil moisture, temperature, humidity, NPK (nutrient) sensors, drones (multispectral imaging).

    • Network: LPWAN (LoRaWAN) or WSN (ZigBee) for field sensors; cellular for gateway.

    • Platform: Cloud IoT platform (e.g., Azure IoT) ingests data.

    • Analytics: ML models predict irrigation needs, detect crop disease from drone imagery.

    • Actuation: Automated valve control for irrigation, fertilizer spreaders.

    • Benefits: Water savings (20-40%), increased yield, reduced chemical use.

  • Practical Uses Today:

    • Industrial IoT (IIoT): Predictive maintenance, asset tracking.

    • Smart Cities: Smart parking, waste management, air quality monitoring.

    • Healthcare: Remote patient monitoring, asset tracking in hospitals.

    • Retail: Inventory management, beacon-based promotions.

Final Exam Strategy:

  1. Definitions First: Always start answers with clear, concise definitions (e.g., "MQTT is a lightweight publish-subscribe messaging protocol...").

  2. Diagrams are Crucial: For ZigBee architecture, IoT levels, communication models, smart home sketch – practice drawing clean, labeled diagrams.

  3. Differentiate in Tables: For M2M vs IoT, AMQP vs MQTT, Logical vs Physical design – use comparison tables.

  4. Box Key Formulas: Quantization error, frame types count.

  5. Link Concepts: Explain how 6LoWPAN enables IPv6 on low-power networks, how RFID feeds into IoT, how cloud APIs bridge devices to apps.

  6. Prioritize High-Frequency: Ensure you can write 200-300 words on CoAP, MQTT, AMQP, ZigBee, 6LoWPAN, Security Models/Attacks, Sensors/Actuators, Smart Home Design.

All the Best for Your Exams!

Go to where you left off?

Quick Add to Notes

Save questions, your own notes and screenshots into notes filed by unit. It takes a free account.

Create free account

Have an account? Log in