Hi,

In a Zigbee PRO network how does a coordinator rebuild it's network after it has been reset but the routers and end devices haven't?

Cheers, Steve.

Do you use the ZDOInitDevice function in order to start a device (i.e. coordinator) in network?

If you do, then before issuing that function, you should restore the network paramters (i.e. PAN ID) that were belong to the Coordinator before it was reset.

After the network is started, the coordinator pretty much just becomes a simple router. So if the coordinator is reset after the network is started, it shouldn't have much impact unless the coordinator is also performing some type of special function, ie: security trust center. There shouldn't be any need to rebuild the network. That was only true with Zigbee Residential which had tree routing and the coordinator was at the bottom of the tree.

Hey Akiba.

I agree with you.

Notice that if the Coordinator should still be able to communicate with other Routers after it was reset, it needs to restore its network parameters, isnt it?

By the way, are there any other network parameters besides PAN ID that the Coordinator needs to restore after reset?

Mostly, you just need to restore the same parameters that a router requires like the network address, PAN ID, etc. I'll have to do testing on that to see what the real-life implications are though. There's always things you can't predict just from the spec.

But what if the co-ordinator restarts on a new channel?

Its reasonable for it to do an energy scan, find a new clean channel and use it.

Yeah, coordinators get kind of weird. If it were a router, then it could just scan for a certain PAN ID and join the network that way. But if you want to keep it as a coordinator, then it can't join anybody because its basically the head of the network, although its essentially meaningless in the case of Zigbee Pro. You might need some special software to handle a coordinator restart by looking for a channel whose members respond with a certain PAN ID when you send out a beacon request. Otherwise, you can force the coordinator to go on to a certain channel by limiting the channel list, but since the coordinator may possibly be the network manager (in charge of changing channels if one gets too noisy), this might not be a good thing.

The co-ordinator is by default the Network Manager.

Limiting the channel list will work but doesn't help when there's interference.

The spec is vague about this scenario though, there's an Annex E which discusses "OPERATION OF NETWORK MANAGER AS NETWORK CHANNEL MANAGER FOR INTERFERENCE REPORTING AND RESOLUTION". It effectively leaves the mechanism in the hands of the implementer.

The suggestion is that the Network Manager detects problems on the channel and gathers interference reports from other routers. Then it can switch to a new channel.

The critical part of this is that the co-ordinator must broadcast a Mgmt_NWK_Update_req notification to tell routers that the channel is changing. But if the co-ordinator lost power, restarted and reformed the network on a new channel, there's a problem. The notification won't be sent.

My feeling is that it should detect an existing network/PAN and then:
a) rejoin that same network if the channels are restricted or there's no need to change it
Or
b) broadcast notification on the old channel that a change is about to happen and follow the process to change channels (involves timeouts, etc).

Just wondering if you've given this any thought in your implementation?

Actually, the coordinator is not necessarily the network manager since any device can be appointed this function. You do bring up a good point though which is that the coordinator will run into problems if it needs to be restarted. The main issue is that since it can't just associate with another device, it will need to be started on the correct channel.

The situation you're talking about where it forms a network on some other channel is actually possible for any router since they can also be coordinators.

As usual with the Zigbee spec, they spell out the general behavior but the details are usually left in the hands of the implementor. Its pretty much the case with most specs actually which is why interoperability is always such a headache.

As for your suggestions, I think (a) is probably the best one to go with. Once the coordinator is restarted, then if its also the network manager, it should notice if the channel is noisy and just execute the standard frequency hop handshake. One other thing which is simpler than limiting the channel list is to just store the current channel and PAN ID in nonvolatile memory. If an outage occurs, then the device will be able to come up where it left off.

I haven't had a chance to work on my stack in quite a while now. This building out of hardware for a general WSN platform is actually quite difficult. I should be getting back to dev later on, and will also be trying to help out on 6LoWPAN/6LoWAPP which is increasingly appealing.