I’ve got a V2 device working with ABP, i’ve deleted from V2 console, then added to V3 console keeping the same DEVId, DEVADD, NWSKEY and APPSKEY, now on my gateway (still V2) i can see the traffic of the device, but on V3 console no data is displayed, what i’m doing wrong?
Let me explain why i’m using ABP instead of OTAA.
- save energy of joining proces.
- Not compiling OTAA saves source code.
- In my case devices are usually placed deep indoors, so i realized that there is the chance to setup the same device settings in TTN and EVERYNET… so i can receive data from my device in two different networks, that’s not posible with OTAA, and gives an “antenna diversity” that improves the chance of the device to communicate, and at the end my customers want “service”.
I understand the reasoning for choosing ABP. But my question is: Are you willing to accept that two LoRaWAN network servers talking back to your device? It could happen that the network servers are issuing conflicting commands to your end device that will disrupt the service that your customer expects. The architecture choice is not something to blame the network server for. If this was part of your risk assessment an you accept the risk it should be fine.
The classic one when servicing two networks (though perhaps not the case here) being both connections telling the node to change settings under ADR - with the poor node changing up and down the gears (SF & Tx pwr) based on which ADR command last seen…in worst case then the network with GW ‘closest’ in terms of best signal perhaps telling the node to go to SF7 (for example) and lower Tx power such that the other networks GW can no longer even hear the node and result is that ‘service’ failing totally! 
Thank you for the feedback, i don’t use ADR, so these MAC commands are not sent by NS, fortunately the RX1 delay on both networks are now different and Rx2 SF too ( 9 for TTN and 12 for Everynet ) so that makes posible to receive MAC commands from both, concerning ADR, my app server chooses best network case to send donwlinks, and the device with the received RSSI tunes the uplink SF and power. i think that it is possible to work that way, thus improving the chance to communicate.
1 Like
For ABP devices, apart from ResetInd, MAC state is reset on FCnt reset.
Since 3.11 we also have a Reset RPC (see ttn-lw-cli end-devices reset CLI command), which lets you reset an ABP device MAC state or forget OTAA device session in the Network Server.
@roman, I tried to reset the MAC but it has no effect.
I executed:
remko@DESKTOP-RLF1S9G:~/ttn-lw-stack$ ./ttn-lw-cli device reset geocaching gc-10 --mac-settings.resets-f-cnt
{
"ids": {
"device_id": "gc-10",
"application_ids": {
"application_id": "geocaching"
},
"dev_eui": "AF5EE00000009C03",
"dev_addr": "260B204B"
},
"created_at": "2021-02-18T13:27:47.737Z",
"updated_at": "2021-02-25T20:02:30.933256929Z",
"mac_settings": {
"resets_f_cnt": true
}
}
The frame counter was reset in console but the downlink for RX1 delay is still scheduled.
I still feel that it is not working.
Can I see ttn-lw-cli device get geocaching gc-10 --mac-settings.rx1-delay --mac-settings.desired-rx1-delay?
And what RX1 delay would you like to use on your device?
By default we use 5 - that requires a RxTimingSetupReq.
That’s actually not legitimate or workable, unless you’ve rigged things such that one of the networks is physically incapable of ever transmitting down to the node.
Otherwise, one will capture the downlink frame counter locking the other out, nevermind the confusion over MAC state.
Keep in mind that downlink support is mandatory with TTN V3, so if you’re going to try to feed two networks, then you must make sure the non-TTN network can never transmit.
fortunately the RX1 delay on both networks are now different and Rx2 SF too ( 9 for TTN and 12 for Everynet ) so that makes posible to receive MAC commands from both, concerning ADR, my app server chooses best network case to send donwlinks, and the device with the received RSSI tunes the uplink SF and power. i think that it is possible to work that way, thus improving the chance to communicate.
No, that is unworkable and should not even be attempted, as it will cause one or both networks to waste downlink capacity on housekeeping messages originated automatically and not by you.
TTN V3 makes it absolutely mandatory that your node support downlinks, and not be registered with anything else that has the capability to send them.
In simple terms, a LoRaWan network (be it TTN or something else) must have exclusive ownership of a node. The protocol simply will not work correctly otherwise.
As far as i know ( just few weeks with testing ), if i don’t setup ADR on Everynet , no downlink MAC commands are sent from , still haven’t been able to setup properly V3 ABP devices,… maybe too busy. The App downlinks are not a problem don’t you think so?
Of course i foresee the chance to have the same DevEui, AppKey registered on both networks, and try to join OTAA on both, an see what happens…
I think that commercial applications should have network server diversity, in my case, Spain, there is not country wide operator, and LORAWAN has strong competitors , let’s say NB-IOT, and the only way to compete with is to have the best network coverage as posible, being able to “roam” in different LORAWAN networks does make sense, i think that stacks should accommodate for this market need, and will thus leverage the use of LORAWAN.
They are most definitely a problem. LoRaWan tracks frame counters in both directions, so you can only have one network sending them, otherwise the downlink frame counter will get out of sequence.
TTN V3 sends downlinks, for its own housekeeping even if you do not request any. And it is mandatory that nodes support and honor those downlinks.
I think that commercial applications should have network server diversity
That’s your opinion, but the designers of LoRaWAN felt differently.
TTN is a LoRaWan network; it works according to the LoRaWAN spec.
And that spec is designed such that a node can only belong to ONE network.
If you want to register an ABP node on a different network, at minimum you’d have to first de-register it from TTN.
Of course i foresee the chance to have the same DevEui, AppKey registered on both networks, and try to join OTAA on both, an see what happens…
You’re not supposed to do that either; if both are in range, the join accepts would jam each other.
LoRaWan is not the only game in town; but it is the network type this forum is about.
Still don’t know , why APP server downlinks are a problem , my application server from the moment receives data from two network servers, it can choose which one to send downlinks. i won’t send application downlinks in both of them
No, it cannot.
Network servers send downlinks based on their own decisision, in addition to yours.
What you want to do is simply not allowed in LoRaWan, end of story
This are MAC downlinks, not APP downlinks, if one of the network servers don’t sent MAC downlinks, no problem, end of story
Still wrong.
At a protocol level, application and MAC downlinks have to share the same frame count series.
And as explained before, you cannot stop TTN V3 from sending its own housekeeping downlinks.
Registering a node on multiple LoRaWan networks is simply not allowed; you really need to read the protocol documentation before you try to tell those of us who actually have read it, how you think it works.
Maybe, in order to enable the network server diversity i’m looking for. there should be the chance to avoid these downlink MAC commands, this is my point of view, maybe i’m not a purist, because i’m trying to figure out how to improve the LORA coverage
There are plenty of alternate ideas (in fact I’ve implemented my own) but those are LoRaWan.
TTN is a LoRaWan network, and this is the TTN forum.
If you want to use TTN, you have to implement actual LoRaWan, not YouRaWan or even MyRaWan, no matter how much better those may be.
Yes, the only alternate nowadays for IOT commercial , and countrywide it is NB-IOT/LTE-CAT-M1
Not true; LoRaWan is only one of the ways of taking advantage of LoRa modulation; granted, it’s the only one which is on topic here.
Country wide, and deep indoor?, really ?