Académique Documents
Professionnel Documents
Culture Documents
Document 053474r17
1
2
3
4
5
6
7
8
9
10
11
ZIGBEE SPECIFICATION 12
13
14
15
16
17
18
19
ZigBee Document 053474r17
20
January 17, 2008 11:09 am 21
Sponsored by: ZigBee Alliance 22
23
Accepted by ZigBee Alliance Board of Directors 24
Abstract The ZigBee Specification describes the infrastructure and services 25
available to applications operating on the ZigBee platform. 26
Keywords ZigBee, Stack, Network, Application, Profile, Framework, Device 27
Description, Binding, Security 28
29
30
31
32
33
34
January 17, 2008 35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
This page intentionally blank 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 i
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
This page intentionally blank 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 iii
DOCUMENT HISTORY 1
2
3
4
5
ZigBee Specification History 6
7
Version
Number Date Comments 8
9
December 14, 2004 ZigBee v.1.0 draft ratified 10
r06 February 17, 2006 ZigBee Specification (ZigBee document 11
number 053474r06/07) incorporating errata 12
and clarifications: ZigBee document 13
numbers 053920r02, 053954r02, 06084r00, 14
and 053474r07
15
r07 April 28, 2006 Changes made per Editorial comments on 16
spreadsheet, 17
r13 October 9, 2006 ZigBee-2006 Specification (see letter ballot 18
comments and resolution in ZigBee 19
document 064112) 20
r14 November 3, 2006 ZigBee-2007 Specification (adds features 21
described in 064270, 064269, 064268, 22
064281, 064319, and 064293) 23
r15 December 12, 2006 ZigBee-2007 Specification incorporating 24
errata and clarifications: 074746 25
r16 May 31, 2007 ZigBee-2007 Specification incorporating
26
errata and clarifications: 07819 27
28
r17 October 19, 2007 ZigBee-2007 specification incorporating
errata: 075318, 075053, 075164, 075098
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
iv Document History
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
This page intentionally blank 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 v
TABLE OF CONTENTS 1
2
3
4
Notice of Use and Disclosure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i 5
Document History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii 6
7
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi 8
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix 9
10
Chapter 1 ZigBee Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . 1 11
1.1 Protocol Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 12
1.1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 13
1.1.2 Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 14
1.1.3 Stack Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 15
16
1.1.4 Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
17
1.2 Conventions and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 18
1.2.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 19
1.3 Acronyms and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 20
1.4 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 21
1.4.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 22
23
1.5 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
24
1.5.1 ZigBee/IEEE References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 25
1.5.2 Normative References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 26
1.5.3 Informative References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 27
28
Chapter 2 Application Layer Specification . . . . . . . . . . . . . . . . . . . 17
29
2.1 General Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 30
2.1.1 Application Support Sub-Layer . . . . . . . . . . . . . . . . . . . . . . . 17 31
2.1.2 Application Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 32
2.1.3 ZigBee Device Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 33
2.2 ZigBee Application Support (APS) Sub-Layer . . . . . . . . . . . . . . . 19 34
35
2.2.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
36
2.2.2 Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 37
2.2.3 Application Support (APS) Sub-Layer Overview . . . . . . . . . 20 38
2.2.4 Service Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 39
2.2.5 Frame Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 40
2.2.6 Command Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 41
42
2.2.7 Constants and PIB Attributes. . . . . . . . . . . . . . . . . . . . . . . . . 60
43
2.2.8 Functional Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
vi Table of Contents
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
This page intentionally blank 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 xi
LIST OF TABLES 1
2
3
4
Table 1.1 ZigBee Protocol Versions . . . . . . . . . . . . . . . . . . . . . . . . . 7 5
Table 2.1 APSDE-SAP Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6
Table 2.2 APSDE-DATA.request Parameters . . . . . . . . . . . . . . . . . . 23 7
Table 2.3 APSDE-DATA.confirm Parameters . . . . . . . . . . . . . . . . . 28 8
Table 2.4 APSDE-DATA.indication Parameters . . . . . . . . . . . . . . . . 30 9
10
Table 2.5 Summary of the Primitives Accessed Through the
11
APSME-SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12
Table 2.6 APSME-BIND.request Parameters . . . . . . . . . . . . . . . . . . 34 13
Table 2.7 APSME-BIND.confirm Parameters . . . . . . . . . . . . . . . . . . 36 14
Table 2.8 APSME-UNBIND.request Parameters . . . . . . . . . . . . . . . 38 15
Table 2.9 APSME-UNBIND.confirm Parameters . . . . . . . . . . . . . . . 40 16
17
Table 2.10 APSME-GET.request Parameters . . . . . . . . . . . . . . . . . . 41
18
Table 2.11 APSME-GET.confirm Parameters . . . . . . . . . . . . . . . . . . 42 19
Table 2.12 APSME-SET.request Parameters . . . . . . . . . . . . . . . . . . . 43 20
Table 2.13 APSME-SET.confirm Parameters . . . . . . . . . . . . . . . . . . 44 21
Table 2.14 APSME-ADD-GROUP.request Parameters . . . . . . . . . . 45 22
Table 2.15 APSME-ADD-GROUP.confirm Parameters . . . . . . . . . . 46 23
24
Table 2.16 APSME-REMOVE-GROUP.request Parameters . . . . . . 47
25
Table 2.17 APSME-REMOVE-GROUP.confirm Parameters . . . . . . 49 26
Table 2.18 APSME-REMOVE-ALL-GROUPS.request Parameters . 50 27
Table 2.19 APSME-REMOVE-ALL-GROUPS.confirm Parameters 51 28
Table 2.20 Values of the Frame Type Sub-Field . . . . . . . . . . . . . . . . 52 29
Table 2.21 Values of the Delivery Mode Sub-Field . . . . . . . . . . . . . 53 30
31
Table 2.22 Values of the Fragmentation Sub-Field . . . . . . . . . . . . . . 56
32
Table 2.23 APS Sub-Layer Constants . . . . . . . . . . . . . . . . . . . . . . . . 60 33
Table 2.24 APS IB Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 34
Table 2.25 Group Table Entry Format . . . . . . . . . . . . . . . . . . . . . . . . 62 35
Table 2.26 APS Sub-layer Status Values . . . . . . . . . . . . . . . . . . . . . . 74 36
Table 2.27 ZigBee Descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 37
38
Table 2.28 Fields of the Node Descriptor . . . . . . . . . . . . . . . . . . . . . 81
39
Table 2.29 Values of the Logical Type Field . . . . . . . . . . . . . . . . . . . 82 40
Table 2.30 Values of the Frequency Band Field . . . . . . . . . . . . . . . . 83 41
Table 2.31 Server Mask Bit Assignments . . . . . . . . . . . . . . . . . . . . . 84 42
Table 2.32 Descriptor Capability Bit Assignments . . . . . . . . . . . . . . 85 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
xii List of Tables
LIST OF FIGURES 1
2
3
4
Figure 1.1 Outline of the ZigBee Stack Architecture . . . . . . . . . . . . 2 5
Figure 2.1 The APS Sub-Layer Reference Model . . . . . . . . . . . . . . . 21 6
Figure 2.2 General APS Frame Format . . . . . . . . . . . . . . . . . . . . . . . 52 7
Figure 2.3 Format of the Frame Control Field . . . . . . . . . . . . . . . . . . 52 8
Figure 2.4 Format of the Extended Header Sub-Frame . . . . . . . . . . . 55 9
10
Figure 2.5 Format of the Extended Frame Control Field . . . . . . . . . . 56
11
Figure 2.6 Data Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 12
Figure 2.7 APS Command Frame Format . . . . . . . . . . . . . . . . . . . . . 58 13
Figure 2.8 Acknowledgement Frame Format . . . . . . . . . . . . . . . . . . 58 14
Figure 2.9 Binding on a Device Supporting a Binding Table . . . . . . 65 15
Figure 2.10 Successful Data Transmission Without an 16
17
Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
18
Figure 2.11 Successful Data Transmission With an 19
Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 20
Figure 2.12 Successful Data Transmission With Fragmentation . . . . 72 21
Figure 2.13 Fragmented Data Transmission With a Single 22
Retransmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 23
24
Figure 2.14 Fragmented Data Transmission With Multiple
25
Retransmissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 26
Figure 2.15 Format of the Complex Descriptor . . . . . . . . . . . . . . . . . 80 27
Figure 2.16 Format of an Individual Complex Descriptor Field . . . . 80 28
Figure 2.17 Format of the MAC Capability Flags Field . . . . . . . . . . 83 29
Figure 2.18 Format of the Language and Character Set Field . . . . . . 90 30
31
Figure 2.19 Format of the ZDP Frame . . . . . . . . . . . . . . . . . . . . . . . . 97
32
Figure 2.20 Format of the NWK_addr_req Command . . . . . . . . . . . 99 33
Figure 2.21 Format of the IEEE_addr_req_Command Frame . . . . . . 101 34
Figure 2.22 Format of the Node_Desc_req Command Frame . . . . . . 102 35
Figure 2.23 Format of the Power_Desc_req Command Frame . . . . . 103 36
Figure 2.24 Format of the Simple_Desc_req Command Frame . . . . 104 37
38
Figure 2.25 Format of the Active_EP_req Command Frame . . . . . . 104
39
Figure 2.26 Format of the Match_Desc_req Command Frame . . . . . 105 40
Figure 2.27 Format of the Complex_Desc_req Command Frame . . . 107 41
Figure 2.28 Format of the User_Desc_req Command Frame . . . . . . 108 42
Figure 2.29 Format of the Discovery_Cache_req Command Frame . 109 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
xx List of Figures
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
This page intentionally blank 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 1
C H A P T E R
1
1
2
3
4
5
6
7
8
9
Each service entity exposes an interface to the upper layer through a service
access point (SAP), and each SAP supports a number of service primitives to 1
achieve the required functionality. 2
3
The IEEE 802.15.4-2003 standard defines the two lower layers: the physical 4
(PHY) layer and the medium access control (MAC) sub-layer. The ZigBee 5
Alliance builds on this foundation by providing the network (NWK) layer and the 6
framework for the application layer. The application layer framework consists of 7
the application support sub-layer (APS) and the ZigBee device objects (ZDO). 8
Manufacturer-defined application objects use the framework and share APS and 9
security services with the ZDO. 10
IEEE 802.15.4-2003 has two PHY layers that operate in two separate frequency 11
ranges: 868/915 MHz and 2.4 GHz. The lower frequency PHY layer covers both 12
the 868 MHz European band and the 915 MHz band, used in countries such as the 13
United States and Australia. The higher frequency PHY layer is used virtually 14
worldwide. A complete description of the IEEE 802.15.4-2003 PHY layers can be 15
found in [B1]. 16
17
The IEEE 802.15.4-2003 MAC sub-layer controls access to the radio channel 18
using a CSMA-CA mechanism. Its responsibilities may also include transmitting 19
beacon frames, synchronization, and providing a reliable transmission 20
mechanism. A complete description of the IEEE 802.15.4-2003 MAC sub-layer 21
can be found in [B1]. 22
23
Application (APL) Layer 24
Application Framework 25
ZigBee Stack 26
ZigBee Device Object 27
Architecture (ZDO)
ZDO Public
Application
Interfaces
Application
Object 240 … Object 1
28
29
Endpoint 240 Endpoint 1 Endpoint 0
30
APSDE-SAP APSDE-SAP APSDE-SAP
31
Application Support Sublayer (APS)
ZDO Management Plane
32
APSME-
SAP
IEEE 802.15.4
Security Message Routing Network
defined Broker Management Management 36
Management
ZigBee TM
Alliance
defined MLDE-SAP MLME-SAP
37
End manufacturer
Medium Access Control (MAC) Layer 38
defined 39
PLME-SAP
Layer
PD-SAP
Physical (PHY) Layer 40
function
2.4 GHz Radio 868/915 MHz Radio 41
Layer
interface 42
43
Figure 1.1 Outline of the ZigBee Stack Architecture 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 3
• Fields that are longer than a single octet are sent to the PHY in order from the
octet containing the lowest numbered bits to the octet containing the highest- 1
numbered bits. 2
3
1.2.1.4 Strings and String Operations 4
5
A string is a sequence of symbols over a specific set (e.g., the binary alphabet 6
{0,1} or the set of all octets). The length of a string is the number of symbols it 7
contains (over the same alphabet). The empty string has length 0. The right- 8
concatenation of two strings x and y of length m and n respectively (notation: x || 9
y), is the string z of length m+n that coincides with x on its leftmost m symbols 10
and with y on its rightmost n symbols. An octet is a symbol string of length 8. In 11
our context, all octets are strings over the binary alphabet. 12
13
14
1.3 Acronyms and Abbreviations 15
16
For the purposes of this standard, the following acronyms and abbreviations 17
apply: 18
19
AIB Application support layer information base
20
AF Application framework 21
APDU Application support sub-layer protocol data unit 22
23
APL Application layer
24
APS Application support sub-layer 25
APSDE Application support sub-layer data entity 26
27
APSDE-SAP Application support sub-layer data entity – service access point 28
APSME Application support sub-layer management entity 29
APSME-SAP Application support sub-layer management entity – service access point 30
31
ASDU APS service data unit 32
BRT Broadcast retry timer 33
34
BTR Broadcast transaction record
35
BTT Broadcast transaction table 36
CCM* Enhanced counter with CBC-MAC mode of operation 37
38
CSMA-CA Carrier sense multiple access – collision avoidance
39
EPID Extended PAN ID 40
FFD Full function device 41
42
GTS Guaranteed time slot
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 5
HDR Header
1
IB Information base 2
LQI Link quality indicator 3
4
LR-WPAN Low rate wireless personal area network
5
MAC Medium access control 6
MCPS-SAP Medium access control common part sub-layer – service access point 7
8
MIC Message integrity code
9
MLME-SAP Medium access control sub-layer management entity – service access point 10
MSC Message sequence chart 11
12
MSDU Medium access control sub-layer service data unit 13
MSG Message service type 14
NBDT Network broadcast delivery time 15
16
NHLE Next higher layer entity 17
NIB Network layer information base 18
19
NLDE Network layer data entity
20
NLDE-SAP Network layer data entity – service access point 21
NLME Network layer management entity 22
23
NLME-SAP Network layer management entity – service access point
24
NPDU Network layer protocol data unit 25
NSDU Network service data unit 26
27
NWK Network
28
OSI Open systems interconnection 29
PAN Personal area network 30
31
PD-SAP Physical layer data – service access point 32
PDU Protocol data unit 33
PHY Physical layer 34
35
PIB Personal area network information base 36
PLME-SAP Physical layer management entity – service access point 37
38
POS Personal operating space
39
QOS Quality of service 40
RFD Reduced function device 41
42
RREP Route reply
43
RREQ Route request 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 1
6 ZigBee Protocol Overview
RN Routing node
1
SAP Service access point 2
SKG Secret key generation 3
4
SKKE Symmetric-key key establishment
5
SSP Security services provider 6
SSS Security services specification 7
8
WPAN Wireless personal area network
9
XML Extensible markup language 10
ZB ZigBee 11
12
ZDO ZigBee device object 13
14
15
1.4 Glossary 16
17
18
1.4.1 Definitions 19
20
1.4.1.1 Conformance Levels 21
The conformance level definitions shall follow those in clause 13, section 1 of the 22
IEEE Style Manual [B13]. 23
24
Expected: A key word used to describe the behavior of the hardware or 25
software in the design models assumed by this Specification. Other hardware 26
and software design models may also be implemented. 27
May: A key word indicating a course of action permissible within the limits of 28
the standard (may equals is permitted to). 29
30
Shall: A key word indicating mandatory requirements to be strictly followed in 31
order to conform to the standard; deviations from shall are prohibited (shall 32
equals is required to). 33
Should: A key word indicating that, among several possibilities, one is 34
recommended as being particularly suitable, without mentioning or excluding 35
others; that a certain course of action is preferred but not necessarily required; 36
or, that (in the negative form) a certain course of action is deprecated but not 37
prohibited (should equals is recommended that). 38
39
Reserved Codes: A set of codes that are defined in this specification, but not 40
otherwise used. Future specifications may implement the use of these codes. A 41
product implementing this specification shall not generate these codes. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 7
Reserved Fields: A set of fields that are defined in this specification, but are
not otherwise used. Products that implement this specification shall zero these 1
fields and shall make no further assumptions about these fields nor perform 2
processing based on their content. 3
4
ZigBee Protocol Version: The name of the ZigBee protocol version governed 5
by this specification. The protocol version sub-field of the frame control field 6
in the NWK header of all ZigBee Protocol Stack frames conforming to this 7
specification shall have a value of 0x02. The protocol version support required 8
by various ZigBee specification revisions appears below in Table 1.1. 9
Table 1.1 ZigBee Protocol Versions 10
11
Protocol 12
Specification Version Comment
13
Current 0x02 Backwards compatibility with ZigBee 2006 14
required. 15
Backwards compatibility with ZigBee 2004 not 16
required. 17
ZigBee 2006 0x02 Backwards compatibility with ZigBee 2004 not 18
required. 19
ZigBee 2004 0x01 Original ZigBee version. 20
21
22
A ZigBee device that conforms to this version of the specification may elect to 23
provide backward compatibility with the 2004 revision of the specification. If it 24
so elects, it shall do so by supporting, in addition to the frame formats and 25
features described in this specification version, all frame formats and features 26
as specified in the older version. [All devices in an operating network, 27
regardless of which revisions of the ZigBee specification they support 28
internally, shall, with respect to their external, observable behavior, 29
consistently conform to a single ZigBee protocol version.] A single ZigBee 30
network shall not contain devices that conform, in terms of their external 31
behavior, to multiple ZigBee protocol versions. [The protocol version of the 32
network to join shall be determined by a backwardly compatible device in 33
examining the beacon payload prior to deciding to join the network; or shall be 34
established by the application if the device is a ZigBee coordinator.] A ZigBee 35
device conforming to this specification may elect to support only protocol 36
version 0x02, whereby it shall join only networks that advertise commensurate 37
beacon payload support. A ZigBee device that conforms to this specification 38
shall discard all frames carrying a protocol version sub-field value other than 39
0x01 or 0x02, and shall process only protocol versions of 0x01 or 0x02, 40
consistent with the protocol version of the network that the device participates 41
within. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 1
8 ZigBee Protocol Overview
Link key: This is a key that is shared exclusively between two, and only two,
peer application-layer entities within a PAN. 1
2
Master key: This is a shared key used during the execution of a symmetric-key 3
key establishment protocol. The master key is the basis for long-term security 4
between the two devices, and may be used to generate link keys. 5
Mesh network: This is a network in which the routing of messages is 6
performed as a decentralized, cooperative process involving many peer devices 7
routing on each other’s behalf. 8
9
Multicast: This is a transmission to every device in a particular PAN 10
belonging to a dynamically defined multicast group, and within a given 11
transmission radius measured in hops. 12
Multihop network: This is a network, in particular a wireless network, in 13
which there is no guarantee that the transmitter and the receiver of a given 14
message are connected or linked to each other. This implies that intermediate 15
devices must be used as routers. 16
17
Non-beacon-enabled personal area network: This is a personal area network 18
that does not contain any devices that transmit beacon frames at a regular 19
interval. 20
Neighbor table: This is a table used by a ZigBee device to keep track of other 21
devices within the POS. 22
23
Network address: This is the address assigned to a device by the network 24
layer and used by the network layer for routing messages between devices. 25
Network broadcast delivery time: This is the time required by a broadcast 26
transaction to reach every device of a given network. 27
28
Network manager: This is a ZigBee device that implements network 29
management functions as described in Clause 3, including PAN ID conflict 30
resolution and frequency agility measures in the face of interference. 31
Network protocol data unit: This is a unit of data that is exchanged between 32
the network layers of two peer entities. 33
34
Network service data unit: This is the information that is delivered as a unit 35
through a network service access point. 36
Node: This is a collection of independent device descriptions and applications 37
residing in a single unit and sharing a common 802.15.4 radio. 38
39
Normal operating state: This is the processing which occurs after all startup 40
and initialization processing has occurred and prior to initiation of shutdown 41
processing. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 1
12 ZigBee Protocol Overview
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
This page intentionally blank 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 17
C H A P T E R
1
2
2
3
4
5
6
7
8
9
objects. The ZDO interfaces with the lower portions of the ZigBee protocol stack,
on endpoint 0, through the APSDE-SAP for data, and through the APSME-SAP 1
and NLME-SAP for control messages. The public interface provides address 2
management of the device, discovery, binding, and security functions within the 3
application framework layer of the ZigBee protocol stack. The ZDO is fully 4
described in clause 2.5. 5
6
2.1.3.1 Device Discovery 7
8
Device discovery is the process whereby a ZigBee device can discover other 9
ZigBee devices. There are two forms of device discovery requests: IEEE address 10
requests and NWK address requests. The IEEE address request is unicast to a 11
particular device and assumes the NWK address is known. The NWK address 12
request is broadcast and carries the known IEEE address as data payload. 13
14
2.1.3.2 Service Discovery 15
Service discovery is the process whereby the capabilities of a given device are 16
discovered by other devices. Service discovery can be accomplished by issuing a 17
query for each endpoint on a given device or by using a match service feature 18
(either broadcast or unicast). The service discovery facility defines and utilizes 19
various descriptors to outline the capabilities of a device. 20
21
Service discovery information may also be cached in the network in the case 22
where the device proffering a particular service may be inaccessible at the time 23
the discovery operation takes place. 24
25
26
2.2 ZigBee Application Support (APS) Sub-Layer 27
28
29
2.2.1 Scope 30
31
This clause specifies the portion of the application layer providing the service 32
specification and interface to both the manufacturer-defined application objects 33
and the ZigBee device objects. The specification defines a data service to allow 34
the application objects to transport data, and a management service providing 35
mechanisms for binding. In addition, it also defines the application support sub- 36
layer frame format and frame-type specifications. 37
38
2.2.2 Purpose 39
40
The purpose of this clause is to define the functionality of the ZigBee application 41
support (APS) sub-layer. This functionality is based on both the driver 42
functionality necessary to enable correct operation of the ZigBee network layer 43
and the functionality required by the manufacturer-defined application objects. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
20 Application Layer Specification
The APS sub-layer provides two services, accessed through two service access
points (SAPs). These are the APS data service, accessed through the APS sub- 1
layer data entity SAP (APSDE-SAP), and the APS management service, accessed 2
though the APS sub-layer management entity SAP (APSME-SAP). These two 3
services provide the interface between the NHLE and the NWK layer, via the 4
NLDE-SAP and, to a limited extent, NLME-SAP interfaces (see sub-clause 3.1). 5
The NLME-SAP interface between the NWK layer and the APS sub-layer 6
supports only the NLME-GET and NLME-SET primitives; all other NLME-SAP 7
primitives are available only via the ZDO (see sub-clause 2.5). In addition to these 8
external interfaces, there is also an implicit interface between the APSME and the 9
APSDE that allows the APSME to use the APS data service. 10
11
2.2.4.1 APS Data Service 12
13
The APS sub-layer data entity SAP (APSDE-SAP) supports the transport of 14
application protocol data units between peer application entities. Table 2.1 lists 15
the primitives supported by the APSDE-SAP. Each of these primitives will be 16
discussed in the following sub-clauses. 17
Table 2.1 APSDE-SAP Primitives 18
19
APSDE- 20
SAP
Primitive Request Confirm Indication 21
22
APSDE- 2.2.4.1.1 2.2.4.1.2 2.2.4.1.3 23
DATA 24
25
2.2.4.1.1 APSDE-DATA.request 26
27
This primitive requests the transfer of a NHLE PDU (ASDU) from the local 28
NHLE to one or more peer NHLE entities. 29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 23
entries are found, then the APSDE examines the destination address information
in each binding table entry. If this indicates a device itself, then the APSDE shall 1
issue an APSDE-DATA.indication primitive to the next higher layer with the 2
DstEndpoint parameter set to the destination endpoint identifier in the binding 3
table entry. Otherwise, the APSDE constructs the APDU with the endpoint 4
information from the binding table entry, if present, and uses the destination 5
address information from the binding table entry when transmitting the frame via 6
the NWK layer. If more than one binding table entry is present, then the APSDE 7
processes each binding table entry as described above; until no more binding table 8
entries remain. If this primitive was received by the APSDE of a device that does 9
not support a binding table, the APSDE issues the APSDE-DATA.confirm 10
primitive with a status of NOT_SUPPORTED. 11
12
If the DstAddrMode parameter is set to 0x03, the DstAddress parameter contains 13
an extended 64-bit IEEE address and must first be mapped to a corresponding 16- 14
bit NWK address by using the nwkAddressMap attribute of the NIB (see 15
Table 3.43). If a corresponding 16-bit NWK address could not be found, the 16
APSDE issues the APSDE-DATA.confirm primitive with a status of 17
NO_SHORT_ADDRESS. If a corresponding 16-bit NWK address is found, it will 18
be used in the invocation of the NLDE-DATA.request primitive and the value of 19
the DstEndpoint parameter will be placed in the resulting APDU. The delivery 20
mode sub-field of the frame control field of the APS header shall have a value of 21
0x00 in this case. 22
If the DstAddrMode parameter has a value of 0x01, indicating group addressing, 23
the DstAddress parameter will be interpreted as a 16-bit group address. This 24
address will be placed in the group address field of the APS header, the 25
DstEndpoint parameter will be ignored, and the destination endpoint field will be 26
omitted from the APS header. The delivery mode sub-field of the frame control 27
field of the APS header shall have a value of 0x03 in this case. 28
29
If the DstAddrMode parameter is set to 0x02, the DstAddress parameter contains 30
a 16-bit NWK address, and the DstEndpoint parameter is supplied. The next 31
higher layer should only employ DstAddrMode of 0x02 in cases where the 32
destination NWK address is employed for immediate application responses and 33
the NWK address is not retained for later data transmission requests. 34
The application may limit the number of hops a transmitted frame is allowed to 35
travel through the network by setting the RadiusCounter parameter of the NLDE- 36
DATA.request primitive to a non-zero value. 37
38
If the DstAddrMode parameter has a value of 0x01, indicating group addressing, 39
or the DstAddrMode parameter has a value of 0x00 and the corresponding binding 40
table entry contains a group address, then the APSME will check the value of the 41
nwkUseMulticast attribute of the NIB (see Table 3.44). If this attribute has a value 42
of FALSE, then the delivery mode sub-field of the frame control field of the 43
resulting APDU will be set to 0b11, the 16-bit address of the destination group 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
26 Application Layer Specification
will be placed in the group address field of the APS header of the outgoing frame,
and the NSDU frame will be transmitted as a broadcast. A value of 0xfffd, that is, 1
the broadcast to all devices for which macRxOnWhenIdle = TRUE, will be 2
supplied for the DstAddr parameter of the NLDE-DATA.request that is used to 3
transmit the frame. If the nwkUseMulticast attribute has a value of TRUE, then the 4
outgoing frame will be transmitted using NWK layer multicast, with the delivery 5
mode sub-field of the frame control field of the APDU set to 0b10, the destination 6
endpoint field set to 0xff, and the group address not placed in the APS header. 7
8
If the TxOptions parameter specifies that secured transmission is required, the 9
APS sub-layer shall use the security service provider (see sub-clause 4.2.3) to 10
secure the ASDU. If the security processing fails, the APSDE shall issue the 11
APSDE-DATA.confirm primitive with a status of SECURITY_FAIL. 12
The APSDE transmits the constructed frame by issuing the NLDE-DATA.request 13
primitive to the NWK layer. When the APSDE has completed all operations 14
related to this transmission request, including transmitting frames as required, any 15
retransmissions, and the receipt or timeout of any acknowledgements, then the 16
APSDE shall issue the APSDE-DATA.confirm primitive (see sub- 17
clause 2.2.4.1.2). If one or more NLDE-DATA.confirm primitives failed, then the 18
Status parameter shall be set to that received from the NWK layer. Otherwise, if 19
one or more APS acknowledgements were not correctly received, then the Status 20
parameter shall be set to NO_ACK. If the ASDU was successfully transferred to 21
all intended targets, then the Status parameter shall be set to SUCCESS. 22
23
If NWK layer multicast is being used, the NonmemberRadius parameter of the 24
NLDE-DATA.request primitive shall be set to apsNonmemberRadius. 25
The APSDE will ensure that route discovery is always enabled at the network 26
layer by setting the DiscoverRoute parameter of the NLDE-DATA.request 27
primitive to 0x01, each time it is issued. 28
29
If the ASDU to be transmitted is larger than will fit in a single frame and 30
fragmentation is not possible, then the ASDU is not transmitted and the APSDE 31
shall issue the APSDE-DATA.confirm primitive with a status of 32
ASDU_TOO_LONG. Fragmentation is not possible if either an acknowledged 33
transmission is not requested, or if the fragmentation permitted flag in the 34
TxOptions field is set to 0, or if the ASDU is too large to be handled by the 35
APSDE. 36
If the ASDU to be transmitted is larger than will fit in a single frame, an 37
acknowledged transmission is requested, and the fragmentation permitted flag of 38
the TxOptions field is set to 1, and the ASDU is not too large to be handled by the 39
APSDE, then the ASDU shall be fragmented across multiple APDUs, as 40
described in sub-clause 2.2.8.4.5. Transmission and security processing where 41
requested, shall be carried out for each individual APDU independently. Note that 42
fragmentation shall not be used unless relevant higher-layer documentation and/or 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 27
interactions explicitly indicate that fragmentation is permitted for the frame being
sent, and that the other end is able to receive the fragmented transmission, both in 1
terms of number of blocks and total transmission size. 2
3
2.2.4.1.2 APSDE-DATA.confirm 4
The primitive reports the results of a request to transfer a data PDU (ASDU) from 5
a local NHLE to one or more peer NHLEs. 6
7
2.2.4.1.2.1 Semantics of the Service Primitive 8
9
This semantics of this primitive are as follows: 10
11
APSDE-DATA.confirm {
12
DstAddrMode, 13
DstAddress, 14
DstEndpoint, 15
SrcEndpoint, 16
Status, 17
TxTime 18
} 19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
28 Application Layer Specification
If the Status parameter is not set to SUCCESS, the APSDE sets the ASDULength
parameter to 0 and the ASDU parameter to the null set of bytes. 1
2
The APS sub-layer entity shall attempt to map the source address from the 3
received frame to its corresponding extended 64-bit IEEE address by using the 4
nwkAddressMap attribute of the NIB (see Table 3.43). If a corresponding 64-bit 5
IEEE address was found, the APSDE issues this primitive with the SrcAddrMode 6
parameter set to 0x03 and the SrcAddress parameter set to the corresponding 64- 7
bit IEEE address. If a corresponding 64-bit IEEE address was not found, the 8
APSDE issues this primitive with the SrcAddrMode parameter set to 0x02, and 9
the SrcAddress parameter set to the 16-bit source address as contained in the 10
received frame. 11
12
2.2.4.1.3.3 Effect on Receipt 13
On receipt of this primitive, the next higher layer is notified of the arrival of data 14
at the device. 15
16
2.2.4.2 APS Management Service 17
18
The APS management entity SAP (APSME-SAP) supports the transport of 19
management commands between the next higher layer and the APSME. Table 2.5 20
summarizes the primitives supported by the APSME through the APSME-SAP 21
interface. See the following sub-clauses for more details on the individual 22
primitives. 23
Table 2.5 Summary of the Primitives Accessed Through the APSME-SAP 24
25
Name Request Indication Response Confirm 26
APSME-BIND 2.2.4.3.1 2.2.4.3.2
27
28
APSME-UNBIND 2.2.4.3.3 2.2.4.3.4 29
APSME-GET 2.2.4.4.1 2.2.4.4.2 30
31
APSME-SET 2.2.4.4.3 2.2.4.4.4
32
APSME-ADD-GROUP 2.2.4.5.1 2.2.4.5.2 33
APSME-REMOVE- 2.2.4.5.3 2.2.4.5.4 34
GROUP 35
APSME-REMOVE- 2.2.4.5.5 2.2.4.5.6
36
ALL-GROUPS 37
38
39
2.2.4.3 Binding Primitives 40
This set of primitives defines how the next higher layer of a device can add 41
(commit) a binding record to its local binding table or remove a binding record 42
from its local binding table. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
34 Application Layer Specification
Only a device supporting a binding table or a binding table cache may process
these primitives. If any other device receives these primitives from their next 1
higher layer, the primitives should be rejected. 2
3
2.2.4.3.1 APSME-BIND.request 4
This primitive allows the next higher layer to request to bind two devices together, 5
or to bind a device to a group, by creating an entry in its local binding table, if 6
supported. 7
8
2.2.4.3.1.1 Semantics of the Service Primitive 9
10
The semantics of this primitive are as follows: 11
12
APSME-BIND.request {
13
SrcAddr, 14
SrcEndpoint, 15
ClusterId, 16
DstAddrMode, 17
DstAddr, 18
DstEndpoint 19
} 20
21
Table 2.6 specifies the parameters for the APSME-BIND.request primitive. 22
23
Table 2.6 APSME-BIND.request Parameters 24
Name Type Valid Range Description 25
26
SrcAddr IEEE A valid 64-bit The source IEEE address for the binding 27
address IEEE address entry. 28
SrcEndpoint Integer 0x01 – 0xf0 The source endpoint for the binding entry. 29
ClusterId Integer 0x0000 – 0xffff The identifier of the cluster on the source
30
device that is to be bound to the destination 31
device. 32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 35
2.2.4.4.2 APSME-GET.confirm
1
This primitive reports the results of an attempt to read the value of an attribute 2
from the AIB. 3
4
2.2.4.4.2.1 Semantics of the Service Primitive 5
6
The semantics of this primitive are as follows:
7
APSME-GET.confirm { 8
Status, 9
AIBAttribute, 10
AIBAttributeLength, 11
AIBAttributeValue
12
13
}
14
15
Table 2.11 specifies the parameters for this primitive. 16
Table 2.11 APSME-GET.confirm Parameters 17
18
Name Type Valid Range Description 19
Status Enumeration SUCCESS or The results of the request to read an 20
UNSUPPORTED AIB attribute value. 21
_ATTRIBUTE 22
AIBAttribute Integer See Table 2.24 The identifier of the AIB attribute 23
that was read. 24
AIBAttributeLength Integer 0x0001 - 0xffff The length, in octets, of the
25
attribute value being returned. 26
27
AIBAttributeValue Various Attribute specific The value of the AIB attribute that
28
(see Table 2.24) was read.
29
30
2.2.4.4.2.2 When Generated 31
This primitive is generated by the APSME and issued to its next higher layer in 32
response to an APSME-GET.request primitive. This primitive returns a status of 33
SUCCESS, indicating that the request to read an AIB attribute was successful, or 34
an error code of UNSUPPORTED_ATTRIBUTE. The reasons for these status 35
values are fully described in sub-clause 2.2.4.4.1.3. 36
37
38
2.2.4.4.2.3 Effect on Receipt
39
On receipt of this primitive, the next higher layer is notified of the results of its 40
request to read an AIB attribute. If the request to read an AIB attribute was 41
successful, the Status parameter will be set to SUCCESS. Otherwise, the Status 42
parameter indicates the error. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 43
2.2.4.4.3 APSME-SET.request
1
This primitive allows the next higher layer to write the value of an attribute into 2
the AIB. 3
4
2.2.4.4.3.1 Semantics of the Service Primitive 5
6
The semantics of this primitive are as follows:
7
APSME-SET.request { 8
AIBAttribute, 9
AIBAttributeLength, 10
AIBAttributeValue 11
}
12
13
14
Table 2.12 specifies the parameters for this primitive. 15
Table 2.12 APSME-SET.request Parameters 16
17
Name Type Valid Range Description 18
AIBAttribute Integer See Table 2.24. The identifier of the AIB attribute to be 19
written. 20
AIBAttributeLength Integer 0x0000 - 0xffff The length, in octets, of the attribute 21
value being set. 22
23
AIBAttributeValue Various Attribute specific The value of the AIB attribute that should
(see Table 2.24). be written. 24
25
26
2.2.4.4.3.2 When Generated 27
This primitive is to be generated by the next higher layer and issued to its APSME 28
in order to write the value of an attribute in the AIB. 29
30
2.2.4.4.3.3 Effect on Receipt 31
32
On receipt of this primitive, the APSME attempts to write the given value to the 33
indicated AIB attribute in its database. If the AIBAttribute parameter specifies an 34
attribute that is not found in the database, the APSME issues the APSME- 35
SET.confirm primitive with a status of UNSUPPORTED_ATTRIBUTE. If the 36
AIBAttributeValue parameter specifies a value that is outside the valid range for 37
the given attribute, the APSME issues the APSME-SET.confirm primitive with a 38
status of INVALID_PARAMETER. 39
If the requested AIB attribute is successfully written, the APSME issues the 40
APSME-SET.confirm primitive with a status of SUCCESS. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
44 Application Layer Specification
2.2.4.4.4 APSME-SET.confirm
1
This primitive reports the results of an attempt to write a value to an AIB attribute. 2
3
2.2.4.4.4.1 Semantics of the Service Primitive 4
5
The semantics of this primitive are as follows:
6
APSME-SET.confirm { 7
Status, 8
AIBAttribute 9
} 10
11
12
Table 2.13 specifies the parameters for this primitive. 13
Table 2.13 APSME-SET.confirm Parameters 14
15
Name Type Valid Range Description
16
Status Enumeration SUCCESS, The result of the request to 17
INVALID_PARAMETER or write the AIB Attribute. 18
UNSUPPORTED_ATTRIBUTE 19
AIBAttribute Integer See Table 2.24. The identifier of the AIB 20
attribute that was written. 21
22
2.2.4.4.4.2 When Generated 23
24
This primitive is generated by the APSME and issued to its next higher layer in 25
response to an APSME-SET.request primitive. This primitive returns a status of 26
either SUCCESS, indicating that the requested value was written to the indicated 27
AIB attribute, or an error code of INVALID_PARAMETER or 28
UNSUPPORTED_ATTRIBUTE. The reasons for these status values are 29
completely described in sub-clause 2.2.4.4.3.3. 30
31
2.2.4.4.4.3 Effect on Receipt 32
33
On receipt of this primitive, the next higher layer is notified of the results of its
34
request to write the value of a AIB attribute. If the requested value was written to
35
the indicated AIB attribute, the Status parameter will be set to SUCCESS.
36
Otherwise, the Status parameter indicates the error.
37
2.2.4.5 Group Management 38
39
This set of primitives allows the next higher layer to manage group membership 40
for endpoints on the current device by adding and removing entries in the group 41
table. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 45
2.2.4.5.1 APSME-ADD-GROUP.request
1
This primitive allows the next higher layer to request that group membership for a 2
particular group be added for a particular endpoint. 3
4
2.2.4.5.1.1 Semantics of the Service Primitive 5
6
The semantics of this primitive are as follows:
7
APSME-ADD-GROUP.request { 8
GroupAddress, 9
Endpoint 10
} 11
12
13
Table 2.14 specifies the parameters for this primitive. 14
Table 2.14 APSME-ADD-GROUP.request Parameters 15
16
Name Type Valid Range Description
17
GroupAddress 16-bit 0x0000 - 0xffff The 16-bit address of the 18
group group being added. 19
address 20
Endpoint Integer 0x01 - 0xf0 The endpoint to which the 21
given group is being 22
added. 23
24
2.2.4.5.1.2 When Generated 25
26
This primitive is generated by the next higher layer when it wants to add 27
membership in a particular group to an endpoint, so that frames addressed to the 28
group will be delivered to that endpoint in the future. 29
30
2.2.4.5.1.3 Effect on Receipt 31
If, on receipt of this primitive, the GroupAddress parameter is found to be outside 32
the valid range, then the APSME will issue the APSME-ADD-GROUP.confirm 33
primitive to the next higher layer with a status value of INVALID_PARAMETER. 34
Similarly, if the Endpoint parameter has a value which is out of range or else 35
enumerates an endpoint that is not implemented on the current device, the 36
APSME will issue the APSME-ADD-GROUP.confirm primitive with a Status of 37
INVALID_PARAMETER. 38
39
After checking the parameters as described above, the APSME will check the 40
group table to see if an entry already exists containing the values given by the 41
GroupAddress and Endpoint parameters. If such an entry already exists in the 42
table then the APSME will issue the APSME-ADD-GROUP.confirm primitive to 43
the next higher layer with a status value of SUCCESS. If there is no such entry 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
46 Application Layer Specification
and there is space in the table for another entry then the APSME will add a new
entry to the group table with the values given by the GroupAddress and Endpoint 1
parameters. After the entry is added to the APS group table, and if the NWK layer 2
is maintaining a group table, then the APSME ensures that the corresponding 3
NWK group table is consistent by issuing the NLME-SET.request primitive, for 4
the nwkGroupIDTable attribute, with the list of group addresses contained in the 5
group table of the APS sub-layer. Once both tables are consistent, the APSME 6
issues the APSME-ADD-GROUP.confirm primitive to the next higher layer with 7
a status value of SUCCESS. If no entry for the given GroupAddress and Endpoint 8
is present but there is no room in the group table for another entry, then the 9
APSME will issue the APSME-ADD-GROUP.confirm primitive to the next 10
higher layer with a status value of TABLE_FULL. 11
12
2.2.4.5.2 APSME-ADD-GROUP.confirm 13
This primitive allows the next higher layer to be informed of the results of its 14
request to add a group to an endpoint. 15
16
2.2.4.5.2.1 Semantics of the Service Primitive 17
18
The semantics of the service primitive are as follows: 19
20
APSME-ADD-GROUP.confirm {
21
Status, 22
GroupAddress, 23
Endpoint 24
} 25
26
Table 2.15 specifies the parameters for this primitive. 27
28
Table 2.15 APSME-ADD-GROUP.confirm Parameters
29
Name Type Valid Range Description 30
31
Status Enumeration SUCCESS, The status of the request to
32
INVALID_PARAMETER add a group.
or TABLE_FULL 33
34
GroupAddress 16-bit group 0x0000 - 0xffff The 16-bit address of the
35
address group being added.
36
Endpoint Integer 0x01 - 0xf0 The endpoint to which the 37
given group is being 38
added.
39
40
2.2.4.5.2.2 When Generated 41
This primitive is generated by the APSME and issued to the next higher layer in 42
response to an APMSE-ADD-GROUP.request primitive. If the APSME-ADD- 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 47
for being equal to zero. If such a reserved field is not equal to zero, no further
processing shall be applied to the frame and the frame shall be discarded. 1
2
2.2.5.1 General APDU Frame Format 3
4
The APS frame format is composed of an APS header and an APS payload. The 5
fields of the APS header appear in a fixed order, however, the addressing fields 6
may not be included in all frames. The general APS frame shall be formatted as 7
illustrated in Figure 2.2. 8
9
Octets: 0/
1 0/1 0/2 0/2 0/2 0/1 1 Variable Variable 10
11
Frame Destination Group Cluster Profile Source APS Extended Frame 12
control endpoint address identifier identifier endpoint counter header payload 13
Addressing fields 14
15
APS header APS
payload 16
17
Figure 2.2 General APS Frame Format 18
19
2.2.5.1.1 Frame Control Field 20
The frame control field is 8-bits in length and contains information defining the 21
frame type, addressing fields, and other control flags. The frame control field shall 22
be formatted as illustrated in Figure 2.3. 23
24
Bits: 0-1 2-3 4 5 6 7 25
26
Frame type Delivery mode Ack. formata Security Ack. request Extended
header
27
present 28
29
a. CCB #813 30
Figure 2.3 Format of the Frame Control Field 31
32
2.2.5.1.1.1 Frame Type Sub-Field 33
34
The frame type sub-field is two bits in length and shall be set to one of the non- 35
reserved values listed in Table 2.20. 36
Table 2.20 Values of the Frame Type Sub-Field 37
38
Frame Type Value 39
b1 b0 Frame Type Name
40
00 Data 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 53
set to 0 for data frame acknowledgement and 1 for APS command frame
acknowledgement.1 1
2
2.2.5.1.1.4 Security Sub-Field 3
4
The Security Services Provider (see Chapter 4) manages the security sub-field. 5
6
2.2.5.1.1.5 Acknowledgement Request Sub-Field 7
8
The acknowledgement request sub-field is one bit in length and specifies whether 9
the current transmission requires an acknowledgement frame to be sent to the 10
originator on receipt of the frame. If this sub-field is set to 1, the recipient shall 11
construct and send an acknowledgement frame back to the originator after 12
determining that the frame is valid. If this sub-field is set to 0, the recipient shall 13
not send an acknowledgement frame back to the originator. 14
This sub-field shall be set to 0 for all frames that are broadcast or multicast. 15
16
2.2.5.1.1.6 Extended Header Present 17
18
The extended header present sub-field is one bit in length and specifies whether 19
the extended header shall be included in the frame. If this sub-field is set to 1, then 20
the extended header shall be included in the frame. Otherwise, it shall not be 21
included in the frame. 22
2.2.5.1.2 Destination Endpoint Field 23
24
The destination endpoint field is 8-bits in length and specifies the endpoint of the 25
final recipient of the frame. This field shall be included in the frame only if the 26
delivery mode sub-field of the frame control field is set to 0b00 (normal unicast 27
delivery), 0b01 (indirect delivery where the indirect address mode sub-field of the 28
frame control field is also set to 0), or 0b10 (broadcast delivery). In the case of 29
broadcast delivery, the frame shall be delivered to the destination endpoint 30
specified within the range 0x01-0xf0 or to all active endpoints if specified as 0xff. 31
A destination endpoint value of 0x00 addresses the frame to the ZigBee device 32
object (ZDO), resident in each device. A destination endpoint value of 0x01-0xf0 33
addresses the frame to an application operating on that endpoint. A destination 34
endpoint value of 0xff addresses the frame to all active endpoints except endpoint 35
0x00. All other endpoints (0xf1-0xfe) are reserved. 36
37
2.2.5.1.3 Group Address Field 38
The group address field is 16 bits in length and will only be present if the delivery 39
mode sub-field of the frame control has a value of 0b11. In this case, the 40
destination endpoint shall not be present. If the APS header of a frame contains a 41
42
43
1. CCB #813 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 55
group address field, the frame will be delivered to all endpoints for which the
group table in the device contains an association between that endpoint and the 1
group identified by the contents of the group address field. 2
3
Devices where nwkUseMulticast is set to TRUE shall never set the group address 4
field of an outgoing frame. 5
2.2.5.1.4 Cluster Identifier Field 6
7
The cluster identifier field is 16 bits in length and specifies the identifier of the 8
cluster to which the frame relates and which shall be made available for filtering 9
and interpretation of messages at each device that takes delivery of the frame. 10
This field shall be present only for data or acknowledgement frames. 11
2.2.5.1.5 Profile Identifier Field 12
13
The profile identifier is two octets in length and specifies the ZigBee profile 14
identifier for which the frame is intended and shall be used during the filtering of 15
messages at each device that takes delivery of the frame. This field shall be 16
present only for data or acknowledgement frames. 17
2.2.5.1.6 Source Endpoint Field 18
19
The source endpoint field is eight-bits in length and specifies the endpoint of the 20
initial originator of the frame. A source endpoint value of 0x00 indicates that the 21
frame originated from the ZigBee device object (ZDO) resident in each device. A 22
source endpoint value of 0x01-0xf0 indicates that the frame originated from an 23
application operating on that endpoint. All other endpoints (0xf1-0xff) are 24
reserved. 25
26
2.2.5.1.7 APS Counter
27
This field is eight bits in length and is used as described in sub-clause 2.2.8.4.2 to 28
prevent the reception of duplicate frames. This value shall be incremented by one 29
for each new transmission. 30
31
2.2.5.1.8 Extended Header Sub-Frame 32
The extended header sub-frame contains further sub-fields and shall be formatted 33
as illustrated in Figure 2.4. 34
35
Octets: 1 0/1 0/1 36
Extended frame control Block number ACK bitfield
37
38
Figure 2.4 Format of the Extended Header Sub-Frame 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
56 Application Layer Specification
The order of the fields of the acknowledgement frame shall conform to the order
of the general APS frame as illustrated in Figure 2.2. 1
2
2.2.5.2.3.1 Acknowledgement Frame APS Header Fields 3
4
If the ack format field is not set in the frame control field, the destination 5
endpoint, cluster identifier, profile identifier and source endpoint shall be present. 6
This is not set for data frame acknowledgement.2 Both the source and destination 7
endpoint fields shall be included in an acknowledgement frame. The extended 8
header field shall be included in a data frame according to the value of the 9
extended header present sub-field of the frame control field. 10
In the frame control field, the frame type sub-field shall contain the value that 11
indicates an acknowledgement frame, as shown in Table 2.20. The extended 12
header present sub-field shall contain the same value as in the frame to which this 13
frame is an acknowledgement. All other sub-fields shall be set appropriately 14
according to the intended use of the acknowledgement frame. 15
16
If the ack format field is set in the frame control field, the frame is an APS 17
command frame acknowledgement and the destination endpoint, cluster identifier, 18
profile identifier and source endpoint fields shall not be set.3 Alternatively, if an 19
APS data frame is being acknowledged, the source endpoint field shall reflect the 20
value in the destination endpoint field of the frame that is being acknowledged. 21
Similarly, the destination endpoint field shall reflect the value in the source 22
endpoint field of the frame that is being acknowledged. 23
The APS counter field shall contain the same value as the frame to which this 24
frame is an acknowledgment. 25
26
Where the extended header is present, the fragmentation sub-field of the extended 27
frame control field shall contain the same value as in the frame to which this 28
frame is an acknowledgement. If fragmentation is in use for this frame, then the 29
block number and ack bitfield fields shall be present. Where present, the block 30
number field shall contain the value zero if this is the first frame of a fragmented 31
transmission, and otherwise shall contain the same value as in the frame to which 32
this frame is an acknowledgement. 33
34
2.2.6 Command Frames 35
36
This specification defines no command frames. Refer to sub-clause 4.4.9 for a 37
thorough description of the APS command frames and primitives related to 38
security. 39
40
41
42
2. CCB #813 43
3. CCB #813 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
60 Application Layer Specification
• apsUseExtendedPANID
1
• apsUseInsecureJoin 2
• apsGroupTable (if supported on the device) 3
4
• Binding Table Cache (if the device is designated as a primary or backup 5
binding table cache, see clause 2.4.2.4) 6
• Discovery Cache (if the device is designated as a primary discovery cache, see 7
clause 2.4.2.1) 8
9
• Node Descriptor, Power Descriptor plus the Simple Descriptor(s) for each 10
active endpoint on the device 11
• Network manager address4 12
13
The method by which these data are made to persist is beyond the scope of this
14
specification. 15
16
2.2.8.2 Binding 17
The APS may maintain a binding table, which allows ZigBee devices to establish 18
a designated destination for frames from a given source endpoint and with a given 19
cluster ID. Each designated destination shall represent either a specific endpoint 20
on a specific device, or a group address. 21
22
2.2.8.2.1 Binding Table Implementation 23
A device designated as containing a binding table shall be able to support a 24
binding table of implementation-specific length. The binding table shall 25
implement the following mapping: 26
27
(as, es, cs) = {(ad1|, ed1|), (ad2|, ed2|) … (adn|, edn |)} 28
29
30
Where: 31
as = the address of the device as the source of the binding link. 32
33
es = the endpoint identifier of the device as the source of the binding link.
34
cs = the cluster identifier used in the binding link. 35
adi = the ith destination address or destination group address associated with the binding link. 36
37
edi = the ith optional destination endpoint identifier associated with the binding link. Note that 38
edi will only be present when adi is a device address.
39
40
41
42
43
4. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
64 Application Layer Specification
2.2.8.2.2 Binding
1
The APSME-BIND.request or APSME-UNBIND.request primitives initiate the 2
procedure for creating or removing a binding link. Only a device supporting a 3
binding table cache, or a device that wishes to store source bindings, shall initiate 4
this procedure. If this procedure is initiated by another type of device, then the 5
APSME shall issue the APSME-BIND.confirm or APSME-UNBIND.confirm 6
primitive with the Status parameter set to ILLEGAL_REQUEST. 7
When this procedure is initiated, the APSME shall first extract the address and 8
endpoint for both the source and destination of the binding link. If the 9
DstAddrMode parameter has a value of 0x01, indicating group addressing, then 10
only the source address is treated in the way just described. The 16-bit group 11
address is used directly as a destination address and, in this case, no destination 12
endpoint is specified. With this information, the APSME shall either create a new 13
entry or remove the corresponding entry from its binding table, depending on 14
whether the bind or unbind procedure, respectively, was initiated. 15
16
If a bind operation was requested, the APSME shall create a new entry in the 17
binding table. The device shall only create a new entry in the binding table if it has 18
the capacity to do so. If the binding table does not have capacity, then the APSME 19
shall issue the APSME-BIND.confirm primitive with the Status parameter set to 20
TABLE_FULL. 21
If an unbind operation was requested, the APSME shall search the binding table 22
for an existing entry that matches the information contained in the initiation 23
request. If an entry is not found, the APSME shall terminate the procedure and 24
notify the NHLE of the invalid binding. This is achieved by issuing the APSME- 25
UNBIND.confirm primitive with the Status parameter set to 26
INVALID_BINDING. If an entry is found, the APSME shall remove the entry in 27
the binding table. 28
29
If the binding link is successfully created or removed, the APSME shall notify the 30
NHLE of the results of the binding attempt and the success of the procedure. This 31
is achieved by issuing the APSME-BIND.confirm or APSME-UNBIND.confirm 32
primitive, respectively, with the binding results and the Status parameter set to 33
SUCCESS. 34
The procedure for a successful binding is illustrated in the MSC shown in 35
Figure 2.9. 36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 65
1
APL APS NWK 2
3
APSME- 4
(UN)BIND.request 5
6
Create a new entry or 7
remove an existing entry 8
in the binding table 9
APSME- 10
(UN)BIND.confirm 11
12
13
14
Figure 2.9 Binding on a Device Supporting a Binding Table 15
16
2.2.8.3 Group Addressing 17
18
The APS sub-layer shall maintain a group table, which allows endpoints to be 19
associated with groups and allows group-addressed frames to be delivered 20
selectively to those endpoints that are associated in the table with a particular 21
group. 22
The list of group addresses in the APS sub-layer group table shall be kept 23
consistent with the list of group IDs in the NWK layer group table, stored in the 24
nwkGroupIDTable attribute. 25
26
2.2.8.3.1 The Group Table 27
For purposes of this discussion, the group table shall be viewed as a set of 28
associations between groups and endpoints as follows: 29
30
{(g1 - ep11, ep12…ep1n), (g2 - ep21, ep22… ep2m)… (gi - epi1, epi2… epik)} 31
32
33
where:
34
gi = the ith group represented in the table. 35
epij = the jth endpoint associated with the ith group.
36
37
38
Implementers of this specification are free to implement the group table in any 39
manner that is convenient and efficient, as long as it represents the associations 40
just described. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
66 Application Layer Specification
If fragmentation is required, and is permitted for this frame, then the frame shall
be processed as described in clause 2.2.8.4.5. 1
2
When the frame is constructed and ready for transmission, it shall be passed to the 3
NWK data service with suitable destination and source addresses. In addition, the 4
APS layer shall ensure that route discovery is enabled at the network layer. An 5
APDU transmission is initiated by issuing the NLDE-DATA.request primitive to 6
the NWK layer and the results of the transmission returned via the NLDE- 7
DATA.confirm primitive. 8
2.2.8.4.2 Reception and Rejection 9
10
The APS sub-layer shall be able to filter frames arriving via the NWK layer data 11
service and only present the frames that are of interest to the NHLE. 12
If the APSDE receives a secured frame, it shall process the frame as described in 13
clause 4.4 to remove the security. 14
15
If the APSDE receives a frame containing the destination endpoint field, then the 16
APSDE shall pass it directly to the NHLE at the destination endpoint supplied, 17
unless it is part of an incomplete fragmented transmission or it is determined to 18
have been a duplicate of a frame that has been passed up previously. Subject to the 19
same incomplete fragmented transmission and duplicate frame detection, if the 20
destination endpoint is set to the broadcast endpoint (0xff) and the DstAddrMode 21
parameter of the received NLDE-DATA.indication primitive was not 0x01, then 22
the APSDE shall also present the frame to all non-reserved endpoints (0x01-0xf0) 23
supported by the NHLE. 24
If the APSDE of a device receives a transmission with the delivery mode sub-field 25
of the frame control field set to 0b11, indicating group addressing, it shall deliver 26
the frame to each endpoint on the device that is associated in the group table with 27
the 16-bit group address found in the group address field of the APS header. 28
Similarly, if the APSDE of a device receives a NLDE-DATA.indication primitive 29
where the DstAddrMode parameter has a value of 0x01, also indicating group 30
addressing, it shall deliver the frame to each endpoint on the device that is 31
associated in the group table with the 16-bit group address given as the value of 32
the DstAddr parameter. In either case, it shall search the group table and, for each 33
endpoint associated with the given group address, it shall issue the NLDE- 34
DATA.indication primitive to the next higher layer with a value of the 35
DstEndpoint parameter equal to the number of the associated endpoint. All other 36
parameters of the NLDE-DATA.indication primitive shall remain the same for all 37
instances of the primitive issued. 38
39
The APSDE shall maintain a duplicate rejection table to include at least source 40
address, APS counter, and timing information, such that frames transmitted 41
according to this specification and received more than once are identified as 42
duplicates and only delivered to the NHLE once. The size of this table shall be at 43
least apscMinDuplicateRejectionTableSize. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
68 Application Layer Specification
Originator Recipient 1
next higher Originator Recipient next higher
layer APS APS layer 2
APSDE-DATA.request (AR=1)
3
Data (AR=1) 4
5
Acknowldgement
6
APSDE-DATA.indication
7
APSDE-DATA.confirm 8
9
10
11
Figure 2.11 Successful Data Transmission With an Acknowledgement 12
13
2.2.8.4.4 Retransmissions 14
A device that sends a frame with its acknowledgement request sub-field set to 0 15
shall assume that the transmission was successfully received and shall hence not 16
perform the retransmission procedure. 17
18
A device that sends a frame with its acknowledgement request sub-field set to 1 19
shall wait for a maximum of apscAckWaitDuration seconds for the corresponding 20
acknowledgement frame to be received. 21
If an acknowledgement frame is received within apscAckWaitDuration seconds, 22
containing the same cluster identifier and APS counter as the original frame and 23
has a source endpoint equal to the destination endpoint to which the original frame 24
was transmitted, the transmission shall be considered successful and no further 25
action shall be taken by the device. If an acknowledgement is not received within 26
apscAckWaitDuration seconds, or an acknowledgement is received within 27
apscAckWaitDuration seconds but contains an unexpected cluster identifier or 28
APS counter or has a source endpoint that is not equal to the destination endpoint 29
to which the original frame was transmitted, the device shall conclude that the 30
single transmission attempt has failed. 31
32
If a single transmission attempt has failed, the device shall repeat the process of 33
transmitting the frame and waiting for the acknowledgement, up to a maximum of 34
apscMaxFrameRetries times. If an acknowledgement is still not received after 35
apscMaxFrameRetries retransmissions, the APS sub-layer shall assume the 36
transmission has failed and notify the next higher layer of the failure. 37
Retransmissions of a secured frame shall use the same frame counter as the 38
original frame. 39
40
2.2.8.4.5 Fragmented Transmissions 41
Where an ASDU is too large to be transmitted within a single MAC data frame, an 42
acknowledged unicast transmission was requested, and fragmentation is permitted 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
70 Application Layer Specification
for this frame, the ASDU shall be fragmented into a number of smaller byte
strings, here referred to as “blocks.” Each block is transmitted in a separate frame. 1
2
A “transmission window” is used to arrange an orderly transaction. The window 3
size is set by the stack profile, and may be set as high as eight blocks. The protocol 4
below arranges that all blocks in a transmission window must be received and 5
acknowledged before the window can move on. An acknowledgement is sent 6
when all blocks in the transmission window have been successfully received or, 7
according to the protocol below, to request retransmission of one or more 8
unreceived blocks. 9
Transactions not using APS acknowledgements may not be fragmented. Multicast 10
and broadcast transmissions are not permitted to use fragmentation. 11
12
2.2.8.4.5.1 Transmission 13
14
All blocks in a fragmented transmission shall have the same APS Counter value. 15
The extended header sub-frame shall be included in the frame. The fragmentation 16
sub-field of the extended frame control field shall be set to 0b01 for the first block 17
and 0b10 for all subsequent blocks of the a fragmented transmission. The block 18
number field shall indicate the total number of blocks in the transmission in the 19
first block, shall take the value 0x01 in the second block, and thereafter shall be 20
incremented for each subsequent block. 21
A transmission window shall be maintained, initially covering blocks 0 to 22
(apscMaxWindowSize-1), or the total number of blocks if this is less. 23
24
If security is required, then each frame shall be processed independently, as 25
described in clause 4. Following transmission of each block, the APS shall start a 26
timer. If there are more unacknowledged blocks to send in the current 27
transmission window, then after a delay of apsInterframeDelay milliseconds the 28
next block shall be passed to the NWK data service. Otherwise, the timer shall be 29
set for apscAckWaitDuration seconds. 30
A retryCounter parameter shall be maintained and is reset to zero for each new 31
transaction. If an apscAckWaitDuration timer expires, then the block with the 32
lowest unacknowledged block number shall be passed to the NWK data service 33
again, and the retryCounter parameter shall be incremented. If the retryCounter 34
parameter reaches the value apscMaxFrameRetries, the transaction shall be 35
deemed to have failed, and an APSDE-DATA.confirm primitive returned to the 36
NHLE with a status value of NO_ACK. 37
38
On receipt of an acknowledgement frame with matching values in the APS 39
counter, block number, and addressing fields, outgoing blocks are acknowledged 40
as described in the section below. If at least one previously unacknowledged block 41
is acknowledged, then the timer shall be stopped and the retryCounter parameter 42
reset. If all blocks in the current transmission window have been acknowledged, 43
then the transmission window shall be increased by apscMaxWindowSize. If all 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 71
blocks have now been transmitted and acknowledged, then the transaction is
complete, and an APSDE-DATA.confirm primitive shall be returned to the NHLE 1
with a status value of SUCCESS. Otherwise, the block with the lowest 2
unacknowledged block number shall be passed to the NWK data service. 3
4
2.2.8.4.5.2 Reception and Rejection, and Acknowledgements 5
6
If the fields required for a fragmentation-enabled transmission are not present in 7
the frame it shall be rejected. Also, any frames with parameters that fall outside 8
the bounds of this protocol shall be rejected. 9
If an incoming fragmented transaction is already in progress but the addressing 10
and APS counter fields do not match those of the received frame, then the 11
received frame may optionally be rejected or handled independently as a further 12
transaction. 13
14
If no transaction is in progress and a fragmented frame is received, then 15
reassembly shall be attempted. Initially the receive window shall be from 0 to 16
(apscMaxWindowSize-1). 17
If a transaction is initiated with APS counter and source address field values 18
matching a previously received transaction, then the new transaction may be 19
rejected as a duplicate. 20
21
If the receive window does not move forward within any (apscAckWaitDuration 22
+ apscAckWaitDuration * apscMaxFrameRetries) time period, the transaction 23
shall be deemed to have failed. The receiver shall send an acknowledgement to 24
the sender with the block or blocks missed.5 25
If all blocks in the current receive window have been received and a block is 26
received with a block number higher than the current receive window, then the 27
receive window shall be increased by apsMaxWindowSize blocks. 28
29
If the last block in the transaction is received, or if a block is received with its 30
block number value equal to or higher than the highest previously 31
unacknowledged block number in the window, then an acknowledgement shall be 32
generated. 33
Once all blocks in the transaction have been received, the APS shall issue an 34
APSDE-DATA.indication primitive containing the reassembled message, and the 35
transaction shall be deemed to be complete. A period of persistence of 36
apscAckWaitDuration seconds is encouraged in order to facilitate any 37
retransmission of the final acknowledgement. 38
39
Where generated, the acknowledgement is formatted according to the 40
acknowledgement frame format specified in sub-clause 2.2.5.2.3. The APS 41
counter field shall reflect the value in the corresponding field of the frame(s) 42
43
5. CCB #817 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
72 Application Layer Specification
being acknowledged. The block number field shall contain the value of the lowest
block number in the current receive window, using the value 0 as the value of the 1
first block. 2
3
The first bit of the ack bitfield shall be set to 1 if the first fragment in the current 4
receive window has been correctly received, and 0 otherwise. Subsequent bits 5
shall be set similarly, with values corresponding to subsequent fragments in the 6
current receive window. If apsMaxWindowSize is less than 8, then the remaining 7
bits shall be set to 1. 8
The process is illustrated in the following diagrams. In Figure 2.12, the 9
transmission is successful immediately. (These examples assume that 10
apscMaxWindowSize takes the value 3). 11
12
13
Originator Recipient
14
next higher
Originator
APS
Recipient
APS
next higher 15
layer layer
16
17
APSDE-DATA.request
Data (first fragment,
18
block number=5) 19
Data (block number=1, …)
20
21
Data (block number=2, …)
22
Acknowledgement
(block number=0, …,
23
Ack bitfield=0xFF) 24
Data (block number=3, …) 25
26
Data (block number=4, …)
27
Acknowledgement
(block number=3, …, APSDE-DATA.indication
28
APSDE-DATA.confirm
Ack bitfield=0xFF) 29
30
31
32
33
34
35
Figure 2.12 Successful Data Transmission With Fragmentation
36
37
In Figure 2.13, a single frame is lost during transit across the network, and is
38
retransmitted.
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 73
Originator Recipient
1
Originator Recipient
next higher
APS APS
next higher 2
layer layer
3
4
APSDE-DATA.request
Data (first fragment,
5
block number=5) 6
Data (block number=1, …)
7
8
Data (block number=2, …)
9
Acknowledgement
(block number=0, …, 10
Ack bitfield=0xFD) 11
Data (block number=1, …) 12
Acknowledgement 13
(block number=0, …, 14
Ack bitfield=0xFF)
15
Data (block number=3, …) 16
Data (block number=4, …) 17
Acknowledgement 18
(block number=3, …, APSDE-DATA.indication 19
Ack bitfield=0xFF)
APSDE-DATA.confirm 20
21
22
Figure 2.13 Fragmented Data Transmission With a Single Retransmission
23
24
In Figure 2.14, multiple frames are lost in the network, including a frame which
25
has the highest block number in the window. Slightly more traffic is required in
26
this case, but the source backs off and gives the network a chance to recover, and
27
the ASDU is delivered successfully.
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
74 Application Layer Specification
Originator Recipient 1
Originator Recipient
next higher
APS APS
next higher 2
layer layer
3
APSDE-DATA.request
Data (first fragment, 4
block number=5) 5
Data (block number=1, …) 6
7
Data (block number=2, …)
8
apsFragmentation-
RetryTimeout 9
seconds Data (block number=0, …) 10
Data (block number=1, …) 11
Data (block number=2, …)
12
Acknowledgement
13
(block number=0, …, 14
Ack bitfield=0xFF) 15
Data (block number=3, …) 16
Data (block number=4, …) 17
Acknowledgement 18
(block number=3, …, APSDE-DATA.indication 19
Ack bitfield=0xFF)
APSDE-DATA.confirm 20
21
22
Figure 2.14 Fragmented Data Transmission With Multiple Retransmissions
23
24
2.2.9 APS Sub-Layer Status Values 25
26
Application support (APS) sub-layer confirm primitives often include a parameter 27
that reports on the status of the request to which the confirmation applies. Values 28
for APS sub-layer Status parameters appear in Table 2.26. 29
Table 2.26 APS Sub-layer Status Values 30
31
Name Value Description 32
SUCCESS 0x00 A request has been executed successfully.
33
34
ASDU_TOO_LONG 0xa0 A transmit request failed since the ASDU is 35
too large and fragmentation is not supported.
36
DEFRAG_DEFERRED 0xa1 A received fragmented frame could not be 37
defragmented at the current time. 38
DEFRAG_UNSUPPORTED 0xa2 A received fragmented frame could not be 39
defragmented since the device does not 40
support fragmentation. 41
ILLEGAL_REQUEST 0xa3 A parameter value was out of range. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 75
add new features, the revisions could either be incorporated directly into public
profile identifier “XX” if such extensions are supported via the definition of the 1
profile, or could be introduced into a new public profile with a new profile 2
identifier (say “XY”). Assuming extensibility is not supported in public profile 3
“XX,” devices manufactured with just profile identifier “XX” could still be 4
compatible with newer devices manufactured later by having the newer devices 5
advertise support for both profile identifier “XX” and profile identifier “XY.” In 6
this manner, the newer device may communicate with older devices using profile 7
identifier “XX,” however, it may also communicate with newer devices using 8
profile identifier “XY” from within the same application. The service discovery 9
feature within ZigBee enables devices on the network to determine the level of 10
support. 11
12
It is the goal of the ZigBee Alliance to provide extensibility, both for 13
manufacturer extensions to public profiles as well as future enhancements to 14
public profiles. That goal includes maintaining those extensions and 15
enhancements within the same profile identifier whenever possible. This section 16
illustrates that the profile definition features within ZigBee permit deployment of 17
manufacturer extensions and feature enhancements, whether the goal of profile 18
extensibility is achievable or not. The subject of profile extensibility, both for 19
manufacturer extensions and feature enhancements, is beyond the scope of this 20
document and addressed in other Alliance documents. 21
22
2.3.2 ZigBee Descriptors 23
24
ZigBee devices describe themselves using descriptor data structures. The actual 25
data contained in these descriptors is defined in the individual device descriptions. 26
There are five descriptors: node, node power, simple, complex, and user, shown in 27
Table 2.27. 28
29
Table 2.27 ZigBee Descriptors
30
Descriptor 31
Name Status Description 32
33
Node M Type and capabilities of the node.
34
Node power M Node power characteristics. 35
Simple M Device descriptions contained in node. 36
37
Complex O Further information about the device descriptions.
38
User O User-definable descriptor. 39
40
2.3.2.1 Transmission of Descriptors 41
42
The node, node power, simple, and user descriptors shall be transmitted in the 43
order that they appear in their respective tables, i.e., the field at the top of the table 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
80 Application Layer Specification
is transmitted first and the field at the bottom of the table is transmitted last. Each
individual field shall follow the transmission order specified in sub-clause 1.2.1.4. 1
2
Each descriptor shall be less than or equal to apscMaxDescriptorSize unless 3
provision has been made to enable transmission of discovery information without 4
the mandatory use of fragmentation. 5
In the case of the Simple Descriptor (see 2.3.2.5), transmission primitives exist 6
which permit the descriptor to extend beyond apscMaxDescriptorSize (see 7
2.4.3.1.21 and 2.4.4.1.20). When extended transmission primitives are employed, 8
the standard transmission primitives (see 2.4.3.1.5 and 2.4.4.1.5) require 9
transmission of an abbreviated Simple Descriptor, and the Node Descriptor of the 10
device shall indicate availability of extended transmission primitives (see 11
2.3.2.3.12). 12
13
The complex descriptor shall be formatted and transmitted as illustrated in 14
Figure 2.15. 15
16
Octets: 1 Variable … Variable 17
Field count Field 1 … Field n 18
19
Figure 2.15 Format of the Complex Descriptor
20
21
Each field included in the complex descriptor shall be formatted as illustrated in 22
Figure 2.16. 23
24
Octets: 1 Variable 25
26
Compressed Field data 27
XML tag 28
Figure 2.16 Format of an Individual Complex Descriptor Field 29
30
2.3.2.1.1 Field Count Field 31
32
The field count field is one octet in length and specifies the number of fields 33
included in the Complex Descriptor, each formatted as illustrated in Figure 2.16. 34
35
2.3.2.1.1.1 Compressed XML Tag Field 36
The compressed XML tag field is one octet in length and specifies the XML tag 37
for the current field. The compressed XML tags for the complex descriptor are 38
listed in Table 2.40. 39
40
41
2.3.2.1.1.2 Field Data Field
42
The field data field has a variable length and contains the information specific to 43
the current field, as indicated by the compressed XML tag field. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 81
802.15.4 radio, the corresponding bit of the frequency band field, as listed in
Table 2.30, shall be set to 1. All other bits shall be set to 0. 1
2
Table 2.30 Values of the Frequency Band Field
3
Frequency 4
Band Field Bit Supported 5
Number Frequency Band 6
0 868 – 868.6 MHz 7
8
1 Reserved 9
2 902 – 928 MHz 10
3 2400 – 2483.5 MHz
11
12
4 Reserved 13
14
2.3.2.3.6 MAC Capability Flags Field 15
16
The MAC capability flags field is eight bits in length and specifies the node 17
capabilities, as required by the IEEE 802.15.4-2003 MAC sub-layer [B1]. The 18
MAC capability flags field shall be formatted as illustrated in Figure 2.17. 19
Bits: 0 1 2 3 4-5 6 7 20
21
Alternate Device Power Receiver on Reserved Security Allocate 22
PAN type source when idle capability address 23
coordinator
24
Figure 2.17 Format of the MAC Capability Flags Field 25
26
The alternate PAN coordinator sub-field is one bit in length and shall be set to 1 if 27
this node is capable of becoming a PAN coordinator. Otherwise, the alternative 28
PAN coordinator sub-field shall be set to 0. 29
30
The device type sub-field is one bit in length and shall be set to 1 if this node is a
31
full function device (FFD). Otherwise, the device type sub-field shall be set to 0,
32
indicating a reduced function device (RFD).
33
The power source sub-field is one bit in length and shall be set to 1 if the current 34
power source is mains power. Otherwise, the power source sub-field shall be set to 35
0. This information is derived from the node current power source field of the 36
node power descriptor. 37
38
The receiver on when idle sub-field is one bit in length and shall be set to 1 if the
39
device does not disable its receiver to conserve power during idle periods.
40
Otherwise, the receiver on when idle sub-field shall be set to 0 (see also sub-
41
clause 2.3.2.4.)
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
84 Application Layer Specification
The security capability sub-field is one bit in length and shall be set to 1 if the
device is capable of sending and receiving frames secured using the security suite 1
specified in [B1]. Otherwise, the security capability sub-field shall be set to 0. 2
3
The allocate address sub-field is one bit in length and shall be set to 0 or 1.6 4
2.3.2.3.7 Manufacturer Code Field 5
6
The manufacturer code field of the node descriptor is sixteen bits in length and 7
specifies a manufacturer code that is allocated by the ZigBee Alliance, relating the 8
manufacturer to the device. 9
2.3.2.3.8 Maximum Buffer Size Field 10
11
The maximum buffer size field of the node descriptor is eight bits in length, with a 12
valid range of 0x00-0x7f. This field specifies the maximum size, in octets, of the 13
network sub-layer data unit (NSDU) for this node. This is the maximum size of 14
data or commands passed to or from the application by the application support 15
sub-layer, before any fragmentation or re-assembly. 16
This field can be used as a high-level indication for network management. 17
18
2.3.2.3.9 Maximum Incoming Transfer Size Field 19
20
The maximum transfer size field of the node descriptor is sixteen bits in length,
21
with a valid range of 0x0000-0x7fff. This field specifies the maximum size, in
22
octets, of the application sub-layer data unit (ASDU) that can be transferred to this
23
node in one single message transfer. This value can exceed the value of the node
24
maximum buffer size field (see sub-clause 2.3.2.3.8) through the use of
25
fragmentation.
26
2.3.2.3.10 Server Mask Field 27
28
The server mask field of the node descriptor is sixteen bits in length, with bit 29
settings signifying the system server capabilities of this node. It is used to 30
facilitate discovery of particular system servers by other nodes on the system. The 31
bit settings are defined inTable 2.31. 32
Table 2.31 Server Mask Bit Assignments 33
34
Bit Number Assignment
35
0 Primary Trust Center 36
1 Backup Trust Center 37
38
2 Primary Binding Table Cache 39
3 Backup Binding Table Cache 40
41
4 Primary Discovery Cache
42
43
6. CCB #841 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 85
power source selected, the corresponding bit of the current power source field, as
listed in Table 2.36, shall be set to 1. All other bits shall be set to 0. 1
2
Table 2.36 Values of the Current Power Sources Field
3
Current Power Source 4
Field Bit Number Current Power Source 5
6
0 Constant (mains) power
7
1 Rechargeable battery 8
2 Disposable battery 9
10
3 Reserved
11
12
2.3.2.4.4 Current Power Source Level Field 13
The current power source level field of the node power descriptor is four bits in 14
length and specifies the level of charge of the power source. The current power 15
source level field shall be set to one of the non-reserved values listed in 16
Table 2.37. 17
18
Table 2.37 Values of the Current Power Source Level Field 19
Current Power Source 20
Level Field b3b2b1b0 Charge Level 21
22
0000 Critical 23
0100 33% 24
1000 66%
25
26
1100 100% 27
All other values Reserved 28
29
30
2.3.2.5 Simple Descriptor 31
The simple descriptor contains information specific to each endpoint contained in 32
this node. The simple descriptor is mandatory for each endpoint present in the 33
node. 34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
88 Application Layer Specification
The fields of the simple descriptor are shown in Table 2.38 in their order of
transmission. As this descriptor needs to be transmitted over air, the overall length 1
of the simple descriptor shall be less than or equal to apscMaxDescriptorSize. 2
3
Table 2.38 Fields of the Simple Descriptor
4
Field Name Length (Bits) 5
6
Endpoint 8 7
Application profile identifier 16 8
Application device identifier 16 9
10
Application device version 4 11
Reserved 4 12
13
Application input cluster count 8
14
Application input cluster list 16*i (where i is the value of the application 15
input cluster count) 16
Application output cluster count 8 17
Application output cluster list 16*o (where o is the value of the application 18
output cluster count) 19
20
21
2.3.2.5.1 Endpoint Field
22
The endpoint field of the simple descriptor is eight bits in length and specifies the 23
endpoint within the node to which this description refers. Applications shall only 24
use endpoints 1-240. 25
26
2.3.2.5.2 Application Profile Identifier Field
27
The application profile identifier field of the simple descriptor is sixteen bits in 28
length and specifies the profile that is supported on this endpoint. Profile 29
identifiers shall be obtained from the ZigBee Alliance. 30
31
2.3.2.5.3 Application Device Identifier Field 32
The application device identifier field of the simple descriptor is sixteen bits in 33
length and specifies the device description supported on this endpoint. Device 34
description identifiers shall be obtained from the ZigBee Alliance. 35
36
2.3.2.5.4 Application Device Version Field 37
The application device version field of the simple descriptor is four bits in length 38
and specifies the version of the device description supported on this endpoint. The 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 89
application device version field shall be set to one of the non-reserved values
listed in Table 2.39. 1
2
Table 2.39 Values of the Application Device Version Field
3
Application Device Version 4
Value b3b2b1b0 Description 5
6
0000-1111 Specific values to be set by the
application profile described by the 7
application profile identifier in this 8
descriptor. Default shall be 0000 unless 9
otherwise defined by the application 10
profile. 11
12
2.3.2.5.5 Application Input Cluster Count Field 13
14
The application input cluster count field of the simple descriptor is eight bits in
15
length and specifies the number of input clusters, supported on this endpoint, that
16
will appear in the application input cluster list field. If the value of this field is
17
zero, the application input cluster list field shall not be included.
18
2.3.2.5.6 Application Input Cluster List 19
20
The application input cluster list of the simple descriptor is 16*i bits in length, 21
where i is the value of the application input cluster count field. This field specifies 22
the list of input clusters supported on this endpoint, for use during the service 23
discovery and binding procedures. 24
The application input cluster list field shall be included only if the value of the 25
application input cluster count field is greater than zero. 26
27
2.3.2.5.7 Application Output Cluster Count Field 28
The application output cluster count field of the simple descriptor is eight bits in 29
length and specifies the number of output clusters, supported on this endpoint, that 30
will appear in the application output cluster list field. If the value of this field is 31
zero, the application output cluster list field shall not be included. 32
33
2.3.2.5.8 Application Output Cluster List 34
The application output cluster list of the simple descriptor is 16*o bits in length, 35
where o is the value of the application output cluster count field. This field 36
specifies the list of output clusters supported on this endpoint, for use during the 37
service discovery and binding procedures. 38
39
The application output cluster list field shall be included only if the value of the 40
application output cluster count field is greater than zero. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
90 Application Layer Specification
The character set identifier sub-field is one octet in length and specifies the
encoding used by the characters in the character set. This sub-field shall be set to 1
one of the non-reserved values listed in Table 2.41. 2
3
Table 2.41 Values of the Character Set Identifier Sub-Field
4
Character Set Bits Per 5
Identifier Value Character Description 6
7
0x00 8 ISO 646, ASCII character set. Each character is fitted into
the least significant 7 bits of an octet with the most 8
significant bit set to zero (see also [B6]). 9
10
0x01 – 0xff - Reserved.
11
12
If the language and character sets have not been specified, the language shall 13
default to English (language code = “EN”) and the character set to ISO 646. 14
2.3.2.6.2 Manufacturer Name Field 15
16
The manufacturer name field has a variable length and contains a character string 17
representing the name of the manufacturer of the device. 18
2.3.2.6.3 Model Name Field 19
20
The model name field has a variable length and contains a character string 21
representing the name of the manufacturers model of the device. 22
23
2.3.2.6.4 Serial Number Field
24
The serial number field has a variable length and contains a character string 25
representing the manufacturers serial number of the device. 26
27
2.3.2.6.5 Device URL Field
28
The device URL field has a variable length and contains a character string 29
representing the URL through which more information relating to the device can 30
be obtained. 31
32
2.3.2.6.6 Icon Field 33
The icon field has a variable length and contains an octet string which carries the 34
data for an icon that can represent the device on a computer, gateway, or PDA. 35
The format of the icon shall be a 32-by-32-pixel PNG image. 36
37
2.3.2.6.7 Icon URL Field 38
The icon URL field has a variable length and contains a character string 39
representing the URL through which the icon for the device can be obtained. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
92 Application Layer Specification
the clusters within the ZigBee Device Profile define capabilities supported in all
ZigBee devices. As with any profile document, this document details the 1
mandatory and/or optional clusters. 2
3
4
2.4.2 Device Profile Overview 5
6
The Device Profile supports four key inter-device communication functions 7
within the ZigBee protocol. These functions are explained in the following 8
sections: 9
• Device and Service Discovery Overview 10
11
• End Device Bind Overview 12
• Bind and Unbind Overview 13
14
• Binding Table Management Overview 15
• Network Management Overview 16
17
2.4.2.1 Device and Service Discovery Overview 18
19
Device and Service Discovery are distributed operations where individual devices 20
or designated discovery cache devices respond to discovery requests. The “device 21
address of interest” field enables responses from either the device itself or a 22
discovery cache device. In selected cases where both the discovery cache device 23
and the “device address of interest” device respond, the response from the “device 24
address of interest” shall be used. 25
The following capabilities exist for device and service discovery: 26
27
• Device Discovery: Provides the ability for a device to determine the identity of 28
other devices on the PAN. Device Discovery is supported for both the 64-bit 29
IEEE address and the 16-bit Network address. 30
• Device Discovery messages can be used in one of two ways: 31
32
—Broadcast addressed: All devices on the network shall respond accord- 33
ing to the Logical Device Type and the matching criteria. ZigBee End 34
Devices shall respond with just their address. ZigBee Coordinators and 35
ZigBee Routers with associated devices shall respond with their address 36
as the first entry followed by the addresses of their associated devices 37
depending on the type of request. The responding devices shall employ 38
APS acknowledged service on the unicast responses. 39
40
—Unicast addressed: Only the specified device responds. A ZigBee End 41
Device shall respond only with its address. A ZigBee Coordinator or 42
Router shall reply with its own address and the address of each associ- 43
ated child device. Inclusion of the associated child devices allows the 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
94 Application Layer Specification
• Provides the ability for a primary binding table cache to request that a
specific entry be removed from the backup binding table cache (after 1
receiving an unbind request). 2
3
• Backing up of the entire binding table: 4
• Provides the ability for a primary binding table cache to request backup of 5
its entire binding table, using the backup binding table cache. 6
7
• Restoring the entire binding table: 8
• Provides the ability for a primary binding table cache to request restoration 9
of its entire binding table, using the backup binding table cache. 10
11
• Backing up the Primary Binding Table Cache: 12
• Provides the ability for a primary binding table cache to request backup of 13
its entire source devices address table (which contains the addresses of any 14
source device containing its own binding table). 15
16
• Restoring the Primary Binding Table Cache: 17
• Provides the ability for a primary binding table cache to request restoration 18
of its entire source devices address table (which contains the addresses of 19
any source device containing its own binding table). 20
21
2.4.2.5 Network Management Overview 22
23
The following capabilities exist for network management: 24
• Provides the ability to retrieve management information from the devices 25
including: 26
27
• Network discovery results 28
• Link quality to neighbor nodes 29
30
• Routing table contents 31
• Binding table contents 32
33
• Discovery cache contents 34
• Energy detection scan results 35
36
• Provides the ability to set management information controls including: 37
• Network leave 38
39
• Network direct join 40
• Permit joining 41
42
• Network update and fault notification 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 97
The transaction sequence number field can be used by a controlling device, which
may have issued multiple commands, so that it can match the incoming responses 1
to the relevant command. 2
3
2.4.2.8.2 Transaction Data Field 4
The transaction data field has a variable length and contains the data for the 5
individual ZDP transaction. The format and length of this field is dependent on 6
the command being transmitted, as defined in sub-clauses 2.4.3 and 2.4.4. 7
8
9
2.4.3 Client Services 10
11
The Device Profile Client Services support the transport of device and service 12
discovery requests, end device binding requests, bind requests, unbind requests, 13
and network management requests from client to server. Additionally, Client 14
Services support receipt of responses to these requests from the server. 15
16
2.4.3.1 Device and Service Discovery Client Services 17
Table 2.43 lists the commands supported by Device Profile, Device, and Service 18
Discovery Client Services. Each of these commands will be discussed in the 19
following sub-clauses. 20
21
Table 2.43 Device and Service Discovery Client Services Commands 22
Device and Service 23
Discovery Client Server 24
Client Services Transmission Processing 25
26
NWK_addr_req O M
27
IEEE_addr_req O M 28
Node_Desc_req O M 29
30
Power_Desc_req O M
31
Simple_Desc_req O M 32
Active_EP_req O M 33
34
Match_Desc_req O M 35
Complex_Desc_req O O 36
User_Desc_req O O 37
38
Discovery_Cache_req O O 39
Device_annce O M 40
41
User_Desc_set O O
42
System_Server_Discover_req O O 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 99
Table 2.43 Device and Service Discovery Client Services Commands (Continued)
1
Discovery_store_req O O
2
Node_Desc_store_req O O 3
Power_Desc_store_req O O 4
5
Active_EP_store_req O O 6
Simple_Desc_store_req O O 7
Remove_node_cache_req O O 8
9
Find_node_cache_req O O 10
Extended_Simple_Desc_req O O 11
12
Extended_Active_EP_req O O
13
14
2.4.3.1.1 NWK_addr_req 15
The NWK_addr_req command (ClusterID=0x0000) shall be formatted as 16
illustrated in Figure 2.20. 17
18
Octets: 8 1 1 19
20
IEEEAddress RequestType StartIndex
21
Figure 2.20 Format of the NWK_addr_req Command 22
23
Table 2.44 specifies the fields of the NWK_addr_req Command Frame. 24
Table 2.44 Fields of the NWK_addr_req Command 25
26
Name Type Valid Range Description 27
IEEEAddr IEEE A valid 64-bit IEEE The IEEE address to be matched by the
28
Address address Remote Device 29
30
RequestType Integer 0x00-0xff Request type for this command:
31
0x00 – Single device response 32
0x01 – Extended response 33
34
0x02-0xFF – reserved
35
StartIndex Integer 0x00-0xff If the Request type for this command is 36
Extended response, the StartIndex 37
provides the starting index for the
38
requested elements of the associated
devices list 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
100 Application Layer Specification
2.4.3.1.2 IEEE_addr_req
1
The IEEE_addr_req command (ClusterID=0x0001) shall be formatted as 2
illustrated in Figure 2.21. 3
4
Octets: 2 1 1
5
NWKAddrOfInterest RequestType StartIndex 6
7
Figure 2.21 Format of the IEEE_addr_req_Command Frame 8
9
Table 2.45 specifies the fields of the IEEE_addr_req command frame. 10
Table 2.45 Fields of the IEEE_addr_req Command 11
12
Name Type Valid Range Description
13
NWKAddrOfInterest Device 16-bit NWK address NWK address that is used for IEEE 14
Address address mapping. 15
RequestType Integer 0x00-0xff Request type for this command: 16
17
0x00 – Single device response
18
0x01 – Extended response
19
0x02-0xff – reserved 20
StartIndex Integer 0x00-0xff If the Request type for this 21
command is Extended response, the 22
StartIndex provides the starting 23
index for the requested elements of
the associated devices list.
24
25
26
2.4.3.1.2.1 When Generated 27
The IEEE_addr_req is generated from a Local Device wishing to inquire as to the 28
64-bit IEEE address of the Remote Device based on their known 16-bit address. 29
The destination addressing on this command shall be unicast. 30
31
2.4.3.1.2.2 Effect on Receipt 32
33
Upon receipt, a Remote Device shall compare the NWKAddrOfInterest to its 34
local NWK address or any NWK address held in its local discovery cache. If there 35
is no match, an IEEE_addr_resp command shall be generated and sent back to the 36
local device with the Status field set to DEVICE_NOT_FOUND; the 37
IEEEAddrRemoteDev field set to the IEEE address of this device; the 38
NWKAddrRemoteDev field set to the NWK address of the request; and the 39
NumAssocDev, StartIndex, and NWKAddrAssocDevList fields shall not be 40
included in the frame. 41
42
If a match is detected between the contained NWKAddrOfInterest and the Remote
43
Device's NWK address or one held in the discovery cache, the RequestType shall
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
102 Application Layer Specification
to the remote device itself or to an alternative device that contains the discovery
information of the remote device. 1
2
The local device shall generate the Node_Desc_req command using the format 3
illustrated in Table 2.46. The NWKAddrOfInterest field shall contain the network 4
address of the remote device for which the node descriptor is required. 5
6
2.4.3.1.3.2 Effect on Receipt 7
Upon receipt of this command, the recipient device shall process the command 8
and generate a Node_Desc_rsp command in response, according to the 9
description in sub-clause 2.4.4.1.3.1. 10
11
2.4.3.1.4 Power_Desc_req 12
13
The Power_Desc_req command (ClusterID=0x0003) shall be formatted as
14
illustrated in Figure 2.23.
15
Octets: 2 16
17
NWKAddrOfInterest 18
Figure 2.23 Format of the Power_Desc_req Command Frame 19
20
Table 2.47 specifies the fields of the Power_Desc_req command frame. 21
22
Table 2.47 Fields of the Power_Desc_req Command
23
Name Type Valid Range Description 24
25
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request. 26
Address
27
28
2.4.3.1.4.1 When Generated 29
30
The Power_Desc_req command is generated from a local device wishing to
31
inquire as to the power descriptor of a remote device. This command shall be
32
unicast either to the remote device itself or to an alternative device that contains
33
the discovery information of the remote device.
34
The local device shall generate the Power_Desc_req command using the format 35
illustrated in Table 2.47. The NWKAddrOfInterest field shall contain the network 36
address of the remote device for which the power descriptor is required. 37
38
2.4.3.1.4.2 Effect on Receipt 39
40
Upon receipt of this command, the recipient device shall process the command 41
and generate a Power_Desc_rsp command in response according to the 42
description in sub-clause 2.4.4.1.4.1. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
104 Application Layer Specification
2.4.3.1.5 Simple_Desc_req
1
The Simple_Desc_req command (ClusterID=0x0004) shall be formatted as 2
illustrated in Figure 2.24. 3
4
Octets: 2 1
5
NWKAddrOfInterest EndPoint 6
7
Figure 2.24 Format of the Simple_Desc_req Command Frame 8
9
Table 2.48 specifies the fields of the Simple_Desc_req command frame. 10
Table 2.48 Fields of the Simple_Desc_req Command 11
12
Name Type Valid Range Description
13
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request 14
Address 15
Endpoint 8 bits 1-240 The endpoint on the destination 16
17
18
2.4.3.1.5.1 When Generated
19
The Simple_Desc_req command is generated from a local device wishing to 20
inquire as to the simple descriptor of a remote device on a specified endpoint. This 21
command shall be unicast either to the remote device itself or to an alternative 22
device that contains the discovery information of the remote device. 23
24
The local device shall generate the Simple_Desc_req command using the format 25
illustrated in Table 2.48. The NWKAddrOfInterest field shall contain the network 26
address of the remote device for which the simple descriptor is required and the 27
endpoint field shall contain the endpoint identifier from which to obtain the 28
required simple descriptor. 29
30
2.4.3.1.5.2 Effect on Receipt 31
Upon receipt of this command, the recipient device shall process the command 32
and generate a Simple_Desc_rsp command in response, according to the 33
description in sub-clause 2.4.4.1.5.1. 34
35
2.4.3.1.6 Active_EP_req 36
The Active_EP_req command (ClusterID=0x0005) shall be formatted as 37
illustrated in Figure 2.25. 38
39
Octets: 2 40
41
NWKAddrOfInterest 42
Figure 2.25 Format of the Active_EP_req Command Frame 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 105
The remaining fields shall contain the required criterion for which the simple
descriptor match is requested. The ProfileID field shall contain the identifier of 1
the profile for which the match is being sought. 2
3
The NumInClusters field shall contain the number of elements in the InClusterList 4
field. If the value of this field is 0, the InClusterList field shall not be included. If 5
the value of the NumInClusters field is not equal to 0, the InClusterList field shall 6
contain the list of input cluster identifiers for which the match is being sought. 7
The NumOutClusters field shall contain the number of elements in the 8
OutClusterList field. If the value of this field is 0, the OutClusterList field shall 9
not be included. If the value of the NumOutClusters field is not equal to 0, the 10
OutClusterList field shall contain the list of output cluster identifiers for which the 11
match is being sought. 12
13
2.4.3.1.7.2 Effect on Receipt 14
15
Upon receipt of this command, the recipient device shall process the command 16
and generate a Match_Desc_rsp command in response, according to the 17
description in sub-clause 2.4.4.1.7.1. 18
2.4.3.1.8 Complex_Desc_req 19
20
The Complex_Desc_req command (ClusterID=0x0010) shall be formatted as 21
illustrated in Figure 2.27. 22
23
Octets: 2 24
NWKAddrOfInterest 25
26
Figure 2.27 Format of the Complex_Desc_req Command Frame 27
28
Table 2.51 specifies the fields of the Complex_Desc_req command frame. 29
Table 2.51 Fields of the Complex_Desc_req Command 30
31
Name Type Valid Range Description 32
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request 33
Address 34
35
2.4.3.1.8.1 When Generated 36
37
The Complex_Desc_req command is generated from a local device wishing to 38
inquire as to the complex descriptor of a remote device. This command shall be 39
unicast either to the remote device itself or to an alternative device that contains 40
the discovery information of the remote device. 41
42
The local device shall generate the Complex_Desc_req command using the
43
format illustrated in Table 2.51. The NWKAddrOfInterest field shall contain the
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
108 Application Layer Specification
network address of the remote device for which the complex descriptor is
required. 1
2
2.4.3.1.8.2 Effect on Receipt 3
4
Upon receipt of this command, the recipient device shall process the command 5
and generate a Complex_Desc_rsp command in response, according to the 6
description in sub-clause 2.4.4.1.8.1. 7
2.4.3.1.9 User_Desc_req 8
9
The User_Desc_req (ClusterID=0x0011) command shall be formatted as 10
illustrated in Figure 2.28. 11
12
Octets: 2 13
NWKAddrOfInterest 14
15
Figure 2.28 Format of the User_Desc_req Command Frame 16
17
Table 2.52 specifies the fields of the User_Desc_req command frame. 18
Table 2.52 Fields of the User_Desc_req Command 19
20
Name Type Valid Range Description 21
NWKAddrOfInterest Device Address 16-bit NWK address NWK address for the request. 22
23
24
2.4.3.1.9.1 When Generated
25
The User_Desc_req command is generated from a local device wishing to inquire 26
as to the user descriptor of a remote device. This command shall be unicast either 27
to the remote device itself or to an alternative device that contains the discovery 28
information of the remote device. 29
30
The local device shall generate the User_Desc_req command using the format 31
illustrated in Table 2.52. The NWKAddrOfInterest field shall contain the network 32
address of the remote device for which the user descriptor is required. 33
34
2.4.3.1.9.2 Effect on Receipt 35
Upon receipt of this command, the recipient device shall process the command 36
and generate a User_Desc_rsp command in response, according to the description 37
in sub-clause 2.4.4.1.9.1. 38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 109
2.4.3.1.10 Discovery_Cache_req
1
The Discovery_Cache_req command (ClusterID=0x0012) shall be formatted as 2
illustrated in Figure 2.29. 3
4
Octets: 2 8
5
NWKAddr IEEEAddr 6
7
Figure 2.29 Format of the Discovery_Cache_req Command Frame 8
9
Table 2.53 specifies the parameters for the Discovery_Cache_req command 10
frame. 11
Table 2.53 Fields of the Discovery_Cache_req Command 12
13
Name Type Valid Range Description
14
NWKAddr Device Address 16-bit NWK address NWK address for the Local Device. 15
IEEEAddr Device Address 64-bit IEEE address IEEE address for the Local Device. 16
17
18
2.4.3.1.10.1 When Generated 19
The Discovery_Cache_req is provided to enable devices on the network to locate 20
a Primary Discovery Cache device on the network. The destination addressing on 21
this primitive shall be broadcast to all devices for which macRxOnWhenIdle = 22
TRUE. 23
24
2.4.3.1.10.2 Effect on Receipt 25
26
Upon receipt, if the Remote Device does not support the Discovery_Cache_req, 27
the request shall be dropped and no further processing performed. If the 28
Discovery_Cache_req is supported, the Remote Device shall create a unicast 29
Discovery_Cache_rsp message to the source indicated by the 30
Discovery_Cache_req and include a SUCCESS status. 31
32
2.4.3.1.11 Device_annce
33
The Device_annce command (ClusterID=0x0013) shall be formatted as illustrated 34
in Figure 2.30. 35
36
Octets: 2 8 1 37
NWKAddr IEEEAddr Capability 38
39
Figure 2.30 Format of the Device_annce Command Frame 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
110 Application Layer Specification
2.4.3.1.13 System_Server_Discovery_req
1
The System_Server_Discovery_req command (ClusterID=0x0015) shall be 2
formatted as illustrated in Figure 2.32. 3
4
Octets: 2
5
ServerMask 6
7
Figure 2.32 Format of the System_Server_Discovery_req Command Frame 8
9
Table 2.56 specifies the fields of the System_Server_Discovery_req command 10
frame. 11
Table 2.56 Fields of the System_Server_Discovery_req Command 12
13
Name Type Valid Range Description
14
ServerMask Bitmap 16 bits See Table 2.31 for bit assignments 15
16
2.4.3.1.13.1 When Generated 17
18
The System_Server_Discovery_req is generated from a Local Device wishing to 19
discover the location of a particular system server or servers as indicated by the 20
ServerMask parameter. The destination addressing on this request is ‘broadcast to 21
all devices for which macRxOnWhenIdle = TRUE.’ 22
23
2.4.3.1.13.2 Effect on Receipt 24
25
Upon receipt, remote devices shall compare the ServerMask parameter to the 26
Server Mask field in their own Node descriptor. If no bits are found to match, no 27
action is taken. If any matching bits are found, the remote device shall send a 28
System_Server_Discovery_rsp back to the originator using unicast transmission 29
(with acknowledgement request) and indicating the matching bits. 30
2.4.3.1.14 Discovery_store_req 31
32
The Discovery_Store_req command (ClusterID=0x0016) shall be formatted as 33
illustrated in Figure 2.33. 34
35
Octets: 2 8 1 1 1 1 Variable
36
NWKAddr IEEEAddr NodeDes PowerDe ActiveEPSize SimpleDes SimpleDesc- 37
c-Size sc-Size c-Count SizeList 38
Figure 2.33 Format of the Discovery_Store_req Command Frame
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 113
shall determine if enough space is available to store the Node Descriptor for the
Local Device. If not, the Remote Device shall return INSUFFICIENT_SPACE. 1
Finally, the Remote Device shall store the Node Descriptor for the Local Device 2
and return SUCCESS. If the request returned a status of SUCCESS and the 3
NWKAddr and IEEEAddr in the request referred to addresses already held in the 4
Primary Discovery Cache, the descriptor in this request shall overwrite the 5
previously held entry. 6
7
2.4.3.1.16 Power_Desc_store_req 8
The Power_Desc_store_req command (ClusterID=0x0018) shall be formatted as 9
illustrated in Figure 2.35. 10
11
Octets: 2 8 Variable 12
13
NWKAddr IEEEAddr PowerDescriptor
14
Figure 2.35 Format of the Power_Desc_store_req Command Frame 15
16
Table 2.59 specifies the fields of the Power_Desc_store_req command frame. 17
18
Table 2.59 Fields of the Power_Desc_store_req Command
19
Name Type Valid Range Description 20
21
NWKAddr Device 16-bit NWK Address NWK Address for the Local Device.
Address 22
23
IEEEAddr Device 64-bit Address IEEE address for the Local Device. 24
Address
25
PowerDescriptor Power See the Power Descriptor format in 26
Descriptor sub-clause 2.3.2.4; This field shall only 27
be included in the frame if the status
field is equal to SUCCESS.
28
29
30
2.4.3.1.16.1 When Generated 31
The Power_Desc_store_req is provided to enable ZigBee end devices on the 32
network to request storage of their Power Descriptor on a Primary Discovery 33
Cache device which has previously received a SUCCESS status from a 34
Discovery_store_req to the same Primary Discovery Cache device. Included in 35
this request is the Power Descriptor the Local Device wishes to cache. 36
37
2.4.3.1.16.2 Effect on Receipt 38
39
Upon receipt, the Remote Device shall determine whether it is a Primary 40
Discovery Cache device. If it is not a Primary Discovery Cache device, the 41
Remote Device shall return a status of NOT_SUPPORTED. Next, the Remote 42
Device shall determine whether it has previously processed a 43
Discovery_store_req for the Local Device and returned a status of SUCCESS. If a 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
116 Application Layer Specification
Discovery_store_req to the same Primary Discovery Cache device. Note that each
Simple Descriptor for every active endpoint on the Local Device must be 1
individually uploaded to the Primary Discovery Cache device via this command 2
to enable cached discovery. Included in this request is the length of the Simple 3
Descriptor the Local Device wishes to cache and the Simple Descriptor itself. The 4
endpoint is a field within the Simple Descriptor and is accessed by the Remote 5
Device to manage the discovery cache information for the Local Device. 6
7
2.4.3.1.18.2 Effect on Receipt 8
9
Upon receipt, the Remote Device shall determine whether it is a Primary 10
Discovery Cache device. If it is not a Primary Discovery Cache device, the 11
Remote Device shall return a status of NOT_SUPPORTED. Next, the Remote 12
Device shall determine whether it has previously processed a 13
Discovery_store_req for the Local Device and returned a status of SUCCESS. If a 14
previous Discovery_store_req has not been processed with a SUCCESS status, 15
the Remote Device shall return NOT_PERMITTED. Next, the Remote Device 16
shall determine if enough space is available to store the Simple Descriptor for the 17
Local Device. If not, the Remote Device shall return INSUFFICIENT_SPACE. 18
Finally, the Remote Device shall store the Simple Descriptor for the Local Device 19
and return SUCCESS. If the request returned a status of SUCCESS and the 20
NWKAddr and the IEEEAddr in the request referred to addresses already held in 21
the Primary Discovery Cache, the descriptor in this request shall overwrite the 22
previously held entry. 23
2.4.3.1.19 Remove_node_cache_req 24
25
The Remove_node_cache_req command (ClusterID=0x001b) shall be formatted 26
as illustrated in Figure 2.38. 27
28
Octets: 2 8 29
NWKAddr IEEEAddr 30
31
Figure 2.38 Format of the Remove_node_cache_req Command Frame 32
33
Table 2.62 specifies the fields of the Remove_node_cache_req command frame. 34
Table 2.62 Fields of the Remove_node_cache_req Command 35
36
Name Type Valid Range Description 37
NWKAddr Device Address 16-bit NWK Address NWK Address for the device of 38
interest. 39
IEEEAddr Device Address 64-bit IEEE Address IEEE Address for the device of interest. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 119
endpoint. This command shall be unicast either to the remote device itself or to an
alternative device that contains the discovery information of the remote device. 1
The Extended_Simple_Desc_req is intended for use with devices which employ a 2
larger number of application input or output clusters than can be described by the 3
Simple_Desc_req. 4
5
The local device shall generate the Extended_Simple_Desc_req command using 6
the format illustrated in Table 2.64. The NWKAddrOfInterest field shall contain 7
the network address of the remote device for which the simple descriptor is 8
required and the endpoint field shall contain the endpoint identifier from which to 9
obtain the required simple descriptor. The StartIndex is the first entry requested in 10
the Application Input Cluster List and Application Output Cluster List sequence 11
within the resulting response. 12
13
2.4.3.1.21.2 Effect on Receipt 14
Upon receipt of this command, the recipient device shall process the command 15
and generate an Extended_Simple_Desc_rsp command in response, according to 16
the description in sub-clause 2.4.4.1.20.1. 17
18
The results in the Extended_Simple_Desc_rsp shall include the elements 19
described in Table 2.108 with a selectable set of the application input cluster and 20
application output cluster lists starting with the entry StartIndex and continuing 21
with whole entries until the maximum APS packet length is reached, along with a 22
status of SUCCESS. 23
2.4.3.1.22 Extended_Active_EP_req 24
25
The Extended_Active_EP_req command (ClusterID=0x001e) shall be formatted 26
as illustrated in Figure 2.41. 27
28
Octets: 2 1 29
NWKAddrOfInterest StartIndex 30
31
Figure 2.41 Format of the Extended_Active_EP_req Command Frame 32
33
Table 2.65 specifies the fields of the Extended_Active_EP_req command frame. 34
Table 2.65 Fields of the Extended_Active_EP_req Command 35
36
Name Type Valid Range Description 37
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request. 38
Address 39
StartIndex 8 bits 0x00-0xff Starting index within the Active 40
Endpoint list in the response. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
122 Application Layer Specification
Remote Device shall then respond with SUCCESS if the entry has been created by
the Binding Manager; otherwise, the Remote Device shall respond with 1
NOT_SUPPORTED. 2
3
This command shall be subject to a permissions check as defined in sub- 4
clause 4.6.3.8. On failure, the remote device shall not carry out the command, and 5
shall respond with NOT_AUTHORIZED. 6
2.4.3.2.3 Unbind_req 7
8
The Unbind_req command (ClusterID=0x0022) shall be formatted as illustrated 9
in Figure 2.44. 10
11
Octets: 8 1 2 1 2/8 0/1
12
SrcAddress SrcEndp ClusterID DstAddrMode DstAddress DstEndp 13
14
Figure 2.44 Format of the Unbind_req Command Frame 15
16
Table 2.69 specifies the fields of the Unbind_req command frame.
17
Table 2.69 Fields of the Unbind_req Command 18
19
Name Type Valid Range Description
20
SrcAddress IEEE A valid 64-bit IEEE The IEEE address for the source 21
Address address 22
SrcEndp Integer 0x01-0xf0 The source endpoint for the binding 23
entry 24
ClusterID Integer 0x0000-0xffff The identifier of the cluster on the source
25
device that is bound to the destination. 26
27
DstAddrMode Integer 0x00-0xff The addressing mode for the destination
28
address used in this command. This field
can take one of the non-reserved values 29
from the following list: 30
31
0x00 = reserved
32
0x01 = 16-bit group address for
DstAddress and DstEndp not present 33
34
0x02 = reserved
35
0x03 = 64-bit extended address for
DstAddress and DstEndp present 36
37
0x04 – 0xff = reserved
38
DstAddress Address As specified by the The destination address for the binding 39
DstAddrMode field entry.
40
DstEndp Integer 0x01-0xf0 This field shall be present only if the 41
DstAddrMode field has a value of 0x03 42
and, if present, shall be the destination 43
endpoint for the binding entry.
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
128 Application Layer Specification
2.4.3.2.6 Store_Bkup_Bind_Entry_req
1
The Store_Bkup_Bind_Entry_req command (ClusterID=0x0025) shall be 2
formatted as illustrated in Figure . 3
4
Octets: 8 1 2 1 2/8 0/1
5
SrcAddress SrcEndp ClusterID DstAddrMode DstAddress DstEndp 6
7
Figure 2.47 Format of the Store_Bkup_Bind_Entry_req Command Frame 8
9
Table 2.72 specifies the fields of the Store_Bkup_Bind_Entry_req command 10
frame. 11
Table 2.72 Fields of the Store_Bkup_Bind_Entry_req Command 12
13
Name Type Valid Range Description
14
SrcAddress IEEE Address A valid 64-bit The IEEE address for the source. 15
IEEE address 16
SrcEndpoint Integer 0x01 - 0xf0 The source endpoint for the binding entry. 17
18
ClusterId Integer 0x0000 - 0xffff The identifier of the cluster on the source
device that is bound to the destination.
19
20
DstAddrMo Integer 0x00-0xff The addressing mode for the destination 21
de address used in this command. This field
22
can take one of the non-reserved values
from the following list: 23
24
0x00 = reserved
25
0x01 = 16-bit group address for 26
DstAddress and DstEndp not present
27
0x02 = reserved
28
0x03 = 64-bit extended address for 29
DstAddress and DstEndp present
30
0x04 – 0xff = reserved
31
DstAddress Address As specified by The destination address for the binding 32
the entry. 33
DstAddrMode
34
field
35
DstEndp Integer 0x01-0xf0 This field shall be present only if the 36
DstAddrMode field has a value of 0x03 37
and, if present, shall be the destination
endpoint for the binding entry. 38
39
40
2.4.3.2.6.1 When Generated 41
The Store_Bkup_Bind_Entry_req is generated from a local primary binding table 42
cache and sent to a remote backup binding table cache device to request backup 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
132 Application Layer Specification
storage of the entry. It will be generated whenever a new binding table entry has
been created by the primary binding table cache. The destination addressing mode 1
for this request is unicast. 2
3
2.4.3.2.6.2 Effect on Receipt 4
5
If the remote device is not a backup binding table cache it shall return a status of 6
NOT_SUPPORTED. If it is the backup binding table cache, it should maintain the 7
identity of the primary binding table cache from previous discovery. If the 8
contents of the Store_Bkup_Bind_Entry parameters match an existing entry in the 9
binding table cache, then the remote device shall return SUCCESS. Otherwise, 10
the backup binding table cache shall add the binding entry to its binding table and 11
return a status of SUCCESS. If there is no room, it shall return a status of 12
TABLE_FULL. 13
2.4.3.2.7 Remove_Bkup_Bind_Entry_req 14
15
The Remove_Bkup_Bind_Entry_req command (ClusterID=0x0026) shall be 16
formatted as illustrated in Figure 2.48. 17
18
Octets: 8 1 2 1 2/8 0/1 19
SrcAddress SrcEndp ClusterID DstAddrMode DstAddress DstEndp 20
21
Figure 2.48 Format of the Remove_Bkup_Bind_Entry_req Command Frame 22
23
Table 2.73 specifies the fields of the Remove_Bkup_Bind_Entry_req command 24
frame. 25
Table 2.73 Fields of the Remove_Bkup_Bind_Entry_req Command 26
27
Name Type Valid Range Description 28
SrcAddress IEEE A valid 64-bit The IEEE address for the source. 29
Address IEEE address 30
SrcEndpoint Integer 0x01 - 0xf0 The IEEE address for the binding entry. 31
32
ClusterId Integer 0x0000 - 0xffff The identifier of the cluster on the source 33
device that is bound to the destination.
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 133
2.4.3.2.8 Backup_Bind_Table_req
1
The Backup_Bind_Table_req command (ClusterID=0x0027) shall be formatted 2
as illustrated in Figure 2.49. 3
4
Octets: 2 2 2 Variable
5
BindingTableEntries StartIndex BindingTableListCount BindingTableList 6
7
Figure 2.49 Format of the Backup_Bind_Table_req Command Frame 8
9
Table 2.74 specifies the fields of the Backup_Bind_Table_req command frame. 10
Table 2.74 Fields of the Backup_Bind_Table_req Command 11
12
Name Type Valid Range Description
13
BindingTableEntries Integer 0x0000 - 0xffff Total number of binding 14
table entries on the primary 15
binding table cache device. 16
StartIndex Integer 0x0000 - 0xffff Starting index within the 17
binding table of entries. 18
BindingTableListCount Integer 0x0000 - 0xffff Number of binding table 19
entries included within 20
BindingTableList. 21
BindingTableList List of The list shall contain A list of descriptors 22
binding the number of elements beginning with the 23
descriptors given by the StartIndex element and 24
BindingTableListCount continuing for 25
BindingTableListCount of
26
the elements in the primary
binding table cache devices’s 27
binding table (see 28
Table 2.130 for details.) 29
30
2.4.3.2.8.1 When Generated 31
32
The Backup_Bind_Table_req is generated from a local primary binding table 33
cache and sent to the remote backup binding table cache device to request backup 34
storage of its entire binding table. The destination addressing mode for this 35
request is unicast. 36
37
2.4.3.2.8.2 Effect on Receipt 38
39
If the remote device is not a backup binding table cache, it shall return a status of
40
NOT_SUPPORTED. If it is a backup binding table cache, it should maintain the
41
identity of the primary binding table cache from previous discovery. If it does not
42
recognize the sending device as a primary binding table cache, it shall return a
43
status of INV_REQUESTTYPE. Otherwise, the backup binding table cache shall
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 135
overwrite the binding entries in its binding table starting with StartIndex and
continuing for BindingTableListCount entries. If this exceeds its table size, it shall 1
fill in as many entries as possible and return a status of TABLE_FULL. 2
Otherwise, it shall return a status of SUCCESS. The table is effectively truncated 3
to the end of the last entry written by this request. The new size of the table is 4
returned in the response and will be equal to StartIndex + BindingTableListCount 5
unless TABLE_FULL is being returned it which case it will be the maximum size 6
of the table. 7
8
2.4.3.2.9 Recover_Bind_Table_req 9
The Recover_Bind_Table_req command (ClusterID=0x0028) shall be formatted 10
as illustrated in Figure 2.50. 11
12
Octets: 2 13
14
StartIndex
15
Figure 2.50 Fields of the Recover_Bind_Table_req Command Frame 16
17
Table 2.75 specifies the fields of the Recover_Bind_Table_req command frame. 18
19
Table 2.75 Fields of the Recover_Bind_Table_req Command
20
Name Type Valid Range Description 21
22
StartIndex Integer 0x0000 - 0xffff Starting index for the requested
elements of the binding table 23
24
25
2.4.3.2.9.1 When Generated 26
The Recover_Bind_Table_req is generated from a local primary binding table 27
cache and sent to a remote backup binding table cache device when it wants a 28
complete restore of the binding table. The destination addressing mode for this 29
request is unicast. 30
31
2.4.3.2.9.2 Effect on Receipt 32
33
If the remote device is not the backup binding table cache, it shall return a status 34
of NOT_SUPPORTED. If it does not recognize the sending device as a primary 35
binding table cache it shall return a status of INV_REQUESTTYPE. Otherwise, 36
the backup binding table cache shall prepare a list of binding table entries from its 37
backup beginning with StartIndex. It will fit in as many entries as possible into a 38
Recover_Bind_Table_rsp command and return a status of SUCCESS. 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
136 Application Layer Specification
2.4.3.2.10 Backup_Source_Bind_req
1
The Backup_Source_Bind_req command (ClusterID=0x0029) shall be formatted 2
as illustrated in Figure 2.51. 3
4
Octets: 2 2 2 Variable
5
SourceTableEntries StartIndex SourceTableListCount SourceTableList 6
7
Figure 2.51 Fields of the Backup_Source_Bind_req Command Frame 8
9
Table 2.76 specifies the fields of the Backup_Source_Bind_req command frame. 10
Table 2.76 Fields of the Backup_Source_Bind_req Command 11
12
Name Type Valid Range Description
13
SourceTableEntries Integer 0x0000 - 0xffff Total number of source table 14
entries on the primary binding 15
table cache device. 16
StartIndex Integer 0x0000 - 0xffff Starting index within the 17
binding table of the entries in 18
SourceTableList. 19
SourceTableListCount Integer 0x0000 - 0xffff Number of source table entries 20
included within 21
SourceTableList. 22
SourceTableList List of The list shall contain A list of addresses beginning 23
IEEE the number of with the StartIndex element and 24
Addresses elements given by the continuing for 25
SourceTableListCount SourceTableListCount of
26
source addresses in the primary
binding table cache device’s 27
source table. 28
29
30
2.4.3.2.10.1 When Generated
31
The Backup_Source_Bind_req is generated from a local primary binding table 32
cache and sent to a remote backup binding table cache device to request backup 33
storage of its entire source table. The destination addressing mode for this request 34
is unicast. 35
36
2.4.3.2.10.2 Effect on Receipt 37
38
If the remote device is not the backup binding table cache, it shall return a status 39
of NOT_SUPPORTED. If it does not recognize the sending device as a primary 40
binding table cache, it shall return a status of INV_REQUESTTYPE. Otherwise, 41
the backup binding table cache shall overwrite the source entries in its backup 42
source table starting with StartIndex and continuing for SourceTableListCount 43
entries. If this exceeds its table size, it shall return a status of TABLE_FULL. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 137
Table 2.79 specifies the fields for the Mgmt_NWK_Disc_req command frame.
1
Table 2.79 Fields of the Mgmt_NWK_Disc_req Command
2
Valid 3
Name Type Range Description 4
5
ScanChannels Bitmap 32-bit field See (sub-clause 3.2.2.1) for details
on NLME-NETWORK- 6
DISCOVERY.request ScanChannels 7
parameter. 8
ScanDuration Integer 0x00-0x0e A value used to calculate the length 9
of time to spend scanning each 10
channel. The time spent scanning 11
each channel is 12
(aBaseSuperframeDuration * (2n + 13
1)) symbols, where n is the value of
the ScanDuration parameter. For 14
more information on MAC sub-layer 15
scanning (see [B1]. 16
StartIndex Integer 0x00-0xff Starting index within the resulting 17
NLME-NETWORK- 18
DISCOVERY.confirm NetworkList 19
to begin reporting for the 20
Mgmt_NWK_Disc_rsp. 21
22
2.4.3.3.1.1 When Generated 23
24
The Mgmt_NWK_Disc_req is generated from a Local Device requesting that the 25
Remote Device execute a Scan to report back networks in the vicinity of the Local 26
Device. The destination addressing on this command shall be unicast. 27
28
2.4.3.3.1.2 Effect on Receipt 29
The Remote Device shall execute an NLME-NETWORK-DISCOVERY.request 30
using the ScanChannels and ScanDuration parameters supplied with the 31
Mgmt_NWK_Disc_req command. The results of the Scan shall be reported back 32
to the Local Device via the Mgmt_NWK_Disc_rsp command. 33
34
If this command is not supported in the Remote Device, the return status provided 35
with the Mgmt_NWK_Disc_rsp shall be NOT_SUPPORTED. If the scan was 36
successful, the Mgmt_NWK_Disc_rsp command shall contain a status of 37
SUCCESS and the results of the scan shall be reported, beginning with the 38
StartIndex element of the NetworkList. If the scan was unsuccessful, the 39
Mgmt_NWK_Disc_rsp command shall contain the error code reported in the 40
NLME-NETWORK-DISCOVERY.confirm primitive. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
140 Application Layer Specification
2.4.3.3.2 Mgmt_Lqi_req
1
The Mgmt_Lqi_req command (ClusterID=0x0031) shall be formatted as 2
illustrated in Figure 2.54. 3
4
Octets: 1
5
StartIndex 6
7
Figure 2.54 Format of the Mgmt_Lqi_req Command Frame 8
9
Table 2.80 specifies the fields for the Mgmt_NWK_Disc_req command frame. 10
Table 2.80 Fields of the Mgmt_Lqi_req Command 11
12
Valid
Name Type Range Description 13
14
StartIndex Integer 0x00-0xff Starting Index for the requested elements of the 15
Neighbor Table. 16
17
2.4.3.3.2.1 When Generated 18
19
The Mgmt_Lqi_req is generated from a Local Device wishing to obtain a 20
neighbor list for the Remote Device along with associated LQI values to each 21
neighbor. The destination addressing on this command shall be unicast only and 22
the destination address must be that of a ZigBee Coordinator or ZigBee Router. 23
24
2.4.3.3.2.2 Effect on Receipt 25
Upon receipt, a Remote Device (ZigBee Router or ZigBee Coordinator) shall 26
retrieve the entries of the neighbor table and associated LQI values via the 27
NLME-GET.request primitive (for the nwkNeighborTable attribute) and report the 28
resulting neighbor table (obtained via the NLME-GET.confirm primitive) via the 29
Mgmt_Lqi_rsp command. 30
31
If this command is not supported in the Remote Device, the return status provided 32
with the Mgmt_Lqi_rsp shall be NOT_SUPPORTED. If the neighbor table was 33
obtained successfully, the Mgmt_Lqi_rsp command shall contain a status of 34
SUCCESS and the neighbor table shall be reported, beginning with the element in 35
the list enumerated as StartIndex. If the neighbor table was not obtained 36
successfully, the Mgmt_Lqi_rsp command shall contain the error code reported in 37
the NLME-GET.confirm primitive. 38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 141
2.4.3.3.3 Mgmt_Rtg_req
1
The Mgmt_Rtg_req command (ClusterID=0x0032) shall be formatted as 2
illustrated in Figure 2.55. 3
4
Octets: 1
5
StartIndex 6
7
Figure 2.55 Format of the Mgmt_Rtg_req Command Frame 8
9
Table 2.81 specifies the fields for the Mgmt_Rtg_req command frame. 10
Table 2.81 Fields of the Mgmt_Rtg_req Command 11
12
Name Type Valid Range Description
13
StartIndex Integer 0x00-0xff Starting Index for the requested elements of the 14
Routing Table 15
16
2.4.3.3.3.1 When Generated 17
18
The Mgmt_Rtg_req is generated from a Local Device wishing to retrieve the 19
contents of the Routing Table from the Remote Device. The destination 20
addressing on this command shall be unicast only and the destination address 21
must be that of the ZigBee Router or ZigBee Coordinator. 22
23
2.4.3.3.3.2 Effect on Receipt 24
25
Upon receipt, a Remote Device (ZigBee Coordinator or ZigBee Router) shall
26
retrieve the entries of the routing table from the NWK layer via the NLME-
27
GET.request primitive (for the nwkRouteTable attribute) and report the resulting
28
routing table (obtained via the NLME-GET.confirm primitive) via the
29
Mgmt_Rtg_rsp command.
30
If the Remote Device does not support this optional management request, it shall 31
return a Status of NOT_SUPPORTED. If the routing table was obtained 32
successfully, the Mgmt_Rtg_req command shall contain a status of SUCCESS 33
and the routing table shall be reported, beginning with the element in the list 34
enumerated as StartIndex. If the routing table was not obtained successfully, the 35
Mgmt_Rtg_rsp command shall contain the error code reported in the NLME- 36
GET.confirm primitive. 37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
142 Application Layer Specification
2.4.3.3.4 Mgmt_Bind_req
1
The Mgmt_Bind_req command (ClusterID=0x0033) shall be formatted as 2
illustrated in Figure 2.56. 3
4
Octets: 1
5
StartIndex 6
7
Figure 2.56 Format of the Mgmt_Bind_req Command Frame 8
9
Table 2.82 specifies the fields for the Mgmt_Bind_req command frame. 10
Table 2.82 Fields of the Mgmt_Bind_req Command 11
12
Name Type Valid Range Description
13
StartIndex Integer 0x00-0xff Starting Index for the requested 14
elements of the Binding Table. 15
16
2.4.3.3.4.1 When Generated 17
18
The Mgmt_Bind_req is generated from a Local Device wishing to retrieve the 19
contents of the Binding Table from the Remote Device. The destination 20
addressing on this command shall be unicast only and the destination address 21
must be that of a Primary binding table cache or source device holding its own 22
binding table. 23
24
2.4.3.3.4.2 Effect on Receipt 25
26
Upon receipt, a Remote Device shall retrieve the entries of the binding table from
27
the APS sub-layer via the APSME-GET.request primitive (for the
28
apsBindingTable attribute) and report the resulting binding table (obtained via the
29
APSME-GET.confirm primitive) via the Mgmt_Bind_rsp command.
30
If the Remote Device does not support this optional management request, it shall 31
return a status of NOT_SUPPORTED. If the binding table was obtained 32
successfully, the Mgmt_Bind_rsp command shall contain a status of SUCCESS 33
and the binding table shall be reported, beginning with the element in the list 34
enumerated as StartIndex. If the binding table was not obtained successfully, the 35
Mgmt_Bind_rsp command shall contain the error code reported in the APSME- 36
GET.confirm primitive. 37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 143
2.4.3.3.5 Mgmt_Leave_req
1
The Mgmt_Leave_req command (ClusterID=0x0034) shall be formatted as 2
illustrated in Figure 2.57. 3
4
Bits: 64 6 1 1
5
Device Address Reserved Remove Children Rejoin 6
7
Figure 2.57 Format of the Mgmt_Leave_req Command Frame 8
9
Table 2.83 specifies the fields for the Mgmt_Leave_req command frame. 10
Table 2.83 Fields of the Mgmt_Leave_req Command 11
12
Name Type Valid Range Description
13
DeviceAddress Device An extended 64- See (sub-clause 3.2.2.16) for details 14
Address bit, IEEE address on the DeviceAddress parameter 15
within NLME-LEAVE.request. For 16
DeviceAddress of NULL, a value of
0x0000000000000000 shall be 17
used.a 18
19
Remove Bit 0 or 1 This field has a value of 1 if the
Children device being asked to leave the 20
network is also being asked to 21
remove its child devices, if any. 22
Otherwise, it has a value of 0. 23
Rejoin Bit 0 or 1 This field has a value of 1 if the 24
device being asked to leave from the 25
current parent is requested to rejoin 26
the network. Otherwise, it has a 27
value of 0.
28
a. CCB #849 29
30
2.4.3.3.5.1 When Generated 31
32
The Mgmt_Leave_req is generated from a Local Device requesting that a Remote 33
Device leave the network or to request that another device leave the network. The 34
Mgmt_Leave_req is generated by a management application which directs the 35
request to a Remote Device where the NLME-LEAVE.request is to be executed 36
using the parameter supplied by Mgmt_Leave_req. 37
38
2.4.3.3.5.2 Effect on Receipt 39
40
Upon receipt, the remote device shall issue the NLME-LEAVE.request primitive
41
using the parameters supplied with the Mgmt_Leave_req command. The results
42
of the leave attempt shall be reported back to the local device via the
43
Mgmt_Leave_rsp command.
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
144 Application Layer Specification
If the remote device does not support this optional management request, it shall
return a status of NOT_SUPPORTED. If the leave attempt was executed 1
successfully, the Mgmt_Leave_rsp command shall contain a status of SUCCESS. 2
If the leave attempt was not executed successfully, the Mgmt_Leave_rsp 3
command shall contain the error code reported in the NLME-LEAVE.confirm 4
primitive. 5
6
This command shall be subject to a permissions check as defined in sub- 7
clause 4.6.3.8. On failure the remote device shall not carry out the command, and 8
shall respond with NOT_AUTHORIZED. 9
2.4.3.3.6 Mgmt_Direct_Join_req 10
11
The Mgmt_Direct_Join_req command (ClusterID=0x0035) shall be formatted as 12
illustrated in Figure 2.58. 13
14
Octets: 8 1
15
Device Address Capability 16
Information 17
18
Figure 2.58 Format of the Mgmt_Direct_Join _req Command Frame
19
Table 2.84 specifies the fields for the Mgmt_Direct_Join_req command frame. 20
21
Table 2.84 Fields of the Mgmt_Direct_Join_req Command 22
Name Type Valid Range Description 23
24
DeviceAddress Device An extended 64-bit, See sub-clause 3.2.2.14 for details 25
Address IEEE address on the DeviceAddress parameter 26
within NLME-DIRECT-
JOIN.request. 27
28
CapabilityInformation Bitmap See Table 3.47 The operating capabilities of the 29
device being directly joined.
30
31
2.4.3.3.6.1 When Generated 32
33
The Mgmt_Direct_Join_req is generated from a Local Device requesting that a
34
Remote Device permit a device designated by DeviceAddress to join the network
35
directly. The Mgmt_Direct_Join_req is generated by a management application
36
which directs the request to a Remote Device where the NLME-DIRECT-
37
JOIN.request is to be executed using the parameter supplied by
38
Mgmt_Direct_Join_req.
39
40
2.4.3.3.6.2 Effect on Receipt
41
Upon receipt, the remote device shall issue the NLME-DIRECT-JOIN.request 42
primitive using the DeviceAddress and CapabilityInformation parameters 43
supplied with the Mgmt_Direct_Join_req command. The results of the direct join 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 145
attempt shall be reported back to the local device via the Mgmt_Direct_Join_rsp
command. 1
2
If the remote device does not support this optional management request, it shall 3
return a status of NOT_SUPPORTED. If the direct join attempt was executed 4
successfully, the Mgmt_Direct_Join_rsp command shall contain a status of 5
SUCCESS. If the direct join attempt was not executed successfully, the 6
Mgmt_Direct_Join_rsp command shall contain the error code reported in the 7
NLME-DIRECT-JOIN.confirm primitive. 8
This command shall be subject to a permissions check as defined in sub- 9
clause 4.6.3.8. On failure the remote device shall not carry out the command, and 10
shall respond with NOT_AUTHORIZED. 11
12
2.4.3.3.7 Mgmt_Permit_Joining_req 13
The Mgmt_Permit_Joining_req command (ClusterID=0x0036) shall be formatted 14
as illustrated in Figure 2.59. 15
16
Octets: 1 1 17
18
PermitDuration TC_Significance
19
Figure 2.59 Format of the Mgmt_Permit_Joining_req Command Frame 20
21
Table 2.85 specifies the fields of the Mgmt_Permit_Joining_req command frame. 22
23
Table 2.85 Fields of the Mgmt_Permit_Joining_req Command
24
Name Type Valid Range Description 25
26
PermitDuration Integer 0x00 - 0xff See sub-clause 3.2.2.5 for details on the
PermitDuration parameter within NLME- 27
PERMIT-JOINING.request. 28
29
TC_Significance Boolean 0x00 - 0x01 If this is set to 0x01 and the remote device is
Integer the Trust Center, the command affects the 30
Trust Center authentication policy as 31
described in the sub-clauses below; If this is 32
set to 0x00, there is no effect on the Trust 33
Center. 34
35
2.4.3.3.7.1 When Generated 36
37
The Mgmt_Permit_Joining_req is generated from a Local Device requesting that 38
a remote device or devices allow or disallow association. The 39
Mgmt_Permit_Joining_req is generated by a management application or 40
commissioning tool which directs the request to a remote device(s) where the 41
NLME-PERMIT-JOINING.request is executed using the PermitDuration 42
parameter supplied by Mgmt_Permit_Joining_req. Additionally, if the remote 43
device is the Trust Center and TC_Significance is set to 1, the Trust Center 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
146 Application Layer Specification
2.4.3.3.8 Mgmt_Cache_req
1
The Mgmt_Cache_req command (ClusterID=0x0037) shall be formatted as 2
illustrated in Figure 2.60. 3
4
Octets: 1
5
StartIndex 6
7
Figure 2.60 Fields of the Mgmt_Cache_req Command Frame 8
9
Table 2.86 specifies the fields of the Mgmt_Cache_req command frame. 10
Table 2.86 Fields of the Mgmt_Cache_req Command 11
12
Valid
Name Type Range Description 13
14
StartIndex Integer 0x00 - 0xff Starting Index for the requested 15
elements of the discovery cache list. 16
17
2.4.3.3.8.1 When Generated 18
19
The Mgmt_Cache_req is provided to enable ZigBee devices on the network to 20
retrieve a list of ZigBee End Devices registered with a Primary Discovery Cache 21
device. The destination addressing on this primitive shall be unicast. 22
23
2.4.3.3.8.2 Effect on Receipt 24
Upon receipt, the Remote Device shall determine whether it is a Primary 25
Discovery Cache or whether this optional request primitive is supported. If it is 26
not a Primary Discovery Cache device or the Mgmt_Cache_req primitive is not 27
supported, the Remote Device shall return a status of NOT_SUPPORTED. If the 28
Remote Device is a Primary Discovery Cache and supports the Mgmt_Cache_req, 29
the Remote Device shall return SUCCESS to the Local Device along with the 30
discovery cache list which consists of the NWKAddr and IEEEaddr for each 31
ZigBee End Device registered. 32
33
2.4.3.3.9 Mgmt_NWK_Update_req 34
The Mgmt_NWK_Update_req command (ClusterID=0x0038) shall be formatted 35
as illustrated in Figure 2.61. 36
37
Octets: 4 1 0/1 0/1 0/2 38
39
ScanChannels ScanDuration ScanCount nwkUpdateId nwkManagerAddr
40
Figure 2.61 Fields of the Mgmt_NWK_Update_req Command Frame 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
148 Application Layer Specification
Table 2.88 Device and Service Discovery Server Service Primitives (Continued)
1
Device and Service 2
Discovery Server
Server Services Processing 3
4
Complex_Desc_rsp O 5
User_Desc_rsp O 6
7
User_Desc_conf O
8
System_Server_Discovery_rsp O 9
Discovery_store_rsp O 10
11
Node_Desc_store_rsp O 12
Power_Desc_store_rsp O 13
Active_EP_store_rsp O
14
15
Simple_Desc_store_rsp O 16
Remove_node_cache_rsp O 17
18
Find_node_cache_rsp O
19
Extended_Simple_Desc_rsp O 20
Extended_Active_EP_rsp O 21
22
2.4.4.1.1 NWK_addr_rsp 23
24
The NWK_addr_rsp command (ClusterID=0x8000) shall be formatted as 25
illustrated in Figure 2.62. 26
27
Octets: 1 8 2 0/1 0/1 Variable 28
Status IEEEAddr NWKAddr Num StartIndex NWKAddr 29
RemoteDev RemoteDev AssocDev AssocDevList 30
31
Figure 2.62 Format of the NWK_addr_rsp Command Frame 32
33
Table 2.89 specifies the fields of the NWK_addr_rsp command frame. 34
Table 2.89 Fields of the NWK_addr_rsp Command 35
36
Name Type Valid Range Description
37
Status Integer SUCCESS, The status of the 38
INV_REQUESTTYPE or NWK_addr_req command. 39
DEVICE_NOT_FOUND 40
IEEEAddrRemoteDev Device An extended 64-bit, IEEE 64-bit address for the Remote 41
Address address Device. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
152 Application Layer Specification
2.4.4.1.2 IEEE_addr_rsp
1
The IEEE_addr_rsp command (ClusterID=0x8001) shall be formatted as 2
illustrated in Figure 2.63. 3
4
Octets: 1 8 2 0/1 0/1 Variable
5
Status IEEEAddr NWKAddr Num StartIndex NWKAddr 6
RemoteDev RemoteDev AssocDev AssocDevList 7
8
Figure 2.63 Format of the IEEE_addr_rs Command Frame
9
Table 2.90 specifies the fields of the IEEE_addr_rs command frame. 10
11
Table 2.90 IEEE_addr_rsp Parameters 12
Name Type Valid Range Description 13
14
Status Integer SUCCESS, The status of the 15
INV_REQUESTTYPE or IEEE_addr_req command. 16
DEVICE_NOT_FOUND
17
IEEEAddrRemoteDev Device An extended 64-bit, IEEE 64-bit address for the 18
Address address Remote Device. 19
NWKAddrRemoteDev Device A 16-bit, NWK address 16-bit address for the 20
Address Remote Device. 21
NumAssocDev Integer 0x00-0xff Count of the number of 22
16-bit short addresses to 23
follow. 24
If the RequestType in the 25
request is Extended 26
Response and there are no 27
associated devices on the 28
Remote Device, this field
29
shall be set to 0.
30
If an error occurs or the 31
RequestType in the
32
request is for a Single
Device Response, this 33
field shall not be included 34
in the frame. 35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 155
The remote device shall generate the Node_Desc_rsp command using the format
illustrated in Table 2.91. The NWKAddrOfInterest field shall match that specified 1
in the original Node_Desc_req command. If the NWKAddrOfInterest field 2
matches the network address of the remote device, it shall set the Status field to 3
SUCCESS and include its node descriptor (see sub-clause 2.3.2.3) in the 4
NodeDescriptor field. 5
6
If the NWKAddrOfInterest field does not match the network address of the 7
remote device and it is an end device, it shall set the Status field to 8
INV_REQUESTTYPE and not include the NodeDescriptor field. If the 9
NWKAddrOfInterest field does not match the network address of the remote 10
device and it is the coordinator or a router, it shall determine whether the 11
NWKAddrOfInterest field matches the network address of one of its children. If 12
the NWKAddrOfInterest field does not match the network address of one of the 13
children of the remote device, it shall set the Status field to 14
DEVICE_NOT_FOUND and not include the NodeDescriptor field. If the 15
NWKAddrOfInterest matches the network address of one of the children of the 16
remote device, it shall determine whether a node descriptor for that device is 17
available. If a node descriptor is not available for the child indicated by the 18
NWKAddrOfInterest field, the remote device shall set the Status field to 19
NO_DESCRIPTOR and not include the NodeDescriptor field. If a node descriptor 20
is available for the child indicated by the NWKAddrOfInterest field, the remote 21
device shall set the Status field to SUCCESS and include the node descriptor (see 22
sub-clause 2.3.2.3) of the matching child device in the NodeDescriptor field. 23
24
2.4.4.1.3.2 Effect on Receipt 25
On receipt of the Node_Desc_rsp command, the recipient is either notified of the 26
node descriptor of the remote device indicated in the original Node_Desc_req 27
command or notified of an error. If the Node_Desc_rsp command is received with 28
a Status of SUCCESS, the NodeDescriptor field shall contain the requested node 29
descriptor. Otherwise, the Status field indicates the error and the NodeDescriptor 30
field shall not be included. 31
32
2.4.4.1.4 Power_Desc_rsp 33
34
The Power_Desc_rsp command (ClusterID=0x8003) shall be formatted as
35
illustrated in Figure 2.65.
36
Octet: 1 2 Variable 37
38
Status NWKAddr Power 39
OfInterest Descriptor
40
Figure 2.65 Format of the Power_Desc_rsp Command Frame 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
158 Application Layer Specification
the remote device shall set the Status field to SUCCESS and include the power
descriptor (see sub-clause 2.3.2.4) of the matching child device in the 1
PowerDescriptor field. 2
3
2.4.4.1.4.2 Effect on Receipt 4
5
On receipt of the Power_Desc_rsp command, the recipient is either notified of the 6
power descriptor of the remote device indicated in the original Power_Desc_req 7
command or notified of an error. If the Power_Desc_rsp command is received 8
with a Status of SUCCESS, the PowerDescriptor field shall contain the requested 9
power descriptor. Otherwise, the Status field indicates the error and the 10
PowerDescriptor field shall not be included. 11
2.4.4.1.5 Simple_Desc_rsp 12
13
The Simple_Desc_rsp command (ClusterID=0x8004) shall be formatted as 14
illustrated in Figure 2.66. 15
16
Octet: 1 2 1 Variable 17
Status NWKAddr Length Simple 18
OfInterest Descriptor 19
20
Figure 2.66 Format of the Simple_Desc_rsp Command Frame 21
22
Table 2.93 specifies the fields of the Simple_Desc_rsp command frame. 23
Table 2.93 Fields of the Simple_Desc_rsp Command 24
25
Name Type Valid Range Description
26
Status Integer SUCCESS, The status of the 27
INVALID_EP, Simple_Desc_req command. 28
NOT_ACTIVE, 29
DEVICE_NOT_FOUND,
INV_REQUESTTYPE or 30
NO_DESCRIPTOR 31
32
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request.
Address 33
34
Length Integer 0x00-0xff Length in bytes of the Simple 35
Descriptor to follow.
36
SimpleDescriptor Simple See the Simple Descriptor 37
Descriptor format in sub-clause 2.3.2.5. 38
This field shall only be
39
included in the frame if the
status field is equal to 40
SUCCESS. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
160 Application Layer Specification
device and include an ascending list of all the identifiers of the active endpoints on
that device in the ActiveEPList field. 1
2
If the NWKAddrOfInterest field does not match the network address of the 3
remote device and it is an end device, it shall set the Status field to 4
INV_REQUESTTYPE, set the ActiveEPCount field to 0, and not include the 5
ActiveEPList field. If the NWKAddrOfInterest field does not match the network 6
address of the remote device and it is the coordinator or a router, it shall determine 7
whether the NWKAddrOfInterest field matches the network address of a device it 8
holds in a discovery cache. If the NWKAddrOfInterest field does not match the 9
network address of a device it holds in a discovery cache, it shall set the Status 10
field to DEVICE_NOT_FOUND, set the ActiveEPCount field to 0, and not 11
include the ActiveEPList field. If the NWKAddrOfInterest matches the network 12
address of a device held in a discovery cache on the remote device, it shall 13
determine whether that device has any active endpoints. If the discovery 14
information corresponding to the ActiveEP request has not yet been uploaded to 15
the discovery cache, the remote device shall set the Status field to 16
NO_DESCRIPTOR, set the ActiveEPCount field to 0 and not include the 17
ActiveEPList field. If the cached device has no active endpoints, the remote 18
device shall set the Status field to SUCCESS, set the ActiveEPCount field to 0, 19
and not include the ActiveEPList field. If the cached device has active endpoints, 20
the remote device shall set the Status field to SUCCESS, set the ActiveEPCount 21
field to the number of active endpoints on that device, and include an ascending 22
list of all the identifiers of the active endpoints on that device in the ActiveEPList 23
field. 24
25
2.4.4.1.6.2 Effect on Receipt 26
On receipt of the Active_EP_rsp command, the recipient is either notified of the 27
active endpoints of the remote device indicated in the original Active_EP_req 28
command or notified of an error. If the Active_EP_rsp command is received with 29
a Status of SUCCESS, the ActiveEPCount field indicates the number of entries in 30
the ActiveEPList field. Otherwise, the Status field indicates the error and the 31
ActiveEPList field shall not be included. 32
33
2.4.4.1.7 Match_Desc_rsp 34
35
The Match_Desc_rsp command (ClusterID=0x8006) shall be formatted as
36
illustrated in Figure 2.68.
37
Octet: 1 2 1 Variable 38
39
Status NWKAddr Match Match 40
OfInterest Length List
41
Figure 2.68 Format of the Match_Desc_rsp Command Frame 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 163
address of the remote device and it is the coordinator or a router, it shall determine
whether the NWKAddrOfInterest field matches the network address of one of its 1
children. If the NWKAddrOfInterest field does not match the network address of 2
one of the children of the remote device, it shall set the Status field to 3
DEVICE_NOT_FOUND, set the MatchLength field to 0, and not include the 4
MatchList field. 5
6
If the NWKAddrOfInterest matches the network address of one of the children of 7
the remote device, it shall determine whether any simple descriptors for that 8
device are available. If no simple descriptors are available for the child indicated 9
by the NWKAddrOfInterest field, the remote device shall set the Status field to 10
NO_DESCRIPTOR, set the MatchLength field to 0, and not include the 11
MatchList field. If any simple descriptors are available for the child indicated by 12
the NWKAddrOfInterest field, the remote device shall apply the match criterion, 13
as described below, that was specified in the original Match_Desc_req command 14
to each of these simple descriptors. 15
The remote device shall apply the match criteria to each simple descriptor (see 16
sub-clause 2.3.2.5) as follows. The remote device shall first check that the 17
ProfileID field matches the application profile identifier field of the simple 18
descriptor. If the profile identifiers do not match, the remote device shall assume 19
the match to be unsuccessful and perform no further matching. 20
21
If the profile identifiers match, the remote device shall determine whether the 22
match criteria contains a list of input clusters (the NumInClusters field is not equal 23
to 0). If the match criteria contains a list of input clusters, the remote device shall 24
check that at least one of the cluster identifiers listed in the InClusterList field 25
matches one of the cluster identifiers in the application input cluster list field of 26
the simple descriptor. If at least one matching input cluster is found, the remote 27
device shall assume the match to be successful, note the identifier of the endpoint 28
to which this simple descriptor refers and perform no further matching. 29
If the remote device is unable to find any matching input clusters, it shall 30
determine whether the match criterion contains a list of output clusters (the 31
NumOutClusters field is not equal to 0). If the match criterion contains a list of 32
output clusters, the remote device shall check that at least one of the cluster 33
identifiers listed in the OutClusterList field matches one of the cluster identifiers 34
in the application output cluster list field of the simple descriptor. If at least one 35
matching output cluster is found, the remote device shall assume the match to be 36
successful and note the identifier of the endpoint to which this simple descriptor 37
refers. If the remote device is unable to find any output matching clusters, it shall 38
assume the match to be unsuccessful. 39
40
If the above procedure produces one or more matches, the remote device shall 41
construct a separate Match_Desc_rsp command for each matching device 42
(including itself). For each response, the Status field shall be set to SUCCESS, the 43
NWKAddrOfInterest field shall be set to the address of the appropriate matching 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 165
device, the MatchLength field shall be set to the number of simple descriptors that
matched the criteria for the appropriate matching device, and the MatchList field 1
shall contain an ascending list of the endpoints on which a simple descriptor 2
matched the criteria for the appropriate matching device. 3
4
2.4.4.1.7.2 Effect on Receipt 5
6
On receipt of the Match_Desc_rsp command, the recipient is either notified of the 7
results of its match criterion query indicated in the original Match_Desc_req 8
command or notified of an error. If the Match_Desc_rsp command is received 9
with a Status of SUCCESS, the MatchList field shall contain the list of endpoints 10
containing simple descriptors that matched the criterion. Otherwise, the Status 11
field indicates the error and the MatchList field shall not be included. 12
2.4.4.1.8 Complex_Desc_rsp 13
14
The Complex_Desc_rsp command (ClusterID=0x8010) shall be formatted as 15
illustrated in Figure 2.69. 16
17
Octet: 1 2 1 Variable 18
Status NWKAddr Length Complex 19
OfInterest Descriptor 20
21
Figure 2.69 Format of the Complex_Desc_rsp Command Frame 22
23
Table 2.96 specifies the fields of the Complex_Desc_rsp command frame. 24
Table 2.96 Fields of the Complex_Desc_rsp Command 25
26
Name Type Valid Range Description
27
Status Integer SUCCESS, The status of the 28
DEVICE_NOT_FOUND, Complex_Desc_req command. 29
INV_REQUESTTYPE or 30
NO_DESCRIPTOR
31
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request. 32
Address 33
Length Integer 0x00-0xff Length in bytes of the 34
ComplexDescriptor field. 35
ComplexDescriptor Complex See the Complex Descriptor 36
Descript format in sub-clause 2.3.2.6. 37
or This field shall only be 38
included in the frame if the 39
status field is equal to
40
SUCCESS.
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
166 Application Layer Specification
2.4.4.1.9 User_Desc_rsp
1
The User_Desc_rsp command (ClusterID=0x8011) shall be formatted as 2
illustrated in Figure 2.70. 3
4
Octet: 1 2 1 Variable
5
Status NWKAddr Length User 6
OfInterest Descriptor 7
8
Figure 2.70 Format of the User_Desc_rsp Command Frame
9
Table 2.97 specifies the fields of the User_Desc_rsp command frame. 10
11
Table 2.97 Fields of the User_Desc_rsp Command 12
Name Type Valid Range Description 13
14
Status Integer SUCCESS, The status of the 15
NOT_SUPPORTED, User_Desc_req 16
DEVICE_NOT_FOUND, command.
INV_REQUESTTYPE or 17
NO_DESCRIPTOR 18
19
NWKAddrOfInterest Device 16-bit NWK address NWK address for the
Address request. 20
21
Length Integer 0x00-0x10 Length in bytes of the 22
UserDescriptor field.
23
UserDescriptor User See the User Descriptor 24
Descriptor format in sub- 25
clause 2.3.2.7. This
26
field shall only be
included in the frame if 27
the status field is equal 28
to SUCCESS. 29
30
2.4.4.1.9.1 When Generated 31
32
The User_Desc_rsp is generated by a remote device in response to a 33
User_Desc_req directed to the remote device. This command shall be unicast to 34
the originator of the User_Desc_req command. 35
The remote device shall generate the User_Desc_rsp command using the format 36
illustrated in Table 2.97. The NWKAddrOfInterest field shall match that specified 37
in the original User_Desc_req command. If the NWKAddrOfInterest field 38
matches the network address of the remote device but a user descriptor does not 39
exist, it shall set the Status field to NO_DESCRIPTOR, set the Length field to 0, 40
and not include the UserDescriptor field. If the NWKAddrOfInterest field 41
matches the network address of the remote device and a user descriptor exists, it 42
shall set the Status field to SUCCESS, set the Length field to the length of the user 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
168 Application Layer Specification
descriptor, and include its user descriptor (see sub-clause 2.3.2.7) in the
UserDescriptor field. 1
2
If the NWKAddrOfInterest field does not match the network address of the 3
remote device and it is an end device, it shall set the Status field to 4
INV_REQUESTTYPE, set the Length field to 0, and not include the 5
UserDescriptor field. If the NWKAddrOfInterest field does not match the network 6
address of the remote device and it is the coordinator or a router, it shall determine 7
whether the NWKAddrOfInterest field matches the network address of one of its 8
children. If the NWKAddrOfInterest field does not match the network address of 9
one of the children of the remote device, it shall set the Status field to 10
DEVICE_NOT_FOUND, set the Length field to 0, and not include the 11
UserDescriptor field. If the NWKAddrOfInterest matches the network address of 12
one of the children of the remote device, it shall determine whether a user 13
descriptor for that device is available. If a user descriptor is not available for the 14
child indicated by the NWKAddrOfInterest field, the remote device shall set the 15
Status field to NO_DESCRIPTOR, set the Length field to 0, and not include the 16
UserDescriptor field. If a user descriptor is available for the child indicated by the 17
NWKAddrOfInterest field, the remote device shall set the Status field to 18
SUCCESS, set the Length field to the length of the user descriptor for that device, 19
and include the user descriptor (see sub-clause 2.3.2.7) of the matching child 20
device in the UserDescriptor field. 21
22
2.4.4.1.9.2 Effect on Receipt 23
On receipt of the User_Desc_rsp command, the recipient is either notified of the 24
user descriptor of the remote device indicated in the original User_Desc_req 25
command or notified of an error. If the User_Desc_rsp command is received with 26
a Status of SUCCESS, the UserDescriptor field shall contain the requested user 27
descriptor. Otherwise, the Status field indicates the error and the UserDescriptor 28
field shall not be included. 29
30
2.4.4.1.10 System_Server_Discovery_rsp 31
32
The System_Server_Discovery_rsp command (ClusterID=0x8015) shall be
33
formatted as illustrated in Figure 2.74.
34
Octet: 1 2 35
36
Status ServerMask 37
Figure 2.71 System_Server_Discovery_rsp Command Frame 38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 169
2.4.4.1.13 Discovery_store_rsp
1
The Discovery_store_rsp command (ClusterID=0x8016) shall be formatted as 2
illustrated in Figure 2.74. 3
4
Octets: 1
5
Status 6
7
Figure 2.74 Format of the Discovery_store_rsp Command Frame 8
9
Table 2.101 specifies the fields of the Discovery_store_rsp command frame 10
Table 2.101 Fields of the Discovery_store_rsp Command 11
12
Name Type Valid Range Description
13
Status Integer SUCCESS, The status of the 14
INSUFFICIENT_SPACE Discovery_store_req 15
or NOT_SUPPORTED command. 16
17
2.4.4.1.13.1 When Generated 18
19
The Discovery_store_rsp is provided to notify a Local Device of the request status 20
from a Primary Discovery Cache device. Included in the response is a status code 21
to notify the Local Device whether the request is successful (the Primary Cache 22
Device has space to store the discovery cache data for the Local Device), whether 23
the request is unsupported (meaning the Remote Device is not a Primary 24
Discovery Cache device), or insufficient space exists. 25
26
2.4.4.1.13.2 Effect on Receipt 27
Upon receipt, the Local Device shall determine whether the response status 28
indicates that the Remote Device is not a Primary Cache Device as indicated by a 29
NOT_SUPPORTED status. If a NOT_SUPPORTED status is returned, the Local 30
Device should process any other Discovery_store_rsp devices from other Remote 31
Devices or re-perform the Discovery_Cache_req to determine the address of 32
another Primary Discovery Cache device (eliminating the address of the Remote 33
Device that responded with NOT_SUPPORTED if it responds again to the 34
Discovery_Cache_req). If an INSUFFICIENT_SPACE status is returned, the 35
Local Device should also process any other Discovery_store_rsp and re-perform 36
the Discovery_Cache_req if none of the responses indicate SUCCESS (with the 37
radius field increased to include more Remote Devices). If a SUCCESS status is 38
returned, the Local Device shall upload its discovery cache information to the 39
Remote Device via the Node_Desc_store_req, Power_Desc_store_req, 40
Active_EP_store_req, and Simple_Desc_store_req. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 173
2.4.4.1.14 Node_Desc_store_rsp
1
The Node_Desc_store_rsp command (ClusterID=0x8017) shall be formatted as 2
illustrated in Figure 2.75. 3
4
Octets: 1
5
Status 6
7
Figure 2.75 Format of the Node_Desc_store_rsp Command Frame 8
9
Table 2.102 specifies the fields of the Node_Desc_store_rsp command frame. 10
Table 2.102 Fields of the Node_Desc_store_rsp Command 11
12
Name Type Valid Range Description
13
Status Integer SUCCESS, The status of the Node_store_rsp 14
INSUFFICIENT_SPACE, command. 15
NOT_PERMITTED or 16
NOT_SUPPORTED 17
18
2.4.4.1.14.1 When Generated 19
20
The Node_store_rsp is provided to notify a Local Device of the request status 21
from a Primary Discovery Cache device. Included in the response is a status code 22
to notify the Local Device whether the request is successful (the Primary Cache 23
Device has space to store the discovery cache data for the Local Device), whether 24
the request is not supported (meaning the Remote Device is not a Primary 25
Discovery Cache device), or insufficient space exists. 26
27
2.4.4.1.14.2 Effect on Receipt 28
29
Upon receipt, the Local Device shall determine whether the response status 30
indicates that the Remote Device is not a Primary Cache Device as indicated by a 31
NOT_SUPPORTED status. If a NOT_SUPPORTED status is returned, the Local 32
Device should re-perform discovery of the Primary Discovery Cache device. If a 33
NOT_PERMITTED status is returned, the local device must first issue a 34
Discovery_store_req with a returned SUCCESS status. If an 35
INSUFFICIENT_SPACE status is returned, the Local Device shall also send the 36
Remote Device a Remove_node_cache_req. If a SUCCESS status is returned, the 37
Local Device should continue to upload its remaining discovery cache 38
information to the Remote Device via the Power_Desc_store_req, 39
Active_EP_store_req, and Simple_Desc_store_req. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
174 Application Layer Specification
2.4.4.1.15 Power_Desc_store_rsp
1
The Power_Desc_store_rsp command (ClusterID=0x8018) shall be formatted as 2
illustrated in Figure 2.76. 3
4
Octets: 1 8 Variable
5
Status IEEEAddr PowerDescriptor 6
7
Figure 2.76 Format of the Power_Desc_store_rsp Command Frame 8
9
Table 2.103 specifies the fields of the Power_Desc_store_rsp command frame. 10
Table 2.103 Fields of the Power_Desc_store_rsp Command 11
12
Name Type Valid Range Description
13
Status Integer SUCCESS, The status of the Power_store_rsp 14
INSUFFICIENT_SPACE, command. 15
NOT_PERMITTED or 16
NOT_SUPPORTED 17
18
2.4.4.1.15.1 When Generated 19
20
The Power_Desc_store_rsp is provided to notify a Local Device of the request 21
status from a Primary Discovery Cache device. Included in the response is a status 22
code to notify the Local Device whether the request is successful (the Primary 23
Cache Device has space to store the discovery cache data for the Local Device), 24
whether the request is not supported (meaning the Remote Device is not a Primary 25
Discovery Cache device), or insufficient space exists. 26
27
2.4.4.1.15.2 Effect on Receipt 28
29
Upon receipt, the Local Device shall determine whether the response status 30
indicates that the Remote Device is not a Primary Cache Device as indicated by a 31
NOT_SUPPORTED status. If a NOT_SUPPORTED status is returned, the Local 32
Device should re-perform discovery on the Primary Discovery Cache. If a 33
NOT_PERMITTED status is returned, the local device must first issue a 34
Discovery_store_req with a returned SUCCESS status. If an 35
INSUFFICIENT_SPACE status is returned, the Local Device shall discontinue 36
upload of discovery information, issue a Remove_node_cache_req (citing the 37
Local Device), and cease attempts to upload discovery information to the Remote 38
Device. 39
If a SUCCESS status is returned, the Local Device should continue to upload its 40
remaining discovery cache information to the Remote Device via the 41
Active_EP_store_req and Simple_Desc_store_req. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 175
2.4.4.1.16 Active_EP_store_rsp
1
The Active_EP_store_rsp command (ClusterID=0x8019) shall be formatted as 2
illustrated in Figure 2.77. 3
4
Octets: 1
5
Status 6
7
Figure 2.77 Format of the Active_EP_store_rsp Command Frame 8
9
Table 2.104 specifies the fields of the Active_EP_store_rsp command frame. 10
Table 2.104 Fields of the Active_EP_store_rsp Command 11
12
Name Type Valid Range Description
13
Status Integer SUCCESS, The status of the 14
INSUFFICIENT_SPACE Active_EP_store_rsp command. 15
, NOT_PERMITTED or 16
NOT_SUPPORTED
17
18
2.4.4.1.16.1 When Generated 19
20
The Active_EP_store_rsp is provided to notify a Local Device of the request
21
status from a Primary Discovery Cache device. Included in the response is a status
22
code to notify the Local Device whether the request is successful (the Primary
23
Cache Device has space to store the discovery cache data for the Local Device),
24
the request is not supported (meaning the Remote Device is not a Primary
25
Discovery Cache device), or insufficient space exists.
26
27
2.4.4.1.16.2 Effect on Receipt
28
Upon receipt, the Local Device shall determine whether the response status 29
indicates that the Remote Device is not a Primary Cache Device as indicated by a 30
NOT_SUPPORTED status. If a NOT_SUPPORTED status is returned, the Local 31
Device should re-perform discovery on the Primary Discovery Cache. If a 32
NOT_PERMITTED status is returned, the local device must first issue a 33
Discovery_store_req with a returned SUCCESS status. If an 34
INSUFFICIENT_SPACE status is returned, the Local Device shall discontinue 35
upload of discovery information, issue a Remove_node_cache_req (citing the 36
Local Device), and cease attempts to upload discovery information to the Remote 37
Device. If a SUCCESS status is returned, the Local Device should continue to 38
upload its remaining discovery cache information to the Remote Device via the 39
Simple_Desc_store_req. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
176 Application Layer Specification
2.4.4.1.17 Simple_Desc_store_rsp
1
The Simple_Desc_store_rsp command (ClusterID=0x801a) shall be formatted as 2
illustrated in Figure 2.78. 3
4
Octets: 1
5
Status 6
7
Figure 2.78 Format of the Simple_Desc_store_rsp Command Frame 8
9
Table 2.105 specifies the fields of the Simple_Desc_store_rsp command frame. 10
Table 2.105 Fields of the Simple_Desc_store_rsp Command 11
12
Name Type Valid Range Description
13
Status Integer SUCCESS, The status of the 14
INSUFFICIENT_SPACE, Simple_desc_store_rsp 15
NOT_PERMITTED or command. 16
NOT_SUPPORTED
17
18
2.4.4.1.17.1 When Generated 19
20
The Simple_Desc_store_rsp is provided to notify a Local Device of the request
21
status from a Primary Discovery Cache device. Included in the response is a status
22
code to notify the Local Device whether the request is successful (the Primary
23
Cache Device has space to store the discovery cache data for the Local Device),
24
the request is not supported (meaning the Remote Device is not a Primary
25
Discovery Cache device), or insufficient space exists.
26
27
2.4.4.1.17.2 Effect on Receipt
28
Upon receipt, the Local Device shall determine whether the response status 29
indicates that the Remote Device is not a Primary Cache Device as indicated by a 30
NOT_SUPPORTED status. If a NOT_SUPPORTED status is returned, the Local 31
Device should re-perform discovery on the Primary Discovery Cache. If a 32
NOT_PERMITTED status is returned, the local device must first issue a 33
Discovery_store_req with a returned SUCCESS status. If an 34
INSUFFICIENT_SPACE status is returned, the Local Device shall discontinue 35
upload of discovery information, issue a Remove_node_cache_req (citing the 36
Local Device), and cease attempts to upload discovery information to the Remote 37
Device. If a SUCCESS status is returned, the Local Device should continue to 38
upload its remaining discovery cache information to the Remote Device via the 39
Simple_Desc_store_req for other endpoints on the Local Device. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 177
2.4.4.1.18 Remove_node_cache_rsp
1
The Remove_node_cache_rsp command (ClusterID=0x801b) shall be formatted 2
as illustrated in Figure 2.79. 3
4
Octets: 1
5
Status 6
7
Figure 2.79 Format of the Remove_node_cache_rsp Command Frame 8
9
Table 2.106 specifies the fields of the Remove_node_cache_rsp command frame. 10
Table 2.106 Fields of the Remove_node_cache_rsp Command 11
12
Name Type Valid Range Description
13
Status Integer SUCCESS, The status of the 14
DEVICE_NOT_FOUND Remove_node_cache_rsp command 15
or NOT_SUPPORTED 16
17
2.4.4.1.18.1 When Generated 18
19
The Remove_node_cache_rsp is provided to notify a Local Device of the request 20
status from a Primary Discovery Cache device. Included in the response is a status 21
code to notify the Local Device whether the request is successful (the Primary 22
Cache Device has removed the discovery cache data for the indicated device of 23
interest), or the request is not supported (meaning the Remote Device is not a 24
Primary Discovery Cache device). 25
26
2.4.4.1.18.2 Effect on Receipt 27
Upon receipt, the Local Device shall determine whether the response status 28
indicates that the Remote Device is not a Primary Cache Device as indicated by a 29
NOT_SUPPORTED status. If a NOT_SUPPORTED status is returned, the Local 30
Device should re-perform Find_node_cache_req to locate the Primary Discovery 31
Cache device holding the discovery cache information for the indicated device of 32
interest. When the Primary Discovery Cache device holding the discovery 33
information for the device of interest is located, the Local Device should repeat 34
the Remove_node_cache_req to successfully remove the discovery information. If 35
a status of DEVICE_NOT_FOUND is received, this indicates that the Remote 36
Device is the Primary Discovery Cache but does not hold the discovery 37
information for the NWKAddr and the IEEEAddr presented in the request. The 38
Local Device should employ the device discovery commands NWK_Addr_req 39
and IEEE_Addr_req to determine the correct values for NWKAddr and 40
IEEEAddr. If a SUCCESS status is returned, the Local Device has successfully 41
removed the discovery cache information for the indicated device of interest 42
within the request. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
178 Application Layer Specification
2.4.4.1.19 Find_node_cache_rsp
1
The Find_node_cache_rsp command (ClusterID=0x801c) shall be formatted as 2
illustrated in Figure 2.80. 3
4
Octets: 2 2 8
5
CacheNWKAddress NWKAddr IEEEAddr 6
7
Figure 2.80 Format of the Find_node_cache_rsp Command Frame 8
9
Table 2.107 specifies the fields of the Find_node_cache_rsp command frame. 10
Table 2.107 Fields of the Find_node_cache_rsp Command 11
12
Name Type Valid Range Description
13
CacheNWKAddr Device 16-bit NWK Address NWK Address for the Primary 14
Address Discovery Cache device holding 15
the discovery information (or the 16
device of interest if it responded to
the request directly). 17
18
NWKAddr Device 16-bit NWK Address NWK Address for the device of 19
Address interest.
20
IEEEAddr Device 64-bit IEEE Address IEEE address for the device of 21
Address interest. 22
23
2.4.4.1.19.1 When Generated 24
25
The Find_node_cache_rsp is provided to notify a Local Device of the successful 26
discovery of the Primary Discovery Cache device for the given NWKAddr and 27
IEEEAddr fields supplied in the request, or to signify that the device of interest is 28
capable of responding to discovery requests. The Find_node_cache_rsp shall be 29
generated only by Primary Discovery Cache devices holding discovery 30
information for the NWKAddr and IEEEAddr in the request or the device of 31
interest itself and all other Remote Devices shall not supply a response. 32
33
2.4.4.1.19.2 Effect on Receipt 34
Upon receipt, the Local Device shall utilize the CacheNWKAddr as the Remote 35
Device address for subsequent discovery requests relative to the NWKAddr and 36
IEEEAddr in the response. 37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 179
2.4.4.1.20 Extended_Simple_Desc_rsp
1
The Extended_Simple_Desc_rsp command (ClusterID=0x801d) shall be 2
formatted as illustrated in Figure 2.81. 3
4
Octet:1 2 1 1 1 1 Variable
5
Status NWKAddr Endpoint AppInput AppOutput StartIndex AppCluster 6
OfInterest ClusterCount ClusterCount List 7
8
Figure 2.81 Format of the Extended_Simple_Desc_rsp Command Frame
9
Table 2.108 specifies the fields of the Extended_Simple_Desc_rsp command 10
frame. 11
12
Table 2.108 Fields of the Extended_Simple_Desc_rsp Command 13
Name Type Valid Range Description 14
15
Status Integer SUCCESS, The status of the 16
INVALID_EP, Extended_Simple_Desc_req 17
NOT_ACTIVE, command.
DEVICE_NOT_FOUND, 18
INV_REQUESTTYPE or 19
NO_DESCRIPTOR 20
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request. 21
Address 22
23
Endpoint 8 bits 1-240 The endpoint on the
destination.
24
25
AppInputClusterCou 8 bits 0x00-0xff The total count of application 26
nt input clusters in the Simple
27
Descriptor for this endpoint.
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
180 Application Layer Specification
field does not correspond to an active endpoint, the remote device shall set the
Status field to NOT_ACTIVE, set the StartIndex field to the value supplied in the 1
request, and not include the AppClusterList field. 2
3
2.4.4.1.20.2 Effect on Receipt 4
5
On receipt of the Extended_Simple_Desc_rsp command, the recipient is either 6
notified of the requested AppClusterList on the endpoint of the remote device 7
indicated in the original Extended_Simple_Desc_req command or notified of an 8
error. If the Extended_Simple_Desc_rsp command is received with a Status of 9
SUCCESS, the AppClusterList field shall contain the requested portion of the 10
application input cluster list and application output cluster list, starting with the 11
StartIndex. Otherwise, the Status field indicates the error and the AppClusterList 12
field shall not be included. 13
2.4.4.1.21 Extended_Active_EP_rsp 14
15
The Extended_Active_EP_rsp command (ClusterID=0x801e) shall be formatted 16
as illustrated in Figure 2.82. 17
18
Octet: 1 2 1 1 Variable 19
Status NWKAddr ActiveEP StartIndex ActiveEP 20
OfInterest Count List 21
22
Figure 2.82 Format of the Extended_Active_EP_rsp Command Frame 23
24
Table 2.109 specifies the fields of the Extended_Active_EP_rsp command frame. 25
Table 2.109 Fields of the Extended_Active_EP_rsp Command 26
27
Name Type Valid Range Description
28
Status Integer SUCCESS, The status of the 29
DEVICE_NOT_FOUND Extended_Active_EP_req 30
, INV_REQUESTTYPE command. 31
or NO_DESCRIPTOR
32
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request. 33
Address 34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
182 Application Layer Specification
ActiveEPList field. If the cached device has no active endpoints, the remote
device shall set the Status field to SUCCESS, set the ActiveEPCount field to 0, 1
and not include the ActiveEPList field. If the cached device has active endpoints, 2
the remote device shall set the Status field to SUCCESS, set the ActiveEPCount 3
field to the number of active endpoints on that device and include an ascending 4
list of all the identifiers of the active endpoints, beginning with StartIndex, on that 5
device in the ActiveEPList field. 6
7
2.4.4.1.21.2 Effect on Receipt 8
9
On receipt of the Extended_Active_EP_rsp command, the recipient is either 10
notified of the active endpoints of the remote device indicated in the original 11
Extended_Active_EP_req command or notified of an error. If the 12
Extended_Active_EP_rsp command is received with a Status of SUCCESS, the 13
ActiveEPCount field indicates the number of entries in the ActiveEPList field. 14
Otherwise, the Status field indicates the error and the ActiveEPList field shall not 15
be included. The requesting device may need to employ 16
Extended_Active_EP_req multiple times, with different StartIndex values, to 17
receive the full ActiveEPList from the remote device. 18
19
2.4.4.2 End Device Bind, Bind, Unbind Bind Management 20
Server Services 21
22
Table 2.110 lists the commands supported by Device Profile: End Device Bind, 23
Bind and Unbind Server Services. Each of these primitives will be discussed in 24
the following sub-clauses. 25
Table 2.110 End Device Bind, Unbind and Bind Management 26
Server Services Primitives 27
28
End Device Bind, Bind and Unbind Server
Server Service Commands Processing 29
30
End_Device_Bind_rsp O 31
Bind_rsp O 32
33
Unbind_rsp O
34
Bind_Register_rsp O 35
Replace_Device_rsp O 36
37
Store_Bkup_Bind_Entry_rsp O
38
Remove_Bkup_Bind_Entry_rsp O 39
Backup_Bind_Table_rsp O 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
184 Application Layer Specification
INVALID_EP shall be returned. If the supplied endpoint falls within the specified
range and if this is the first End_Device_Bind_req submitted for evaluation, it 1
shall be stored and a timer started which expires at a pre-configured timeout 2
value. This timeout value shall be a configurable item on the ZigBee Coordinator. 3
If the timer expires before a second End_Device_Bind_req is received, a Status of 4
TIMEOUT is returned. Otherwise, if a second End_Device_Bind_req is received 5
within the timeout window, the two End_Device_Bind_req's are compared for a 6
match. A Status of NO_MATCH indicates that two End_Device_Bind_req were 7
evaluated for a match, but either the ProfileID parameters did not match or the 8
ProfileID parameter matched but there was no match of any element of the 9
InClusterList or OutClusterList. A Status of SUCCESS means that a match was 10
detected and a resulting Bind_req will subsequently be directed to the device 11
indicated by the BindingTarget field of the End_Device_Bind_req with matched 12
elements of the OutClusterList. 13
14
2.4.4.2.2 Bind_rsp 15
The Bind_rsp command (ClusterID=0x8021) shall be formatted as illustrated in 16
Figure 2.84. 17
18
Octets: 1 19
20
Status
21
Figure 2.84 Format of the Bind_rsp Command Frame 22
23
Table 2.112 specifies the fields of the Bind_rsp command frame. 24
25
Table 2.112 Fields of the Bind_rsp Command
26
Name Type Valid Range Description 27
28
Status Integer SUCCESS, The status of the Bind_req command.
NOT_SUPPORTED, 29
INVALID_EP, 30
TABLE_FULL or 31
NOT_AUTHORIZED 32
33
2.4.4.2.2.1 When Generated 34
35
The Bind_rsp is generated in response to a Bind_req. If the Bind_req is processed 36
and the Binding Table entry committed on the Remote Device, a Status of 37
SUCCESS is returned. If the Remote Device is not a Primary binding table cache 38
or the SrcAddress, a Status of NOT_SUPPORTED is returned. The supplied 39
endpoint shall be checked to determine whether it falls within the specified range. 40
If it does not, a Status of INVALID_EP shall be returned. If the Remote Device is 41
the Primary binding table cache or SrcAddress but does not have Binding Table 42
resources for the request, a Status of TABLE_FULL is returned. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
186 Application Layer Specification
2.4.4.2.4 Bind_Register_rsp
1
The Bind_Register_rsp command (ClusterID=0x8023) shall be formatted as 2
illustrated in Figure 2.86. 3
4
Octets: 1 2 2 Variable
5
Status BindingTableEntries BindingTableListCount BindingTableList 6
7
Figure 2.86 Format of the Bind_Register_rsp Command Frame 8
9
Table 2.114 specifies the fields of the Bind_Register_rsp command frame. 10
Table 2.114 Fields of the Bind_Register_rsp Command 11
12
Name Type Valid Range Description
13
Status Integer SUCCESS, The status of the Bind_Register_reg 14
NOT_SUPPORTED, command. 15
TABLE_FULL 16
BindingTable Integer 0x0000 - 0ffff Number of binding table entries for 17
Entries the requesting device held by the 18
primary binding table cache. 19
BindingTable Integer 0x0000 - 0xffff Number of source binding table 20
ListCount entries contained in this response. 21
BindingTable List of This list shall contain the A list of source binding. 22
List source number of elements 23
binding given by the 24
descriptors BindingTableListCount 25
26
2.4.4.2.4.1 When Generated 27
28
The Bind_Register_rsp is generated from a primary binding table cache device in 29
response to a Bind_Register_req and contains the status of the request. This 30
command shall be unicast to the requesting device. 31
If the device receiving the Bind_Register_req is not a primary binding table cache 32
a Status of NOT_SUPPORTED is returned. If its list of devices which choose to 33
store their own binding table entries is full, a status of TABLE_FULL is returned. 34
In these error cases, BindingTableEntries and BindingTableListCount shall be 35
zero and BindingTableList shall be empty. A Status of SUCCESS indicates that 36
the requesting device has been successfully registered. 37
38
In the successful case, the primary binding table cache device shall search its 39
cache for existing entries whose source address is the same as the parameter 40
supplied in the Bind_Register_req command. The number of such entries is given 41
in the response as BindingTableEntries. The entries are used to generate 42
BindingTableList up to the maximum that can be contained in the response. The 43
actual number of entries is given in the response as BindingTableListCount and 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
188 Application Layer Specification
may be less than BindingTableEntries if this is too large. In this case (which is
expected to be rare) the primary binding table cache device shall use Bind_req 1
commands to send the rest of the entries to the requesting device. 2
3
2.4.4.2.4.2 Effect on Receipt 4
5
The requesting device is notified of the results of its attempt to register. If 6
successful, it shall store the source binding table entries from the response into its 7
source binding table. 8
2.4.4.2.5 Replace_Device_rsp 9
10
The Replace_Device_rsp command (ClusterID=0x8024) shall be formatted as 11
illustrated in Figure 2.87. 12
13
Octets: 1 14
Status 15
16
Figure 2.87 Format of the Replace_Device_rsp Command Frame 17
18
Table 2.115 specifies the fields of the Replace_Device_rsp command frame 19
Table 2.115 Fields of the Replace_Device_rsp Command 20
21
Name Type Valid Range Description 22
Status Integer NOT_SUPPORTED, The status of the Replace_Device_req 23
INV_REQUESTTYPE command. 24
25
2.4.4.2.5.1 When Generated 26
27
The Replace_Device_rsp is generated from a primary binding table cache device 28
in response to a Replace_Device_req and contains the status of the request. This 29
command shall be unicast to the requesting device. If the device receiving the 30
Replace_Device_req is not a primary binding table cache, a Status of 31
NOT_SUPPORTED is returned. The primary binding table cache shall search its 32
binding table for entries whose source address and source endpoint, or whose 33
destination address and destination endpoint match OldAddress and OldEndpoint, 34
as described in the text for Replace_Device_req. It shall change these entries to 35
have NewAddress and possibly NewEndpoint. It shall then return a response of 36
SUCCESS. 37
38
2.4.4.2.5.2 Effect on Receipt 39
40
The requesting device is notified of the status of its Replace_Device_req 41
command. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 189
2.4.4.2.6 Store_Bkup_Bind_Entry_rsp
1
The Store_Bkup_Bind_Entry_rsp command (ClusterID=0x8025) shall be 2
formatted as illustrated in Figure 2.88. 3
4
Octets: 1
5
Status 6
7
Figure 2.88 Format of the Store_Bkup_Bind_Entry_rsp Command Frame 8
9
Table 2.116 specifies the fields of the Store_Bkup_Bind_Entry_rsp command 10
frame. 11
Table 2.116 Fields of the Store_Bkup_Bind_Entry_rsp Command 12
13
Name Type Valid Range Description
14
Status Integer SUCCESS, The status of the 15
NOT_SUPPORTED, Store_Bkup_Bind_Entry_rsp command. 16
INV_REQUESTTYPE. 17
TABLE_FULL
18
19
2.4.4.2.6.1 When Generated 20
21
The Store_Bkup_Bind_Entry_rsp is generated from a backup binding table cache
22
device in response to a Store_Bkup_Bind_Entry_req from a primary binding table
23
cache, and contains the status of the request. This command shall be unicast to the
24
requesting device. If the remote device is not a backup binding table cache, it shall
25
return a status of NOT_SUPPORTED. If the originator of the request is not
26
recognized as a primary binding table cache, it shall return a status of
27
INV_REQUESTTYPE. Otherwise, the backup binding table cache shall add the
28
binding entry to its binding table and return a status of SUCCESS. If there is no
29
room, it shall return a status of TABLE_FULL.
30
31
2.4.4.2.6.2 Effect on Receipt
32
The requesting device is notified of the status of its attempt to store a bind entry. 33
34
2.4.4.2.7 Remove_Bkup_Bind_Entry_rsp 35
The Remove_Bkup_Bind_Entry_rsp command (ClusterID=0x8026) shall be 36
formatted as illustrated in Figure 2.89. 37
38
Octets: 1 39
40
Status
41
Figure 2.89 Format of the Remove_Bkup_Bind_Entry_rsp Command Frame 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
190 Application Layer Specification
2.4.4.2.10 Backup_Source_Bind_rsp
1
The Backup_Source_Bind_rsp command (ClusterID=0x8029) shall be formatted 2
as illustrated in Figure 2.92. 3
4
Octets: 1
5
Status 6
7
Figure 2.92 Format of the Backup_Source_Bind_rsp Command Frame 8
9
Table 2.120 specifies the fields of the Backup_Source_Bind_rsp command frame. 10
Table 2.120 Fields of the Backup_Source_Bind_rsp Command 11
12
Name Type Valid Range Description
13
Status Integer SUCCESS, The status of the 14
NOT_SUPPORTED, Backup_Source_Bind_rsp 15
TABLE_FULL, command. 16
INV_REQUESTTYPE
17
18
2.4.4.2.10.1 When Generated 19
20
The Backup_Source_Bind_rsp is generated from a backup binding table cache
21
device in response to a Backup_Source_Bind_req from a primary binding table
22
cache and contains the status of the request. This command shall be unicast to the
23
requesting device. If the remote device is not a backup binding table cache, it shall
24
return a status of NOT_SUPPORTED. If the originator of the request is not
25
recognized as a primary binding table cache, it shall return a status of
26
INV_REQUESTTYPE. Otherwise, the backup binding table cache shall
27
overwrite its backup source binding table starting with StartIndex and continuing
28
for BindingTableListCount entries. If this exceeds its table size, it shall return a
29
status of TABLE_FULL. Otherwise it shall return a status of SUCCESS.
30
31
2.4.4.2.10.2 Effect on Receipt
32
The requesting device is notified of the status of its attempt to backup the source 33
binding table. 34
35
2.4.4.2.11 Recover_Source_Bind_rsp 36
The Recover_Source_Bind_rsp command (ClusterID=0x802a) shall be formatted 37
as illustrated in Figure 2.93. 38
39
Octets: 1 2 2 2 Variable 40
41
Status SourceTableEntries StartIndex SourceTableListCount SourceTableList
42
Figure 2.93 Format of the Recover_Source_Bind_rsp Command Frame 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
194 Application Layer Specification
2.4.4.3.2 Mgmt_Lqi_rsp
1
The Mgmt_Lqi_rsp command (ClusterID=0x8031) shall be formatted as 2
illustrated in Figure 2.95. 3
4
Octets: 1 1 1 1 Variable
5
Status NeighborTable Start NeighborTable NeighborTable 6
Entries Index ListCount List 7
8
Figure 2.95 Format of the Mgmt_Lqi_rsp Command Frame
9
Table 2.125 specifies the fields of the Mgmt_Lqi_rsp command frame. 10
11
Table 2.125 Fields of the Mgmt_Lqi_rsp Command 12
Name Type Valid Range Description 13
14
Status Integer NOT_SUPPORTED or The status of the 15
any status code returned Mgmt_Lqi_req command. 16
from the NLME-
GET.confirm primitive 17
18
NeighborTableEntries Integer 0x00-0xff Total number of Neighbor 19
Table entries within the
Remote Device. 20
21
StartIndex Integer 0x00-0xff Starting index within the 22
Neighbor Table to begin
reporting for the
23
NeighborTableList. 24
25
NeighborTableListCount Integer 0x00-0x02 Number of Neighbor Table
26
entries included within
NeighborTableList. 27
28
NeighborTableList List of The list shall contain the A list of descriptors,
29
Neighbor number elements given beginning with the
Descriptors by the StartIndex element and 30
NeighborTableListCount continuing for 31
NeighborTableListCount, 32
of the elements in the 33
Remote Device's Neighbor
34
Table including the device
address and associated LQI 35
(see Table 2.126 for 36
details). 37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 199
The extended address, device type, RxOnWhenIdle, and permit joining fields
have “unknown” values which shall be returned where the values are not 1
available. 2
3
2.4.4.3.2.2 Effect on Receipt 4
5
The local device is notified of the results of its attempt to obtain the neighbor 6
table. 7
2.4.4.3.3 Mgmt_Rtg_rsp 8
9
The Mgmt_Rtg_rsp command (ClusterID=0x8032) shall be formatted as 10
illustrated in Figure 2.96. 11
12
Octets: 1 1 1 1 Variable 13
Status RoutingTable Start RoutingTable RoutingTable 14
Entries Index ListCount List 15
16
Figure 2.96 Format of the Mgmt_Rtg_rsp Command Frame 17
18
Table 2.127 specifies the fields of the Mgmt_Rtg_rsp command frame. 19
Table 2.127 Fields of the Mgmt_Rtg_rsp Command 20
21
Name Type Valid Range Description
22
Status Integer NOT_SUPPORTED or The status of the Mgmt_Rtg_req 23
any status code returned command. 24
from the NLME- 25
GET.confirm primitive
26
RoutingTableEntries Integer 0x00-0xff Total number of Routing Table 27
entries within the Remote Device. 28
StartIndex Integer 0x00-0xff Starting index within the Routing 29
Table to begin reporting for the 30
RoutingTableList. 31
RoutingTableListCou Integer 0x00-0xff Number of Routing Table entries 32
nt included within RoutingTableList. 33
RoutingTableList List of The list shall contain the A list of descriptors, beginning 34
Routin number elements given with the StartIndex element and 35
g by the continuing for 36
Descri RoutingTableListCount RoutingTableListCount, of the 37
ptors elements in the Remote Device's
38
Routing Table (see the
Table 2.128 for details). 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
202 Application Layer Specification
1
Table 2.128 RoutingTableList Record Format
2
Size 3
Name (Bits) Valid Range Description 4
5
Destination 16 The 16-bit network Destination address.
address address of this route. 6
7
Status 3 The status of the 0x0=ACTIVE. 8
route. 0x1=DISCOVERY_UNDERWAY. 9
0x2=DISCOVERY_FAILED. 10
0x3=INACTIVE. 11
0x4=VALIDATION_UNDERWAY 12
0x5-0x7=RESERVED. 13
14
Memory 1 A flag indicating whether the device
Constrained is a memory constrained 15
concentrator. 16
17
Many-to-one 1 A flag indicating that the destination
is a concentrator that issued a many- 18
to-one request. 19
20
Route record 1 A flag indicating that a route record
required command frame should be sent to the 21
destination prior to the next data 22
packet. 23
Reserved 2 24
25
Next-hop 16 The 16-bit network Next-hop address. 26
address address of the next
hop on the way to the
27
destination. 28
29
30
CCB #250 31
32
2.4.4.3.3.1 When Generated 33
34
The Mgmt_Rtg_rsp is generated in response to an Mgmt_Rtg_req. If this
35
management command is not supported, a status of NOT_SUPPORTED shall be
36
returned and all parameter fields after the Status field shall be omitted. Otherwise,
37
the Remote Device shall implement the following processing.
38
Upon receipt of and after support for the Mgmt_Rtg_req has been verified, the 39
Remote Device shall perform an NLME-GET.request (for the nwkRouteTable 40
attribute) and process the resulting NLME-GET.confirm (containing the 41
nwkRouteTable attribute) to create the Mgmt_Rtg_rsp command. The 42
Mgmt_Rtg_rsp command shall contain the same status that was contained in the 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 203
NLME-GET.confirm primitive and if this was not SUCCESS, all parameter fields
after the status field shall be omitted. 1
2
From the nwkRouteTable attribute, the routing table shall be accessed, starting 3
with the index specified by StartIndex, and moved to the RoutingTableList field of 4
the Mgmt_Rtg_rsp command. The entries reported from the routing table shall be 5
those, starting with StartIndex and including whole RoutingTableList records (see 6
Table 2.127) until MSDU size limit, i.e., aMaxMACFrameSize (see [B1]), is 7
reached. Within the Mgmt_Rtg_Rsp command, the RoutingTableEntries field 8
shall represent the total number of Routing Table entries in the Remote Device. 9
The RoutingTableListCount field shall be the number of entries reported in the 10
RoutingTableList field of the Mgmt_Rtg_req command. 11
12
2.4.4.3.3.2 Effect on Receipt 13
The local device is notified of the results of its attempt to obtain the routing table. 14
15
2.4.4.3.4 Mgmt_Bind_rsp 16
17
The Mgmt_Bind_rsp command (ClusterID=0x8033) shall be formatted as
18
illustrated in Figure 2.97.
19
Octets: 1 1 1 1 Variable 20
21
Status BindingTable Start BindingTable BindingTable 22
Entries Index ListCount List
23
Figure 2.97 Format of the Mgmt_Bind_rsp Command Frame 24
25
Table 2.129 specifies the fields of the Mgmt_Bind_rsp command frame. 26
27
Table 2.129 Fields of the Mgmt_Bind_rsp Command
28
Name Type Valid Range Description 29
30
Status Integer NOT_SUPPORTED or The status of the
any status code returned Mgmt_Bind_req command. 31
from the APSME- 32
GET.confirm primitive 33
BindingTableEntries Integer 0x00-0xff Total number of Binding 34
Table entries within the 35
Remote Device. 36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
204 Application Layer Specification
2.4.4.3.6 Mgmt_Direct_Join_rsp
1
The Mgmt_Direct_Join_rsp (ClusterID=0x8035) shall be formatted as illustrated 2
in Figure 2.99. 3
4
Octets: 1
5
Status 6
7
Figure 2.99 Format of the Mgmt_Direct_Join_rsp Command Frame 8
9
Table 2.132 specifies the fields of the Mgmt_Direct_Join_rsp command frame. 10
Table 2.132 Fields of the Mgmt_Direct_Join_rsp Command 11
12
Name Type Valid Range Description
13
Status Integer NOT_SUPPORTED, The status of the 14
NOT_AUTHORIZED or any Mgmt_Direct_Join_req 15
status code returned from the command. 16
NLME-DIRECT-JOIN.confirm
primitive 17
18
19
2.4.4.3.6.1 When Generated 20
The Mgmt_Direct_Join_rsp is generated in response to a Mgmt_Direct_Join_req. 21
If this management command is not supported, a status of NOT_SUPPORTED 22
shall be returned. Otherwise, the Remote Device shall implement the following 23
processing. 24
25
Upon receipt and after support for the Mgmt_Direct_Join_req has been verified, 26
the Remote Device shall execute the NLME-DIRECT-JOIN.request to directly 27
associate the DeviceAddress contained in the Mgmt_Direct_Join_req to the 28
network. The Mgmt_Direct_Join_rsp shall contain the same status that was 29
contained in the NLME-DIRECT-JOIN.confirm primitive. 30
31
2.4.4.3.6.2 Effect on Receipt 32
33
Upon receipt and after support for the Mgmt_Direct_Join_req has been verified,
34
the Remote Device shall execute the NLME-DIRECT-JOIN.request to directly
35
associate the DeviceAddress contained in the Mgmt_Direct_Join_req to the
36
network.
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
208 Application Layer Specification
2.4.4.3.7 Mgmt_Permit_Joining_rsp
1
The Mgmt_Permit_Joining_rsp command (ClusterID=0x8036) shall be formatted 2
as illustrated in Figure 2.100. 3
4
Octets: 1
5
Status 6
7
Figure 2.100 Format of the Mgmt_Permit_Joining_rsp Command Frame 8
9
Table 2.133 specifies the fields of the Mgmt_Permit_Joining_rsp command 10
frame. 11
Table 2.133 Fields of the Mgmt_Permit_Joining_rsp Command 12
13
Name Type Valid Range Description
14
Status Integer SUCCESS, The status of the 15
INVALID_REQUEST, Mgmt_Permit_Joining_rsp 16
NOT_AUTHORIZED or command. 17
any status code returned
from the NLME- 18
PERMIT- 19
JOINING.confirm 20
primitive 21
22
2.4.4.3.7.1 When Generated 23
24
The Mgmt_Permit_Joining_rsp is generated in response to a unicast 25
Mgmt_Permit_Joining_req. In the description which follows, note that no 26
response shall be sent if the Mgmt_Permit_Joining_req was received as a 27
broadcast to all routers. If this management command is not permitted by the 28
requesting device, a status of INVALID_REQUEST shall be returned. Upon 29
receipt and after support for Mgmt_Permit_Joining_req has been verified, the 30
Remote Device shall execute the NLME-PERMIT-JOINING.request. The 31
Mgmt_Permit-Joining_rsp shall contain the same status that was contained in the 32
NLME-PERMIT-JOINING.confirm primitive. 33
34
2.4.4.3.7.2 Effect on Receipt 35
36
The status of the Mgmt_Permit_Joining_req command is notified to the requestor.
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 209
2.4.4.3.8 Mgmt_Cache_rsp
1
The Mgmt_Cache_rsp command (ClusterID=0x8037) shall be formatted as 2
illustrated in Figure 2.101 3
4
Octets: 1 1 1 1 Variable
5
Status DiscoveryCache StartIndex DiscoveryCacheList DiscoveryCacheList 6
Entries Count 7
8
Figure 2.101 Format of the Mgmt_Cache_rsp Command Frame
9
Table 2.134 specifies the fields of the Mgmt_Cache_rsp command frame. 10
11
Table 2.134 Fields of the Mgmt_Cache_rsp Command 12
Name Type Valid Range Description 13
14
Status Integer SUCCESS or The status of the 15
NOT_SUPPORTED Mgmt_Cache_rsp command. 16
DiscoveryCacheEntries Integer 0x00 - 0xff DiscoveryCacheEntries. 17
StartIndex Integer 0x00 - 0xff StartIndex.
18
19
DiscoveryCacheListCount Integer 0x00 - 0xff The list shall contain the number 20
of elements given by the
21
DiscoveryCacheListCount
parameter. 22
23
DiscoveryCacheList Integer List of A list of descriptors, one for each
24
DiscoveryCache of the Discovery cache devices
descriptors registered, beginning with the 25
StartIndex element and 26
continuing for 27
DiscoveryCacheListCount, of 28
the registered devices in the
29
Primary Discovery Cache. Each
entry shall be formatted as 30
illustrated in Table 2.135. 31
32
33
34
Table 2.135 DiscoveryCacheList Record Format 35
Size 36
Name (Bits) Valid Range Description 37
38
Extended 64 An extended 64-bit IEEE 64-bit IEEE Address of 39
Address Address the cached device.
40
Network 16 Network address The 16-bit network 41
Address address of the cached 42
device.
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
210 Application Layer Specification
I
1
Table 2.137 ZDP Enumerations Description
2
Enumeration Value Description 3
4
SUCCESS 0x00 The requested operation or transmission 5
was completed successfully.
6
- 0x01-0x7f Reserved. 7
INV_REQUESTTYPE 0x80 The supplied request type was invalid. 8
9
DEVICE_NOT_FOUND 0x81 The requested device did not exist on a
device following a child descriptor
10
request to a parent. 11
12
INVALID_EP 0x82 The supplied endpoint was equal to 0x00
13
or between 0xf1 and 0xff.
14
NOT_ACTIVE 0x83 The requested endpoint is not described 15
by a simple descriptor.
16
NOT_SUPPORTED 0x84 The requested optional feature is not 17
supported on the target device. 18
TIMEOUT 0x85 A timeout has occurred with the 19
requested operation. 20
NO_MATCH 0x86 The end device bind request was 21
unsuccessful due to a failure to match 22
any suitable clusters. 23
- 0x87 Reserved.
24
25
NO_ENTRY 0x88 The unbind request was unsuccessful due 26
to the coordinator or source device not
having an entry in its binding table to
27
unbind. 28
29
NO_DESCRIPTOR 0x89 A child descriptor was not available
30
following a discovery request to a parent.
31
INSUFFICIENT_SPACE 0x8a The device does not have storage space 32
to support the requested operation.
33
NOT_PERMITTED 0x8b The device is not in the proper state to 34
support the requested operation. 35
TABLE_FULL 0x8c The device does not have table space to 36
support the operation. 37
NOT_AUTHORIZED 0x8d The permissions configuration table on 38
the target indicates that the request is not 39
authorized from this device. 40
- 0x8e-0xff Reserved.
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 213
2.4.6 Conformance 1
2
When conformance to this Profile is claimed, all capabilities indicated mandatory
3
for this Profile shall be supported in the specified manner (process mandatory).
4
This also applies to optional and conditional capabilities, for which support is
5
indicated, and is subject to verification as part of the ZigBee certification
6
program.
7
8
2.5 The ZigBee Device Objects (ZDO) 9
10
11
2.5.1 Scope 12
13
This section describes the concepts, structures, and primitives needed to 14
implement a ZigBee Device Objects application on top of a ZigBee Application 15
Support Sub-layer (sub-clause 2.2) and ZigBee Network Layer (Chapter 3). 16
17
ZigBee Device Objects are applications which employ network and application 18
support layer primitives to implement ZigBee End Devices, ZigBee Routers, and 19
ZigBee Coordinators. 20
The ZigBee Device Object Profile employs Clusters to describe its primitives. 21
The ZigBee Device Profile Clusters do not employ attributes and are analogous to 22
messages in a message transfer protocol. Cluster identifiers are employed within 23
the ZigBee Device Profile to enumerate the messages employed within ZigBee 24
Device Objects. 25
26
ZigBee Device Objects also employ configuration attributes. The configuration 27
attributes within ZigBee Device Objects are configuration parameters set by the 28
application or stack profile. The configuration attributes are also not related to the 29
ZigBee Device Profile, though both the configuration attributes and the ZigBee 30
Device Profile are employed with ZigBee Device Objects. 31
32
2.5.2 Device Object Descriptions 33
34
The ZigBee Device Objects are an application solution residing within the 35
Application Layer (APL) and above the Application Support Sub-layer (APS) in 36
the ZigBee stack architecture as illustrated in Figure 1.1. 37
38
The ZigBee Device Objects are responsible for the following functions: 39
• Initializing the Application Support Sublayer (APS), Network Layer (NWK), 40
Security Service Provider (SSP) and any other ZigBee device layer other than 41
the end applications residing over Endpoints 1-240. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
214 Application Layer Specification
location for a given device of interest. Note that if the discovery information
is held by the device itself, that device must also respond to identify itself as 1
the repository of discovery information. See Figure 2.103 for details on state 2
machine processing for the Primary Discovery Cache device. 3
4
5
System_Server_Discovery_req 6
System_Server_Discovery_rsp 7
Until (STATUS) 8
STATUS is
SUCCESS Discovery_store_req 9
10
Discovery_store_rsp(STATUS)
11
Node_Desc_store_req
12
13
If STATUS is not SUCCESS Node_Desc_store_rsp(STATUS) 14
for any descriptor storage
request, then Repeat for: 15
Remove_node_cahe_req Power_Desc_store_req, 16
Active_EP_store_req, 17
Simple_Desc_store_req
18
19
End Device sleeps and
Primary Discovery Cache
20
handles any discovery 21
requests for the device. 22
End Device (client) Primary Discovery Cache
23
(server)
24
25
Figure 2.103 Primary Discovery Cache State Machine
26
27
2.5.2.2 Device and Service Discovery 28
This function shall support device and service discovery within a single PAN. 29
Additionally, for all ZigBee device types, this function shall perform the 30
following: 31
32
• Within each network employing sleeping ZigBee End Devices, some ZigBee 33
Routers (or the ZigBee Coordinator) may be designated as Primary Discovery 34
Cache Devices as described by their Node Descriptor. These Primary Cache 35
Devices are themselves discoverable and provide server services to upload and 36
store discovery information on behalf of sleeping ZigBee End Devices. 37
Additionally, the Primary Cache Devices respond to discovery requests on 38
behalf of the sleeping ZigBee End Devices. Each Primary Discovery Cache 39
Device shall be either a ZigBee Router or the ZigBee Coordinator. 40
• For ZigBee End Devices which intend to sleep as indicated 41
by:Config_Node_Power, Device and Service Discovery may manage upload 42
and storage of the NWK Address, IEEE Address, Active Endpoints, Simple 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
216 Application Layer Specification
of the query type is also provided to return the full list through multiple
requests. 1
2
—NWK address or broadcast address (of any broadcast address type) plus 3
Service Match including Profile ID and, optionally, Input and Output 4
Clusters – Specified device matches Profile ID with all active endpoints 5
to determine a match. If no input or output clusters are specified, the 6
endpoints that match the request are returned. If input and/or output 7
clusters are provided in the request, those are matched as well, and any 8
matches are provided in the response with the list of endpoints on the 9
10
device providing the match. The responding device shall employ APS
11
acknowledged service for the unicast response to the broadcast inquiry. 12
By convention, in cases where the application profile enumerates input 13
clusters and their response output clusters with the same cluster identi- 14
fier, the application profile shall list only the input cluster within the 15
Simple Descriptor for the purposes of Service Discovery. 16
17
—NWK address plus Node Descriptor or Power Descriptor query type –
18
Specified device shall return the Node or Power Descriptor for the 19
device. 20
—NWK address, Endpoint Number plus Simple Descriptor query type – 21
Specified address shall return the Simple Descriptor associated with that 22
Endpoint for the device. Should the list of input and/or output clusters 23
24
exceed the ASDU size capacity to return the Simple Descriptor in a sin-
25
gle packet an extended version of the query type is also provided to 26
return the full list through multiple requests. 27
—Optionally, NWK address plus Complex or User Descriptor query type 28
– If supported, specified address shall return the Complex or User 29
Descriptor for the device 30
31
2.5.2.3 Security Manager 32
33
This function determines whether security is enabled or disabled and, if enabled, 34
shall perform the following: 35
36
• Establish Key 37
• Transport Key 38
39
• Request Key 40
• Update Device 41
42
• Remove Device 43
• Switch Key 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
218 Application Layer Specification
• Authenticate Device
1
The Security Manager function addresses the Security Services Specification 2
(Chapter 4). Security Management, implemented by APSME primitive calls by 3
ZDO, performs the following: 4
• Contacts the Trust Center to obtain the Master Key between this device and the 5
Trust Center (step is omitted if this device is the Trust Center, the Master Key 6
with the Trust Center has been pre-configured, or the network is operating in 7
residential mode). This step employs the Transport Key primitive. 8
9
• Establishes a Link Key with the Trust Center. This step employs the APSME- 10
Establish-Key primitive (omitted in residential mode). 11
• Obtains the NWK Key from the Trust Center using secured communication 12
with the Trust Center (commercial mode). Alternatively, the NWK Key from 13
the Trust Center may be sent from the Trust Center using unsecured 14
communication (residential mode). This step employs the APSME- 15
TRANSPORT-KEY primitive. 16
17
• Establishes or transports Link Keys and master keys, as required, with specific 18
devices in the network identified as messaging destinations (commercial 19
mode). These steps employ the APSME-ESTABLISH-KEY, APSME- 20
TRANSPORT-KEY and/or APSME-REQUEST-KEY primitives. 21
• Informs the Trust Center of any devices that join the network using the 22
APSME-UPDATE-DEVICE primitives. This function is only performed if the 23
device is a ZigBee router. 24
25
• Permits devices to obtain keys from the Trust Center using the APSME- 26
REQUEST-KEY primitives. 27
• Permits the Trust Center to remove devices from the network using the 28
APSME-REMOVE-DEVICE primitives. 29
30
• Permits the Trust Center to switch the active network key using the APSME- 31
SWITCH-KEY primitives. 32
• Permits devices in the network to authenticate other devices using the APSME- 33
AUTHENTICATE primitives. 34
35
2.5.2.4 Network Manager 36
37
This function shall implement the ZigBee Coordinator, ZigBee Router, or ZigBee 38
End Device logical device types according to configuration settings established 39
either via a programmed application or during installation. If the device type is a 40
ZigBee Router or ZigBee End Device, this function shall provide the ability to 41
select an existing PAN to join and implement procedures which permit the device 42
to rejoin if network communication is lost. If the device type is a ZigBee 43
Coordinator or ZigBee Router, this function shall provide the ability to select an 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 219
unused channel for creation of a new PAN. Note that it is possible to deploy a
network without a device pre-designated as ZigBee Coordinator where the first 1
Full Function Device (FFD) activated assumes the role of ZigBee Coordinator. 2
The following description covers processing addressed by Network Management: 3
4
• Permits specification of a channel list for network scan procedures. Default is 5
to specify use of all channels in the selected band of operation. 6
• Manages network scan procedures to determine neighboring networks and the 7
identity of their ZigBee coordinators and routers. 8
9
• Permits selection of a channel to start a PAN (ZigBee Coordinator) or selection 10
of an existing PAN to join (ZigBee Router or ZigBee End Device). 11
• Supports orphaning and extended procedures to rejoin the network, including 12
support for intra_PAN portability. 13
14
• May support direct join. For ZigBee Coordinators and ZigBee Routers, a local 15
version of direct join may be supported to enable the device to join via the 16
orphaning or rejoin procedures. 17
• May support Management Entities that permit external network management. 18
19
• Detects and reports interference to support changing network channels. 20
• Manages network interference reporting and selection of a new channel for 21
network operation if interference exists on the initial channel if the particular 22
node is identified as the network manager for the overall PAN. 23
24
2.5.2.5 Binding Manager 25
26
The Binding Manager performs the following: 27
• Establishes resource size for the Binding Table. The size of this resource is 28
determined via a programmed application or via a configuration parameter 29
defined during installation. 30
31
• Processes bind requests for adding or deleting entries from the APS binding 32
table. 33
• Supports Bind and Unbind commands from external applications such as those 34
that may be hosted on a commissioning or network management tool to support 35
assisted binding. Bind and Unbind commands shall be supported via the 36
ZigBee Device Profile (see clause 2.4). 37
38
• For the ZigBee Coordinator, supports the End Device Bind that permits binding 39
on the basis of button presses or other manual means. 40
• Permits source devices to register with a primary binding table cache their 41
ability to hold their own binding table. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
220 Application Layer Specification
• Permits configuration tools to exchange one device for another in all the
binding table entries which refer to it. 1
2
• Permits the primary binding table cache to backup and recover individual bind 3
entries or the entire binding table or the table of source devices holding their 4
own binding tables. 5
6
2.5.2.6 Node Manager 7
For ZigBee Coordinators and ZigBee Routers, the Node Management function 8
performs the following: 9
10
• Permits remote management commands to perform network discovery. 11
• Provides remote management commands to retrieve the routing table. 12
13
• Provides remote management commands to retrieve the binding table. 14
• Provides a remote management command to have the device leave the network 15
or to direct that another device leave the network. 16
17
• Provides a remote management command to retrieve the LQI for neighbors of 18
the remote device. 19
• Provides a remote management command to Permit or disallow joining on 20
particular routers or to generally allow or disallow joining via the Trust Center. 21
22
2.5.2.7 Group Manager 23
24
The Group Manager performs the following: 25
• Provides for inclusion of application objects within the local device into groups 26
under application control. 27
28
• Provides for removal of application objects within the local device from group 29
membership under application control. 30
31
2.5.3 Layer Interface Description 32
33
Unlike other device descriptors for applications residing above Endpoints 1-240, 34
the ZigBee Device Objects (ZDO) interface to the APS via the APSME-SAP in 35
addition to the APSDE-SAP. ZDO communicates over Endpoint 0 using the 36
APSDE-SAP via Profiles like all other applications. The Profile used by ZDO is 37
the ZigBee Device Profile (See clause 2.4). ZDO frames shall not be fragmented. 38
39
ZigBee Device Objects shall employ Endpoint 0 as the source and destination 40
endpoint in any transmitted ZigBee Device Profile request frames, and shall 41
expect Endpoint 0 as the source and destination endpoint in any received response 42
frames. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 221
11
1
Configuration Attributes
Group Manager Object 2
Optional Mandatory 3
4
Mandatory Attributes :Config_Node_Descriptor
5
:Config_Power_Descriptor
6
:Config_Simple_Descriptors
:Config_NWK_Mode_and_Params
7
:Config_NWK_Scan_Attempts
8
:Config_NWK_Time_btwn_Scans
9
Optional Attributes 10
Optional
11
APSME-ADD-
GROUP.request 12
:Config_Complex_Descriptor
APSME-ADD- 13
:Config_User_Descriptor
GROUP.confirm 14
:Config_Max_Bind
APSME-REMOVE- 15
GROUP.request :Config_Master_Key 16
APSME-REMOVE- :Config_NWK_Join_Direct_Addrs
GROUP.confirm 17
APSME-REMOVE-ALL-
:Config_Max_Assoc 18
GROUPS.request :Config_EndDev_Bind_Timeout 19
APSME-REMOVE-ALL- :Config_Permit_Join_Duration 20
GROUPS.confirm :Config_Nwk_Security_Level 21
:Config_Nwk_Secure_All_Frames 22
:Config_NWK_Leave_removeChildren 23
:Config_NWK_BroadcastDeliveryTime 24
:Config_NWK_TransactionPersistenceTim 25
:Config_NWK_indirectPollRate 26
:Config_NWK_Alt_protocol_version 27
28
29
30
Figure 2.107 System Usage ZigBee Device Object Details — Group Manager 31
Object and Configuration Attributes 32
33
2.5.5 Object Definition and Behavior 34
35
2.5.5.1 Object Overview 36
37
ZigBee Device Objects contain six Objects: 38
39
• Device and Service Discovery
40
• Network Manager 41
42
• Binding Manager
43
• Security Manager 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 225
• Node Manager
1
• Group Manager 2
Table 2.138 describes these ZigBee Device Objects. 3
4
Table 2.138 ZigBee Device Objects
5
Object Description 6
7
Name Status 8
:Device_and_Service M Handles device and service discovery. 9
_Discovery 10
11
:Network_Manager M Handles network activities such as network
discovery, leaving/joining a network, 12
resetting a network connection and creating 13
a network. 14
:Binding_Manager O Handles end device binding, binding and 15
unbinding activities. 16
17
:Security_Manager O Handles security services such as key
loading, key establishment, key transport
18
and authentication. 19
20
:Node_Manager O Handles management functions.
21
:Group Manager O Handles management of groups 22
23
2.5.5.2 Optional and Mandatory Objects and Attributes 24
25
Objects listed as Mandatory shall be present on all ZigBee devices. However, for 26
certain ZigBee logical types, Objects listed as Optional for all ZigBee devices 27
may be Mandatory in specific logical device types. For example, the NLME- 28
NETWORK-FORMATION.request within the Network_Manager object is in a 29
Mandatory object and is an Optional attribute, though the attribute is required for 30
ZigBee Coordinator logical device types. The introduction section of each Device 31
Object section will detail the support requirements for Objects and Attributes by 32
logical device type. 33
34
2.5.5.3 Security Key Usage 35
36
ZigBee Device Objects may employ security for packets created by ZigBee
37
Device Profile primitives. These application packets using APSDE on Endpoint 0
38
shall utilize the APSDE Security Service Provider interface like all other
39
Application Objects.
40
41
2.5.5.4 Public and Private Methods 42
Methods that are accessible to any endpoint application on the device are called 43
public methods. Private methods are only accessible to the Device Application on 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
226 Application Layer Specification
endpoint 0 and not to the end applications (which run on endpoints 1 through
240). 1
2
2.5.5.5 State Machine Functional Descriptions 3
4
2.5.5.5.1 ZigBee Coordinator 5
6
2.5.5.5.1.1 Initialization 7
8
The implementation shall set the startup-related IB parameters shown in Table 2.139 9
to values that reflect the desired startup behavior for the device. In particular, the 10
apsDesignatedCordinator attribute of the IB shall be set to TRUE. If the device 11
implements more than one option for ZigBee protocol version or stack profile, it shall 12
choose a single value for each and set nwkcProtocolVersion and nwkStackProfile 13
accordingly. Additionally, provision shall be made to provide configuration elements 14
to describe the Node Descriptor, Power Descriptor, Simple Descriptor for each active 15
endpoint and application plus the list of active endpoints. These configurations shall 16
be embodied in :Config_Node_Descriptor,:Config_Power_Descriptor, and 17
:Config_Simple_Descriptors. If the :Config_Node_Descriptor configuration object 18
indicates that this device is a Primary Discovery Cache device, the device shall be 19
configured to process server commands for the ZigBee Device Profile associated with 20
requests to the Primary Discovery Cache and shall operate according to the state 21
machine description provided in sub-clause 2.5.2.1. 22
If supported, provision shall be made to supply configuration elements for the 23
Complex Descriptor, User Descriptor, the maximum number of bind entries and 24
the master key. These elements shall be embodied in 25
:Config_Complex_Descriptor, :Config_User_Descriptor, :Config_Max_Bind and 26
:Config_Master_Key. 27
28
To start as a ZigBee coordinator, the device application shall execute the startup 29
procedure described in sub-clause 2.5.5.5.6.2 with startup parameters set as 30
described above. This should have the effect of executing the procedure for network 31
formation described in sub-clause 3.6.1.1. The device application shall set the 32
nwkSecurityLevel, nwkAllFresh, and nwkSecureAllFrames NIB attributes according 33
to the values established by convention within the Stack Profile employed by the 34
device. The device application shall check the return status via the NLME- 35
NETWORK-FORMATION.confirm to verify successful creation of the PAN. The 36
:Config_Permit_Join_Duration shall be set according to the default parameter value 37
supplied using the NLME-PERMIT-JOINING.request. Additionally, the 38
nwkNetworkBroadcastDeliveryTime and nwkTransactionPersistenceTime Network 39
Information Block parameters (see sub-clause 3.6.2) shall be set with 40
:Config_NWK_BroadcastDeliveryTime and 41
:Config_NWK_TransactionPersistenceTime respectively (see sub-clause 2.5.6). 42
Provision shall be made to ensure APS primitive calls from the end applications 43
over EP 1 through EP 240 return appropriate error status values prior to 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 227
specific protocol version number, it shall employ that protocol version number as
its nwkcProtocolVersion. Additionally, the ZigBee router shall then adhere to all 1
frame formats and processing rules supplied by the version of the ZigBee 2
Specification employing that protocol version number. 3
4
The :Config_Permit_Join_Duration shall be set according to the default parameter 5
value supplied using NLME-PERMIT-JOINING.request. The router shall support 6
the NLME-START-ROUTER.request and NLME-START-ROUTER.confirm to 7
begin operations as a router within the PAN it has joined. Additionally, the 8
nwkNetworkBroadcastDeliveryTime and nwkTransactionPersistenceTime 9
Network Information Block parameters (see sub-clause 3.6.2) shall be set with 10
:Config_NWK_BroadcastDeliveryTime and 11
:Config_NWK_TransactionPersistenceTime respectively (see sub-clause 2.5.6). 12
Provision shall be made to ensure APS primitive calls from the end applications 13
over EP 1 through EP 240 return appropriate error status values prior to 14
completion of the Initialization state by ZigBee Device Objects and transition to 15
the normal operating state. 16
17
If the network has security enabled, the device shall wait to be authenticated by 18
the Trust Center, and for successful acquisition of the NWK key to start 19
functioning as a router in the network. See sub-clause 4.6.2 for details on Trust 20
Center operations. 21
The device application shall set the nwkSecurityLevel and nwkSecureAllFrames 22
NIB attributes to the values used in the network and begin functioning as a router 23
using NLME-START-ROUTER.req. 24
25
2.5.5.5.2.2 Normal Operating State 26
27
In this state, the ZigBee router shall allow other devices to join the network based 28
on the configuration items :Config_Permit_Join_Duration and 29
:Config_Max_Assoc. When a new device joins the network, the device 30
application shall be informed via the NLME-JOIN.indication attribute. Should the 31
device be admitted to the PAN, the ZigBee router shall indicate this via the 32
NLME-JOIN.confirm with SUCCESS status. If security is enabled on the 33
network, the device application shall inform the Trust Center via the APSME- 34
UPDATE-DEVICE. request. 35
Orphan indications for which this device is not the parent are notified to the ZDO 36
from the NWK layer by receipt of an NLME-JOIN.indication primitive with 37
parameter IsParent set to value FALSE. The mechanism by which this is handled 38
is described in 2.5.5.5.4. 39
40
The ZigBee router shall respond to any device discovery or service discovery 41
operations requested of its own device, and if it is designated as a Primary 42
Discovery Cache device, shall also respond on behalf of registered devices that 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 231
have stored discovery information. The device application shall also ensure that
the number of binding entries does not exceed the :Config_Max_Bind attribute. 1
2
If security is supported operating in commercial mode, the ZigBee router shall 3
support the :Config_Master_Key and shall employ the Master Key in key 4
establishment procedures for Link Keys. Upon presentation of a remote 5
destination address requiring secure communications, the ZigBee router shall 6
support APSME-ESTABLISH-KEY.request to establish a link key with the 7
remote device and APSME-ESTABLISH-KEY.indication to present the request to 8
the destination and shall support APSME-ESTABLISH-KEY.confirm and 9
APSME-ESTABLISH-KEY.response to complete the key establishment of the 10
Link Key. The ZigBee router shall provide the ability to store Link Keys for 11
known destinations requiring secure communications and shall manage key 12
storage of Link Keys. The ZigBee router shall support APSME-TRANSPORT- 13
KEY.indication to receive keys from the Trust Center. 14
If security is supported operating in commercial or residential modes, the ZigBee 15
router shall request the Trust Center to update its NWK key via the APSME- 16
REQUEST-KEY.request. 17
18
The ZigBee router shall support the NLME-PERMIT-JOINING.request and 19
NLME-PERMIT-JOINING.confirm to permit application control of network join 20
processing. 21
The ZigBee router shall support the NLME-NWK-STATUS.indication and 22
process those notifications per sub-clause 3.2.2.30. 23
24
The ZigBee router shall support the NLME-LEAVE.request and NLME- 25
LEAVE.confirm employing the :Config_NWK_Leave_removeChildren attribute 26
where appropriate to permit removal of associated devices under application 27
control. Conditions that lead to removal of associated devices may include lack of 28
security credentials, removal of the device via a privileged application or 29
detection of exception. When a ZigBee end device is asked to leave the network, 30
the ReuseAddress parameter of the NLME-LEAVE.request primitive should have 31
a value of TRUE indicating that the NWK layer may give the address formerly in 32
use by the leaving device to another end device that joins subsequently. 33
The ZigBee router shall process Device_annce messages from other ZigBee 34
devices. Upon receipt of a Device_annce where nwkUseTreeRouting is TRUE, the 35
ZigBee router shall check all internal tables holding 64-bit IEEE addresses for 36
devices within the PAN for a match with the address supplied in the Device_annce 37
message. If a match is detected, the ZigBee router shall update its 38
nwkAddressMap of the NIB corresponding to the matched 64-bit IEEE address to 39
reflect the updated 16-bit NWK address contained in the Device_annce. Upon 40
receipt of a Device_annce where nwkUseTreeRouting is FALSE, the ZigBee 41
Router shall employ the address conflict resolution procedure detailed in sub- 42
clause 3.6.9. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
232 Application Layer Specification
The ZigBee router shall maintain a list of currently associated devices and
facilitate support of orphan scan and rejoin processing to enable previously 1
associated devices to rejoin the network. 2
3
The ZigBee router may generate APSME-AUTHENTICATE.requests under 4
application control from other application objects and may process and respond to 5
APSME-AUTHENTICATE.indications from other devices. The ZigBee router 6
shall supply APSME-AUTHENTICATE.confirms to application objects whose 7
requests have been processed. 8
The ZigBee router may decide it has lost contact with the network it was joined to. 9
In this situation, the router should conduct an active scan to find the network. If 10
the network is found more than once the router should attempt to rejoin where 11
there is a more recent value of nwkUpdateId in the beacon payload. 12
13
2.5.5.5.3 Binding Table Cache Operation 14
Any router (including the coordinator) may be designated as either a primary 15
binding table cache or a backup binding table cache. 16
17
It shall respond to the System_Server_Discovery_req primitive to enable other 18
devices to discover it and use its facilities. 19
A primary binding table cache shall maintain a binding table and a table of 20
devices registered to cache their binding tables. 21
22
A primary binding table cache shall respond to the Bind_Register_req and 23
Replace_Device_req primitives described in clause 2.4.3.2. 24
If a backup binding table cache is available, a primary binding table cache shall 25
use the additional bind management primitives to backup and restore its binding 26
table and its table of source binding devices. 27
28
A backup binding table cache shall maintain a backup of the binding table and 29
table of registered binding devices for one or more primary binding table caches. 30
It shall support the bind management primitives for backup and restore of these 31
tables. 32
2.5.5.5.4 Operations to Support Intra-PAN Portability 33
34
35
2.5.5.5.4.1 Overview
36
The operations described in this section are carried out by ZigBee Coordinator 37
and ZigBee Router Devices for support of intra-PAN portability. 38
39
The main steps are summarized as follows:- 40
• Detect the problem - The ZDO of the moved device is notified of 41
acknowledgement failures via the NLME-NWK-STATUS.indication 42
primitive, and identifies a problem. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 233
• Carry out the NWK layer rejoin procedure - The ZDO of a moved ZED
initiates this process using the NLME-JOIN.request primitive, either through a 1
secured or un-secured rejoining procedure. The NWK rejoin procedures closely 2
mirror the MAC association procedure. Note that ZigBee Routers shall also 3
carry out this procedure periodically if they find that they are no longer in 4
contact with the Trust Center. 5
6
• Security verification - Secured and unsecured protocol steps are described to 7
ensure that the orphaned device should really be accepted. (See 8
clause 2.5.5.5.4.2.) 9
• Inform the rest of the network - when a device changes parents the steps to 10
complete address conflict detection in sub-clause 3.6.1.9 must be completed. 11
These actions also serve to notify the old parent that the End Device has 12
changed parents.7 13
14
These steps are described in detail in the subsections below. The mechanism is 15
illustrated for secured rejoin of a ZED in Figure 2.108, unsecured rejoin of a ZED 16
in Figure 2.109, and unsecured rejoin of a ZR in Figure 2.110 respectively. Note 17
that the NWK and SEC sections on secured and unsecured rejoin (sub-clauses 18
3.2.2.11, 3.2.2.12, 3.2.2.13, 3.6.1.4 and 4.6.3) shall be the authoritative text for 19
these procedures. The diagrams in this section are provided for illustrative 20
purposes only. 21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
7. CCB #833 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
234 Application Layer Specification
New New
Old parent
Child’s Child’s
parent’s parent’s
Trust 1
NWK ZDO Centre
NWK ZDO 2
3
4
NO_ACK (x 12)
5
ROUTE-ERROR. 6
indication
7
Optional active scan. Select parent, eg: by
EPID. If rejoin fails then retry later.
8
9
JOIN.request
(RejoinNetwork=2) 10
Rejoin request 11
(secured at NWK layer with NWK key,
from IEEE address)
JOIN.indication
(secured rejoin)
12
Rejoin response (secured at NWK layer
13
with NWK key, to IEEE address, includes 14
JOIN.confirm
(SUCCESS)
short address)
15
16
Entity authentication [if required] 17
Device_annce 18
(if short address changed) Device_annce
19
20
21
Figure 2.108 Portability Message Sequence Chart: ZED Secured Rejoin 22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 235
New New
Old parent
Child’s Child’s
parent’s parent’s
Trust 1
NWK ZDO Centre
NWK ZDO 2
3
4
NO_ACK (x12)
5
ROUTE-ERROR. 6
indication
7
Optional active scan. Select parent, eg: by 8
EPID. If rejoin fails then retry later.
9
JOIN.request
(RejoinNetwork=2)
10
Rejoin request 11
(unsecured, from IEEE address) JOIN.indication
Update device
12
Rejoin response (unsecured, to IEEE (unsecured
address, includes short address) rejoin) 13
Key transport
JOIN.confirm
(NWK key) 14
(SUCCESS)
SET and GET Alternatively 15
(relationship) Remove device.
Key transport (NWK key, unsecured at 16
NWK layer) 17
Entity authentication [if required]
18
Device_annce
Device_annce
19
(if short address changed)
20
21
Figure 2.109 Portability Message Sequence Chart: ZED Unsecured Rejoin 22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
236 Application Layer Specification
PAN portability procedure, the ZDO shall arrange that any IEEE address to short
address mappings which have become known to applications running on this 1
device be updated. This behavior is mandatory, but the mechanism by which it is 2
achieved is outside the scope of this specification. 3
4
2.5.5.5.5 ZigBee End Device 5
6
2.5.5.5.5.1 Initialization 7
8
The implementation shall set the startup-related IB parameters shown in Table 2.139
9
to values that reflect the desired startup behavior for the device. In particular, the
10
apsDesignatedCordinator attribute of the IB shall be set to FALSE.
11
If supported, provision shall be made to supply configuration elements for the 12
Complex Descriptor, User Descriptor, the maximum number of bind entries, and 13
the master key. These elements shall be embodied in 14
:Config_Complex_Descriptor, :Config_User_Descriptor, :Config_Max_Bind, and 15
:Config_Master_Key. If the device application set the NLME-JOIN 16
RxOnWhenIdle parameter to FALSE, the end device shall utilize the procedure 17
described in sub-clause 2.5.2.1 to discover a Primary Discovery Cache device, 18
register with it, and to successfully upload its device and service discovery 19
information. To facilitate the process of uploading discovery information to the 20
Primary Discovery Cache device, the local device may temporarily increase its 21
polling rate with its parent. Prior to registering with any Primary Discovery Cache 22
device, the end device shall utilize the Find Node Cache request to ensure it has 23
not previously registered with any other Primary Discovery Cache device. If a 24
server response indicates the end device has a previous registration, the end 25
device shall update its discovery cache information on that Primary Discovery 26
Cache device or shall remove its discovery cache information from that previous 27
registration and create a new registration. 28
29
To start as a ZigBee end device, the device application shall execute the startup
30
procedure described in sub-clause 2.5.5.5.6.2 with startup parameters set as
31
described above. This should have the effect of executing either the procedure for
32
network rejoin described in sub-clause 3.6.1.4.2 or else the full procedure for
33
network join through MAC association described in sub-clause 3.6.1.4.1. The
34
NLME-NETWORK-DISCOVERY.request procedure shall be implemented
35
:Config_NWK_Scan_Attempts, each separated in time by
36
:Config_NWK_Time_btwn_Scans. The purpose of repeating the NLME-
37
NETWORK-DISCOVERY.request is to provide a more accurate neighbor list and
38
associated link quality indications to the NWK layer. Specification of the
39
algorithm for selection of the PAN shall be left to the profile description and may
40
include use of the Extended PAN ID, operational mode of the network, identity of
41
the ZigBee Router or Coordinator identified on the PAN, depth of the ZigBee
42
Router on the PAN from the ZigBee Coordinator for the PAN, capacity of the
43
ZigBee Router or Coordinator, the routing cost, or the Protocol Version Number
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 239
The ZigBee end device shall respond to any device discovery or service discovery
operations requested of its own device using the attributes described in sub- 1
clause 2.5.4. 2
3
If security is enabled operating in commercial mode, the ZigBee end device shall 4
support the :Config_Master_Key and shall employ the Master Key in key 5
establishment procedures for Link Keys. Upon presentation of a remote 6
destination address requiring secure communications, the ZigBee end device shall 7
support APSME-ESTABLISH-KEY.request to establish a link key with the 8
remote device, and support APSME-ESTABLISH-KEY.indication to present the 9
request to the destination, and shall support APSME-ESTABLISH-KEY.confirm 10
and APSME-ESTABLISH-KEY.response to complete the key establishment of 11
the Link Key. The ZigBee end device shall provide the ability to store Link Keys 12
for known destinations requiring secure communications and shall manage key 13
storage of Link Keys. The ZigBee end device shall support APSME- 14
TRANSPORT-KEY.indication to receive keys from the Trust Center. 15
If security is enabled operating in commercial mode, the ZigBee end device shall 16
request the Trust Center to update its NWK key via the APSME-REQUEST- 17
KEY.request. 18
19
The ZigBee End Device shall process Device_annce messages from other ZigBee 20
devices. Upon receipt of a Device_annce where nwkUseTreeRouting is TRUE, the 21
ZigBee End Device shall check all internal tables holding 64-bit IEEE addresses 22
for devices within the PAN for a match with the address supplied in the 23
Device_annce message. If a match is detected, the ZigBee End Device shall 24
update the nwkAddressMap of the NIB corresponding to the matched 64-bit IEEE 25
address to reflect the updated 16-bit NWK address contained in the 26
Device_annce.9 27
The ZigBee End Device shall process the NLME-NWK-STATUS.indication sent 28
from the NWK layer. If the error code equals to 0x09 (Parent Link Failure), the 29
ZED will update its failure counter maintained in ZDO. If the value of the failure 30
counter is smaller than the :Config_Parent_Link_Retry_Threshold attribute, the 31
ZED may decide to issue further commands to attempt to communicate with the 32
parent node, depending on the application of the ZED. If the value of the failure 33
counter exceeds the :Config_Parent_Link_Retry_Threshold attribute, the ZED 34
shall then prepare to start the rejoin process. Note that implementers may 35
optionally use a more accurate time-windowed scheme to identify a link failure. 36
37
The rejoin process mirrors the MAC association process very closely, however, a 38
device is permitted to rejoin a parent that is not accepting new associations. The 39
ZDO may use the NLME-NETWORK-DISCOVERY.request primitive to detect 40
potential alternative parents, and in order to optimize recovery latency and 41
42
43
9. CCB #842 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 241
seamlessly on the same network. As a partial solution to this problem, this sub-
clause lists a common set of configuration parameters for ZigBee devices and 1
outlines a common procedure for devices to use at start-up time. The other critical 2
component of the solution is a common set of commissioning protocols and 3
procedures, which are outside the scope of this document. 4
5
2.5.5.5.6.1 Configuration Parameters 6
7
The startup procedure outlined in sub-clause 2.5.5.5.6.2 is designed in such a way 8
that, by using it consistently, devices can go through all the stages of 9
commissioning up to being joined to the proper ZigBee network and able to send 10
and receive application data traffic. Later-stage commissioning, including the 11
commissioning of bindings and group membership is discussed briefly in sub- 12
clause 2.5.5.5.6.3 below. The procedure makes use of the system parameters listed 13
in Table 2.139. 14
Table 2.139 Startup Parameters 15
16
Name Reference Comment 17
nwkExtendedPANID Table 3.43 This is the extended PANID of the network 18
to which the device is joined. If it has a 19
value of 0x0000000000000000, then the 20
device is not connected to a network. 21
apsDesignatedCoordinator Table 2.24 This boolean flag indicates whether the 22
device should assume on startup that it must 23
become a ZigBee coordinator. 24
apsChannelMask Table 2.24 This is the mask containing allowable 25
channels on which the device may attempt 26
to form or join a network at startup time. 27
apsUseExtendedPANID Table 2.24 The 64-bit identifier of the network to join 28
or form. 29
30
apsUseInsecureJoin Table 2.24 A boolean flag, which defaults to TRUE and
indicates whether it is OK to use insecure 31
join on startup. 32
33
34
2.5.5.5.6.2 Startup Procedure
35
The startup procedure uses the parameters listed in sub-clause 2.5.5.5.6.1 to 36
perform a controlled startup of the ZigBee networking facilities of a device. The 37
procedure should be run whenever the device restarts, but may also be run under 38
application control at the discretion of the developer. 39
40
When a device starts up, it should check the value of nwkExtendedPANID. If
41
nwkExtendedPANID has a non-zero value, then the device should assume it has all
42
the network parameters required to operate on a network. Note that the device
43
should assume the channel identifier present in its current network parameters but
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 243
may need to scan over the ChannelMask if the nwkExtendedPANID is not found.
In order for this to work effectively across power failures and processor resets, 1
nwkExtendedPANID must be placed in non-volatile storage.11 2
3
If the device finds it is not connected to a network, then it should check the value 4
of apsDesignatedCoordinator. If this parameter has a value of TRUE, then the 5
device should follow the procedures for starting a network outlined in sub- 6
clause 3.6.1.4.1 and should use the value of apsChannelMask for the 7
ScanChannels parameter of the NLME-NETWORK-FORMATION.request 8
primitive, and set nwkExtendedPANID to the value given in 9
apsUseExtendedPANID if apsUseExtendedPANID has a non-zero value. 10
If the device is not the designated coordinator and apsUseExtendedPANID has a 11
non-zero value, the device should attempt to rejoin the network specified in 12
apsUseExtendedPANID. To do this, it should use NLME-JOIN.request with the 13
ExtendedPANID parameter equal to the value of apsUseExtendedPANID, the 14
ScanChannels parameter of the primitive equal to the value of the 15
apsChannelMask configuration parameter. The RejoinNetwork parameter of the 16
NLME-JOIN.request primitive should have a value of 0x02 indicating rejoin. 17
18
If the network rejoin attempt fails, and the value of the apsUseInsecureJoin 19
attribute of the AIB has a value of TRUE, then the device should follow the 20
procedure outlined in sub-clause 3.6.1.4.1 for joining a network, using 21
apsChannelMask any place that a ScanChannels mask is called for. If 22
apsUseExtendedPANID has a non-zero value, then the device should join only the 23
specified network and the procedure should fail if that network is found to be 24
inaccessible. If apsUseExtendedPANID is equal to 0x0000000000000000, then 25
the device should join the best available network. 26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
11. CCB #846 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
244 Application Layer Specification
in the Security Manager are present for any ZigBee logical device type. See
clause 2.4 for a description of any of the primitives listed in Table 2.142. 1
2
Table 2.142 Security Manager Attributes
3
Attribute M/O Type 4
5
APSME-ESTABLISH-KEY.request O Public 6
APSME-ESTABLISH-KEY.response O Public 7
APSME-ESTABLISH-KEY. indication O Public 8
9
APSME-ESTABLISH-KEY.confirm O Public 10
APSME-TRANSPORT-KEY.request O Public 11
12
APSME-TRANSPORT-KEY.indication O Public
13
APSME-UPDATE-DEVICE.request O Public 14
APSME-UPDATE-DEVICE.indication O Public 15
16
APSME-REMOVE-DEVICE.request O Public
17
APSME-REMOVE-DEVICE.indication O Public 18
APSME-REQUEST-KEY.request O Public 19
20
APSME-REQUEST-KEY.indication O Public
21
APSME-SWITCH-KEY.request O Public 22
APSME-SWITCH-KEY.indication O Public 23
24
APSME-AUTHENTICATE.request O Private 25
APSME-AUTHENTICATE.indication O Private 26
APSME-AUTHENTICATE.confirm O Private
27
28
29
2.5.5.8 Binding Manager 30
The Binding Management function supports: 31
32
• End Device Binding 33
• Bind and Unbind 34
35
Binding Management performs the above functions with ZigBee Device Profile 36
commands plus APSME-SAP primitives to commit/remove binding table entries 37
once the indication arrives on the ZigBee coordinator, router, or end device 38
supporting the binding table. 39
2.5.5.8.1 Optional and Mandatory Attributes Within Binding Manager 40
41
The Binding Manager is an optional object for all ZigBee Device Types. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
248 Application Layer Specification
If the Binding Manager is present, all requests are optional for all ZigBee logical
device types. Responses shall be supported on devices which implement a binding 1
table cache, and on devices which correspond to the source address for the 2
binding table entries held on those devices. 3
4
If the Binding Manager is not present, all requests and all responses for all ZigBee 5
logical device types shall not be supported. Table 2.143 summarizes Binding 6
Manager attributes. 7
Table 2.143 Binding Manager Attributes 8
9
Attribute M/O Type 10
End_Device_Bind_req O Public 11
12
End_Device_Bind_rsp O Public
13
Bind_req O Public 14
Bind_rsp O Public 15
16
Unbind_req O Public
17
Unbind_rsp O Public 18
Bind_Register_req O Public 19
20
Bind_Register_rsp O Public 21
Replace_Device_req O Public 22
Replace_Device_rsp O Public
23
24
Store_Bkup_Bind_Entry_req O Public 25
Store_Bkup_Bind_Entry_rsp O Public 26
27
Remove_Bkup_Bind_req O Public
28
Remove_Bkup_Bind_rsp O Public 29
Backup_Bind_Table_req O Public 30
31
Backup_Bind_Table_rsp O Public
32
Recover_Bind_Table_req O Public 33
Recover_Bind_Table_rsp O Public 34
35
Backup_Source_Bind_req O Public
36
Backup_Source_Bind_rsp O Public 37
Recover_Source_Bind_req O Public 38
39
Recover_Source_Bind_rsp O Public 40
APSME-BIND.request O Private 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 249
NWK Start Router confirm, NWK Join request, NWK Join confirm, NWK Join
indication, NWK Leave request, NWK Leave confirm, NWK Leave indication, 1
NWK Permit Joining request, and NWK Permit Joining confirm shall be 2
supported. The NWK Direct Join request, NWK Direct Join confirm, NWK Route 3
Discovery request, and NWK Route Discovery confirm may be supported. 4
5
If the ZigBee logical device type is ZigBee End Device, the NWK Formation 6
request and confirm plus the NWK Start Router request and confirm shall not be 7
supported. Additionally, the NWK Join indication and NWK Permit Joining 8
request shall not be supported. The NWK Join request, NWK Join confirm, NWK 9
Leave request, NWK Leave indication, NWK Leave confirm shall be supported. 10
For all ZigBee logical devices types, the NWK Sync request, indication and 11
confirm plus NWK reset request and confirm plus NWK route discovery request 12
and confirm shall be optional. Table 2.144 summarizes Network Manager 13
Attributes. See Chapter 3 for a description of any of the primitives listed in 14
Table 2.144. 15
16
For all ZigBee logical device types, reception of the NWK Network Status 17
indication shall be supported, but no action is required in this version of the 18
specification. 19
Table 2.144 Network Manager Attributes 20
21
Attribute M/O Type 22
NLME-GET.request M Private 23
24
NLME-GET.confirm M Private
25
NLME-SET.request M Private 26
NLME-SET.confirm M Private 27
28
NLME-NETWORK-DISCOVERY.request M Public
29
NLME-NETWORK-DISCOVERY.confirm M Public 30
NLME-NETWORK-FORMATION.request O Private 31
32
NLME-NETWORK- O Private 33
FORMATION.confirm
34
NLME-START-ROUTER.request O Private 35
NLME-START-ROUTER.confirm O Private 36
37
NLME-JOIN.request O Private
38
NLME-JOIN.confirm O Private 39
NLME_JOIN.indication O Private 40
41
NLME-PERMIT-JOINING O Public 42
NLME-PERMIT-JOINING.confirm O Public 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 251
Manager object is present. Table 2.145 summarizes Node Manager attributes. See
clause 2.4 for a description of these attributes. 1
2
Table 2.145 Node Manager Attributes
3
Attribute M/O Type 4
5
Mgmt_NWK_Disc_req O Public 6
Mgmt_NWK_Disc_rsp O Public 7
Mgmt_Lqi_req O Public 8
9
Mgmt_Lqi_rsp O Public 10
Mgmt_Rtg_req O Public 11
12
Mgmt_Rtg_rsp O Public
13
Mgmt_Bind_req O Public 14
Mgmt_Bind_rsp O Public 15
16
Mgmt_Leave_req O Public
17
Mgmt_Leave_rsp O Public 18
Mgmt_Direct_Join_req O Public 19
20
Mgmt_Direct_Join_rsp O Public
21
Mgmt_Permit_Joining_req O Public 22
Mgmt_Permit_Joining_rsp O Public 23
24
Mgmt_Cache_req O Public 25
Mgmt_Cache_rsp O Public 26
Mgmt_NWK_Update_req O Private
27
28
Mgmt_NWK_Update_notify O Private 29
30
2.5.5.11 Group Manager 31
32
The Group Manager supports the ability to include application objects within 33
groups or to remove application objects from groups. The group management 34
functions operate only on application objects within the local device. Mechanisms 35
to manage groups on other devices are beyond the scope of this document. 36
2.5.5.11.1 Optional and Mandatory Attributes Within Group Manager 37
38
The Group Manager is an optional object for all ZigBee Device Types. All request 39
and response attributes within Group Manager are also optional if the Group 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 253
C H A P T E R
1
3
2
3
4
5
6
7
8
9
1
Next Higher Layer Entity 2
3
4
NLDE-SAP NLME-SAP
5
NLME 6
NLDE 7
NWK 8
IB 9
10
MCPS-SAP MLME -SAP 11
12
MAC Sub-Layer Entity 13
14
15
Figure 3.1 The NWK Layer Reference Model 16
17
3.2.1 NWK Data Service 18
19
The NWK layer data entity SAP (NLDE-SAP) supports the transport of 20
application protocol data units (APDUs) between peer application entities. 21
Table 3.1 lists the primitives supported by the NLDE-SAP and the sub-clauses in 22
which these primitives are discussed. 23
24
Table 3.1 NLDE-SAP Primitives 25
NLDE-SAP Primitive Request Confirm Indication 26
27
NLDE-DATA 3.2.1.1 3.2.1.2 3.2.1.3 28
29
3.2.1.1 NLDE-DATA.request 30
31
This primitive requests the transfer of a data PDU (NSDU) from the local APS 32
sub-layer entity to a single or multiple peer APS sub-layer entities. 33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
262 Network Specification
the NWK header will be set to the value of the Radius parameter. If the Radius
parameter has a value of zero, then the radius field of the NWK header will be set 1
to twice the value of the nwkMaxDepth attribute of the NIB. The NWK layer will 2
generate a sequence number for the frame as described in sub-clause 3.6.2.1. and 3
the sequence number field of the NWK header of the frame will be set to this 4
sequence number value. The multicast flag field of the NWK header will be set 5
according to the value of the DstAddrMode parameter. If the DstAddrMode 6
parameter has a value of 0x01, the NWK header will contain a multicast control 7
field whose fields will be set as follows: 8
9
• The multicast mode field will be set to 0x01 if this node is a member of the 10
group specified in the DstAddr parameter. 11
• Otherwise, the multicast mode field will be set to 0x00. 12
13
• The non-member radius and the max non-member radius fields will be set to 14
the value of the NonmemberRadius parameter. 15
Once the NPDU is constructed, the NSDU is routed using the procedure described 16
in sub-clause 3.6.3.3 if it is a unicast, sub-clause 3.6.5 if it is a broadcast, or sub- 17
clause 3.6.6.2 if it is a multicast. When the routing procedure specifies that the 18
NSDU is to be transmitted, this is accomplished by issuing the MCPS- 19
DATA.request primitive with both the SrcAddrMode and DstAddrMode 20
parameters set to 0x02, indicating the use of 16-bit network addresses. The 21
SrcPANId and DstPANId parameters should be set to the current value of 22
macPANId from the MAC PIB. The SrcAddr parameter will be set to the value of 23
macShortAddr from the MAC PIB. The value of the DstAddr parameter is the 24
next hop address determined by the routing procedure. If the message is a unicast, 25
bit b0 of the TxOptions parameter should be set to 1 denoting that an 26
acknowledgement is required. On receipt of the MCPS-DATA.confirm primitive, 27
the NLDE issues the NLDE-DATA.confirm primitive with a status equal to that 28
received from the MAC sub-layer. 29
30
If the nwkSecurityLevel NIB attribute has a non-zero value and the SecurityEnable 31
parameter has a value of TRUE, then NWK layer security processing will be 32
applied to the frame before transmission as described in clause 4.3. Otherwise, no 33
security processing will be performed at the NWK layer for this frame. If security 34
processing is performed and it fails for any reason, then the frame is discarded and 35
the NLDE issues the NLDE-DATA.confirm primitive with a Status parameter 36
value equal to that returned by the security suite. 37
38
3.2.1.2 NLDE-DATA.confirm 39
This primitive reports the results of a request to transfer a data PDU (NSDU) from 40
a local APS sub-layer entity to a single peer APS sub-layer entity. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 265
the Status parameter will be set to SUCCESS. Otherwise, the Status parameter
will indicate the error. 1
2
3.2.1.3 NLDE-DATA.indication 3
4
This primitive indicates the transfer of a data PDU (NSDU) from the NWK layer 5
to the local APS sub-layer entity. 6
3.2.1.3.1 Semantics of the Service Primitive 7
8
The semantics of this primitive are as follows: 9
10
NLDE-DATA.indication {
11
DstAddrMode,
12
DstAddr,
13
SrcAddr, 14
NsduLength, 15
Nsdu, 16
LinkQuality 17
RxTime 18
SecurityUse 19
} 20
21
Table 3.4 specifies the parameters for the NLDE-DATA.indication primitive. 22
23
Table 3.4 NLDE-DATA.indication Parameters 24
Name Type Valid Range Description 25
26
DstAddrMo Integer 0x01 or 0x02 The type of destination address 27
de supplied by the DstAddr parameter.
28
This may have one of the following
two values: 29
30
0x01=16-bit multicast group
31
address
32
0x02=16-bit network address of a 33
device or a 16-bit broadcast address
34
DstAddr 16-bit 0x0000-0xffff The destination address to which 35
Address the NSDU was sent. 36
SrcAddr 16-bit Any valid device address The individual device address from 37
Device except a broadcast address which the NSDU originated. 38
address
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 267
3.2.2.2 NLME-NETWORK-DISCOVERY.confirm
1
This primitive reports the results of a network discovery operation. 2
3
3.2.2.2.1 Semantics of the Service Primitive
4
The semantics of this primitive are as follows: 5
6
NLME-NETWORK-DISCOVERY.confirm {
7
Status 8
NetworkCount, 9
NetworkDescriptor, 10
} 11
12
Table 3.7 describes the arguments of the NLME-NETWORK- 13
DISCOVERY.confirm primitive. 14
15
Table 3.7 NLME-NETWORK-DISCOVERY.confirm Parameters
16
Name Type Valid Range Description 17
18
Status Status Any status value returned See [B1].
with the MLME- 19
SCAN.confirm primitive. 20
21
NetworkCount Integer 0x00 – 0xff Gives the number of networks
discovered by the search. 22
23
NetworkDescriptor List of The list contains the A list of descriptors, one for
network number of elements given each of the networks 24
descriptors by the NetworkCount discovered. Table 3.8 gives a 25
parameter detailed account of the contents 26
of each item. 27
28
Table 3.8 gives a detailed account of the contents of a network descriptor from the 29
NetworkDescriptor parameter. 30
Table 3.8 Network Descriptor Information Fields
31
32
Name Type Valid Range Description 33
34
ExtendedPANId Integer 0x0000000000000 The 64-bit PAN identifier of the
001 - network. 35
0xfffffffffffffffe 36
LogicalChannel Integer Selected from the The current logical channel 37
available logical occupied by the network. 38
channels 39
supported by the 40
PHY (see [B1]). 41
StackProfile Integer 0x00 – 0x0f A ZigBee stack profile identifier 42
indicating the stack profile in use in 43
the discovered network.
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 271
3.2.2.4 NLME-NETWORK-FORMATION.confirm
1
This primitive reports the results of the request to initialize a ZigBee coordinator 2
in a network. 3
4
3.2.2.4.1 Semantics of the Service Primitive
5
The semantics of this primitive are as follows: 6
7
NLME-NETWORK-FORMATION.confirm {
8
Status 9
} 10
11
Table 3.10 specifies the parameters for the NLME-NETWORK- 12
FORMATION.confirm primitive. 13
Table 3.10 NLME-NETWORK-FORMATION.confirm Parameters 14
15
Name Type Valid Range Description 16
Status Status INVALID_REQUEST, The result of the attempt to initialize a 17
STARTUP_FAILURE ZigBee coordinator. 18
or any status value returned from 19
the MLME-START.confirm 20
primitive 21
22
3.2.2.4.2 When Generated 23
24
This primitive is generated by the NLME and issued to its next higher layer in
25
response to an NLME-NETWORK-FORMATION.request primitive. This
26
primitive returns a status value of INVALID_REQUEST, STARTUP_FAILURE
27
or any status value returned from the MLME-START.confirm primitive.
28
Conditions under which these values may be returned are described in sub-
29
clause 3.2.2.3.3.
30
3.2.2.4.3 Effect on Receipt 31
32
On receipt of this primitive, the next higher layer is notified of the results of its 33
request to initialize the device as a ZigBee coordinator. If the NLME has been 34
successful, the Status parameter will be set to SUCCESS. Otherwise, the Status 35
parameter indicates the error. 36
37
3.2.2.5 NLME-PERMIT-JOINING.request 38
This primitive allows the next higher layer of a ZigBee coordinator or router to set 39
its MAC sub-layer association permit flag for a fixed period when it may accept 40
devices onto its network. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 275
On receipt of this primitive with the PermitDuration parameter set to any value
other than 0x00 or 0xff, the NLME sets the MAC PIB attribute, 1
macAssociationPermit, to TRUE as described above. Following the receipt of the 2
MLME-SET.confirm primitive, the NLME starts a timer to expire after 3
PermitDuration seconds. Once the timer is set, the NLME issues the NLME- 4
PERMIT-JOINING.confirm primitive with a status equal to that received by the 5
MAC sub-layer. On expiration of the timer, the NLME sets macAssociationPermit 6
to FALSE by issuing the MLME-SET.request primitive. 7
8
Every NLME-PERMIT-JOINING.request primitive issued by the next higher 9
layer supersedes all previous requests. 10
11
3.2.2.6 NLME-PERMIT-JOINING.confirm 12
This primitive allows the next higher layer of a ZigBee coordinator or router to be 13
notified of the results of its request to permit the acceptance of devices onto the 14
network. 15
16
3.2.2.6.1 Semantics of the Service Primitive 17
The semantics of this primitive are as follows: 18
19
NLME-PERMIT-JOINING.confirm { 20
Status 21
} 22
23
Table 3.12 specifies the parameters for the NLME-PERMIT-JOINING.confirm 24
primitive. 25
26
Table 3.12 NLME-PERMIT-JOINING.confirm Parameters 27
Name Type Valid Range Description 28
29
Status Status INVALID_REQUEST The status of the corresponding request 30
or any status returned from
the MLME-SET.confirm 31
primitive (see [B1]). 32
33
3.2.2.6.2 When Generated 34
35
This primitive is generated by the initiating NLME of a ZigBee coordinator or 36
router and issued to its next higher layer in response to an NLME-PERMIT- 37
JOINING.request. The Status parameter either indicates the status received from 38
the MAC sub-layer or an error code of INVALID_REQUEST. The reasons for 39
these status values are described in sub-clause 3.2.2.5. 40
41
3.2.2.6.3 Effect on Receipt
42
On receipt of this primitive, the next higher layer of the initiating device is 43
notified of the results of its request to permit devices to join the network. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 277
3.2.2.7 NLME-START-ROUTER.request
1
This primitive allows the next higher layer of a ZigBee router to initiate the 2
activities expected of a ZigBee router including the routing of data frames, route 3
discovery, and the accepting of requests to join the network from other devices. 4
5
3.2.2.7.1 Semantics of the Service Primitive
6
The semantics of this primitive are as follows: 7
8
NLME-START-ROUTER.request {
9
BeaconOrder, 10
SuperframeOrder, 11
BatteryLifeExtension 12
} 13
14
Table 3.13 specifies the parameters for NLME-START-ROUTER.request. 15
16
Table 3.13 NLME-START-ROUTER.request Parameters
17
Name Type Valid Range Description 18
19
BeaconOrder Integer 0x00 – 0x0f The beacon order of the network that
the higher layers wish to form. 20
21
SuperframeOrder Integer 0x00 – 0x0f The superframe order of the network
22
that the higher layers wish to form.
23
BatteryLifeExtension Boolean TRUE or FALSE If this value is TRUE, the NLME will 24
request that the ZigBee router is started
supporting battery life extension mode; 25
If this value is FALSE, the NLME will 26
request that the ZigBee router is 27
started without supporting battery life 28
extension mode. 29
30
3.2.2.7.2 When Generated 31
32
This primitive is generated by the next higher layer of a new device and issued to
33
its NLME to request the initialization of itself as a ZigBee router.
34
3.2.2.7.3 Effect on Receipt 35
36
On receipt of this primitive by a device that is not already joined to a ZigBee 37
network as a router, the NLME issues the NLME-START-ROUTER.confirm 38
primitive with the Status parameter set to INVALID_REQUEST. 39
On receipt of this primitive by the NLME of a device that is joined to a ZigBee 40
network as a router, the NLME issues the MLME-START.request primitive to the 41
MAC sub-layer. The BeaconOrder, SuperframeOrder, and BatteryLifeExtension 42
parameters of the MLME-START.request primitive will have the values given by 43
the corresponding parameters of the NLME-START-ROUTER.request. The 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
278 Network Specification
parameter will be set to SUCCESS. Otherwise, the Status parameter indicates the
error. 1
2
3.2.2.9 NLME-ED-SCAN.request 3
4
This primitive allows the next higher layer to request an energy scan to evaluate 5
channels in the local area. 6
3.2.2.9.1 Semantics of the Service Primitive 7
8
The semantics of this primitive are as follows: 9
10
NLME-ED-SCAN.request {
11
ScanChannels,
12
ScanDuration,
13
} 14
15
Table 3.15 specifies the parameters for the service primitive. 16
Table 3.15 NLME-ED-SCAN.request Parameters 17
18
Valid 19
Name Type Range Description 20
ScanChannels Bitmap 32-bit field The five most significant bits (b27,..., 21
b31) are reserved. The 27 least 22
significant bits (b0, b1,... b26) indicate 23
which channels are to be scanned
24
(1=scan, 0=do not scan) for each of the
27 valid channels (see [B1]). 25
26
ScanDuration Integer 0x00-0x0e A value used to calculate the length of
time to spend scanning each channel. 27
The time spent scanning each channel is 28
(aBaseSuperframeDuration * (2n + 1)) 29
symbols, where n is the value of the 30
ScanDuration parameter [B1]. 31
32
3.2.2.9.2 When Generated 33
34
The next higher layer of a device generates this primitive to request to conduct an
35
energy scan of channels.
36
3.2.2.9.3 Effect on Receipt 37
38
On receipt of this primitive by a device that is currently joined to a network, the 39
device will temporarily stop operating on the network to conduct an energy scan. 40
To do this, the NLME issues the MLME-SCAN.request primitive to the MAC 41
sub-layer with the ScanType parameter set to indicate an energy detection scan 42
and the ScanChannels and ScanDuration from the NLME request. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
280 Network Specification
3.2.2.10 NLME-ED-SCAN.confirm
1
This primitive provides the next higher layer results from an energy scan. 2
3
3.2.2.10.1 Semantics of the Service Primitive
4
The semantics of this primitive are as follows: 5
6
NLME-ED-SCAN.confirm {
7
Status 8
UnscannedChannels, 9
EnergyDetectList 10
} 11
12
Table 3.16 specifies the parameters for the service primitive. 13
14
Table 3.16 NLME-ED-SCAN.confirm
15
Valid 16
Name Type Range Description 17
Status Status SUCCESS, The status of the request. 18
or any valid 19
code from 20
the MAC 21
UnscannedChann Bitmap 32 bit field The five most significant bits (b27,..., 22
els b31) are reserved. The 27 least 23
significant bits (b0, b1,... b26) indicate 24
which channels were not scanned
25
(0=scan, 1=did not scan) for each of the
27 valid channels (see [B1]). Note this is 26
the UnscannedChannel list of [B1]. 27
EnergyDetectList List of 0x00-0xff for The list of energy measurements in 28
integers each integer accordance with [B1], one for each 29
channel. 30
31
3.2.2.10.2 When Generated 32
33
This primitive is generated by the NLME of a ZigBee device in response to an 34
NLME-ED-SCAN.request. The status indicates the status received from the MAC 35
sub-layer primitive MLME-SCAN.confirm. UnscannedChannels indicates which 36
channels were not scanned (0= channel scanned). EnergyDetectList contains the 37
ED scan result (List of integers, 0x00 - 0xff) for the channels scanned in 38
accordance with IEEE 802.15.4-2003. 39
3.2.2.10.3 Effect on Receipt 40
41
On receipt of this primitive, the next higher layer is notified of the results of an 42
ED scan. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 281
3.2.2.11 NLME-JOIN.request
1
This primitive allows the next higher layer to request to join or rejoin a network, 2
or to change the operating channel for the device while within an operating 3
network. 4
5
3.2.2.11.1 Semantics of the Service Primitive
6
The semantics of this primitive are as follows: 7
8
NLME-JOIN.request {
9
ExtendedPANId, 10
RejoinNetwork, 11
ScanChannels, 12
ScanDuration, 13
CapabilityInformation, 14
SecurityEnable 15
} 16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
282 Network Specification
device to rejoin the network using the NWK rejoining procedure as shown in
Figure 3.40. 1
2
3.2.2.12.3 Effect on Receipt 3
On receipt of this primitive, the next higher layer of a ZigBee coordinator or 4
ZigBee router is notified that a new device has joined its network. 5
6
3.2.2.13 NLME-JOIN.confirm 7
8
This primitive allows the next higher layer to be notified of the results of its 9
request to join a network. 10
3.2.2.13.1 Semantics of the Service Primitive 11
12
The semantics of this primitive are as follows: 13
14
NLME-JOIN.confirm {
15
Status,
16
NetworkAddress, 17
ExtendedPANID, 18
ActiveChannel 19
} 20
21
Table 3.19 specifies the parameters for the NLME-JOIN.confirm primitive. 22
23
Table 3.19 NLME-JOIN.confirm Parameters
24
Name Type Valid Range Description 25
26
Status Status INVALID_REQUEST, The status of the corresponding
NOT_PERMITTED, request. 27
NO_NETWORKS 28
29
or any status value
returned from the MLME- 30
ASSOCIATE.confirm 31
primitive or the MLME- 32
SCAN.confirm primitive. 33
NetworkAddress Integer 0x0001 – 0xfff7 and 0xffff The 16-bit network address that 34
was allocated to this device. This 35
parameter will be equal to 0xffff if 36
the join attempt was unsuccessful.
37
ExtendedPANID Integer 0x0000000000000001 – The 64-bit extended PAN 38
0xfffffffffffffffe identifier for the network of which 39
the device is now a member.
40
ActiveChannel Integer The number of any The value of phyCurrentChannel 41
channel supported by the attribute of the PHY PIB, which is
42
PHY (see [B1]). equal to the current channel of the
network that has been joined. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
286 Network Specification
transmissions. If the MAC sub-layer fails, for any reason, to transmit the route
request command frame, the NLME will issue the ROUTE-DISCOVERY.confirm 1
primitive to the next higher layer with a Status parameter value equal to that 2
returned by the MCPS-DATA.confirm. If the route discovery command frame is 3
sent successfully and if the DstAddrMode parameter has a value of 0x00, 4
indicating many-to-one route discovery, the NLME will immediately issue the 5
ROUTE-DISCOVERY.confirm primitive with a value of SUCCESS. Otherwise, 6
the NLME will wait until either a route reply command frame is received or the 7
route discovery operation times out as described in sub-clause 3.6.3.5. If a route 8
reply command frame is received before the route discovery operation times out, 9
the NLME will issue the NLME-ROUTE-DISCOVERY.confirm primitive to the 10
next higher layer with a status value of SUCCESS. If the operation times out, it 11
will issue the NLME_ROUTE-DISCOVERY.confirm primitive with a Status of 12
ROUTE_ERROR and with a NetworkStatusCode value reflecting the reason for 13
failure as described in Table 3.42. 14
15
3.2.2.32 NLME_ROUTE-DISCOVERY.confirm 16
17
This primitive informs the next higher layer about the results of an attempt to 18
initiate route discovery. 19
3.2.2.32.1 Semantics of the Service Primitive 20
21
The semantics of this primitive are as follows: 22
23
NLME_ROUTE-DISCOVERY.confirm {
24
Status,
25
NetworkStatusCode
26
} 27
28
Table 3.35 specifies the parameters for the NLME-ROUTE- 29
DISCOVERY.confirm primitive. 30
Table 3.35 NLME_ROUTE-DISCOVERY.confirm Parameters 31
32
Name Type Valid Range Description 33
Status status value INVALID_REQUEST, The status of an attempt to 34
ROUTE_ERROR or any status initiate route discovery. 35
value returned by the MCPS- 36
DATA.confirm primitive 37
NetworkSt Network See Table 3.42 In the case where the 38
atusCode status code Status parameter has a 39
value of ROUTE_ERROR, 40
this code gives further
information about the kind 41
of error that occurred. 42
Otherwise, it should be 43
ignored. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 307
on a particular device shall be made available as the value of the NWK constant
nwkcProtocolVersion. 1
2
3.3.1.1.3 Discover Route Sub-Field 3
The discover route sub-field may be used to control route discovery operations for 4
the transit of this frame (see sub-clause 3.6.3.5). 5
6
Table 3.38 Values of the Discover Route Sub-Field 7
Discover Route Field Value Field Meaning 8
9
0x00 Suppress route discovery 10
0x01 Enable route discovery 11
Reserved
12
0x02, 0x03
13
14
For NWK layer command frames, the discover route sub-field shall be set to 0x00 15
indicating suppression of route discovery. 16
3.3.1.1.4 Multicast Flag Sub-Field 17
18
The multicast flag sub-field is 1 bit in length and has the value 0 if the frame is a 19
unicast or broadcast frame and the value 1 if it is a multicast frame. The multicast 20
control field of the NWK header shall be present only if the multicast flag has the 21
value 1. 22
3.3.1.1.5 Security Sub-Field 23
24
The security sub-field shall have a value of 1 if, and only if, the frame is to have 25
NWK security operations enabled. If security for this frame is implemented at 26
another layer or disabled entirely, it shall have a value of 0. 27
3.3.1.1.6 Source Route Sub-Field 28
29
The source route sub-field shall have a value of 1 if and only if a source route 30
subframe is present in the NWK header. If the source route subframe is not 31
present, the source route sub-field shall have a value of 0. 32
33
3.3.1.1.7 Destination IEEE Address Sub-Field
34
The destination IEEE address sub-field shall have a value of 1 if, and only if, the 35
NWK header is to include the full IEEE address of the destination. 36
37
3.3.1.1.8 Source IEEE Address Sub-Field
38
The source IEEE address sub-field shall have a value of 1 if, and only if, the NWK 39
header is to include the full IEEE address of the source device. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
310 Network Specification
of the NWK header. Upon receipt of a frame containing a 64-bit IEEE address, the
contents of the nwkAddressMap and Neighbor Table should be checked for 1
consistency, and updated if necessary. Sub-clause 3.6.1.9.2 describes the actions 2
to take in detecting address conflicts. 3
4
3.3.1.8 Multicast Control Field 5
6
The multicast control sub-field is 1 octet in length and shall only be present if the 7
multicast flag sub-field has a value of 1. It is divided into three sub-fields as 8
illustrated in Figure 3.7. 9
10
Bits: 0 – 1 2–4 5–7
11
Multicast mode NonmemberRadius MaxNonmemberRadius 12
13
14
Figure 3.7 Multicast Control Field Format 15
16
3.3.1.8.1 Multicast Mode Sub-Field 17
18
The multicast mode sub-field indicates whether the frame is to be transmitted 19
using member or non-member mode. Member mode is used to propagate 20
multicasts between the devices that are members of the destination group. Non- 21
member mode is used to transmit a multicast frame from a device that is not a 22
member of the multicast group to a device that is a member of the multicast group. 23
Table 3.39 Values of the Multicast Mode Sub-Field 24
25
Multicast Mode Field 26
Value Field Meaning
27
0x0 Non-member mode 28
0x1 Member mode 29
30
0x2 Reserved 31
0x3 Reserved 32
33
3.3.1.8.2 NonmemberRadius Sub-Field 34
35
The nonmemberradius sub-field indicates the range of a member mode multicast 36
when relayed by devices that are not members of the destination group. Receiving 37
devices that are members of the destination group will set this field to the value of 38
the MaxNonmemberRadius sub-field. The originating device and receiving 39
devices that are not members of the destination group will discard the frame if the 40
NonmemberRadius sub-field has value 0 and will decrement the field if the 41
NonmemberRadius sub-field has a value in the range 0x01 through 0x06. A value 42
of 0x07 indicates an infinite range and is not decremented. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
312 Network Specification
The value of the NonmemberRadius sub-field will never exceed the value of the
MaxNonmemberRadius sub-field. 1
2
3.3.1.8.3 MaxNonmemberRadius Sub-Field 3
The maximum value of the NonmemberRadius sub-field for this frame. 4
5
3.3.1.9 Source Route Subframe Field 6
7
The source route subframe field shall only be present if the source route sub-field 8
of the frame control field has a value of 1. It is divided into three sub-fields as 9
illustrated in Figure 3.8. 10
11
Octets: 1 1 Variable 12
Relay count Relay index Relay list 13
14
15
Figure 3.8 Source Route Subframe Format 16
17
3.3.1.9.1 Relay Count Sub-Field 18
19
The relay count sub-field indicates the number of relays contained in the relay list 20
sub-field of the source route subframe. 21
3.3.1.9.2 Relay Index 22
23
The relay index sub-field indicates the index of the next relay in the relay list sub- 24
field to which the packet will be transmitted. This field is initialized to 1 less than 25
the relay count by the originator of the packet, and is decremented by 1 by each 26
receiving relay. 27
3.3.1.9.3 Relay List Sub-Field 28
29
The relay list sub-field shall contain the list of relay addresses. The relay closest to 30
the destination shall be listed first. The relay closest to the originator shall be 31
listed last. 32
33
3.3.1.10 Frame Payload Field 34
35
The frame payload field has a variable length and contains information specific to 36
individual frame types. 37
38
3.3.2 Format of Individual Frame Types 39
40
There are two defined NWK frame types: data and NWK command. Each of these 41
frame types is discussed in the following sub-clauses. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 313
In the frame control field, the frame type sub-field shall contain the value that
indicates a NWK command frame, as shown in Table 3.37. All other sub-fields 1
shall be set according to the intended use of the NWK command frame. 2
3
The routing fields shall contain an appropriate combination of address and 4
broadcast fields, depending on the settings in the frame control field. 5
3.3.2.2.2 NWK Command Identifier Field 6
7
The NWK command identifier field indicates the NWK command being used. 8
This field shall be set to one of the non-reserved values listed in Table 3.40. 9
3.3.2.2.3 NWK Command Payload Field 10
11
The NWK command payload field of a NWK command frame shall contain the 12
NWK command itself. 13
14
15
3.4 Command Frames 16
17
The command frames defined by the NWK layer are listed in Table 3.40. The 18
following sub-clauses detail how the NLME shall construct the individual 19
commands for transmission. 20
21
For each of these commands, the following applies to the NWK header fields
22
unless specifically noted in the clause on NWK header in each command:
23
• The frame type sub-field of the NWK frame control field shall be set to indicate 24
that this frame is a NWK command frame. 25
26
• The discover route sub-field in the NWK header shall be set to suppress route
27
discovery (see Table 3.38).
28
• The source address field in the NWK header shall be set to the address of the 29
originating device. 30
31
32
Table 3.40 NWK Command Frames 33
Command Frame Identifier Command Name Reference 34
35
0x01 Route request 3.4.1 36
0x02 Route reply 3.4.2 37
38
0x03 Network Status 3.4.3
39
0x04 Leave 3.4.4 40
0x05 Route Record 3.4.5 41
42
0x06 Rejoin request 3.4.6 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 315
device to the destination device to travel more efficiently. The payload of the route
reply command shall be formatted as illustrated in Figure 3.13. 1
2
Octets: 1 1 2 2 1 0/8 0/8 3
4
Command Route Originator Responder Path cost Originator Responder
options request address address IEEE IEEE 5
identifier address address 6
7
NWK command payload
8
Figure 3.13 Route Reply Command Format 9
10
3.4.2.1 MAC Data Service Requirements 11
12
In order to transmit this command using the MAC data service, specified in IEEE 13
802.15.4-2003 [B1], the following information shall be included in the MAC 14
frame header: 15
• The destination MAC address and PAN identifier shall be set to the network 16
address and PAN identifier, respectively, of the first hop in the path back to the 17
originator of the corresponding route request command frame. The destination 18
PAN identifier shall be the same as the PAN identifier of the originator. 19
20
• The source MAC address and PAN identifier shall be set to the network 21
address and PAN identifier of the device sending the route reply command, 22
which may or may not be the device from which the command originated. 23
• The frame control field shall be set to specify that the frame is a MAC data 24
frame with MAC security disabled, since any secured frame originating from 25
the NWK layer shall use NWK layer security. The transmission options shall 26
be set to require acknowledgment. The addressing mode and intra-PAN flags 27
shall be set to support the addressing fields described here. 28
29
3.4.2.2 NWK Header Fields 30
31
In order for this route reply to reach its destination and for the route discovery 32
process to complete correctly, the following information must be provided: 33
• The source address in the NWK header shall be set to the 16-bit network 34
address of the device transmitting the frame. 35
36
• The destination address field in the NWK header shall be set to the network 37
address of the first hop in the path back to the originator of the corresponding 38
route request. 39
• Since this is a NWK layer command frame, the source IEEE address sub-field 40
of the frame control field shall be set to 1 and the source IEEE address field of 41
the NWK header shall be present and shall contain the 64-bit IEEE address of 42
the originator of the frame. The destination IEEE address sub-field of the frame 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 319
control field shall also have a value of 1 and the destination IEEE address field
of the NWK header shall be present and shall contain the 64-bit IEEE address 1
of the first hop in the path back to the originator of the corresponding route 2
request. 3
4
3.4.2.3 NWK Payload Fields 5
6
The NWK frame payload contains a command identifier field, a command options 7
field, the route request identifier, originator and responder addresses and an up-to- 8
date summation of the path cost. 9
The command frame identifier shall contain the value indicating a route reply 10
command frame. 11
12
3.4.2.3.1 Command Options Field 13
The format of the 8-bit command options field is shown in Figure 3.14. 14
15
Bit: 0 – 3 4 5 6 7 16
17
Reserved Originator Responder Multicast Reserved 18
IEEE address IEEE address
19
Figure 3.14 Route Reply Command Options Field 20
21
3.4.2.3.1.1 Originator IEEE Address 22
23
The originator IEEE address sub-field is a single-bit field. It shall have a value of 24
1 if and only if the originator IEEE address field is included in the payload. This 25
bit shall be set when nwkUniqueAddr is FALSE. 26
27
3.4.2.3.1.2 Responder IEEE Address 28
The responder IEEE address sub-field is a single-bit field. It shall have a value of 29
1 if, and only if, the responder IEEE address field is included in the payload. This 30
bit shall be set when nwkUniqueAddr is FALSE and the multicast sub-field is set 31
to 0. 32
33
3.4.2.3.1.3 Multicast Sub-Field 34
35
The multicast sub-field is a single-bit field. It shall have a value of 1 if and only if 36
the command frame is a reply to a request for a route to a multicast group, in 37
which case the responder address field contains the Group ID of the desired 38
group. 39
40
3.4.2.3.2 Route Request Identifier
41
The route request identifier is the 8-bit sequence number of the route request to 42
which this frame is a reply. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
320 Network Specification
• Tree link failure: The routing failure occurred as a result of the failure of an
attempt to route the frame along the tree. 1
2
• Non-tree link failure: The routing failure did not occur as a result of an 3
attempt to route along the tree. 4
• Low battery level: The frame was not relayed because the relaying device was 5
running low on battery power. 6
7
• No routing capacity: The failure occurred because the relaying device has no 8
routing capacity. 9
• No indirect capacity: The failure occurred as the result of an attempt to buffer 10
a frame for a sleeping end device child and the relaying device had no buffer 11
capacity to use. 12
13
• Indirect transaction expiry: A frame that was buffered on behalf of a sleeping 14
end device child has been dropped as a result of a time-out. 15
• Target device unavailable: An end device child of the relaying device is for 16
some reason unavailable. 17
18
• Target address unallocated: The frame was addressed to a non-existent end 19
device child of the relaying device. 20
• Parent link failure: The failure occurred as a result of a failure in the RF link 21
to the device’s parent. This status is only used locally on a device to indicate 22
loss of communication with the parent. 23
24
• Validate route: The multicast route identified in the destination address field 25
should be validated as described in sub-clause 3.6.3.6. 26
• Source route failure: Source routing has failed, probably indicating a link 27
failure in one of the source route’s links. 28
29
• Many-to-one route failure: A route established as a result of a many-to-one 30
route request has failed. 31
• Address conflict: The address in the destination address field has been 32
determined to be in use by two or more devices. 33
34
• Verify addresses: The source device has the IEEE address in the Source IEEE 35
address field and, if the Destination IEEE address field is present, the value it 36
contains is the expected IEEE address of the destination. 37
• PAN identifier update: The operational network PAN identifier of the device 38
has been updated. 39
40
• Network address update: The network address of the device has been 41
updated. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
324 Network Specification
• Bad frame counter: A frame counter reported in a received frame had a value
less than or equal to that stored in nwkSecurityMaterialSet.15 1
2
• Bad key sequence number: The key sequence number reported in a received 3
frame did not match that of nwkActiveKeySeqNumber.16 4
3.4.3.3.2 Destination Address 5
6
The destination address field is 2 octets in length and shall be present if, and only 7
if, the network status command frame is being sent in response to a routing 8
failure. In this case, it shall contain the destination address from the data frame 9
that encountered the failure. 10
11
3.4.4 Leave Command 12
13
The leave command is used by the NLME to inform other devices on the network 14
that a device is leaving the network or else to request that a device leave the 15
network. The payload of the leave command shall be formatted as shown in 16
Figure 3.16 17
18
1 19
20
Command options
21
NWK command payload 22
23
Figure 3.16 Leave Command Frame Format
24
25
3.4.4.1 MAC Data Service Requirement 26
In order to transmit this command using the MAC data service, specified in IEEE 27
802.15.4-2003 [B1], the following information shall be provided: 28
29
• The destination MAC address and PAN identifier shall be set to the network 30
address and PAN identifier, respectively, of the neighbor device to which the 31
frame is being sent or else to the MAC broadcast address 0xffff in the case 32
where the NWK header also contains a broadcast address. 33
• The source MAC address and PAN identifier shall be set to the network 34
address and PAN identifier of the device sending the leave command. 35
36
• The frame control field shall be set to specify that the frame is a MAC data 37
frame with MAC security disabled, since any secured frame originating from 38
the NWK layer shall use NWK layer security. Acknowledgment shall be 39
requested. 40
41
42
15. CCB #765 43
16. CCB #765 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 325
• The addressing mode and intra-PAN flags shall be set to support the addressing
fields described here. 1
2
3.4.4.2 NWK Header Fields 3
4
The NWK header fields of the leave command frame shall be set as follows: 5
• The source IEEE address sub-field of the frame control field shall be set to 1 6
and the source IEEE address field of the NWK header shall be present and shall 7
contain the 64-bit IEEE address of the originator of the frame. 8
9
• If the request sub-field of the command options field is set to 1 then the 10
destination address field in the NWK header shall be set to the network address 11
of the child device being requested to leave. 12
• If the request sub-field is set to 0 then the destination address field in the NWK 13
header shall be set to 0xfffd so that the indication is received by devices with 14
macRxOnWhenIdle equal to TRUE. 15
16
• If and only if the command frame is not broadcast, the destination IEEE 17
address sub-field of the frame control field shall be set to 1, and the destination 18
IEEE address field shall be set to the IEEE address of the device being 19
requested to leave. 20
• The radius field shall be set to 1. 21
22
3.4.4.3 NWK Payload Fields 23
24
The NWK payload of the leave command frame contains a command frame 25
identifier field and a command options field. The command frame identifier field 26
shall be set to specify the leave command frame as described in Table 3.40. 27
3.4.4.3.1 Command Options Field 28
29
The format of the 8-bit Command Options field is shown in Figure 3.17. 30
31
Bit: 0 – 4 5 6 7 32
Reserved Rejoin Request Remove children 33
34
Figure 3.17 Leave Command Options Field 35
36
3.4.4.3.1.1 Rejoin Sub-Field 37
The Rejoin sub-field is a single-bit field. If the value of this sub-field is 1, the 38
device that is leaving from its current parent will rejoin the network. If the value 39
of this sub-field is 0, the device will not rejoin the network. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
326 Network Specification
Such events are radio channel condition and PAN ID conflicts. The payload of a
network report command shall be formatted as illustrated in Figure 3.24. 1
2
Octets: 1 8 Variable 3
4
Command EPID Report
options (see information 5
Figure 3.25) 6
7
NWK command payload
8
Figure 3.24 Network Report Command Frame Format 9
10
3.4.9.1 MAC Data Service Requirements 11
12
In order to transmit this command using the MAC data service, specified in [B1], 13
the following information shall be included in the MAC frame header: 14
• The destination PAN identifier shall be set to the PAN identifier of the device 15
sending the network report command. 16
17
• The destination address shall be set to the value of the next-hop address field in 18
the routing table entry for which the destination address field has the same 19
value as the nwkManagerAddr field in the NIB. If no such routing table entry 20
exists, then the NWK may attempt route discovery as described in sub- 21
clause 3.6.3.5. 22
• The source MAC address and PAN identifier shall be set to the network 23
address and PAN identifier of the device sending the network report command, 24
which may or may not be the device from which the command originated. 25
26
• The frame control field shall be set to specify that the frame is a MAC data 27
frame with MAC security disabled, since any secured frame originating from 28
the NWK layer shall use NWK layer security. The transmission options shall 29
be set to require acknowledgment. 30
31
3.4.9.2 NWK Header Fields 32
The NWK header fields of the network report command frame shall be set as 33
follows: 34
35
• The source address field, source IEEE address sub-field of the frame control 36
field and source IEEE address field of the NWK header shall be set as usual for 37
a NWK command frame. 38
• The destination address field in the NWK header shall be set to the 16-bit 39
network address contained in the nwkManagerAddr attribute of the NIB. 40
41
• The destination IEEE address sub-field of the frame control field shall have a 42
value of 1 and the destination IEEE address field of the NWK header shall be 43
present and shall contain the 64-bit IEEE address of the corresponding to the 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
334 Network Specification
• The destination PAN identifier shall be set to the old PAN identifier of the
ZigBee coordinator in order for the command frame to reach network devices 1
which have not received this update. The destination address shall be set 2
according to the procedures for broadcast transmission outlined in sub- 3
clause 3.6.5. 4
5
• The source MAC address and PAN identifier shall be set to the network 6
address and the old PAN identifier of the device sending the network report 7
command, which may or may not be the device from which the command 8
originated. 9
• The frame control field shall be set to specify that the frame is a MAC data 10
frame with MAC security disabled, since any secured frame originating from 11
the NWK layer shall use NWK layer security. 12
13
3.4.10.2 NWK Header Fields 14
15
The NWK header fields of the network update command frame shall be set as 16
follows: 17
• The source address field, source IEEE address sub-field of the frame control 18
field, and source IEEE address field of the NWK header shall be set as usual for 19
a NWK command frame. 20
21
• The destination address in the NWK header shall be set to the broadcast 22
address 0xffff. 23
• The destination IEEE address sub-field of the frame control field shall have a 24
value of 0 and the destination IEEE address field shall not be present in the 25
NWK header. 26
27
3.4.10.3 NWK Payload Fields 28
29
The NWK frame payload contains a command identifier field, a command options 30
field, an EPID field and an Update Information variable field. 31
The command frame identifier shall contain the value indicating a network update 32
command frame. 33
34
3.4.10.3.1 Command Options Field 35
36
The format of the 8-bit command options field is shown in Figure 3.29.
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 337
1
Bits 0 - 4 5-7 2
3
Update Update
Information Command 4
Count identifier 5
6
(see Figure 3.30)
7
Figure 3.29 Network Update Command Options Field 8
9
3.4.10.3.1.1 Update Information Count Sub-Field 10
11
The update information count sub-field contains an integer indicating the number 12
of records contained within the Update Information field. The size of a record 13
depends on the value of the Update Command Identifier sub-field. 14
15
3.4.10.3.1.2 Update Command Identifier Sub-Field 16
The update command identifier sub-field contains an integer indicating the type of 17
update information command. Figure 3.30 contains the values that can be inserted 18
into this field. 19
20
21
22
Update Command 23
Identifier Value Report Type
24
0x00 PAN Identifier 25
Update 26
0x01 - 0x07 Reserveda 27
a. CCB #824
28
29
Figure 3.30 Update Command Identifier Sub-Field
30
3.4.10.3.2 EPID Field 31
32
The EPID field shall contain the 64bit EPID that identifies the network that is to 33
be updated. 34
35
3.4.10.3.3 Update Id Field
36
The update Id field will reflect the current value of the nwkUpdateId attribute of 37
the device sending the frame. 38
39
3.4.10.3.4 Update Information 40
The update information field provides the information being updated, the format 41
of this field depends upon the value of the Update Command Identifier sub-field. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
338 Network Specification
incremented every time the NWK layer sends a frame. The attributes of the NIB
are presented in Table 3.44. 1
2
Table 3.44 NIB Attributes
3
Read 4
Attribute Id Type Only Range Description Default 5
6
nwkSequenceNumber 0x81 Integer Yes 0x00 – 0xff A sequence number used Random
to identify outgoing frames value from 7
(see sub-clause 3.6.2). within the 8
range 9
nwkPassiveAckTimeout 0x82 Integer No 0x0000 – The maximum time Defined in 10
0x2710 duration in milliseconds stack profile 11
allowed for the parent and 12
all child devices to 13
retransmit a broadcast 14
message (passive
acknowledgment time- 15
out). 16
nwkMaxBroadcastRetries 0x83 Integer No 0x00 – 0x5 The maximum number of
17
0x03
retries allowed after a 18
broadcast transmission 19
failure. 20
nwkMaxChildren 0x84 Integer No 0x00 – 0xff The number of children a Defined in 21
device is allowed to have the stack 22
on its current network Note profile 23
that when nwkAddrAlloc 24
has a value of 0x02,
indicating stochastic 25
addressing, the value of 26
this attribute is 27
implementation- 28
dependent. 29
nwkMaxDepth 0x85 Integer Yes 0x00 – 0xff The depth a device can Defined in 30
have. stack profile 31
nwkMaxRouters 0x86 Integer No 0x01-0xff The number of routers any Defined in 32
one device is allowed to stack profile 33
have as children. This 34
value is determined by the
ZigBee coordinator for all
35
devices in the network. 36
37
If nwkAddrAlloc is 0x02
this value not used.
38
39
nwkNeighborTable 0x87 Set No Variable The current set of neighbor Null set 40
table entries in the device
(see Table 3.48). 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 341
c. CCB #830
1
d. CCB #830
2
3
4
Table 3.45 Route Record Table Entry Format
5
Field Valid 6
Field Name Type Range Reference 7
8
Network Address Integer 0x0000- The destination
0xfff7 network address for 9
this route record. 10
Relay Count Integer 0x0000 - The count of relay 11
0xffff nodes from 12
concentrator to the 13
destination. 14
Path Set of The set of network 15
Network addresses that 16
Addresses represent the route in 17
order from the
18
concentrator to the
destination. 19
20
21
22
Table 3.46 Network Address Map 23
64-bit IEEE Address 16-bit Network address 24
25
A valid 64-bit IEEE Address or Null 0x0000 - 0xfff7 26
if not known 27
28
3.5.2.1 Broadcast Delivery Time 29
30
The total delivery time for a broadcast transmission, i.e. the time required for a 31
broadcast to be delivered to every device in the network, shall be calculated 32
according to the following formula: 33
nwkBroadcastDeliveryTime = 2*nwkMaxDepth* 34
((0.05+(nwkcMaxBroadcastJitter/2))+
35
36
nwkPassiveAckTimeout*nwkBroadcastRetries/
37
1000) 38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 347
(see [B1]), to search for possible interferers. A channel scan is initiated by issuing
the MLME-SCAN.request primitive to the MAC sub-layer with the ScanType 1
parameter set to energy detection scan. The results are communicated back via the 2
MLME-SCAN.confirm primitive. This scan is not necessary if there is only one 3
channel specified. 4
5
On receipt of the results from a successful energy detection scan, the NLME shall 6
order the channels according to increasing energy measurement and discard those 7
channels whose energy levels are beyond an acceptable level. The choice of an 8
acceptable energy level is left to the implementation. The NLME shall then 9
perform an active scan, by issuing the MLME-SCAN.request primitive with the 10
ScanType parameter set to active scan and ChannelList set to the list of acceptable 11
channels, to search for other ZigBee devices. To determine the best channel on 12
which to establish a new network, the NLME shall review the list of returned PAN 13
descriptors and find the first channel with the lowest number of existing networks, 14
favoring a channel with no detected networks. 15
If no suitable channel is found, the NLME shall terminate the procedure and 16
notify the next higher layer of the startup failure. This is achieved by issuing the 17
NLME-NETWORK-FORMATION.confirm primitive with the Status parameter 18
set to STARTUP_FAILURE. 19
20
If a suitable channel is found, the NLME shall select a PAN identifier for the new 21
network. To do this the device shall choose a random PAN identifier less than 22
0xffff that is not already in use on the selected channel. Once the NLME makes its 23
choice, it shall set the macPANID attribute in the MAC sub-layer to this value by 24
issuing the MLME-SET.request primitive. 25
If no unique PAN identifier can be chosen, the NLME shall terminate the 26
procedure and notify the next higher layer of the startup failure by issuing the 27
NLME-NETWORK-FORMATION.confirm primitive with the Status parameter 28
set to STARTUP_FAILURE. 29
30
Once a PAN identifier is selected, the NLME shall select a 16-bit network address 31
equal to 0x0000 and set the nwkNetworkAddress attribute of the NIB equal to the 32
selected network address. 33
Once a network address is selected, the NLME shall check the value of the 34
nwkExtendedPANId attribute of the NIB. If this value is 0x0000000000000000 35
this attribute is initialized with the value of the MAC constant aExtendedAddress. 36
37
Once the value of the nwkExtendedPANId is checked, the NLME shall begin 38
operation of the new PAN by issuing the MLME-START.request primitive to the 39
MAC sub-layer. The parameters of the MLME-START.request primitive shall be 40
set according to those passed in the NLME-NETWORK-FORMATION.request, 41
the results of the channel scan, and the chosen PAN identifier. The status of the 42
PAN startup is communicated back via the MLME-START.confirm primitive. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 349
On receipt of the status of the PAN startup, the NLME shall inform the next higher
layer of the status of its request to initialize the ZigBee coordinator. This is 1
achieved by issuing the NLME-NETWORK-FORMATION.confirm primitive 2
with the Status parameter set to the primitive returned in the MLME- 3
START.confirm from the MAC sub-layer. 4
5
The procedure to successfully start a new network is illustrated in the message 6
sequence chart (MSC) shown in Figure 3.32. 7
8
NLME-NETWORK-FORMATION.request
9
MLME-SCAN.request 10
Perform energy
11
MLME-SCAN.confirm
detection scan 12
MLME-SCAN.request
13
14
Perform active scan 15
MLME-SCAN.confirm
16
Select Channel, PAN ID,
Beacon Payload and Short 17
Address
MLME-SET.request
18
19
MLME-SET.confirm
20
MLME-START.request
21
22
MLME-START.confirm
23
NLME- NETWORK-FORMATION.confirm
24
25
APL NWK MAC
26
Figure 3.32 Establishing a New Network 27
28
3.6.1.2 Permitting Devices to Join a Network 29
30
The procedure for permitting devices to join a network is initiated through the 31
NLME-PERMIT-JOINING.request primitive. Only devices that are either the 32
ZigBee coordinator or a ZigBee router shall attempt to permit devices to join the 33
network. 34
When this procedure is initiated with the PermitDuration parameter set to 0x00, 35
the NLME shall set the macAssociationPermit PIB attribute in the MAC sub-layer 36
to FALSE. A MAC sub-layer attribute setting is initiated by issuing the MLME- 37
SET.request primitive. 38
39
When this procedure is initiated with the PermitDuration parameter set to a value 40
between 0x01 and 0xfe, the NLME shall set the macAssociationPermit PIB 41
attribute in the MAC sub-layer to TRUE. The NLME shall then start a timer to 42
expire after the specified duration. On expiration of this timer, the NLME shall set 43
the macAssociationPermit PIB attribute in the MAC sub-layer to FALSE. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
350 Network Specification
When this procedure is initiated with the PermitDuration parameter set to 0xff, the
NLME shall set the macAssociationPermit PIB attribute in the MAC sub-layer to 1
TRUE for an unlimited amount of time, unless another NLME-PERMIT- 2
JOINING.request primitive is issued. 3
4
The procedure for permitting devices to join a network is illustrated in the MSC 5
shown in Figure 3.33. 6
7
8
NLME-PERMIT-JOINING.request
9
MLME-SET.request( macAssociationPermit ) 10
11
MLME-SET.confirm
NLME-PERMIT-JOINING.confirm 12
13
14
PermitDuration 15
16
17
MLME-SET.request( macAssociationPermit )
18
MLME-SET.confirm 19
20
21
22
APL NWK MAC 23
Figure 3.33 Permitting Devices to Join a Network 24
25
3.6.1.3 Network Discovery 26
27
The NWK layer enables higher layers to discover what networks, if any, are 28
operational in the POS of a device. 29
30
The procedure for network discovery shall be initiated by issuing the NLME-
31
NETWORK-DISCOVERY.request primitive with the ScanChannels parameter
32
set to indicate which channels are to be scanned for networks and the
33
ScanDuration parameter set to indicate the length of time to be spent scanning
34
each channel. Upon receipt of this primitive, the NWK layer shall issue an
35
MLME-SCAN.request primitive asking the MAC sub-layer to perform an active
36
scan.
37
Every beacon frame received during the scan having a non-zero length payload 38
shall cause the MLME-BEACON-NOTIFY.indication primitive to be issued from 39
the MAC sub-layer of the scanning device to its NLME. This primitive includes 40
information such as the addressing information of the beaconing device, whether 41
or not it is permitting association and the beacon payload. (See [B1] for the 42
complete list of parameters). The NLME of the scanning device shall check the 43
protocol ID field in the beacon payload and verify that it matches the ZigBee 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 351
protocol identifier. If not, the beacon is ignored. Otherwise, the device shall copy
the relevant information from each received beacon (see Figure 3.49 for the 1
structure of the beacon payload) into its neighbor table (see Table 3.48 for the 2
contents of a neighbor table entry). 3
4
Once the MAC sub-layer signals the completion of the scan by issuing the 5
MLME-SCAN.confirm primitive to the NLME, the NWK layer shall issue the 6
NLME-NETWORK-DISCOVERY.confirm primitive containing a description of 7
each network that was heard. Every network description contains the ZigBee 8
version, stack profile, Extended PAN Id, PAN Id, logical channel, and information 9
on whether it is permitting joining (see Table 3.8). 10
11
3.6.1.4 Joining a Network 12
For purposes of the ensuing discussion, a parent-child relationship is formed when 13
a device having membership in the network allows a new device to join. On 14
joining, the new device becomes the child, while the first device becomes the 15
parent. 16
17
3.6.1.4.1 Joining a Network Through Association 18
This sub-clause specifies the procedure a device (child) shall follow if it opts to 19
join a network using the underlying association capabilities provided by the 20
MAC, as well as the procedure a ZigBee coordinator or router (parent) shall 21
follow upon receipt of an MLME-ASSOCIATE.request primitive from the MAC. 22
23
24
3.6.1.4.1.1 Child Procedure
25
The procedure for joining a network using the MAC layer association procedure 26
should be preceded by network discovery as described in sub-clause 3.6.1.3. 27
Upon receipt of the NLME-NETWORK-DISCOVERY.confirm primitive, the 28
next higher layer shall either choose a network to join from the discovered 29
networks or redo the network discovery. Once a network is selected, it shall then 30
issue the NLME-JOIN.request with the RejoinNetwork parameter set to 0x00 and 31
the JoinAsRouter parameter set to indicate whether the device wants to join as a 32
routing device. 33
34
Only those devices that are not already joined to a network shall initiate the join 35
procedure. If any other device initiates this procedure, the NLME shall terminate 36
the procedure and notify the next higher layer of the illegal request by issuing the 37
NLME-JOIN.confirm primitive with the Status parameter set to 38
INVALID_REQUEST. 39
For a device that is not already joined to a network, the NLME-JOIN.request 40
primitive shall cause the NWK layer to search its neighbor table for a suitable 41
parent device, i.e. a device for which following conditions are true: 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
352 Network Specification
than one device meets these requirements, then the joining device may select the
parent with the smallest network depth. 1
2
Table 3.47 Capability Information Bit-Fields
3
Bit Name Description 4
5
0 Alternate PAN This field will always have a value of 0 in
6
coordinator implementations of this specification.
7
1 Device type This field will have a value of 1 if the 8
joining device is a ZigBee router. It will 9
have a value of 0 if the device is a ZigBee
end device or else a router-capable device 10
that is joining as an end device. 11
This field will be set to the value of
12
2 Power source
lowest-order bit of the PowerSource 13
parameter passed to the NLME-JOIN- 14
request primitive. The values are: 15
0x01 = Mains-powered device 16
0x00 = other power source 17
18
3 Receiver on when idle This field will be set to the value of the
lowest-order bit of the RxOnWhenIdle
19
parameter passed to the NLME- 20
JOIN.request primitive. 21
0x01 = The receiver is enabled when the
22
device is idle 23
0x00 = The receiver may be disabled 24
when the device is idle 25
This field will always have a value of 0 in
26
4–5 Reserved
implementations of this specification. 27
28
6 Security capability This field shall have a value of 0 if the
device is operating in Standard Security 29
Mode and a value of 1 if the device is 30
operating in High Security Mode. Note 31
that this overrides the default meaning 32
specified in [B1].a 33
7 Allocate address This field will have a value of 1 in 34
implementations of this specification, 35
indicating that the joining device must be
issued a 16-bit network address, except in
36
the case where a device has self-selected 37
its address while using the NWK rejoin 38
command to join a network for the first 39
time in a secure manner. In this case, it 40
shall have a value of 0.
41
a. CCB #788 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
354 Network Specification
Otherwise, the NLME issues the NLME-JOIN.confirm with the Status parameter
set to the Status parameter value returned from the MLME-ASSOCIATE.confirm 1
primitive. 2
3
If the RejoinNetwork parameter is 0x00 and the JoinAsRouter parameter is set to 4
TRUE, the device will function as a ZigBee router in the network. If the 5
JoinAsRouter parameter is FALSE, then it will join as an end device and not 6
participate in routing. 7
The addressing parameters in the MLME-ASSOCIATE.request primitive (see 8
Chapter 2) shall be set to contain the addressing information for the device chosen 9
from the neighbor table. The status of the association is communicated back to the 10
NLME via the MLME-ASSOCIATE.confirm primitive. 11
12
If the attempt to join was unsuccessful, the NWK layer shall receive an MLME- 13
ASSOCIATE.confirm primitive from the MAC sub-layer with the Status 14
parameter indicating the error. If the Status parameter indicates a refusal to permit 15
joining on the part of the neighboring device (that is, PAN at capacity or PAN 16
access denied), then the device attempting to join should set the Potential parent 17
bit to 0 in the corresponding neighbor table entry to indicate a failed join attempt. 18
Setting the Potential parent bit to 0 ensures that the NWK layer shall not issue 19
another request to associate to the same neighboring device. The Potential parent 20
bit should be set to 1 for every entry in the neighbor table each time an MLME- 21
SCAN.request primitive is issued. 22
A join request may also be unsuccessful, if the potential parent is not allowing 23
new routers to associate (for example, the maximum number of routers, 24
nwkMaxRouters may already have associated with the device) and the joining 25
device has set the JoinAsRouter parameter to TRUE. In this case, the NLME- 26
JOIN.confirm primitive will indicate a status of NOT_PERMITTED. In this case, 27
the child device’s application may wish to attempt to join again as an end device 28
instead, by issuing another NLME-JOIN.request with the JoinAsRouter parameter 29
set to FALSE. 30
31
If the attempt to join was unsuccessful, the NLME shall attempt to find another 32
suitable parent from the neighbor table. If no such device could be found, the 33
NLME shall issue the NLME-JOIN.confirm primitive with the Status parameter 34
set to the value returned in the MLME-ASSOCIATE.confirm primitive. 35
If the attempt to join was unsuccessful and there is a second neighboring device 36
that could be a suitable parent, the NWK layer shall initiate the MAC sub-layer 37
association procedure with the second device. The NWK layer shall repeat this 38
procedure until it either joins the PAN successfully or exhausts its options to join 39
the PAN. 40
41
If the device cannot successfully join the PAN specified by the next higher layer, 42
the NLME shall terminate the procedure by issuing the NLME-JOIN.confirm 43
primitive with the Status parameter set to the value returned in the last received 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 355
NLME-NETWORK-DISCOVERY.request
1
MLME-SCAN.request
2
Perform active scan
3
MLME-BEACON-NOTIFY.indication 4
5
6
MLME-BEACON-NOTIFY.indication 7
MLME-SCAN.confirm 8
NLME-NETWORK-DISCOVERY.confirm 9
Select suitable EPID 10
NLME-JOIN.request 11
MLME-ASSOCIATE.request
12
MAC Association Procedure
13
MLME-ASSOCIATE.confirm
14
15
NLME-JOIN.confirm
MLME-SET.request(macBeaconPayload)
Association Procedure
16
MLME-SET.confirm
NLME-START-ROUTER.request
17
MLME-START.request
18
MLME-START.confirm
19
NLME- START_ROUTER.confirm
20
21
APL NWK MAC 22
Figure 3.34 Procedure for Joining a Network Through Association 23
24
3.6.1.4.1.2 Parent Procedure 25
26
The procedure for a ZigBee coordinator or router to join a device to its network 27
using the MAC sub-layer association procedure is initiated by the MLME- 28
ASSOCIATE.indication primitive arriving from the MAC sub-layer. Only those 29
devices that are either a ZigBee coordinator or a ZigBee router and that are 30
permitting devices to join the network shall initiate this procedure. If this 31
procedure is initiated on any other device, the NLME shall terminate the 32
procedure. 33
When this procedure is initiated, the NLME of a potential parent shall first 34
determine whether the device wishing to join already exists on its network. To do 35
this, the NLME shall search its neighbor table in order to determine whether a 36
matching 64-bit, extended address can be found. If an extended address match is 37
found, the NLME shall check that the supplied DeviceCapabilities match the 38
device type on record in the neighbor table. If the device type also matches the 39
NLME, it shall then obtain the corresponding 16-bit network address and issue an 40
association response to the MAC sub-layer. If a device type match is not found the 41
NLME shall remove all records of the device in its neighbor table and restart 42
processing of the MLME-ASSOCIATION.indication. If an extended address 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 357
match is not found, the NLME shall, if possible, allocate a 16-bit network address
for the new device. See sub-clause 3.6.1.6 and sub-clause 3.6.1.7 for an 1
explanation of the address assignment mechanisms. 2
3
If the potential parent does not have the capacity to accept more children, the 4
NLME shall terminate the procedure and indicate this fact in the subsequent 5
MLME-ASSOCIATE.response primitive to the MAC sub-layer. The Status 6
parameter of this primitive shall indicate that the PAN is at capacity. 7
If the request to join is granted, the NLME of the parent shall create a new entry 8
for the child in its neighbor table using the supplied device information and 9
indicate a successful association in the subsequent MLME-ASSOCIATE.response 10
primitive to the MAC sub-layer. If the value of nwkSecurityLevel is 0x00, the 11
relationship field of the new neighbor table entry shall be set to the value 0x01 12
indicating that the neighbor is a child; otherwise, it shall be set to 0x05 indicating 13
an unauthenticated child. The status of the response transmission to the child is 14
communicated back to the network layer via the MLME-COMM- 15
STATUS.indication primitive. 16
17
If the transmission was unsuccessful (i.e. the MLME-COMM-STATUS.indication 18
primitive contained a Status parameter not equal to SUCCESS), the NLME shall 19
terminate the procedure. If the transmission was successful, the NLME shall 20
notify the next higher layer that a child has just joined the network by issuing the 21
NLME-JOIN.indication primitive. 22
The procedure for successfully joining a device to the network is illustrated in the 23
MSC shown in Figure 3.35. 24
25
26
MLME-ASSOCIATE.indication
27
28
Check Extended Address
and assign short address 29
MLME-ASSOCIATE.response 30
MLME-COMM-STATUS.indication 31
32
Update Beacon Payload
33
MLME-SET.request(macBeaconPayload)
34
35
MLME-SET.confirm
NLME-JOIN.indication
36
37
APL NWK MAC 38
39
Figure 3.35 Procedure for Handling a Join Request 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
358 Network Specification
attempt to join was unsuccessful, the NLME shall attempt to find another suitable
parent from the neighbor table. If no such device can be found, the NLME shall 1
issue the NLME-JOIN.confirm primitive with the Status parameter set to 2
NOT_PERMITTED. If the attempt to join is unsuccessful and there is a second 3
neighboring device that could be a suitable parent, the NWK layer shall initiate 4
the NWK rejoin procedure with the second device. The NWK layer shall repeat 5
this procedure until it either rejoins the PAN successfully or exhausts its options to 6
rejoin the PAN. If the device cannot successfully rejoin the PAN specified by the 7
next higher layer, the NLME shall terminate the procedure by issuing the NLME- 8
JOIN.confirm primitive with the Status parameter set to NOT_PERMITTED. In 9
this case, the device shall not receive a valid logical address and shall not be 10
permitted to transmit on the network. If the attempt to rejoin was successful, the 11
NWK rejoin response command received by the NWK layer shall contain a 16-bit 12
logical address unique to that network, which the child can use in future 13
transmissions. Note that this address may be identical to the current 16-bit 14
network address of the device stored in the nwkNetworkAddress attribute of the 15
NIB. The NWK layer shall then set the relationship field in the corresponding 16
neighbor table entry to indicate that the neighbor is its parent. By this time, the 17
parent shall have added the new device to its neighbor table. Furthermore, the 18
NWK layer shall update the values of nwkNetworkAddress, nwkUpdateId, and 19
nwkPANId in the NIB if necessary. 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 361
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Figure 3.36 Child Rejoin Procedure 23
24
3.6.1.4.2.2 Parent Procedure 25
26
The procedure for a ZigBee coordinator or router to rejoin a device to its network 27
using the NWK rejoin procedure is initiated by the arrival of a NWK layer rejoin 28
command frame via the MAC data service. Only those devices that are either 29
ZigBee coordinators or ZigBee routers shall initiate this procedure. If this 30
procedure is initiated on any other device, the NLME shall terminate the 31
procedure. When this procedure is initiated, the NLME of a potential parent shall 32
first determine whether it already has knowledge of the requesting device. To do 33
this, the NLME shall search its neighbor table in order to determine whether a 34
matching 64-bit, extended address can be found. If an extended address match is 35
found, the NLME shall check that the supplied DeviceCapabilities match the 36
device type on record in the neighbor table. If the device type matches, the NLME 37
shall consider the join attempt successful and use the 16-bit network address 38
found in its neighbor table as the network address of the joining device. If a device 39
type match is not found, the NLME shall remove all records of the device in its 40
neighbor table and restart processing of the NWK layer rejoin command. 41
42
If the potential parent does not have the capacity to accept the joining device, the
43
NLME shall terminate the procedure and indicate this fact in the subsequent rejoin
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
362 Network Specification
response command. The Status parameter of this command shall indicate that the
PAN is at capacity. 1
2
If the request to rejoin is granted, the NLME of the parent shall create a new entry 3
for the child in its neighbor table, or modify the existing entry if one such already 4
exists, using the supplied device information, and indicate a successful rejoin by 5
replying to the requesting device with a NWK rejoin response command. If the 6
nwkAddrAlloc attribute of the NIB has a value of 0x00, indicating tree addressing, 7
the NLME shall allocate new a 16-bit network address for the joining device. See 8
sub-clause 3.6.1.6 and sub-clause 3.6.1.7 for an explanation of the address 9
assignment mechanisms. 10
If the nwkAddrAlloc attribute of the NIB does not have a value of 0x00, the 11
allocate address sub-field of the capabilities information field of the rejoin request 12
command frame payload may have a value of 0 indicating a self-assigned or pre- 13
existing network address. In this case, as is the case with all NWK command 14
frames, the 16-bit network address in the source address field of the NWK header, 15
in combination with the 64-bit IEEE address from the source IEEE address field 16
of the network header should be checked for address conflicts as described in sub- 17
clause 3.6.1.9. If an address conflict is discovered, a new, and non-conflicting, 18
address shall be chosen for the joining device and shall be placed in the network 19
address field of command frame payload of the outgoing rejoin response 20
command frame. Otherwise, the contents of the source address field of the 21
incoming rejoin request command frame shall be placed in the network address 22
field of the command frame payload of the outgoing rejoin response command 23
frame. 24
25
The NLME shall then notify the next higher layer that a child has just rejoined the 26
network by issuing the NLME-JOIN.indication primitive. The procedure for 27
successfully rejoining a device to the network is illustrated in the MSC shown in 28
Figure 3.37. 29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 363
MCPS-DATA.indication(NWK_REJOIN_REQUEST)
1
Check Extended Address
2
and if appropriate assign 3
short address
MCPS-DATA.request(NWK_REJOIN_RESPONSE)
4
MCPS-DATA.confirm
5
6
Update Beacon Payload
7
MLME-SET.request(macBeaconPayload) 8
MLME-SET.confirm 9
NLME-JOIN.indication 10
11
12
APL NWK MAC 13
14
Figure 3.37 Parent Rejoin Procedure 15
16
3.6.1.4.3 Joining a Network Directly 17
This sub-clause specifies how a device can be directly added to a network by a 18
previously designated parent device (ZigBee coordinator or router). In this case, 19
the parent device is preconfigured with the 64-bit address of the child device. The 20
following text describes how this prior address knowledge may be used to 21
establish the parent-child relationship. 22
23
The procedure for a ZigBee coordinator or router to directly join a device to its 24
network is initiated by issuing the NLME-DIRECT-JOIN.request primitive with 25
the DeviceAddress parameter set to the address of the device to be joined to the 26
network. Only those devices that are either a ZigBee coordinator or a ZigBee 27
router may initiate this procedure. If this procedure is initiated on any other 28
device, the NLME may terminate the procedure and notify the next higher layer of 29
the illegal request by issuing the NLME-DIRECT-JOIN.confirm primitive with 30
the Status parameter set to INVALID_REQUEST. 31
When this procedure is initiated, the NLME of the parent shall first determine 32
whether the specified device already exists on its network. To do this, the NLME 33
shall search its neighbor table in order to determine whether a matching 64-bit, 34
extended address can be found. If a match is found, the NLME shall terminate the 35
procedure and notify the next higher layer that the device is already present in the 36
device list by issuing the NLME-DIRECT-JOIN.confirm primitive with the Status 37
parameter set to ALREADY_PRESENT. 38
39
If a match is not found, the NLME shall, if possible, allocate a 16-bit network 40
address for the new device as well as a new neighbor table entry. See sub- 41
clause 3.6.1.6 and sub-clause 3.6.1.7 for an explanation of the address assignment 42
mechanisms. If the parent device has no more room in its neighbor table, the 43
NLME shall terminate the procedure and notify the next higher layer of the 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
364 Network Specification
command frame (see sub-clause 3.6.1.4.2). The ZigBee coordinator, which has no
parent, shall always have the address 0x0000. 1
2
3.6.1.8 Installation and Addressing 3
4
It should be clear that nwkMaxDepth roughly determines the number of hops in 5
network terms from the root of the tree to the farthest end device. In principle, 6
nwkMaxDepth also determines the overall network diameter. In particular, for an 7
ideal network layout in which the ZigBee coordinator is located in the center of 8
the network, as illustrated in Figure 3.41, the network diameter should be 2* 9
nwkMaxDepth. In practice, application-driven placement decisions and order of 10
deployment may lead to a smaller diameter. In this case, nwkMaxDepth provides a 11
lower bound on the network diameter while the 2* nwkMaxDepth provides the 12
upper bound. 13
Finally, due to the fact that the tree is not dynamically balanced, when 14
nwkAddrAlloc has a value of 0x00, the possibility exists that certain installation 15
scenarios, such as long lines of devices, may exhaust the address capacity of the 16
network long before the real capacity is reached. 17
18
Under stochastic address assignment, nwkMaxDepth is related to the number of 19
hops across the network. This is not a controlled value in networks using 20
stochastic address assignment. 21
22
3.6.1.9 Address Conflicts 23
An address conflict occurs when two devices in the same network have identical 24
values for nwkNetworkAddress. Preventing all such conflicts, for example by 25
using tree address assignment and prohibiting the reuse of assigned addresses, is 26
not always practical. This section describes how address conflicts that do occur 27
can be detected and corrected. Address conflict detection shall be enabled if the 28
NIB attribute nwkUniqueAddr is FALSE. 29
30
Note that the network addresses used in routing messages are verified during the 31
route discovery process. The device_annc now is also used to verify addresses. 32
The verification applies only to devices, links, and information present at the time 33
of the discovery or device_annc. Verification can be achieved at other times, such 34
as before sending a unicast directly to a neighbor, by sending a network status 35
command with a status code value of 0x0e, indicating address verification. 36
If a device receives a broadcast data frame and discovers an address conflict as a 37
result of the receipt, as discussed below in sub-clause 3.6.1.9.2, it should not 38
retransmit the frame as usual but shall discard it before taking the resolution 39
actions described below in sub-clause 3.6.1.9.3.21 40
41
42
43
21. CCB #869 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
374 Network Specification
status command with a status code of 0x0d indicating address conflict, and with
the offending address in the destination address field. The network status 1
command shall be broadcast to 0xFFFD, i.e. all devices with macRxOnWhenIdle 2
= TRUE. The device shall delay initiation of this broadcast by a random jitter 3
amount bounded by nwkcMaxBroadcastJitter. If during this delay a network 4
status is received with the identical payload, the device shall cancel its own 5
broadcast. 6
7
If a device determines that there are one or more other users of its own network 8
address, or if the device receives a network status command with a status code of 9
0x0d indicating address conflict, and its own address in the destination address 10
field, then that device shall obtain a new address. 11
If the conflict is detected on a ZigBee end device or nwkAddrAlloc is not equal to 12
stochastic address assignment then the device shall perform a rejoin to obtain a 13
new address. Otherwise, the device that requires a new address shall pick a new 14
address randomly, avoiding all addresses that appear in NIB entries. 15
16
If a parent device detects or is informed of a conflict with the address of a child, 17
the parent shall pick a new address for the child and shall send an unsolicited 18
rejoin response command frame to inform the child of the new address. To notify 19
the next higher layer of an address change, an NLME-NWK-STATUS.indication 20
shall be issued with status 'Network Address Update' and the new network address 21
as the value of the ShortAddr parameter.23 22
23
3.6.1.10 Leaving a Network 24
This sub-clause specifies methods for a device to remove itself from the network 25
and for the parent of a device to request its removal. In both cases, the children of 26
the removed device, if any, may also be removed. 27
28
3.6.1.10.1 Method for a Device to Initiate Its Own Removal from the Network 29
This sub-clause describes how a device can initiate its own removal from the 30
network in response to the receipt of an NLME-LEAVE.request primitive from 31
the next higher layer as shown in Figure 3.42. 32
33
34
35
36
37
38
39
40
41
42
43
23. CCB #814 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
376 Network Specification
1
2
3
4
5
6
7
8
9
10
11
Figure 3.42 Initiation of the Leave Procedure 12
13
When the NWK layer of a ZigBee router or ZigBee coordinator, receives the 14
NLME-LEAVE.request primitive with the DeviceAddress parameter equal to 15
NULL (indicating that the device is to remove itself) the device shall send a leave 16
command frame using the MCPS-DATA.request primitive with the DstAddr 17
parameter set to 0xffff indicating a MAC broadcast. The request sub-field of the 18
command options field of the leave command frame shall be set to 0. The value of 19
the remove children sub-field of the command options field of the leave command 20
shall reflect the value of the RemoveChildren parameter of the NLME- 21
LEAVE.request primitive, and the value of the Rejoin sub-field of the leave 22
command shall reflect the value of the Rejoin parameter of the NLME- 23
LEAVE.request primitive. After transmission of the leave command frame, it shall 24
issue a NLME-LEAVE.confirm primitive to the higher layer with the 25
DeviceAddress parameter equal to NULL. The Status parameter shall be 26
SUCCESS if the leave command frame was transmitted successfully. Otherwise, 27
the Status parameter of the NLME-LEAVE.confirm shall have the same value as 28
the Status parameter returned by the MCPS-DATA.confirm primitive. 29
30
If the device receiving the NLME-LEAVE.request primitive is a ZigBee end 31
device, then the device shall send a leave command frame using the MCPS- 32
DATA.request primitive with the DstAddr parameter set to the 16-bit network 33
address of its parent device, indicating a MAC unicast. The request and remove 34
children sub-fields of the command options field of the leave command frame 35
shall be set to 0. After transmission of the leave command frame, it shall set the 36
nwkExtendedPANId attribute of the NIB to 0x0000000000000000 and issue a 37
NLME-LEAVE.confirm primitive to the higher layer with the DeviceAddress 38
parameter equal to NULL. The Status parameter shall be SUCCESS if the leave 39
command frame was transmitted successfully. Otherwise, the Status parameter of 40
the NLME-LEAVE.confirm shall have the same value as the Status parameter 41
returned by the MCPS-DATA.confirm primitive. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 377
3.6.1.10.2 Method for a Device to Remove Its Child from the Network
1
This sub-clause describes how a device can initiate the removal from the network 2
of one of its child devices in response to the receipt of an NLME-LEAVE.request 3
primitive from the next higher layer as shown in Figure 3.43. 4
5
6
7
8
9
10
11
12
13
14
15
16
17
Figure 3.43 Procedure for a Device to Remove Its Child 18
19
When the NWK layer of a ZigBee coordinator or ZigBee router, receives the 20
NLME-LEAVE.request primitive with the DeviceAddress parameter equal to the 21
64-bit IEEE address of a child device, if the relationship field of the neighbor 22
table entry corresponding to that child device does not have a value of 0x05 23
indicating that the child has not yet authenticated, the device shall send a network 24
leave command frame using the MCPS-DATA.request primitive with the DstAddr 25
parameter set to the 16-bit network address of that child device. The request sub- 26
field of the command options field of the leave command frame shall have a value 27
of 1, indicating a request to leave the network. The value of the remove children 28
sub-field of the command options field of the leave command shall reflect the 29
value of the RemoveChildren parameter of the NLME-LEAVE.request primitive, 30
and the value of the Rejoin sub-field of the leave command shall reflect the value 31
of the Rejoin parameter of the NLME-LEAVE.request primitive. 32
If the relationship field of the neighbor table entry corresponding to the device 33
being removed has a value of 0x05, indicating that it is an unauthenticated child, 34
the device shall not send a network leave command frame. 35
36
Next, the NWK layer shall issue the NLME-LEAVE.confirm primitive with the 37
DeviceAddress parameter set to the 64-bit IEEE address of the child device being 38
removed. The Status parameter of the NLME-LEAVE.confirm primitive shall 39
have a value of SUCCESS if the leave command frame was not transmitted, i.e. in 40
the case of an unauthenticated child. Otherwise, the Status parameter of the 41
NLME-LEAVE.confirm shall have the same value as the Status parameter 42
returned by the MCPS-DATA.confirm primitive. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
378 Network Specification
After the child device has been removed, the NWK layer of the parent should
modify its neighbor table, and any other internal data structures that refer to the 1
child device, to indicate that the device is no longer on the network. It is an error 2
for the next higher layer to address and transmit frames to a child device after that 3
device has been removed. 4
5
If an unauthenticated child device is removed from the network before it is 6
authenticated, then the address formerly in use by the device being asked to leave 7
may be assigned to another device that joins subsequently. 8
ZigBee end devices have no child devices to remove and should not receive 9
NLME-LEAVE.request primitives with non-NULL DeviceAddress parameters. 10
11
3.6.1.10.3 Upon Receipt of the Leave Command Frame 12
Upon receipt of the leave command frame by the NWK layer via the MCPS- 13
DATA.indication primitive, as shown in Figure 3.44, the device shall check the 14
value of the request sub-field of the command options field of the command 15
frame. If the request sub-field has a value of 0, then the NWK layer shall issue the 16
NLME-LEAVE.indication primitive to the next higher layer with the device 17
address parameter equal to the value in the source IEEE Address sub-field of the 18
leave command frame. The device should also modify its neighbor table, and any 19
other internal data structures that refer to the leaving device, to indicate that it is 20
no longer on the network. It is an error for the next higher layer to address and 21
transmit frames to a device after that device has left the network. 22
23
24
25
APL NWK MAC 26
27
MCPS-DATA.indication (NWK_LEAVE) 28
29
NLME-LEAVE.indication (Remote Device)
30
31
Continue if
RemoveChildren=1 and 32
received from Parent
33
MCPS-DATA.request (NWK_LEAVE indication)
34
35
MCPS-DATA.confirm 36
NLME-LEAVE.indication (NULL)
37
38
39
40
Figure 3.44 On Receipt of a Leave Command 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 379
MCPS-DATA.indication(NWK_LEAVE) 1
NLME-LEAVE.indication( Remote Device ) 2
3
Continue on ZigBee Routers, 4
if RemoveChildren, and
received from Parent 5
MCPS-DATA.request(NWK_LEAVE Indication) 6
MCPS-DATA.confirm 7
NLME-LEAVE.indication( NULL )
8
9
10
APL NWK MAC 11
12
Figure 3.45 On Receipt of a Leave Command by a ZED
13
If, on receipt by the NWK layer of a ZigBee router of a leave command frame as 14
described above, the SrcAddr parameter of the MCPS-DATA.indication that 15
delivered the command frame is the 16-bit network address of the parent of the 16
recipient, and either the value of the request sub-field of the command options 17
field is found to have a value of 1 or the value of the remove children sub-field of 18
the command options field is found to have a value of 1, then the recipient shall 19
send a leave command frame using the MCPS-DATA.request primitive with the 20
DstAddr parameter set to 0xffff indicating a MAC broadcast. The request sub- 21
field of the command options field of the leave command frame shall be set to 0. 22
23
The value of the remove children sub-field of the command options field of the 24
outgoing leave command shall reflect the value of the same field for the incoming 25
leave command frame. After transmission of the leave command frame, it shall set 26
the nwkExtendedPANId attribute of the NIB to 0x0000000000000000 and it shall 27
issue a NLME-LEAVE.indication primitive to the higher layer with 28
DeviceAddress parameter equal to NULL. 29
If the request sub-field has a value of 1 and the source of the leave command 30
frame is a device other than the parent of the recipient, the frame shall be 31
immediately and silently discarded. 32
33
If a ZigBee end device receives a leave command frame as described above and 34
the SrcAddr parameter of the MCPS-DATA.indication that delivered the 35
command frame is the 16-bit network address of the parent of the recipient, it 36
shall set the nwkExtendedPANId attribute of the NIB to 0x0000000000000000 and 37
shall issue a NLME-LEAVE.indication primitive to the higher layer with 38
DeviceAddress parameter equal to NULL. 39
The NWK layer may employ retry techniques, as described in sub-clause 3.6.5 to 40
enhance the reliability of the leave procedure but, beyond this note, these 41
mechanisms are outside the scope of this specification. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
380 Network Specification
Once an NPDU is complete, if security is required for the frame, it shall be passed
to the security service provider for subsequent processing according to the 1
specified security suite (see sub-clause 4.2.2). Security processing is not required 2
if the SecurityEnable parameter of the NLDE-DATA.request is equal to FALSE. If 3
the NWK security level as specified in nwkSecurityLevel is equal to 0, or if the 4
frame originated at the higher layer and the nwkSecureAllFrames NIB attribute is 5
set to 0x00, then the security sub-field of the frame control field shall always be 6
set to 0. 7
8
On successful completion of the secure processing, the security suite returns the 9
frame to the NWK layer for transmission. The processed frame will have the 10
correct auxiliary header attached. If security processing of the frame fails and the 11
frame was a data frame, the frame will inform the higher layer of the NLDE- 12
DATA.confirm primitive’s status. If security processing of the frame fails and the 13
frame is a network command frame, it is discarded and no further processing shall 14
take place. 15
When the frame is constructed and ready for transmission, it shall be passed to the 16
MAC data service. An NPDU transmission is initiated by issuing the MCPS- 17
DATA.request primitive to the MAC sub-layer. The MCPS-DATA.confirm 18
primitive then returns the results of the transmission. 19
20
3.6.2.2 Reception and Rejection 21
22
In order to receive data, a device must enable its receiver. The next higher layer 23
may initiate reception using the NLME-SYNC.request primitive. On a beacon- 24
enabled network, receipt of this primitive by the NWK layer shall cause a device 25
to synchronize with its parent’s next beacon and, optionally, to track future 26
beacons. The NWK layer shall accomplish this by issuing an MLME- 27
SYNC.request to the MAC sub-layer. On a non-beacon-enabled network, the 28
NLME-SYNC.request shall cause the NWK layer of a device with 29
macRxOnWhenIdle set to FALSE to poll the device’s parent using the MLME- 30
POLL.request primitive. 31
On a non-beacon-enabled network, the NWK layer on a ZigBee coordinator or 32
ZigBee router shall ensure, to the maximum extent feasible, that the receiver is 33
enabled whenever the device is not transmitting. On a beacon-enabled network, 34
the NWK layer should ensure that the receiver is enabled when the device is not 35
transmitting during the active period of its own superframe and of its parent’s 36
superframe. The NWK layer may use the macRxOnWhenIdle attribute of the 37
MAC PIB for this purpose. 38
39
Once the receiver is enabled, the NWK layer will begin to receive frames via the 40
MAC data service. On receipt of each frame, the radius field of the NWK header 41
shall be decremented by 1. If, as a result of being decremented, this value falls to 42
0, the frame shall not, under any circumstances, be retransmitted. It may, however, 43
be passed to the next higher layer or otherwise processed by the NWK layer as 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
384 Network Specification
outlined elsewhere in this specification. The following data frames shall be passed
to the next higher layer using the NLDE-DATA.indication primitive: 1
2
• Frames with a broadcast address that matches a broadcast group of which the 3
device is a member. 4
• Unicast data frames and source-addressed data frames for which the destination 5
address matches the device's network address. 6
7
• Multicast data frames whose group identifier is listed in the nwkGroupIDTable. 8
If the receiving device is a ZigBee coordinator or an operating ZigBee router, that 9
is, a router that has already invoked the NLME-START-ROUTER.request 10
primitive, it shall process data frames as follows: 11
12
• Broadcast and multicast data frames shall be relayed according to the 13
procedures outlined in sub-clauses 3.6.5 and 3.6.6. 14
• Unicast data frames with a destination address that does not match the device's 15
network address shall be relayed according to the procedures outlined in sub- 16
clause 3.6.3.3. (Under all other circumstances, unicast data frames shall be 17
discarded immediately.) 18
19
• Source-routed data frames with a destination address that does not match the 20
device’s network address shall be relayed according to the procedures outlined 21
in sub-clause 3.6.3.3.2. 22
• The procedure for handling route request command frames is outlined in sub- 23
clause 3.6.3.5.2. 24
25
• The procedure for handling route reply command frames for which the 26
destination address matches the device's network address is outlined in sub- 27
clause 3.6.3.5.3. 28
• Route reply command frames for which the destination address does not match 29
the device's network address shall be discarded immediately. Network status 30
command frames shall be handled in the same manner as data frames. 31
32
The NWK layer shall indicate the receipt of a data frame to the next higher layer 33
using the NLDE-DATA.indication primitive. 34
On receipt of a frame, the NLDE shall check the value of the security sub-field of 35
the frame control field. If this value is non-zero, the NLDE shall pass the frame to 36
the security service provider (see 4.2.2) for subsequent processing according to 37
the specified security suite. If the security sub-field is set to 0, the 38
nwkSecurityLevel attribute in the NIB is non-zero, and the incoming frame is a 39
NWK command frame, the NLDE shall discard the frame. If the security sub-field 40
is set to 0, the nwkSecurityLevel attribute in the NIB is non-zero, and the incoming 41
frame is a NWK data frame, the NLDE shall check the nwkSecureAllFrames NIB 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 385
attribute. If this attribute is set to 0x01, the NLDE shall only accept the frame if it
is destined to itself, that is, if it does not need to be forwarded to another device. 1
2
3
3.6.3 Routing 4
5
ZigBee coordinators and routers shall provide the following functionality: 6
• Relay data frames on behalf of higher layers 7
8
• Relay data frames on behalf of other ZigBee routers 9
• Participate in route discovery in order to establish routes for subsequent data 10
frames 11
12
• Participate in route discovery on behalf of end devices 13
• Participate in route repair 14
15
• Employ the ZigBee path cost metric as specified in route discovery 16
ZigBee coordinators or routers may provide the following functionality: 17
18
• Maintain routing tables in order to remember best available routes 19
• Initiate route discovery on behalf of higher layers 20
21
• Initiate route discovery on behalf of other ZigBee routers 22
• Initiate route repair 23
24
• Conduct neighbor routing 25
26
3.6.3.1 Routing Cost 27
The ZigBee routing algorithm uses a path cost metric for route comparison during 28
route discovery and maintenance. In order to compute this metric, a cost, known 29
as the link cost, is associated with each link in the path and link cost values are 30
summed to produce the cost for the path as a whole. 31
32
More formally, if we define a path P of length L as an ordered set of 33
devices [D 1,D 2 … D L ] and a link, [D i,D i + 1 ]as a sub-path of length 2, then the path 34
cost 35
36
L–1 37
C {P } = ∑ C {[Di,Di + 1 ]} 38
i=1 39
40
where each of the values C {[Di,Di + 1 ]} is referred to as a link cost. The link 41
cost C {l } for a link l is a function with values in the interval [0… 7 ] defined as: 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
386 Network Specification
1
⎧7, 2
⎪ 3
C{l} = ⎨ ⎛ ⎛ 1 ⎞⎞
⎜ ⎟
⎪min⎜ 7, round⎜⎜ p 4 ⎟⎟ ⎟ 4
⎩ ⎝ ⎝ l ⎠⎠ 5
6
7
where pl is defined as the probability of packet delivery on the link l. 8
Thus, implementers may report a constant value of 7 for link cost or they may 9
report a value that reflects the probability pl of reception — specifically, the 10
reciprocal of that probability — which should, in turn, reflect the number of 11
expected attempts required to get a packet through on that link each time it is 12
used. A device that offers both options may be forced to report a constant link cost 13
by setting the value of the NIB attribute nwkReportConstantCost to TRUE. If the 14
nwkSymLink attribute of the NIB has a value of TRUE, then the 15
nwkReportConstantCost attribute must have a value of FALSE, and the NWK 16
layer must calculate routing cost in the manner described above.28 17
18
The question that remains, however, is how pl is to be estimated or measured. This 19
is primarily an implementation issue, and implementers are free to apply their 20
ingenuity. pl may be estimated over time by actually counting received beacon 21
and data frames and observing the appropriate sequence numbers to detect lost 22
frames. This is generally regarded as the most accurate measure of reception 23
probability. However, the most straightforward method, available to all, is to form 24
estimates based on an average over the per-frame LQI value provided by the IEEE 25
802.15.4-2003 MAC and PHY. Even if some other method is used, the initial cost 26
estimates shall be based on average LQI. A table-driven function may be used to 27
map average LQI values onto C{l} values. It is strongly recommended that 28
implementers check their tables against data derived from tests performed on 29
production hardware, as inaccurate costs will hamper the operating ability of the 30
ZigBee routing algorithm. 31
32
3.6.3.2 Routing Tables 33
A ZigBee router or ZigBee coordinator may maintain a routing table. The 34
information that shall be stored in a ZigBee routing table entry is shown in 35
Table 3.51. The aging and retirement of routing table entries in order to reclaim 36
37
38
39
40
41
42
43
28. CCB #809 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 387
table space from entries that are no longer in use is a recommended practice; it is,
however, out of scope of this specification. 1
2
Table 3.51 Routing Table Entry
3
Field Name Size Description 4
5
Destination address 2 The 16-bit network address or Group ID of this route. If the
6
octets destination device is a ZigBee router, ZigBee coordinator, or
an end device, and nwkAddrAlloc has a value of 0x02, this 7
field shall contain the actual 16-bit address of that device. If 8
the destination device is an end device and nwkAddrAlloc has 9
a value of 0x00, this field shall contain the 16-bit network 10
address of the device’s parent.
11
Status 3 bits The status of the route. See Table 3.52 for values. 12
No route cache 1 bit A flag indicating that the destination indicated by this address 13
does not store source routes. 14
Many-to-one 1 bit A flag indicating that the destination is a concentrator that 15
issued a many-to-one route request. 16
Route record 1 bit A flag indicating that a route record command frame should 17
required be sent to the destination prior to the next data packet. 18
GroupID flag 1 bit A flag indicating that the destination address is a Group ID. 19
20
Next-hop address 2 The 16-bit network address of the next hop on the way to the
21
octets destination.
22
23
Table 3.52 enumerates the values for the route status field. 24
Table 3.52 Route Status Values 25
26
Numeric Value Status
27
0x0 ACTIVE 28
29
0x1 DISCOVERY_UNDERWAY
30
0x2 DISCOVERY_FAILED 31
0x3 INACTIVE 32
33
0x4 VALIDATION_UNDERWAY
34
0x5 – 0x7 Reserved 35
36
This section describes the routing algorithm. The term “routing table capacity” is 37
used to describe a situation in which a device has the ability to use its routing table 38
to establish a route to a particular destination device. A device is said to have 39
routing table capacity if: 40
41
• It is a ZigBee coordinator or ZigBee router 42
• It maintains a routing table 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
388 Network Specification
• It has a free routing table entry or it already has a routing table entry
corresponding to the destination 1
2
If a ZigBee router or ZigBee coordinator maintains a routing table, it shall also 3
maintain a route discovery table containing the information shown in Table 3.53. 4
Routing table entries are long-lived, while route discovery table entries last only 5
as long as the duration of a single route discovery operation and may be reused. 6
Table 3.53 Route Discovery Table Entry 7
8
Field Name Size Description 9
Route request ID 1 octet A sequence number for a route request command frame that is 10
incremented each time a device initiates a route request. 11
Source address 2 The 16-bit network address of the route request’s initiator. 12
octets 13
Sender address 2 The 16-bit network address of the device that has sent the most 14
octets recent lowest cost route request command frame corresponding to 15
this entry’s route request identifier and source address. This field is 16
used to determine the path that an eventual route reply command 17
frame should follow.
18
Forward cost 1 octet The accumulated path cost from the source of the route request to 19
the current device. 20
Residual cost 1 octet The accumulated path cost from the current device to the 21
destination device. 22
Expiration time 2 A countdown timer indicating the number of milliseconds until 23
octets route discovery expires. The initial value is 24
nwkcRouteDiscoveryTime. 25
26
A device is said to have “route discovery table capacity” if: 27
• It maintains a route discovery table 28
29
• It has a free entry in its route discovery table 30
If a device has both routing table capacity and route discovery table capacity then 31
it may be said to have “routing capacity.” 32
33
During route discovery, the information that a ZigBee router or ZigBee 34
coordinator is required to maintain in order participate in the discovery of a 35
particular route is distributed between a routing table entry and a route discovery 36
table entry. Once discovery has been completed, only the routing table entry need 37
be maintained in order for the NWK layer to perform routing along the discovered 38
route. Throughout this sub-clause, references are made to this relationship 39
between a routing table entry and its “corresponding” route discovery table entry 40
and vice versa. The maintenance of this correspondence is up to the implementer 41
since entries in the tables have no elements in common, but it is worth noting in 42
this regard that the unique “keys” that define a route discovery are the source 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 389
address of the route discovery command frame and the route request ID generated
by that device and carried in the command frame payload. 1
2
If a device has the capability to initiate a many-to-one route request, it may also 3
maintain a route record table (see Table 3.45). 4
5
3.6.3.3 Upon Receipt of a Unicast Frame 6
On receipt of a unicast frame from the MAC sub-layer, or an NLDE- 7
DATA.request from the next higher layer, the NWK layer routes it according to 8
the following procedure. 9
10
If the receiving device is a ZigBee router or ZigBee coordinator, and the 11
destination of the frame is a ZigBee end device and also the child of the receiving 12
device, the frame shall be routed directly to the destination using the MCPS- 13
DATA.request primitive, as described in sub-clause 3.6.2.1. The frame shall also 14
set the next hop destination address equal to the final destination address. 15
Otherwise, for purposes of the ensuing discussion, define the routing address of a 16
device to be its network address if it is a router or the coordinator or an end device 17
and nwkAddrAlloc has a value of 0x02, or the network address of its parent if it is 18
an end device and nwkAddrAlloc has a value of 0x00. Define the routing 19
destination of a frame to be the routing address of the frame’s NWK destination. 20
Note that distributed address assignment makes it possible to derive the routing 21
address of any device from its address. See sub-clause 3.6.1.6 for details. 22
A ZigBee router or ZigBee coordinator may check the neighbor table for an entry 23
corresponding to the routing destination of the frame. If there is such an entry, the 24
device may route the frame directly to the destination using the MCPS- 25
DATA.request primitive as described in sub-clause 3.6.2.1. 26
27
A device that has routing capacity shall check its routing table for an entry 28
corresponding to the routing destination of the frame. If there is such an entry, and 29
if the value of the route status field for that entry is ACTIVE or 30
VALIDATION_UNDERWAY, the device shall relay the frame using the MCPS- 31
DATA.request primitive and set the route status field of that entry to ACTIVE if it 32
does not already have that value. If the many-to-one field of the routing table 33
entry is set to TRUE, the NWK shall follow the procedure outlined in sub- 34
clause 3.6.3.5.4 to determine whether a route record command frame must be 35
sent. 36
When relaying a unicast frame, the SrcAddrMode and DstAddrMode parameters 37
of the MCPS-DATA.request primitive shall both have a value of 0x02, indicating 38
16-bit addressing. The SrcPANId and DstPANId parameters shall both have the 39
value provided by the macPANId attribute of the MAC PIB for the relaying 40
device. The SrcAddr parameter shall be set to the value of macShortAddress from 41
the MAC PIB of the relaying device, and the DstAddr parameter shall be the value 42
provided by the next-hop address field of the routing table entry corresponding to 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
390 Network Specification
to the next higher layer with the NetworkAddr parameter equal to the 16-bit
network address of the frame, and the Status parameter equal to 0x04, indicating a 1
lack of routing capacity. 2
3
For hierarchical routing, if the destination is a descendant of the device, the device 4
shall route the frame to the appropriate child. If the destination is a child, and it is 5
also an end device, delivery of the frame can fail due to the macRxOnWhenIdle 6
state of the child device. If the child has macRxOnWhenIdle set to FALSE, 7
indirect transmission as described in IEEE 802.15.4-2003 [B1] may be used to 8
deliver the frame. If the destination is not a descendant, the device shall route the 9
frame to its parent. 10
Every other device in the network is a descendant of the ZigBee coordinator and 11
no device in the network is the descendant of any ZigBee end device. For a 12
ZigBee router with address A at depth d, if the following logical expression is true, 13
then a destination device with address D is a descendant: 14
15
A < D < A + Cskip (d – 1 ) 16
For a definition of Cskip (d ), see sub-clause 3.6.1.6. 17
18
If it is determined that the destination is a descendant of the receiving device, the 19
address N of the next hop device is given by: 20
21
N = D
22
for ZigBee end devices, where D > A + Rm · Cskip (d ), and otherwise: 23
24
25
⎢ D - (A +1)⎥ 26
N = A +1 + ⎢ ⎥ · Cskip (d )
⎣ Cskip (d ) ⎦ 27
28
If the NWK layer on a ZigBee router or ZigBee coordinator fails to deliver a 29
unicast or multicast frame for any reason, the router or coordinator shall make its 30
best effort to report the failure. No failure should be reported as the result of a 31
failure to deliver a NLME-NWK-STATUS. The failure reporting may take one of 32
two forms. If the failed frame was being relayed as a result of a request from the 33
next higher layer, then the NWK layer shall issue an NLDE-DATA.confirm with 34
the error to the next higher layer. The value of the NetworkAddr parameter of the 35
primitive shall be the intended destination of the frame. If the frame was being 36
relayed on behalf of another device, then the relaying device shall send a network 37
status command frame back to the source of the frame. The destination address 38
field of the network status command frame shall be taken from the destination 39
address field of the failed data frame. 40
41
In either case, the reasons for failure that may be reported appear in Table 3.42.
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
392 Network Specification
If nwkAddrAlloc has a value of 0x00, neighbor table entries for relatives should
not be considered stale and reused. 1
2
3.6.3.5 Route Discovery 3
4
Route discovery is the procedure whereby network devices cooperate to find and 5
establish routes through the NWK. Unicast route discovery is always performed 6
with regard to a particular source device and a particular destination device. 7
Multicast route discovery is performed with respect to a particular source device 8
and a multicast group. Many-to-one route discovery is performed by a source 9
device to establish routes to itself from all ZigBee routers and ZigBee coordinator, 10
within a given radius. A source device that initiates a many-to-one route discovery 11
is designated as a concentrator and referred to as such in this document. 12
Throughout sub-clause 3.6.3.5 a destination address may be a 16-bit broadcast 13
address, the 16-bit network address of a particular device, or a 16-bit multicast 14
address, also known as a multicast group ID. A route request command whose 15
destination address is the routing address of a particular device and whose route 16
request option field does not have the multicast bit set, is a unicast route request. 17
A route request command whose route request option field has the multicast bit 18
set is a multicast route request. The destination address field of a multicast route 19
request shall be a multicast group ID. A route request command payload whose 20
destination address sub-field is a broadcast address (see Table 3.54) is a many-to- 21
one route request. The multicast bit in the route request option field of a many-to- 22
one route request shall be set to 0. 23
3.6.3.5.1 Initiation of Route Discovery 24
25
The unicast route discovery procedure for a device shall be initiated on a ZigBee 26
router or ZigBee coordinator by the NWK layer up on receipt of an NLME- 27
ROUTE-DISCOVERY.request primitive from the next higher layer where the 28
DstAddrMode parameter has a value of 0x02. Or, up on receipt of an NLDE- 29
DATA.request primitive from a higher layer with the DstAddrMode set to 0x02 30
and the discover route sub-field set to 0x01, for which there is no routing table 31
entry corresponding to the routing address of the destination device (the 16-bit 32
network address indicated by the DstAddr parameter). Or, on receipt of a frame 33
from the MAC sub-layer for which the value of the destination address field in the 34
NWK header is not the address of the current device, the address of an end device 35
child of the current device, or a broadcast address and: 36
• The discover route sub-field of the frame control field has a value of 0x01, and 37
38
• there is no routing table entry corresponding to the routing destination of the 39
frame, and 40
• either the value of the source address field of the NWK header of the received 41
frame is the same as the 16-bit network address of one of the end device 42
children of the current device, or 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 395
children is the destination of the route request command frame, it shall reply with
a route reply command frame. When replying to a route request with a route reply 1
command frame, the device shall construct a frame with the frame type field set to 2
0x01. The route reply’s source address shall be set to the 16-bit network address 3
of the device creating the route reply and the destination address shall be set to the 4
calculated next hop address, considering the originator of the route request as the 5
destination. The link cost from the next hop device to the current device shall be 6
computed as described in sub-clause 3.6.3.1 and inserted into the path cost field of 7
the route reply command frame. The route reply command frame shall be unicast 8
to the next hop device by issuing an MCPS-DATA.request primitive. 9
10
If the device is not the destination of the route request command frame, the device 11
shall compute the link cost from the previous device that transmitted the frame, as 12
described in sub-clause 3.6.3.1. This value shall be added to the path cost value 13
stored in the route request command frame. The route request command frame 14
shall then be unicast towards the destination using the MCPS-DATA.request 15
service primitive. The next hop for this unicast transmission is determined in the 16
same manner as if the frame were a data frame addressed to the device identified 17
by the destination address field in the payload. 18
If the device does have routing capacity and the received request is a unicast route 19
request, the device shall check if it is the destination of the command frame by 20
comparing the destination address field of the route request command frame 21
payload with its own address. It shall also check if the destination of the command 22
frame is one of its end device children by comparing the destination address field 23
of the route request command frame payload with the address of each of its end 24
device children, if any. If neither the device nor one of its end device children is 25
the destination of the route request command frame, the device shall determine if 26
a route discovery table (see Table 3.53) entry exists with the same route request 27
identifier and source address field. If no such entry exists, one shall be created. 28
29
If the device does have routing capacity and the multicast sub-field of the route 30
request command options field of the received route request frame indicates a 31
multicast route request, the device shall determine whether an entry already exists 32
in the nwkGroupIDTable for which the group identifier field matches the 33
destination address field of the frame. If a matching entry is found, the device 34
shall determine if a route discovery table (see Table 3.53) entry exists with the 35
same route request identifier and source address field. If no such entry exists, one 36
shall be created. 37
For many-to-one route requests, and for regular route requests if the nwkSymLink 38
parameter is TRUE, upon receipt of a route request command frame, the neighbor 39
table is searched for an entry corresponding to the transmitting device. If no such 40
entry is found, or if the outgoing cost field of the entry has a value of 0, the frame 41
is discarded and route request processing is terminated. The maximum of the 42
incoming and outgoing costs for the neighbor is used for the purposes of the path 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
398 Network Specification
cost calculation, instead of the incoming cost. This includes the value used to
increment the path cost field of the route request frame prior to retransmission. 1
2
When creating the route discovery table entry, the fields are set to the 3
corresponding values in the route request command frame. The only exception is 4
the forward cost field, which is determined by using the previous sender of the 5
command frame to compute the link cost, as described in sub-clause 3.6.3.1, and 6
adding it to the path cost contained the route request command frame. The result 7
of the above calculation is stored in the forward cost field of the newly created 8
route discovery table entry. If the nwkSymLink attribute is set to TRUE, the device 9
shall also create a routing table entry with the destination address field set to the 10
source address of the route request command frame and the next hop field set to 11
the address of the previous device that transmitted the command frame. The status 12
field shall be set to ACTIVE. The device shall then issue a route reply command 13
frame to the source of the route request command frame. In the case that the 14
device already has a route discovery table entry for the source address and route 15
request identifier pair, the device shall determine if the path cost in the route 16
request command frame is less than the forward cost stored in the route discovery 17
table entry. The comparison is made by first computing the link cost from the 18
previous device that sent this frame, as described in sub-clause 3.6.3.1, then 19
adding it to the path cost value in the route request command frame. If this value 20
is greater than the value in the route discovery table entry, the frame shall be 21
dropped and no further processing is required. Otherwise, the forward cost and 22
sender address fields in the route discovery table are updated with the new cost 23
and the previous device address from the route request command frame. 24
If the nwkSymLink attribute is set to TRUE and the received route request 25
command frame is a unicast route request, the device shall also create a routing 26
table entry with the destination address field set to the source address of the route 27
request command frame and the next hop field set to the address of the previous 28
device that transmitted the command frame. The status field shall be set to 29
ACTIVE. The device shall then respond with a route reply command frame. In 30
either of these cases, if the device is responding on behalf of one of its end device 31
children, the responder address in the route reply command frame payload shall 32
be set equal to the address of the end device child and not of the responding 33
device. 34
35
When a device with routing capacity is not the destination of the received route 36
request command frame, it shall determine if a route discovery table entry (see 37
Table 3.53) exists with the same route request identifier and source address field. 38
If no such entry exists, one shall be created. The route request timer shall be set to 39
expire in nwkcRouteDiscoveryTime milliseconds. If a routing table entry 40
corresponding to the routing address of the destination exists and its status is not 41
ACTIVE or VALIDATION_UNDERWAY, the status shall be set to 42
DISCOVERY_UNDERWAY. If no such entry exists and the frame is a unicast 43
route request, an entry shall be created and its status set to 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 399
frames arriving with lower path cost. The NWK layer shall retry the broadcast
nwkcRREQRetries times after the original relay resulting in a maximum of 1
nwkcRREQRetries + 1 relays per relay attempt. Implementers may choose to 2
discard route request command frames awaiting retransmission in the case that a 3
frame with the same source and route request identifier arrives with a lower path 4
cost than the one awaiting retransmission. 5
6
The device shall also set the status field of the routing table entry corresponding to 7
the routing address of the destination field in the payload to 8
DISCOVERY_UNDERWAY. If no such entry exists, it shall be created. 9
When replying to a route request with a route reply command frame, a device that 10
has a route discovery table entry corresponding to the source address and route 11
request identifier of the route request shall construct a command frame with the 12
frame type field set to 0x01. The source address field of the NWK header shall be 13
set to the 16-bit network address of the current device and the destination address 14
field shall be set to the value of the sender address field from the corresponding 15
route discovery table entry. The device constructing the route reply shall populate 16
the payload fields in the following manner. 17
18
• The NWK command identifier shall be set to route reply. 19
• The route request identifier field shall be set to the same value found in the 20
route request identifier field of the route request command frame. 21
22
• The originator address field shall be set to the source address in the NWK 23
header of the route request command frame. 24
• Using the sender address field from the route discovery table entry 25
corresponding to the source address in the NWK header of the route request 26
command frame, the device shall compute the link cost as described in sub- 27
clause 3.6.3.1. This link cost shall be entered in the path cost field. 28
29
The route reply command frame is then unicast to the destination by using the 30
MCPS-DATA.request primitive and the sender address obtained from the route 31
discovery table as the next hop. 32
3.6.3.5.3 Upon Receipt of a Route Reply Command Frame 33
34
On receipt of a route reply command frame, a device shall perform the following 35
procedure. 36
If the receiving device has no routing capacity and its NIB attribute 37
nwkUseTreeRouting has a value of TRUE, it shall send the route reply as though it 38
were a data frame being forwarded using tree routing. If the receiving device has 39
no routing capacity and its NIB attribute nwkUseTreeRouting has a value of 40
FALSE, it shall discard the command frame. Before forwarding the route reply 41
command frame the device shall update the path cost field in the payload by 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 401
computing the link cost from the next hop device to itself as described in sub-
clause 3.6.3.1 and adding this to the value in the route reply path cost field. 1
2
If the receiving device has routing capacity, it shall check whether it is the 3
destination of the route reply command frame by comparing the contents of the 4
originator address field of the command frame payload with its own address. If it 5
is, it shall search its route discovery table for an entry corresponding to the route 6
request identifier in the route reply command frame payload. If there is no such 7
entry, the route reply command frame shall be discarded and route reply 8
processing shall be terminated. If a route discovery table entry exists, the device 9
shall search its routing table for an entry with a destination address field equal to 10
the routing address corresponding to the responder address in the route reply 11
command frame. If there is no such routing table entry, the route reply command 12
frame shall be discarded and, if a route discovery table entry corresponding to the 13
route request identifier in the route reply command frame exists, it shall also be 14
removed and route reply processing shall be terminated. If a routing table entry 15
and a route discovery table entry exist and if the status field of the routing table 16
entry is set to DISCOVERY_UNDERWAY, it shall be changed to 17
VALIDATION_UNDERWAY if the routing table entry’s GroupId flag is TRUE or 18
to ACTIVE otherwise; the next hop field in the routing table shall be set to the 19
previous device that forwarded the route reply command frame. The residual cost 20
field in the route discovery table entry shall be set to the path cost field in the route 21
reply payload. 22
If the status field was already set to ACTIVE or VALIDATION_UNDERWAY, the 23
device shall compare the path cost in the route reply command frame to the 24
residual cost recorded in the route discovery table entry, and update the residual 25
cost field and next hop field in the routing table entry if the cost in the route reply 26
command frame is smaller. If the path cost in the route reply is not smaller, the 27
route reply shall be discarded and no further processing shall take place. 28
29
If the device receiving the route reply is not the destination, the device shall find 30
the route discovery table entry corresponding to the originator address and route 31
request identifier in the route reply command frame payload. If no such route 32
discovery table entry exists, the route reply command frame shall be discarded. If 33
a route discovery table entry exists, the path cost value in the route reply 34
command frame and the residual cost field in the route discovery table entry shall 35
be compared. If the route discovery table entry value is less than the route reply 36
value, the route reply command frame shall be discarded. 37
Otherwise, the device shall find the routing table entry with a destination address 38
field equal to the routing address corresponding to the responder address in the 39
route reply command frame. In this case, it is an error if the route discovery table 40
entry exists and there is no corresponding routing table entry, and the route reply 41
command frame should be discarded. The routing table entry shall be updated by 42
replacing the next hop field with the address of the previous device that forwarded 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
402 Network Specification
the route reply command frame. The route discovery table entry shall also be
updated by replacing the residual cost field with the value in the route reply 1
command frame. 2
3
Whenever the receipt of a route reply causes the next hop field of the 4
corresponding routing table entry to be modified, and the routing table entry's 5
GroupId flag is TRUE, the device shall set the expiration time field of the 6
corresponding route discovery table entry to expire in nwkcWaitBeforeValidation 7
milliseconds if the device is the destination of the route reply and 8
nwkcRouteDiscoveryTime milliseconds if it is not. 9
After updating its own route entry, the device shall forward the route reply to the 10
destination. Before forwarding the route reply, the path cost value shall be 11
updated. The sender shall find the next hop to the route reply’s destination by 12
searching its route discovery table for the entry matching the route request 13
identifier and the source address and extracting the sender address. It shall use this 14
next hop address to compute the link cost as described in sub-clause 3.6.3.1. This 15
cost shall be added to the path cost field in the route reply. The destination address 16
in the command frame NWK header shall be set to the next hop address and the 17
frame shall be unicast to the next hop device using the MCPS-DATA.request 18
primitive.The DstAddr parameter of the MCPS-DATA.request primitive shall be 19
set to the next-hop address from the route discovery table. 20
21
If the value of the nwkSymLink attribute of the NIB has a value of TRUE, the 22
NWK layer shall, upon relaying the route reply command frame, also create a 23
reverse routing table entry if such an entry does not yet exist. The value of the 24
destination address field of the routing table entry shall correspond to the value of 25
the originator address field of the route reply command frame. The status field 26
shall have a value of ACTIVE. The next-hop address field shall have a value 27
corresponding to the next hop address in the route reply command being relayed, 28
as determined in the previous paragraph. If the reverse routing table entry already 29
exists the next-hop address field shall be updated, if necessary. 30
3.6.3.5.4 Initiation and Processing of a Route Record Command Frame 31
32
If the NWK layer of a ZigBee router or ZigBee coordinator is initiating a unicast 33
data frame as a result of an NLDE-DATA.request from the next higher layer and 34
the many-to-one field of the routing table entry corresponding to the destination 35
address of the frame has a value of TRUE, then the NWK layer shall examine the 36
route record required field of that same routing table entry. If the route record 37
required field also has a value of TRUE, the NWK shall unicast a route record 38
command to the destination before transmitting the data frame. 39
If the NWK layer of a ZigBee router or ZigBee coordinator is forwarding a 40
unicast data frame on behalf of one of its end device children and the many-to-one 41
field of the destination’s routing table entry has a value of TRUE, then the device 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 403
shall unicast a route record command to the destination before relaying the data
frame. 1
2
An optional optimization is possible in which the router or coordinator may keep 3
track of which of its end device children have received source routed data frames 4
from a particular concentrator device and can thereby reduce the number of route 5
record commands it transmits to that concentrator on behalf of its end device 6
children. 7
Each relay node that receives the route record command shall append its network 8
address to the command payload, increment the relay count, and forward the 9
message. If no next hop is available, or if delivery to the next hop fails, or if there 10
is insufficient space in the payload for the network address, the command frame 11
shall be discarded and no error command shall be generated. 12
13
Upon receipt of the route record command by the destination, the route shall be 14
stored in the source route table. Any existing source routes to the message source 15
or intermediary nodes shall be replaced by the new route information. 16
17
3.6.3.6 Upon Expiration of a Route Discovery Table Entry 18
When a route discovery table entry is created, the expiration timer shall be set to 19
expire in nwkcRouteDiscoveryTime milliseconds. For entries whose GroupId flag 20
in the corresponding entry in the routing table is TRUE, when a route reply is 21
received that causes the next hop to change, the expiration time field of the 22
corresponding route discovery table entry is set to expire in 23
nwkcWaitBeforeValidation milliseconds if the device is the destination of the route 24
reply and nwkcRouteDiscoveryTime milliseconds if it is not. When the timer 25
expires, the device shall delete the entry from the route discovery table. If the 26
device is the originator of the route request and the routing table entry 27
corresponding to the destination address has a Status field value of 28
VALIDATION_UNDERWAY, then the device shall transmit a message to validate 29
the route: either the message-buffered pending route discovery or a network status 30
command with a status code of 0x0a (validate route). If the routing table entry 31
corresponding to the destination address has any Status field value other than 32
ACTIVE or VALIDATION_UNDERWAY and there are no other entries in the 33
route discovery table corresponding to that routing table entry, the routing table 34
entry shall also be deleted. 35
36
3.6.3.7 Route Maintenance 37
38
A device NWK layer shall maintain a failure counter for each neighbor to which it 39
has an outgoing link, i.e., to which it has been required to send data frames. If the 40
outgoing link is classified as a failed link, then the device shall respond as 41
described in the following paragraphs. Implementers may choose a simple failure- 42
counting scheme to generate this failure counter value or they may use a more 43
accurate time-windowed scheme. Note that it is important not to initiate repair too 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
404 Network Specification
frequently since repair operations may flood the network and cause other traffic
disruptions. The procedure for retiring links and ceasing to keep track of their 1
failure counter is out of the scope of this specification. 2
3
3.6.3.7.1 In Case of Link Failure 4
If a failed link is encountered while a device is forwarding a unicast data frame 5
using a routing table entry with the many-to-one field set to TRUE, a network 6
status command frame with status code of 0x0c indicating many-to-one route 7
failure shall be generated. The destination address field in the NWK header of the 8
network status command frame shall be equal to the destination address field in 9
the NWK header of the frame causing the error. The destination address field of 10
the network status command payload shall be equal to the source address field in 11
the NWK header of the frame causing the error. The network status command 12
frame shall be unicast to a random router neighbor using the MCPS- 13
DATA.request primitive. Because it is a many-to-one route, all neighbors are 14
expected to have a routing table entry to the destination. Upon receipt of the 15
network status command frame, if no routing table entry for the destination is 16
present, or if delivery of the network status command frame to the next hop in the 17
routing table entry fails, the network status command frame shall again be unicast 18
to a random router neighbor using the MCPS-DATA.request primitive. The radius 19
counter in the NWK header will limit the maximum number of times the network 20
status command frame is relayed. Upon receipt of the network status command 21
frame by its destination it shall be passed up to the next higher layer using the 22
NLME-NWK-STATUS.indication primitive. Many-to-one routes are not 23
automatically rediscovered by the NWK layer due to route errors. 24
25
If a failed link is encountered while the device is forwarding a unicast frame using 26
normal unicast routing, the device shall issue a network status command frame 27
back to the source device of the frame with a status code indicating the reason for 28
the failure (see Table 3.42), and issue an NLME-NWK-STATUS.indication to the 29
next higher layer with a status code indicating the reason for the failure. 30
On receipt of a network status command frame by a router that is the intended 31
destination of the command where the status code field of the command frame 32
payload has a value of 0x01 or 0x02 indicating a link failure, the NWK layer will 33
remove the routing table entry corresponding to the value of the destination 34
address field of the command frame payload, if one exists, and inform the next 35
higher layer of the failure using the NLME-NWK-STATUS.indication using the 36
same status code. 37
38
On receipt of a network status command frame by a router that is the parent of an 39
end device that is the intended destination, where the status code field of the 40
command frame payload has a value of 0x01 or 0x02 indicating a link failure, the 41
NWK layer will remove the routing table entry corresponding to the value of the 42
destination address field of the command frame payload, if one exists. It will then 43
relay the frame as usual to the end device. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 405
On receipt of a network status command frame by an end device, the NWK layer
shall inform the next higher layer of the failure using the NLME-NWK- 1
STATUS.indication. 2
3
If an end device encounters a failed link to its parent, the end device shall inform 4
the next higher layer using the NLME-NWK-STATUS.indication primitive with a 5
Status parameter value of 0x09 indicating parent link failure (see Table 3.42). 6
Similarly if a ZigBee router without routing capacity for which 7
nwkUseTreeRouting has a value of TRUE encounters a failed link to its parent, it 8
shall inform the next higher layer using the NLME-NWK-STATUS.indication 9
primitive with a Status parameter value of 0x09 indicating parent link failure. 10
11
3.6.4 Scheduling Beacon Transmissions 12
13
Beacon scheduling is necessary in a multi-hop topology to prevent the beacon 14
frames of one device from colliding with either the beacon frames or the data 15
transmissions of its neighboring devices. Beacon scheduling is necessary when 16
implementing a tree topology but not a mesh topology, as beaconing is not 17
permitted in ZigBee mesh networks. 18
19
3.6.4.1 Scheduling Method 20
21
The ZigBee coordinator shall determine the beacon order and superframe order 22
for every device in the network (see [B1] for more information on these 23
attributes). Because one purpose of multi-hop beaconing networks is to allow 24
routing nodes the opportunity to sleep in order to conserve power, the beacon 25
order shall be set much larger than the superframe order. Setting the attributes in 26
this manner makes it possible to schedule the active portion of the superframes of 27
every device in any neighborhood such that they are non-overlapping in time. In 28
other words, time is divided into approximately (macBeaconInterval/ 29
macSuperframeDuration) non-overlapping time slots, and the active portion of 30
the superframe of every device in the network shall occupy one of these non- 31
overlapping time slots. An example of the resulting frame structure for a single 32
beaconing device is shown in Figure 3.46. 33
34
Beacon Interval 35
Beacon CAP 36
37
38
39
Inactive Period
40
41
Superframe
Duration 42
43
Figure 3.46 Typical Frame Structure for a Beaconing Device 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
406 Network Specification
The beacon frame of a device shall be transmitted at the start of its non-
overlapping time slot, and the transmit time shall be measured relative to the 1
beacon transmit time of the parent device. This time offset shall be included in the 2
beacon payload of every device in a multi-hop beaconing network (see sub- 3
clause 3.6.7 for a complete list of beacon payload parameters). Therefore a device 4
receiving a beacon frame shall know the beacon transmission time of both the 5
neighboring device and the parent of the neighboring device, since the 6
transmission time of the parent may be calculated by subtracting the time offset 7
from the timestamp of the beacon frame. The receiving device shall store both the 8
local timestamp of the beacon frame and the offset included in the beacon payload 9
in its neighbor table. The purpose of having a device know when the parent of its 10
neighbor is active is to maintain the integrity of the parent-child communication 11
link by alleviating the hidden node problem. In other words, a device will never 12
transmit at the same time as the parent of its neighbor. 13
14
Communication in a tree network shall be accomplished using the parent-child 15
links to route along the tree. Since every child tracks the beacon of its parent, 16
transmissions from a parent to its child shall be completed using the indirect 17
transmission technique. Transmissions from a child to its parent shall be 18
completed during the CAP of the parent. Details for the communication 19
procedures can be found in IEEE 802.15.4-2003 [B1]. 20
A new device wishing to join the network shall follow the procedure outlined in 21
sub-clause 3.6.1.4. In the process of joining the network, the new device shall 22
build its neighbor table based on the information collected during the MAC scan 23
procedure. Using this information, the new device shall choose an appropriate 24
time for its beacon transmission and CAP (the active portion of its superframe 25
structure) such that the active portion of its superframe structure does not overlap 26
with that of any neighbor or of the parent of any neighbor. If there is no available 27
non-overlapping time slot in the neighborhood, the device shall not transmit 28
beacons and shall operate on the network as an end device. If a non-overlapping 29
time slot is available, the time offset between the beacon frames of the parent and 30
the new device shall be chosen and included in the beacon payload of the new 31
device. Any algorithm for selecting the beacon transmission time that avoids 32
beacon transmission during the active portion of the superframes of its neighbors 33
and their parents may be employed, as interoperability will be ensured. 34
35
To counteract drift, the new device shall track the beacon of its parent and adjust 36
its own beacon transmission time such that the time offset between the two 37
remains constant. Therefore, the beacon frames of every device in the network are 38
essentially synchronized with those of the ZigBee coordinator. Figure 3.47 39
illustrates the relationship between the active superframe portions of a parent and 40
its child. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 407
1
2
3
4
5
Beacon Tracking
6
7
8
9
10
Beacon 11
Tx Offset 12
Figure 3.47 Parent-Child Superframe Positioning Relationship 13
14
The density of devices that can be supported in the network is inversely 15
proportional to the ratio of the superframe order to the beacon order. The smaller 16
the ratio, the longer the inactive period of each device and the more devices that 17
can transmit beacon frames in the same neighborhood. It is recommended that a 18
tree network utilize a superframe order of 0, which, when operating in the 19
2.4 GHz band, gives a superframe duration of 15.36 ms and a beacon order of 20
between 6 and 10, which, in the 2.4 GHz band, gives a beacon interval between 21
0.98304s and 15.72864s. Using these superframe and beacon order values, a 22
typical duty cycle for devices in the network will be between ~2% and ~0.1% 23
regardless of the frequency band. 24
25
26
3.6.5 Broadcast Communication 27
28
This sub-clause specifies how a broadcast transmission is accomplished within a 29
ZigBee network. Any device within a network may initiate a broadcast 30
transmission intended for a number of other devices that are part of the same 31
network. A broadcast transmission is initiated by the local APS sub-layer entity 32
through the use of the NLDE-DATA.request primitive by setting the DstAddr 33
parameter to a broadcast address as shown in Table 3.54, or by the NWK layer 34
through the use of these same broadcast addresses in the construction of an 35
outgoing NWK header. 36
Table 3.54 Broadcast Addresses 37
38
Broadcast Address Destination Group 39
0xffff All devices in PAN 40
0xfffe Reserved 41
42
0xfffd macRxOnWhenIdle = TRUE
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
408 Network Specification
outlined in Table 3.54, the frame shall be discarded. If the destination address
corresponds to the device type of the receiver, the device shall compare the 1
sequence number and the source address of the broadcast frame with the records 2
in its BTT. 3
4
If the device has a BTR of this particular broadcast frame in its BTT, it may 5
update the BTR to mark the neighboring device as having relayed the broadcast 6
frame. It shall then drop the frame. If no record is found, it shall create a new BTR 7
in its BTT and may mark the neighboring device as having relayed the broadcast. 8
The NWK layer shall then indicate to the higher layer that a new broadcast frame 9
has been received using the NLDE-DATA.indication. If the radius field value is 10
greater than 0 or if the device is not a ZigBee End Device then it shall retransmit 11
the frame. Otherwise, it shall drop the frame. Before the retransmission, it shall 12
wait for a random time period called broadcast jitter. This time period shall be 13
bounded by the value of the nwkcMaxBroadcastJitter attribute. ZigBee end 14
devices with macRxOnWhenIdle equal to FALSE shall not participate in the 15
relaying of broadcast frames and need not maintain a BTT for broadcast frames 16
that they originate. 17
If, on receipt of a broadcast frame, the NWK layer finds that the BTT is full and 18
contains no expired entries, then the frame should be dropped. In this situation the 19
frame should not be retransmitted, nor should it be passed up to the next higher 20
layer. 21
22
A ZigBee coordinator or ZigBee router operating in a non-beacon-enabled ZigBee 23
network shall retransmit a previously broadcast frame at most 24
nwkMaxBroadcastRetries times. If the device does not support passive 25
acknowledgement, then it shall retransmit the frame exactly 26
nwkMaxBroadcastRetries times. If the device supports passive acknowledgement 27
and any of its neighboring devices have not relayed the broadcast frame within 28
nwkPassiveAckTimeout seconds then it shall continue to retransmit the frame up 29
to a maximum of nwkMaxBroadcastRetries times. 30
A device should change the status of a BTT entry after 31
nwkNetworkBroadcastDeliveryTime seconds have elapsed since its creation. The 32
entry status should change to expired and thus the entry can be overwritten if 33
required when a new broadcast is received. 34
35
When a ZigBee router that has the macRxOnWhenIdle MAC PIB attribute set to 36
FALSE receives a broadcast transmission, it shall use a different procedure for 37
retransmission than the one outlined above. It shall retransmit the frame without 38
delay to each of its neighbors individually, using a MAC layer unicast, that is, 39
with the DstAddr parameter of the MCPS-DATA.request primitive set to the 40
address of each neighbor device and not to the broadcast address. Similarly, a 41
router or coordinator with the macRxOnWhenIdle MAC PIB attribute set to 42
TRUE, which has one or more neighbors with the macRxOnWhenIdle MAC PIB 43
parameter set to FALSE, shall, in the case where the destination address is 0xffff 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
410 Network Specification
denoting broadcast to all devices, retransmit the broadcast frame to each of these
neighbors in turn as a MAC layer unicast in addition to performing the more 1
general broadcast procedure spelled out in the previous paragraphs. Indirect 2
transmission, as described in IEEE 802.15.4-2003 [B1], may be employed to 3
ensure that these unicasts reach their destination. 4
5
Every ZigBee router shall have the ability to buffer at least 1 frame at the NWK 6
layer in order to facilitate retransmission of broadcasts. 7
Figure 3.48 shows a broadcast transaction between a device and two neighboring 8
devices. 9
10
11
MAC Broadcast Transmission
12
Add new BTR
Mark Neighbor 1 as having 13
14
relayed the message
15
Broadcast
Jitter
16
17
18
19
MAC Broadcast Transmission MAC Broadcast Transmission MAC Broadcast Transmission
that group. Only data frames are multicast — no NWK command frames are
multicast. 1
2
Multicast frames are propagated through the network by both members and non- 3
members of the destination multicast group. A packet may be sent in one of two 4
modes as indicated by a mode flag in the packet which determines the method of 5
relay to the next hop. If the original message was created by a member of the 6
group, it is considered to be in ‘Member Mode’ and is relayed by means of 7
broadcasts. If the original message was created by a non-member of the group, it 8
is considered to be in ‘Non-Member Mode’ and is relayed by means of unicasts 9
towards a group member. Once a non-member message reaches any member of 10
the destination group, it is instantly transformed into a Member Mode type relay 11
for the duration of the life of the packet regardless of who relays it next. 12
Multicast messages may be originated by end devices but are not sent to devices 13
where macRxOnWhenIdle is equal to FALSE. 14
15
3.6.6.1 The Group ID Table 16
17
The NWK layer of a device may maintain a group ID table, nwkGroupIDTable, 18
accessible as an attribute of the NIB as shown in Table 3.44. If the 19
nwkGroupIDTable NIB attribute is present then it shall contain a set of 16-bit 20
group identifiers for groups of which the device is a member. 21
Note that the optional nwkGroupIDTable NIB attribute has a functional overlap 22
with the mandatory APS group table (see Table 2.18). If a device maintains both 23
tables, and thereby expects to use NWK-layer multicast as a method for receiving 24
group-addressed frames, it must assure that each 16-bit group identifiers that 25
appears in the APS group table also appears in the NWK group table. 26
27
Note also that from an implementation perspective, it would be wasteful to 28
duplicate the list of group identifiers across layers and it is assumed that 29
implementers will find a way to combine the APS and NWK group tables to avoid 30
waste. 31
32
3.6.6.2 Upon Receipt of a Multicast Frame from the Next 33
Higher Layer 34
35
If an NLDE-DATA.request is received by the NWK layer from its next higher 36
layer and the multicast control field is 0x01, the NWK layer shall determine 37
whether an entry exists in the nwkGroupIDTable having a group identifier field 38
matching the destination address of the frame. If a matching entry is found, the 39
NWK layer shall multicast the frame according to the procedure outlined in sub- 40
clause 3.6.6.2.1. If a matching entry is not found, the frame shall be initiated as a 41
non-member mode multicast using the procedure outlined in sub-clause 3.6.6.2.2. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
412 Network Specification
the nwkGroupIDTable whose group identifier field matches the destination group
ID of the frame. If a matching entry is found, the message shall be passed to the 1
next higher layer, the multicast mode sub-field of the multicast control field shall 2
be set to 0x01 (member mode), the value of the NonmemberRadius sub-field shall 3
be set to the value of the MaxNonmemberRadius sub-field in the multicast control 4
field, and the message shall be transmitted as outlined in the following paragraph. 5
6
If a matching entry is not found, the NWK layer shall examine the frame's 7
multicast NonmemberRadius field. If the value of the NonmemberRadius sub- 8
field of the multicast field is 0 the message shall be discarded, along with the 9
newly added BTR. Otherwise, the NonmemberRadius sub-field shall be 10
decremented if it is less than 0x07 and the frame shall be transmitted as outlined in 11
following paragraphs. 12
Each member mode multicast message shall be transmitted 13
nwkMaxBroadcastRetries times. For member mode multicast frames that did not 14
originate on the local device, the initial transmission shall be delayed by a random 15
time bounded by the value of the nwkcMaxBroadcastJitter attribute. A device 16
shall delay a period of nwkPassiveAckTimeout seconds between retransmissions 17
of a particular member mode multicast message. Unlike broadcasts, there is no 18
passive acknowledgement for multicasts. ZigBee end devices shall not participate 19
in the relaying of multicast frames. 20
21
To transmit a member mode multicast MSDU, the NWK layer issues an MCPS- 22
DATA.request primitive to the MAC sub-layer with the DstAddrMode parameter 23
set to 0x02 (16-bit network address) and the DstAddr parameter set to 0xffff, 24
which is the broadcast network address. The PANId parameter shall be set to the 25
PANId of the ZigBee network. Member mode multicast transmissions shall not 26
use the MAC sub-layer acknowledgement or the passive acknowledgement used 27
for broadcasts. The MAC sub-layer acknowledgement is disabled by setting the 28
acknowledged transmission flag of the TxOptions parameter to FALSE. All other 29
flags of the TxOptions parameter shall be set based on the network configuration. 30
31
3.6.6.4 Upon Receipt of a Non-Member Mode Multicast 32
Frame 33
34
When a device receives a non-member mode multicast frame from a neighboring 35
device, the NWK layer shall determine whether an entry exists in the 36
nwkGroupIDTable having a group identifier field that matches the destination 37
address of the frame. If a matching entry is found, the multicast control field shall 38
be set to 0x01 (member mode) and the message shall be processed as if it had been 39
received as a member mode multicast. If no matching nwkGroupIDTable entry is 40
found, the device shall check its routing table for an entry corresponding to the 41
GroupID destination of the frame. If there is no such routing table entry, the 42
message shall be discarded. If there is such an entry, the NWK layer shall examine 43
the entry's status field. If the status is ACTIVE, the device shall (re)transmit the 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
414 Network Specification
LPR devices should be able to receive network command frames that are
broadcast in the network. This can be achieved by setting the destination address 1
in the NWK header to the broadcast address for all routers and coordinators (see 2
Table 3.54). 3
4
5
3.7 NWK Layer Status Values 6
7
Network (NWK) layer confirmation primitives often include a parameter that 8
reports on the status of the request to which the confirmation applies. Values for 9
NWK layer Status parameters appear in Table 3.57. 10
11
12
Table 3.57 NWK Layer Status Values 13
14
Name Value Description 15
SUCCESS 0x00 A request has been executed successfully. 16
17
INVALID_PARAMETER 0xc1 An invalid or out-of-range parameter has been
passed to a primitive from the next higher layer.
18
19
INVALID_REQUEST 0xc2 The next higher layer has issued a request that is 20
invalid or cannot be executed given the current
state of the NWK layer. 21
22
NOT_PERMITTED 0xc3 An NLME-JOIN.request has been disallowed.
23
STARTUP_FAILURE 0xc4 An NLME-NETWORK-FORMATION.request 24
has failed to start a network. 25
ALREADY_PRESENT 0xc5 A device with the address supplied to the NLME- 26
DIRECT-JOIN.request is already present in the 27
neighbor table of the device on which the NLME- 28
DIRECT-JOIN.request was issued.
29
SYNC_FAILURE 0xc6 Used to indicate that an NLME-SYNC.request has 30
failed at the MAC layer.
31
NEIGHBOR_TABLE_FULL 0xc7 An NLME-JOIN-DIRECTLY.request has failed 32
because there is no more room in the neighbor 33
table.
34
UNKNOWN_DEVICE 0xc8 An NLME-LEAVE.request has failed because the 35
device addressed in the parameter list is not in the
neighbor table of the issuing device.
36
37
UNSUPPORTED_ 0xc9 An NLME-GET.request or NLME-SET.request 38
ATTRIBUTE has been issued with an unknown attribute
identifier. 39
40
NO_NETWORKS 0xca An NLME-JOIN.request has been issued in an
environment where no networks are detectable.
41
42
Reserved 0xcb 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
418 Network Specification
C H A P T E R
1
4
2
3
4
5
6
7
8
9
In summary:
1
• The provided security services cryptographically protect the interfaces between 2
different devices only. 3
• Separation of the interfaces between different stack layers on the same device 4
is arranged non-cryptographically, via proper design of security service access 5
points. 6
7
4.2.1.2 Security Design Choices 8
9
The open trust model (as described in sub-clause 4.2.1.1) on a device has far- 10
reaching consequences. It allows re-use of the same keying material among 11
different layers on the same device and it allows end-to-end security to be realized 12
on a device-to-device basis rather than between pairs of particular layers (or even 13
pairs of applications) on two communicating devices. 14
However, one must also take into consideration whether one is concerned with the 15
ability of malevolent network devices to use the network to transport frames 16
across the network without permission. 17
18
These observations lead to the following architectural design choices: 19
• First, the principle that “the layer that originates a frame is responsible for 20
initially securing it” is established. For example, if a NWK command frame 21
needs protection, NWK layer security shall be used. 22
23
• Second, if protection from theft of service is required (i.e., from malevolent 24
network devices), NWK layer security shall be used for all frames, except those 25
passed between a router and a newly joined device (until the newly joined 26
device receives the active network key). Thus, only a device that has joined the 27
network and successfully received the active network key will be able to have 28
its messages communicated more than one hop across the network. 29
• Third, due to the open trust model, security can be based on the reuse of keys 30
by each layer. For example, the active network key shall be used to secure APS 31
layer broadcast frames or NWK layer frames. Reuse of keys helps reduce 32
storage costs. 33
34
• Fourth, end-to-end security is enabled such that it is possible for only source 35
and destination devices to access their shared key. This limits the trust 36
requirement to those devices whose information is at stake. Additionally, it 37
ensures that routing of messages between devices can be realized independent 38
of trust considerations (thus if security is used, facilitating considerable 39
separation of concern). 40
• Fifth, to simplify interoperability of devices, the security level used by all 41
devices in a given network, and by all layers of a device, shall be the same. If 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
422 Security Services Specification
an application needs more security for its payload than is provided by a given
network, it shall form its own separate network with a higher security level. 1
2
There are several policy decisions which any real implementation must address 3
correctly. Application profiles should include policies to: 4
• Handle error conditions arising from securing and unsecuring packets. Some 5
error conditions may indicate loss of synchronization of security material, or 6
may indicate ongoing attacks. 7
8
• Detect and handle loss of counter synchronization and counter overflow. 9
• Detect and handle loss of key synchronization. 10
11
• Expire and periodically update keys, if desired. 12
13
4.2.1.3 Security Keys 14
Security amongst a network of ZigBee devices is based on “link” keys and a 15
“network” key. Unicast communication between APL peer entities is secured by 16
means of a 128-bit link key shared by two devices, while broadcast 17
communications are secured by means of a 128-bit network key shared amongst 18
all devices in the network. The intended recipient is always aware of the exact 19
security arrangement; that is, the recipient knows whether a frame is protected 20
with a link key or a network key. 21
22
A device shall acquire link keys either via key-transport, key-establishment, or 23
pre-installation (for example, during factory installation). A device shall acquire a 24
network key via key-transport or pre-installation. The key-establishment 25
technique for acquiring a link key (see sub-clause 4.2.3.1) is based on a “master” 26
key. A device shall acquire a master key (for purposes of establishing 27
corresponding link keys) via key-transport or pre-installation. Ultimately, security 28
between devices depends on secure initialization and installation of these keys. 29
There are two different types of network keys: standard, and high-security. The 30
type controls how a network key is distributed; and may control how network 31
frame counters are initialized. The type does not affect how messages are secured. 32
33
In a secured network there are a variety of security services available. Prudence 34
dictates that one would prefer to avoid re-use of keys across different security 35
services, which otherwise could cause security leaks due to unwanted interactions. 36
As such, these different services use a key derived from a one-way function using 37
the link key (as specified in sub-clause 4.5.3). The use of uncorrelated keys 38
ensures logical separation of the execution of different security protocols. The 39
key-load key is used to protect transported master and link keys; the key-transport 40
key is used to protect transported network keys. The active network key may be 41
used by the NWK and APL layers of ZigBee. As such, the same network key and 42
associated outgoing and incoming frame counters shall be available to all of these 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 423
layers. The link and master keys may be used only by the APS sublayer. As such,
the link and master keys shall be available only to the APL layer. 1
2
4.2.1.4 ZigBee Security Architecture 3
4
The ZigBee security architecture includes security mechanisms at two layers of 5
the protocol stack. The NWK and APS layers are responsible for the secure 6
transport of their respective frames. Furthermore, the APS sublayer provides 7
services for the establishment and maintenance of security relationships. The 8
ZigBee Device Object (ZDO) manages the security policies and the security 9
configuration of a device. Figure 1.1 shows a complete view of the ZigBee 10
protocol stack. The security mechanisms provided by the APS and NWK layers 11
are described in this version of the specification. 12
13
4.2.2 NWK Layer Security 14
15
When a frame originating at the NWK layer needs to be secured, or when a frame 16
originates at a higher layer and the nwkSecureAllFrames attribute in the NIB is 17
TRUE, ZigBee shall use the frame-protection mechanism given in sub- 18
clause 4.3.1 of this specification, unless the SecurityEnable parameter of the 19
NLDE-DATA.request primitive is FALSE, explicitly prohibiting security. The 20
NWK layer's frame-protection mechanism shall make use of the Advanced 21
Encryption Standard (AES) [B8] and use CCM* as specified in Annex A. The 22
security level applied to a NWK frame shall be determined by the 23
nwkSecurityLevel attribute in the NIB. Upper layers manage NWK layer security 24
by setting up active and alternate network keys and by determining which security 25
level to use. 26
27
Figure 4.1 shows an example of the security fields that may be included in a NWK 28
frame. 29
30
Application of security suite adds auxiliary header
31
and also an integrity code 32
33
34
SYNC
PHY MAC NWK Auxiliary
Encrypted NWK Payload MIC 35
HDR HDR HDR HDR 36
37
38
All of the above NWK frame is integrity-protected 39
Figure 4.1 ZigBee Frame with Security on the NWK Level 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
424 Security Services Specification
(child), that field shall be set to the value 0x05 (unauthenticated child). If the
security material cannot be obtained, security processing shall indicate a failure 1
to the next higher layer with a status of 'frame security failed' and no further 2
security processing shall be done on this frame.31 3
4
3 If there is an incoming frame count FrameCount corresponding to 5
SenderAddress from the security material obtained in step 2 and if 6
ReceivedFrameCount is less than FrameCount, security processing shall 7
indicate a failure to the next higher layer with a status of 'bad frame counter' 8
and no further security processing shall be done on this frame.32 9
4 Execute the CCM* mode decryption and authentication checking operation, as 10
specified in sub-clause A.2, with the following instantiations: 11
12
a The parameter M shall be obtained from Table 4.38 corresponding to the 13
security level from step 1. 14
b The bit string Key shall be the key obtained from step 2. 15
16
c The nonce N shall be the 13-octet string constructed using the security 17
control, the frame counter, and the source address fields from 18
AuxiliaryHeader (see sub-clause 4.5.2.2). Note that the security level sub- 19
field of the security control field has been overwritten in step 1 and now 20
contains the value determined from the nwkSecurityLevel attribute from the 21
NIB. 22
d The octet string SecuredPayload shall be parsed as Payload1 || Payload2, 23
where the rightmost string Payload2 is an M-octet string. If this operation 24
fails, security processing shall indicate a failure to the next higher layer with 25
a status of 'frame security failed' and no further security processing shall be 26
done on this frame.33 27
28
e If the security level requires decryption, the octet string a shall be the string 29
NwkHeader || AuxiliaryHeader and the octet string c shall be the string 30
SecuredPayload. Otherwise, the octet string a shall be the string NwkHeader 31
|| AuxiliaryHeader || Payload1 and the octet string c shall be the string 32
Payload2. 33
5 Return the results of the CCM* operation: 34
35
a If the CCM* mode invoked in step 4 outputs ‘invalid’, security processing 36
shall indicate a failure to the next higher layer with a status of 'frame security 37
failed' and no further security processing shall be done on this frame.34 38
39
40
31. CCB #673 41
32. CCB #765 42
33. CCB #673 43
34. CCB #673 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
430 Security Services Specification
b Let m be the output of step 4. If the security level requires encryption, set the
octet string UnsecuredNwkFrame to the string NwkHeader || m. Otherwise, 1
set the octet string UnsecuredNwkFrame to the string NwkHeader || 2
Payload1. 3
4
6 Set FrameCount to (ReceivedFrameCount + 1) and store both FrameCount and 5
SenderAddress in the NIB. UnsecuredNwkFrame now represents the unsecured 6
received network frame and security processing shall succeed. So as to never 7
cause the storage of the frame count and address information to exceed the 8
available memory, the memory allocated for incoming frame counters needed 9
for NWK layer security shall be bounded by M*N, where M and N represent the 10
cardinality of nwkSecurityMaterialSet and nwkNeighborTable in the NIB, 11
respectively. 12
7 If the sequence number of the received frame belongs to a newer entry in the 13
nwkSecurityMaterialSet, set the nwkActiveKeySeqNumber to the received 14
sequence number. 15
16
8 If there is an entry in nwkNeighborTable in the NIB whose extended address 17
matches SenderAddress and whose relationship field has value 0x05 18
(unauthenticated child), then set relationship field in that entry to the value 19
0x01 (child). 20
21
4.3.2 Secured NPDU Frame 22
23
The NWK layer frame format (see sub-clause 3.3.1) consists of a NWK header 24
and NWK payload field. The NWK header consists of frame control and routing 25
fields. When security is applied to an NPDU frame, the security bit in the NWK 26
frame control field shall be set to 1 to indicate the presence of the auxiliary frame 27
header. The format for the auxiliary frame header is given in sub-clause 4.5.1. The 28
format of a secured NWK layer frame is shown in Figure 4.3. The auxiliary frame 29
header is situated between the NWK header and payload fields. 30
31
Octets: Variable 14 Variable 32
33
Original NWK header Auxiliary Encrypted Encrypted message integrity code (MIC)
([B3], Clause 7.1) frame payload 34
header 35
Secure frame payload = output of CCM* 36
Full NWK header Secured NWK payload 37
38
Figure 4.3 Secured NWK Layer Frame Format 39
40
4.3.3 Security-Related NIB Attributes 41
42
The NWK PIB contains attributes that are required to manage security for the 43
NWK layer. Each of these attributes can be read and written using the NLME- 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 431
1
Table 4.2 Elements of the Network Security Material Descriptor
2
Name Type Range Description Default 3
4
KeySeqNumber Octet 0x00-0xFF A sequence number assigned to a 00 5
network key by the Trust Center
and used to distinguish network 6
keys for purposes of key updates, 7
and incoming frame security 8
operations. 9
OutgoingFrame Ordered 0x00000000- Outgoing frame counter used for 0x00000000 10
Counter set of 4 0xFFFFFFF outgoing frames. 11
octets. F 12
IncomingFrame Set of Variable Set of incoming frame counter Null set 13
CounterSet incoming values and corresponding device 14
frame addresses. 15
counter 16
descriptor
values. 17
See Table 18
4.3. 19
Key Ordered - The actual value of the key. -
20
set of 16 21
octets. 22
23
KeyType Octet 0x00 - 0xff The type of the key. 0x01
24
0x01 = standard 25
0x05 = high security 26
27
All other values are reserved.
28
29
30
Table 4.3 Elements of the Incoming Frame Counter Descriptor 31
32
Name Type Range Description Default 33
SenderAddress Device Any valid 64-bit Extended device Device 34
address address address. specific 35
IncomingFrame Ordered set 0x00000000- Incoming frame 0x00000000 36
Counter of 4 octets 0xFFFFFFFF counter used for 37
incoming 38
frames. 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
434 Security Services Specification
2 If KeyIdentifier is 01 (that is, the active network key), the APS layer shall first
verify that the NWK layer is not also applying security. If the NWK layer is 1
applying security, then the APS layer shall not apply any security. The APS 2
layer can determine that the NWK layer is applying security by verifying that 3
the value of the nwkSecureAllFrames attribute of the NIB has a value of TRUE 4
and the nwkSecurityLevel NIB attribute has a non-zero value. 5
6
3 Extract the outgoing frame counter (and, if KeyIdentifier is 01, the key 7
sequence number) from the security material obtained from step 1. If the 8
outgoing frame counter has as its value the 4-octet representation of the integer 9
232-1, or if the key cannot be obtained, security processing shall fail and no 10
further security processing shall be done on this frame. 11
4 Obtain the security level from the nwkSecurityLevel attribute from the NIB. 12
13
5 Construct auxiliary header AuxiliaryHeader (see sub-clause 4.5.1). The 14
security control field shall be set as follows: 15
a The security level sub-field shall be the security level obtained from step 4. 16
17
i The key identifier sub-field shall be set to KeyIdentifier. 18
ii The extended nonce sub-field shall be set to 0. 19
20
b The frame counter field shall be set to the outgoing frame counter from 21
step 3. 22
c If KeyIdentifier is 01, the key sequence number field shall be present and set 23
to the key sequence number from step 3. Otherwise, the key sequence 24
number field shall not be present. 25
26
6 Execute the CCM* mode encryption and authentication operation, as specified 27
in sub-clause A.2, with the following exceptions: 28
a The parameter M shall be obtained from Table 4.38 corresponding to the 29
security level from step 3. 30
31
b The bit string Key shall be the key obtained from step 1. 32
c The nonce N shall be the 13-octet string constructed using the security 33
control and frame counter fields from step 5 and the 64-bit extended address 34
of the local device (see sub-clause 4.5.2.2). 35
36
d If the security level requires encryption, the octet string a shall be the string 37
ApsHeader || AuxiliaryHeader and the octet string m shall be the string 38
Payload. Otherwise, the octet string a shall be the string ApsHeader || 39
AuxiliaryHeader || Payload and the octet string m shall be a string of length 40
zero. 41
7 If the CCM* mode invoked in step 6 outputs “invalid”, security processing 42
shall fail and no further security processing shall be done on this frame. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 437
8 Let c be the output from step 6. If the security level requires encryption, the
secured outgoing frame shall be ApsHeader || AuxiliaryHeader || c, otherwise the 1
secured outgoing frame shall be ApsHeader || AuxiliaryHeader || Payload || c. 2
3
9 If the secured outgoing frame size will result in the MSDU being greater than 4
aMaxMACFrameSize octets (see IEEE Std. 802.15.4 802 [B1]), security 5
processing shall fail and no further security processing shall be done on this 6
frame. 7
10 The outgoing frame counter from step 3 shall be incremented and stored in the 8
appropriate location(s) of the NIB, AIB, and MAC PIB corresponding to the 9
key that was used to protect the outgoing frame. 10
11
11 Over-write the security level sub-field of the security control field with the 3- 12
bit all-zero string '000'. 13
14
4.4.1.2 Security Processing of Incoming Frames 15
If the APS layer receives a secured frame (consisting of a header ApsHeader, 16
auxiliary header AuxiliaryHeader, and payload SecuredPayload) as indicated by 17
the security sub-field of the APS header frame control field it shall perform 18
security processing as follows: 19
20
1 Determine the sequence number SequenceNumber, key identifier KeyIdentifier, 21
and received frame counter value ReceivedFrameCounter from the auxiliary 22
header AuxiliaryHeader. If ReceivedFrameCounter is the 4-octet 23
representation of the integer 232-1, security processing shall fail and no further 24
security processing shall be done on this frame. 25
2 Determine the source address SourceAddress from the address-map table in the 26
NIB, using the source address in the APS frame as the index. If the source 27
address is incomplete or unavailable, security processing shall fail and no 28
further security processing shall be done on this frame. 29
30
3 Obtain the appropriate security material in the following manner. If the security 31
material cannot be obtained, security processing shall fail and no further 32
security processing shall be done on this frame. 33
a If KeyIdentifier is ‘00’ (i.e., a data key), the security material associated with 34
the SourceAddress of the incoming frame shall be obtained from the 35
apsDeviceKeyPairSet attribute in the AIB. 36
37
b If KeyIdentifier is ‘01’ (i.e., a network key), the security material shall be 38
obtained by matching SequenceNumber to the sequence number of any key 39
in the nwkSecurityMaterialSet attribute in the NIB. 40
c If KeyIdentifier is ‘02’ (i.e., a key-transport key), the security material 41
associated with the SourceAddress of the incoming frame shall be obtained 42
from the apsDeviceKeyPairSet attribute in the AIB; the key for this 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
438 Security Services Specification
b Let m be the output of step 6. If the security level requires encryption, set the
octet string UnsecuredApsFrame to the string ApsHeader || m. Otherwise, 1
set the octet string UnsecuredApsFrame to the string ApsHeader || Payload. 2
3
8 Set FrameCount to (ReceivedFrameCount + 1) and store both FrameCount and 4
SourceAddress in the appropriate security material as obtained in step 3. If 5
storing this frame count and address information will cause the memory 6
allocation for this type of information to be exceeded, and the nwkAllFresh 7
attribute in the NIB is TRUE, then security processing shall fail and no further 8
security processing shall be done on this frame. Otherwise, security processing 9
shall succeed. 10
9 If the sequence number of the received frame belongs to a newer entry in the 11
nwkSecurityMaterialSet then the nwkActiveKeySeqNumber shall be set to 12
received sequence number. 13
14
15
4.4.2 Key-Establishment Services 16
17
The APSME provides services that allow two devices to mutually establish a link 18
key. Initial trust information (for example, a master key) must be installed in each 19
device prior to running the key establishment protocol (see sub-clause 4.4.3 for 20
mechanisms to provision initial trust information). 21
22
4.4.2.1 APSME-ESTABLISH-KEY.request 23
The APSME-ESTABLISH-KEY request primitive is used for initiating a key- 24
establishment protocol. This primitive can be used when there is a need to 25
securely communicate with another device. 26
27
One device will act as an initiator device, and the other device will act as the 28
responder. The initiator shall start the key-establishment protocol by issuing: 29
• The APSME-ESTABLISH-KEY.request with parameters indicating the 30
address of the responder device. 31
32
• An indication of which key-establishment protocol to use (currently SKKE). 33
4.4.2.1.1 Semantics of the Service Primitive 34
35
This primitive shall provide the following interface 36
37
APSME-ESTABLISH-KEY.request {
38
ResponderAddress,
39
UseParent, 40
ResponderParentAddress, 41
KeyEstablishmentMethod 42
} 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
440 Security Services Specification
4.4.2.2 APSME-ESTABLISH-KEY.confirm
1
This primitive is issued to the ZDO upon completion or failure of a key- 2
establishment protocol. 3
4
4.4.2.2.1 Semantics of the Service Primitive
5
This primitive shall provide the following interface: 6
7
APSME-ESTABLISH-KEY.confirm { 8
Address, 9
Status 10
} 11
12
Table 4.6 specifies the parameters of the APSME-ESTABLISH-KEY.confirm 13
primitive. Table 4.10 gives a description of some codes that can be returned in the 14
Status parameter of this primitive. In addition to these codes, if, when sending one 15
of the protocol messages, an NLDE-DATA.confirm primitive with a Status 16
parameter set to a value other than SUCCESS is issued, the Status parameter of 17
the APSME-ESTABLISH-KEY.confirm primitive shall be set to that received 18
from the NWK layer. 19
20
Table 4.6 APSME-ESTABLISH-KEY.confirm Parameters
21
Name Type Valid Range Description 22
23
Address Device Any valid 64-bit The extended 64-bit address of the device
24
Address address. with which the key-establishment
protocol was executed. 25
26
Status Enumeration Value given by Table This parameter indicates the final status
27
4.10 or any status value of the key-establishment protocol.
returned from the 28
NLDE-DATA.confirm 29
primitive. 30
31
4.4.2.2.2 When Generated 32
33
The APSME in both the responder and initiator devices shall issue this primitive 34
to the ZDO upon completion of a key-establishment protocol. 35
4.4.2.2.3 Effect on Receipt 36
37
If key establishment is successful, the AIB of the initiator and responder shall be 38
updated with the new link key and the initiator shall be able to securely 39
communicate with the responder. If the key establishment was not successful, then 40
the AIB shall not be changed. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
442 Security Services Specification
4.4.2.3 APSME-ESTABLISH-KEY.indication
1
The APSME in the responder shall issue this primitive to its ZDO when it receives 2
an initial key-establishment message (for example, an SKKE-1 frame) from an 3
initiator. 4
5
4.4.2.3.1 Semantics of the Service Primitive
6
This primitive shall provide the following interface: 7
8
APSME-ESTABLISH-KEY.indication { 9
InitiatorAddress, 10
KeyEstablishmentMethod 11
} 12
13
Table 4.7 specifies the parameters of the APSME-ESTABLISH-KEY.indication 14
primitive. 15
16
Table 4.7 APSME-ESTABLISH-KEY.indication Parameters
17
Name Type Valid Range Description 18
19
InitiatorAddress Device Any valid 64- The extended 64-bit address of the
20
Address bit address initiator device.
21
KeyEstablishmentMethod Integer 0x00 - 0x03 The requested key-establishment 22
method shall be one of the following:
23
0x00 = SKKE method 24
0x01-0x03 = reserved 25
26
4.4.2.3.2 When Generated 27
28
The APSME in the responder device shall issue this primitive to the ZDO when a 29
request to start a key-establishment protocol (for example, an SKKE-1 frame) is 30
received from an initiator device and a master key associated with the initiator is 31
present in the AIB. 32
4.4.2.3.3 Effect on Receipt 33
34
Upon receiving the APSME-ESTABLISH-KEY.indication primitive, the ZDO 35
may use the KeyEstablishmentMethod and InitiatorAddress parameters to 36
determine whether to establish a key with the initiator. The ZDO shall respond 37
using the APSME-ESTABLISH-KEY.response primitive. 38
39
4.4.2.4 APSME-ESTABLISH-KEY.response 40
41
The ZDO of the responder device shall use the APSME-ESTABLISH-
42
KEY.response primitive to respond to an APSME-ESTABLISH-KEY.indication
43
primitive. The ZDO determines whether to continue with the key establishment or
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 443
halt it. This decision is indicated in the Accept parameter of the APSME-
ESTABLISH-KEY.response primitive. 1
2
4.4.2.4.1 Semantics of the Service Primitive 3
This primitive shall provide the following interface: 4
5
APSME-ESTABLISH-KEY.response { 6
InitiatorAddress, 7
Accept 8
} 9
10
Table 4.8 specifies the parameters of the APSME-ESTABLISH-KEY.response 11
primitive. 12
13
Table 4.8 APSME-ESTABLISH-KEY.response Parameters 14
Name Type Valid Range Description 15
16
InitiatorAddress Device Any valid The extended 64-bit address of the device that 17
Address 64-bit address initiated key establishment 18
Accept Boolean TRUE | This parameter indicates the response to an 19
FALSE initiator's request to execute a key- 20
establishment protocol. The response shall be 21
either:
22
TRUE = Accept 23
FALSE = Reject 24
25
4.4.2.4.2 When Generated 26
27
The APSME-ESTABLISH-KEY.response primitive shall be generated by the 28
ZDO and provided to the APSME following a request from an initiator device to 29
start a key-establishment protocol (that is, after receipt of an APSME- 30
ESTABLISH-KEY.indication). This primitive provides the responder's ZDO with 31
an opportunity to determine whether to accept or reject a request to establish a key 32
with a given initiator. 33
In addition to any other criterion for this decision, the responder’s ZDO shall 34
check the permissions configuration table as detailed in sub-clause 4.6.3.8. 35
36
4.4.2.4.3 Effect on Receipt 37
If the Accept parameter is TRUE, then the APSME of the responder will attempt 38
to execute the key establishment protocol indicated by the 39
KeyEstablishmentMethod parameter. If KeyEstablishmentMethod is equal to 40
SKKE, the APSME shall execute the SKKE protocol, described in sub- 41
clause 4.4.2.6. The local APSME shall act as the responder of this protocol and 42
the APSME indicated by the InitiatorAddress parameter shall act as the initiator of 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
444 Security Services Specification
this protocol. If the Accept parameter is FALSE, the local APSME shall halt and
erase all intermediate data pertaining to the pending key-establishment protocol. 1
2
If the UseParent sub-parameter of the TransportKeyData parameter and the 3
nwkSecureAllFrame NIB attribute are both TRUE, the command frame shall be 4
embedded in a tunnel command frame as described in sub-clause 4.6.3.7 and the 5
tunnel command shall be sent in place of the transport key command. 6
7
4.4.2.5 Data Service Message Sequence Chart 8
Figure 4.4 illustrates the sequence of primitives necessary for a successful key 9
establishment between two devices. 10
11
12
Initiator Responder
Device
13
Device
14
15
ZDO APSME APSME ZDO
16
1. APSME-ESTABLISH-KEY.request 2. APSME-ESTABLISH-KEY.indication 17
3. APSME-ESTABLISH-KEY.response
18
SKKE 19
4. APSME-ESTABLISH-KEY.confirm Protocol 5. APSME-ESTABLISH-KEY.confirm 20
21
22
23
Figure 4.4 Sequence Chart for Successful APSME-ESTABLISH- 24
KEY Primitives
25
26
4.4.2.6 The SKKE Protocol 27
The APSME on the initiator and responder execute the symmetric-key key- 28
agreement scheme instantiated in sub-clause B.2.1 and specified in sub-clause 29
B.1. The shared key (as specified in sub-clause B.1 prerequisite step 2), shall be 30
the master key shared between the initiator and responder devices as obtained 31
from the appropriate master key element in the apsDeviceKeyPairSet attribute in 32
the AIB. The messages sent during the scheme specified in sub-clause B.1 shall be 33
assigned to the frame names given in Table 4.9. The formats for these SKKE 34
frames are given in sub-clause 4.4.9.1. The initiator device is responsible for 35
sending the SKKE-1 and SKKE-3 frames and the responder device is responsible 36
for sending the SKKE-2 and SKKE-4 frames. Additionally, if the UseParent 37
parameter of the APSME-ESTABLISH-KEY.request primitive is TRUE, the 38
responder device’s parent (as indicated by the ResponderParentAddress parameter 39
of the APSME-ESTABLISH-KEY.request primitive) shall act as a liaison and 40
forward messages between the initiator and responder devices. 41
42
During the key-establishment scheme, if the responder or initiator device detects 43
any error condition listed in Table 4.10, the scheme shall be aborted and the local 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 445
TRUE. Otherwise, the device shall send the SKKE-2 frame to its parent using
the NLDE-DATA.request primitive, with the DiscoverRoute parameter set to 1
0x01, and the SecurityEnable parameter set to FALSE. 2
3
4.4.2.6.3 On Receipt of the SKKE-2 Frame 4
If the initiator address field of the SKKE-2 frame does not equal the local device 5
address, the APSME shall perform the following steps: 6
7
1 If the device indicated by the responder address field is not a child of the local 8
device, the SKKE-2 frame shall be discarded. 9
2 Otherwise, the device shall send the SKKE-2 frame to the initiator device using 10
the NLDE-DATA.request primitive with NWK layer set to the default level. 11
12
Otherwise, the device shall construct an SKKE-3 frame as specified in sub- 13
clause 4.4.9.1. If the source of the SKKE-2 frame is the same as the responder 14
address field of the SKKE-2 frame, the device shall send this SKKE-3 frame 15
directly to the responder device. Otherwise, the device shall send the SKKE-3 16
frame to the responder’s parent. The SKKE-3 frame shall be sent using the 17
NLDE-DATA.request primitive with NWK layer security set to the default NWK 18
layer security level. 19
4.4.2.6.4 On Receipt of the SKKE-3 Frame 20
21
If the responder address field of the SKKE-3 frame does not equal the local device 22
address, the APSME shall perform the following steps: 23
1 If the responder address field of the SKKE-3 frame does not equal the local 24
device address, the APSME shall perform the following steps: 25
26
i If the device given by the responder address field is not a child of the local 27
device, the SKKE-3 frame shall be discarded. 28
ii Otherwise, the device shall send the SKKE-3 to the responder device using the 29
NLDE-DATA.request primitive with NWK layer security disabled. 30
31
iii Otherwise, the device shall process the SKKE-3 data field and if the protocol 32
was not a success it shall issue an APSME-ESTABLISH-KEY.confirm 33
primitive with the Address parameter set to the initiator’s address and the 34
Status parameter set appropriately. 35
2 If, from the device’s perspective, the protocol was a success, the device shall 36
construct an SKKE-4 frame as specified in sub-clause 4.4.9.1. If the source of 37
the SKKE-3 frame is the same as the initiator address field of the SKKE-3 38
frame, the device shall send this SKKE-4 frame directly to the initiator device 39
using the NLDE-DATA.request primitive with NWK layer security set to the 40
default level. Otherwise, the device shall send the SKKE-4 frame to its parent 41
using the NLDE-DATA.request primitive with NWK layer security disabled. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 449
1
Table 4.13 TransportKeyData Parameter for a Trust
Center Master Key or Link Key 2
3
Parameter 4
Name Type Valid Range Description 5
ParentAddress Device Any valid The extended 64-bit address of the parent 6
address 64-bit address of the destination device given by the 7
DestAddress parameter. 8
Key Set of 16 Variable The Trust Center master or link key. 9
octets 10
11
12
13
Table 4.14 TransportKeyData Parameter for a Network Key 14
Parameter Valid 15
Name Type Range Description 16
17
KeySeqNumber Octet 0x00-0xFF A sequence number assigned to a network key by 18
the Trust Center and used to distinguish network
keys for purposes of key updates and incoming 19
frame security operations. 20
21
NetworkKey Set of Variable The network key.
16
22
octets 23
24
UseParent Boolean TRUE | This parameter indicates if the destination device’s
25
FALSE parent shall be used to forward the key to the
destination device: 26
27
TRUE = Use parent
28
FALSE = Do not use parent 29
ParentAddress Device Any valid If the UseParent is TRUE, then ParentAddress 30
address 64-bit parameter shall contain the extended 64-bit address 31
address of the destination device’s parent device; 32
otherwise, this parameter is not used and need not 33
be set.
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
452 Security Services Specification
1
Table 4.15 TransportKeyData Parameter for an Application Master or Link Key
2
Parameter 3
Name Type Valid Range Description 4
5
PartnerAddress Device Any valid The extended 64-bit address of the device that
address 64-bit address was also sent this master key. 6
7
Initiator Boolean TRUE | This parameter indicates if the destination 8
FALSE device of this master key requested it:
9
TRUE = If the destination requested the key 10
FALSE = Otherwise 11
12
Key Set of 16 Variable The master or link key (as indicated by the
octets KeyType parameter). 13
14
15
4.4.3.1.2 When Generated 16
The ZDO on an initiator device shall generate this primitive when it requires a key 17
to be transported to a responder device. 18
19
4.4.3.1.3 Effect on Receipt 20
The receipt of an APSME-TRANSPORT-KEY.request primitive shall cause the 21
APSME to create a transport-key command packet (see sub-clause 4.4.9.2). 22
23
If the KeyType parameter is 0x00 or 0x04 (that is, Trust Center master or link 24
key), the key descriptor field of the transport-key command shall be set as 25
follows: 26
• The key sub-field shall be set to the Key sub-parameter of the 27
TransportKeyData parameter. 28
29
• The destination address sub-field shall be set to the DestinationAddress 30
parameter. 31
• The source address sub-field shall be set to the local device address. 32
33
This command frame shall be security-protected as specified in sub- 34
clause 4.4.1.1. Then, if security processing succeeds, it is sent to the device 35
specified by the ParentAddress sub-parameter of the TransportKeyData parameter 36
by issuing a NLDE-DATA.request primitive. 37
If the DestinationAddress parameter is all zeros, the secured command frame shall 38
be unicast to any and all rx-off-when-idle children of the device. These unicasts 39
shall be repeated until successful, or a subsequent APSME-TRANSPORT- 40
KEY.request primitive with the KeyType parameter equal to 0x01 or 0x05 has 41
been received, or a period of twice the recommended maximum polling interval 42
has passed. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 453
If the KeyType parameter is 0x01 or 0x05 (that is, a network key), the key
descriptor field of the transport-key command shall be set as follows: 1
2
• The key sub-field shall be set to the Key sub-parameter of the 3
TransportKeyData parameter. 4
• The sequence number sub-field shall be set to the KeySeqNumber sub- 5
parameter of the TransportKeyData parameter. 6
7
• The destination address sub-field shall be set to the DestinationAddress 8
parameter. 9
• The source address sub-field shall be set to the local device address. 10
11
This command frame shall be security-protected as specified in sub-clause 4.4.1.1 12
and then, if security processing succeeds, sent to the device specified by the 13
ParentAddress sub-parameter of the TransportKeyData parameter (if the 14
UseParent sub-parameter of the TransportKeyData parameter is TRUE) or the 15
DestinationAddress parameter (if the UseParent sub-parameter of the 16
TransportKeyData parameter is FALSE) by issuing a NLDE-DATA.request 17
primitive. 18
If the UseParent sub-parameter of the TransportKeyData parameter is FALSE, 19
and there is an entry in nwkNeighborTable whose extended address matches the 20
SenderAddress parameter and whose relationship field has value 0x05 21
(unauthenticated child), then the relationship field in that entry shall be set to the 22
value 0x01 (child). 23
24
If the KeyType parameter is 0x02 or 0x03 (that is, an application master or link 25
key), the key descriptor field of the transport-key command shall be set as 26
follows: 27
• The key sub-field shall be set to the Key sub-parameter of the 28
TransportKeyData parameter. 29
30
• The partner address sub-field shall be set to the PartnerAddress sub-parameter 31
of the TransportKeyData parameter. 32
• The initiator sub-field shall be set 1 (if the Initiator sub-parameter of the 33
TransportKeyData parameter is TRUE) or 0 (if the Initiator sub-parameter of 34
the TransportKeyData parameter is FALSE). 35
36
This command frame shall be security-protected as specified in sub-clause 4.4.1.1 37
and then, if security processing succeeds, sent to the device specified by the 38
DestinationAddress parameter by issuing a NLDE-DATA.request primitive. 39
40
4.4.3.2 APSME-TRANSPORT-KEY.indication 41
The APSME-TRANSPORT-KEY.indication primitive is used to inform the ZDO 42
of the receipt of keying material. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
454 Security Services Specification
Table 4.17 TransportKeyData Parameter for a Trust Center Master or Link Key 1
Parameter Name Type Valid Range Description 2
3
TrustCenter- Set of 16 Variable The Trust Center master key. 4
MasterKey octets 5
6
7
Table 4.18 TransportKeyData Parameter for a Network Key
8
Parameter 9
Name Type Valid Range Description 10
11
KeySeqNumber Octet 0x00-0xFF A sequence number assigned to a network key
by the Trust Center and used to distinguish; 12
network keys for purposes of key updates and 13
incoming frame security operations. 14
NetworkKey Set of 16 Variable The network key. 15
octets 16
17
18
19
Table 4.19 TransportKeyData Parameter for an Application Master or Link Key 20
Valid 21
Parameter Name Type Range Description 22
23
PartnerAddress Device Any valid The extended 64-bit address 24
address 64-bit of the device that was also
address sent this master key.
25
26
Key Set of 16 Variable The master or link key (as 27
octets indicated by the KeyType
28
parameter).
29
30
4.4.3.2.2 When Generated 31
The APSME shall generate this primitive when it receives a transport-key 32
command as specified in sub-clause 4.4.3.3. 33
34
4.4.3.2.3 Effect on Receipt 35
Upon receipt of this primitive, the ZDO is informed of the receipt of the keying 36
material. 37
38
4.4.3.3 Upon Receipt of a Transport-Key Command 39
40
Upon receipt of a transport-key command, the APSME shall execute security 41
processing as specified in, then check the key type sub-field. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
456 Security Services Specification
Upon receipt of a secured transport-key command, the APSME shall check the
key type sub-field. If the key type field is set to 0x02, 0x03, 0x04, or 0x05 (that is, 1
application link or master key, Trust Center link key, or high-security network 2
key) and the command was not secured using a Trust Center link key, the 3
command shall be discarded. If the key type field is set to 0x01 (that is, standard 4
network key) and the command was not secured using a Trust Center link key or 5
the active network key, the command shall be discarded. 6
7
If the key type field is set to 0x02 or 0x03 (that is, application link or master key), 8
the APSME shall issue the APSME-TRANSPORT-KEY.indication primitive 9
with: the SrcAddress parameter set to the source of the key-transport command 10
(as indicated by the NLDE-DATA.indication SrcAddress parameter), and the 11
KeyType parameter set to the key type field. The TransportKeyData parameter 12
shall be set as follows: 13
• The Key sub-parameter shall be set to the key field. 14
15
• The PartnerAddress sub-parameter shall be set to the partner address field. 16
• The Initiator parameter shall be set to TRUE, if the initiator field is 1. 17
Otherwise it shall be set to 0. 18
19
If the key type field is set to 0x00, 0x01, 0x04, or 0x05 (that is, Trust Center 20
master or link key, or a network key) and the destination field is equal to the local 21
address, or if the key type field is set to 0x01 (that is, a standard network key), the 22
destination field is the all-zero string, and the current network key type is equal to 23
the value of the key type field, the APSME shall issue the APSME-TRANSPORT- 24
KEY.indication primitive with the SrcAddress parameter set to the source address 25
field of the key-transport command and the KeyType parameter set to the key type 26
field. The TransportKeyData parameter shall be set as follows: the Key sub- 27
parameter shall be set to the key field and, in the case of a network key (that is, the 28
key type field is set to 0x01 or 0x05), the KeySeqNumber sub-parameter shall be 29
set to the sequence number field. 30
If the key type field is set to 0x00 or 0x01 (that is, Trust Center master or link key 31
or standard network key) and the destination address field is not equal to the local 32
address, the APSME shall send the command to the address indicated by the 33
destination address field by issuing the NLDE-DATA.request primitive with 34
security disabled. 35
36
If the key type field is set to 0x01 (that is, the standard network key) and there is 37
an entry in nwkNeighborTable whose extended address matches value of the 38
destination address field and whose relationship field has value 0x05 39
(unauthenticated child), then the relationship field in that entry shall be set to the 40
value 0x01 (child). 41
Upon receipt of a secured transport-key command with the key type field set to 42
0x01, if the destination field is all zeros and the source address field is set to the 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 457
1
Table 4.33 Mapping of Mutual Entity Authentication Error
Conditions to Status Codes 2
3
Status Description Status Code Value 4
5
No errors occur. SUCCESS 0x00
6
An invalid parameter was input to one of the key INVALID_PARAMETER 0x01 7
establishment primitives. 8
No authentication key exists. NO_KEY 0x02 9
No authentication data exists. NO_DATA 0x03
10
11
Challenge is invalid: INVALID_CHALLENGE 0x04 12
Initiator during action step 2 (sub-clause B.8.1). 13
14
Responder during action step 1 (sub-clause B.8.2).
15
MAC transformation outputs invalid: INVALID_MAC 0x05 16
Initiator during action step 4 (sub-clause B.8.1). 17
18
Responder during action steps 4 and 7 (sub-clause B.8.2).
19
Tag checking transformation outputs invalid: INVALID_KEY 0x06 20
Initiator during action step 3 (sub-clause B.8.1). 21
22
Responder during action step 6 (sub-clause B.8.2).
23
The initiator or responder waits for an expected incoming TIMEOUT 0x07 24
message for time greater than apsSecurityTimeoutPeriod. 25
26
4.4.9 Command Frames 27
28
The APS layer command frame formats are given in this clause. 29
30
All APS layer command frames are sent secured unless explicitly specified. 31
Command identifier values are shown in Table 4.34. 32
33
Table 4.34 Command Identifier Values 34
Command Identifier Value 35
36
APS_CMD_SKKE_1 0x01 37
APS_CMD_SKKE_2 0x02 38
39
APS_CMD_SKKE_3 0x03a
40
APS_CMD_SKKE_4 0x04 41
APS_CMD_TRANSPORT_KEY 0x05 42
43
APS_CMD_UPDATE_DEVICE 0x06 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 475
• The key sub-field shall contain the master key that should be used to set up link
keys with the Trust Center. 1
2
• The destination address sub-field shall contain the address of the device which 3
should use this master key. 4
• The source address sub-field shall contain the address of the device (for 5
example, the Trust Center) which originally sent this master key. 6
7
4.4.9.2.3.2 Network Key Descriptor Field 8
9
If the key type field is set to 1, 5 or 6, this field shall be formatted as shown in 10
Figure 4.10. 11
12
Octets: 16 1 8 8 13
Key Sequence number Destination address Source address 14
15
Figure 4.10 Network Key Descriptor Field in Transport-Key Command 16
17
• The key sub-field shall contain a network key. 18
• The sequence number sub-field shall contain the sequence number associated 19
with this network key. 20
21
• The destination address sub-field shall contain the address of the device which 22
should use this network key. 23
• If the network key is sent to a broadcast address, the destination address sub- 24
field shall be set to the all-zero string and shall be ignored upon reception. 25
26
• The source address field sub-shall contain the address of the device (for 27
example, the Trust Center) which originally sent this network key. 28
29
4.4.9.2.3.3 Application Master and Link Key Descriptor Field 30
If the key type field is set to 2 or 3, this field shall be formatted as shown in 31
Figure 4.11. 32
33
Octets: 16 8 1 34
35
Key Partner address Initiator flag
36
Figure 4.11 Application Master Key Descriptor in Transport-Key Command 37
38
• The key sub-field shall contain a master or link key that is shared with the 39
device identified in the partner address sub-field. 40
41
• The partner address sub-field shall contain the address of the other device that 42
was sent this link or master key. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 479
• The initiator flag sub-field shall be set to 1 if the device receiving this packet
requested this key. Otherwise, this sub-field shall be set to 0. 1
2
4.4.9.3 Update Device Commands 3
4
The APS command frame used for device updates is specified in this clause. The 5
optional fields of the APS header portion of the general APS frame format shall 6
not be present. 7
The update-device command frame shall be formatted as illustrated in 8
Figure 4.12. 9
10
Octets: 1 1 1 8 2 1 11
12
Frame control APS countera APS Device Address Device short Status
command address
13
identifierb 14
15
APS Headerc Payload
16
a. CCB #811 17
b. CCB #811 18
c. CCB #811 19
Figure 4.12 Update-Device Command Frame Format 20
21
4.4.9.3.1 Command Identifier Field 22
23
The command identifier field shall indicate the update-device APS command type 24
(APS_CMD_UPDATE_DEVICE, see Tables 4.34). 37 25
4.4.9.3.2 Device Address Field 26
27
The device address field shall be the 64-bit extended address of the device whose 28
status is being updated. 29
4.4.9.3.3 Device Short Address Field 30
31
The device short address field shall be the 16-bit network address of the device 32
whose status is being updated. 33
4.4.9.3.4 Status Field 34
35
The status field shall be assigned a value as described for the Status parameter in 36
Table 4.20. 37
38
39
40
41
42
43
37. CCB #811 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
480 Security Services Specification
identifiers are not indicative of the relative strength of the various security levels.
Also note that security levels 0 and 4 should not be used for frame security. 1
2
Table 4.38 Security Levels Available to the NWK, and APS Layers
3
Security Frame Integrity 4
Security Level Sub- (length M of MIC, 5
Level Field Security Data in Number of 6
Identifier (Table 4.24) Attributes Encryption Octets) 7
0x00 ‘000’ None OFF NO (M = 0) 8
9
0x01 ‘001’ MIC-32 OFF YES (M=4)
10
0x02 ‘010’ MIC-64 OFF YES (M=8) 11
0x03 ‘011’ MIC-128 OFF YES (M=16) 12
13
0x04 ‘100’ ENC ON NO (M = 0)
14
0x05 ‘101’ ENC-MIC-32 ON YES (M=4) 15
0x06 ‘110’ ENC-MIC-64 ON YES (M=8) 16
17
0x07 ‘111’ ENC-MIC-128 ON YES (M=16) 18
19
4.5.1.1.2 Key Identifier Sub-Field 20
21
The key identifier sub-field consists of two bits that are used to identify the key
22
used to protect the frame. The encoding for the key identifier sub-field shall be as
23
listed in Table 4.39.
24
Table 4.39 Encoding for the Key Identifier Sub-Field 25
26
Key Identifier Sub-Field
Key Identifier (Table 4.24) Description 27
28
0x00 ‘00’ A data key. 29
0x01 ‘01’ A network key. 30
31
0x02 ‘10’ A key-transport key.
32
0x03 ‘11’ A key-load key. 33
34
4.5.1.1.3 Extended Nonce Sub-Field 35
36
The extended nonce sub-field shall be set to 1 if the sender address field of the 37
auxiliary header is present. Otherwise, it shall be set to 0. 38
39
4.5.1.2 Counter Field 40
The counter field is used to provide frame freshness and to prevent processing of 41
duplicate frames. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
492 Security Services Specification
auxiliary header’s source address field (as defined in sub-clause 4.5.1) of the
frame being processed 1
2
Octets: 8 4 1 3
4
Source address Frame counter Security control
5
Figure 4.25 CCM* Nonce 6
7
8
4.5.3 Cryptographic Key Hierarchy 9
10
The link key established between two (or more) devices via one of the key-
11
establishment schemes specified in sub-clause 4.4.2 (or transport-key commands
12
specified in sub-clause 4.4.3) is used to determine related secret keys, including
13
data keys, key-transport keys, and key-load keys. These keys are determined as
14
follows:
15
1 Key-Transport Key. This key is the outcome of executing the specialized keyed 16
hash function specified in sub-clause B.1.4 under the link key with the 1-octet 17
string ‘0x00’as the input string. 18
19
2 Key-Load Key. This key is the outcome of executing the specialized keyed hash
20
function specified in sub-clause B.1.4 under the link key with as input string
21
the 1-octet string ‘0x02’as the input string.
22
3 Data Key. This key is equal to the link key. 23
24
All keys derived from the link key shall share the associated frame counters. Also,
25
all layers of ZigBee shall share the active network key and associated outgoing
26
and incoming frame counters.
27
28
4.5.4 Implementation Guidelines (Informative) 29
30
This clause provides general guidelines that should be followed to ensure a secure 31
implementation. 32
33
4.5.4.1 Random Number Generator 34
35
A ZigBee device implementing the key-establishment security service, (see sub- 36
clause 4.2.3.1) may need a strong method of random number generation. For 37
example, when link keys are pre-installed (e.g., in the factory), a random number 38
may not be needed. 39
In all cases that require random numbers, it is critical that the random numbers are 40
not predictable or have enough entropy, so an attacker will not be able determine 41
them by exhaustive search. The general recommendation is that the random 42
number generation shall meet the random number tests specified in FIPS140- 43
2 [B13]. Methods for generation of random numbers include: 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
494 Security Services Specification
1 Base the random number on random clocks and counters within the ZigBee
hardware; 1
2
2 Base the random number on random external events; 3
3 Seed each ZigBee device with a good random number from an external source 4
during production. This random number can then used as a seed to generate 5
additional random numbers. 6
7
A combination of these methods can be used. Since the random number 8
generation is likely integrated into the ZigBee IC, its design — and hence the 9
ultimate viability of any encryption/security scheme — is left up to the IC 10
manufacturers. 11
12
4.5.4.2 Security Implementation 13
To avoid “bugs” that an attacker can use to his advantage, it is crucial that security 14
be well implemented and tested. It is also desirable that the security 15
implementation does not require re-certification for every application. Security 16
services should be implemented and tested by security experts and should not be 17
re-implemented or modified for different applications. 18
19
4.5.4.3 Conformance 20
21
Conformance shall be defined by the profile inheriting given in this specification. 22
Correct implementation of selected cryptographic protocols should be verified as 23
part of the ZigBee certification process. This verification shall include known 24
value tests: an implementation must show that, given particular parameters, it will 25
correctly compute the corresponding results. 26
27
28
4.6 Functional Description 29
30
This sub-clause provides detailed descriptions of how the security services shall 31
be used in a ZigBee network. A description of the ZigBee coordinator’s security 32
initialization responsibilities is given in sub-clause 4.6.1. A brief description of 33
the Trust Center application is given in sub-clause 4.6.2. Detailed security 34
procedures are given in sub-clause 4.6.3. 35
36
37
4.6.1 ZigBee Coordinator 38
39
The ZigBee coordinator shall configure the security level of the network by
40
setting the nwkSecurityLevel attribute in the NIB. If the nwkSecurityLevel
41
attribute is set to zero, the network will be unsecured, otherwise it will be secured.
42
The ZigBee coordinator shall configure the address of the Trust Center by setting 43
the AIB attribute apsTrustCenterAddress. The default value of this address is the 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 495
A device that is operating in a network and has missed a key update may also use
these procedures to receive the latest network key. 1
2
3
Router Joiner
4
ZDO NWK MAC MAC NWK ZDO
5
NLME-PERMIT-JOINING.request NLME-NETWORK-DISCOVERY.request 6
MLME-SET.request(macAssociationPermit = TRUE) MLME-SCAN.request 7
8
Beacon request command (unsecured)
9
Beacon (unsecured)
MLME-SCAN.confirm 10
NLME-NETWORK-DISCOVERY.confirm
11
12
NLME-JOIN.request
13
MLME-ASSOCIATE.request
Association request command 14
MLME-ASSOCIATE.indication
15
16
NLME-JOIN.indication
17
MLME-ASSOCIATE.response
Association response command
18
19
MLME-ASSOCIATE.confirm
NLME-JOIN.confirm
20
21
Joined (unauthenticated) 22
23
Successful Authenticate Routine (see 8.3.2) 24
25
NLME-START-ROUTER.request (only if B is a router) 26
MLME-START.request (only if B is a router) 27
28
Joined (authenticated)
29
30
Figure 4.26 Example of Joining a Secured Network 31
32
The joiner device may begin the join procedure by issuing an NLME- 33
NETWORK-DISCOVERY.request primitive. This primitive will invoke an 34
MLME-SCAN.request primitive which may cause the transmission of an 35
unsecured beacon request frame (depending on whether the scan is an active or 36
passive scan). 37
The joiner device receives beacons from nearby routers and the NWK layer issues 38
an NLME-NETWORK-DISCOVERY.confirm primitive. The NetworkList 39
parameter of this primitive will indicate all of the nearby PANs. In Figure 4.26, 40
the shown router device has already been placed in a state such that its beacons 41
have the “association permit” sub-field set to “1” (permit association). 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 497
The joiner device shall decide which PAN to join and shall issue the NLME-
JOIN.request primitive to join that PAN. If the joiner already has a network key 1
for this PAN, the SecurityEnable parameter for the NLME-JOIN.request primitive 2
shall be set to TRUE; otherwise it shall be set to FALSE. As shown in Figure 4.26, 3
the NLME-JOIN.request primitive causes an association request or rejoin request 4
command to be sent to the router. 5
6
Upon receipt of an association request MAC command, the router shall issue an 7
MLME-ASSOCIATE.indication primitive. Next, the NWK layer will issue an 8
NLME-JOIN.indication primitive to the router’s ZDO. The router shall now know 9
the joiner device's address and security capabilities. The router will also issue an 10
MLME-ASSOCIATE.response. This primitive will cause an association response 11
command to be sent to the joiner. 12
Alternatively, upon receipt of a rejoin request network command, the NWK layer 13
will issue an NLME-JOIN.indication primitive to the router’s ZDO. The router 14
shall now know the joiner device's address, security capabilities, and whether the 15
network key was used to secure the rejoin request command. The router will also 16
issue a rejoin response command to the joiner. 17
18
Upon receipt of the association response MAC command or the rejoin response 19
network command, the joiner shall issue the NLME-JOIN.confirm primitive. The 20
joiner is now declared “joined, but unauthenticated” to the network. The 21
authentication routine (see sub-clause 4.6.3.2) shall follow. 22
If the joiner is not a router, it is declared “joined and authenticated” immediately 23
following the successful completion of the authentication routine. 24
25
If the joiner is a router, it is declared “joined and authenticated” only after the 26
successful completion of the authentication routine followed by the initiation of 27
routing operations. Routing operations shall be initiated by the joiner’s ZDO 28
issuing the NLME-START.request primitive to cause the MLME-START.request 29
primitive to be sent to the MAC layer of the joiner. 30
If the router refuses the joiner, its association response frame or rejoin response 31
frame shall contain the association status field set to a value other than 0x00, and, 32
after this parameter reaches the ZDO of the joiner in the NLME-JOIN.confirm 33
primitive, the joiner shall not begin the authentication routine. 34
35
4.6.3.2 Authentication 36
37
Once a device joins a secured network and is declared “joined but 38
unauthenticated”, it must be authenticated as specified in this sub-clause. In high 39
security mode, neighboring routers must also be authenticated as described in sub- 40
clause 4.4.8. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
498 Security Services Specification
upon receipt of the switch-key command, device 1 makes the new network key
the active network key; however device 2 has only one active network key, so it 1
ignores this command. 2
3
4.6.3.5 End-to-End Application Key Establishment 4
5
An initiator device, a Trust Center, and a responder device shall follow the 6
procedures described in this sub-clause when establishing a link key for purposes 7
of end-to-end application security between initiator and responder devices. 8
4.6.3.5.1 Device Operation 9
10
The initiator device shall begin the procedure to establish a link key with a 11
responder device by issuing the APSME-REQUEST-KEY.request primitive. The 12
DestAddress parameter shall be set to the address of its Trust Center, the KeyType 13
parameter shall be set to 0x02 (that is, application key), and the PartnerAddress 14
parameter shall be set to the address of the responder device. 15
16
4.6.3.5.1.1 Upon Receipt of a Link Key 17
18
Upon receipt of an APSME-TRANSPORT-KEY.indication primitive with the 19
KeyType parameter set to 0x03 (that is, application link key), a device may accept 20
the TransportKeyData parameters as a link key with the device indicated by the 21
PartnerAddress parameter only if the SrcAddress parameter is the same as the 22
apsTrustCenterAddress attribute of the AIB. If accepted, the 23
apsDeviceKeyPairSet attribute in AIB table will be updated. A key-pair descriptor 24
in the AIB shall be created (or updated if already present) for the device indicated 25
by the PartnerAddress parameter, by setting the DeviceAddress element to the 26
PartnerAddress parameter, the LinkKey element to the link key from the 27
TransportKeyData parameter, and the OutgoingFrameCounter and 28
IncomingFrameCounter elements to 0. 29
30
4.6.3.5.1.2 Upon Receipt of a Master Key 31
Upon receipt of an APSME-TRANSPORT-KEY.indication primitive with the 32
KeyType parameter set to 0x02 (that is, application master key), a device may 33
accept the TransportKeyData parameters as a master key with the device indicated 34
by the PartnerAddress sub-parameter only if the SrcAddress parameter is the same 35
as the apsTrustCenterAddress attribute of the AIB. If accepted, the 36
apsDeviceKeyPairSet attribute in AIB table will be updated. A key-pair descriptor 37
shall be created (or updated if already present) for the device indicated by the 38
PartnerAddress parameter, by setting the DeviceAddress element to the 39
PartnerAddress parameter, the MasterKey element to the master key from the 40
TransportKeyData parameter, and the OutgoingFrameCounter and 41
IncomingFrameCounter elements to 0. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 511
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
This page intentionally blank 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 521
A N N E X
1
A
2
3
4
5
6
7
8
9
Note that this definition ensures that all the Ai fields are distinct from the B0
fields that are actually used, as those have a Flags field with a non-zero 1
encoding of M in the positions where all Ai fields have an all-zero encoding of 2
the integer 0 (see sub-clause A.2.2, step 1). 3
4
Parse the message PlaintextData as M1 || ... ||Mt, where each message block Mi 5
is a 16-octet string. 6
The ciphertext blocks C1, ... , Ct are defined by: 7
8
Ci:= E(Key, Ai) Mi for i=1, 2, ... , t 9
10
11
The string Ciphertext is the result of omitting all but the leftmost l(m) octets of 12
the string C1 || ... || Ct 13
Define the 16-octet encryption block S0 by: 14
15
S0:= E(Key, A0) 16
17
2 The encrypted authentication tag U is the result of XOR-ing the string 18
consisting of the leftmost M octets of S0 and the authentication tag T. 19
20
Output: If any of the above operations has failed, then output ‘invalid’. 21
Otherwise, output the right-concatenation of the encrypted message Ciphertext 22
and the encrypted authentication tag U. 23
24
25
A.3 CCM* Mode Decryption and Authentication 26
Checking Transformation 27
28
Input: The CCM* inverse transformation takes as inputs: 29
30
1 A bit string Key of length keylen bits to be used as the key. Each entity shall 31
have evidence that access to this key is restricted to the entity itself and its 32
intended key-sharing group member(s). 33
2 A nonce N of 15-L octets. Within the scope of any encryption key Key, the 34
nonce value shall be unique. 35
36
3 An octet string c of length l(c) octets, where 0 < l(c)-M < 28L. 37
4 An octet string a of length l(a) octets, where 0 < l(a) < 264. 38
39
40
A.3.1 Decryption Transformation 41
42
The decryption transformation involves the following steps, in order: 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex A
526 CCM* Mode of Operation
1 Parse the message c as C ||U, where the rightmost string U is an M-octet string.
If this operation fails, output ‘invalid’ and stop. U is the purported encrypted 1
authentication tag. Note that the leftmost string C has length l(c)-M octets. 2
3
2 Form the padded message CiphertextData by right-concatenating the string C 4
with the smallest non-negative number of all-zero octets such that the octet 5
string CiphertextData has length divisible by 16. 6
3 Use the encryption transformation in sub-clause A.2.3, with the data 7
CipherTextData and the tag U as inputs. 8
9
4 Parse the output string resulting from applying this transformation as m || T, 10
where the rightmost string T is an M-octet string. T is the purported 11
authentication tag. Note that the leftmost string m has length l(c)-M octets. 12
13
A.3.2 Authentication Checking Transformation 14
15
The authentication checking transformation involves the following steps: 16
17
1 Form the message AuthData using the input transformation in sub- 18
clause A.2.1, with the string a and the octet string m that was established in 19
sub-clause A.3.1 (step 4) as inputs. 20
2 Use the authentication transformation in sub-clause A.2.2, with the message 21
AuthData as input. 22
23
3 Compare the output tag MACTag resulting from this transformation with the 24
tag T that was established in sub-clause A.3.1 (step 4). If MACTag=T, output 25
‘valid’; otherwise, output ‘invalid’ and stop. 26
Output: If any of the above verifications has failed, then output ‘invalid’ and 27
reject the octet string m. Otherwise, accept the octet string m and accept one of the 28
key sharing group member(s) as the source of m. 29
30
31
A.4 Restrictions 32
33
All implementations shall limit the total amount of data that is encrypted with a 34
single key. The CCM* encryption transformation shall invoke not more than 261 35
block-cipher encryption function operations in total, both for the CBC-MAC and 36
for the CTR encryption operations. 37
38
At CCM* decryption, one shall verify the (truncated) CBC-MAC before releasing 39
any information, such as, Plaintext. If the CBC-MAC verification fails, only the 40
fact that the CBC-MAC verification failed shall be exposed; all other information 41
shall be destroyed. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 527
A N N E X
1
B
2
3
4
5
6
7
8
9
2 Calculate the tag MacTag for MacData under the key MacKey using the
tagging transformation of the established specialized MAC scheme: 1
2
MacTag = MACMacKey(MacData) 3
4
5
3 If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop.
6
4 Set Z=MacTag. 7
8
Output: The bit string Z as the shared secret value.
9
10
B.6 Block-Cipher-Based Cryptographic Hash Function 11
12
13
This section specifies the Matyas-Meyer-Oseas hash function, a cryptographic 14
hash function based on block-ciphers. We define this hash function for block- 15
ciphers with a key size equal to the block size, such as AES-128, and with a 16
particular choice for the fixed initialization vector IV (we take IV=0). For a more 17
general definition of the Matyas-Meyer-Oseas hash function, refer to Section 18
9.4.1 of [B19]. 19
Prerequisites: The following are the prerequisites for the operation of Matyas- 20
Meyer-Oseas hash function: 21
22
1 A block-cipher encryption function E shall have been chosen, with a key size
23
that is equal to the block size. The Matyas-Meyer-Oseas hash function has a 24
message digest size that is equal to the block size of the established encryption 25
function. It operates on bit strings of length less than 2n, where n is the block 26
size, in octets, of the established block-cipher. 27
2 A fixed representation of integers as binary strings or octet strings shall have 28
been chosen. 29
30
Input: The input to the Matyas-Meyer-Oseas hash function is as follows: 31
1 A bit string M of length l bits, where 0 < l < 2n 32
33
Actions: The hash value shall be derived as follows: 34
1 Pad the message M according to the following method: 35
36
a Right-concatenate to the message M the binary consisting of the bit ‘1’
37
followed by k ‘0’ bits, where k is the smallest non-negative solution to the 38
equation: 39
40
l+1+k 7n (mod 8n) (1) 41
42
b Form the padded message M’ by right-concatenating to the resulting string 43
the n-bit string that is equal to the binary representation of the integer l. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 533
Key 1
2
3
QEU 4
5
U V
6
7
QEV, MACMacKey(0216 || V || U || QEV || QEU || [Text1]), [Text1] 8
9
10
MACMacKey(0316 || U || V || QEU || QEV || [Text2]), [Text2] 11
12
13
Figure B.1 Symmetric-Key Authenticated Key Agreement Scheme 14
15
The scheme is ‘asymmetric’, so two transformations are specified. U uses the 16
transformation specified in sub-clause B.7.1 to agree on keying data with V if U is 17
the protocol’s initiator, and V uses the transformation specified in sub-clause B.7.2 18
to agree on keying data with U if V is the protocol’s responder. 19
The essential difference between the role of the initiator and the role of the 20
responder is that the initiator sends the first pass of the exchange. 21
22
If U executes the initiator transformation, and V executes the responder 23
transformation with the shared secret keying material as input, then U and V will 24
compute the same keying data. 25
Prerequisites: The following are the prerequisites for the use of the scheme: 26
27
1 Each entity has an authentic copy of the system’s challenge domain parameters 28
D=(minchallengelen, maxchallengelen). 29
2 Each entity shall have access to a bit string Key of length keylen bits to be used 30
as the key. Each party shall have evidence that access to this key is restricted to 31
the entity itself and the other entity involved in the symmetric-key 32
authenticated key agreement scheme. 33
34
3 Each entity shall be bound to a unique identifier (e.g., distinguished names). 35
All identifiers shall be bit strings of the same length entlen bits. Entity U’s 36
identifier will be denoted by the bit string U. Entity V’s identifier will be 37
denoted by the bit string V. 38
4 Each entity shall have decided which MAC scheme to use as specified in 39
Section 5.7 of ANSI X9.63-2001 [B7]. The length in bits of the keys used by 40
the chosen MAC scheme is denoted by mackeylen. 41
42
5 A cryptographic hash function shall have been chosen for use with the key 43
derivation function. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 535
6 A specialized MAC scheme shall have been chosen for use with the secret key
generation primitive with tagging transformation as specified in Section 5.7.1 1
of ANSI X9.63-2001 [B7]. The length in bits of the keys used by the 2
specialized MAC scheme is denoted by keylen. 3
4
7 A fixed representation of octets as binary strings shall have been chosen. (e.g., 5
most-significant-bit-first order or least-significant-bit-first order). 6
7
B.7.1 Initiator Transformation 8
9
U shall execute the following transformation to agree on keying data with V if U is 10
the protocol’s initiator. U shall obtain an authentic copy of V’s identifier and an 11
authentic copy of the static secret key Key shared with V. 12
13
Input: The input to the initiator transformation is: 14
1 An integer keydatalen that is the length in bits of the keying data to be 15
generated. 16
17
2 (Optional) A bit string SharedData of length shareddatalen bits that consists of 18
some data shared by U and V. 19
3 (Optional) A bit string Text2 that consists of some additional data to be 20
provided from U to V. 21
22
Ingredients: The initiator transformation employs the challenge generation 23
primitive specified in Section 5.3 of ANSI X9.63-2001 [B7], the challenge 24
validation primitive in sub-clause B.3.2, the SKG primitive in sub-clause B.5, the 25
key derivation function in Section 5.6.3 of ANSI X9.63-2001 [B7], and one of the 26
MAC schemes in Section 5.7 of ANSI X9.63-2001 [B7]. 27
Actions: Keying data shall be derived as follows: 28
29
1 Use the challenge generation primitive in Section 5.3 of ANSI X9.63-2001 30
[B7] to generate a challenge QEU for the challenge domain parameters D. Send 31
QEU to V. 32
2 Then receive from V a challenge QEV', purportedly owned by V. If this value is 33
not received, output ‘invalid’ and stop. 34
35
3 Verify that QEV' is a valid challenge for the challenge domain parameters D as 36
specified in sub-clause B.3.2. If the validation primitive rejects the challenge, 37
output ‘invalid’ and stop. 38
4 Use the SKG primitive given in sub-clause B.5 to derive a shared secret bit 39
string Z from the challenges Q1=QEU owned by U and Q2=QEV' owned by V, 40
using as key the shared key Key. If the SKG primitive outputs ‘invalid’, output 41
‘invalid’ and stop. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex B
536 Security Building Blocks
5 Use the key derivation function in Section 5.6.3 of ANSI X9.63-2001 [B7] with
the established hash function to derive keying data KKeyData of length 1
mackeylen+keydatalen bits from the shared secret value Z and the shared data 2
[SharedData]. 3
4
6 Parse the leftmost mackeylen bits of KKeyData as a MAC key MacKey and the 5
remaining bits as keying data KeyData. 6
7 Form the bit string consisting of the octet 0216, V’s identifier, U’s identifier, the 7
bit string QEV', the bit string QEU, and if present Text1: 8
9
MacData1 = 0216 || V || U || QEV' || QEU || [Text1] 10
11
8 Verify that MacTag1' is the tag for MacData1 under the key MacKey using the 12
tag checking transformation of the appropriate MAC scheme specified in 13
Section 5.7.2 of ANSI X9.63-2001 [B7]. If the tag checking transformation 14
outputs ‘invalid’, output ‘invalid’ and stop. 15
9 Form the bit string consisting of the octet 0316, U’s identifier, V’s identifier, the 16
bit string QEU corresponding to U’s challenge, the bit string QEV' 17
corresponding to V’s challenge, and optionally a bit string Text2: 18
19
MacData2 = 0316 || U || V || QEU || QEV' || [Text2] 20
21
10 Calculate the tag MacTag2 on MacData2 under the key MacKey using the 22
tagging transformation of the appropriate MAC scheme specified in Section 23
5.7.1 of ANSI X9.63-2001 [B7]: 24
25
MacTag2 = MACMacKey(MacData2) (3) 26
27
11 If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send 28
MacTag2 and, if present, Text2 to V. 29
12 Receive from V an optional bit string Text1, and a purported tag MacTag1'. If 30
these values are not received, output ‘invalid’ and stop. 31
32
Output: If any of the above verifications has failed, then output ‘invalid’ and 33
reject the bit strings KeyData and Text1. Otherwise, output ‘valid’, accept the bit 34
string KeyData as the keying data of length keydatalen bits shared with V and 35
accept V as the source of the bit string Text1 (if present). 36
37
B.7.2 Responder Transformation 38
39
V shall execute the following transformation to agree on keying data with U if V is 40
the protocol’s responder. V shall obtain an authentic copy of U’s identifier and an 41
authentic copy of the static secret key Key shared with U. 42
43
Input: The input to the responder transformation is: 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 537
8 Parse the leftmost mackeylen bits of KKeyData as a MAC key MacKey and the
remaining bits as keying data KeyData. 1
2
9 Form the bit string consisting of the octet 0216, V’s identifier, U’s identifier, the 3
bit string QEV, the bit string QEU', and, optionally, a bit string Text1: 4
5
MacData1 = 0216 || V || U || QEV || QEU' || [Text1] 6
7
10 Calculate the tag MacTag1 for MacData1 under the key MacKey using the 8
tagging transformation of the appropriate MAC scheme specified in Section 5.7 9
of ANSI X9.63-2001 [B7]: 10
11
MacTag1 = MACMacKey(MacData1) 12
13
14
If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send to 15
U, if present the bit string Text1, and MacTag1. 16
Output: If any of the above verifications has failed, then output ‘invalid’ and 17
reject the bit strings KeyData and Text2. Otherwise, output ‘valid’, accept the bit 18
string KeyData as the keying data of length keydatalen bits shared with U and 19
accept U as the source of the bit string Text2 (if present). 20
21
22
B.8 Mutual Symmetric-Key Entity Authentication 23
24
This section specifies the mutual symmetric-key entity authentication scheme. A 25
MAC scheme is used to provide key confirmation. 26
27
Figure B.2 illustrates the messaging involved in the use of mutual symmetric-key 28
entity authentication scheme. 29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 539
MacKey
1
2
3
QEU 4
5
6
QEV 7
8
9
10
MAC MacKey (0316 || U || V || QEU || QEV || [Text2]),[Text2] 11
12
13
MAC MacKey (0216 || V || U || QEV || QEU || [Text1]),[Text1] 14
15
Figure B.2 Mutual Symmetric-Key Entity Authentication Scheme 16
17
The scheme is ‘asymmetric’, so two transformations are specified. U uses the 18
transformation specified in sub-clause B.8.1 to establish authenticity of, and 19
optionally obtain authenticated data from, V by means of sharing a key and 20
communicating cooperatively with V. V uses the transformation specified in sub- 21
clause B.8.2 to establish authenticity of, and optionally obtain authenticated data 22
from, U by means of sharing a key and communicating cooperatively with U. 23
24
The essential difference between the role of the initiator and the role of the 25
responder is that the initiator sends the first pass of the exchange. 26
Prerequisites: The following are the prerequisites for the use of the scheme: 27
28
1 Each entity has an authentic copy of the system’s challenge domain parameters 29
D=(minchallengelen, maxchallengelen). These parameters shall have been 30
generated using the parameter generation primitive in sub-clause B.3.1. 31
Furthermore, the parameters shall have been validated using the parameter 32
validation primitive in sub-clause B.3.2. 33
2 Each entity shall have access to a bit string MacKey of length mackeylen bits to 34
be used as the key. Each party shall have evidence that access to this key is 35
restricted to the entity itself and the other entity involved in the mutual entity 36
authentication scheme. 37
38
3 Each entity shall be bound to a unique identifier (e.g., distinguished names). 39
All identifiers shall be bit strings of the same length entlen bits. Entity U’s 40
identifier will be denoted by the bit string U. Entity V’s identifier will be 41
denoted by the bit string V. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter B
540 Security Building Blocks
4 Each entity shall have decided which MAC scheme to use as specified in
Section 5.7 of ANSI X9.63-2001 [B7]. The length in bits of the keys used by 1
the chosen MAC scheme is denoted by mackeylen. 2
3
5 A fixed representation of octets as binary strings shall have been chosen (e.g., 4
most-significant-bit-first order or least-significant-bit-first order). 5
6
B.8.1 Initiator Transformation 7
8
U shall execute the following transformation to establish authenticity of, and 9
optionally obtain authenticated data from, V by means of sharing a key and 10
communicating cooperatively with V. U shall obtain an authentic copy of V’s 11
identifier and an authentic copy of the secret key MacKey shared with V. 12
13
Input: The input to the initiator transformation is: 14
1 (Optional) A bit string Text2 that consists of some additional data to be 15
provided from U to V. 16
17
Ingredients: The initiator transformation employs the challenge generation 18
primitive specified in Section 5.3 of ANSI X9.63-2001 [B7], the challenge 19
validation primitive specified in sub-clause B.4, and one of the MAC schemes in 20
Section 5.7 of ANSI X9.63-2001 [B7]. 21
Actions: Entity authentication shall be established as follows: 22
23
1 Use the challenge generation primitive given in Section 5.3 of ANSI X9.63- 24
2001 [B7] to generate a challenge QEU for the challenge domain parameters D. 25
Send QEU to V. 26
2 Then receive from V a challenge QEV' purportedly owned by V. If this value is 27
not received, output ‘invalid’ and stop. 28
29
3 Verify that QEV' is a valid challenge for the challenge domain parameters D as 30
specified in sub-clause B.3.1. If the validation primitive rejects the challenge, 31
output ‘invalid’ and stop. 32
4 Form the bit string consisting of the octet 0316, U’s identifier, V’s identifier, the 33
bit string QEU corresponding to U’s challenge, the bit string QEV' 34
corresponding to V’s purported challenge, and optionally a bit string Text2: 35
36
MacData2 = 0316 || U || V || QEU || QEV' || [Text2]. 37
38
39
5 Calculate the tag MacTag2 on MacData2 under the key MacKey using the
40
tagging transformation of the appropriate MAC scheme specified in Section
41
5.7.1 of ANSI X9.63-2001 [B7]:
42
43
MacTag2 = MACMacKey (MacData2). 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 541
If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send
MacTag2 and, if present, bit string Text2 to V. 1
2
6 Receive from V an optional bit string Text1, and a purported tag MacTag1'. If 3
these values are not received, output ‘invalid’ and stop. 4
7 Form the bit string consisting of the octet 0216, V’s identifier, U’s identifier, the 5
bit string QEV' corresponding to V’s purported challenge, the bit string QEU 6
corresponding to U’s challenge, and if present Text1: 7
8
MacData1 = 0216 || V || U || QEV' || QEU || [Text1]. 9
10
11
8 Verify that MacTag1' is the tag for MacData1 under the key MacKey using the
12
tag checking transformation of the appropriate MAC scheme specified in
13
Section 5.7.2 of ANSI X9.63-2001 [B7]. If the tag checking transformation
14
outputs ‘invalid’, output ‘invalid’ and stop.
15
Output: If any of the above verifications has failed, then output ‘invalid’ and 16
reject the authenticity of V and reject the entity authentication from V. Otherwise, 17
output ‘valid’, accept the authenticity of V and accept the entity authentication 18
from V of the authenticated bit string Text1 (if present). 19
20
21
B.8.2 Responder Transformation 22
23
V shall execute the following transformation to establish authenticity, of and
24
optionally obtain authenticated data from, U by means of sharing a key and
25
communicating cooperatively with U. V shall obtain an authentic copy of U’s
26
identifier and an authentic copy of the secret key MacKey shared with U.
27
Input: The input to the responder transformation is: 28
29
1 A challenge QEU' purportedly owned by U.
30
2 (Optional) A bit string Text1 that consists of some additional data to be 31
provided from V to U. 32
33
Ingredients: The responder transformation employs the challenge generation
34
primitive specified in Section 5.3 of ANSI X9.63-2001 [B7], the challenge
35
validation primitive specified in sub-clause B.4, and one of the MAC schemes in
36
Section 5.7 of ANSI X9.63-2001 [B7].
37
Actions: Entity authentication shall be established as follows: 38
39
1 Verify that QEU' is a valid challenge for the challenge domain parameters D as
40
specified in sub-clause B.3.1. If the validation primitive rejects the challenge,
41
output ‘invalid’ and stop.
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter B
542 Security Building Blocks
A N N E X
1
C
2
3
4
5
6
7
8
9
BUILDING BLOCKS
12
13
14
15
This annex provides sample test vectors for the ZigBee community, aimed at with 16
the intent of assisting in building interoperable security implementations. The 17
sample test vectors are provided as is, pending independent validation. 18
19
20
C.1 Data Conversions 21
22
For test vectors, see Appendix J1 of ANSI X9.63-2001 [B7]. 23
24
25
C.2 AES Block Cipher 26
27
This annex provides sample test vectors for the block-cipher specified in sub- 28
clause B.1.1. 29
30
For test vectors, see FIPS Pub 197 [B8]. 31
32
33
C.3 CCM* Mode Encryption and Authentication 34
Transformation 35
36
37
This annex provides sample test vectors for the mode of operation as specified in
38
sub-clause B.1.2.
39
Prerequisites: The following prerequisites are established for the operation of the 40
mode of operation: 41
42
1 The parameter M shall have the integer value 8.
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex C
544 Test Vectors For Cryptographic Building
AuthData = 00 08 00 01 02 03 04 05 06 07 00 00 00 00 00 00 ||
08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 1
18 19 1A 1B 1C 1D 1E 00 00 00 00 00 00 00 00 00 2
3
4
C.3.2 Authentication Transformation 5
6
The data AuthData that was established above shall be tagged using the following 7
tagging transformation: 8
1 Form the 1-octet Flags field as follows: 9
10
Flags = 59 11
12
2 Form the 16-octet B0 field as follows: 13
14
B0 = 59 || A0 A1 A2 A3 A4 A5 A6 A7 03 02 01 00 06 || 00 17 15
3 Parse the message AuthData as B1 || B2 ||B3, where each message block Bi is a 16
16-octet string. 17
18
4 The CBC-MAC value X4 is calculated as follows: 19
20
i Bi Xi 21
22
0 59 A0 A1 A2 A3 A4 A5 A6 A7 03 02 01 00 06 00 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
23
1 00 08 00 01 02 03 04 05 06 07 00 00 00 00 00 00 F7 74 D1 6E A7 2D C0 B3 E4 5E 36 CA 8F 24 3B 1A 24
25
2 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 90 2E 72 58 AE 5A 4B 5D 85 7A 25 19 F3 C7 3A B3
26
3 18 19 1A 1B 1C 1D 1E 00 00 00 00 00 00 00 00 00 5A B2 C8 6E 3E DA 23 D2 7C 49 7D DF 49 BB B4 09 27
28
4 æ B9 D7 89 67 04 BC FA 20 B2 10 36 74 45 F9 83 D6
29
30
The authentication tag T is the result of omitting all but the leftmost M=8 octets of 31
the CBC-MAC value X4: 32
33
T = B9 D7 89 67 04 BC FA 20 34
35
C.3.3 Encryption Transformation 36
37
The data PlaintextData shall be encrypted using the following encryption 38
transformation: 39
40
1 Form the 1-octet Flags field as follows: 41
42
Flags = 01 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex C
546 Test Vectors For Cryptographic Building
AuthData = 08 00 01 02 03 04 05 06 07 00 00 00 00 00 00 00 ||
08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 1
18 19 1A 1B 1C 1D 1E 00 00 00 00 00 00 00 00 00 2
3
2 Use the authentication transformation in sub-clause C.3.2, with the message 4
AuthData to compute the authentication tag MACTag as input: 5
6
MACTag = B9 D7 89 67 04 BC FA 20 7
3 Compare the output tag MACTag resulting from this transformation with the 8
tag T that was established in sub-clause C.4.1 (step 9): 9
T = B9 D7 89 67 04 BC FA 20 = MACTag 10
11
Output: Since MACTag=T, output ‘valid’ and accept the octet string m and accept 12
one of the key sharing group member(s) as the source of m. 13
14
15
C.5 Cryptographic Hash Function 16
17
This annex provides sample test vectors for the cryptographic hash function 18
specified in clause C.5. 19
20
C.5.1 Test Vector Set 1 21
22
Input: The input to the cryptographic hash function is as follows: 23
24
1 The bit string M of length l=8 bits to be used: 25
26
M=C0 27
Actions: The hash value shall be derived as follows: 28
29
1 Pad the message M by right-concatenating to M the bit ‘1’ followed by the 30
smallest non-negative number of ‘0’ bits, such that the resulting string has 31
length 14 (mod 16) octets: 32
33
C0 || 80 00 00 00 00 00 00 00 00 00 00 00 00 34
2 Form the padded message M' by right-concatenating to the resulting string the 35
16-bit string that is equal to the binary representation of the integer l: 36
37
M' = C0 || 80 00 00 00 00 00 00 00 00 00 00 00 00 || 00 08 38
39
3 Parse the padded message M' as M1, where each message block Mi is a 16-octet 40
string. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex C
550 Test Vectors For Cryptographic Building
7 Form the padded message M2 by right-concatenating the bit string Key2 with
the bit string Hash1: 1
2
M2 = Key2 || Hash1 = 1C 1D 1E 1F 18 19 1A 1B 14 15 16 17 10 11 12 13 || 3
3C 3D 53 75 29 A7 A9 A0 3F 66 9D CD 88 6C B5 2C 4
5
8 Compute the hash value Hash2 of the bit string M2: 6
7
Hash2 = 45 12 80 7B F9 4C B3 40 0F 0E 2C 25 FB 76 E9 99 8
Output: the 16-octet string HMAC = Hash2 = 45 12 80 7B F9 4C B3 40 0F 0E 2C 9
25 FB 76 E9 99 10
11
12
C.6.2 Test Vector Set 2 13
14
Input: The input to the keyed hash function is as follows: 15
1 The key Key of size keylen=256 bits to be used: 16
Key = 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F || 17
50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 18
19
2 The bit string M of length l=128 bits to be used: 20
21
M = C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF 22
Actions: The keyed hash value shall be derived as follows: 23
24
1 Compute the hash value Key0 of the bit string Key: 25
26
Key0 = 22 F4 0C BE 15 66 AC CF EB 77 77 E1 C4 A9 BB 43 27
2 Create the 16-octet string ipad (inner pad) as follows: 28
29
ipad = 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 30
31
3 Form the inner key Key1 by XOR-ing the bit key Key0 and the octet string ipad: 32
33
Key1 = Key0 ¯ ipad = 14 C2 3A 88 23 50 9A F9 DD 41 41 D7 F2 9F 8D 75 34
4 Form the padded message M1 by right-concatenating the bit string Key1 with 35
the bit string M: 36
37
M1 = Key1 || M = 14 C2 3A 88 23 50 9A F9 DD 41 41 D7 F2 9F 8D 75 || 38
C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF 39
40
5 Compute the hash value Hash1 of the bit string M1: 41
42
Hash1 = 42 65 BE 29 74 55 8C A2 7B 77 85 AC 73 F2 22 10 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 553
• Keys are interpreted over-the-air as Little Endian, and used as Little Endian
values. 1
2
• Initiator and Responder Challenges are interpreted over-the-air as Little 3
Endian. They are concatenated in the bit strings also as Little Endian values. 4
• MacTag data is interpreted as Little Endian and sent over-the-air in the same 5
way as it is derived via the algorithms. 6
7
• Frame Counters are sent over-the-air as Little Endian, but are concatenated in 8
the bit strings as Big Endian. 9
Legend: 10
11
(<) Indicates the number is little-endian, e.g. (<)1234 displayed in big-endian 12
form is 0x3412. 13
(>) Indicates the number is big-endian. 14
15
C.6.4.2 SKKE Initiator Transform 16
17
Term Description 18
19
Key Shared key (i.e. Trust Center Master)
20
MacKey A key created during generation of keying data 21
22
U Initiator's unique ID (EUI64 Address) 23
24
V Responder's unique ID (EUI64 Address)
25
QEU Initiator challenge (16 byte random number) 26
27
QEV Responder challenge (16 byte random number) 28
29
MAC Our HMAC Function
30
Text1 Optional bit string. Not used in SKKE. 31
32
Text2 "" 33
34
Optional data shared between initiator and responder. An empty string for
SharedData SKKE / EA. 35
36
37
Note: '||' in this pseudo-code means concatenation 38
1 Responder's IEEE (V) must be known ahead of time 39
40
2 Generate Initiator Challenge QEU 41
3 Send Initiator Challenge and Initiator IEEE to Responder (SKKE-1) 42
43
4 Receive Responder Challenge, QEV (SKKE-2) 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 555
a Hash-1 = Z || 00 00 00 01 || SharedData
1
Bit String (before Hash) 2
0x4c 0x3f 0x60 0xa0 0x2e 0x07 0x13 0x5e 3
0xdf 0xad 0xb0 0xe0 0xc1 0x46 0xfd 0xe2 4
0x00 0x00 0x00 0x01 5
6
b Hash-2 = Z || 00 00 00 02 || SharedData 7
8
Bit String (before Hash) 9
0x4c 0x3f 0x60 0xa0 0x2e 0x07 0x13 0x5e 10
0xdf 0xad 0xb0 0xe0 0xc1 0x46 0xfd 0xe2 11
0x00 0x00 0x00 0x02 12
13
c KeyingData = Hash-1 || Hash-2 14
7 Parse Keying Data as follows: 15
16
a MacKey = First 128 bits (Hash-1) of KeyingData 17
18
0xaf 0x6e 0x2b 0x7a 0x59 0xc0 0x98 0xb0 19
0xcf 0x0a 0x93 0x1c 0x8b 0x34 0xcd 0xbd 20
21
b KeyData = Second 128 bits (Hash-2) of KeyingData 22
23
0x19 0xbb 0xfc 0x94 0x57 0x55 0xe7 0x09 24
0x86 0xe8 0x8b 0x5d 0x21 0x1c 0x97 0x37 25
26
8 Form the bit string MacData2. 27
a MacData2 = 03 || U || V || QEU || QEV || Text2 28
29
30
0x03 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x22 0x22 0x22 0x22 0x22 0x22 0x22 31
0x22 0x00 0x00 0x00 0x00 0x00 0x00 0x00 32
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 33
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 34
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 35
0x00 36
37
9 Calculate MacTag2. 38
39
a MacTag2 = MAC(MacData2, MacKey)
40
41
0xf9 0xa0 0x89 0x6c 0xe2 0x73 0x8d 0x71 42
0x34 0x3d 0x27 0x9b 0x51 0x3f 0x07 0x9c
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex C
558 Test Vectors For Cryptographic Building
A N N E X
1
D
2
3
4
5
6
7
8
9
CLARIFICATIONS
12
13
14
15
D.1 Introduction 16
17
18
D.1.1 Scope 19
20
This annex applies to the IEEE 802.15.4 2003 Medium Access Control sub-layer 21
(MAC) and Physical Layer (PHY) specification when used in conjunction with 22
higher layers defined by the ZigBee specification. Nothing is implied about the 23
usage under other circumstances. 24
25
26
D.1.2 Purpose 27
28
The current ZigBee specification assumes the use of the MAC and PHY sub- 29
layers defined in the IEEE 802.15.4 2003 specification. However, as developers 30
have put the MAC and PHY sub-layers into use, they have uncovered problems 31
that may or may not have been anticipated by the authors of the specification, or 32
are not covered in the IEEE 802.15.4 2003 specification. This document is 33
intended to provided solutions to such problems, for use by the ZigBee Alliance. 34
35
36
D.2 Stack Size Issues 37
38
Both MAC and ZigBee stack developers have discovered that implementation of a 39
full-blown MAC is a major undertaking and requires a great deal of code space. 40
Even with the optional GTS and MAC security features eliminated, it is not 41
surprising to find the MAC taking up more than 24K of code space on a processor 42
with 64K of available space. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex D
568 MAC and PHY Sub-Layer Clarifications
The ZigBee Alliance has adopted a compensating policy to declare MAC features
that are not required to support a particular stack profile optional with respect to 1
that stack profile. In particular, any MAC feature that will not be exploited as a 2
result of platform compliance testing for a particular stack profile need not be 3
present in order for an implementation to be declared platform compliant. For 4
example, since the ZigBee 2006 stack profile relies on a beaconless network, the 5
platform compliance testing for the stack profile does not employ beaconing. The 6
code to support regular beaconing, beacon track, and so on, may therefore be 7
absent from the code base of the device under test without the knowledge of the 8
testers, without presenting a problem with respect to platform compliance 9
certification. 10
11
12
D.3 MAC Association 13
14
At association time, according to the IEEE 802.15.4 2003 specification, a number 15
of frames are sent, including an association request command, an associate 16
response command and a data request. There is some ambiguity in the 17
specification regarding the addressing fields in the headers for these frames. 18
Tables D.1–D.3 outline the allowable options that shall be recognized by devices 19
implementing the ZigBee specification. In each case, the first option given is the 20
preferred option and should be used. 21
22
Table D.1 Associate Request Header Fields 23
DstPANId DstAddr SrcPANId SrcAddr 24
25
The PANId of the The 16-bit short 0xffff The 64-bit extended 26
destination device. address of the address of the source
destination device. device.
27
28
PANId omitted 29
because the IntraPAN
30
sub-field in the frame
control field is set to 31
one. 32
33
The PANId of the
destination device. 34
35
Not present if the Not present if the 36
destination device is destination device is
the PAN coordinator. the PAN coordinator. 37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 569
Note that in this case and the case below, the source of the command is the device
requesting association. 1
2
Table D.2 Data Request Header Fields
3
DstPANId DstAddr SrcPANId SrcAddr 4
5
The PANId of the The 16-bit short 0xffff The 64-bit extended 6
destination device. address of the address of the source
destination device. device. 7
8
PANId omitted 9
because the IntraPAN
sub-field in the frame 10
control field is set to 11
one. 12
The PANId of the 13
destination device. 14
15
Not present if the Not present if the
destination device is destination device is
16
the PAN coordinator. the PAN coordinator. 17
18
19
20
Table D.3 Association Response Header Fields 21
22
DstPANId DstAddr SrcPANId SrcAddr
23
The PANId of the The 64-bit extended PANId omitted The 64-bit extended 24
destination device. address of the because the IntraPAN address of the source 25
destination device. sub-field in the frame device.
26
control field is set to
one. 27
28
The PANId of the
29
source device.
30
0xffff 31
32
33
D.4 aMaxMACFrameSize 34
35
In the IEEE 802.15.4 2003 specification, there is a constant called 36
aMaxMACFrameSize which is defined as being aMaxPHYPacketSize - 37
aMaxFrameOverhead. This formula gives aMaxMACFrameSize = 127 - 25 = 102 38
bytes. The disagreement about this value relates to the aMaxFrameOverhead 39
parameter. The value of 25 for this parameter is not correct for a ZigBee network 40
in which only short addressing modes can be used. The ZigBee alliance decided 41
that, rather than arguing what the correct value of aMaxFrameOverhead should 42
be, an acceptable packet is defined as one that is less than aMaxPHYFrameSize 43
and is a decodable 802.15.4 and ZigBee packet. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex D
570 MAC and PHY Sub-Layer Clarifications
To facilitate this, the maximum sizes for the nsdulength parameters are defined as
less than aMaxPHYFrameSize -(nwkcMACFrameOverhead + 1
nwkcMinHeaderOverhead). Developers of ZigBee solutions therefore need to 2
ensure that their 802.15.4 implementations are able to accommodate this 3
enhancement. 4
5
6
D.5 Beacon Timing51 7
8
In order to employ the NWK beacon scheduling algorithm, it is necessary to 9
implement the following enhancement to the IEEE Std 802.15.4-2003 MAC sub- 10
layer. 11
12
A new parameter, StartTime, shall be added to the MLME-START.request 13
primitive to specify the time to begin transmitting beacons. The new format of the 14
primitive is as follows: 15
MLME-START.request {
16
17
PANID,
18
LogicalChannel,
19
BeaconOrder, 20
SuperframeOrder, 21
PANCoordinator, 22
BatteryLifeExtention, 23
CoordRealignment, 24
SecurityEnable, 25
StartTime 26
} 27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
51. LB #0160 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 571
The StartTime parameter is fully described in Table D.4, and the description of all
other parameters can be found in IEEE 802.15.4-2003 [B1]. 1
2
Table D.4 Start Time for Beacon Transmissions
3
Name Type Valid Range Description 4
5
StartTime Integer 0x000000 – 0xffffff The time at which to begin transmitting 6
beacons. If the device issuing the
primitive is the PAN coordinator, this 7
parameter is ignored and beacon 8
transmissions will begin immediately. 9
Otherwise, this parameter specifies the 10
time relative to its parent’s beacon. The 11
parameter is specified in symbols and is
rounded to a backoff slot boundary. The 12
precision of this value is a minimum of 13
20 bits, with the lowest 4 bits being the 14
least significant. 15
16
17
18
The value of macAutoRequest shall be set to the default value in IEEE 802.15.4 19
[B1].52 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
52. LB #1044 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter D
572 MAC and PHY Sub-Layer Clarifications
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
This page intentionally blank 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 573
A N N E X
1
E
2
3
4
5
6
7
8
9
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
This page intentionally blank 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.