Chapters

13 Network Design: Topology Tradeoffs

design-methodology
network

13.1 Start With the Decision

It does not by itself select the protocol, guarantee performance, or prove coverage.

13.2 Route Overview

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

13.3 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

  • 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

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.

Follow Figure 13.1 from IoT Network Topologies into STAR TOPOLOGY before checking MESH TOPOLOGY. The first uses IoT Network Topologies to locate a communication boundary, the second uses STAR TOPOLOGY to locate a communication boundary, and the last uses MESH TOPOLOGY to locate a communication boundary. This ordered reading preserves Topology choice is a tradeoff between simplicity, reach, resilience, energy, and operating complexity in the Topology Patterns evidence chain.

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

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

13.7.2 Traffic and Capacity

Capacity planning starts with offered load. A simple first pass is:

offered load=device count×payload bits×reports per secondusable channel efficiency\text{offered load} = \frac{\text{device count} \times \text{payload bits} \times \text{reports per second}}{\text{usable channel efficiency}}

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

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

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

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

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

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

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

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

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

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

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

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

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 final part closes the route from Topology Patterns through Key Takeaway. Return to Network Design: Prototype Strategy or continue from the design-methodology module index.