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.
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.
(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.
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.
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.
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.
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.
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.
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.