Copyright !1996-2014 by the ZigBee Alliance. 2400 Camino Ramon, Suite 375, San Ramon, CA 94583, USA http://www.zigbee.org All rights reserved. Permission is granted to members of the ZigBee Alliance to reproduce this document for their own use or the use of other ZigBee Alliance members only, provided this notice is included. All other rights reserved. Duplication for sale, or for commercial or for-profit use is strictly prohibited without the prior written consent of the ZigBee Alliance. 1 2 3 4 ZigBee Document 074855r05 5 ZigBee-PRO Stack Profile: Platform 6 restrictions for compliant platform testing 7 and interoperability 8 9 Revision 05 10 11 January 2008 12 Sponsored by: 13 ZigBee Alliance 14 Accepted for release by: 15 This document has not yet been accepted for release by the ZigBee Alliance Board of Directors. 16 Abstract: 17 This document defines the ZigBee-PRO stack profile as applied to the ZigBee Specification r16. 18 Keywords:19 ZigBee, ZigBee-PRO, Stack profile, Architecture. 20 21
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Copyright! 1996-2014 by the ZigBee Alliance.2400 Camino Ramon, Suite 375, San Ramon, CA 94583, USA
http://www.zigbee.org All rights reserved.
Permission is granted to members of the ZigBee Alliance to reproduce this document for their own use or the use of other ZigBee Alliance members
only, provided this notice is included. All other rights reserved. Duplication for sale, or for commercial or for-profit use is strictly prohibited withoutthe prior written consent of the ZigBee Alliance.
1
2
3
4
ZigBee Document 074855r055
ZigBee-PRO Stack Profile: Platform6
restrictions for compliant platform testing7
and interoperability8
9
Revision 0510
11
January 200812
Sponsored by:13
ZigBee Alliance14
Accepted for release by:15
This document has not yet been accepted for release by the ZigBee Alliance Board of Directors.16
Abstract:17
This document defines the ZigBee-PRO stack profile as applied to the ZigBee Specification r16.18
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO (A) ANY WARRANTY THAT THE USE OF THE INFORMATION7 HEREIN WILL NOT INFRINGE ANY RIGHTS OF THIRD PARTIES (INCLUDING WITHOUT LIMITATION ANY INTELLECTUAL8
PROPERTY RIGHTS INCLUDING PATENT, COPYRIGHT OR TRADEMARK RIGHTS) OR (B) ANY IMPLIED WARRANTIES OF9 MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE OR NON-INFRINGEMENT. IN NO EVENT WILL10 ZIGBEE BE LIABLE FOR ANY LOSS OF PROFITS, LOSS OF BUSINESS, LOSS OF USE OF DATA, INTERRUPTION OF11 BUSINESS, OR FOR ANY OTHER DIRECT, INDIRECT, SPECIAL OR EXEMPLARY, INCIDENTIAL, PUNITIVE OR12CONSEQUENTIAL DAMAGES OF ANY KIND, IN CONTRACT OR IN TORT, IN CONNECTION WITH THIS DOCUMENT OR13THE INFORMATION CONTAINED HEREIN, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE. All14Company, brand and product names may be trademarks that are the sole property of their respective owners.15The above notice and this paragraph must be included on all copies of this document that are made.16
7.4 Multicast mechanism and groups .................................................................................................... 9 207.5 Trust Center Policies and Security Settings..................................................................................... 9 21
ZigBee Document 074855r05, October 2007 ZigBee-PRO Stack Profile
1 Introduction1
1.1 Scope2
This document covers the ZigBee PRO stack profile for the 2007 release of the ZigBee specification.3
The ZigBee PRO stack profile allows for networks of small to moderately large size, a fair degree of4autonomous self-configuration on the part of the network devices, and a flexible security model. The5
PRO stack profile is intended to support application profiles targeted to building automation plus6
sensing and control in commercial, industrial and institutional environments. It can also support other7
lightweight applications for ZigBee technology that do not require low-power routers.8
The ZigBee specification has a number of options, which, if exercised in different ways by different9
vendors, will hamper both compliance testing activities and future product interoperability. This10document, which is, for the most part, a set of restrictions on the Protocol Implementation11
Conformance Statement (PICS) documents corresponding to the three main sub-clauses of the12
specification, further restricts those options so as to promote interoperability and testability.13
1.2 Purpose14
This document defines the knobs settings, functional description and PICS for devices conforming to15
this stack profile, and is intended as the foundation for the platform compliance test plan that stack16
providers must pass in order to certify their products as ZigBee compliant.17
ZigBee Document 074855r05, October 2007 ZigBee-PRO Stack Profile
5 General description1
This document is the stack profile specification for the ZigBee-PRO stack profile.2
The sections in this document are:3
• Knob settings – details of values to be used for parameters specified in the ZigBee4specification for tuning the operation of the ZigBee stack, including network, application and5
security settings.6
• Functional description – further operational restrictions to be applied to all devices in this7
stack profile where various approaches are otherwise supported by the ZigBee specification.8
• Protocol implementation conformance statement (PICS) – a formal definition of functionality9
to be implemented in these devices.10
These requirements aim to allow a designer to make necessary assumptions about what settings,11
features and safeguards will be in place in the networks in which a device will be deployed.12
ZigBee-PRO Stack Profile, ZigBee Document 074855r054, October 2007
7 Functional description1
For the most part, the functioning of ZigBee with respect to the NWK layer, the APS layer and the2
ZDO is described in [R1]. However, the configuration details and operational requirements for devices3
operating under the ZigBee-PRO stack profile lead to some special functional considerations, which4
are detailed here.5
7.1 Device roles6
The basic roles performed by ZigBee devices in ZigBee-PRO networks are determined by their device7
type:8
• The ZigBee coordinator initiates network formation, choosing the network channel, PAN ID9
and extended PAN ID in the process, and thereafter should act as a ZigBee router. It may also10 perform the roles of trust center and Network Channel Manager. With respect to binding, the11
ZigBee coordinator is expected to handle end device bind request on behalf of all end devices12
in the network but is not expected to be a global binding repository for the network.13
• ZigBee routers are called upon to relay traffic on behalf of other devices in the network and,14in particular, are required to act as routing agents on behalf of their end device children, which15
will typically not have the neighbor tables, routing tables, route discovery tables or broadcast16
transaction tables required to perform routing. Since end devices may sleep, ZigBee routers17
and ZigBee coordinators in their role of ZigBee routers may cache discovery information on18
behalf of their sleeping end-device children. A ZigBee router may perform the role of trust19
center and Network Channel Manager.20
• ZigBee end devices are joined to and managed by ZigBee routers or the ZigBee coordinator.21
Because ZigBee-PRO networks are beaconless, there is no built-in synchronization22mechanism between sleeping end devices and their router parents. End devices are free to set23
their own duty cycles within the broad polling limits defined by this stack profile. End24
devices that wish to have their discovery information cached by their parent or some other25
device are responsible for using the discovery cache commands to achieve this.26
Under the ZigBee-PRO stack profile, all devices are expected to manage their own binding tables if27
they use binding tables.28
7.2 Compatibil i ty with Other Stack Profi les29
Devices implementing the ZigBee-PRO stack profile will advertise a stack profile identifier of 2 in30
their beacon payloads as stated below in the additional restrictions for PICS item NLF4. In general,31such devices will seek out and join networks in which the ZigBee coordinator and all ZigBee routers32
implement the ZigBee-PRO stack profile and advertise this fact by placing a stack profile identifier of33
2 in their beacon payloads.34
In order to provide compatibility with devices implemented according to the ZigBee stack profile,35
ZigBee-PRO devices shall additionally be able to join networks which advertise a stack profile36
identifier of 1 in their beacon payloads but the device must join the ZigBee networks as end devices.37
If a ZigBee PRO network is to allow ZigBee devices to join as end devices, it shall use the standard38
network security. If high security is used, ZigBee devices will not be able to be authenticated on the39
ZigBee Document 074855r05, October 2007 ZigBee-PRO Stack Profile
7.3 Binding tables1
Binding tables, if used, shall be located on the source device. While binding is optional, devices that2
choose to use binding tables should allocate enough binding table entries to handle their own3
communications needs. This suggests that binding table size should be flexible enough that it can be4set, at least at compile time, with some awareness of the actual intended usage of the device.5
7.4 Mult icast mechanism and groups6
Support for APS level multicasts is mandatory to support compatibility with ZigBee 2006 devices. The7
multicast groups are then established using the application level mechanisms. Support for network8
level multicasts is optional in this stack profile.9
7.5 Trust Center Policies and Security Sett ings10
A ZigBee PRO network shall have a trust center uniquely pointed to by each device in the network11
through apsTrustCenterAddress within each network member device. It is beyond the scope of the12
PRO Stack Profile to describe how this value is set or whether it is changed and the Trust Center13relocated to another device during operation. The only requirement of the PRO Stack Profile is that all14
devices in the network point to the one unique Trust Center and that the device pointed to as the Trust15
Center supplies the security services described by this document.16
The trust center dictates the security parameters of the network, such as which network key type to use,17
settings of the service permissions table, when, if at all, to allow devices to use unsecured association18
to the network, and when, if at all, to allow an application master or link key to be set up between two19
devices. For interoperability, there are two distinct security settings that can be used within the ZigBee20
PRO stack profile – a standard and a high security.21
Networks can exist for periods without a trust center. There are some operations where it is necessary22for the trust center to be operational in the network. These include initial network setup, key changes,23
and when joining and rejoining devices require updated keys.24
A wide range of implementations are possible, depending on the requirements of the application. A25
high security trust center may allow the user to install devices “out-of-band”, keep separate link keys26
for different devices, optionally ignore Mgmt_Permit_Joining_req commands from other nodes, and27
configure application trust policies between devices or groups of devices, etc. A standard security trust28
center would not offer these advantages, but would not be required to carry the associated costs.29
7.6 Battery powered devices30
ZigBee-PRO networks may, of course, contain battery-powered devices. ZigBee routers are required to31have their receivers enabled whenever they are not transmitting.32
As mentioned above, ZigBee-PRO networks are beaconless networks and, in the absence of an explicit33
mechanism for synchronization and indirect transmission, sleeping devices must set their own duty34
cycles and use polling, under ZDO control, if they expect to receive frames that are directed to them35
when they are asleep. The stack profile provides that parent devices, i.e. ZigBee routers and the ZigBee36
coordinator, hold frames for 7.5 seconds on behalf of sleeping end devices and this is also, roughly37
speaking, the maximum polling rate prescribed here. Devices may implement a polling interval longer38
than 7.5 seconds, however the application will then have to handle the potential loss of messages39
ZigBee-PRO Stack Profile, ZigBee Document 074855r054, October 2007
7.7 Mains powered devices1
It is assumed that for most ZigBee-PRO networks, the ZigBee coordinator and ZigBee routers will be2
mains-powered and always on in order to properly perform their required roles with respect to the3
operation of the network.4
7.8 Persistent storage5
The ZigBee-PRO stack profile does not support devices without persistent storage. Devices have6
information required to be saved between unintentional restarts and power failures. See [R1] sections7
2.2.8 and 3.6.8 for details of persistent data in the application and NWK layers. Various security8
material shall additionally be stored across power failures. All attributes in sections 4.3.3 and 4.4.109
shall be stored, except that it is not mandatory to store those values which can safely be recovered10
using other stored information, or other methods.11
7.9 Address Reuse12
Re-use of previously assigned network short addresses in ZigBee-PRO devices is permitted subject to13execution of the address conflict procedure by the device on the re-used address. 14
7.10 Duty cycle l imitat ions and fragmentation15
No mandatory restrictions are defined for intermittent, low channel usage data, although developers are16
encouraged to minimise bandwidth usage wherever possible.17
Large acknowledged unicast transmissions should generally use the APS fragmentation mechanism,18
where supported, as this handles retransmissions, duplicate rejection, flow control and congestion19
control automatically. Use of the fragmentation mechanism is as specified in the application profile20documents.21
7.10.1 Vulnerabil i ty join22
Vulnerability join shall be optional for networked devices, but support for it shall be mandatory for23
trust centers. The default for networks is permit joining is off. Permit joining is allowed for24
established time periods based on application requirements and specific instructions based on the25
system design.26
Devices that join but do not successfully acquire and use the relevant security keys within the specified27
security timeout period shall disassociate themselves from the network, and their short address may be28
reused.29
7.10.2 Pre-instal lat ion30
Pre-installation is acceptable. Pre-installed devices are not exempt from the other requirements in this31document. For example, a device certified as a trust center for this stack profile shall support32
vulnerability installation of new devices, even if it is initially pre-installed. 33
ZigBee Document 074855r05, October 2007 ZigBee-PRO Stack Profile
7.11 Security1
This stack profile is designed to allow the efficient deployment of low cost devices, while also2
supporting the security requirements of highly sensitive applications. Installation and network3
maintenance procedures and administration are defined with the goal of satisfying the requirements of4a range of applications within a single network infrastructure.5
To achieve this, two security modes are specified: Standard mode and High Security mode. By default6
all applications will use the network key for communications. However, where confidentiality from7
other network nodes is required an application shall be permitted to use application link keys. Where8
link keys are required by specific application profiles, commands not secured with a link key shall be9
processed according to the rules established by the application profile.10
The trust center plays a key role in determining the security settings in use in the network, and can11
optionally be implemented to apply further restrictions on the network. Please see section Error!12
Reference source not found. for details.13
It is recommended that the trust center change the network key if it is discovered that any device has14
been stolen or otherwise compromised, and in order to avoid deadlock if all frame counter records15
become filled up. It is an application responsibility within the Trust Center to effect the change to the16 network key. There is no expectation that the network key be changed when adding a new device.17
All devices may implement a service permissions table, which they may use to determine which18
devices are authorized to issue which commands. Unauthorized commands should not be carried out.19
The trust center should be implemented to make appropriate choices about when to initiate an20
application master/link key shared between two devices. Where restrictions between devices are21
required it is the responsibility of the system installer/administrator to deploy a suitably intelligent trust22
center and configure it to make relevant checks before initiating sharing of application link keys23
between two devices. For example, it might facilitate policies based on certain times, certain24
manufacturers or device types, or when the trust center is configured in a certain way, etc. By default a25
simple trust center should always allow requests for link keys.26
Devices may perform the relevant in or out of band authentication or key exchange before acquiring or27using a link key with a new target.28
7.11.1 Secur ity Modes within PRO Networks29
The stack profile shall use two security modes: Standard mode and High Security mode.30
With the Standard mode, network keys and application link keys are permitted for all devices. The31
network key type shall be the “standard” network key. It shall not be required that devices perform32
entity authentication with their parent on joining nor shall it be required to perform entity33
authentication between neighbors. If end devices wish to have a trust center link key, this should be34
requested using the request key command. Note that it is optional for the trust center to support link35
keys.36
With the High Security mode, all three key types are permitted and shall be supported by all devices.37
The network key type shall be the “high security” network key. It shall be required that devices shall38 perform entity authentication with their parent on joining and it shall be required to perform entity39
authentication between neighbors. Frames from devices not in the neighbor table shall not be accepted.40
When a “standard” type network key is in use, devices shall be permitted to update the network key41
when requested to do so by a command appropriately secured with the current network key. When a42
“high security” type of network key is in use this shall not be permitted. Additionally, in “high43
security”, new trust center link keys may be deployed by SKKE only, ie: they shall not be sent using44