Class-A devices on multiple bands ~simultaneously

End Devices (Nodes)
1

Hey team,

I’m not sure where to ask general LoRaWAN protocol questions, but I’m connecting to TTN so I’ll start here.

Is a device that works across multiple bands effectively multiple devices as far as the network is concerned? e.g. it needs different network identities? I see this question about connecting to two different networks, but what I want to do is both better (single network) and worse (undefined behaviour?)

Background

I’m working on using the Lacuna basicmac stack for a TTN Mapper client implementation to cross multiple bands (specifically for .au, AU915/AS923, but there’s no reason to be constrained to those). .au uses both but the LoRaWAN standard doesn’t (not an expert) give me a lot of guidance on a device that can switch between them, I’m guessing because the whole original structure was that a country has one band plan so it didn’t need further consideration.

Under TTNv2 (at least) devices are not registered to be on a particular band plan.

Progress so far

I’ve got it running and flipping between bands between packets (post-RX listen periods). I’m resetting the stack every time, so forced to ABP-only, and frame counts reset to zero etc. This is … bad. I’m going to store/restore this stack state per band to avoid this.

Questions

  1. Do you see any issues with storing the state and restoring it? I’m only doing Class-A so the device disappearing from the band for (time period) shouldn’t be noticeable to the network.
  2. The MAC stack state (client and server) means, I think, that I should give my device two identities e.g. register it twice, with different keys? The gateways shouldn’t care, but the TTN server state will get messed up otherwise? It’s certainly the safer path but I’d rather not walk down it unless I have to.
  3. This code should have other (simpler) uses; I could build a device that tries to OTAA on alternate bands until it works and then continue using only that band - blending the TTN coverage, and simplifying deployment. The bands should be the ones legal to use in the country of course. A device could end up on a band with worse (but still workable) coverage, but I can’t see that this violates the standard, can you?
    2a. Would this use case need two different identities? I’d like to think it doesn’t.

Thanks,
Bruce

2

As the regional parameters do not only include frequencies but behavior (which channels are used to join, which frequencies are used for downlink etc) the only safe way to have a device using two sets of regional parameters is to use separate virtual devices. If you don’t you will end up with a confused device stack or a backend that does understand what is going on.
However, you will need to check the stack does reset everything required when switching to the different parameter set.

For 2 you should be good with one registration if you do not switch once the device is joined. (And of course you should not try to join using US regional parameters in EU and vice versa as in that case you would be using illegal frequencies)

1 Like
3

The network thinks an OTAA device is joined as soon as it generates a join accept; but a device doesn’t consider itself joined until it receives the join accept, eg, after the process survives several additional failure modes.

It might work, but I think it would be better to preserve distinct identity for each network in the OTAA case, too. And in that situation you probably can even be clever and allocation device euis that differ only in one bit, which would signify network.

Also keep in mind that you might get success on multiple networks but far better performance on one.

1 Like
4

Thanks @cslorabox and @kersing, that’s really helpful.

Will report back when I have something to show.

2 Likes