Theory
Nine names on one exam line
The syllabus line for this topic reads like a spilled drawer of acronyms: Ethernet, WiFi, WiMAX, LR-WPAN, 2G/3G/4G, IPv6, 6LoWPAN, MQTT, WebSocket.
Memorised flat, they blur by Friday. Organised by ROLE, they become 3 small families with one question each: how do bits move? how are devices addressed? how is the conversation structured?
That organisation is what "physical design of IoT" actually means: the things, and the layered wardrobe of protocols they wear.
Theory
First, the things
In physical-design language, a thing is any device with a unique identity that can sense, actuate and communicate: SmartHostel's tank sensor, gas detector, smart gate, energy meter.
Each thing owns some mix of: sensing hardware, actuation hardware, a processor, a communication interface, and a power source (mains or battery: remember this one; it decides half the protocol choices below).
The thing is the noun. The protocols are its grammar.
At a glance
Family 1: LINK protocols (move bits over one hop)
| Protocol | Nature | SmartHostel fit |
|---|---|---|
| Ethernet (802.3) | Wired, fast, reliable | The hostel server and router, cabled |
| WiFi (802.11) | Wireless LAN, good speed, hungry | Mains-powered devices: cameras, the gate |
| WiMAX (802.16) | Wireless broadband across a city area | Linking a far-off annexe without cables |
| LR-WPAN (802.15.4) | Low-Rate WPAN: tiny power, short range, small data | Battery sensors in every room (ZigBee's base) |
| 2G/3G/4G cellular | Wide-area mobile networks | The water pump house beyond WiFi's reach |
Theory
Family 2: NETWORK: giving every thing an address
Once bits can move, each device needs a findable address.
IPv6 exists because IPv4's roughly 4 billion addresses cannot cover a world where every bulb and tank wants one. IPv6's 128-bit addresses are effectively inexhaustible: every sensor in every hostel on earth can be individually addressable: the unique identity characteristic, delivered.
6LoWPAN (IPv6 over Low-power WPAN) solves the follow-up problem: full IPv6 packets are heavy for LR-WPAN's tiny frames, so 6LoWPAN compresses IPv6 to fit: letting even a coin-cell room sensor be a proper internet citizen.
At a glance
Family 3: APPLICATION protocols (structure the conversation)
| Protocol | Conversation shape | SmartHostel fit |
|---|---|---|
| MQTT | Lightweight publish-subscribe via a BROKER: senders publish to topics, receivers subscribe | Every sensor publishes hostel/tank/level; the dashboard subscribes: made for constrained devices |
| WebSocket | One persistent, full-duplex connection: both sides send anytime | The warden's live dashboard: readings stream in without re-asking (contrast AJAX's ask-answer-hang-up) |
Quiz
A battery-powered room sensor must run for a year on a coin cell, sending a tiny reading every 5 minutes across 10 metres. Which LINK protocol family fits?
- WiFi: it is the fastest wireless option in the table
- LR-WPAN (802.15.4): low power, short range, small data: built for exactly this
- WiMAX: wireless is wireless
- 4G cellular: maximum coverage is always safest
Show the answer
LR-WPAN (802.15.4): low power, short range, small data: built for exactly this
Match the constraints, not the speeds: a year on a coin cell forbids WiFi's power appetite (option A: speed the sensor never needs, paid in battery), and 10 metres of range mocks WiMAX's city-scale radios and 4G's tower budget (options C and D: coverage and cost the job never asked for). LR-WPAN is DESIGNED down to this job: low rate, low power, personal-area range: which is why it underlies ZigBee sensor networks. The exam pattern: every choose-a-protocol question is a constraints checklist: power, range, data size: run it and the answer names itself.
Think first
Why MQTT for machines, and what does 6LoWPAN really buy?
Two think-first questions in one: (a) HTTP served the whole web: why did IoT want MQTT instead for its devices? (b) In one sentence: what exactly does 6LoWPAN add over plain IPv6? Commit to answers, then tap.
Show the answer
(a) HTTP is comparatively heavy: verbose headers, ask-and-answer per exchange: fine for browsers, expensive for a coin-cell sensor speaking 20 bytes. MQTT is minimal by design and publish-subscribe by nature: the sensor publishes its topic and sleeps; whoever cares subscribes at the broker: less power, less traffic, no sensor ever tracking who is listening. (b) 6LoWPAN compresses IPv6 packets to fit low-power WPAN frames: internet citizenship for devices too small to carry full IPv6. Both answers are the same theme: IoT protocols are ordinary internet ideas, slimmed for tiny devices.
Watch out
Protocol-zoo slips
Flat-list answers: 9 names without their 3 roles reads as memorisation; group by family (link, network, application) and each name gains its why.
WiFi vs WiMAX: local area vs metro area: the M is for the missing kilometres.
MQTT as a link protocol: it structures MESSAGES at the application layer and rides on whatever link exists: layers, not alternatives.
"IPv6 is faster than IPv4": the win is ADDRESS SPACE (128-bit), not speed: write addresses, collect the mark.
Theory
One decision, three questions
Fitting a new SmartHostel device is always the same interview: what is the power and range budget? (picks the link family) : does it need to be individually addressable from anywhere? (IPv6/6LoWPAN) : is the conversation publish-and-forget or a live two-way stream? (MQTT vs WebSocket). Next lesson leaves the hardware for the LOGICAL design: IoT's functional blocks, and the 4 communication models: where MQTT's publish-subscribe idea gets its formal seat.
Summary
Key takeaways
- Physical design = things (identifiable sense-act-communicate devices) + their protocols, organised by role.
- Link family moves bits: Ethernet (wired), WiFi (WLAN), WiMAX (metro), LR-WPAN 802.15.4 (low-power sensors), 2G/3G/4G (wide area).
- Network family addresses: IPv6's 128-bit space covers every thing; 6LoWPAN compresses IPv6 for tiny devices.
- Application family converses: MQTT (lightweight publish-subscribe via a broker), WebSocket (persistent full-duplex stream).
- Choose by constraints: power + range + data size for links; conversation shape for application protocols.
- Layers stack: MQTT rides over a link, never replaces one.
- Memory hook: move, address, converse: three families, one wardrobe.