LoRaWAN Frequency Plans & Regulations: A Global Deployment Guide

The First Decision in Any LoRaWAN Deployment

Before you choose a sensor, before you plan coverage, before you write a line of decoder code, there is a decision that silently governs all of them: which frequency plan does your deployment use?

LoRaWAN is a global standard, but it is not a global frequency. It runs in the license-free ISM bands that each country sets aside for unlicensed radio—and those bands differ from region to region. A device built for Europe's 868 MHz band cannot legally transmit in the United States, and even if it could, it wouldn't connect: it would be calling out on frequencies your US gateway never listens to. The radios are the same LoRa chips; the rules they must obey are not.

Get this right and everything downstream just works. Get it wrong and the failure modes are expensive and confusing: hardware that won't join the network, a pilot that works on the bench in one country and goes silent when shipped to another, or—worst of all—a deployment that transmits on a band it isn't authorized to use, exposing you to regulatory liability. For any organization deploying across borders, or sourcing hardware from one region to install in another, frequency planning is the first thing to get right.

The LoRa radio is global. The regulations are not. "Which band?" is the first question of every deployment, and the cheapest one to get wrong on paper instead of in the field.

Why There Isn't One Global Band

LoRaWAN rides on unlicensed sub-GHz spectrum—frequencies low enough to travel kilometers and penetrate buildings, free enough to use without a spectrum license. The catch is that no single slice of sub-GHz spectrum is free worldwide. Each regulator carved out different bands for unlicensed use:

• Europe and much of EMEA settled on the 863–870 MHz range.
• North America and much of the Americas use 902–928 MHz.
• Asia-Pacific countries largely use bands around 915–928 MHz or 920–923 MHz, with significant country-by-country variation.
• India uses 865–867 MHz.

Because of this, the LoRa Alliance publishes Regional Parameters: a specification that defines, for each region, exactly which channels devices use, how much power they may transmit, and what airtime limits apply. There are over a dozen defined regional plans. Your device firmware, your gateway, and your network server must all agree on the same one.

The Major Regional Plans

Here are the plans you are most likely to encounter, with the specifics that matter when you select hardware. (Always confirm the rules for the specific country you deploy in—national regulators sometimes impose tighter limits than the regional plan's defaults.)

Other defined plans you may meet include KR920 (South Korea), CN470 (China), and RU864 (Russia). The principle is identical: a different band, a different channel plan, and different local rules.

EU868 — Europe, regulated by ETSI

In the EU868 band, devices join on three mandatory frequencies—868.1, 868.3, and 868.5 MHz—and transmit at up to +16 dBm EIRP (40 mW). The defining constraint here is the duty cycle: under ETSI rules, a device may only occupy the airwaves for a small fraction of the time. On the common channels that means roughly 1% airtime, and some sub-bands are tighter still. This single rule shapes how often your sensors can report, and it's the most common scaling surprise in European deployments. (It deserves its own treatment, which is coming in a dedicated article on duty cycle and airtime budgeting.)

US915 — North America, regulated by the FCC

US915 works on a fundamentally different model. Instead of a duty cycle, the FCC requires frequency hopping across a wide pool of channels—64 uplink channels at 125 kHz plus 8 at 500 kHz, with 8 downlink channels at 500 kHz—and imposes a 400 ms maximum dwell time per transmission on the 125 kHz channels. In exchange, devices may transmit at a much higher +30 dBm EIRP (1 W). The practical upshot: US915 deployments don't hit the same hard daily-airtime wall that EU868 does, but they must hop channels correctly and keep individual transmissions short. A subtle implication for engineers: with 72 uplink channels, your gateway needs to listen across the right sub-band, and devices and gateways must agree on which 8-channel sub-band is in use.

AU915 — Australia and others, looks like US915 but isn't

AU915 lives in the same 915 MHz neighborhood as US915 and uses a similar 64+8 channel structure, which leads to a frequent and costly mistake: assuming a US915 device will work in Australia, or vice versa. They are distinct plans with distinct channel frequencies and local rules. Treat "915" as a family of incompatible plans, not a single band.

AS923 — Asia-Pacific, the flexible one

AS923 covers a large, diverse set of countries (Japan, much of Southeast Asia, and others) around 920–923 MHz. It is deliberately flexible, with channel groups and rules that vary by country—some apply a duty cycle, others a dwell time, and some require Listen Before Talk. AS923's adaptability is its strength and its trap: "AS923" alone isn't enough to specify a deployment; you need the country-specific variant.

IN865 — India

India uses 865–867 MHz with three mandatory channels. It's a comparatively narrow band, which constrains channel planning, and it is specific to the Indian regulatory domain.

Duty Cycle vs. Dwell Time: Two Philosophies for Sharing the Air

Every regulator is solving the same problem—keeping an unlicensed band from being hogged by a few loud devices—but they solve it in two different ways, and the difference drives real engineering decisions.

• Duty cycle (EU/ETSI style): A device may transmit for only a percentage of time. A 1% duty cycle allows roughly 864 seconds of airtime per day; a 0.1% sub-band allows only about 86 seconds. The regulator caps how much you talk. This makes airtime a hard budget you must plan around—especially at scale, where firmware updates, frequent reporting, and large payloads compete for the same few minutes per day.

• Dwell time + frequency hopping (FCC style): A device may transmit as often as it likes, but each transmission must be short (e.g. 400 ms) and must hop across many channels so no single frequency is monopolized. The regulator caps how long any one transmission lasts and spreads the traffic.

Neither is "better"—they're different constraints that reward different designs. A reporting strategy that's perfectly legal and efficient in US915 can blow straight through the EU868 duty-cycle budget. This is why you cannot simply "port" a deployment from one region to another by reflashing the band; the whole airtime strategy may need rethinking.

How the Frequency Plan Ripples Through Your Project

The band you operate in isn't an isolated setting—it constrains decisions across the stack:

Hardware procurement. Sensors and gateways are sold per region. A device's radio front-end, antenna matching, and certification are tuned to a specific band. You must buy the correct regional SKU; a EU868 gateway is not a US915 gateway with a software switch. Ordering the wrong variant for a site is a re-purchase, not a reconfiguration.

Certification and legality. Operating in a band means meeting that region's regulatory certification—CE/RED in Europe, FCC in the US, and the equivalents elsewhere. Using uncertified hardware, or certified hardware on the wrong band, is a compliance exposure, not just a performance issue.

Reporting frequency and payload design. In duty-cycle regions, airtime is finite, so how often devices report and how large their payloads are become budget decisions. The spreading factor matters too: higher spreading factors reach further but occupy the air far longer per message, consuming more of your duty-cycle budget per transmission.

Network server and gateway configuration. The network server must be set to the right regional plan so it schedules downlinks on legal channels and windows. A mismatch between device, gateway, and server frequency configuration is a classic "everything looks configured but nothing connects" failure.

Multi-region rollouts. Organizations deploying the same solution across continents effectively run several deployments in parallel—different hardware SKUs, different airtime strategies, different certifications—coordinated into one coherent system and one set of dashboards. That coordination is where the real planning work lives.

Getting It Right the First Time

A defensible frequency-planning approach comes down to a few deliberate steps:

1. Identify the exact regulatory domain for every deployment site—by country, not just continent. Confirm the regional plan and any national restrictions tighter than the defaults.
2. Source hardware in the correct regional variant for each site, and verify the certification matches the band.
3. Design your reporting and payload strategy around the region's airtime rule—a duty-cycle budget in Europe, dwell-time and hopping in North America.
4. Configure device, gateway, and network server to the same regional plan, and validate end-to-end before scaling.
5. For multi-region deployments, plan each region explicitly rather than assuming one design ports across borders.

None of this is difficult once you know the rules. The expense comes from discovering them after the hardware is bought or the pilot has shipped—which is exactly the kind of avoidable, costly surprise that good planning eliminates.

What I Provide

Frequency planning is where regulatory rules, hardware procurement, and airtime strategy meet—and getting it right up front is far cheaper than re-buying hardware or re-architecting a deployment that shipped to the wrong band. This is planning and integration work by nature: the kind of decision that's invisible when it's right and very visible when it's wrong.

Services:

• Regional band selection and frequency planning for single-site and multi-region deployments
• Hardware sourcing guidance: the correct regional SKUs, certified for each deployment country
• Airtime and reporting strategy: duty-cycle budgeting for EU868, dwell-time and hopping for US915/AU915
• Network server and gateway configuration for the correct regional parameters
• Multi-region rollout architecture: coordinating different bands and rules into one coherent system
• Compliance review: certification (CE/RED, FCC, and regional equivalents) and legal operation
• Team training so your staff understand the regional constraints they're designing within

You own everything:

• Complete source code and documentation for any software delivered
• A deployment designed around the rules of the regions you actually operate in
• No vendor lock-in, no recurring platform fees

I don't sell hardware or charge recurring fees. I help organizations deploy LoRaWAN that works—and is legal—wherever in the world it runs, then hand over the knowledge to extend it themselves.

Not sure which band a deployment needs, or planning a rollout across several countries? A short planning engagement settles the frequency-plan and compliance questions before you commit to hardware—the cheapest possible place to catch a regional mistake.

Related Articles

Open Source LoRaWAN Multiplexer and Protocol Converter

Open Source LoRaWAN Traffic Analyzer

LoRaWAN Total Cost of Ownership: What 5 Years of IoT Really Costs