-
Notifications
You must be signed in to change notification settings - Fork 408
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HIP draft – LoRaWAN Sub-region Max EIRP Limit #325
Conversation
Country: Singapore (AS923-1) |
Country: Malaysia (AS923-1) |
Country: Taiwan (AS923-2)
Reference: Low-power Radio-frequency Devices |
_Country: Indonesia (AS923-2) |
Country: Vietnam ( AS923-2) |
Country: Philippines: AS923-3 |
This seems like an improvement to the network to me. Is there a difference between new regions and sub-regions? I assume sub-regions have the same channel plan but with a different EIRP limit. If it is decided to do this maybe they just be treated as whole new regions instead of adding a sub-region concept? Here is a summary of places that have been mentioned. Feel free to add to the list https://docs.google.com/spreadsheets/d/17Ta-k97ciFYQ9oYfUYp7wJCQKNXjcEhte6gE6gunIjU/edit?usp=sharing |
@gradoj thanks for the summary. I will try to update more soon. I think your subregion grouping is just fine. Will try to add other countries to fill up the table |
latest regional parameters from semtech has Malaysia at AS923-1 |
anyone know why Semtech has the 16dBm EIRP in the regional parameters? it would be nice to know their reasoning on that. i'd guess to combine countries and minimize the number of regions but maybe there are other factors. For example, if sensors cannot transmit above that power limit legally it may not make sense for the gateways to be much stronger. In that case, even if it could be done legally, it may not make sense for us to increase these limits for poc. I'm starting to think this should be part of hip-45. |
Well tbh each country in Asia follows their own set of allocated Freq. Not necessarily they have to follow semtech or alliance. They follow the AS923 as a standard but define their own set of Freq |
If I'm not mistaken, it says the word "default" as 16dbm. My interpretation is not an enforcement. Cause ultimately enforcement authorities are local govt. |
Not sure where you are on the "should PoC represent real-world coverage" discussion, but in case you lean towards yes (I'm not saying you need to), the following table of existing LoRa device chips might be useful (I compiled it for #21) :
|
Hi, judging from your document, this is still a drafting document. The last that I check with some legal documents, if your device has ERP higher than 25mW (for the AS923 frequency bands), you will need to ask for a certificate from the government to operate. This means the limit to EIRP (for using hotspot without seeking operating certificate from government is about 41 mW EIRP) There is also translated summary/documents by legal companies in VN as shown in this link I recalled they said there is some new legal documents in effect from 12/2021 from frequency regulators in VN. Will double check this again. |
Below is the last updated published regulation : |
Hi thanks, I will have a read on this. This might just be about national standard on LPWAN devices (for manufacturers who want to sell products in Vietnam, which will need to go through testing and approval by the govt agency) but they don't mention operating regulations I was referring to this document. You can check page 48, Phụ Lục 19 (annex 19). This annex said that they will waive the need for end user's license if your LPWAN device with 920-923Mhz has <25mW ERP. This document is recently issued and currently in effect English version (translated by a third-party legal company) is also here for ease of discussion. Apologise for the mess in our regulatory system |
Technically, every product SKU needs a type approval. This is simplified by using a certified module (e.g. from Semtech or others) rather than the chip (from Semtech only). BUT, use of a certified module does not officially alleviate the need for final testing and approval, though some products do skip this step when using a certified module. |
Seems in line. The "end users' operating license" is the person buying and setting up the Helium hotspot. So, a manufacturer selling there would still need testing to prove that their device meets the EIRP as well as other RF envelope requirements. |
Yes, I think we should look at the perspective of hotspot owner here to help expand our network further. Also getting a user license in certain country, like my one is really a pain. |
Country: Thailand |
I've asked about this issues (both regarding differences in freq usage in as923 country and also the max eirp for as923), but it's been 2 months now i believe, and seems we're starting from scratch again. Now after POCv11 is implemented, we have seen the beaconing/witnessing activity has been suffering a lot in AS923 countries. The distance of the beacon gets shorter. Tx power has been reduced to 16dbm seen from the JSON data from various brands of hotspots deployed in AS923 countries. Now with this open issue (again), now we can see also that it turns out the freq being implemented by Helium for some AS923 countries are not conforming with the Govt regulation in Asia. How can this be? Please speed up this process as we don't want the hotspots to be confiscated by the Authority for breaking the regulation on Frequency utilization. So to summarize this issue with Helium in AS923:
|
@ubiru I understand that you raise the issues way before, that's why I credited you as part of the author (was trying to contact you on discord). This HIP is directed to address the Tx power, you can read the commit if you have not. Regarding the issue with Helium in AS923, the first point can be addressed with the help of HIP 45 and for 2nd point, we should address this in HIP 49. |
i just wished that when helium decided to keep delaying the poc11 at that time, there was enough time for them to fix the issues with AS923. But they did nothing and now it's kinda we're talking from scratch again with them. sighhhhh it's a known problem from the beginning if only they look at the govt regulation issued by each country instead of just looking at a piece of document from the lora-alliance. if only.... |
For very dense city states like Singapore and Taiwan (arguably overcrowded with hotspots already), might the reduced transmission power actually help level the playing field and even out rewards? Previously, those who had the benefit of high rise access (which confers natural line of sight advantage) were double dipping with high gain antennas to extend range. |
@MavJoe405 Overall coverage for AS923 countries in general have been impacted by the reduced tx power with the fact they could be doing better with the higher local regulatory limits. You can probably take a look at HIP17 if your concern is about density etc. |
Yes, i understand each country follows their own regulations. Semtech has grouped the countries into a reasonable number of channel plans based on each countries regulations. In doing so there may have be some compromises like max eirp but the advantage is sensor manufacturers do not need to worry about each country they can comply with the LoRaWAN Standard and set the lorawan region and know the sensor is compliant with regulations. in my opinion POC is supposed to be an analog to sensor performance so i wouldn't approve this hip unless there was an official LoRaWAN region or subregion defined. If there is no official sub/region there will never be any sensors built that take advantage of the higher power. The regulations are complicated and as you can see from the chaotic discussion here i don't think it is the right place. I vote to move this to hip45. |
Hi..I thought we are talking about the EIRP of hotspots not sensors . Each country has a different regulation of EIRP of hotspot and sensors. Like in Singapore the max eirp allowed for a gateway is 500mw and for sensors it is 100mw. Not sure where is the sensor EIRP coming to the picture here. Each hotspot vendor has to go through country specific test for compliance and same for sensor manufacturers. They are totally 2 different things. Apologies if I got it wrong. |
@beaky98 sorry for being unclear. What I mean is that if PoC is supposed to simulate real-world coverage for devices (to stimulate long-term growth), then the extra tx power allowed by hotspots in some regions is useless, because devices would not be able to use that extra tx power anyway. Using higher power would mean that PoC simulates something else than device coverage. But if PoC is not supposed to simulate real-world coverage for devices, then we should probably use the maximum tx power allowed by law. |
in my understanding, LORA gateway is a passive device when working with sensors. It's only being active in POC activities. If the gateway's tx power is bigger than the sensors', then the sensors can be located in the edge (but crossing coverage) of the 2 gateways and it can still connect to either gateway. And the idea of gateway tx power is bigger than sensor i believe due to the gateway quantities would be much less than the sensors and gateway is supposed to be located (or at least the antenna) in much higher ground compared to the sensors which may be so closed to us, so the radiation/interference from the gateway is limited. |
I guess then it's been answered 6 months ago. So let's move back on to what we are trying to address here. |
We think this is the way to go and close it ..:) |
Helium follows the LoRaWAN standards. Semtech created the standard to follow the regulations in all countries. If a country changes their spectrum or rules the standard will change to adopt it. If any parameter is incorrect in the standard including the max EIRP it should be taken up with HIP45 to change the standard(as some limitations intentional to limit the number of channel plans). I actually think you are wrong saying all AS923 frequencies in Asia are incorrect. I as well believe POC should roughly simulate sensor coverage. Yes, we are talking about fixed installed hotspots but if their sensors can only transmit at a lower power then i am not in favor on changing the max eirp. Again: we are all talking about hotspots, Semtech created a Standard. That standard is designed to follow all country's regulatory rules. If you want to change the Standard to improve performance legally in a country then it should be brought up with HIP45 |
@abhay can you please help us out here? It seems like we are going about this all over again in loops.. |
I never said not to do it. I said you shouldn't just change it and ignore the standard because if new regions are not added sensors will never be able to take advantage of what you guys are advocating for. If sensors cannot take advantage of the change then there is no point - as Poc is an analog for sensor coverage |
If LoraWAN regional parameters are followed, in that case, why the default uplink frequencies in AS923-2 and 923-3 are not according to the lorawan regional parameters? again my point is not only the EIRP.. we are risking the helium hotspot investors in legal issues with wrong frequencies. Also, LoRaWAN regional parameter says default EIRP as 16dBm, not MAXIMUM. Maximum is regulated by country. So they are just leaving the EIRP as minimum default and let the countries to decide on maximum. |
This is not supposed to be about what anyone's thinking. But it's about following what's been regulated. If for these past few months people incl. Helium team side been talking about POCv11 is made also for complying regulation, then why do we need to argue about this? We need the action, not the long discussion. Don't make this issue and also the HIP to cover this issue becoming something forgotten like last time and the just be closed after that long period of nothing. |
It actually said 'default maximum' whatever that means. Please be very specific: what channels are incorrect in 923 and in which country? |
Also, about the frequency, LoRAWAN regional parameter says AS923-1 is from 915-928 Mhz? so why didn't helium allow the entire range in AS923-1? there must have been a rationale behind this that helium did not allow to use the entire range. about wrong frequency, what I was pointing is the uplink frequencies in AS923-2 are wrong in helium. in AS923-2 it is 921.4 and .6 NOT 923.2 and 923.6 .. which is clearly defined in regional parameters. |
i was very specific in the first post where I have mentioned the incorrect uplink frequencies. |
If so, why not just create a ticket? I don't see how it is relevant to this discussion |
that's fine to create a ticket. but going around the circle is risking the hotspot investors to be in legal issues in different countries... that's what I was trying to point. EIRP is not a legal issue..but its an earning issue of the hotspot owners, which is the most important thing for now, else no one will invest on helium anymore... but transmitting out of the allowed band is a legal issue. that was all I was trying to say. |
if poc is analog for sensor coverage, then when you deploy it like a bts, then it would have so much blank spot on the network coverage. Pls read my comment above |
When a hotspot owner got issues with the govt on the freq matter, his investment on the device will go down the toilet. Govt will seize the hotspot from the owner.
But owner has no control over the freq setup of the hotspot, so owner then may take a lawsuit or a class action suit to the manufacturers. Blaming the manufacturers for leading them into buying some devices with illegal impact.
But then again, manufacturers have no control over what freq being setup on the hotspot because it was helium who wrote the code inside that managing the freq being used in such country.
So hopefully, someone is now doing their homework, instead of just keep using a piece of doc from lora alliance as an excuse and say it's a standard, but ignoring the regulation from each govt. And doing it fast.
As i still remember that it was said as the people network, not the certain country people network.
Get BlueMail for Android
…On Dec 23, 2021, 23:08, at 23:08, joyanta-klk ***@***.***> wrote:
that's fine to create a ticket. but going around the circle is risking
the hotspot investors to be in legal issues in different countries...
that's what I was trying to point. EIRP is not a legal issue.. but
transmitting out of the allowed band is. that was all I was trying to
say.
--
Reply to this email directly or view it on GitHub:
#325 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
|
Why do you guys keep talking about illegal frequencies being used? If you've found a mistake with channels being used create a ticket with helium and the lora alliance. This is not relevant to the max eirp hip discussion |
This I agree. Everyone, let's keep this discussion relevant to the HIP proposal. |
Firstly, thank you, everyone, for all the valuable feedback and opinions. I apologize for how things have turned up into. One of the main reasons for PoCv11 is to be compliant with the regional regulations so that the hotspots would not be operating illegally in countries exceeding the max EIRP limits mandated by local regulations. PoCv11 has however not taken into consideration that not all countries have the same regulatory max EIRP limits by implementing the blanket 16dBm max EIRP limit across the entire AS923 region & others affected. Most of the countries in AS923 has local regulatory max EIRP limits of 25-27dBm (up to 500mW) instead of the 16dBm (40mW) implemented via PoCv11. IMO, this is a bit like a car manufacturer saying they will limit all their cars to a 30mph speed limit with engine cut off regardless of individual countries' regulatory speed limit because there is a standard that's being used for reference. We are not asking to implement something different but rather a fair request for impacted countries to have their max EIRP limit corrected for Helium hotspots based on local regulation which aligns with what PoCv11 is set out to achieve rather than being penalized. With regards to the discussion below, I feel that we need better clarification as this could be a separate discussion as it is something different.Quote by @gradoj
I'm not sure if Semtech standards are being used/referenced for PoCv11, if so: We can certainly explore the topic mentioned when we transit to a more real-world data usage-driven phase with the Helium network. Coming back to the topic for this HIPQuote by @gradoj :
@abhay @lthiery @vihu @gradoj Whatever I have said is more or less the TLDR of what's discussed in this request. I would like to ask you to please advise how we can move forward with this? |
Wio Lorawan Tester from Seeedstudio for helium tester is using STM32WLE5JC which using SX126X chip from SEMTECH. So that means even SEMTECH is designing chip with 22 dBm. Not 16 dBM. And this is being used in ASIA for AS923 frequency. |
Sticking with car analogy...my car has a top speed of 222km/h. Doesn't mean i can legally drive it at that speed.
There are a couple of things stopping this imo. These might help move things forward:
|
@gradoj thank you for your comments. For now, We will work towards:
Anyways, thanks to everyone for their valuable feedbacks and points, and Merry Christmas! Let's take a break from the heavy discussion. |
@beaky98 last minute but would you be interested in presenting this HIP at the community call today? noon ET https://dewi.org/community-call |
@jamiew Sorry, not able to make it today. I will try to present it in a future session. Please keep me in the loop for any questions posted later, thank you. |
This HIP draft has been numbered and merged for discussion as HIP 49. Please direct future questions & comments to the new tracking issue: #327 If you are one of the named authors, please include |
This proposal suggests adopting a LoRaWAN subregion config for max EIRP limit which will allow individual countries within an RF region i.e. AS923 to define max EIRP limit based on each country’s local regulation instead of a single max EIRP limit across the entire AS923 as a result of PoCv11.
Hope to hear everyone's feedback! Thank you! :)