Chapters

13 Network Design: Topology Tradeoffs

design-methodology
network

13.1 Start With the Decision

This section: Start With the Decision — Topology means the shape of the links between devices.

Topology means the shape of the links between devices. It does not by itself select a protocol, the rules for messages, guarantee performance, or prove coverage. In the star example below, each device talks to a central gateway, access point, coordinator, or controller; a gateway can connect this network to another network.

13.2 Route Overview

This section: Route Overview — This is part 2 of 2.

This is part 2 of 2. Review Network Design: Prototype Strategy for the preceding evidence.

13.3 Learning Objectives

This section: Learning Objectives

  • Test topology patterns with a concrete scenario and pass criteria.
  • Validate references and standards with a concrete scenario and pass criteria.

13.4 Chapter Roadmap

This section: Chapter Roadmap

  • Topology Patterns
  • Topology Selection Matrix
  • Requirements That Shape the Network
  • Example Capacity Check
  • Requirements to Criteria
  • Gateway Placement and Backhaul
  • Building Monitoring Pilot
  • Incremental Examples
  • Try It Now: Pick a Topology Boundary
  • Find the Missing Requirement
  • Practice Checks
  • Match Inputs to Design Decisions
  • Order Fundamentals Design Flow
  • Label the Network Design Packet
  • Knowledge Check
  • Knowledge Check: Coverage Evidence
  • Common Pitfalls
  • 1. Starting with a Favorite Protocol
  • 2. Topology Diagram Is Not Proof
  • 3. Hiding Different Traffic Classes
  • 4. Ignoring Operations
  • Summary
  • See Also
  • References and Standards
  • What’s Next
  • Key Takeaway

13.5 Topology Patterns

This section: Topology Patterns — Topology describes the communication shape.

Topology describes the communication shape. It does not by itself select the protocol, guarantee performance, or prove coverage. The same protocol may support different shapes, and the same topology may behave very differently in two sites.

Evidence for Topology Patterns starts at the figure Figure 13.1 with IoT Network Topologies. Contrast STAR TOPOLOGY against it to make topology choice a reviewable trade-off between simplicity, reach, resilience, energy, and operating complexity.

Star, mesh, tree and hybrid cards compare communication shape, strong fit, main risk and design checks. Accept a topology only when requirements and validation evidence support it.
Figure 13.1: Topology choice is a tradeoff between simplicity, reach, resilience, energy, and operating complexity.

The cards in Figure 13.1 compare star, mesh, tree, and hybrid links; check fit before choice.

13.5.1 Star

In a star topology, each device communicates with a central gateway, access point, coordinator, or controller. The device path is easy to reason about because there is usually one network hop from device to gateway.

Use star when the area is bounded, every device can reach the gateway with margin, low-power devices should avoid relay duty, and centralized management is acceptable. Review the gateway carefully because it can become the capacity bottleneck and a single point of failure.

13.5.2 Mesh

In a mesh topology, devices can forward messages through neighboring devices. This can extend coverage and provide alternate paths, especially when nodes are mains-powered or can afford the relay energy.

Use mesh when path diversity matters and there are enough stable nodes to form useful routes. Review hop count, routing convergence, relay load, battery impact, and what happens when the network becomes sparse or mobile.

13.5.3 Tree and Hierarchical

Tree topologies organize devices under parent nodes, cluster heads, gateways, floors, zones, or regions. They are natural for aggregation, management, and addressing when the deployment already has a physical or operational hierarchy.

Use tree patterns when traffic mostly moves from many devices toward upstream systems. Review parent-node failures, branch imbalance, aggregation bottlenecks, and whether a local cluster can continue operating when the upstream link is unavailable.

13.5.4 Star-of-Stars and Hybrid

Many real IoT deployments combine patterns. A site might use local star clusters, a mesh lighting layer, wired gateway backhaul, and cloud integration. Hybrid design is normal when subsystems have different traffic, power, security, or maintenance needs.

Use hybrid designs when one topology would force weak compromises across the whole deployment. Review the boundaries between subsystems: addressing, timing, security zones, gateway ownership, monitoring, and how faults propagate across layers.

13.6 Topology Selection Matrix

This section: Topology Selection Matrix — The table below is a decision aid, not a rule book.

The table below is a decision aid, not a rule book. A topology is acceptable only when the requirements and validation evidence support it.

Pattern
Strong Fit
Main Risk
Design Checks
Star
Simple device-to-gateway reporting, bounded area, low-power end nodes, centralized control.
Gateway outage or overload can affect many devices.
Coverage margin, gateway capacity, redundancy, local fallback.
Mesh
Path diversity, obstructed spaces, relays with stable power, extended indoor coverage.
Routing overhead can increase latency, energy use, and troubleshooting complexity.
Hop count, relay load, route repair time, weak-node distribution.
Tree
Buildings, campuses, zones, industrial lines, or sensor clusters with clear aggregation paths.
Parent or cluster-head failure can isolate children.
Branch balance, parent redundancy, aggregation rate, upstream buffering.
Hybrid
Mixed applications, mixed power sources, different security zones, multiple protocols or backhaul layers.
Interfaces between layers can hide failures and ownership gaps.
Segmentation, gateway mapping, shared services, monitoring, change control.

13.7 Requirements That Shape the Network

This section: Requirements That Shape the Network

13.7.2 Traffic and Capacity

Capacity planning starts with an estimate of generated application payload traffic. For devices with the same reporting rate, a simple first pass is:

estimated application payload rate=device count×payload bits per report×reports per second per device\text{estimated application payload rate} = \text{device count} \times \text{payload bits per report} \times \text{reports per second per device}

This estimate is only a screening check. It does not include retries, joins, acknowledgments, bursts, firmware updates, security handshakes, route repair, or interference. Those effects should appear in the scenario plan or pilot evidence.

Example Capacity Check

A building monitor has three traffic classes: slow environmental readings, event-driven occupancy messages, and command traffic for lighting scenes. Do not average them into one generic sensor stream. List each class separately, identify peak events, then check whether the gateway and channel still have headroom during a busy interval.

13.7.3 Latency and Jitter

Latency is the time from event or reading to useful receipt. Jitter is latency variation. For monitoring dashboards, occasional delay may be acceptable. For alarms, synchronized sampling, or control actions, delay variation can matter as much as the average delay.

Design choices that affect latency include hop count, duty cycle, contention, retransmissions, gateway processing, backhaul, edge analytics, cloud dependency, and queueing during bursts.

13.7.4 Reliability and Recovery

Reliability is not one number. A design should state what kind of failure is being handled:

  • Lost packet.
  • Weak link.
  • Gateway outage.
  • Backhaul outage.
  • Power loss.
  • Interference event.
  • Firmware or configuration error.
  • Maintenance window.

The recovery plan may involve retransmission, alternate routes, local buffering, redundant gateways, local control, manual override, or accepting delayed data. Pick the mechanism that matches the application risk.

13.7.5 Power and Maintenance

Battery-powered devices usually benefit from short transmissions, predictable schedules, and long sleep periods. They are poor relay candidates unless the application explicitly budgets for that role. Mains-powered devices can support relaying, scanning, always-on listeners, or gateway functions, but they still need security updates and monitoring.

For every device class, record the intended sleep behavior, transmit schedule, receive behavior, and maintenance interval. Treat “battery lasts long enough” as an assumption until measured under realistic traffic and environmental conditions.

13.7.6 Security and Segmentation

Network topology affects the security model. A shared network may be cheaper to operate, but segmentation can be necessary when tenants, subsystems, safety functions, clinical spaces, or operational technology have different risk profiles.

Common segmentation decisions include separate VLANs, separate gateways, separate keys, broker-level authorization, firewall boundaries, local-only control paths, and dedicated management networks.

13.8 Requirements to Criteria

This section: Requirements to Criteria — Good requirements are testable.

Good requirements are testable. They say what must happen, under which condition, and how the team will check it.

Weak Statement
Reviewable Criterion
Possible Evidence
"Good coverage"
Each installed location reports with the agreed margin during normal and busy site conditions.
RF survey, pilot packet captures, gateway RSSI/SNR logs, weak-area map.
"Low latency"
Alarm messages meet the target end-to-end delay during normal load and during a defined burst scenario.
Timestamped event tests, gateway logs, simulation trace, percentile summary.
"Reliable network"
The design tolerates the named gateway, relay, link, or backhaul failure without losing the required function.
Failure scenario run, failover test, buffer drain test, recovery timeline.
"Long battery life"
The measured duty cycle, retransmission rate, and sleep current support the maintenance interval with margin.
Power profile, firmware configuration, field log, battery model assumptions.
"Scalable"
The design handles the planned growth case without exceeding gateway, channel, address, or operations limits.
Growth scenario, capacity worksheet, provisioning test, monitoring dashboard review.

13.9 Gateway Placement and Backhaul

This section: Gateway Placement and Backhaul — Gateways connect local device networks to the rest of the IoT system.

Gateways connect local device networks to the rest of the IoT system. Placement decisions therefore affect coverage, latency, resilience, operations, and security.

1. Start with device clustersGroup devices by floor, zone, tenant, outdoor area, function, or maintenance team.
2. Map weak pathsIdentify walls, metal, distance, interference, moving equipment, and backhaul constraints.
3. Place for serviceGateways need power, backhaul, physical access, monitoring, and security controls.
4. Add redundancy selectivelyProtect critical functions first; avoid paying complexity where delay or data loss is acceptable.
5. Validate in the siteConfirm assumptions with pilot logs, packet captures, gateway metrics, or RF survey evidence.
Design review rule: A gateway count is not complete unless the design basis explains coverage assumptions, traffic assumptions, backhaul, ownership, failure behavior, and validation evidence.

13.10 Building Monitoring Pilot

This section: Building Monitoring Pilot — A facilities team wants environmental, occupancy, and equipment-status data from a multi-floor building.

A facilities team wants environmental, occupancy, and equipment-status data from a multi-floor building. The brief says the system will support dashboards, comfort tuning, maintenance alerts, and future lighting integration.

13.10.1 Step 1: Split the Requirements

Device Class
Traffic Pattern
Constraint
Initial Topology Fit
Environmental sensors
Small periodic readings.
Battery service interval matters more than immediate delivery.
Star or star-of-stars to gateways.
Occupancy sensors
Event-driven messages with possible morning and meeting-room bursts.
Low latency is useful, but occasional delayed data may be acceptable outside alerts.
Star-of-stars with coverage validation.
Equipment status
Periodic readings plus maintenance events.
Equipment rooms may have metal, noise, and access restrictions.
Dedicated gateway or wired backhaul if wireless evidence is weak.
Future lighting
Command and status traffic.
Requires more careful latency, fallback, and manual override review.
Separate segment; possibly mesh if powered nodes can relay.

13.10.2 Step 2: Avoid One-Topology Thinking

A single building-wide mesh may look resilient, but it can force battery sensors into relay behavior. A single gateway per floor may look simple, but it may create weak corners and floor-level outages. A hybrid design may be justified if it keeps low-power monitoring simple while giving powered lighting or equipment nodes their own resilient segment.

13.10.3 Step 3: Write the Decision Packet

The pilot packet should contain:

First: A device-class inventory and traffic table.

Next: A topology choice per subsystem with rejected alternatives.

Then: Gateway candidate locations and backhaul assumptions.

After that: A failure review: gateway outage, backhaul outage, weak link, power loss, and maintenance window.

Also inspect: A validation plan: where to place pilot nodes, which logs to collect, and what will trigger redesign.

13.11 Incremental Examples

This section: Incremental Examples — Beginner Example: Ten classroom CO2 sensors publish MQTT telemetry over Wi-Fi every five minutes.

Beginner Example: Ten classroom CO2 sensors publish MQTT telemetry over Wi-Fi every five minutes. A star through the existing access point may be enough if RSSI is stable at each mounting location, DHCP/MQTT reconnect after an AP restart is acceptable, and delayed readings do not create a safety issue.

Intermediate Example: Warehouse freezer alarms use LoRaWAN because gateways can cover long aisles without asking battery nodes to relay. The review needs RSSI/SNR by freezer row, spreading factor distribution, gateway backhaul behavior, alarm latency percentiles, and current traces during retry bursts before accepting the star-of-stars plan.

Advanced Example: A smart-building retrofit combines battery environmental sensing, powered lighting control, and maintenance diagnostics. A hybrid design may be better than one shared mesh: keep battery telemetry simple, put powered routers where route repair is useful, segment lighting commands, and define local fallback if the cloud or gateway path fails.

13.12 Try It Now: Pick a Topology Boundary

This section: Try It Now: Pick a Topology Boundary — For a small clinic with battery temperature sensors, mains-powered room displays, and a local alarm requirement, write two candidate topology boundaries.

For a small clinic with battery temperature sensors, mains-powered room displays, and a local alarm requirement, write two candidate topology boundaries. For each boundary, name one reason it could work, one failure mode it creates, and one piece of evidence that would reject it.

13.13 Find the Missing Requirement

This section: Find the Missing Requirement — Read this requirement: “The network must be scalable and reliable.” Rewrite it as two measurable criteria.

Read this requirement: “The network must be scalable and reliable.” Rewrite it as two measurable criteria. Include the device count or growth case, traffic class, failure scenario, and the evidence source you would expect in a review.

13.14 Practice Checks

This section: Practice Checks

Common Pitfalls

This section: Common Pitfalls

Protocol familiarity is useful, but it should not decide the design alone. Start with placement, traffic, power, latency, reliability, security, and operations requirements, then compare candidate technologies.

A topology diagram is a communication tool. It does not prove coverage, capacity, latency, recovery, or battery life. Attach evidence to the diagram.

Averaging traffic across all devices can hide bursts, alarms, firmware updates, joins, retries, and command traffic. Separate traffic classes before estimating capacity.

A technically elegant topology can fail in practice if the team cannot provision devices, rotate keys, monitor gateways, update firmware, or troubleshoot weak links.

13.15 Summary

This section: Summary — First: Network design begins with testable requirements: placement, traffic, latency, reliability, power, security, scale, and operations.

First: Network design begins with testable requirements: placement, traffic, latency, reliability, power, security, scale, and operations.

Next: Star, mesh, tree, star-of-stars, and hybrid patterns each solve different problems and introduce different risks.

Then: Gateway placement must account for coverage, backhaul, service access, security, monitoring, and failure behavior.

After that: Acceptance criteria turn vague design statements into evidence that can be simulated, surveyed, captured, piloted, or measured.

Also inspect: A strong design packet records assumptions, rejected alternatives, failure scenarios, and validation evidence.

13.16 See Also

This section: See Also — First: Network Design Introduction frames the evidence route before topology selection.

First: Network Design Introduction frames the evidence route before topology selection.

Next: Network Simulation Tools explains which tools can test topology, traffic, and recovery assumptions.

Then: Network Traffic Analysis shows how packet captures reveal timing, retries, protocol state, and gateway behavior.

After that: Network Design Methodology gives review criteria for deciding whether the design evidence is strong enough.

13.17 References and Standards

This section: References and Standards — First: IETF RFC 6550, RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks.

First: IETF RFC 6550, RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks.

Next: IETF RFC 7252, The Constrained Application Protocol (CoAP).

Then: IETF RFC 8200, Internet Protocol, Version 6 (IPv6) Specification.

After that: Wireshark, User’s Guide, for packet-capture evidence and troubleshooting workflows.

13.18 What’s Next

This section: What’s Next — The next chapter, Network Design Methodology, explains how to turn the requirements, assumptions, scenarios, and evidence introduced here into a repeatable design record.

The next chapter, Network Design Methodology, explains how to turn the requirements, assumptions, scenarios, and evidence introduced here into a repeatable design record.

PreviousCurrentNext
Network Design IntroductionNetwork Design FundamentalsNetwork Design Methodology

13.19 Key Takeaway

This section: Key Takeaway — Network fundamentals become design decisions when requirements are quantified.

Network fundamentals become design decisions when requirements are quantified. Range, throughput, latency, reliability, power, mobility, and cost should be measured or estimated before choosing a topology.

13.20 Continue Your Route

This section: Continue Your Route — This is the last part of this chapter.

This is the last part of this chapter. Return to Network Design: Prototype Strategy or continue from the design-methodology module index.

Find help

3 reviewed answers.

Where should I start in a module?

Open the module page from the sidebar to see its chapters in order. Use the module map to return to a topic you need.

Modules and paths

Reviewed

What can I try when a project does not work?

Check the symptom, then work through the diagnostic steps. Keep the error message and the smallest example that reproduces it.

When you are stuck

Reviewed

How do interactive examples work?

Use the interactive guide to check how examples and simulations work before changing your project.

Interactive examples guide

Reviewed