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 Laura,

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 ?

Yes, the coordinator will be the network manager. 

When a high value of transmit failures is detected, is channel scan done? Is channel changed?

This is correct. Both routers and coordinators will track transmit failures. If the number of transmit failures is too high, then the coordinator will perform energy scans on the different channels. The network manager (coordinator) can then decide to change channel.

Do you manage the reception of Mgmt_NWK_Update_notify? Which actions are performed?

This is handled internally by the stack. I am not sure exactly which actions the network manager performs in the ZBOSS stack, since there are no strict specifications on how a network manager must handle this, but I will ask the development team.

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?

All of this is handled internally by the stack, and there is no signal sent to the signal handler about this. However, you can manually send a Mgmt_NWK_Update_req with zb_zdo_mgmt_nwk_update_req(). If you set ScanDuration to 0xfe then the Mgmt_NWK_Update_req will be a request to change channel.

Best regards,

Marte

[Laura M]

Hello Marte,

thank you for the reply.

Regarding  zb_zdo_mgmt_nwk_update_req function, is it enough to call it in order to notify devices about the channel change and also to change channel? Take into account that I'm developing a Zigbee coordinator device.

If that function isn't enough, is there another function to change channel? I've tried to use nrf_802154_channel_set function but channel didn't change, as I could see from a radio sniffer. Please consider that I'm trying to change channel at run time.

Best regards

Laura

[Marte Myrvold]

Hi Laura,

Thank you for sharing the code you used for testing this. I was able to reproduce it in nRF Connect SDK v2.5.0 as well. I have reported it to the developers and they are looking into it.

Best regards,
Marte

[tcruse]

Hi Marte,

Thanks for looking into this.
Has there been any follow up from the developers ?

Indeed, this issue we face is pretty serious. If the Boss stack on its own is deciding to change channels, without application level intervention, whilst not controlling / verifying that the already connected devices on the mesh will follow the channel change, we have a very unstable connection.
This is a problem.

All the tests done by Laura and team to date, have pointed to the fact that the stack is indeed choosing to change the channel, and consequently leaving some devices behind, lost on the previous channels, with no way for those to reconnect successfully.

Would appreciate your support on this.

Could we organise a call with your developers and team, ASAP so we can get to the bottom of this ?

Thanks

Tim

[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

[Marte Myrvold]

Hi Giacomo and Tim,

GiacomoPaci said:

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

I have asked about this internally to verify.

tcruse said:

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

That is my understanding as well, and DSR are aware of the issue. However, if they were to fix this in the ZBOSS stack this would not be available in the nRF5 SDK for Thread and Zigbee, since it is deprecated and will not be upgraded.

I have forwarded your concern about this.

I will receive the hot fix for the other issue today, so hopefully I will be able to test it and share it with you later today. Although this is not the only issue you are seeing, it will provide a way to force the device to change channel, which might help with investigating a workaround for the issue you are raising here as well, but I cannot guarantee anything.

In the meantime, do you see any trend when this automatic channel change happens? Does it only occur under certain conditions or at random? Do you see anything in the application log or a sniffer log that might be relevant?

Best regards,
Marte

[Laura M]

Hello Marte,

we saw the issue after power cycling Nordic but it also happened at runtime (I don't know if a reboot occurred in these cases).

It isn't easy to reproduce and I don't have any logs. We are aware about channel change because our application is checking current channel every 10 minutes and it's reporting it to upper layer.

Thank you

Laura

[Marte Myrvold]

Hi,

Here is the fix that allows you to change channel on the local device. Call zb_set_channel_locally() to change the channel. This should be called from the callback function of zb_zdo_mgmt_nwk_update_req().

zb_set_channel_locally.h

Best regards,
Marte