Overview

The frequency plan and network server address must match the real operating environment. Each network server instance runs with one fixed frequency plan; in the public Firefly cloud each SaaS hostname is therefore paired with a plan (see Mapping in the public Firefly cloud). Mistakes here often make gateways look reachable while delivering no usable payloads or unreliable downlinks.

When this page applies

This page is relevant when:

• a new region is being set up
• a gateway is on the wrong plan
• Firefly is not sending or receiving against the expected address
• distinguishing SaaS from a self-hosted installation

Prerequisites

For planning, the following should be known:

• target region of the device or gateway
• gateway type in use
• whether the deployment is public Firefly SaaS or self-hosted

In niotix, region and endpoint URLs must match the same Firefly context: align the Virtual Device and Firefly connector configuration with this page.

Frequency plans

Firefly supports the following frequency plans.

Plan overview table

Channel frequencies

All values in MHz. For EU868, AS923, IN865, and KR920, the listed uplink frequencies are the same as the downlink channels for RX1 window 1 (see get_rx1_freq in the respective band modules).

EU868

US915

AU915

AS923

IN865

KR920

Note: RX2 (921.9 MHz) is the fixed second receive window in LoRaWAN / Firefly (921900000 Hz in the KR920 band module); it is not one of the seven uplink / RX1 center frequencies.

CN470 (active on the server: uplink indices 80–87 of the 470 MHz grid; downlink the first eight channels of the 500 MHz grid)

RX2 per plan: see the Overview table.

Public SaaS addresses

The public SaaS uses several network server hostnames for UDP-based packet forwarders. The documented default port is 1700. The following sections explain how frequency plan and hostname relate.

These addresses are only correct when the public Firefly SaaS is actually in use.

How it works: one network server, one frequency plan

For every Firefly environment you connect to, the LoRaWAN network service operates with exactly one frequency plan (a regional LoRa channel plan).

Three sides must be aligned to the same target region and plan: the reachable network service or target address (host/port), the end device settings, and the gateway settings. In the public SaaS, you pick the documented host name for your target region; in a self-hosted setup, the endpoint described in your documentation. The end device must use matching region and frequency and profile parameters, and the gateway must use the corresponding channel plan configuration.

If this alignment is not consistent, you will typically see connectivity or join issues, or application payloads will stay empty—even when the target address and port are formally reachable on the network.

Mapping in the public Firefly cloud

In the public Firefly SaaS, the Europe / EU868 instance is fireflyiot.com.

Each network server host documented in the table below and in the application manual is assigned to a target region and frequency plan profile. See the Firefly application manual, chapter on regions and server addresses.

In practice, the gateway and device profile must match the frequency plan that host is intended for—for US915 typically us1.ns.fireflyiot.com, for EU868 fireflyiot.com. A host name on its own does not enforce the plan; the target, gateway, and end device must all follow the same intended plan for that region.

Impact on operations and troubleshooting

When the frequency plan or address does not fit, common symptoms include:

• no or too few uplinks
• inconsistent downlinks
• gateways that look connected but carry no usable traffic
• join problems

Checks should always cover together:

• Firefly region
• gateway configuration
• device profile
• target address and port
• SaaS vs self-hosted environment

Common questions

Is US915 always tied to us1.ns.fireflyiot.com?

In the public Firefly cloud, that pairing is the intended and documented US915 mapping for that host. The DNS name does not technically enforce the plan—what matters is the configuration of the network server that is actually reached and that target, gateway, and devices all match the intended plan. In self-hosted environments other hostnames can serve the same role; there the deployment configuration decides, not the fixed SaaS name.

Datasheets list several LoRa regions—which one is relevant for a live deployment?

What matters is the channel plan and region you have actually configured and run in production—not every region the device could support on paper. Keep the device profile, gateway settings, and the Firefly target / frequency context aligned to that same real configuration.

Why does a gateway receive packets but still behave inconsistently?

In many cases, the frequency plan does not fully match the Firefly region, or the gateway is sending to the wrong address or environment (SaaS vs self-hosted). See Impact on operations and troubleshooting.