Home arrow Blog arrow Zigbee arrow Zigbee Network Layer Tutorial - Part 4: Network Management 1
Zigbee Network Layer Tutorial - Part 4: Network Management 1 | Print |
Written by Akiba   
Thursday, 04 June 2009

Welcome back to my ongoing series of Zigbee tutorials on the soon-to-be obsolete Zigbee Networking layer. Now that we’ve finished covering the data path, it’s time to look at the network management services. It’s quite a wide topic so I’ll start with the main management services and then cover some of the more esoteric ones later. Before we begin, I think it might be good to give a quick peek ahead on how a user application would interface to the networking layer to manage the network. With a top-down view, things might make more sense than just listening to me talk about some abstract next higher layers that all the data magically goes to or comes from.

Brief Overview

Whereas the Zigbee networking data path logically follows the protocol stack layer hierarchy, the network management deviates somewhat from it. Since this may be a bit confusing, let me try to explain it briefly.

The application layer consists of three parts: the Application Sublayer (APS), the Application Framework (AF), and the endpoints. The Application Sublayer interfaces the Zigbee application layer to the Zigbee networking layer and it provides a common set of data transport services to all the endpoints. There are also a couple of other services that the APS provides and we’ll get into that when we discuss the app layer in more detail.

The Application Framework is just a glorified multiplexer and container for all of the endpoints. All of the endpoints register themselves with the AF, and when a data frame comes into the application layer, the AF will check its destination endpoint and forward it there.

The endpoints are what most people associate with Zigbee. Each endpoint houses what’s called an application object which is basically a device profile with whatever extra functionality you decide to add. When the device is started, all the endpoints will register themselves with the application framework and provide descriptions of their device profile and their capabilities. Endpoint 0 is a special endpoint and always contains the Zigbee Device Object (ZDO). This object implements the Zigbee Device Profile which has multiple functions, one of them being the network manager.

The user application can manage the network by making requests and handling callbacks to this object, which is why it’s important to know about it. In general, the Zigbee endpoints are going to be the main interface between the user application and the stack.

When I mentioned that the network management deviates slightly from the stack’s layer hierarchy, what I meant was the ZDO’s network manager object bypasses the APS and interfaces directly to the networking layer. Thus, you get a bizarre looking layer stackup like this where you can see the ZDO wraps around the APS and the NWK layers.

Zigbee Architecture

(Graphic gratuitously copied from from Zigbee Open House - Seoul, 2006 - Phil Jamieson)

You can also forget about all of those SAPs (service access points) between the layers, since they’re mostly there for formality. In a real implementation, you would just call the functions directly or via function pointers.

With that out of the way, we can take a look at a few of the main network management functions.

Network Formation

When the user app decides to form a network instead of joining an existing one, it will instruct the ZDO to call the network formation function. Only a router that is coordinator-capable can form a network and this is indicated in the application layer’s information base. It’s just a fancy term for the app layer’s configuration table.  

When the network formation function is called, a list of allowed channels needs to be supplied to which may be limited to a subset of the total available channels (16 channels @ 2.4GHz). It’s usually based on certain requirements like avoiding channels that overlap with an existing 802.11 network. Incidentally, coexistence of Zigbee with 802.11 is a major debate point between other competing radio providers. The main issue is that they claim Zigbee is susceptible to interference from Wi-Fi networks whereas other radios operating at non-2.4 GHz frequencies are not. I won’t inject myself into the debate here, but I’d suggest locating any routing nodes a few feet away from an 802.11 access point. I think 3-6 feet is the magic number that I often hear. Otherwise, just take care to avoid 802.11 channels in your channel list.

The network formation function will call the MAC’s energy scan and active scan services and perform scans on the supplied channel list. When the scans are finished, the MAC’s scan confirm function will return the energy readings and network scan descriptors to the function via the MAC’s scan confirmation. From there, the network formation function will need to decide on the channel to join. The usual criteria is to choose a channel with the lowest energy reading (lowest amount of traffic) and the fewest networks. If you have access to the source code, you can also modify the channel decision function to add additional criteria.

Once the channel is decided on, the newly crowned coordinator will decide on a PAN ID and set the channel in the radio. The final step is for the NWK layer to call the MAC start service which configures the MAC layer. After that, confirmations go back all the way up to the user app.

Network Formation Sequence

Network Discovery

As the name implies, the Zigbee network discovery service is used to discover the existing networks on the current channel. It’s mostly just used when the device is started to find out if there are any suitable networks to join, although it can also be called at any time via the user app.

When a network discovery is requested by the ZDO (or user app), the discovery function will call the MAC’s active scan service which, in turn, will broadcast a beacon request. When other devices see the beacon request, they will respond with an 802.15.4 beacon frame. If you remember from my 802.15.4 articles, an 802.15.4 beacon frame contains MAC information about the responding device as well as a beacon payload for generic data. Within that payload, the responding device will include Zigbee network information such as the protocol ID and version, amount of routers and end devices allowed to join, the device profile that is being used, and other somewhat useful information.

Beacon Network Payload

When the beacons from the scan request are received, the device will add both the MAC and NWK info to its scan descriptor list and its neighbor table. After all of the beacons have been collected, a network discovery confirmation will be sent to the ZDO along with the list containing all the scan descriptors. The ZDO or the user app would then need to decide which network to join based on certain join critera. It’s here that the user can specify if they only want their device to join certain networks or even if there is a specific device they’d like to join to.

Network Discovery Sequence

Network Join

Joining a device or allowing a device to join is probably one of the most complicated processes in Zigbee. There are actually two sides to the network join function: the child side which sends the request and the parent side which processes the request and sends the response. To get a thorough understanding of the join process, I’ll treat each sequence separately. I won’t go into the details of the 802.15.4 association sequence since an explanation of that can be found in the MAC tutorial.

Network Join – Child

The first part of the join process for the child is to do a network discovery. This is usually done when the device is first started and is not associated with any network as mentioned previously. Once the network discovery is finished and the potential parent has been decided on according to the join criteria, then it’s time for the network join process to start.

When the potential parent has been chosen, a network join request is called by the ZDO. The network join request will call the MAC’s association service and issue an association request to the potential parent. From there, the procedure follows the MAC’s association sequence until the association response is received from the potential parent.

When this response is received, it will get passed up to the network layer via the MAC’s association response. If the join was successful, the device will update it’s NWK and MAC information tables to include the new network address, PAN ID, and also update the neighbor table to specify its parent. Once the administrative work is taken care of, the network join confirmation is sent up to the ZDO where it can inform the application about the join status. If the join status was unsuccessful, then the ZDO/user app will choose another potential parent from the neighbor table and retry the join procedure until it eventually joins a network or runs out of potential parents.

One of the last things that occur after a successful join is that the device will broadcast a device announcement informing everyone on the network that it has joined the network as well as it’s 16-bit network address and 64-bit IEEE address. This is important because if the device was previously joined to the network with a different network address, the other devices will be able to find out from it’s IEEE address and can clear all references to the old network address. Also, the address info will be added to everyone’s address map which tracks all the devices on the network.

Zigbee Join Sequence - Child

Network Join – Paren

The parent side of the join process is slightly easier. When a MAC association request arrives at the potential parent, it sends an indication to the network layer that a device is trying to join. The potential parent will then search its neighbor table to see if the 64-bit IEEE address already exists. If it does, then that means that the device was already previously joined and the parent will just issue the same network address to it. If not, and the parent is allowing devices to join it, then it will simply add the device to its neighbor table specifying that it’s a child device and generate a new network address for it. This all gets packaged up and sent out as a MAC association response. Again the rest goes according to the MAC’s association service.

Zigbee Join Sequence - Parent


Well, I guess that just about takes care of this part of the network management functions. Tune in for another chunk of network management functions in the next part.

Hits: 79135
Comments (6)Add Comment
Thank you !
written by Tally, June 15, 2009
Hello Akiba,

Thank you so much for the wonderful tutorial. I am just starting out on ZigBee and your tutorials are helping me a lot.
report abuse
vote down
vote up
Votes: +5
written by Akiba, June 15, 2009
No problem. I think you're one of the few people that are actually seriously reading through them smilies/tongue.gif
report abuse
vote down
vote up
Votes: +0
written by André, June 26, 2009
Second serious reader starting here smilies/cheesy.gif.

Thanks a lot, your tutorials are helping a lot in understanding the ZigBee structure.
report abuse
vote down
vote up
Votes: +3
written by Akiba, June 26, 2009
Ha ha ha...been slacking on my tutorials lately. Gonna add more soon, I hope...
report abuse
vote down
vote up
Votes: +0
Thank you!
written by nickagian, September 17, 2009
It is a very helpful tutorial! Thank you very much!
report abuse
vote down
vote up
Votes: +1
thank you
written by ramya rao, August 27, 2010
hello sir,
I have been studying about Zigbee and how Zigbee commnicates with the devices and your tutorial is helping me a lot.I just want to know the role of group manager.whether group manager assigns cluster ID or the device which becomes the PAN co ordinator destination address will have cluster head?
ramya rao
report abuse
vote down
vote up
Votes: +1

Write comment


Discuss (4 posts)
Tomas B.
Zigbee Network Layer Tutorial - Part 4: Network Management 1
Jun 15 2009 12:11:22
This thread discusses the Content article: Zigbee Network Layer Tutorial - Part 4: Network Management 1

Hello Akiba, here's another freak, playing with 802.15.4. Thank you for your articles. What I would appreciate is to go more deep to ZDO. And examples how to form and setup clusters etc. From my side the 802.15.4 MAC is quite clear, but the ZigBee spec is not easy to understand without examples.

My current HW is Zena + MC13201 + PIC24F + RTOS + now running MiWi stack on MC13201 but trying to go deeper into ZigBee itslef - but without MCHP ZigBee Stack.

Re:Zigbee Network Layer Tutorial - Part 4: Network Management 1
Jun 15 2009 12:43:33
Your wish will be granted. I'm just slow in implementing the tutorials. It seems that the application layer (APS + AF + ZDO + ZCL) will become the most important part of Zigbee in the future so I will definitely be covering those.
Re:Zigbee Network Layer Tutorial - Part 4: Network Management 1
Sep 17 2009 08:30:26
Hello Akiba!

I am totally newbie to Zigbee and your articles help me a lot to get the idea behind it.

I was wondering if you could help me a little with something I can't understand. I am trying to design a Zigbee application, where the end devices will work off-line (even when no network has been formed) and the coordinator will not be permanently present. My intention is to download data from the end devices to a laptop using a Zigbee USB dongle.

So the network will be formed as soon as the laptop comes in range and act as a coordinator. What should the end devices do while waiting for the coordinator? I was thinking that maybe they should periodically perform a network discovery sequence. On the other hand when the laptop comes in place and the coordinator service is activated, a network formation sequence will be performed, isn't that right? So, is it necessary for the end devices to periodically search for a network?

Re:Zigbee Network Layer Tutorial - Part 4: Network Management 1
Sep 17 2009 18:03:38
Yeah, actually you can try either approach. If you want the devices to join your laptop as you come rolling by, then you can just have them perform a network discovery sequence periodically. In terms of battery efficiency, this would get you the longest life because the node will control when the radio is turned on and when it is shut off.

As you mentioned, you can also have the converse, where the devices will listen for a join request from your laptop. In this case, there are two downsides. The first is that you would require full routers rather than end devices since end devices cannot be parents. The second down side is that the radio would always need to be on to listen for requests. If you have a battery powered application, this would not be possible.

< Prev   Next >