ZigBee radio channel change

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

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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

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

Children
  • Hi Marte,

    were left behind some routers (not all) and sleepy end devices connected to those routers.

    Thank you for the screenshot, regarding NIB table, I see that, for instance, extended_pan_id contains the expected value, same for router_child_num and ed_child_num whose value is automatically updated when devices join the network.

    nwk_manager_addr instead is automatically set to 0xFFFF and I'd like to know if by changing it into deafult value (0x0000) has any effect. In particular, I'd like to set it before calling zboss_start_no_autostart() and I'd like to know if the bit in the screenshot you sent is automatically set.

    To give you some context, we call ZB_INIT() first, then we call functions to initialize nwk parameters like zb_set_network_coordinator_role and zb_set_extended_pan_id and functions to register device context (ZB_AF_REGISTER_DEVICE_CTX) and to register ep callbacks. In the end, we call zboss_start_no_autostart and we enter in while loop containing zboss_main_loop_iteration

    Thank you,

    Laura

  • Marte can you please tell us about the effect of changing nwk_manager_addr to 0x0000? Doing like that we will have network manager running in ZBOSS stack?

    Do we have any setting to enable disable network manager?

    Can you also reply to all the other Laura's questions?

    Best

    Giacomo

  • Hi

    GiacomoPaci said:
    can you please tell us about the effect of changing nwk_manager_addr to 0x0000?
    Laura M said:
    nwk_manager_addr instead is automatically set to 0xFFFF and I'd like to know if by changing it into deafult value (0x0000) has any effect. In particular,

    In theory, the Network Manager address should be set automatically and changing this manually without receiving Zigbee commands to change it might have unexpected consequences. However, since it does not seem like the address is set correctly in the first place you can try setting it to 0x0000 and see if it affects anything.

    GiacomoPaci said:
    Doing like that we will have network manager running in ZBOSS stack?

    No. Devices do not enable/disable network manager support based on the contents of the nwkManagerAddr field of NIB. This field is used for devices to know what the address of the network manager is.

    GiacomoPaci said:
    Do we have any setting to enable disable network manager?

    I am not aware of any API available in the application for disabling this, and I was not able to find it when looking. Is there a particular reason for why you want to disable it?

    Laura M said:
    I'd like to know if the bit in the screenshot you sent is automatically set.

    Yes. My screenshot was from me testing with the Zigbee Shell sample in nRF Connect SDK. I did not make any changes to the sample and configured it as a coordinator using shell commands, so the bit was set automatically.

    Have you been able to collect logs from your tests?

    Best regards,
    Marte

  • Hello Marte,

    yes these are the logs (file name contains encryption key): Nordic automatically sends nwk update req(pkt 49969, key 8D 80 4F 1B 40 13 3D D9 F3 E3 4B 2F 69 BD 0A B8).pcapng

    This was a stress test with:

    • Coordinator running our application with nRF5 SDK for Thread and Zigbee v4.1.0 and initially in channel 22. Channel mask enabling all Zigbee channel.

    • Nordic nRF52840 DK with radio test FW from Nordic: nRF5 SDK v17.1.0: Radio Test Example
      I started TX sweep with following configurations:

      • Radio mode: Ieee802154_250Kbit

      • Radio TX power: 8 dBm

      • Start Channel: 22

      • End Channel: 23

      • Time on each channel: 99 ms

    • 5 routers joined to the network. They sometimes send Mgmt_NWK_Update_notify to notify about the state of each Zigbee channel.

    Result: After many packet transmissions and after power cycling both coordinator and routers, the coordinator sent a command to move from current channel (22) to channel 24

    I don't know if power cycling was needed, I did it to try to speed up the test which anyway took time.

    In the logs you can see that all routers received the command to move to the new network and executed it. Unfortunately there are other routers that we integrate that do not support the nwk update req for a new channel and they wouldn't be reachable any more if coordinator changes channel.

    Is there a way to disable this feature? I do not want to set the channel mask enabling only one channel but I'd like to leave the coordinator choose the best channel at the beginning, when it is installed, and keep that one. In this way I expect that in an installation with many coordinators, they will be in different channels.

    Thank you

    Laura

  • Hi Laura,

    The coordinator receives Mgmt_NWK_Update_notify commands from one of the devices (0x9970), with information about the energy levels of the different channels. The results of the energy scan shows that channel 24 has the lowest energy level, i.e. the least amount of noise. I also see the same device sending several route failures to the coordinator, but this could also be when you power cycled the device.

    It seems like the Mgmt_NWK_Update_notify caused the coordinator to initiate channel change since the energy levels reported matches with the channel, and I see that the device sent the command before the coordinator sent Mgmt_NWK_Update_req to inform devices of the channel change.

    You can disable processing of Mgmt_NWK_Update_notify command by calling zb_zdo_disable_network_mgmt_channel_update().
    The device will still process Mgmt_NWK_Update_req commands as according to the specification.

    Best regards,
    Marte

Related