The name refers to the waggle dance of honey bees after their return to the beehive.
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.
thumb|ZigBee protocol stack ZigBee builds upon the physical layer and medium access control defined in IEEE standard 802.15.4 (2003 version) for low-rate WPAN's. The specification goes on to complete the standard by adding four main components: network layer, application layer, ZigBee device objects (ZDO's) 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 ZDO's. 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 msec 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. Because ZigBee nodes can sleep most of the time, average power consumption can be low, resulting in long battery life.
The requirements for membership in the Zigbee Alliance causes problems for open-source developers because the annual fee conflicts with the GNU General Public License. The requirement for the developer to join the ZigBee Alliance similarly conflicts with most other Free software licenses.
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, 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:
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.
Typical application areas include:
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. There are three notable exceptions to the use of CSMA. Beacons are sent on a fixed timing schedule, and do not use CSMA. Message acknowledgments also do not use CSMA. Finally, devices in Beacon Oriented networks that have low latency real-time requirements may also use Guaranteed Time Slots (GTS), which by definition do not use CSMA.
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. 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.
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. The ZigBee specifications were ratified on 14 December 2004. 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.
The first stack release is now called ZigBee 2004. The second stack release is called ZigBee 2006, and mainly replaces the MSG/KVP structure used in 2004 with a "cluster library". The 2004 stack is now more or less obsolete.
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.
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.
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 to the ISO 17025 standard 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 getting smaller devices.
This standard specifies operation in the unlicensed 2.4 GHz (worldwide), 915 MHz (Americas and Australia) and 868 MHz (Europe) ISM bands. In the 2.4 GHz band there are 16 ZigBee channels, with each channel requiring 5 MHz of bandwidth. The 2.4 GHz band provides up to 250 kbit/s, 915 MHz provides up to 40 kbit/s and 868 MHz provides a data rate up to 20 kbit/s. The actual data throughput will be less than the maximum specified bit rate due to the packet overhead and processing delays.
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 four 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. Transmission range is between 10 and 75 meters (33 and 246 feet) and up to 1500 meters for zigbee pro, although it is heavily dependent on the particular environment. The output power of the radios is generally 0 dBm (1 mW).
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.
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.
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.
There are two services available for application objects to use (in ZigBee 1.0):
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.
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.
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. There is a momentary exception to this rule, which 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 physically accessible to external devices and the particular working environment cannot be foretold; likewise, different applications running concurrently and using the same transceiver to communicate are supposed to be mutually trustworthy: for cost reasons the model does not assume a firewall exists between application-level entities.
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 cyphered, 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.
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 security levels infrastructure is based on CCM*, which adds encryption- and integrity-only features to CCM.
IEEE 802.15.4 web site
Category:Wireless networking Category:IEEE 802 Category:Home automation Category:Building automation Category:Personal area networks
ar:زيجبي cs:ZigBee de:ZigBee es:ZigBee fa:زیگ بی fr:ZigBee ko:직비 hr:ZigBee it:ZigBee he:ZigBee ml:സിഗ്ബി nl:ZigBee ja:ZigBee no:ZigBee pl:ZigBee pt:ZigBee ru:Zigbee fi:ZigBee sv:ZigBee uk:ZigBee zh:ZigBeeThis text is licensed under the Creative Commons CC-BY-SA License. This text was originally published on Wikipedia and was developed by the Wikipedia community.
The World News (WN) Network, has created this privacy statement in order to demonstrate our firm commitment to user privacy. The following discloses our information gathering and dissemination practices for wn.com, as well as e-mail newsletters.
We do not collect personally identifiable information about you, except when you provide it to us. For example, if you submit an inquiry to us or sign up for our newsletter, you may be asked to provide certain information such as your contact details (name, e-mail address, mailing address, etc.).
When you submit your personally identifiable information through wn.com, you are giving your consent to the collection, use and disclosure of your personal information as set forth in this Privacy Policy. If you would prefer that we not collect any personally identifiable information from you, please do not provide us with any such information. We will not sell or rent your personally identifiable information to third parties without your consent, except as otherwise disclosed in this Privacy Policy.
Except as otherwise disclosed in this Privacy Policy, we will use the information you provide us only for the purpose of responding to your inquiry or in connection with the service for which you provided such information. We may forward your contact information and inquiry to our affiliates and other divisions of our company that we feel can best address your inquiry or provide you with the requested service. We may also use the information you provide in aggregate form for internal business purposes, such as generating statistics and developing marketing plans. We may share or transfer such non-personally identifiable information with or to our affiliates, licensees, agents and partners.
We may retain other companies and individuals to perform functions on our behalf. Such third parties may be provided with access to personally identifiable information needed to perform their functions, but may not use such information for any other purpose.
In addition, we may disclose any information, including personally identifiable information, we deem necessary, in our sole discretion, to comply with any applicable law, regulation, legal proceeding or governmental request.
We do not want you to receive unwanted e-mail from us. We try to make it easy to opt-out of any service you have asked to receive. If you sign-up to our e-mail newsletters we do not sell, exchange or give your e-mail address to a third party.
E-mail addresses are collected via the wn.com web site. Users have to physically opt-in to receive the wn.com newsletter and a verification e-mail is sent. wn.com is clearly and conspicuously named at the point of
collection.If you no longer wish to receive our newsletter and promotional communications, you may opt-out of receiving them by following the instructions included in each newsletter or communication or by e-mailing us at michaelw(at)wn.com
The security of your personal information is important to us. We follow generally accepted industry standards to protect the personal information submitted to us, both during registration and once we receive it. No method of transmission over the Internet, or method of electronic storage, is 100 percent secure, however. Therefore, though we strive to use commercially acceptable means to protect your personal information, we cannot guarantee its absolute security.
If we decide to change our e-mail practices, we will post those changes to this privacy statement, the homepage, and other places we think appropriate so that you are aware of what information we collect, how we use it, and under what circumstances, if any, we disclose it.
If we make material changes to our e-mail practices, we will notify you here, by e-mail, and by means of a notice on our home page.
The advertising banners and other forms of advertising appearing on this Web site are sometimes delivered to you, on our behalf, by a third party. In the course of serving advertisements to this site, the third party may place or recognize a unique cookie on your browser. For more information on cookies, you can visit www.cookiecentral.com.
As we continue to develop our business, we might sell certain aspects of our entities or assets. In such transactions, user information, including personally identifiable information, generally is one of the transferred business assets, and by submitting your personal information on Wn.com you agree that your data may be transferred to such parties in these circumstances.