ZigBee
From Wikipedia, the free encyclopedia
ZigBee 
A ZigBee module |
| International standard | IEEE 802.15.4 |
| Developed by | ZigBee Alliance |
| Industry | Industrial, scientific and medical |
| Physical range | 10-100 meters (approx) |
ZigBee is a specification for a suite of high level communication protocols used to create personal area networks built from small, low-power digital radios. ZigBee is based on an IEEE 802 standard. Though low-powered, ZigBee devices often transmit data over longer distances by passing data through intermediate devices to reach more distant ones, creating a mesh network; i.e., a network with no centralized control or high-power transmitter/receiver able to reach all of the networked devices. The decentralized nature of such wireless ad-hoc networks make them suitable for applications where a central node can't be relied upon.
Read More, at the Bottom of this Page of go here...
http://en.wikipedia.org/wiki/ZigBee
Freaklabs - Open Source Wireless - 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. 
(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 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. 
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 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. 
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. Trackback(0)  TrackBack URI for this entry  Subscribe to this comment's feed
 Show/Hide comment form
|
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. | #872 |
| Akiba | 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. | #873 |
| Nick | 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? | #1316 |
| Akiba | 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. | #1319 |
Read More...
http://www.freaklabs.org/index.php/Blog/Zigbee/Zigbee-Network-Layer-Tutorial-Part-4-Network-Management-1.html ZigBee
Continued - From Wikipedia, the free encyclopedia
ZigBee is used in applications that require a low data rate, long battery life, and secure networking. ZigBee has a defined rate of 250 kbit/s, best suited for periodic or intermittent data or a single signal transmission from a sensor or input device. Applications include wireless light switches, electrical meters with in-home-displays, traffic management systems, and other consumer and industrial equipment that requires short-range wireless transfer of data at relatively low rates. The technology defined by the ZigBee specification is intended to be simpler and less expensive than other WPANs, such as Bluetooth or Wi-Fi.
Zigbee networks are secured by 128 bit symmetric encryption keys.
Zigbee was conceived in 1998, standardized in 2003 and revised in 2006. The name refers to the waggle dance of honey bees after their return to the beehive.[1]
Overview
ZigBee is a low-cost, low-power, wireless mesh network standard. The low cost allows the technology to be widely deployed in wireless control and monitoring applications. Low power-usage allows longer life with smaller batteries. Mesh networking provides high reliability and more extensive range. ZigBee chip vendors typically sell integrated radios and microcontrollers with between 60 KB and 256 KB flash memory.
ZigBee operates in the industrial, scientific and medical (ISM) radio bands; 868 MHz in Europe, 915 MHz in the USA and Australia and 2.4 GHz in most jurisdictions worldwide. Data transmission rates vary from 20 kilobits/second in the 868 MHz frequency band to 250 kilobits/second in the 2.4 GHz frequency band.[2]
The ZigBee network layer natively supports both star and tree typical networks, and generic mesh networks. Every network must have one coordinator device, tasked with its creation, the control of its parameters and basic maintenance. Within star networks, the coordinator must be the central node. Both trees and meshes allows the use of ZigBee routers to extend communication at the network level.
ZigBee builds upon the physical layer and medium access control defined in IEEE standard 802.15.4 (2003 version) for low-rate WPANs. The specification goes on to complete the standard by adding four main components: network layer, application layer, ZigBee device objects (ZDOs) and manufacturer-defined application objects which allow for customization and favor total integration.
Besides adding two high-level network layers to the underlying structure, the most significant improvement is the introduction of ZDOs. These are responsible for a number of tasks, which include keeping of device roles, management of requests to join a network, device discovery and security.
ZigBee is not intended to support powerline networking but to interface with it at least for smart metering and smart appliance purposes.
Because ZigBee nodes can go from sleep to active mode in 30 ms or less, the latency can be low and devices can be responsive, particularly compared to Bluetooth wake-up delays, which are typically around three seconds.[3] Because ZigBee nodes can sleep most of the time, average power consumption can be low, resulting in long battery life. A Bluetooth SMART device can when advertising is pushed to maximum connect, exchange data and disconnect in 3 ms. This significantly enhances the experiences for HID devices.
History
ZigBee-style networks began to be conceived around 1999, when many installers realized that both Wi-Fi and Bluetooth were going to be unsuitable for many applications. In particular, many engineers[by whom?] saw a need for self-organizing ad-hoc digital radio networks.[citation needed] The real need for mesh has been cast in doubt since that, in particular as mesh is largely absent in the market.
The IEEE 802.15.4-2003 standard was completed in May 2003 and has been superseded by the publication of IEEE 802.15.4-2006.[4] In the summer of 2003, Philips Semiconductors, a major mesh network supporter, ceased the investment. Philips Lighting has, however, continued Philips' participation, and Philips remains a promoter member on the ZigBee Alliance Board of Directors.[citation needed]
The ZigBee Alliance announced in October 2004 that the membership had more than doubled in the preceding year and had grown to more than 100 member companies, in 22 countries. By April 2005 membership had grown to more than 150 companies, and by December 2005 membership had passed 200 companies.[citation needed]
The ZigBee specifications were ratified on 14 December 2004.[5] The ZigBee Alliance announced availability of Specification 1.0 on 13 June 2005, known as ZigBee 2004 Specification. In September 2006, ZigBee 2006 Specification is announced. In 2007, ZigBee PRO, the enhanced ZigBee specification was finalized.[citation needed]
The first stack release is now called ZigBee 2004. The second stack release is called ZigBee 2006, and mainly replaces the MSG/KVP (Message/Key Value Pair) structure used in 2004 with a "cluster library". The 2004 stack is now more or less obsolete.[citation needed]
ZigBee 2007, now the current stack release, contains two stack profiles, stack profile 1 (simply called ZigBee), for home and light commercial use, and stack profile 2 (called ZigBee PRO). ZigBee PRO offers more features, such as multi-casting, many-to-one routing and high security with Symmetric-Key Key Exchange (SKKE), while ZigBee (stack profile 1) offers a smaller footprint in RAM and flash. Both offer full mesh networking and work with all ZigBee application profiles.[citation needed]
ZigBee 2007 is fully backward compatible with ZigBee 2006 devices: A ZigBee 2007 device may join and operate on a ZigBee 2006 network and vice versa. Due to differences in routing options, ZigBee PRO devices must become non-routing ZigBee End-Devices (ZEDs) on a ZigBee 2006 network, the same as for ZigBee 2006 devices on a ZigBee 2007 network must become ZEDs on a ZigBee PRO network. The applications running on those devices work the same, regardless of the stack profile beneath them.
The ZigBee 1.0 specification was ratified on 14 December 2004 and is available to members of the ZigBee Alliance. Most recently, the ZigBee 2007 specification was posted on 30 October 2007. The first ZigBee Application Profile, Home Automation, was announced 2 November 2007.
Uses
A ZigBee motion sensor from
NYCE Control, used in home automation (smart lighting and security).
ZigBee protocols are intended for embedded applications requiring low data rates and low power consumption. The resulting network will use very small amounts of power — individual devices must have a battery life of at least two years to pass ZigBee certification.[6]
Typical application areas include:[7]
Standard and profiles
The ZigBee Alliance is a group of companies that maintain and publish the ZigBee standard.[9] The term ZigBee is a registered trademark of this group, not a single technical standard. The Alliance publishes application profiles that allow multiple OEM vendors to create interoperable products. The relationship between IEEE 802.15.4 and ZigBee[10] is similar to that between IEEE 802.11 and the Wi-Fi Alliance.
License
For non-commercial purposes, the ZigBee specification is available free to the general public.[11] An entry level membership in the ZigBee Alliance, called Adopter, provides access to the as-yet unpublished specifications and permission to create products for market using the specifications.
The requirements for membership in the ZigBee Alliance causes problems for Free Software developers because the annual fee conflicts with the GNU General Public Licence.[12] The requirement for the developer to join the ZigBee Alliance similarly conflicts with most other free software licenses.[13]
Application profiles
The current list of application profiles either published, or in the works are:
- Released specifications
- ZigBee Home Automation
- ZigBee Smart Energy 1.0
- ZigBee Telecommunication Services
- ZigBee Health Care
- ZigBee RF4CE – Remote Control
- ZigBee RF4CE – Input Device
- ZigBee Light Link
- Specifications under development
- ZigBee Smart Energy 2.0
- ZigBee Building Automation
- ZigBee Retail Services
The ZigBee Smart Energy V2.0 specifications define an IP-based protocol to monitor, control, inform and automate the delivery and use of energy and water. It is an enhancement of the ZigBee Smart Energy version 1 specifications,[14] adding services for plug-in electric vehicle (PEV) charging, installation, configuration and firmware download, prepay services, user information and messaging, load control, demand response and common information and application profile interfaces for wired and wireless networks. It is being developed by partners including:
- HomeGrid Forum responsible for marketing and certifying ITU-T G.hn technology and products
- HomePlug Powerline Alliance
- International Society of Automotive Engineers SAE International
- IPSO Alliance
- SunSpec Alliance
- Wi-Fi Alliance.
In 2009 the RF4CE (Radio Frequency for Consumer Electronics) Consortium and ZigBee Alliance agreed to jointly deliver a standard for radio frequency remote controls. ZigBee RF4CE is designed for a wide range of consumer electronics products, such as TVs and set-top boxes. It promises many advantages over existing remote control solutions, including richer communication and increased reliability, enhanced features and flexibility, interoperability, and no line-of-sight barrier.[15] The ZigBee RF4CE specification lifts off some networking weight and does not support all the mesh features, which is traded for smaller memory configurations for lower cost devices, such as remote control of consumer electronics.
With the introduction of the second ZigBee RF4CE application profile in 2012 and increased momentum in MSO market, the ZigBee RF4CE team provides an overview on current status of the standard, applications, and future of the technology.[16][17]
Radio hardware
The radio design used by ZigBee has been carefully optimized for low cost in large scale production. It has few analog stages and uses digital circuits wherever possible.
Though the radios themselves are inexpensive, the ZigBee Qualification Process involves a full validation of the requirements of the physical layer. All radios derived from the same validated semiconductor mask set would enjoy the same RF characteristics. An uncertified physical layer that malfunctions could cripple the battery lifespan of other devices on a ZigBee network. ZigBee radios have very tight constraints on power and bandwidth. Thus, radios are tested with guidance given by Clause 6 of the 802.15.4-2006 Standard. Most vendors plan to integrate the radio and microcontroller onto a single chip[18] getting smaller devices.[19]
This standard specifies operation in the unlicensed 2.4 GHz (worldwide), 915 MHz (Americas and Australia) and 868 MHz (Europe) ISM bands. Sixteen channels are allocated in the 2.4 GHz band, with each channel requiring 5 MHz of bandwidth. The radios use direct-sequence spread spectrum coding, which is managed by the digital stream into the modulator. Binary phase-shift keying (BPSK) is used in the 868 and 915 MHz bands, and offset quadrature phase-shift keying (OQPSK) that transmits two bits per symbol is used in the 2.4 GHz band.
The raw, over-the-air data rate is 250 kbit/s per channel in the 2.4 GHz band, 40 kbit/s per channel in the 915 MHz band, and 20 kbit/s in the 868 MHz band. The actual data throughput will be less than the maximum specified bit rate due to the packet overhead and processing delays. Transmission range is between 10 and 75 meters[citation needed] (33 and 246 feet) and up to 1500 meters for ZigBee PRO[citation needed], although it is heavily dependent on the particular environment. The output power of the radios is generally 0-20 dBm (1-100 mW).
Device types and operating modes
ZigBee devices are of three types:
- ZigBee Co-ordinator (ZC): The most capable device, the Co-ordinator forms the root of the network tree and might bridge to other networks. There is exactly one ZigBee Co-ordinator in each network since it is the device that started the network originally (the ZigBee LightLink specification also allows operation without a ZigBee Co-ordinator, making it more usable for over-the-shelf home products). It stores information about the network, including acting as the Trust Center & repository for security keys.[20][21]
- ZigBee Router (ZR): As well as running an application function, a Router can act as an intermediate router, passing on data from other devices.
- ZigBee End Device (ZED): Contains just enough functionality to talk to the parent node (either the Co-ordinator or a Router); it cannot relay data from other devices. This relationship allows the node to be asleep a significant amount of the time thereby giving long battery life. A ZED requires the least amount of memory, and therefore can be less expensive to manufacture than a ZR or ZC.
The current ZigBee protocols support beacon and non-beacon enabled networks. In non-beacon-enabled networks, an unslotted CSMA/CA channel access mechanism is used. In this type of network, ZigBee Routers typically have their receivers continuously active, requiring a more robust power supply. However, this allows for heterogeneous networks in which some devices receive continuously, while others only transmit when an external stimulus is detected. The typical example of a heterogeneous network is a wireless light switch: The ZigBee node at the lamp may receive constantly, since it is connected to the mains supply, while a battery-powered light switch would remain asleep until the switch is thrown. The switch then wakes up, sends a command to the lamp, receives an acknowledgment, and returns to sleep. In such a network the lamp node will be at least a ZigBee Router, if not the ZigBee Coordinator; the switch node is typically a ZigBee End Device.
In beacon-enabled networks, the special network nodes called ZigBee Routers transmit periodic beacons to confirm their presence to other network nodes. Nodes may sleep between beacons, thus lowering their duty cycle and extending their battery life. Beacon intervals depend on data rate; they may range from 15.36 milliseconds to 251.65824 seconds at 250 kbit/s, from 24 milliseconds to 393.216 seconds at 40 kbit/s and from 48 milliseconds to 786.432 seconds at 20 kbit/s. However, low duty cycle operation with long beacon intervals requires precise timing, which can conflict with the need for low product cost.
In general, the ZigBee protocols minimize the time the radio is on, so as to reduce power use. In beaconing networks, nodes only need to be active while a beacon is being transmitted. In non-beacon-enabled networks, power consumption is decidedly asymmetrical: some devices are always active, while others spend most of their time sleeping.
Except for the Smart Energy Profile 2.0, ZigBee devices are required to conform to the IEEE 802.15.4-2003 Low-Rate Wireless Personal Area Network (LR-WPAN) standard. The standard specifies the lower protocol layers—the physical layer (PHY), and the media access control portion of the data link layer (DLL). The basic channel access mode is "carrier sense, multiple access/collision avoidance" (CSMA/CA). That is, the nodes talk in the same way that people converse; they briefly check to see that no one is talking before they start, with three notable exceptions. Beacons are sent on a fixed timing schedule, and do not use CSMA. Message acknowledgments also do not use CSMA. Finally, devices in beacon-enabled networks that have low latency real-time requirements may also use Guaranteed Time Slots (GTS), which by definition do not use CSMA.
Software
The software is designed to be easy to develop on small, inexpensive microprocessors.
Network layer
The main functions of the network layer are to enable the correct use of the MAC sublayer and provide a suitable interface for use by the next upper layer, namely the application layer. Its capabilities and structure are those typically associated to such network layers, including routing.
On the one hand, the data entity creates and manages network layer data units from the payload of the application layer and performs routing according to the current topology. On the other hand, there is the layer control, which is used to handle configuration of new devices and establish new networks: it can determine whether a neighboring device belongs to the network and discovers new neighbors and routers. The control can also detect the presence of a receiver, which allows direct communication and MAC synchronization.
The routing protocol used by the Network layer is AODV. In order to find the destination device, it broadcasts out a route request to all of its neighbors. The neighbors then broadcast the request to their neighbors, etc. until the destination is reached. Once the destination is reached, it sends its route reply via unicast transmission following the lowest cost path back to the source. Once the source receives the reply, it will update its routing table for the destination address with the next hop in the path and the path cost.
Application layer
The application layer is the highest-level layer defined by the specification, and is the effective interface of the ZigBee system to its end users. It comprises the majority of components added by the ZigBee specification: both ZDO and its management procedures, together with application objects defined by the manufacturer, are considered part of this layer.
Main components
The ZDO is responsible for defining the role of a device as either coordinator or end device, as mentioned above, but also for the discovery of new (one-hop) devices on the network and the identification of their offered services. It may then go on to establish secure links with external devices and reply to binding requests accordingly.
The application support sublayer (APS) is the other main standard component of the layer, and as such it offers a well-defined interface and control services. It works as a bridge between the network layer and the other components of the application layer: it keeps up-to-date binding tables in the form of a database, which can be used to find appropriate devices depending on the services that are needed and those the different devices offer. As the union between both specified layers, it also routes messages across the layers of the protocol stack.
Communication models
ZigBee high-level communication model
An application may consist of communicating objects which cooperate to carry out the desired tasks. The focus of ZigBee is to distribute work among many different devices which reside within individual ZigBee nodes which in turn form a network (said work will typically be largely local to each device, for instance the control of each individual household appliance).
The collection of objects that form the network communicate using the facilities provided by APS, supervised by ZDO interfaces. The application layer data service follows a typical request-confirm/indication-response structure. Within a single device, up to 240 application objects can exist, numbered in the range 1-240. 0 is reserved for the ZDO data interface and 255 for broadcast; the 241-254 range is not currently in use but may be in the future.
Two services are available for application objects to use (in ZigBee 1.0):
- The key-value pair service (KVP) is meant for configuration purposes. It enables description, request and modification of object attributes through a simple interface based on get/set and event primitives, some allowing a request for response. Configuration uses compressed XML (full XML can be used) to provide an adaptable and elegant solution.
- The message service is designed to offer a general approach to information treatment, avoiding the necessity to adapt application protocols and potential overhead incurred on by KVP. It allows arbitrary payloads to be transmitted over APS frames.
Addressing is also part of the application layer. A network node consists of an 802.15.4-conformant radio transceiver and one or more device descriptions (basically collections of attributes which can be polled or set, or which can be monitored through events). The transceiver is the base for addressing, and devices within a node are specified by an endpoint identifier in the range 1-240.
Communication and device discovery
In order for applications to communicate, their comprising devices must use a common application protocol (types of messages, formats and so on); these sets of conventions are grouped in profiles. Furthermore, binding is decided upon by matching input and output cluster identifiers, unique within the context of a given profile and associated to an incoming or outgoing data flow in a device. Binding tables contain source and destination pairs.
Depending on the available information, device discovery may follow different methods. When the network address is known, the IEEE address can be requested using unicast communication. When it is not, petitions are broadcast (the IEEE address being part of the response payload). End devices will simply respond with the requested address, while a network coordinator or a router will also send the addresses of all the devices associated with it.
This extended discovery protocol permits external devices to find out about devices in a network and the services that they offer, which endpoints can report when queried by the discovering device (which has previously obtained their addresses). Matching services can also be used.
The use of cluster identifiers enforces the binding of complementary entities by means of the binding tables, which are maintained by ZigBee coordinators, as the table must be always available within a network and coordinators are most likely to have a permanent power supply. Backups, managed by higher-level layers, may be needed by some applications. Binding requires an established communication link; after it exists, whether to add a new node to the network is decided, according to the application and security policies.
Communication can happen right after the association. Direct addressing uses both radio address and endpoint identifier, whereas indirect addressing uses every relevant field (address, endpoint, cluster and attribute) and requires that they be sent to the network coordinator, which maintains associations and translates requests for communication. Indirect addressing is particularly useful to keep some devices very simple and minimize their need for storage. Besides these two methods, broadcast to all endpoints in a device is available, and group addressing is used to communicate with groups of endpoints belonging to a set of devices.
Security services
As one of its defining features, ZigBee provides facilities for carrying out secure communications, protecting establishment and transport of cryptographic keys, cyphering frames and controlling devices. It builds on the basic security framework defined in IEEE 802.15.4. This part of the architecture relies on the correct management of symmetric keys and the correct implementation of methods and security policies.
Basic security model
The basic mechanism to ensure confidentiality is the adequate protection of all keying material. Trust must be assumed in the initial installation of the keys, as well as in the processing of security information. In order for an implementation to globally work, its general conformance to specified behaviors is assumed.
Keys are the cornerstone of the security architecture; as such their protection is of paramount importance, and keys are never supposed to be transported through an insecure channel. A momentary exception to this rule occurs during the initial phase of the addition to the network of a previously unconfigured device. The ZigBee network model must take particular care of security considerations, as ad hoc networks may be Within the protocol stack, different network layers are not cryptographically separated, so access policies are needed and correct design assumed. The open trust model within a device allows for key sharing, which notably decreases potential cost. Nevertheless, the layer which creates a frame is responsible for its security. If malicious devices may exist, every network layer payload must be ciphered, so unauthorized traffic can be immediately cut off. The exception, again, is the transmission of the network key, which confers a unified security layer to the network, to a new connecting device.
Security architecture
ZigBee uses 128-bit keys to implement its security mechanisms. A key can be associated either to a network, being usable by both ZigBee layers and the MAC sublayer, or to a link, acquired through pre-installation, agreement or transport. Establishment of link keys is based on a master key which controls link key correspondence. Ultimately, at least the initial master key must be obtained through a secure medium (transport or pre-installation), as the security of the whole network depends on it. Link and master keys are only visible to the application layer. Different services use different one-way variations of the link key in order to avoid leaks and security risks.
Key distribution is one of the most important security functions of the network. A secure network will designate one special device which other devices trust for the distribution of security keys: the trust center. Ideally, devices will have the trust center address and initial master key preloaded; if a momentary vulnerability is allowed, it will be sent as described above. Typical applications without special security needs will use a network key provided by the trust center (through the initially insecure channel) to communicate.
Thus, the trust center maintains both the network key and provides point-to-point security. Devices will only accept communications originating from a key provided by the trust center, except for the initial master key. The security architecture is distributed among the network layers as follows:
- The MAC sublayer is capable of single-hop reliable communications. As a rule, the security level it is to use is specified by the upper layers.
- The network layer manages routing, processing received messages and being capable of broadcasting requests. Outgoing frames will use the adequate link key according to the routing, if it is available; otherwise, the network key will be used to protect the payload from external devices.
- The application layer offers key establishment and transport services to both ZDO and applications. It is also responsible for the propagation across the network of changes in devices within it, which may originate in the devices themselves (for instance, a simple status change) or in the trust manager (which may inform the network that a certain device is to be eliminated from it). It also routes requests from devices to the trust center and network key renewals from the trust center to all devices. Besides this, the ZDO maintains the security policies of the device.
The security levels infrastructure is based on CCM*, which adds encryption- and integrity-only features to CCM.
Simulation of ZigBee networks
Network simulators, like OPNET, NetSim and NS2, can be used to simulate IEEE 802.15.4 ZigBee networks.
These simulators come with open source C or C++ libraries for users to modify. This way users can check out the validity of new algorithms prior to hardware implementation.
Chip vendors/devices
To become ZigBee certified as a semiconductor company, vendors must ensure their applications are interoperable. Periodic interoperability events verify that devices work with other certified devices.
- Atmel ATmega128RFA1,ATmega256RFR2, AT86RF230/231/233
- Anaren A2530R24E, A2530R24R
- CEL ZICM357SPx
- Digi International XBee XB24CZ7PIS-004
- Silicon Labs EM250, EM351, EM357
- Freescale MC13224, MC13226
- GreenPeak Technologies ZigBee RF4CE, ZigBee PRO, ZigBee Green Power, ZigBee IP
- Jennic JN5148
- NXP Semiconductors JN514x RF4CE and JN514x ZBPro
- Renesas uPD78F8056/57/58, M16C/6B3 and R8C/3MQ
- STMicroelectronics STM32W
- Samsung Electro-Mechanics ZBS240
- Telegesis (UK) Ltd ETRX2 and ETRX357
- Texas Instruments CC2530 and CC2520
- Microchip Technology MRF24J40MA, MRF24J40MB, MRF24J40MC
See also
References
- ^ "ZigBee Wireless Networking", Drew Gislason (via EETimes)
- ^ "Frequently Asked Questions". Zigbee Alliance. Retrieved March 23, 2013.
- ^ "ZigBee: Wireless Technology for Low-Power Sensor Networks". Commsdesign.com. Retrieved 2012-10-18.
- ^ "IEEE 802.15.4". Ieee802.org. Retrieved 2012-10-18.
- ^ ZigBee Document 053474r06, Version 1.0, ZigBee Specification. ZigBee Alliance. 2004.
- ^ [1][dead link]
- ^ "What's so good about ZigBee networks?". Daintree Networks. Retrieved 2007-01-19.
- ^ Bellido-Outeirino, Francisco J. (February 2012). "Building lighting automation through the integration of DALI with wireless sensor networks". IEEE Transactions on Consumer Electronics 58 (1): 47–52. doi:10.1109/TCE.2012.6170054.
- ^ "The ZigBee Alliance". Zigbee.org. Retrieved 2012-10-18.
- ^ "Wireless Sensor Networks Research Group". Sensor-networks.org. 2008-11-17. Retrieved 2012-10-18.
- ^ "ZigBee Cluster Library Specification Download Request". zigbee.org. Retrieved 2010-04-10.
- ^ "ZigBee is only royalty-free if not used for commercial purposes...", FAQ for BEN WPAN
- ^ "Zigbee, Linux, and the GPL". freaklabs.org. Retrieved 2009-06-14.
- ^ "ZigBee Smart Energy Overview". ZigBee.org. Retrieved 2012-10-18.
- ^ "Introducing ZigBee RF4CE". Daintree Networks. Retrieved 2009-05-04.
- ^ "ZigBee RF4CE: A Quiet Revolution is Underway (December, 2012)". ZigBee Alliance. Retrieved 2012-12-06.
- ^ "ZigBee RF4CE Webinar: A Quiet Revolution is Underway (December, 2012)". ZigBee Alliance. Retrieved 2012-12-06.
- ^ "Zigbit Modules MCU Wireless- Atmel Corporation". Atmel.com. Retrieved 2012-10-18.
- ^ "n-Core Platform & Polaris Real-Time Locating System – Wireless Sensor Networks – ZigBee". N-core.info. Retrieved 2012-10-18.
- ^ "Wireless Sensor Networks Research Group". Sensor-networks.org. 2010-04-15. Retrieved 2012-10-18.
- ^ "Wireless Sensor Networks Research Group". Sensor-networks.org. 2009-02-05. Retrieved 2012-10-18.
External links
ZigBee is a specification for a suite of high level communication protocols used to create personal area networks built from small, low-power digital radio
- Zigbee network - Google Search
- Zigbee network - Google Search
- ZigBee - Wikipedia, the free encyclopedia
- File:ZigBee protocol stack.png - Wikipedia, the free encyclopedia
- RTI Releases Integration Designer 9.0 Programming Software
- ZigBee network controller - 2.4 GHz, 3 inputs | Net-Bee - UControl Wireless
- RF Modules
- Product News: HAI Ships ZigBee Energy Management Products, by Rachel Cericola - Electronic House
- Greenologic - Gateway: Modbus RS485 - ZigBee ZC-GW-485-EM
- Relaying Device for Zigbee Wireiess Communication (ZRL-WT) - TSC Systems Co., Ltd., South Korea Manufacturer
- Antenna - Selling Leads, Manufacturers, Suppliers, Exporters
- TX7502 Freedom Elite Zigbee Network Transmitter :: LRS Base Transmitters :: In House-Transmitters :: PagePlus
- 900 × 848 - controlanything.com
- e-Gizmo Zigbee Module 200m
- Project – ZigBee Controller for One Asset Place - Fritzing
- National Control Devices: 2-Channel 3-Amp DPDT ZB ZigBee Relay Controller with Relay Interface
- ZigBee Network Devices Standard Overview
- ZigBee Specification Network Topology
- Forming a ZigBee Network
- Freaklabs - Open Source Wireless - Zigbee Network Layer Tutorial - Part 4: Network Management 1
Thank you so much for the wonderful tutorial. I am just starting out on ZigBee and your tutorials are helping me a lot.