ZigBee radio channel change

[Laura M]

Hello,

We developed with nRF5240 using nRF5 SDK as zigbee coordinator and I have some questions about channel change mechanism:

1. By choosing 'coordinator' as network role at startup, is this automatically also the network channel manager as explained in Annex E of Zigbee specification https://zigbeealliance.org/wp-content/uploads/2019/11/docs-05-3474-21-0csg-zigbee-specification.pdf ?
2. When a high value of transmit failures is detected, is channel scan done? Is channel changed?
3. Do you manage the reception of Mgmt_NWK_Update_notify? Which actions are performed?
4. In Zigbee spec about transmit failures, there is written: "the network manager would report to the local application using Mgmt_NWK_Update_notify and the application can force a channel change using the Mgmt_NWK_Update_req.". Do you ever notify application about this through Zigbee signal handler or any callback? Do you implemented a function that I can use to send Mgmt_NWK_Update_req to force channel change?

I've read another question about the same topic:  https://devzone.nordicsemi.com/f/nordic-q-a/94366/zigbee-radio-channel-selection-and-change-during-run-time/398143 
But I couldn't find the answers.

Best regards.

Laura

[Marte Myrvold]

Hi Tim,

The problem has been reported to DSR, the providers of the ZBOSS stack, and they are currently looking into it. I will update you as soon as I have more information.

Best regards,
Marte

[GiacomoPaci]

Hi Marte,

Any news about the channel management issue?

We need to fix this in our application as soon as possible, do you have any suggestion to give to us as a work around?

Best regards

Giacomo

[Marte Myrvold]

Hi Giacomo,

There was a discussion with DSR yesterday.

• The feature that coordinator is automatically also the network channel manager that you refer to initially is described as "may be implemented" in the Zigbee specification, and is not mandatory. In the ZBOSS stack this is not implemented to be mandatory.
• The Zigbee R22 specification does not have the best procedure regarding channel change, which is why such problems as you have reported occur. In addition, if you force a channel change and it "completes" with success, i.e. notification is sent to all devices and the coordinator changes channel as well, there is no guarantee that all devices will receive the channel change request, so some of them could be missing after this operation. For example, as is stated in the Zigbee specification, sleepy end devices will not receive the network channel change.
• DSR are working on a workaround. There is a function internally in ZBOSS that can be called to make the local device change channel, but this is not available in the API. They are working on a fix to make a function with similar functionality that you can define in the application. This function should be called together with the call to zb_zdo_mgmt_nwk_update_req() which you are already using, preferably in the callback function provided by the zb_zdo_mgmt_nwk_update_req. When DSR provides this fix I will test that it works and share it with you if it does. Hopefully I will be able to share it today or tomorrow.
• Please note that with the workaround some devices could still be missing after a channel change due to not receiving the channel change notification.

Best regards,
Marte

[GiacomoPaci]

Hello Marte, good new!

In the meanwhile i have another question,

so if I have understood correctly ZBOSS has not the channel manager, then if it is like this we should not experience any channel change in our network with nordic as a coordinator.

However we experienced network channel change. Could be flash storage issue in the old nrf5 4.1.0? 

I saw there where flash fixies between nrf5 4.1.0 and nrf5 4.2.0.

I hope to read good news from you soon.

Best regards

Giacomo

[tcruse]

Hi Marte,

thanks for the feedback. Giacomo and the team will look into this.

I do however have a follow up question / concern here.

Our issue is that the stack is choosing to change channels without providing the application control over this. The consequence of this, is choosing to change channels and not controlling that devices on the mesh are actually changing the channel. Resulting in devices falling off the network.
Unless I'm mis-understanding ?

The above recommendations would allow us to control the channel switching but not prevent it, correct ?

Isn't the issue different ?

Thanks

Tim