Chapters

Practice: LoRaWAN Simulation

lorawan
simulation
lab

This lab belongs to LoRaWAN Common Pitfalls

Start Simple

This section: Start Simple — Picture a field meter that sends one reading during a desk test.

Use the Rehearsal to Find the Missing Proof

Picture a field meter that sends one reading during a desk test. The record appears on screen, yet no one knows whether a second receiver heard it, whether the reply window opened, or whether the value still means the same thing after decoding. A neat trace is only the start of the review.

LoRaWAN means Long Range Wide Area Network, a system for small messages over long radio links. A gateway is a device that hears those radio messages and passes them onward. A payload is the useful data carried inside a message. Follow one payload from the meter, through each gateway copy, to the service that makes the final record.

Change one condition at a time. Remove a gateway copy, delay the reply, repeat the same message, and alter the radio setting chosen by the simulation. Record which symptom appears, what the operator should decide, and what real field proof is still missing.

A simulation cannot prove range, interference, battery life, or local installation quality. The deeper lab steps show how timing records, duplicate handling, decoded values, and release checks turn the rehearsal into a bounded evidence plan.

Use this lab as a rehearsal for reading evidence. A simulated packet trace is not field proof, but it can teach the habit of asking what each record shows and what it leaves unproven. Start with one uplink, one receive window, one ADR decision, and one duplicate gateway copy. Then decide what a release reviewer would still need from the real deployment.

In 60 Seconds

This lab uses simulated LoRaWAN records instead of an external emulator. You will inspect packet traces, Class A receive timing, ADR decisions, duplicate gateway copies, decoded payload samples, and security symptoms. The goal is not to build a radio stack. The goal is to learn how an operator decides whether simulated records are meaningful enough to prepare for field validation.

Learning Objectives: What This Lab Checks

This section: Learning Objectives: What This Lab Checks

  • How to read a simulated LoRaWAN packet trace without confusing trace fields with application meaning.
  • How Class A timing records separate uplink success from downlink opportunity.
  • How ADR decisions should be tied to link records and exception handling.
  • How duplicate gateway copies are deduplicated before application delivery.
  • How security symptoms such as counter rejects and MIC errors route to security checks.
  • How to write a release packet that treats simulation as preparation, not final proof.

Learning Objectives

This section: Learning Objectives

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

  • Identify the fields needed in a LoRaWAN packet-trace check.
  • Explain Class A receive-window behavior from a timeline record.
  • Check an ADR decision using link records and exception notes.
  • Confirm duplicate gateway-copy handling before application routing.
  • Classify simulated failure symptoms and assign the right owner.
  • Prepare a simulation release record with field-validation triggers.

Lab Check Map

This section: Lab Check Map — The lab follows a controlled record path from trace to release packet.

The lab follows a controlled record path from trace to release packet.

Pause before applying the “each stage must leave a visible record; uncertainty goes to an owner before release”–“failed / ambiguous to owner” decision, then inspect Figure 1. It places “Each stage must leave a visible record; uncertainty goes to an owner before release” against “Failed / ambiguous to owner”, exposing the evidence behind this claim: LoRaWAN simulation evidence path from bounded lab question through packet, timing, ADR, and payload checks to named owner action and a bounded release claim.

Seven-step LoRaWAN simulation record: define the bounded question, capture packet evidence, verify Class A timing, justify the ADR decision, check payload semantics, assign any failed or ambiguous stage to a named owner, and release only the claim supported by the evidence packet.
Figure 1: LoRaWAN simulation evidence path from bounded lab question through packet, timing, ADR, and payload checks to named owner action and a bounded release claim

Figure 1 connects the lab question to packet, timing, ADR, and payload checks, with failed or ambiguous results sent to an owner before release.

Use the map this way:

  • Lab question: decide what the simulation is testing.
  • Packet trace: inspect device address, counter, port, message type, and payload status.
  • Class A timing: confirm receive opportunities after an uplink.
  • ADR decision: connect adjustment to link records and exception policy.
  • Payload check: verify the application receives useful decoded fields.
  • Owner action: assign rechecks for failed or ambiguous records.
  • Release packet: record what the simulation proved and what still needs field validation.

Minimum Check Knowledge

This section: Minimum Check Knowledge

Trace

Packet fields are records

Device address, counter, port, MIC status, and payload status explain what the simulated packet path did.

Timing

Downlink has a window

Class A downlink depends on receive opportunities after an uplink, not on an always-listening device.

ADR

Adjustment needs records

ADR decisions should reference link history, exception devices, rollback rules, and monitoring ownership.

Release

Simulation is preparation

Simulated success prepares field validation; it does not replace gateway and application records from the target environment.

Step 1: Capture the Packet Trace

This section: Step 1: Capture the Packet Trace — Start with a simulated packet trace.

Start with a simulated packet trace. The trace should show what the device sent, what the gateway heard, and what the application decoded.

  • In the packet trace view, set a bounded scenario and record its device address, frame counter, port, message type, MIC state, and payload.
  • Compare the device row with the gateway-copy and server-route rows before calling the uplink delivered.
  • In a local Python record model, DevAddr=26011ABC, FCnt=7, FPort=1, MIC=valid, and payload=temp=21.4 were stored together.
  • That model also merged two gateway copies into one application record; this is a deduplication check, not a radio capture.
  • In the actual simulator, retain its own trace and decoded application sample, or mark either missing in the release packet.

Use Figure 2 with “Scenario” to ask what this simulated uplink should prove, and for which payload and location. Compare the uplink-frame fields with the gateway copy, server route, and application sample to make the packet-trace check reviewable.

An uplink frame split into MType, DevAddr, FCnt, FPort, FRMPayload, and MIC segments, with frame-counter and payload status chips, above a path from device uplink to gateway copy, server route, and application sample.
Figure 2: LoRaWAN packet-trace simulation check: a scenario banner over an uplink-frame anatomy bar (MType, DevAddr, FCnt, FPort, FRMPayload, MIC), two green status chips for frame counter and payload, and a device-to-application path of gateway copy, server route, and application sample.

Read Figure 2 with “Scenario” as the anchor. Then inspect the “Uplink frame” fields, including “MType”, and trace the device uplink through the gateway copy and server route to the application sample.

Check the trace this way:

  • Does the scenario state what the simulated device is supposed to prove?
  • Does the trace show device address, counter state, port, message type, and MIC status?
  • Does the gateway record show whether the packet was heard and forwarded?

Practice Exercises

This section: Practice Exercises — The old practice worksheet chapter is folded into this lab.

The old practice worksheet chapter is folded into this lab. Use these exercises after the packet trace, timing, ADR, and release-packet checks.

Step 2: Fill the Record Worksheet

This section: Step 2: Fill the Record Worksheet

Fill a one-page worksheet for a proposed LoRaWAN device:

  • Open a worksheet beside the packet trace and enter the scenario name and model version at the top.

  • Copy the trace’s actual device, gateway, server, and application fields into separate rows.

  • Put the timing, ADR, and duplicate-copy decisions beside their supporting records, not beside a general pass mark.

  • Mark missing evidence with an owner and recheck trigger so the worksheet cannot imply a field release.

  • application promise;

  • regional profile and payload size;

  • device class and downlink promise;

  • activation method and counter reset behavior;

  • gateway records and duplicate-copy handling;

  • ADR policy and exception devices;

  • application acceptance record;

  • release owner and retest trigger.

Step 3: Decide the Device Class

This section: Step 3: Decide the Device Class — Given a low-power meter that sends periodic readings and rarely receives commands, choose the class behavior and state what records would prove the downlink promise.

Given a low-power meter that sends periodic readings and rarely receives commands, choose the class behavior and state what records would prove the downlink promise. The answer should explain why a successful uplink does not prove routine downlink availability.

  • In the multicast workbench, select the Class A fallback and note when the uplink opens RX1 and RX2.
  • Compare the Class B ping-slot and Class C window views against the meter’s command promise.
  • A local timing model put an uplink at time 0, RX1 at 1, RX2 at 2, and a command at 3; it queued that command for the next uplink.
  • Those times are model units, not measured LoRaWAN timings; retain the browser workbench’s own status before claiming delivery.

Run it: Before you name the class, watch how each class actually delivers a downlink in the workbench below. Run the Class A fallback path to confirm the meter only hears a command right after its own uplink, then compare Class B ping slots and the Class C window to see the power-versus-downlink trade you are choosing against. Send a Configuration command or Emergency alert and read the Watch For panel to see which devices are Ready versus waiting on a Beacon or clock — that is the evidence a class decision must cite about the downlink promise.

Step 4: Check Activation Recovery

This section: Step 4: Check Activation Recovery — Given a device that returns after reset with rejected frames, identify whether the next check belongs to activation, frame counters, key custody, application decoding, or radio link records.

Given a device that returns after reset with rejected frames, identify whether the next check belongs to activation, frame counters, key custody, application decoding, or radio link records. State what record clears the issue.

  • In the OTAA workbench, follow JoinRequest, DevNonce, MIC, and JoinAccept in the event view.
  • After reset, compare the new join attempt and counter state with the prior accepted session.
  • Record whether a nonce, MIC, or counter rejection appears before investigating payload decoding.
  • Use its actual event record when completing the recovery answer.

Run it: Work this activation-recovery question in the OTAA join workbench below. Step a JoinRequest through to JoinAccept and watch the DevNonce and MIC so you can tell an activation or key fault (bad MIC, replayed DevNonce) from a frame-counter or decoder fault. Switch the Key model between the LoRaWAN 1.0.x and 1.1 split-key models, then reset the device and re-join to see which record — nonce, MIC, or frame counter — actually clears the rejected-frame symptom the exercise describes.

Step 5: Compare ADR Suitability

This section: Step 5: Compare ADR Suitability — Given mixed fixed and moving devices, identify which devices can use ADR from recent uplink history and which need conservative settings or exception handling.

Given mixed fixed and moving devices, identify which devices can use ADR from recent uplink history and which need conservative settings or exception handling.

  • In the ADR animation, select Rooftop meter and record its SNR and link-margin history before accepting a proposal.
  • Repeat with Mobile tracker and Obstruction event, noting which history changes or invalidates the proposal.
  • A local Python decision model classified a fixed device with margin 12 as eligible for review and a moving device with margin -2 as an exception.
  • These are stated model inputs, not measured SNR or the animation’s output; capture its own values for a lab decision.

Run it: Decide ADR suitability by running each device profile in the ADR animation below. Compare a Rooftop meter against a Mobile tracker and an Obstruction event and watch how SNR and link margin drive the ADR decision toward a lower spreading factor and TX power — or fail to, when the link keeps moving. The stable fixed node converges to an efficient data rate, while the mover shows why it needs conservative settings or exception handling, which is exactly the fixed-versus-moving split this exercise asks you to make.

Step 6: Check Payload and Airtime

This section: Step 6: Check Payload and Airtime — Given a payload that grew during product design, decide whether to reduce payload, change cadence, add gateway records, revise ADR policy, or reject the release packet until the airtime effect is checked.

Given a payload that grew during product design, decide whether to reduce payload, change cadence, add gateway records, revise ADR policy, or reject the release packet until the airtime effect is checked.

  • In the capacity workbench, set the region, original payload length, report interval, repeats, and spreading-factor mix.
  • Increase only payload length and copy the Formula Trace airtime and headroom before changing another input.
  • Try one mitigation at a time, then compare the trace with the enlarged-payload baseline.

Run it: Test the grown payload in the capacity workbench below before you accept or reject the release. Set the Region model and raise the Application payload to the new size, then read the Formula Trace to see airtime climb and duty-cycle headroom shrink. Now try the mitigations the exercise lists — lengthen the Report interval, cut Uplink repeats, or shift the Spreading-factor mix toward SF7-SF9 — and watch which one restores margin, so your decision to reduce payload, change cadence, or reject the packet is backed by the airtime numbers.

Step 7: Route the Multi-Issue Scenario

This section: Step 7: Route the Multi-Issue Scenario — When a scenario includes missed uplinks, duplicate gateway records, invalid MIC errors, and application decode gaps, split the records by owner before proposing a fix.

When a scenario includes missed uplinks, duplicate gateway records, invalid MIC errors, and application decode gaps, split the records by owner before proposing a fix.

  • In the review worksheet, put gateway hearing, server acceptance, and decoded application sample on separate lines.

  • Assign invalid MIC to the activation/security check and a missing decoded field to the application decoder check.

  • Treat duplicate gateway copies as a server deduplication question; the local model produced 2 copies and 1 application record.

  • Keep missed uplinks as missing evidence until a gateway or device trace identifies where the path stopped.

  • Does the server record show whether duplicate copies were merged?

  • Does the application sample show useful decoded fields?

  • Are missing or rejected records classified instead of ignored?

Check 1: Packet Trace Records

This section: Check 1: Packet Trace Records

Step 8: Check Class A Timing

This section: Step 8: Check Class A Timing — Class A timing helps learners separate uplink success from downlink opportunity.

Class A timing helps learners separate uplink success from downlink opportunity. A simulation record should show the uplink, receive opportunities, downlink attempt, and fallback path.

  • In the timing view, locate the uplink completion and the two receive opportunities before placing a downlink attempt.
  • Record whether that attempt was delivered, delayed, missed, or queued; a successful uplink alone is not the answer.
  • The local Python timing model queued a command at model time 3, after RX1=1 and RX2=2 had passed.
  • Label those times as model units, then attach the actual browser trace or field timing record before making a command promise.

A release decision about the “class a”–“bi-directional” decision needs “end-devices”, not a slogan. Inspect Figure 3 through “Class A” and “Bi-directional” to check this claim: LoRaWAN device class comparison: Class A opens RX1 and RX2 windows only after an uplink (lowest power), Class B adds beacon-scheduled slots, and Class C listens almost continuously.

LoRaWAN device class comparison timeline showing Class A receive windows only after an uplink, Class B beacon-scheduled receive slots, and Class C near-continuous listening.
Figure 3: LoRaWAN device class comparison: Class A opens RX1 and RX2 windows only after an uplink (lowest power), Class B adds beacon-scheduled slots, and Class C listens almost continuously.

Read Figure 3 with “Class A” as the anchor; treat “Bi-directional” as the first comparison. Then connect “end-devices” with “Lowest Power”. Those labels make LoRaWAN device class comparison: Class A opens RX1 and RX2 windows only after an uplink (lowest power), Class B adds beacon-scheduled slots, and Class C listens almost continuously a traceable part of the “class a”–“bi-directional” decision, not an unsupported assertion.

Check timing records this way:

  • Does the timeline distinguish uplink completion from receive opportunity?
  • Does the downlink attempt show whether it was queued, delivered, delayed, or missed?
  • Does the fallback action explain what happens if the device is not listening?
  • Does the application distinguish sensor-report success from command-delivery success?
  • Is the recheck trigger tied to device class, command promise, and owner action?

Check 2: Class A Timing

This section: Check 2: Class A Timing

Step 9: Check ADR and Duplicate Copies

This section: Step 9: Check ADR and Duplicate Copies — ADR and duplicate-copy handling are easier to understand in simulation, but the check still needs clear records and boundaries.

ADR and duplicate-copy handling are easier to understand in simulation, but the check still needs clear records and boundaries.

  • In the ADR history view, identify the fixed or moving device and the observations behind any rate proposal.
  • In the packet path, compare gateway copies by device address and frame counter before counting application samples.
  • The local Python record model counted two copies of one counter and one application record after deduplication.
  • Record any exception device and rollback trigger beside the ADR decision, then recheck on field radio evidence.

To ground the “history”–“adr” decision through “proposal” in visible evidence about “history”, inspect Figure 4. Its named elements “history” and “ADR” frame the claim that LoRaWAN ADR and duplicate-copy simulation check showing link history, ADR proposal, exception device, gateway copy, deduplication, decoded sample, and release decision.

LoRaWAN ADR and duplicate-copy simulation check with link history, ADR proposal, exception device, gateway copy, deduplication, decoded sample, and release decision.
Figure 4: LoRaWAN ADR and duplicate-copy simulation check showing link history, ADR proposal, exception device, gateway copy, deduplication, decoded sample, and release decision.

Trace the review path across Figure 4 from “history” to “ADR”, then from “proposal” to “Exception”. Retain the link history, ADR proposal, and exception-device record when revisiting the ADR decision.

ADR and duplicate-copy checks:

  • Does the ADR decision reference link history rather than a fixed preference?
  • Are exception devices identified before applying broad settings?
  • Does the simulation show duplicate copies from multiple gateways as expected behavior?
  • Does the server merge duplicates before application routing?
  • Does the decoded sample show one application record was created?
  • Are rollback and field-validation triggers documented before release?

Check 3: ADR And Duplicate Copies

This section: Check 3: ADR And Duplicate Copies

Step 10: Write the Lab Release Packet

This section: Step 10: Write the Lab Release Packet — The lab is complete only when learners can explain what the simulation proved and what it did not prove.

The lab is complete only when learners can explain what the simulation proved and what it did not prove.

  • In the release worksheet, list the accepted packet, timing, ADR, duplicate-copy, and decoded-payload records.
  • Separate modeled results from actual browser traces, and mark any missing trace as unverified.
  • Assign an owner to MIC, counter, decode, or delayed-command failures before setting a release state.
  • State which gateway placement and field measurements remain necessary before deployment.
Trace

Accepted records

Store packet traces, timing records, ADR decisions, duplicate-copy records, and decoded samples.

Limits

Simulation boundary

Name what was not represented, including physical environment, gateway placement, and field variation.

Failure

Symptom routing

Route rejected counters, MIC errors, missing payloads, and delayed commands to the right check path.

Next

Field validation

Define the field records needed before the simulated design can be trusted outside the lab.

Check 4: Lab Release Packet

This section: Check 4: Lab Release Packet

Match The Simulation Records

This section: Match The Simulation Records

Order The Simulation Check

This section: Order The Simulation Check

Label The Simulation Lab Map

This section: Label The Simulation Lab Map

Common Pitfalls

This section: Common Pitfalls

Simulation helps learners practice record checks. It does not prove real gateway placement, physical environment, or application operations.

A complete lab record connects device trace, gateway hearing, server handling, decoded application data, and owner actions.

Rejected counters, MIC errors, missed downlinks, and decode failures are useful learning records when they are classified and routed.

A simulation release packet should name exactly what field records are required before the same design is trusted outside the lab.

Overview: Simulation Is A Bounded Proof

A LoRaWAN simulation lab is useful when it proves one narrow claim and records the boundary around that claim. The learner should be able to say which scenario was tested, which records were accepted, which records were missing, and which field checks still own the final release decision.

For example, a desk simulation may show a sensor uplink, a valid frame counter, one gateway copy, a network-server route, and a decoded temperature field. That is useful evidence for the packet path, but it is not proof that the field gateway hears the same device through walls, that RX windows match the command promise, or that ADR remains safe after the device moves. The release claim should stay as narrow as the records: this scenario, this profile, this payload, this timing assumption, this server route, and these missing field checks.

The strongest lab outcome is a release answer, not a pass/fail screenshot. It separates useful evidence from missing evidence, names exceptions, assigns an owner, and states the trigger that forces a field test. If those pieces are absent, the simulation may still be a good exercise, but it is not yet a release record. A short note such as "bench trace only, field gateway unproven" is more honest than a broad green label. It also tells the next reviewer exactly where to resume.

Inspect Figure 5 to see how a simulation result becomes a bounded release answer without claiming field proof.

LoRaWAN simulation release answer structure showing useful evidence, missing evidence, decision, exception, owner, and trigger.
Figure 5: Simulation evidence becomes usable when the release answer separates accepted proof from missing field checks, exceptions, owners, and retest triggers.

Read Figure 5 from what the modeled run can support: a sensor uplink with a valid frame counter, one gateway copy routed by the network server, and the decoded temperature field. Keep the missing evidence beside it. The browser run cannot prove that a field gateway hears through real walls, receive windows meet a command promise, or ADR remains safe after movement. The decision therefore releases only the bounded claim supported by the record. Failed records stay visible, an owner is named for the next field check, and field proof becomes the retest trigger before anyone trusts the result outside the lab.

Claim

Name the scenario

State the device behavior, region, activation method, payload, and downlink promise before reading the trace.

Record

Keep the path together

Connect device frame, gateway copy, network-server handling, application decode, and owner action in one record.

Limit

Preserve the boundary

Do not let simulated success stand in for gateway placement, interference, antenna orientation, or field operations.

Practitioner: Write The Replayable Lab Record

The lab record should let another reviewer replay the decision without rerunning the exercise. That means the record needs enough packet, timing, ADR, duplicate-copy, payload, security, and owner evidence to explain the release decision.

Write the record as a trace through surfaces, not as a summary of screens. A useful entry might start with "meter-south-lot, EU868 profile, OTAA join, 12-byte uplink, Class A command promise, ADR enabled for fixed devices only." It then lists the device frame fields, the gateway copies, the server route, the decoded application sample, the RX1/RX2 queue result, the ADR basis, and the field condition still outside the simulation. Another reviewer should be able to see why the claim passed, why a broader claim did not pass, and which owner has to collect the next record.

When a record fails, preserve the failure instead of rewriting the scenario until it looks clean. A frame-counter reject belongs to activation and security state; a missing application row belongs to route, decoder, or storage evidence; a missed command belongs to Class A timing and queue behavior; duplicate gateway copies belong to server deduplication. Keeping those failures in separate rows prevents one vague "LoRaWAN failed" note from hiding the actual next action.

Replay Checklist

  1. Start with the lab question and expected device behavior.
  2. Capture packet fields, gateway copies, network-server route, and application decode.
  3. Separate uplink success from Class A downlink opportunity.
  4. Tie ADR changes to link history, exception devices, and rollback rules.
  5. Classify failures as radio, activation, counter, timing, decode, or owner-record gaps.
  6. Name the field-validation trigger that must pass before release.

Worked Record: Missed Downlink In A Good Uplink Test

The device sends an uplink and the application decodes the payload, but a command is missed. A replayable record separates the good uplink path from the downlink promise, checks RX1/RX2 timing, records queue behavior, assigns the command owner, and adds a field test for the promised response time.

Under The Hood: Simulation Can Hide Coupled Failures

LoRaWAN failures often cross boundaries. A payload-size change can affect airtime, data-rate fit, ADR decisions, duty pressure, downlink capacity, decoder versioning, and field support. A simulation that checks only one layer can miss the coupling that matters in production.

Consider a firmware change that adds a diagnostic field and increases the reporting cadence. The application decoder may still pass because the JSON shape is recognized, while the radio path becomes less tolerant of low data rates, retries, and busy channels. If ADR then lowers spreading factor for fixed devices, moving or obstructed devices can become exceptions. If the product also promises operator commands, the extra uplinks can change when downlinks are queued and whether the device is listening. The simulation record should therefore connect payload fit, timing, ADR, duplicate handling, and owner action instead of treating them as independent checkboxes.

Security and state can hide the same kind of coupling. A gateway can hear a frame with good radio evidence while the network server rejects it because the activation context or frame counter is wrong. A decoder can accept a sample while the release owner has not proved storage, alerting, or rollback behavior. The under-the-hood habit is to ask which boundary accepted the record, which boundary rejected it, and which later change would make the evidence stale. That stale-evidence check is what keeps simulation results useful after firmware, payload, gateway, or owner assumptions change.

Payload

Size changes radio behavior

More fields can push packets over practical limits when the device needs slower settings or retries.

State

Counters and keys gate acceptance

A gateway can hear a frame while the network server rejects it because activation or counter state is wrong.

Operations

Owners close the loop

A lab result is weak if no one owns the next field measurement, rollback rule, or retest after payload and firmware changes.

Summary

This section: Summary — This lab uses simulated LoRaWAN records to practice packet-trace checks, Class A timing checks, ADR decision checks, duplicate-copy handling, payload checking, security symptom routing, and release packet writing.

This lab uses simulated LoRaWAN records to practice packet-trace checks, Class A timing checks, ADR decision checks, duplicate-copy handling, payload checking, security symptom routing, and release packet writing. A strong lab result explains both what the simulation proved and what still needs field validation.

Key Takeaway

This section: Key Takeaway — A LoRaWAN simulation lab should test gateway placement, airtime, collisions, spreading factors, and traffic assumptions.

A LoRaWAN simulation lab should test gateway placement, airtime, collisions, spreading factors, and traffic assumptions. Simulation is a planning aid, not a replacement for measured deployment data.