10 Network Topologies and Tradeoffs
Choosing IoT Network Topologies from Requirements
10.1 Start With the Places Devices Actually Sit
Imagine drawing a neat mesh on a plan, then walking the site and finding metal shelving, service corridors, locked rooms, moving assets, and maintenance constraints. Network fundamentals begin with the real deployment story: where devices sit, how they are powered, what they must send, which paths are blocked, and what evidence would show the topology can survive the place.
Phoebe’s Why
This chapter keeps returning to “coin-cell sensors” and “battery tags” as the reason mesh relay duty is expensive, but the battery itself has two separate physics stories that a topology review has to keep apart. The first is a bookkeeping question: how much charge (mAh) the cell holds, and how that becomes energy (Wh) once a voltage is attached to it. The second is a circuit question: every real cell has internal resistance, so pulling current makes its terminal voltage sag, and a coin cell’s resistance is high enough that a radio’s transmit pulse can sag the voltage far more than the mAh rating would ever suggest. A star-of-stars LoRaWAN design that looks fine on a charge budget can still brown out mid-transmission if nobody checked the second story.
The Derivation
Charge becomes energy only once the nominal voltage multiplies in:
\[E\ \mathrm{(Wh)} = \frac{C\ \mathrm{(mAh)} \times V}{1000}\]
A loaded cell’s terminal voltage sags by its own internal resistance (Ohm’s law applied to the cell as a circuit element):
\[V_{load} = V_{oc} - I\,R_{int}\]
and self-discharge quietly derates the nameplate capacity before any of it is ever spent:
\[C_{usable} = C_0\,(1 - k)^{t}\]
Meanwhile the radio side of the same design is governed by the free-space path-loss relationship every RF link shares:
\[\mathrm{FSPL} = \left(\frac{4\pi d}{\lambda}\right)^2\]
Worked Numbers: Coin Cell Behind an Outdoor Yard Sensor
The chapter names no specific cell, so take a catalog-typical CR2032: \(V=3.00\) V, \(C_0=225\) mAh, internal resistance \(R_{int}\approx20\ \Omega\) (mid-life, pulsed load; catalog range is roughly 10-30 \(\Omega\)).
- Energy: \(E = (225\times3.00)/1000 = 0.675\) Wh – the number the mAh rating is actually worth.
- Voltage sag during a catalog-typical LoRa transmit pulse (\(I=90\) mA at \(\sim\)+13 dBm): \(V_{sag} = 0.090\times20 = 1.80\) V, leaving only \(3.00-1.80=1.20\) V at the terminals – likely below the regulator’s dropout, which is exactly why LoRa-class radios on coin cells commonly need a bulk or supercapacitor buffer, not a bigger-mAh cell.
- Self-discharge: at a catalog-typical 1%/year, five years idle removes about \(225\times0.01\times5=11.25\) mAh before any transmission is sent.
- RF side, same outdoor yard sensor at 915 MHz over 1500 m: \(\lambda=0.328\) m, \(\mathrm{FSPL}=20\log_{10}(4\pi\times1500/0.328)=95.2\) dB. At 16 dBm EIRP (14 dBm radio + 2 dBi antenna, catalog-typical), received power is \(16-95.2=-79.2\) dBm – against a \(-137\) dBm SF12 sensitivity, that is a comfortable \(57.8\) dB margin, so for this link the battery-sag problem, not the path-loss budget, is the more fragile assumption.
10.2 Learning Objectives
By the end of this chapter, you will be able to:
- Translate an IoT deployment brief into network requirements that can be reviewed and tested.
- Compare star, mesh, tree, star-of-stars, and hybrid topologies without treating any one pattern as universally best.
- Explain how traffic, latency, reliability, power, coverage, security, and operations constraints shape topology choice.
- Plan gateway placement and segmentation decisions from evidence instead of from diagrams alone.
- Prepare a short design packet that connects requirements, assumptions, topology decisions, and validation evidence.
10.3 Prerequisites
This chapter assumes you have basic familiarity with:
- Networking basics: addressing, routing, layers, and packet delivery.
- IoT protocol families: common short-range, mesh, LPWAN, Wi-Fi, and cellular options.
- IoT reference models: how edge, gateway, fog, and cloud layers divide network responsibilities.
10.4 Topology Follows Requirements
Network topology is the shape that best protects the deployment promise. A simple star may be correct for low-power meters. A mesh may be correct for powered lighting nodes. A star-of-stars may be correct for LoRaWAN sensors. A hybrid may be necessary when monitoring, control, maintenance, and security zones have different needs.
The wrong starting point is “which topology is best?” The better starting point is which messages must move, where devices are installed, how much delay or loss is acceptable, how power is supplied, and who can keep the network working after launch. A topology drawing without those requirements can look tidy while hiding the constraint that will break the deployment.
Consider a warehouse with cold-chain pallets, forklift traffic, loading docks, staff tablets, and roof-mounted gateways. A star Wi-Fi design may work for tablets but waste power on coin-cell sensors. A LoRaWAN star-of-stars design may reach outdoor yard sensors but may not support frequent acknowledgements or low-latency commands. A Thread or Zigbee mesh may suit powered lighting nodes but may be weak for battery tags that cannot relay. The useful question is not which pattern is fashionable; it is which traffic classes, power sources, physical obstructions, and recovery needs each pattern can prove.
A reviewable design packet therefore starts with a requirements map. It lists device classes, traffic classes, candidate topology shapes, protocol candidates, gateway locations, security segments, and the evidence that would reject the design. If the packet cannot say how a gateway outage, weak dock coverage, certificate expiry, or firmware rollout will behave, the topology is not yet a design decision.
- Communication need: Name telemetry, command, alarm, join, time sync, firmware, and maintenance traffic separately.
- Physical need: Name distance, walls, metal, water, terrain, floors, mobility, enclosure, and antenna constraints.
- Operating need: Name provisioning, monitoring, key rotation, gateway access, support workflow, and replacement process.
10.5 Check Topology Against Risk
Each topology has a failure pattern. A star network concentrates risk at the gateway. A mesh can spend battery and airtime on relaying. A tree can overload or isolate parent nodes. A star-of-stars LPWAN deployment can look simple until gateway placement, spreading factor, duty cycle, joins, acknowledgements, and backhaul ownership are tested.
Choose metrics that expose the dominant risk. A battery sensor needs current profile, sleep behavior, retransmission rate, and maintenance interval. An alarm network needs latency percentiles, duplicate handling, acknowledgement timing, and failover behavior. A gateway plan needs RSSI/SNR, packet delivery by location, join rate, queue depth, and backhaul outage handling.
In practice, compare candidates with the same evidence grid. For a campus leak-detection network, a Wi-Fi design should show AP coverage, DHCP behavior after power restoration, TLS provisioning, and alert latency during busy hours. A LoRaWAN design should show spreading-factor distribution, airtime budget, confirmed-uplink policy, gateway backhaul, and downlink limits. A Thread or Zigbee design should show relay placement, route repair time, mains-powered router availability, and what happens when a corridor is closed for maintenance. The winning topology is the one whose weakest assumption is visible and manageable.
Practitioners should also separate pilot evidence from production evidence. A bench test can confirm payload shape and broker behavior, but it cannot prove dock-door fading, elevator-shaft shadowing, tenant segmentation, or battery replacement workload. A pilot should include a floor walk, gateway candidate list, installation constraints, packet-delivery logs, current traces, alert acknowledgements, and a support handoff. Without that evidence, the topology may only be optimized for the lab.
- Write the dominant requirement. Decide whether coverage, latency, battery life, capacity, resilience, segmentation, or operations is the first constraint.
- Choose candidate topologies. Compare star, mesh, tree, star-of-stars, and hybrid patterns against that constraint.
- Define acceptance evidence. Pick the RF survey, packet capture, simulation run, power profile, pilot log, or gateway metric that can reject a weak design.
10.6 Capacity and Recovery Scenarios
Network capacity is not just average payload rate. Joins, retries, acknowledgements, route repair, security handshakes, firmware rollout traffic, multicast commands, and gateway buffering can dominate the busy moments. The design must show behavior under normal, peak, failure, maintenance, and growth scenarios.
Recovery behavior is also topology-specific. Thread or Zigbee routes may repair after a relay disappears. RPL parent choices may shift after link quality changes. LoRaWAN devices may increase spreading factor after weak uplinks. Wi-Fi devices may reconnect slowly after access-point or DHCP disruption. Cellular devices may roam, back off, or lose service during congestion.
The under-the-hood model should be scenario based, not just a spreadsheet of average bytes. A 500-node environmental system may look light if each node sends 40 bytes every five minutes. The same system can overload during commissioning if every device joins, negotiates keys, downloads configuration, and publishes diagnostic state in the same window. A mesh can also create hidden load when a small set of routers carries traffic for a whole floor. The design should show which nodes forward, which links are bottlenecks, and which queues fill first.
Security and operations can change the topology as much as radio physics. Separate VLANs, broker authorization rules, per-tenant gateways, certificate lifetimes, and maintenance access boundaries may require a hybrid design even when one radio could technically cover the site. For example, safety alarms may need a local gateway and local fallback path, while analytics telemetry can tolerate cloud delay. Firmware rollout traffic may need staging by floor or zone so the update process does not consume the same channel needed for alarms.
A defensible design records recovery drills. It should say how many messages can buffer during a backhaul outage, whether acknowledgements are retried or suppressed, how stale data is marked, how route repair is detected, how a gateway is replaced, and which logs prove the system recovered. Those details turn a topology from a picture into an operating claim that can be tested before launch.
- Traffic model: Include payload size, interval, burst trigger, retry policy, acknowledgement rule, and priority for each class.
- Failure model: Include gateway loss, relay loss, backhaul outage, interference, power recovery, credential expiry, and maintenance windows.
- Security model: Include device identity, key or certificate lifetime, broker authorization, network segmentation, and support access boundaries.
10.7 Network Design Is a Requirements Problem
An IoT network is successful when it lets the application meet its operational promise. The topology drawing is only one artifact. The design also needs requirements, assumptions, placement evidence, capacity checks, failure behavior, security boundaries, and maintenance plans.
What must happen?
Define the business or safety result first: monitor, alert, control, locate, meter, actuate, or synchronize.
Who talks to whom?
Record whether traffic is device-to-gateway, peer-to-peer, hierarchical aggregation, or mixed by subsystem.
What can fail?
Name the acceptable loss, delay, outage, battery service interval, and recovery behavior.
How will we know?
Plan the RF survey, simulation, packet capture, pilot log, or gateway metric that will test the assumption.
10.8 Choose Topology by Constraint
Treat topology selection as a requirements filter, not as a preference poll.
- Split the traffic. Separate telemetry, alarms, commands, joins, firmware updates, diagnostics, and maintenance traffic before estimating network load.
- Name the dominant constraint. Decide whether coverage, latency, battery service interval, gateway ownership, security segmentation, or recovery time is most likely to break the design.
- Compare candidate shapes. Test star, mesh, tree, star-of-stars, and hybrid options against the dominant constraint rather than ranking them abstractly.
- Attach rejection evidence. State what RF survey, packet capture, gateway metric, current trace, simulation run, or pilot log would disqualify the candidate topology.
10.9 The Six Questions
Start every network design by answering the same six questions. If a question is unanswered, topology selection is premature.
10.10 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.
10.10.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.
10.10.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.
10.10.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.
10.10.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.
10.11 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.
10.12 Requirements That Shape the Network
10.12.1 Coverage and Link Margin
Coverage is not just distance. Walls, metal shelving, equipment, bodies, weather, antenna orientation, and gateway elevation can all change link quality. A design should identify expected weak areas and explain how they will be tested.
Record:
- Device locations and expected movement.
- Gateway or relay candidate positions.
- Known obstacles and interference sources.
- Antenna assumptions and mounting constraints.
- The validation method: survey, pilot, packet capture, or simulation.
10.12.2 Traffic and Capacity
Capacity planning starts with offered load. A simple first pass is:
\[ \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.
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.
10.12.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.
10.12.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.
10.12.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.
10.12.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.
10.13 Requirements to Criteria
Good requirements are testable. They say what must happen, under which condition, and how the team will check it.
10.14 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.
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.
10.15 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.
10.15.1 Step 1: Split the Requirements
10.15.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.
10.15.3 Step 3: Write the Decision Packet
The pilot packet should contain:
- A device-class inventory and traffic table.
- A topology choice per subsystem with rejected alternatives.
- Gateway candidate locations and backhaul assumptions.
- A failure review: gateway outage, backhaul outage, weak link, power loss, and maintenance window.
- A validation plan: where to place pilot nodes, which logs to collect, and what will trigger redesign.
10.16 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.
10.17 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.
10.18 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.
10.19 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.
10.20 Summary
- Network design begins with testable requirements: placement, traffic, latency, reliability, power, security, scale, and operations.
- Star, mesh, tree, star-of-stars, and hybrid patterns each solve different problems and introduce different risks.
- Gateway placement must account for coverage, backhaul, service access, security, monitoring, and failure behavior.
- Acceptance criteria turn vague design statements into evidence that can be simulated, surveyed, captured, piloted, or measured.
- A strong design packet records assumptions, rejected alternatives, failure scenarios, and validation evidence.
10.21 See Also
- Network Design Introduction frames the evidence route before topology selection.
- Network Simulation Tools explains which tools can test topology, traffic, and recovery assumptions.
- Network Traffic Analysis shows how packet captures reveal timing, retries, protocol state, and gateway behavior.
- Network Design Methodology gives review criteria for deciding whether the design evidence is strong enough.
10.22 References and Standards
- IETF RFC 6550, RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks.
- IETF RFC 7252, The Constrained Application Protocol (CoAP).
- IETF RFC 8200, Internet Protocol, Version 6 (IPv6) Specification.
- Wireshark, User’s Guide, for packet-capture evidence and troubleshooting workflows.
10.23 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.
| Previous | Current | Next |
|---|---|---|
| Network Design Introduction | Network Design Fundamentals | Network Design Methodology |
10.24 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.