Overview

Beyond basic functions, Firefly covers several advanced LoRaWAN topics: downlink selection and scheduling, OTAA join including join-accept delivery via gateways, differences between Class A and Class C, multicast for group downlinks, handling of relevant MAC commands, and ADR (Adaptive Data Rate) in connection with radio parameters.

Typical work focuses on analyzing downlinks (including the outbox), OTAA join and join requests that keep repeating without stable data traffic, operating Class C devices, multicast groups with correct device and key configuration, and interpreting MAC and ADR events in the packet journal. For this, devices and gateways should operate in the same region, recent uplinks should be available, and the device class plus journal and outbox data should be traceable. In Firefly these topics mainly concern organization views for devices and multicast groups, the packet journal and outbox, and device-specific configuration; in niotix the Firefly connector matters when downlinks or multicast are triggered programmatically.

Downlink Logic for Class A and Class C

Firefly handles downlinks differently depending on the device class:

• Class A
  uses recent uplink metadata and the matching RX window
• Class C
  uses immediate delivery and its own queue logic based on known gateways

For Class C, the following is especially important:

• Firefly can prioritize the most recently known gateways
• if transmission fails, additional gateways are tried
• time-on-air and queue behavior influence final delivery

OTAA join in Firefly

OTAA (Over the Air Activation) is the usual way an end device registers with the network and receives session keys and a DevAddr. In Firefly, Join Server (keys, join-request validation, join-accept creation) and Network Server (radio path, timing, gateway selection for transmission) work together; see Architecture for the role split.

Flow in brief

1. The device sends a Join Request (including DevEUI, JoinEUI, DevNonce).
2. At least one gateway receives the join request and forwards it to the Network Server; often several copies exist when multiple gateways hear the same request.
3. Join Server and Network Server validate the frame (known device, correct keys, DevNonce rules, MIC).
4. On success, the join context builds the Join Accept; the Network Server schedules it as a downlink in the RX1 or RX2 receive windows opened immediately after the join-request uplink (same principle as Class A downlinks after an uplink).
5. The device applies the join accept, derives the session, and starts data uplinks (frame counter and normal MAC session apply from then on).

Until step 5 completes, the device is not fully “on network” from an application perspective; the packet journal should show join requests and, on success, join accepts followed by data frames (see Device management).

Which gateway sends the join accept?

The join accept is a downlink and is transmitted by a specific gateway chosen by the Network Server for that transmission. The decision uses the receive paths reported for the join request (which gateways heard the request and with what quality). Typically the downlink uses one of the gateways that received the join request, often prioritized by radio quality or internal network rules (load, backhaul, configuration). It is not necessarily the same gateway used for a later data packet; what matters is that the join accept reaches the device in time in the RX1/RX2 window after the triggering join request.

If the join request is only heard weakly on one gateway but another gateway is chosen for downlink transmission, the over-the-air path for the join accept may be insufficient. The journal can then look as if the server “responds” while the device never completes join — a typical gateway and RF issue, not purely a key issue.

Troubleshooting: device does not join

Suggested order of checks:

• Device in Firefly
  DevEUI, JoinEUI (if used), and Application Key must exactly match the device (format, typos, wrong organization).
• Region and channel plan
  Device, all involved gateways, and Firefly must use the same region / channel plan; otherwise the join request may not be understood or the join accept may miss the RX windows.
• RX2 data rate and RF profile
  Mismatched RX2 settings between network and device make join-accept reception in RX2 difficult. Compare Firefly / connector settings with the device datasheet.
• Gateway reception
  In the packet journal or gateway metrics, verify the join request actually reaches the network. If it never appears, the problem is before the Network Server (antenna, distance, wrong frequency, device not transmitting).
• Join accept visible?
  If join requests arrive but there is no join accept and no data, check keys/MIC; if a join accept appears in the journal but the device still does not proceed, favor RX timing, RX2, or device firmware.

Join loop (repeated join requests)

A join loop means the device keeps sending join requests without moving to stable data traffic.

Common causes:

• Join accept not received
  Wrong RX2/region parameters, poor downlink path, or an unfavorable gateway choice for join-accept transmission (see above).
• DevNonce and replay rules
  The server rejects join requests with repeated DevNonce for the same device identity when they are invalid. A device that retries after an “almost successful” join can get stuck while still sending join requests. The root cause is often still join accept not received on the first attempt or a reset without a clean session.
• Wrong application key
  MIC validation fails or the device cannot process the join accept; the device may keep retrying join.
• Duplicate or conflicting registration
  Devices in multiple organizations or with stale parameters can produce confusing join patterns — keep registration and keys unique.

Multicast

Multicast in LoRaWAN addresses several end devices at once with one group-encrypted downlink. Class C is typically required so devices can receive the multicast window.

Specification and device configuration

The LoRaWAN specification defines a separate session for multicast: group address (Multicast Device Address) and associated keys (Multicast Application Session Key and Multicast Network Session Key) are not derived automatically from a normal OTAA join or from unicast session keys. They are described as out-of-band provisioning, outside the standard join flow—for example via vendor tools, configuration interfaces, or firmware parameters on the end device.

Operational consequences:

• Server and end device must carry the same multicast parameters; creating a group on the network alone is not enough if the device does not know the group keys and group address.
• Firefly manages multicast groups on the server side and sends multicast downlinks through that group. Aligning with the end device (keys and group context on the device) remains a separate configuration task per specification and device manual.

Implementation in Firefly and niotix

In Firefly, multicast downlinks are triggered via multicast groups. If no gateway IDs are set manually, Firefly tries to determine a minimal set of suitable gateways; if gateway IDs are set, delivery is limited to those gateways. Missing or stale uplink history can block multicast downlinks because gateway selection is not reliable enough; unsuitable gateway IDs prevent delivery entirely.

For automated multicast downlinks from niotix, the Firefly connector calls the REST endpoint POST /api/v1/multicast_groups/{mcid}/multicast_down_packets; mcid identifies the multicast group. Payload, port, and encoding match the connector command sendMultiCastDownlink.

MAC Commands

LoRaWAN MAC commands control radio, session, and diagnostic parameters. They are usually embedded in the FOpts area of the MAC header or combined with the application payload frame, depending on direction and length budget.

Rough flow:

• Uplink from the device may contain requests (Req) or answers (Ans) to previously received network requests.
• Downlink from the network may send requests to the device; the device typically confirms or comments in the next uplink with Ans commands.

Firefly processes the following device-originated or answering commands among others (selection as documented from a product perspective):

Operationally, ADR shows up in LinkAdrReq/LinkAdrAns, time alignment in DeviceTime commands, receive-window changes in RxParamSetup, channel changes in NewChannel, and device state in DevStatus. The packet journal often maps these events via the MAC trace or raw view.

In Firefly device configuration via the niotix Firefly connector, Enable daily device status request (DevStatusReq) can optionally be enabled: the network then requests status via DevStatusReq on a fixed cadence, if the end device supports it.

ADR

ADR (Adaptive Data Rate) is a LoRaWAN network mechanism to adapt data rate (spreading factor / DR index), TX power, and usually the active channel mask to measured radio quality. The goal is a stable link with as short time-on-air and as low device power consumption as possible, without losing reliability.

Flow in brief

1. The device sends uplinks; gateways report RSSI and SNR among other data to the Network Server.
2. The Network Server evaluates quality across several received packets (diversity, history).
3. In a downlink it sends LinkAdrReq with proposed data rate, TX power, and channel mask (and ChMaskCtl depending on region).
4. The device answers with LinkAdrAns: it confirms which parts of the proposal it accepts, or rejects combinations it does not support.
5. Only after successful negotiation do the new parameters apply; the device may impose its own limits (minimum data rate, supported channels).

ADR is therefore not a simple slider on the device, but a dialog between network and device using standardized MAC commands.

Firefly and ADR limit

Firefly applies ADR based on received uplinks and the usual LinkAdr mechanism. The device option ADR Limit in the Firefly connector (field adr_limit) can cap how high ADR may raise the data rate—useful with unstable RF or when a more conservative data rate should be kept. Allowed steps match the same scale as RX2 Data Rate (DR indices with associated spreading factors). Field details: Device management.

Troubleshooting

Typical checks for advanced LoRaWAN features:

• OTAA: trace join request and join accept in the packet journal; verify keys, region, RX2, and gateway paths (see OTAA join in Firefly)
• Class A or Class C configured correctly
• uplink history is recent enough
• gateway selection is understandable
• multicast only with the correct device class; multicast keys and group address on the device set as specified
• MAC-related parameters such as ADR, RX2, or timing are not contradictory

Common Questions

Why does a Class C downlink not work immediately?

Even for Class C, Firefly still needs a usable gateway selection and a healthy queue state. Missing last-gateway data or blocked queues are common causes.

Why does multicast not behave like a normal downlink?

Multicast uses group delivery and therefore requires the right device class, explicitly provisioned multicast keys and group address on the end device (not automatic from join), and a usable gateway selection for several devices at once.

Are all LoRaWAN features in Firefly fully documented here?

This page focuses on the LoRaWAN functions that are relevant for day-to-day operation in Firefly and niotix-based setups.