A LoRaWAN gateway should be selected for the country where it will operate, not just the country where it is purchased.
This becomes important when a monitoring system validated in Germany later needs to be deployed in the United States, Australia, or Southeast Asia. The application may be reusable. The exact gateway radio variant, antenna, end-device configuration, and Network Server channel plan may not be.
A Robustel R1520LG LoRaWAN Gateway is available in different regional radio variants, which makes it a useful example for this issue.
A practical procurement sequence looks like this:
deployment country
→ permitted LoRaWAN regional plan
→ gateway radio variant
→ antenna and end-device compatibility
→ LNS channel configuration
→ regulatory approval
Getting this 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 country, not the SKU
A common shortcut is to ask for “an 868 MHz gateway” for Europe or “a 915 MHz gateway” for everywhere else.
That is not precise enough for production deployment.
Regional plans such as EU868, US915, AU915, and AS923 are not just marketing labels. They define channel structures, data rates, power behavior, receive windows, and other radio parameters.
A rollout covering Germany, the United States, Australia, and Japan should not use one vague line item such as:
LoRaWAN gateway, 915 MHz
It should identify the actual market and regional plan for each deployment:
Germany → EU868 variant
United States → US915 variant
Australia → AU915 variant
Japan → AS923-1-compatible configuration
The first procurement question should be:
Where will this gateway legally operate?
Only then should the gateway variant be selected.
AS923 is not one universal “Asia band”
AS923 often causes confusion because people treat it as one Asia-wide frequency plan.
It is more specific than that.
AS923 has multiple subgroups, such as AS923-1, AS923-2, AS923-3, and AS923-4, which exist because different countries have different spectrum allocations and operating requirements.
That creates a practical problem for multi-country deployments. Saying “AS923 supported” is not enough when equipment is preconfigured in one country and shipped to another.
A better regional record should look like this:
country
→ AS923 subgroup
→ permitted local spectrum
→ exact gateway variant
→ sensor configuration
→ LNS channel plan
→ certification status
This prevents the common mistake of assuming that “Asia” is one radio configuration.
Keep gateway, sensor, antenna, and LNS aligned
Correct gateway hardware is only one part of compatibility.
A LoRaWAN network works only when the complete radio path agrees on the regional configuration:
end device
↔ end-device regional configuration
↔ gateway radio and antenna
↔ packet-forwarder settings
↔ LoRaWAN Network Server channel plan
A US915 end device does not become compatible with an EU868 gateway because both products support LoRaWAN. An AU915 gateway and a Network Server configured with mismatched assumptions can also fail even though both sit in the broader 900 MHz range.
The antenna belongs in the same chain. The connector may fit, but the antenna still needs to cover the correct frequency range and remain appropriate for local radiated-power rules.
The LNS must then use the same regional plan as the gateway and devices.
Build a regional approval record
For international deployments, the safest approach is to create one record per country.
A useful record should include:
deployment country
LoRaWAN regional plan
local spectrum requirements
full gateway model and regional order code
certification status
end-device regional variant
antenna frequency range and gain
LNS channel plan
firmware and configuration baseline
replacement stock
join/uplink/downlink validation
This record should be completed before hardware is released for volume deployment.
It also helps with replacement. A gateway with the correct software configuration but the wrong radio variant is still the wrong replacement.
Regional information should be part of procurement records, installation documents, configuration templates, spare-parts management, and field-service instructions.
Where Robustel R1520LG fits
Robustel R1520LG LoRaWAN Gateway illustrates why gateway selection needs regional control.
The product line includes regional variants for EU868, AU915, US915, and AS923-type deployments. The exact order code and certification should be checked for the target market before procurement.
The gateway can connect to external Network Servers or operate with embedded ChirpStack, but the LNS architecture does not remove the need for correct regional radio configuration.
Remote management can help track fleet configuration, but it cannot turn the wrong radio variant into the right one.
FAQ
Q1. What LoRaWAN frequency is used in Europe?
EU868 is the common LoRaWAN regional plan associated with the EU863–870 MHz band. Buyers should still confirm the destination country, gateway regional variant, antenna, device configuration, and applicable approvals before assuming every “868 MHz” product is interchangeable.
Q2. What is the difference between US915 and AU915?
US915 and AU915 are both 900 MHz-region LoRaWAN plans, but their uplink channel structures and regional parameters differ. A gateway or sensor configured for one should not automatically be treated as compatible with the other.
Q3. Can LoRaWAN frequency be changed only through software?
Not always. Software can configure channels within the capability of the installed radio, but it cannot make every hardware variant legally or technically suitable for every market. Radio hardware, antennas, and certifications also matter.
