15 Network Simulation: Tool Landscape

15.1 Start With the Decision

Run several cases, not one perfect case. Change one assumption at a time.

15.2 Route Overview

This is part 1 of 2. Continue with Network Simulation: Selection Methods.

15.3 Part Objectives

• Choose a defensible design using choose tools by question.
• Validate tool output validity boundaries with a concrete scenario and pass criteria.

15.4 Chapter Roadmap

• Start With the Evidence You Need
• Phoebe’s Field Notes: Why A Simulator’s Default Antenna Is Not Just A Number Off
• Choose Tools by Question
• Match Tool Class to Evidence
• Tool Output Validity Boundaries
• In 60 Seconds
• Prerequisites
• What This Chapter Does

15.5 Start With the Evidence You Need

Choose the Test Before the Tool

Picture a team planning a thousand trackers for a large warehouse. Building the whole site first would cost too much. A computer model can help, but only if it answers the same question the team must decide.

The design lead should write one claim and a pass rule. For example: a warning must reach the local desk within two seconds when one radio path is blocked. Then choose a tool that can represent the needed devices, messages, walls, failures, and timing. Leave out detail that cannot change the decision.

Run several cases, not one perfect case. Change one assumption at a time. Compare the model with a small field test and record where they disagree. Never present a smooth chart as proof when the input was guessed.

Ask a second person to read the setup before running it. They should be able to state which parts are real, which are estimated, and which are left out. Give every estimate a reasonable high and low value. Show whether the decision changes across that range.

Save the setup, random starting value, tool version, and result. Repeat enough runs to show normal spread rather than one lucky trace. End with a field check that can reject the model. A model that cannot be challenged is only an illustration.

Match the picture to the audience. A designer may need the main trade-off. A reviewer needs the assumptions and spread. A field worker needs the check to repeat on site. Use the same result, but do not hide its limits behind a polished animation.

Close with a choice and an open list. State what the model supports, what it rejects, and what remains unknown. Give each unknown an owner or field check. If no decision changes, stop adding detail and spend the effort on real evidence.

Use a short model card. Name the question. Name the planned site. List the facts taken from measurements. Mark each estimate. Give the pass rule. State the number of runs. Link the raw results.

Then ask simple checks. Can the tool represent the failure? Can the field team measure the same result? Does a different starting value change the choice? Does the result still pass at the high and low estimate? What real test could prove it wrong?

The card makes comparison fair. Two tools can answer the same question. One may model radio paths well. Another may run real device code. Neither is best for every claim. Choose the smallest tool chain that leaves a clear test trail.

No model can copy every person, building, or radio. Practitioner selects and checks tools. Under the Hood examines event timing, radio models, repeated runs, and limits on the result.

Imagine choosing a simulator because it is familiar, then discovering the real risk was firmware reconnect behavior or RF coverage in a warehouse aisle. Tool choice should start with the evidence question. If the claim depends on packets, code, radio conditions, installed gateways, or operations telemetry, the tool has to match that claim rather than decorate the design.

Phoebe’s Field Notes: Why A Simulator’s Default Antenna Is Not Just A Number Off

The mathematical gist. An 8 dBi antenna has $10^{8/10}=6.31\times$ linear gain. At a 20 dBm EIRP ceiling it uses 12 dBm, or 15.8 mW, of conducted power and an ideal one-lobe model occupies about 1.99 sr, 15.8% of the sphere. If conducted power were fixed instead, forgetting that gain would understate in-beam range by $\sqrt{6.31}=2.51\times$.

Math Bridge · guided foundationsHow can one antenna setting reshape a coverage model?Let Blueprint Bina connect gain, solid angle, EIRP, conducted power, and modeled range in one trace. Learn the maths

15.6 Learning Objectives

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

• Choose a network simulation or measurement tool based on the design question it must answer.
• Distinguish packet-level simulation, firmware-aware emulation, modular simulation frameworks, packet capture, RF survey, and field telemetry.
• Explain why tool output must be tied to assumptions, scenarios, metrics, and validation evidence.
• Identify when a classroom visual tool is useful for learning but insufficient for production design evidence.
• Prepare a tool-selection record that another reviewer can reproduce or challenge.

15.7 Choose Tools by Question

A network tool is only useful when it observes or models the behavior behind a real design decision. A simulator can compare alternatives before deployment. An emulator can exercise firmware paths. A packet capture can show what actually crossed an interface. An RF survey can reveal site conditions. Operations telemetry can show whether a deployed network stays healthy over time. The mistake to avoid is treating all of those outputs as equivalent. A packet-level model, a Contiki-NG mote run, a Wireshark trace, a LoRaWAN gateway export, and a pilot dashboard answer different questions.

Start with the decision, then choose the least complex tool that can produce credible evidence. A classroom topology visualizer may help a learner understand routing, but it cannot prove LoRaWAN coverage, Wi-Fi roaming, Thread mesh recovery, gateway backhaul resilience, or battery life without additional measurements. A design team should first ask whether the claim depends on modelled packets, real firmware, real RF, installed gateways, application logs, or long-run operations. That question keeps tool choice practical. If the risk is MQTT reconnect behavior after broker failover, a small broker test plus packet capture may beat a large radio simulation. If the risk is RPL repair after a parent disappears, ns-3, OMNeT++/INET, or Cooja may be worth the setup. If the risk is metal shelving blocking coverage, an RF walk test and pilot node logs carry more weight than a diagram.

Start with the question in Figure 15.1, then identify the fidelity need before choosing a tool class. The scenario plan and validation source lead to a decision record containing the basis, limits, and rejected tools.

The route also protects reproducibility. Before the tool is run, the team should name the scenario, metric, version, input files, random-seed policy where relevant, capture point, gateway log source, and validation check. After the tool is run, the result should say what it can support and what it cannot support. That boundary is the difference between evidence and decoration.

• Model tools: Useful for repeatable comparisons of topology, routing, traffic, queueing, and protocol behavior.
• Measurement tools: Useful for checking real packets, RF conditions, gateway health, installation effects, and operational drift.
• Review artifacts: Tool version, inputs, scripts, traces, assumptions, model limits, and validation source must travel with the result.

15.8 Match Tool Class to Evidence

Use ns-3 or OMNeT++/INET when the question is about repeatable network behavior such as routing recovery, queue depth, protocol overhead, contention, or scale. Use Cooja with Contiki-NG when constrained-node firmware, mote logs, RPL, 6LoWPAN, or low-power stack behavior matters. Use Wokwi, Renode, or board-level test harnesses when firmware interaction is more important than large-scale radio realism. For a Thread or Zigbee mesh, the practitioner decision may be whether powered-router density and retry limits keep recovery inside the service target. For LoRaWAN, it may be whether spreading-factor distribution, duty-cycle limits, join capacity, and gateway backhaul leave enough margin. For Wi-Fi, Ethernet, LTE-M, NB-IoT, or private cellular, the relevant evidence may shift toward DHCP, DNS, roaming, SIM lifecycle, APN/VPN routing, cloud reachability, and operational ownership.

Use measurement tools when reality is the question. Wireshark or tshark can confirm MQTT, CoAP, TCP, TLS, BLE, or 802.15.4 packet behavior at a capture point. iperf3 can test throughput and jitter on IP links. ChirpStack or The Things Stack gateway logs can expose LoRaWAN joins, RSSI/SNR, frame counters, ADR behavior, and downlink limits. Broker logs, cloud IoT logs, RF survey results, and battery-current traces should be tied back to the model assumption they confirm or challenge. If a simulator predicts acceptable latency but a packet capture shows repeated TLS handshakes after every sleep cycle, the design question changes. If a gateway log shows join failures in one loading bay, the simulation needs a site-specific coverage check. If pilot telemetry shows retries concentrated after firmware update windows, the scenario pack needs maintenance traffic, not only steady-state telemetry.

A useful tool-selection record is short but specific. It names the layer under test, the tool class, the selected product or framework, the scenario, the metric, the validation source, and the rejected alternatives. For example, "use OMNeT++/INET to compare mesh recovery under one-router failure, validate the route-repair timing with a five-node pilot and packet capture, and do not use the result to claim battery life." That level of precision helps reviewers see whether the tool is strong enough without pretending it proves more than it does.

1. Name the layer. Decide whether the claim depends on RF, MAC, routing, transport, application protocol, firmware timing, or operations.
2. Pick the evidence class. Choose simulation, emulation, capture, survey, pilot, or telemetry based on that layer.
3. Preserve reproducibility. Save versions, inputs, scripts, seeds, traces, topology files, and validation notes before interpreting results.

15.9 Tool Output Validity Boundaries

Every tool has a validity boundary. ns-3 results depend on the configured propagation model, traffic model, random seeds, and protocol modules. OMNeT++/INET results depend on selected components and simplified layers. Cooja exercises Contiki-NG behavior but still abstracts physical deployment. Wireshark shows captured packets, not the packets that were lost before the capture point. RF surveys show a site at a particular time, with particular antennas, mounting, and interference. Operations dashboards show what the deployed platform retained, which may omit rejected packets, local outages, encrypted payload detail, or devices that never joined.

A good tool-selection record states which boundary matters. For LoRaWAN, that may include regional duty-cycle limits, spreading factor, payload size, gateway placement, ADR, and downlink scarcity. For Thread or Zigbee, it may include 802.15.4 channels, route repair, router density, commissioning, and interference. For Wi-Fi, it may include channel width, roaming, airtime, DHCP/DNS behavior, backhaul capacity, and access-point logs. For a cellular design, the record may include modem firmware, carrier profile, APN, NAT behavior, coverage sample, SIM or eSIM lifecycle, power-save mode, and roaming assumptions. For an application-protocol claim, it may include MQTT session expiry, QoS, retained messages, keepalive, CoAP confirmable retransmission, TCP reconnect timing, TLS resumption, and broker throttling.

The hidden mechanism is usually timing and loss. Simulators generate events from configured distributions; packet captures depend on timestamp accuracy and capture placement; RF surveys depend on antenna orientation and environmental state; gateway dashboards depend on aggregation windows; and pilots depend on who installed, provisioned, powered, and maintained the devices. A result that looks authoritative can still be wrong for the decision if one of those mechanisms is outside the tool. That is why the validation step should attack the riskiest assumption first. Compare a modelled delivery ratio with gateway counters, compare a simulated retry burst with packet traces, compare an RF prediction with measured RSSI/SNR, and compare firmware sleep-state assumptions with current traces or device logs.

• Input boundary: Topology, traffic distribution, radio model, firmware path, queue policy, sampling interval, and outage scenario.
• Observation boundary: Capture point, clock sync, antenna, channel, test duration, pilot size, and log-retention window.
• Decision boundary: The exact design choice the tool can support and the residual risk that still needs field validation.

15.10 Prerequisites

This chapter assumes you have already reviewed:

• Network Design Fundamentals: requirements, topology, gateway placement, and acceptance criteria.
• Network Design Methodology: decisions, assumptions, scenarios, evidence plans, and validation.
• Network Design Introduction: the overall evidence route from requirements to validation.

15.11 What This Chapter Does

This is a tool-selection chapter, not a simulator tutorial. It helps you decide which type of evidence tool belongs in a network design workflow and what limits to write down before trusting the output.

15.12 Continue to the Next Part

Carry this evidence into Network Simulation: Selection Methods, which begins with Tool Selection Route.