Someone on another forum who works in the sector posted this in the past few days:
Quote:
Bit of background information that may aid your understanding
- There is only one HAN network, controlled by the coordinator, this also stores most of the keys as you say. The HAN has to be opened for joining for the initial network commissioning. This joining window is only open for a short while (for security reasons), maybe 5 minutes, or an hour, or even 24 hours. If the joining window is not open no new devices can join the HAN.
- The keys are stored in non-volatile memory in each device, so if a device loses power it can “re-join” the network without the joining window being opened. However, if you reset a device, say restore to factory settings, then the keys are erased and the device can no longer join the HAN except by a repeat of the commissioning step.
- Generally, the ESME does not push data to the IHD, the IHD polls the ESME for the data it needs. Similarly for the GSME, but because the GSME is mostly asleep, the IHD has to poll the gas proxy on the CH.
- There is a keep-alive cluster in each device. The ESME polls the keep-alive in the CH to check that it is still there (so a heartbeat function) on a regular basis. If the ESME sees a number of consecutive fails of this heartbeat, it assumes the CH has failed/is being replaced, so it enters a TCSO (Trust Centre Swap Out) process. It scans all the Zigbee channels looking for the replacement CH. If it fails to find a new CH, then it goes back to look for the original CH.
- The HAN interface between CH and ESME is quite narrow, there are only a few Zigbee Clusters involved
- Time Cluster. The HANs sense of time
- Keep-Alive Cluster. As explained above
- OTA Cluster. For firmware upgrades
- Tunnel Cluster. This is a way for non-Zigbee protocol messages to be transported across a Zigbee network. Most of the CH<->ESME comms passes over this channel. The GBCS messages generated by Service Requests from the head end are sent this way. They are usually encrypted so that only the ESME and the source of the message can decode them. Note that this is not the Zigbee Network/Application level encryption, but yet another level of encryption.
- In contrast, the ESME<->IHD interface is quite wide, it uses many of the Zigbee Clusters
Most Zigbee Clusters are just “there” if instantiated in the product. The Tunnel is slightly different. The Tunnel Cluster can support a few tunnels, so there is an initial negotiation phase to establish which tunnel to use. In the CH<->ESME case it is the CH that initiates this process. So if the tunnel gets reset for some reason and the CH has no heartbeat on tunnel operation, then the ESME wil go deaf from the head ends’ point of view, but will quite happily keep talking to the IHD.
And:
There is only one HAN, and all devices communicate on that. There are CH<->ESME, CH<->IHD, CH<->GSME, ESME<->IHD communication paths (using Zigbee Clusters) on that network. The network is a CSMA-CA (Carrier Sense Multiple Access - Collision Avoidance) network, so every device can (potentially) talk to every other device but only one device can talk on the network at a given time. At the test centres there are hundreds of HAN networks active at the same time happily working so the CA bit seems to work. What probably doesn’t happen at the test centres is leaving a given HAN up for weeks on end as in a real installation.
If a previously functioning network stops working then some possibilities are
- A new significant source of RF interference has appeared and is wiping out all HAN communications
- The CH has had a brainstorm and told all devices to leave the HAN.
- Tunnels have failed and the CH has not restored them.
- RF reception is marginal (either due to range or building construction) so the devices on the HAN have fallen into TCSO hell.
- A new intermittent source of RF interference has appeared and driven the HAN into TCSO hell.
- Firmware bugs and design flaws.
Unquote
(credit: Alun)
