Ship sensors into three countries without checking the frequency plan first, and you'll spend week one debugging "why won't this join" instead of collecting data. LoRaWAN isn't one radio standard — it's a family of regional parameter sets, and mixing them up is the single most common reason a multi-country rollout stalls before it starts.
- Match every country to its LoRaWAN regional plan before ordering hardware — AS923 alone has at least four national variants.
- US915 splits into 8 sub-bands of 8 channels each; pick one sub-band per gateway, don't run all 64.
- EU868 caps most channels at a 1% duty cycle — plan payload size and interval around that limit, not around demand.
- Order sensors and gateways with the frequency plan baked into the SKU, never assume a device is region-agnostic.
- Kilo Cloud lets you run separate LoRaWAN channel plans per site from one network server instance in 2026.
Why this matters
A sensor built for EU868 will not join a US915 gateway. That's not a configuration bug — it's physics and regulation. Each region's radio spectrum authority sets its own rules on which frequencies are open for unlicensed low-power devices, how long a device can transmit, and how often.
The LoRa Alliance publishes Regional Parameters that codify these rules into named plans: EU868, US915, AU915, AS923, IN865, KR920, RU864, and a handful of others. Getting the plan wrong at Kilo Cloud or any other IoT platform doesn't mean a support ticket — it means devices that never send a single uplink.
Multi-country rollouts multiply this risk. A facilities team monitoring cold storage in Germany, the US, and Singapore is dealing with three separate frequency plans, three different duty cycle or dwell time rules, and at least one country (Singapore, under AS923) where the plan itself has sub-variants depending on national spectrum allocation.
What you'll need
- A list of every country in the rollout, with exact site addresses (regional plans can vary at the country level, occasionally at the sub-national level)
- The LoRaWAN Regional Parameters document version your network server and devices support
- Sensor and gateway SKUs confirmed against each target region — not "LoRaWAN compatible" but region-specific part numbers
- A network server that supports multiple channel plans simultaneously across sites
- A join server or device provisioning workflow that assigns the correct plan per device at onboarding, not after
- Spectrum analyzer access or gateway-side channel utilization logs for post-deployment verification
The steps
1. Map every rollout country to its LoRaWAN regional plan
Start with a spreadsheet, not a network server config. List each country, its assigned plan (EU868, US915, AU915, AS923-1 through AS923-4, IN865, KR920, RU864), and the specific sub-variant where one exists.
AS923 is the trap here. Japan, Australia, New Zealand, Malaysia, Singapore, Thailand, Brunei, and several other AS923 countries do not share identical channel plans — the LoRa Alliance splits AS923 into multiple variants specifically because national regulators carved out different frequency blocks. Treating "AS923" as one plan across four countries is how devices end up silent.
Common mistake: assuming a supplier's "AS923" sensor works in every AS923 country. Confirm the exact variant against your target country's regulator before ordering.
2. Check duty cycle and dwell time limits per region
EU868 imposes duty cycle limits — typically 1% on the main channels, sometimes 0.1% on specific sub-bands — meaning a device can only transmit for a fraction of any hour on a given frequency. US915 works differently: no duty cycle, but a dwell time limit (400 ms per transmission on some channel sets) and mandatory frequency hopping across its 64 channels.
This directly shapes what you can do with payload size and reporting interval. A cold storage sensor sending every 5 minutes in Germany needs a smaller payload and tighter channel management than the same sensor in Texas, where the constraint is dwell time rather than duty cycle.
Why it matters: get the duty cycle math wrong and the network server throttles uplinks silently — you'll see gaps in the data with no error message pointing at the cause.
3. Decide your approach for regions with multiple valid plans
Some countries fall inside more than one usable plan, and others require you to pick a sub-band rather than a full plan. In US915, only one of the 8 sub-bands (8 channels each, 64 total) should be active per gateway — running all 64 channels on one gateway wastes capacity and confuses join behavior for large device counts.
For multi-country builds, standardize on the narrowest valid configuration per site rather than trying to run one universal config across regions. It costs more setup time upfront and saves weeks of mystery outages later.
4. Confirm gateway and sensor SKUs match before you order hardware
Order sheets are where frequency plan mistakes get expensive. Gateways and end devices are manufactured with a fixed regional radio configuration baked in at the firmware or hardware level in most cases — you can't flash a US915 gateway into an EU868 unit after the fact on most consumer-grade hardware.
Build a hardware order checklist that pairs every SKU with its confirmed region before purchase orders go out. A single mismatched pallet of sensors shipped to the wrong country site is the most common cause of a multi-country rollout slipping its go-live date.
5. Configure separate channel plans per site in your network server
Your LoRaWAN network server needs to run each site's channel plan independently — a German site on EU868, a US site on US915 sub-band 2, a Singapore site on its specific AS923 variant, all reporting into the same dashboard without cross-contaminating configurations.
A private LoRaWAN network server built for multi-site, multi-region operation handles this as a per-gateway or per-site setting, not a global platform default. Confirm this before committing to a network server for a rollout spanning more than one regulatory region.
6. Load-test channel utilization before scaling past the pilot site
Run a pilot with 10-20 devices per site before ordering the full fleet. Watch channel utilization on the gateway — if you see repeated join failures or a spike in dropped uplinks on specific channels, the sub-band or duty cycle assumption from step 2 needs revisiting before you scale to 200 devices.
Expected outcome: a pilot site should show consistent join success and stable uplink intervals within 48-72 hours of activation. If it doesn't, the frequency plan — not the sensors — is usually the first thing to check.
7. Document and version the plan for future sites
Write down the final plan per country: regional parameter version, sub-band, duty cycle or dwell time budget, and the SKU list that matches it. Multi-country rollouts rarely stop at the first three sites — version this document so site four in 2026 doesn't repeat the same discovery work as site one.
Run every site on one platform
Manage region-specific LoRaWAN plans across sites from a single dashboard.
Troubleshooting
- Devices won't join after arriving on-site. Check the AS923 sub-variant or US915 sub-band match between device firmware and gateway configuration — a one-digit mismatch (AS923-1 vs AS923-2) blocks every join attempt.
- Uplinks work for an hour, then stop. This is almost always an EU868 duty cycle throttle. Reduce payload frequency or move to a sub-band with a higher duty cycle allowance.
- Some devices join, others on the same gateway don't. Mixed hardware batches from different suppliers, or a firmware update that shipped one batch on a different regional parameter version.
- A device that worked in the lab fails on-site in another country. The device was configured for the wrong region before shipping — verify the SKU against the destination country, not the origin warehouse.
- Gateway shows high channel utilization with few connected devices. Too many channels active for the device count on US915 — narrow to a single sub-band rather than running the full 64-channel set.
- Roaming assets crossing a border stop reporting. LoRaWAN regional plans don't roam like cellular. A tracked asset moving from a US915 country into an AU915 country needs a device capable of switching plans, or a fallback connectivity layer.
Tools and resources
- LoRa Alliance Regional Parameters document — the source of truth for every plan and sub-variant
- A network server that supports multiple regional configurations per instance, such as a LoRaWAN device management platform built for multi-site operation
- Gateway-side channel utilization logs for post-deployment verification
- A hardware order checklist mapping SKU to confirmed destination region
What to do next
Once the frequency plan is locked per country, the next bottleneck is provisioning hundreds of devices without manual entry per unit. That's a separate problem from frequency planning, but it hits the same rollouts at the same time.
FAQ
What frequency plan does the US use for LoRaWAN?
The US uses US915, which spans 64 channels split into 8 sub-bands of 8 channels each. Deployments should run one sub-band per gateway rather than the full channel set to keep join times consistent.
Is AS923 the same in every Asian country?
No. AS923 has at least four regional variants (AS923-1 through AS923-4) because national regulators in Japan, Australia, New Zealand, Malaysia, Singapore, and Thailand carved out different frequency blocks. Always confirm the exact variant per country before ordering hardware.
Can one gateway support multiple frequency plans?
A single gateway is built for one regional plan at the hardware level in most cases. Multi-country rollouts need one gateway model per region, all reporting into a network server that handles multiple plans across sites.
How much does duty cycle limit throughput in EU868?
EU868 typically caps transmission on main channels at a 1% duty cycle, meaning a device can only transmit for a small fraction of any given hour on that frequency. This shapes how often sensors can report without being throttled.
What happens if a sensor ships with the wrong frequency plan?
It will not join the network at the destination site, and there is usually no error message pointing directly at the cause. The fix is replacing the device with the correct regional SKU, not a firmware patch.
Do I need a different frequency plan per country or per region?
Per country, and sometimes per sub-region within a country for plans like AS923 or US915 sub-bands. Never assume neighboring countries share an identical plan without checking the LoRa Alliance Regional Parameters document.
How does mioty differ from LoRaWAN on frequency planning?
mioty uses its own regional parameter sets separate from LoRaWAN's, though both operate in similar sub-GHz unlicensed bands depending on the country. The two protocols are not interchangeable at the hardware level, so a mioty deployment needs its own regional check independent of any LoRaWAN plan already in place.
What's the cost of getting a frequency plan wrong at scale?
A mismatched hardware order for an entire country site means re-ordering sensors and gateways, plus every week of delay in getting real data from that site. Catching the mismatch at the SKU-ordering stage in step 4 is far cheaper than catching it after installation.
One last thing
The part most teams miss isn't the big regions — it's the AS923 sub-variants. A rollout spanning Singapore and Australia looks like "one AS923 plan" on paper and turns into two separate configurations the moment devices hit the ground in 2026. Check the sub-variant before the purchase order, not after the pallet arrives.
