Data-only hotspots on Helium can be connected to multiple LoRaWAN networks when DIY. I have some running myself.
How does it stay within legal Tx limits?
Not, when downlink load is high. But this is not relevant for the discussion.
Of course itâs relevant.
Both breaking the law, and dropping downlinks assigned to that gateway by the network server are serious issues.
At present thereâs no solution that solves both problems, because nobody has yet implemented a âHey, you willing to do this? Sorry, not right now, try somebody elseâ scheme between network servers and gateways, as would be required to share gateways.
Even âpacket brokerâ, which sounds like it should do that, turns out to not (at least in the TTN interface) to make any effort to solve the downlink airtime exhaustion / scheduling conflict problem whatsoever.
1 Like
Coming up with this topic in this thread is similar to hijacking a topic. I would have chosen to start a new thread. Although this topic was discussed extensively before.
Then why did you claim it was possible, especially if you are aware of previous discussion explaining why it isnât?
You canât yourself post misinformation and then complain about the responses which explain why it doesnât really work right.
Technically it is possible. So that is not misinformation. Is it legal? As long as the gateway stays within airtime allocations it is. Is there a process that will guarantee the gateway stays legal? No. Is it desirable? Not given the potential issues. Can anyone with sufficient knowledge make it happen? Yes, most definitely.
1 Like
Not really, no - you forget that legality is only part of the problem.
The other problem is downlink scheduling conflict.
That can only be solved by enhancing network servers with an algorithm that puts out requests, and if the original is declined, re-issues it to another candidate gateway.
At present, NACK on tx requests is theoretically reported, but I donât believe anyone has a âwell then weâll try elsewhereâ scheme.
The switch to a longer RX1 interval should make this possible to implement (for current packet forwarders with a queue which permits advance rather than last minute pushing of TX requests), but it hasnât been done.
Fortunately re-allocation would (in combination with gateways tracking their own airtime) solve both schedule conflict and legality problems.
Iâm not ignorant and as author of one of the packet forwarders am well aware of the issue. That is why I state it is not desirable and I try to discourage everyone attempting to do so. However if one accepts the potential downsides caused by downlink packet loss (which might happen anyway in an RF environment) and the potential backlash from fellow LoRaWAN users it is still possible.
Problem is the gateway deployer might accept risk of loss and other downsides but other community users dont get to decide and they also see downlinks for the âforeign networkâ causing the GW to miss uplinks whilst handling them creating an artificially high level of packet loss over and above what might be expected just due to RF environment or other issues - can even be viewed as a mini DoS 
Community users may be happy with a GW 5km away, then suddenly find a shared GW is placed say 500m away and esp with ADR they then find they are subject to increased lossesâŚ
1 Like
The problems are well known and beaten to dead on this forum by now. As this isnât going anywhere Iâll close the topic right now.
2 Likes