Multiple JOIN

[brunoS]

Join several LORAWAN network.

To ensure optimal communication, I would like the LOPY module successively join two LoraWan networks (TTN and Objenious) and send the same message on both.
I managed by reinstantiating the LoRa object with 2 authentication tuples:

lora = LoRa (mode = LoRa.LORAWAN, device_class = LoRa.CLASS_C, adr = True)
lora.join (activation = LoRa.OTAA, auth = (app_eui_T, app_key_T), timeout = 20000, dr = 0)
     if lora.has_joined ():
            ---> send TTN message
lora = LoRa (mode = LoRa.LORAWAN, device_class = LoRa.CLASS_C, adr = True)
lora.join (activation = LoRa.OTAA, auth = (app_eui_O, app_key_O), timeout = 20000, dr = 0)
     if lora.has_joined ():
          ---> send message OBJENIOUS

It works, but with each sends the UPLINK's counter is reset

Is it possible to manage and memorize several JOIN and counter with lora.nvram_save() and lora.nvram_restore() ?

Thank you

[brunoS]

@brunos !
With s.setblocking (True) before s.send(), it's OK !!

[brunoS]

@jmarcelino

Thank you for the advice I will follow.
I'm trying to use the lora.nvram_save () and lora.nvram_restore () with deepsleep() but without success.
Here is a snippet of my code:

lora = LoRa (mode = LoRa.LORAWAN, device_class = LoRa.CLASS_A, adr = False)
lora.nvram_restore ()
if lora.has_joined () == False:
    lora.join (activation = LoRa.OTAA, auth = (app_eui, app_key), timeout = 0, dr = 0)
    while not lora.has_joined ():
           time.sleep (2.5)
           print ('Not yet joined ...')

s = socket.socket (socket.AF_LORA, socket.SOCK_RAW)
s.setblocking (False)
s.send (message.encode ())

lora.nvram_save ()
machine.deepsleep (10000)

lora.join () is only done once, so there is backup and restore of the OTTA context, but the UPLINK counter remains stuck at 1. I tested with TTN and Objenious.

What am I doing wrong?

Thanks

[jmarcelino]

@brunos
Since TTN is really just a backup and it looks like the data isn't too safety/ critical, I'd suggest keeping Objenious as your OTAA network (which you use with nvram_save and _restore) and then rejoin as ABP to send to TTN (but then don't save)

When you're done sending to TTN, do a nvram_restore to get back to Objenious.

In TTN settings for the node disable "Frame Counter Checks" so you don't need to care about storing the frame counters - if I understand correctly other people being able to replay your data isn't a big issue here.

This should save a lot of headaches with doing repeated re-joins.

[brunoS]

Thank you for all your answers.
I bring a few details:
I am designing a LoraWan-based GPS tracker (class A unlike the code) (lopy + pytrack) for a strotospheric balloon.
The main Lorawan network is Objenious (only OTAA) but this one does not have a 100% coverage!
So I want to implement a redundancy to also send the UPLINKs to a TTN mobile gateway to locate the balloon fallout if Objenious does not cover the landing zone.

So I plan to periodically sleep the embedded system and wake up joining each Lorawan network to send the position through each one.

[jmarcelino]

@eric24
Sending essentially duplicate packets is neither efficient - you're using twice the airtime and power for every message - nor secure since it becomes easier to guess the information.

Also @brunoS's example shows the LoPy configured as Class C, but it's not possible to support two networks' RX parameters simultaneously (just imagine the networks use different downlink frequencies - or a different spreading factor from the "standard" as TTN does - what would the node do?)

That's why I feel passive roaming is the correct approach.

[Eric24]

@jmarcelino I'm actually not thinking about roaming at all (nor do I think @brunoS is either). Unless I'm missing @brunoS intent, he is not trying to "keep from sending the same message twice". He wants to do this, to ensure that at least one message is received by at least one of the networks.

[jmarcelino]

@eric24
With passive roaming both networks would receive the same one message - it doesn't matter if the networks are physically overlapping or not. The serving network can receive the message from its own connected gateways and also forwarded from the "roaming" network.

The advantage is you don't need to send the same message twice or register the node (and your application) with the (potentially many) "visiting" networks.

You may be thinking of handover roaming which is very different.

[Eric24]

@jmarcelino Right, but I don't think that's the same thing. From my understanding of @brunoS objective, he wants to actively send the same message to two different physically-overlapping networks (not have one message forwarded from one network to another). The kind of redundancy you're talking about is that one network doesn't happen to receive a message, but forwards it to the device's "home network". The kind of redundancy I think @brunoS is talking about is actually sending out two messages, each being (potentially) received by a separate network.

[jmarcelino]

@eric24
Using Passive Roaming the serving (original) Network Server can accept roaming from multiple networks for the same node, effectively providing redundancy (say if TTN has a passive roaming agreement with Objenius and the node only has Objenius coverage TTN would still get the data, just forwarded from Objenius)

The type of roaming is now standardised by the LoRa Alliance (LoRaWAN Backend Interfaces 1.0 Specification) and works for both ABP and OTAA as long as the network support it. It happens automatically without changes to the node, the packets are forwarded based on the NetID.

[Eric24]

@jmarcelino - I don't think roaming solves this. @brunoS question is about redundancy, I think, not just the ability to move between networks. I think it's a potentially useful application.

[bmarkus]

You can register your device in multiple networks with ABP. Unacknowledged uplink and downlink will work fine with fixed Data Rate.

It is called 'Passive Roaming'.

[jmarcelino]

@brunos

It's not currently possible no, and probably not necessary or efficient since many LoRaWAN networks will support roaming soon.