UNIT 3: Internet of Things - Comprehensive Study Notes

1.0 IoT FUNDAMENTALS & ARCHITECTURAL FRAMEWORKS

1.1 IoT Ecosystem & Functional View

• Definition: IoT is a network of physical objects ("things") embedded with sensors, software, and connectivity to collect and exchange data over the internet.

• Functional Components (Four Pillars):

  1. Things: Physical devices/objects with sensing/actuation capabilities.

  2. Internet: Communication infrastructure for data transfer.

  3. Analytics: Processing and deriving insights from collected data (cloud/edge).

  4. People: End-users who interact with the system or receive insights.

• IoT Ecosystem Working: Sensors on "Things" capture data → Data transmitted via gateways/networks → Cloud/edge platform processes & analyzes → Insights delivered to users/applications → Users/Applications trigger actions via actuators.

[!TIP] Exam Focus: Questions often ask to explain the ecosystem or functionality of gateways. Gateways act as bridges between local device networks (e.g., ZigBee) and the internet, handling protocol translation, security, and data filtering.

1.2 IoT Architectural Frameworks & Models

• Layered Reference Models:

  • 3-Layer: Perception (sensors), Network (communication), Application (user interface).

  • 5-Layer: Perception, Transport (network), Processing (middleware/cloud), Application, Business.

  • 7-Layer: More detailed, often aligns with standard protocol stacks (e.g., perception, network, gateway, middleware, application, business, security).

• IoT Service-Oriented Architecture (SOA):

  • Significance: Promotes modularity, reusability, and interoperability. Services (e.g., "temperature monitoring," "light control") are independent, loosely coupled, and discoverable.

  • Challenges: Service discovery in highly dynamic, constrained environments; ensuring low latency.

• IoT "Planes" & Enablers: A conceptual view of six interdependent planes:

  1. Device Plane: Sensors, actuators, hardware.

  2. Communication Plane: Networks & protocols (WPAN, WLAN, cellular).

  3. Service Plane: Application logic, data processing.

  4. Management Plane: Device management, configuration, updates.

  5. Security Plane: Authentication, encryption, access control.

  6. Application Plane: User-facing apps and dashboards.

  Diagram:

  DiagramCANVAS: Six horizontal planes stacked, showing bidirectional interdependencies between all layers. Device at bottom, Application at top.

• IoT Level 3 vs. Level 4 Systems:

  | Feature | Level 3 (Device-Centric) | Level 4 (Service/Cloud-Centric) | | :--- | :--- | :--- | | Focus | Individual device connectivity & data. | Integrated services, cloud analytics, ecosystem. | | Example | Smart thermostat connecting to Wi-Fi. | Full smart home system (thermostat, lights, security) managed via cloud platform with AI. | | Complexity | Lower. | Higher, involving multiple devices, services, and data fusion. |

• Physical vs. Logical Design:

  • Physical Design: Deals with hardware components (sensors, actuators, microcontrollers, communication modules) and their interconnections.

  • Logical Design: Deals with software layers, protocols, data formats, and functional flow (e.g., data acquisition → transmission → processing → action).

1.3 Evolution: M2M to IoT

• M2M (Machine-to-Machine): Point-to-point communication between machines for specific, often closed, tasks (e.g., SCADA systems). Primarily uses proprietary or cellular networks.

• Reasons for Shift to IoT:

  • Need for IP-based connectivity for global reach.

  • Demand for scalability (millions of devices).

  • Requirement for interoperability across vendors.

  • Shift from isolated automation to integrated, intelligent systems with analytics.

  • Move from siloed data to cloud-centric data processing.

• M2M vs. IoT Comparison:

  | Aspect | M2M | IoT | | :--- | :--- | :--- | | Scope | Point-to-point, vertical. | Networked, horizontal, ecosystem. | | Communication | Often proprietary, cellular. | Standard IP-based (IPv6), diverse (LPWAN, WPAN). | | Intelligence | Limited, at device/network edge. | High, in cloud/edge with analytics, AI. | | Data | Siloed, for specific control. | Aggregated, analyzed for insights, shared. |

• M2M Service Layer Standardization: Efforts like oneM2M provide a common service layer (application layer) to standardize M2M/IoT device management, data exchange, and security, enabling interoperability across different verticals.

1.4 IoT Characteristics & Challenges

• Core Characteristics:

  • Connectivity: Anything can connect to the internet.

  • Heterogeneity: Diverse devices, OS, protocols.

  • Scalability: Must handle massive device numbers.

  • Dynamic & Self-Adapting: Devices/contexts change.

  • Semantic Interoperability: Common meaning/understanding of data.

  • Security & Privacy: Critical due to physical-world impact.

• Device Challenges & Requirements:

  • Power: Often battery-powered → need for low-energy protocols & sleep modes.

  • Processing: Limited compute → lightweight protocols, edge processing.

  • Cost: Must be low for mass deployment.

  • Reliability: Must operate in harsh environments.

• IoT LAN Development Issues:

  • Interference in unlicensed bands (2.4 GHz).

  • Network topology management (mesh, star).

  • Device discovery and onboarding.

  • Ensuring Quality of Service (QoS) for diverse traffic.

2.0 HARDWARE BUILDING BLOCKS: SENSORS, ACTUATORS & MICROCONTROLLERS

2.1 Sensors & Sensing

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

• Key Sensor Features: Sensitivity, accuracy, precision, range, resolution, repeatability, response time, stability.

• Sensor Evolution: From large, wired, expensive sensors → miniaturized (MEMS), low-cost, wireless, smart sensors with on-board processing.

• Sensor Classification:

  | Type | Description | Examples | | :--- | :--- | :--- | | Scalar | Measures a single scalar quantity. | Temperature (thermocouple), pressure, humidity. | | Vector | Measures magnitude and direction. | Accelerometer, gyroscope, magnetometer. | | Analog | Continuous output signal (voltage/current). | LM35 (temperature), photoresistor. | | Digital | Discrete output (binary/encoded). | DHT11 (temp/humidity), PIR motion sensor. |

• Common IoT Sensors: Temperature, Humidity, Proximity, Motion (PIR), Gas (MQ series), Pressure, Light (LDR), Accelerometer, GPS.

• Sensor Performance Parameters:

  • Bias: Constant systematic error (offset from true value).

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

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

  • Quantization Error: Error due to digitization of an analog signal; max error = ±½ LSB (Least Significant Bit).

2.2 Actuators

• Role: Convert electrical/control signals into physical action (movement, force, change). The "effectors" of IoT.

• Actuator Types:

  | Type | Principle | IoT Examples | Comparison Notes | | :--- | :--- | :--- | :--- | | Mechanical | Electric motor, solenoid. | Servo motor (robot), relay (switch). | Precise, common, limited force. | | Pneumatic | Compressed air. | Industrial robotic arms. | High force/speed, needs air supply. | | Hydraulic | Pressurized fluid. | Heavy machinery. | Very high force, complex, leaks. | | Soft | Elastomeric, flexible. | Soft grippers, wearable robotics. | Safe for human interaction, compliant. | | SMP-based | Shape Memory Polymer (changes shape with heat). | Self-deploying structures, medical stents. | Biocompatible, slow response. |

• Four Selection Characteristics:

  1. Force/Torque Output: Required strength of action.

  2. Speed/Response Time: How fast it must act.

  3. Precision/Accuracy: Required positional/control accuracy.

  4. Operating Environment: Temperature, pressure, corrosive/explosive atmosphere.

2.3 Microcontrollers & Single-Board Computers (SBCs)

• Basic Microcontrollers (e.g., AVR, ARM Cortex-M):

  • Review: Integrated CPU, memory (RAM/Flash), GPIO, ADC/DAC, communication peripherals (UART, SPI, I2C, USB). Programmed in C/C++/Assembly.

  • Interfacing: Connect sensors/actuators via GPIO (digital), ADC (analog sensors), communication buses (SPI/I2C for digital sensors).

• Raspberry Pi (SBC):

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

  • Features: GPIO pins (40-pin header), HDMI, USB, Ethernet, Wi-Fi/Bluetooth.

  • Interfaces:

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

    • SPI (Serial Peripheral Interface): Synchronous, full-duplex, for high-speed devices (displays, ADC).

    • I2C (Inter-Integrated Circuit): Synchronous, multi-master, multi-slave, for low-speed sensors (only 2 wires).

  • vs Desktop Computer: Lower power, no HDD/PCIe, ARM vs x86, embedded OS, focus on GPIO/interfacing.

• Arduino (Microcontroller Board):

  • Basic Features: Simple, beginner-friendly, based on AVR/ARM MCU. Has built-in programmer, USB interface. Simpler IDE, less resource-intensive.

  • Role in IoT: Ideal for sensor data acquisition and basic actuator control due to real-time performance, low power, and simplicity. Often used as a "sensor node" feeding data to a more powerful hub (like Pi).

• Smart Home Design Example:

  • Hub: Raspberry Pi (runs central logic, cloud connectivity, web server).

  • Sensor Nodes: Arduino/ESP32 with sensors (temp, motion, light) → communicate via ZigBee/Bluetooth to Pi.

  • Actuators: Relays (lights), servo motors (curtains) controlled by Pi via GPIO or through ZigBee endpoints.

  • Sketch Description:

    DiagramCANVAS: Central Raspberry Pi with cloud arrow. Surrounding nodes (Arduino+Temp Sensor, PIR Sensor) connected via ZigBee mesh. Pi GPIO connected to Relay (Light) and Servo (Curtain). Pi also connected to Wi-Fi router.

3.0 COMMUNICATION & NETWORKING TECHNOLOGIES

3.1 Wireless Personal/Local Area Networks (WPAN/WLAN) for IoT

• IEEE 802.15.4:

  • Protocol Spec: Defines PHY (physical radio) and MAC (medium access) layers for low-rate, low-power, low-cost wireless networks.

  • Fundamental Role in IoT: It is the foundational standard upon which ZigBee, 6LoWPAN, and WirelessHART are built. Provides the basic radio link and channel access method (CSMA/CA).

• ZigBee:

  • Architecture (Layers):

    
    Application (APL) - ZigBee Device Objects (ZDO), Application Framework (AF)
    
    Network (NWK) - Routing, device association
    
    MAC - CSMA/CA, GTS
    
    PHY - Based on IEEE 802.15.4
    
    

  • Device Types:

    • Coordinator (ZC): Forms network, stores network info, may be trust center. One per network.

    • Router (ZR): Can route traffic, associate devices, extend network range.

    • End Device (ZED): Only communicates with parent (ZC/ZR), can sleep. No routing.

  • ZigBee Types & Apps:

    • ZigBee PRO: Most common, for general monitoring/control (smart home, lighting).

    • ZigBee IP: Uses IPv6, for internet-connectable devices.

    • ZigBee RF4CE: For remote control (TV, set-top boxes), low latency.

• Bluetooth & BLE:

  • Role: Short-range, device-to-device connectivity. BLE (Bluetooth Low Energy) is crucial for IoT (beacons, wearables, phone-to-device). Uses advertising packets for connectionless data.

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

  • Functionality: Adaptation layer that compresses IPv6 headers to fit within IEEE 802.15.4's small MTU (127 bytes). Enables IPv6 addressing for constrained devices.

  • Contribution: Allows IoT devices to have native IPv6 addresses, enabling direct internet integration without complex gateways (end-to-end IP).

  • vs IPv4/IPv6: Native IPv6 header is 40 bytes; 6LoWPAN compresses it to ~10-20 bytes using header compression (HC1/HC2) and fragmentation.

  • Impact of IPv6: Provides vast address space (~3.4×10³⁸ addresses), essential for trillions of IoT devices. Enables stateless address autoconfiguration (SLAAC).

  [!TIP] Key Distinction: 6LoWPAN runs over IEEE 802.15.4. ZigBee runs over IEEE 802.15.4 but uses its own NWK layer (not IP). ZigBee IP uses 6LoWPAN.

3.2 Identification & Short-Range Communication

• RFID (Radio Frequency Identification):

  • Working: Tag (with ID, antenna) → Reader (emits RF, receives tag response) → Backend System (processes ID).

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

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

  • Link to IoT: RFID provides automatic identification & data capture (AIDC). It is a primary "sensing" technology for "things" (e.g., inventory, smart labels). RFID data feeds into IoT platforms for tracking, management.

• NFC (Near Field Communication):

  • Concept: Short-range (≤10 cm), high-frequency (13.56 MHz) wireless technology. Based on RFID standards. Enables two-way communication.

  • IoT Apps: Device pairing (Bluetooth/Wi-Fi handover), contactless payment, access control, smart poster interaction (tap to get info).

3.3 Wireless Sensor Networks (WSN)

• Definition & Architecture: Network of spatially distributed autonomous sensor nodes to monitor physical/environmental conditions. Nodes collaborate to relay data to a sink/base station. Typically multi-hop, self-organizing mesh.

• WSN vs. IoT:

  | WSN | IoT | | :--- | :--- | | Focus on sensing & data collection. | Focus on integration of sensing, actuation, connectivity, and services. | | Often isolated, application-specific. | Internet-connected, part of larger ecosystem. | | May use proprietary protocols. | Emphasizes IP-based standards (6LoWPAN, CoAP). | | Subset/Enabler of IoT. | Superset encompassing WSN, M2M, internet. |

• Key WSN Applications: Environmental monitoring (forest, agriculture), industrial monitoring (machine health), structural health monitoring, smart metering, battlefield surveillance.

4.0 APPLICATION LAYER PROTOCOLS & MESSAGING

4.1 Message Queueing & Broker-Based Protocols

• MQTT (Message Queuing Telemetry Transport):

  • Role: Lightweight, publish-subscribe messaging protocol. Ideal for constrained networks & devices. Minimizes network bandwidth and code footprint.

  • Key Components:

    • Client: Any device/app publishing or subscribing.

    • Broker: Central server handling message routing.

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

    • QoS (Quality of Service):

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

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

      • 2 (Exactly once): 4-step handshake, guaranteed no duplicates.

  • Use Case: Sensor publishes temperature to sensors/temp1; multiple apps (dashboard, alert system) subscribe.

  • WebSockets: MQTT can be transported over WebSockets for browser-based clients.

• AMQP (Advanced Message Queuing Protocol):

  • Features: Binary, wire-level protocol for reliable, interoperable messaging. More feature-rich/complex than MQTT.

  • Components & Model:

    • Exchanges: Receive messages from producers and route to queues (types: direct, fanout, topic, headers).

    • Queues: Store messages until consumed.

    • Bindings: Rules connecting exchanges to queues.

    • Message Attributes: Metadata (routing key, headers, delivery mode).

    • Payload: Actual application data.

  • AMQP Frame Types: Define communication (e.g., OPEN, BEGIN, ATTACH, FLOW, TRANSFER, DISPOSITION, CLOSE). TRANSFER carries the message; DISPOSITION acknowledges.

4.2 Constrained & Web-Centric Protocols

• CoAP (Constrained Application Protocol):

  • Design: RESTful protocol for constrained devices/networks. Mimics HTTP (GET/POST/PUT/DELETE) but uses UDP, small headers, binary.

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

  • Request-Response Model:

    | Message Type | Reliability | Description | | :--- | :--- | :--- | | Confirmable (CON) | Reliable (ACK required). | Requires ACK/RST response. | | Non-Confirmable (NON) | Unreliable (no ACK). | Fire-and-forget. | | Acknowledgement (ACK) | Reliable. | Response to CON. | | Reset (RST) | Reliable. | Indicates CON not understood/processed. | | Separate Response | | Response sent later, not piggybacked on ACK. |

  • Use in Constrained Networks: CoAP is designed for device-to-device communication on same constrained network (e.g., LLN). Supports proxying (CoAP-to-HTTP gateway) and caching for efficiency.

• XMPP (Extensible Messaging and Presence Protocol):

  • Role in IoT: Based on XML, provides federated, decentralized communication. Excels at presence (device status) and secure, authenticated messaging. Used for device management, chat-based IoT control, and social IoT applications.

4.3 Specialized & Secure Protocols

• SMQTT (Secure MQTT):

  • Mechanism: Adds security layer to MQTT. Uses cryptographic techniques (like RSA, AES) to encrypt the MQTT payload before transmission. Broker cannot read message content. Provides confidentiality and integrity.

  • Secure Transfer Flow: Client encrypts payload → sends encrypted payload via MQTT → Broker stores/forwards encrypted blob → Recipient client decrypts.

• WebSockets:

  • Role: Provides full-duplex, persistent TCP connection between client and server. Enables real-time, bidirectional communication in web-based IoT dashboards and control panels, avoiding HTTP polling overhead.

5.0 CLOUD INTEGRATION, DATA & PLATFORMS

5.1 Cloud Computing for IoT

• Role & Usefulness:

  • Storage: Massive, scalable storage for time-series IoT data.

  • Processing: Elastic compute for batch/stream analytics (e.g., Spark, Flink).

  • Scalability: On-demand resources for device spikes.

  • Services: Pre-built AI/ML, visualization, device management.

• Cloud Service Models in IoT:

  • IaaS (Infrastructure as a Service): Rent VMs, storage, networks (e.g., AWS EC2). IoT company manages OS, middleware, apps.

  • PaaS (Platform as a Service): Platform for app/dev (e.g., Azure IoT Hub, AWS IoT Core). Includes device management, data ingestion, analytics engines.

  • SaaS (Software as a Service): Ready-to-use IoT applications (e.g., Salesforce IoT Cloud, industry-specific apps).

• Cloud Storage Models:

  • Block Storage: Raw volumes (for VMs).

  • File Storage: Hierarchical (e.g., NFS).

  • Object Storage: Massive, scalable (e.g., AWS S3, Azure Blob) – ideal for IoT data (unstructured, vast).

• Cloud Communication APIs: RESTful APIs provided by cloud IoT platforms (e.g., AWS IoT Device SDKs, Azure IoT Hub REST API) for device-to-cloud (telemetry) and cloud-to-device (commands, updates) messaging.

5.2 IoT Platforms & Enablers

• Definition: Integrated software/hardware suites providing device management, data ingestion, storage, analytics, and application enablement.

• Role: Abstract infrastructure complexity, provide SDKs, security, scalability. Examples: AWS IoT Core, Microsoft Azure IoT, Google Cloud IoT Core, IBM Watson IoT, ThingWorx.

• Enablers: Middleware, device SDKs, data brokers (MQTT broker), rule engines, visualization tools.

5.3 Data Analytics in IoT

• Role & Significance: Raw IoT data is valueless without analysis. Analytics extracts insights, predictions, and automations.

  • Descriptive: What happened? (Dashboards, reports).

  • Diagnostic: Why did it happen? (Root cause analysis).

  • Predictive: What will happen? (ML models for failure prediction).

  • Prescriptive: What should we do? (Automated decisions, optimization).

• M2M vs IoT Analytics:

  • M2M: Typically descriptive, rule-based, on isolated datasets.

  • IoT: Predictive/prescriptive, uses big data/ML, correlates multi-source, high-velocity data across the ecosystem.

5.4 Software Defined Networking (SDN) in IoT

• Concept: Separates control plane (centralized SDN controller) from data plane (switches/routers). Controller programs network behavior via open APIs (e.g., OpenFlow).

• Justification for IoT:

  • Dynamic Management: Easily adapt network policies for diverse IoT devices/needs.

  • Security: Centralized policy enforcement, traffic monitoring.

  • Resource Optimization: Efficient routing for constrained networks.

• Maturity: Evolving for IoT. While SDN is mature in data centers, its application in highly constrained, low-power IoT networks (e.g., LLNs) is an active research area due to overhead and controller scalability challenges.

6.0 SECURITY & PRIVACY IN IoT

6.1 Need for Security & Privacy

• Why Required? IoT expands attack surface to physical world. Vulnerabilities can lead to:

  • Physical harm (medical devices, industrial control).

  • Privacy invasion (surveillance, data theft).

  • Infrastructure disruption (smart grid attacks).

  • Financial loss (theft, fraud).

• Major Issues: Weak/default passwords, unpatched firmware, lack of encryption, insecure network services, privacy-invasive data collection.

6.2 IoT Security Models & Frameworks

• Device-Centric: Security embedded in device hardware/software (secure boot, TPM, hardware crypto).

• Network-Centric: Security at network layer (firewalls, segmentation, intrusion detection).

• Data-Centric: Focus on data integrity, confidentiality, and privacy (encryption at rest/in transit, anonymization).

• Lifecycle-Centric: Security贯穿 device lifecycle (manufacturing, deployment, operation, decommissioning).

• Frameworks: NIST IoT Cybersecurity Framework, IoT Security Foundation Guidelines.

6.3 Vulnerabilities & Attacks

• Kinds of Vulnerabilities: Insecure web interfaces, poor authentication, lack of transport encryption, insecure firmware, insecure cloud interfaces, weak device management.

• Attack Spectrum (Application/Service Layer):

  • Impersonation: Attacker pretends to be legitimate device/user.

  • Profile Cloning: Copying identity/credentials of a legitimate device.

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

  • Profile Porting: Moving a device profile to a malicious device.

• Layer-Specific Attacks:

  • Physical: Tampering, side-channel.

  • Link: Jamming, packet injection.

  • Network: Routing attacks (sinkhole, wormhole).

  • Transport: DoS, spoofing.

  • Application: Malware, injection attacks.

6.4 Security Protocols & Mechanisms

• SMQTT: Provides end-to-end message confidentiality by encrypting payload at the application layer, independent of transport security (TLS/DTLS).

• Other Mechanisms:

  • TLS/DTLS: Transport layer security for MQTT, CoAP.

  • IPsec: For network layer security (IPv6).

  • OAuth 2.0: For authorization.

  • Lightweight Ciphers: ASCON, SPECK for constrained devices.

7.0 APPLICATIONS & CASE STUDIES

7.1 Smart Home Automation

• Design with Hardware:

  • Hub/Controller: Raspberry Pi 4 (runs Home Assistant/OpenHAB, MQTT broker).

  • Sensor Nodes: ESP32/Arduino with DHT11 (temp/humidity), PIR (motion), LDR (light). Connect via Wi-Fi or ZigBee (with CC2531 dongle on Pi).

  • Actuators: Relay modules (lights, fans), servo motors (curtains), smart plugs.

  • Communication: MQTT for messaging between nodes and Pi. Pi publishes sensor data, subscribes to control topics.

  • Cloud/Remote Access: Pi connects to cloud MQTT broker (e.g., HiveMQ Cloud) or VPN for remote control via mobile app.

• Neat Sketch Description:

  DiagramCANVAS: Central Raspberry Pi with Wi-Fi symbol. Arrows from Pi to cloud (Internet). From Pi to ZigBee coordinator dongle. ZigBee mesh network connecting to: 1) Node (Arduino+DHT11+PIR) labeled "Living Room Sensor", 2) Node (Arduino+Relay) labeled "Light Control". Pi GPIO connected to "Main Door Relay". Mobile phone connected via cloud to Pi.

• Applications: Lighting control, HVAC automation, security (motion alerts, smart locks), energy monitoring, appliance control.

7.2 Other IoT Application Domains

• Practical Uses Today:

  • Smart City: Smart parking, waste management, traffic monitoring.

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

  • Smart Agriculture: Soil moisture monitoring, precision irrigation, livestock tracking.

  • Healthcare (IoMT): Remote patient monitoring, wearable fitness trackers.

  • Retail: Inventory management, smart shelves, personalized offers.

• WSN Applications: (As in 3.3) Environmental, structural, industrial, agricultural monitoring.

7.3 Detailed Case Study: Smart Agriculture

• Objective: Optimize water usage, increase crop yield, monitor soil/crop health.

• System Components:

  • Sensors: Soil moisture (capacitive), temperature, humidity, pH, NPK (nutrient) sensors. Deployed in field nodes.

  • Nodes: Solar-powered ESP32/Arduino with LoRa module for long-range, low-power communication.

  • Network: LoRaWAN (star-of-stars). Nodes transmit to LoRa Gateway (connected via Ethernet/Wi-Fi).

  • Cloud Platform: AWS IoT Core / ThingsBoard. Ingests data via MQTT.

  • Analytics: Rules engine (if soil moisture < threshold → alert), ML model for yield prediction based on sensor + weather data.

  • Actuation: Control solenoid valves for drip irrigation via LoRa commands.

  • Dashboard: Web/mobile app for farmer to view field maps, sensor readings, alerts, and manually control irrigation.

• Benefits: 20-40% water savings, early disease/pest detection, data-driven decisions.

FINAL EXAM STRATEGY: For 7-mark questions, structure answers as: 1. Clear Definition, 2. Detailed Explanation with Examples, 3. Diagram/Schematic if applicable, 4. Advantages/Limitations/Comparison. Always link concepts to IoT context. For sketch questions, label all components clearly (sensors, actuators, comm links, hub, cloud).