LoRaWAN Roaming Routing Workbench

Trace how LoRaWAN roaming routes uplinks, downlinks, joins, and handover decisions through home and visited network servers.

animation
lorawan
lpwan
roaming
backend-interfaces
netid
mobility
intermediate
Interactive LoRaWAN roaming workbench covering passive roaming, activation roaming, handover roaming, NetID and DevAddr routing hints, agreement failures, MIC/frame-counter checks, and visited-gateway downlinks.
Passive roaming Activation roaming Handover roaming Backend interfaces

LoRaWAN Roaming Routing Workbench

Follow one sensor as its frames are heard by home and visited gateways. The device still transmits normal LoRaWAN frames; roaming is decided by agreements, addressing hints, server policy, and authenticated backend exchanges.

Passive route Current roaming decision
hNS remains serving Where device/session context is authoritative
Agreement active Business and technical policy gate
MIC pending Integrity and frame-counter state

Scenario

Pick a roaming problem. Step through it and watch both the packet path and the server-side decision change.

Beginner ramp

LoRaWAN end devices usually do not attach to a specific gateway. They transmit, any gateway may hear them, and the network servers decide which copy is valid and where it must be routed.

Do not assume
  • Roaming is not automatic without an agreement.
  • The visited network should not see application plaintext.
  • Overlap can create duplicate uplinks that must be deduplicated.
Passive roaming ready Step through the path from a visited gateway to the home network server.
ED -> visited GW -> fNS -> hNS/sNS Packet path
Encrypted payload forwarded Security posture
LoRaWAN roaming route map A sensor is heard by home and visited LoRaWAN gateways. Routes highlight server-to-server roaming and downlink scheduling. Home operator coverage Visited operator coverage Overlap does not mean the device chooses a network. Servers route, validate, and deduplicate received frames. Home GW hears local frames hNS / sNS device context App server application data Join server activation path Visited GW radio reception fNS / vNS roaming peer End device uplink Home NetID 0x000013 Visited NetID 0x00002A PRStartReq / XmitDataReq / HRStartReq DevAddr includes routing bits; exact NwkID width depends on NetID type
Uplink frame DevAddr 26 01 1A C4 | FCntUp 1025 | MIC pending The visited side forwards the PHYPayload and radio metadata, then the serving side validates the device state.
Roaming policy PrAllowed = true | Downlink via fNS allowed Agreement and policy decide whether backend messages are accepted.
Server decision Accept after MIC and frame-counter check Duplicate copies from overlap are filtered before application delivery.
Uplink/backend forwarding Downlink scheduling Blocked policy path Home network Visited network
Teaching note: Roaming starts as a server-side routing problem. The sensor sends the same LoRaWAN uplink format; gateways and network servers decide what to forward and what to discard.
Diagnosis

The device is under visited coverage. The visited gateway hears the uplink and the forwarding network server uses addressing and policy to locate the serving home network.

Operator lever

Keep the roaming agreement, backend authentication, downlink permissions, and DevAddr or NetID routing data aligned between partners.

Misconception check

The end device does not need to know which gateway heard it. Server-side routing and deduplication make the path work.

Passive roaming

The forwarding network receives radio traffic and forwards accepted frames to the serving or home network. The home side keeps device context and application routing.

Activation roaming

A join can start while the device is outside home coverage. The visited side discovers the home/join path and a supported roaming activation flow creates a session.

Handover roaming

Serving responsibility can move to another network server when policy and backend support allow context transfer. It is not just a radio signal handoff.

Independent learning reference
Technical accuracy anchors
  • Home NS holds device, service, and routing profiles; a visited NS is another NS with a business and technical agreement.
  • Passive roaming applies to LoRaWAN 1.0 and 1.1 end devices and uses network-server backend messages.
  • Roaming activation covers joins outside home coverage, subject to network policy and server discovery.
Frame and key scope
  • MIC and frame-counter validation decide whether a forwarded uplink is accepted.
  • Application payload stays encrypted across the visited network path.
  • DevAddr and NetID help route traffic, but exact NwkID extraction depends on the assigned NetID type.
LoRa Alliance TS002-1.1.0 Backend interfaces and roaming message flows for network servers, join server, passive roaming, handover, and activation. TS002 PDF Detailed packet transmission, NetID, DevAddr, and roaming activation figures. AWS IoT Wireless roaming guide Implementation-oriented passive roaming overview and public network support notes.