CC2538: End device join network issue

You shouldn’t power on 400 nodes at the same time for joining. It’s too over for coordinator and I suggest you to add device one by one. Also, single ZC and ZR won’t be able to join 400 devices. The default max is 40.

Hi Albert,

A Zigbee network with 1 coordinator, 1 router, and 400 end devices is unrealistic for a robust Zigbee network. In general, a good rule to follow is you should have at least 1 routing device for every 15-20 end devices, and have the end devices and routers spread out in a topology such that each routing device has 15-20 direct end device children. Additionally, you should use Many-To-One Routing with Source Route Caching enabled on the ZC.

As for forming a network with 400 nodes, you should consider that network commissioning is one of the most network traffic heavy activities that a Zigbee device can do, so it is a good idea to stagger the joining of new devices in order to not overload the channel, and you also want to make sure that the parent ZC/ZR you are joining devices through is not overloaded by processing too many network join requests at once. It would be helpful to run a sniffer during the network formation procedure so you can more accurately determine why some devices are unable to join.

Z-Stack Home 1.2.2a has some configurations parameters that determine the size and stability of path finding in the network:

NWK_MAX_DEVICE_LIST (on each routing device, ZC or ZR)
- maximum number of devices in the association table (devices which have joined through this node)
- my recommendation would be to keep this number relatively low for each routing node, i.e. <25 devices

MAX_NEIGHBOR_ENTRIES (on each routing device, ZC or ZR)
- maximum number of devices in the neighbor table (ZR devices which did not join through this node but are within radio range, determined via Link Status messages)
- the larger this value is on each node, the more neighbors each device will remember, which will increase the robustness of path discovery. Default is 16.

MAX_RTG_SRC_ENTRIES (only on ZC)
- maximum number of devices in the source routing table, used for Many-To-One routing. if CONCENTRATOR_ROUTE_CACHE is enabled, discovered paths will be saved in definitely.
- you want this value set to the maximum number of nodes in the network, i.e. 400 or more. Coordinator will keep track of paths to each node by issuing MTO route request, then nodes can issue Route Record back to ZC with the path, which is then stored in the source routing table.

Hi Jason,

End device only communication with ZR, and after join network ZC almost without traffic, so don’t worry about routing traffic problem. In factor, We also try to use 1ZR + 400 end device’s ( one by one joining, not joining at the same time ) already, end device’s and ZR can communication for each other, and our default setting of MTO is enable, this suggestion does not help for fix this issue.

By the way, because We signed NDA with end customer, so can you offer your E-MALL address, and we can discuss on mail?

As Jason and I replied, 1 ZR and ZC for 400 nodes is unrealistic. What is your NWK_MAX_DEVICE_LIST define?

Hi,

I put in a request for internal support. Not sure I understand your follow up post, can you explain your statement a little more? Why does your use case require a 400 node network with only 1 ZC and 1 ZR? As mentioned in my previous post, though you may be able to get this topology to work in a controlled environment (e.g. a lab), it is not a realistic topology for a real-world Zigbee network. Zigbee networks rely on many routing devices to make sure that the mesh route discovery is robust.

Consider what would happen if you lost one or both parent routing devices due to power outage, etc. Many or all 400 end devices would go into the parent lost/orphan state, and then they would all need to rejoin at the same time, which is definitely not going to work due to heavy network traffic. If there are a sufficient number of routing devices in the network, losing a routing device isn't such a big deal, the direct children of that node will orphan and look for a new parent within radio range and then rejoin through that parent instead.

Hi JasonB ,

Thanks for your reply and support.

Base on our customer's specification , not only 1 ZC , 1 ZR. Network will have 1 ZC , many ZRs (Every 1 ZR to 400 ZEDs)

Do not worry about multi-hops traffic and ZED rejoin issue. Although we are not expert in ZStack , but we had sufficient realistic experiences to meet customer's requirement.

Let us focus in Question 2 =>  ZED hand up , it's really a big trouble for us.

Because of we have contract  with our customer, could you please provide contact window (e-mail). We can discuss with TI and my customer together.

 

Hi JasonB ,

I upload the sniffer log to below link :
www.dropbox.com/.../384_nodes.psd