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

[Laura M]

Hello Marte,

thank you!

I tested the code you provided and I cloud see coordinator moving to new channel. Also, new channel is retained if coordinator is rebooted. 

Best,

Laura

[Marte Myrvold]

Hi Laura,

Great to hear that it works on your side as well!

Regarding the underlying issue of the device automatically changing channel we have not been able to reproduce this behavior on our side. Getting logs from when this issue occurs, both application logs from the device and sniffer logs, would be helpful in figuring out what might be causing the issue.

Best regards,
Marte

[Laura M]

Hello Marte,

as I said we don't have the logs you are asking unfortunately but I'll try to collect them.

To have a good setup for my test I need to better understand what is not implemented related to network manager.

I tried to read network manager address from NIB table by using ZB_NIB() and I saw that it is 0xFFFF in our network. Because of this, I'm afraid that maybe a third party router device sends a request to change channel.

If I set this address to 0 (coordinator address) when network is created, what happens? Are devices being notified about Nordic being the network manager when they join the network?

thank you,

Laura

[Marte Myrvold]

Hi Laura,

Laura M said:

I tried to read network manager address from NIB table by using ZB_NIB() and I saw that it is 0xFFFF in our network. Because of this, I'm afraid that maybe a third party router device sends a request to change channel.

0xFFFF is outside the supported address range (0x0000-0xFFF7), so it seems more likely that this value is incorrect. A sniffer log should show if a channel change request is sent on the network.

Laura M said:

If I set this address to 0 (coordinator address) when network is created, what happens? Are devices being notified about Nordic being the network manager when they join the network?

This could lead to unexpected behavior.

Devices should be informed of network manager support by the Network Manager server flag in the Node Descriptor, as in this picture:

One of your colleagues provided some more context about the issue over mail, and I have some questions based on that context to better understand the issue.

• Can you confirm whether all devices are left behind or if only some of them are?
• Are the devices left behind routers or end devices?
• If end devices, are they sleepy or non-sleepy end devices?

Best regards,
Marte