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 it costs far less to answer on paper than 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, since national regulators sometimes impose tighter limits than the regional plan's defaults.)
| Plan | Common name | Frequency range | Channel structure | Max power | Airtime rule |
|---|---|---|---|---|---|
| EU863-870 | EU868 | 863-870 MHz | 3 mandatory + extra 125 kHz channels | +16 dBm EIRP | Duty cycle (1% typical) |
| US902-928 | US915 | 902-928 MHz | 64×125 kHz + 8×500 kHz up, 8×500 kHz down | +30 dBm EIRP | Dwell time (400 ms) + hopping |
| AU915-928 | AU915 | 915-928 MHz | 64×125 kHz + 8×500 kHz (US-like) | +30 dBm EIRP | Dwell time / region-dependent |
| AS923 | AS923 | ~920-923 MHz | Channel groups per country | Region-dependent | Duty cycle or dwell time |
| IN865-867 | IN865 | 865-867 MHz | 3 mandatory channels | +30 dBm | Region-dependent |
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 it gets in the duty cycle and airtime budgeting article.
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.
The EU and ETSI style is a duty cycle: a device may transmit for only a percentage of the time. A 1% duty cycle allows roughly 864 seconds of airtime per day, and a 0.1% sub-band allows only about 86 seconds. The regulator is capping how much you talk. That turns airtime into a hard budget you have to plan around, and it bites hardest at scale, where firmware updates, frequent reporting and large payloads all compete for the same few minutes a day.
The FCC style regulates dwell time and hopping instead: a device may transmit as often as it likes, but each transmission must be short, typically capped at 400 ms, and must hop across many channels so no single frequency is monopolized. Here the regulator is capping how long any one transmission lasts and forcing the traffic to spread.
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, and different certifications, all 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:
- 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.
- Source hardware in the correct regional variant for each site, and verify the certification matches the band.
- 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.
- Configure device, gateway, and network server to the same regional plan, and validate end-to-end before scaling.
- 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 it's the kind of decision that's invisible when it's right and very visible when it's wrong. I help organizations pick the correct band for every site, source the right regional hardware variants, and design reporting strategies around the airtime rule that actually applies: a duty-cycle budget in Europe, dwell time and hopping in North America, country-specific variants across Asia-Pacific. For multi-region rollouts, I architect the deployment so different bands and rules still come together into one coherent system, configure the network servers and gateways to match, and train your team on the constraints they're designing within.
Anything I deliver comes with full source code and documentation, and there are no recurring fees. If you're unsure which band a deployment needs, or you're planning a rollout across several countries, a short conversation before you commit to hardware costs far less than re-buying it afterwards.
Working on a LoRaWAN project?
If this article touches on something you're building, tell me about it. The first conversation is free, and you'll get an honest read on the right approach for your situation.
Book a Free ConsultationCurious what the finished thing looks like? Open the live demo dashboard
