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.

Orphan rejoin problem - Urgent help needed!

Other Parts Discussed in Thread: Z-STACK, CC2530

Hi,

On our devices we are using CC2530 chips, Z-Stack core version 2.6.0.2, ZigbeePRO profile with no security enabled. Test network consists of one ZB Coordinator, three ZB Routers and one ZB End Device. ZB Router devices are mains-powered and ZB End Device is battery-powered remote controller.

 

Problem description:

There are more than one Zigbee network available (e.g. networks A and B) and End Device was, before joined to current network (e.g. network A), previously joined to networks B. Network A operates at Zigbee channel 13 (0x0D) and network B is on channel 21 (0x15). All devices have default channel list set as: DEFAULT_CHANLIST=0x0061A000 (using only channels 13, 15, 16, 21, 22). End Device is joined to network A. Join permitted on both networks.


When End Device performs network rejoin (either because parent is out of range or ED restarts), it first attempts NWK_RESUME (Orphan Rejoin), which is regular rejoin process (as described in ZigBee Specification,Document 053474r17, chapter 3.6.1.4.3.1) provided for fast End-Device rejoin to new parent when device's current parent is out of range.

It is important here to know that ZB Routers do not delete their child list as long as they don't leave current network. ED broadcasts "Orphan Rejoin" request to all supported channels without any PAN ID information (all devices and all network on that channel receives that message) and any old ED's parent, which don't have to belong to ED's current network, may respond to that orphan rejoin request!

Sometimes, router from network B (probably once ED's old parent) responses to Orphan Rejoin request by sending Coordinator Realignment message to ED. This response for some reason corrupts rejoin process and ED cannot rejoin its regular network - it continues to send Orphan Notifications to that "false old" parent and that parent responds with Coordinator Realignment message. It even sends Rejoin Requests (with PAN id of network A) to channel 13. On channel 21 ED sends only beacon requests - no orphan nor regular rejoin requests. After ED reboot (power off/on) it successfully rejoins network B.

Ubiqa sniffer log: http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/158/0647.OrphanRejoinProblem.7z

OrphanRejoinProblem.7z
  • Hi Dejan,

    I understand your concern. What is your exact use case?
    It is not clear to me, but do you want your ED to be able to communicate on network A and B, or just A or B?

    Are you using NV_RESTORE? or Is your ED a mobile ED?

    LPRF Rocks the World

  • Hi LPRF,

    Thanks for the response.

    ED is mobile device - remote controller. NV_RESTORE option is used and it works fine.

    Regarding to a described test setup, ED should be able to communicate on network B only.

    The use case is, for example, if there are two networks in very close proximity - two neighbor rooms in house or hotel. If user, for some reason, wants to move ED from network A to network B, he must press reset button on ED. ED leaves network A and its parent (router) for some reason fails to receive ED's Leave request (currently offline). The network A is not informed about ED's leave and ED's MAC address is not removed from child lists within network A routers. ED performs reset (clears all stored network information from NV) and joins network B. The rest is described above...

  • Anyone?

    Any update?