Professional Documents
Culture Documents
Document 053474r20
1
2
3
4
5
6
7
8
9
10
11
ZIGBEE SPECIFICATION 12
13
14
15
16
17
18
19
ZigBee Document 053474r20
20
September 7, 2012 10:19 pm 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
September 19, 2012 35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007-2012 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 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
r18 June 16, 2009 ZigBee-2007 specification incorporating 31
errata: 08012
32
r19 September 28, 2010 ZigBee-2007 specification incorporating 33
errata described in document 105413r04 34
r20 September 18, 2012 ZigBee-2007 specification incorporating 35
errata described in 11-53778-r13 and 12- 36
0030-01 37
38
39
40
41
42
43
44
45
Copyright © 2007-2012 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
24
1.5.1 ZigBee/IEEE References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
vi Table of Contents
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 . . . . . . . . . . . . . . . . . . 24 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
11
the 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 . . . . . . 48 26
Table 2.18 APSME-REMOVE-ALL-GROUPS.request 27
Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 28
Table 2.19 APSME-REMOVE-ALL-GROUPS.confirm 29
Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 30
31
Table 2.20 Values of the Frame Type Sub-Field . . . . . . . . . . . . . . . . 52
32
Table 2.21 Values of the Delivery Mode Sub-Field . . . . . . . . . . . . . 53 33
Table 2.22 Values of the Fragmentation Sub-Field . . . . . . . . . . . . . . 56 34
Table 2.23 APS Sub-Layer Constants . . . . . . . . . . . . . . . . . . . . . . . . 60 35
Table 2.24 APS IB Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 36
Table 2.25 Group Table Entry Format . . . . . . . . . . . . . . . . . . . . . . . . 62 37
38
Table 2.26 apsMaxWindowSize by Endpoint Number . . . . . . . . . . . 63
39
Table 2.27 APS Sub-layer Status Values . . . . . . . . . . . . . . . . . . . . . . 75 40
Table 2.28 ZigBee Descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 41
Table 2.29 Fields of the Node Descriptor . . . . . . . . . . . . . . . . . . . . . 82 42
Table 2.30 Values of the Logical Type Field . . . . . . . . . . . . . . . . . . . 83 43
44
45
Copyright © 2007-2012 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 . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . 55
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 . . . . 73 21
Figure 2.13 Fragmented Data Transmission with a 22
Single Retransmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 23
24
Figure 2.14 Fragmented Data Transmission with Multiple
25
Retransmissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 26
Figure 2.15 Format of the Complex Descriptor . . . . . . . . . . . . . . . . . 81 27
Figure 2.16 Format of an Individual Complex Descriptor Field . . . . 81 28
Figure 2.17 Format of the MAC Capability Flags Field . . . . . . . . . . 84 29
Figure 2.18 Format of the Language and Character Set Field . . . . . . 91 30
31
Figure 2.19 Format of the ZDP Frame . . . . . . . . . . . . . . . . . . . . . . . . 98
32
Figure 2.20 Format of the NWK_addr_req Command . . . . . . . . . . . 100 33
Figure 2.21 Format of the IEEE_addr_req_Command Frame . . . . . . 102 34
Figure 2.22 Format of the Node_Desc_req Command Frame . . . . . . 104 35
Figure 2.23 Format of the Power_Desc_req Command Frame . . . . . 104 36
Figure 2.24 Format of the Simple_Desc_req Command Frame . . . . 105 37
38
Figure 2.25 Format of the Active_EP_req Command Frame . . . . . . 106
39
Figure 2.26 Format of the Match_Desc_req Command Frame . . . . . 107 40
Figure 2.27 Format of the Complex_Desc_req Command Frame . . . 108 41
Figure 2.28 Format of the User_Desc_req Command Frame . . . . . . 109 42
43
44
45
Copyright © 2007-2012 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 1
C HAPTER
1
2
1 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 the 12
868 MHz European band and the 915 MHz band, used in countries such as the United 13
States and Australia. The higher frequency PHY layer is used virtually worldwide. A 14
complete description of the IEEE 802.15.4-2003 PHY layers can be found in [B1]. 15
16
The IEEE 802.15.4-2003 MAC sub-layer controls access to the radio channel 17
using a CSMA-CA mechanism. Its responsibilities may also include transmitting 18
beacon frames, synchronization, and providing a reliable transmission 19
mechanism. A complete description of the IEEE 802.15.4-2003 MAC sub-layer 20
can be found in [B1]. 21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
Figure 1.1 Outline of the ZigBee Stack Architecture 42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 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-2012 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 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 for all ZigBee frames, and a value of 8
0x03 for the ZigBee Green Power frames.1 The protocol version support 9
required by various ZigBee specification revisions appears below in Table 1.1. 10
Table 1.1 ZigBee Protocol Versions 11
12
Protocol 13
Specification Version Comment
14
ZigBee Green 0x03 ZigBee Green Power feature See reference [B26]. 15
Power 16
ZigBee Pro 0x02 Backwards compatibility not required. ZigBee Pro 17
and ZigBee 2006 compatibility required.a 18
ZigBee 2006
19
ZigBee 2004 0x01 Original ZigBee version.
20
a. CCB 1361 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 t0 0x032, and shall process only protocol versions of 0x01 or 0x02, 40
41
42
1. CCB 1361 43
2. CCB 1361 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 1
8 ZigBee Protocol Overview
consistent with the protocol version of the network that the device participates
within. A ZigBee device that conforms to this specification shall pass the 1
frames carrying the protocol version sub-field value 0x03 to the ZGP stub (see 2
[B26]), if it supports the ZigBee Green Power, otherwise it shall drop them.3 3
4
1.4.1.2 ZigBee Definitions 5
6
For the purposes of this standard, the following terms and definitions apply. Terms 7
not defined in this clause can be found in IEEE P802.15.4 §3 [B1] or in ANSI 8
X9.63-2001 §2.1 [B7]. 9
Access control list: This is a table used by a device to determine which devices 10
are authorized to perform a specific function. This table may also store the 11
security material (e.g., cryptographic keys, frame counts, key counts, security 12
level information) used for securely communicating with other devices. 13
14
Active network key: This is the key used by a ZigBee device to secure 15
outgoing NWK frames and that is available for use to process incoming NWK 16
frames. 17
Alternate network key: This is a key available to process incoming NWK 18
frames in lieu of the active network key. 19
20
Application domain: This describes a broad area of applications, such as 21
building automation. 22
Application key: This is a master key or a link key transported by the Trust 23
center to a device for the purpose of securing end-to-end communication. 24
25
Application object: This is a component of the top portion of the application 26
layer defined by the manufacturer that actually implements the application. 27
Application profile: This is a collection of device descriptions, which together 28
form a cooperative application. For instance, a thermostat on one node 29
communicates with a furnace on another node. Together, they cooperatively 30
form a heating application profile. 31
32
Application support sub-layer protocol data unit: This is a unit of data that 33
is exchanged between the application support sub-layers of two peer entities. 34
APS command frame: This is a command frame from the APSME on a device 35
addressed to the peer entity on another device. 36
37
Association: This is the service provided by the IEEE 802.15.4-2003 MAC 38
sub-layer that is used to establish membership in a network. 39
Attribute: This is a data entity which represents a physical quantity or state. 40
This data is communicated to other devices using commands. 41
42
43
3. CCB 1361 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 9
Key transport: This is a mechanism for communicating a key from one device
to another device or other devices. 1
2
Key-transport key: This is a key derived from a link key used to protect key 3
transport messages carrying a key other than a master key. 4
Key update: This is a mechanism implementing the replacement of a key 5
shared amongst two or more devices by means of another key available to that 6
same group. 7
8
Local device: This is the initiator of a ZDP command. 9
Link key: This is a key that is shared exclusively between two, and only two, 10
peer application-layer entities within a PAN. 11
12
Master key: This is a shared key used during the execution of a symmetric-key 13
key establishment protocol. The master key is the basis for long-term security 14
between the two devices, and may be used to generate link keys. 15
Mesh network: This is a network in which the routing of messages is 16
performed as a decentralized, cooperative process involving many peer devices 17
routing on each other’s behalf. 18
19
Multicast: This is a transmission to every device in a particular PAN 20
belonging to a dynamically defined multicast group, and within a given 21
transmission radius measured in hops. 22
Multihop network: This is a network, in particular a wireless network, in 23
which there is no guarantee that the transmitter and the receiver of a given 24
message are connected or linked to each other. This implies that intermediate 25
devices must be used as routers. 26
27
Non-beacon-enabled personal area network: This is a personal area network 28
that does not contain any devices that transmit beacon frames at a regular 29
interval. 30
Neighbor table: This is a table used by a ZigBee device to keep track of other 31
devices within the POS. 32
33
Network address: This is the address assigned to a device by the network 34
layer and used by the network layer for routing messages between devices. 35
Network broadcast delivery time: This is the time required by a broadcast 36
transaction to reach every device of a given network. 37
38
Network manager: This is a ZigBee device that implements network 39
management functions as described in Clause 3, including PAN ID conflict 40
resolution and frequency agility measures in the face of interference. 41
Network protocol data unit: This is a unit of data that is exchanged between 42
the network layers of two peer entities. 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 1
12 ZigBee Protocol Overview
Network service data unit: This is the information that is delivered as a unit
through a network service access point. 1
2
Node: This is a collection of independent device descriptions and applications 3
residing in a single unit and sharing a common 802.15.4 radio. 4
Normal operating state: This is the processing which occurs after all startup 5
and initialization processing has occurred and prior to initiation of shutdown 6
processing. 7
8
NULL: a parameter or variable value that means unspecified, undefined, or 9
unknown. The exact value of NULL is implementation-specific, and must not 10
conflict with any other parameters or values. 11
Octet: eight bits of data, used as a synonym for a byte. 12
13
OctetDuration: transmission time (in seconds) of an octet on PHY layer. This 14
time is calculated as 8/phyBitRate where phyBitRate can be found in Table 1 of 15
IEEE 802.15.4 2003 standard. To get milliseconds from N OctetDurations for 16
2.4 GHz the follow formula has to be used: N*(8/250000)*1000 where 250000 17
bit rate on 2.4 GHz and 8 number of bits in one octet.4 18
One-way function: a function whose forward computation is much easier to 19
perform than its inverse.5 20
21
Orphaned device: a device, typically a ZigBee end device, that has lost 22
communication with the ZigBee device through which it has its PAN 23
membership. 24
PAN coordinator: the principal controller of an IEEE 802.15.4-2003-based 25
network that is responsible for network formation. The PAN coordinator must 26
be a full function device (FFD). 27
28
PAN information base: a collection of variables in the IEEE 802.15.4-2003 29
standard that are passed between layers, in order to exchange information. This 30
database may include the access control list, which stores the security material. 31
Personal operating space: the area within reception range of a single device. 32
33
Private method: attributes and commands which are accessible to ZigBee 34
device objects only and unavailable to the end applications. 35
Protocol data unit: the unit of data that is exchanged between two peer 36
entities. 37
38
Public method: attributes and commands which are accessible to end 39
applications. 40
41
42
4. ZigBee Document 12-0220-04 43
5. ZigBee Document 12-0220-04 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 13
Radio: the IEEE 802.15.4-2003 radio that is part of every ZigBee device.
1
Remote device: the target of a ZDP command. 2
Route discovery: an operation in which a ZigBee coordinator or ZigBee router 3
attempts to discover a route to a remote device by issuing a route request 4
command frame. 5
6
Route discovery table: a table used by a ZigBee coordinator or ZigBee router 7
to store temporary information used during route discovery. 8
Route reply: a ZigBee network layer command frame used to reply to route 9
requests. 10
11
Route request: a ZigBee network layer command frame used to discover paths 12
through the network over which subsequent messages may be delivered. 13
Routing table: a table in which a ZigBee coordinator or ZigBee router stores 14
information required to participate in the routing of frames. 15
16
Service discovery: the ability of a device to locate services of interest. 17
Stack profile: an agreement by convention outside the scope of the ZigBee 18
specification on a set of additional restrictions with respect to features declared 19
optional by the specification itself. 20
21
Symmetric-key key establishment: a mechanism by which two parties 22
establish a shared secret, based on a pre-shared secret (a so-called master key). 23
Trust center: the device trusted by devices within a ZigBee network to 24
distribute keys for the purpose of network and end-to-end application 25
configuration management. 26
27
Unicast: the transmission of a message to a single device in a network. 28
ZigBee coordinator: an IEEE 802.15.4-2003 PAN coordinator. 29
30
ZigBee device object: the portion of the application layer responsible for 31
defining the role of the device within the network (e.g., ZigBee coordinator or 32
end device), initiating and/or responding to binding and discovery requests, and 33
establishing a secure relationship between network devices. 34
ZigBee end device: an IEEE 802.15.4-2003 RFD or FFD participating in a 35
ZigBee network, which is neither the ZigBee coordinator nor a ZigBee router. 36
37
ZigBee router: an IEEE 802.15.4-2003 FFD participating in a ZigBee 38
network, which is not the ZigBee coordinator but may act as an IEEE 802.15.4- 39
2003 coordinator within its personal operating space, that is capable of routing 40
messages between devices and supporting associations. 41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 1
14 ZigBee Protocol Overview
1.5 References 1
2
The following standards contain provisions, which, through reference in this 3
document, constitute provisions of this standard. Normative references are given 4
in “ZigBee/IEEE References,” and “Normative References,” and informative 5
references are given in “Informative References.” At the time of publication, the 6
editions indicated were valid. All standards are subject to revision, and parties to 7
agreements based on this standard are encouraged to investigate the possibility of 8
applying the most recent editions of the references, as indicated in this sub-clause. 9
10
1.5.1 ZigBee/IEEE References 11
12
[B1] Institute of Electrical and Electronics Engineers, Inc., IEEE Std. 802.15.4- 13
2003, IEEE Standard for Information Technology — Telecommunications and 14
Information Exchange between Systems — Local and Metropolitan Area 15
Networks — Specific Requirements — Part 15.4: Wireless Medium Access 16
Control (MAC) and Physical Layer (PHY) Specifications for Low Rate 17
Wireless Personal Area Networks (WPANs). New York: IEEE Press. 2003. 18
19
[B2] IEEE 754-1985, IEEE Standard for Binary Floating-Point Arithmetic, 20
IEEE, 1985. 21
[B3] Document 03285r0: Suggestions for the Improvement of the IEEE 22
802.15.4 Standard, July 2003. 23
24
[B4] Document 02055r4: Network Requirements Definition, August 2003. 25
26
1.5.2 Normative References 27
28
[B5] ISO/IEC 639-1:2002 Codes for the representation of names of languages 29
— Part 1: Alpha-2 code. 30
31
[B6] ISO/IEC 646:199 Information technology — ISO 7-bit coded character 32
set for information interchange. 33
[B7] ANSI X9.63-2001, Public Key Cryptography for the Financial Services 34
Industry - Key Agreement and Key Transport Using Elliptic Curve 35
Cryptography, American Bankers Association, November 20, 2001. Available 36
from http://www.ansi.org. 37
38
[B8] FIPS Pub 197, Advanced Encryption Standard (AES), Federal 39
Information Processing Standards Publication 197, US Department of 40
Commerce/N.I.S.T, Springfield, Virginia, November 26, 2001. Available from 41
http://csrc.nist.gov/. 42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 15
[B9] FIPS Pub 198, The Keyed-Hash Message Authentication Code (HMAC),
Federal Information Processing Standards Publication 198, US Department of 1
Commerce/N.I.S.T., Springfield, Virginia, March 6, 2002. Available from 2
http://csrc.nist.gov/. 3
4
[B10] ISO/IEC 9798-2, Information Technology - Security Techniques — 5
Entity Authentication Mechanisms — Part 2: Mechanisms Using 6
Symmetric Encipherment Algorithms, International Standardization 7
Organization, Geneva, Switzerland, 1994 (first edition). Available from 8
http://www.iso.org/. 9
[B11] NIST Pub 800-38A 2001 ED, Recommendation for Block Cipher Modes 10
of Operation — Methods and Techniques, NIST Special Publication 800-38A, 11
2001 Edition, US Department of Commerce/N.I.S.T., December 2001. 12
Available from http://csrc.nist.gov/. 13
14
[B12] NIST, Random Number Generation and Testing. Available from http:// 15
csrc.nist.gov/rng/. 16
17
1.5.3 Informative References 18
19
[B13] FIPS Pub 140-2, Security requirements for Cryptographic Modules, US 20
Department of Commerce/N.I.S.T., Springfield, Virginia, June 2001 21
(supersedes FIPS Pub 140-1). Available from http://csrc.nist.gov/. 22
23
[B14] IEEE Standards Style Manual, published and distributed in May 2000 24
and revised on September 20, 2001. Available from http://standards.ieee.org/ 25
guides/style/. 26
[B15] ISO/IEC 7498-1:1994 Information technology — Open systems 27
interconnection — Basic reference model: The basic model. 28
29
[B16] ISO/IEC 10731:1994, Information technology — Open Systems 30
Interconnection — Conventions for the definition of OSI services. 31
[B17] ISO/IEC 9646-1:1991, Information technology — Open systems 32
Interconnection — Conformance testing methodology and framework — Part 33
1: General concepts. 34
35
[B18] ISO/IEC 9646-7:1995, Information technology — Open Systems 36
Interconnection — Conformance testing methodology and framework — Part 37
7. Implementation conformance statements. 38
[B19] A.J. Menezes, P.C. van Oorschot, S.A. Vanstone, Handbook of Applied 39
Cryptography, Boca Raton: CRC Press, 1997. 40
41
[B20] FIPS Pub 113, Computer Data Authentication, Federal Information 42
Processing Standard Publication 113, US Department of Commerce/N.I.S.T., 43
May 30, 1985. Available from http://csrc.nist.gov/. 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 1
16 ZigBee Protocol Overview
C HAPTER
1
2
2 3
4
5
6
7
8
9
The ZDO presents public interfaces to the application objects in the application
framework layer for control of device and network functions by the application 1
objects. The ZDO interfaces with the lower portions of the ZigBee protocol stack, 2
on endpoint 0, through the APSDE-SAP for data, and through the APSME-SAP 3
and NLME-SAP for control messages. The public interface provides address 4
management of the device, discovery, binding, and security functions within the 5
application framework layer of the ZigBee protocol stack. The ZDO is fully 6
described in clause 2.5. 7
8
2.1.3.1 Device Discovery 9
10
Device discovery is the process whereby a ZigBee device can discover other 11
ZigBee devices. There are two forms of device discovery requests: IEEE address 12
requests and NWK address requests. The IEEE address request is unicast to a 13
particular device and assumes the NWK address is known. The NWK address 14
request is broadcast and carries the known IEEE address as data payload. 15
16
2.1.3.2 Service Discovery 17
Service discovery is the process whereby the capabilities of a given device are 18
discovered by other devices. Service discovery can be accomplished by issuing a 19
query for each endpoint on a given device or by using a match service feature 20
(either broadcast or unicast). The service discovery facility defines and utilizes 21
various descriptors to outline the capabilities of a device. 22
23
Service discovery information may also be cached in the network in the case 24
where the device proffering a particular service may be inaccessible at the time 25
the discovery operation takes place. 26
27
28
2.2 ZigBee Application Support (APS) Sub-Layer 29
30
31
2.2.1 Scope 32
33
This clause specifies the portion of the application layer providing the service 34
specification and interface to both the manufacturer-defined application objects 35
and the ZigBee device objects. The specification defines a data service to allow 36
the application objects to transport data, and a management service providing 37
mechanisms for binding. In addition, it also defines the application support sub- 38
layer frame format and frame-type specifications. 39
40
2.2.2 Purpose 41
42
The purpose of this clause is to define the functionality of the ZigBee application 43
support (APS) sub-layer. This functionality is based on both the driver 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
20 Application Layer Specification
The APSME shall provide the ability to match two devices together based on their
services and their needs. This service is called the binding service, and the 1
APSME shall be able to construct and maintain a table to store this information. 2
3
In addition, the APSME will provide the following services: 4
• Binding management: this is the ability to match two devices together based 5
on their services and their needs. 6
7
• AIB management: the ability to get and set attributes in the device’s AIB. 8
• Security: the ability to set up authentic relationships with other devices 9
through the use of secure keys. 10
11
• Group management: this provides the ability to declare a single address 12
shared by multiple devices, to add devices to the group, and to remove devices 13
from the group. 14
15
2.2.4 Service Specification 16
17
The APS sub-layer provides an interface between a next higher layer entity 18
(NHLE) and the NWK layer. The APS sub-layer conceptually includes a 19
management entity called the APS sub-layer management entity (APSME). This 20
entity provides the service interfaces through which sub-layer management 21
functions may be invoked. The APSME is also responsible for maintaining a 22
database of managed objects pertaining to the APS sub-layer. This database is 23
referred to as the APS sub-layer information base (AIB). Figure 2.1 depicts the 24
components and interfaces of the APS sub-layer. 25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
22 Application Layer Specification
1
Next Higher Layer Entity 2
3
4
APSDE-SAP APSME-SAP 5
6
APSME 7
8
APSDE
APS 9
IB 10
11
12
NLDE-SAP NLME-SAP 13
14
NWK Layer Entity 15
16
17
Figure 2.1 The APS Sub-Layer Reference Model 18
19
The APS sub-layer provides two services, accessed through two service access 20
points (SAPs). These are the APS data service, accessed through the APS sub- 21
layer data entity SAP (APSDE-SAP), and the APS management service, accessed 22
though the APS sub-layer management entity SAP (APSME-SAP). These two 23
services provide the interface between the NHLE and the NWK layer, via the 24
NLDE-SAP and, to a limited extent, NLME-SAP interfaces (see sub-clause 3.1). 25
The NLME-SAP interface between the NWK layer and the APS sub-layer 26
supports only the NLME-GET and NLME-SET primitives; all other NLME-SAP 27
primitives are available only via the ZDO (see sub-clause 2.5). In addition to these 28
external interfaces, there is also an implicit interface between the APSME and the 29
APSDE that allows the APSME to use the APS data service. 30
31
2.2.4.1 APS Data Service 32
33
The APS sub-layer data entity SAP (APSDE-SAP) supports the transport of 34
application protocol data units between peer application entities. Table 2.1 lists 35
the primitives supported by the APSDE-SAP. Each of these primitives will be 36
discussed in the following sub-clauses. 37
Table 2.1 APSDE-SAP Primitives 38
39
APSDE-
SAP 40
Primitive Request Confirm Indication 41
42
APSDE- 2.2.4.1.1 2.2.4.1.2 2.2.4.1.3 43
DATA
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 23
2.2.4.1.1 APSDE-DATA.request
1
This primitive requests the transfer of a NHLE PDU (ASDU) from the local 2
NHLE to one or more peer NHLE entities. 3
4
2.2.4.1.1.1 Semantics of the Service Primitive 5
6
The semantics of this primitive are as follows:
7
APSDE-DATA.request { 8
DstAddrMode, 9
DstAddress, 10
DstEndpoint, 11
ProfileId,
12
13
ClusterId,
14
SrcEndpoint,
15
ADSULength, 16
ADSU, 17
TxOptions, 18
RadiusCounter 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
24 Application Layer Specification
processes each binding table entry as described above; until no more binding table
entries remain. If this primitive was received by the APSDE of a device that does 1
not support a binding table, the APSDE issues the APSDE-DATA.confirm 2
primitive with a status of NOT_SUPPORTED. 3
4
If the DstAddrMode parameter is set to 0x03, the DstAddress parameter contains 5
an extended 64-bit IEEE address and must first be mapped to a corresponding 16- 6
bit NWK address by using the nwkAddressMap attribute of the NIB (see 7
Table 3.43). If a corresponding 16-bit NWK address could not be found, the 8
APSDE issues the APSDE-DATA.confirm primitive with a status of 9
NO_SHORT_ADDRESS. If a corresponding 16-bit NWK address is found, it will 10
be used in the invocation of the NLDE-DATA.request primitive and the value of 11
the DstEndpoint parameter will be placed in the resulting APDU. The delivery 12
mode sub-field of the frame control field of the APS header shall have a value of 13
0x00 in this case. 14
If the DstAddrMode parameter has a value of 0x01, indicating group addressing, 15
the DstAddress parameter will be interpreted as a 16-bit group address. This 16
address will be placed in the group address field of the APS header, the 17
DstEndpoint parameter will be ignored, and the destination endpoint field will be 18
omitted from the APS header. The delivery mode sub-field of the frame control 19
field of the APS header shall have a value of 0x03 in this case. 20
21
If the DstAddrMode parameter is set to 0x02, the DstAddress parameter contains 22
a 16-bit NWK address, and the DstEndpoint parameter is supplied. The next 23
higher layer should only employ DstAddrMode of 0x02 in cases where the 24
destination NWK address is employed for immediate application responses and 25
the NWK address is not retained for later data transmission requests. 26
The application may limit the number of hops a transmitted frame is allowed to 27
travel through the network by setting the RadiusCounter parameter of the NLDE- 28
DATA.request primitive to a non-zero value. 29
30
If the DstAddrMode parameter has a value of 0x01, indicating group addressing, 31
or the DstAddrMode parameter has a value of 0x00 and the corresponding binding 32
table entry contains a group address, then the APSME will check the value of the 33
nwkUseMulticast attribute of the NIB (see Table 3.44). If this attribute has a value 34
of FALSE, then the delivery mode sub-field of the frame control field of the 35
resulting APDU will be set to 0b11, the 16-bit address of the destination group 36
will be placed in the group address field of the APS header of the outgoing frame, 37
and the NSDU frame will be transmitted as a broadcast. A value of 0xfffd, that is, 38
the broadcast to all devices for which macRxOnWhenIdle = TRUE, will be 39
supplied for the DstAddr parameter of the NLDE-DATA.request that is used to 40
transmit the frame. If the nwkUseMulticast attribute has a value of TRUE, then the 41
outgoing frame will be transmitted using NWK layer multicast, with the delivery 42
mode sub-field of the frame control field of the APDU set to 0b10, the destination 43
endpoint field set to 0xff, and the group address not placed in the APS header. 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 27
Under all other circumstances, the APSDE sets the Status parameter to
SUCCESS. 1
2
If the Status parameter is not set to SUCCESS, the APSDE sets the ASDULength 3
parameter to 0 and the ASDU parameter to the null set of bytes. 4
The APS sub-layer entity shall attempt to map the source address from the 5
received frame to its corresponding extended 64-bit IEEE address by using the 6
nwkAddressMap attribute of the NIB (see Table 3.43). If a corresponding 64-bit 7
IEEE address was found, the APSDE issues this primitive with the SrcAddrMode 8
parameter set to 0x03 and the SrcAddress parameter set to the corresponding 64- 9
bit IEEE address. If a corresponding 64-bit IEEE address was not found, the 10
APSDE issues this primitive with the SrcAddrMode parameter set to 0x02, and 11
the SrcAddress parameter set to the 16-bit source address as contained in the 12
received frame. 13
14
2.2.4.1.3.3 Effect on Receipt 15
16
On receipt of this primitive, the next higher layer is notified of the arrival of data 17
at the device. 18
19
2.2.4.2 APS Management Service 20
21
The APS management entity SAP (APSME-SAP) supports the transport of
22
management commands between the next higher layer and the APSME. Table 2.5
23
summarizes the primitives supported by the APSME through the APSME-SAP
24
interface. See the following sub-clauses for more details on the individual
25
primitives.
26
Table 2.5 Summary of the Primitives Accessed Through the APSME-SAP 27
Name Request Indication Response Confirm 28
29
APSME-BIND 2.2.4.3.1 2.2.4.3.2 30
APSME-UNBIND 2.2.4.3.3 2.2.4.3.4 31
32
APSME-GET 2.2.4.4.1 2.2.4.4.2
33
APSME-SET 2.2.4.4.3 2.2.4.4.4 34
APSME-ADD-GROUP 2.2.4.5.1 2.2.4.5.2 35
36
APSME-REMOVE- 2.2.4.5.3 2.2.4.5.4 37
GROUP
38
APSME-REMOVE- 2.2.4.5.5 2.2.4.5.6 39
ALL-GROUPS 40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
34 Application Layer Specification
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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 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-2012 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 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 - 0xfe 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-2012 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 - 0xfe 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 47
may not be included in all frames. The general APS frame shall be formatted as
illustrated in Figure 2.2. 1
2
Octets 0/ 3
:1 0/1 0/2 0/2 0/2 0/1 1 Variable Variable 4
Frame Destination Group Cluster Profile Source APS Extended Frame 5
control endpoint addres identifier identifier endpoint counter header payload 6
s 7
Addressing fields 8
9
APS header APS 10
payload
11
Figure 2.2 General APS Frame Format 12
13
2.2.5.1.1 Frame Control Field 14
15
The frame control field is 8-bits in length and contains information defining the
16
frame type, addressing fields, and other control flags. The frame control field shall
17
be formatted as illustrated in Figure 2.3.
18
Bits: 0-1 2-3 4 5 6 7 19
20
Frame type Delivery mode Ack. format Security Ack. request Extended 21
header 22
present
23
Figure 2.3 Format of the Frame Control Field 24
25
2.2.5.1.1.1 Frame Type Sub-Field 26
27
The frame type sub-field is two bits in length and shall be set to one of the non- 28
reserved values listed in Table 2.20. 29
Table 2.20 Values of the Frame Type Sub-Field 30
31
Frame Type Value 32
b1 b0 Frame Type Name
33
00 Data 34
01 Command 35
36
10 Acknowledgement 37
11 Reserved 38
39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 53
and interpretation of messages at each device that takes delivery of the frame.
This field shall be present only for data or acknowledgement frames. 1
2
2.2.5.1.5 Profile Identifier Field 3
The profile identifier is two octets in length and specifies the ZigBee profile 4
identifier for which the frame is intended and shall be used during the filtering of 5
messages at each device that takes delivery of the frame. This field shall be 6
present only for data or acknowledgement frames. 7
8
2.2.5.1.6 Source Endpoint Field 9
The source endpoint field is eight-bits in length and specifies the endpoint of the 10
initial originator of the frame. A source endpoint value of 0x00 indicates that the 11
frame originated from the ZigBee device object (ZDO) resident in each device. A 12
source endpoint value of 0x01-0xfe indicates that the frame originated from an 13
application operating on that endpoint. 14
15
2.2.5.1.7 APS Counter 16
17
This field is eight bits in length and is used as described in sub-clause 2.2.8.4.2 to
18
prevent the reception of duplicate frames. This value shall be incremented by one
19
for each new transmission.
20
2.2.5.1.8 Extended Header Sub-Frame 21
22
The extended header sub-frame contains further sub-fields and shall be formatted 23
as illustrated in Figure 2.4. 24
Octets: 1 0/1 0/1 25
26
Extended frame control Block number ACK bitfield 27
28
Figure 2.4 Format of the Extended Header Sub-Frame
29
2.2.5.1.8.1 Extended Frame Control Field 30
31
The extended frame control field is eight-bits in length and contains information 32
defining the use of fragmentation. The extended frame control field shall be 33
formatted as illustrated in Figure 2.5. 34
35
Bits: 0-1 2-7 36
Fragmentation Reserved 37
38
Figure 2.5 Format of the Extended Frame Control Field 39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
56 Application Layer Specification
The fragmentation sub-field is two bits in length and shall be set to one of the non-
reserved values listed in Table 2.22. 1
2
Table 2.22 Values of the Fragmentation Sub-Field
3
Fragmentation Value 4
b1 b 0 Description 5
6
00 Transmission is not fragmented.
7
01 Frame is first fragment of a 8
fragmented transmission. 9
10 Frame is part of a fragmented 10
transmission but not the first part. 11
11 Reserved 12
13
14
2.2.5.1.8.2 Block Number 15
The block number field is one octet in length and is used for fragmentation control 16
as follows: If the fragmentation sub-field is set to indicate that the transmission is 17
not fragmented then the block number field shall not be included in the sub-frame. 18
If the fragmentation sub-field is set to 01, then the block number field shall be 19
included in the sub-frame and shall indicate the number of blocks in the 20
fragmented transmission. If the fragmentation sub-field is set to 10, then the block 21
number field shall be included in the sub-frame and shall indicate which block 22
number of the transmission the current frame represents, taking the value 0x01 for 23
the second fragment, 0x02 for the third, etc. 24
25
2.2.5.1.8.3 Ack Bitfield 26
27
The ack bitfield field is one octet in length and is used in an APS 28
acknowledgement as described in sub-clause 2.2.8.4.5.2 to indicate which blocks 29
of a fragmented ASDU have been successfully received. This field is only present 30
if the frame type sub-field indicates an acknowledgement and the fragmentation 31
sub-field indicates a fragmented transmission. 32
2.2.5.1.9 Frame Payload Field 33
34
The frame payload field has a variable length and contains information specific to 35
individual frame types. 36
37
2.2.5.2 Format of Individual Frame Types 38
39
There are three defined frame types: data, APS command, and acknowledgement.
40
Each of these frame types is discussed in the following sub-clauses.
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 57
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. The extended header field shall 7
be included in a data frame according to the value of the extended header present 8
sub-field of the frame control field. 9
In the frame control field, the frame type sub-field shall contain the value that 10
indicates an acknowledgement frame, as shown in Table 2.20. The extended 11
header present sub-field shall contain the same value as in the frame to which this 12
frame is an acknowledgement. All other sub-fields shall be set appropriately 13
according to the intended use of the acknowledgement frame. 14
15
If the ack format field is set in the frame control field, the frame is an APS 16
command frame acknowledgement and the destination endpoint, cluster identifier, 17
profile identifier and source endpoint fields shall not be included. Alternatively, if 18
an APS data frame is being acknowledged, the source endpoint field shall reflect 19
the value in the destination endpoint field of the frame that is being 20
acknowledged. Similarly, the destination endpoint field shall reflect the value in 21
the source endpoint field of the frame that is being acknowledged. And the Cluster 22
identifier and Profile identifier fields shall contain the same values as in the frame 23
to which this frame is an acknowledgement. 24
The APS counter field shall contain the same value as the frame to which this 25
frame is an acknowledgment. 26
27
Where the extended header is present, the fragmentation sub-field of the extended 28
frame control field shall contain the same value as in the frame to which this 29
frame is an acknowledgement. If fragmentation is in use for this frame, then the 30
block number and ack bitfield fields shall be present. Where present, the block 31
number field shall contain block number to which this frame is an 32
acknowledgement. If fragmentation is in use, the acknowledgement frames shall 33
be issued according to sub-clause 2.2.8.4.5.2 and not for each received frame 34
unless the transmission window size is set to request acknowledgement of each 35
frame. 36
37
2.2.6 Command Frames 38
39
This specification defines no command frames. Refer to sub-clause 4.4.9 for a 40
thorough description of the APS command frames and primitives related to 41
security. 42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
60 Application Layer Specification
where:
1
gi = the ith group represented in the table. 2
epij = the jth endpoint associated with the ith group. 3
4
5
Implementers of this specification are free to implement the group table in any
6
manner that is convenient and efficient, as long as it represents the associations
7
just described.
8
2.2.8.4 Transmission, Reception, and Acknowledgement 9
10
This sub-clause describes the fundamental procedures for transmission, reception, 11
and acknowledgement. 12
13
2.2.8.4.1 Transmission
14
Only those devices that are currently part of a network shall send frames from the 15
APS sub-layer. If any other device receives a request to transmit a frame, it shall 16
discard the frame and notify the instigating layer of the error. An APSDE- 17
DATA.confirm primitive with a status of CHANNEL_ACCESS_FAILURE 18
indicates that the attempt at transmission of the frame was unsuccessful due to the 19
channel being busy. 20
21
All frames handled by or generated within the APS sub-layer shall be constructed 22
according to the general frame format specified in sub-clause 2.2.5.1 and 23
transmitted using the NWK layer data service. 24
Transmissions employing delivery modes 0b00 (Normal Unicast) and 0b10 25
(Broadcast) shall include both the source endpoint and destination endpoint fields. 26
Group addressed transmissions, having a delivery mode sub-field value of 0b11 27
shall contain a source endpoint field and group address field, but no destination 28
endpoint field. Note that other endpoints on the source device are legal group 29
members and possible destinations for group-addressed frames. 30
31
For all devices where the transmission is due to a binding table entry stored on the 32
source device, the APSDE of the source device shall determine whether the 33
binding table entry contains a unicast destination device address or a destination 34
group address. In the case where a binding table entry contains a unicast 35
destination device address and this destination device address is that of the source 36
device itself, the APSDE shall issue an APSDE-DATA.indication primitive to the 37
next higher layer and shall not transmit a frame. Otherwise, the APSDE shall 38
transmit the frame to the 16-bit NWK address corresponding to the destination 39
address indicated by the binding table entry, and the delivery mode sub-field of 40
the frame control field shall be set to 0b00. In the case where the binding table 41
entry contains a destination group address and nwkUseMulticast is FALSE, the 42
delivery mode sub-field of the frame control field shall have a value of 0b11, the 43
destination group address shall be placed in the APS header, and the destination 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 67
endpoint shall be omitted. The frame shall then be broadcast using the NLDE-
DATA.request primitive and employing a broadcast address of 0xfffd. In the case 1
where the binding table entry contains a destination group address and 2
nwkUseMulticast is TRUE, the delivery mode sub-field of the frame control field 3
shall have a value of 0b10 and the destination endpoint shall have a value of 0xff. 4
The frame shall then be multicast using the NLDE-DATA.request primitive and 5
employing the group address supplied in the binding table entry. 6
7
If security is required, the frame shall be processed as described in clause 4.4. 8
If fragmentation is required, and is permitted for this frame, then the frame shall 9
be processed as described in clause 2.2.8.4.5. 10
11
When the frame is constructed and ready for transmission, it shall be passed to the 12
NWK data service with suitable destination and source addresses. In addition, the 13
APS layer shall ensure that route discovery is enabled at the network layer. An 14
APDU transmission is initiated by issuing the NLDE-DATA.request primitive to 15
the NWK layer and the results of the transmission returned via the NLDE- 16
DATA.confirm primitive. 17
2.2.8.4.2 Reception and Rejection 18
19
The APS sub-layer shall be able to filter frames arriving via the NWK layer data 20
service and only present the frames that are of interest to the NHLE. 21
If the APSDE receives a secured frame, it shall process the frame as described in 22
clause 4.4 to remove the security. 23
24
If the APSDE receives a frame containing the destination endpoint field, then the 25
APSDE shall pass it directly to the NHLE at the destination endpoint supplied, 26
unless it is part of an incomplete fragmented transmission or it is determined to 27
have been a duplicate of a frame that has been passed up previously. Subject to the 28
same incomplete fragmented transmission and duplicate frame detection, if the 29
destination endpoint is set to the broadcast endpoint (0xff) and the DstAddrMode 30
parameter of the received NLDE-DATA.indication primitive was not 0x01, then 31
the APSDE shall also present the frame to all non-reserved endpoints (0x01-0xfe) 32
supported by the NHLE. 33
If the APSDE of a device receives a transmission with the delivery mode sub-field 34
of the frame control field set to 0b11, indicating group addressing, it shall deliver 35
the frame to each endpoint on the device that is associated in the group table with 36
the 16-bit group address found in the group address field of the APS header. 37
Similarly, if the APSDE of a device receives a NLDE-DATA.indication primitive 38
where the DstAddrMode parameter has a value of 0x01, also indicating group 39
addressing, it shall deliver the frame to each endpoint on the device that is 40
associated in the group table with the 16-bit group address given as the value of 41
the DstAddr parameter. In either case, it shall search the group table and, for each 42
endpoint associated with the given group address, it shall issue the NLDE- 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
68 Application Layer Specification
1
2
3
4
5
! 6
" # $%&'
7
# $ #
%(!)' 8
# $ #
%*!)' 9
$ +
,
10
# $ #
%-!)!
$#
,%-..' 11
# $ #
%/!)' 12
# $ #
%0!)' 13
$ +
,
14
# $ #
%/!)! , 15
$#
,%-..'
16
17
18
19
20
21
22
Figure 2.12 Successful Data Transmission with Fragmentation
23
24
In Figure 2.13, a single frame is lost during transit across the network, and is
25
retransmitted.
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
74 Application Layer Specification
1
2
3
4
5
! 6
" # $%&'
7
# $ #
%(!)' 8
# $ #
%*!)' 9
$ +
,
# $ #
%-!)!
10
$#
,%-.' 11
# $ #
%(!)' 12
$ +
,
13
# $ #
%-!)!
$#
,%-..' 14
# $ #
%/!)' 15
# $ #
%0!)'
16
$ +
,
17
# $ #
%/!)! , 18
$#
,%-..'
19
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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 75
1
2
3
4
! 5
" # $%&'
6
# $ #
%(!)' 7
# $ #
%*!)' 8
.
9
, # $ #
%-!)' 10
# $ #
%(!)' 11
# $ #
%*!)' 12
$ +
,
13
# $ #
%-!)!
$#
,%-..'
14
# $ #
%/!)' 15
# $ #
%0!)'
16
$ +
,
17
# $ #
%/!)! , 18
$#
,%-..'
19
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.27. 29
Table 2.27 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
76 Application Layer Specification
802.15.4 radio, the corresponding bit of the frequency band field, as listed in
Table 2.31, shall be set to 1. All other bits shall be set to 0. 1
2
Table 2.31 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 85
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. 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.32. 32
Table 2.32 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
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
86 Application Layer Specification
power source selected, the corresponding bit of the current power source field, as
listed in Table 2.37, shall be set to 1. All other bits shall be set to 0. 1
2
Table 2.37 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.38. 17
18
Table 2.38 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 89
The fields of the simple descriptor are shown in Table 2.39 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.39 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-254. Endpoints 241-254 shall be used only with the approval of 25
the ZigBee Alliance. 26
27
2.3.2.5.2 Application Profile Identifier Field
28
The application profile identifier field of the simple descriptor is sixteen bits in 29
length and specifies the profile that is supported on this endpoint. Profile 30
identifiers shall be obtained from the ZigBee Alliance. 31
32
2.3.2.5.3 Application Device Identifier Field 33
The application device identifier field of the simple descriptor is sixteen bits in 34
length and specifies the device description supported on this endpoint. Device 35
description identifiers shall be obtained from the ZigBee Alliance. 36
37
2.3.2.5.4 Application Device Version Field 38
The application device version field of the simple descriptor is four bits in length 39
and specifies the version of the device description supported on this endpoint. The 40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
90 Application Layer Specification
application device version field shall be set to one of the non-reserved values
listed in Table 2.40. 1
2
Table 2.40 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 91
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.42. 2
3
Table 2.42 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 93
ZigBee Routers with associated devices shall respond with their address
as the first entry followed by the addresses of their associated devices 1
depending on the type of request. The responding devices shall employ 2
3
APS acknowledged service on the unicast responses.
4
—Unicast addressed: Only the specified device responds. A ZigBee End 5
Device shall respond only with its address. A ZigBee Coordinator or 6
Router shall reply with its own address and the address of each associ- 7
ated child device. Inclusion of the associated child devices allows the 8
requestor to determine the network topology underlying the specified 9
10
device.
11
• Service Discovery: Provides the ability for a device to determine services 12
offered by other devices on the PAN. 13
14
• Service Discovery messages can be used in one of two ways:
15
—Broadcast addressed: Due to the volume of information that could be 16
returned, only the individual device or the primary discovery cache shall 17
respond with the matching criteria established in the request. The pri- 18
mary discovery cache shall only respond in this case if it holds cached 19
discovery information for the NWKAddrOfInterest from the request. 20
21
The responding devices shall also employ APS acknowledged service
22
on the unicast responses. 23
—Unicast addressed: Only the specified device shall respond. In the case 24
of a ZigBee Coordinator or ZigBee Router, these devices shall cache the 25
Service Discovery information for sleeping associated devices and 26
respond on their behalf. 27
28
• Service Discovery is supported with the following query types: 29
30
—Active Endpoint: This command permits an enquiring device to deter-
31
mine the active endpoints. An active endpoint is one with an application 32
supporting a single profile, described by a Simple Descriptor. The com- 33
mand shall be unicast addressed. 34
—Match Simple Descriptor: This command permits enquiring devices to 35
supply a Profile ID (and, optionally, lists of input and/or output Cluster 36
37
IDs) and ask for a return of the identity of an endpoint on the destination
38
device which matches the supplied criteria. This command may be 39
broadcast to all devices for which macRxOnWhenIdle = TRUE, or uni- 40
cast addressed. For broadcast addressed requests, the responding device 41
shall employ APS acknowledged service on the unicast responses. 42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
96 Application Layer Specification
Table 2.44 Device and Service Discovery Client Services Commands (Continued)
1
Active_EP_req O M
2
Match_Desc_req O M 3
Complex_Desc_req O O 4
5
User_Desc_req O O 6
Discovery_Cache_req O O 7
Device_annce O M 8
9
User_Desc_set O O 10
System_Server_Discover_req O O 11
12
Discovery_store_req O O
13
Node_Desc_store_req O O 14
Power_Desc_store_req O O 15
16
Active_EP_store_req O O
17
Simple_Desc_store_req O O 18
Remove_node_cache_req O O 19
20
Find_node_cache_req O O
21
Extended_Simple_Desc_req O O 22
Extended_Active_EP_req O O 23
24
25
2.4.3.1.1 NWK_addr_req
26
The NWK_addr_req command (ClusterID=0x0000) shall be formatted as 27
illustrated in Figure 2.20. 28
29
Octets: 8 1 1 30
IEEEAddress RequestType StartIndex 31
32
Figure 2.20 Format of the NWK_addr_req Command 33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 101
2.4.3.1.3 Node_Desc_req
1
The Node_Desc_req_command (ClusterID=0x0002) shall be formatted as 2
illustrated in Figure 2.22. 3
4
Octets: 2
5
NWKAddrOfInterest 6
7
Figure 2.22 Format of the Node_Desc_req Command Frame 8
9
Table 2.47 specifies the fields for the Node_Desc_req command frame. 10
Table 2.47 Fields of the Node_Desc_req Command 11
12
Name Type Valid Range Description
13
NWKAddrOfInterest Device Address 16-bit NWK address NWK address for the request 14
15
2.4.3.1.3.1 When Generated 16
17
The Node_Desc_req command is generated from a local device wishing to inquire 18
as to the node descriptor of a remote device. This command shall be unicast either 19
to the remote device itself or to an alternative device that contains the discovery 20
information of the remote device. 21
22
The local device shall generate the Node_Desc_req command using the format
23
illustrated in Table 2.47. The NWKAddrOfInterest field shall contain the network
24
address of the remote device for which the node descriptor is required.
25
26
2.4.3.1.3.2 Effect on Receipt
27
Upon receipt of this command, the recipient device shall process the command 28
and generate a Node_Desc_rsp command in response, according to the 29
description in sub-clause 2.4.4.1.3.1. 30
31
2.4.3.1.4 Power_Desc_req 32
The Power_Desc_req command (ClusterID=0x0003) shall be formatted as 33
illustrated in Figure 2.23. 34
35
Octets: 2 36
37
NWKAddrOfInterest
38
Figure 2.23 Format of the Power_Desc_req Command Frame 39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 105
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 User_Desc_req command using the format 3
illustrated in Table 2.53. The NWKAddrOfInterest field shall contain the network 4
address of the remote device for which the user descriptor is required. 5
6
2.4.3.1.9.2 Effect on Receipt 7
Upon receipt of this command, the recipient device shall process the command 8
and generate a User_Desc_rsp command in response, according to the description 9
in sub-clause 2.4.4.1.9.1. 10
11
2.4.3.1.10 Discovery_Cache_req 12
13
The Discovery_Cache_req command (ClusterID=0x0012) shall be formatted as
14
illustrated in Figure 2.29.
15
Octets: 2 8 16
17
NWKAddr IEEEAddr 18
Figure 2.29 Format of the Discovery_Cache_req Command Frame 19
20
Table 2.54 specifies the parameters for the Discovery_Cache_req command 21
frame. 22
23
Table 2.54 Fields of the Discovery_Cache_req Command
24
Name Type Valid Range Description 25
26
NWKAddr Device Address 16-bit NWK address NWK address for the Local Device. 27
IEEEAddr Device Address 64-bit IEEE address IEEE address for the Local Device. 28
29
2.4.3.1.10.1 When Generated 30
31
The Discovery_Cache_req is provided to enable devices on the network to locate 32
a Primary Discovery Cache device on the network. The destination addressing on 33
this primitive shall be broadcast to all devices for which macRxOnWhenIdle = 34
TRUE. 35
36
2.4.3.1.10.2 Effect on Receipt 37
38
Upon receipt, if the Remote Device does not support the Discovery_Cache_req, 39
the request shall be dropped and no further processing performed. If the 40
Discovery_Cache_req is supported, the Remote Device shall create a unicast 41
Discovery_Cache_rsp message to the source indicated by the 42
Discovery_Cache_req and include a SUCCESS status. 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 111
2.4.3.1.11 Device_annce
1
The Device_annce command (ClusterID=0x0013) shall be formatted as illustrated 2
in Figure 2.30. 3
4
Octets: 2 8 1
5
NWKAddr IEEEAddr Capability 6
7
Figure 2.30 Format of the Device_annce Command Frame 8
9
Table 2.55 specifies the fields of the Device_annce command frame. 10
Table 2.55 Fields of the Device_annce Command 11
12
Name Type Valid Range Description
13
NWKAddr Device Address 16-bit NWK address NWK address for the Local Device 14
IEEEAddr Device Address 64-bit IEEE address IEEE address for the Local Device 15
16
Capability Bitmap See Figure 2.17 Capability of the local device 17
18
2.4.3.1.11.1 When Generated 19
20
The Device_annce is provided to enable ZigBee devices on the network to notify 21
other ZigBee devices that the device has joined or re-joined the network, 22
identifying the device’s 64-bit IEEE address and new 16-bit NWK address, and 23
informing the Remote Devices of the capability of the ZigBee device. This 24
command shall be invoked for all ZigBee end devices upon join or rejoin. This 25
command may also be invoked by ZigBee routers upon join or rejoin as part of 26
NWK address conflict resolution. The destination addressing on this primitive is 27
broadcast to all devices for which macRxOnWhenIdle = TRUE. 28
29
2.4.3.1.11.2 Effect on Receipt 30
Upon receipt, the Remote Device shall use the IEEEAddr in the message to find a 31
match with any other IEEE address held in the Remote Device. If a match is 32
detected, the Remote Device shall update the nwkAddressMap attribute of the NIB 33
with the updated NWKAddr corresponding to the IEEEAddr received. 34
35
The Remote Device shall also use the NWKAddr in the message to find a match 36
with any other 16-bit NWK address held in the Remote Device. If a match is 37
detected for a device with an IEEE address other than that indicated in the 38
IEEEAddr field received, then this entry shall be marked as not having a known 39
valid 16-bit NWK address. 40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
112 Application Layer Specification
2.4.3.1.12 User_Desc_set
1
The User_Desc_set command (ClusterID=0x0014) shall be formatted as 2
illustrated in Figure 2.31. 3
4
Octets: 2 1 Various
5
NWKAddrOfInterest Length UserDescriptor 6
7
Figure 2.31 Format of the User_Desc_set Command Frame 8
9
Table 2.56 specifies the fields of the User_Desc_set command frame. 10
Table 2.56 Fields of the User_Desc_set Command 11
12
Valid
Name Type Range Description 13
14
NWKAddrOfInterest Device Address 16-bit NWK address for the request. 15
NWK 16
address
17
Length Integer 0x00 - 0x10 Length of the User Descriptor in 18
bytes. 19
UserDescription User Descriptor The user description to configure; if 20
the ASCII character string to be 21
entered here is less than 16 characters 22
in length, it shall be padded with
space characters (0x20) to make a
23
total length of 16 characters. 24
Characters with codes 0x00-0x1f are 25
not permitted. 26
27
2.4.3.1.12.1 When Generated 28
29
The User_Desc_set command is generated from a local device wishing to 30
configure the user descriptor on a remote device. This command shall be unicast 31
either to the remote device itself or to an alternative device that contains the 32
discovery information of the remote device. 33
The local device shall generate the User_Desc_set command using the format 34
illustrated in Table 2.56. The NWKAddrOfInterest field shall contain the network 35
address of the remote device for which the user descriptor is to be configured and 36
the UserDescription field shall contain the ASCII character string that is to be 37
configured in the user descriptor. Characters with ASCII codes numbered 0x00 38
through 0x1f are not permitted to be included in this string. 39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 113
2.4.3.1.14 Discovery_store_req
1
The Discovery_Store_req command (ClusterID=0x0016) shall be formatted as 2
illustrated in Figure 2.33. 3
4
Octets: 2 8 1 1 1 1 Variable
5
NWKAddr IEEEAddr NodeDes PowerDe ActiveEPSize SimpleDes SimpleDesc- 6
c-Size sc-Size c-Count SizeList 7
8
Figure 2.33 Format of the Discovery_Store_req Command Frame
9
Table 2.58 specifies the fields of the Discovery_store_req command frame. 10
11
Table 2.58 Fields of the Discovery_store_req Command 12
Name Type Valid Range Description 13
14
NWKAddr Device 16-bit NWK NWK Address for the Local 15
Address Address Device. 16
IEEEAddr Device 64-bit IEEE IEEE Address for the Local 17
Address Address Device. 18
NodeDescSize Integer 0x00-oxff Size in bytes of the Node 19
Descriptor for the Local Device. 20
21
PowerDescSize Integer 0x00 - 0xff Size in bytes of the Power
Descriptor for the Local Device. 22
23
ActiveEPSize Integer 0x00 - 0xff Size in bytes of the ActiveEPCount
24
and ActiveEPList fields of the
Active_EP_rsp for the Local 25
Device. 26
27
SimpleDescCount Integer 0x00 - 0xff Number of Simple Descriptors
supported by the Local Device 28
(should be the same value as the 29
ActiveEPSize). 30
SimpleDescSizeList Array of bytes List of bytes of SimpleDescCount 31
length, each of which represents 32
the size in bytes of the Simple 33
Descriptor for each Active 34
Endpoint on the Local Device. 35
36
2.4.3.1.14.1 When Generated 37
38
The Discovery_store_req is provided to enable ZigBee end devices on the 39
network to request storage of their discovery cache information on a Primary 40
Discovery Cache device. Included in the request is the amount of storage space 41
the Local Device requires. 42
The destination addressing on this request is unicast. 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 115
2.4.3.1.19 Remove_node_cache_req
1
The Remove_node_cache_req command (ClusterID=0x001b) shall be formatted 2
as illustrated in Figure 2.38. 3
4
Octets: 2 8
5
NWKAddr IEEEAddr 6
7
Figure 2.38 Format of the Remove_node_cache_req Command Frame 8
9
Table 2.63 specifies the fields of the Remove_node_cache_req command frame. 10
Table 2.63 Fields of the Remove_node_cache_req Command 11
12
Name Type Valid Range Description
13
NWKAddr Device Address 16-bit NWK Address NWK Address for the device of 14
interest. 15
IEEEAddr Device Address 64-bit IEEE Address IEEE Address for the device of interest. 16
17
18
2.4.3.1.19.1 When Generated
19
The Remove_node_cache_req is provided to enable ZigBee devices on the 20
network to request removal of discovery cache information for a specified ZigBee 21
end device from a Primary Discovery Cache device. The effect of a successful 22
Remove_node_cache_req is to undo a previously successful Discovery_store_req 23
and additionally remove any cache information stored on behalf of the specified 24
ZigBee end device on the Primary Discovery Cache device. 25
26
2.4.3.1.19.2 Effect on Receipt 27
28
Upon receipt, the Remote Device shall determine whether it is a Primary 29
Discovery Cache device. If it is not a Primary Discovery Cache device, the 30
Remote Device shall return a status of NOT_SUPPORTED. Next, the Remote 31
Device shall determine whether it has previously processed a 32
Discovery_store_req for the indicated device and returned a status of SUCCESS. 33
If a previous Discovery_store_req has not been processed with a SUCCESS 34
status, the Remote Device shall return DEVICE_NOT_FOUND. Finally, the 35
Remote Device shall remove all cached discovery information for the device of 36
interest and return SUCCESS to the Local Device. 37
38
39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 121
2.4.3.1.20 Find_node_cache_req
1
The Find_node_cache_req command (ClusterID=0x001c) shall be formatted as 2
illustrated in Figure 2.39. 3
4
Octets: 2 8
5
NWKAddr IEEEAddr 6
7
Figure 2.39 Format of the Find_node_cache Command Frame 8
9
Table 2.64 specifies the fields of the Find_node_cache_req command frame. 10
Table 2.64 Fields of the Find_node_cache_req Command Frame 11
12
Name Type Valid Range Description
13
NWKAddr Device 16-bit NWK Address NWK Address for the device of 14
Address interest. 15
IEEEAddr Device 64-bit IEEE Address IEEE Address for the device of 16
Address interest. 17
18
2.4.3.1.20.1 When Generated 19
20
The Find_node_cache_req is provided to enable ZigBee devices on the network to 21
broadcast to all devices for which macRxOnWhenIdle = TRUE a request to find a 22
device on the network that holds discovery information for the device of interest, 23
as specified in the request parameters. The effect of a successful 24
Find_node_cache_req is to have the Primary Discovery Cache device, holding 25
discovery information for the device of interest, unicast a Find_node_cache_rsp 26
back to the Local Device. Note that, like the NWK_addr_req, only the device 27
meeting this criteria shall respond to the request generated by 28
Find_node_cache_req. 29
30
2.4.3.1.20.2 Effect on Receipt 31
32
Upon receipt, the Remote Device shall determine whether it is the device of 33
interest or a Primary Discovery Cache device, and if so, if it holds discovery cache 34
information for the device of interest. If it is not the device of interest or a Primary 35
Discovery Cache device, and does not hold discovery cache information for the 36
device of interest, the Remote Device shall cease processing the request and not 37
supply a response. If the Remote Device is the device of interest, or a Primary 38
Discovery Cache device, and, if the device holds discovery information for the 39
indicated device of interest, the Remote Device shall return the NWKAddr and 40
IEEEaddr for the device of interest. 41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
122 Application Layer Specification
2.4.3.1.21 Extended_Simple_Desc_req
1
The Extended_Simple_Desc_req command (ClusterID=0x001d) shall be 2
formatted as illustrated in Figure 2.40. 3
4
Octets: 2 1 1
5
NWKAddrOfInterest EndPoint StartIndex 6
7
Figure 2.40 Format of the Extended_Simple_Desc_req Command Frame 8
9
Table 2.65 specifies the fields of the Extended_Simple_Desc_req command 10
frame. 11
Table 2.65 Fields of the Extended_Simple_Desc_req Command 12
13
Name Type Valid Range Description
14
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request. 15
Address 16
Endpoint 8 bits 1-254 The endpoint on the destination. 17
18
StartIndex 8 bits 0x00-0xff Starting index within the cluster
list of the response represented by
19
an ordered list of the Application 20
Input Cluster List and Application 21
Output Cluster List. 22
23
2.4.3.1.21.1 When Generated 24
25
The Extended_Simple_Desc_req command is generated from a local device 26
wishing to inquire as to the simple descriptor of a remote device on a specified 27
endpoint. This command shall be unicast either to the remote device itself or to an 28
alternative device that contains the discovery information of the remote device. 29
The Extended_Simple_Desc_req is intended for use with devices which employ a 30
larger number of application input or output clusters than can be described by the 31
Simple_Desc_req. 32
The local device shall generate the Extended_Simple_Desc_req command using 33
the format illustrated in Table 2.65. The NWKAddrOfInterest field shall contain 34
the network address of the remote device for which the simple descriptor is 35
required and the endpoint field shall contain the endpoint identifier from which to 36
obtain the required simple descriptor. The StartIndex is the first entry requested in 37
the Application Input Cluster List and Application Output Cluster List sequence 38
within the resulting response. 39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 123
2.4.3.2.1 End_Device_Bind_req
1
The End_Device_Bind_req command (ClusterID=0x0020) shall be formatted as 2
illustrated in Figure 2.42. 3
4
Octets:
2 8 1 2 1 Variable 1 Variable 5
6
Binding SrcIEEE Src Profile Num InCluster Num OutCluster 7
Target Address Endpoint ID InClusters List OutClusters List 8
Figure 2.42 Format of the End_Device_Bind_req Command Frame 9
10
Table 2.68 specifies the fields of the End_Device_Bind_req command frame. 11
12
Table 2.68 Fields of the End_Device_Bind_req Command
13
Name Type Valid Range Description 14
15
BindingTarget Device Address 16-bit NWK The address of the target for the binding. 16
address This can be either the primary binding
cache device or the short address of the 17
local device. 18
19
SrcIEEEAddre IEEE Address A valid 64-bit The IEEE address of the device
ss IEEE Address generating the request. 20
21
SrcEndpoint 8 bits 1-254 The endpoint on the device generating 22
the request.
23
ProfileID Integer 0x0000-0xffff ProfileID which is to be matched 24
between two End_Device_Bind_req 25
received at the ZigBee Coordinator
26
within the timeout value pre-configured
in the ZigBee Coordinator. 27
28
NumInClusters Integer 0x00-0xff The number of Input Clusters provided
29
for end device binding within the
InClusterList. 30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
126 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.70 specifies the fields of the Unbind_req command frame.
17
Table 2.70 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-0xfe 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-00xfe 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
130 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.73 specifies the fields of the Store_Bkup_Bind_Entry_req command 10
frame. 11
Table 2.73 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 - 0xfe 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-0xfe 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
134 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.74 specifies the fields of the Remove_Bkup_Bind_Entry_req command 24
frame. 25
Table 2.74 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 - 0xfe The endpoint 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 135
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.75 specifies the fields of the Backup_Bind_Table_req command frame. 10
Table 2.75 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.131 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 137
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.76 specifies the fields of the Recover_Bind_Table_req command frame. 18
19
Table 2.76 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
138 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.77 specifies the fields of the Backup_Source_Bind_req command frame. 10
Table 2.77 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 139
Table 2.80 specifies the fields for the Mgmt_NWK_Disc_req command frame.
1
Table 2.80 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
142 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.81 specifies the fields for the Mgmt_NWK_Disc_req command frame. 10
Table 2.81 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 143
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.82 specifies the fields for the Mgmt_Rtg_req command frame. 10
Table 2.82 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
144 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.83 specifies the fields for the Mgmt_Bind_req command frame. 10
Table 2.83 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 145
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.84 specifies the fields for the Mgmt_Leave_req command frame. 10
Table 2.84 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 used. 17
18
Remove Bit 0 or 1 This field has a value of 1 if the 19
Children device being asked to leave the
network is also being asked to 20
remove its child devices, if any. 21
Otherwise, it has a value of 0. 22
Rejoin Bit 0 or 1 This field has a value of 1 if the
23
device being asked to leave from the 24
current parent is requested to rejoin 25
the network. Otherwise, it has a 26
value of 0. 27
28
2.4.3.3.5.1 When Generated 29
30
The Mgmt_Leave_req is generated from a Local Device requesting that a Remote 31
Device leave the network or to request that another device leave the network. The 32
Mgmt_Leave_req is generated by a management application which directs the 33
request to a Remote Device where the NLME-LEAVE.request is to be executed 34
using the parameter supplied by Mgmt_Leave_req. 35
36
2.4.3.3.5.2 Effect on Receipt 37
Upon receipt, the remote device shall issue the NLME-LEAVE.request primitive 38
using the parameters supplied with the Mgmt_Leave_req command. The results 39
of the leave attempt shall be reported back to the local device via the 40
Mgmt_Leave_rsp command. 41
42
If the remote device does not support this optional management request, it shall 43
return a status of NOT_SUPPORTED. If the leave attempt was executed 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
146 Application Layer Specification
If the remote device does not support this optional management request, it shall
return a status of NOT_SUPPORTED. If the direct join attempt was executed 1
successfully, the Mgmt_Direct_Join_rsp command shall contain a status of 2
SUCCESS. If the direct join attempt was not executed successfully, the 3
Mgmt_Direct_Join_rsp command shall contain the error code reported in the 4
NLME-DIRECT-JOIN.confirm 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.7 Mgmt_Permit_Joining_req 10
11
The Mgmt_Permit_Joining_req command (ClusterID=0x0036) shall be formatted 12
as illustrated in Figure 2.59. 13
14
Octets: 1 1
15
PermitDuration TC_Significance 16
17
Figure 2.59 Format of the Mgmt_Permit_Joining_req Command Frame 18
19
Table 2.86 specifies the fields of the Mgmt_Permit_Joining_req command frame. 20
Table 2.86 Fields of the Mgmt_Permit_Joining_req Command 21
22
Name Type Valid Range Description
23
PermitDuration Integer 0x00 - 0xff See sub-clause 3.2.2.5 for details on the 24
PermitDuration parameter within NLME- 25
PERMIT-JOINING.request. 26
TC_Significance Boolean 0x00 - 0x01 If this is set to 0x01 and the remote device is 27
Integer the Trust Center, the command affects the 28
Trust Center authentication policy as 29
described in the sub-clauses below; If this is
set to 0x00, there is no effect on the Trust 30
Center. 31
32
33
2.4.3.3.7.1 When Generated
34
The Mgmt_Permit_Joining_req is generated from a Local Device requesting that 35
a remote device or devices allow or disallow association. The 36
Mgmt_Permit_Joining_req is generated by a management application or 37
commissioning tool which directs the request to a remote device(s) where the 38
NLME-PERMIT-JOINING.request is executed using the PermitDuration 39
parameter supplied by Mgmt_Permit_Joining_req. Additionally, if the remote 40
device is the Trust Center and TC_Significance is set to 1, the Trust Center 41
authentication policy will be affected. The addressing may be unicast or 42
‘broadcast to all routers and coordinator’. 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
148 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.87 specifies the fields of the Mgmt_Cache_req command frame. 10
Table 2.87 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
150 Application Layer Specification
limitation described for fragmentation, and supply the results to the requesting
device with a Mgmt_NWK_Update_notify with a SUCCESS status. 1
2
Otherwise, if the ScanDuration is equal to 0x06 to 0xfd and the destination 3
addressing on this command was unicast then the Remote Device shall return a 4
status of INVALID_REQUEST. 5
If the destination addressing on this command was not unicast then the Remote 6
Device shall not transmit a response. 7
8
9
10
2.4.4 Server Services 11
12
The Device Profile Server Services support the processing of device and service 13
discovery requests, end device bind requests, bind requests, unbind requests, and 14
network management requests. Additionally, Server Services support 15
transmission of these responses back to the requesting device. 16
17
For all broadcast addressed requests (of any broadcast address type) to the server, 18
if the command is not supported, the server shall drop the packet. No error status 19
shall be unicast back to the Local Device for any broadcast addressed client 20
request including, but not limited to, requests which are not supported on the 21
server. 22
For all unicast addressed requests to the server, if the command is not supported, 23
the server shall formulate a response packet including the response Cluster ID and 24
status fields only. The response Cluster ID shall be created by taking the request 25
Cluster ID and setting the high order bit to create the response Cluster ID. The 26
status field shall be set to NOT_SUPPORTED. The resulting response shall be 27
unicast to the requesting client. 28
29
2.4.4.1 Device and Service Discovery Server 30
31
Table 2.89 lists the commands supported by the Device and Service Discovery 32
Server Services device profile. Each of these commands will be discussed in the 33
following sub-clauses. For receipt of the Device_annce command, the server shall 34
check all internal references to the IEEE and 16-bit NWK addresses supplied in 35
the request. For all references to the IEEE address in the Local Device, the 36
corresponding NWK address supplied in the Device_annce shall be substituted. 37
For any other references to the NWK address in the Local Device, the 38
39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 153
corresponding entry shall be marked as not having a known valid 16-bit NWK
address. The server shall not supply a response to the Device_annce. 1
2
Table 2.89 Device and Service Discovery Server Service Primitives
3
Device and Service 4
Discovery Server 5
Server Services Processing 6
NWK_addr_rsp M 7
8
IEEE_addr_rsp M 9
Node_Desc_rsp M 10
Power_Desc_rsp M
11
12
Simple_Desc_rsp M 13
Active_EP_rsp M 14
15
Match_Desc_rsp M
16
Complex_Desc_rsp O 17
User_Desc_rsp O 18
19
User_Desc_conf O
20
System_Server_Discovery_rsp O 21
Discovery_store_rsp O 22
23
Node_Desc_store_rsp O
24
Power_Desc_store_rsp O 25
Active_EP_store_rsp O 26
27
Simple_Desc_store_rsp O 28
Remove_node_cache_rsp O 29
Find_node_cache_rsp O
30
31
Extended_Simple_Desc_rsp O 32
Extended_Active_EP_rsp O 33
34
2.4.4.1.1 NWK_addr_rsp 35
36
The NWK_addr_rsp command (ClusterID=0x8000) shall be formatted as 37
illustrated in Figure 2.62. 38
39
Octets: 1 8 2 0/1 0/1 Variable 40
Status IEEEAddr NWKAddr Num StartIndex NWKAddr 41
RemoteDev RemoteDev AssocDev AssocDevList 42
43
Figure 2.62 Format of the NWK_addr_rsp Command Frame 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
154 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.91 specifies the fields of the IEEE_addr_rs command frame. 10
11
Table 2.91 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 157
The remote device shall generate the Node_Desc_rsp command using the format
illustrated in Table 2.92. 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
160 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.94 specifies the fields of the Simple_Desc_rsp command frame. 23
Table 2.94 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
162 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 165
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 if the ProfileID 17
field matches exactly the application profile identifier field of the simple 18
descriptor. If the profileID field does not match exactly the remote device shall 19
check if the Profile ID of the Match_desc_req matches the wildcard profile 20
(0xFFFF) and the Profile ID of the Simple Descriptor is within the Standard range 21
(a public profile) as dictated by document [B25].14 If the profile identifiers do not 22
match, the remote device shall assume the match to be unsuccessful and perform 23
no further matching. 24
25
If the profile identifiers match, the remote device shall determine whether the 26
match criteria contains a list of input clusters (the NumInClusters field is not equal 27
to 0). If the match criteria contains a list of input clusters, the remote device shall 28
check that at least one of the cluster identifiers listed in the InClusterList field 29
matches one of the cluster identifiers in the application input cluster list field of 30
the simple descriptor. If at least one matching input cluster is found, the remote 31
device shall assume the match to be successful, note the identifier of the endpoint 32
to which this simple descriptor refers and perform no further matching. 33
If the remote device is unable to find any matching input clusters, it shall 34
determine whether the match criterion contains a list of output clusters (the 35
NumOutClusters field is not equal to 0). If the match criterion contains a list of 36
output clusters, the remote device shall check that at least one of the cluster 37
identifiers listed in the OutClusterList field matches one of the cluster identifiers 38
in the application output cluster list field of the simple descriptor. If at least one 39
matching output cluster is found, the remote device shall assume the match to be 40
successful and note the identifier of the endpoint to which this simple descriptor 41
42
43
14. CCB 1224 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 167
refers. If the remote device is unable to find any output matching clusters, it shall
assume the match to be unsuccessful. 1
2
If the above procedure produces one or more matches, the remote device shall 3
construct a separate Match_Desc_rsp command for each matching device 4
(including itself). For each response, the Status field shall be set to SUCCESS, the 5
NWKAddrOfInterest field shall be set to the address of the appropriate matching 6
device, the MatchLength field shall be set to the number of simple descriptors that 7
matched the criteria for the appropriate matching device, and the MatchList field 8
shall contain an ascending list of the endpoints on which a simple descriptor 9
matched the criteria for the appropriate matching device. 10
11
2.4.4.1.7.2 Effect on Receipt 12
On receipt of the Match_Desc_rsp command, the recipient is either notified of the 13
results of its match criterion query indicated in the original Match_Desc_req 14
command or notified of an error. If the Match_Desc_rsp command is received 15
with a Status of SUCCESS, the MatchList field shall contain the list of endpoints 16
containing simple descriptors that matched the criterion. Otherwise, the Status 17
field indicates the error and the MatchList field shall not be included. 18
19
2.4.4.1.8 Complex_Desc_rsp 20
21
The Complex_Desc_rsp command (ClusterID=0x8010) shall be formatted as
22
illustrated in Figure 2.69.
23
Octet: 1 2 1 Variable 24
25
Status NWKAddr Length Complex 26
OfInterest Descriptor
27
Figure 2.69 Format of the Complex_Desc_rsp Command Frame 28
29
Table 2.97 specifies the fields of the Complex_Desc_rsp command frame. 30
31
Table 2.97 Fields of the Complex_Desc_rsp Command
32
Name Type Valid Range Description 33
34
Status Integer SUCCESS, The status of the
NOT_SUPPORTED,a Complex_Desc_req command. 35
DEVICE_NOT_FOUND, 36
INV_REQUESTTYPE or 37
NO_DESCRIPTOR 38
39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
168 Application Layer Specification
2.4.4.1.10 System_Server_Discovery_rsp
1
The System_Server_Discovery_rsp command (ClusterID=0x8015) shall be 2
formatted as illustrated in Figure 2.75. 3
4
Octet: 1 2
5
Status ServerMask 6
7
Figure 2.71 System_Server_Discovery_rsp Command Frame 8
9
Table 2.99 specifies the fields of the System_Server_Discovery_rsp command 10
frame. 11
Table 2.99 Fields of the System_Server_Discovery_rsp Command 12
13
Name Type Valid Range Description
14
Status Integer SUCCESS The status of the 15
System_Server_Discovery_rsp 16
command. 17
ServerMask Integer Bitmap See Table 2.32 for bit assignments. 18
19
2.4.4.1.10.1 When Generated 20
21
The System_Server_Discovery_rsp is generated from Remote Devices on receipt 22
of a System_Server_Discovery_req primitive if the parameter matches the Server 23
Mask field in its node descriptor. If there is no match, the 24
System_Server_Discovery_req shall be ignored and no response given. Matching 25
is performed by masking the ServerMask parameter of the 26
System_Server_Discovery_req with the Server Mask field in the node descriptor. 27
This command shall be unicast to the device which sent 28
System_Server_Discovery_req with Acknowledge request set in TxOptions. The 29
parameter ServerMask contains the bits in the parameter of the request which 30
match the server mask in the node descriptor. 31
32
2.4.4.1.10.2 Effect on Receipt 33
34
The requesting device is notified that this device has some of the system server 35
functionality that the requesting device is seeking. 36
If the Network Manager bit was set in the System_Server_Discovery_rsp, then the 37
Remote Device’s NWK address shall be set into the nwkManagerAddr of the NIB. 38
39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
172 Application Layer Specification
2.4.4.1.11 User_Desc_conf
1
The User_Desc_conf command (ClusterID=0x8014) shall be formatted as 2
illustrated in Figure 2.72. 3
4
Octets: 1 2
5
Status NWKAddr 6
OfInterest 7
8
Figure 2.72 Format of the User_Desc_conf Command Frame
9
Table 2.100 specifies the fields of the User_Desc_conf command frame. 10
11
Table 2.100 Fields of the User_Desc_conf Command 12
Name Type Valid Range Description 13
14
Status Integer SUCCESS, The status of the 15
NOT_SUPPORTED, User_Desc_set command. 16
DEVICE_NOT_FOUND,
INV_REQUESTTYPE or 17
NO_DESCRIPTOR 18
19
NWKAddrOfInterest Device Any 16-bit NWK address The network address of the
Address device on which the user 20
descriptor set attempt was 21
made. 22
23
2.4.4.1.11.1 When Generated 24
25
The User_Desc_conf is generated by a remote device in response to a 26
User_Desc_set directed to the remote device. This command shall be unicast to 27
the originator of the User_Desc_set command. 28
29
The remote device shall generate the User_Desc_conf command using the format
30
illustrated in Table 2.100. The NWKAddrOfInterest field shall match that
31
specified in the original User_Desc_set command. If the NWKAddrOfInterest
32
field matches the network address of the remote device but a user descriptor does
33
not exist, it shall set the Status field to NOT_SUPPORTED. If the
34
NWKAddrOfInterest field matches the network address of the remote device and
35
a user descriptor exists, it shall set the Status field to SUCCESS and configure the
36
user descriptor with the ASCII character string specified in the original
37
User_Desc_set command.
38
If the NWKAddrOfInterest field does not match the network address of the 39
remote device and it is an end device, it shall set the Status field to 40
INV_REQUESTTYPE. If the NWKAddrOfInterest field does not match the 41
network address of the remote device and it is the coordinator or a router, it shall 42
determine whether the NWKAddrOfInterest field matches the network address of 43
one of its children. If the NWKAddrOfInterest field does not match the network 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 173
address of one of the children of the remote device, it shall set the Status field to
DEVICE_NOT_FOUND. If the NWKAddrOfInterest matches the network 1
address of one of the children of the remote device, it shall determine whether a 2
user descriptor for that device is available. If a user descriptor is not available for 3
the child indicated by the NWKAddrOfInterest field, the remote device shall set 4
the Status field to NO_DESCRIPTOR. If a user descriptor is available for the 5
child indicated by the NWKAddrOfInterest field, the remote device shall set the 6
Status field to SUCCESS and configure the user descriptor with the ASCII 7
character string specified in the original User_Desc_set command. 8
9
2.4.4.1.11.2 Effect on Receipt 10
11
The local device is notified of the results of its attempt to configure the user 12
descriptor on a remote device. 13
2.4.4.1.12 Discovery_Cache_rsp 14
15
The Discovery_Cache_rsp command (ClusterID=0x8012) shall be formatted as 16
illustrated in Figure 2.73. 17
18
Octets: 1 19
Status 20
21
Figure 2.73 Format of the Discovery_Cache_rsp Command Frame 22
23
Table 2.101. specifies the fields of the Discovery_Cache_rsp Command Frame. 24
Table 2.101 Fields of the Discovery_Cache_rsp Command 25
26
Name Type Valid Range Description 27
Status Integer SUCCESS The status of the 28
Discovery_Cache_req command. 29
30
2.4.4.1.12.1 When Generated 31
32
The Discovery_Cache_rsp is generated by Primary Discovery Cache devices 33
receiving the Discovery_Cache_req. Remote Devices which are not Primary 34
Discovery Cache devices (as designated in its Node Descriptor) should not 35
respond to the Discovery_Cache_req command. 36
37
2.4.4.1.12.2 Effect on Receipt 38
39
Upon receipt of the Discovery_Cache_rsp, the Local Device determines if a 40
SUCCESS status was returned. If no Discovery_Cache_rsp messages were 41
returned from the original Discovery_Cache_req command, then the Local Device 42
should increase the radius for the request to locate Primary Discovery Cache 43
devices beyond the radius supplied in the previous request. If a SUCCESS status 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
174 Application Layer Specification
is returned, the Local Device should use the Discovery_Store_req, targeted to the
Remote Device supplying the response, to determine whether sufficient discovery 1
cache storage is available. 2
3
2.4.4.1.13 Discovery_store_rsp 4
The Discovery_store_rsp command (ClusterID=0x8016) shall be formatted as 5
illustrated in Figure 2.74. 6
7
Octets: 1 8
9
Status
10
Figure 2.74 Format of the Discovery_store_rsp Command Frame 11
12
Table 2.102 specifies the fields of the Discovery_store_rsp command frame 13
14
Table 2.102 Fields of the Discovery_store_rsp Command
15
Name Type Valid Range Description 16
17
Status Integer SUCCESS, The status of the
INSUFFICIENT_SPACE Discovery_store_req 18
or NOT_SUPPORTED command. 19
20
21
2.4.4.1.13.1 When Generated
22
The Discovery_store_rsp is provided to notify a Local Device of the request status 23
from a Primary Discovery Cache device. Included in the response is a status code 24
to notify the Local Device whether the request is successful (the Primary Cache 25
Device has space to store the discovery cache data for the Local Device), whether 26
the request is unsupported (meaning the Remote Device is not a Primary 27
Discovery Cache device), or insufficient space exists. 28
29
2.4.4.1.13.2 Effect on Receipt 30
31
Upon receipt, the Local Device shall determine whether the response status 32
indicates that the Remote Device is not a Primary Cache Device as indicated by a 33
NOT_SUPPORTED status. If a NOT_SUPPORTED status is returned, the Local 34
Device should process any other Discovery_store_rsp devices from other Remote 35
Devices or re-perform the Discovery_Cache_req to determine the address of 36
another Primary Discovery Cache device (eliminating the address of the Remote 37
Device that responded with NOT_SUPPORTED if it responds again to the 38
Discovery_Cache_req). If an INSUFFICIENT_SPACE status is returned, the 39
Local Device should also process any other Discovery_store_rsp and re-perform 40
the Discovery_Cache_req if none of the responses indicate SUCCESS (with the 41
radius field increased to include more Remote Devices). If a SUCCESS status is 42
returned, the Local Device shall upload its discovery cache information to the 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 175
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.104 specifies the fields of the Power_Desc_store_rsp command frame. 10
Table 2.104 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 177
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.105 specifies the fields of the Active_EP_store_rsp command frame. 10
Table 2.105 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
178 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.106 specifies the fields of the Simple_Desc_store_rsp command frame. 10
Table 2.106 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 179
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.107 specifies the fields of the Remove_node_cache_rsp command frame. 10
Table 2.107 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
180 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.108 specifies the fields of the Find_node_cache_rsp command frame. 10
Table 2.108 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 181
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.109 specifies the fields of the Extended_Simple_Desc_rsp command 10
frame. 11
12
Table 2.109 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-254 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
182 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.110 specifies the fields of the Extended_Active_EP_rsp command frame. 25
Table 2.110 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
184 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.111 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.111 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
186 Application Layer Specification
this device is the ZigBee Coordinator, the supplied endpoint shall be checked to
determine whether it falls within the specified range. If it does not, a Status of 1
INVALID_EP shall be returned. If the supplied endpoint falls within the specified 2
range and if this is the first End_Device_Bind_req submitted for evaluation, it 3
shall be stored and a timer started which expires at a pre-configured timeout 4
value. This timeout value shall be a configurable item on the ZigBee Coordinator. 5
If the timer expires before a second End_Device_Bind_req is received, a Status of 6
TIMEOUT is returned. Otherwise, if a second End_Device_Bind_req is received 7
within the timeout window, the two End_Device_Bind_req's are compared for a 8
match. A Status of NO_MATCH indicates that two End_Device_Bind_req were 9
evaluated for a match, but either the ProfileID parameters did not match or the 10
ProfileID parameter matched but there was no match of any element of the 11
InClusterList or OutClusterList. A Status of SUCCESS means that a match was 12
detected and a resulting Bind_req will subsequently be directed to the device 13
indicated by the BindingTarget field of the End_Device_Bind_req with matched 14
elements of the OutClusterList. 15
16
2.4.4.2.2 Bind_rsp 17
The Bind_rsp command (ClusterID=0x8021) shall be formatted as illustrated in 18
Figure 2.84. 19
20
Octets: 1 21
22
Status
23
Figure 2.84 Format of the Bind_rsp Command Frame 24
25
Table 2.113 specifies the fields of the Bind_rsp command frame. 26
27
Table 2.113 Fields of the Bind_rsp Command
28
Name Type Valid Range Description 29
30
Status Integer SUCCESS, The status of the Bind_req command.
NOT_SUPPORTED, 31
INVALID_EP, 32
TABLE_FULL or 33
NOT_AUTHORIZED 34
35
2.4.4.2.2.1 When Generated 36
37
The Bind_rsp is generated in response to a Bind_req. If the Bind_req is processed 38
and the Binding Table entry committed on the Remote Device, a Status of 39
SUCCESS is returned. If the Remote Device is not a Primary binding table cache 40
or the SrcAddress, a Status of NOT_SUPPORTED is returned. The supplied 41
endpoint shall be checked to determine whether it falls within the specified range. 42
If it does not, a Status of INVALID_EP shall be returned. If the Remote Device is 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
188 Application Layer Specification
the Primary binding table cache or SrcAddress but does not have Binding Table
resources for the request, a Status of TABLE_FULL is returned. 1
2
2.4.4.2.2.2 Effect on Receipt 3
4
Upon receipt, error checking is performed on the request as described in the 5
previous section. Assuming the Status is SUCCESS, the parameters from the 6
Bind_req are entered into the Binding Table at the Remote Device via the 7
APSME-BIND.request primitive. 8
2.4.4.2.3 Unbind_rsp 9
10
The Unbind_rsp command (ClusterID=0x8022) shall be formatted as illustrated in 11
Figure 2.85. 12
13
Octets: 1 14
Status 15
16
Figure 2.85 Format of the Unbind_rsp Command Frame 17
18
Table 2.114 specifies the fields of the Unbind_rsp command frame. 19
Table 2.114 Fields of the Unbind_rsp Command 20
21
Name Type Valid Range Description 22
Status Integer SUCCESS, The status of the Unbind_req command. 23
NOT_SUPPORTED, 24
INVALID_EP, 25
NO_ENTRY or 26
NOT_AUTHORIZED
27
28
2.4.4.2.3.1 When Generated 29
30
The Unbind_rsp is generated in response to an Unbind_req. If the Unbind_req is
31
processed and the corresponding Binding Table entry is removed from the Remote
32
Device, a Status of SUCCESS is returned. If the Remote Device is not the ZigBee
33
Coordinator or the SrcAddress, a Status of NOT_SUPPORTED is returned. The
34
supplied endpoint shall be checked to determine whether it falls within the
35
specified range. If it does not, a Status of INVALID_EP shall be returned If the
36
Remote Device is the ZigBee Coordinator or SrcAddress but does not have a
37
Binding Table entry corresponding to the parameters received in the request, a
38
Status of NO_ENTRY is returned.
39
40
2.4.4.2.3.2 Effect on Receipt
41
Upon receipt, error checking is performed on the response. If the status is 42
SUCCESS, the device has successfully removed the binding entry for the 43
parameters specified in the Unbind_req. 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 189
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.115 specifies the fields of the Bind_Register_rsp command frame. 10
Table 2.115 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
190 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.116 specifies the fields of the Replace_Device_rsp command frame 19
Table 2.116 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 191
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.117 specifies the fields of the Store_Bkup_Bind_Entry_rsp command 10
frame. 11
Table 2.117 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
192 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.121 specifies the fields of the Backup_Source_Bind_rsp command frame. 10
Table 2.121 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
196 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.126 specifies the fields of the Mgmt_Lqi_rsp command frame. 10
11
Table 2.126 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.127 for 36
details). 37
38
39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 201
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.128 specifies the fields of the Mgmt_Rtg_rsp command frame. 19
Table 2.128 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.129 for details). 39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
204 Application Layer Specification
1
Table 2.129 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
2.4.4.3.3.1 When Generated 31
The Mgmt_Rtg_rsp is generated in response to an Mgmt_Rtg_req. If this 32
management command is not supported, a status of NOT_SUPPORTED shall be 33
returned and all parameter fields after the Status field shall be omitted. Otherwise, 34
the Remote Device shall implement the following processing. 35
36
Upon receipt of and after support for the Mgmt_Rtg_req has been verified, the 37
Remote Device shall perform an NLME-GET.request (for the nwkRouteTable 38
attribute) and process the resulting NLME-GET.confirm (containing the 39
nwkRouteTable attribute) to create the Mgmt_Rtg_rsp command. The 40
Mgmt_Rtg_rsp command shall contain the same status that was contained in the 41
NLME-GET.confirm primitive and if this was not SUCCESS, all parameter fields 42
after the status field shall be omitted. 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 205
From the nwkRouteTable attribute, the routing table shall be accessed, starting
with the index specified by StartIndex, and moved to the RoutingTableList field of 1
the Mgmt_Rtg_rsp command. The entries reported from the routing table shall be 2
those, starting with StartIndex and including whole RoutingTableList records (see 3
Table 2.128) until MSDU size limit, i.e., aMaxMACFrameSize (see [B1]), is 4
reached. Within the Mgmt_Rtg_Rsp command, the RoutingTableEntries field 5
shall represent the total number of Routing Table entries in the Remote Device. 6
The RoutingTableListCount field shall be the number of entries reported in the 7
RoutingTableList field of the Mgmt_Rtg_req command. 8
9
2.4.4.3.3.2 Effect on Receipt 10
11
The local device is notified of the results of its attempt to obtain the routing table. 12
2.4.4.3.4 Mgmt_Bind_rsp 13
14
The Mgmt_Bind_rsp command (ClusterID=0x8033) shall be formatted as 15
illustrated in Figure 2.97. 16
17
Octets: 1 1 1 1 Variable 18
Status BindingTable Start BindingTable BindingTable 19
Entries Index ListCount List 20
21
Figure 2.97 Format of the Mgmt_Bind_rsp Command Frame 22
23
Table 2.130 specifies the fields of the Mgmt_Bind_rsp command frame. 24
Table 2.130 Fields of the Mgmt_Bind_rsp Command 25
26
Name Type Valid Range Description
27
Status Integer NOT_SUPPORTED or The status of the 28
any status code returned Mgmt_Bind_req command. 29
from the APSME- 30
GET.confirm primitive
31
BindingTableEntries Integer 0x00-0xff Total number of Binding 32
Table entries within the 33
Remote Device.
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
206 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.133 specifies the fields of the Mgmt_Direct_Join_rsp command frame. 10
Table 2.133 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
210 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.134 specifies the fields of the Mgmt_Permit_Joining_rsp command 10
frame. 11
Table 2.134 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 211
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.135 specifies the fields of the Mgmt_Cache_rsp command frame. 10
11
Table 2.135 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.136. 31
32
33
34
Table 2.136 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
212 Application Layer Specification
device shall employ APS acknowledged service for the unicast response
to the broadcast inquiry. 1
2
• Service Discovery: Based on the following inputs, the corresponding 3
responses shall be supplied: 4
—NWK address plus Active Endpoint query type – Specified device shall 5
6
return the endpoint number of all applications residing in that device.
7
Should the list of active endpoints exceed the ASDU size and where 8
fragmentation is not supported on the server device, an extended version 9
of the query type is also provided to return the full list through multiple 10
requests. 11
—NWK address or broadcast address (of any broadcast address type) plus 12
13
Service Match including Profile ID and, optionally, Input and Output
14
Clusters – Specified device matches Profile ID with all active endpoints 15
to determine a match. If no input or output clusters are specified, the 16
endpoints that match the request are returned. If input and/or output 17
clusters are provided in the request, those are matched as well, and any 18
matches are provided in the response with the list of endpoints on the 19
device providing the match. The responding device shall employ APS 20
acknowledged service for the unicast response to the broadcast inquiry. 21
By convention, in cases where the application profile enumerates input 22
clusters and their response output clusters with the same cluster identi- 23
fier, the application profile shall list only the input cluster within the 24
Simple Descriptor for the purposes of Service Discovery. 25
26
—NWK address plus Node Descriptor or Power Descriptor query type – 27
Specified device shall return the Node or Power Descriptor for the 28
device. 29
30
—NWK address, Endpoint Number plus Simple Descriptor query type – 31
Specified address shall return the Simple Descriptor associated with that 32
Endpoint for the device. Should the list of input and/or output clusters 33
exceed the ASDU size capacity to return the Simple Descriptor in a sin- 34
gle packet an extended version of the query type is also provided to 35
return the full list through multiple requests. 36
37
—Optionally, NWK address plus Complex or User Descriptor query type 38
– If supported, specified address shall return the Complex or User 39
Descriptor for the device 40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
220 Application Layer Specification
• Permits the Trust Center to switch the active network key using the APSME-
SWITCH-KEY primitives. 1
2
• Permits devices in the network to authenticate other devices using the APSME- 3
AUTHENTICATE primitives. 4
5
2.5.2.4 Network Manager 6
This function shall implement the ZigBee Coordinator, ZigBee Router, or ZigBee 7
End Device logical device types according to configuration settings established 8
either via a programmed application or during installation. If the device type is a 9
ZigBee Router or ZigBee End Device, this function shall provide the ability to 10
select an existing PAN to join and implement procedures which permit the device 11
to rejoin if network communication is lost. If the device type is a ZigBee 12
Coordinator or ZigBee Router, this function shall provide the ability to select an 13
unused channel for creation of a new PAN. Note that it is possible to deploy a 14
network without a device pre-designated as ZigBee Coordinator where the first 15
Full Function Device (FFD) activated assumes the role of ZigBee Coordinator. 16
The following description covers processing addressed by Network Management: 17
18
• Permits specification of a channel list for network scan procedures. Default is 19
to specify use of all channels in the selected band of operation. 20
• Manages network scan procedures to determine neighboring networks and the 21
identity of their ZigBee coordinators and routers. 22
23
• Permits selection of a channel to start a PAN (ZigBee Coordinator) or selection 24
of an existing PAN to join (ZigBee Router or ZigBee End Device). 25
• Supports orphaning and extended procedures to rejoin the network, including 26
support for intra_PAN portability. 27
28
• May support direct join. For ZigBee Coordinators and ZigBee Routers, a local 29
version of direct join may be supported to enable the device to join via the 30
orphaning or rejoin procedures. 31
• May support Management Entities that permit external network management. 32
33
• Detects and reports interference to support changing network channels. 34
• Manages network interference reporting and selection of a new channel for 35
network operation if interference exists on the initial channel if the particular 36
node is identified as the network manager for the overall PAN. 37
38
2.5.2.5 Binding Manager 39
40
The Binding Manager performs the following: 41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
222 Application Layer Specification
• Establishes resource size for the Binding Table. The size of this resource is
determined via a programmed application or via a configuration attribute 1
defined during installation. 2
3
• Processes bind requests for adding or deleting entries from the APS binding 4
table. 5
• Supports Bind and Unbind commands from external applications such as those 6
that may be hosted on a commissioning or network management tool to support 7
assisted binding. Bind and Unbind commands shall be supported via the 8
ZigBee Device Profile (see clause 2.4). 9
10
• For the ZigBee Coordinator, supports the End Device Bind that permits binding 11
on the basis of button presses or other manual means. 12
• Permits source devices to register with a primary binding table cache their 13
ability to hold their own binding table. 14
15
• Permits configuration tools to exchange one device for another in all the 16
binding table entries which refer to it. 17
• Permits the primary binding table cache to backup and recover individual bind 18
entries or the entire binding table or the table of source devices holding their 19
own binding tables. 20
21
2.5.2.6 Node Manager 22
23
For ZigBee Coordinators and ZigBee Routers, the Node Management function 24
performs the following: 25
• Permits remote management commands to perform network discovery. 26
27
• Provides remote management commands to retrieve the routing table. 28
• Provides remote management commands to retrieve the binding table. 29
30
• Provides a remote management command to have the device leave the network 31
or to direct that another device leave the network. 32
• Provides a remote management command to retrieve the LQI for neighbors of 33
the remote device. 34
35
• Provides a remote management command to Permit or disallow joining on 36
particular routers or to generally allow or disallow joining via the Trust Center. 37
38
2.5.2.7 Group Manager 39
The Group Manager performs the following: 40
41
• Provides for inclusion of application objects within the local device into groups 42
under application control. 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 223
• Provides for removal of application objects within the local device from group
membership under application control. 1
2
3
2.5.3 Layer Interface Description 4
5
Unlike other device descriptors for applications residing above Endpoints 1-254, 6
the ZigBee Device Objects (ZDO) interface to the APS via the APSME-SAP in 7
addition to the APSDE-SAP. ZDO communicates over Endpoint 0 using the 8
APSDE-SAP via Profiles like all other applications. The Profile used by ZDO is 9
the ZigBee Device Profile (See clause 2.4). ZDO frames shall not be fragmented. 10
ZigBee Device Objects shall employ Endpoint 0 as the source and destination 11
endpoint in any transmitted ZigBee Device Profile request frames, and shall 12
expect Endpoint 0 as the source and destination endpoint in any received response 13
frames. 14
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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
224 Application Layer Specification
11
1
Group Manager Object Configuration Attributes
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
:Config_Max_Assoc 18
APSME-REMOVE-ALL-
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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
228 Application Layer Specification
• Node Manager
1
• Group Manager 2
Table 2.139 describes these ZigBee Device Objects. 3
4
Table 2.139 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 229
endpoint 0 and not to the end applications (which run on endpoints 1 through
254). 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 attributes shown in Table 2.140 to 9
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 attributes set as described 30
above. This should have the effect of executing the procedure for network formation 31
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 attribute value 37
supplied using the NLME-PERMIT-JOINING.request. Additionally, the 38
nwkNetworkBroadcastDeliveryTime and nwkTransactionPersistenceTime Network 39
Information Block attributes (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 254 return appropriate error status values prior to 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
230 Application Layer Specification
Primary Discovery Cache device, the device shall be configured to process server
commands for the ZigBee Device Profile associated with requests to the Primary 1
Discovery Cache and shall operate according to the state machine description 2
provided in sub-clause 2.5.2.1. 3
4
If supported, provision shall be made to supply configuration elements for the 5
Complex Descriptor, User Descriptor, the maximum number of bind entries, and 6
the master key. These elements shall be embodied in 7
:Config_Complex_Descriptor, :Config_User_Descriptor, :Config_Max_Bind and 8
:Config_Master_Key. 9
To start as a ZigBee router, the device application shall execute the startup 10
procedure described in sub-clause 2.5.5.5.6.2 with startup attributes set as described 11
above. This should have the effect of executing either the procedure for network 12
rejoin described in sub-clause 3.6.1.4.2 or else the full procedure for network join 13
through MAC association described in sub-clause 3.6.1.4.1. The NLME- 14
NETWORK-DISCOVERY.request procedure shall be implemented 15
:Config_NWK_Scan_Attempts, each separated in time by 16
:Config_NWK_Time_btwn_Scans. The purpose of repeating the NLME- 17
NETWORK-DISCOVERY.request is to provide a more accurate neighbor list and 18
associated link quality indications to the NWK layer. Specification of the 19
algorithm for selection of the PAN shall be left to the profile description and may 20
include use of the Extended PAN ID, operational mode of the network, identity of 21
the ZigBee Router or Coordinator identified on the PAN, depth of the ZigBee 22
Router on the PAN from the ZigBee Coordinator for the PAN, capacity of the 23
ZigBee Router or Coordinator, the routing cost, or the Protocol Version Number 24
(these parameters are supplied by the NLME-NETWORK-DISCOVERY.confirm 25
and the beacon payload). 26
27
The ZigBee router may join networks employing the current protocol version 28
number or may join networks employing a previous protocol version number, 29
under application control, if backward compatibility is supported in the device. A 30
single ZigBee PAN shall consist of devices employing only a single protocol 31
version number (networks with devices employing different protocol version 32
numbers and frame formats within the same PAN are not permitted). An optional 33
configuration attribute, :Config_NWK_alt_protocol_version, provides the 34
protocol version numbers which the device may choose to employ other than the 35
current protocol version number. Once the ZigBee router chooses a PAN and a 36
specific protocol version number, it shall employ that protocol version number as 37
its nwkcProtocolVersion. Additionally, the ZigBee router shall then adhere to all 38
frame formats and processing rules supplied by the version of the ZigBee 39
Specification employing that protocol version number. 40
The :Config_Permit_Join_Duration shall be set according to the default parameter 41
value supplied using NLME-PERMIT-JOINING.request. The router shall support 42
the NLME-START-ROUTER.request and NLME-START-ROUTER.confirm to 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 233
begin operations as a router within the PAN it has joined. Additionally, the
nwkNetworkBroadcastDeliveryTime and nwkTransactionPersistenceTime 1
Network Information Block attributes (see sub-clause 3.6.2) shall be set with 2
:Config_NWK_BroadcastDeliveryTime and 3
:Config_NWK_TransactionPersistenceTime respectively (see sub-clause 2.5.6). 4
5
Provision shall be made to ensure APS primitive calls from the end applications 6
over EP 1 through EP 254 return appropriate error status values prior to 7
completion of the Initialization state by ZigBee Device Objects and transition to 8
the normal operating state. 9
If the network has security enabled, the device shall wait to be authenticated by 10
the Trust Center, and for successful acquisition of the NWK key to start 11
functioning as a router in the network. See sub-clause 4.6.2 for details on Trust 12
Center operations. 13
14
The device application shall set the nwkSecurityLevel and nwkSecureAllFrames 15
NIB attributes to the values used in the network and begin functioning as a router 16
using NLME-START-ROUTER.req. 17
18
2.5.5.5.2.2 Normal Operating State 19
In this state, the ZigBee router shall allow other devices to join the network based 20
on the configuration items :Config_Permit_Join_Duration and 21
:Config_Max_Assoc. When a new device joins the network, the device 22
application shall be informed via the NLME-JOIN.indication attribute. Should the 23
device be admitted to the PAN, the ZigBee router shall indicate this via the 24
NLME-JOIN.confirm with SUCCESS status. If security is enabled on the 25
network, the device application shall inform the Trust Center via the APSME- 26
UPDATE-DEVICE. request. 27
28
Orphan indications for which this device is not the parent are notified to the ZDO 29
from the NWK layer by receipt of an NLME-JOIN.indication primitive with 30
parameter IsParent set to value FALSE. The mechanism by which this is handled 31
is described in 2.5.5.5.4. 32
The ZigBee router shall respond to any device discovery or service discovery 33
operations requested of its own device, and if it is designated as a Primary 34
Discovery Cache device, shall also respond on behalf of registered devices that 35
have stored discovery information. The device application shall also ensure that 36
the number of binding entries does not exceed the :Config_Max_Bind attribute. 37
38
If security is supported operating in commercial mode, the ZigBee router shall 39
support the :Config_Master_Key and shall employ the Master Key in key 40
establishment procedures for Link Keys. Upon presentation of a remote 41
destination address requiring secure communications, the ZigBee router shall 42
support APSME-ESTABLISH-KEY.request to establish a link key with the 43
remote device and APSME-ESTABLISH-KEY.indication to present the request to 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
234 Application Layer Specification
the network is found more than once the router should attempt to rejoin where
there is a more recent value of nwkUpdateId in the beacon payload. 1
2
2.5.5.5.3 Binding Table Cache Operation 3
Any router (including the coordinator) may be designated as either a primary 4
binding table cache or a backup binding table cache. 5
6
It shall respond to the System_Server_Discovery_req primitive to enable other 7
devices to discover it and use its facilities. 8
A primary binding table cache shall maintain a binding table and a table of 9
devices registered to cache their binding tables. 10
11
A primary binding table cache shall respond to the Bind_Register_req and 12
Replace_Device_req primitives described in clause 2.4.3.2. 13
If a backup binding table cache is available, a primary binding table cache shall 14
use the additional bind management primitives to backup and restore its binding 15
table and its table of source binding devices. 16
17
A backup binding table cache shall maintain a backup of the binding table and 18
table of registered binding devices for one or more primary binding table caches. 19
It shall support the bind management primitives for backup and restore of these 20
tables. 21
2.5.5.5.4 Operations to Support Intra-PAN Portability 22
23
24
2.5.5.5.4.1 Overview
25
The operations described in this section are carried out by ZigBee Coordinator 26
and ZigBee Router Devices for support of intra-PAN portability. 27
28
The main steps are summarized as follows:- 29
• Detect the problem - The ZDO of the moved device is notified of 30
acknowledgement failures via the NLME-NWK-STATUS.indication 31
primitive, and identifies a problem. 32
33
• Carry out the NWK layer rejoin procedure - The ZDO of a moved ZED 34
initiates this process using the NLME-JOIN.request primitive, either through a 35
secured or un-secured rejoining procedure. The NWK rejoin procedures closely 36
mirror the MAC association procedure. Note that ZigBee Routers shall also 37
carry out this procedure periodically if they find that they are no longer in 38
contact with the Trust Center. 39
• Security verification - Secured and unsecured protocol steps are described to 40
ensure that the orphaned device should really be accepted. (See 41
clause 2.5.5.5.4.2.) 42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
236 Application Layer Specification
• Inform the rest of the network - when a device changes parents the steps to
complete address conflict detection in sub-clause 3.6.1.9 must be completed. 1
These actions also serve to notify the old parent that the End Device has 2
changed parents. 3
4
These steps are described in detail in the subsections below. The mechanism is 5
illustrated for secured rejoin of a ZED in Figure 2.108, trust center rejoin of a 6
ZED in Figure 2.109, and trust center rejoin of a ZR in Figure 2.110 respectively. 7
Note that the NWK and SEC sections on secured and trust center rejoin (sub- 8
clauses 3.2.2.11, 3.2.2.12, 3.2.2.13, 3.6.1.4 and 4.6.3) shall be the authoritative 9
text for these procedures. The diagrams in this section are provided for illustrative 10
purposes only. 11
12
New New 13
Child’s Child’s Trust
Old parent parent’s parent’s
NWK ZDO
NWK ZDO
Centre 14
15
16
NO_ACK (x 12) 17
ROUTE-ERROR. 18
indication 19
Optional active scan. Select parent, eg: by 20
EPID. If rejoin fails then retry later. 21
JOIN.request 22
(RejoinNetwork=2) 23
Rejoin request
(secured at NWK layer with NWK key, JOIN.indication 24
from IEEE address) (secured rejoin) 25
Rejoin response (secured at NWK layer 26
with NWK key, to IEEE address, includes
JOIN.confirm short address) 27
(SUCCESS) 28
Entity authentication [if required] 29
30
Device_annce
(if short address changed) Device_annce 31
32
33
Figure 2.108 Portability Message Sequence Chart: ZED Secured Rejoin 34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 237
New New
Child’s Child’s Trust 1
Old parent parent’s parent’s
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)
Rejoin response (unsecured, to IEEE
JOIN.indication
Update device
12
(trust center
address, includes short address) rejoin) 13
Key transport
JOIN.confirm 14
(NWK key)
(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 Trust Center 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
238 Application Layer Specification
The ZigBee end device may join networks employing the current protocol version
number or may join networks employing a previous protocol version number, 1
under application control, if backward compatibility is supported in the device. A 2
single ZigBee PAN shall consist of devices employing only a single protocol 3
version number (networks with devices employing different protocol version 4
numbers and frame formats within the same PAN are not permitted). An optional 5
configuration attribute, :Config_NWK_alt_protocol_version, provides the 6
protocol version numbers which the device may choose to employ other than the 7
current protocol version number. Once the ZigBee end device chooses a PAN and 8
a specific protocol version number, it shall employ that protocol version number 9
as its nwkcProtocolVersion. Additionally, the ZigBee end device shall then adhere 10
to all frame formats and processing rules supplied by the version of the ZigBee 11
Specification employing that protocol version number. 12
13
If the device application sets the NLME-JOIN RxOnWhenIdle parameter to 14
FALSE, the :Config_NWK_indirectPollRate shall be used to determine the 15
polling rate for indirect message requests. The :Config_NWK_indirectPollRate 16
shall be set according to the value established by the application profile(s) 17
supported on the device. Once polling for indirect message requests is initiated, if 18
communications failure with the parent is detected determined by failure of 19
indirect message requests :Config_Parent_Link_Threshold_Retry consecutive 20
attempts, the device application shall employ the network rejoin procedure. 21
Once the End Device has successfully joined a network, the device shall issue a 22
Device_annce providing its 64-bit IEEE address and 16-bit NWK address. 23
24
Provision shall be made to ensure APS primitive calls from the end applications 25
over EP 1 through EP 254 return appropriate error status values prior to 26
completion of the Initialization state by ZigBee Device Objects and transition to 27
the normal operating state. 28
If the network has security enabled, the device shall wait to be authenticated by 29
the Trust Center and for successful acquisition of the NWK key to start 30
functioning as an end device in the network. See sub-clause 4.6.2 for details on 31
Trust Center operations. 32
33
2.5.5.5.5.2 Normal Operating State 34
35
If the device application set the NLME-JOIN RxOnWhenIdle parameter to 36
FALSE, the :Config_NWK_indirectPollRate shall be used to poll the parent for 37
indirect transmissions while in the normal operating state. While a fragmented 38
message is being received, the device may temporarily increase its polling rate, 39
and shall ensure that it polls its parent at least once every 40
macTransactionPersistenceTime seconds. 41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
242 Application Layer Specification
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. 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
reliability, shall select an appropriate new parent based on the following 42
information from that device's beacon: 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 243
• PAN ID
1
• EPID (Extended PAN ID) 2
• Channel 3
4
• Signal strength 5
• Whether the potential parent indicates that it is currently able to communicate 6
with its Trust Center 7
8
• Whether this device has recently failed to join this parent, or this network 9
Once a potential parent has been selected, the ZDO shall issue an NLME- 10
JOIN.request primitive with RejoinNetwork set to 0x02. 11
12
The start time of the rejoin process is determined by the time the last NLME- 13
JOIN.request primitive was sent and by the attribute :Config_Rejoin_Interval. 14
Only if the interval between the current and the previous NLME-JOIN.request 15
sent time is longer than the :Config_Rejoin_Interval shall a new NLME- 16
JOIN.request primitive be sent. The application may want to gradually increase 17
the :Config_Rejoin_Interval if a certain number of retries have been done (or a 18
certain period of time has passed) but none of them were successful. The 19
:Config_Rejoin_Interval should not exceed the :Config_Max_Rejoin_Interval. 20
Every time an NLME-JOIN.confirm has been successfully received, the ZDO 21
shall reset its failure counter to zero and the :Config_Rejoin_Interval attribute to 22
its initial value. The choice of the default initial value and the algorithm of 23
increasing the rejoin interval shall be determined by the application, and is out of 24
the scope of this document. 25
If the ZigBee End Device rejoins a new parent using the rejoin process, it shall 26
complete the address conflict process in sub-clause 3.6.1.9. 27
28
The ZigBee end device may generate APSME-AUTHENTICATE.requests under 29
application control from other application objects and may process and respond to 30
APSME-AUTHENTICATE.indications from other devices. The ZigBee end 31
device shall supply APSME-AUTHENTICATE.confirms to application objects 32
whose requests have been processed. 33
2.5.5.5.6 Support for Commissioning Applications 34
35
ZigBee devices in the field will need commissioning, and it will be up to 36
developers to provide applications that perform such commissioning. There is a 37
risk that applications from different vendors will work differently, thereby 38
diminishing the ability of ZigBee devices from different vendors to operate 39
seamlessly on the same network. As a partial solution to this problem, this sub- 40
clause lists a common set of configuration attributes for ZigBee devices and 41
outlines a common procedure for devices to use at start-up time. The other critical 42
component of the solution is a common set of commissioning protocols and 43
procedures, which are outside the scope of this document. 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
244 Application Layer Specification
clause 3.6.1.4.1 and should use the value of apsChannelMask for the
ScanChannels parameter of the NLME-NETWORK-FORMATION.request 1
primitive, and set nwkExtendedPANID to the value given in 2
apsUseExtendedPANID if apsUseExtendedPANID has a non-zero value. 3
4
If the device is not the designated coordinator and apsUseExtendedPANID has a 5
non-zero value, the device should attempt to rejoin the network specified in 6
apsUseExtendedPANID. To do this, it should use NLME-JOIN.request with the 7
ExtendedPANID parameter equal to the value of apsUseExtendedPANID, the 8
ScanChannels parameter of the primitive equal to the value of the 9
apsChannelMask configuration attribute. The RejoinNetwork parameter of the 10
NLME-JOIN.request primitive should have a value of 0x02 indicating rejoin. 11
If the network rejoin attempt fails, and the value of the apsUseInsecureJoin 12
attribute of the AIB has a value of TRUE, then the device should follow the 13
procedure outlined in sub-clause 3.6.1.4.1 for joining a network, using 14
apsChannelMask any place that a ScanChannels mask is called for. If 15
apsUseExtendedPANID has a non-zero value, then the device should join only the 16
specified network and the procedure should fail if that network is found to be 17
inaccessible. If apsUseExtendedPANID is equal to 0x0000000000000000, then 18
the device should join the best available network. 19
20
2.5.5.5.6.3 Further Commissioning 21
22
Once a device is on a network and capable of communicating with other devices 23
on the network in a secure manner, other commissioning becomes possible. Other 24
items that should be subject to commissioning are shown in Table 2.141. 25
Table 2.141 Additional Commissioning Attributes 26
27
Name Reference Comment 28
apsBindingTable Table 2.24 The binding table for this device. Binding 29
provides a separation of concerns in the 30
sense that applications may operate without 31
having to manage recipient address 32
information for the frames they emit. This 33
information can be input at commissioning
time without the main application on the 34
device even being aware of it. 35
36
nwkGroupIDTable Table 3.43 Commissioning applications should be able
to manage group membership of a device 37
and its endpoints by accessing this table. 38
39
nwkSecurityMaterialSet Table 4.2 This set contains the network keying
material, which should be accessible to 40
commissioning applications. 41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 2
246 Application Layer Specification
For all ZigBee logical device types, reception of the NWK Network Status
indication shall be supported, but no action is required in this version of the 1
specification. 2
3
Table 2.145 Network Manager Attributes
4
Attribute M/O Type 5
6
NLME-GET.request M Private 7
NLME-GET.confirm M Private 8
NLME-SET.request M Private 9
10
NLME-SET.confirm M Private 11
NLME-NETWORK-DISCOVERY.request M Public 12
13
NLME-NETWORK-DISCOVERY.confirm M Public
14
NLME-NETWORK-FORMATION.request O Private 15
NLME-NETWORK- O Private 16
FORMATION.confirm 17
NLME-START-ROUTER.request O Private 18
19
NLME-START-ROUTER.confirm O Private 20
NLME-JOIN.request O Private 21
22
NLME-JOIN.confirm O Private
23
NLME_JOIN.indication O Private 24
NLME-PERMIT-JOINING O Public 25
26
NLME-PERMIT-JOINING.confirm O Public
27
NLME-DIRECT-JOIN.request O Public 28
NLME-DIRECT-JOIN.confirm O Public 29
30
NLME_LEAVE.request M Public
31
NLME-LEAVE.confirm M Public 32
NLME_LEAVE.indication M Public 33
34
NLME-RESET.request O Private 35
NLME-RESET.confirm O Private 36
NLME-SYNC.request O Public 37
38
NLME-SYNC.indication O Public 39
NLME-SYNC.confirm O Public 40
41
NLME-NWK-STATUS.indication M Private
42
NLME-ROUTE-DISCOVERY.request O Public 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 253
C HAPTER
1
2
3 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
264 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
on a unicast, the NLDE issues the NLDE-DATA.confirm primitive with a status 28
equal to that received from the MAC sub-layer. Upon transmission of a MCPS- 29
DATA.confirm primitive, in the case of a broadcast or multicast, the NLDE 30
immediately issues the NLDE-DATA.confirm primitive with a status of success. 31
32
If the nwkSecurityLevel NIB attribute has a non-zero value and the SecurityEnable 33
parameter has a value of TRUE, then NWK layer security processing will be 34
applied to the frame before transmission as described in clause 4.3. Otherwise, no 35
security processing will be performed at the NWK layer for this frame. If security 36
processing is performed and it fails for any reason, then the frame is discarded and 37
the NLDE issues the NLDE-DATA.confirm primitive with a Status parameter 38
value equal to that returned by the security suite. 39
40
3.2.1.2 NLDE-DATA.confirm 41
This primitive reports the results of a request to transfer a data PDU (NSDU) from 42
a local APS sub-layer entity to a single peer APS sub-layer entity. 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 267
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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 269
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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 277
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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 279
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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
280 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
282 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
EnergyDetectList 9
} 10
11
Table 3.16 specifies the parameters for the service primitive. 12
Table 3.16 NLME-ED-SCAN.confirm
13
14
Valid 15
Name Type Range Description 16
Status Status SUCCESS, The status of the request. 17
or any valid 18
code from 19
the MAC 20
EnergyDetectList List of 0x00-0xff for The list of energy measurements in 21
integers each integer accordance with [B1], one for each 22
channel. 23
24
3.2.2.10.2 When Generated 25
26
This primitive is generated by the NLME of a ZigBee device in response to an
27
NLME-ED-SCAN.request. The status indicates the status received from the MAC
28
sub-layer primitive MLME-SCAN.confirm. EnergyDetectList contains the ED
29
scan result (List of integers, 0x00 - 0xff) for the channels scanned in accordance
30
with IEEE 802.15.4-2003.
31
3.2.2.10.3 Effect on Receipt 32
33
On receipt of this primitive, the next higher layer is notified of the results of an 34
ED scan. 35
36
3.2.2.11 NLME-JOIN.request 37
This primitive allows the next higher layer to request to join or rejoin a network, 38
or to change the operating channel for the device while within an operating 39
network. 40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 283
Once the device has successfully joined a network, it will set the value of the
nwkExtendedPANId NIB attribute to the extended PAN identifier of the network to 1
which it joined. 2
3
If a device receives this primitive and the RejoinNetwork parameter is equal to 4
0x03, and the device supports setting the value of phyCurrentChannel then the 5
device attempts to switch the operating channel to that provided in the 6
ScanChannels parameter. If more than one channel is provided in the 7
ScanChannels parameter, the NLME issues an NLME-JOIN.confirm primitive 8
with the Status parameter set to INVALID_REQUEST. If the channel change is 9
performed successfully, then the device issues a NLME-JOIN.confirm with the 10
Status parameter set to SUCCESS. If the device does not support the setting of 11
phyCurrentChannel directly, then the NLME issues a NLME-JOIN.confirm 12
primitive with the Status parameter set to UNSUPPORTED_ATTRIBUTE. 13
If the MAC layer returned an error status during the channel change then this 14
status shall be reported in the status field of the NLME-JOIN.confirm primitive.15 15
16
3.2.2.12 NLME-JOIN.indication 17
18
This primitive allows the next higher layer of a ZigBee coordinator or ZigBee 19
router to be notified when a new device has successfully joined its network by 20
association or rejoined using the NWK rejoin procedure as described in sub- 21
clause 3.6.1.4.3. 22
3.2.2.12.1 Semantics of the Service Primitive 23
24
The semantics of this primitive are as follows: 25
26
NLME-JOIN.indication {
27
NetworkAddress,
28
ExtendedAddress,
29
CapabilityInformation, 30
RejoinNetwork 31
SecureRejoin 32
} 33
34
35
36
37
38
39
40
41
42
43
15. ZigBee Document 12-0220-04 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
286 Network Specification
router or end device and issued to its next higher layer to indicate that it has been
successfully removed from the network by its associated router or ZigBee 1
coordinator. 2
3
3.2.2.17.3 Effect on Receipt 4
On receipt of this primitive, the next higher layer of a ZigBee coordinator or 5
ZigBee router is notified that a device, formerly on the network, has left. The 6
primitive can also inform the next higher layer of a ZigBee router or end device 7
that it has been removed from the network by its associated ZigBee router or 8
ZigBee coordinator parent. In this case, the value of the Rejoin parameter 9
indicates to the next higher layer whether the peer entity on the parent device 10
wishes the device that has been removed to rejoin the same network. 11
12
3.2.2.18 NLME-LEAVE.confirm 13
14
This primitive allows the next higher layer of the initiating device to be notified of 15
the results of its request for itself or another device to leave the network. 16
3.2.2.18.1 Semantics of the Service Primitive 17
18
The semantics of this primitive are as follows: 19
20
NLME-LEAVE.confirm {
21
Status,
22
DeviceAddress 23
} 24
25
Table 3.24 specifies the parameters for the NLME-LEAVE.confirm primitive. 26
Table 3.24 NLME-LEAVE.confirm Parameters 27
28
Name Type Valid Range Description 29
Status Status SUCCESS, INVALID_REQUEST, The status of the 30
UNKNOWN_DEVICE or any corresponding request. 31
status returned by the MCPS- 32
DATA.confirm primitive 33
DeviceAddress 64-bit Any 64-bit, IEEE address The 64-bit IEEE address 34
IEEE in the request to which 35
address this is a confirmation or 36
null if the device
37
requested to remove
itself from the network. 38
39
40
3.2.2.18.2 When Generated
41
This primitive is generated by the initiating NLME and issued to its next higher 42
layer in response to an NLME-LEAVE.request primitive. If the request was 43
successful, the Status parameter indicates a successful leave attempt. Otherwise, 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
294 Network Specification
the NLME issues the NLME-RESET.confirm with the Status parameter set to
SUCCESS if the MAC sub-layer was successfully reset or 1
DISABLE_TRX_FAILURE otherwise. 2
3
On receipt of this primitive where WarmStart is set to TRUE, the network layer 4
should not modify any NIB values, but rather should resume normal network 5
operations and consider itself part of the network specified in the NIB. Routing 6
table values and neighbor table values should be cleared. The method by which 7
the network and MAC layers attributes are pre-loaded is left to the implementer. 8
If this primitive is issued to the NLME of a device that is currently joined to a 9
network, any required leave attempts using the NLME-LEAVE.request primitive 10
should be made a priori at the discretion of the next higher layer. 11
12
3.2.2.20 NLME-RESET.confirm 13
14
This primitive allows the next higher layer of the initiating device to be notified of 15
the results of the request to reset the NWK layer. 16
3.2.2.20.1 Semantics of the Service Primitive 17
18
The semantics of this primitive are as follows: 19
20
NLME-RESET.confirm {
21
Status
22
}
23
24
Table 3.26 specifies the parameters for this primitive. 25
Table 3.26 NLME-RESET.confirm Parameters 26
27
Name Type Valid Range Description 28
Status Status Any status value returned The result of the reset operation 29
from the MLME- 30
RESET.confirm primitive 31
(see [B1]) 32
33
3.2.2.20.2 When Generated 34
35
This primitive is generated by the NLME and issued to its next higher layer in
36
response to an NLME-RESET.request primitive. If the request was successful, the
37
Status parameter will have a value of SUCCESS. Otherwise, the Status parameter
38
will indicate an error code of DISABLE_TRX_FAILURE. The reasons for these
39
status values are fully described in sub-clause 3.2.2.19.3.
40
3.2.2.20.3 Effect on Receipt 41
42
On receipt of this primitive, the next higher layer is notified of the results of its 43
request to reset the NWK layer. 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
296 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 309
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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
314 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 315
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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 317
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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 321
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
• The Sequence Number field in the NWK header shall be created for every hop 5
during the route reply process. The Radius Field shall be set to nwkMaxDepth * 6
2 by the target of the route request. Every hop during the Route Reply process 7
shall decrement the radius by 1.17 If the value of the radius in the received 8
Route Reply message is 1, the relaying router shall set the radius of the 9
message to 1. The Sequence Number shall be created as if it were a new frame 10
from the device transmitting the frame replacing the sequence number with the 11
device’s next available sequence number. The Route Reply frame is not a 12
forwarded frame, but is newly created by each hop during the route reply 13
process. 14
15
3.4.2.3 NWK Payload Fields 16
The NWK frame payload contains a command identifier field, a command options 17
field, the route request identifier, originator and responder addresses and an up-to- 18
date summation of the path cost. 19
20
The command frame identifier shall contain the value indicating a route reply 21
command frame. 22
3.4.2.3.1 Command Options Field 23
24
The format of the 8-bit command options field is shown in Figure 3.14. 25
26
Bit: 0 – 3 4 5 6 7 27
Reserved Originator Responder Multicast Reserved 28
IEEE address IEEE address 29
30
Figure 3.14 Route Reply Command Options Field
31
32
3.4.2.3.1.1 Originator IEEE Address 33
The originator IEEE address sub-field is a single-bit field. It shall have a value of 34
1 if and only if the originator IEEE address field is included in the payload. This 35
bit shall be set when nwkUniqueAddr is FALSE. 36
37
3.4.2.3.1.2 Responder IEEE Address 38
39
The responder IEEE address sub-field is a single-bit field. It shall have a value of 40
1 if, and only if, the responder IEEE address field is included in the payload. This 41
42
43
17. CCB 1400/1414 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
322 Network Specification
bit shall be set when nwkUniqueAddr is FALSE and the multicast sub-field is set
to 0. 1
2
3.4.2.3.1.3 Multicast Sub-Field 3
4
The multicast sub-field is a single-bit field. It shall have a value of 1 if and only if 5
the command frame is a reply to a request for a route to a multicast group, in 6
which case the responder address field contains the Group ID of the desired 7
group. 8
3.4.2.3.2 Route Request Identifier 9
10
The route request identifier is the 8-bit sequence number of the route request to 11
which this frame is a reply. 12
13
3.4.2.3.3 Originator Address
14
The originator address field shall be 2 octets in length and shall contain the 16-bit 15
network address of the originator of the route request command frame to which 16
this frame is a reply. 17
18
3.4.2.3.4 Responder Address 19
The responder address field shall be 2 octets in length and shall always be the 20
same as the value in the destination address field of the corresponding route 21
request command frame. 22
23
3.4.2.3.5 Path Cost 24
The path cost field is used to sum link cost as the route reply command frame 25
transits the network (see sub-clause 3.6.3.5.3). 26
27
3.4.2.3.6 Originator IEEE Address 28
The originator IEEE address field shall be 8 octets in length and shall contain the 29
64-bit address of the originator of the route request command frame to which this 30
frame is a reply. This field shall only be present if the originator IEEE address 31
sub-field of the command options field has a value of 1. 32
33
3.4.2.3.7 Responder IEEE Address 34
The responder IEEE address field shall be 8 octets in length and shall contain the 35
64-bit address of the destination of the route request command frame to which this 36
frame is a reply. This field shall only be present if the responder IEEE address 37
sub-field of the command options field has a value of 1. 38
39
40
3.4.3 Network Status Command 41
42
A device uses the network status command to report errors and other conditions 43
arising in the NWK layer of a particular device to the peer NWK layer entities of 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 323
other devices in the network. The NWK status command may be also used to
diagnose network problems, e.g. address conflicts. The payload of a network 1
status command shall be formatted as illustrated in Figure 3.15. 2
3
Octets: 1 2 4
5
Status code Destination address
6
NWK command payload 7
8
Figure 3.15 Network Status Command Frame Format
9
10
3.4.3.1 MAC Data Service Requirements
11
In order to transmit this command using the MAC data service, specified in IEEE 12
802.15.4-2003 [B1], the following information shall be provided: 13
14
• The destination MAC address and PAN identifier shall be set to the network 15
address and PAN identifier, respectively, of the first hop in the path to the 16
destination of the command frame or to the broadcast address 0xffff in the case 17
where the command frame is being broadcast at the NWK layer. 18
• The source MAC address and PAN identifier shall be set to the network 19
address and PAN identifier of the device sending the network status command. 20
21
• The frame control field shall be set to specify that the frame is a MAC data 22
frame with MAC security disabled, since any secured frame originating from 23
the NWK layer shall use NWK layer security. The transmission options shall 24
not be set to require acknowledgement if the destination MAC address is the 25
broadcast address 0xffff. 26
• The addressing mode and intra-PAN flags shall be set to support the addressing 27
fields described here. 28
29
3.4.3.2 NWK Header Fields 30
31
Network status commands may be either unicast or broadcast. The fields of the 32
NWK header shall be set as follows: 33
• The source address field shall always be set to the 16-bit network address of the 34
device originating the command frame. 35
36
• The source IEEE address sub-field of the frame control field shall be set to 1 37
and the source IEEE address field of the NWK header shall be present and shall 38
contain the 64-bit IEEE address of the originator of the frame. 39
• When sent in response to a routing error, the destination address field in the 40
NWK header shall be set to the same value as the source address field of the 41
data frame that encountered a forwarding failure. 42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
324 Network Specification
• If and only if, the network status command frame is not broadcast, the
destination IEEE address sub-field of the frame control field shall have a value 1
of 1 and the destination IEEE address field of the NWK header shall be present 2
and shall contain the 64-bit IEEE corresponding to the 16-bit network address 3
in the destination address field if this IEEE address is known. 4
5
3.4.3.3 NWK Payload Fields 6
7
The NWK frame payload of the network status command frame contains a 8
command frame identifier field, a status code field and a destination address field 9
as described below. The command frame identifier shall be set to specify the 10
network status command frame as defined in Table 3.40. 11
3.4.3.3.1 Status Code 12
13
The status code shall be set to one of the non-reserved values shown in 14
Table 3.42. 15
Table 3.42 Status Codes for Network Status Command Frame 16
17
Value Status Code 18
0x00 No route available 19
20
0x01 Tree link failure 21
0x02 Non-tree link failure 22
0x03 Low battery level 23
24
0x04 No routing capacity 25
0x05 No indirect capacity 26
27
0x06 Indirect transaction expiry
28
0x07 Target device unavailable 29
0x08 Target address unallocated 30
31
0x09 Parent link failure
32
0x0a Validate route 33
0x0b Source route failure 34
35
0x0c Many-to-one route failure
36
0x0d Address conflict 37
0x0e Verify addresses 38
39
0x0f PAN identifier update 40
0x10 Network address update 41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 325
Table 3.42 Status Codes for Network Status Command Frame (Continued)
1
Value Status Code 2
0x11 Bad frame counter 3
4
0x12 Bad key sequence number
5
0x13 – 0xff Reserved 6
7
These status codes are used both as values for the status code field of a network 8
status command frame and as values of the Status parameter of the NLME-NWK- 9
STATUS.indication primitive. A brief explanation of each follows: 10
11
• No route available: Route discovery and/or repair has been attempted and no 12
route to the intended destination address has been discovered. 13
• Tree link failure: The routing failure occurred as a result of the failure of an 14
attempt to route the frame along the tree. 15
16
• Non-tree link failure: The routing failure did not occur as a result of an 17
attempt to route along the tree. 18
• Low battery level: The frame was not relayed because the relaying device was 19
running low on battery power. 20
21
• No routing capacity: The failure occurred because the relaying device has no 22
routing capacity. 23
• No indirect capacity: The failure occurred as the result of an attempt to buffer 24
a frame for a sleeping end device child and the relaying device had no buffer 25
capacity to use. 26
27
• Indirect transaction expiry: A frame that was buffered on behalf of a sleeping 28
end device child has been dropped as a result of a time-out. 29
• Target device unavailable: An end device child of the relaying device is for 30
some reason unavailable. 31
32
• Target address unallocated: The frame was addressed to a non-existent end 33
device child of the relaying device. 34
• Parent link failure: The failure occurred as a result of a failure in the RF link 35
to the device’s parent. This status is only used locally on a device to indicate 36
loss of communication with the parent. 37
38
• Validate route: The multicast route identified in the destination address field 39
should be validated as described in sub-clause 3.6.3.6. 40
• Source route failure: Source routing has failed, probably indicating a link 41
failure in one of the source route’s links. 42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
326 Network Specification
• The destination MAC address and PAN identifier shall be set to the network
address and PAN identifier, respectively, of the neighbor device to which the 1
frame is being sent or else to the MAC broadcast address 0xffff in the case 2
where the NWK header also contains a broadcast address. 3
4
• The source MAC address and PAN identifier shall be set to the network 5
address and PAN identifier of the device sending the leave command. 6
• The frame control field shall be set to specify that the frame is a MAC data 7
frame with MAC security disabled, since any secured frame originating from 8
the NWK layer shall use NWK layer security. Acknowledgment shall be 9
requested. 10
11
• The addressing mode and intra-PAN flags shall be set to support the addressing 12
fields described here. 13
14
3.4.4.2 NWK Header Fields 15
The NWK header fields of the leave command frame shall be set as follows: 16
17
• The source IEEE address sub-field of the frame control field shall be set to 1 18
and the source IEEE address field of the NWK header shall be present and shall 19
contain the 64-bit IEEE address of the originator of the frame. 20
• If the request sub-field of the command options field is set to 1 then the 21
destination address field in the NWK header shall be set to the network address 22
of the child device being requested to leave. 23
24
• If the request sub-field is set to 0 then the destination address field in the NWK 25
header shall be set to 0xfffd so that the indication is received by devices with 26
macRxOnWhenIdle equal to TRUE. 27
• If and only if the command frame is not broadcast, the destination IEEE 28
address sub-field of the frame control field shall be set to 1, and the destination 29
IEEE address field shall be set to the IEEE address of the device being 30
requested to leave. 31
32
• The radius field shall be set to 1. 33
34
3.4.4.3 NWK Payload Fields 35
The NWK payload of the leave command frame contains a command frame 36
identifier field and a command options field. The command frame identifier field 37
shall be set to specify the leave command frame as described in Table 3.40. 38
39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
328 Network Specification
• The destination MAC address and PAN identifier shall be set to the network
address and PAN identifier, respectively, of the neighbor device to which the 1
frame is being sent. 2
3
• The source MAC address and PAN identifier shall be set to the network 4
address and PAN identifier of the device sending the route record command. 5
• The frame control field shall be set to specify that the frame is a MAC data 6
frame with MAC security disabled, since any secured frame originating from 7
the NWK layer shall use NWK layer security. Acknowledgment shall be 8
requested. 9
10
• The addressing mode and intra-PAN flags shall be set to support the addressing 11
fields described here. 12
13
3.4.5.2 NWK Header Fields 14
The NWK header fields of the route record command frame shall be set as 15
follows: 16
17
• If the route record is being initiated as the result of a NLDE-DATA.request 18
primitive from the next higher layer, the source address field shall be set to the 19
16-bit network address of the originator of the frame. If the route record is 20
being initiated as a result of the relaying of a data frame on behalf of one of the 21
device’s end device children, the source address field shall contain the 16-bit 22
network address of that end device child. 23
• The source IEEE address sub-field of the frame control field shall be set to 1 24
and the source IEEE address field of the NWK header shall be present and shall 25
contain the 64-bit IEEE address corresponding to the 16-bit network address 26
contained in the source address field. 27
28
• The destination address field in the NWK header shall be set to the 16-bit 29
network address of the concentrator device that is the destination of the frame. 30
• The destination IEEE address sub-field of the frame control field shall be set to 31
1, and the destination IEEE address field shall be set to the IEEE address of the 32
concentrator device that is the destination of the frame, if this address is known. 33
34
• The Source Route sub-field of the frame control field shall be set to 0. 35
36
3.4.5.3 NWK Payload 37
The NWK frame payload contains a command identifier field, a relay count field, 38
and a relay list field. The command frame identifier shall contain the value 39
indicating a route record command frame. 40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
330 Network Specification
• The source IEEE address sub-field of the frame control field shall be set to 1
and the source IEEE address field of the NWK header shall be present and shall 1
contain the 64-bit IEEE address of the originator of the frame.19 2
3
• The destination address in the NWK header shall be set to the router-only 4
broadcast address (see Table 3.54). 5
• The destination IEEE address sub-field of the frame control field shall have a 6
value of 0 and the destination IEEE address field of the NWK header shall not 7
be present. 8
9
• The radius field shall be set to 1. 10
11
3.4.8.3 NWK Payload Fields 12
The NWK command payload of the link status command shall be formatted as 13
illustrated in Figure 3.21. 14
15
Octets: 1 Variable 16
17
Command Link status
options list
18
19
NWK command payload 20
21
Figure 3.21 Link Status Command Format 22
23
3.4.8.3.1 Command Options Field 24
The format of the 8-bit command options field is shown in Figure 3.22. 25
26
Bit: 0 – 4 5 6 7 27
28
Entry count First frame Last frame Reserved
29
Figure 3.22 Link Status Command Options Field 30
31
The entry count sub-field of the command options field indicates the number of 32
link status entries present in the link status list. The first frame sub-field is set to 1 33
if this is the first frame of the sender's link status. The last frame sub-field is set to 34
1 if this is the last frame of the sender's link status. If the sender's link status fits 35
into a single frame, the first frame and last frame bits shall both be set to 1. 36
37
38
39
40
41
42
43
19. CCB 1321 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 335
• The destination PAN identifier shall be set to the PAN identifier of the device
sending the network report command. 1
2
• The destination address shall be set to the value of the next-hop address field in 3
the routing table entry for which the destination address field has the same 4
value as the nwkManagerAddr field in the NIB. If no such routing table entry 5
exists, then the NWK may attempt route discovery as described in sub- 6
clause 3.6.3.5. 7
• The source MAC address and PAN identifier shall be set to the network 8
address and PAN identifier of the device sending the network report command, 9
which may or may not be the device from which the command originated. 10
11
• The frame control field shall be set to specify that the frame is a MAC data 12
frame with MAC security disabled, since any secured frame originating from 13
the NWK layer shall use NWK layer security. The transmission options shall 14
be set to require acknowledgment. 15
16
3.4.9.2 NWK Header Fields 17
The NWK header fields of the network report command frame shall be set as 18
follows: 19
20
• The source IEEE address sub-field of the frame control field shall be set to 21
1and the source IEEE address field of the NWK header shall be present and 22
shall contain the 64-bit IEEE address of the originator of the frame.20 23
• The destination address field in the NWK header shall be set to the 16-bit 24
network address contained in the nwkManagerAddr attribute of the NIB. 25
26
• The destination IEEE address sub-field of the frame control field shall have a 27
value of 1 and the destination IEEE address field of the NWK header shall be 28
present and shall contain the 64-bit IEEE address of the corresponding to the 29
16-bit network address contained in the nwkManagerAddr attribute of the NIB, 30
if this IEEE address is known. 31
32
3.4.9.3 NWK Payload Fields 33
The NWK frame payload contains a command identifier field, a command options 34
field, an EPID field, and a report information payload. 35
36
The command frame identifier shall contain the value indicating a network report 37
command frame. 38
39
40
41
42
43
20. CCB 1321 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 337
command, which may or may not be the device from which the command
originated. 1
2
• The frame control field shall be set to specify that the frame is a MAC data 3
frame with MAC security disabled, since any secured frame originating from 4
the NWK layer shall use NWK layer security. 5
6
3.4.10.2 NWK Header Fields 7
The NWK header fields of the network update command frame shall be set as 8
follows: 9
10
• The source IEEE address sub-field of the frame control field shall be set to 11
1and the source IEEE address field of the NWK header shall be present and 12
shall contain the 64-bit IEEE address of the originator of the frame.21 13
• The destination address in the NWK header shall be set to the broadcast 14
address 0xffff. 15
16
• The destination IEEE address sub-field of the frame control field shall have a 17
value of 0 and the destination IEEE address field shall not be present in the 18
NWK header. 19
20
3.4.10.3 NWK Payload Fields 21
The NWK frame payload contains a command identifier field, a command options 22
field, an EPID field and an Update Information variable field. 23
24
The command frame identifier shall contain the value indicating a network update 25
command frame. 26
3.4.10.3.1 Command Options Field 27
28
The format of the 8-bit command options field is shown in Figure 3.29. 29
30
31
Bits 0 - 4 5-7 32
33
Update Update 34
Information Command
Count identifier
35
36
(see Figure 3.30) 37
Figure 3.29 Network Update Command Options Field 38
39
40
41
42
43
21. CCB 1321 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
340 Network Specification
The PAN identifier update shall be made up of a single 16-bit PAN identifier that
is the new PAN identifier for this network to use. The Update Information count 1
sub field shall be set equal to 1 as there is only a single PAN identifier contained 2
within the Update Information field. 3
4
5
3.5 Constants and NIB Attributes 6
7
8
3.5.1 NWK Constants 9
10
The constants that define the characteristics of the NWK layer are presented in 11
Table 3.43. 12
Table 3.43 NWK Layer Constants 13
14
Constant Description Value 15
nwkcCoordinatorCapable A Boolean flag indicating whether the device Configuration
16
is capable of becoming the ZigBee dependent 17
coordinator. A value of 0x00 indicates that 18
the device is not capable of becoming a 19
coordinator while a value of 0x01 indicates 20
that the device is capable of becoming a
coordinator. 21
22
nwkcDefaultSecurityLevel The default security level to be used (see Defined in stack 23
Chapter 4). profile
24
nwkcMinHeaderOverhead The minimum number of octets added by the 0x08 25
NWK layer to an NSDU. 26
nwkcProtocolVersion The version of the ZigBee NWK protocol in 0x02 27
the device. 28
nwkcWaitBeforeValidation The number of OctetDurations, on the 0x9c40 (0x500 29
originator of a multicast route request, msec on 2.4 30
between receiving a route reply and sending a GHz)a 31
message to validate the route.
32
nwkcRouteDiscoveryTime The number of OctetDurations until a route 0xc4b4 (0x2710 33
discovery expires. msec on
34
2.4GHz)b
35
nwkcMaxBroadcastJitter The maximum broadcast jitter time measured 0x7d0 (0x40 36
in OctetDurations. msec on
37
2.4GHz)c
38
nwkcInitialRREQRetries The number of times the first broadcast 0x03 39
transmission of a route request command
40
frame is retried.
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
342 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 0x000000 – The maximum time Defined in 10
0xffffff duration in OctetDurations stack profilea 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
344 Network Specification
1
Table 3.45 Route Record Table Entry Format
2
Field Valid 3
Field Name Type Range Reference 4
5
Network Address Integer 0x0000- The destination
0xfff7 network address for 6
this route record. 7
Relay Count Integer 0x0000 - The count of relay 8
0xffff nodes from 9
concentrator to the 10
destination. 11
Path Set of The set of network 12
Network addresses that 13
Addresses represent the route in 14
order from the
15
concentrator to the
destination. 16
17
18
19
Table 3.46 Network Address Map 20
64-bit IEEE Address 16-bit Network address 21
22
A valid 64-bit IEEE Address or Null 0x0000 - 0xfff7 23
if not known 24
25
3.5.2.1 Broadcast Delivery Time 26
27
The total delivery time for a broadcast transmission, i.e. the time required for a 28
broadcast to be delivered to every device in the network, shall be calculated 29
according to the following formula: 30
nwkBroadcastDeliveryTime = 2*nwkMaxDepth* 31
((0.05+(nwkcMaxBroadcastJitter/2))+
32
33
nwkPassiveAckTimeout*nwkBroadcastRetries/
34
1000) 35
36
37
3.6 Functional Description 38
39
40
3.6.1 Network and Device Maintenance 41
42
All ZigBee devices shall provide the following functionality: 43
• Join a network 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 351
• Leave a network
1
• Rejoin a network 2
Both ZigBee coordinators and routers shall provide the following additional 3
functionality: 4
5
• Permit devices to join the network using the following: 6
• Association indications from the MAC 7
8
• Explicit join requests from the application 9
• Rejoin requests 10
11
• Permit devices to leave the network using the following: 12
• Network leave command frames 13
14
• Explicit leave requests from the application 15
• Participate in assignment of logical network addresses 16
17
• Maintain a list of neighboring devices 18
ZigBee coordinators shall provide functionality to establish a new network. 19
ZigBee routers and end devices shall provide the support of portability within a 20
network. 21
22
3.6.1.1 Establishing a New Network 23
24
The procedure to establish a new network is initiated through use of the NLME- 25
NETWORK-FORMATION.request primitive. Only devices for which the 26
nwkcCoordinatorCapable constant has a value of 0x01, and which are not 27
currently joined to a network shall attempt to establish a new network. If this 28
procedure is initiated on any other device, the NLME shall terminate the 29
procedure and notify the next higher layer of the illegal request. This is achieved 30
by issuing the NLME-NETWORK-FORMATION.confirm primitive with the 31
Status parameter set to INVALID_REQUEST. 32
When this procedure is initiated, the NLME shall first request that the MAC sub- 33
layer perform an energy detection scan over either a specified set of channels or, 34
by default, the complete set of available channels, as dictated by the PHY layer 35
(see [B1]), to search for possible interferers. A channel scan is initiated by issuing 36
the MLME-SCAN.request primitive to the MAC sub-layer with the ScanType 37
parameter set to energy detection scan. The results are communicated back via the 38
MLME-SCAN.confirm primitive. This scan is not necessary if there is only one 39
channel specified. 40
41
On receipt of the results from a successful energy detection scan, the NLME shall 42
order the channels according to increasing energy measurement and discard those 43
channels whose energy levels are beyond an acceptable level. The choice of an 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
352 Network Specification
acceptable energy level is left to the implementation. The NLME shall then
perform an active scan, by issuing the MLME-SCAN.request primitive with the 1
ScanType parameter set to active scan and ChannelList set to the list of acceptable 2
channels, to search for other ZigBee devices. To determine the best channel on 3
which to establish a new network, the NLME shall review the list of returned PAN 4
descriptors and find the first channel with the lowest number of existing networks, 5
favoring a channel with no detected networks. 6
7
If no suitable channel is found, the NLME shall terminate the procedure and 8
notify the next higher layer of the startup failure. This is achieved by issuing the 9
NLME-NETWORK-FORMATION.confirm primitive with the Status parameter 10
set to STARTUP_FAILURE. 11
If a suitable channel is found, the NLME shall select a PAN identifier for the new 12
network. To do this the device shall choose a random PAN identifier less than 13
0xffff that is not already in use on the selected channel. Once the NLME makes its 14
choice, it shall set the macPANID attribute in the MAC sub-layer to this value by 15
issuing the MLME-SET.request primitive. 16
17
If no unique PAN identifier can be chosen, the NLME shall terminate the 18
procedure and notify the next higher layer of the startup failure by issuing the 19
NLME-NETWORK-FORMATION.confirm primitive with the Status parameter 20
set to STARTUP_FAILURE. 21
Once a PAN identifier is selected, the NLME shall select a 16-bit network address 22
equal to 0x0000 and set the nwkNetworkAddress attribute of the NIB equal to the 23
selected network address. 24
25
Once a network address is selected, the NLME shall check the value of the 26
nwkExtendedPANId attribute of the NIB. If this value is 0x0000000000000000 27
this attribute is initialized with the value of the MAC constant aExtendedAddress. 28
Once the value of the nwkExtendedPANId is checked, the NLME shall begin 29
operation of the new PAN by issuing the MLME-START.request primitive to the 30
MAC sub-layer. The parameters of the MLME-START.request primitive shall be 31
set according to those passed in the NLME-NETWORK-FORMATION.request, 32
the results of the channel scan, and the chosen PAN identifier. The status of the 33
PAN startup is communicated back via the MLME-START.confirm primitive. 34
35
On receipt of the status of the PAN startup, the NLME shall inform the next higher 36
layer of the status of its request to initialize the ZigBee coordinator. This is 37
achieved by issuing the NLME-NETWORK-FORMATION.confirm primitive 38
with the Status parameter set to the primitive returned in the MLME- 39
START.confirm from the MAC sub-layer. 40
The procedure to successfully start a new network is illustrated in the message 41
sequence chart (MSC) shown in Figure 3.32. 42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 353
NLME-NETWORK-FORMATION.request 1
MLME-SCAN.request
2
Perform energy
detection scan
3
MLME-SCAN.confirm
4
MLME-SCAN.request 5
Perform active scan
6
MLME-SCAN.confirm 7
Select Channel, PAN ID, 8
Beacon Payload and Short
Address
MLME-SET.request
9
10
MLME-SET.confirm 11
MLME-START.request 12
13
MLME-START.confirm 14
NLME- NETWORK-FORMATION.confirm 15
16
APL NWK MAC 17
18
Figure 3.32 Establishing a New Network
19
20
3.6.1.2 Permitting Devices to Join a Network 21
The procedure for permitting devices to join a network is initiated through the 22
NLME-PERMIT-JOINING.request primitive. Only devices that are either the 23
ZigBee coordinator or a ZigBee router shall attempt to permit devices to join the 24
network. 25
26
When this procedure is initiated with the PermitDuration parameter set to 0x00, 27
the NLME shall set the macAssociationPermit PIB attribute in the MAC sub-layer 28
to FALSE. A MAC sub-layer attribute setting is initiated by issuing the MLME- 29
SET.request primitive. 30
When this procedure is initiated with the PermitDuration parameter set to a value 31
between 0x01 and 0xfe, the NLME shall set the macAssociationPermit PIB 32
attribute in the MAC sub-layer to TRUE. The NLME shall then start a timer to 33
expire after the specified duration. On expiration of this timer, the NLME shall set 34
the macAssociationPermit PIB attribute in the MAC sub-layer to FALSE. 35
36
When this procedure is initiated with the PermitDuration parameter set to 0xff, the 37
NLME shall set the macAssociationPermit PIB attribute in the MAC sub-layer to 38
TRUE for an unlimited amount of time, unless another NLME-PERMIT- 39
JOINING.request primitive is issued. 40
The procedure for permitting devices to join a network is illustrated in the MSC 41
shown in Figure 3.33. 42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
354 Network Specification
1
NLME-PERMIT-JOINING.request 2
MLME-SET.request( macAssociationPermit )
3
MLME-SET.confirm 4
NLME-PERMIT-JOINING.confirm
5
6
7
PermitDuration
8
9
MLME-SET.request( macAssociationPermit ) 10
11
MLME-SET.confirm
12
13
14
APL NWK MAC 15
16
Figure 3.33 Permitting Devices to Join a Network 17
18
3.6.1.3 Network Discovery 19
20
The NWK layer enables higher layers to discover what networks, if any, are
21
operational in the POS of a device.
22
The procedure for network discovery shall be initiated by issuing the NLME- 23
NETWORK-DISCOVERY.request primitive with the ScanChannels parameter 24
set to indicate which channels are to be scanned for networks and the 25
ScanDuration parameter set to indicate the length of time to be spent scanning 26
each channel. Upon receipt of this primitive, the NWK layer shall issue an 27
MLME-SCAN.request primitive asking the MAC sub-layer to perform an active 28
scan. 29
30
Every beacon frame received during the scan having a non-zero length payload
31
shall cause the MLME-BEACON-NOTIFY.indication primitive to be issued from
32
the MAC sub-layer of the scanning device to its NLME. This primitive includes
33
information such as the addressing information of the beaconing device, whether
34
or not it is permitting association and the beacon payload. (See [B1] for the
35
complete list of parameters). The NLME of the scanning device shall check the
36
protocol ID field in the beacon payload and verify that it matches the ZigBee
37
protocol identifier. If not, the beacon is ignored. Otherwise, the device shall copy
38
the relevant information from each received beacon (see Figure 3.49 for the
39
structure of the beacon payload) into its neighbor table (see Table 3.48 for the
40
contents of a neighbor table entry).
41
Once the MAC sub-layer signals the completion of the scan by issuing the 42
MLME-SCAN.confirm primitive to the NLME, the NWK layer shall issue the 43
NLME-NETWORK-DISCOVERY.confirm primitive containing a description of 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 355
each network that was heard. Every network description contains the ZigBee
version, stack profile, Extended PAN Id, PAN Id, logical channel, and information 1
on whether it is permitting joining (see Table 3.8). 2
3
3.6.1.4 Joining a Network 4
5
For purposes of the ensuing discussion, a parent-child relationship is formed when 6
a device having membership in the network allows a new device to join. On 7
joining, the new device becomes the child, while the first device becomes the 8
parent. 9
3.6.1.4.1 Joining a Network Through Association 10
11
This sub-clause specifies the procedure a device (child) shall follow if it opts to 12
join a network using the underlying association capabilities provided by the 13
MAC, as well as the procedure a ZigBee coordinator or router (parent) shall 14
follow upon receipt of an MLME-ASSOCIATE.request primitive from the MAC. 15
16
3.6.1.4.1.1 Child Procedure 17
18
The procedure for joining a network using the MAC layer association procedure 19
should be preceded by network discovery as described in sub-clause 3.6.1.3. 20
Upon receipt of the NLME-NETWORK-DISCOVERY.confirm primitive, the 21
next higher layer shall either choose a network to join from the discovered 22
networks or redo the network discovery. Once a network is selected, it shall then 23
issue the NLME-JOIN.request with the RejoinNetwork parameter set to 0x00 and 24
the JoinAsRouter parameter set to indicate whether the device wants to join as a 25
routing device. 26
Only those devices that are not already joined to a network shall initiate the join 27
procedure. If any other device initiates this procedure, the NLME shall terminate 28
the procedure and notify the next higher layer of the illegal request by issuing the 29
NLME-JOIN.confirm primitive with the Status parameter set to 30
INVALID_REQUEST. 31
32
For a device that is not already joined to a network, the NLME-JOIN.request 33
primitive shall cause the NWK layer to search its neighbor table for a suitable 34
parent device, i.e. a device for which following conditions are true: 35
• The device belongs to the network identified by the ExtendedPANId 36
parameter. 37
38
• The device is open to join requests and is advertising capacity of the correct 39
device type. 40
• The link quality for frames received from this device is such that a link cost of 41
at most 3 is produced when calculated as described in sub-clause 3.6.3.1. 42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
356 Network Specification
• If the neighbor table entry contains a potential parent field for this device, that
field shall have a value of 1 indicating that the device is a potential parent. 1
2
• The device shall have the most recent update id, where the determination of 3
most recent needs to take into account that the update id will wrap back to zero. 4
In particular the update id given in the beacon payload of the device should be 5
greater than or equal to — again, compensating for wrap — the nwkUpdateId 6
attribute of the NIB. 7
If the neighbor table contains no devices that are suitable parents, the NLME shall 8
respond with an NLME-JOIN.confirm with a Status parameter of 9
NOT_PERMITTED. If the neighbor table has more than one device that could be 10
a suitable parent, the device which is at a minimum depth from the ZigBee 11
coordinator may be chosen. If more than one device has a minimum depth, the 12
NWK layer is free to choose from among them. 13
14
Once a suitable parent is identified, the NLME shall issue an MLME- 15
ASSOCIATE.request primitive to the MAC sub-layer. The LogicalChannel 16
parameter of the MLME-ASSOCIATE.request primitive shall be set to that found 17
in the neighbor table entry corresponding to the coordinator address of the 18
potential parent. The bit-fields of the CapabilityInformation parameter shall have 19
the values shown in Table 3.47 and the capability information shall be stored as 20
the value of the nwkCapabilityInformation NIB attribute (see Table 3.44). If more 21
than one device meets these requirements, then the joining device may select the 22
parent with the smallest network depth. 23
Table 3.47 Capability Information Bit-Fields 24
25
Bit Name Description 26
0 Alternate PAN This field will always have a value of 0 in 27
coordinator implementations of this specification. 28
1 Device type This field will have a value of 1 if the 29
joining device is a ZigBee router. It will 30
have a value of 0 if the device is a ZigBee 31
end device or else a router-capable device 32
that is joining as an end device. 33
2 Power source This field will be set to the value of 34
lowest-order bit of the PowerSource 35
parameter passed to the NLME-JOIN-
request primitive. The values are:
36
37
0x01 = Mains-powered device 38
0x00 = other power source 39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 357
bit to 0 in the corresponding neighbor table entry to indicate a failed join attempt.
Setting the Potential parent bit to 0 ensures that the NWK layer shall not issue 1
another request to associate to the same neighboring device. The Potential parent 2
bit should be set to 1 for every entry in the neighbor table each time an MLME- 3
SCAN.request primitive is issued. 4
5
A join request may also be unsuccessful, if the potential parent is not allowing 6
new routers to associate (for example, the maximum number of routers, 7
nwkMaxRouters may already have associated with the device) and the joining 8
device has set the JoinAsRouter parameter to TRUE. In this case, the NLME- 9
JOIN.confirm primitive will indicate a status of NOT_PERMITTED. In this case, 10
the child device’s application may wish to attempt to join again as an end device 11
instead, by issuing another NLME-JOIN.request with the JoinAsRouter parameter 12
set to FALSE. 13
If the attempt to join was unsuccessful, the NLME shall attempt to find another 14
suitable parent from the neighbor table. If no such device could be found, the 15
NLME shall issue the NLME-JOIN.confirm primitive with the Status parameter 16
set to the value returned in the MLME-ASSOCIATE.confirm primitive. 17
18
If the attempt to join was unsuccessful and there is a second neighboring device 19
that could be a suitable parent, the NWK layer shall initiate the MAC sub-layer 20
association procedure with the second device. The NWK layer shall repeat this 21
procedure until it either joins the PAN successfully or exhausts its options to join 22
the PAN. 23
If the device cannot successfully join the PAN specified by the next higher layer, 24
the NLME shall terminate the procedure by issuing the NLME-JOIN.confirm 25
primitive with the Status parameter set to the value returned in the last received 26
MLME-ASSOCIATE.confirm primitive. In this case, the device shall not receive 27
a valid logical address and shall not be permitted to transmit on the network. 28
29
If the attempt to join was successful, the NWK shall issue the NLME- 30
JOIN.confirm primitive with a status value of SUCCESS. In this case, the 31
MLME-ASSOCIATE.confirm primitive received by the NWK layer shall contain 32
a 16-bit logical address unique to that network which the child can use in future 33
transmissions. The NWK layer shall then set the Relationship field in the 34
corresponding neighbor table entry to indicate that the neighbor is its parent. By 35
this time, the parent shall have added the new device to its neighbor table. 36
Furthermore, the NWK layer will update the values of nwkNetworkAddress, 37
nwkUpdateId and mwkPANId in the NIB. 38
If the device is attempting to join a secure network and it is a router, it will need to 39
wait until its parent has authenticated it before transmitting beacons. The device 40
shall therefore wait for an NLME-START-ROUTER.request primitive to be 41
issued from the next higher layer. Upon receipt of this primitive, the NLME shall 42
issue an MLME-START.request primitive if it is a router. If the NLME-START- 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 359
ROUTER.request primitive is issued on an end device, the NWK layer shall issue
an NLME-START-ROUTER.confirm primitive with the status value set to 1
INVALID_REQUEST. 2
3
Once the device has successfully joined the network, if it is a router and the next 4
higher layer has issued a NLME-START-ROUTER.request, the NWK layer shall 5
issue the MLME-START.request primitive to its MAC sub-layer. The PANId, 6
LogicalChannel, BeaconOrder and SuperframeOrder parameters shall be set equal 7
to the corresponding values held in the neighbor table entry for its parent. The 8
network depth is set to one more than the parent network depth unless the parent 9
network depth has a value of 0x0f, i.e. the maximum value for the 4-bit device 10
depth field in the beacon payload. In this case, the network depth shall also be set 11
to 0x0f. The PANCoordinator and CoordRealignment parameters shall both be set 12
to FALSE. Upon receipt of the MLME-START.confirm primitive, the NWK layer 13
shall issue an NLME-START-ROUTER.confirm primitive with the same status 14
value. 15
16
17
NLME-NETWORK-DISCOVERY.request 18
MLME-SCAN.request 19
Perform active scan 20
MLME-BEACON-NOTIFY.indication
21
22
23
MLME-BEACON-NOTIFY.indication
24
MLME-SCAN.confirm
25
NLME-NETWORK-DISCOVERY.confirm
26
Select suitable EPID
NLME-JOIN.request
27
MLME-ASSOCIATE.request
28
29
MAC Association Procedure
MLME-ASSOCIATE.confirm 30
NLME-JOIN.confirm 31
MLME-SET.request(macBeaconPayload) 32
Association Procedure MLME-SET.confirm 33
NLME-START-ROUTER.request 34
MLME-START.request 35
MLME-START.confirm 36
NLME- START_ROUTER.confirm
37
APL NWK MAC
38
39
Figure 3.34 Procedure for Joining a Network Through Association 40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
360 Network Specification
MLME-ASSOCIATE.indication
1
2
Check Extended Address
and assign short address 3
MLME-ASSOCIATE.response 4
MLME-COMM-STATUS.indication 5
6
Update Beacon Payload
7
MLME-SET.request(macBeaconPayload)
8
MLME-SET.confirm
9
NLME-JOIN.indication
10
11
APL NWK MAC 12
13
Figure 3.35 Procedure for Handling a Join Request 14
15
3.6.1.4.2 Joining or Rejoining a Network Using NWK Rejoin 16
Devices that have lost all connection to the network, for example a ZED that can 17
no longer communicate successfully with its parent, can rejoin the network using 18
the NWK rejoin request and NWK rejoin response commands. The rejoining 19
procedure is identical to the association procedure described in the previous 20
section, except that the MAC association procedure is replaced by an exchange 21
involving the rejoin request and rejoin response commands, and, because NWK 22
commands make use of NWK security, no authentication step is performed. Using 23
these commands instead of the MAC procedure allows a device to rejoin a 24
network that does not currently allow new devices to join. 25
26
Devices that are joining a network for the first time may also use a variant of this 27
procedure as described in the following sub-clauses. 28
29
3.6.1.4.2.1 Child Procedure 30
31
The procedure for joining or rejoining a network using the NWK rejoin procedure
32
shall be initiated by issuing the NLME-JOIN.request primitive, as shown in
33
Figure 3.36, with the RejoinNetwork parameter set to 0x02 and the
34
ExtendedPANId parameter set to the ExtendedPANId of the network to rejoin.
35
The device type field of the CapabilityInformation parameter shall be set to 1 if
36
the device is intended to join as a router and to 0 otherwise. If the value of the
37
nwkNetworkAddress value in the NIB is within the valid range defined for that
38
value, it shall use nwkNetworkAddress when issuing the Rejoin Request
39
command. If the nwkNetworkAddress is NOT within the valid range, it shall
40
randomly generate a short address within the valid range, excluding the value of
41
0x0000, and use that for the Rejoin Request command.22
42
43
22. CCB 1312 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
362 Network Specification
command frame is received, then the rejoin was unsuccessful. If the receiver on
when idle field of the CapabilityInformation parameter is equal to 0, the device 1
shall issue a MLME-POLL.request to the potential parent to retrieve the rejoin 2
response command. If the receiver on when idle field is equal to 1, polling is not 3
required. 4
5
Note: Polling more than once before aResponseWaitTime ([B1]) elapses is 6
permitted. 7
On receipt of a rejoin response command frame, after the above procedure or at 8
any other time, the device shall check the destination IEEE address field and the 9
source IEEE address fields of the command frame NWK header. If the destination 10
IEEE address field is not equal in value to the IEEE address of the receiving 11
device or if the source IEEE address field is not equal in value to the IEEE address 12
of the most recent potential parent to which a rejoin request command frame was 13
sent (or the current parent in the case of an unsolicited rejoin response), then the 14
rejoin response command frame shall be discarded without further processing. 15
16
If the rejoin status field within the rejoin response command frame indicates a 17
refusal to permit rejoining on the part of the neighboring device (that is, PAN at 18
capacity or PAN access denied), then the device attempting to rejoin should set the 19
potential parent bit to 0 in the corresponding neighbor table entry to indicate a 20
failed join attempt. Setting the potential parent bit to 0 ensures that the NWK layer 21
will not issue another request to rejoin to the same neighboring device. If the 22
attempt to join was unsuccessful, the NLME shall attempt to find another suitable 23
parent from the neighbor table. If no such device can be found, the NLME shall 24
issue the NLME-JOIN.confirm primitive with the Status parameter set to 25
NOT_PERMITTED. If the attempt to join is unsuccessful and there is a second 26
neighboring device that could be a suitable parent, the NWK layer shall initiate 27
the NWK rejoin procedure with the second device. The NWK layer shall repeat 28
this procedure until it either rejoins the PAN successfully or exhausts its options to 29
rejoin the PAN. If the device cannot successfully rejoin the PAN specified by the 30
next higher layer, the NLME shall terminate the procedure by issuing the NLME- 31
JOIN.confirm primitive with the Status parameter set to NOT_PERMITTED. In 32
this case, the device shall not receive a valid logical address and shall not be 33
permitted to transmit on the network. If the attempt to rejoin was successful, the 34
NWK rejoin response command received by the NWK layer shall contain a 16-bit 35
logical address unique to that network, which the child can use in future 36
transmissions. Note that this address may be identical to the current 16-bit 37
network address of the device stored in the nwkNetworkAddress attribute of the 38
NIB. The NWK layer shall then set the relationship field in the corresponding 39
neighbor table entry to indicate that the neighbor is its parent. By this time, the 40
parent shall have added the new device to its neighbor table. Furthermore, the 41
NWK layer shall update the values of nwkNetworkAddress, nwkUpdateId, and 42
nwkPANId in the NIB if necessary. 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
364 Network Specification
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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 365
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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
366 Network Specification
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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 367
has no reason to relinquish that address and should retain it unless it receives an
indication that its address is in conflict with that of another device on the network. 1
Furthermore, devices may self-assign random addresses under stochastic 2
addressing and retain them, as in the case of joining a network using the rejoin 3
command frame (see sub-clause 3.6.1.4.2). The ZigBee coordinator, which has no 4
parent, shall always have the address 0x0000. 5
6
3.6.1.8 Installation and Addressing 7
8
It should be clear that nwkMaxDepth roughly determines the number of hops in 9
network terms from the root of the tree to the farthest end device. In principle, 10
nwkMaxDepth also determines the overall network diameter. In particular, for an 11
ideal network layout in which the ZigBee coordinator is located in the center of 12
the network, as illustrated in Figure 3.41, the network diameter should be 2* 13
nwkMaxDepth. In practice, application-driven placement decisions and order of 14
deployment may lead to a smaller diameter. In this case, nwkMaxDepth provides a 15
lower bound on the network diameter while the 2* nwkMaxDepth provides the 16
upper bound. 17
Finally, due to the fact that the tree is not dynamically balanced, when 18
nwkAddrAlloc has a value of 0x00, the possibility exists that certain installation 19
scenarios, such as long lines of devices, may exhaust the address capacity of the 20
network long before the real capacity is reached. 21
22
Under stochastic address assignment, nwkMaxDepth is related to the number of 23
hops across the network. This is not a controlled value in networks using 24
stochastic address assignment. 25
26
3.6.1.9 Address Conflicts 27
An address conflict occurs when two devices in the same network have identical 28
values for nwkNetworkAddress. Preventing all such conflicts, for example by 29
using tree address assignment and prohibiting the reuse of assigned addresses, is 30
not always practical. This section describes how address conflicts that do occur 31
can be detected and corrected. Address conflict detection shall be enabled if the 32
NIB attribute nwkUniqueAddr is FALSE. 33
34
Note that the network addresses used in routing messages are verified during the 35
route discovery process. The device_annc now is also used to verify addresses. 36
The verification applies only to devices, links, and information present at the time 37
of the discovery or device_annc. Verification can be achieved at other times, such 38
as before sending a unicast directly to a neighbor, by sending a network status 39
command with a status code value of 0x0e, indicating address verification. 40
If a device receives a broadcast data frame and discovers an address conflict as a 41
result of the receipt, as discussed below in sub-clause 3.6.1.9.2, it should not 42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 377
retransmit the frame as usual but shall discard it before taking the resolution
actions described below in sub-clause 3.6.1.9.3. 1
2
3.6.1.9.1 Obtaining Address Information 3
The NWK layer obtains address information from incoming messages, including 4
both NWK commands and data messages. Address information from data 5
messages is passed to the NWK layer by being added to the network address map 6
table in the NIB. 7
8
The ability to detect address conflicts is enhanced by adding one or both of the 9
Destination IEEE Address and Source IEEE Address fields to a message’s NWK 10
frame. When nwkUniqueAddr is FALSE, all NWK command messages shall 11
contain the source IEEE address and also the destination IEEE address if it is 12
known by the source device. 13
When nwkUniqueAddr is FALSE, route request commands shall include the 14
sender's IEEE address in the Sender IEEE address field. This ensures that devices 15
are aware of their neighbors' IEEE addresses. 16
17
3.6.1.9.2 Detecting Address Conflicts 18
After joining a network or changing address due to a conflict, a device shall send 19
either a device_annc or initiate a route discovery prior to sending messages. 20
21
Upon receipt of a frame containing a 64-bit IEEE address in the NWK header, the 22
contents of the nwkAddressMap attribute of the NIB and neighbor table should be 23
checked for consistency. 24
If the destination address field of the NWK Header of the incoming frame is equal 25
to the nwkNetworkAddress attribute of the NIB then the NWK layer shall check 26
the destination IEEE address field, if present, against the value of 27
aExtendedAddress. If the IEEE addresses are not identical then a local address 28
conflict has been detected on nwkNetworkAddress. 29
30
If a neighbor table or address map entry is located in which the 64-bit address is 31
the null IEEE address (0x00....00), the 64-bit address in the table can be updated. 32
However, if the 64-bit address is not the null IEEE address and does not 33
correspond to the received 16-bit address, the device has detected a conflict 34
elsewhere in the network. 35
When a broadcast frame is received that creates a new BTR, if the Source Address 36
field in the NWK Header is equal to the nwkNetworkAddress attribute of the NIB 37
then a local address conflict has been detected on nwkNetworkAddress. 38
39
Address conflicts are resolved as described in sub-clause 3.6.1.9.3. 40
3.6.1.9.3 Resolving Address Conflicts 41
42
If a ZigBee coordinator or Router determines that there are multiple users of an 43
address that is not its own, it shall inform the network by broadcasting a network 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
378 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 the device has learned of the conflict other than receiving a network status 8
command with a status of 0x0d, then it shall inform the network by broadcasting a 9
network status command with a status code of 0x0d indicating address conflict, 10
and with its previous address in the destination address field. The network status 11
command shall be broadcast to 0xFFFD, i.e. all devices with 12
macRxOnWhenIdle= TRUE. The device shall delay initiation of this broadcast by 13
a random jitter amount bounded by nwkcMaxBroadcastJitter. If during this delay 14
a network status is received with the identical payload, the device shall cancel its 15
own broadcast. Regardless of how it learned of the conflict, it shall implement the 16
procedure on Detecting Address Conflicts detailed in sub-clause 3.6.1.9.2. 17
If the conflict is detected on a ZigBee end device or nwkAddrAlloc is not equal to 18
stochastic address assignment then the device shall perform a rejoin to obtain a 19
new address. Otherwise, the device that requires a new address shall pick a new 20
address randomly, avoiding all addresses that appear in NIB entries. 21
22
If a parent device detects or is informed of a conflict with the address of an end 23
device child, the parent shall pick a new address for the end device child and shall 24
send an unsolicited rejoin response command frame to inform the end device child 25
of the new address. To notify the next higher layer of an address change the end 26
device shall issue an NLME-NWK-STATUS.indication with status 'Network 27
Address Update' and the new network address as the value of the ShortAddr 28
parameter. 29
30
3.6.1.10 Leaving a Network 31
This sub-clause specifies methods for a device to remove itself from the network 32
and for the parent of a device to request its removal. In both cases, the children of 33
the removed device, if any, may also be removed. 34
35
3.6.1.10.1 Method for a Device to Initiate Its Own Removal from the Network 36
This sub-clause describes how a device can initiate its own removal from the 37
network in response to the receipt of an NLME-LEAVE.request primitive from 38
the next higher layer as shown in Figure 3.42. 39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 379
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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
380 Network Specification
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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 381
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 the 20
leaving device23 is no longer on the network. It is an error for the next higher layer 21
to address and 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
23. CCB 1279 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
382 Network Specification
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, the device is an end device and the source 30
of the leave command frame is a device other than the parent of the recipient, the 31
frame shall be immediately and silently discarded; the device shall not leave the 32
network. If the request sub-field has a value of 1, the nwkLeaveRequestAllowed 33
attribute of the NIB (Table 3.44) is FALSE, and the device is not an end device, 34
the frame shall be immediately and silently discarded; the device shall not leave 35
the network.24 36
37
If a ZigBee end device receives a leave command frame as described above and 38
the SrcAddr parameter of the MCPS-DATA.indication that delivered the 39
command frame is the 16-bit network address of the parent of the recipient, it 40
shall set the nwkExtendedPANId attribute of the NIB to 0x0000000000000000 and 41
42
43
24. CCB 1279 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 383
the ZigBee coordinator shall change its current PAN ID to the newly selected one
by reissuing the MLME-START.request with the new PANID. 1
2
Upon transmission of the Network Update command frame the designated 3
network layer function manager shall create a NLME-NWK-STATUS.indication 4
primitive with the NetworkAddr parameter set to 0 and the Status parameter set to 5
PAN Identifier Update. 6
3.6.1.13.3 Upon Receipt of a Network Update Command Frame 7
8
On receipt of a network update command frame of type PAN identifier update, a 9
device shall start a timer with a value equal to 10
nwkNetworkBroadcastDeliveryTime OctetDurations.26 When the timer expires, 11
the device shall change its current PAN Identifier to the value contained within the 12
Update Information field. 13
Upon transmission of the network update command frame the device shall create 14
a NLME-NWK-STATUS.indication primitive with the NetworkAddr parameter 15
set to 0 and the Status parameter set to PAN Identifier Update. 16
17
Upon receipt of the Network Update command from the device identified by the 18
nwkManagerAddr attribute of the NIB, the value contained in the update id field 19
shall be stored in nwkUpdateId attribute in the NIB. The beacon payload shall 20
also be updated. 21
22
3.6.2 Transmission and Reception 23
24
3.6.2.1 Transmission 25
26
Only those devices that are currently associated shall send data frames from the 27
NWK layer. If a device that is not associated receives a request to transmit a 28
frame, it shall discard the frame and notify the higher layer of the error by issuing 29
an NLDE-DATA.confirm primitive with a status of INVALID_REQUEST. 30
31
All frames handled by or generated within the NWK layer shall be constructed 32
according to the general frame format specified in Figure 3.5 and transmitted 33
using the MAC sub-layer data service. 34
In addition to source address and destination address fields, all NWK layer 35
transmissions shall include a radius field and a sequence number field. For data 36
frames originating at a higher layer, the value of the radius field may be supplied 37
using the Radius parameter of the NLDE-DATA.request primitive. If a value is 38
not supplied, then the radius field of the NWK header shall be set to twice the 39
value of the nwkMaxDepth attribute of the NIB (see clause 3.5). The NWK layer 40
on every device shall maintain a sequence number that is initialized with a random 41
42
43
26. ZigBee Document 12-0220-04 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
386 Network Specification
value. The sequence number shall be incremented by 1, each time the NWK layer
constructs a new NWK frame, either as a result of a request from the next higher 1
layer to transmit a new NWK data frame or when it needs to construct a new 2
NWK layer command frame. After being incremented, the value of the sequence 3
number shall be inserted into the sequence number field of the frame's NWK 4
header. 5
6
Once an NPDU is complete, if security is required for the frame, it shall be passed 7
to the security service provider for subsequent processing according to the 8
specified security suite (see sub-clause 4.2.2). Security processing is not required 9
if the SecurityEnable parameter of the NLDE-DATA.request is equal to FALSE. If 10
the NWK security level as specified in nwkSecurityLevel is equal to 0, or if the 11
frame originated at the higher layer and the nwkSecureAllFrames NIB attribute is 12
set to 0x00, then the security sub-field of the frame control field shall always be 13
set to 0. 14
On successful completion of the secure processing, the security suite returns the 15
frame to the NWK layer for transmission. The processed frame will have the 16
correct auxiliary header attached. If security processing of the frame fails and the 17
frame was a data frame, the frame will inform the higher layer of the NLDE- 18
DATA.confirm primitive’s status. If security processing of the frame fails and the 19
frame is a network command frame, it is discarded and no further processing shall 20
take place. 21
22
When the frame is constructed and ready for transmission, it shall be passed to the 23
MAC data service. An NPDU transmission is initiated by issuing the MCPS- 24
DATA.request primitive to the MAC sub-layer. The MCPS-DATA.confirm 25
primitive then returns the results of the transmission. 26
27
3.6.2.2 Reception and Rejection 28
In order to receive data, a device must enable its receiver. The next higher layer 29
may initiate reception using the NLME-SYNC.request primitive. On a beacon- 30
enabled network, receipt of this primitive by the NWK layer shall cause a device 31
to synchronize with its parent’s next beacon and, optionally, to track future 32
beacons. The NWK layer shall accomplish this by issuing an MLME- 33
SYNC.request to the MAC sub-layer. On a non-beacon-enabled network, the 34
NLME-SYNC.request shall cause the NWK layer of a device with 35
macRxOnWhenIdle set to FALSE to poll the device’s parent using the MLME- 36
POLL.request primitive. 37
38
On a non-beacon-enabled network, the NWK layer on a ZigBee coordinator or 39
ZigBee router shall ensure, to the maximum extent feasible, that the receiver is 40
enabled whenever the device is not transmitting. On a beacon-enabled network, 41
the NWK layer should ensure that the receiver is enabled when the device is not 42
transmitting during the active period of its own superframe and of its parent’s 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 387
superframe. The NWK layer may use the macRxOnWhenIdle attribute of the
MAC PIB for this purpose. 1
2
Once the receiver is enabled, the NWK layer will begin to receive frames via the 3
MAC data service. On receipt of each frame, the radius field of the NWK header 4
shall be decremented by 1. If, as a result of being decremented, this value falls to 5
0, the frame shall not, under any circumstances, be retransmitted. It may, however, 6
be passed to the next higher layer or otherwise processed by the NWK layer as 7
outlined elsewhere in this specification. The following data frames shall be passed 8
to the next higher layer using the NLDE-DATA.indication primitive: 9
• Frames with a broadcast address that matches a broadcast group of which the 10
device is a member. 11
12
• Unicast data frames and source-addressed data frames for which the destination 13
address matches the device's network address. 14
• Multicast data frames whose group identifier is listed in the nwkGroupIDTable. 15
16
If the receiving device is a ZigBee coordinator or an operating ZigBee router, that 17
is, a router that has already invoked the NLME-START-ROUTER.request 18
primitive, it shall process data frames as follows: 19
• Broadcast and multicast data frames shall be relayed according to the 20
procedures outlined in sub-clauses 3.6.5 and 3.6.6. 21
22
• Unicast data frames with a destination address that does not match the device's 23
network address shall be relayed according to the procedures outlined in sub- 24
clause 3.6.3.3. (Under all other circumstances, unicast data frames shall be 25
discarded immediately.) 26
• Source-routed data frames with a destination address that does not match the 27
device’s network address shall be relayed according to the procedures outlined 28
in sub-clause 3.6.3.3.2. 29
30
• The procedure for handling route request command frames is outlined in sub- 31
clause 3.6.3.5.2. 32
• The procedure for handling route reply command frames for which the 33
destination address matches the device's network address is outlined in sub- 34
clause 3.6.3.5.3. 35
36
• Route reply command frames for which the destination address does not match 37
the device's network address shall be discarded immediately. Network status 38
command frames shall be handled in the same manner as data frames. 39
The NWK layer shall indicate the receipt of a data frame to the next higher layer 40
using the NLDE-DATA.indication primitive. 41
42
On receipt of a frame, the NLDE shall check the value of the security sub-field of 43
the frame control field. If this value is non-zero, the NLDE shall pass the frame to 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
388 Network Specification
the security service provider (see 4.2.2) for subsequent processing according to
the specified security suite. If the security sub-field is set to 0, the 1
nwkSecurityLevel attribute in the NIB is non-zero, and the incoming frame is a 2
NWK command frame, the NLDE shall discard the frame. If the security sub-field 3
is set to 0, the nwkSecurityLevel attribute in the NIB is non-zero, and the incoming 4
frame is a NWK data frame, the NLDE shall check the nwkSecureAllFrames NIB 5
attribute. If this attribute is set to 0x01, the NLDE shall only accept the frame if it 6
is destined to itself, that is, if it does not need to be forwarded to another device. 7
8
9
3.6.3 Routing 10
11
ZigBee coordinators and routers shall provide the following functionality: 12
• Relay data frames on behalf of higher layers 13
14
• Relay data frames on behalf of other ZigBee routers 15
• Participate in route discovery in order to establish routes for subsequent data 16
frames 17
18
• Participate in route discovery on behalf of end devices 19
• Participate in route repair 20
21
• Employ the ZigBee path cost metric as specified in route discovery 22
ZigBee coordinators or routers may provide the following functionality: 23
24
• Maintain routing tables in order to remember best available routes 25
• Initiate route discovery on behalf of higher layers 26
27
• Initiate route discovery on behalf of other ZigBee routers 28
• Initiate route repair 29
30
• Conduct neighbor routing 31
32
3.6.3.1 Routing Cost 33
The ZigBee routing algorithm uses a path cost metric for route comparison during 34
route discovery and maintenance. In order to compute this metric, a cost, known 35
as the link cost, is associated with each link in the path and link cost values are 36
summed to produce the cost for the path as a whole. 37
38
More formally, if we define a path P of length L as an ordered set of 39
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 40
cost 41
42
L–1 43
C P = C D i D i + 1 44
i=1 45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 389
1
where each of the values C Di Di + 1 is referred to as a link cost. The link 2
cost C l for a link l is a function with values in the interval 07 defined as: 3
4
7, 5
6
C{l}
min 7, round 14 7
p
l 8
9
10
where pl is defined as the probability of packet delivery on the link l. 11
12
Thus, implementers may report a constant value of 7 for link cost or they may 13
report a value that reflects the probability pl of reception — specifically, the 14
reciprocal of that probability — which should, in turn, reflect the number of 15
expected attempts required to get a packet through on that link each time it is 16
used. A device that offers both options may be forced to report a constant link cost 17
by setting the value of the NIB attribute nwkReportConstantCost to TRUE. If the 18
nwkSymLink attribute of the NIB has a value of TRUE, then the 19
nwkReportConstantCost attribute must have a value of FALSE, and the NWK 20
layer must calculate routing cost in the manner described above. 21
The question that remains, however, is how pl is to be estimated or measured. This 22
is primarily an implementation issue, and implementers are free to apply their 23
ingenuity. pl may be estimated over time by actually counting received beacon 24
and data frames and observing the appropriate sequence numbers to detect lost 25
frames. This is generally regarded as the most accurate measure of reception 26
probability. However, the most straightforward method, available to all, is to form 27
estimates based on an average over the per-frame LQI value provided by the IEEE 28
802.15.4-2003 MAC and PHY. Even if some other method is used, the initial cost 29
estimates shall be based on average LQI. A table-driven function may be used to 30
map average LQI values onto C{l} values. It is strongly recommended that 31
implementers check their tables against data derived from tests performed on 32
production hardware, as inaccurate costs will hamper the operating ability of the 33
ZigBee routing algorithm. 34
35
3.6.3.2 Routing Tables 36
37
A ZigBee router or ZigBee coordinator may maintain a routing table. The 38
information that shall be stored in a ZigBee routing table entry is shown in 39
Table 3.51. The aging and retirement of routing table entries in order to reclaim 40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
390 Network Specification
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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 391
• 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
392 Network Specification
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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 393
the current device, the NLDE shall issue the NLDE-DATA.confirm primitive with
a status value of ROUTE_ERROR. If the frame is being relayed on behalf of 1
another device, the NLME shall issue a network status command frame destined 2
for the device that is the source of the frame with a status of 0x04, indicating a 3
lack of routing capacity. It shall also issue the NLME-NWK-STATUS.indication 4
to the next higher layer with the NetworkAddr parameter equal to the 16-bit 5
network address of the frame, and the Status parameter equal to 0x04, indicating a 6
lack of routing capacity. 7
8
For hierarchical routing, if the destination is a descendant of the device, the device 9
shall route the frame to the appropriate child. If the destination is a child, and it is 10
also an end device, delivery of the frame can fail due to the macRxOnWhenIdle 11
state of the child device. If the child has macRxOnWhenIdle set to FALSE, 12
indirect transmission as described in IEEE 802.15.4-2003 [B1] may be used to 13
deliver the frame. If the destination is not a descendant, the device shall route the 14
frame to its parent. 15
Every other device in the network is a descendant of the ZigBee coordinator and 16
no device in the network is the descendant of any ZigBee end device. For a 17
ZigBee router with address A at depth d, if the following logical expression is true, 18
then a destination device with address D is a descendant: 19
20
A D A + Cskip d – 1 21
For a definition of Cskip d , see sub-clause 3.6.1.6. 22
23
If it is determined that the destination is a descendant of the receiving device, the 24
address N of the next hop device is given by: 25
26
N = D
27
for ZigBee end devices, where D A + Rm Cskip d , and otherwise: 28
29
D A 1
30
N A 1 Cskip (d )
31
Cskip(d ) 32
33
If the NWK layer on a ZigBee router or ZigBee coordinator fails to deliver a 34
unicast or multicast frame for any reason, the router or coordinator shall make its 35
best effort to report the failure. No failure should be reported as the result of a 36
failure to deliver a NLME-NWK-STATUS. The failure reporting may take one of 37
two forms. If the failed frame was being relayed as a result of a request from the 38
next higher layer, then the NWK layer shall issue an NLDE-DATA.confirm with 39
the error to the next higher layer. The value of the NetworkAddr parameter of the 40
primitive shall be the intended destination of the frame. If the frame was being 41
relayed on behalf of another device, then the relaying device shall send a network 42
status command frame back to the source of the frame. The destination address 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 395
field of the network status command frame shall be taken from the destination
address field of the failed data frame. 1
2
In either case, the reasons for failure that may be reported appear in Table 3.42. 3
3.6.3.3.1 Originating a Source Routed Data Frame 4
5
If, on receipt of a data frame from the next higher layer, it is determined that the 6
frame should be transmitted using source routing as described above, the source 7
route shall be retrieved from the route record table. 8
If there are no intermediate relay nodes, the frame shall be transmitted directly to 9
the routing destination without source routing by using the MCPS-DATA.request 10
primitive, with the DstAddr parameter value indicating the routing destination. 11
12
If there is at least one relay node, the source route flag of the NWK header frame 13
control field shall be set, and the NWK header source route subframe shall be 14
present. The relay count sub-field of the source route subframe shall have a value 15
equal to the number of relays in the relay list. The relay index sub-field shall have 16
a value equal to 1 less than the number of relays. The relay list sub-field shall 17
contain the list of relay addresses, least significant octet first. The relay closest to 18
the destination shall be listed first. The relay closest to the originator shall be 19
listed last. 20
The device shall relay the frame using the MCPS-DATA.request primitive. The 21
DstAddr parameter shall have the value of the final relay address in the relay list. 22
23
3.6.3.3.2 Relaying a Source Routed Data Frame 24
Upon receipt of a source routed data frame from the MAC sub-layer as described 25
in sub-clause 3.6.3.3, if the relay index sub-field of the source route sub-frame has 26
a value of 0, the device shall check the destination address field of the NWK 27
header of the frame. If the destination address field of the NWK header of the 28
frame is equal in value to the nwkNetworkAddress attribute of the NIB, then the 29
frame shall be passed to the next higher layer using the NLDE-DATA.indication 30
primitive. If the destination address field is not equal to the nwkNetworkAddress 31
attribute of the NIB, and the receiving device is a ZigBee router or ZigBee 32
coordinator, the device shall relay the frame directly to the NWK header 33
destination using the MCPS-DATA.request primitive, otherwise the frame shall be 34
discarded silently. 35
36
If the relay index sub-field has a value other than 0, the device shall compare its 37
network address with the address found at the relay index in the relay list. If the 38
addresses do not match, the frame shall be discarded and no further action shall be 39
taken. Otherwise, as long as the destination address is not the address of an end 40
device where the relaying device is the parent, the device shall decrement the 41
relay index sub-field by 1, and relay the frame to the address immediately prior to 42
its own address in the relay list sub-field. If the destination address of the frame is 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
396 Network Specification
an end device child of the relaying device, the frame shall be unicast using the
MCPS-DATA.request primitive. 1
2
When relaying a source routed data frame, the NWK layer of a device shall also 3
examine the routing table entry corresponding to the source address of the frame. 4
If the no route cache field of the routing table entry has a value of FALSE, then 5
the route record required field of the routing table entry shall be set to FALSE. 6
7
3.6.3.4 Link Status Messages 8
Wireless links may be asymmetric, that is, they may work well in one direction 9
but not the other. This can cause route replies to fail, since they travel backwards 10
along the links discovered by the route request. 11
12
For many-to-one routing and two-way route discovery (nwkSymLink = TRUE), it 13
is a requirement to discover routes that are reliable in both directions. To 14
accomplish this, routers exchange link cost measurements with their neighbors by 15
periodically transmitting link status frames as a one-hop broadcast. The reverse 16
link cost information is then used during route discovery to ensure that discovered 17
routes use high-quality links in both directions. 18
3.6.3.4.1 Initiation of a Link Status Command Frame 19
20
When joined to a network, a ZigBee router or coordinator shall periodically send a 21
link status command every nwkLinkStatusPeriod seconds, as a one-hop broadcast 22
without retries. It may be sent more frequently if desired. Random jitter should be 23
added to avoid synchronization with other nodes. See sub-clause 3.4.8 for the link 24
status command frame format. 25
End devices do not send link status command frames. 26
27
3.6.3.4.2 Upon Receipt of a Link Status Command Frame 28
29
Upon receipt of a link status command frame by a ZigBee router or coordinator,
30
the age field of the neighbor table entry corresponding to the transmitting device
31
is reset to 0. The list of addresses covered by a frame is determined from the first
32
and last addresses in the link status list, and the first frame and last frame bits of
33
the command options field. If the receiver's network address is outside the range
34
covered by the frame, the frame is discarded and processing is terminated. If the
35
receiver's network address falls within the range covered by the frame, then the
36
link status list is searched. If the receiver's address is found, the outgoing cost
37
field of the neighbor table entry corresponding to the sender is set to the incoming
38
cost value of the link status entry. If the receiver's address is not found, the
39
outgoing cost field is set to 0.
40
End devices do not process link status command frames. 41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 397
DATA.request primitive from a higher layer with the DstAddrMode set to 0x02
and the discover route sub-field set to 0x01, for which there is no routing table 1
entry corresponding to the routing address of the destination device (the 16-bit 2
network address indicated by the DstAddr parameter). Or, on receipt of a frame 3
from the MAC sub-layer for which the value of the destination address field in the 4
NWK header is not the address of the current device, the address of an end device 5
child of the current device, or a broadcast address and: 6
7
• The discover route sub-field of the frame control field has a value of 0x01, and 8
• there is no routing table entry corresponding to the routing destination of the 9
frame, and 10
11
• either the value of the source address field of the NWK header of the received 12
frame is the same as the 16-bit network address of one of the end device 13
children of the current device, or 14
• the nwkUseTreeRouting attribute of the NIB has a value of TRUE. 15
16
The route discovery procedure for a multicast address shall be initiated by the 17
NWK layer either in response to the receipt of an NLME-ROUTE- 18
DISCOVERY.request primitive from the next higher layer where the 19
DstAddrMode parameter has a value of 0x01, or as specified in sub- 20
clause 3.6.6.2.2. 21
If the device initiating route discovery has no routing table entry corresponding to 22
the routing address of the destination device, it shall establish a routing table entry 23
with status equal to DISCOVERY_UNDERWAY. If the device has an existing 24
routing table entry corresponding to the routing address of the destination with 25
status equal to ACTIVE or VALIDATION _UNDERWAY, that entry shall be used 26
and the status field of that entry shall retain its current value. If it has an existing 27
routing table entry with a status value other than ACTIVE or 28
VALIDATION_UNDERWAY, that entry shall be used and the status of that entry 29
shall be set to DISCOVERY_UNDERWAY. The device shall also establish the 30
corresponding route discovery table entry if one with the same initiator and route 31
request ID does not already exist. 32
33
Each device issuing a route request command frame shall maintain a counter used 34
to generate route request identifiers. When a new route request command frame is 35
created, the route request counter is incremented and the value is stored in the 36
device’s route discovery table in the Route request identifier field. Other fields in 37
the routing table and route discovery table are set as described in sub- 38
clause 3.6.3.2. 39
The NWK layer may choose to buffer the received frame pending route discovery 40
or, if the frame is a unicast frame and the NIB attribute nwkUseTreeRouting has a 41
value of TRUE, set the discover route sub-field of the frame control field in the 42
NWK header to 0 and forward the data frame along the tree. 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 399
Once the device creates the route discovery table and routing table entries, the
route request command frame shall be created with the payload depicted in 1
Figure 3.12. The individual fields are populated as follows: 2
3
• The command frame identifier field shall be set to indicate the command frame 4
is a route request, see Table 3.40. 5
• The Route request identifier field shall be set to the value stored in the route 6
discovery table entry. 7
8
• The multicast flag and destination address fields shall be set in accordance with 9
the destination address for which the route is to be discovered. 10
• The path cost field shall be set to 0. 11
12
Once created, the route request command frame is ready for broadcast and is 13
passed to the MAC sub-layer using the MCPS-DATA.request primitive. 14
When broadcasting a route request command frame at the initiation of route 15
discovery, the NWK layer shall retry the broadcast nwkcInitialRREQRetries times 16
after the initial broadcast, resulting in a maximum of nwkcInitialRREQRetries + 1 17
transmissions. The retries will be separated by a time interval of 18
nwkcRREQRetryInterval OctetDurations.27 19
20
The many-to-one route discovery procedure shall be initiated by the NWK layer 21
of a ZigBee router or coordinator on receipt of an NLME-ROUTE- 22
DISCOVERY.request primitive from the next higher layer where the 23
DstAddrMode parameter has a value of 0x00. A many-to-one route request 24
command frame is not retried; however, a discovery table entry is still created to 25
provide loop detection during the nwkcRouteDiscoveryTime period. If the 26
NoRouteCache parameter of the NLME-ROUTE-DISCOVERY.request primitive 27
is TRUE, the many-to-one sub-field of the command options field of the 28
command frame payload shall be set to 2. Otherwise, the many-to-one sub-field 29
shall be set to 1. Note that in this case, the NWK layer should maintain a route 30
record table. The destination address field of the NWK header shall be set to 31
0xfffc, the all-router broadcast address. The broadcast radius shall be set to the 32
value in nwkConcentratorRadius. A source device that initiates a many-to-one 33
route discovery is designated as a concentrator and referred to as such in this 34
document and the NIB attribute nwkIsConcentrator should be set to TRUE. If a 35
device has nwkIsConcentrator equal to TRUE and there is a non-zero value in 36
nwkConcentratorDiscoveryTime, the network layer should issue a route request 37
command frame each nwkConcentratorDiscoveryTime. 38
3.6.3.5.2 Upon Receipt of a Route Request Command Frame 39
40
Upon receipt of a route request command frame, if the device is an end device, it 41
shall drop the frame. Otherwise, it shall determine if it has routing capacity. 42
43
27. ZigBee Document 12-0220-04 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
400 Network Specification
If the device does not have routing capacity and the route request is a multicast
route request or a many-to-one-route request, the route request shall be discarded 1
and route request processing shall be terminated. 2
3
If nwkAddrAlloc is 0x00 and the device does not have routing capacity and the 4
route request is a unicast route request, the device shall check if the frame was 5
received along a valid path. A path is valid if the frame was received from one of 6
the device’s children and the source device is a descendant of that child device, or 7
if the frame was received from the device’s parent device and the source device is 8
not a descendant of the device. If the route request command frame was not 9
received along a valid path, it shall be discarded. Otherwise, the device shall 10
check if it is the intended destination. It shall also check if the destination of the 11
command frame is one of its end device children by comparing the destination 12
address field of the route request command frame payload with the address of 13
each of its end device children, if any. If either the device or one of its end device 14
children is the destination of the route request command frame, it shall reply with 15
a route reply command frame. When replying to a route request with a route reply 16
command frame, the device shall construct a frame with the frame type field set to 17
0x01. The route reply’s source address shall be set to the 16-bit network address 18
of the device creating the route reply and the destination address shall be set to the 19
calculated next hop address, considering the originator of the route request as the 20
destination. The link cost from the next hop device to the current device shall be 21
computed as described in sub-clause 3.6.3.1 and inserted into the path cost field of 22
the route reply command frame. The route reply command frame shall be unicast 23
to the next hop device by issuing an MCPS-DATA.request primitive. 24
If the device is not the destination of the route request command frame, the device 25
shall compute the link cost from the previous device that transmitted the frame, as 26
described in sub-clause 3.6.3.1. This value shall be added to the path cost value 27
stored in the route request command frame. The route request command frame 28
shall then be unicast towards the destination using the MCPS-DATA.request 29
service primitive. The next hop for this unicast transmission is determined in the 30
same manner as if the frame were a data frame addressed to the device identified 31
by the destination address field in the payload. 32
33
If the device does have routing capacity and the received request is a unicast route 34
request, the device shall check if it is the destination of the command frame by 35
comparing the destination address field of the route request command frame 36
payload with its own address. It shall also check if the destination of the command 37
frame is one of its end device children by comparing the destination address field 38
of the route request command frame payload with the address of each of its end 39
device children, if any. If neither the device nor one of its end device children is 40
the destination of the route request command frame, the device shall determine if 41
a route discovery table (see Table 3.53) entry exists with the same route request 42
identifier and source address field. If no such entry exists, one shall be created. 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 401
If the device does have routing capacity and the multicast sub-field of the route
request command options field of the received route request frame indicates a 1
multicast route request, the device shall determine whether an entry already exists 2
in the nwkGroupIDTable for which the group identifier field matches the 3
destination address field of the frame. If a matching entry is found, the device 4
shall determine if a route discovery table (see Table 3.53) entry exists with the 5
same route request identifier and source address field. If no such entry exists, one 6
shall be created. 7
8
For many-to-one route requests, and for regular route requests if the nwkSymLink 9
attribute is TRUE, upon receipt of a route request command frame, the neighbor 10
table is searched for an entry corresponding to the transmitting device. If no such 11
entry is found, or if the outgoing cost field of the entry has a value of 0, the frame 12
is discarded and route request processing is terminated. The maximum of the 13
incoming and outgoing costs for the neighbor is used for the purposes of the path 14
cost calculation, instead of the incoming cost. This includes the value used to 15
increment the path cost field of the route request frame prior to retransmission. 16
When creating the route discovery table entry, the fields are set to the 17
corresponding values in the route request command frame. The only exception is 18
the forward cost field, which is determined by using the previous sender of the 19
command frame to compute the link cost, as described in sub-clause 3.6.3.1, and 20
adding it to the path cost contained the route request command frame. The result 21
of the above calculation is stored in the forward cost field of the newly created 22
route discovery table entry. If the nwkSymLink attribute is set to TRUE, the device 23
shall also create a routing table entry with the destination address field set to the 24
source address of the route request command frame and the next hop field set to 25
the address of the previous device that transmitted the command frame. The status 26
field shall be set to ACTIVE. The device shall then issue a route reply command 27
frame to the source of the route request command frame. In the case that the 28
device already has a route discovery table entry for the source address and route 29
request identifier pair, the device shall determine if the path cost in the route 30
request command frame is less than the forward cost stored in the route discovery 31
table entry. The comparison is made by first computing the link cost from the 32
previous device that sent this frame, as described in sub-clause 3.6.3.1, then 33
adding it to the path cost value in the route request command frame. If this value 34
is greater than the value in the route discovery table entry, the frame shall be 35
dropped and no further processing is required. Otherwise, the forward cost and 36
sender address fields in the route discovery table are updated with the new cost 37
and the previous device address from the route request command frame. 38
39
If the nwkSymLink attribute is set to TRUE and the received route request 40
command frame is a unicast route request, the device shall also create a routing 41
table entry with the destination address field set to the source address of the route 42
request command frame and the next hop field set to the address of the previous 43
device that transmitted the command frame. The status field shall be set to 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
402 Network Specification
ACTIVE. The device shall then respond with a route reply command frame. In
either of these cases, if the device is responding on behalf of one of its end device 1
children, the responder address in the route reply command frame payload shall 2
be set equal to the address of the end device child and not of the responding 3
device. 4
5
When a device with routing capacity is not the destination of the received route 6
request command frame, it shall determine if a route discovery table entry (see 7
Table 3.53) exists with the same route request identifier and source address field. 8
If no such entry exists, one shall be created. The route request timer shall be set to 9
expire in nwkcRouteDiscoveryTime OctetDurations.28 If a routing table entry 10
corresponding to the routing address of the destination exists and its status is not 11
ACTIVE or VALIDATION_UNDERWAY, the status shall be set to 12
DISCOVERY_UNDERWAY. If no such entry exists and the frame is a unicast 13
route request, an entry shall be created and its status set to 14
DISCOVERY_UNDERWAY. If the frame is a many-to-one route request, the 15
device shall also create a routing table entry with the destination address field 16
equal to the source address of the route request command frame by setting the 17
next hop field to the address of the previous device that transmitted the command 18
frame. If the frame is a many-to-one route request (i.e. the many-to-one sub-field 19
of the command options field of the command frame payload has a non-zero 20
value), the many-to-one field in the routing table entry shall be set to TRUE, and 21
the no route cache flag shall be set to TRUE if the many-to-one sub-field of the 22
command options field of the command frame payload has a value of 2 or to 23
FALSE if it has a value of 1. If the routing table entry is new, or if the no route 24
cache flag is set to TRUE, or if the next hop field changed, the route record 25
required field shall be set to TRUE, otherwise it remains unchanged. The status 26
field shall be set to ACTIVE. When the route request timer expires, the device 27
deletes the route request entry from the route discovery table. When this happens, 28
the routing table entry corresponding to the routing address of the destination shall 29
also be deleted, if its status field has a value of DISCOVERY_UNDERWAY and 30
there are no other entries in the route discovery table created as a result of a route 31
discovery for that destination address. 32
If an entry in the route discovery table already exists, the path cost in the route 33
request command frame shall be compared to the forward cost value in the route 34
discovery table entry. The comparison is made by computing the link cost from 35
the previous device, as described in sub-clause 3.6.3.1, and adding it to the path 36
cost value in the route request command frame. If this path cost is greater, the 37
route request command frame is dropped and no further processing is required. 38
Otherwise, the forward cost and sender address fields in the route discovery table 39
are updated with the new cost and the previous device address from the route 40
request command frame. Additionally, the path cost field in the route request 41
42
43
28. ZigBee Document 12-0220-04 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 403
command frame shall be updated with the cost computed for comparison
purposes. If the nwkSymLink attribute is set to TRUE and the received route 1
request command frame is a unicast route request, the device shall also update any 2
routing table entry with the destination address field set to the source address of 3
the route request command frame, and the next hop field set to the address of the 4
previous device that transmitted the command frame. The status field shall be set 5
to ACTIVE. The device shall then broadcast the route request command frame 6
using the MCPS-DATA.request primitive. 7
8
When broadcasting a route request command frame, the NWK layer shall delay 9
retransmission by a random jitter amount calculated using the formula: 10
11
2 x R[nwkcMinRREQJitter, nwkcMaxRREQJitter] 12
13
where R a b is a random function on the interval a b . The units of this jitter 14
amount are milliseconds. Implementers may adjust the jitter amount so that route 15
request command frames arriving with large path cost are delayed more than 16
frames arriving with lower path cost. The NWK layer shall retry the broadcast 17
nwkcRREQRetries times after the original relay resulting in a maximum of 18
nwkcRREQRetries + 1 relays per relay attempt. Implementers may choose to 19
discard route request command frames awaiting retransmission in the case that a 20
frame with the same source and route request identifier arrives with a lower path 21
cost than the one awaiting retransmission. 22
23
The device shall also set the status field of the routing table entry corresponding to 24
the routing address of the destination field in the payload to 25
DISCOVERY_UNDERWAY. If no such entry exists, it shall be created. 26
When replying to a route request with a route reply command frame, a device that 27
has a route discovery table entry corresponding to the source address and route 28
request identifier of the route request shall construct a command frame with the 29
frame type field set to 0x01. The source address field of the NWK header shall be 30
set to the 16-bit network address of the current device and the destination address 31
field shall be set to the value of the sender address field from the corresponding 32
route discovery table entry. The device constructing the route reply shall populate 33
the payload fields in the following manner. 34
35
• The NWK command identifier shall be set to route reply. 36
• The route request identifier field shall be set to the same value found in the 37
route request identifier field of the route request command frame. 38
39
• The originator address field shall be set to the source address in the NWK 40
header of the route request command frame. 41
• Using the sender address field from the route discovery table entry 42
corresponding to the source address in the NWK header of the route request 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
404 Network Specification
command frame, the device shall compute the link cost as described in sub-
clause 3.6.3.1. This link cost shall be entered in the path cost field. 1
2
The route reply command frame is then unicast to the destination by using the 3
MCPS-DATA.request primitive and the sender address obtained from the route 4
discovery table as the next hop. 5
3.6.3.5.3 Upon Receipt of a Route Reply Command Frame 6
7
On receipt of a route reply command frame, a device shall perform the following 8
procedure. 9
If the receiving device has no routing capacity and its NIB attribute 10
nwkUseTreeRouting has a value of TRUE, it shall send the route reply as though it 11
were a data frame being forwarded using tree routing. If the receiving device has 12
no routing capacity and its NIB attribute nwkUseTreeRouting has a value of 13
FALSE, it shall discard the command frame. Before forwarding the route reply 14
command frame the device shall update the path cost field in the payload by 15
computing the link cost from the next hop device to itself as described in sub- 16
clause 3.6.3.1 and adding this to the value in the route reply path cost field. 17
18
To support legacy devices, a route reply received with a radius of 1 shall NOT be 19
dropped. It shall continue to be processed as follows.29 20
If the receiving device has routing capacity, it shall check whether it is the 21
destination of the route reply command frame by comparing the contents of the 22
originator address field of the command frame payload with its own address. If it 23
is, it shall search its route discovery table for an entry corresponding to the route 24
request identifier in the route reply command frame payload. If there is no such 25
entry, the route reply command frame shall be discarded and route reply 26
processing shall be terminated. If a route discovery table entry exists, the device 27
shall search its routing table for an entry with a destination address field equal to 28
the routing address corresponding to the responder address in the route reply 29
command frame. If there is no such routing table entry, the route reply command 30
frame shall be discarded and, if a route discovery table entry corresponding to the 31
route request identifier in the route reply command frame exists, it shall also be 32
removed and route reply processing shall be terminated. If a routing table entry 33
and a route discovery table entry exist and if the status field of the routing table 34
entry is set to DISCOVERY_UNDERWAY, it shall be changed to 35
VALIDATION_UNDERWAY if the routing table entry’s GroupId flag is TRUE or 36
to ACTIVE otherwise; the next hop field in the routing table shall be set to the 37
previous device that forwarded the route reply command frame. The residual cost 38
field in the route discovery table entry shall be set to the path cost field in the route 39
reply payload. 40
41
42
43
29. CCB 1400/1414 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 405
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. (Note that broadcast transmission for link status and route 36
37
38
39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 3
412 Network Specification
the destination group, it is instantly transformed into a Member Mode type relay
for the duration of the life of the packet regardless of who relays it next. 1
2
Multicast messages may be originated by end devices but are not sent to devices 3
where macRxOnWhenIdle is equal to FALSE. 4
5
3.6.6.1 The Group ID Table 6
The NWK layer of a device may maintain a group ID table, nwkGroupIDTable, 7
accessible as an attribute of the NIB as shown in Table 3.44. If the 8
nwkGroupIDTable NIB attribute is present then it shall contain a set of 16-bit 9
group identifiers for groups of which the device is a member. 10
11
Note that the optional nwkGroupIDTable NIB attribute has a functional overlap 12
with the mandatory APS group table (see Table 2.18). If a device maintains both 13
tables, and thereby expects to use NWK-layer multicast as a method for receiving 14
group-addressed frames, it must assure that each 16-bit group identifiers that 15
appears in the APS group table also appears in the NWK group table. 16
Note also that from an implementation perspective, it would be wasteful to 17
duplicate the list of group identifiers across layers and it is assumed that 18
implementers will find a way to combine the APS and NWK group tables to avoid 19
waste. 20
21
3.6.6.2 Upon Receipt of a Multicast Frame from the Next 22
23
Higher Layer 24
If an NLDE-DATA.request is received by the NWK layer from its next higher 25
layer and the multicast control field is 0x01, the NWK layer shall determine 26
whether an entry exists in the nwkGroupIDTable having a group identifier field 27
matching the destination address of the frame. If a matching entry is found, the 28
NWK layer shall multicast the frame according to the procedure outlined in sub- 29
clause 3.6.6.2.1. If a matching entry is not found, the frame shall be initiated as a 30
non-member mode multicast using the procedure outlined in sub-clause 3.6.6.2.2. 31
32
3.6.6.2.1 Initiating a Member Mode Multicast 33
The NWK layer shall set the multicast mode sub-field of the multicast control 34
field to 0x01 (member mode). If the BTT table is full and contains no expired 35
entries, the message shall not be sent and the NLDE shall issue the NLDE- 36
DATA.confirm primitive with a status value of BT_TABLE_FULL. If the BTT is 37
not full or contains an expired BTR, a new BTR shall be created with the local 38
node as the source and the multicast frame's sequence number. The message shall 39
then be transmitted according to the procedure described in the final paragraph of 40
sub-clause 3.6.6.3. 41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 417
1
Table 3.57 NWK Layer Status Values
2
Name Value Description 3
4
SUCCESS 0x00 A request has been executed successfully.
5
INVALID_PARAMETER 0xc1 An invalid or out-of-range parameter has been 6
passed to a primitive from the next higher layer. 7
INVALID_REQUEST 0xc2 The next higher layer has issued a request that is 8
invalid or cannot be executed given the current 9
state of the NWK layer. 10
NOT_PERMITTED 0xc3 An NLME-JOIN.request has been disallowed. 11
STARTUP_FAILURE 0xc4 An NLME-NETWORK-FORMATION.request 12
has failed to start a network. 13
ALREADY_PRESENT A device with the address supplied to the NLME-
14
0xc5
DIRECT-JOIN.request is already present in the 15
neighbor table of the device on which the NLME- 16
DIRECT-JOIN.request was issued. 17
SYNC_FAILURE 0xc6 Used to indicate that an NLME-SYNC.request has 18
failed at the MAC layer. 19
NEIGHBOR_TABLE_FULL 0xc7 An NLME-JOIN-DIRECTLY.request has failed 20
because there is no more room in the neighbor 21
table. 22
UNKNOWN_DEVICE 0xc8 An NLME-LEAVE.request has failed because the 23
device addressed in the parameter list is not in the 24
neighbor table of the issuing device. 25
UNSUPPORTED_ 0xc9 An NLME-GET.request or NLME-SET.request 26
ATTRIBUTE has been issued with an unknown attribute 27
identifier. 28
NO_NETWORKS 0xca An NLME-JOIN.request has been issued in an 29
environment where no networks are detectable. 30
Reserved 0xcb 31
32
MAX_FRM_COUNTER 0xcc Security processing has been attempted on an
outgoing frame, and has failed because the frame 33
counter has reached its maximum value. 34
NO_KEY 0xcd Security processing has been attempted on an 35
outgoing frame, and has failed because no key was 36
available with which to process it. 37
BAD_CCM_OUTPUT 0xce Security processing has been attempted on an 38
outgoing frame, and has failed because the 39
security engine produced erroneous output. 40
Reserved 0xcf 41
42
ROUTE_DISCOVERY_FAILED 0xd0 An attempt to discover a route has failed due to a
reason other than a lack of routing capacity. 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 423
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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 425
C HAPTER
1
2
4 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 4
428 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
There are two different types of link keys: global and unique. The type of link key 34
in use by the local device shall determine how the device handles various trust 35
center messages (APS commands), including whether to apply APS encryption. 36
A default global trust center link key must be supported by the device if no other 37
link key is specified by the application at the time of joining. This default link key 38
shall have a value of 5A 69 67 42 65 65 41 6C 6C 69 61 6E 63 65 30 39 39
(ZigBeeAlliance09).36 40
41
42
43
36. CCB 1039 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 429
a Obtain the parameter M from Table 4.40 corresponding to the security level
from step 1; 1
2
b The bit string Key shall be the key obtained from step 1; 3
c The nonce N shall be the 13-octet string constructed using the security 4
control field from step a, the frame counter field from step d, and the source 5
address field from step c (see sub-clause 4.5.2.2); 6
7
d If the security level requires encryption, the octet string a shall be the string 8
NwkHeader || AuxiliaryHeader and the octet string m shall be the string 9
Payload. Otherwise, the octet string a shall be the string NwkHeader || 10
AuxiliaryHeader || Payload and the octet string m shall be a string of length 11
zero. 12
4 If the CCM* mode invoked in step 3 outputs ‘invalid’, security processing shall 13
fail and no further security processing shall be done on this frame. 14
15
5 Let c be the output from step 3. If the security level requires encryption, the 16
secured outgoing frame shall be NwkHeader || AuxiliaryHeader || c, otherwise 17
the secured outgoing frame shall be NwkHeader || AuxiliaryHeader || Payload || 18
c. 19
6 If the secured outgoing frame size is greater than aMaxMACFrameSize (see 20
IEEE Std. 802.15.4 802 [B1]), security processing shall fail and no further 21
security processing shall be done on this frame. 22
23
7 The outgoing frame counter from step 1 shall be incremented by one and stored 24
in the OutgoingFrameCounter element of the network security material 25
descriptor referenced by the nwkActiveKeySeqNumber in the NIB; that is, the 26
outgoing frame counter value associated with the key used to protect the frame 27
is updated. 28
8 The security level sub-field of the security control field shall be over-written by 29
the 3-bit all-zero string '000'. 30
31
4.3.1.2 Security Processing of Incoming Frames 32
33
If the NWK layer receives a secured frame (consisting of a header NwkHeader, 34
auxiliary header AuxiliaryHeader, and payload SecuredPayload) as indicated by 35
the security sub-field of the NWK header frame control field, it shall perform 36
security processing as follows: 37
1 Determine the security level from the nwkSecurityLevel attribute of the NIB. 38
Over-write the 3-bit security level sub-field of the security control field of the 39
AuxiliaryHeader with this value. Determine the sequence number 40
SequenceNumber, sender address SenderAddress, and received frame count 41
ReceivedFrameCount from the auxiliary header AuxiliaryHeader (see sub- 42
clause 4.5.1). If ReceivedFrameCounter has as value the 4-octet representation 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 435
of the integer 232-1, security processing shall indicate a failure to the next
higher layer with a status of 'bad frame counter' and no further security 1
processing shall be done on this frame. 2
3
2 Obtain the appropriate security material (consisting of the key and other 4
attributes) by matching SequenceNumber to the sequence number of any key in 5
the nwkSecurityMaterialSet attribute in the NIB. If the neighbor table entry 6
corresponding to SenderAddress has a relationship field with value 0x01 7
(child), that field shall be set to the value 0x05 (unauthenticated child). If the 8
security material cannot be obtained, security processing shall indicate a failure 9
to the next higher layer with a status of 'frame security failed' and no further 10
security processing shall be done on this frame. 11
3 If there is an incoming frame count FrameCount corresponding to 12
SenderAddress from the security material obtained in step 2 and if 13
ReceivedFrameCount is less than FrameCount, security processing shall 14
indicate a failure to the next higher layer with a status of 'bad frame counter' 15
and no further security processing shall be done on this frame. 16
17
4 Execute the CCM* mode decryption and authentication checking operation, as 18
specified in sub-clause A.2, with the following instantiations: 19
a The parameter M shall be obtained from Table 4.40 corresponding to the 20
security level from step 1. 21
22
b The bit string Key shall be the key obtained from step 2. 23
c The nonce N shall be the 13-octet string constructed using the security 24
control, the frame counter, and the source address fields from 25
AuxiliaryHeader (see sub-clause 4.5.2.2). Note that the security level sub- 26
field of the security control field has been overwritten in step 1 and now 27
contains the value determined from the nwkSecurityLevel attribute from the 28
NIB. 29
30
d The octet string SecuredPayload shall be parsed as Payload1 || Payload2, 31
where the rightmost string Payload2 is an M-octet string. If this operation 32
fails, security processing shall indicate a failure to the next higher layer with 33
a status of 'frame security failed' and no further security processing shall be 34
done on this frame. 35
e If the security level requires decryption, the octet string a shall be the string 36
NwkHeader || AuxiliaryHeader and the octet string c shall be the string 37
SecuredPayload. Otherwise, the octet string a shall be the string NwkHeader 38
|| AuxiliaryHeader || Payload1 and the octet string c shall be the string 39
Payload2. 40
41
5 Return the results of the CCM* operation: 42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 4
436 Security Services Specification
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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 4
440 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 as follows: If the TxOptions bit for 19
include extended nonce is set (0x10) then the extended nonce sub-field shall be 20
set to 1. Otherwise it shall be set to 0. 21
22
a If the extended nonce sub-field is set to 1, then set the source address field to 23
the 64-bit extended address of the local device.37 24
b The frame counter field shall be set to the outgoing frame counter from 25
step 3. 26
27
c If KeyIdentifier is 01, the key sequence number field shall be present and set 28
to the key sequence number from step 3. Otherwise, the key sequence 29
number field shall not be present. 30
6 Execute the CCM* mode encryption and authentication operation, as specified 31
in sub-clause A.2, with the following exceptions: 32
33
a The parameter M shall be obtained from Table 4.40 corresponding to the 34
security level from step 3. 35
b The bit string Key shall be the key obtained from step 1. 36
37
c The nonce N shall be the 13-octet string constructed using the security 38
control and frame counter fields from step 5 and the 64-bit extended address 39
of the local device (see sub-clause 4.5.2.2). 40
41
42
43
37. CCB 1184 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 443
d If the security level requires encryption, the octet string a shall be the string
ApsHeader || AuxiliaryHeader and the octet string m shall be the string 1
Payload. Otherwise, the octet string a shall be the string ApsHeader || 2
AuxiliaryHeader || Payload and the octet string m shall be a string of length 3
zero. 4
5
7 If the CCM* mode invoked in step 6 outputs “invalid”, security processing 6
shall fail and no further security processing shall be done on this frame. 7
8 Let c be the output from step 6. If the security level requires encryption, the 8
secured outgoing frame shall be ApsHeader || AuxiliaryHeader || c, otherwise the 9
secured outgoing frame shall be ApsHeader || AuxiliaryHeader || Payload || c. 10
11
9 If the secured outgoing frame size will result in the MSDU being greater than 12
aMaxMACFrameSize octets (see IEEE Std. 802.15.4 802 [B1]), security 13
processing shall fail and no further security processing shall be done on this 14
frame. 15
10 The outgoing frame counter from step 3 shall be incremented and stored in the 16
appropriate location(s) of the NIB, AIB, and MAC PIB corresponding to the 17
key that was used to protect the outgoing frame. 18
19
11 Over-write the security level sub-field of the security control field with the 3- 20
bit all-zero string '000'. 21
22
4.4.1.2 Security Processing of Incoming Frames 23
If the APS layer receives a secured frame (consisting of a header ApsHeader, 24
auxiliary header AuxiliaryHeader, and payload SecuredPayload) as indicated by 25
the security sub-field of the APS header frame control field it shall perform 26
security processing as follows: 27
28
1 Determine the sequence number SequenceNumber, key identifier KeyIdentifier, 29
and received frame counter value ReceivedFrameCounter from the auxiliary 30
header AuxiliaryHeader. If ReceivedFrameCounter is the 4-octet 31
representation of the integer 232-1, security processing shall fail and no further 32
security processing shall be done on this frame. 33
2 Determine the source address SourceAddress from the address-map table in the 34
NIB, using the source address in the APS frame as the index. If the source 35
address is incomplete or unavailable, security processing shall fail and no 36
further security processing shall be done on this frame. 37
38
3 Obtain the appropriate security material in the following manner. If the security 39
material cannot be obtained, security processing shall fail and no further 40
security processing shall be done on this frame. 41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 4
444 Security Services Specification
a If KeyIdentifier is ‘00’ (i.e., a data key), the security material associated with
the SourceAddress of the incoming frame shall be obtained from the 1
apsDeviceKeyPairSet attribute in the AIB. 2
3
b If KeyIdentifier is ‘01’ (i.e., a network key), the security material shall be 4
obtained by matching SequenceNumber to the sequence number of any key 5
in the nwkSecurityMaterialSet attribute in the NIB. 6
c If KeyIdentifier is ‘02’ (i.e., a key-transport key), the security material 7
associated with the SourceAddress of the incoming frame shall be obtained 8
from the apsDeviceKeyPairSet attribute in the AIB; the key for this 9
operation shall be derived from the security material as specified in sub- 10
clause 4.5.3 for the key-transport key. 11
12
d If KeyIdentifier is ‘03’ (i.e., a key-load key), the security material associated 13
with the SourceAddress of the incoming frame shall be obtained from the 14
apsDeviceKeyPairSet attribute in the AIB and the key for this operation 15
shall be derived from the security material as specified in sub-clause 4.5.3 16
for the key-load key. 17
4 If the apsLinkKeyType of the associated link key is 0x00 (unique) and there38 is 18
an incoming frame count FrameCount corresponding to SourceAddress from 19
the security material obtained in step 3 and if ReceivedFrameCount is less than 20
FrameCount, security processing shall fail and no further security processing 21
shall be done on this frame. 22
23
5 Determine the security level SecLevel as follows. If the frame type sub-field of 24
the frame control field of ApsHeader indicates an APS data frame, then 25
SecLevel shall be set to the nwkSecurityLevel attribute in the NIB. Overwrite 26
the security level sub-field of the security control field in the AuxiliaryHeader 27
with the value of SecLevel. 28
6 Execute the CCM* mode decryption and authentication checking operation as 29
specified in sub-clause A.3, with the following instantiations: 30
31
a The parameter M shall be obtained from Table 4.40 corresponding to the 32
security level from step 5. 33
b The bit string Key shall be the key obtained from step 3. 34
35
c The nonce N shall be the 13-octet string constructed using the security 36
control and frame counter fields from AuxiliaryHeader, and SourceAddress 37
from step 2 (see sub-clause 4.5.2.2). 38
d Parse the octet string SecuredPayload as Payload1 || Payload2, where the 39
rightmost string Payload2 is an M-octet string. If this operation fails, 40
41
42
43
38. CCB 1313 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 445
security processing shall fail and no further security processing shall be done
on this frame. 1
2
e If the security level requires encryption, the octet string a shall be the string 3
ApsHeader || AuxiliaryHeader and the octet string c shall be the string 4
SecuredPayload. Otherwise, the octet string a shall be the string ApsHeader 5
|| AuxiliaryHeader || Payload1 and the octet string c shall be the string 6
Payload2. 7
7 Return the results of the CCM* operation: 8
9
a If the CCM* mode invoked in step 6 outputs “invalid”, security processing 10
shall fail and no further security processing shall be done on this frame. 11
b Let m be the output of step 6. If the security level requires encryption, set the 12
octet string UnsecuredApsFrame to the string ApsHeader || m. Otherwise, 13
set the octet string UnsecuredApsFrame to the string ApsHeader || Payload. 14
15
8 Set FrameCount to (ReceivedFrameCount + 1) and store both FrameCount and 16
SourceAddress in the appropriate security material as obtained in step 3. If 17
storing this frame count and address information will cause the memory 18
allocation for this type of information to be exceeded, and the nwkAllFresh 19
attribute in the NIB is TRUE, then security processing shall fail and no further 20
security processing shall be done on this frame. Otherwise, security processing 21
shall succeed. 22
9 If the sequence number of the received frame belongs to a newer entry in the 23
nwkSecurityMaterialSet then the nwkActiveKeySeqNumber shall be set to 24
received sequence number. 25
26
4.4.1.3 Security Processing of APS Commands 27
28
A device that is not the trust center that receives an APS command shall determine 29
if the message was sent by the trust center. If the message was not sent by the trust 30
center then it shall discard the message and no further processing shall be done. 31
If the message was sent by the trust center, the device shall then consult the AIB 32
attribute apsLinkKeyType associated with the sending device to determine if the 33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 4
446 Security Services Specification
key is a unique link key or global link key. It shall then consult Table 4.5 to
determine the policy that shall be used. 1
2
Table 4.5 Security Policy for Accepting APS Commands
3
APS Command Unique Link Key (0x00) Global Link Key (0x01) 4
5
SKKE Commands (0x01 APS encryption not required APS encryption not required 6
– 0x04)
7
Transport Key (0x05) APS encryption is required as APS encryption is required as 8
per device policy (see sub- per device policy (see sub- 9
clause 4.4.1.5) clause 4.4.1.5)
10
Update Device (0x06) APS encryption required APS encryption not required 11
Remove Device (0x07) APS encryption required APS encryption required 12
13
Request Key (0x08) APS encryption required APS encryption not required
14
Trust Center Policy may
further restrict, see sub- 15
clause 4.4.1.5 16
17
Trust Center Policy may
further restrict, see 18
section 4.4.1.5 19
20
Switch Key (0x09) APS encryption not required APS encryption not required
21
Entity Authentication APS encryption not required APS encryption not required 22
(0x0A – 0x0D) 23
Tunnel Data (0x0E) APS encryption not required APS encryption not required 24
25
Upon reception of an APS command that does not have APS encryption but APS 26
encryption is required by Table 4.5, the device shall drop the message and no 27
further processing shall take place. If APS encryption is not required for the 28
command but the received message has APS encryption, the receiving device 29
shall accept and process the message. Accepting additional security on messages 30
is required to support legacy devices in the field. 31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 447
encrypted APS commands then the sending device may send APS commands
without APS encryption. 1
2
It is left up to the implementers to determine whether or not the receiving device is 3
capable of receiving an APS command with APS encryption. A device may 4
simply send two copies of the APS command, one with APS encryption and one 5
without, in order to satisfy the requirements of interoperability with existing 6
devices. 7
Conditional encryption of APS commands shall only apply when the 8
apsLinkKeyType with receiving device is set to global link key (0x01). 9
10
4.4.1.5 Acceptance of Commands Based on Security Policy 11
12
There are two commands that may be conditionally accepted based on the local 13
security policies in place on the device. 14
The APS Request key command requires APS encryption based on Table 4.5. 15
However the trust center may apply additional security policies based on the 16
profile in use, or other additional factors. A trust center that disallows requesting a 17
key may do so based on the type being requested, or it may disallow all requests. 18
In this case the trust center is permitted to drop the APS request key command and 19
not respond. 20
21
The APS transport key command may be sent with or without APS encryption. 22
The decision to do so is based on the trust center’s security policies. The trust 23
center may deem it acceptable to send a key without APS encryption based on the 24
type, or simply choose to send all requests unencrypted. 25
Conversely, a device receiving an APS transport key command may choose 26
whether or not APS encryption is required. This is most often done during initial 27
joining. For example, during joining a device that has no preconfigured link key 28
would only accept unencrypted transport key messages, while a device with a 29
preconfigured link key would only accept a transport key APS encrypted with its 30
preconfigured key. 31
32
The application profile implemented by the device may dictate the policies in 33
place for these commands.39 34
35
4.4.2 Key-Establishment Services 36
37
The APSME provides services that allow two devices to mutually establish a link 38
key. Initial trust information (for example, a master key) must be installed in each 39
device prior to running the key establishment protocol (see sub-clause 4.4.3 for 40
mechanisms to provision initial trust information). 41
42
43
39. CCB 1313 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 449
4.4.2.1 APSME-ESTABLISH-KEY.request
1
The APSME-ESTABLISH-KEY request primitive is used for initiating a key- 2
establishment protocol. This primitive can be used when there is a need to 3
securely communicate with another device. 4
5
One device will act as an initiator device, and the other device will act as the
6
responder. The initiator shall start the key-establishment protocol by issuing:
7
• The APSME-ESTABLISH-KEY.request with parameters indicating the 8
address of the responder device. 9
10
• An indication of which key-establishment protocol to use (currently SKKE).
11
4.4.2.1.1 Semantics of the Service Primitive 12
13
This primitive shall provide the following interface 14
APSME-ESTABLISH-KEY.request { 15
ResponderAddress, 16
UseParent, 17
ResponderParentAddress,
18
19
KeyEstablishmentMethod
20
}
21
22
Table 4.7 specifies the parameters for the APSME-ESTABLISH-KEY.request 23
primitive. 24
Table 4.7 APSME-ESTABLISH-KEY.request Parameters 25
26
Valid 27
Parameter Name Type Range Description 28
Responder-Address Device Any valid The extended 64-bit address of the responder 29
Address 64-bit device. 30
address 31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 4
450 Security Services Specification
is, the key-agreement scheme outputs “valid”), then the initiator and responder
shall consider the derived key (that is, KeyData) as their newly shared link key. 1
Both the initiator and responder shall update or add this link key to their AIB, set 2
the corresponding incoming and outgoing frame counts to zero, and issue the 3
APSME-ESTABLISH-KEY.confirm primitive with the Status parameter set to 4
SUCCESS. 5
6
Table 4.11 Mapping of Frame Names to Symmetric-Key Key
Agreement Scheme Messages 7
8
Frame 9
Name Description Reference 10
SKKE-1 Sent by initiator during action step 1 (sub-clause B.7.1) sub-clause 11
4.4.2.6.2 12
13
SKKE-2 Sent by responder during action step 2 (sub-clause B.7.2) sub-clause
4.4.2.6.3 14
15
SKKE-3 Sent by initiator during action step 8 (sub-clause B.7.1) sub-clause 16
4.4.2.6.4
17
SKKE-4 Sent by responder during action step 9 (sub-clause B.7.2) sub-clause 18
4.4.2.6.5 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 4
456 Security Services Specification
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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 459
1
Table 4.15 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.16 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 4
462 Security Services Specification
1
Table 4.17 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 463
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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 4
464 Security Services Specification
Table 4.19 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.20 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.21 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-2012 ZigBee Standards Organization. All rights reserved.
Chapter 4
466 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 467
by the ParentAddress parameter) remove one of its child devices (as specified by
the TargetAddress parameter), or if it wants to remove a router from the network. 1
2
If the device being removed is a router then the ParentAddress field shall be set to 3
the EUI64 of that router and the TargetAddress shall be set to the same value.40 4
4.4.5.1.3 Effect on Receipt 5
6
Upon receipt of the APSME-REMOVE-DEVICE.request primitive the device 7
shall first create a remove-device command frame (see sub-clause 4.4.9.3). The 8
child address field of this command frame shall be set to the ChildAddress 9
parameter. This command frame shall be security-protected as specified in sub- 10
clause 4.4.1.1 and then, if security processing succeeds, sent to the device 11
specified by the ParentAddress parameter by issuing a NLDE-DATA.request 12
primitive. 13
14
4.4.5.2 APSME-REMOVE-DEVICE.indication 15
The APSME shall issue this primitive to inform the ZDO that it received a 16
remove-device command frame. 17
18
4.4.5.2.1 Semantics of the Service Primitive 19
20
This primitive shall provide the following interface:
21
APSME-REMOVE-DEVICE.indication { 22
SrcAddress, 23
ChildAddress 24
} 25
26
27
Table 4.25 specifies the parameters for the APSME-REMOVE- 28
DEVICE.indication primitive. 29
Table 4.25 APSME-REMOVE-DEVICE.indication Parameters 30
31
Parameter
Name Type Valid Range Description 32
33
SrcAddress Device Any valid The extended 64-bit address of the device 34
Address 64-bit address requesting that a child device be removed. 35
ChildAddress Device Any valid The extended 64-bit address of the child 36
Address 64-bit address device that is requested to be removed. 37
38
39
40
41
42
43
40. CCB 1280 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 473
4.4.7.2 APSME-SWITCH-KEY.indication
1
The APSME shall issue this primitive to inform the ZDO that it received a switch- 2
key command frame. 3
4
4.4.7.2.1 Semantics of the Service Primitive
5
This primitive shall provide the following interface: 6
7
APSME-SWITCH-KEY.indication { 8
SrcAddress, 9
KeySeqNumber 10
} 11
12
Table 4.29 specifies the parameters for the APSME-SWITCH-KEY.indication 13
primitive. 14
15
Table 4.29 APSME-SWITCH-KEY.indication Parameters
16
Valid 17
Parameter Name Type Range Description 18
19
SrcAddress Device Any valid The extended 64-bit address of the device
Address 64-bit that sent the switch-key command. 20
address 21
22
KeySeqNumber Octet 0x00- A sequence number assigned to a network
0xFF key by the Trust Center and used to 23
distinguish network keys. 24
25
4.4.7.2.2 When Generated 26
27
The APSME shall generate this primitive when it receives a switch-key command 28
frame that is successfully decrypted and authenticated, as specified in sub- 29
clause 4.4.1.2. 30
31
4.4.7.2.3 Effect on Receipt
32
Upon receipt of the APSME-SWITCH-KEY.indication primitive the ZDO shall 33
be informed that the device referenced by the SrcAddress parameter is requesting 34
that the network key referenced by the KeySeqNumber parameter become the 35
new active network key. 36
37
4.4.7.3 Secured APDU Frame 38
39
The APS layer frame format consists of APS header and APS payload fields (see 40
Figure 2.4.) The APS header consists of frame control and addressing fields. 41
When security is applied to an APDU frame, the security bit in the APS frame 42
control field shall be set to 1 to indicate the presence of the auxiliary frame header. 43
The format for the auxiliary frame header is given in sub-clause 4.5.1. The format 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 4
478 Security Services Specification
of a secured APS layer frame is shown in Figure 4.5. The auxiliary frame header
is situated between the APS header and payload fields. 1
2
Octets: Variable 5 or 6 Variable 3
4
Original APS header Auxiliary Encrypted payload Encrypted message
([B7], clause 7.1) frame integrity code (MIC) 5
header 6
Secure frame payload = output of CCM* 7
Full APS header Secured APS payload 8
9
Figure 4.5 Secured APS Layer Frame Format 10
11
4.4.8 Entity Authentication Services 12
13
The APSME provides services that allow two devices to mutually authenticate 14
each other. The process authenticates the originator of the data by using a random 15
challenge with a response based on a pre-shared secret, in this case, a key. It also 16
allows optional authenticated data transfer. 17
18
4.4.8.1 APSME-AUTHENTICATE.request 19
20
The APSME-AUTHENTICATE.request primitive is used for initiating entity 21
authentication or responding to an entity authentication initiated by another 22
device. This primitive can be used when there is a need to authenticate another 23
device without using frame security. The protocol confirms authenticity based on 24
the two devices sharing a pre-shared key. 25
4.4.8.1.1 Semantics of the Service Primitive 26
27
This primitive shall provide the following interface: 28
APSME-AUTHENTICATE.request { 29
PartnerAddress,
30
31
Action,
32
RandomChallenge
33
} 34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 479
clause 4.4.8.5. The local APSME shall act as the responder of this protocol and
the APSME indicated by the PartnerAddress parameter shall act as the initiator of 1
this protocol. If the Action parameter is set to RESPOND_REJECT, the entity 2
authentication will not take place. 3
4
4.4.8.2 APSME-AUTHENTICATE.confirm 5
6
This primitive shall be issued to the ZDO of the initiator and responder devices 7
upon completion or failure of entity authentication. 8
4.4.8.2.1 Semantics of the Service Primitive 9
10
This primitive shall provide the following interface: 11
12
APSME-AUTHENTICATE.confirm {
13
Address,
14
Status 15
} 16
17
Table 4.32 specifies the parameters of the APSME-AUTHENTICATE.confirm 18
primitive. In addition to these codes, if an NLDE-DATA.confirm primitive with a 19
Status parameter set to a value other than SUCCESS is issued when sending one 20
of the protocol messages, the Status parameter of the APSME- 21
AUTHENTICATE.confirm primitive shall be set to that received from the NWK 22
layer. 23
Table 4.32 APSME-AUTHENTICATE.confirm Parameters 24
25
Parameter 26
Name Type Valid Range Description 27
Address DevAddress Any valid 64-bit The extended, 64-bit IEEE 28
address. address of the device with 29
which the entity authentication 30
took place. 31
Status Enumeration Value given by The final status of the entity 32
Table 4.31 or any status authentication. 33
value returned from the 34
NLDE-DATA.confirm
35
primitive.
36
37
4.4.8.2.2 When Generated 38
The APSME of the initiator or responder shall issue this primitive to its ZDO 39
upon completion of entity authentication. 40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 481
During the authentication scheme, if any error condition listed in Table 4.35 is
detected then the scheme shall be aborted and the local APSME shall issue the 1
APSME-AUTHENTICATE.confirm primitive with the Status parameter set as 2
indicated in Table 4.35. If no error conditions occur (i.e., the authentication 3
scheme outputs “valid”), then the initiator shall consider that secure 4
communications with the responder using the indicated key are possible. The 5
initiator and responder shall issue the APSME-AUTHENTICATE.confirm 6
primitive with the Status parameter set to SUCCESS. 7
8
Table 4.34 Mapping of Frame Names to Mutual Entity Authentication Scheme
Messages 9
10
Frame Name Description Reference 11
12
APS_CMD_EA_INIT_CHLNG Sent by initiator during action step 1 4.4.9.7.1
(sub-clause B.8.1). 13
14
APS_CMD_EA_RSP_CHLNG Sent by responder during action step 2 4.4.9.7.2 15
(sub-clause B.8.2).
16
APS_CMD_EA_INIT_MAC_DATA Sent by initiator during action step 5 4.4.9.7.3 17
(sub-clause B.8.1). 18
APS_CMD_EA_RSP_MAC_DATA Sent by responder during action step 8 4.4.9.7.4 19
(sub-clause B.8.2). 20
21
22
23
Table 4.35 Mapping of Mutual Entity Authentication Error
Conditions to Status Codes 24
25
Status Description Status Code Value 26
27
No errors occur. SUCCESS 0x00
28
An invalid parameter was input to one of the key INVALID_PARAMETER 0x01 29
establishment primitives.
30
No authentication key exists. NO_KEY 0x02 31
No authentication data exists. NO_DATA 0x03 32
33
Challenge is invalid: INVALID_CHALLENGE 0x04 34
Initiator during action step 2 (sub-clause B.8.1). 35
Responder during action step 1 (sub-clause B.8.2). 36
37
38
39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 485
Table 4.40 Security Levels Available to the NWK, and APS Layers (Continued)
1
Security Frame Integrity 2
Security Level Sub- (length M of MIC,
Level Field Security Data in Number of 3
Identifier (Table 4.24) Attributes Encryption Octets) 4
5
0x04 ‘100’ ENC ON NO (M = 0) 6
0x05 ‘101’ ENC-MIC-32 ON YES (M=4) 7
8
0x06 ‘110’ ENC-MIC-64 ON YES (M=8)
9
0x07 ‘111’ ENC-MIC-128 ON YES (M=16) 10
11
4.5.1.1.2 Key Identifier Sub-Field 12
13
The key identifier sub-field consists of two bits that are used to identify the key 14
used to protect the frame. The encoding for the key identifier sub-field shall be as 15
listed in Table 4.41. 16
Table 4.41 Encoding for the Key Identifier Sub-Field 17
18
Key Identifier Sub-Field
Key Identifier (Table 4.24) Description 19
20
0x00 ‘00’ A data key. 21
0x01 ‘01’ A network key. 22
23
0x02 ‘10’ A key-transport key.
24
0x03 ‘11’ A key-load key. 25
26
4.5.1.1.3 Extended Nonce Sub-Field 27
28
The extended nonce sub-field shall be set to 1 if the sender address field of the 29
auxiliary header is present. Otherwise, it shall be set to 0. 30
31
4.5.1.2 Counter Field 32
The counter field is used to provide frame freshness and to prevent processing of 33
duplicate frames. 34
35
4.5.1.3 Source Address Field 36
37
The source address field shall only be present when the extended nonce sub-field 38
of the security control field is 1. When present, the source address field shall 39
indicate the extended 64-bit address of the device responsible for securing the 40
frame. 41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 501
The joiner device may begin the join procedure by issuing an NLME-
NETWORK-DISCOVERY.request primitive. This primitive will invoke an 1
MLME-SCAN.request primitive which may cause the transmission of an 2
unsecured beacon request frame (depending on whether the scan is an active or 3
passive scan). 4
5
The joiner device receives beacons from nearby routers and the NWK layer issues 6
an NLME-NETWORK-DISCOVERY.confirm primitive. The NetworkList 7
parameter of this primitive will indicate all of the nearby PANs. In Figure 4.26, 8
the shown router device has already been placed in a state such that its beacons 9
have the “association permit” sub-field set to “1” (permit association). 10
The joiner device shall decide which PAN to join and shall issue the NLME- 11
JOIN.request primitive to join that PAN. If the joiner already has a network key 12
for this PAN, the SecurityEnable parameter for the NLME-JOIN.request primitive 13
shall be set to TRUE; otherwise it shall be set to FALSE. As shown in Figure 4.26, 14
the NLME-JOIN.request primitive causes an association request or rejoin request 15
command to be sent to the router. 16
17
Upon receipt of an association request MAC command, the router shall issue an 18
MLME-ASSOCIATE.indication primitive. Next, the NWK layer will issue an 19
NLME-JOIN.indication primitive to the router’s ZDO. The router shall now know 20
the joiner device's address and security capabilities. The router will also issue an 21
MLME-ASSOCIATE.response. This primitive will cause an association response 22
command to be sent to the joiner. 23
Alternatively, upon receipt of a rejoin request network command, the NWK layer 24
will issue an NLME-JOIN.indication primitive to the router’s ZDO. The router 25
shall now know the joiner device's address, security capabilities, and whether the 26
network key was used to secure the rejoin request command. The router will also 27
issue a rejoin response command to the joiner. 28
29
Upon receipt of the association response MAC command or the rejoin response 30
network command, the joiner shall issue the NLME-JOIN.confirm primitive. The 31
joiner is now declared “joined, but unauthenticated” to the network. The 32
authentication routine (see sub-clause 4.6.3.2) shall follow. 33
If the joiner is not a router, it is declared “joined and authenticated” immediately 34
following the successful completion of the authentication routine. 35
36
If the joiner is a router, it is declared “joined and authenticated” only after the 37
successful completion of the authentication routine followed by the initiation of 38
routing operations. Routing operations shall be initiated by the joiner’s ZDO 39
issuing the NLME-START.request primitive to cause the MLME-START.request 40
primitive to be sent to the MAC layer of the joiner. 41
If the router refuses the joiner, its association response frame or rejoin response 42
frame shall contain the association status field set to a value other than 0x00, and, 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 507
after this parameter reaches the ZDO of the joiner in the NLME-JOIN.confirm
primitive, the joiner shall not begin the authentication routine. 1
2
4.6.3.2 Authentication 3
4
Once a device joins a secured network and is declared “joined but 5
unauthenticated”, it must be authenticated as specified in this sub-clause. In high 6
security mode, neighboring routers must also be authenticated as described in sub- 7
clause 4.4.8. 8
4.6.3.2.1 Router Operation 9
10
If the router is not the Trust Center, it shall begin the authentication procedure 11
immediately after receipt of the NLME-JOIN.indication primitive by issuing an 12
APSME-UPDATE-DEVICE.request primitive with the DestAddress parameter 13
set to the apsTrustCenterAddress in the AIB and the DeviceAddress parameter set 14
to the address of the newly joined device. The Status parameter of this primitive 15
shall be set by the NLME-JOIN.indication primitive parameters according to 16
Table 4.42. 17
Table 4.42 Mapping of NLME-JOIN.indication Parameters to 18
Update Device Status 19
20
NLME-JOIN.indication Parameters Update Device Status 21
Capability Method 22
Information (RejoinNetwor Request Status Description 23
Bit 6 k parameter) Secured 24
25
0 NWK Rejoin TRUE 0x00 Standard security
(0x02) device secured rejoin 26
27
0 MAC Association FALSE 0x01 Standard security 28
(0x00) device unsecured join
29
0 NWK Rejoin FALSEa 0x03 Standard security 30
(0x02) device unsecured 31
rejoin
32
1 NWK Rejoin TRUEb 0x04 High security device 33
(0x02) secured rejoin 34
1 MAC Association FALSE 0x05 High security device 35
(0x00) unsecured join 36
1 NWK Rejoin FALSEc 0x07 High security device 37
(0x02) unsecured rejoin 38
39
a. CCB 1387
40
b. CCB 1387 41
c. CCB 1387 42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter 4
508 Security Services Specification
If the router is the Trust Center, it shall begin the authentication procedure by
simply operating as a Trust Center. 1
2
If initiated by the joining device, the router shall complete the authentication 3
procedure by responding to an entity authentication initiated by the joining device 4
by using APSME-AUTHENTICATION.request with the PartnerAddress 5
parameter set to the joining device address, the Action parameter set to respond, 6
and the RandomChallenge parameter set to a new random value. 7
The router shall not forward messages to a child device, or respond to ZDO 8
requests or NWK command requests on that child's behalf, while the value of the 9
relationship field entry in the corresponding nwkNeighborTable in the NIB is 10
0x05 (unauthenticated child). 11
12
4.6.3.2.2 Trust Center Operation 13
The Trust Center role in the authentication procedure shall be activated upon 14
receipt of an incoming update-device command or immediately after receipt of the 15
NLME-JOIN.indication primitive (in the case where the router is the Trust 16
Center). The Trust Center behaves differently depending on at least five factors: 17
18
• Whether the Trust Center decides to allow the new device to join the network 19
(for example, the Trust Center is in a mode that allows new devices to join). 20
• Whether the Trust Center is operating in residential or commercial mode (see 21
sub-clause 4.6.2.1 and sub-clause 4.6.2.2, respectively). 22
23
• If in standard security mode, whether the device is joining unsecured or secured 24
and the security capabilities of the joining device as indicated by the Status 25
sub-field of the update-device command. 26
• If in high security mode, whether the device is joining unsecured or secured, 27
the security capabilities of the joining device as indicated by the Status sub- 28
field of the update-device command and whether the Trust Center has a master 29
key corresponding to the newly joined device. 30
31
• The nwkSecureAllFrames attribute of the NIB. 32
• The type of the current network key. 33
34
If, at any time during the authentication procedure, the Trust Center decides not to 35
allow the new device to join the network (for example, a policy decision or a 36
failed key-establishment protocol), it shall take actions to remove the device from 37
the network. If the Trust Center is not the router of the newly joined device, it 38
shall remove the device from the network by issuing the APSME-REMOVE- 39
DEVICE.request primitive with the ParentAddress parameter set to the address of 40
the router originating the update-device command and the ChildAddress 41
parameter set to the address of the joined (but unauthenticated) device. 42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 509
address of the newly joined device, and the KeyType parameter set to 0x00 or
0x04 (that is, Trust Center master or link key). The TransportKeyData sub- 1
parameters shall be set as follows: the Key sub-parameter shall be set to Trust 2
Center master or link key as appropriate, and the ParentAddress sub-parameter 3
shall set to the address of the local device if the Trust Center is the router. 4
Otherwise, the ParentAddress sub-parameter shall set to the address of the router 5
originating the update-device command. The issuance of this primitive will cause 6
the master key to be sent unsecured from the router to the newly joined device— 7
security is assumed to be present here via non-cryptographic means — for 8
example by only sending this key once, at low power, immediately after external 9
input to both router and joiner, etc. 10
11
If a master key was sent, the Trust Center shall initiate the establishment of a link 12
key by issuing the APSME-ESTABLISH-KEY.request primitive with the 13
ResponderAddress parameter set to the address of the newly joined device and the 14
KeyEstablishmentMethod set to 0x00 (that is, SKKE). Additionally, if the 15
nwkSecureAllFrames attribute of the NIB is FALSE or if the Trust Center is the 16
router, the UseParent parameter shall be set to FALSE. Otherwise, the UseParent 17
parameter shall be set to TRUE and the ResponderParentAddress parameter shall 18
be set to the address of the router originating the update-device command. 19
Upon receipt of the corresponding APSME-ESTABLISH-KEY.confirm primitive 20
with Status equal to 0x00 (that is, success), the Trust Center shall send the new 21
device the active network key by issuing the APSME-TRANSPORT-KEY.request 22
primitive with the DestAddress parameter set to the address of the newly joined 23
device, and the KeyType parameter to 0x06 (that is, high security network key 24
transport). The TransportKeyData sub-parameters shall be set as follows: 25
26
• The KeySeqNumber sub-parameter shall be set to the sequence count value for 27
the active network key. 28
• The NetworkKey sub-parameter shall be set to active network key. 29
30
• The UseParent sub-parameter shall be set to FALSE. 31
4.6.3.2.3 Joining Device Operation 32
33
After successfully joining or rejoining a secured network, the joining device shall 34
participate in the authentication procedure described in this sub-clause. Following 35
a successful authentication procedure, the joining device shall set the 36
nwkSecurityLevel and nwkSecureAllFrames attributes in the NIB to the values 37
indicated in the beacon from the router. 38
A joined and authenticated device in a secured network with nwkSecureAllFrames 39
equal to TRUE shall always apply NWK layer security to outgoing (incoming) 40
frames unless the frame is destined for (originated from) a newly joined but 41
unauthenticated child. No such restrictions exist if nwkSecureAllFrames is equal 42
to FALSE. 43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 511
parameter set to a new random value. The joining device is now considered
authenticated and shall enter the normal operating state for commercial mode. 1
2
3
Trust Center Router Joiner
4
5
Joined (unauthenticated)
6
Update-Device Command 7
8
Decision to accept 9
new device
10
1
Secured Transport-Key Command(NWK key)
1
11
Unsecured Transport-Key Command(NWK key) 12
Joined (authenticated)
13
14
Note: 15
1. The trust center sends a dummy all-zero NWK key if the joiner securely joined using a preconfigured network key.
16
17
Figure 4.27 Example Standard Security Mode Authentication Procedure
18
4.6.3.2.4 Neighboring Device Authentication 19
20
If a neighboring device attempts to communicate and the neighboring device is 21
unknown and the device is in high security mode and frame counter checking is in 22
place, the communication will be rejected as the frame counter has not been 23
initialized. The neighboring device shall be authenticated by initiating an entity 24
authentication with the it by using APSME-AUTHENTICATION.request with the 25
PartnerAddress parameter set to the neighboring device address, the Action 26
parameter set to initiate, and the RandomChallenge parameter set to a new 27
random value. The APSME-AUTHENTICATION.request will be sent with 28
random jitter. The neighboring device will then respond with a APSME- 29
AUTHENTICATION.request with the PartnerAddress parameter set to the device 30
address, the Action parameter set to respond, and the RandomChallenge 31
parameter set to a new random value. The neighboring device is now considered 32
authenticated. 33
4.6.3.2.5 Message Sequence Charts 34
35
Figure 4.27 and 4.28 give example message sequence charts for the authentication 36
procedure when the router and the Trust Center are separate devices operating in 37
standard or high security mode, respectively. 38
39
In Figure 4.27 the update-device and transport-key commands communicated
40
between the Trust Center and the router shall be secured at the APS layer based on
41
the active network key. The transport-key command sent from the router to the
42
joiner shall not be secured.
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 515
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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 521
2 The destination address field shall be set to the 64-bit extended address of the
destination device. 1
2
3 The tunnelled auxiliary frame field shall be set to the auxiliary frame of the 3
secured command, with following changes: 4
• The extended nonce sub-field shall be set to 1; 5
6
• The source address field shall be set to the 64-bit extended address of the 7
Trust Center; 8
• The tunnelled command shall be set to the secured payload of the embedded 9
command. 10
11
The tunnelled command shall then be sent to the parent or other neighbor of the 12
destination device. 13
4.6.3.7.2 Parent Operations 14
15
Upon receipt of an APS tunnel command, a router shall extract the embedded 16
command as follows: 17
1 The APS header fields shall be set to the values of the APS header fields of the 18
tunnel command. 19
20
2 The auxiliary frame field shall be set to the value of the tunnelled auxiliary 21
frame field of the tunnel command. 22
3 The APS payload field shall be set to the tunnelled command field of the tunnel 23
command. 24
25
The extracted command shall be sent to the destination indicated by the 26
destination address field by issuing the NLDE-DATA.request primitive with 27
security disabled. 28
4.6.3.7.3 Destination Operation 29
30
Upon receipt of a message secured at the APS layer and with an extended nonce in 31
the APS auxiliary frame, the message shall be processed as usual, except that the 32
message shall not be looked up in, or added to, the APS duplicate rejection table. 33
34
4.6.3.8 Permissions Configuration Table 35
36
The permissions configuration table in Table 4.43 indicates which devices have
37
authorization to carry out certain types of commands, and determines in each case
38
whether or not link key security is required. Values in the table are expected to be
39
populated by the next higher layer, and are checked as indicated below for
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 527
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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 531
A NNEX
1
2
A 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-2012 ZigBee Standards Organization. All rights reserved.
Annex A
536 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 537
A NNEX
1
2
B 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 22n, 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 22n 32
33
Actions: The hash value shall be derived as follows: 34
1 If the message M has length less than 2n bits, pad this message according to the 35
following procedure: 36
37
a Right-concatenate to the message M the binary consisting of the bit ‘1’
38
followed by k ‘0’ bits, where k is the smallest non-negative solution to the 39
equation: 40
41
l+1+k 7n (mod 8n) (1) 42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 543
Key 1
2
3
QEU 4
U V 5
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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 545
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-2012 ZigBee Standards Organization. All rights reserved.
Annex B
546 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) (4) 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 547
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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 549
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-2012 ZigBee Standards Organization. All rights reserved.
Chapter B
550 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 551
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-2012 ZigBee Standards Organization. All rights reserved.
Chapter B
552 Security Building Blocks
A NNEX
1
2
C 3
4
5
6
7
8
9
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-2012 ZigBee Standards Organization. All rights reserved.
Annex C
556 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-2012 ZigBee Standards Organization. All rights reserved.
Annex C
560 Test Vectors For Cryptographic Building
3 This test vector is above the threshold of a 216 bit string so the second padding
method described in clause B.6 is utilized. 1
2
Actions: The hash value shall be derived as follows. 3
1 Pad the message by right-concatenating to M the bit 1 followed by the smallest 4
non-negative number of '0' bits, such that the resulting string has length 10 5
(mod 16) octets: 6
7
00 01 02 03 04 … FB FC FD FE FF || 80 00 00 00 00 00 00 00 00 00 8
9
2 Form the padded message M' by right-concatenating to the resulting string the 10
32-bit string that is equal to the binary representation of the integer l: 11
12
00 01 02 03 04 … FB FC FD FE FF || 80 00 00 00 00 00 00 00 00 00 || 00 01 00 13
00 14
3 Concatenate a 16-bit string of zeros for the padding normally used by the first 15
padding method described in clause B.6. 16
17
00 01 02 03 04 … FB FC FD FE FF || 80 00 00 00 00 00 00 00 00 00 || 00 01 00 18
00 || 00 00 19
20
4 Parse the padded message M' as M1, where each message block Mi is a 16-octet 21
string. 22
5 The hash value Hash1 is computed as follows using 16-byte hash block 23
operations: 24
25
i Hashi Mi 26
27
0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 28
1 7A CB 0D DA B8 D3 EA 7B 97 9E 4C 6D 1A EB AC 8D 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 29
30
... ... ... 31
i-1 4E 55 0D CE 34 31 42 96 41 BA D0 C7 BC 44 34 67 F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF 32
33
i 24 EC 2F E7 5B BF FC B3 47 89 BC 06 10 E7 F1 65 80 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 34
35
36
C.5.5 Test Vector 5 37
38
Input: The input to the cryptographic hash function is as follows:
39
1 The bit string M of length l = 65608 bits to be used. 40
41
2 8201 bytes (sequence of 0, 1, 2, … 255, 0, 1, 2, …)
42
3 This test vector is above the threshold of a 216 bit string so the second padding 43
method described in clause B.6 is utilized. 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 563
9 Calculate MacTag2
1
a MacTag2 = MAC(MacData2, MacKey) 2
3
0x57 0xe1 0xd4 0xf9 0x7b 0x28 0xab 0x72 4
0xb1 0x9b 0xb7 0x76 0xf7 0xb5 0x55 0x1c 5
6
10 Send MacTag2 and Text2 to Responder (SKKE-3). 7
11 Receive MacTag1' and Text1 from Responder (SKKE-4). 8
9
12 Create bit string MacData1 10
a MacData1 = 02 || V || U || QEV || QEU || Text1 11
12
0x02 0x55 0x73 0x65 0x72 0x20 0x56 0x0d 13
0x0a 0x55 0x73 0x65 0x72 0x20 0x55 0x0d 14
0x0a 0xbf 0x14 0xdf 0x94 0x94 0x39 0xd2 15
0xce 0x24 0xc9 0x09 0x53 0xb5 0x72 0xd6 16
0x53 0x9e 0x3f 0x0c 0x19 0x05 0x4b 0x05 17
0x44 0xd5 0xa7 0x17 0x62 0x0a 0xf2 0x7d 18
0x96 19
20
13 Verify MacTag1 and MacTag1' match 21
a MacTag1 = MAC(MacData1, MacKey) 22
23
0xa0 0x31 0x57 0x12 0x38 0x6a 0x25 0xef 24
0x28 0x94 0x30 0x6c 0x6f 0xba 0xa4 0xda 25
26
b Check MacTag1 == MacTag1' 27
28
14 Store new Link Key, KeyData. (SKKE), or 29
30
0x84 0x3d 0x71 0x7f 0x92 0xc3 0xd4 0x31 31
0x0a 0x9f 0x46 0x6b 0x58 0xb9 0xf2 0x1c 32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 575
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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 581
A NNEX
1
2
D 3
4
5
6
7
8
9
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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 583
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 constant is not correct for a ZigBee network in 40
which only short addressing modes can be used. The ZigBee alliance decided that, 41
rather than arguing what the correct value of aMaxFrameOverhead should be, an 42
acceptable packet is defined as one that is less than aMaxPHYFrameSize and is a 43
decodable 802.15.4 and ZigBee packet. 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Annex D
584 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 Timing 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
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 585
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]. 20
21
22
D.6 CSMA Backoff Timing 23
24
The IEEE 802.15.4 2006 specification provides an increase in macMaxBE to 8 25
from 5. This higher value is allowed within ZigBee and it is recommended as the 26
default. The default value of macMinBE should be 5 instead of 3. This provides 27
better joining performance in dense networks where many devices may be 28
responding to a beacon request. 29
Note the time a device listens for beacons is set by IEEE 802.15.4 to 30
aBaseSuperframeDuration*(2n+1) symbols where n is the value of the 31
ScanDuration parameter. For ZigBee implementations the value of n should be set 32
to ensure the duration of the listening window is similar to the length of time the 33
beacon responses are expected. 34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Chapter D
586 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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 587
A NNEX
1
2
E 3
4
5
6
7
8
9
and the message counters are not reset. However, repeated energy scans are not
desirable as the device is off the network during these scans and therefore 1
implementations should limit how often a device with failures conducts energy 2
scans. 3
4
2 If the energy scan does indicate increased energy on the channel in use, a 5
Mgmt_NWK_Update_notify should be sent to the Network Manager to 6
indicate interference is present. This report is sent as an APS Unicast with 7
acknowledgement and once the acknowledgment is received the total transmit 8
and transmit failure counters are reset to zero. 9
3 To avoid a device with communication problems from constantly sending 10
reports to the network manager, the device should not send a 11
Mgmt_NWK_Update_notify more than 4 times per hour. 12
13
Upon receipt of an unsolicited Mgmt_NWK_Update_notify, the network 14
manager must evaluate if a channel change is required in the network. The 15
specific mechanisms the network manager uses to decide upon a channel change 16
are left to the implementers. It is expected that implementers will apply different 17
methods to best determine when a channel change is required and how to select 18
the most appropriate channel. The following is offered as guidance for 19
implementation. 20
The network manager may do the following: 21
22
1 Wait and evaluate if other reports from other devices are received. This may be 23
appropriate if there are no other failures reported. In this case the network 24
manager should add the reporting device to a list of devices that have reported 25
interference. The number of devices on such a list would depend on the size of 26
the network. The network manager can age devices out of this list. 27
2 Request other interference reports using the Mgmt_NWK_Update_req 28
command. This may be done if other failures have been reported or the network 29
manager device itself has failures and a channel change may be desired. The 30
network manager may request data from the list of devices that have reported 31
interference plus other randomly selected routers in the network. The network 32
manager should not request an update from the device that has just reported 33
interference since this data is fresh already. 34
35
3 Upon receipt of the Mgmt_NWK_Update_notify, the network manager shall 36
determine if a channel change is required using whatever implementation 37
specific mechanisms are considered appropriate. The network manager device 38
with just one channel allowed in the apsChannelMask parameter must not issue 39
the Mgmt_Nwk_Update_Req command to request other devices to change the 40
current channel. However, the network manager may report channel quality 41
issues to the application.48 42
43
48. ZigBee Document 12-0220-04 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 589
4 If the above data indicate a channel change should be considered, the network
manager completed the following: 1
2
a Select a single channel based on the Mgmt_NWK_Update_notify based on 3
the lowest energy. This is the proposed new channel. If this new channel 4
does not have an energy level below an acceptable threshold, a channel 5
change should not be done. Additionally, a new channel shall not belong to a 6
PHY different from the one on which a network manager is operating now.49 7
5 Prior to changing channels, the network manager should store the energy scan 8
value as the last energy scan value and the failure rate from the existing channel 9
as the last failure rate. These values are useful to allow comparison of the 10
failure rate and energy level on the previous channel to evaluate if the network 11
is causing its own interference. 12
13
6 The network manager should broadcast a Mgmt_NWK_Update_req notifying 14
devices of the new channel. The broadcast shall be to all devices with 15
RxOnWhenIdle equal to TRUE. The network manager is responsible for 16
incrementing the nwkUpdateId parameter from the NIB and including it in the 17
Mgmt_NWK_Update_req. The network manager shall set a timer based on the 18
value of apsChannelTimer upon issue of a Mgmt_NWK_Update_req that 19
changes channels and shall not issue another such command until this timer 20
expires. However, during this period, the network manager can complete the 21
above analysis. However, instead of changing channels, the network manager 22
would report to the local application using Mgmt_NWK_Update_notify and 23
the application can force a channel change using the Mgmt_NWK_Update_req. 24
Upon receipt of a Mgmt_NWK_Update_req with a change of channels, the local 25
network manager shall set a timer equal to the 26
nwkNetworkBroadcastDeliveryTime and shall switch channels upon expiration of 27
this timer. Each node shall also increment the nwkUpdateId parameter and also 28
reset the total transmit count and the transmit failure counters. 29
30
For devices with RxOnWhenIdle equals FALSE, any network channel change will 31
not be received. On these devices or routers that have lost the network, an active 32
scan shall be conducted on the apsChannelMask list in the APS IB using the 33
extended PANID to find the network. If the extended PANID is found on different 34
channels, the device should select the channel with the higher value in the 35
nwkUpdateId parameter. If the extended PANID is not found using the 36
apsChannelMask list, a scan should be completed using all channels within the 37
current PHY.50 38
39
40
41
42
49. ZigBee Document 12-0220-04 43
50. ZigBee Document 12-0220-04 44
45
Copyright © 2007-2012 ZigBee Standards Organization. All rights reserved.
Annex E
590 Operation of Network Manager as Network
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-2012 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r20 591
A NNEX
1
2
F 3
4
5
6
7
8
9