"2014-5-31"z-stack-modification of Zigbee Device Object for better network access management

Writing a pleasing engineering document is a difficult task. If you want to write well, not only to use the tool (using the right tools), pay attention to writing, but also have to devote a lot of time, really is a very difficult thing. But, if really write good, also is good great Yan: can let a person understand "why so design", namely "know it more know its why", also can peel off some trivial details, let more not so much time and energy, or the background knowledge insufficient friend, to the core method and the idea, a little more understanding, namely, provides a kind of " Gangjumuzhang sketchy cobwebs "possibilities.

Chance coincidence, I decided today to initiate, write a not so good engineering documents. Also expect friends interested in this topic to expand or re-create an excellent engineering document.

Background

Z-stack is a semi-open source Zigbee protocol stack for Texas Instruments (Texas instrument). Z-stack 2.5.1a is the last independent release of its release, the so-called "standalone release", that is, the version provided includes both home Automation profile content such as smart home and smart energy, such as centralized meter reading Profile related content, in layman's words, a hodgepodge. Later, the Z-stack is bundled in a separate profile and is no longer available as a separate download. (This information reference link, can also refer to 2.5.1a release note)

Why is this strategy adopted? (The following is a personal understanding) also have to first talk about the original purpose of the birth of Zigbee.

Zigbee was originally designed to solve the interoperability problem of low-power LAN, and was born a protocol based on 802.15.4 layer. Assuming that your home bulb takes the Smartblub protocol (the name of the nonsense), the air purification equipment uses the private Aircleaner protocol, the centralized controller is the Smartcontroller protocol, then congratulations, 're same page Jiongzhuang, in your home "smart home" happened. In the event of such Wohuo, you will of course put this group of "smart equipment" scold again, after all, ah Q said, insects don't curse.
In order to avoid the high-quality of your wronged, ZigBee was born: light bulbs, air conditioners, everyone use Zigbee protocol, everyone good is really good!

However, the world is complex. In addition to smart home, there are many areas that require interoperability, such as energy management, healthcare, and building automation. You will ask, so many different scenarios, each other will have a variety of topology and communication requirements, the same set of Zigbee protocol, can meet all the scenarios? Zigbee shouted loudly "Five damaged a countermeasure"! Unfortunately, Zigbee is not L ' oreal, in order to deal with these different scenarios, it has to toss a number of different profiles (configuration), such as the above you see the Home Automation and Smart Energy.

So, smart you have read the beginning, you should expect the end: profile differentiation, is any attempt to "incomplete open source (slot) but provide perfect service (advantage)" The Zigbee stack vendors have to face the end ...

Problem

The following sections are for the Z-stack 2.5.1a version.

In the Zigbee role, there are coordinator/router/end-device three roles. End-device equipment is mainly as a sensor node, the collected data information, as well as the usual control information (such as maintaining a connected heartbeat packet, command control packets, etc.) sent to the Router/coordinator device. The following address: node/end node/sensor node, all refer to end-device; routing/relaying, all refer to Router; Coordinator/Ap/zigbee Gateway, all refer to coordinator.

The part of this paper is mainly about the network control part of the node. Many friends on the Internet have encountered problems, summed up, are similar to the following two typical problems:

1. When the router/coordinator does not exist, or because the signal strength is too low and the link disconnects, it is observed from the sniffer sniffer that the end-device frequent beacon leads to the battery power of the sensor node (often the sensor node is battery-powered) and is exhausted. Harry

2. In a stable operation network with only a group of End-device and a coordinator, the node cannot access the net again after replacing the coordinator. How to break?
Note: Here intentionally does not involve any question about router, because router and coordinator in ZigBee network, the role behavior has certain overlap degree, will make the problem itself complicate; Considering the focus of this paper is on the network behavior of End-device, simplifying the problem, Remove the router.

Solutions

To the above two problems, give some suggestions to solve the problem, for reference.

1. The problem is relatively simple. Just start with a workaround and modify only two configurations:

Smart you must know the existence of the F8wconfig.cfg file. This includes configuration information for a wide range of Zigbee protocol stacks.

# File: \projects\zstack\tools\cc2530db\f8wconfig.cfg
-dbeacon_request_delay=3000     # from default 100–> 3000
-DBEACON_REQ_DELAY_MASK=0X0FFF  # from default 0x00ff–> 0x0fff

Where the –D prefix represents the #define macro definition of the preprocessor. The above two macro definitions, the former, represents delay delay between beacon request, the latter, which represents the time delay mask masks (introducing randomness), that is, the real delay is delay + rand () & mask.

Can be learned by a simple calculation that the default delay is 100 milliseconds, mask default is 0x00FF, the upper and lower limit of the delay is [100, 355]; modified to 3000 milliseconds and 0x0fff mask, the upper and lower limits are changed to [3000, 7095] respectively. Averaging 228ms and 5048ms, the visible average delay increased by about 20 times times. If you have been in the Beacon request Search Network process, the original can continue to search for 5 days of battery capacity, can be sustained for 3 months. It's simple, right!

2. On the assumption that there is only a group of End-device and coordinator in the network, and has run ing steadily. Suddenly your kitten puppy ran over and threw the coordinator from the table to the ground, and unfortunately it was so bad that you had to change the coordinator. The problem is: the node is still sending beacon request, and the new coordinator has been responding to superframe (Dev. Cap is also 1, that is, there are remaining end-device capacity, allow nodes to access the network), node is no association request, let alone the network ... You feel depressed and criticize the kitten dog, even though they don't know what you're talking about.

There are two completely different ways to solve this problem.

A) The first kind, simple and rude, software restart.

Smart you must know that there is a zdo_state_change system message in the Sampleapp_processevent function of the sample application application, which is a message sent from the ZDO (Zigbee Device Object) layer. Said "brother state has changed, brothers please according to the new state to make their own treatment."

Under what circumstances will sampleapp_processevent receive the State_change message from ZDO?

In the case of the above problem, because End-device do not know coordinator has been tilted legs, so once the sensor detects a certain information, it is still silly to the coordinator to send the past; Naturally, it cannot receive MAC layer ACK from the Coordinator That is, confirm the response (confirmation acknowledgement), and from sniffer, you will find that the end-device of the response is not receiving multiple retransmission packets.

After multiple retransmission of packets failed (neither received MAC layer ACK), End-device thought that the Half node (Parent-node) had lost contact and urged ZDO to send a state change (formerly Dev_end_device state, which is now missing from the parent node) , becomes the Orphan node State, i.e. Dev_nwk_orphan).

Once the sampleapp_processevent receives the status change to orphan, the software restarts starts the new round searches the net the network process.

b) The first method is too simple to be rude, so that you cannot complete some more sophisticated operations in order to cope with more complex real-world situations.

Let's assume that your coordinator was thrown to the ground by a kitten puppy and did not have a leg, but only the battery was off (transient shock). Is the toilet you, heard the noise, although the heart, and insufficient force, can not immediately rushed out of the toilet, to save the temporary shock of the Coordinator, can only watch the End-device to the coordinator to send data and not receive the MAC layer ACK, thereby self-thought into an orphan ...

According to the first method, the End-device sensor may detect an important message, and once restarted, the information will be lost unless you write the data to the NV-non-volatile region ...
In fact, End-device only need to wait two minutes, when you go out of the toilet, to the coordinator to install the battery, it can be directly through the orphan notification (instead of Beacon request), with less air interaction times, lower energy consumption to complete the network again ... How do you do that?

Smart you can definitely search for the Devstartmodes_t enumeration type, this enumeration state determines the default behavior of the node network.

For example, Mode_resume corresponds to the Orphan node State, which attempts to access the network through orphan notification, while Mode_rejoin and Mode_join are sending Beacon request network, but rejoin want to see Supe The rframe.extended_pan_id field (extended Pan ID) is equal to the extended Pan ID of the network before it becomes an orphan state.

After the node is lost, the MAC/NWK layer is naturally the first to know this message, in order to inform the other layers of the brothers, MAC/NWK through the ZDO layer of the callback function ZDO_SYNCINDICATIONCB (), told that "we have lost the half of the joint, Brother please inform other brothers. " This function then sends the ZDO_NWK_JOIN_REQ message to Zdapp, notifying the "We have lost the connection, please deal with the re-access issue as soon as possible."

The next thing, smart you should be able to read through the Z-stack network part of the source code to fix it. If you want to make ZigBee primitive that the original language is very clear, you can refer to ZigBee specification, Poke here can refer to the following I read the source of some of the summary.

Overall, understand the meaning of the request confirmation indication, should be able to better understand the network layer code. For example, assuming that the mode_join is now in the network mode, Zdo_startdevice () nlme_networkdiscoveryrequest () will request "send beacon to get around the parent node", in response to the Superframe (s) data frames are processed through ZDO_BEACONNOTIFYINDCB (), and the results of the Network Discovery are fed back through ZDO_NETWORKDISCOVERYCONFIRMCB (), and so on. This blog, also on the theoretical level, describes the overall network process.

Welfare

You have less time, more things, today to accompany people to play cards, tomorrow to accompany people to eat, the day after, to travel, it is not time to read so many network layer source code, how to break? Poke here to download the benefits. The design of the network behavior (reference link in the "Network Behavior Design"), is a fairly broad set, should be able to meet the needs of most scenarios, and can be easily customized (reference zdapp.c in the Gl_zdo_prepare_init_cnt_timeout two-dimensional array).

Although the Z-stack itself is semi-open source and can be publicly downloaded, but given that there are some tailoring and changes, in order to prevent any conflict with TI's release protocol, the above link is encrypted.

If you want to get the decompression password, please send me an email stating what type of project you are doing using z-stack (I also do a little research and get some feedback). A word of information such as "password seeking" is directly ignored. The link on the left side of the blog is the email address. Refusal of harassment.