Connecting a Zigbee router to a network with a specific PAN ID

[Dmitro Balo]

NRF52840DK
NCS 2.8.0

Hello,
We are developing an application where a device with router function must join a coordinator network. The coordinator uses OOB (proprietary IR) to transmit the parameters of the network it forms to the router (PAN Id, Extended PAN Id, Channel). The router should not join networks whose PAN Id differs from the one transmitted from the coordinator.
To test this behavior, we use the Zigbee shell example, on two NRF52840DK boards, using the following commands:

Router board:

uart:~$ bdb role zr
Router role set
Done
uart:~$ bdb panid 0x57ca
Done
uart:~$ bdb start
Started router
Done
[00:03:53.518,218] <inf> zigbee_app_utils: Production configuration is not present or invalid (status: -1)
[00:03:53.518,676] <inf> zigbee_app_utils: Zigbee stack initialized
[00:03:53.524,139] <inf> zigbee_app_utils: Device started for the first time
[00:03:53.524,139] <inf> zigbee_app_utils: Start network steering
[00:03:53.524,169] <inf> zigbee_app_utils: Started network rejoin procedure.
[00:03:56.292,907] <inf> zigbee_app_utils: Unimplemented signal (signal: 54, status: 0)
[00:03:57.324,737] <inf> zigbee_app_utils: Unimplemented signal (signal: 54, status: 0)
[00:03:57.327,362] <inf> zigbee_app_utils: Joined network successfully (Extended PAN ID: f4ce3694d85533d8, PAN ID: 0x57cc)
[00:03:57.327,392] <inf> zigbee_app_utils: Network rejoin procedure stopped.
uart:~$

Coordinator board:

uart:~$ bdb role zc
Zigbee shell does not erase the NVRAM between reboots, but is not aware of the previously configured role.
Remember to set the coordinator role after rebooting the device.
Coordinator set
Done
uart:~$ bdb start
Started coordinator
Done
[00:02:12.252,075] <inf> zigbee_app_utils: Production configuration is not present or invalid (status: -1)
[00:02:12.252,563] <inf> zigbee_app_utils: Zigbee stack initialized
[00:02:12.258,056] <inf> zigbee_app_utils: Device started for the first time
[00:02:12.258,087] <inf> zigbee_app_utils: Start network formation
[00:02:12.810,516] <inf> zigbee_app_utils: Unimplemented signal (signal: 54, status: 0)
[00:02:12.812,622] <inf> zigbee_app_utils: Network formed successfully, start network steering (Extended PA N ID: f4ce3694d85533d8, PAN ID: 0x57cc)
[00:02:13.269,042] <inf> zigbee_app_utils: Unimplemented signal (signal: 54, status: 0)
[00:02:13.271,697] <inf> zigbee_app_utils: Joined network successfully (Extended PAN ID: f4ce3694d85533d8, PAN ID: 0x57cc)
[00:03:19.457,763] <inf> zigbee_app_utils: Device update received (short: 0xe3f3, long: f4ce36dec1d2db97, s tatus: 1)
[00:03:19.709,777] <inf> zigbee_app_utils: New device commissioned or rejoined (short: 0xe3f3)
[00:03:20.664,642] <inf> zigbee_app_utils: Device authorization event received (short: 0xe3f3, long: f4ce36 dec1d2db97, authorization type: 1, authorization status: 0)
[00:03:20.769,897] <inf> zigbee_app_utils: Unimplemented signal (signal: 54, status: 0)

Despite the fact that the PAN Id for the router is set different from that generated a coordinator (0x57ca vs 0x57cc), the router still successfully connected to the network. How can I make sure that the router connects only to a specific network with a specific PAN Id?

[Maria Gilje]

Hello,

I have forwarded your question internally and I'll get back to you when I get a reply.

In the mean time, I will also share some initial thoughts:

Using PAN ID as a criteria for finding a network suitable in the network steering procedure will require some changes on the appliation level. See Chs. 8.1 and 8.2 in the Zigbee PRO Base Device Behavior Specification, v3.0.1.

Transmitting network data OOB seems similar to the touchlink commissioning procedure. Have you looked into that method? See Chs. 8.6 and 8.7 in the Zigbee PRO Base Device Behavior Specification, v3.0.1.

Best regards,

Maria

[Dmitro Balo]

Thank you for your reply, Maria

We studied touchlink a little, and it really serves similar purposes as our OOB, but unfortunately our coordinator is a finished device with closed source code and it does not support touchlink.

If we cannot use PAN ID to specify a specific network to connect to, perhaps we could use Extended PAN ID for this purpose? This is acceptable for our task.

In a similar way, using shell example, we tried to set Extended PAN Id with the bdb extpanid command, but we also did not get the required router behavior, it also connects to all networks. Also, after set bdb extpanid, the command to get the current extpanid always returns 00000000000000000, i.e. it is not actually used. If the bdb level prevents us from achieving the required behavior, perhaps we could use lower stack levels or disable bdb?

[Maria Gilje]

Thank you for sharing your results. Our experts are on this, and I'll check back in by end of Tuesday next week.

Best regards,

Maria

[Marte Myrvold]

Hi,

Maria is out of the office today, so I am handling this ticket until she returns.

According to the developers, this functionality is not available in our current ZBOSS solution. If this feature is critical, I recommend contacting your local sales representative from Nordic Semiconductor.

Best regards,
Marte

[Dmitro Balo]

Thanks for your help, I would like to ask a few additional questions.

According to the Base Device Behavior Specification, Chs. 8.3,  Network steering procedure for a node not on a network:

"The node SHALL determine whether any suitable networks with a permit joining flag set to TRUE were found by analyzing the NetworkCount and NetworkDescriptor parameters. The decision regarding what constitutes a suitable network is application specific".

The application layer should be able to decide whether the network is suitable or not, do I understand correctly that the current Zigbee stack in the NRF Connect SDK does not comply with this chapter?

We are also considering the possibility of sending NLME-JOIN.request with the specified network parameters (ExtendedPANId) to the coordinator without performing the network discovery procedure, since our OOB already reports all the necessary parameters for joining, this feature is also not available?

[Maria Gilje]

Hello,

Dmitro Balo said:

"The node SHALL determine whether any suitable networks with a permit joining flag set to TRUE were found by analyzing the NetworkCount and NetworkDescriptor parameters. The decision regarding what constitutes a suitable network is application specific".

The application layer should be able to decide whether the network is suitable or not, do I understand correctly that the current Zigbee stack in the NRF Connect SDK does not comply with this chapter?

"Application specific" refers to the application itself, not the application layer.

Dmitro Balo said:

We are also considering the possibility of sending NLME-JOIN.request with the specified network parameters (ExtendedPANId) to the coordinator without performing the network discovery procedure, since our OOB already reports all the necessary parameters for joining, this feature is also not available?

I'll investigate some more on this as I don't have the full picture at the moment.

Just a heads up: there is a national holiday here in Norway tomorrow, so I may not be able to get back to you until Monday.

Best regards,

Maria

[Maria Gilje]

 Hello,

Thank you for your patience.

Our internal discussions has led to some possible solutions for you, but note that the ways that are supported with nRF Connect SDK v2.8.0 are not able to select a suitable network based on PAN ID (or extended PAN ID).

Here are the suggested options.

1. Use Install Codes (IC). This is most compliant with specification and provides the behaviour you want. However, it involves adding the IC to the coordinator.
2. Using production config. You can create a production config for ZR to pre-commission it and completely skip the joining procedure. But you will also need to bypass a TCLK key exchange on ZC and provide the related key to ZC.
3. Upgrade your ZR to use the Zigbee R23 add-on. It implements an API for pre-installed network parameters.
   

Best regards,

Maria