11 Network Design: Evidence and Architecture Workflow
11.1 Start With the Decision
A network choice should follow the device, traffic, place, and failure evidence. The workflow keeps those facts ahead of vendor features.
11.2 Route Overview
This is part 2 of 2. Review Network Design: Tail Risk and Scope for the preceding evidence.
11.3 Learning Objectives
- Build a network evidence route from system needs.
- Apply a staged workflow to architecture decisions.
11.4 Chapter Roadmap
- Build Network Evidence Route
- Why IoT Network Design Is Different
- The Evidence Types
- The First Questions
- The Network Design Sequence
- What Belongs in Later Chapters
- Worked Example: A Building Monitor
- Incremental Examples
- Try It Now: Reject a Weak Topology Claim
- Micro-Exercise: Pick the Evidence
- Practice Checks
- Match Evidence to Question
- Order Introduction Workflow
- Label the Network Evidence Route
- Knowledge Check
- Knowledge Check: Simulation Use
- Common Pitfalls
- 1. Treating Simulation as the First Step
- 2. Confusing a Diagram With Evidence
- 3. Averaging Away Risk
- 4. Forgetting the Operator
- Summary
- See Also
- References
- What’s Next
- Key Takeaway
11.5 Build Network Evidence Route
Use this route before arguing for LoRaWAN, Thread, Zigbee, Wi-Fi, Ethernet, LTE-M, NB-IoT, or any simulator.
First: Name the communication promise. Write the device class, payload, sender, receiver, interval, latency target, loss tolerance, command behavior, and failure behavior.
Next: Map the physical and operational boundary. Record placement, power source, gateway access, backhaul, installation owner, monitoring owner, update path, security boundary, and maintenance window.
Then: Choose evidence for the risky claim. Pair each claim with the evidence type that can test it: RF survey for coverage, packet capture for protocol timing, current logging for retry cost, simulation for scale assumptions, and pilot logs for installed behavior.
After that: Decide what would change the design. Define the metric or field signal that would trigger a gateway move, topology change, retry-limit change, segmentation change, or local fallback.
11.6 Why IoT Network Design Is Different
Traditional enterprise networks often assume stable power, managed devices, predictable locations, and mature monitoring. IoT networks often add constraints that make those assumptions weak.
Make Why IoT Network Design Is Different traceable: inspect Figure 11.1 for IoT Network Topologies. Focus next on Star Topology, the companion label anchoring Star, mesh, tree, and hybrid topologies solve different deployment constraints; none is automatically best for every IoT system.
Within the visual Figure 11.1, IoT Network Topologies establishes the opening checkpoint because it uses IoT Network Topologies to locate a communication boundary. Star Topology develops the Why IoT Network Design Is Different reading by showing how it uses Star Topology to locate a communication boundary; Mesh Topology completes it by showing where it uses Mesh Topology to locate a communication boundary. The sequence makes Star, mesh, tree, and hybrid topologies solve different deployment constraints; none is automatically best for every IoT system auditable for Why IoT Network Design Is Different.
11.7 The Evidence Types
Different evidence types answer different design questions. A good network review combines them rather than treating one artifact as proof of everything.
11.8 The First Questions
Before selecting a simulator or drawing a topology, answer these questions.
11.9 The Network Design Sequence
The design sequence is not strictly linear. Teams may loop back when evidence contradicts assumptions. Still, the work usually follows a stable path.
Evidence for The Network Design Sequence starts at Figure 11.2 with Network. Contrast Decision Review against it to make The design loop keeps requirements, models, measurements, validation, and decisions connected reviewable rather than assumed.
Inspect Figure 11.2 at Network and note that it uses Network to locate a communication boundary. Compare Decision Review, which uses Decision Review to mark a decision point, before reading Requirements as the place that uses Requirements to state a required condition. The comparison turns The design loop keeps requirements, models, measurements, validation, and decisions connected into a bounded The Network Design Sequence choice.
11.9.1 1. Requirements
Define device classes, placement, traffic, latency, reliability, energy, security, scale, maintenance, and operations. Avoid vague requirements such as “good coverage” or “low latency.” Write what must be tested.
11.9.2 2. Candidate Design
Compare topology and protocol options against the requirements. Star, mesh, tree, star-of-stars, and hybrid patterns are choices with tradeoffs, not maturity levels.
11.9.3 3. Model or Measurement Plan
Choose the smallest evidence plan that can answer the decision question. Sometimes a table and site walk are enough. Sometimes a simulation, packet capture, RF survey, or pilot is necessary.
11.9.4 4. Metrics and Scenarios
Metrics should match the requirement: delivery, latency, jitter, throughput, queue depth, recovery time, battery current, route repair, join behavior, or gateway load. Scenarios should include normal, peak, failure, environment, maintenance, and growth cases when relevant.
11.9.5 5. Validation
Compare model claims with real evidence. If pilot logs disagree with simulation assumptions, revise the model or the design. Simulation credibility depends on validation, not on attractive diagrams.
11.9.6 6. Design Basis
Record the chosen design, rejected alternatives, assumptions, evidence, limitations, remaining risks, and the conditions that would reopen the design. This keeps future maintainers from inheriting an unexplained topology.
11.10 What Belongs in Later Chapters
This chapter only sets the mental model. The next chapters handle the detailed work.
11.11 Worked Example: A Building Monitor
A building team wants environmental monitoring, occupancy insight, and future lighting integration. A weak introduction-level response would be “use a mesh network because it is reliable.” A stronger introduction-level response creates an evidence route.
The key lesson is not the exact topology. The key lesson is that each decision has a reason, a risk, and an evidence plan.
11.12 Incremental Examples
Beginner Example: A classroom temperature logger sends one MQTT message every five minutes through Wi-Fi. The evidence route can stay small: confirm Wi-Fi RSSI at the intended shelf, check DHCP and MQTT reconnect behavior after an access-point restart, and record whether delayed messages are acceptable for a classroom dashboard.
Intermediate Example: A freezer-alarm pilot uses LoRaWAN sensors across a warehouse. The evidence route must include gateway placement, RSSI/SNR by freezer row, spreading factor distribution, join success after a power event, alarm latency percentiles, and battery current during retry bursts. A topology diagram alone cannot show whether the coldest weak-signal corner is safe.
Advanced Example: A campus wants environmental sensing now and lighting control later. Treat monitoring and control as different network promises. Use Thread or Zigbee mesh assumptions only after checking powered-router density, route repair time, command acknowledgement timing, segmentation, commissioning ownership, and fallback behavior if the gateway or cloud path is unavailable.
11.13 Try It Now: Reject a Weak Topology Claim
Review this claim: “Use mesh because it is reliable for all building sensors.” Rewrite it as one reviewable network-design statement. Your rewrite should name the device class, traffic type, site constraint, topology option, evidence source, and one condition that would force redesign.
11.14 Micro-Exercise: Pick the Evidence
For a battery sensor that misses alarms during busy periods, choose the first two evidence sources you would request: RF survey, packet capture, current trace, gateway queue metrics, simulator output, support ticket log, or dashboard screenshot. Explain which claim each source can and cannot prove.
11.15 Practice Checks
Common Pitfalls
Simulation is useful after the team knows what question it is answering. Start with requirements, assumptions, and scenarios.
A diagram shows structure. Evidence shows whether the structure can meet coverage, traffic, latency, energy, failure, and operations requirements.
Average latency, average packet delivery, or average gateway load can hide weak locations, burst failures, retry storms, and tail behavior. Ask for distributions or scenario-specific results where the risk matters.
Deployment success depends on provisioning, monitoring, updates, key management, physical access, documentation, and support ownership. Include operations in the design from the beginning.
11.16 Summary
First: IoT network design follows an evidence route that connects requirements, topology, model assumptions, metrics, validation, and decisions.
Next: Simulation is useful when it answers a specific question under documented assumptions; it is not a replacement for requirements or field validation.
Then: Different evidence sources answer different questions: paper design, simulation, packet capture, RF survey, pilot logs, and operations metrics.
After that: A deployment-ready design basis explains the chosen design, rejected alternatives, evidence, limits, and remaining risk.
11.17 See Also
First: Network Design Fundamentals explains topology and protocol tradeoffs once the communication promise is clear.
Next: Network Simulation Tools shows when ns-3, OMNeT++/INET, Cooja, packet captures, or RF tools fit a design question.
Then: Network Traffic Analysis teaches packet-capture viewpoints for diagnosing timing, retry, broker, and gateway behavior.
After that: Network Design Methodology turns the evidence route into a repeatable study plan with scenarios and validation boundaries.
References
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.
11.18 What’s Next
| If you want to… | Read this |
|---|---|
| Learn topology fundamentals in depth | Network Design Fundamentals |
| Explore available validation tools | Network Simulation Tools |
| Apply a disciplined study process | Network Design Methodology |
| Judge whether evidence is strong enough | Network Design Methodology |
| Inspect packet and gateway evidence | Network Traffic Analysis |
| Previous | Current | Next |
|---|---|---|
| Design Thinking Validation | Network Design Introduction | Network Design Fundamentals |
11.19 Key Takeaway
Start network design by defining the communication need: who talks to whom, how often, with what payload, under what latency, power, and reliability constraints. Technology selection comes after that.
11.20 Continue Your Route
This final part closes the route from Build Network Evidence Route through Key Takeaway. Return to Network Design: Tail Risk and Scope or continue from the design-methodology module index.