←Back to Subject
Notes
Notes
Study material and explanations
Diagrams
Diagrams
Visualize concepts easily
Mnemonics
Mnemonics
Tricks to remember faster
One Night Prep
One Night Prep
Short and focused revision
Revision
Revision
Quick summary and key points
Important Questions
Important Questions
Practice most relevant questions
Notes

Logical Design of IoT: Functional Blocks & Communication APIs

Study material and explanations for Unit 1

Logical Design of IoT: Functional Blocks and Communication APIs

What is the Logical Design of IoT? (In Simple Words)

While the Physical Design deals with tangible hardware chips, wires, and radio frequencies, the Logical Design is all about the software architecture:

  • Which software modules are needed to make the system work?
  • How do apps, servers, and devices talk to each other?

It mainly covers two key topics:

  1. IoT Functional Blocks: The 6 software building blocks of any IoT system.
  2. IoT Communication APIs: The two main ways apps communicate with devices — REST-based APIs and WebSocket-based APIs.

1. The Six Core IoT Functional Blocks

Every complete IoT system has six functional building blocks:

The Six IoT Functional Blocks
1. Device Block
The software running on the hardware to read sensors, trigger actuators, and monitor device health.
2. Communication Block
Handles network connections and sends/receives packets using Wi-Fi, Bluetooth, or cellular networks.
3. Services Block
Provides essential services like data storage, analytics, device discovery, and message routing.
4. Management Block
Administrative tools to configure devices, install remote firmware updates, and check device status.
5. Security Block
Protects the system using user logins, password authentication, access rights, and data encryption.
6. Application Block
The user interface: mobile apps and web dashboards with buttons, charts, and alert notifications.

2. IoT Communication APIs: REST vs. WebSocket

How does an Android app or a web dashboard exchange data with an IoT device or server? The two primary API styles used in IoT are:

RESTful vs. WebSocket API Comparison
REST-Based APIs (Stateless Request-Response)
Client sends a request, server sends a reply, then connection closes.
Half-duplex, higher overhead per packet.
WebSocket-Based APIs (Persistent Full-Duplex)
Single connection stays open like a phone call.
Full-duplex, two-way, ultra-low overhead for live streaming.

A. REST-Based Communication APIs (Representational State Transfer)

  • Based on the standard HTTP protocol used by the World Wide Web.
  • Client-Server & Stateless: Every request is independent. The server answers and immediately forgets the client; it does not remember past requests.
  • Uses standard HTTP methods:
    • GET: Fetch sensor data (e.g., GET /sensors/temperature to read current room temperature).
    • POST: Send new readings or register a new device on the server.
    • PUT: Update a device setting (e.g., PUT /switches/fan with data {"state": "ON"}).
    • DELETE: Remove a device record or old log entry.
  • Data Format: Data is usually sent as lightweight JSON text.
  • Drawback in IoT: The client must continuously ask the server (“Is the door open yet? Is the door open yet?”). This is called polling. Each HTTP request has large header sizes (500+ bytes), which wastes precious battery and mobile data.

B. WebSocket-Based Communication APIs

  • Designed for Real-Time, Instant Data Updates.
  • How it Works:
    1. The client sends a regular HTTP request asking to upgrade the connection (called the WebSocket Handshake).
    2. The server accepts, and the connection switches to WebSocket.
    3. The TCP connection stays open permanently!
  • Key Advantages for IoT:
    • Full-Duplex (Two-Way): Both the app and the device can send messages at any time. If a smoke sensor detects fire, it can instantly send an emergency alert to your phone without waiting for the phone to ask!
    • Tiny Overhead: Once the connection is open, each message header is just 2 to 10 bytes (compared to 500+ bytes in HTTP).
    • No Polling Needed: The server pushes new data the moment it is available.

3. Quick Comparison Table: REST vs. WebSocket

Parameter REST-Based APIs WebSocket-Based APIs
Communication Style Request - Response (Half-Duplex) Bi-Directional / Full-Duplex (Two-Way)
Connection State Stateless (Closes after each reply) Stateful & Persistent (Stays open continuously)
Who Can Start Talking? Only the Client can start Both Client and Server can send data anytime
Header Overhead High (500+ bytes per HTTP request) Very Low (2 to 10 bytes per frame)
Real-Time Data Poor (requires continuous polling) Excellent (instant push notifications)
Best Used For Daily battery logs, configuration settings Live telemetry graphs, instant smoke/theft alarms

💡 DAVV Exam Preparation Tips

5-Mark Question: “List and briefly describe the six functional blocks of an IoT system.”

  • Name all 6 blocks: Device, Communication, Services, Management, Security, Application.
  • Give a 1-line clear description for each block (e.g. Device = reads sensors, Security = manages authentication and encryption, Application = user app interface).

10-Mark Question: “Explain the Logical Design of IoT. Compare REST-based APIs and WebSocket-based APIs in detail across communication style, connection state, header overhead, and suitability for real-time sensor streams.”

  • Start by defining Logical Design (software architecture, functional blocks, and APIs).
  • Explain all 6 functional blocks clearly with bullet points.
  • Explain RESTful APIs: HTTP methods (GET, POST, PUT, DELETE), stateless nature, JSON formatting, and polling drawbacks.
  • Explain WebSocket APIs: Handshake mechanism, persistent TCP connection, full-duplex communication, and lightweight frame headers.
  • Draw the side-by-side comparison table to score full marks!