What appears to be happening is that the network stack is sending a LinkADRReq that is setting a ch_mask with channels 0-7. These channels are supported in the gateway, however, only channels 0-3 are enabled by default on the device. Additional channels have not be added since there was no join procedure (not using OTAA) providing a CFList. As such the device end is ignoring the LinkADRReq and not applying any change of DR or TXP since it doesn’t like the ch_mask.
Since we are the OEM of the device hardware and software, we can modify the source code to ignore the channel IDs that are not yet added. Having said that, I’m not sure what is compliant behaviour in this context. Is the network stack permitted to enable these channels on a device in ABP mode if they haven’t been added? Would appreciate some thoughts on this.
In my understanding of LoRawan ABP，the diff between OTAA and abp,just 3 para diff,all mac cmd is same , otaa device after join succ is equal to abp device
Thanks for the response but it doesn’t really address my question. I know the mechanism can be made to work one way or another. I am just questioning the legitimacy of the network stack (ChirpStack) sending a LinkAdrReq with ch_mask containing entries which the end device has no knowledge of since they have not been setup prior in ABP mode.
EU868 with default enabled channels 0, 1 and 2 as per regional parameters in v1.0.3 of standard. I have also noted that if I disable the ch_mask error checking of the LinkADRReq handling in our code (i.e., to ignore ch_mask bits that have no frequency setup), then ADR settings take effect as one would expect. Moreover, eventually the network stack will also send NewChannel requests for channels 3-7, presumably as it recognises that only channels 0-2 are being used. So I’m leaning towards the network stack behaviour requiring some explanation in ABP mode.
ABP device shall implement NewChannelReq, NewChannelAns, DlChannelReq, DlChannelAns commands so additional channels can be added to device by Network Server. And ABP device must remember those additional channels during power-off. Seems like your device got all necessary information about channels 4-7 some time ago and lost it during power-off. As OEM you should modify software to satisfy LoRaWAN specification in this aspect.
This may be the case regarding loss of NVRAM on the end device in question.
I am curious because I thought I was observing the first-time communications between the network stack and this end device.
I’ll double check the behaviour by deleting the device from the registry and adding it again (which presumably would mean the network stack would have no history or state). Basically, I am trying to prove/disprove if the network stack is still sending ch_mask with 4-7 channels set before NewChannelReq in ABP mode.
Ok. I deleted the device, added it back again (in ABP mode) and re-activated it. Then I performed the initial transmission from my end device and a sequence of further transmissions. The following is taken from the frame logs for this device:
UnconfirmedDataUp: NewChannelAns[0]=all ok, NewChannelAns[1]=all ok
UnconfirmedDataDown: LinkADRReq with ch_mask bits[0:7]=true
I still don’t think this is correct behaviour from the network stack. Surely ch_mask bits should at least omit bits 4:5 since there is no corresponding NewChannelReq for idx=4,5 yet?
