HIP 45: LoRaWAN Frequency Plan Selection
hiptron opened this issue · 12 comments
- Author(s): @lthiery, @ivandigiusto
- Start Date: 2021-10-25
- Category: Technical
- Original HIP PR: #298
- Tracking Issue: this
- Status: Withdrawn
Problem Statement
There are over a dozen of officially recognized LoRaWAN channel plans cited in the LoRaWAN Regional Specification. In each region, the Helium Network must select one and only one frequency plan (based on current design constraints). In cases where only one channel plan is possible (eg: Anguilla) or where only one has regulatory type approval (eg: American Samoa), the selection for the Helium Network may default to that one.
This HIP proposes methodology for the selection of a channel plan for each region.
Rendered View
https://github.com/helium/HIP/blob/master/0045-lorawan-frequency-plan-selection.md
We are already experiencing problems in Australia where there seem to be a lot of 'misconfigured' gateways. According to the documentation https://docs.helium.com/lorawan-on-helium/frequency-plans/ (and I completely agree with this choice), the officially supported frequency plan is AU915 FSB2.
The issue seems that gateway manufacturers seem to be shipping gateways to Australia with US915 configuration as well as various AS923 configurations. Whilst AS923 happens to be legal (as it's just a subset of the 64 AU915 channels) US915 is not.
The same problem has happened during the TTN Public deployment (see an extensive explanation and discussion here: https://www.thethingsnetwork.org/forum/t/future-strategies-for-au915-and-as923-in-australia/) and has caused a fragmentation of the network which makes tracking use-cases impossible. Helium would have a huge potential in such use-cases, but I fear we are already seeing the same problem occurring on the currently ~3000 Helium gateways. I am aware that DEWI tried some very hasty and in my opinion very short-sighted and ill-considered change to AS923 which thankfully was reversed quickly.
Currently, there is no way of seeing which channel plan a Helium gateway is configured to. I think this would be of critical importance for a consistent countywide network.
I believe for Helium to be able to live up to its potential in Australia really has to fix this problem urgently before it ends up a nightmare for people actually trying to roll out sensors in the real world,
There has been strong support for this proposal. The coredevs support it, the newly formed LoRaWAN committee supports it, it has 95%+ support in Discord straw polling, and there have no concerns raised either here or on the monthly community call, and it has been open for several months.
I believe this proposal has passed our standard for rough consensus, and an on-chain temperature check or vote is not required.
On behalf of the DeWi, the HIP Editors, and the wider Helium community, I am marking this proposal as approved, and request that the coredev team implement the necessary changes as soon as reasonably possible.
Several times I've heard Helium staff refer to Australia as though it is undecided between 2 frequency plans.
That's not the case. AU915 is the default standard (it's named that way) and AS923 is allowed for historical reasons and hardware supply issues that don't apply anymore.
This discussion is essential for anyone who needs to understand this https://www.thethingsnetwork.org/forum/t/future-strategies-for-au915-and-as923-in-australia/44218
At least one commercial operator uses AS923, and some private operators probably do too, but for public LoRaWAN ie TTN it's overwhelmingly AU915. AU915 also has technical superiority, and it is the frequency that Helium began with in Australia.
So if anyone wants to change the Helium frequency plan for Australia now, they need to address these points.
If a commercial operator wants this change to happen they need to justify to the Australian Helium community the benefit for the community. It could be that they bring enough roaming traffic to make it worthwhile, but I doubt there's much traffic at all outside a few capital cities and hosts aren't currently given much for traffic and that would be weighed against losing TTN compatibility.
Since this is about Frequency Plan, I do need to highlight that we face the same problem in Malaysia. The allowed frequency is actually 919-923MHz with an EIRP of 500mW (max), and 923-924MHz with an EIRP of 500mW (max) and some extra conditions. So legally, LoRa or LongFi should not transmit outside of 919 - 924MHz and best is to stay within 919-923MHz only. The official document is here: https://www.mcmc.gov.my/skmmgovmy/media/General/pdf/Class-Assignment-No-1-of-2021_.pdf.
However, referring to LoRa Alliance document: https://lora-alliance.org/wp-content/uploads/2021/05/RP002-1.0.3-FINAL-1.pdf, There are 3 frequency bands listed for Malaysia, 433-435MHz(EU433), 916-919MHz(AS923-1), 919-924MHz (AS923-1). But the hotspots in Malaysia are transmitting frequencies of 923.2, 923.4, 923.6, 923.8, 924.0, 924.2, 924.4, 924.6 MHz. As you can see, any freq above 924MHz are out of the range allowed by Malaysia authority. Even 923MHz have special condition of < 1% duty cycle, or freq hopping or LBT.
In short preferable frequency band should be within 919-923MHz, which I think should be AS923-2=921.4, 921.6, 921.8, 922.0, 922.2, 922.4, 922.6, 922.8. These freq band are within the allowed operating freq in Malaysia.
Hope to get the attention from the Helium community. We want to grow the network legally in Malaysia.
Grabbed this info from the Australian helium discord chanel. Seems like changing to As923 is going backwards.
AU915:
- Official ACMA Regional Standard
- 64 available channels (8 sub-bands)
- Higher antenna power (30 dBm max EIRP)
- no duty cycle limitation
AS923:
- 16 channels (2 sub-bands)
- Limited antenna power (16 dBm max EIRP)
- Multiple implementations depending on which Asian country (AS923-1, AS923-2)
There is a number of other minor things, but that would be the major stuff. If you want the full low-down: https://www.thethingsnetwork.org/forum/t/future-strategies-for-au915-and-as923-in-australia/44218 or https://www.thethingsnetwork.org/docs/lorawan/regional-parameters/
We need 915 for the extra power in rural areas. Connecting towns and farms together Australia wide could be huge.
I am providing this feedback based on having run LoRaWAN networks (both AS923 and AU915) over a number of years. I have previously run other IoT networks in the same spectrum (915-928 MHz) in Australia. I am also a contributor to the LoRaWAN Regional Parameters document.
I completely understand @Ravenitt points and concerns and would like to address them here. There is a difference in what the spec says vs what it means in the real world.
| Comment | Response |
|---|---|
| AU915 | |
| Official ACMA Regional Standard | Not the case. The ACMA does not have a position on which LoRaWAN channel plan should be used in Australia. This is not their purpose nor their authority. The ACMA sets the radio rules (allowed frequencies, power and interference) for the use of radio spectrum. Also, the LoRa Alliance label of AU915 only indicates it as the first channel plan that could be used in Australia/New Zealand, not as the only one. AS923 was developed as it became clear that regional uniformity existed in the Asia-Pacific region and that a more flexible channel plan would be beneficial. |
| 64 available channels (8 sub-bands) | Correct. 64 channel max, but all Helium hotspots at this point are using only 8 channels. |
| Higher antenna power (30 dBm max EIRP) | AS923 can use up to 30 dBm. More info in AS923 section below. |
| no duty cycle limitation | There is no duty cycle limitation for AS923 when used in Australia/New Zealand. |
| AS923 | |
| 16 channels (2 sub-bands) | At this point, maximum number of channels that can be configured in one device is 16. This does not mean that all devices have to use the same 16 channels. By having channels dynamically assigned, you can spread your devices however you want, allowing you to use a wide frequency range. Additionally, this allows the option to use the newly opened 928-935 MHz spectrum (or any other band that is open to public), once Helium in AU/NZ gets to a point of needing to expand to two bands. |
| Limited antenna power (16 dBm max EIRP) | 1. The protocol allows devices to enable higher transmit power after connection (up to 36 dBm but you need to operate within the ACMA regulations). 2. There is nothing prohibiting you from setting the device to a high power transmit in the firmware (within ACMA regulations) if the device will only be used in AU/NZ. The network does not care. 3. This value does not apply to the downlink transmit power which means it can fully utilise the maximum allowed power (within the ACMA regulations). |
| Multiple implementations depending on which Asian country (AS923-1, AS923-2) | All implementations use the same logic, The only difference is the initial two uplink frequencies. |
I would also like to point out the technical benefits of AS923 not discussed by others:
| Feature | Benefit |
|---|---|
| Uplink channels configurable | Other than the two mandatory channels (923.2 and 923.4), the rest of the channels can be freely configured to desired frequencies. This allows for better management of future capacity expansion, interference management and day-to-day network operation. It is possible to have different sets of devices operate on different frequencies. Imagine a future where we start needing more than 8 channels due to a large number of devices. The network would end up having 8 channels across the country, and dense areas would retask some hotspots to cover a new band of 8 channels. Devices that are mobile would be configured with 8 channels that are most common across the region. Devices that are stationary (water meters, environmental sensors, rain gauges, etc.) could be switched to the new 8 channels. While you could do this with AU915, you would have to pick a fixed bank of channels. With AS923, that spectrum can be anywhere (within the ACMA regulations) That flexibility is very valuable for the continued success of Helium. |
| Downlink channels can be customised for each uplink frequency | Instead of being stuck with hard-coded downlink frequencies, AS923 allows for customisation of each downlink frequency. This allows the network to deal with potential interference and congestion issues in the future. Future interference and congestion issues can severely impact the viability of the Helium network, so it is essential to have tools at our disposal to deal with them as they arise. |
| Slowest downlink SF12BW125 | AS923 downlink will be able to reach further than on AU915 (SF12BW500). The difference is about 5 dB which is close to doubling the downlink range |
I am providing this feedback based on having run LoRaWAN networks (both AS923 and AU915) over a number of years. I have previously run other IoT networks in the same spectrum (915-928 MHz) in Australia.
Well, that is good for you. I am assuming that these were insular private LoRaWAN networks. However, what we are talking about here is a public network on a global scale. Helium in Australia is already at a scale no other LoRaWAN network has ever achieved.
There is a difference in what the spec says vs what it means in the real world.
That is a very dangerous comment to make. Standards are there for a reason. This is not the wild west.
Just because you could ignore the standard and make all these changes on a private network where you control all the aspects end-to-end (devices, gateways and NS) does not mean that this is relevant with a large public ecosystem of gateway and device manufacturers worldwide.
Gateway radios are controlled by standardised configuration files and devices by respective libraries which enforce the official (AS923/AU915) specs.
Just because there is the theoretical ability for these things to be different in Australia is totally irrelevant. It will never happen on a public network.
Also, the LoRa Alliance label of AU915 only indicates it as the first channel plan that could be used in Australia/New Zealand, not as the only one. AS923 was developed as it became clear that regional uniformity existed in the Asia-Pacific region and that a more flexible channel plan would be beneficial.
This is also a very misleading comment.
AS923 was never developed for Australia. Quite obvious by the first two characters. It just happens to fit into the rules as it is just a subset of the AU915 channels plan and with lower limits on TX and duty cycle limitations.
The fact is also that AS923 only became useable in Australia after LoRa Alliance made some changes.
Anybody with a history of LoRaWAN in Australia knows it wasn't chosen for reasons of being better suited for Australia by some private operators - it was chosen purely as in the early days because of issues with certain device availability. That pretty much is a non-issue these days for devices using recent LoRaWAN modules.
64 available channels (8 sub-bands) Correct. 64 channel max, but all Helium hotspots at this point are using only 8 channels.
The important part in this comment is "at this point". It is shortsighted to assume that this is not going to change as the Helium and LoRaWAN ecosystem matures. We are building this network for the future - not just for today.
Downgrading the Helium network at this point (by adopting AS923) is incredibly counterproductive and short-sighted.
Higher antenna power (30 dBm max EIRP) AS923 can use up to 30 dBm. More info in AS923 section below.
Could theoretically be used - again just a misleading comment.
The AS923 specs say 16 dBm max EIRP and that's what is in the radio configuration the gateway manufacturers are shipping.
The fact is that this is totally irrelevant in the real world. Just because theoretically you could doesn't mean it has any realistic chance of ever happening on a public network ecosystem.
This TX limitation is actually the most crucial deficiency of AS923.
You might be able to mask that fact in the densely populated metropolitan areas. But that is a very small part of Australia. This would be absolute madness in the rest of Australia.
A large number of these devices would never be able to get through an OTAA join procedure outside of dense metro areas because of the limited TX power of AS923.
Changing the Helium frequency plan for Helium in Australia is the equivalent of taking out a shotgun, aiming straight for your foot and pulling the trigger.
no duty cycle limitation There is no duty cycle limitation for AS923 when used in Australia/New Zealand.
Again - as per the previous point. These limitations are enforced by gateway radio configuration and devices libraries. What you are effectively arguing for is "AS923-4" - YAFFP (yet another f....g frequency plan).
All implementations use the same logic, The only difference is the initial two uplink frequencies.
You are totally missing the point. AS923 has 3 variations (AS923-1, AS923-2 and AS923-3).
The point is that the whole region "roaming" argument is a furphy. AS923 is fragmented and in fact, Australia's closest neighbour (and by far the largest population in our region) is AS923-3.
Much more important is the huge differences between the countries adopting AS923 and AU915.
(thanks @rockinrobstar for the image)
Countries adopting AS923-1 are mainly countries that have high population density. That is the EXACT opposite of Australia. If you look at the list of countries adopting AU915 they are large countries with vast areas of very sparsely populated regional areas. Look at Brazil or Argentina or Chile. There is an obvious reason for this.
Overall these comments are mostly irrelevant in the context of a global PUBLIC network with phenomenal growth and in a country as vast as Australia. And they are downright dangerous for everyone who has invested their time and money in the Helium network in this country. They serve no purpose other than saving face for some private network operators that have bet on the wrong horse years ago.
The same private network operators I actually notice on your list of employers (LinkedIn). Would it not be appropriate declaring that conflict of interest here?
As for some of the RF details, I would highly recommend reading the comments from @tonysmith55 in the main PR
"AS923-4" - YAFFP (yet another f....g frequency plan).
AS923-4 already exists for Israel. So you will need to go to AS923-5.
I think this probably proves your point even more though 😉
@shawaj @leogaggl @ivandigiusto @oberchoo @buzzware
It seems many of these comments relate to AU+NZ in particular and I request such comments move to the dedicated topic:
dewi-alliance/hplans#28
HIP45 amendments or related governance topics might be related here, but this HIP has nothing to do with AU+NZ in particular and instead covers frequency plan changes in general.
HIP 45 was invalidated: https://discord.com/channels/404106811252408320/813452716286017557/1006694552557596733
HIP45 has been closed, and the corresponding Discord channel has been archived. Some thoughts have been raised that HIP45 needs to be unlocked as frequent changes are planned and need discussion.
Going forward, #poc-discussion in Discord is the best place to talk about HIP45. HIP 45 was a HIP to create a way of deciding on which frequencies to use where there was more than one, or it was undefined. But, since we became more involved with the LoRa Alliance, Helium made a decision to follow their defined or recommended default standards for a country rather than decide on our own and break with the rest of the alliance.
Country frequency plan issues can also be raised at hplans
hplans is a geojson representation of the LoRaWAN regional parameter channel plans. It is based on the LoRaWAN Alliance's RP2-1.0.3 LoRaWAN Regional Parameters, as well as the Helium Network's country definitions.