This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1352P: Beacon Req - Destination PAN

Part Number: CC1352P

I never thought of this before (Kim did :), but the 802.4.15 Beacon Request contains a Destination PAN field.  Since we are specifying the PAN for a joining FFD to use, should/could this field be set to that value?  Would that then cause only routers on that PAN to respond?  If this is true, that would greatly reduce traffic for an FFD looking to join a PAN when there are many PANs on that same channel.  It would also help us identify rouge devices.

- Bill

  • Hey Bill,

    I don't see why this won't work the way you described. When the FFDs receive beacons notifications, it checks to see if the PAN ID is 0xFFFF, if so the device can join any network, and associates with the first coordinator from which the beacon is received. Otherwise, it checks to see a match on that specific coordinator's panID, which is what you're looking for. (See jdllc.c snippet below)

    /* Check for beacon order match */
    if(checkBeaconOrder(pData->panDesc.superframeSpec) == true)
    {
      if(devInfoBlock.panID == JDLLC_INVALID_PAN)
      {
        /* Device can join any network , associate with
         * first coordinator from which beacon is received */
        devInfoBlock.panID = pData->panDesc.coordPanId;
        panIdMatch = true;
      }
      /* Check the incoming PAN ID to see if it's a valid coordinator */
      else if (devInfoBlock.panID == pData->panDesc.coordPanId)
      {
        panIdMatch = true;
      }
    //...

    Try setting a specific panID on both your FFDs and the coordinator (or router in this case) device and verify with the sniffer!

    If you have any issues please post follow up questions below.

  • In addition to Ammar's reply, the 15.4 spec mandates that the destination PANID be 0xFFFF for Beacon Requests.

  • Hi Ammar,

    We're actually using the zstack and not the ti154stack. We're also looking to change the destination PANID in the Beacon Request.  It looks like the BeaconReq is being built in ApiMac_mlmeScanReq(), which isn't available.

    Toby,

    I didn't see the mandate for the destination PANID to be 0xFFFF, but I guessed that that may be the case.

    Regardless, is there a place in the zstack where we could attempt to override this with a specific PANID as an experiment?  Or is it buried in some mac api too?

  • Bill,

    Per IEEE Std 802.15.4-2015:

    Changing this field would lead to undefined behavior for both the sender and any potential receiver, and thus the logic which sets this field is inside one of the MAC libraries.

  • I only have a copy of the -2003 spec which doesn't include this detail.  

    It was worth a shot.

    Thanks

    - Bill