Internet of Things (CY-504 (B)) - Unit 2 Short Notes

UNIT 2: Internet of Things - Comprehensive Short Notes

I. IoT FOUNDATIONS & ARCHITECTURAL FRAMEWORKS

IoT Ecosystem & Core Concepts

The IoT ecosystem integrates physical objects ("Things") with the Internet to enable data exchange and intelligent decision-making.

• Role of "Things": Physical entities embedded with sensors/actuators to collect/act on data (e.g., temperature sensor, smart lock).

• Role of the Internet: Provides connectivity for data transmission to cloud/application servers.

• Functional Components:

  1. Sensors/Actuators: Interface with physical world.

  2. Connectivity: Networks (Wi-Fi, ZigBee, cellular) for data transfer.

  3. Data Processing: Edge/cloud analytics to derive insights.

  4. Application: User interfaces and business logic (mobile apps, dashboards).

[!TIP]

Common Pitfall: Confusing "Things" as only sensors. Things include both sensors (data input) and actuators (data output).

IoT vs. M2M (Machine-to-Machine)

Reasons for Shift from M2M to IoT:

• Cost reduction in sensors & connectivity.

• Ubiquitous Internet access.

• Cloud computing enabling scalable data processing.

• Standardization of protocols (e.g., MQTT, CoAP).

Logical vs. Physical Design of IoT

Example:

• Logical: "Temperature data is published to a broker."

• Physical: "DHT22 sensor connected to Raspberry Pi GPIO pin, using Python to publish via MQTT."

[!TIP]

Exam Focus: Past papers frequently ask to differentiate these. Use the table structure in answers.

IoT Reference Architectures

• Cisco IoT Architecture: Three layers—Edge (devices/gateways), Platform (data management/analytics), Application (user interfaces).

• IETF Constrained Networks: Focus on low-power devices (6LoWPAN, CoAP).

• IoT-A (IoT Architecture): ARM (Architecture Reference Model) with eight layers from physical to business.

IoT Levels/Tiers (Four-Layer Model)

IoT Service-Oriented Architecture (SOA)

• Principles: Loose coupling, reusability, interoperability, discoverability.

• Components:

  • Services: Atomic functions (e.g., "read temperature").

  • Orchestration: Combines services into workflows.

  • Registry: Service discovery (e.g., UDDI-like).

• Challenges: Latency in constrained networks, security of services, service composition complexity.

IoT Planes and Enablers

• Planes (functional domains):

  • Data Plane: Actual data transfer (sensors to cloud).

  • Control Plane: Management commands (actuator control).

  • Management Plane: Device configuration, monitoring.

  • Security Plane: Authentication, encryption across all planes.

• Enablers (supporting technologies):

  • Identification (RFID, IPv6 addressing).

  • Communication (ZigBee, MQTT).

  • Data Management (stream processing, databases).

  • Security (DTLS, OAuth).

• Complex Interdependencies: E.g., IPv6 addressing (enabler) affects routing (control plane) and scalability (management plane).

II. IOT ENABLING TECHNOLOGIES & NETWORKS

RFID (Radio Frequency Identification)

• Principles: Electromagnetic coupling between tag and reader for wireless identification.

• Components:

  • Tag: Contains chip & antenna (active/passive).

  • Reader: Emits RF signal, receives tag response.

  • Middleware: Filters/aggregates tag data, interfaces with applications.

• Types:

  | Active RFID | Passive RFID | |-----------------------|-------------------------| | Battery-powered | No battery; powered by reader's RF | | Longer range (100m+) | Short range (<10m) | | Costlier | Cheaper | | Used for tracking | Access control, inventory |

• Features: Read/write capability, durability, multi-tag reading.

• Applications: Supply chain, asset tracking, contactless payments.

[!TIP]

Exam Focus: "RFID features" and "RFID vs IoT" are frequent. Emphasize RFID as an enabler for IoT (provides identification).

Wireless Sensor Networks (WSN)

• Definition: Network of spatially distributed autonomous sensors monitoring physical/environmental conditions.

• Node Architecture: Sensor, microcontroller, radio transceiver, battery.

• Relation to IoT: WSNs form the perception layer in IoT; they collect data that is then transmitted via Internet protocols.

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

IEEE 802.15.4 Standard

• Role: Defines PHY and MAC layers for low-rate wireless personal area networks (LR-WPANs). Foundation for ZigBee, 6LoWPAN.

• Frame Structure:

  
  | Preamble | SFD | PHY Header | MAC Header | Payload | CRC |
  
  

• Device Types:

  • FFD (Full-Function Device): Can act as coordinator/router, full protocol stack.

  • RFD (Reduced-Function Device): End device, limited functionality, low cost.

6LoWPAN (IPv6 over Low-Power WPAN)

• Functionality: Adaptation layer enabling IPv6 packets over IEEE 802.15.4 networks.

• Adaptation Layer Tasks:

  • Header Compression: Reduces IPv6 header (40 bytes) to ~1-2 bytes.

  • Fragmentation/Reassembly: IPv6 MTU (1280 bytes) > 802.15.4 frame (127 bytes).

• Differences from IPv4/IPv6:

  • Uses link-local addresses primarily (no global IP needed for every node).

  • Stateless address autoconfiguration (SLAAC) adapted for low-power.

  • No need for NAT due to vast IPv6 address space.

• Role in IoT: Bridges constrained networks to the Internet, enabling end-to-end IP.

ZigBee Protocol

• Architecture (Layers):

  • PHY/MAC: Based on IEEE 802.15.4.

  • NWK (Network): Mesh routing, device association.

  • APL (Application): Application objects, ZDO (ZigBee Device Object), profiles.

• Device Types:

  • Coordinator: Forms network, stores network info, often connected to gateway.

  • Router: Extends network, relays data, can be mains-powered.

  • End Device: Sleeps most of time, communicates only with parent (router/coordinator).

• ZigBee Types:

  • ZigBee PRO: General-purpose, mesh networking.

  • ZigBee IP: Uses IPv6, 6LoWPAN.

  • ZigBee RF4CE: Remote control (low latency).

• Features: Low power, mesh topology (self-healing), secure (AES-128), large network (65k nodes).

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

Low-Power Lossy Networks (LLNs)

• Characteristics:

  • Lossy links: High packet loss due to interference, multi-path fading.

  • Constrained nodes: Limited power, memory, processing.

  • Dynamic topology: Nodes join/leave, mobility.

• Optimization Techniques:

  • RPL (Routing Protocol for LLNs): Objective functions for path selection.

  • Duty cycling: Nodes sleep to save power.

  • Header compression (as in 6LoWPAN).

IoT Communication Models

III. IOT HARDWARE: SENSORS, ACTUATORS & CONTROLLERS

Sensors

• Definition: Transducers that convert physical phenomena (temperature, light) into electrical signals.

• Common Commercially Available Sensors:

  | Sensor Type | Principle | Application | |-------------------|-----------------------------------|------------------------------| | Temperature | Thermocouple, RTD, thermistor | HVAC, weather stations | | Humidity | Capacitive change | Agriculture, indoor climate | | Motion | PIR (infrared) | Security, lighting | | Proximity | IR, ultrasonic, capacitive | Object detection, robotics | | Gas | Chemiresistive (MQ series) | Air quality, leak detection | | Light | Photoresistor, photodiode | Automatic lighting |

• Sensor Selection Criteria:

  • Accuracy: Closeness to true value.

  • Precision: Repeatability of measurements.

  • Sensitivity: Output change per input change.

  • Range: Min/max measurable values.

  • Resolution: Smallest detectable change.

  • Quantization Error:

$$\text{Quantization Error} = \frac{V_{range}}{2^n}$$

where $$\displaystyle V_{range} $$ = full-scale voltage range, $n$ = ADC bits.

• Interfacing:

  • Analog Sensors: Require ADC (Analog-to-Digital Converter) to convert continuous signal to digital.

  • Digital Sensors: Output digital (I2C, SPI, UART); no ADC needed.

Actuators

• Definition: Convert electrical/control signals into physical action (movement, force).

• Types:

  • Electrical: Motors (DC, stepper), solenoids.

  • Mechanical: Relays, brakes.

  • Pneumatic: Air pressure-driven cylinders.

  • Soft: Elastomeric, flexible (e.g., artificial muscles).

  • Shape Memory Polymer (SMP): Deforms with temperature change, returns on cooling.

• Four Common Selection Characteristics:

  1. Operating Force/Torque: Required mechanical output.

  2. Speed of Response: How fast actuator moves.

  3. Positioning Accuracy: Precision of movement (critical in robotics).

  4. Environmental Compatibility: Temperature, humidity, explosion risk.

• Comparison:

  | Type | Advantages | Disadvantages | |----------------|---------------------------------|---------------------------------| | Mechanical | High force, rigid | Noise, wear, bulky | | Soft | Flexible, safe for human contact| Low force, complex control | | SMP | Silent, lightweight | Slow response, temperature-dependent |

[!TIP]

Exam Focus: "Four common characteristics" is a direct past paper question. Memorize the list.

Microcontrollers & Single-Board Computers (SBCs)

• Basic Microcontrollers:

  • Arduino: Easy-to-use, rich I/O, based on AVR/ARM. Good for prototyping.

  • AVR: 8-bit (e.g., ATmega328P), low cost, moderate performance.

  • ARM Cortex-M: 32-bit, low power, high performance (e.g., STM32). Used in commercial IoT devices.

  • Key Interfaces:

    • GPIO: General Purpose Input/Output pins for digital signals.

    • SPI: Serial Peripheral Interface (fast, full-duplex, master-slave).

    • I2C: Inter-Integrated Circuit (multi-master, slower, address-based).

    • UART: Universal Asynchronous Receiver/Transmitter (serial communication).

• Raspberry Pi (SBC):

  • vs Desktop Computer:

    • Runs Linux (OS), desktop runs Windows/macOS.

    • ARM processor (vs x86 in desktops), lower power.

    • GPIO pins for direct hardware interfacing (desktops lack this).

    • No BIOS; boots from SD card.

  • GPIO Pins: 40-pin header, digital I/O, some PWM, I2C, SPI, UART.

  • Use in IoT Prototyping: Acts as gateway or edge device; runs MQTT brokers, Python scripts, connects sensors via GPIO/SPI/I2C.

IV. IOT COMMUNICATION PROTOCOLS (APPLICATION LAYER)

MQTT (Message Queuing Telemetry Transport)

• Model: Publish/Subscribe.

  • Broker: Central server that routes messages.

  • Clients: Publishers (send) and Subscribers (receive).

  • Topics: Hierarchical strings (e.g., home/living/temp). Subscribers subscribe to topics.

• QoS Levels:

  • QoS 0: "At most once" (fire-and-forget).

  • QoS 1: "At least once" (acknowledged, possible duplicates).

  • QoS 2: "Exactly once" (four-step handshake, no duplicates).

• Role in IoT: Lightweight, low bandwidth, suitable for unreliable networks.

• WebSockets: MQTT can run over WebSockets for web browser integration.

CoAP (Constrained Application Protocol)

• Model: RESTful Request/Response (like HTTP but for constrained devices).

• Methods: GET, POST, PUT, DELETE.

• Observe Option: Allows client to observe resource changes (server sends notifications).

• Use in Constrained Networks:

  • Uses UDP (not TCP) to reduce overhead.

  • Small header (4 bytes), binary format.

  • Supports multicast.

• CoAP Request-Response Model:

  • Confirmable (CON): Requires ACK from server.

  • Non-Confirmable (NON): No ACK, for frequent updates.

  • Piggybacked Response: Response sent in ACK of CON request.

  • Separate Response: Response sent later (for long processing).

[!TIP]

Exam Focus: "CoAP request-response model" is a direct question. Explain CON/NON, piggybacking, separate response.

AMQP (Advanced Message Queuing Protocol)

• Features: Binary, wire-level protocol, message-oriented middleware.

• Components:

  • Exchange: Receives messages from producers.

  • Queue: Stores messages until consumed.

  • Binding: Rules connecting exchange to queue.

• Message Attributes: Routing key, priority, timestamp, user properties.

• Payload: Actual message body (binary/string).

• Frame Types (AMQP 1.0):

  1. OPEN

  2. BEGIN

  3. ATTACH

  4. FLOW

  5. TRANSFER

  6. DISPOSITION

  7. DETACH

  8. CLOSE

  9. END

  \boxed{9 \text{ frame types}}

XMPP (Extensible Messaging and Presence Protocol)

• How it Improves IoT Services:

  • Built-in presence (know if device is online).

  • Extensible via XML namespaces (custom payloads).

  • Decentralized (no central broker needed, though servers exist).

  • Real-time messaging suitable for chat-based IoT (e.g., home automation control via chat).

• Use Cases: Smart home control via messaging apps, collaborative IoT systems.

SMQTT (Secure MQTT)

• Secure Message Transfer Mechanism:

  • Uses MQTT over TLS/SSL for encryption.

  • Client authentication via certificates or username/password.

  • Broker and client negotiate secure connection.

  • Addresses MQTT's lack of built-in security.

HTTP/HTTPS in IoT

• Role: Simple, widely supported; used for cloud APIs (RESTful services).

• Limitations:

  • Heavy headers (text-based, verbose).

  • Connection overhead (TCP handshake, no keep-alive by default).

  • Unsuitable for constrained devices due to memory/CPU usage.

  • Prefer CoAP (UDP, binary) or MQTT (lightweight pub/sub) for device-to-device.

Gateway Functionality & IoT Ecosystem Integration

• Gateway Functionality:

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

  • Data Aggregation: Collects data from multiple devices.

  • Security: Firewall, encryption termination.

  • Edge Processing: Local analytics, filtering.

• IoT Ecosystem Workflow:

  
  Sensors/Actuators → Gateway (local network) → Cloud (processing/storage) → Application (user interface)
  
  

• Cloud Communication APIs:

  • RESTful APIs (HTTP/JSON): For device management, data retrieval.

  • MQTT/CoAP: For real-time data ingestion.

  • Vendor-specific (AWS IoT Core, Azure IoT Hub).

• Integration Challenges:

  • Heterogeneity: Multiple device protocols.

  • Scalability: Millions of devices.

  • Security: End-to-end encryption, device authentication.

  • Latency: Real-time requirements vs cloud round-trip.

V. DATA ANALYTICS, CLOUD & EDGE COMPUTING

Role of Data Analytics in IoT

• Transforms raw sensor data into actionable insights.

• Enables predictive maintenance, anomaly detection, optimization.

• Real-time vs Batch:

  • Real-time: Stream processing (e.g., Spark Streaming, Flink) for immediate response (alerts).

  • Batch: Historical analysis (e.g., Hadoop MapReduce) for trends.

Analytics Paradigms: Cloud vs Edge

Advantages of Edge Analytics:

• Reduced bandwidth costs.

• Improved response time.

• Enhanced data privacy.

• Operation during network outages.

IoT Analytics Platforms & Tools

• Hadoop Ecosystem: HDFS (storage), MapReduce (batch processing), Hive (SQL-like).

• Spark: In-memory processing, supports batch & streaming (Spark Streaming, Structured Streaming).

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

• Stream Processors: Apache Flink, Kafka Streams.

Cloud Computing for IoT

• Cloud Service Models in IoT:

  • IaaS: Virtual machines for device management servers (e.g., AWS EC2).

  • PaaS: Development platforms for IoT apps (e.g., Azure IoT Hub).

  • SaaS: Ready-to-use IoT applications (e.g., predictive maintenance dashboards).

• Benefits:

  • Scalability: Handle millions of devices.

  • Storage: Massive data retention.

  • Processing: On-demand compute for analytics.

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

• Integration Models:

  • Direct: Devices connect to cloud via APIs (MQTT/HTTP).

  • Gateway-mediated: Gateway aggregates and forwards.

• Challenges:

  • Vendor lock-in: Proprietary cloud APIs.

  • Latency: Not suitable for hard real-time.

  • Security: Data in transit/at rest.

VI. IOT SECURITY & PRIVACY

Why Security is Required in IoT?

• Unique Challenges:

  • Resource Constraints: Limited CPU/memory for strong crypto.

  • Heterogeneity: Diverse devices, protocols, manufacturers.

  • Scale: Billions of devices, massive attack surface.

  • Physical Access: Devices often in public/unsecured locations.

  • Long Lifespans: Devices deployed for years without updates.

IoT Security Models & Frameworks

• CIA Triad in IoT:

  • Confidentiality: Encrypt data (DTLS for CoAP, TLS for MQTT).

  • Integrity: Hash functions (SHA-256), message authentication codes.

  • Availability: DDoS mitigation, redundancy.

• Layered Security Approach:

  | Layer | Security Measures | |-------------------|----------------------------------------------------| | Perception | Tamper detection, secure boot, hardware crypto | | Network | Firewalls, VPNs, intrusion detection (IDS) | | Application | Secure coding, input validation, authentication | | Management | Secure OTA updates, access control, logging |

Vulnerabilities & Attacks

• Kinds of Vulnerabilities:

  • Weak/default passwords.

  • Unencrypted communications.

  • Insecure web interfaces.

  • Lack of firmware update mechanism.

  • Insecure mobile interfaces.

• Attacks on IoT Systems:

  • Physical Layer: Tampering, side-channel attacks.

  • Network Layer: MITM, DoS, routing attacks (e.g., on RPL).

  • Device Layer: Malware injection, firmware reverse engineering.

  • Application/Service Layer (Frequent):

    • Injection: SQL/command injection via APIs.

    • Cross-Site Scripting (XSS): In web-based IoT interfaces.

    • Denial-of-Service (DoS): Overwhelm device/cloud with requests.

    • Broken Authentication: Weak credentials, session hijacking.

    • Insecure Deserialization: Malicious object reconstruction.

Security Mechanisms & Protocols

• Secure Transport:

  • DTLS (Datagram TLS) for CoAP (UDP).

  • TLS for MQTT/HTTP (TCP).

• Lightweight Cryptography: ECC (Elliptic Curve Crypto) instead of RSA for lower overhead.

• Authentication/Authorization:

  • OAuth 2.0: For delegated access (e.g., third-party apps).

  • X.509 Certificates: Device identity (mutual TLS).

  • Pre-Shared Keys (PSK): For constrained devices.

• Key Management: Secure key distribution (bootstrapping protocols like EST).

[!TIP]

Exam Focus: "Attacks on Application/Service Layer" is a direct question. List specific attacks (injection, XSS, DoS) with brief examples.

VII. IOT APPLICATIONS & CASE STUDIES

Smart Home & Building Automation

• Design with Raspberry Pi (Frequent Past Paper Question):

  • Hardware:

    • Hub: Raspberry Pi (runs Linux, MQTT broker like Mosquitto).

    • Sensors: DHT22 (temp/humidity), PIR (motion), MQ-2 (gas).

    • Actuators: Relays for lights/fans, servo for door lock.

    • Connectivity: ZigBee modules (for low-power sensors) or direct GPIO.

  • Software:

    • Pi runs Python scripts to read sensors (via GPIO/SPI/I2C), publish to MQTT topics.

    • Home automation app (e.g., OpenHAB) subscribes to topics, controls actuators.

    • Cloud integration (e.g., AWS IoT) for remote access.

  • Neat Sketch Description:

    
    [Sensors] → (ZigBee/Wired) → [Raspberry Pi Hub] → (Wi-Fi) → [Cloud] → [Mobile App]
    
                     ↑
    
                [Actuators]
    
    

    Label components: DHT22 → Pi GPIO → Mosquitto broker → Node-RED dashboard → Relay module.

Smart City & Transportation

• Smart Parking Architecture:

  • Sensors: Ultrasonic/IR in each parking spot.

  • Gateway: Aggregates spot status, sends to cloud via 4G/LoRaWAN.

  • Cloud: Processes data, updates availability map.

  • Application: Mobile app shows free spots, allows reservation.

  • Diagram: Sensors → Gateway → Cloud → User App.

• Smart Traffic Control:

  • Sensors: Cameras, loop detectors, GPS from vehicles.

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

  • Central System: Optimizes corridor timing, incident detection.

  • Benefits: Reduced congestion, lower emissions.

Other Domains

• Industrial IoT (IIoT): Predictive maintenance (vibration sensors on machines), asset tracking.

• Smart Agriculture: Soil moisture sensors, automated irrigation, drone-based crop monitoring.

• Healthcare IoT: Wearables (heart rate), remote patient monitoring, smart pills.

• Environmental Monitoring: Air quality sensors, forest fire detection, water level monitoring.

[!TIP]

Exam Focus: "Construct design of Smart Home" and "Smart Parking Architecture" are very frequent. Practice drawing block diagrams with labeled components.