LoRaWAN Frequency Bands by Region: Gateway Selection Checklist
A LoRaWAN gateway should be selected for the country where it will operate, not simply for the market where it is purchased. The Robustel R1520LG LoRaWAN Gateway is available in different regional radio variants, illustrating why EU868, US915, AU915 and AS923 must be treated as deployment requirements rather than software labels that can always be changed later.
Consider an equipment manufacturer that has already validated a LoRaWAN monitoring system in Germany. The same design is now scheduled for sites in the United States, Australia and Southeast Asia. Reusing the application is straightforward; reusing the exact gateway, antenna and radio configuration may not be.
The procurement sequence should therefore begin with: Deployment country → permitted LoRaWAN regional plan → gateway radio variant → antenna and end-device compatibility → LNS channel configuration → regulatory approval
Getting that sequence wrong can leave a technically functional gateway unable to communicate with the installed sensors—or unsuitable for legal operation in the target market.
Start with the Deployment Country, Not the Gateway SKU
A common purchasing shortcut is to ask for “an 868 MHz gateway” for Europe or “a 915 MHz gateway” for every other region. That level of description is not sufficient for an international LoRaWAN rollout.
The LoRa Alliance maintains RP002-1.0.5 LoRaWAN Regional Parameters, published in October 2025, which maps countries to LoRaWAN channel plans and defines the operating parameters for those regional plans. The specification distinguishes dynamic channel plans such as EU868 and AS923 from fixed channel plans such as US915 and AU915.
For a Robustel LoRaWAN gateway deployment, that means the country should be known before the order code is finalised.
A project manager planning installations in Germany, the United States and Australia should not write: “Use the same 915 MHz gateway outside Europe.”
Instead, the bill of materials should explicitly identify the applicable regional configuration for each market.
This matters because LoRaWAN regional parameters affect more than the centre frequency. They define channel structures, data rates, transmit-power behaviour, receive windows and other radio settings. US915 and AU915, for example, are both fixed-channel plans in the 900 MHz range, but they use different uplink frequency sets and should not be treated as interchangeable configurations.
The Robustel R1520LG reflects this hardware-selection process in its ordering information. Robustel currently lists separate regional variants identified as EU868, AU915, US915 and AS923. Certifications are tied to the corresponding order codes rather than one universal model.
The first procurement question should therefore be: Where will this gateway legally operate? Only then should the team select the product variant.
Translate the Region into a LoRaWAN Channel Plan
The regional names are convenient shorthand, but each represents a different radio plan. A buyer does not need to memorise every LoRaWAN channel frequency. The useful task is to understand which aspects must remain aligned across the deployment.
| Regional plan | LoRa Alliance plan type | Regional-plan frequency range | Buyer should verify |
|---|---|---|---|
| EU868 | Dynamic | 863–870 MHz | Country regulation, gateway variant, antenna, power limits and network configuration |
| US915 | Fixed | 902–928 MHz | North American gateway variant, channel plan, end-device compatibility and LNS configuration |
| AU915 | Fixed | 915–928 MHz | Country support, gateway variant, channel plan and regulatory approval |
| AS923-1 | Dynamic | 915–928 MHz group | Exact country allocation and AS923 variant |
| AS923-2 | Dynamic | 920–923 MHz group | Exact country allocation and AS923-2 configuration |
| AS923-3 | Dynamic | 915–921 MHz group | Exact country allocation and AS923-3 configuration |
| AS923-4 | Dynamic | 917–920 MHz group | Exact country allocation and AS923-4 configuration |
These are LoRa Alliance regional-plan definitions, not substitutes for national radio regulations. The RP002 country cross-reference should be checked alongside the applicable local regulatory requirements before deployment.
For EU868, the LoRa Alliance defines the regional channel structure and operating parameters, while local regulations remain the controlling limit. End-device EIRP guidance in the Regional Parameters should not be interpreted as the transmit-power specification of the Robustel R1520LG gateway itself.
The practical implication for a Robustel R1520LG LoRaWAN Gateway project is not “set the gateway to 868 MHz and continue.” The selected gateway, antenna, end devices and Network Server must all be configured for the same appropriate regional environment.
A real deployment helps put this in context: Robustel deployment example: nationwide LoRaWAN network backhaul over LTE450 for Cibicom
Cibicom operates LoRaWAN infrastructure in Denmark. The published Robustel case describes LoRa 868 MHz connectivity at gateway sites, with the original Robustel R3000-LG LoRaWAN Gateway installed as part of an outdoor system and LTE450 providing upstream backhaul. The R3000-LG used in the project is now a legacy product, with Robustel identifying the R1520LG as the current replacement.
The important lesson is not that every European deployment should copy Cibicom’s exact configuration. It is that the radio configuration belongs to a specific country, network and installation, rather than to a generic worldwide LoRaWAN design.
AS923 Shows Why “Asia Frequency” Is Not Specific Enough
AS923 deserves particular attention because the label is often treated as one Asian frequency plan. It is not.
The current LoRa Alliance specification defines AS923-1, AS923-2, AS923-3 and AS923-4, using different frequency offsets to accommodate regulatory conditions in different countries. AS923-1 represents the historical AS923 group, while the other variants shift the operating plan into different portions of the 900 MHz spectrum.
For example, the LoRa Alliance country table currently identifies:
- Japan with AS923-1
- Indonesia and Vietnam with AS923-2
- the Philippines with AS923-3
- Israel with AS923-4
Other countries may have multiple permitted bands or different national allocations, so this list should not be used as a substitute for the current country table or local regulation.
This creates a practical purchasing issue.
A Robustel LoRaWAN gateway described as supporting AS923 still needs to be checked against the exact destination market and its required configuration. The current R1320LGe product page, for example, lists a Southeast Asia model for AS923 alongside separate EU868, AU915 and US915 order variants. Robustel also notes that certification status differs by model and that some approvals remain in progress.
For a rollout covering Singapore, Indonesia and another Asian market, therefore, “AS923 supported” is not a complete procurement statement.
The regional record should identify: Country → AS923 subgroup → permitted local spectrum → exact gateway variant → sensor configuration → LNS channel plan → applicable certification
This is especially important when equipment is pre-configured in one country and shipped directly to another.
Keep the Gateway, Sensor, Antenna and LNS on the Same Regional Plan
Correct gateway hardware is only one part of regional compatibility. A LoRaWAN sensor network works only when the complete radio path agrees on the regional parameters.
For a Robustel LoRaWAN deployment, the compatibility chain should be reviewed as one system: LoRaWAN end device ↔ end-device regional configuration ↔ gateway radio and antenna ↔ packet-forwarder regional settings ↔ LoRaWAN Network Server channel plan
A US915 end device does not become compatible with an EU868 gateway because both products support LoRaWAN. Likewise, an AU915 gateway and Network Server using mismatched channel assumptions may fail even though their nominal frequencies both sit in the 900 MHz range.
This is particularly relevant to US915 and AU915 because they are fixed-channel plans with large predefined channel sets. RP002-1.0.5 specifies different uplink frequency structures for the two plans, even though their downlink ranges overlap.
The antenna also belongs inside this chain. An antenna should cover the frequency range used by the ordered gateway variant, while its gain and installation must remain consistent with local radiated-power requirements. Selecting an antenna simply because the connector fits is not sufficient.
The LNS must then use the corresponding regional plan.
The Robustel R1520LG LoRaWAN Gateway can connect to external Network Servers through UDP, Basic Station and Loriot, or operate with its embedded ChirpStack LNS. Whichever architecture is selected, the regional configuration still needs to match the deployed radio hardware and devices.
Robustel’s “What Is a LoRaWAN Gateway” video provides a useful visual overview of the gateway’s position between LoRaWAN end devices and the IP network. That architecture is also why regional configuration cannot be checked only at the sensor or only at the server—the gateway sits directly between both sides.
Map Robustel LoRaWAN Gateway Variants Before the Purchase Order
For an international project, product selection should be turned into a regional bill of materials rather than one global gateway line item.
The Robustel R1520LG LoRaWAN Gateway currently illustrates this clearly:
- EU868 variants are listed with CE approval
- AU915 variants are listed with RCM approval
- US915 variants are listed with FCC and IC approvals
- Asian variants are listed for AS923, with the current product page showing no certification entry for those order codes
The exact ordering code and current regulatory status should be confirmed at procurement because radio products and approvals are market-specific.
The Robustel R1320LGe LoRaWAN Gateway provides another useful example. Its ordering information separates EU868, AU915, US915 and AS923 variants and explicitly marks some certifications as still in progress. This is a good reason to verify the current datasheet and approval status rather than copying a model number from an earlier project.
This becomes even more important when a successful deployment expands geographically.
A multi-site Robustel example: LoRaWAN monitoring for vaccines and labs with the R1520LG
KoolZone uses R1520LG gateways for cold-chain and laboratory monitoring, with the published Robustel case describing deployments across the UK and Europe and stating that KoolZone’s wider monitoring operations extend across four continents.
The case does not publish the LoRaWAN frequency configuration used in every country, so it should not be used to infer that one R1520-LG radio variant serves the entire estate.
Its value for this discussion is operational: once a solution expands across countries, regional hardware control becomes part of fleet management. The organisation needs to know which gateway variant belongs at which site before devices are shipped, configured or replaced.
A replacement gateway with the correct software configuration but the wrong radio variant is still the wrong replacement.
Build a Regional Approval Record Before Rollout
The safest way to manage LoRaWAN frequencies is to make regional compatibility a formal deployment gate.
For each target country, create one approval record containing:
| Item | What to record |
|---|---|
| Deployment country | Exact country, not broad sales region |
| LoRaWAN plan | EU868, US915, AU915, AS923 variant or other applicable plan |
| Local spectrum | Permitted national operating band |
| Gateway | Full Robustel model and regional order code |
| Certification | Current approval required for that market |
| End devices | Confirmed regional variant and configuration |
| Antenna | Frequency coverage, gain and connector |
| LNS | Matching regional channel plan |
| Firmware/configuration | Approved baseline for that market |
| Replacement stock | Correct regional spare units |
| Validation | Join, uplink and required downlink tested at the destination |
This record should be completed before a Robustel gateway is released for volume deployment.
It also prevents a common scaling problem: the pilot team knows that “the German unit is EU868,” but the information exists only in an engineer’s memory. Six months later, procurement orders replacement gateways for several countries using a generic product description.
Regional information should instead become part of:
- ERP or purchasing records
- installation documentation
- configuration templates
- spare-parts management
- field-service instructions
- acceptance testing
Where a project uses RCMS remote management platform for Robustel gateway fleet management, hardware identity and configuration records can support the operational workflow, but a management platform does not change the radio certification or physical regional variant of the gateway.
Regional compliance must be correct before remote management begins.
Foire aux questions
Q1. What LoRaWAN frequency is used in Europe?
EU868 is the common LoRaWAN regional plan associated with the EU863–870 MHz band. The exact spectrum and permitted operating conditions still depend on national regulations. A buyer should confirm the destination country, gateway regional variant, antenna, device configuration and applicable approvals rather than assuming that every “868 MHz” product is interchangeable.
Q2. What is the difference between US915 and AU915?
US915 and AU915 are both fixed-channel LoRaWAN plans in the 900 MHz region, but their uplink channel frequencies and data-rate definitions differ. RP002-1.0.5 defines US915 around the 902–928 MHz plan and AU915 around 915–928 MHz. A gateway or sensor configured for one should not automatically be treated as compatible with the other.
Q3. Does the Robustel R1520LG support multiple LoRaWAN frequency bands?
Yes, but through regional product variants rather than one universal radio configuration. The Robustel R1520LG LoRaWAN Gateway currently has EU, Australian, North American and Asian ordering variants covering EU868-type, AU915, US915 and AS923 requirements. The exact order code and certification should be checked for the target market.
Q4. Are all AS923 countries using the same frequencies?
No. The LoRa Alliance currently defines AS923-1, AS923-2, AS923-3 and AS923-4 to accommodate different national frequency allocations. Country mapping should be checked against the current RP002 specification and applicable local regulation rather than using “AS923” as a universal Asia-wide setting.
Q5. Can a LoRaWAN gateway frequency be changed only through software?
That depends on the gateway hardware and regional variant. Software controls channel configuration within the capabilities of the installed radio, but it cannot make every hardware variant legally or technically suitable for every market. Radio components, antenna compatibility and regulatory approvals also matter. Confirm the full regional product specification before assuming that a configuration change is sufficient.
Conclusion
Choosing among LoRaWAN frequencies is primarily a deployment and compliance decision, not a preference for one band over another.
Start with the country. Identify the applicable LoRaWAN Regional Parameters and local spectrum rules. Then match the gateway hardware, antenna, end devices and Network Server to the same plan.
The Robustel R1520LG LoRaWAN Gateway and other products in the Robustel LoRaWAN gateway portfolio are offered in regional configurations precisely because a production LoRaWAN network cannot assume that one radio SKU is valid worldwide.
For multi-country deployments, the most useful purchasing rule is simple: Order the exact radio configuration and approval required for the country where the gateway will operate.
Explore more articles about Robustel’s LoRaWAN gateway in industrial IoT:
À propos de l'auteur
Robert Liao | Technical Support Engineer
Robert is an IoT Technical Support Engineer at Robustel, specializing in industrial networking and edge connectivity. A certified Networking Engineer, Robert focuses on the deployment and troubleshooting of large-scale IIoT infrastructures. His work centers on architecting reliable, scalable system performance for complex industrial applications, bridging the gap between field hardware and cloud-side data management.