17 Network Simulation: Claims and Scenarios

17.1 Start With the Decision

A simulator can give a precise answer to the wrong failure. Begin with the claim, risk, and scenario that could disprove it.

17.2 Route Overview

This is part 1 of 2. Continue with Network Simulation: Method Selection and Evidence.

17.3 Part Objectives

• Turn network risks into testable simulation claims.
• Build repeatable scenario packs with fixed evidence.

17.4 Chapter Roadmap

• Start With the Scenario That Could Fail
• Scenario Packs Test Decisions
• Build Reproducible Runs
• Variation Is Evidence
• In 60 Seconds
• Phoebe’s Field Notes: Why the Greenhouse Pilot’s “Nominal Margin” Is Not the Whole Scenario Pack
• Prerequisites
• What This Chapter Adds
• Build Network Scenario Packs
• Method 1: Define the Decision and Bands
• Do Not Optimize to a Moving Target

17.5 Start With the Scenario That Could Fail

Make the Model Answer One Real Question

Picture a team planning one thousand field sensors. Building the whole site before testing the idea would be slow and costly. A network simulation is a computer model that lets the team try a design before the real build.

Start with one question. Ask whether alarms arrive in time, batteries last long enough, or the network survives a blocked path. Write the pass rule before running the model. Then list each guess about distance, traffic, power, movement, and failure.

Build the smallest model that can answer the question. Run more than one random trial. Change the guesses that are least certain. Compare the result with a bench test or a small field test. Keep the model version, inputs, seed, output, and decision together.

A model is not a forecast just because it makes a clean chart. It only explores the rules and guesses that were put into it. Real radios, people, weather, and faults may behave differently.

Use Practitioner to plan fair runs and checks. Use Under the Hood to study events, statistics, scale, and model limits.

Picture a field network that looks fine on a calm day but fails in rain or at peak load. One best-case run cannot support a release choice.

First, name the choice the test must guide. Then vary the few conditions that can change that choice and save the full run record.

Many runs can reveal risk, but they cost time and can make the result hard to read. Too few runs are clear, yet they may hide chance or a weak edge.

That is the simple story, but a model cannot prove the field on its own. The later method joins repeatable runs with real checks and change rules.

Use the Practitioner sections to build and compare test packs. Use the Under the Hood sections to study model bounds, spread, chance, and field gaps in more depth.

Firmware is the code stored on a device. A gateway is a local bridge to a wider service.

Plain check

• Name the release choice. Name the user harm. Name the safe result. Name the test owner.
• Write the calm case. Write the busy case. Write the weak case. Write the fault case.
• Fix the start state. Fix the code build. Fix the random seed. Save every run input.
• Vary one cause first. Keep other parts still. Run the same test. Compare the clear result.
• Then vary two causes. Mark why they meet. Save each pair. Watch for a new fault.
• Test more than once. Keep each raw run. Show the spread. Do not hide an outlier.
• Check lost messages. Check late messages. Check repeated messages. Check wrong order.
• Check low power. Check weak signal. Check busy links. Check a full store.
• Test the gateway edge. Test a dead device. Test a slow service. Test a bad clock.
• Keep model limits clear. Mark what it omits. Mark what it assumes. Mark what needs field proof.
• Compare against field data. Explain each gap. Fix the model or claim. Run the pack again.
• Set pass bands first. Set stop bands first. Do not tune them later. Record who approved them.
• Save the tool build. Save the input pack. Save the result set. Save the review note.
• Use Practitioner to package. Use deeper model checks. Test the weak edge. State each bound.
• Reopen after field change. Reopen after code change. Reopen after new load. Keep proof current.

Picture a simulation that looks excellent because it only models normal traffic. A useful scenario pack begins with the case that could break the design: peak load, a failed parent, gateway outage, bursty firmware update, mobility, interference, or growth. The model earns trust when pass bands, assumptions, random variation, and measurement checks are visible before results are interpreted.

17.6 Learning Objectives

By the end of this chapter, you will be able to:

• Build a simulation scenario pack that tests the network decision rather than only a best-case model.
• Select the right simulation method for baseline, stress, fault, sensitivity, and validation questions.
• Keep model boundaries, randomization, inputs, output traces, and acceptance criteria reviewable.
• Analyze variation, tail behavior, and scenario differences without overstating what the simulator proves.
• Convert simulation results into a simulation decision basis that can be validated against field evidence.

17.7 Scenario Packs Test Decisions

A simulation scenario pack is a controlled set of cases that asks whether a network design is credible under normal, stressed, failed, and changing conditions. It should not be a single attractive run. The pack should state the decision, the pass and fail bands, the assumptions being tested, and the field evidence that will later check the model. In an IoT review, the decision might be whether one LoRaWAN gateway is enough for a greenhouse, whether a Thread or Zigbee mesh survives loss of a powered router, whether Wi-Fi reconnects keep dashboard freshness inside the service target, or whether an MQTT alarm path can tolerate a broker restart.

For IoT networks, the scenario pack must include the conditions that usually break deployments: burst traffic, weak links, gateway outage, commissioning storms, firmware update load, mobility, interference, battery constraints, and maintenance windows. Each case should explain what design choice would change if the result fails. That means the scenario pack is not a generic "run ns-3" or "open OMNeT++" task. It is a decision artifact. The tool, whether ns-3, OMNeT++/INET, Cooja, a trace-driven script, or a broker timing rig, is selected because it can test one part of the scenario pack.

The Scenario Packs Test Decisions argument uses Figure 17.1 to compare Inputs. Look next for Scenario model before accepting Ad hoc simulation lab workflow as a design claim.

Start with the scenario model in Figure 17.1, which defines nodes, radio range, mobility, and traffic load. Routing protocols feed the simulation loop, while the metrics collector tracks delivery, latency, overhead, and energy. Compare these outcomes across seeds and scenario variants.

• Decision case: Topology, protocol, gateway placement, retry policy, traffic shaping, battery budget, or pilot readiness.
• Stress case: Alarm burst, correlated reporting, gateway loss, joining storm, firmware rollout, backhaul outage, or interference.
• Validation case: Packet capture, RF survey, pilot log, bench test, gateway telemetry, or operations dashboard check.

17.8 Build Reproducible Runs

Write the run package before interpreting the result. For ns-3, OMNeT++/INET, or Cooja, keep topology files, traffic inputs, configuration, random seeds, model versions, trace outputs, and analysis scripts together. For MQTT or CoAP timing rigs, keep broker configuration, payload sizes, QoS choices, keepalive settings, retry rules, and clock alignment notes. The reviewer should be able to see how nodes were placed, which protocol modules were enabled, how traffic was generated, where metrics came from, and which parts of the network were simplified.

Use scenario families rather than one case. A LoRaWAN pack may vary spreading factor, payload interval, duty-cycle pressure, gateway count, RSSI/SNR, ADR behavior, and downlink attempts. A Thread or Zigbee pack may vary router density, 802.15.4 channel, route repair, sleepy-end-device timing, and interference. A Wi-Fi pack may vary channel plan, roaming, backhaul latency, DHCP/DNS recovery, and access-point load. A cellular pack may vary coverage class, modem firmware, SIM or eSIM profile, APN/VPN path, power-save mode, and cloud endpoint availability. Application-protocol scenarios may vary MQTT QoS and session expiry, CoAP confirmable retransmission, TLS resumption, payload size, and broker throttling.

Make the run package practical. Name the exact scenario, the command or project file that runs it, the expected input files, the output directory, and the script that turns traces into metrics. For randomized studies, state the seed policy and why the sample is enough for the decision. For trace-driven studies, state where the trace came from and whether it represents normal operation, a pilot, a fault event, or synthetic load. For validation, tie one claim to one evidence source: Wireshark or tcpdump for packet timing, gateway logs for joins and retries, RF survey data for path-loss assumptions, broker logs for session behavior, and power traces for battery claims.

1. Freeze the bands first. Define pass, investigate, and fail thresholds before seeing simulator output.
2. Run variation deliberately. Use replicated seeds, parameter sweeps, sensitivity checks, and fault injection where the decision depends on variability.
3. Write the validation hook. Name the capture, survey, pilot, or telemetry source that will test the most important model assumption.

17.9 Variation Is Evidence

IoT network behavior is often dominated by tails, not averages. A mean latency can hide gateway queue spikes. Average packet delivery can hide weak nodes at the edge of coverage. A successful join rate can hide commissioning storms. A battery estimate can hide repeated retransmissions, long receive windows, sensor warm-up, or firmware update traffic. Simulation methodology therefore needs distributions, scenario deltas, and trace audits, not only a chart that says the average passed.

The scenario pack should preserve enough state to explain those tails. Network state includes topology, queue policy, retry timer, route repair, airtime, channel occupancy, packet size, and gateway backhaul. Device state includes sleep schedule, firmware version, buffer size, sample interval, watchdog reset, and power mode. Measurement state includes clock sync, capture point, pilot size, RF condition, and log-retention window. In ns-3, that may mean preserving helper configuration, mobility or propagation assumptions, packet traces, and random seeds. In OMNeT++/INET, it may mean NED topology, ini parameters, result filters, and module versions. In Cooja, it may mean mote firmware commits, radio medium, serial logs, and packet captures.

The under-the-hood review asks whether the mechanism that controls the decision is visible. If a LoRaWAN result depends on path loss, spreading factor, duty cycle, or downlink scarcity, the pack should expose those inputs and plan an RF or gateway-log check. If a mesh result depends on RPL repair, parent choice, or 802.15.4 interference, the pack should preserve route-change evidence and not only final delivery ratio. If an application result depends on MQTT session behavior, CoAP retransmission, TCP reconnect, or TLS handshake cost, packet timing and broker logs should be part of the validation path. Variation is useful because it points to the assumption that must be measured next.

• Distribution evidence: Latency percentiles, packet-loss spread, retry counts, queue depth, join time, and weak-node behavior.
• Sensitivity evidence: Which input changes the conclusion when placement, traffic, seeds, interference, or gateway count moves.
• Residual risk: What the simulator cannot prove until captures, surveys, pilots, or production telemetry are available.

17.10 Prerequisites

You should already be comfortable with:

• Network Design Methodology: how decisions, assumptions, scenarios, evidence, validation, and records fit together.
• Network Simulation Tools: how to choose a simulator, emulator, capture tool, survey method, or field telemetry source.
• Network Design Introduction: how simulation evidence fits the wider topology, protocol, traffic, and deployment decision path.
• Networking basics: packets, routing, layers, addressing, latency, loss, and throughput.

17.11 What This Chapter Adds

Earlier chapters explain the overall evidence loop and the available tool classes. This chapter focuses on the part that most often determines whether simulation evidence is useful: the scenario pack.

17.12 Build Network Scenario Packs

A scenario pack turns a broad network question into a repeatable study. The team names the decision, selects the cases that could change the answer, records model boundaries, packages each run, reads results against pre-set bands, and names the field evidence that will test the most important assumptions.

The loop introduced in the overview is deliberately practical. Each pass should either support a network decision, expose an assumption that needs validation, or show that the current design needs another iteration.

17.13 Method 1: Define the Decision and Bands

A simulation result is weak if the acceptance target appears after the result is known. Define the decision and interpretation bands first.

Good criteria come from the application. A classroom sensor demo, warehouse alarm system, building-control loop, and battery-powered farm monitor should not share the same pass band. The simulator can compare modeled behavior; it cannot invent operational acceptability.

17.14 Continue to the Next Part

Carry this evidence into Network Simulation: Method Selection and Evidence, which begins with Method 2: Build the Scenario Matrix.