11 Network Design: Evidence and Architecture Workflow

11.1 Start With the Decision

This section: Start With the Decision — A network choice should follow the device, traffic, place, and failure evidence.

A network choice should follow the device, traffic, place, and failure evidence. Start with the payload, the data each device sends; latency, the time a message takes to arrive; and the gateway, if one joins the device network to another network. Keep those facts ahead of vendor features.

11.2 Route Overview

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

This is part 2 of 2. Review Network Design: Tail Risk and Scope for the preceding evidence.

11.3 Learning Objectives

This section: Learning Objectives

• Build a network evidence route from system needs.
• Apply a staged workflow to architecture decisions.

11.4 Chapter Roadmap

This section: 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

This section: Build Network Evidence Route — Use this route before arguing for LoRaWAN, Thread, Zigbee, Wi-Fi, Ethernet, LTE-M, NB-IoT, or any simulator.

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

This section: Why IoT Network Design Is Different — Traditional enterprise networks often assume stable power, managed devices, predictable locations, and mature monitoring.

Traditional enterprise networks often assume stable power, managed devices, predictable locations, and mature monitoring. IoT networks often add constraints that make those assumptions weak.

A topology choice has to fit the site and the service. In Figure 11.1, star, mesh, tree, and hybrid are options, not a ranking. The worked building case shows why: environmental and occupancy sensing may start with a star-of-stars layout, but walls and equipment rooms still call for a site survey and pilot gateway logs. Later lighting control may need a separate resilient segment because its traffic and fallback needs differ. The comparison helps the team ask which path is weak, which service depends on it, and what field evidence would change the proposed layout.

+

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

This section: The Evidence Types — Different evidence types answer different design questions.

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

This section: The First Questions — Before selecting a simulator or drawing a topology, answer these questions.

Before selecting a simulator or drawing a topology, answer these questions.

11.9 The Network Design Sequence

This section: The Network Design Sequence — The design sequence is not strictly linear.

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.10 What Belongs in Later Chapters

This section: What Belongs in Later Chapters — This chapter only sets the mental model.

This chapter only sets the mental model. The next chapters handle the detailed work.

11.11 Worked Example: A Building Monitor

This section: Worked Example: A Building Monitor — A building team wants environmental monitoring, occupancy insight, and future lighting integration.

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

This section: Incremental Examples — Beginner Example: A classroom temperature logger sends one MQTT message every five minutes through Wi-Fi.

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

This section: 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.

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

This section: 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

This section: Practice Checks

11.16 Summary

This section: Summary — First: IoT network design follows an evidence route that connects requirements, topology, model assumptions, metrics, validation, and decisions.

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

This section: See Also — First: Network Design Fundamentals explains topology and protocol tradeoffs once the communication promise is clear.

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.

11.18 What’s Next

This section: What’s Next

11.19 Key Takeaway

This section: 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.

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 section: Continue Your Route — This is the last part of this chapter.

This is the last part of this chapter. Return to Network Design: Tail Risk and Scope or continue from the design-methodology module index.