Try all uplink channels during OTAA for US915 and AU915

[gonzabrusco]

For LoRaWAN regions US915 and AU915, the device should attempt OTAA joins by rotating through all 64 (125 kHz) uplink channels (0–63) using DR0 and all 8 (500 kHz) uplink channels using DR4, as specified in the LoRaWAN Regional Parameters document. This is especially important for devices with no preconfigured subband, or when deploying on networks with unknown or dynamic subband configurations.

According to RP 1.0.2: For rapid network acquisition in mixed gateway channel plan environments, the device SHOULD follow a random channel selection sequence which efficiently probes the octet groups of eight 125 kHz channels followed by probing one 500 kHz channel each pass. Each consecutive pass SHOULD NOT select a channel that was used in a previous pass, until a Join-request is transmitted on every channel, after which the entire process can restart.

After a successful join the device should wait for LinkADRReq MAC commands from the network server to update the channel mask (i.e., reduce active uplink channels to the selected subband or custom mask).

Is that possible with RadioLib?

[StevenCellist]

I see that this is not really mentioned / documented: selecting subband 0 will replicate this behaviour. With the note that it selects one random channel from each subband until all subbands are exhausted, after which it does another random selection: this means that it is unlikely to cover all 64+8 channels in one go, but it will most definitely cover all subbands. It is a wish for future me to implement a deterministic selection to cover all channels without random selection. That is likely postponed until I can get my hands on a real 64ch gateway :)

[gonzabrusco]

Great to hear that! I had assumed that behavior wasn’t implemented because, in all the examples, the comments mention that for US915 and AU915, we should use subband = 2. That left me unsure whether the full channel-scan behavior was actually supported, and whether the device correctly handled the LinkADRReq with the channel mask.

[StevenCellist]

By all means, please try it and see how it behaves (you might want to enable DEBUG_PROTOCOL to see more info). It's a feature that isn't used much and I only try my US915 gateway once every few months as law requires me to limit transmissions to just my room only.. ;)
But as far as I know, it all fully works.

[HeadBoffin]

Is that possible with RadioLib?

Absolutely. The question is, is that a useful function as almost all the gateways in the world are 8 channel so trying 64 channels upon deployment gives the device a much longer join time. Most LNS's suggest a sub-set, hence the channel mask.

This is especially important for devices with no preconfigured subband

Which ones are those? And can't they be configured before deployment?

, or when deploying on networks with unknown or dynamic subband configurations.

Which ones are those? Using unknown networks has so many downsides - like how often they are available and/or move sub-band (which would render all the devices joined via it offline, so not likely to be a thing).

If you are hoping that LW networks are like public WiFi, then that's not the case.

But the age old question is the why. What is it you want to achieve? Do you want to run 8 low cost gateways in parallel or 4 expensive gateways in parallel (those that can do 16 channels)? Or really just unwrap a device, register it's credentials on an LNS and then send it out in to the world hoping that the gateway that hears it is has some sort of connection back to the LNS it is registered on? Because if you've registered it on an LNS, like you have to, then you know what channel plans are in use ...

[HeadBoffin]

Not an identified bug or deficit at this stage given that the stack passes all pre-certification tests, so converted to issue.

[gonzabrusco]

If you're developing an off-the-shelf commercial product intended to operate in LoRaWAN regions like AU915 or US915, it's critical that the device can work out-of-the-box with any gateway deployment without requiring prior knowledge of which subband is in use.

This is precisely why I believe the device should attempt to join across all subbands. Since the device initially has no information about which subband is active, scanning all available join channels becomes part of the discovery process. Once the join succeeds, the network server provides the operational channel configuration via the LinkADRReq MAC command with the appropriate channel mask.

Relying on a fixed subband for a commercial product introduces limitations: either we must provide the end user with a way to configure the subband, or we risk situations where the device is unable to join simply because the user's gateway is listening on a different subband (e.g., subband 3 instead of 2).

By allowing the device to scan all subbands during join, we ensure maximum compatibility and eliminate the need for manual configuration, something especially important when targeting large-scale or consumer deployments.

[gonzabrusco]

But for that you must have the persistent storage. You have to store in a NVM the state of the device and not rejoin each time you restart.

[HeadBoffin]

Which is a requirement of the 1.0.4 and 1.1 specs and IS implemented ...

[gonzabrusco]

Great. So I truly don't understand why you said:

Well.. it is quite inconvenient and poor behaviour to have to wait for 8 join-requests everytime you restart a device if you're on subband 8.

If you have persistent storage, you don't rejoin on each restart. You are contradicting yourself.

[HeadBoffin]

Not really, we may have some abilities with LW that are hard to get across when volunteers who's first language is not English type stuff, probably on a phone whilst on holiday ...

RL LW supports v1.0.4 and v1.1, both of which require persistence to store as a minimum the DevNonce. We can also hold the entire session, useful for ESP32 who's version of deep sleep is more like off.

What Steven was trying to say is that if you deploy a pile of these devices all trying to join, a full 7 eighths of the transmissions could be pointless. Why do that, why not set the device to the LNS settings.

[gonzabrusco]

I completely understand what you are saying. And it is up to you if you want to implement that functionality or not (or if I should make a PR or not). I'm just stating what the Regional Parameters documents says (in the image of the first post). I can provide a method for the final user to choose the subband, I just wanted to see if it was possible to avoid that step using RadioLib. What I'm telling you is not something I'm inventing out of nowhere, it's on the specs. And that's why LoRaWAN have the channel mask setting on the LinkADRReq MAC command. If you are forced to set the subband prior to making the join, why do you think LoRaWAN implements the channel mask message for regions US915 and AU915?

[gonzabrusco]

And finally, the official LoRaWAN Regional Parameters document explicitly requires this behavior.

[StevenCellist]

With its current implementation, RadioLib isn't getting an official certification for these channelplans. So from that perspective, you could just as well consider that it isn't implemented. Please be very cautious if you want to make a real product for these channelplans - feel free to contribute by proposing a modification that tackles this problem.

[gonzabrusco]

Thanks!

[HeadBoffin]

Not quite sure why you expect a voluntary project to be fully compliant for edge cases.

[gonzabrusco]

Hey, take it easy. I was just making a suggestion and asking whether that behavior is supported by RadioLib. I'm not demanding anything, just trying to understand the options for devices that need to be subband-agnostic out of the box.

Have a nice day!

[HeadBoffin]

Erm, screen shot of the spec plus "And finally, the official LoRaWAN Regional Parameters document explicitly requires this behavior." sort of hints to an expectation, but as above, it's all about if you are reading in your first language and/or understand the culture of a country.

[HeadBoffin]

it's critical that the device can work out-of-the-box with any gateway deployment without requiring prior knowledge of which subband is in use.

I guess you must drive a petrol/diesel/electric with regenerative breaking with a hydrogen fuel cell to cover all eventualities.*

About the only time I'd think it may be critical is if I were selling devices to consumers. Which with LW would be a deep dark well of despair that even Dante didn't think of. Pretty much every device comes pre-configured to a common environment for the region but can be re-configured via serial port or BLE.

All that said, even I could change the code to scan all the channels if I had the time, so if you want to submit a PR ...

OR you could use LoRaMac-node OR you could use SWL2001 - both of which have many codez to implement various schemes of defaults vs practical reality.

• Plus coal, wood and pedals ...