By the end of this section, you will be able to:
Designing a network is like planning a transportation system for a city. You need to think about how many stops (devices) there will be, how far apart they are, how much traffic they generate, what happens if a road closes, and how much the whole thing costs. These five considerations help engineers make smart choices when building IoT networks.
“Before building our network, we need to answer five important questions,” said Max the Microcontroller. “Question 1: What are the devices? A tiny battery sensor needs a different protocol than a powered security camera.”
“Question 2: What is the data like?” added Sammy the Sensor. “I send 50 bytes every 15 minutes – barely any traffic. But a video camera sends megabytes per second! The data volume and frequency determine how much bandwidth you need.”
Lila the LED continued, “Question 3: What enterprise infrastructure exists? If there are already Wi-Fi access points and Ethernet switches in the building, use them! Question 4: How do we handle IP addresses? With thousands of devices, you need a systematic addressing plan – subnets by floor, by device type, or by zone.”
“And Question 5: What is the physical and logical topology?” finished Bella the Battery. “Where are the devices physically located? Where do the gateways go? How does data flow from sensor to cloud? Answer all five questions BEFORE buying hardware, and you will avoid expensive redesigns later. Planning saves money!”
Before studying this chapter, review:
Once the scope and types of devices to be connected have been determined at Level 1, the interconnectivity requirements of Level 2 can be determined.
Low power and passive devices may require the application of IoT-specific, and perhaps proprietary, communication protocols, especially if the device does not have software to operate and process protocols in the TCP/IP suite.
Communications decisions may include:
Complex IoT deployments could include a combination of these media – the actual technologies being dependent on the devices used and the scale of the interconnections required.
When selecting devices for your IoT deployment, consider:
The form of the data to be communicated will determine the protocols and network infrastructure required.
The aggregation of data and Fog computing requirements, from Level 2 to Level 3 and onto Level 4 of the Reference Model, will mean that the operating systems of the devices at these levels will have to process IPv4 or IPv6 packets for network and Internet communications.
Key considerations:
| Data Type | Volume | Frequency | Recommended Protocol |
|---|---|---|---|
| Temperature readings | Small (few bytes) | Periodic (minutes) | MQTT, CoAP |
| Video streams | Large (MB/s) | Continuous | HTTP/RTSP over Wi-Fi/5G |
| Motion detection | Small (boolean) | Event-driven | MQTT, WebSocket |
| GPS tracking | Medium (tens of bytes) | Periodic (seconds) | MQTT, UDP |
| Industrial telemetry | Medium | High frequency (ms) | OPC UA, Modbus TCP |
Processes at Level 4 and above in the IoT reference model generally occur far from the devices at the edge of the network.
The network devices operating at these levels are the Ethernet switches, routers, and servers already in use in corporate data networks and the Internet, and would not usually require any specific adaptation for IoT data.
Network design decisions for these devices would be based on:
For mission-critical IoT applications (industrial control, healthcare monitoring, autonomous vehicles), design must include:
To manage the potentially large number of end devices in an IoT, design decisions will also include IP addressing schemes for those devices that can run TCP/IP.
These decisions would include:
| Aspect | IPv4 + NAT | IPv6 |
|---|---|---|
| Address Space | ~4 billion (limited) | 340 undecillion (unlimited) |
| Address Assignment | DHCP required | SLAAC auto-configuration |
| End-to-End | NAT breaks it | Native support |
| Header | Variable 20-60 bytes | Fixed 40 bytes (simpler processing) |
| Deployment | Widely supported | Growing adoption |
| Best For | Small-medium IoT | Large-scale IoT |
Advantages and disadvantages of each method:
Static IP Addressing:
Dynamic IP Addressing (DHCP):
IPv6 SLAAC:
As these decisions are being made, the design details need to be documented.
A logical topology will show: - The range and types of end devices - The communication flows between them - Labels and addressing used - Protocol relationships and data flow
A physical topology will be created to show: - Exactly where devices are to be installed - Connecting cabling (if not wireless) - Access point and gateway locations - Coverage areas and range limitations
The five design considerations do not operate in isolation – each constrains and informs the others:
Logical Topology:
Physical Topology:
Test your understanding of network design implications with these questions.
This worked example applies all five design considerations systematically to a real deployment scenario, demonstrating how each consideration constrains the next.
Scenario: A city of 180,000 residents plans to deploy 8,000 smart LED streetlights across 45 km2. Each light must dim/brighten based on pedestrian activity, report energy consumption, and alert maintenance crews to failures. The city requires 15-year operational life with remote management.
Device inventory:
8,000 smart LED controllers (mains-powered, outdoor IP66)
8,000 ambient light sensors (integrated, no battery)
2,000 PIR motion sensors (battery-powered, 5-year target)
200 air quality sensors (mains-powered, on select poles)
50 weather stations (mains-powered, every 15 poles)
Key constraint: Mains-powered controllers can run TCP/IP.
PIR motion sensors are battery-constrained -- need low-power protocol.
-> Decision: Two-tier architecture (mains devices on one protocol,
battery devices on another)Data flows:
Dimming commands: 10 bytes, event-driven (motion detected -> dim up)
Latency requirement: <500 ms (pedestrian safety)
Energy reports: 50 bytes per light, every 15 minutes
96 readings/day x 8,000 lights = 768,000 messages/day
Failure alerts: 20 bytes, event-driven, <5 minute delivery
Air quality: 100 bytes, every 5 minutes (2,400 per sensor per day)
Total daily data: ~42 MB (modest)
Peak message rate: ~900 messages/minute (energy reports)
-> Decision: MQTT for telemetry (efficient pub-sub for 768K daily messages),
CoAP for motion-triggered dimming (low-latency UDP)Existing city infrastructure:
Municipal fiber backbone (10 Gbps between districts)
No existing IoT platform
IT team: 3 network engineers, no IoT experience
Level 4 (Data Accumulation): Time-series DB for energy data
Level 5 (Data Abstraction): API layer for maintenance app
Level 6 (Analytics): Energy optimization ML model
Level 7 (Business): Dashboard for public works department
-> Decision: Cloud-hosted IoT platform (AWS IoT Core or Azure IoT Hub)
to avoid hiring specialized IoT operations staff.
Estimated: $2,400/month for 8,000 devicesDevice count: 10,250 total (8,000 + 2,000 + 200 + 50)
Growth buffer: 30% -> plan for 13,325 devices
IPv6 allocation: 2001:db8:city:lights::/64 (one subnet, 18 quintillion addresses)
Prefix structure:
2001:db8:city:lights:{district}:{pole}:{device-type}:{id}
District = 1-12 (city zones)
Pole = 1-700 per district
Device-type = 1 (LED), 2 (motion), 3 (air), 4 (weather)
-> Decision: IPv6 SLAAC for mains-powered devices (auto-configure).
PIR sensors use 6LoWPAN compressed addresses (battery savings).
Management by district prefix enables zone-level firmware updates.Physical topology:
Streetlights arranged along roads (linear physical layout)
Average 50m spacing between lights
District clusters of 500-800 lights
Logical topology:
Option A: Star (each light -> cellular gateway)
Cost: 8,000 x NB-IoT @ $1/month = $96K/year
Pro: Simple, no mesh complexity
Con: Recurring cost, motion latency 1-10s (too slow)
Option B: Mesh (Zigbee/Thread between lights)
Cost: $0 recurring, $15/light for mesh radio = $120K one-time
Pro: No subscription, low latency
Con: 50m spacing may exceed reliable mesh range
Option C: Hybrid star-mesh (mesh clusters -> LoRaWAN gateways)
Cost: 25 gateways x $1,500 + $8/light mesh radio = $101.5K one-time
Pro: Mesh for local dimming, LoRaWAN for telemetry to cloud
Con: Two radio protocols to manage
-> Decision: Option B (Thread mesh). Mains-powered lights act as mesh
routers (no battery concern). 50m spacing with outdoor line-of-sight
is within Thread's 100m range. Thread provides IPv6 natively,
matching Consideration 4. $120K one-time vs $1.44M over 15 years
for cellular.| Layer | Technology | Rationale |
|---|---|---|
| Application | MQTT (telemetry), CoAP (dimming) | Pub-sub for 768K daily messages, low-latency for safety |
| Transport | UDP (CoAP), TCP (MQTT) | UDP for time-critical dimming, TCP for reliable telemetry |
| Network | IPv6 with 6LoWPAN | SLAAC auto-config, district-based prefix for management |
| Data Link | Thread (802.15.4 mesh) | No recurring cost, local low-latency, mains-powered routers |
| Physical | 2.4 GHz (Thread) | 50m pole spacing within 100m outdoor range |
| 15-year TCO | $320,000 | Hardware + cloud platform + maintenance |
Let’s verify the Thread mesh network capacity and battery life claims for the 2,000 PIR motion sensors transmitting dimming commands.
Thread mesh capacity analysis: Each PIR sensor triggers ~4 times per night (pedestrian detected). Dimming command: 10 bytes CoAP message.
Time-on-air at 250 kbps (802.15.4) with compressed headers (6LoWPAN IPHC + NHC): \[T_{\text{airtime}} = \frac{8 \times (25 \text{ MAC} + 6 \text{ 6LoWPAN} + 4 \text{ UDP-NHC} + 10 \text{ CoAP})}{250{,}000} = \frac{360}{250{,}000} = 1.44 \text{ ms}\]
Total nightly airtime for 2,000 sensors: \[T_{\text{total}} = 2{,}000 \times 4 \times 1.44 \text{ ms} = 11.5 \text{ seconds/night}\]
With 8,000 mains-powered mesh routers (one per streetlight), each router handles: \[\text{Load per router} = \frac{2{,}000}{8{,}000} = 0.25 \text{ sensors}\]
Router channel time: \(0.25 \times 4 \times 1.44 = 1.44\) ms/night – negligible
PIR sensor battery life (2× AA lithium, 3000 mAh each @ 1.5V, 6000 mAh total): Energy per transmission at 17.4 mA TX: \[E_{\text{TX}} = 17.4 \text{ mA} \times 1.44 \text{ ms} = 0.025 \text{ mAs}\]
Sleep current (0.5 uA) over 24 hours: \[E_{\text{sleep}} = 0.0005 \text{ mA} \times 86{,}400 \text{ s} = 43.2 \text{ mAs}\]
Daily energy (4 transmissions): \[E_{\text{daily}} = (4 \times 0.025) + 43.2 = 43.3 \text{ mAs} = 0.012 \text{ mAh}\]
Battery life with 2x AA (6000 mAh): \[\text{Life} = \frac{6000 \text{ mAh}}{0.012 \times 365} = 1{,}370 \text{ days} = \mathbf{3.8 \text{ years}}\]
Problem: Target is 5 years, but calculation shows only 3.8 years!
Solution: Use 3x AA lithium batteries (9000 mAh total): \[\text{Life}_{3\text{AA}} = \frac{9000}{0.012 \times 365} = 2{,}055 \text{ days} = \mathbf{5.6 \text{ years}}\]
Meets 5-year requirement with 12% margin. ✓
TCO impact of battery sizing:
ROI: \(\frac{(\$48\text{K} - \$42\text{K}) - \$4\text{K}}{\$4\text{K}} = 50\%\) return on battery upsizing investment.
Key principle: Battery sizing calculations must account for both active and sleep energy. Sleep current (0.5 uA) over 24 hours consumes 99.7% of total energy – active transmissions are negligible in comparison. This is why ultra-low sleep current matters more than TX efficiency for infrequent-reporting IoT devices.
Design Foundations:
Network Topologies and Protocols:
Implementation and Addressing:
Designers often chase the lowest-latency or lowest-cost topology and discover only in production that they violated a battery-life or security constraint. Fix: score each of the five considerations explicitly before committing to a topology.
A gateway sized for 50 nodes will bottleneck when the deployment grows to 500. Fix: over-provision the gateway tier by 5–10× the initial node count, or choose a topology that allows gateway redundancy.
Network segmentation and encryption are far harder to retrofit than to build in from the start. Fix: define security zones and key-management strategy during the topology design phase.
Lab bench tests in open air rarely predict real-world link quality in metal-shelved warehouses or concrete buildings. Fix: conduct RF site surveys and budget 10–15 dB of link margin before finalising topology.
The five key design considerations form a comprehensive framework for IoT network planning:
| Direction | Chapter | Description |
|---|---|---|
| Next | Advanced Scenarios and Labs | Industrial case studies and hands-on lab exercises |
| Previous | Protocol Selection Examples | Spectrum allocation and TCO analysis |
| Parent | Design Implications Overview | Chapter overview and quick reference |