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

[Laura M]

Hello,

I am writing again about this topic to have a clarification.

1. When you write "The network manager (coordinator) can then decide to change channel", who is responsible for changing channel? ZBOSS stack, Nordic stack, or user application?
2. How is the application notified about channel been changed, if channel change is managed by stack? Or how is it notified about a request to change channel, if the channel change needs to be managed by user application?

Best,

Laura

[Marte Myrvold]

Hi Laura,

Laura M said:

When you write "The network manager (coordinator) can then decide to change channel", who is responsible for changing channel? ZBOSS stack, Nordic stack, or user application?

This is done by the ZBOSS stack.

Laura M said:

How is the application notified about channel been changed, if channel change is managed by stack? Or how is it notified about a request to change channel, if the channel change needs to be managed by user application?

The application does not need to handle this, as it should be handled automatically by the ZBOSS stack. Thus, the application is not notified about the channel change.

Best regards,
Marte

[Laura M]

Hello Marte,

thank you for your answers. Related to this topic, I am not sure how to solve an issue I face: devices in our meshes falling off the network and requiring re-commissioning, because they never received the command to move to new channel.

I’ve been running the following tests to understand what is going on with ZBOSS stack:

1. Nordic as coordinator broadcasting Mgmt_NWK_Update_req to change channel.
   The request is sent through zb_zdo_mgmt_nwk_update_req function as you suggested.
   Result is Nordic remaining in previous channel while routers moving to new channel.
   I was expecting Nordic to change channel too.
2. Nordic as router sending to Nordic as coordinator Mgmt_NWK_Update_req to change channel. Nordic as router is running CLI example code from Nordic nRF5 SDK for Thread and Zigbee v4.1.0.
   Result is Nordic as coordinator changing channel without notifying routers within the network and Nordic as router not changing channel.
   I was expecting Nordic as coordinator not changing channel at all or changing channel notifying routers within the network.

I used Nordic nRF5 SDK for Thread and Zigbee v4.1.0 and then I repeated tests with v4.2.0 with same results.

I've also performed some tests with nrf_802154_channel_set but I saw that new channel isn't stored and when nordic reboots it moves to previous channel.

Can you please bring clarity on this topic and suggest improvements I can implement.

Thank you in advance.

Best regards,

Laura

[Marte Myrvold]

Hi Laura,

I will look into this issue and discuss it with the developers.

Just to make sure that I understand the problem correctly, are you manually calling zb_zdo_mgmt_nwk_update_req() on both coordinator and router to make it send a Mgmt_NWK_Update_req, or is the Mgmt_NWK_Update_req sent as a result of other factors such as for example a lot of noise on the network in any of the cases?

As for nrf_802154_channel_set(), this only sets the channel in the 802.15.4 radio driver without informing the ZBOSS stack, so as you experienced, the ZBOSS stack will make it use the previous channel on a reboot.

Best regards,
Marte

[Laura M]

Hello Marte,

I start working on channel selection because, more than once, we saw routers being in a channel and coordinator in a different channel. This without calling zb_zdo_mgmt_nwk_update_req().

We tried to implement coordinator manually sending Mgmt_NWK_Update_req through zb_zdo_mgmt_nwk_update_req() to solve the above issue without recommissioning the routers. The objective was also to investigate if routers in use are able to switch channel as per Zigbee specification, which they did.

This is the function I've implemented:

bool APP_ZigbeeChangeChannelReq(uint8_t channel)
{
  zb_bufid_t bufid;
  zb_zdo_mgmt_nwk_update_req_t *req;
  zb_uint8_t zb_ret;
  uint32_t channelMask = 1UL << channel;
  bool ret = false;

  if(channel < ZB_PAGE0_2_4_GHZ_CHANNEL_FROM || channel > ZB_PAGE0_2_4_GHZ_CHANNEL_TO)
  {
    CDB_PRINT(APP_ZB_DB_PRINT1, "channel 0x%02x\n", channel);
    DB_EXCEPTION(1);
    return true;
  }

  bufid = zb_buf_get_out();
  if (bufid == ZB_BUF_INVALID)
  {
    CDB_PRINT(APP_ZB_DB_PRINT2, "No Zigbee buffer available\r\n");
  }
  else
  {
    req = ZB_BUF_GET_PARAM(bufid, zb_zdo_mgmt_nwk_update_req_t);
    ZB_CHANNEL_PAGE_SET_PAGE(req->hdr.scan_channels, ZB_CHANNEL_LIST_PAGE0_IDX);
    ZB_CHANNEL_PAGE_SET_MASK(req->hdr.scan_channels, channelMask);
    req->hdr.scan_duration = ZB_ZDO_NEW_ACTIVE_CHANNEL;
    req->dst_addr = ZB_NWK_BROADCAST_ALL_DEVICES; //ZB_NWK_BROADCAST_RX_ON_WHEN_IDLE;
    CDB_PRINT(APP_ZB_DB_PRINT1, "channel 0x%02x, ScanChannels 0x%08x\n", channel, req->hdr.scan_channels);
    zb_ret = zb_zdo_mgmt_nwk_update_req(bufid, NULL); //no callback since no reply for this cmd

    if (zb_ret != ZB_ZDO_INVALID_TSN)
    {
      ret = true;
    }
    else
    {
      zb_buf_free(bufid);
    }
  }
  return ret;
}

[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