How to implement custom PAN ID for Zigbee in STM32WB55 MCU?

[Phang]

Hi, 

Our product uses 2 x STM32WB55 MCUs, where one as Server/Coordinator and the other one as Client/Router for Zigbee.  However, our customer prefer to use customized PAN ID or Extended PAN ID so that more controllable and traceable by their application software later. Below is the setup of the Server/Coordinator and Client/Router in my firmware (modify based on sample code "Zigbee_OnOff_Server_Coord & Zigbee_OnOff_Client_Router").

** Server/Coordinator :

startupControl = ZbStartTypeForm;

config.panId = 0x0001;  // range from 0x0001 to 0xfffe

config.extendedPanId = 0x00001; // incremental from 0x01 onwards

** Client/Router:

startupControl = ZbStartTypeRejoin;

config.panId = 0x0001;  // range from 0x0001 to 0xfffe

config.extendedPanId = 0x00001; // incremental from 0x01 onwards

Questions:

1. May I know the configuration above is enough and valid to do so?

2. What are the steps needed or I missed out in order to use customized PAN ID or extended PAN ID or even the short address if question 1 above is not valid and enough?

3. How to bypass the default auto PAN ID or extended PAN ID assignment by wireless stack? 

4. Do I need to rebind my client/router with the server/coord after changing the PAN ID on client/router to match server/coord's PAN ID?

5. Under what circumstances we need to do binding? during pairing?  and only once will do?

Thanks.

[Phang]

Added from my previous post above, I have implemented persistent data NVM in both Serve/Coord and Client/Router and it is working well with auto PAN ID but unfortunately not with my custom PAN ID especially after unplug/plug back the server/coord device from USB port.

[Ouadi]

Hi @Phang,

Thanks for contacting us through the support community channel, please find the answers to your questions :

1. In principle, the configuration seems correct to me, on the Coordinator side, the device forms the Zigbee network using the configured PAN ID and EPID provided at startup. These parameters define the network identity at formation time. On the Router side, the joining device does not create the network parameters itself; instead, it uses the configured PAN ID / EPID as network selection criteria to discover and join only the network matching those identifiers
2. In practice, PAN ID and especially Extended PAN ID are sufficient to define a customized Zigbee network identity. The 16-bit short address is not a network formation parameter and is not used to identify the network during the form/join procedure. It is dynamically allocated by the network during association, so there is typically no need, and generally no mechanism, to fix it manually for this purpose.
3. The previous config allow to bypass the auto setting of pan ID
4. 5. Regarding binding, it creates a persistent association between a source endpoint/cluster and a destination endpoint/cluster or group address, allowing application-layer messages to be delivered without requiring explicit destination addressing for each transmission.

Best regards,

Ouadi

[Phang]

Hi Ouadi,

Thanks for the reply. The reason I asked these questions because our customer's existing product requires user to set 4/5 bytes server/coord ID onto the client device once in order to allow to join/form the network. So, they wanted this feature in their new product design for Zigbee as well so that they can control, trace and monitor connected devices.

Other than using the PANID and/or Ext PANID method, any other way can be used instead? This is because I ever seen the custom PANID and Ext PANID set inside the server/coord's persistent data NVM get changed but still able to receive data from clients. 

[Ouadi]

Hi Phang,

If I understand the concern correctly, the customer is looking for a user-configurable identifier to be provisioned from the coordinator side for each joining device, so that the application can later use this identifier for control, traceability, and monitoring, correct?

For such a use case, the most appropriate identifier is the device’s IEEE address. This is a 64-bit globally unique address that is stable and well suited for:

• uniquely identifying the coordinator
• uniquely identifying each router or end device
• storing trusted device identity in the application database
• validating or authorizing a joined device
• ensuring long-term traceability independently of the dynamically assigned short address

At startup, the joining device can provide its own extended IEEE address through the Zigbee initialization flow, e.g: ZbInit(). This address can then be provisioned or registered on the coordinator side, allowing the coordinator application to use it for filtering, validation, and traceability.

I hope this answers the question.

Regards,

Ouadi

[Phang]

Hi Ouadi,

Yes, your understanding is correct. So, do you have sample code for using extended IEEE address or what should I start for coord and router? Can you provide in more details info /step?

Thanks.

[Ouadi · Accepted solution]

Hi @Phang,

Please find a snippet code below showing how to fix the Extended address for a Zigbee device : 

/* Fixed 64-bit IEEE address - must be unique for each device */
static const uint64_t g_ieee_addr = 0x00124B000025AA11ULL;

void APP_ZIGBEE_Init(void)
{
    struct ZbInitT *zb_init;
    zb_init = ZbInit(g_ieee_addr, NULL, NULL);
    if (zb_init == NULL) {
        APP_DBG("ZbInit failed\r\n");
        return;
    }

    APP_DBG("Zigbee stack initialized with fixed IEEE address: 0x%016llX\r\n",
            (unsigned long long)g_ieee_addr);
}

Regards,

Ouadi