13 Building Simulation Scenarios
Building Scenario Packs That Produce Reviewable Network Evidence
13.1 Start With the Scenario That Could Fail
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.
13.2 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.
13.3 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 lifecycle in the figure is deliberately iterative. A baseline run checks the ordinary case. A stress run exposes capacity pressure. A fault run shows recovery behavior. A sensitivity run tells the team which assumption controls the decision. A validation record names the capture, RF survey, gateway log, pilot telemetry, or bench measurement that will check the model before release. The result is stronger because it says what was tested, what changed the answer, and what still needs field evidence.
- 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.
13.4 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.
- Freeze the bands first. Define pass, investigate, and fail thresholds before seeing simulator output.
- Run variation deliberately. Use replicated seeds, parameter sweeps, sensitivity checks, and fault injection where the decision depends on variability.
- Write the validation hook. Name the capture, survey, pilot, or telemetry source that will test the most important model assumption.
13.5 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.
Phoebe’s Why
This chapter’s LoRaWAN greenhouse pilot asks whether one gateway is enough or a two-gateway plan is needed, and free-space physics gives the honest starting number: power spreads over a growing sphere, so received power falls as \(1/d^2\) no matter what protocol carries it. That average trend is exactly what a “baseline scenario” should model. But a greenhouse is full of metal trusses and glazing bars, and reflections off them are wave optics, not just distance – a direct path and a reflected path can add constructively at one plant row and cancel at the next, entirely apart from how far the gateway is. A baseline run built only on the average \(1/d^2\) trend will look comfortable and still miss the one row sitting in a local interference null. That gap between the average model and the real variance is precisely why this chapter insists on stress and validation scenarios instead of one quiet run.
The Derivation
Free-space path loss from spherical spreading, referenced at \(d_0\) and extended with a path-loss exponent \(n\) for the greenhouse’s mild clutter:
\[PL(d_0) = 20\log_{10}\!\frac{4\pi d_0}{\lambda}, \qquad PL(d) = PL(d_0) + 10\,n\log_{10}\!\frac{d}{d_0}\]
Link margin against the receiver’s decode floor:
\[\mathrm{margin} = \big[P_t + G_{\mathrm{node}} + G_{\mathrm{gw}} - PL(d)\big] - P_{\mathrm{sens}}\]
Reflection interference (wave optics) governs the variance around that average trend – a path-length difference of half a wavelength between the direct and reflected ray flips constructive to destructive:
\[\Delta d = \left(k+\tfrac12\right)\lambda \implies \text{local null, independent of average } d\]
Worked Numbers: One Gateway vs. Two, at 868 MHz / SF7
\(\lambda=0.346\) m, \(PL(d_0{=}1\ \mathrm{m})=31.21\) dB, catalog-typical \(P_t=14\) dBm, \(G_{\mathrm{node}}=0\) dBi, \(G_{\mathrm{gw}}=3\) dBi, SF7 sensitivity \(-123\) dBm, \(n=2.2\) (catalog-typical for a lightly cluttered metal-and-glass structure):
- One gateway, 250 m worst-case run: \(PL=31.21+22\log_{10}(250)=83.97\) dB; \(P_r=14+3-83.97=-66.97\) dBm; nominal margin \(=56.03\) dB
- Two gateways, 125 m to the nearest: \(PL=31.21+22\log_{10}(125)=77.34\) dB; \(P_r=-60.34\) dBm; nominal margin \(=62.66\) dB
- Gateway-count delta: \(62.66-56.03=6.63\) dB, matching \(10\times2.2\log_{10}(2)=6.62\) dB exactly – halving distance in a log-distance model is a fixed, predictable dB gain, not a guess
- Reflection null scale: \(\lambda/2=17.3\) cm – well-documented multipath nulls of 20 dB or more can occur at specific standing-wave positions near a truss or glazing bar, independent of \(d\)
Both distances carry generous average margin – the average-case model genuinely supports either plan. What it cannot rule out is a plant row that happens to sit in a local reflection null near structural metal. Two gateways do not just buy 6.6 dB of extra average margin; they buy path diversity, so a null that erases one gateway’s signal at a given row is unlikely to erase the other gateway’s differently angled path at the same spot. That is the physical reason this chapter’s own scenario-pack philosophy – baseline plus stress plus fault cases, not one best-case run – is the right way to test a propagation-dependent design, and why “the release decision should wait for measured site evidence” whenever a result leans on one path-loss assumption.
13.6 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.
13.7 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.
Scenario design
Translate the design decision into baseline, stress, fault, maintenance, environment, growth, and validation scenarios.
Repeatable runs
Choose deterministic replay, stochastic replication, parameter sweeps, sensitivity checks, or fault injection based on the question.
Reviewable outputs
Keep tool versions, inputs, seeds or sampling policy, trace files, analysis scripts, and model limits attached to the result.
Validation path
Finish with what the result supports, what remains uncertain, and which capture, survey, pilot, or telemetry source will check reality.
13.8 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.
13.9 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.
If the pass band changes after each run, the study becomes a search for a favorable story. Freeze the decision, criteria, scenario set, and review method before interpreting results. Revise them only with a clear record of why the study changed.
13.10 Method 2: Build the Scenario Matrix
Use the matrix to make coverage explicit. Not every project needs every scenario, but every omitted scenario should be a conscious decision.
13.11 Method 3: Choose the Simulation Method
Different questions need different methods. A single packet-level run is useful for debugging, but it is rarely enough for a design decision.
Deterministic scenario
Use fixed inputs to debug model mechanics, verify accounting, and make a result reproducible during review.
Stochastic replication
Repeat randomized placement, traffic timing, channel variation, or MAC behavior until the decision is stable enough to interpret.
Parameter variation
Vary one or more design variables, such as gateway location, retry policy, reporting interval, or transmit power.
Boundary search
Increase load, density, burst intensity, outage duration, or update traffic to identify where the design begins to fail.
Fault injection
Remove gateways, links, relays, parents, or backhaul paths to observe recovery and single points of failure.
Trace-driven model
Drive the simulation with measured traffic, mobility, or packet-capture timing when real workload shape matters.
Uncertainty check
Vary uncertain assumptions to see which inputs control the decision and which can be safely approximated.
Validation replay
Compare simulator output with pilot, RF survey, capture, or telemetry evidence to decide whether the model is credible.
Use lightweight methods for early screening and heavier methods for decisions that affect deployment cost, safety, operations, or long-term maintenance. The more expensive the consequence of being wrong, the stronger the scenario and validation evidence should be.
13.12 Method 4: Control Model Boundaries
Every simulator is an approximation. The point is not to model the whole world; it is to be explicit about which approximations can affect the decision.
13.13 Method 5: Package the Runs
A simulation run should be packaged so another reviewer can rerun it or understand why they cannot.
Minimum run package: decision statement, scenario matrix, acceptance bands, tool and model versions, input files, topology data, traffic definitions, seed or sampling policy, configuration files, trace paths, analysis scripts, output summary, model boundaries, validation plan, and owner.
For stochastic models, the exact number of observations depends on variability and consequence. Do not cite a universal run count. Instead, report the policy: what was randomized, how observations were generated, how stable the result was, and whether additional observations would change the decision.
Use time windows deliberately:
- Warm-up window: network joins, routing, caches, queues, or schedules reach the state being studied.
- Measurement window: metrics are collected for the scenario under review.
- Event window: bursts, failures, updates, or recovery actions occur at documented times.
- Exclusion window: setup artifacts that should not be counted are clearly marked.
13.14 Method 6: Analyze Variation
Simulation output should be read as a result set, not a screenshot. Averages are useful only after you know what they hide.
Use a result statement that keeps context attached:
scenario, traffic class, metric, distribution or interval, sample policy, seed or trace policy, tool version, model boundary, validation status, decision impact
This format prevents a number from floating away from the assumptions that produced it.
13.15 Method 7: Validate and Decide
Verification and validation are different review steps.
Check model mechanics
- Packet accounting balances sent, received, dropped, and retried events.
- Scenario inputs match the documented configuration.
- Trace analysis reproduces the reported metrics.
- Sanity checks align with protocol limits and known behavior.
Check real-world fit
- Packet captures match protocol timing and retry behavior.
- RF survey or pilot data checks coverage assumptions.
- Application traces match traffic shape and burst timing.
- Gateway logs or telemetry check recovery and maintenance behavior.
Record the outcome
- Approve the design within stated limits.
- Revise topology, protocol, traffic policy, or operations plan.
- Collect more evidence for an uncertain assumption.
- Stop a design path that repeatedly fails credible scenarios.
The simulation decision basis should make the evidence useful later. Include the selected design, rejected alternatives, scenarios passed, scenarios failed, assumptions not yet validated, evidence owners, and monitoring that will be used after deployment.
13.16 Incremental Examples
13.16.1 Classroom Wi-Fi Sensor Bench
A small lab group wants to know whether ten ESP32 temperature nodes can publish readings to a local MQTT broker every minute over one classroom access point. The scenario pack can stay simple: one baseline run, one synchronized-reporting burst, one access-point restart, and one check of broker logs and Wireshark captures. The decision is not “Wi-Fi works.” It is whether the class demo has enough margin for the planned node count, payload size, and recovery expectation.
13.16.2 LoRaWAN Greenhouse Pilot
A greenhouse team is comparing one gateway location with a two-gateway plan for soil-moisture and air-temperature sensors. A useful pack would vary spreading factors, payload interval, downlink acknowledgements, gateway RSSI/SNR assumptions, ADR behavior, and a correlated alarm event after irrigation. Tools may include ns-3 or OMNeT++/INET for traffic and queue behavior, plus gateway logs and an RF walk test during the pilot. If the result depends strongly on one path-loss assumption, the release decision should wait for measured site evidence.
13.16.3 Mixed Fleet Across Sites
A facilities program has Wi-Fi devices in buildings, Thread or Zigbee sensors in dense rooms, and LTE-M or NB-IoT monitors in remote areas. The scenario pack should separate traffic classes, route repair, gateway failure, firmware update windows, TLS reconnect storms, MQTT QoS choices, and dashboard freshness by site type. The analysis should preserve packet traces, queue metrics, retry counts, weak-node behavior, gateway backhaul events, and tool versions so operations, security, and field teams can each see which assumption they own.
13.17 Warehouse Alarm Scenario Pack
A warehouse team must decide whether the gateway plan and routing policy can support normal telemetry, alarm bursts, mobile equipment, and maintenance windows.
The result is not “the warehouse network works.” A stronger conclusion is: “Under the documented assumptions, the current plan supports the baseline and alarm-burst scenarios, but recovery depends on one gateway placement assumption that must be checked during the pilot.” That statement is reviewable and leaves a clear next action.
13.18 Practice Checks
13.19 Try It Now
Pick one proposed network simulation result from a lab, project brief, or design review and test whether it is ready to support a decision.
| Audit field | What to write down |
|---|---|
| Decision claim | The topology, gateway, protocol, traffic, battery, or release decision the result is supposed to support. |
| Scenario coverage | The baseline case plus at least two stress, burst, fault, maintenance, environment, growth, or validation cases that could change the answer. |
| Evidence package | The inputs, model boundaries, tool version, seed or sampling policy, trace path, and metric summary a reviewer could inspect. |
| Validation need | The packet capture, RF survey, pilot, bench test, gateway log, or telemetry source that should check the strongest assumption. |
| Decision outcome | Approve, redesign, pilot, collect more evidence, or stop the design path, with one named owner for the next action. |
If any row is blank, the result is still analysis evidence, not a release decision.
13.20 Find the Missing Scenario
For each one-sentence result, name the missing scenario that could change the decision:
- “Average latency is acceptable during quiet telemetry.”
- “The gateway plan passes with all nodes already joined.”
- “Delivery looks strong when the backhaul is available.”
For a stronger answer, add the measurement that would validate the model: packet capture, gateway logs, RF survey, pilot telemetry, broker logs, power profile, or field maintenance record.
13.21 Common Pitfalls
Average normal operation does not cover alarms, outages, joins, updates, environmental variation, or growth. Use a scenario pack.
Changing pass criteria after seeing the result undermines the review. If criteria change, record why and rerun the study under the new decision.
Defaults are not automatically wrong, but unreviewed defaults become hidden assumptions. Record the defaults that affect the decision.
Many IoT networks are quiet until an event, join wave, command burst, outage recovery, or update campaign makes many devices active together.
A screenshot can communicate a result, but the decision needs inputs, traces, analysis, assumptions, and validation status.
Simulation predicts behavior under modeled assumptions. Validation checks whether the assumptions and predictions are credible in the target environment.
13.22 Summary
Simulation methods and scenarios turn a network model into reviewable evidence. The strongest studies define the decision first, set interpretation bands before results are known, build a scenario matrix that includes credible stress and failure cases, package runs for repeatability, analyze variation and tail behavior, and close with validation evidence. The goal is not a perfect model. The goal is a decision that states what the evidence supports and what still needs to be checked in the field.
13.23 References
- ns-3 Tutorial - official ns-3 tutorial for packet-level network simulation.
- ns-3 Manual - official ns-3 model, configuration, and tracing documentation.
- OMNeT++ Simulation Manual - official OMNeT++ simulation environment documentation.
- INET Framework User’s Guide - official INET guide for network simulation models.
- Contiki-NG Cooja documentation - official Cooja simulator documentation for Contiki-NG.
- Wireshark User’s Guide - official packet-capture documentation for validating network behavior.
13.24 See Also
- Network Design Methodology: connect scenario results to assumptions, evidence, and release decisions.
- Network Simulation Tools: choose the simulator, emulator, packet-capture tool, survey method, or telemetry source for each scenario.
- Network Design Fundamentals: place scenario packs against requirements, topology, traffic, constraints, and review records.
- Network Traffic Analysis: interpret packet captures and field traces after a simulation result needs validation.
13.25 What’s Next
| If you want to… | Read this |
|---|---|
| Compare tools before building a scenario pack | Network Simulation Tools |
| Review the wider network design evidence loop | Network Design Methodology |
| Interpret packet captures and field traces | Network Traffic Analysis |
| Practice complete network design review | Network Design Methodology |
| Previous | Current | Next |
|---|---|---|
| Network Simulation Tools | Simulation Methods & Scenarios | Network Traffic Analysis |
13.26 Key Takeaway
Simulation methodology matters more than tool screenshots. State assumptions, run baseline and stress cases, compare against expected behavior, and treat simulation output as evidence to validate in the field.