In the device profile page, if I set the join type as ABP, I can set RXFreq2 and other params, but when I checked the OTAA type, the fields disappear.
Why?
I think OTAA devices should also support settings for these params.
I believe OTAA devices initially should use the standard settings / frequencies as defined by the LoRaWAN (Regional Parameters) specification.
To use a different frequency for the RX2 receive-window, update the loraserver.toml configuration and LoRa Server will send a mac-command to the device on the first downlink opportunity to update this setting 
Thank you for your reply.
I have checked with the specification again.
Yes, I agree with you that OTAA devices should initially use the default settings for RX2.
But updating loraserver.toml file is a server scope of modification, it affects all OTAA devices connected to the server.
How do you think about using the device profile to update RX2 settings for devices related to the device profile?
In my opinion the loraserver.toml configuration is the right place as I believe these settings should be in the domain of the network, not the end-user. When the owner of the network is not the same as the owner of the device (end-user), you would like to avoid that this end-user is able to use settings that impact your network in a negative way.
Sorry, I can’t understand that.
How would end-user settings impact the network in a negative way?
It only affects the devices that related to some specific device profiles.
And the end user could also use ABP devices to achieve the same effect.
The only difference is that OTAA devices need to send join request.
How would end-user settings impact the network in a negative way?
As radio settings have impact on the radio spectrum and gateway usage, which could affect other devices. Note that the user / company managing the network has more knowledge of the network than the end-user. E.g. in some cases a RX Delay > 1 second is needed to deal with latency between the network-server and the gateways. In my opinion it is better to manage this on a network-level instead of informing each end-user / updating each device to deal with this. An other example, in China some channels must not be used in certain regions:
In my opinion, this should not be managed by the end-user but by the network.
And the end user could also use ABP devices to achieve the same effect.
Initially yes, but LoRa Server will update the device (using mac-commands) to sync its settings as specified by loraserver.toml.
I see, thank you for your explanation.
But settings RX2 params in network server scope is too general, do you have any plan to support settings RX2 params by application scope in the network server?
No, this is currently not on my backlog.
OK, then I’ll have to modify something myself.
Thank you for your reply, this is an awesome project, good job!
1 Like