054024r01ZB AFG ZigBee Specification 2006 Download

ZigBee Specification
Document 053474r13
1
2
3
4
5
6
7
8
9
10
11
ZIGBEE SPECIFICATION 12
13
14
15
16
17
18
19
ZigBee Document 053474r13
20
December 1, 2006 3:10 pm 21
Sponsored by: ZigBee Alliance 22
23
Accepted by This document has not been accepted by the Alliance BOD. 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
December 1, 2006 35
36
37
38
39
40
41
42
43
44
45
Copyright © 2006 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
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
Document 053474r13 i
NOTICE OF USE AND DISCLOSURE 1

2
3
4
The ZigBee Specification is available to individuals, companies and institutions free of
charge for all non-commercial purposes (including university research, technical 5
evaluation, and development of non-commercial software, tools, or documentation). No 6
part of this specification may be used in development of a product for sale without 7
becoming a member of ZigBee Alliance.
8
Copyright © ZigBee Alliance, Inc. (2006). All rights Reserved. This information within this 9
document is the property of the ZigBee Alliance and its use and disclosure are restricted. 10
Elements of ZigBee Alliance specifications may be subject to third party intellectual 11
property rights, including without limitation, patent, copyright or trademark rights (such a 12
third party may or may not be a member of ZigBee). ZigBee is not responsible and shall not 13
be held responsible in any manner for identifying or failing to identify any or all such third
party intellectual property rights. 14
15
This document and the information contained herein are provided on an “AS IS” basis and 16
ZigBee DISCLAIMS ALL WARRANTIES EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO (A) ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 17
WILL NOT INFRINGE ANY RIGHTS OF THIRD PARTIES (INCLUDING WITHOUT 18
LIMITATION ANY INTELLECTUAL PROPERTY RIGHTS INCLUDING PATENT, 19
COPYRIGHT OR TRADEMARK RIGHTS) OR (B) ANY IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE OR NON- 20
INFRINGEMENT. IN NO EVENT WILL ZIGBEE BE LIABLE FOR ANY LOSS OF 21
PROFITS, LOSS OF BUSINESS, LOSS OF USE OF DATA, INTERRUPTION OF 22
BUSINESS, OR FOR ANY OTHER DIRECT, INDIRECT, SPECIAL OR EXEMPLARY,
INCIDENTIAL, PUNITIVE OR CONSEQUENTIAL DAMAGES OF ANY KIND, IN 23
CONTRACT OR IN TORT, IN CONNECTION WITH THIS DOCUMENT OR THE 24
INFORMATION CONTAINED HEREIN, EVEN IF ADVISED OF THE POSSIBILITY OF 25
SUCH LOSS OR DAMAGE. All Company, brand and product names may be trademarks
that are the sole property of their respective owners. 26
27
The above notice and this paragraph must be included on all copies of this document that 28
are made.
29
ZigBee Alliance, Inc. 30
2400 Camino Ramon, Suite 375 31
San Ramon, CA 94583
32
33
34
35
36
37
38
39
40
41
42
43
44
45
ii Notice of Use and Disclosure
1
2
3
4
5
6
7
8
9
10
11
12
13
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
Document 053474r13 iii
DOCUMENT HISTORY 1
2
3
4
5
6
7
8
ZigBee Specification History 9
10
Version
Number Date Comments 11
12
December 14, 2004 ZigBee v.1.0 draft ratified 13
r06 February 17, 2006 ZigBee Specification (ZigBee document 14
number 053474r06/07) incorporating errata 15
and clarifications: ZigBee document 16
numbers 053920r02, 053954r02, 06084r00, 17
053474r07
18
r07 April 28, 2006 Changes made per Editorial comments on 19
spreadsheet, 20
r13 December 1, 2006 3:08 pm ZigBee-2006 Specification (see letter ballot 21
comments and resolution in ZigBee 22
document 064112) 23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
iv Document History
1
2
3
4
5
6
7
8
9
10
11
12
13
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
Document 053474r13 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
17
1.2 Conventions and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 18
1.2.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 19
1.3 Acronyms and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 20
1.4 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 21
1.4.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 22
23
1.5 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
24
1.5.1 ZigBee/IEEE References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 25
1.5.2 Normative References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 26
1.5.3 Informative References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 27
28
Chapter 2 Application Layer Specification . . . . . . . . . . . . . . . . . . . 19
29
2.1 General Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 30
2.1.1 Application Support Sub-Layer . . . . . . . . . . . . . . . . . . . . . . . 20 31
2.1.2 Application Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 32
2.1.3 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 33
2.1.4 Application Communication Fundamentals . . . . . . . . . . . . . 22 34
35
2.1.5 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
36
2.1.6 Binding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 37
2.1.7 Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 38
2.1.8 ZigBee Device Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 39
2.2 ZigBee Application Support (APS) Sub-Layer . . . . . . . . . . . . . . . 29 40
2.2.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 41
42
2.2.2 Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
43
2.2.3 Application Support (APS) Sub-Layer Overview . . . . . . . . . 29 44
45
vi Table of Contents
2.2.4 Service Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1
2.2.5 Frame Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2
2.2.6 Command Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3
2.2.7 Constants and PIB Attributes. . . . . . . . . . . . . . . . . . . . . . . . . 66 4
2.2.8 Functional Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5
2.3 The ZigBee Application Framework . . . . . . . . . . . . . . . . . . . . . . . 75 6
2.3.1 Creating a ZigBee Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 7
8
2.3.2 ZigBee Descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
9
2.3.3 Functional Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 10
2.4 The ZigBee Device Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 11
2.4.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 12
2.4.2 Device Profile Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 13
2.4.3 Client Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 14
15
2.4.4 Server Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
16
2.4.5 ZDP Enumeration Description. . . . . . . . . . . . . . . . . . . . . . . . 199 17
2.4.6 Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 18
2.5 The ZigBee Device Objects (ZDO) . . . . . . . . . . . . . . . . . . . . . . . . 200 19
2.5.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 20
2.5.2 Device Object Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . 201 21
22
2.5.3 Layer Interface Description . . . . . . . . . . . . . . . . . . . . . . . . . . 208
23
2.5.4 System Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 24
2.5.5 Object Definition and Behavior . . . . . . . . . . . . . . . . . . . . . . . 211 25
2.5.6 Configuration Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 26
27
Chapter 3 Network Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
28
3.1 NWK Layer Status Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 29
3.2.1 Network (NWK) Layer Overview . . . . . . . . . . . . . . . . . . . . . 244 31
3.3 Service Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 32
3.3.1 NWK Data Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 33
34
3.3.2 Network Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
35
3.3.3 Network Formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 36
3.3.4 Allowing Devices to Join. . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 37
3.3.5 Begin as a Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 38
3.3.6 Joining a Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 39
3.3.7 Joining a Device Directly to a Network. . . . . . . . . . . . . . . . . 273 40
41
3.3.8 Leaving a Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
42
3.3.9 Resetting a Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 43
3.3.10 Receiver Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . 282 44
45
Document 053474r13 vii
3.3.11 Information Base Maintenance . . . . . . . . . . . . . . . . . . . . . . 286

1
3.3.12 Route Error Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
2
3.3.13 Route Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 3
3.4 Frame Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 4
3.4.1 General NPDU Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 295 5
3.4.2 Format of Individual Frame Types . . . . . . . . . . . . . . . . . . . . 300 6
3.5 Command Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 7
8
3.5.1 Route Request Command . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
9
3.5.2 Route Reply Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 10
3.5.3 Route Error Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 11
3.5.4 Leave Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 12
3.5.5 Route Record Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 13
3.5.6 Rejoin Request Command . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 14
15
3.5.7 Rejoin Response Command. . . . . . . . . . . . . . . . . . . . . . . . . . 313
16
3.6 Constants and NIB Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 17
3.6.1 NWK Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 18
3.6.2 NWK Information Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 19
3.7 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 20
3.7.1 Network and Device Maintenance. . . . . . . . . . . . . . . . . . . . . 323 21
22
3.7.2 Transmission and Reception . . . . . . . . . . . . . . . . . . . . . . . . . 352
23
3.7.3 Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 24
3.7.4 Scheduling Beacon Transmissions . . . . . . . . . . . . . . . . . . . . 372 25
3.7.5 Broadcast Communication. . . . . . . . . . . . . . . . . . . . . . . . . . . 375 26
3.7.6 Multicast Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 378 27
3.7.7 NWK Information in the MAC Beacons . . . . . . . . . . . . . . . . 381 28
29
Chapter 4 Security Services Specification . . . . . . . . . . . . . . . . . . . . 385 30
4.1 Document Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 31
4.2.1 Security Architecture and Design . . . . . . . . . . . . . . . . . . . . . 386 33
34
4.2.2 MAC Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
35
4.2.3 NWK Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390 36
4.2.4 APL Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 37
4.2.5 Trust Center Role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 38
4.3 MAC Layer Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 39
4.3.1 Frame Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 40
41
4.3.2 Security-related MAC PIB Attributes . . . . . . . . . . . . . . . . . . 397
42
4.4 NWK Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 43
4.4.1 Frame Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 44
45
viii Table of Contents
4.4.2 Secured NPDU Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401

1
4.4.3 Security-related NIB Attributes . . . . . . . . . . . . . . . . . . . . . . . 402
2
4.5 APS Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404 3
4.5.1 Frame Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 4
4.5.2 Key-establishment Services . . . . . . . . . . . . . . . . . . . . . . . . . . 410 5
4.5.3 Transport-key Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 6
4.5.4 Update Device Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 7
8
4.5.5 Remove Device Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
9
4.5.6 Request Key Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431 10
4.5.7 Switch Key Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 11
4.5.8 Command Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 12
4.5.9 Security-related AIB Attributes . . . . . . . . . . . . . . . . . . . . . . . 442 13
4.6 Common Security Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 14
15
4.6.1 Auxiliary Frame Header Format . . . . . . . . . . . . . . . . . . . . . . 445
16
4.6.2 Security Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447 17
4.6.3 Cryptographic Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 448 18
4.6.4 Implementation Guidelines (Informative) . . . . . . . . . . . . . . . 448 19
4.7 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449 20
4.7.1 ZigBee Coordinator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449 21
22
4.7.2 Trust Center Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
23
4.7.3 Security Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450 24
Annex A CCM* Mode of Operation . . . . . . . . . . . . . . . . . . . . . . . . . 471 25
A.1 Notation and Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472 26
27
A.2 CCM* Mode Encryption and Authentication Transformation . . . 472
28
A.2.1 Input Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 29
A.2.2 Authentication Transformation . . . . . . . . . . . . . . . . . . . . . . . 473 30
A.2.3 Encryption Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 474 31
A.3 CCM* Mode Decryption and Authentication 32
Checking Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475 33
34
A.3.1 Decryption Transformation. . . . . . . . . . . . . . . . . . . . . . . . . . 475
35
A.3.2 Authentication Checking Transformation. . . . . . . . . . . . . . . 476 36
A.4 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476 37
Annex B Security Building Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . 477 38
39
B.1 Symmetric-key Cryptographic Building Blocks . . . . . . . . . . . . . . 477
40
B.1.1 Block-cipher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 41
B.1.2 Mode of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 42
B.1.3 Cryptographic Hash Function . . . . . . . . . . . . . . . . . . . . . . . . 478 43
B.1.4 Keyed Hash Function for Message Authentication . . . . . . . 478 44
45
Document 053474r13 ix
B.1.5 Specialized Keyed Hash Function for

1
Message Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
2
B.1.6 Challenge Domain Parameters . . . . . . . . . . . . . . . . . . . . . . . 479 3
B.2 Key Agreement Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 4
B.2.1 Symmetric-key Key Agreement Scheme . . . . . . . . . . . . . . . 479 5
B.3 Challenge Domain Parameter Generation and Validation . . . . . . . 479 6
B.3.1 Challenge Domain Parameter Generation. . . . . . . . . . . . . . . 480 7
8
B.3.2 Challenge Domain Parameter Verification . . . . . . . . . . . . . . 480
9
B.4 Challenge Validation Primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . 481 10
B.5 Secret Key Generation (SKG) Primitive . . . . . . . . . . . . . . . . . . . . 481 11
B.6 Block-cipher-based Cryptographic Hash Function . . . . . . . . . . . . 482 12
B.7 Symmetric-key Authenticated Key Agreement Scheme . . . . . . . . 484 13
B.7.1 Initiator Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485 14
15
B.7.2 Responder Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 487
16
Annex C Test Vectors For Cryptographic Building Blocks . . . . . . 489 17
C.1 Data Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489 18
C.2 AES Block Cipher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489 19
20
C.3 CCM* Mode Encryption and Authentication Transformation . . . 489
21
C.3.1 Input Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490 22
C.3.2 Authentication Transformation . . . . . . . . . . . . . . . . . . . . . . . 491 23
C.3.3 Encryption Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 491 24
C.4 CCM* Mode Decryption and Authentication 25
Checking Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493 26
27
C.4.1 Decryption Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 493
28
C.4.2 Authentication Checking Transformation. . . . . . . . . . . . . . . 494 29
C.5 Cryptographic Hash Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495 30
C.5.1 Test Vector Set 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495 31
C.5.2 Test Vector Set 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496 32
C.6 Keyed Hash Function for Message Authentication . . . . . . . . . . . . 497 33
34
C.6.1 Test Vector Set 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
35
C.6.2 Test Vector Set 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498 36
C.6.3 Specialized Keyed Hash Function for Message 37
Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499 38
C.6.4 Symmetric-key Key Agreement Scheme . . . . . . . . . . . . . . . 499 39
C.6.5 Initiator Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500 40
41
C.6.6 Responder Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 502
42
Annex D MAC and PHY Sub-Layer Clarifications . . . . . . . . . . . . 505 43
D.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505 44
45
x Table of Contents
D.1.1 Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505

1
D.1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
2
D.1.3 Stack Size Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505 3
D.1.4 MAC Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506 4
5
6
7
8
9
10
11
12
13
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
Document 053474r13 xi
LIST OF TABLES 1
2
3
4
Table 2.1 APSDE-SAP Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5
Table 2.2 APSDE-DATA.request Parameters . . . . . . . . . . . . . . . . . . 33 6
Table 2.3 APSDE-DATA.confirm Parameters . . . . . . . . . . . . . . . . . 37 7
Table 2.4 APSDE-DATA.indication Parameters . . . . . . . . . . . . . . . . 39 8
Table 2.5 Summary of the Primitives Accessed Through the APSME-SAP 9
10
41
11
Table 2.6 APSME-BIND.request Parameters . . . . . . . . . . . . . . . . . . 42 12
Table 2.7 APSME-BIND.confirm Parameters . . . . . . . . . . . . . . . . . . 44 13
Table 2.8 APSME-UNBIND.request Parameters . . . . . . . . . . . . . . . 45 14
Table 2.9 APSME-UNBIND.confirm Parameters . . . . . . . . . . . . . . . 47 15
Table 2.10 APSME-GET.request Parameters . . . . . . . . . . . . . . . . . . 49 16
17
Table 2.11 APSME-GET.confirm Parameters . . . . . . . . . . . . . . . . . . 50
18
Table 2.12 APSME-SET.request Parameters . . . . . . . . . . . . . . . . . . . 51 19
Table 2.13 APSME-SET.confirm Parameters . . . . . . . . . . . . . . . . . . 52 20
Table 2.14 APSME-ADD-GROUP.request Parameters . . . . . . . . . . 53 21
Table 2.15 APSME-ADD-GROUP.confirm Parameters . . . . . . . . . . 54 22
Table 2.16 APSME-REMOVE-GROUP.request Parameters . . . . . . 55 23
24
Table 2.17 APSME-REMOVE-GROUP.confirm Parameters . . . . . . 56
25
Table 2.18 APSME-REMOVE-ALL-GROUPS.request Parameters . 57 26
Table 2.19 APSME-REMOVE-ALL-GROUPS.confirm Parameters 58 27
Table 2.20 Values of the Frame Type Sub-field . . . . . . . . . . . . . . . . 60 28
Table 2.21 Values of the Delivery Mode Sub-field . . . . . . . . . . . . . . 60 29
Table 2.22 APS Sub-layer Constants . . . . . . . . . . . . . . . . . . . . . . . . . 66 30
31
Table 2.23 APS IB Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
32
Table 2.24 Address Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 33
Table 2.25 ZigBee Descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 34
Table 2.26 Fields of the Node Descriptor . . . . . . . . . . . . . . . . . . . . . 80 35
Table 2.27 Values of the Logical Type Field . . . . . . . . . . . . . . . . . . . 80 36
Table 2.28 Values of the Frequency Band Field . . . . . . . . . . . . . . . . 81 37
38
Table 2.29 Server Mask Bit Assignments . . . . . . . . . . . . . . . . . . . . . 83
39
Table 2.30 Fields of the Node Power Descriptor . . . . . . . . . . . . . . . . 83 40
Table 2.31 Values of the Current Power Mode Field . . . . . . . . . . . . 84 41
Table 2.32 Values of the Available Power Sources Field . . . . . . . . . 84 42
Table 2.33 Values of the Current Power Sources Field . . . . . . . . . . . 85 43
44
45
xii List of Tables
Table 2.34 Values of the Current Power Source Level Field . . . . . . 85

1
Table 2.35 Fields of the Simple Descriptor . . . . . . . . . . . . . . . . . . . . 86
2
Table 2.36 Values of the Application Device Version Field . . . . . . . 87 3
Table 2.37 Fields of the Complex Descriptor . . . . . . . . . . . . . . . . . . 88 4
Table 2.38 Values of the Character Set Identifier Sub-field . . . . . . . 89 5
Table 2.39 Fields of the User Descriptor . . . . . . . . . . . . . . . . . . . . . . 90 6
Table 2.40 Device and Service Discovery Client Services Commands 97 7
8
Table 2.41 Fields of the NWK_addr_req Command . . . . . . . . . . . . . 98
9
Table 2.42 Fields of the IEEE_addr_req Command . . . . . . . . . . . . . 99 10
Table 2.43 Fields of the Node_Desc_req Command . . . . . . . . . . . . . 100 11
Table 2.44 Fields of the Power_Desc_req Command . . . . . . . . . . . . 101 12
Table 2.45 Fields of the Simple_Desc_req Command . . . . . . . . . . . . 102 13
Table 2.46 Fields of the Active_EP_req Command . . . . . . . . . . . . . . 103 14
15
Table 2.47 Fields of the Match_Desc_req Command . . . . . . . . . . . . 104
16
Table 2.48 Fields of the Complex_Desc_req Command . . . . . . . . . . 105 17
Table 2.49 Fields of the User_Desc_req Command . . . . . . . . . . . . . 106 18
Table 2.50 Fields of the Discovery_Cache_req Command . . . . . . . . 107 19
Table 2.51 Fields of the End_Device_annce Command . . . . . . . . . . 108 20
Table 2.52 Fields of the User_Desc_set Command . . . . . . . . . . . . . . 109 21
22
Table 2.53 Fields of the System_Server_Discovery_req Command . 110
23
Table 2.54 Fields of the Discovery_store_req Command . . . . . . . . . 110 24
Table 2.55 Fields of the Node_Desc_store_req Command . . . . . . . . 112 25
Table 2.56 Fields of the Power_Desc_store_req Command . . . . . . . 113 26
Table 2.57 Fields of the Active_EP_store_req Command . . . . . . . . . 114 27
Table 2.58 Fields of the Simple_Desc_store_req Command . . . . . . . 115 28
29
Table 2.59 Fields of the Remove_node_cache_req Command . . . . . 116
30
Table 2.60 Fields of the Find_node_cache_req Command Frame . . 117 31
Table 2.61 End Device Bind, Bind, Unbind and Bind 32
Management Client Service Commands . . . . . . . . . . . . . . . . . . . 118 33
Table 2.62 Fields of the End_Device_Bind_req Command . . . . . . . 119 34
Table 2.63 Fields of the Bind_req Command . . . . . . . . . . . . . . . . . . 122 35
36
Table 2.64 Fields of the Unbind_req Command . . . . . . . . . . . . . . . . 123
37
Table 2.65 Fields of the Bind_Register_req Command . . . . . . . . . . . 125 38
Table 2.66 Fields of the Replace_Device_req Command . . . . . . . . . 126 39
Table 2.67 Fields of the Store_Bkup_Bind_Entry_req Command . . 127 40
Table 2.68 Fields of the Remove_Bkup_Bind_Entry_req Command 129 41
Table 2.69 Fields of the Backup_Bind_Table_req Command . . . . . . 131 42
43
Table 2.70 Fields of the Recover_Bind_Table_req Command . . . . . 132
44
45
Document 053474r13 xiii
Table 2.71 Fields of the Backup_Source_Bind_req Command . . . . . 133

1
Table 2.72 Fields of the Recover_Source_Bind_req Command . . . . 134
2
Table 2.73 Network Management Client Services Commands . . . . . 134 3
Table 2.74 Fields of the Mgmt_NWK_Disc_req Command . . . . . . . 135 4
Table 2.75 Fields of the Mgmt_Lqi_req Command . . . . . . . . . . . . . . 136 5
Table 2.76 Fields of the Mgmt_Rtg_req Command . . . . . . . . . . . . . 137 6
Table 2.77 Fields of the Mgmt_Bind_req Command . . . . . . . . . . . . 138 7
8
Table 2.78 Fields of the Mgmt_Leave_req Command . . . . . . . . . . . 139
9
Table 2.79 Fields of the Mgmt_Direct_Join_req Command . . . . . . . 140 10
Table 2.80 Fields of the Mgmt_Permit_Joining_req Command . . . . 141 11
Table 2.81 Fields of the Mgmt_Cache_req Command . . . . . . . . . . . 143 12
Table 2.82 Device and Service Discovery Server Service Primitives 144 13
Table 2.83 Fields of the NWK_addr_rsp Command . . . . . . . . . . . . . 145 14
15
Table 2.84 IEEE_addr_rsp Parameters . . . . . . . . . . . . . . . . . . . . . . . 147
16
Table 2.85 Fields of the Node_Desc_rsp Command . . . . . . . . . . . . . 150 17
Table 2.86 Fields of the Power_Desc_rsp Command . . . . . . . . . . . . 152 18
Table 2.87 Fields of the Simple_Desc_rsp Command . . . . . . . . . . . . 153 19
Table 2.88 Fields of the Active_EP_rsp Command . . . . . . . . . . . . . . 155 20
Table 2.89 Fields of the Match_Desc_rsp Command . . . . . . . . . . . . 157 21
22
Table 2.90 Fields of the Complex_Desc_rsp Command . . . . . . . . . . 159
23
Table 2.91 Fields of the User_Desc_rsp Command . . . . . . . . . . . . . . 161 24
Table 2.92 Fields of the System_Server_Discovery_rsp Command . 163 25
Table 2.93 Fields of the User_Desc_conf Command . . . . . . . . . . . . 164 26
Table 2.94 Fields of the Discovery_Cache_rsp Command . . . . . . . . 165 27
Table 2.95 Fields of the Discovery_store_rsp Command . . . . . . . . . 166 28
29
Table 2.96 Fields of the Node_Desc_store_rsp Command . . . . . . . . 167
30
Table 2.97 Fields of the Power_Desc_store_rsp Command . . . . . . . 168 31
Table 2.98 Fields of the Active_EP_store_rsp Command . . . . . . . . . 169 32
Table 2.99 Fields of the Simple_Desc_store_rsp Command . . . . . . . 170 33
Table 2.100 Fields of the Remove_node_cache_rsp Command . . . . 171 34
Table 2.101 Fields of the Find_node_cache_rsp Command . . . . . . . 172 35
36
Table 2.102 End Device Bind, Unbind and Bind Management
37
Server Services Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 38
Table 2.103 Fields of the End_Device_Bind_rsp Command . . . . . . . 174 39
Table 2.104 Fields of the Bind_rsp Command . . . . . . . . . . . . . . . . . 175 40
Table 2.105 Fields of the Unbind_rsp Command . . . . . . . . . . . . . . . 176 41
Table 2.106 Fields of the Bind_Register_rsp Command . . . . . . . . . . 177 42
43
Table 2.107 Fields of the Replace_Device_rsp Command . . . . . . . . 178
44
45
xiv List of Tables
Table 2.108 Fields of the Store_Bkup_Bind_Entry_rsp Command . 179

1
Table 2.109 Fields of the Remove_Bkup_Bind_Entry_rsp Command 180
2
Table 2.110 Fields of the Backup_Bind_Table_rsp Command . . . . . 181 3
Table 2.111 Fields of the Recover_Bind_Table_rsp Command . . . . 182 4
Table 2.112 Fields of the Backup_Source_Bind_rsp Command . . . . 183 5
Table 2.113 Fields of the Recover_Source_Bind_rsp Command . . . 184 6
Table 2.114 Network Management Server Service Commands . . . . 185 7
8
Table 2.115 Fields of the Mgmt_NWK_Disc_rsp Command . . . . . . 185
9
Table 2.116 NetworkList Record Format . . . . . . . . . . . . . . . . . . . . . 186 10
Table 2.117 Fields of the Mgmt_Lqi_rsp Command . . . . . . . . . . . . . 188 11
Table 2.118 NeighborTableList Record Format . . . . . . . . . . . . . . . . 189 12
Table 2.119 Fields of the Mgmt_Rtg_rsp Command . . . . . . . . . . . . . 191 13
Table 2.120 RoutingTableList Record Format . . . . . . . . . . . . . . . . . 191 14
15
Table 2.121 Fields of the Mgmt_Bind_rsp Command . . . . . . . . . . . . 193
16
Table 2.122 BindingTableList Record Format . . . . . . . . . . . . . . . . . 194 17
Table 2.123 Fields of the Mgmt_Leave_rsp Command . . . . . . . . . . . 195 18
Table 2.124 Fields of the Mgmt_Direct_Join_rsp Command . . . . . . 196 19
Table 2.125 Fields of the Mgmt_Permit_Joining_rsp Command . . . 197 20
Table 2.126 Fields of the Mgmt_Cache_rsp Command . . . . . . . . . . 198 21
22
Table 2.127 DiscoveryCacheList Record Format . . . . . . . . . . . . . . . 198
23
Table 2.128 ZDP Enumerations Description . . . . . . . . . . . . . . . . . . . 199 24
Table 2.129 ZigBee Device Objects . . . . . . . . . . . . . . . . . . . . . . . . . 211 25
Table 2.130 Device and Service Discovery Attributes . . . . . . . . . . . 227 26
Table 2.131 Security Manager Attributes . . . . . . . . . . . . . . . . . . . . . 229 27
Table 2.132 Binding Manager Attributes . . . . . . . . . . . . . . . . . . . . . . 230 28
29
Table 2.133 Network Manager Attributes . . . . . . . . . . . . . . . . . . . . . 232
30
Table 2.134 Node Manager Attributes . . . . . . . . . . . . . . . . . . . . . . . . 233 31
Table 2.135 Configuration Attributes . . . . . . . . . . . . . . . . . . . . . . . . 234 32
Table 2.136 Configuration Attribute Definitions . . . . . . . . . . . . . . . . 236 33
Table 3.1 NWK Layer Status Values . . . . . . . . . . . . . . . . . . . . . . . . . 243 34
Table 3.2 NLDE-SAP Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 35
36
Table 3.3 NLDE-DATA.request Parameters . . . . . . . . . . . . . . . . . . 248
37
Table 3.4 NLDE-DATA.confirm Parameters . . . . . . . . . . . . . . . . . . 251 38
Table 3.5 NLDE-DATA.indication Parameters . . . . . . . . . . . . . . . . . 252 39
Table 3.6 Summary of the Primitives Accessed Through the NLME-SAP 40
253 41
Table 3.7 NLME-NETWORK-DISCOVERY.request Parameters . . 254 42
43
Table 3.8 NLME-NETWORK-DISCOVERY.confirm Parameters . 255
44
45
Document 053474r13 xv
Table 3.9 Network Descriptor Information Fields . . . . . . . . . . . . . . . 256

1
Table 3.10 NLME-NETWORK-FORMATION.request Parameters . 258
2
Table 3.11 NLME-NETWORK-FORMATION.confirm Parameters 260 3
Table 3.12 NLME-PERMIT-JOINING.request Parameters . . . . . . . 261 4
Table 3.13 NLME-PERMIT-JOINING.confirm Parameters . . . . . . . 262 5
Table 3.14 NLME-START-ROUTER.request Parameters . . . . . . . . 263 6
Table 3.15 NLME-START-ROUTER.confirm Parameters . . . . . . . . 264 7
8
Table 3.16 NLME-JOIN.request Parameters . . . . . . . . . . . . . . . . . . . 266
9
Table 3.17 Capability Information Bit-fields . . . . . . . . . . . . . . . . . . . 268 10
Table 3.18 NLME-JOIN.indication Parameters . . . . . . . . . . . . . . . . . 271 11
Table 3.19 NLME-JOIN.confirm Parameters . . . . . . . . . . . . . . . . . . 272 12
Table 3.20 NLME-DIRECT-JOIN.request Parameters . . . . . . . . . . . 273 13
Table 3.21 NLME-DIRECT-JOIN.confirm Parameters . . . . . . . . . . 274 14
15
Table 3.22 NLME-LEAVE.request Parameters . . . . . . . . . . . . . . . . . 276
16
Table 3.23 NLME-LEAVE.indication Parameters . . . . . . . . . . . . . . 278 17
Table 3.24 NLME-LEAVE.confirm Parameters . . . . . . . . . . . . . . . . 279 18
Table 3.25 NLME-RESET.confirm Parameters . . . . . . . . . . . . . . . . 281 19
Table 3.26 NLME-SYNC.request Parameters . . . . . . . . . . . . . . . . . . 283 20
Table 3.27 NLME-SYNC.confirm Parameters . . . . . . . . . . . . . . . . . 284 21
22
Table 3.28 NLME-GET.request Parameters . . . . . . . . . . . . . . . . . . . 287
23
Table 3.29 NLME-GET.confirm Parameters . . . . . . . . . . . . . . . . . . . 288 24
Table 3.30 NLME-SET.request Parameters . . . . . . . . . . . . . . . . . . . . 289 25
Table 3.31 NLME-SET.confirm Parameters . . . . . . . . . . . . . . . . . . . 290 26
Table 3.32 NLME-ROUTE-ERROR.indication Parameters . . . . . . . 291 27
Table 3.33 NLME-ROUTE-DISCOVERY.request Parameters . . . . 292 28
29
Table 3.34 NLME-ROUTE-DISCOVERY.confirm Parameters . . . . 294
30
Table 3.35 Values of the Frame Type Sub-field . . . . . . . . . . . . . . . . 296 31
Table 3.36 Values of the Discover Route Sub-field . . . . . . . . . . . . . 296 32
Table 3.37 Values of the Multicast Mode Sub-field . . . . . . . . . . . . . 299 33
Table 3.38 NWK Command Frames . . . . . . . . . . . . . . . . . . . . . . . . . 302 34
Table 3.39 Error Codes for Route Error Command Frame . . . . . . . . 307 35
36
Table 3.40 NWK Layer Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
37
Table 3.41 NWK IB Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 38
Table 3.42 Group Table Entry Format . . . . . . . . . . . . . . . . . . . . . . . . 323 39
Table 3.43 Neighbor Table Entry Format . . . . . . . . . . . . . . . . . . . . . 342 40
Table 3.44 Additional Neighbor Table Fields . . . . . . . . . . . . . . . . . . 344 41
Table 3.45 Example Addressing Offset Values for Each Given 42
43
Depth Within the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
44
45
xvi List of Tables
Table 3.46 Routing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

1
Table 3.47 Route Status Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
2
Table 3.48 Route Discovery Table . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 3
Table 3.49 Start Time for Beacon Transmissions . . . . . . . . . . . . . . . 375 4
Table 3.50 Broadcast Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 5
Table 3.51 NWK Layer Information Fields . . . . . . . . . . . . . . . . . . . . 382 6
Table 4.1 NIB Security Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 7
8
Table 4.2 Elements of the Network Security Material Descriptor . . . 404
9
Table 4.3 Elements of the Incoming Frame Counter Descriptor . . . . 404 10
Table 4.4 The APS Layer Security Primitives . . . . . . . . . . . . . . . . . . 405 11
Table 4.5 APSME-ESTABLISH-KEY.request Parameters . . . . . . . . 411 12
Table 4.6 APSME-ESTABLISH-KEY.confirm Parameters . . . . . . . 412 13
Table 4.7 APSME-ESTABLISH-KEY.indication Parameters . . . . . 413 14
15
Table 4.8 APSME-ESTABLISH-KEY.response Parameters . . . . . . 414
16
Table 4.9 Mapping of Frame Names to Symmetric-key Key 17
Agreement Scheme Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 18
Table 4.10 Mapping of Symmetric-key Key Agreement Error 19
Conditions to Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 20
Table 4.11 APSME-TRANSPORT-KEY.request Parameters . . . . . . 421 21
22
Table 4.12 KeyType Parameter of The Transport-Key Primitive . . . 421
23
Table 4.13 TransportKeyData Parameter for a Trust Center Master Key 24
421 25
Table 4.14 TransportKeyData Parameter for a Network Key . . . . . . 422 26
Table 4.15 TransportKeyData Parameter for an Application 27
Master or Link Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 28
29
Table 4.16 APSME-TRANSPORT-KEY.indication Parameters . . . 424
30
425 32
Table 4.18 TransportKeyData Parameter for a Network Key . . . . . . 425 33
Table 4.19 APSME-UPDATE-DEVICE.request Parameters . . . . . . 427 34
Table 4.20 APSME-UPDATE-DEVICE.indication Parameters . . . . 429 35
36
Table 4.21 APSME-REMOVE-DEVICE.request Parameters . . . . . . 430
37
Table 4.22 APSME-REMOVE-DEVICE.indication Parameters . . . 431 38
Table 4.23 APSME-REQUEST-KEY.request Parameters . . . . . . . . 432 39
Table 4.24 APSME-REQUEST-KEY.indication Parameters . . . . . . 433 40
Table 4.25 APSME-SWITCH-KEY.request Parameters . . . . . . . . . . 434 41
Table 4.26 APSME-SWITCH-KEY.indication Parameters . . . . . . . 435 42
43
Table 4.27 Command Identifier Values . . . . . . . . . . . . . . . . . . . . . . . 436
44
45
Document 053474r13 xvii
Table 4.28 AIB Security Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 443

1
Table 4.29 Elements of the Key-Pair Descriptor . . . . . . . . . . . . . . . . 444
2
Table 4.30 Security Levels Available to the MAC, NWK, and APS layers 3
445 4
Table 4.31 Encoding for the Key Identifier Sub-field . . . . . . . . . . . . 446 5
Table D.1 Associate Request Header Fields . . . . . . . . . . . . . . . . . . . 506 6
Table D.2 Data Request Header Fields . . . . . . . . . . . . . . . . . . . . . . . 507 7
8
Table D.3 Association Response Header Fields . . . . . . . . . . . . . . . . 507
9
10
11
12
13
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
xviii List of Tables
1
2
3
4
5
6
7
8
9
10
11
12
13
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
Document 053474r13 xix
LIST OF FIGURES 1
2
3
4
Figure 1.1 Outline of the ZigBee Stack Architecture . . . . . . . . . . . . 3 5
Figure 2.1 Multiple Subunits in a Single Node . . . . . . . . . . . . . . . . . 21 6
Figure 2.2 ZigBee Binding and the Binding Table . . . . . . . . . . . . . . 25 7
Figure 2.3 The APS Sub-Layer Reference Model . . . . . . . . . . . . . . . 31 8
Figure 2.4 General APS Frame Format . . . . . . . . . . . . . . . . . . . . . . . 59 9
10
Figure 2.5 Format of the Frame Control Field . . . . . . . . . . . . . . . . . . 59
11
Figure 2.6 Data Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 12
Figure 2.7 APS Command Frame Format. . . . . . . . . . . . . . . . . . . . . 64 13
Figure 2.8 Acknowledgement Frame Format . . . . . . . . . . . . . . . . . . 64 14
Figure 2.9 Direct Binding on a Device Supporting a Binding Table . 69 15
Figure 2.10 Successful Data Transmission Without an Acknowledgement 16
17
73
18
Figure 2.11 Successful Data Transmission With an Acknowledgement 74 19
Figure 2.12 Format of the Complex Descriptor . . . . . . . . . . . . . . . . . 78 20
Figure 2.13 Format of an Individual Complex Descriptor Field . . . . 78 21
Figure 2.14 Format of the MAC Capability Flags Field . . . . . . . . . . 81 22
Figure 2.15 Format of the Language and Character Set Field . . . . . . 88 23
24
Figure 2.16 Format of the ZDP Frame . . . . . . . . . . . . . . . . . . . . . . . . 96
25
Figure 2.17 Format of the NWK_addr_req Command . . . . . . . . . . . 98 26
Figure 2.18 Format of the IEEE_addr_req_Command Frame . . . . . . 99 27
Figure 2.19 Format of the Node_Desc_req Command Frame . . . . . . 100 28
Figure 2.20 Format of the Power_Desc_req Command Frame . . . . . 101 29
Figure 2.21 Format of the Simple_Desc_req Command Frame . . . . 102 30
31
Figure 2.22 Format of the Active_EP_req Command Frame . . . . . . 102
32
Figure 2.23 Format of the Match_Desc_req Command Frame . . . . . 103 33
Figure 2.24 Format of the Complex_Desc_req Command Frame . . 105 34
Figure 2.25 Format of the User_Desc_req Command Frame . . . . . . 106 35
Figure 2.26 Format of the Discovery_Cache_req Command Frame . 107 36
Figure 2.27 Format of the End_Device_annce Command Frame . . . 107 37
38
Figure 2.28 Format of the User_Desc_set Command Frame . . . . . . 108
39
Figure 2.29 Format of the System_Server_Discovery_req 40
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 41
Figure 2.30 Format of the Discovery_Store_req Command Frame . 110 42
Figure 2.31 Format of the Node_Desc_store_req Command Frame . 112 43
44
45
xx List of Figures
Figure 2.32 Format of the Power_Desc_store_req Command Frame 113

1
Figure 2.33 Format of the Active_EP_store_req Command Frame . 114
2
Figure 2.34 Format of the Simple_Desc_store_req Command Frame 115 3
Figure 2.35 Format of the Remove_node_cache_req Command Frame 4
116 5
Figure 2.36 Format of the Find_node_cache Command Frame . . . . 117 6
Figure 2.37 Format of the End_Device_Bind_req Command Frame 119 7
8
Figure 2.38 Format of the Bind_req Command Frame . . . . . . . . . . . 121
9
Figure 2.39 Format of the Unbind_req Command Frame . . . . . . . . . 123 10
Figure 2.40 Format of the Bind_Register_req Command Frame . . . 125 11
Figure 2.41 Format of the Replace_Device_req Command Frame . . 126 12
Figure 2.42 Format of the Store_Bkup_Bind_Entry_req Command Frame 13
127 14
15
Figure 2.43 Format of the Remove_Bkup_Bind_Entry_req
16
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 17
Figure 2.44 Format of the Backup_Bind_Table_req Command Frame 18
130 19
Figure 2.45 Fields of the Recover_Bind_Table_req Command Frame 132 20
Figure 2.46 Fields of the Backup_Source_Bind_req Command Frame 21
22
132
23
Figure 2.47 Format of the Recover_Source_Bind_req Command Frame 24
134 25
Figure 2.48 Format of the Mgmt_NWK_Disc_req Command Frame 135 26
Figure 2.49 Format of the Mgmt_Lqi_req Command Frame . . . . . . 136 27
Figure 2.50 Format of the Mgmt_Rtg_req Command Frame . . . . . . 137 28
29
Figure 2.51 Format of the Mgmt_Bind_req Command Frame . . . . . 138
30
Figure 2.52 Format of the Mgmt_Leave_req Command Frame . . . . 139 31
Figure 2.53 Format of the Mgmt_Direct_Join _reqCommand Frame 140 32
Figure 2.54 Format of the Mgmt_Permit_Joining_req Command Frame 33
141 34
Figure 2.55 Fields of the Mgmt_Cache_req Command Frame . . . . . 142 35
36
Figure 2.56 Format of the NWK_addr_rsp Command Frame . . . . . . 145
37
Figure 2.57 Format of the IEEE_addr_rs Command Frame . . . . . . . 147 38
Figure 2.58 Format of the Node_Desc_rsp Command Frame . . . . . . 150 39
Figure 2.59 Format of the Power_Desc_rsp Command Frame . . . . . 151 40
Figure 2.60 Format of the Simple_Desc_rsp Command Frame . . . . 153 41
Figure 2.61 Format of the Active_EP_rsp Command Frame . . . . . . 155 42
43
Figure 2.62 Format of the Match_Desc_rsp Command Frame . . . . . 156
44
45
Document 053474r13 xxi
Figure 2.63 Format of the Complex_Desc_rsp Command Frame . . . 159

1
Figure 2.64 Format of the User_Desc_rsp Command Frame . . . . . . 161
2
Figure 2.65 System_Server_Discovery_rsp Command Frame . . . . . 162 3
Figure 2.66 Format of the User_Desc_conf Command Frame . . . . . 163 4
Figure 2.67 Format of the Discovery_Cache_rsp Command Frame . 165 5
Figure 2.68 Format of the Discovery_store_rsp Command Frame . . 166 6
Figure 2.69 Format of the Node_Desc_store_rsp Command Frame . 167 7
8
Figure 2.70 Format of the Power_Desc_store_rsp Command Frame 168
9
Figure 2.71 Format of the Active_EP_store_rsp Command Frame . 169 10
Figure 2.72 Format of the Simple_Desc_store_rsp Command Frame 170 11
Figure 2.73 Format of the Remove_node_cache_rsp Command Frame 12
171 13
Figure 2.74 Format of the Find_node_cache_rsp Command Frame . 172 14
15
Figure 2.75 Format of the End_Device_Bind_rsp Command Frame 173
16
Figure 2.76 Format of the Bind_rsp Command Frame . . . . . . . . . . . 175 17
Figure 2.77 Format of the Unbind_rsp Command Frame . . . . . . . . . 176 18
Figure 2.78 Format of the Bind_Register_rsp Command Frame . . . 177 19
Figure 2.79 Format of the Replace_Device_rsp Command Frame . . 178 20
Figure 2.80 Format of the Store_Bkup_Bind_Entry_rsp Command Frame 21
22
179
23
Figure 2.81 Format of the Remove_Bkup_Bind_Entry_rsp 24
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 25
Figure 2.82 Format of the Backup_Bind_Table_rsp Command Frame 180 26
Figure 2.83 Format of the Backup_Bind_Table_rsp Command Frame 181 27
Figure 2.84 Format of the Backup_Source_Bind_rsp Command Frame 28
29
183
30
Figure 2.85 Format of the Recover_Source_Bind_rsp Command Frame 31
183 32
Figure 2.86 Format of the Mgmt_NWK_Disc_rsp Command Frame 185 33
Figure 2.87 Format of the Mgmt_Lqi_rsp Command Frame . . . . . . 188 34
Figure 2.88 Format of the Mgmt_Rtg_rsp Command Frame . . . . . . 191 35
36
Figure 2.89 Format of the Mgmt_Bind_rsp Command Frame . . . . . 193
37
Figure 2.90 Format of the Mgmt_Leave_rsp Command Frame . . . . 195 38
Figure 2.91 Format of the Mgmt_Direct_Join_rsp Command Frame 196 39
Figure 2.92 Format of the Mgmt_Permit_Joining_rsp Command Frame 40
197 41
Figure 2.93 Format of the Mgmt_Cache_rsp Command Frame . . . . 198 42
43
Figure 2.94 Primary Discovery Cache State Machine . . . . . . . . . . . . 203
44
45
xxii List of Figures
Figure 2.95 System Usage ZigBee Device Object Details . . . . . . . . 209

1
Figure 2.96 Portability Message Sequence Chart: ZED Rejoin . . . . 220
2
Figure 2.97 Portability Message Sequence Chart: ZR Rejoin . . . . . . 221 3
Figure 3.1 The NWK Layer Reference Model . . . . . . . . . . . . . . . . . 246 4
Figure 3.2 Message Sequence Chart for Resetting the Network Layer 282 5
Figure 3.3 Message Sequence Chart for Synchronizing in a Non- 6
Beaconing Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 7
8
Figure 3.4 Message Sequence Chart for Synchronizing in a Beacon-
9
Enabled Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 10
Figure 3.5 General NWK Frame Format . . . . . . . . . . . . . . . . . . . . . . 295 11
Figure 3.6 Frame Control Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 12
Figure 3.7 Multicast Control Field Format . . . . . . . . . . . . . . . . . . . . 298 13
Figure 3.8 Source Route Subframe Format . . . . . . . . . . . . . . . . . . . . 299 14
15
Figure 3.9 Data Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
16
Figure 3.10 NWK Command Frame Format . . . . . . . . . . . . . . . . . . . 301 17
Figure 3.11 Route Request Command Frame Format . . . . . . . . . . . . 302 18
Figure 3.12 Route Request Command Options Field . . . . . . . . . . . . 303 19
Figure 3.13 Route Reply Command Format . . . . . . . . . . . . . . . . . . . 304 20
Figure 3.14 Route Reply Command Options Field . . . . . . . . . . . . . . 305 21
22
Figure 3.15 Route Error Command Frame Format . . . . . . . . . . . . . . 306
23
Figure 3.16 Leave Command Frame Format . . . . . . . . . . . . . . . . . . . 309 24
Figure 3.17 Leave Command Options Field . . . . . . . . . . . . . . . . . . . 310 25
Figure 3.18 Route Record Command Format . . . . . . . . . . . . . . . . . . 311 26
Figure 3.19 Rejoin Request Command Frame Format . . . . . . . . . . . 312 27
Figure 3.20 Rejoin Response Command Frame Format . . . . . . . . . . 313 28
29
Figure 3.21 Establishing a New Network . . . . . . . . . . . . . . . . . . . . . 326
30
Figure 3.22 Permitting Devices to Join a Network . . . . . . . . . . . . . . 327 31
Figure 3.23 Procedure for Joining a Network Through Association . 331 32
Figure 3.24 Procedure for Handling a Join Request . . . . . . . . . . . . . 333 33
Figure 3.25 Child Rejoin Procedure . . . . . . . . . . . . . . . . . . . . . . . . . 335 34
Figure 3.26 Parent Rejoin Procedure . . . . . . . . . . . . . . . . . . . . . . . . . 337 35
36
Figure 3.27 Joining a Device to a Network Directly . . . . . . . . . . . . . 338
37
Figure 3.28 Child Procedure for Joining or Re-joining a Network 38
Through Orphaning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 39
Figure 3.29 Parent Procedure for Joining or Re-joining a Device to its 40
Network Through Orphaning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 41
Figure 3.30 Address Assignment in an Example Network . . . . . . . . 346 42
43
Figure 3.31 Initiation of the Leave Procedure . . . . . . . . . . . . . . . . . . 348
44
45
Document 053474r13 xxiii
Figure 3.32 Procedure for a Device to Remove Its Child . . . . . . . . . 349

1
Figure 3.33 On Receipt of a Leave Command . . . . . . . . . . . . . . . . . 351
2
Figure 3.34 Typical Frame Structure for a Beaconing Device . . . . . 373 3
Figure 3.35 Parent-Child Superframe Positioning Relationship . . . . 374 4
Figure 3.36 Broadcast Transaction Message Sequence Chart . . . . . . 378 5
Figure 3.37 Format of the MAC Sub-Layer Beacon Payload . . . . . . 383 6
Figure 4.1 ZigBee Frame with Security at the MAC Level . . . . . . . . 390 7
8
Figure 4.2 ZigBee Frame with Security on the NWK Level . . . . . . . 391
9
Figure 4.3 ZigBee Frame with Security on the APS Level . . . . . . . . 392 10
Figure 4.4 Secured NWK Layer Frame Format . . . . . . . . . . . . . . . . . 402 11
Figure 4.5 Sequence Chart for Successful APSME-ESTABLISH- 12
KEY Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 13
Figure 4.6 Secured APS Layer Frame Format . . . . . . . . . . . . . . . . . . 436 14
15
Figure 4.7 Generic SKKE Frame Command Format . . . . . . . . . . . . . 437
16
Figure 4.8 Transport-Key Command Frame . . . . . . . . . . . . . . . . . . . 438 17
Figure 4.9 Trust Center Master Key Descriptor Field in Transport-Key 18
Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439 19
Figure 4.10 Network Key Descriptor Field in Transport-Key Command 20
439 21
22
Figure 4.11 Application Master Key Descriptor in Transport-Key
23
Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440 24
Figure 4.12 Update-Device Command Frame Format . . . . . . . . . . . 440 25
Figure 4.13 Remove-Device Command Frame Format . . . . . . . . . . . 441 26
Figure 4.14 Request-Key Command Frame Format . . . . . . . . . . . . . 441 27
Figure 4.15 Switch-key Command Frame Format . . . . . . . . . . . . . . 442 28
29
Figure 4.16 Auxiliary Frame Header Format . . . . . . . . . . . . . . . . . . 445
30
Figure 4.17 Security Control Field Format . . . . . . . . . . . . . . . . . . . . 445 31
Figure 4.18 CCM* Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447 32
Figure 4.19 Example of Joining a Secured Network . . . . . . . . . . . . . 451 33
Figure 4.20 Example Residential-Mode Authentication Procedure . 458 34
Figure 4.21 Example Commercial-Mode Authentication Procedure . 459 35
36
Figure 4.22 Example Network Key-Update Procedure . . . . . . . . . . . 461
37
Figure 4.23 Example Network Key-Recovery Procedure . . . . . . . . . 462 38
Figure 4.24 Example End-to-End Application Key Establishment 39
Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 40
Figure 4.25 Example Remove-Device Procedure . . . . . . . . . . . . . . . 467 41
Figure 4.26 Example Device-Leave Procedure . . . . . . . . . . . . . . . . . 468 42
43
Figure B.1 Symmetric-Key Authenticated Key Agreement Scheme 484
44
45
xxiv List of Figures
1
2
3
4
5
6
7
8
9
10
11
12
13
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
Document 053474r13 1
C H A P T E R
1
1
2
3
4
5
6
7
8
9
CHAPTER 1ZIGBEE PROTOCOL OVERVIEW 10

11
12
13
1.1 Protocol Description 14
15
The ZigBee Alliance is developing a very low-cost, very low power consumption, 16
two-way, wireless communications standard. Solutions adopting the ZigBee 17
standard will be embedded in consumer electronics, home and building 18
automation, industrial controls, PC peripherals, medical sensor applications, toys 19
and games. 20
21
22
1.1.1 Scope 23
24
This document contains specifications, interface descriptions, object descriptions, 25
protocols and algorithms pertaining to the ZigBee protocol standard, including the 26
application support sub-layer (APS), the ZigBee device objects (ZDO), ZigBee 27
device profile (ZDP), the application framework, the network layer (NWK) and 28
ZigBee security services. 29
30
1.1.2 Purpose 31
32
The purpose of this document is to provide a definitive description of the ZigBee 33
protocol standard as a basis for future implementations, such that any number of 34
companies incorporating the ZigBee standard into platforms and devices on the 35
basis of this document will produce interoperable, low-cost and highly usable 36
products for the burgeoning wireless marketplace. 37
38
39
1.1.3 Stack Architecture 40
41
The ZigBee stack architecture is made up of a set of blocks called layers. Each 42
layer performs a specific set of services for the layer above: a data entity provides 43
a data transmission service and a management entity provides all other services. 44
45
Chapter 1
2 ZigBee Protocol Overview
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 ZigBee stack architecture, depicted in Figure 1.1, is based on the standard 4
Open Systems Interconnection (OSI) seven-layer model (see [B14]) but defines 5
only those layers relevant to achieving functionality in the intended market space. 6
The IEEE 802.15.4-2003 standard defines the two lower layers: the physical 7
(PHY) layer and the medium access control (MAC) sub-layer. The ZigBee 8
Alliance builds on this foundation by providing the network (NWK) layer and the 9
framework for the application layer. The application layer framework is 10
comprised of the application support sub-layer (APS), the ZigBee device objects 11
(ZDO) and the manufacturer-defined application objects. 12
IEEE 802.15.4-2003 has two PHY layers that operate in two separate frequency 13
ranges: 868/915 MHz and 2.4 GHz. The lower frequency PHY layer covers both 14
the 868 MHz European band and the 915 MHz band, used in countries such as the 15
United States and Australia. The higher frequency PHY layer is used virtually 16
worldwide. A complete description of the IEEE 802.15.4-2003 PHY layers can be 17
found in [B1]. 18
19
The IEEE 802.15.4-2003 MAC sub-layer controls access to the radio channel 20
using a CSMA-CA mechanism. Its responsibilities may also include transmitting 21
beacon frames, synchronization and providing a reliable transmission mechanism. 22
A complete description of the IEEE 802.15.4-2003 MAC sub-layer can be found 23
in [B1]. 24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Application (APL) Layer

1
Application Framework
2
ZigBee Device Object
3
(ZDO) 4
ZDO Public
Application Application
Interfaces
Object 240
… Object 1 5
6
Endpoint 240
APSDE-SAP
Endpoint 1
APSDE-SAP
Endpoint 0
APSDE-SAP
7
8
ZDO Management Plane

APSME-SAP
Application Support Sublayer (APS)
ASL
APS Security APS Message Reflector 9
Management Broker Management
Security 10
Service -
Provider
NLDE-SAP
Network (NWK) Layer
11
NLME-SAP
IEEE 802.15.4
NWK Security NWK Message Routing Network 12
defined
TM
Management Broker Management Management
13
ZigBee Alliance
defined MLDE-SAP MLME-SAP 14
Medium Access Control (MAC) Layer
End manufacturer 15
defined
PLME-SAP
16
PD-SAP
Layer
Physical (PHY) Layer 17
function
2.4 GHz Radio 868/915 MHz 18
Layer di
interface 19
20
Figure 1.1 Outline of the ZigBee Stack Architecture 21
22
The responsibilities of the ZigBee NWK layer shall include mechanisms used to: 23
24
• Join and leave a network 25
• Apply security to frames 26
27
• Route frames to their intended destinations 28
• Discover and maintain routes between devices 29
30
• Discover one-hop neighbors 31
• Store of pertinent neighbor information 32
33
The NWK layer of a ZigBee coordinator (see “Network Topology”) is responsible 34
for starting a new network, when appropriate, and assigning addresses to newly 35
associated devices. 36
The ZigBee application layer consists of the APS, the Application Framework 37
(AF), the ZDO and the manufacturer-defined application objects. 38
39
The responsibilities of the APS sub-layer include: 40
• Maintaining tables for binding, defined as the ability to match two devices 41
together based on their services and their needs 42
43
• Forwarding messages between bound devices 44
45
Chapter 1
The responsibilities of the ZDO include:

1
• Defining the role of the device within the network (e.g., ZigBee coordinator or 2
end device) 3
• Initiating and/or responding to binding requests 4
5
• Establishing a secure relationship between network devices. 6
The ZDO is also responsible for discovering devices on the network and 7
determining which application services they provide. 8
9
10
1.1.4 Network Topology 11
12
The ZigBee network layer (NWK) supports star, tree and mesh topologies. In a 13
star topology, the network is controlled by one single device called the ZigBee 14
coordinator. The ZigBee coordinator is responsible for initiating and maintaining 15
the devices on the network, and all other devices, known as end devices, directly 16
communicate with the ZigBee coordinator. In mesh and tree topologies, the 17
ZigBee coordinator is responsible for starting the network and for choosing 18
certain key network parameters but the network may be extended through the use 19
of ZigBee routers. In tree networks, routers move data and control messages 20
through the network using a hierarchical routing strategy. Tree networks may 21
employ beacon-oriented communication as described in the IEEE 802.15.4-2003 22
specification. Mesh networks shall allow full peer-to-peer communication. 23
ZigBee routers in mesh networks shall not emit regular IEEE 802.15.4-2003 24
beacons. This specification describes only intra-PAN networks, that is, networks 25
in which communications begin and terminate within the same network. 26
27
28
1.2 Conventions and Abbreviations 29
30
31
1.2.1 Conventions 32
33
1.2.1.1 Symbols and Notation 34
Notation follows from ANSI X9.63-2001, §2.2 [B7] 35
36
1.2.1.2 Integers, Octets, and Their Representation 37
38
Throughout Annexes A through D, the representation of integers as octet strings 39
and of octet strings as binary strings shall be fixed. All integers shall be 40
represented as octet strings in most-significant-octet first order. This 41
representation conforms to the convention in Section 4.3 of ANSI X9.63- 42
2001 [B7]. All octets shall be represented as binary strings in most-significant-bit 43
first order. 44
45
1.2.1.3 Entities
1
Throughout this specification, each entity shall be a DEV and shall be uniquely 2
identified by its 64-bit IEEE device address [B1]. The parameter entlen shall have 3
the integer value 64. 4
5
1.2.1.4 Transmission Order 6
7
Unless otherwise indicated, the transmission order of all frames in this 8
specification follow the conventions used in IEEE Std. 802.15.4-2003 [B1]): 9
• Frame formats are depicted in the order in which they are transmitted by the 10
PHY layer—from left to right—where the leftmost bit is transmitted first in 11
time. 12
13
• Bits within each field are numbered from 0 (leftmost, and least significant) to k- 14
1 (rightmost, and most significant), where the length of the field is k bits. 15
• Fields that are longer than a single octet are sent to the PHY in the order from 16
the octet containing the lowest numbered bits to the octet containing the highest 17
numbered bits. 18
19
1.2.1.5 Strings and String Operations 20
21
A string is a sequence of symbols over a specific set (e.g., the binary alphabet 22
{0,1} or the set of all octets). The length of a string is the number of symbols it 23
contains (over the same alphabet). The empty string has length 0. The right- 24
concatenation of two strings x and y of length m and n respectively (notation: x || 25
y), is the string z of length m+n that coincides with x on its leftmost m symbols 26
and with y on its rightmost n symbols. An octet is a symbol string of length 8. In 27
our context, all octets are strings over the binary alphabet. 28
29
1.3 Acronyms and Abbreviations 30
31
32
For the purposes of this standard, the following acronyms and abbreviations 33
apply: 34
AIB Application support layer information base 35
36
AF Application framework 37
APDU Application support sub-layer protocol data unit 38
APL Application layer
39
40
APS Application support sub-layer 41
APSDE Application support sub-layer data entity 42
43
APSDE-SAP Application support sub-layer data entity – service access point
44
45
Chapter 1
APSME Application support sub-layer management entity

1
APSME-SAP Application support sub-layer management entity – service access point 2
ASDU APS Service Data Unit 3
4
BRT Broadcast retry timer
5
BTR Broadcast transaction record 6
BTT Broadcast transaction table 7
8
CCM* Enhanced counter with CBC-MAC mode of operation
9
CSMA-CA Carrier sense multiple access – collision avoidance 10
FFD Full function device 11
12
GTS Guaranteed time slot 13
IB Information base 14
LQI Link quality indicator 15
16
LR-WPAN Low rate wireless personal area network 17
MAC Medium access control 18
19
MCPS-SAP Medium access control common part sub-layer – service access point
20
MIC Message integrity code 21
MLME-SAP Medium access control sub-layer management entity – service access point 22
23
MSC Message sequence chart
24
MSDU Medium access control sub-layer service data unit 25
MSG Message service type 26
27
NBDT Network broadcast delivery time
28
NHLE Next Higher Layer Entity 29
NIB Network layer information base 30
31
NLDE Network layer data entity 32
NLDE-SAP Network layer data entity – service access point 33
NLME Network layer management entity 34
35
NLME-SAP Network layer management entity – service access point 36
NPDU Network layer protocol data unit 37
38
NSDU Network service data unit
39
NWK Network 40
OSI Open systems interconnection 41
42
PAN Personal area network
43
PD-SAP Physical layer data – service access point 44
45
PDU Protocol data unit

1
PHY Physical layer 2
PIB Personal area network information base 3
4
PLME-SAP Physical layer management entity – service access point
5
POS Personal operating space 6
QOS Quality of service 7
8
RFD Reduced function device
9
RREP Route reply 10
RREQ Route request 11
12
RN Routing node 13
SAP Service access point 14
SKG Secret key generation 15
16
SKKE Symmetric-key key establishment 17
SSP Security services provider 18
19
SSS Security services specification
20
WPAN Wireless personal area network 21
XML Extensible markup language 22
23
ZB ZigBee
24
ZDO ZigBee device object 25
26
27
1.4 Glossary 28
29
30
1.4.1 Definitions 31
32
1.4.1.1 Conformance Levels 33
34
The conformance level definitions shall follow those in clause 13, section 1 of the
35
IEEE Style Manual [B12].
36
Expected: A key word used to describe the behavior of the hardware or 37
software in the design models assumed by this Specification. Other hardware 38
and software design models may also be implemented. 39
40
May: A key word indicating a course of action permissible within the limits of
41
the standard (may equals is permitted).
42
43
44
45
Chapter 1
Shall: A key word indicating mandatory requirements to be strictly followed in

order to conform to the standard; deviations from shall are prohibited (shall 1
equals is required to). 2
3
Should: A key word indicating that, among several possibilities, one is 4
recommended as particularly suitable, without mentioning or excluding others; 5
that a certain course of action is preferred but not necessarily required; or, that 6
(in the negative form) a certain course of action is deprecated but not prohibited 7
(should equals is recommended that). 8
Reserved Codes: A set of codes that are defined in this specification, but not 9
otherwise used. Future specifications may implement the use of these codes. A 10
product implementing this specification shall not generate these codes. 11
12
Reserved Fields: A set fields that are defined in this specification, but are not 13
otherwise used. Products that implement this specification shall zero these 14
fields and shall make no further assumptions about these fields nor perform 15
processing based on their content. Products that implement future revisions of 16
this specification may set these fields as defined by the specification. 17
ZigBee Protocol Stack: The name of the ZigBee protocol revision governed 18
by this specification. The protocol version sub-field of the frame control field 19
in the NWK header of all ZigBee Protocol Stack frames conforming to this 20
specification shall have a value of 0x02. Frames defined in earlier revision of 21
the ZigBee Protocol Stack specification published in March 2005 employ a 22
value of 0x01. Frames defined in subsequent versions of the specification may 23
set the protocol version sub-field of the frame control field to a value other than 24
0x01 or 0x02. A ZigBee device that conforms to this version of the 25
specification may elect to provide backward compatibility with the 2005 26
revision of the specification. It shall do so by supporting all frame formats and 27
features as specified in that version of the specification and specify this support 28
by using 0x01 as the protocol version when doing so. In addition, the device 29
conforming to this specification may support frame formats and features 30
consistent with this version of the specification and shall, when doing so, 31
specify this support by using 0x02 as the protocol version. All devices in an 32
operating network, regardless of which revisions of the ZigBee specification 33
they support internally, shall, with respect to their external, observable 34
behavior, consistently conform to a single ZigBee protocol version. A single 35
ZigBee network shall not contain devices that conform, in terms of their 36
external behavior, to a multiple ZigBee protocol version. The protocol version 37
of the network to join shall be determined by a backwardly compatible device 38
via examination of the beacon payload prior to deciding to join the network; or, 39
shall be established by the application if the device is a ZigBee coordinator. A 40
ZigBee device conforming to this specification may elect to support only 41
protocol version 0x02, whereby it shall join only networks that advertise 42
ZigBee v1.1 beacon payload support. A ZigBee device shall discard all frames 43
44
45
that carry a protocol version sub-field value other than 0x0 or 0x02, and shall
process only protocol versions of 0x01 or 0x02, consistent with the protocol 1
version of the network that the device participates within. 2
3
Strings and string operations: A string is a sequence of symbols over a 4
specific set (e.g., the binary alphabet {0,1} or the set of all octets). The length 5
of a string is the number of symbols it contains (over the same alphabet). The 6
empty string has length 0. The right-concatenation of two strings x and y of 7
length m and n respectively (notation: x || y), is the string z of length m+n that 8
coincides with x on its leftmost m symbols and with y on its rightmost n 9
symbols. An octet is a symbol string of length 8. In our context, all octets are 10
strings over the binary alphabet. 11
12
1.4.1.2 ZigBee Definitions 13
For the purposes of this standard, the following terms and definitions apply. Terms 14
not defined in this clause can be found in IEEE P802.15.4 §3 [B1] or in ANSI 15
X9.63-2001 §2.1 [B7]. 16
17
Access control list: a table used by a device to determine which devices are 18
authorized to perform a specific function. This table may also store the security 19
material (e.g., cryptographic keys, frame counts, key counts, security level 20
information) used for securely communicating with other devices. 21
Active network key: the key used by a ZigBee device to secure outgoing 22
NWK frames and that is available for use to process incoming NWK frames. 23
24
Alternate network key: a key available for use in lieu of the active Network 25
key to process incoming NWK frames. 26
Application domain: this describes a broad area of applications, such as 27
building automation. 28
29
Application object: a component of the top portion of the application layer 30
defined by the manufacturer that actually implements the application. 31
Application support sub-layer protocol data unit: a unit of data that is 32
exchanged between the application support sub-layers of two peer entities. 33
34
APS command frame: an APS frame that contains neither source nor 35
endpoints. 36
Association: the service provided by the IEEE 802.15.4-2003 MAC sub-layer 37
that is used to establish membership in a network. 38
39
Attribute: a data entity which represents a physical quantity or state. This data 40
is communicated to other devices using commands. 41
Beacon-enabled personal area network: a personal area network containing 42
at least one device that transmits beacon frames at a regular interval. 43
44
45
Chapter 1
Binding: the creation of a unidirectional logical link between a source

endpoint/cluster identifier pair and a destination endpoint, which may exist on 1
one or more devices. 2
3
Broadcast: the transmission of a message to every device within a network. 4
Broadcast jitter: random delay time introduced by a device before relaying a 5
broadcast transaction. 6
7
Broadcast transaction record: a local receipt of a broadcast message that was 8
either initiated or relayed by a device. 9
Broadcast transaction table: collection of broadcast transaction records. 10
11
Cluster: is a container for one or more attributes in a command structure that 12
employs attributes or is synonymous with a message in a command structure 13
that does not employ attributes. As an example, the ZigBee Device Profile 14
defines commands and responses. These are contained in Clusters with the 15
cluster identifiers enumerated for each command and response. Each ZigBee 16
Device Profile message is then defined as a cluster. Alternatively, an 17
application profile may create sub-types within the cluster known as attributes. 18
In this case, the cluster is a collection of attributes specified to accompany a 19
specific cluster identifier (sub-type messages.) 20
Cluster identifier: a reference to an enumeration of clusters within a specific 21
application profile or collection of application profiles. The cluster identifier is 22
a 16-bit number unique within the scope of each application profile and 23
identifies a specific cluster. Conventions may be established across application 24
profiles for common definitions of cluster identifiers whereby each application 25
profile defines a set of cluster identifiers identically. Cluster identifiers are 26
designated as inputs or outputs in the simple descriptor for use in creating a 27
binding table. 28
29
Component: a component consists of a physical object (e.g., switch, 30
controller, etc.) and its corresponding application profile(s). 31
Coordinator: an IEEE 802.15.4-2003 device responsible for associating and 32
disassociating devices into its PAN. A coordinator must be a full function 33
device (FFD). 34
35
Data integrity: assurance that the data has not been modified from its original 36
form. 37
Data key: a key shared between two devices for peer-to-peer data 38
communications. 39
40
Device: any entity that contains an implementation of the ZigBee protocol 41
stack. 42
43
44
45
Device application: a special application that is responsible for Device

operation. The Device Application resides on Endpoint 0 by convention and 1
contains logic to manage the Devices networking and general maintenance 2
features. 3
4
Device description: a description of a specific device within an application 5
profile. For example, the light sensor device description is a member of the 6
home automation application profile. The device description also has a unique 7
identifier that is exchanged as part of the discovery process. 8
Direct addressing: a mode of addressing in which the destination of a frame is 9
completely specified in the frame itself. 10
11
Direct binding: the procedure through which the uppers layers of a device 12
which maintains a binding table in the APS can create or remove a binding link 13
in that binding table. 14
Direct transmission: frame transmission using direct addressing. 15
16
Disassociation: the service provided by the IEEE 802.15.4-2003 MAC sub- 17
layer that is used to discontinue the membership of a device in a network. 18
End application: applications that reside on Endpoints 1 through 240 on a 19
Device. The End Applications implement features that are non-networking and 20
ZigBee protocol related. 21
22
End device binding: the procedure for creating or removing a binding link 23
initiated by each of the end devices that will form the link. The procedure may 24
or may not involve user intervention. 25
Endpoint: a particular component within a unit. Each ZigBee device may 26
support up to 240 such components. 27
28
Endpoint address: the address assigned to an endpoint. This address is 29
assigned in addition to the unique, 64-bit IEEE address and 16-bit network 30
address. 31
Extended PAN ID: The globally unique 64-bit PAN identifier of the network. 32
This identifier should be unique among the PAN overlapping in a given area. 33
This identifier is used to avoid PAN ID conflicts between distinct networks. 34
35
First hop indirect frame: a period in the transit of a frame that has been 36
indirectly addressed when only the source address appears in the frame. 37
Indirect addressing: the ability for resource limited devices to communicate 38
without having to know the address of the desired destination. Indirect 39
transmissions shall include only the source endpoint-addressing field along 40
with the Indirect Addressing bit set in the APDU and are directed to the ZigBee 41
Coordinator by the source. The ZigBee Coordinator is expected to lookup the 42
43
44
45
Chapter 1
source address/endpoint/cluster ID within its binding table and re-issues the

message to each corresponding destination address/endpoint. 1
2
Information base: a collection of variables that define certain behavior in a 3
layer. These variables can be specified or obtained from a layer through its 4
management service. 5
Key establishment: A mechanism that involves the execution of a protocol by 6
two devices to derive a mutually shared secret key. 7
8
Key transport: A mechanism for communicating a key from one device to 9
another device or other devices. 10
Key-transport key: A key used to protect key transport messages. 11
12
Key update: A mechanism implementing the replacement of a key shared 13
amongst two or more devices by means of another key available to that same 14
group. 15
Local coordinator: A ZigBee Coordinator or ZigBee Router, which is the 16
IEEE 802.15.4 coordinator, which processed the association request for a 17
specific End Device. 18
19
Local device: A ZigBee Coordinator, ZigBee Router or ZigBee End Device 20
which issues a ZigBee Device Object request message. The Local device is the 21
client in the message exchange and the message processing description within 22
the ZigBee Device Profile refers to client processing from the perspective of 23
the “Local device”. 24
Link key: A key that is shared between two devices within a PAN. 25
26
Master key: A shared key used during the execution of a symmetric-key key 27
establishment protocol. The master key is the basis for long-term security 28
between the two devices, and may be used to generate link keys. 29
Mesh network: a network in which the routing of messages is performed as a 30
decentralized, cooperative process involving many peer devices routing on 31
each others’ behalf. 32
33
Multihop network: a network, in particular a wireless network, in which there 34
is no guarantee that the transmitter and the receiver of a given message are 35
connected or linked to each other. This implies that intermediate devices must 36
be used as routers. 37
Non-beacon-enabled personal area network: a personal area network that 38
does not contain any devices that transmit beacon frames at a regular interval. 39
40
Neighbor table: a table used by a ZigBee device to keep track of other devices 41
within the POS. 42
43
44
45
Network address: the address assigned to a device by the network layer and
used by the network layer for routing messages between devices. 1
2
Network broadcast delivery time: time duration required by a broadcast 3
transaction to reach every device of a given network. 4
Network protocol data unit: a unit of data that is exchanged between the 5
network layers of two peer entities. 6
7
Network service data unit: Information that is delivered as a unit through a 8
network service access point. 9
Node: a collection of independent device descriptions and applications residing 10
in a single unit and sharing a common 802.15.4 radio. 11
12
Normal operating state: processing which occurs after all startup and 13
initialization processing has occurred and prior to initiation of shutdown 14
processing. 15
NULL: A parameter or variable value that mean unspecified, undefined or 16
unknown. The exact value of NULL is implementation specific, and must not 17
conflict with any other parameters or values. 18
19
Octet: eight bits of data, used as a synonym for a byte. 20
One-way function: A function that is a much easier computation to perform 21
than its inverse. 22
23
Orphaned device: a device that has lost communication contact with or 24
information about the ZigBee device through which it has its PAN 25
membership. 26
PAN coordinator: The principal controller of an IEEE 802.15.4-2003-based 27
network that is responsible for network formation and maintenance. The PAN 28
coordinator must be a full function device (FFD). 29
30
PAN information base: A collection of variables in the IEEE 802.15.4-2003 31
standard that are passed between layers, in order to exchange information. This 32
database may include the access control list, which stores the security material. 33
Personal operating space: the area within reception range of a single device. 34
35
Private method: attributes which are accessible to ZigBee device objects only 36
and unavailable to the end applications. 37
Profile: a collection of device descriptions, which together form a cooperative 38
application. For instance, a thermostat on one node communicates with a 39
furnace on another node. Together, they cooperatively form a heating 40
application profile. 41
42
Protocol data unit: the unit of data that is exchanged between two peer 43
entities. 44
45
Chapter 1
Proxy binding: the procedure through which a device can create or remove a
binding link on the ZigBee coordinator between two devices (none of which 1
may be the device itself). 2
3
Public method: attributes which are accessible to End Applications. 4
Radio: the IEEE 802.15.4-2003 radio that is part of every ZigBee device. 5
6
Remote device: A ZigBee Coordinator, ZigBee Router or ZigBee End Device 7
which receives a ZigBee Device Object request message. The Remote device is 8
the server in the message exchange and the message processing description 9
within the ZigBee Device Profile refers to server processing from the 10
perspective of the “Remote device”. 11
Route discovery: an operation in which a ZigBee coordinator or ZigBee router 12
attempts to discover a route to a remote device by issuing a route request 13
command frame. 14
15
Route discovery table: a table used by a ZigBee coordinator or ZigBee router 16
to store temporary information used during route discovery. 17
Route reply: a ZigBee network layer command frame used to reply to route 18
requests. 19
20
Route request: a ZigBee network layer command frame used to discover paths 21
through the network over which subsequent messages may be delivered. 22
Routing table: a table in which a ZigBee coordinator or ZigBee router stores 23
information required to participate in the routing of frames. 24
25
Service discovery: the ability of a device to locate services of interest. 26
Symmetric-key key establishment: a mechanism by which two parties 27
establish a shared secret, based on a pre-shared secret (a so-called master key). 28
29
Trust center: the device trusted by devices within a ZigBee network to 30
distribute keys for the purpose of network and end-to-end application 31
configuration management. 32
Unicast: the transmission of a message to a single device in a network. 33
34
Unit: a component or collection of components that share a single ZigBee 35
radio. Each unit has a unique 64-bit IEEE address and a 16-bit network address. 36
ZigBee coordinator: an IEEE 802.15.4-2003 PAN coordinator. 37
38
ZigBee device object: the portion of the application layer responsible for 39
defining the role of the device within the network (e.g., ZigBee coordinator or 40
end device), initiating and/or responding to binding and discovery requests and 41
establishing a secure relationship between network devices. 42
43
44
45
ZigBee end device: an IEEE 802.15.4-2003 RFD or FFD participating in a

ZigBee network, which is neither the ZigBee coordinator nor a ZigBee router. 1
2
ZigBee router: an IEEE 802.15.4-2003 FFD participating in a ZigBee 3
network, which is not the ZigBee coordinator but may act as an IEEE 802.15.4- 4
2003 coordinator within its personal operating space, that is capable of routing 5
messages between devices and supporting associations. 6
7
8
1.5 References 9
10
The following standards contain provisions, which, through reference in this 11
document, constitute provisions of this standard. Normative references are given 12
in “ZigBee/IEEE References” and “Normative References” and informative 13
references are given in “Informative References”. At the time of publication, the 14
editions indicated were valid. All standards are subject to revision, and parties to 15
agreements based on this standard are encouraged to investigate the possibility of 16
applying the most recent editions of the references, as indicated in this sub-clause. 17
18
1.5.1 ZigBee/IEEE References 19
20
[B1] Institute of Electrical and Electronics Engineers, Inc., IEEE Std. 802.15.4- 21
2003, IEEE Standard for Information Technology — telecommunications and 22
Information Exchange between Systems — Local and Metropolitan Area 23
Networks — Specific Requirements — Part 15.4: Wireless Medium Access 24
Control (MAC) and Physical Layer (PHY) Specifications for Low Rate 25
Wireless Personal Area Networks (WPANs). New York: IEEE Press. 2003. 26
27
[B2] IEEE 754-1985, IEEE Standard for Binary Floating-Point Arithmetic, 28
IEEE, 1985. 29
[B3] Document 03285r0: Suggestions for the Improvement of the IEEE 30
802.15.4 Standard, July 2003. 31
32
[B4] Document 02055r4: Network Requirements Definition, August 2003. 33
34
1.5.2 Normative References 35
36
[B5] ISO/IEC 639-1:2002 Codes for the representation of names of languages 37
— Part 1: Alpha-2 code. 38
39
[B6] ISO/IEC 646:199 Information technology — ISO 7-bit coded character 40
set for information interchange. 41
[B7] ANSI X9.63-2001, Public Key Cryptography for the Financial Services 42
Industry - Key Agreement and Key Transport Using Elliptic Curve 43
44
45
Chapter 1
Cryptography, American Bankers Association, November 20, 2001. Available

from http://www.ansi.org. 1
2
[B8] FIPS Pub 197, Advanced Encryption Standard (AES), Federal 3
Information Processing Standards Publication 197, US Department of 4
Commerce/N.I.S.T, Springfield, Virginia, November 26, 2001. Available from 5
http://csrc.nist.gov/. 6
[B9] FIPS Pub 198, The Keyed-Hash Message Authentication Code (HMAC), 7
Federal Information Processing Standards Publication 198, US Department of 8
Commerce/N.I.S.T., Springfield, Virginia, March 6, 2002. Available from 9
http://csrc.nist.gov/. 10
11
[B10] ISO/IEC 9798-2, Information Technology - Security Techniques — 12
Entity Authentication Mechanisms — Part 2: Mechanisms Using Symmetric 13
Encipherment Algorithms, International Standardization Organization, 14
Geneva, Switzerland, 1994 (first edition). Available from http://www.iso.org/. 15
[B11] NIST Pub 800-38A 2001 ED, Recommendation for Block Cipher Modes 16
of Operation — Methods and Techniques, NIST Special Publication 800-38A, 17
2001 Edition, US Department of Commerce/N.I.S.T., December 2001. 18
Available from http://csrc.nist.gov/. 19
20
21
1.5.3 Informative References 22
23
[B12] FIPS Pub 140-2, Security requirements for Cryptographic Modules, US 24
Department of Commerce/N.I.S.T., Springfield, Virginia, June 2001 25
(supersedes FIPS Pub 140-1). Available from http://csrc.nist.gov/. 26
[B13] IEEE Standards Style Manual, published and distributed in May 2000 27
and revised on September 20, 2001. Available from http://standards.ieee.org/ 28
guides/style/. 29
30
[B14] ISO/IEC 7498-1:1994 Information technology — Open systems 31
interconnection — Basic reference model: The basic model. 32
[B15] ISO/IEC 10731:1994, Information technology — Open Systems 33
Interconnection — Conventions for the definition of OSI services. 34
35
[B16] ISO/IEC 9646-1:1991, Information technology — Open systems 36
Interconnection — Conformance testing methodology and framework — Part 37
1: General concepts. 38
[B17] ISO/IEC 9646-7:1995, Information technology — Open Systems 39
Interconnection — Conformance testing methodology and framework — Part 40
7. Implementation conformance statements. 41
42
[B18] A.J. Menezes, P.C. van Oorschot, S.A. Vanstone, Handbook of Applied 43
Cryptography, Boca Raton: CRC Press, 1997. 44
45
[B19] FIPS Pub 113, Computer Data Authentication, Federal Information

Processing Standard Publication 113, US Department of Commerce/N.I.S.T., 1
May 30, 1985. Available from http://csrc.nist.gov/. 2
3
[B20] R. Housley, D. Whiting, N. Ferguson, Counter with CBC-MAC (CCM), 4
submitted to N.I.S.T., June 3, 2002. Available from http://csrc.nist.gov/ 5
encryption/modules/proposedmodes/. 6
[B21] J. Jonsson, On the Security of CTR + CBC-MAC, in Proceedings of 7
Selected Areas in Cryptography — SAC 2002, K. Nyberg, H. Heys, Eds., 8
Lecture Notes in Computer Science, Vol. 2595, pp. 76-93, Berlin: Springer, 9
2002. 10
11
[B22] J. Jonsson, On the Security of CTR + CBC-MAC, NIST Mode of 12
Operation — Additional CCM Documentation. Available from http:// 13
csrc.nist.gov/encryption/modes/proposedmodes/. 14
[B23] P. Rogaway, D. Wagner, A Critique of CCM, IACR ePrint Archive 15
2003-070, April 13, 2003. 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
Chapter 1
1
2
3
4
5
6
7
8
9
10
11
12
13
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
C H A P T E R
1
2
2
3
4
5
6
7
8
9
CHAPTER 2APPLICATION LAYER SPECIFICATION 10

11
12
13
2.1 General Description 14
15
The ZigBee stack architecture includes a number of layered components including 16
the IEEE 802.15.4 2003 Medium Access Control (MAC) layer, Physical (PHY) 17
layer and the ZigBee Network (NWK) layer. Each component provides an 18
application with its own set of services and capabilities. Although this chapter 19
may refer to other components within the ZigBee stack architecture, its primary 20
purpose is to describe the component labeled Application (APL) Layer shown in 21
Figure 1.1 of “ZigBee Protocol Overview”. 22
23
As shown in Figure 1.1, the ZigBee application layer consists of the APS sub- 24
layer, the ZDO (containing the ZDO management plane), and the manufacturer- 25
defined application objects. 26
The responsibilities of the APS sub-layer include: 27
28
• Maintaining tables for binding, that is, the ability to match two devices together 29
based on their services and their needs 30
• Forwarding messages between bound devices 31
32
• Group address definition, removal and filtering of group addressed messages 33
• Address mapping from 64 bit IEEE addresses to and from 16 bit NWK 34
addresses 35
36
• Fragmentation, reassembly and reliable data transport 37
The responsibilities of the ZDO include: 38
39
• Defining the role of the device within the network (e.g., ZigBee coordinator or 40
end device) 41
• Discovering devices on the network and determining which application 42
services they provide 43
44
45
Chapter 2
20 Application Layer Specification
• Initiating and/or responding to binding requests

1
• Establishing a secure relationship between network devices 2
3
2.1.1 Application Support Sub-Layer 4
5
The application support sub-layer (APS) provides an interface between the 6
network layer (NWK) and the application layer (APL) through a general set of 7
services that are used by both the ZDO and the manufacturer-defined application 8
objects. The services are provided by two entities: 9
10
• The APS data entity (APSDE) through the APSDE service access point 11
(APSDE-SAP) 12
• The APS management entity (APSME) through the APSME service access 13
point (APSME-SAP). 14
15
The APSDE provides the data transmission service for the transport of application 16
PDUs between two or more devices located on the same network including 17
filtering of group addressed messages. The APSDE also support fragmentation 18
and reassembly of packets larger than the supported data payload of the APSDU 19
and reliable data transport. 20
The APSME provides security services, binding of devices, establishment and 21
removal of group addresses and also maintains a database of managed objects, 22
known as the APS information base (AIB). The AIB supports addressing mapping 23
between 64 bit IEEE addresses and 16 bit NWK addresses. 24
25
26
2.1.2 Application Framework 27
28
The application framework in ZigBee is the environment in which application 29
objects are hosted on ZigBee devices. Inside the application framework, the 30
application objects send and receive data through the APSDE-SAP. The 31
application objects perform the following functions through the ZDO public 32
interfaces (see clause 2.5): 33
• Control and management of the protocol layers in the ZigBee device 34
35
• Initiation of standard network functions 36
The data service, provided by APSDE-SAP, includes request, confirm, response 37
and indication primitives for data transfer. The request primitive supports data 38
transfers between peer application object entities. The confirm primitive reports 39
the results of a request primitive call. The indication primitive is used to indicate 40
the transfer of data from the APS to the destination application object entity. 41
42
Up to 240 distinct application objects can be defined, each interfacing on an 43
endpoint indexed from 1 to 240. Two additional endpoints are defined for 44
45
APSDE-SAP usage: endpoint 0 is reserved for the data interface to the ZDO and
endpoint 255 is reserved for the data interface function to broadcast data to all 1
application objects. Endpoints 241-254 are reserved for future use. 2
3
4
2.1.3 Addressing 5
6
2.1.3.1 Node Addressing 7
8
In Figure 2.1, there are two nodes, each containing a single radio. One node
9
contains two switches and the other contains four lamps.
10
11
12
13
Lamps 14
Radio
1 2 3 4 15
16
17
18
19
20
Radio
21
22
23
24
Switch 1 25
26
27
Switch 2 28
29
30
31
32
Figure 2.1 Multiple Subunits in a Single Node 33
34
A node contains one or more device descriptions and has a single IEEE 802.15.4 35
radio. In Figure 2.1, the individual parts of the nodes (the switches and lamps) are 36
subunits containing one device description in each subunit. Each node is given an 37
address when it joins the ZigBee network. 38
39
2.1.3.2 Endpoint Addressing 40
41
In Figure 2.1, it is required that switch 1 should control lamps 1, 2 and 3, while 42
switch 2 should control only lamp 4. However, as the only addressable component 43
44
45
Chapter 2
is the radio, it is not possible to identify or address the individual subunits, so it

would not be possible for switch 2 to turn on lamp 4 only. 1
2
ZigBee provides another level of sub-addressing, which is used in conjunction 3
with the mechanisms of IEEE802.15.4. An endpoint number can be used to 4
identify individual switches and lamps. For instance, in the example above, switch 5
1 could use endpoint 3, while switch 2 could use endpoint 21. Similarly, the lamps 6
will each have their own endpoints. Endpoint 0 is reserved for device 7
management and is used to address the descriptors in the node. Each identifiable 8
subunit in a node (such as the switches and lamps) is assigned its own specific 9
endpoint in the range 1-240. 10
Physical devices are described in terms of the data attributes that they contain. For 11
instance, a thermostat might contain an output attribute “temperature” which 12
represents the current temperature of a room. A furnace controller may take this 13
attribute as an input and control the furnace according to the temperature value 14
received from the thermostat. These two physical devices, including their 15
attributes, would be described in the relevant device descriptions for those 16
devices. 17
18
The simple room thermostat described has temperature-sensing circuitry, which 19
can be queried by the external furnace controller. It advertises its service on an 20
endpoint and the service is described in the simple description implemented on 21
that endpoint. 22
A more complex version of the thermostat may also have an optional “heartbeat” 23
report timer, which causes the device to report current room temperature after a 24
set period. In this example, the ReportTime attribute specifies when reports are to 25
be sent and writing a suitable time value to this attribute sets the frequency of 26
these temperature reports. This implementation would advertise its services (in a 27
list of cluster identifiers) on a different endpoint. 28
29
In order to allow product differentiation in the marketplace, manufacturers may 30
add clusters containing extra attributes of their own in the context of one or more 31
private profiles. These manufacturer-specific clusters do not form part of this or 32
any other ZigBee specification and interoperability is not guaranteed for these 33
clusters. Such services would be advertised on different endpoints from those 34
described above. 35
36
2.1.4 Application Communication Fundamentals 37
38
2.1.4.1 Application Profiles 39
40
Application profiles are agreements for messages, message formats and 41
processing actions that enable applications to create an interoperable, distributed 42
application between applications that reside on separate devices. These 43
application profiles enable applications to send commands, request data and 44
45
process commands and requests. For instance, a thermostat on one node can
communicate with a furnace on another node. Together, they cooperatively form a 1
heating application profile. ZigBee vendors develop application profiles to 2
provide solutions to specific technology needs. 3
4
Application profiles are simultaneously a means of unifying interoperable 5
technical solutions within the ZigBee standard, as well as focusing usability 6
efforts within a given marketing area. For example, it is expected that vendors of 7
lighting equipment will want to provide ZigBee profiles that interoperate with 8
several varieties of lighting types or controller types. Additional information on 9
profiles is provided in clause 2.2 of this document. 10
11
2.1.4.2 Clusters 12
Clusters are identified by a cluster identifier, which is associated with data 13
flowing out of, or into, the device. Cluster identifiers are unique within the scope 14
of a particular profile. Binding decisions are taken by matching an output cluster 15
identifier to an input cluster identifier, assuming both are within the same profile. 16
In the thermostat example above, binding takes place on temperature, between a 17
device with a temperature cluster identifier as output and a device with a 18
temperature cluster identifier as input. The binding table contains the identifier for 19
temperature along with the address of the source and destination devices. 20
21
22
2.1.5 Discovery 23
24
2.1.5.1 Device Discovery 25
26
Device discovery is the process whereby a ZigBee device can discover other 27
ZigBee devices by initiating queries that are broadcast (of any broadcast address 28
type) or unicast addressed. There are two forms of device discover requests: IEEE 29
address requests and NWK address requests. The IEEE address request is unicast 30
and assumes the NWK address is known. The NWK address request is broadcast 31
to all RxOnWhenIdle devices and carries the known IEEE address as data 32
payload. 33
Responses to the broadcast or unicast device discovery messages vary by logical 34
device type as follows: 35
36
• ZigBee end device: responds to the device discovery query by sending its IEEE 37
or NWK address (depending on the request). 38
• ZigBee coordinator device: responds to the query by sending its IEEE or NWK 39
addresses and the NWK addresses of all devices that are associated with the 40
ZigBee coordinator (depending on the request). 41
42
43
44
45
Chapter 2
• ZigBee router device: responds to the query by sending its IEEE or NWK
addresses and the NWK addresses of all devices that are associated with the 1
ZigBee router (depending on the request). 2
3
A description of the procedure details, primitive calls, and applicable parameters 4
is given in clause 2.4. 5
Discovery information may also be cached within the devices in the network 6
designated as the Primary Discovery Cache device. The protocol for identifying 7
these devices, requesting storage on them, and uploading discovery information is 8
supplied in clause 1.5. The mechanics of this type of proxy discovery are as 9
follows: 10
11
1 Discovery requests utilizing broadcast messaging are processed by discovery 12
cache devices or the target devices themselves and those devices respond either 13
on behalf of device information held in the cache or from their local descriptor 14
information. 15
2 For unicast discovery requests, the request is directed either to the destination 16
network address of the discovery cache or the device of interest and the 17
network address of interest field is filled in to reflect the target of the discovery 18
request. 19
20
3 A discovery command is also provided to enable a device to locate where 21
discovery information can be obtained for a specified network address. The 22
location of the discovery information can either be the device itself or a 23
discovery cache device. 24
25
2.1.5.2 Service Discovery 26
Service discovery is the process whereby services available on endpoints at the 27
receiving device are discovered by external devices. Service discovery can be 28
accomplished by issuing a query for each endpoint on a given device or by using a 29
match service feature (either broadcast or unicast). Service discovery utilizes the 30
complex, user, node or power descriptors plus the simple descriptor further 31
addressed by the endpoint (for the connected application object). 32
33
The service discovery process in ZigBee is key to interfacing devices within the 34
network. Through specific requests for descriptors on specified nodes, broadcast 35
requests for service matching and the ability to ask a device which endpoints 36
support application objects, a range of options are available for commissioning 37
tools and applications. See clause 2.4 for details on service discovery. 38
Service discovery information may also be cached in the network within the 39
Primary discovery cache device. The protocol for identifying these devices, 40
requesting storage on them, and uploading discovery information is supplied in 41
Sub-clause 2.5.2.1. The mechanics of this type of proxy discovery are the same as 42
those described in Sub-clause 2.5.2.1 for device discovery. 43
44
45
2.1.6 Binding 1
2
In ZigBee, there is an application level concept using cluster identifiers (and the
3
attributes contained in them) on the individual endpoints or group addresses in
4
different nodes. This is referred to as binding – the creation of logical links
5
between complementary application devices and endpoints or group addresses In
6
the example of sub-clause 2.1.3.2, a binding could be made between thermostat
7
and the furnace controller. In Figure 2.2, switch 1 is bound with lamps 1-3, while
8
switch 2 is bound with lamp 4 only.
9
The information about which cluster is bound between nodes is stored in a binding 10
table. This is described fully in sub-clause 2.1.6 and is illustrated in Figure 2.2. 11
12
13
14
Radio Lamps 15
Z2 1 2 3 4 16
EP5 EP7 EP8 EP17
17
18
19
20
21
Radio 22
Z1
23
Binding Table
24
Switch 1 25
EP3 26
27
Switch 2 28
EP21 29
30
31
Figure 2.2 ZigBee Binding and the Binding Table 32
33
The use of a list of three entries in the binding table for switch 1 allows it to 34
control three lamps, which could also be in separate nodes (with their own ZigBee 35
radios). It is also possible for one lamp to be controlled by several switches: in this 36
case there would be entries for each switch, all linked to the same lamp. 37
38
As an alternative, the endpoints describing the three lamps could have been 39
assigned to a single group address in which case a single binding entry could be 40
used. The choice of creating separate binding entries for individual destination 41
application devices and endpoints or grouping the destination devices and 42
endpoints into a single group address is left to the application. 43
44
45
Chapter 2
Binding is always performed after a communications link has been established.

Once a link has been established, the implementation decides whether a new node 1
should be part of the network. This will depend on the security in operation for the 2
application and how it is implemented. Binding is only allowed if the 3
implemented security on all devices allows this (see Chapter 4). 4
5
The binding table is implemented in the source device of the binding pair or 6
within a device designated as the binding table cache. The message reflection 7
feature employs the binding table and can be deployed either on the source device 8
or in the ZigBee coordinator. Some applications may need a duplicate of the 9
binding table to be available in the event that the device storing the table fails. 10
Backup of the binding table, and any other key ZigBee coordinator data, is the 11
responsibility of application software, using ZDO primitives. 12
The details of the creation of binding links is covered in the ZigBee device profile 13
(see clause 2.4). 14
15
16
2.1.7 Messaging 17
18
2.1.7.1 Direct Addressing 19
20
Once devices have been associated, commands can be sent from one device to
21
another. A command is sent to an application object at the destination address
22
(radio address plus its endpoint). Details of the commands can be found in 2.1.3.
23
Note that binding is not a pre-requisite for using direct addressing.
24
Direct addressing assumes device discovery and service discovery have identified 25
a particular device and endpoint, which supply a complementary service to the 26
requestor. Specifically, direct addressing defines a means of directing messages to 27
the device by including its full address and endpoint information. 28
29
2.1.7.2 Indirect Addressing 30
31
Use of direct addressing requires the controlling device to have knowledge of the 32
following attributes of the target device it will communicate with: 33
• Address 34
35
• Endpoint 36
• Cluster identifier 37
38
Information about these attributes must be committed to a binding table on the 39
ZigBee coordinator for message reflection, prior to the creation of an indirectly 40
addressed message between the device pair. 41
A full IEEE 802.15.4 address amounts to 10 octets (PAN identifier plus 64-bit 42
IEEE address) and a further octet is required for the endpoint. Extremely simple 43
devices, such as battery-powered switches, may not want the overhead of storing 44
45
this information, nor the software for acquiring this information. For these
devices, indirect addressing will be more appropriate. 1
2
When a source device wishes to send a command to a destination using indirect 3
addressing, instead of including the address of the destination device (which it 4
does not know and has not stored), it omits the address and specifies indirect 5
addressing via the APSDE-SAP. The included source address, source endpoint 6
and cluster identifier in the indirect addressed message are translated via the 7
binding table to those of the destination device(s) and the messages are relayed to 8
each indicated destination. 9
Where a cluster contains several attributes, the cluster identifier is used for 10
addressing and the attribute identifier is used in the command itself to identify a 11
particular attribute within the cluster. The applications, however, can parse and 12
utilize the attributes as defined within their profile. 13
14
2.1.7.3 Broadcast Addressing 15
16
An application may broadcast messages to all endpoints on a given destination 17
device. This form of broadcast addressing is called application broadcast. The 18
destination address shall be one of the 16-bit network broadcast addresses and the 19
broadcast flag shall be set in the APS frame control field. The source shall include 20
the cluster identifier, profile identifier and source endpoint fields in the APS frame 21
(see sub-clause 2.2.5). 22
23
2.1.7.4 Group Addressing 24
An application may designate a collection of devices and specific endpoints on 25
those devices to a single group address. The group address may then be used to 26
direct outgoing clusters (and the attributes contained in them) to each of the 27
devices and endpoints assigned to the group. The destination address shall be a 28
16-bit group address and the group address flag shall be set in the APS frame 29
control field. The source shall include the cluster identifier, profile identifier and 30
source endpoint fields in the APS frame. 31
32
33
2.1.8 ZigBee Device Objects 34
35
The ZigBee device objects (ZDO), represents a base class of functionality that 36
provides an interface between the application objects, the device profile and the 37
APS. The ZDO is located between the application framework and the application 38
support sub-layer. It satisfies common requirements of all applications operating 39
in a ZigBee protocol stack. The ZDO is responsible for the following: 40
• Initializing the application support sub-layer (APS), the network layer (NWK), 41
the Security Service Provider. 42
43
44
45
Chapter 2
• Assembling configuration information from the end applications to determine

and implement discovery, security management, network management, and 1
binding management. 2
3
The ZDO presents public interfaces to the application objects in the application 4
framework layer for control of device and network functions by the application 5
objects. The ZDO interfaces to the lower portions of the ZigBee protocol stack, on 6
endpoint 0, through the APSDE-SAP for data and through the APSME-SAP for 7
control messages. The public interface provides address management of the 8
device, discovery, binding, and security functions within the application 9
framework layer of the ZigBee protocol stack. These services are described in the 10
following sub-clauses. The ZDO is fully described in clause 2.5. 11
12
2.1.8.1 Discovery Management 13
Discovery management is provided to the application objects whereby, when 14
queried, the IEEE address or Network Address of the requested device shall be 15
returned (if the device is a ZigBee end device), along with the device addresses of 16
all associated devices (if the device is a ZigBee coordinator or router). This is 17
referred to as device discovery, and is used for the discovery of ZigBee devices. 18
19
In addition to device discovery, service discovery is also provided to determine 20
what services are offered on each endpoint, defined in a device, by the respective 21
application objects. A device can discover active endpoints on individual devices 22
or all devices and a device can discover specific services that match a given 23
criteria (profile identifiers and cluster identifiers). 24
25
2.1.8.2 Binding Management 26
Binding management is provided to the application objects in order to bind 27
application objects on ZigBee devices to each other for clear and concise 28
connections through all layers of the protocol stack and though the various 29
connections provided by the ZigBee network nodes. Binding tables are 30
constructed and populated according to the binding calls and results. End device 31
bind, bind and unbind commands between devices is supported via the ZigBee 32
device profile. 33
34
2.1.8.3 Security Management 35
36
Security management is provided to the application objects for enabling or 37
disabling the security portion of the system. If enabled, key management is 38
performed for master keys, network keys, and the means to establish a link key. 39
Primitives are defined in Chapter 4 to permit key establishment, key transport and 40
authentication. 41
42
43
44
45
2.2 ZigBee Application Support (APS) Sub-Layer 1

2
2.2.1 Scope 3
4
This clause specifies the portion of the application layer providing the service 5
specification and interface to both the manufacturer-defined application objects 6
and the ZigBee device objects. The specification defines a data service to allow 7
the application objects to transport data and a management service providing 8
mechanisms for binding. In addition, it also defines the application support sub- 9
layer frame format and frame-type specifications. 10
11
12
2.2.2 Purpose 13
14
The purpose of this clause is to define the functionality of the ZigBee application 15
support (APS) sub-layer. This functionality is based on both the driver 16
functionality necessary to enable correct operation of the ZigBee network layer 17
and the functionality required by the manufacturer-defined application objects. 18
19
2.2.3 Application Support (APS) Sub-Layer Overview 20
21
The application support sub-layer provides the interface between the network 22
layer and the application layer through a general set of services for use by both the 23
ZigBee device object (ZDO) and the manufacturer-defined application objects. 24
These services are offered via two entities: the data service and the management 25
service. The APS data entity (APSDE) provides the data transmission service via 26
its associated SAP, the APSDE-SAP. The APS management entity (APSME) 27
provides the management service via its associated SAP, the APSME-SAP, and 28
maintains a database of managed objects known as the APS information base 29
(AIB). 30
31
2.2.3.1 Application Support Sub-Layer Data Entity (APSDE) 32
33
The APSDE shall provide a data service to the network layer and both the ZDO 34
and the application objects to enable the transport of application PDUs between 35
two or more devices. The devices themselves must be located on the same 36
network. 37
38
The APSDE will provide the following services:
39
• Generation of the Application level PDU (APDU): The APSDE shall take an 40
application PDU and generate an APS PDU by adding the appropriate protocol 41
overhead. 42
43
44
45
Chapter 2
• Binding: This is the ability to match two devices together based on their
services and their needs. Once two devices are bound, the APSDE shall be able 1
to transfer a message received from one bound device over to the second 2
device. 3
4
• Group Address Filtering: This provides the ability to filter group addressed 5
messages based on whether the device is a member of the group or not. 6
• Reliable transport: This increases the reliability of transactions above that 7
available from the NWK layer alone by employing end-to-end retries. 8
9
• Duplicate rejection: Messages offered for transmission will not be received 10
more than once. 11
12
2.2.3.2 Application Support Sub-Layer Management Entity 13
(APSME) 14
15
The APSME shall provide a management service to allow an application to 16
interact with the stack. 17
The APSME shall provide the ability to match two devices together based on their 18
services and their needs. This service is called the binding service and the APSME 19
shall be able to construct and maintain a table to store this information. 20
21
In addition, the APSME will provide the following services: 22
• AIB Management: The ability to get and set attributes in the device’s AIB. 23
24
• Security: The ability to set up authentic relationships with other devices 25
through the use of secure keys. 26
• Group Management: This provides the ability to declare a single address 27
shared by multiple devices, to add devices to the group, and to remove devices 28
from the group. 29
30
31
2.2.4 Service Specification 32
33
The APS sub-layer provides an interface between a next higher layer entity 34
(NHLE) and the NWK layer. The APS sub-layer conceptually includes a 35
management entity called the APS sub-layer management entity (APSME). This 36
entity provides the service interfaces through which sub-layer management 37
functions may be invoked. The APSME is also responsible for maintaining a 38
database of managed objects pertaining to the APS sub-layer. This database is 39
referred to as the APS sub-layer information base (AIB). Figure 2.3 depicts the 40
components and interfaces of the APS sub-layer. 41
42
43
44
45
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.3 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 NLME-SAP interfaces (see sub-clause 3.2). In addition to these 25
external interfaces, there is also an implicit interface between the APSME and the 26
APSDE that allows the APSME to use the APS data service. 27
28
2.2.4.1 APS Data Service 29
30
The APS sub-layer data entity SAP (APSDE-SAP) supports the transport of 31
application protocol data units between peer application entities. Table 2.1 lists 32
the primitives supported by the APSDE-SAP. Each of these primitives will be 33
discussed in the following subclauses. 34
Table 2.1 APSDE-SAP Primitives 35
36
APSDE-
SAP 37
Primitive Request Confirm Indication 38
39
APSDE- 2.2.4.1.1 2.2.4.1.2 2.2.4.1.3 40
DATA
41
42
43
44
45
Chapter 2
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 a single peer NHLE entity. 3
4
2.2.4.1.1.1 Semantics of the Service Primitive 5
6
This 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
asduLength, 16
asdu, 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
Table 2.2 specifies the parameters for the APSDE-DATA.request primitive.

1
Table 2.2 APSDE-DATA.request Parameters
2
Name Type Valid Range Description 3
4
DstAddrMode Integer 0x00 – 0xff The addressing mode for the source address 5
used in this primitive and of the APDU to be
transferred. This parameter can take one of 6
the non-reserved values from the following 7
list: 8
0x00 = DstAddress and DstEndpoint not 9
present 10
0x01 = 16-bit group address for DstAddress 11
and DstEndpoint not present 12
0x02 = 16-bit address for DstAddress and 13
DstEndpoint present 14
0x03 = 64-bit extended address for 15
DstAddress and DstEndpoint present 16
0x04 – 0xff = reserved 17
DstAddress Address As specified by The individual device address or group 18
the DstAddrMode address of the entity to which the ASDU is 19
parameter being transferred 20
DstEndpoint Integer 0x00 – 0xff This parameter shall be present if, and only 21
if, the DstAddrMode parameter has a value 22
of 0x02 or 0x03 and, if present, shall be 23
either the number of the individual endpoint 24
or the broadcast endpoint (0xff) of the entity 25
to which the ASDU is being transferred
26
ProfileId Integer 0x0000 – 0xffff The identifier of the profile for which this 27
frame is intended 28
ClusterId Integer 0x0000 – 0xffff The identifier of the object to use in the 29
binding operation if the frame is to be sent 30
using indirect addressing; If indirect 31
addressing is not being used, this parameter
32
is ignored
33
SrcEndpoint Integer 0x00 – 0xfe The individual endpoint of the entity from 34
which the ASDU is being transferred
35
asduLength Integer The number of octets comprising the ASDU 36
to be transferred 37
38
39
40
41
42
43
44
45
Chapter 2
Table 2.2 APSDE-DATA.request Parameters

1
Asdu Set of - The set of octets comprising the ASDU to be 3
octets transferred 4
5
TxOptions Bitmap 0000 0xxx The transmission options for the ASDU to be
transferred. These are a bitwise OR of one or 6
(Where x can be 0 more of the following: 7
or 1) 8
0x01 = Security enabled transmission
9
0x02 = Use NWK key
10
0x04 = Acknowledged transmission
11
Radius Unsigned 0x00-0xff The distance, in hops, that a transmitted 12
Integer frame will be allowed to travel through the 13
network
14
15
2.2.4.1.1.2 When Generated 16
17
This primitive is generated by a local NHLE whenever a data PDU (ASDU) is to
18
be transferred to a peer NHLE.
19
20
2.2.4.1.1.3 Effect on Receipt
21
On receipt of this primitive the APS sub-layer entity begins the transmission of 22
the supplied ASDU. 23
24
If the DstAddrMode parameter is set to 0x00, the DstAddress and DstEndpoint 25
parameters are ignored and the value of the DstEndpoint parameter is not placed 26
in the resulting APDU; this option allows indirect addressing to be used. If the 27
DstAddrMode parameter is set to 0x02, the DstAddress parameter contains an 28
extended 64-bit IEEE address and must first be mapped to a corresponding 16-bit 29
NWK address by using the apsAddressMap attribute of the APS IB (see 30
Table 2.23). If a corresponding 16-bit NWK address could not be found, the 31
APSDE issues the APSDE-DATA.confirm primitive with a status of 32
NO_SHORT_ADDRESS. If a corresponding 16-bit NWK address is found, it will 33
be used in the invocation of the NLDE-DATA.request primitive and the value of 34
the DstEndpoint parameter will be placed in the resulting APDU. If the 35
DstAddrMode parameter has a value of 0x01, indicating group addressing, the 36
DstAddress parameter will be interpreted as a 16-bit group address. This address 37
will be placed in the group address field of the APS header, the DstEndpoint 38
parameter will be ignored and the destination endpoint field will be omitted from 39
the APS header. The delivery mode subfield of the frame control field of the APS 40
header shall have a value of 0x03 in this case. 41
If the DstAddrMode parameter is set to 0x02, the DstAddress parameter contains 42
a 16-bit NWK address and the DstEndpoint parameter is supplied. The next 43
higher layer should only employ DstAddrMode of 0x02 in cases where the 44
45
destination NWK address is employed for immediate application responses and

the NWK address is not retained for later data transmission requests. 1
2
The application may limit the number of hops a transmitted frame is allowed to 3
travel through the network by using the RadiusCounter parameter. If the 4
RadiusCounter parameter is set to 0x00, the network layer will transmit the frame 5
with no restriction in the network. If the RadiusCounter parameter is not set to 6
zero, the network layer will allow the frame transmission to exist in the network 7
for at most that many hops. 8
If the APDU to be transmitted using direct addressing, the APSDE transmits the 9
constructed frame by issuing the NLDE-DATA.request primitive to the NWK 10
layer. On receipt of the NLDE-DATA.confirm primitive, the APSDE issues the 11
APSDE-DATA.confirm primitive (see sub-clause 2.2.4.1.2) with a status equal to 12
that received from the NWK layer. 13
14
If the APDU to be transmitted using indirect addressing (the use of indirect 15
addressing is specified in the delivery mode sub-field) and this primitive was 16
received by the APSDE of a device supporting a binding table, a search is made in 17
the binding table with the endpoint and cluster identifiers specified in the 18
SrcEndpoint and ClusterId parameters, respectively, for associated binding table 19
entries. 20
If no binding table entries are found, the APSDE issues the APSDE- 21
DATA.confirm primitive with a status of NO_BOUND_DEVICE. If one or more 22
binding table entries are found, the APSDE constructs the APDU with the 23
endpoint information from the binding table entry, if present, and transmits the 24
frame by issuing the NLDE-DATA.request primitive to the NWK layer using the 25
address information from the binding table entry. On receipt of the corresponding 26
NLDE-DATA.confirm, the APSDE constructs and transmits the APDU for the 27
next binding table entry, as described above; until no more binding table entries 28
remain. On receipt of the initial request, the APSDE issues the APSDE- 29
DATA.confirm primitive with a status of SUCCESS to the originator indicating 30
that the message will be reflected to each binding table entry corresponding to the 31
address of this device and the specified endpoint and cluster identifiers. 32
33
If the APDU to be transmitted using indirect addressing and this primitive was 34
received by the APSDE of a device that does not support a binding table, the 35
APSDE constructs the APDU, without a destination endpoint field, and issues the 36
NLDE-DATA.request primitive to the NWK layer using the address of the ZigBee 37
coordinator. On receipt of the NLDE-DATA.confirm primitive, the APSDE issues 38
the APSDE-DATA.confirm primitive with a status equal to that received from the 39
NWK layer. 40
If the DstAddrMode parameter has a value of 0x01, indicating group addressing, 41
then the frame will be transmitted as a broadcast. A value of 0xffff, that is, the 42
43
44
45
Chapter 2
broadcast to all devices address, will be supplied for the DstAddr parameter of the
NLDE-DATA.request that is used to transmit the frame. 1
2
If the TxOptions parameter specifies that secured transmission is required, the 3
APS sub-layer shall use the security service provider (see sub-clause 4.2.4) to 4
secure the ASDU. If the security processing fails, the APSDE shall issue the 5
APSDE-DATA.confirm primitive with a status of SECURITY_FAIL. 6
The APSDE will ensure that route discovery is always enabled at the network 7
layer by setting the DiscoverRoute parameter of the NLDE-DATA.request 8
primitive to 0x01, each time it is issued. 9
10
If the ASDU to be transmitted is larger than will fit in a single frame then the 11
ASDU is not transmitted and the APSDE shall issue the APSDE-DATA.confirm 12
primitive with a status of INVALID_REQUEST. 13
2.2.4.1.2 APSDE-DATA.confirm 14
15
This primitive reports the results of a request to transfer a data PDU (ASDU) from 16
a local NHLE to a single peer NHLE. 17
18
20
This semantics of this primitive are as follows:
21
APSDE-DATA.confirm { 22
DstAddrMode, 23
DstAddress, 24
DstEndpoint, 25
SrcEndpoint,
26
27
Status
28
}
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Table 2.3 specifies the parameters for the APSDE-DATA.confirm primitive.

1
Table 2.3 APSDE-DATA.confirm Parameters
2
4
DstAddrMode Integer 0x00 – 0xff The addressing mode for the 5
source address used in this
primitive and of the APDU to be 6
transferred. This parameter can 7
take one of the non-reserved 8
values from the following list: 9
0x00 = DstAddress and 10
DstEndpoint not present 11
0x01 = 16-bit group address for 12
DstAddress and DstEndpoint not 13
present 14
0x02 = 16-bit address for 15
DstAddress and DstEndpoint 16
present
17
0x03= 64-bit extended address for
DstAddress and DstEndpoint
18
present 19
21
DstAddress Address As specified by the The individual device address or 22
DstAddrMode parameter group address of the entity to
which the ASDU is being 23
transferred 24
25
DstEndpoint Integer 0x00 – 0xff This parameter shall be present if,
and only if, the DstAddrMode 26
parameter has a value of 0x02 or 27
0x03 and, if present, shall be the 28
number of the individual endpoint 29
of the entity to which the ASDU is 30
being transferred
31
SrcEndpoint Integer 0x00 – 0xfe The individual endpoint of the 32
entity from which the ASDU is 33
being transferred
34
Status Enumerati SUCCESS, The status of the corresponding 35
on NO_SHORT_ADDRESS , request 36
NO_BOUND_DEVICE,
37
SECURITY_FAIL,
NO_ACK or any status 38
values returned from the 39
NLDE-DATA.confirm 40
primitive 41
42
43
44
45
Chapter 2
2.2.4.1.2.2 When Generated

1
This primitive is generated by the local APS sub-layer entity in response to an 2
APSDE-DATA.request primitive. This primitive returns a status of either 3
SUCCESS, indicating that the request to transmit was successful, or an error code 4
of NO_SHORT_ADDRESS, NO_BOUND_DEVICE or SECURITY_FAIL or 5
any status values returned from the NLDE-DATA.confirm primitive. The reasons 6
for these status values are fully described in 2.2.4.1.2. 7
8
2.2.4.1.2.3 Effect on Receipt 9
10
On receipt of this primitive the next higher layer of the initiating device is notified
11
of the result of its request to transmit. If the transmission attempt was successful,
12
the status parameter will be set to SUCCESS. Otherwise, the status parameter will
13
indicate the error.
14
2.2.4.1.3 APSDE-DATA.indication 15
16
This primitive indicates the transfer of a data PDU (ASDU) from the APS sub- 17
layer to the local application entity. 18
19
This semantics of this primitive are as follows: 21
22
APSDE-DATA.indication { 23
DstAddrMode, 24
DstAddress, 25
DstEndpoint, 26
SrcAddrMode, 27
SrcAddress, 28
SrcEndpoint, 29
ProfileId,
30
31
ClusterId,
32
asduLength,
33
asdu, 34
WasBroadcast, 35
SecurityStatus 36
} 37
38
39
40
41
42
43
44
45
Table 2.4 specifies the parameters for the APSDE-DATA.indication primitive.

1
Table 2.4 APSDE-DATA.indication Parameters
2
4
DstAddrMode Integer 0x00 - 0xff The addressing mode for the destination 5
address used in this primitive and of the
APDU that has been received. This 6
parameter can take one of the non- 7
reserved values from the following list: 8
0x00 = reserved 9
0x01 = 16-bit group address for
10
DstAddress and DstEndpoint not present 11
0x02 = 16-bit address for DstAddress and 12
15
DstAddress Address As specified by The individual device address or group
16
the DstAddrMode address to which the ASDU is directed
parameter 17
18
DstEndpoint Integer 0x00 – 0xff The target endpoint on the local entity
19
from which the ASDU has been received
20
SrcAddrMode Integer 0x00 – 0xff The addressing mode for the source 21
address used in this primitive and of the 22
APDU that has been received. This
parameter can take one of the non- 23
reserved values from the following list: 24
25
0x00 = SrcAddress and SrcEndpoint not
present 26
0x01 = reserved
27
28
0x02 = 16-bit short address for
SrcAddress and SrcEndpoint present 29
0x03 = 64-bit extended address for
30
SrcAddress and SrcEndpoint present 31
33
SrcAddress Address As specified by The individual device address or group 34
the SrcAddrMode address of the entity from which the
parameter ASDU has been received 35
36
SrcEndpoint Integer 0x00 – 0xfe This parameter shall be present if, and 37
only if, the SrcAddrMode parameter has a
value of 0x02 or 0x03 and, if present, 38
shall be the number of the individual 39
endpoint of the entity from which the 40
ASDU has been received 41
ProfileId Integer 0x0000 - 0xffff The identifier of the profile from which 42
this frame originated 43
44
45
Chapter 2
Table 2.4 APSDE-DATA.indication Parameters

1
ClusterId Integer 0x0000-0xffff The identifier of the received object 3
4
asduLength Integer The number of octets comprising the
5
ASDU being indicated by the APSDE
6
asdu Set of octets - The set of octets comprising the ASDU 7
being indicated by the APSDE
8
WasBroadcast Boolean TRUE or FALSE TRUE if the transmission was a 9
broadcast, FALSE otherwise 10
SecurityStatus Enumeration UNSECURED, UNSECURED if the ASDU was received 11
without any security 12
SECURED_NW
K_KEY, SECURED_NWK_KEY if the received 13
14
SECURED_LIN ASDU was secured with the NWK key 15
K_KEY
SECURED_LINK_KEY if the ASDU 16
was secured with a link key 17
18
20
This primitive is generated by the APS sub-layer and issued to the next higher 21
layer on receipt of an appropriately addressed data frame from the local NWK 22
layer entity. If the frame control field of the ASDU header indicates that the frame 23
is secured, security processing shall be done as specified in sub-clause 4.2.4. 24
This primitive is generated by the APS sub-layer entity and issued to the next 25
higher layer entity on receipt of an appropriately addressed data frame from the 26
local Network layer entity, via the NLDE-DATA.indication primitive. If the frame 27
control field of the APDU header indicates that the frame is secured, then security 28
processing must be undertaken as specified in sub-clause 4.2.4. 29
30
If the received frame is received using indirect addressing and the APDU does not 31
contain a source endpoint, the APSDE issues this primitive with the 32
SrcAddrMode parameter set to 0x00. If the received frame is not received using 33
indirect addressing, the received source address must be mapped to its 34
corresponding extended 64-bit IEEE address by using the apsAddressMap 35
attribute of the APS ID (see Table 2.23.) If a corresponding 64-bit IEEE address 36
could be found, the APSDE issues this primitive with the SrcAddrMode 37
parameter set to 0x02 and the SrcAddress parameter set to the corresponding 64- 38
bit IEEE address. If a corresponding 64-bit IEEE address could not be found, the 39
APSDE issues this primitive with the SrcAddrMode parameter set to 0x01, and 40
the SrcAddress parameter set to the 16-bit source address as contained in the 41
received frame. 42
43
44
45

1
On receipt of this primitive the next higher layer is notified of the arrival of data at 2
the device. 3
4
2.2.4.2 APS Management Service 5
The APS management entity SAP (APSME-SAP) supports the transport of 6
management commands between the next higher layer and the APSME. Table 2.5 7
summarizes the primitives supported by the APSME through the APSME-SAP 8
interface. See the following sub-clauses for more details on the individual 9
primitives. 10
11
Table 2.5 Summary of the Primitives Accessed Through the APSME-SAP 12
Name Request Indication Response Confirm 13
14
APSME-BIND 2.2.4.3.1 2.2.4.3.2 15
APSME-GET 2.2.4.4.1 2.2.4.4.2 16
17
APSME-SET 2.2.4.4.3 2.2.4.4.4
18
APSME-UNBIND 2.2.4.3.3 2.2.4.3.4 19
APSME-ADD- 2.2.4.5.1 2.2.4.5.2 20
GROUP 21
22
APSME-REMOVE- 2.2.4.5.3 2.2.4.5.4
GROUP 23
24
APSME-REMOVE- 2.2.4.5.5 2.2.4.5.6 25
ALL-GROUPS
26
27
2.2.4.3 Binding Primitives 28
29
This set of primitives defines how the next higher layer of a device can add
30
(commit) a binding record to its local binding table or remove a binding record
31
from its local binding table.
32
Only the ZigBee coordinator, a device supporting a binding table cache or a 33
device that wishes to store source bindings, may process these primitives. If any 34
other device receives these primitives from their next higher layer, the primitives 35
should be ignored. 36
37
2.2.4.3.1 APSME-BIND.request
38
This primitive allows the next higher layer to request to bind two devices together 39
by creating an entry in its local binding table, if supported. 40
41
42
43
44
45
Chapter 2
2.2.4.3.1.1 Semantics of the Service Primitive

1
The semantics of this primitive are as follows: 2
APSME-BIND.request {
3
4
SrcAddr,
5
SrcEndpoint,
6
ClusterId, 7
DstAddrMode, 8
DstAddr, 9
DstEndpoint 10
} 11
12
Table 2.6 specifies the parameters for the APSME-BIND.request primitive. 13
14
Table 2.6 APSME-BIND.request Parameters
15
17
SrcAddr IEEE A valid 64-bit The source IEEE address for the binding 18
address IEEE address entry
19
SrcEndpoint Integer 0x01 – 0xff The source endpoint for the binding entry 20
ClusterId Integer 0x0000 – 0xffff The identifier of the cluster on the source 21
device that is to be bound to the destination 22
device 23
used in this primitive. This parameter can take 25
one of the non-reserved values from the 26
following list: 27
0x00 = reserved 28
0x01 = 16-bit group address for DstAddr and 29
0x02 = reserved 31
0x03 = 64-bit extended address for DstAddr 32
and DstEndpoint present 33
35
DstAddr Address As specified by The destination address for the binding entry
the DstAddrMode 36
parameter 37
38
DstEndpoint Integer 0x01 – 0xff This parameter will be present only if the
DstAddrMode parameter has a value of 0x03 39
and, if present, will be the destination 40
endpoint for the binding entry 41
42
43
44
45

1
This primitive is generated by the next higher layer and issued to the APS sub- 2
layer in order to instigate a binding operation on a device that supports a binding 3
table. 4
5
7
On receipt of this primitive by a device that is not currently joined to a network or
8
by a device that does not support a binding table, the APSME issues the APSME-
9
BIND.confirm primitive with the Status parameter set to ILLEGAL_REQUEST.
10
If the APS sub-layer on a device that supports a binding table receives this 11
primitive from the NHLE, the APSME attempts to create the specified entry 12
directly in its binding table. If the entry could be created, the APSME issues the 13
APSME-BIND.confirm primitive with the Status parameter set to SUCCESS. If 14
the entry could not be created due to a lack of capacity in the binding table, the 15
APSME issues the APSME-BIND.confirm primitive with the Status parameter set 16
to TABLE_FULL. 17
18
2.2.4.3.2 APSME-BIND.confirm
19
This primitive allows the next higher layer to be notified of the results of its 20
request to bind two devices directly or by proxy. 21
22
24
APSME-BIND.confirm { 26
Status,
27
28
SrcAddr,
29
SrcEndpoint,
30
ClusterId, 31
DstAddrMode, 32
DstAddr, 33
DstEndpoint 34
} 35
36
37
38
39
40
41
42
43
44
45
Chapter 2
Table 2.7 specifies the parameters for the APSME-BIND.confirm primitive.

1
Table 2.7 APSME-BIND.confirm Parameters
2
4
Status Enumeration SUCCESS, The results of the binding 5
ILLEGAL_DEVICE, request
ILLEGAL_REQUEST, 6
TABLE_FULL, 7
NOT_SUPPORTED 8
SrcAddr IEEE address A valid 64-bit IEEE The source IEEE address for 9
address the binding entry 10
11
SrcEndpoint Integer 0x01 – 0xff The source endpoint for the
binding entry 12
13
ClusterId Integer 0x0000 – 0xffff The identifier of the cluster 14
on the source device that is
to be bound to the
15
destination device 16
17
DstAddrMode Integer 0x00 – 0xff The addressing mode for the
18
source address used in this
primitive. This parameter 19
can take one of the non- 20
reserved values from the 21
following list: 22
0x00 = reserved 23
0x01 = 16-bit group address 24
for DstAddr and 25
0x02 = reserved 27
0x03 = 64-bit extended 28
address for DstAddr and 29
DstAddr Address As specified by the The destination address for 32
DstAddrMode parameter the binding entry 33
DstEndpoint Integer 0x01 – 0xff This parameter will be 34
present only if the 35
DstAddrMode parameter 36
has a value of 0x03 and, if 37
present, will be the 38
destination endpoint for the
binding entry 39
40
41
42
43
44
45

1
This primitive is generated by the APSME and issued to its NHLE in response to 2
an APSME-BIND.request primitive. If the request was successful, the Status 3
parameter will indicate a successful bind request. Otherwise, the status parameter 4
indicates an error code of ILLEGAL_DEVICE, ILLEGAL_REQUEST or 5
TABLE_FULL. 6
7
9
On receipt of this primitive, the next higher layer is notified of the results of its
10
bind request. If the bind request was successful, the Status parameter is set to
11
SUCCESS. Otherwise, the Status parameter indicates the error.
12
2.2.4.3.3 APSME-UNBIND.request 13
14
This primitive allows the next higher layer to request to unbind two devices by 15
removing an entry in its local binding table, if supported. 16
17
20
APSME-UNBIND.request { 21
SrcAddr, 22
SrcEndpoint, 23
ClusterId, 24
DstAddrMode, 25
DstAddr, 26
DstEndpoint 27
}
28
29
30
Table 2.8 specifies the parameters for the APSME-UNBIND.request primitive. 31
Table 2.8 APSME-UNBIND.request Parameters 32
33
SrcAddr IEEE A valid 64-bit The source IEEE address for the binding entry 35
address IEEE address 36
SrcEndpoint Integer 0x01 – 0xff The source endpoint for the binding entry 37
38
ClusterId Integer 0x0000 – 0xffff The identifier of the cluster on the source device 39
that is bound to the destination device
40
41
42
43
44
45
Chapter 2
Table 2.8 APSME-UNBIND.request Parameters

1
used in this primitive. This parameter can take 4
one of the non-reserved values from the 5
following list: 6
0x00 = reserved 7
0x01 = 16-bit group address for DstAddr and 8
0x02 = reserved 10
0x03 = 64-bit extended address for DstAddr and 11
14
DstAddr Address As specified by The destination address for the binding entry
the 15
DstAddrMode 16
parameter 17
DstEndpoint Integer 0x01 – 0xff This parameter will be present only if the 18
DstAddrMode parameter has a value of 0x03 19
and, if present, will be the destination endpoint 20
for the binding entry 21
22
24
This primitive is generated by the next higher layer and issued to the APS sub- 25
layer in order to instigate an unbind operation on a device that supports a binding 26
table. 27
28
On receipt of this primitive by a device that is not currently joined to a network or 30
by a device that does not support a binding table, the APSME issues the APSME- 31
UNBIND.confirm primitive with the Status parameter set to 32
ILLEGAL_REQUEST. 33
34
If the APS on a device that supports a binding table receives this primitive from 35
the NHLE, the APSME searches for the specified entry in its binding table. If the 36
entry exists, the APSME removes the entry and issues the APSME- 37
UNBIND.confirm (see sub-clause 2.2.4.3.4) primitive with the Status parameter 38
set to SUCCESS. If the entry could not be found, the APSME issues the APSME- 39
UNBIND.confirm primitive with the Status parameter set to 40
INVALID_BINDING. If the devices do not exist on the network, the APSME 41
issues the APSME-BIND.confirm primitive with the Status parameter set to 42
ILLEGAL_DEVICE. 43
44
45
2.2.4.3.4 APSME-UNBIND.confirm
1
request to unbind two devices directly or by proxy. 3
4
6
The semantics of this primitive are as follows:
7
APSME-UNBIND.confirm { 8
Status, 9
SrcAddr, 10
SrcEndpoint, 11
ClusterId,
12
13
DstAddrMode,
14
DstAddr,
15
DstEndpoint 16
} 17
18
Table 2.9 specifies the parameters for the APSME-UNBIND.confirm primitive. 19
Table 2.9 APSME-UNBIND.confirm Parameters 20
21
Name Type ValidRange Description 22
23
Status Enumeration SUCCESS, The results of the unbind
ILLEGAL_DEVICE, request 24
ILLEGAL_REQUEST, 25
INVALID_BINDING 26
SrcAddr IEEE address A valid 64-bit IEEE The source IEEE address for 27
address the binding entry 28
29
SrcEndpoint Integer 0x01 – 0xff The source endpoint for the
binding entry 30
31
ClusterId Integer 0x0000 – 0xffff The identifier of the cluster on 32
the source device that is bound
to the destination device 33
34
35
36
37
38
39
40
41
42
43
44
45
Chapter 2
Table 2.9 APSME-UNBIND.confirm Parameters

1
Name Type ValidRange Description 2
DstAddrMode Integer 0x00 – 0xff The addressing mode for the 3
source address used in this 4
primitive. This parameter can 5
take one of the non-reserved 6
values from the following list:
7
0x00 = reserved 8
0x01 = 16-bit group address 9
for DstAddr and DstEndpoint 10
not present 11
0x02 = reserved 12
0x03 = 64-bit extended address 13
for DstAddr and DstEndpoint 14
present
15
0x04 – 0xff = reserved
16
DstAddr Address As specified by the The destination address for the 17
DstAddrMode parameter binding entry 18
DstEndpoint Integer 0x01 – 0xff The destination endpoint for 19
the binding entry 20
21
23
This primitive is generated by the APSME and issued to its NHLE in response to 24
an APSME-UNBIND.request primitive. If the request was successful, the Status 25
parameter will indicate a successful unbind request. Otherwise, the status 26
parameter indicates an error code of ILLEGAL_DEVICE, 27
ILLEGAL_REQUEST, or INVALID_BINDING. 28
29
31
32
unbind request. If the unbind request was successful, the Status parameter is set to
33
SUCCESS. Otherwise, the Status parameter indicates the error.
34
2.2.4.4 Information Base Maintenance 35
36
This set of primitives defines how the next higher layer of a device can read and 37
write attributes in the AIB. 38
39
2.2.4.4.1 APSME-GET.request
40
This primitive allows the next higher layer to read the value of an attribute from 41
the AIB. 42
43
44
45

1
APSME-GET.request {
3
4
AIBAttribute
5
}
6
7
Table 2.10 specifies the parameters for this primitive. 8
Table 2.10 APSME-GET.request Parameters 9
10
AIBAttribute Integer See Table 2.23 The identifier of the AIB attribute to read 12
13
14
This primitive is generated by the next higher layer and issued to its APSME in 16
order to read an attribute from the AIB. 17
18
20
On receipt of this primitive, the APSME attempts to retrieve the requested AIB 21
attribute from its database. If the identifier of the AIB attribute is not found in the 22
database, the APSME issues the APSME-GET.confirm primitive with a status of 23
UNSUPPORTED_ATTRIBUTE. 24
If the requested AIB attribute is successfully retrieved, the APSME issues the 25
APSME-GET.confirm primitive with a status of SUCCESS such that it contains 26
the AIB attribute identifier and value. 27
28
2.2.4.4.2 APSME-GET.confirm 29
30
This primitive reports the results of an attempt to read the value of an attribute
31
from the AIB.
32
33
34
36
APSME-GET.confirm { 37
Status, 38
AIBAttribute, 39
AIBAttributeLength, 40
AIBAttributeValue 41
} 42
43
44
45
Chapter 2
Table 2.11 specifies the parameters for this primitive.

1
Table 2.11 APSME-GET.confirm Parameters
2
4
Status Enumeration SUCCESS or The results of the request to read an 5
UNSUPPORTED AIB attribute value
_ATTRIBUTE 6
7
AIBAttribute Integer See Table 2.23 The identifier of the AIB attribute 8
that was read
9
AIBAttributeLength Integer 0x0000 - 0xffff The length, in octets, of the 10
attribute value being returned 11
AIBAttributeValue Various Attribute Specific The value of the AIB attribute that 12
(see Table 2.23) was read 13
14
16
This primitive is generated by the APSME and issued to its next higher layer in 17
response to an APSME-GET.request primitive. This primitive returns a status of 18
SUCCESS, indicating that the request to read an AIB attribute was successful, or 19
an error code of UNSUPPORTED_ATTRIBUTE. The reasons for these status 20
values are fully described in sub-clause 2.2.4.4.1.3. 21
22
24
25
request to read an AIB attribute. If the request to read an AIB attribute was
26
successful, the Status parameter will be set to SUCCESS. Otherwise, the status
27
parameter indicates the error.
28
2.2.4.4.3 APSME-SET.request 29
30
This primitive allows the next higher layer to write the value of an attribute into 31
the AIB. 32
33
36
APSME-SET.request { 37
AIBAttribute, 38
AIBAttributeLength, 39
AIBAttributeValue 40
} 41
42
43
44
45

1
Table 2.12 APSME-SET.request Parameters
2
4
AIBAttribute Integer See Table 2.23. The identifier of the AIB attribute to be 5
written.
6
AIBAttributeLength Integer 0x0000 - 0xffff The length, in octets, of the attribute 7
value being set 8
AIBAttributeValue Various Attribute Specific The value of the AIB attribute that should 9
(see Table 2.23). be written. 10
11
13
This primitive is to be generated by the next higher layer and issued to its APSME 14
in order to write the value of an attribute in the AIB. 15
16
18
On receipt of this primitive the APSME attempts to write the given value to the
19
indicated AIB attribute in its database. If the AIBAttribute parameter specifies an
20
attribute that is not found in the database, the APSME issues the APSME-
21
SET.confirm primitive with a status of UNSUPPORTED_ATTRIBUTE. If the
22
AIBAttributeValue parameter specifies a value that is out of the valid range for the
23
given attribute, the APSME issues the APSME-SET.confirm primitive with a
24
status of INVALID_PARAMETER.
25
If the requested AIB attribute is successfully written, the APSME issues the 26
APSME-SET.confirm primitive with a status of SUCCESS. 27
28
2.2.4.4.4 APSME-SET.confirm
29
This primitive reports the results of an attempt to write a value to an AIB attribute. 30
31
33
APSME-SET.confirm { 35
Status,
36
37
AIBAttribute
38
}
39
40
41
42
43
44
45
Chapter 2

1
Table 2.13 APSME-SET.confirm Parameters
2
4
Status Enumeration SUCCESS, The result of the request to 5
INVALID_PARAMETER or write the AIB Attribute
UNSUPPORTED_ATTRIBUTE 6
7
AIBAttribute Integer See Table 2.23. The identifier of the AIB 8
attribute that was written
9
10
12
This primitive is generated by the APSME and issued to its next higher layer in
13
response to an APSME-SET.request primitive. This primitive returns a status of
14
either SUCCESS, indicating that the requested value was written to the indicated
15
AIB attribute, or an error code of INVALID_PARAMETER or
16
UNSUPPORTED_ATTRIBUTE. The reasons for these status values are fully
17
described in sub-clause 2.2.4.4.3.3.
18
19
20
On receipt of this primitive, the next higher layer is notified of the results of its 21
request to write the value of a AIB attribute. If the requested value was written to 22
the indicated AIB attribute, the Status parameter will be set to SUCCESS. 23
Otherwise, the Status parameter indicates the error. 24
25
2.2.4.5 Group Management 26
27
This group of primitives allows the next higher layer to manage group 28
membership for endpoints on the current device by adding and removing entries 29
in the group table. 30
2.2.4.5.1 APSME-ADD-GROUP.request 31
32
This primitive allows the next higher layer to request that group membership for a 33
particular group be added for a particular endpoint. 34
35
37
38
APSME-ADD-GROUP.request { 39
GroupAddress, 40
Endpoint 41
} 42
43
44
45

1
Table 2.14 APSME-ADD-GROUP.request Parameters
2
4
GroupAddress 16-bit 0x0000 - 0xfff7 The 16-bit address of the 5
group group being added
address 6
7
Endpoint Integer 0x01 - 0xf0 The endpoint to which the 8
given group is being added
9
10
12
This primitive is generated by the next higher layer when it wants to add
13
membership in a particular group to an endpoint, so that frames addressed to the
14
group will be delivered to that endpoint in the future.
15
16
17
If, on receipt of this primitive, the GroupAddress parameter is found to be out of 18
the valid range, then the APSME will issue the APSME-ADD-GROUP.confirm 19
primitive to the next higher layer with a Status value of 20
INVALID_PARAMETER. Similarly, if the Endpoint parameter has a value of 21
0x00 or else enumerates an endpoint that is not implemented on the current 22
device, the APSME will issue the APSME-ADD-GROUP.confirm primitive with 23
a Status of INVALID_PARAMETER. 24
25
After checking the parameters as described above, the APSME will check the 26
group table to see if an entry already exists containing the values given by the 27
GroupAddress and Endpoint parameters. If such an entry already exists in the 28
table then the APSME will issue the APSME-ADD-GROUP.confirm primitive to 29
the next higher layer with a Status value of SUCCESS. If there is no such entry 30
and there is space in the table for another entry then the APSME will add a new 31
entry to the group table with the values given by the GroupAddress and Endpoint 32
parameters. After the entry is added, the APSME will issue the APSME-ADD- 33
GROUP.confirm primitive to the next higher layer with a Status value of 34
SUCCESS. If no entry for the given GroupAddress and Endpoint is present but 35
there is no room in the group table for another entry then the APSME will issue 36
the APSME-ADD-GROUP.confirm primitive to the next higher layer with a 37
Status value of TABLE_FULL. 38
2.2.4.5.2 APSME-ADD-GROUP.confirm 39
40
This primitive allows the next higher layer to be informed of the results of its 41
request to add a group to an endpoint. 42
43
44
45
Chapter 2

1
The semantics of the service primitive are as follows: 2
APSME-ADD-GROUP.confirm {
3
4
Status,
5
GroupAddress,
6
Endpoint 7
} 8
9
Table 2.15 APSME-ADD-GROUP.confirm Parameters 11
12
14
Status Enumeration SUCCESS, The status of the request to
INVALID_PARAMETER add a group 15
or TABLE_FULL 16
17
GroupAddress 16-bit group 0x0000 - 0xfff7 The 16-bit address of the
address group being added 18
19
given group is being added
21
22
This primitive is generated by the APSME and issued to the next higher layer in 24
response to an APMSE-ADD-GROUP.request primitive. If the APSME-ADD- 25
GROUP.request was successful then the Status parameter value will be 26
SUCCESS. If one of the parameters of the APSME-ADD-GROUP.request 27
primitive had an invalid value then the Status value will be set to 28
INVALID_PARAMETER. If the APSME attempted to add a group table entry but 29
there was no room in the table for another entry then the Status value will be 30
TABLE_FULL. 31
32
33
34
On receipt of this primitive the next higher layer is informed of the status of its 35
request to add a group. The Status parameter values will be as described above. 36
37
2.2.4.5.3 APSME-REMOVE-GROUP.request 38
This primitive allows the next higher layer to request that group membership in a 39
particular group for a particular endpoint be removed. 40
41
42
43
44
45

1
APSME-REMOVE-GROUP.request {
3
4
GroupAddress,
5
Endpoint
6
} 7
8
Table 2.16 APSME-REMOVE-GROUP.request Parameters 10
11
GroupAddress 16-bit group 0x0000 - 0xfff7 The 16-bit address of the 13
address group being removed 14
15
Endpoint Integer 0x01 - 0xf0 The endpoint to which the
given group is being 16
removed 17
18
19
20
This primitive is generated by the next higher layer when it wants to remove 21
membership in a particular group from an endpoint so that frames addressed to the 22
group will no longer be delivered to that endpoint. 23
24
26
If, on receipt of this primitive, the GroupAddress parameter is found to be out of 27
the valid range, then the APSME will issue the APSME-REMOVE- 28
GROUP.confirm primitive to the next higher layer with a Status value of 29
INVALID_PARAMETER. Similarly, if the Endpoint parameter has a value of 30
0x00 or else enumerates an endpoint that is not implemented on the current device 31
the APSME will issue the APSME-REMOVE-GROUP.confirm primitive with a 32
Status of INVALID_PARAMETER. 33
After checking the parameters as described above, the APSME will check the 34
group table to see if an entry exists containing the values given by the 35
GroupAddress and Endpoint parameters. If such an entry already exists in the 36
table then that entry will be removed and the APSME will issue the APSME- 37
REMOVE-GROUP.confirm primitive to the next higher layer with a Status value 38
of SUCCESS. If there is no such entry, the APSME will issue the APSME- 39
REMOVE-GROUP.confirm primitive to the next higher layer with a Status value 40
of SUCCESS. 41
42
43
44
45
Chapter 2
2.2.4.5.4 APSME-REMOVE-GROUP.confirm
1
request to remove a group from an endpoint. 3
4
6
The semantics of the service primitive are as follows:
7
APSME-REMOVE-GROUP.confirm { 8
Status, 9
GroupAddress, 10
Endpoint 11
}
12
13
14
Table 2.17 APSME-REMOVE-GROUP.confirm Parameters 16
17
Status Enumeration SUCCESS or The status of the request to 19
INVALID_PARAMETER remove a group. 20
GroupAddress 16-bit group 0x0000 - 0xfff7 The 16-bit address of the 21
address group being removed 22
23
Endpoint Integer 0x01 - 0xf0 The endpoint which is to
be removed from the 24
group 25
26
27
28
response to an APMSE-REMOVE-GROUP.request primitive. If the APSME- 30
REMOVE-GROUP.request was successful, the Status parameter value will be 31
SUCCESS. If one of the parameters of the APMSE-REMOVE-GROUP.request 32
primitive had an invalid value then the Status value will be 33
INVALID_PARAMETER. 34
35
37
On receipt of this primitive, the next higher layer is informed of the status of its 38
request to remove a group. The Status parameter values will be as described 39
above. 40
41
42
43
44
45
2.2.4.5.5 APSME-REMOVE-ALL-GROUPS.request
1
This primitive is generated by the next higher layer when it wants to remove 2
membership in all groups from an endpoint, so that no group addressed frames 3
will be delivered to that endpoint. 4
5
7
The semantics of the service primitive are as follows:
8
APSME-REMOVE-ALL-GROUPS.request { 9
Endpoint 10
} 11
12
13
14
Table 2.18 APSME-REMOVE-ALL-GROUPS.request Parameters 15
16
Name Type Valid Range Description
17
given group is being 19
removed
20
21
23
This primitive is generated by the next higher layer when it wants to remove
24
membership in all groups from an endpoint so that no group addressed frames will
25
be delivered to that endpoint.
26
27
If, on receipt of this primitive, the Endpoint parameter has a value of 0x00 or else 29
enumerates an endpoint that is not implemented on the current device the APSME 30
will issue the APSME-REMOVE-ALL-GROUPS.confirm primitive with a Status 31
of INVALID_PARAMETER. 32
33
After checking the Endpoint parameter as described above, the APSME will 34
remove all entries from the group table, related to this endpoint, and will issue the 35
APSME-REMOVE-ALL-GROUPS.confirm primitive to the next higher layer 36
with a Status value of SUCCESS. 37
2.2.4.5.6 APSME-REMOVE-ALL-GROUPS.confirm 38
39
request to remove all groups from an endpoint. 41
42
43
44
45
Chapter 2

1
APSME-REMOVE-ALL-GROUPS.confirm {
3
4
Status,
5
Endpoint
6
} 7
8
Table 2.19 APSME-REMOVE-ALL-GROUPS.confirm Parameters 10
11
Status Enumeration SUCCESS, The status of the request to 13
INVALID_PARAMETER remove all group 14
or TABLE_FULL 15
Endpoint Integer 0x01 - 0xf0 The endpoint which is to 16
be removed from all 17
groups 18
19
21
response to an APSME-REMOVE-ALL-GROUPS.request primitive. If the 23
APSME-REMOVE-ALL-GROUPS.request was successful then the Status 24
parameter value will be SUCCESS. If the Endpoint parameter of the APSME- 25
REMOVE-ALL-GROUPS.request primitive had an invalid value then the Status 26
value will be INVALID_PARAMETER. 27
28
30
On receipt of this primitive the next higher layer is informed of the status of its 31
request to remove all groups from an endpoint. The Status parameter values will 32
be as described above. 33
34
2.2.5 Frame Formats 35
36
This subclause specifies the format of the APS frame (APDU). Each APS frame 37
consists of the following basic components: 38
39
• An APS header, which comprises frame control and addressing information. 40
• An APS payload, of variable length, which contains information specific to the 41
frame type. 42
43
44
45
The frames in the APS sub-layer are described as a sequence of fields in a specific
order. All frame formats in this subclause are depicted in the order in which they 1
are transmitted by the NWK layer, from left to right, where the left-most bit is 2
transmitted first in time. Bits within each field are numbered from 0 (left-most and 3
least significant) to k-1 (rightmost and most significant), where the length of the 4
field is k bits. Fields that are longer than a single octet are sent to the NWK layer 5
in the order from the octet containing the lowest numbered bits to the octet 6
containing the highest numbered bits. 7
8
2.2.5.1 General APDU Frame Format 9
10
The APS frame format is composed of an APS header and an APS payload. The 11
fields of the APS header appear in a fixed order, however, the addressing fields 12
may not be included in all frames. The general APS frame shall be formatted as 13
illustrated in Figure 2.4. 14
15
Octets:
1 0/1 0/2 0/2 0/2 0/1 1 Variable 16
17
Frame Destination Group Cluster Profile Source APS Frame 18
control endpoint address identifier Identifier endpoint counter payload 19
Addressing fields 20
21
APS header APS
payload 22
23
Figure 2.4 General APS Frame Format 24
25
2.2.5.1.1 Frame Control Field 26
27
The frame control field is 8-bits in length and contains information defining the 28
frame type, addressing fields and other control flags. The frame control field shall 29
be formatted as illustrated in Figure 2.5. 30
Bits: 0-1 2-3 4 5 6 7 31
32
Frame type Delivery mode Indirect address mode Security Ack. request Reserved 33
34
Figure 2.5 Format of the Frame Control Field 35
36
37
38
39
40
41
42
43
44
45
Chapter 2
2.2.5.1.1.1 Frame Type Sub-field

1
The frame type sub-field is two bits in length and shall be set to one of the non- 2
reserved values listed in Table 2.20. 3
Table 2.20 Values of the Frame Type Sub-field 4
5
Frame Type Value 6
b1 b0 Frame Type Name
7
00 Data 8
9
01 Command
10
10 Acknowledgement 11
11 Reserved 12
13
14
2.2.5.1.1.2 Delivery Mode Sub-field
15
The delivery mode sub-field is two bits in length and shall be set to one of the 16
non-reserved values from Table 2.21. 17
18
Table 2.21 Values of the Delivery Mode Sub-field
19
Delivery Mode Value 20
b1 b0 Delivery Mode Name 21
00 Normal unicast delivery 22
23
01 Indirect addressing 24
10 Broadcast 25
11 Group addressing
26
27
28
If the value is 0b01, indirect addressing is in use and either the destination or 29
source endpoint shall be omitted, depending on the value of the indirect address 30
mode sub-field. If the value is 0b10, the message is a broadcast. In this case the 31
message will go to all devices and all endpoints defined for the selected broadcast 32
address in use as defined in Section 3.7.51. If the value is 0b11, then group 33
addressing is in use and that frame will only be delivered to device endpoints that 34
express group membership in the group identified by the group address field in the 35
APS header. Note that other endpoints on the source device may be members of 36
the group addressed by the outgoing frame. The frame shall be delivered to any 37
member of the group including other endpoints on the source device that are 38
members of the specified group. 39
40
41
42
43
1. CCB #584 44
45
2.2.5.1.1.3 Indirect Address Mode Sub-field

1
The indirect address mode sub-field is one bit in length and specifies whether the 2
source or destination endpoint fields are present in the frame when the delivery 3
mode sub-field is set to indicate indirect addressing. If this sub-field is set to 1, the 4
destination endpoint field shall be omitted from the frame, indicating an indirect 5
transmission to the ZigBee coordinator. If this sub-field is set to 0, the source 6
endpoint field shall be omitted from the frame, indicating an indirect transmission 7
from the ZigBee coordinator. If the delivery mode sub-field of the frame control 8
field does not indicate indirect addressing, the indirect address mode sub-field 9
shall be ignored. 10
11
2.2.5.1.1.4 Security Sub-field 12
13
The Security Services Provider (see Chapter 4) manages the security sub-field.
14
15
2.2.5.1.1.5 Acknowledgement Request Sub-field 16
The acknowledgement request sub-field is one bit in length and specifies whether 17
the current transmission requires an acknowledgement frame to be sent to the 18
recipient on receipt of the frame. If this sub-field is set to 1, the recipient shall 19
construct and send an acknowledgement frame back to the originator after 20
determining that the frame is valid. If this sub-field is set to 0, the recipient shall 21
not send an acknowledgement frame back to the originator after determining that 22
the frame is valid. 23
24
2.2.5.1.2 Destination Endpoint Field 25
The destination endpoint field is 8-bits in length and specifies the endpoint of the 26
final recipient of the frame. This field shall be included in the frame only if the 27
delivery mode sub-field of the frame control field is set to 0b00 (normal unicast 28
delivery) or if the delivery mode sub-field is set to 0b01 (indirect addressing) and 29
the indirect address mode sub-field of the frame control field is set to 0. 30
31
A destination endpoint value of 0x00 addresses the frame to the ZigBee device 32
object (ZDO), resident in each device. A destination endpoint value of 0x01-0xf0 33
addresses the frame to an application operating on that endpoint. A destination 34
endpoint value of 0xff addresses the frame to all active endpoints. All other 35
endpoints (0xf1-0xfe) are reserved. 36
2.2.5.1.3 Group Address Field 37
38
The group address field is 16 bits in length and will only be present if the delivery 39
mode subfield of the frame control has a value of 0b11. In this case, the 40
destination endpoint shall not be present. If the APS header of a frame contains a 41
group address field, the frame will be delivered to all endpoints for which the 42
group table in the device contains an association between that endpoint and the 43
group identified by the contents of the group address field. 44
45
Chapter 2
2.2.5.1.4 Cluster Identifier Field

1
The cluster identifier field is 16-bits in length and specifies the identifier of the 2
cluster that is to be used in the binding operation on the ZigBee coordinator or on 3
the device indicated by the SrcAddr of the request. The frame type sub-field of the 4
frame control field specifies whether the cluster identifier field is present or not. It 5
will be for data frames, but not for command frames. 6
2.2.5.1.5 Profile Identifier Field 7
8
The profile identifier is 2 octets in length and specifies the ZigBee profile 9
identifier for which the frame is intended and shall be used during the filtering of 10
messages at each device that takes delivery of the frame. This field shall be 11
present only for data or acknowledgement frames. 12
2.2.5.1.6 Source Endpoint Field 13
14
The source endpoint field is 8-bits in length and specifies the endpoint of the 15
initial originator of the frame. A source endpoint value of 0x00 indicates that the 16
frame originated from the ZigBee device object (ZDO) resident in each device. A 17
source endpoint value of 0x01-0xf0 indicates that the frame originated from an 18
application operating on that endpoint. All other endpoints (0xf1-0xfe) are 19
reserved. 20
21
If the delivery mode sub-field of the frame control field indicates a delivery mode
22
of indirect addressing and the indirect address mode sub-field is set to 0, this field
23
shall not be included in the frame .
24
2.2.5.1.7 APS Counter 25
26
This field is 8 bits in length and is used as described in sub-clause 2.2.8.3.2 to 27
prevent the reception of duplicate frames. This value shall be incremented by one 28
for each new transmission. 29
2.2.5.1.8 Frame Payload Field 30
31
The frame payload field has a variable length and contains information specific to 32
individual frame types. 33
34
2.2.5.2 Format of Individual Frame Types 35
There are three defined frame types: data, APS command and acknowledgement. 36
Each of these frame types is discussed in the following subclauses. 37
38
39
40
41
42
43
44
45
2.2.5.2.1 Data Frame Format

1
The data frame shall be formatted as illustrated in Figure 2.6. 2
3
Octets:
1 0/1 0/2 0/2 0/2 0/1 1 Variable 4
5
Frame Destination Group Cluster Profile Source APS Frame 6
control endpoint address identifier Identifier endpoint counter payload 7
Addressing fields 8
9
APS header APS
payload 10
11
Figure 2.6 Data Frame Format 12
13
The order of the fields of the data frame shall conform to the order of the general 14
APS frame as illustrated in Figure 2.4. 15
16
2.2.5.2.1.1 Data Frame APS Header Field 17
18
The APS header field for a data frame shall contain the frame control, cluster 19
identifier, profile identifier, source endpoint and APS counter fields. The 20
destination endpoint field shall be included in a data frame according to the value 21
of the delivery mode sub-field of the frame control field. 22
In the frame control field, the frame type sub-field shall contain the value that 23
indicates a data frame, as shown in Table 2.20. The source endpoint present sub- 24
field shall be set to 1. All other sub-fields shall be set appropriately according to 25
the intended use of the data frame. 26
27
2.2.5.2.1.2 Data Payload Field 28
29
For an outgoing data frame, the data payload field shall contain part or all of the 30
sequence of octets that the next higher layer has requested the APS data service to 31
transmit. For an incoming data frame, the data payload field shall contain the 32
sequence of octets that has been received by the APS data service and that is to be 33
reflected to the destination devices or delivered to the next higher layer if the 34
coordinator is one of the destinations. 35
36
37
38
39
40
41
42
43
44
45
Chapter 2
2.2.5.2.2 APS Command Frame Format

1
The APS command frame shall be formatted as illustrated in Figure 2.7. 2
3
Octets: 1 0/2 1 1 Variable
4
Frame Group APS APS APS 5
control Address counter command command 6
identifier payload 7
APS header APS payload 8
9
Figure 2.7 APS Command Frame Format. 10
11
The order of the fields of the APS command frame shall conform to the order of 12
the general APS frame as illustrated in Figure 2.7. 13
14
2.2.5.2.2.1 APS Command Frame APS Header Field 15
16
The APS header field for an APS command frame shall contain the frame control
17
and APS counter fields. The group address field shall be included in the frame if
18
the delivery mode sub-field of the frame control field is set to indicate group
19
addressing.
20
indicates an APS command frame, as shown in Table 2.20. The APS Command 22
Payload shall be set appropriately according to the intended use of the APS 23
command frame. 24
25
2.2.5.2.2.2 APS Command Identifier Field 26
27
The APS command identifier field identifies the APS command being used. 28
29
2.2.5.2.2.3 APS Command Payload Field 30
The APS command payload field of an APS command frame shall contain the 31
APS command itself. 32
33
2.2.5.2.3 Acknowledgement Frame Format 34
35
The acknowledgement frame shall be formatted as illustrated in Figure 2.8.
36
Octets: 1 0/1 2 2 0/ 1 1 37
38
Frame Destination Cluster Profile Source APS 39
control endpoint Identifier identifier endpoint counter
40
APS header 41
42
Figure 2.8 Acknowledgement Frame Format 43
44
45
The order of the fields of the acknowledgement frame shall conform to the order
of the general APS frame as illustrated in Figure 2.8. 1
2
2.2.5.2.3.1 Acknowledgement Frame APS Header Field 3
4
The APS header field for an acknowledgement frame shall contain the frame 5
control, cluster identifier, profile identifier and APS counter fields. If the delivery 6
mode indicates direct addressing both the source and destination endpoint fields 7
shall be included in an acknowledgement frame. If the delivery mode indicates 8
indirect addressing the source and destination endpoint fields shall be included in 9
an acknowledgement frame according to the value of the indirect address mode 10
sub-field of the frame control field. 11
indicates an acknowledgement frame, as shown in Table 2.20. All other sub-fields 13
shall be set appropriately according to the intended use of the acknowledgement 14
frame. 15
16
Where present, the source endpoint field shall reflect the value in the destination 17
endpoint field of the frame that is being acknowledged. Similarly, where present, 18
the destination endpoint field shall reflect the value in the source endpoint field of 19
the frame that is being acknowledged. 20
The APS counter field shall contain the same value as the frame to which this 21
frame is an acknowledgment. 22
23
24
2.2.6 Command Frames 25
26
This specification defines no command frames. Refer to sub-clause 4.5.8 for a 27
thorough description of the APS command frames and primitives related to 28
security. 29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Chapter 2
2.2.7 Constants and PIB Attributes 1

2
2.2.7.1 APS Constants 3
The constants that define the characteristics of the APS sub-layer are presented in 4
Table 2.22. 5
6
Table 2.22 APS Sub-layer Constants
7
Constant Description Value 8
9
apscMaxAddrMapEntries The maximum number of Address Map 1 (minimum value) 10
entries
Implementation-specific 11
(maximum value) 12
13
apscMaxDescriptorSize The maximum number of octets 64 14
contained in a non-complex descriptor
15
apscMaxDiscoverySize The maximum number of octets that can 64 16
be returned through the discovery 17
process
18
apscMaxFrameRetries The maximum number of retries 3 19
allowed after a transmission failure. 20
apscAckWaitDuration The maximum number of seconds to 0.05 * 21
wait for an acknowledgement to a (2*nwkcMaxDepth) + 22
transmitted frame (security encrypt/ 23
decrypt delay), where
24
the (security encrypt/
decrypt delay) = 0.1 25
26
27
(assume 0.05 per 28
encrypt or decrypt 29
cycle)
30
apscMinDuplicateRejecti The minimum required size of the APS 1 31
onTableSize duplicate rejection table. 32
33
2.2.7.2 APS Information Base 34
35
The APS information base comprises the attributes required to manage the APS 36
layer of a device. The autarkies of the AIB are listed in Table 2.23. The AIB also 37
38
39
40
41
42
43
44
45
comprises of some additional attributes that are required to manage the security
service provider. These attributes are listed in sub-clause 4.5.9. 1
2
Table 2.23 APS IB Attributes
3
Attribute Identifier Type Range Description Default 4
5
apsAddressMap 0xc0 Set Variable The current set of 64 bit Null set 6
IEEE to 16 bit NWK
address maps (see 7
Table 2.24) 8
9
apsBindingTable 0xc1 Set Variable The current set of Null set
binding table entries in 10
the device (see sub- 11
clause 2.2.8.1.1) 12
apsGroupTable 0x0c2 Set Variable The current set of group Null set 13
table entries (see Sub- 14
clause 2.2.8.2) 15
16
17
18
Table 2.24 Address Map 19
16 bit NWK 20
Entry Number 64 bit IEEE address Address 21
22
0x00 - apscMaxAddrMapEntries A valid 64-bit IEEE address 0x0000 – 0xffff
23
24
2.2.8 Functional Description 25
26
27
2.2.8.1 Binding
28
The APS may maintain a binding table, which allows ZigBee devices to establish 29
a designated destination for frames from a given source endpoint and with a given 30
cluster ID. This table is employed by the indirect addressing mechanism. 31
32
2.2.8.1.1 Binding Table Implementation 33
A ZigBee coordinator or a device designated as containing a binding table shall be 34
able to support a binding table of implementation specific length. The binding 35
table shall implement the following mapping: 36
37
( as, es, cs ) = {( ad1|, ed1| ), ( ad2|, ed2| ) … ( adn|, edn |)} 38
39
40
41
42
43
44
45
Chapter 2
Where:
1
as = the address of the device as the source of the binding link 2
es = the endpoint identifier of the device as the source of the binding link 3
4
cs = the cluster identifier used in the binding link
5
adi = the ith destination address or destination group address associated with the binding link 6
edi = the ith optional destination endpoint identifier associated with the binding link. Note that 7
edi will only be present when adi is a device address 8
9
2.2.8.1.2 Binding 10
11
The APSME-BIND.request or APSME-UNBIND.request primitive initiates the 12
procedure for creating or removing a binding link. Only the ZigBee coordinator, a 13
device supporting a binding table cache, or a device that wishes to store source 14
bindings, shall initiate this procedure. This is achieved by issuing the APSME- 15
BIND.confirm or APSME-UNBIND.confirm primitive with the Status parameter 16
set to ILLEGAL_REQUEST. 17
18
When this procedure is initiated, the APSME shall first extract the address and
19
endpoint for both the source and destination of the binding link. The 64-bit IEEE
20
address shall be mapped to the 16-bit NWK address using the apsAddressMap
21
attribute of the APS IB (see Table 2.23.) If the DstAddrMode parameter has a
22
value of 0x01, indicating group addressing, then only the source address is treated
23
in the way just described. The 16-bit group address is used directly as a
24
destination address and, in this case, no destination endpoint is specified. With
25
this information, the APSME shall either create a new entry or remove the
26
corresponding entry from its binding table, depending on whether the bind or
27
unbind procedure, respectively, was initiated.
28
If a bind operation was requested, the APSME shall create a new entry in the 29
binding table. The device shall only create a new entry in the binding table if it has 30
the capacity to do so. This is achieved by issuing the APSME-BIND.confirm 31
primitive with the Status parameter set to TABLE_FULL. 32
33
If an unbind operation was requested, the APSME shall search the binding table
34
for an existing entry that matches the information contained in the initiation
35
request. If an entry was not found, the APSME shall terminate the procedure and
36
notify the NHLE of the invalid binding. This is achieved by issuing the APSME-
37
UNBIND.confirm primitive with the Status parameter set to
38
INVALID_BINDING. If an entry was found, the APSME shall remove the entry
39
in the binding table.
40
If the binding link is successfully created or removed, the APSME shall notify the 41
NHLE of the results of the direct binding attempt and the success of the 42
procedure. This is achieved by issuing the APSME-BIND.confirm primitive with 43
the binding results and the status parameter set to SUCCESS. 44
45
The procedure for a successful direct binding is illustrated in the MSC shown in
Figure 2.9. 1
2
3
4
APL APS NWK 5
6
APSME- 7
(UN)BIND.request 8
9
Create a new entry or 10
remove an existing entry 11
in the binding table 12
APSME- 13
(UN)BIND.confirm 14
15
16
17
Figure 2.9 Direct Binding on a Device Supporting a Binding Table 18
19
2.2.8.2 Group Addressing 20
21
The APS shall maintain a group table, which allows endpoints to be associated 22
with groups and allows group addressed frames to be delivered selectively to 23
those endpoints that are associated in the table with a particular group. 24
2.2.8.2.1 The Group Table 25
26
The group table shall be viewed as a set of associations between groups and 27
endpoints as follows: 28
29
{(g1 - ep11, ep12…ep1n), (g2 - ep21, ep22… ep2m)… (gi - epi1, epi2… epik)} 30
31
where : 32
33
gi = the ith group represented in the table.
34
epij = the jth endpoint associated with the ith group. 35
36
Implementers of this specification are free to implement the group table in any 37
manner that is convenient and efficient to them as long as it represents the 38
associations just described. 39
40
2.2.8.3 Transmission, Reception and Acknowledgement 41
42
This subclause describes the fundamental procedures for transmission, reception 43
and acknowledgement. 44
45
Chapter 2
2.2.8.3.1 Transmission
1
Only those devices that are currently part of a network shall send frames from the 2
APS sub-layer. If any other device receives a request to transmit a frame it shall 3
discard the frame and notify the instigating layer of the error. An APSDE- 4
DATA.confirm primitive with a status of CHANNEL_ACCESS_FAILURE 5
indicates that the attempt at transmission of the frame was unsuccessful due to the 6
channel being busy. 7
All frames handled by or generated within the APS sub-layer shall be constructed 8
according to the general frame format specified in sub-clause 2.2.5.1 and 9
transmitted using the NWK layer data service 10
11
Transmissions may be direct, indirect or group addressed. Direct transmissions 12
shall include both destination and source endpoint fields. In this case, the delivery 13
mode sub-field of the frame control field shall be set to either 0b00 (Normal 14
Unicast) or 0b10 (Broadcast). Group addressed transmissions, having a delivery 15
mode sub-field value of 0b11 shall contain a source endpoint field and group 16
address field but no destination endpoint field. Note that other endpoints on the 17
source device are legal group members and possible destinations for group 18
addressed frames. 19
The APS layer of the device originating an indirect transmission where the 20
binding table entry is stored at the ZigBee coordinator shall direct the 21
transmission to the ZigBee coordinator, which shall handle the task of message 22
reflection. 23
24
Indirect transmissions (i.e., those in which the delivery mode sub-field is set to 25
0b01) shall include only either the source endpoint field or the destination 26
endpoint field, depending on the direction of transmission with respect to the 27
ZigBee coordinator. If the indirect transmission is directed to the ZigBee 28
coordinator, the indirect address mode sub-field shall be set to 1 and the 29
destination endpoint field shall be omitted from the frame. Conversely, if the 30
indirect transmission is directed from the ZigBee coordinator after message 31
reflection, the indirect address mode sub-field shall be set to 0 and the source 32
endpoint field shall be omitted from the frame. 33
For all devices where the binding table is stored on the source device, the APS 34
layer of the source device originating the transmission shall employ direct 35
transmission to the destination addresses indicated by the corresponding binding 36
table entries in the case where the binding table entry contains a unicast 37
destination device address. In this case, the delivery mode sub-field of the frame 38
control field shall be set to 0b00. In the case where the binding table entry 39
contains a destination group address, the delivery mode subfield of the frame 40
control field shall have a value of 0b11 and the destination group address shall be 41
placed in the APS header in place of the destination endpoint. The frame shall 42
43
44
45
then be broadcast using the NLDE-DATA.request primitive and employing a

broadcast address of 0xffff. 1
2
The destination endpoint field, if present, shall contain the endpoint of the 3
intended recipient of the APDU. The source endpoint field, if present, shall 4
contain the endpoint of the originator of the APDU. 5
If security is required, the frame shall be processed as described in clause 4.5. 6
7
When the frame is constructed and ready for transmission, it shall be passed to the 8
NWK data service with a suitable destination and source address. In addition, the 9
APS layer shall ensure that route discovery is enabled at the network layer. An 10
APDU transmission is initiated by issuing the NLDE-DATA.request primitive to 11
the NWK layer and the results of the transmission returned via the NLDE- 12
DATA.confirm primitive. 13
2.2.8.3.2 Reception and Rejection 14
15
The APS sub-layer shall be able to filter frames arriving via the NWK layer data 16
service and only present the frames that are of interest to the NHLE. 17
If the APSDE of a device receives a transmission, it shall pass it directly to the 18
NHLE, unless it needs to be reflected, it is part of an incomplete fragmented 19
transmission, reserved bits are set in the APDSDU frame2, or it is determined to 20
have been a duplicate of a frame that has been passed up previously. The APSDE 21
shall maintain a duplicate rejection table to include at least the source address, 22
APS counter values and timing information such that frames transmitted 23
according to this specification and received more than once are identified as 24
duplicates and only delivered to the NHLE once. In exceptional cases this may 25
result in messages incorrectly being rejected as duplicates. 26
27
If reserved bits are set in the APSDU frame, the APS sub-layer shall drop the 28
frame.3 29
If the APSDE receives a secured frame, it shall process the frame as described in 30
clause 4.5 to remove the security. 31
32
If the APSDE receives a frame containing both destination and source endpoints, 33
it shall be assumed to be a direct transmission. In this case, the APSDE shall pass 34
it directly to the NHLE at the destination endpoint supplied. If the destination 35
endpoint is set to the broadcast endpoint (0xff), the APSDE shall present the 36
frame to all non-reserved endpoints (0x01-0xf0) supported by the NHLE.4 37
If the APSDE of the ZigBee coordinator receives a frame containing only the 38
source endpoint with the delivery mode sub-field of the frame control field set to 39
40
41
2. CCB #613 42
3. CCB #613 43
4. CCB #548 44
45
Chapter 2
the indirect addressing value (0x01) it shall be assumed to be an indirect

transmission. If the device is not a ZigBee coordinator, the frame shall be 1
discarded if the destination endpoint is not present and the delivery mode sub- 2
field of the frame control field is set to the indirect addressing value (0x01). 3
4
If the APSDE of a ZigBee coordinator receives an indirect transmission, it shall 5
search its binding table for an entry that matches the source address 6
communicated from the NWK layer, the cluster identifier included in the received 7
frame and the source endpoint included in the frame. If a match is not found, the 8
frame shall be discarded. If a match is found, the APSDE shall build an APDU for 9
each destination endpoint contained in the matching entry in the binding table. 10
The APSDE shall then transmit each frame using the NWK data service. 11
If the APSDE of a device receives a transmission with the delivery mode sub-field 12
of the frame control field set to 0b11 indicating group addressing, it shall deliver 13
the frame to each endpoint on the device that is associated in the group table with 14
16-bit group address found in the group address field of the APS header. 15
Similarly, if the APSDE of a device receives a NLDE-DATA.request primitive 16
where the DstAddrMode parameter has a value of 0x01, also indicating group 17
addressing, it shall deliver the frame to each endpoint on the device that is 18
associated in the group table with the 16-bit group address given as the value of 19
the DstAddress parameter.5 In either case, it shall search the group table and, for 20
each endpoint associated with the given group address it shall issue the APSDE- 21
DATA.indication primitive to the next higher layer with a value of the 22
DstEndpoint parameter equal to the number of the associated endpoint. All other 23
parameters of the APSDE-DATA.indication primitive shall remain the same for 24
all instances of the primitive issued. 25
26
The APSDE shall maintain a duplicate rejection table to include at least source 27
address, APS counter and timing information such that frames transmitted 28
according to this specification and received more than once are identified as 29
duplicates and only delivered to the NHLE once. The size of this table shall be at 30
least apscMinDuplicateRejectionTableSize. 31
2.2.8.3.3 Use of Acknowledgements 32
33
A data or APS command frame shall be sent with its acknowledgement request 34
sub-field set appropriately for the frame. An acknowledgement frame shall always 35
be sent with the acknowledgement request sub-field set to 0. Similarly, any frame 36
that is broadcast shall be sent with its acknowledgement request sub-field set to 0. 37
38
2.2.8.3.3.1 No Acknowledgement 39
40
A frame that is received by its intended recipient with its acknowledgement
41
request (AR) sub-field set to 0 shall not be acknowledged. The originating device
42
43
5. CCB #624 44
45
shall assume that the transmission of the frame was successful. Figure 2.10 shows
the scenario for transmitting a single frame of data from an originator to a 1
recipient without requiring an acknowledgement. In this case, the originator 2
transmits the data frame with the AR sub-field equal to 0. 3
4
5
Originator Recipient 6
next higher Originator Recipient next higher
layer APS APS layer 7
8
APSDE-DATA.request (AR=0)
Data (AR=0) 9
APSDE-DATA.confirm APSDE-DATA.indication 10
11
12
13
14
Figure 2.10 Successful Data Transmission Without an Acknowledgement 15
16
2.2.8.3.3.2 Acknowledgement 17
A frame that is received by its intended recipient with its acknowledgement 18
request (AR) sub-field set to 1 shall be acknowledged. If the intended recipient 19
correctly receives the frame, it shall generate and send an acknowledgement 20
frame to the originator of the frame that is being acknowledged. 21
22
If the original transmission used indirect addressing, the ZigBee coordinator shall 23
send an acknowledgement to the originator then, for each reflected message, shall 24
indicate to the recipient that it requires an acknowledgement by transmitting the 25
data frame with the acknowledgement request sub-field of the frame control field 26
set to 1. 27
The transmission of an acknowledgement frame shall commence when the APS 28
sub-layer determines that the frame is valid. 29
30
Figure 2.11 shows the scenario for transmitting a single frame of data from an 31
originator to a recipient with an acknowledgement. In this case, the originator 32
indicates to the recipient that it requires an acknowledgement by transmitting the 33
data frame with the AR sub-field set to 1. 34
35
36
37
38
39
40
41
42
43
44
45
Chapter 2
Originator Recipient 1
next higher Originator Recipient next higher
layer APS APS layer 2
APSDE-DATA.request (AR=1)
3
Data (AR=1) 4
5
Acknowldgement
6
APSDE-DATA.indication
7
APSDE-DATA.confirm 8
9
10
11
Figure 2.11 Successful Data Transmission With an Acknowledgement 12
13
2.2.8.3.4 Retransmissions 14
A device that sends a frame with its acknowledgement request sub-field set to 0 15
shall assume that the transmission was successfully received and shall hence not 16
perform the retransmission procedure. 17
18
A device that sends a frame with its acknowledgement request sub-field set to 1 19
shall wait for at most apscAckWaitDuration seconds for the corresponding 20
acknowledgement frame to be received. 21
If an acknowledgement frame is received within apscAckWaitDuration seconds 22
containing the same cluster identifier and APS counter as the original frame and 23
has a source endpoint equal to the destination endpoint to which the original frame 24
was transmitted, the transmission shall be considered successful and no further 25
action shall be taken by the device. If an acknowledgement is not received within 26
apscAckWaitDuration seconds or an acknowledgement is received within 27
apscAckWaitDuration seconds but contains an unexpected cluster identifier or 28
APS counter or has a source endpoint that is not equal to the destination endpoint 29
to which the original frame was transmitted, the device shall conclude that the 30
single transmission attempt has failed. 31
32
If a single transmission attempt has failed, the device shall repeat the process of 33
transmitting the frame and waiting for the acknowledgement, up to a maximum of 34
apscMaxFrameRetries times. If an acknowledgement is still not received after 35
apscMaxFrameRetries retransmissions, the APS sub-layer shall assume the 36
transmission has failed and notify the next higher layer of the failure. 37
Retransmissions of a secured frame shall use the same frame counter as the 38
original frame. 39
40
41
42
43
44
45
2.3 The ZigBee Application Framework 1

2
2.3.1 Creating a ZigBee Profile 3
4
The key to communicating between devices on a ZigBee network is agreement on 5
a profile. 6
7
An example of a profile would be home automation. This ZigBee profile permits 8
a series of device types to exchange control messages to form a wireless home 9
automation application. These devices are designed to exchange well known 10
messages to effect control such as turning a lamp on or off, sending a light sensor 11
measurement to a lighting controller or sending an alert message if an occupancy 12
sensor detects movement. 13
An example of another type of profile is the device profile that defines common 14
actions between ZigBee devices. To illustrate, wireless networks rely on the 15
ability for autonomous devices to join a network and discover other devices and 16
services on devices within the network. Device and service discovery are features 17
supported within the device profile. 18
19
2.3.1.1 Getting a Profile Identifier from the ZigBee Alliance 20
21
ZigBee defines profiles in two separate classes: private and public. The exact 22
definition and criteria for these classes are an administrative issue within the 23
ZigBee Alliance and outside the scope of this document. For the purposes of this 24
technical specification, the only criterion is for profile identifiers to be unique. To 25
that end, every profile effort must start with a request to the ZigBee Alliance for 26
allocation of a profile identifier. Once the profile identifier is obtained, that profile 27
identifier permits the profile designer to define the following: 28
29
• Device descriptions
30
• Cluster identifiers 31
32
The application of profile identifiers to market space is a key criterion for issuance
33
of a profile identifier from the ZigBee Alliance. The profile needs to cover a broad
34
enough range of devices to permit interoperability to occur between devices
35
without being overly broad and resulting in a shortage of cluster identifiers to
36
describe their interfaces. Conversely, the profile cannot be defined to be too
37
narrow resulting in many devices described by individual profile identifiers
38
resulting in a waste of the profile identifier addressing space and interoperability
39
issues in describing how the devices are interfaced. Policy groups within the
40
ZigBee Alliance will establish criteria on how profiles are to be defined and to
41
help requestors tailor their profile identifier requests.
42
43
44
45
Chapter 2
2.3.1.2 Defining Device Descriptions and Clusters

1
The profile identifier is the main enumeration feature within the ZigBee protocol. 2
Each unique profile identifier defines an associated enumeration of device 3
descriptions and cluster identifiers. For example, for profile identifier “1”, there 4
exists a pool of device descriptions described by a 16-bit value (meaning there are 5
65,536 possible device descriptions within each profile) and a pool of cluster 6
identifiers described by a 16-bit value (meaning there are 65,536 possible cluster 7
identifiers within each profile). Each cluster identifier also supports a pool of 8
attributes described by a 16-bit value. As such, each profile identifier has up to 9
65,536 cluster identifiers and each of those cluster identifiers contain up to 65,536 10
attributes. It is the responsibility of the profile developer to define and allocate 11
device descriptions, cluster identifiers and attributes within their allocated profile 12
identifier. Note that the definition of device descriptions, cluster identifiers and 13
attribute identifiers must be undertaken with care to ensure efficient creation of 14
simple descriptors and simplified processing when exchanging messages. 15
16
Device descriptions and cluster identifiers must be accompanied by knowledge of
17
the profile identifier to be processed. Prior to any messages being directed to a
18
device, it is assumed by the ZigBee protocol that service discovery has been
19
employed to determine profile support on devices and endpoints. Likewise, the
20
binding process assumes similar service discovery and profile matching has
21
occurred since the resulting match is distilled to source address, source endpoint,
22
cluster identifier, destination address and destination endpoint.
23
2.3.1.3 Deploying the Profile on Endpoints 24
25
A single ZigBee device may contain support for many profiles, provide for 26
subsets of various cluster identifiers defined within those profiles and may support 27
multiple device descriptions. This capability is defined using a hierarchy of 28
addressing within the device as follows: 29
30
• Device: the entire device is supported by a single radio with a unique IEEE and 31
NWK address. 32
• Endpoints: this is an 8-bit field that describes different applications that are 33
supported by a single radio. Endpoint 0x00 is used to address the device 34
profile, which each ZigBee device must employ, endpoint 0xff is used to 35
address all active endpoints (the broadcast endpoint) and endpoints 0xf1-0xfe 36
are reserved. Consequently, a single physical ZigBee radio can support up to 37
240 applications on endpoints 0x01-0xf0. 38
39
It is an application decision as to how to deploy applications on a device endpoint 40
and which endpoints to advertise. The only requirement is that simple descriptors 41
be created for each endpoint and those descriptors made available for service 42
discovery. 43
44
45
2.3.1.4 Enabling Service Discovery

1
Once a device is created to support specific profiles and made consistent with 2
cluster identifier usage for device descriptions within those profiles, the 3
applications can be deployed. To do this, each application is assigned to individual 4
endpoints and each described using simple descriptors. It is via the simple 5
descriptors and other service discovery mechanisms described in the ZigBee 6
device profile that service discovery is enabled, binding of devices is supported 7
and application messaging between complementary devices facilitated. 8
9
One important point is that service discovery is made on the basis of profile
10
identifier, input cluster identifier list and output cluster identifier list (device
11
description is notably missing). The device description is simply a convention for
12
specifying mandatory and optional cluster identifier support within devices of that
13
type for the indicated profile. Additionally, it is expected that the device
14
description enumeration would be employed within PDAs or other assisted
15
binding devices to provide external descriptions of device capabilities.
16
2.3.1.5 Mixing Standard and Proprietary Profiles 17
18
As an example, a ZigBee device could be created with a single endpoint 19
application written for a standard, published ZigBee profile identifier “XX”. If a 20
manufacturer wanted to deploy a ZigBee device supporting the standard profile 21
“XX” and also provide vendor specific extensions, these extensions would be 22
advertised on a separate endpoint. Devices that support the standard profile 23
identifier “XX” but not manufactured with the vendor extensions, would only 24
advertise support for the single profile identifier “XX” and could not respond to or 25
create messages using the vendor extensions. 26
27
2.3.1.6 Enabling Backward Compatibility 28
29
In the previous example, a device is created using a standard, published ZigBee 30
profile identifier “XX” which contains the initial version of the standard profile. If 31
the ZigBee Alliance were to update this standard profile to create new features 32
and additions, the revisions would be incorporated into a new standard profile 33
with a new profile identifier (say “XY”). Devices manufactured with just profile 34
identifier “XX” would be backward compatible with newer devices manufactured 35
later by having the newer devices advertise support for both profile identifier 36
“XX” and profile identifier “XY”. In this manner, the newer device may 37
communicate with older devices using profile identifier “XX”, however, also 38
communicate with newer devices using profile identifier “XY” from within the 39
same application. The service discovery feature within ZigBee enables devices on 40
the network to determine the level of support. 41
42
43
44
45
Chapter 2
2.3.2 ZigBee Descriptors 1

2
ZigBee devices describe themselves using descriptor data structures. The actual
3
data contained in these descriptors is defined in the individual device descriptions.
4
There are five descriptors: node, node power, simple, complex and user, shown in
5
Table 2.25.
6
Table 2.25 ZigBee Descriptors 7
Descriptor 8
Name Status Description 9
10
Node M Type and capabilities of the node 11
Node power M Node power characteristics 12
13
Simple M Device descriptions contained in node
14
Complex O Further information about the device descriptions 15
User O User-definable descriptor 16
17
18
2.3.2.1 Transmission of Descriptors 19
The node, node power, simple and user descriptors shall be transmitted in the 20
order that they appear in their respective tables, i.e., the field at the top of the table 21
is transmitted first and the field at the bottom of the table is transmitted last. Each 22
individual field shall follow the transmission order specified in (Chapter 1). 23
24
The complex descriptor shall be formatted and transmitted as illustrated in 25
Figure 2.12. 26
27
Octets: 1 Variable … Variable 28
Field count Field 1 … Field n 29
30
31
Figure 2.12 Format of the Complex Descriptor 32
33
Each field included in the complex descriptor shall be formatted as illustrated in
34
Figure 2.13.
35
36
Octets: 1 Variable
37
Compressed Field data 38
XML tag 39
40
Figure 2.13 Format of an Individual Complex Descriptor Field 41
42
43
44
45
2.3.2.1.1 Field Count Field

1
The field count field is one octet in length and specifies the number of fields 2
included in the descriptor, each formatted as illustrated in Figure . 3
4
2.3.2.1.1.1 Compressed XML Tag Field 5
6
The compressed XML tag field is one octet in length and specifies the XML tag
7
for the current field. The compressed XML tags for the complex descriptor are
8
listed in Table 2.37.
9
10
2.3.2.1.1.2 Field Data Field 11
The field data field has a variable length and contains the information specific to 12
the current field, as indicated by the compressed XML tag field. 13
14
2.3.2.2 Discovery via Descriptors 15
16
Descriptor information is queried in the ZDO management entity device and 17
service discovery using the ZigBee device profile request primitive addressed to 18
endpoint 0. For details of the discovery operation, see sub-clause 2.1.5. 19
Information is returned via the ZigBee device profile indication primitive. 20
The node, node power, complex and user descriptors apply to the complete node. 21
The simple descriptor must be specified for each endpoint defined in the node. If a 22
node contains multiple subunits, these will be on separate endpoints and the 23
specific descriptors for these endpoints are read by including the relevant endpoint 24
number in the ZigBee device profile primitive. 25
26
2.3.2.3 Composite Devices 27
28
A ZigBee node may contain a number of separate subunits, each of which has its 29
own simple descriptor. The mechanism for discovering this is described in ZigBee 30
device profile service discovery section. 31
32
2.3.2.4 Node Descriptor 33
The node descriptor contains information about the capabilities of the ZigBee 34
node and is mandatory for each node. There shall be only one node descriptor in a 35
node. 36
37
38
39
40
41
42
43
44
45
Chapter 2
The fields of the node descriptor are shown in Table 2.26 in their order of
transmission. 1
2
Table 2.26 Fields of the Node Descriptor
3
Field Name Length (bits) 4
5
Logical type 3 6
Complex descriptor available 1 7
User descriptor available 1 8
9
Reserved 3 10
APS flags 3 11
12
Frequency band 5
13
MAC capability flags 8 14
Manufacturer code 16 15
16
Maximum buffer size 8
17
Maximum transfer size 16 18
Server Mask 16 19
20
21
2.3.2.4.1 Logical Type Field
22
The logical type field of the node descriptor is three bits in length and specifies the 23
device type of the ZigBee node. The logical type field shall be set to one of the 24
non-reserved values listed in Table 2.27. 25
26
Table 2.27 Values of the Logical Type Field
27
Logical Type Value 28
b 2b1b0 Description 29
000 ZigBee coordinator 30
31
001 ZigBee router 32
010 ZigBee end device 33
34
011-111 Reserved
35
36
2.3.2.4.2 Complex Descriptor Available Field 37
The complex descriptor available field of the node descriptor is one bit in length 38
and specifies whether a complex descriptor is available on this device. If this 39
field is set to 1, a complex descriptor is available. If this field is set to 0, a complex 40
descriptor is not available. 41
42
43
44
45
2.3.2.4.3 User Descriptor Available Field

1
The user descriptor available field of the node descriptor is one bit in length and 2
specifies whether a user descriptor is available on this device. If this field is set to 3
1, a user descriptor is available. If this field is set to 0, a user descriptor is not 4
available. 5
2.3.2.4.4 APS Flags Field 6
7
The APS flags field of the node descriptor is three bits in length and specifies the 8
application support sub-layer capabilities of the node. 9
This field is currently not supported and shall be set to zero. 10
11
2.3.2.4.5 Frequency Band Field 12
13
The frequency band field of the node descriptor is five bits in length and specifies
14
the frequency bands that are supported by the underlying IEEE 802.15.4 radio
15
utilized by the node. For each frequency band supported by the underlying IEEE
16
802.15.4 radio, the corresponding bit of the frequency band field, as listed in
17
Table 2.28, shall be set to 1. All other bits shall be set to 0.
18
Table 2.28 Values of the Frequency Band Field 19
Frequency 20
Band Field Bit Supported Frequency 21
Number Band 22
23
0 868 – 868.6 MHz
24
1 Reserved 25
2 902 – 928 MHz 26
27
3 2400 – 2483.5 MHz 28
4 Reserved 29
30
2.3.2.4.6 MAC Capability Flags Field 31
32
The MAC capability flags field is eight bits in length and specifies the node 33
capabilities, as required by the IEEE 802.15.4 MAC sub-layer [B1]. The MAC 34
capability flags field shall be formatted as illustrated in Figure 2.14. 35
36
Bits: 0 1 2 3 4-5 6 7 37
Alternate Device Power Receiver on Reserved Security Allocate 38
PAN type source when idle capability address 39
coordinator 40
41
Figure 2.14 Format of the MAC Capability Flags Field 42
43
44
45
Chapter 2
The alternate PAN coordinator sub-field is one bit in length and shall be set to 1 if
this node is capable of becoming a PAN coordinator. Otherwise the alternative 1
PAN coordinator sub-field shall be set to 0. 2
3
The device type sub-field is one bit in length and shall be set to 1 if this node is a 4
full function device (FFD). Otherwise the device type sub-field shall be set to 0, 5
indicating a reduced function device (RFD). 6
The power source sub-field is one bit in length and shall be set to 1 if the current 7
power source is mains power. Otherwise the power source sub-field shall be set to 8
0. This information is derived from the node current power source field of the 9
node power descriptor. 10
11
The receiver on when idle sub-field is one bit in length and shall be set to 1 if the 12
device does not disable its receiver to conserve power during idle periods. 13
Otherwise the receiver on when idle sub-field shall be set to 0 (see also sub- 14
clause 2.3.2.5.) 15
The security capability sub-field is one bit in length and shall be set to 1 if the 16
device is capable of sending and receiving frames secured using the security suite 17
specified in [B1]. Otherwise the security capability sub-field shall be set to 0. 18
19
The allocate address sub-field is one bit in length and shall always be set to 1. 20
2.3.2.4.7 Manufacturer Code Field 21
22
The manufacturer code field of the node descriptor is sixteen bits in length and 23
specifies a manufacturer code that is allocated by the ZigBee Alliance, relating the 24
manufacturer to the device. 25
2.3.2.4.8 Maximum Buffer Size Field 26
27
The maximum buffer size field of the node descriptor is eight bits in length, with a 28
valid range of 0x00-0x7f, and specifies the maximum size, in octets, of the 29
application support sub-layer data unit (ASDU) for this node. This is the 30
maximum size of data or commands passed to or from the application by the 31
application support sub-layer, before any fragmentation or re-assembly 32
(fragmentation is not currently supported). 33
This field can be used as a high-level indication for network management. 34
35
2.3.2.4.9 Maximum Transfer Size Field 36
37
The maximum transfer size field of the node descriptor is sixteen bits in length,
38
with a valid range of 0x0000-0x7fff, and specifies the maximum size, in octets,
39
that can be transferred to or from this node in one single message transfer. This
40
value can exceed the value of the node maximum buffer size field (see sub-
41
clause 2.3.2.4.8).
42
This field is currently not supported and shall be set to zero. 43
44
45
2.3.2.4.10 Server Mask Field

1
The server mask field of the node descriptor is sixteen bits in length, with bit 2
settings signifying the system server capabilities of this node. It is used to 3
facilitate discovery of particular system servers by other nodes on the system. The 4
bit settings are defined inTable 2.29. 5
Table 2.29 Server Mask Bit Assignments 6
7
Bit Number Assignment 8
0 Primary Trust Center 9
10
1 Backup Trust Center
11
2 Primary Binding Table Cache 12
3 Backup Binding Table Cache 13
14
4 Primary Discovery Cache 15
5 Backup Discovery Cache 16
6 – 15 Reserved
17
18
19
2.3.2.5 Node Power Descriptor 20
The node power descriptor gives a dynamic indication of the power status of the 21
node and is mandatory for each node. There shall be only one node power 22
descriptor in a node. 23
24
The fields of the node power descriptor are shown in Table 2.30 in the order of 25
their transmission. 26
Table 2.30 Fields of the Node Power Descriptor 27
28
Field Name Length (Bits) 29
Current power mode 4 30
31
Available power sources 4 32
Current power source 4 33
Current power source level 4
34
35
36
37
38
39
40
41
42
43
44
45
Chapter 2
2.3.2.5.1 Current Power Mode Field

1
The current power mode field of the node power descriptor is four bits in length 2
and specifies the current sleep/power-saving mode of the node. The current power 3
mode field shall be set to one of the non-reserved values listed in Table 2.31. 4
Table 2.31 Values of the Current Power Mode Field 5
6
Current Power Mode 7
Value b3b2b1b0 Description
8
0000 Receiver synchronized with the receiver on when idle sub- 9
field of the node descriptor 10
0001 Receiver comes on periodically as defined by the node 11
power descriptor 12
13
0010 Receiver comes on when stimulated, e.g. by a user pressing a
button 14
15
0011-1111 Reserved 16
17
2.3.2.5.2 Available Power Sources Field 18
19
The available power sources field of the node power descriptor is four bits in
20
length and specifies the power sources available on this node. For each power
21
source supported on this node, the corresponding bit of the available power
22
sources field, as listed in Table 2.32, shall be set to 1. All other bits shall be set to
23
0.
24
Table 2.32 Values of the Available Power Sources Field 25
26
Available Power Sources
Field Bit Number Supported Power Source 27
28
0 Constant (mains) power 29
1 Rechargeable battery 30
31
2 Disposable battery
32
3 Reserved 33
34
2.3.2.5.3 Current Power Source Field 35
36
The current power source field of the node power descriptor is four bits in length 37
and specifies the current power source being utilized by the node. For the current 38
39
40
41
42
43
44
45
power source selected, the corresponding bit of the current power source field, as
listed in Table 2.33, shall be set to 1. All other bits shall be set to 0. 1
2
Table 2.33 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.5.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.34. 17
18
Table 2.34 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.6 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
Chapter 2
The fields of the simple descriptor are shown in Table 2.35 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 maxCommandSize. 2
3
Table 2.35 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.6.1 Endpoint Field
22
The endpoint field of the simple descriptor is eight bits in length and specifies the 23
endpoint within the node to which this description refers. Applications shall only 24
use endpoints 1-240. 25
26
2.3.2.6.2 Application Profile Identifier Field
27
The application profile identifier field of the simple descriptor is sixteen bits in 28
length and specifies the profile that is supported on this endpoint. Profile 29
identifiers shall be obtained from the ZigBee Alliance. 30
31
2.3.2.6.3 Application Device Identifier Field 32
The application device identifier field of the simple descriptor is sixteen bits in 33
length and specifies the device description supported on this endpoint. Device 34
description identifiers shall be obtained from the ZigBee Alliance. 35
36
2.3.2.6.4 Application Device Version Field 37
The application device version field of the simple descriptor is four bits in length 38
and specifies the version of the device description supported on this endpoint. The 39
40
41
42
43
44
45
application device version field shall be set to one of the non-reserved values
listed in Table 2.36. 1
2
Table 2.36 Values of the Application Device Version Field
3
Application Device Version 4
Value b3b2b1b0 Description 5
6
0000 Version 1.0
7
0001–1111 Reserved 8
9
2.3.2.6.5 Application Input Cluster Count Field 10
11
The application input cluster count field of the simple descriptor is eight bits in 12
length and specifies the number of input clusters, supported on this endpoint, that 13
will appear in the application input cluster list field. If the value of this field is 14
zero, the application input cluster list field shall not be included. 15
2.3.2.6.6 Application Input Cluster List 16
17
The application input cluster list of the simple descriptor is 16*i bits in length , 18
where i is the value of the application input cluster count field, and specifies the 19
list of input clusters supported on this endpoint, used during the binding 20
procedure. 21
The application input cluster list field shall be included only if the value of the 22
application input cluster count field is greater than zero. 23
24
2.3.2.6.7 Application Output Cluster Count Field 25
The application output cluster count field of the simple descriptor is eight bits in 26
length and specifies the number of output clusters, supported on this endpoint, that 27
will appear in the application output cluster list field. If the value of this field is 28
zero, the application output cluster list field shall not be included. 29
30
2.3.2.6.8 Application Output Cluster List 31
32
The application output cluster list of the simple descriptor is 16*o bits in length,
33
where o is the value of the application output cluster count field, and specifies the
34
list of output clusters supported on this endpoint, used during the binding
35
procedure.
36
The application output cluster list field shall be included only if the value of the 37
application output cluster count field is greater than zero. 38
39
2.3.2.7 Complex Descriptor 40
41
The complex descriptor contains extended information for each of the device
42
descriptions contained in this node. The use of the complex descriptor is optional.
43
44
45
Chapter 2
Due to the extended and complex nature of the data in this descriptor it is
presented in XML form using compressed XML tags. Each field of the descriptor, 1
shown in Table 2.37, can therefore be transmitted in any order. As this descriptor 2
needs to be transmitted over air, the overall length of the complex descriptor shall 3
be less than or equal to maxCommandSize. 4
5
Table 2.37 Fields of the Complex Descriptor
6
Compressed 7
XML Tag 8
Value 9
Field Name XML Tag b 3 b 2b 1 b 0 Data Type 10
Reserved - 0000 - 11
12
Language and character set <languageChar> 0001 See sub-
clause 2.3.2.7.1 13
14
Manufacturer name <manufacturerName> 0010 Character string 15
Model name <modelName> 0011 Character string 16
17
Serial number <serialNumber> 0100 Character string
18
Device URL <deviceURL> 0101 Character string 19
Icon <icon> 0110 Octet string 20
21
Icon URL <outliner> 0111 Character string
22
Reserved - 1000 – 1111 - 23
24
2.3.2.7.1 Language and Character Set Field 25
26
The language and character set field is three octets in length and specifies the 27
language and character set used by the character strings in the complex descriptor. 28
The format of the language and character set field is illustrated in Figure 2.15. 29
30
Octets: 2 1 31
ISO 639-1 language code Character set identifier 32
33
34
Figure 2.15 Format of the Language and Character Set Field 35
36
The ISO 639-1 language code sub-field is two octets in length and specifies the
37
language used for character strings, as defined in [B5].
38
39
40
41
42
43
44
45
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.38. 2
3
Table 2.38 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.7.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.7.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.7.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.7.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.7.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. The 35
format of the icon shall be a 32-by-32-pixel PNG image. 36
37
2.3.2.7.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
Chapter 2
2.3.2.8 User Descriptor

1
The user descriptor contains information that allows the user to identify the device 2
using a user-friendly character string, such as “Bedroom TV” or “Stairs light”. 3
The use of the user descriptor is optional. This descriptor contains a single field, 4
which uses the ASCII character set,6 and shall contain a maximum of 16 5
characters. 6
7
The fields of the user descriptor are shown in Table 2.39 in the order of their
8
transmission.
9
Table 2.39 Fields of the User Descriptor 10
Field Name Length (Octets) 11
12
User description 16 13
14
15
2.3.3 Functional Description 16
17
2.3.3.1 Reception and Rejection 18
The application framework shall be able to filter frames arriving via the APS sub- 19
layer data service and only present the frames that are of interest to the 20
applications implemented on each active endpoint. 21
22
The application framework receives data from the APS sub-layer via the APSDE- 23
DATA.indication primitive and is targeted at a specific endpoint (DstEndpoint 24
parameter) and a specific profile (ProfileId parameter). 25
If the application framework receives a frame for an inactive endpoint, the frame 26
shall be discarded. Otherwise, the application framework shall determine whether 27
the specified profile identifier matches the identifier of the profile implemented on 28
the specified endpoint. If the profile identifier does not match, the application 29
framework shall reject the frame. Otherwise, the application framework shall pass 30
the payload of the received frame to the application implemented on the specified 31
endpoint. 32
33
34
2.4 The ZigBee Device Profile 35
36
37
2.4.1 Scope 38
39
This ZigBee Application Layer Specification describes how general ZigBee 40
device features such as Binding, Device Discovery and Service Discovery are 41
42
43
6. CCB #604 44
45
implemented within ZigBee Device Objects. The ZigBee Device Profile operates
like any ZigBee profile by defining Device Descriptions and Clusters. Unlike 1
application specific profiles, the Device Descriptions and Clusters within the 2
ZigBee Device Profile define capabilities supported in all ZigBee devices. As 3
with any profile document, this document details the mandatory and/or optional 4
clusters. 5
6
7
2.4.2 Device Profile Overview 8
9
The Device Profile supports four key inter-device communication functions 10
within the ZigBee protocol. These functions are explained in the following 11
sections: 12
• Device and Service Discovery Overview 13
14
• End Device Bind Overview 15
• Bind and Unbind Overview 16
17
• Binding Table Management Overview 18
19
2.4.2.1 Device and Service Discovery Overview 20
Device Discovery is a distributed operation where individual devices or 21
designated discovery cache devices respond to discovery requests. The “device 22
address of interest” field enables response from either the device itself or a 23
discovery cache device. In selected cases where the discovery cache device and 24
the “device address of interest” device also responds, the response from the 25
“device address of interest” shall be used. 26
27
Service Discovery is a distributed operation where individual devices or 28
designated discovery cache devices respond to discovery requests. The “device 29
address of interest” field enables responses from either the device itself or a 30
discovery cache device. In cases, where both the discovery cache device and the 31
“device address of interest” devices respond, the response from the “device 32
address of interest” shall be used. 33
The following capabilities exist for device and service discovery: 34
35
• Device Discovery: Provides the ability for a device to determine the identity of 36
other devices on the PAN. Device Discovery is supported for both the 64 bit 37
IEEE address and the 16 bit Network address. 38
• Device Discovery messages can be used in one of two ways: 39
40
—Broadcast addressed: All devices on the network shall respond accord- 41
ing to the Logical Device Type and match criteria. ZigBee End Devices 42
shall respond with just their address. ZigBee Coordinators and ZigBee 43
Routers with associated devices shall respond with their address as the 44
45
Chapter 2
first entry followed by the addresses of their associated devices depend-

ing on the type of request. The responding devices shall employ APS 1
acknowledged service on the unicast responses. 2
3
—Unicast addressed: Only the specified device responds. A ZigBee End 4
Devices shall respond only with its address. A ZigBee Coordinator or 5
Router shall reply with its own address and the addresses of each associ- 6
ated child devices. Inclusion of the associated child devices permit the 7
requestor to determine the network topology underlying the specified 8
device. 9
10
• Service Discovery: Provides the ability for a device to determine services 11
offered by other devices on the PAN. 12
13
• Service Discovery messages can be used in one of two ways:
14
—Broadcast addressed: Due to the volume of information that could be 15
returned, only the individual device or the primary discovery cache shall 16
respond with match criteria established in the request. The primary dis- 17
covery cache shall only respond in this case if it holds cached discovery 18
information for the NWKAddrOfInterest from the request. The respond- 19
ing devices shall also employ APS acknowledged service on the unicast 20
21
responses.
22
—Unicast addressed: Only the specified device shall respond. In the case 23
of a ZigBee Coordinator or ZigBee Router, these devices shall cache the 24
Service Discovery information for sleeping associated devices and 25
respond on their behalf. 26
27
• Service Discovery is supported with the following query types: 28
—Active Endpoint: This command permits an enquiring device to deter- 29
30
mine the active endpoints. An active endpoint is one with an application
31
supporting a single profile, described by a Simple Descriptor. The com- 32
mand may be broadcast or unicast addressed. 33
—Match Simple Descriptor: This command permits enquiring devices to 34
supply a Profile ID and, optionally, lists of input and/or output Cluster 35
IDs and ask for a return of the identity of an endpoint on the destination 36
37
device which match the supplied criteria. This command may be broad-
38
cast to all RxOnWhenIdle devices or unicast addressed. For broadcast 39
addressed requests, the responding device shall employ APS acknowl- 40
edged service on the unicast responses. 41
42
43
44
45
—Simple Descriptor: This command permits an enquiring device to

return the Simple Descriptor for the supplied endpoint. This command 1
shall be unicast addressed. 2
3
—Node Descriptor: This command permits an enquiring device to return 4
the Node Descriptor from the specified device. This command shall be 5
unicast addressed. 6
7
—Power Descriptor: This command permits an enquiring device to 8
return the Power Descriptor from the specified device. This command 9
11
—Complex Descriptor: This optional command permits an enquiring
12
device to return the Complex Descriptor from the specified device. This 13
command shall be unicast addressed. 14
—User Descriptor: This optional command permits an enquiring device 15
to return the User Descriptor from the specified device. This command 16
18
2.4.2.2 End Device Bind Overview 19
20
The following capabilities exist for end device bind: 21
22
• End Device Bind: 23
• Provides the ability for an application to support “simple binding” where 24
user intervention is employed to identify command/control device pairs. 25
Typical usage would be where a user is asked to push buttons on two devices 26
for installation purposes. 27
28
• Provides the ability for an application to support a simplified method of
29
binding where user intervention is employed to identify command/control 30
device pairs. Typical usage would be where a user is asked to push buttons 31
on two devices for installation purposes. Using this mechanism a second 32
time allows the user to remove the binding table entry. 33
34
2.4.2.3 Bind and Unbind Overview 35
The following capabilities exist for directly configuring binding table entries: 36
37
• Bind: 38
• Provides the ability for creation of a Binding Table entry that map control 39
messages to their intended destination. 40
41
• Unbind: 42
• Provides the ability to remove Binding Table entries. 43
44
45
Chapter 2
2.4.2.4 Binding Table Management Overview

1
The following capabilities exist for management of bind tables: 2
3
• Registering devices that implement source binding (where source binding is
4
defined to be the ability for a device that is a client and, supplying requests,
5
holds a record of the server destination that are the desired targets of the
6
recipients) :
7
• Provides the ability for a source device to instruct its primary binding table 8
cache to hold its own binding table 9
10
• Replacing a device with another wherever it occurs in the bind table:
11
• Provides the ability to replace one device for another, by replacing all 12
instances of its address in the binding table 13
14
• Backing up a bind table entry:
15
• Provides the ability for a primary binding table cache to send details of a 16
newly created entry to the backup binding table cache (after receiving a bind 17
request) 18
19
• Removing a backup binding table entry:
20
• Provides the ability for a primary binding table cache to request that a 21
specific entry be removed from the backup binding table cache (after 22
receiving an unbind request) 23
24
• Backing up of the entire binding table:
25
• Provides the ability for a primary binding table cache to request backup of 26
its entire binding table, using the backup binding table cache 27
28
• Restoring the entire binding table:
29
• Provides the ability for a primary binding table cache to request restoration 30
of its entire binding table, using the backup binding table cache 31
32
• Backing up the Primary Binding Table Cache (which contains the addresses of
33
any source device registered to support its own binding table):
34
• Provides the ability for a primary binding table cache to request backup of 35
its entire source devices address table (which contains the addresses of any 36
source device containing its own binding table) 37
38
• Restoring the Primary Binding Table Cache (which contains the addresses of
39
any source device registered to support its own binding table):
40
• Provides the ability for a primary binding table cache to request restoration 41
of its entire source devices address table (which contains the addresses of 42
any source device containing its own binding table) 43
44
45
2.4.2.5 Network Management Overview

1
The following capabilities exist for network management: 2
3
Network management:
4
• Provides the ability to retrieve management information from the devices 5
including: 6
7
• Network discovery results
8
• Link quality to neighbor nodes 9
10
• Routing table contents
11
• Binding table contents 12
13
• Provides the ability to set management information controls including:
14
• Network disassociate 15
16
2.4.2.6 Device Descriptions for the Device Profile 17
18
The ZigBee Device Profile utilizes a single Device Description. Each cluster 19
specified as Mandatory shall be present in all ZigBee devices. The response 20
behavior to some messages is logical device type specific. The support for 21
Optional clusters is not dependent on the logical device type. 22
23
2.4.2.7 Configuration and Roles 24
The Device Profile assumes a client/server topology. A device making Device 25
Discovery, Service Discovery, Binding or Network Management requests does so 26
via a client role. A device which services these requests and responds does so via 27
a server role. The client and server roles are non-exclusive in that a given device 28
may supply both client and server roles. 29
30
Since many client requests and server responses are public and accessible to 31
application objects other than ZigBee Device Objects, the Transaction Sequence 32
number in the Application Framework header shall be the same on client requests 33
and their associated server responses. 34
The Device Profile describes devices in one of two configurations: 35
36
• Client: A client issues requests to the server via Device Profile messages 37
• Server: A server issues responses to the client that initiated the Device Profile 38
message 39
40
In neither the client or server roles of the Device Profile shall indirect messaging 41
be used. Specifically, due to the omission of a Simple Descriptor for the Device 42
Profile and due to the role of the Device Profile in discovery itself, the use of 43
44
45
Chapter 2
binding and indirect messaging on endpoint 0 is prohibited for client or server

operations. 1
2
2.4.2.8 Transmission of ZDP Commands 3
4
All ZDP commands shall be transmitted via the APS data service and shall be 5
formatted according to the ZDP frame structure, as illustrated in Figure 2.16. 6
7
Octets: 1 Variable
8
Transaction sequence number Transaction data 9
10
Figure 2.16 Format of the ZDP Frame 11
12
2.4.2.8.1 Transaction Sequence Number Field 13
The transaction sequence number field is eight bits in length and specifies an 14
identification number for the ZDP transaction so that a response command frame 15
can be related to the request frame. The application object itself shall maintain an 16
8-bit counter that is copied into this field and incremented by one for each 17
command sent. When a value of 0xff is reached, the next command shall re-start 18
the counter with a value of 0x00. 19
20
If a device sends a ZDP request command that requires a response, the target 21
device shall respond with the relevant ZDP response command and include the 22
transaction sequence number contained in the original request command. 23
The transaction sequence number field can be used by a controlling device, which 24
may have issued multiple commands, so that it can match the incoming responses 25
to the relevant command. 26
27
2.4.2.8.2 Transaction Data Field 28
29
The transaction data field has a variable length and contains the data for the
30
individual ZDP transaction. The format and length of this field is dependent on
31
the command being transmitted, as defined in sub-clauses 2.4.3 and 2.4.4.
32
33
2.4.3 Client Services 34
35
The Device Profile Client Services supports the transport of device and service 36
discovery requests, end device binding requests, bind requests unbind requests 37
and network management requests from client to server. Additionally, Client 38
Services support receipt of responses to these requests from the server. 39
40
41
42
43
44
45
2.4.3.1 Device and Service Discovery Client Services

1
Table 2.40 lists the commands supported by Device Profile, Device and Service 2
Discovery Client Services. Each of these commands will be discussed in the 3
following subclauses. 4
Table 2.40 Device and Service Discovery Client Services Commands 5
6
Device and Service 7
Discovery Client Server 8
Client Services Transmission Processing
9
NWK_addr_req O M 10
11
IEEE_addr_req O M
12
Node_Desc_req O M 13
Power_Desc_req O M 14
15
Simple_Desc_req O M
16
Active_EP_req O M 17
Match_Desc_req O M 18
19
Complex_Desc_req O O
20
User_Desc_req O O 21
Discovery_Cache_req O M 22
23
End_Device_annce O O 24
User_Desc_set O O 25
System_Server_Discover O M 26
_req 27
28
Discovery_store_req O O
29
Node_Desc_store_req O O 30
Power_Desc_store_req O O 31
32
Active_EP_store_req O O 33
Simple_Desc_store_req O O 34
Remove_node_cache_req O O 35
36
Find_node_cache_req O M 37
38
39
40
41
42
43
44
45
Chapter 2
2.4.3.1.1 NWK_addr_req
1
The NWK_addr_req command (ClusterID=0x0000) shall be formatted as 2
illustrated in Figure 2.17 . 3
Octets: 8 1 1
4
5
IEEEAddress RequestType StartIndex 6
7
Figure 2.17 Format of the NWK_addr_req Command 8
9
Table 2.41 specifies the fields of the NWK_addr_req Command Frame.
10
Table 2.41 Fields of the NWK_addr_req Command 11
12
13
IEEEAddr IEEE A valid 64-bit IEEE The IEEE address to be matched by the 14
Address address Remote Device 15
RequestType Integer 0x00-0xff Request type for this command: 16
17
0x00 – Single device response
18
0x01 – Extended response 19
0x02-0xFF – reserved 20
21
StartIndex Integer 0x00-0xff If the Request type for this command is
Extended response, the StartIndex 22
provides the starting index for the 23
requested elements of the associated 24
devices list 25
26
28
The NWK_addr_req is generated from a Local Device wishing to inquire as to the 29
16 bit address of the Remote Device based on its known IEEE address. The 30
destination addressing on this command shall be broadcast to all RxOnWhenIdle 31
devices. 32
For future upgrade ability, the destination addressing may be permitted to be 33
unicast. This would permit directing the message to a well-known destination that 34
supports centralized or agent-based device discovery. 35
36
38
Upon receipt, a Remote Device shall compare the IEEEAddr to its local IEEE 39
address or any IEEE address held in its local discovery cache. If there is no match, 40
the request shall be discarded and no response generated. If a match is detected 41
between the contained IEEEAddr and the Remote Device's IEEE address or one 42
held in the discovery cache, the RequestType shall be used to create a response. If 43
the RequestType is one of the reserved values, a NWK_addr_resp command shall 44
45
be generated with the Status field set to INV_REQUESTTYPE, the

IEEEAddrRemoteDev field set to the IEEE address of the request, the 1
NWKAddrRemoteDev field set to the network address corresponding to the IEEE 2
address of the request and the NumAssocDev field set to 0. If the RequestType is 3
single device response or extended response, the Remote Device shall create a 4
unicast message to the Local Device and include the Remote Device’s 16-bit 5
NWK address as the source address and the discovered NWKAddrRemoteDev 6
address along with the matched IEEE Address in the response payload. If the 7
RequestType was Single device response, the response message shall be sent with 8
a SUCCESS status. Otherwise, if the RequestType was Extended response and the 9
Remote Device is either the ZigBee coordinator or router with associated devices, 10
the Remote Device shall first include the matched IEEE Address and NWK 11
Address in the message payload and shall also supply a list of all 16 bit NWK 12
addresses, starting with the entry StartIndex and continuing with whole entries 13
until the maximum APS packet length is reached, for its associated devices along 14
with a status of SUCCESS. 15
16
2.4.3.1.2 IEEE_addr_req 17
The IEEE_addr_req command (ClusterID=0x0001) shall be formatted as 18
20
Octets: 2 1 1 21
22
NWKAddrOfInterest RequestType StartIndex
23
24
Figure 2.18 Format of the IEEE_addr_req_Command Frame
25
Table 2.42 specifies the fields of the IEEE_addr_req command frame. 26
27
Table 2.42 Fields of the IEEE_addr_req Command 28
30
NWKAddrOfInterest Device 16 bit NWK address NWK address that is used for IEEE 31
Address address mapping
32
RequestType Integer 0x00-0xff Request type for this command: 33
0x00 – Single device response 34
0x01 – Extended response 35
36
0x02-0xff – reserved
37
StartIndex Integer 0x00-0xff If the Request type for this 38
command is Extended response, the 39
StartIndex provides the starting
index for the requested elements of 40
the associated devices list 41
42
43
44
45
Chapter 2

1
The IEEE_addr_req is generated from a Local Device wishing to inquire as to the 2
64 bit IEEE address of the Remote Device based on their known 16 bit address. 3
The destination addressing on this command shall be unicast. 4
5
7
Upon receipt of this command, a remote device shall create a unicast
8
IEEE_addr_rsp command to the source as indicated by the IEEE_addr_req
9
command according to the supplied RequestType. If the RequestType is one of the
10
reserved values, an IEEE_addr_resp command shall be generated with the Status
11
field set to INV_REQUESTTYPE, the IEEEAddrRemoteDev field set to the
12
IEEE address of this device, the NWKAddrRemoteDev field set to the network
13
address of this device and the NumAssocDev field set to 0. Additionally, if the
14
RequestType indicates an Extended Response and the Remote Device is the
15
ZigBee coordinator or router with associated devices, the Remote Device shall
16
first include its own 64-bit IEEE address and shall also supply a list of all 16 bit
17
network addresses for its associated devices, starting with the entry StartIndex and
18
continuing with whole entries until the maximum APS packet length is reached,
19
with a status of SUCCESS.
20
2.4.3.1.3 Node_Desc_req 21
22
The Node_Desc_req_command (ClusterID=0x0002) shall be formatted as 23
Octets: 2 25
26
NWKAddrOfInterest 27
28
Figure 2.19 Format of the Node_Desc_req Command Frame 29
30
Table 2.43 specifies the fields for the Node_Desc_req command frame . 31
Table 2.43 Fields of the Node_Desc_req Command 32
33
34
NWKAddrOfInterest Device Address 16 bit NWK address NWK address for the request 35
36
38
The Node_Desc_req command is generated from a local device wishing to inquire 39
as to the node descriptor of a remote device. This command shall be unicast either 40
to the remote device itself or to an alternative device that contains the discovery 41
information of the remote device. 42
43
44
45
The local device shall generate the Node_Desc_req command using the format
illustrated in Table 2.43. The NWKAddrOfInterest field shall contain the network 1
address of the remote device for which the node descriptor is required. 2
3
5
Upon receipt of this command, the recipient device shall process the command 6
and generate a Node_Desc_rsp command in response, according to the 7
description in sub-clause 2.4.4.1.3.1. 8
2.4.3.1.4 Power_Desc_req 9
10
The Power_Desc_req command (ClusterID=0x0003) shall be formatted as 11
13
Octets: 2 14
16
Figure 2.20 Format of the Power_Desc_req Command Frame 17
18
Table 2.44 specifies the fields of the Power_Desc_req command frame. 19
Table 2.44 Fields of the Power_Desc_req Command 20
21
23
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request
Address 24
25
26
The Power_Desc_req command is generated from a local device wishing to 28
inquire as to the power descriptor of a remote device. This command shall be 29
unicast either to the remote device itself or to an alternative device that contains 30
the discovery information of the remote device. 31
32
The local device shall generate the Power_Desc_req command using the format 33
address of the remote device for which the power descriptor is required. 35
36
and generate a Power_Desc_rsp command in response, according to the 39
41
42
43
44
45
Chapter 2
2.4.3.1.5 Simple_Desc_req
1
The Simple_Desc_req command (ClusterID=0x0004) shall be formatted as 2
4
Octets: 2 1
5
NWKAddrOfInterest EndPoint 6
7
Figure 2.21 Format of the Simple_Desc_req Command Frame 8
9
Table 2.45 specifies the fields of the Simple_Desc_req command frame. 10
Table 2.45 Fields of the Simple_Desc_req Command 11
12
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request 14
Address 15
16
endpoint 8 bits 1-240 The endpoint on the destination
17
18
The Simple_Desc_req command is generated from a local device wishing to 20
inquire as to the simple descriptor of a remote device on a specified endpoint. This 21
command shall be unicast either to the remote device itself or to an alternative 22
device that contains the discovery information of the remote device. 23
24
The local device shall generate the Simple_Desc_req command using the format 25
address of the remote device for which the simple descriptor is required and the 27
endpoint field shall contain the endpoint identifier from which to obtain the 28
required simple descriptor. 29
30
32
Upon receipt of this command, the recipient device shall process the command
33
and generate a Simple_Desc_rsp command in response, according to the
34
description in sub-clause 2.4.4.1.5.1.
35
2.4.3.1.6 Active_EP_req 36
37
The Active_EP_req command (ClusterID=0x0005) shall be formatted as 38
Octets: 2 40
41
43
Figure 2.22 Format of the Active_EP_req Command Frame 44
45
Table 2.46 specifies the fields of the Active_EP_req command frame.

1
Table 2.46 Fields of the Active_EP_req Command
2
4
Address
6
7
The Active_EP_req command is generated from a local device wishing to acquire 9
the list of endpoints on a remote device with simple descriptors. This command 10
shall be unicast either to the remote device itself or to an alternative device that 11
contains the discovery information of the remote device. 12
13
The local device shall generate the Active_EP_req command using the format 14
address of the remote device for which the active endpoint list is required. 16
17
19
and generate an Active_EP_rsp command in response, according to the 21
2.4.3.1.7 Match_Desc_req 23
24
The Match_Desc_req command (ClusterID=0x0006) shall be formatted as 25
27
Octets: 2 2 1 Variable 1 Variable
28
NWKAddrOfInterest ProfileID NumInClusters InClusterList NumOutClusters OutClusterList 29
30
Figure 2.23 Format of the Match_Desc_req Command Frame 31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Chapter 2
Table 2.47 specifies the fields of the Match_Desc_req command frame.

1
Table 2.47 Fields of the Match_Desc_req Command
2
Valid 3
Name Type Range Description 4
5
NWKAddrOfInterest Device Address 16-bit NWK NWK address for the request
address 6
7
ProfileID Integer 0x0000- Profile ID to be matched at the 8
0xffff destination
9
NumInClusters Integer 0x00-0xff The number of Input Clusters 10
provided for matching within the 11
InClusterList
12
InClusterList 2 bytes * List of Input ClusterIDs to be used 13
NumInClusters for matching; The InClusterList is 14
the desired list to be matched by
the Remote Device (the elements
15
of the InClusterList are the 16
supported output clusters of the 17
Local Device) 18
NumOutClusters Integer 0x00-0xff The number of Output Clusters 19
provided for matching within 20
OutClusterList 21
OutClusterList 2 bytes * List of Output ClusterIDs to be 22
NumOutClusters used for matching; The 23
OutClusterList is the desired list to 24
be matched by the Remote Device 25
(the elements of the
26
OutClusterList are the supported
input clusters of the Local Device) 27
28
29
The Match_Desc_req command is generated from a local device wishing to find 31
remote devices supporting a specific simple descriptor match criterion. This 32
command shall either be broadcast to all RxOnWhenIdle devices or unicast. If the 33
command is unicast, it shall be directed either to the remote device itself or to an 34
alternative device that contains the discovery information of the remote device. 35
36
The local device shall generate the Match_Desc_req command using the format 37
illustrated in Table 2.47. The NWKAddrOfInterest field shall contain the 38
broadcast to all RxOnWhenIdle devices network address (0xfffd), if the command 39
is to be broadcast, or the network address of the remote device for which the 40
match is required. 41
42
43
44
45
The remaining fields shall contain the required criterion for which the simple
descriptor match is requested. The ProfileID field shall contain the identifier of 1
the profile for which the match is being sought. 2
3
The NumInClusters field shall contain the number of elements in the InClusterList 4
field. If the value of this field is 0, the InClusterList field shall not be included. If 5
the value of the NumInClusters field is not equal to 0, the InClusterList field shall 6
contain the list of input cluster identifiers for which the match is being sought. 7
The NumOutClusters field shall contain the number of elements in the 8
OutClusterList field. If the value of this field is 0, the OutClusterList field shall 9
not be included. If the value of the NumOutClusters field is not equal to 0, the 10
OutClusterList field shall contain the list of output cluster identifiers for which the 11
match is being sought. 12
13
15
and generate a Match_Desc_rsp command in response, according to the 17
2.4.3.1.8 Complex_Desc_req 19
20
The Complex_Desc_req command (ClusterID=0x0010) shall be formatted as 21
23
Octets: 2 24
26
Figure 2.24 Format of the Complex_Desc_req Command Frame 27
28
Table 2.48 specifies the fields of the Complex_Desc_req command frame. 29
Table 2.48 Fields of the Complex_Desc_req Command 30
31
33
NWKAddrOfInterest Device 16 bit NWK address NWK address for the request
Address 34
35
36
The Complex_Desc_req command is generated from a local device wishing to 38
inquire as to the complex descriptor of a remote device. This command shall be 39
unicast either to the remote device itself or to an alternative device that contains 40
the discovery information of the remote device. 41
42
The local device shall generate the Complex_Desc_req command using the 43
format illustrated in Table 2.48. The NWKAddrOfInterest field shall contain the 44
45
Chapter 2
network address of the remote device for which the complex descriptor is
required. 1
2
4
and generate a Complex_Desc_rsp command in response, according to the 6
2.4.3.1.9 User_Desc_req 8
9
The User_Desc_req (ClusterID=0x0011) command shall be formatted as 10
12
Octets: 2 13
15
Figure 2.25 Format of the User_Desc_req Command Frame 16
17
Table 2.49 specifies the fields of the User_Desc_req command frame. 18
Table 2.49 Fields of the User_Desc_req Command 19
20
22
NWKAddrOfInterest Device Address 16-bit NWK address NWK address for the request
23
24
The User_Desc_req command is generated from a local device wishing to inquire 26
as to the user descriptor of a remote device. This command shall be unicast either 27
to the remote device itself or to an alternative device that contains the discovery 28
information of the remote device. 29
30
The local device shall generate the User_Desc_req command using the format 31
address of the remote device for which the user descriptor is required. 33
34
36
Upon receipt of this command, the recipient device shall process the command
37
and generate a User_Desc_rsp command in response, according to the description
38
in sub-clause 2.4.4.1.9.1.
39
40
41
42
43
44
45
2.4.3.1.10 Discovery_Cache_req
1
The Discovery_Cache_req command (ClusterID=0x0012) shall be formatted as 2
4
Octets: 2 8
5
NWKAddr IEEEAddr 6
7
Figure 2.26 Format of the Discovery_Cache_req Command Frame 8
9
Table 2.50 specifies the parameters for the Discovery_Cache_req command 10
frame. 11
Table 2.50 Fields of the Discovery_Cache_req Command 12
13
NWKAddr Device Address 16-bit NWK address NWK address for the Local Device 15
16
IEEEAddr Device Address 64-bit IEEE address IEEE address for the Local Device
17
18
20
The Discovery_Cache_req is provided to enable devices on the network to locate
21
a Primary Discovery Cache device on the network. The destination addressing on
22
this primitive shall be broadcast to all RxOnWhenIdle devices.
23
24
Upon receipt, if the Remote Device does not support the Discovery_Cache_req, 26
the request shall be dropped and no further processing performed. If the 27
Discovery_Cache_req is supported, the Remote Device shall create a unicast 28
Discovery_Cache_rsp message to the source indicated by the 29
Discovery_Cache_req and include a SUCCESS status. 30
31
2.4.3.1.11 End_Device_annce 32
The End_Device_annce command (ClusterID=0x0013) shall be formatted as 33
35
Octets: 2 8 1 36
37
NWKAddr IEEEAddr Capability
38
39
Figure 2.27 Format of the End_Device_annce Command Frame
40
41
42
43
44
45
Chapter 2
Table 2.51 specifies the fields of the End_Device_annce command frame.

1
Table 2.51 Fields of the End_Device_annce Command
2
4
NWKAddr Device Address 16-bit NWK address NWK address for the Local Device 5
IEEEAddr Device Address 64-bit IEEE address IEEE address for the Local Device 6
Capability Bitmap See Figure 2.14 Capability of the local device 7
8
9
The End_Device_annce is provided to enable ZigBee end devices on the network 11
to notify other ZigBee devices that the end device has joined or re-joined the 12
network, identifying the end devices 64-bit IEEE address and new 16-bit 13
NWKaddress and informing the Remote Devices of the capability of the ZigBee 14
EndDevice. The destination addressing on this primitive is broadcast to all 15
devices. 16
17
19
Upon receipt, the Remote Device (a ZigBee coordinator or source device for the 20
binding operation) shall use the IEEEAddr in the message to find a match with 21
any binding table entries held in the Remote Device. If a match is detected, the 22
Remote Device shall update its APS Information Block Address Map with the 23
updated NWKAddr corresponding to the IEEEAddr received. 24
25
2.4.3.1.12 User_Desc_set
26
The User_Desc_set command (ClusterID=0x0014) shall be formatted as 27
29
Octets: 2 1 Various 30
NWKAddrOfInterest Length UserDescriptor 31
32
Figure 2.28 Format of the User_Desc_set Command Frame 33
34
35
36
37
38
39
40
41
42
43
44
45
Table 2.52 specifies the fields of the User_Desc_set command frame.

1
Table 2.52 Fields of the User_Desc_set Command
2
Valid 3
5
NWKAddrOfInterest Device Address 16-bit NWK address for the request
NWK 6
address 7
8
Length Integer 0x00 - 0x10 Length of the User Descriptor in bytes
9
UserDescription User Descriptor The user description to configure; If 10
the ASCII character string to be 11
entered here is less than 16 characters
in length, it shall be padded with 12
space characters (0x20) to make a 13
total length of 16 characters 14
15
17
The User_Desc_set command is generated from a local device wishing to 18
configure the user descriptor on a remote device. This command shall be unicast 19
either to the remote device itself or to an alternative device that contains the 20
discovery information of the remote device. 21
22
The local device shall generate the User_Desc_set command using the format
23
illustrated in Table 2.52. The NWKAddrOfInterest field shall contain the network
24
address of the remote device for which the user descriptor is to be configured and
25
the UserDescription field shall contain the ASCII character string that is to be
26
configured in the user descriptor.
27
28
29
and generate a User_Desc_conf command in response, according to the 31
33
2.4.3.1.13 System_Server_Discovery_req 34
The System_Server_Discovery_req command (ClusterID=0x0015) shall be 35
formatted as illustrated in Figure 2.29. 36
37
Octets: 2 38
39
ServerMask
40
Figure 2.29 Format of the System_Server_Discovery_req Command Frame 41
42
43
44
45
Chapter 2
Table 2.53 specifies the fields of the System_Server_Discovery_req command

frame. 1
2
Table 2.53 Fields of the System_Server_Discovery_req Command
3
5
ServerMask Bitmap 16-bits See Table 2.29 for bit assignments 6
7
9
The System_Server_Discovery_req is generated from a Local Device wishing to 10
discover the location of a particular system server or servers as indicated by the 11
ServerMask parameter. The destination addressing on this request is ‘broadcast to 12
all RxOnWhenIdle devices’. 13
14
Upon receipt, remote devices shall compare the ServerMask parameter to the 16
Server Mask field in their own Node descriptor. If no bits are found to match, no 17
action is taken. If any matching bits are found, the remote device shall send a 18
System_Server_Discovery_rsp back to the originator using unicast transmission 19
(with acknowledgement request) and indicating the matching bits. 20
21
2.4.3.1.14 Discovery_store_req 22
The Discovery_Store_req command (ClusterID=0x0016) shall be formatted as 23
25
Octets: 2 8 1 1 1 1 Variable 26
27
NWKAddr IEEEAddr NodeDesc PowerDesc- ActiveEPSize SimpleDesc- SimpleDesc-
28
-Size Size Count SizeList
29
Figure 2.30 Format of the Discovery_Store_req Command Frame 30
31
Table 2.54 specifies the fields of the Discovery_store_req command frame. 32
33
Table 2.54 Fields of the Discovery_store_req Command
34
36
NWKAddr Device 16-bit NWK NWK Address for the Local
Address Address Device 37
38
IEEEAddr Device 64-bit IEEE IEEE Address for the Local Device 39
Address Address
40
NodeDescSize Integer 0x00-oxff Size in bytes of the Node 41
Descriptor for the Local Device 42
43
44
45
Table 2.54 Fields of the Discovery_store_req Command (Continued)

1
Name Type Valid Range Description (Continued) 2
PowerDescSize Integer 0x00 - 0xff Size in bytes of the Power 3
Descriptor for the Local Device 4
5
ActiveIPSize Integer 0x00 - 0xff Size in bytes of the ActiveEPCount
and ActiveIPList fields of the 6
Active_EP_rsp for the Local 7
Device 8
SimpleDescCount Integer 0x00 - 0xff Number of Simple Descriptors 9
supported by the Local Device 10
(should be the same value as the 11
ActiveEPSize) 12
SimpleDescSizeList Array of bytes List of bytes of SimpleDescCount 13
length, each of which represents 14
the size in bytes of the Simple 15
Descriptor for each Active 16
Endpoint on the Local Device
17
18
The Discovery_store_req is provided to enable ZigBee end devices on the 20
network to request storage of their discovery cache information on a Primary 21
Discovery Cache device. Included in the request is the amount of storage space 22
the Local Device requires. 23
24
26
Upon receipt, the Remote Device shall determine whether it is a Primary 27
Discovery Cache device. If it is not a Primary Discovery Cache device, the 28
Remote Device shall return a status of NOT_SUPPORTED. Next, the Remote 29
Device shall determine whether it has storage for the requested discovery cache 30
size determined by summing the sizes of the NWKAddr and IEEEAddr plus the 31
NodeDescSize, PowerDescSize, ActiveEPSize and the sizes from the 32
SimpleDescSizeList. If sufficient space exists, the Local Device shall be provided 33
a SUCCESS status. Otherwise, the Local Device shall return 34
INSUFFICIENT_SPACE. If a SUCCESS status is returned, the Remote Device 35
shall reserve the storage requested for the upload of the discovery information 36
from the Local Device. Additionally, if the Local Device supplies an IEEEAddr, 37
which matches a previously stored entry, however, the NWKAddr differs from the 38
previous entry, the Remote Device shall remove the previous entry and discovery 39
cache information in favor of the newly registered data. 40
41
42
43
44
45
Chapter 2
2.4.3.1.15 Node_Desc_store_req
1
The Node_Desc_store_req command (ClusterID=0x0017) shall be formatted as 2
4
Octets: 2 8 Variable
5
NWKAddr IEEEAddr NodeDescriptor 6
7
Figure 2.31 Format of the Node_Desc_store_req Command Frame 8
9
Table 2.55 specifies the fields of the Node_Desc_store_req command frame. . 10
Table 2.55 Fields of the Node_Desc_store_req Command 11
12
NWKAddr Device 16-bit NWK Address NWK Address for the Local Device 14
Address 15
16
IEEEAddr Device 64-bit IEEE Address IEEE address for the Local Device
Address 17
18
NodeDescriptor Node See the Node Descriptor format in sub- 19
Descriptor clause 2.3.2.4
20
21
The Node_Desc_store_req is provided to enable ZigBee end devices on the 23
network to request storage of their Node Descriptor on a Primary Discovery 24
Cache device which has previously received a SUCCESS status from a 25
Discovery_store_req to the same Primary Discovery Cache device. Included in 26
this request is the Node Descriptor the Local Device wishes to cache. 27
28
29
30
Device shall determine whether it has previously processed a 34
Discovery_store_req for the Local Device and returned a status of SUCCESS. If a 35
previous Discovery_store_req has not been processed with a SUCCESS status, 36
the Remote Device shall return NOT_PERMITTED. Next, the Remote Device 37
shall determine if enough space is available to store the Node Descriptor for the 38
Local Device. If not, the Remote Device shall return INSUFFICIENT_SPACE. 39
Finally, the Remote Device shall store the Node Descriptor for the Local Device 40
and return SUCCESS. If the request returned a status of SUCCESS and the 41
NWKAddr and IEEEAddr in the request referred to addresses already held in the 42
Primary Discovery Cache, the descriptor in this request shall overwrite the 43
previously held entry. 44
45
2.4.3.1.16 Power_Desc_store_req
1
The Power_Desc_store_req command (ClusterID=0x0018) shall be formatted as 2
4
5
NWKAddr IEEEAddr PowerDescriptor 6
7
Figure 2.32 Format of the Power_Desc_store_req Command Frame 8
9
Table 2.56 specifies the fields of the Power_Desc_store_req command frame. 10
Table 2.56 Fields of the Power_Desc_store_req Command 11
12
NWKAddr Device 16-bit NWK Address NWK Address for the Local Device 14
Address 15
16
IEEEAddr Device 64-bit Address IEEE address for the Local Device
Address 17
18
PowerDescriptor Power See the Power Descriptor format in 19
Descriptor sub-clause 2.3.2.5; This field shall only
be included in the frame if the status 20
field is equal to SUCCESS 21
22
23
24
The Power_Desc_store_req is provided to enable ZigBee end devices on the 25
network to request storage of their Power Descriptor on a Primary Discovery 26
Cache device which has previously received a SUCCESS status from a 27
this request is the Power Descriptor the Local Device wishes to cache. 29
30
32
shall determine if enough space is available to store the Power Descriptor for the 40
Finally, the Remote Device shall store the Power Descriptor for the Local Device 42
NWKAddr and IEEEAddr in the request referred to addresses already held in the 44
45
Chapter 2
Primary Discovery Cache, the descriptor in this request shall overwrite the
2
2.4.3.1.17 Active_EP_store_req 3
The Active_EP_store_req command (ClusterID=0x0019) shall be formatted as 4
illustrated in Figure 2.33 . 5
6
Octets: 2 8 1 Variable 7
8
NWKAddr IEEEAddr ActiveEPCount ActiveEPList
9
10
Figure 2.33 Format of the Active_EP_store_req Command Frame
11
Table 2.57 specifies the fields of the Active_EP_store_req command frame 12
13
Table 2.57 Fields of the Active_EP_store_req Command 14
16
NWKAddr Device 16-bit NWK NWK Address for the Local Device 17
Address Address
18
IEEEAddr Device 64-bit IEEE IEEE Address for the Local Device 19
Address Address 20
ActiveEPCount Integer 0x00-0xff The count of active endpoints on the 21
Local Device 22
ActiveEPList List of bytes, each of which represents 23
an 8-bit endpoint number 24
25
26
27
The Active_EP_store_req is provided to enable ZigBee end devices on the 28
network to request storage of their list of Active Endpoints on a Primary 29
Discovery Cache device which has previously received a SUCCESS status from a 30
this request is the count of Active Endpoints the Local Device wishes to cache and 32
the endpoint list itself. 33
34
36
shall determine if enough space is available to store the Active Endpoint count 44
45
and list for the Local Device. If not, the Remote Device shall return
INSUFFICIENT_SPACE. Finally, the Remote Device shall store the Active 1
Endpoint count and list for the Local Device and return SUCCESS. If the request 2
returned a status of SUCCESS and the NWKAddr and the IEEEAddr in the 3
request referred to addresses already held in the Primary Discovery Cache, the 4
descriptor in this request shall overwrite the previously held entry. 5
6
2.4.3.1.18 Simple_Desc_store_req 7
The Simple_Desc_store_req command (ClusterID=0x001a) shall be formatted as 8
10
12
NWKAddr IEEEAddr Length SimpleDescriptor
13
14
Figure 2.34 Format of the Simple_Desc_store_req Command Frame
15
Table 2.58 specifies the fields of the Simple_Desc_store_req command frame . 16
17
Table 2.58 Fields of the Simple_Desc_store_req Command 18
20
NWKAddr Device 16-bit NWK Address NWK Address for the Local 21
Address Device
22
IEEEAddr Device 64-bit IEEE Address IEEE Address for the Local 23
Address Device 24
Length Device 0x00 - 0xff The length in bytes of the 25
Address Simple Descriptor to follow 26
SimpleDescriptor Simple See the Simple Descriptor 27
Descriptor format in sub-clause 2.3.2.6 28
29
30
31
The Simple_desc_store_req is provided to enable ZigBee end devices on the 32
network to request storage of their list of Simple Descriptors on a Primary 33
Discovery Cache device which has previously received a SUCCESS status from a 34
Discovery_store_req to the same Primary Discovery Cache device. Note that each 35
Simple Descriptor for every active endpoint on the Local Device must be 36
individually uploaded to the Primary Discovery Cache device via this command 37
to enable cached discovery. Included in this request is the length of the Simple 38
Descriptor the Local Device wishes to cache and the Simple Descriptor itself. The 39
endpoint is a field within the Simple Descriptor and is accessed by the Remote 40
Device to manage the discovery cache information for the Local Device. 41
42
43
44
45
Chapter 2

1
shall determine if enough space is available to store the Simple Descriptor for the 9
Finally, the Remote Device shall store the Simple Descriptor for the Local Device 11
NWKAddr and the IEEEAddr in the request referred to addresses already held in 13
the Primary Discovery Cache, the descriptor in this request shall overwrite the 14
2.4.3.1.19 Remove_node_cache_req 16
17
The Remove_node_cache_req command (ClusterID=0x001b) shall be formatted 18
as illustrated in Figure 2.35. 19
20
Octets: 2 8 21
NWKAddr IEEEAddr 22
23
Figure 2.35 Format of the Remove_node_cache_req Command Frame 24
25
Table 2.59 specifies the fields of the Remove_node_cache_req command frame. 26
Table 2.59 Fields of the Remove_node_cache_req Command 27
28
NWKAddr Device Address 16-bit NWK Address NWK Address for the device of 30
interest 31
32
IEEEAddr Device Address 64-bit IEEE Address IEEE Address for the device of interest
33
34
36
The Remove_node_cache_req is provided to enable ZigBee devices on the
37
network to request removal of discovery cache information for a specified ZigBee
38
end device from a Primary Discovery Cache device. The effect of a successful
39
Remove_node_cache_req is to undo a previously successful Discovery_store_req
40
and additionally remove any cache information stored on behalf of the specified
41
ZigBee end device on the Primary Discovery Cache device.
42
43
44
45

1
Discovery_store_req for the indicated device and returned a status of SUCCESS. 6
If a previous Discovery_store_req has not been processed with a SUCCESS 7
status, the Remote Device shall return NOT_PERMITTED. Finally, the Remote 8
Device shall remove all cached discovery information for the device of interest 9
and return SUCCESS to the Local Device. 10
2.4.3.1.20 Find_node_cache_req 11
12
The Find_node_cache_req command (ClusterID=0x001c) shall be formatted as 13
15
Octets: 2 8 16
NWKAddr IEEEAddr 17
18
Figure 2.36 Format of the Find_node_cache Command Frame 19
20
Table 2.60 specifies the fields of the Find_node_cache_req command frame. 21
Table 2.60 Fields of the Find_node_cache_req Command Frame 22
23
NWKAddr Device 16-bit NWK Address NWK Address for the device of 25
Address interest 26
27
IEEEAddr Device 64-bit IEEE Address IEEE Address for the device of interest
Address 28
29
30
The Find_node_cache_req is provided to enable ZigBee devices on the network to 32
broadcast to all RxOnWhenIdle devices a request to find a device on the network 33
that holds discovery information for the device of interest, as specified in the 34
request parameters. The effect of a successful Find_node_cache_req is to have the 35
Primary Discovery Cache device, holding discovery information for the device of 36
interest, unicast a Find_node_cache_rsp back to the Local Device. Note that, like 37
the NWK_addr_req, only the device meeting this criteria shall respond to the 38
request generated by Find_node_cache_req. 39
40
42
Upon receipt, the Remote Device shall determine whether it is the device of 43
interest or a Primary Discovery Cache device, and, if so, if it holds discovery 44
45
Chapter 2
cache information for the device of interest. If it is not the device of interest or a
Primary Discovery Cache device, and does not hold discovery cache information 1
for the device of interest, the Remote Device shall cease processing the request 2
and not supply a response. If the Remote Device is the device of interest, or a 3
Primary Discovery Cache device, and, if the device holds discovery information 4
for the indicated device of interest, the Remote Device shall return SUCCESS to 5
the Local Device along with the NWKAddr and IEEEaddr for the device of 6
interest. 7
8
2.4.3.2 End Device Bind, Bind, Unbind and Bind 9
Management Client Services Primitives 10
11
Table 2.61 lists the primitives supported by Device Profile: End Device Bind, 12
Bind and Unbind Client Services. Each of these commands will be discussed in 13
the following subclauses. 14
Table 2.61 End Device Bind, Bind, Unbind and Bind
15
Management Client Service Commands 16
17
End Device Bind, Bind and 18
Unbind Client Server 19
Client Services Transmission Processing
20
End_Device_Bind_req O O 21
Bind_req O O 22
23
Unbind_req O O 24
Bind_Register_req O O 25
26
Replace_Device_req O O
27
Store_Bkup_Bind_Entry_req O O 28
Remove_Bkup_Bind_Entry_req O O 29
30
Backup_Bind_Table_req O O
31
Recover_Bind_Table_req O O 32
Backup_Source_Bind_req O O 33
34
Recover_Source_Bind_req O O
35
36
37
38
39
40
41
42
43
44
45
2.4.3.2.1 End_Device_Bind_req
1
The End_Device_Bind_req command (ClusterID=0x0020) shall be formatted as 2
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
9
Figure 2.37 Format of the End_Device_Bind_req Command Frame
10
11
Table 2.62 specifies the fields of the End_Device_Bind_req command frame.
12
Table 2.62 Fields of the End_Device_Bind_req Command 13
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 17
cache device or the short address of the
18
local device.a
19
SrcIEEEAddre IEEE Address A valid 64-bit The IEEE address of the device 20
ss IEEE Address generating the request
21
SrcEndpoint 8 bits 1-240 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 27
in the ZigBee Coordinator
28
NumInClusters Integer 0x00-0xff The number of Input Clusters provided 29
for end device binding within the 30
InClusterList
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Chapter 2
Table 2.62 Fields of the End_Device_Bind_req Command (Continued)

1
InClusterList 2 bytes * List of Input ClusterIDs to be used for 3
NumInClusters matching. The InClusterList is the 4
desired list to be matched by the ZigBee 5
coordinator with the Remote Device’s 6
output clusters (the elements of the
InClusterList are supported input clusters
7
of the Local Device).b 8
9
NumOutCluste Integer 0x00-0xff The number of Output Clusters provided
10
rs for matching within OutClusterList.
11
OutClusterList 2 bytes * List of Output ClusterIDs to be used for 12
NumOutCluster matching. The OutClusterList is the
13
s desired list to be matched by the ZigBee
coordinator with the Remote Device’s 14
input clusters (the elements of the 15
OutClusterList are supported output 16
clusters of the Local Device).c 17
a. CCB #587 18
19
b. CCB #544
20
c. CCB #544 21
22
24
The End_Device_Bind_req is generated from a Local Device wishing to perform 25
End Device Bind with a Remote Device. The End_Device_Bind_req is generated, 26
typically based on some user action like a button press. The destination addressing 27
on this command shall be unicast and the destination address shall be that of the 28
ZigBee Coordinator. 29
30
On receipt of this command, the ZigBee coordinator shall first check that the 32
supplied endpoint is within the specified range. If the supplied endpoint does not 33
fall within the specified range, the ZigBee coordinator shall return an 34
End_Device_Bind_rsp with a status of INVALID_EP. 35
36
If the supplied endpoint is within the specified range, the ZigBee Coordinator 37
shall retain the End_Device_Bind_req for a pre-configured timeout duration 38
awaiting a second End_Device_Bind_req. If the second request does not appear 39
within the timeout period, the ZigBee Coordinator shall generate a TIMEOUT 40
status and return it with the End_Device_Bind_rsp to the originating Local 41
Device. Assuming the second End_Device_Bind_req is received within the 42
timeout period, it shall be matched with the first request on the basis of the 43
ProfileID, InClusterList and OutClusterList. 44
45
If no match of the ProfileID is detected or if the ProfileID matches but none of the
InClusterList or OutClusterList elements match, a status of NO_MATCH shall be 1
supplied to both Local Devices via End_Device_Bind_rsp to each device. If a 2
match of Profile ID and at least one input or output clusterID is detected, an 3
End_Device_Bind_rsp with status SUCCESS shall be issued to each Local 4
Device which generated the End_Device_Bind_req. 5
6
The ZigBee coordinator shall then determine the 64-bit IEEE address of each 7
local device. If these addresses are not known, the ZigBee coordinator shall 8
determine them by using the IEEE_Addr_req command and corresponding 9
IEEE_Addr_rsp command. 10
In order to facilitate a toggle action the ZigBee Coordinator shall then issue an 11
Unbind_req command to the BindingTarget, specifying any one of the matched 12
ClusterID values. If the returned status value is NO_ENTRY, the ZigBee 13
Coordinator shall issue a Bind_req command for each matched ClusterID value. 14
Otherwise the ZigBee Coordinator shall conclude that the binding records are 15
instead to be removed and shall issue an Unbind_req command for any further 16
matched ClusterID values. 17
18
The initial Unbind_req and any subsequent Bind_reqs or Unbind_reqs, containing 19
the matched clusters shall be directed to one of the BindingTargets specified by 20
the generating devices. The BindingTarget is selected on an individual basis for 21
each matched cluster, as the Binding Target selected by the generating device 22
having that cluster as an output cluster. The SrcAddress field shall contain the 64- 23
bit IEEE address of that same generating device and the SrcEndp field shall 24
contain its endpoint. The DstAddress field shall contain the 64-bit IEEE address 25
of the generating device having the matched cluster in its input cluster list and the 26
DstEndp field shall contain its endpoint. 27
2.4.3.2.2 Bind_req 28
29
The Bind_req command (ClusterID=0x0021) shall be formatted as illustrated in 30
Figure 2.38. 31
32
Octets: 8 1 2 1 2/8 0/1
33
SrcAddress SrcEndp ClusterID DstAddrMode DstAddress DstEndp 34
35
Figure 2.38 Format of the Bind_req Command Frame 36
37
38
39
40
41
42
43
44
45
Chapter 2
Table 2.63 specifies the fields of the Bind_req command frame.

1
Table 2.63 Fields of the Bind_req Command
2
4
SrcAddress IEEE A valid 64-bit IEEE The IEEE address for the source 5
Address address
6
SrcEndp Integer 0x01-0xf0 The source endpoint for the binding 7
entry 8
ClusterID Integer 0x0000-0xffff The identifier of the cluster on the 9
source device that is bound to the 10
destination 11
DstAddrMode Integer 0x00-0xff The addressing mode for the 12
destination address used in this 13
command. This field can take one of 14
the non-reserved values from the
following list:
15
16
0x00 = reserved 17
DstAddress and DstEndp not present 19
0x02 = reserved 20
21
DstAddress and DstEndp present
22
23
DstAddress Address As specified by the The destination address for the binding 25
DstAddrMode field entry 26
DstEndp Integer 0x01-0xf0 This field shall be present only if the 27
DstAddrMode field has a value of 28
0x03 and, if present, shall be the 29
destination endpoint for the binding 30
entry.
31
32
34
The Bind_req is generated from a Local Device wishing to create a Binding Table
35
entry for the source and destination addresses contained as parameters. The
36
destination addressing on this command shall be unicast only and the destination
37
address shall be that of a Primary binding table cache or to the SrcAddress itself.
38
The Binding Manager is optionally supported on the source device (unless that
39
device is also the ZigBee Coordinator) so that device shall issue a
40
NOT_SUPPORTED status to the Bind_req if not supported.
41
42
43
44
45

1
Upon receipt, a Remote Device (a Primary binding table cache or the device 2
designated by SrcAddress) shall create a Binding Table entry based on the 3
parameters supplied in the Bind_req if the Binding Manager is supported. If the 4
remote device is a primary binding table cache, the following additional 5
processing is required. First, the primary cache shall check its table of devices 6
holding their own source bindings for the device in SrcAddress and, if it is found, 7
shall issue another Bind_req to that device with the same entry. Second, the 8
primary cache shall check if there is a backup binding table cache and, if so, shall 9
issue a Store_Bkup_Binding_Entry_req command to backup the new entry. The 10
Remote Device shall then respond with SUCCESS if the entry has been created by 11
the Binding Manager; otherwise, the Remote Device shall respond with 12
NOT_SUPPORTED. 13
2.4.3.2.3 Unbind_req 14
15
The Unbind_req command (ClusterID=0x0022) shall be formatted as illustrated 16
in Figure 2.39. 17
18
Octets: 8 1 2 1 2/8 0/1 19
SrcAddress SrcEndp ClusterID DstAddrMode DstAddress DstEndp 20
21
Figure 2.39 Format of the Unbind_req Command Frame 22
23
Table 2.64 specifies the fields of the Unbind_req command frame. 24
Table 2.64 Fields of the Unbind_req Command 25
26
SrcAddress IEEE A valid 64-bit IEEE The IEEE address for the source 28
Address address 29
30
SrcEndp Integer 0x01-0xf0 The source 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
Chapter 2
Table 2.64 Fields of the Unbind_req Command (Continued)

1
DstAddrMode Integer 0x00-0xff The addressing mode for the destination 3
address used in this command. This field 4
can take one of the non-reserved values 5
from the following list: 6
0x00 = reserved 7
0x02 = reserved 10
DstAddress and DstEndp present 12
14
DstAddress Address As specified by the The destination address for the binding
DstAddrMode field entry. 15
16
DstEndp Integer 0x01-0xf0 This field shall be present only if the
17
DstAddrMode field has a value of 0x03
and, if present, shall be the destination 18
endpoint for the binding entry. 19
20
22
The Unbind_req is generated from a Local Device wishing to remove a Binding 23
Table entry for the source and destination addresses contained as parameters. The 24
destination addressing on this command shall be unicast only and the destination 25
address must be that of the a Primary binding table cache or the SrcAddress. 26
27
29
The Remote Device shall evaluate whether this request is supported. If the request 30
is not supported, a Status of NOT_SUPPORTED shall be returned. If the request 31
is supported, the Remote Device (a Primary binding table cache or the 32
SrcAddress) shall remove a Binding Table entry based on the parameters supplied 33
in the Unbind_req. If the SrcAddress is specified and the Binding Manager is 34
unsupported on that remote device, a status of NOT_SUPPORTED shall be 35
returned. If a Binding Table entry for the SrvAddress, SrcEndp, ClusterID, 36
DstAddress, DstEndp contained as parameters does not exist, the Remote Device 37
shall respond with NO_ENTRY. Otherwise, the Remote Device shall delete the 38
indicated Binding Table entry and respond with SUCCESS. 39
40
41
42
43
44
45
2.4.3.2.4 Bind_Register_req
1
The Bind_Register_req command (ClusterID=0x0023) shall be formatted as 2
4
Octets: 8
5
NodeAddress 6
7
Figure 2.40 Format of the Bind_Register_req Command Frame 8
9
Table 2.65 specifies the fields for the Bind_Register_req command frame. 10
Table 2.65 Fields of the Bind_Register_req Command 11
12
NodeAddress IEEE A valid 64-bit IEEE The address of the node wishing to hold 14
Address address its own binding table 15
16
17
18
The Bind_Register_req is generated from a Local Device and sent to a primary 19
binding table cache device to register that the local device wishes to hold its own 20
binding table entries. The destination addressing mode for this request is unicast. 21
22
24
If the remote device is not a primary binding table cache it shall return a status of 25
NOT_SUPPORTED. Otherwise, the primary binding table cache shall add the 26
NodeAddress given by the parameter to its table of source devices which have 27
chosen to store their own binding table. If this fails it shall return a status of 28
TABLE_FULL. Otherwise it returns a status of SUCCESS. (If an entry for the 29
NodeAddress already exists in the table of source devices, the behavior will be the 30
same as if it had been newly added.). The source device should clear its source 31
binding table before issuing this command to avoid synchronization problems. In 32
the successful case, any existing bind entries from the binding table whose source 33
address is NodeAddress will be sent to the requesting device for inclusion in its 34
source bind table. See Bind_Register_rsp for further details. Subsequent bind 35
entries written to the binding list will cause copies to be written to the source 36
device using Bind_req. 37
38
39
40
41
42
43
44
45
Chapter 2
2.4.3.2.5 Replace_Device_req
1
The Replace_Device_req command (ClusterID=0x0024) shall be formatted as 2
4
Octets: 8 1 8 1
5
OldAddress OldEndpoint NewAddress NewEndpoint 6
7
Figure 2.41 Format of the Replace_Device_req Command Frame 8
9
Table 2.66 specifies the fields for the Replace_Device_req command frame. 10
Table 2.66 Fields of the Replace_Device_req Command 11
12
OldAddress IEEE Address A valid 64-bit IEEE The address of the node being 14
replaced 15
16
OldEndpoint Integer 0x01 - 0xf0 The endpoint being replaced
17
NewAddress IEEE Address A valid 64-bit IEEE The replacement address 18
NewEndpoint Integer 0x01 - 0xf0 The replacement endpoint 19
20
21
22
The Replace_Device_req is intended for use by a special device such as a 23
Commissioning tool and is sent to a primary binding table cache device to change 24
all binding table entries which match OldAddress and OldEndpoint as specified. 25
(Note that OldEndpoint = 0 has special meaning and signifies that only the 26
address needs to be matched. The endpoint in the binding table will not be 27
changed in this case and so NewEndpoint is ignored.) The processing changes all 28
binding table entries for which the source address is the same as OldAddress and, 29
if OldEndpoint is non-zero, for which the source endpoint is the same as 30
OldEndpoint. It shall also change all binding table entries which have the 31
destination address the same as OldAddress and, if OldEndpoint is non-zero, the 32
destination endpoint the same as OldEndpoint. The destination addressing mode 33
for this request is unicast. 34
35
37
If the remote device is not a primary binding table cache, it shall return a status of 38
NOT_SUPPORTED. The primary binding table cache shall check if its 39
OldAddress is non-zero and, if so, shall search its binding table for entries of 40
source addresses and source entries, or destination addresses and source 41
addresses, that are set the same as OldAddress and OldEndpoint. It shall change 42
these entries to have NewAddress and NewEndpoint. In the case that OldEndpoint 43
is zero, the primary binding table cache shall search its binding table for entries 44
45
whose source address or destination address match OldAddress. It shall change

these entries to have NewAddress leaving the endpoint value unchanged and 1
ignoring NewEndpoint. It shall then return a response of SUCCESS. The primary 2
binding table cache shall also be responsible for notifying affected devices which 3
are registered as holding their own source binding table of the changes. This will 4
be necessary for each changed binding table entry, where the destination address 5
was changed and the source address appears in the list of source devices which 6
have chosen to store their own binding table. In each of these cases the amended 7
bind table entry will be sent to the source device using an Unbind_req command 8
for the old entry followed by a Bind_req command for the new one. In the case 9
that the source address of the bind entry has been changed, it will be necessary for 10
the primary binding table cache to send an Unbind_req command to the old source 11
device if it is a source bind device and to send a Bind_req command to the new 12
source bind device if it is a source bind device. The primary binding table cache 13
shall also update the backup binding table cache by means of the 14
Remove_bkup_binding_entry_req command for the old entry and 15
Store_bkup_binding_entry_req for the altered entry. 16
17
2.4.3.2.6 Store_Bkup_Bind_Entry_req 18
The Store_Bkup_Bind_Entry_req command (ClusterID=0x0025) shall be 19
21
Figure 2.42 Format of the Store_Bkup_Bind_Entry_req Command Frame 22
23
Octets: 8 1 2 1 2/8 0/1 24
SrcAddress SrcEndp ClusterID DstAddrMode DstAddress DstEndpa
25
26
a. CCB #601 27
28
Table 2.67 specifies the fields of the Store_Bkup_Bind_Entry_req command 29
frame. 30
Table 2.67 Fields of the Store_Bkup_Bind_Entry_req Command 31
32
SrcAddress IEEE Address A valid 64-bit The IEEE address for the source 34
IEEE address 35
36
SrcEndpoint Integer 0x01 - 0xf0 The source endpoint for the binding entry
37
ClusterId Integer 0x0000 - 0xffff The identifier of the cluster on the source 38
device that is bound to the destination 39
40
41
42
43
44
45
Chapter 2
Table 2.67 Fields of the Store_Bkup_Bind_Entry_req Command

1
DstAddrMo Integer 0x00-0xff The addressing mode for the destination
de address used in this command. This field
2
can take one of the non-reserved values 3
from the following list: 4
0x00 = reserved
5
6
0x01 = 16-bit group address for
0x02 = reserved
8
9
0x04 – 0xff = reserveda
11
12
DstAddress Address As specified by The destination address for the binding 13
the entry.
14
DstAddrMode
field 15
16
DstEndp Integer 0x01-0xf0 This field shall be present only if the
17
DstAddrMode field has a value of 0x03
and, if present, shall be the destination 18
endpoint for the binding entry. 19
20
a. CCB #601
21
22
The Store_Bkup_Bind_Entry_req is generated from a local primary binding table 24
cache and sent to a remote backup binding table cache device to request backup 25
storage of the entry. It will be generated whenever a new binding table entry has 26
been created by the primary binding table cache. The destination addressing mode 27
for this request is unicast. 28
29
31
If the remote device is not a backup binding table cache it shall return a status of 32
NOT_SUPPORTED. If it is the backup binding table cache, it should maintain the 33
identity of the primary binding table cache from previous discovery. If the 34
contents of the Store_Bkup_Bind_Entry parameters match an existing entry in the 35
binding table cache, then the remote device shall return SUCCESS. Otherwise, 36
the backup binding table cache shall add the binding entry to its binding table and 37
return a status of SUCCESS. If there is no room it shall return a status of 38
TABLE_FULL. 39
40
41
42
43
44
45
2.4.3.2.7 Remove_Bkup_Bind_Entry_req
1
The Remove_Bkup_Bind_Entry_req command (ClusterID=0x0026) shall be 2
Figure 2.43 Format of the Remove_Bkup_Bind_Entry_req Command Frame 4
5
Octets: 8 1 2 1 2/8 0/1 6
7
SrcAddress SrcEndp ClusterID DstAddrMode DstAddress DstEndpa 8
a. CCB #601
9
10
Table 2.67 specifies the fields of the Remove_Bkup_Bind_Entry_req command 11
frame. 12
13
Table 2.68 Fields of the Remove_Bkup_Bind_Entry_req Command 14
16
SrcAddress IEEE A valid 64-bit The IEEE address for the source 17
Address IEEE address 18
SrcEndpoint Integer 0x01 - 0xf0 The IEEE address for the binding entry 19
ClusterId Integer 0x0000 - 0xffff The identifier of the cluster on the source
20
device that is bound to the destination 21
22
DstAddrMode Integer 0x00-0xff The addressing mode for the destination
23
address used in this command. This field can
take one of the non-reserved values from the 24
following list: 25
26
0x00 = reserved
27
0x01 = 16-bit group address for DstAddress
and DstEndp not present 28
29
0x02 = reserved
30
32
0x04 – 0xff = reserveda
33
DstAddress Address As specified by The destination address for the binding 34
the entry.
35
DstAddrMode
field 36
37
DstEndp Integer 0x01-0xf0 This field shall be present only if the 38
DstAddrMode field has a value of 0x03 and,
if present, shall be the destination endpoint 39
for the binding entry. 40
41
a. CCB #601
42
43
44
45
Chapter 2

1
The Remove_Bkup_Bind_Entry_req is generated from a local primary binding 2
table cache and sent to a remote backup binding table cache device to request 3
removal of the entry from backup storage. It will be generated whenever a binding 4
table entry has been unbound by the primary binding table cache. The destination 5
addressing mode for this request is unicast. 6
7
9
If the remote device is not a backup binding table cache it shall return a status of
10
NOT_SUPPORTED. If it is a backup binding table cache, it should maintain the
11
identity of the primary binding table cache from previous discovery. If it does not
12
recognize the sending device as the primary binding table cache it shall return a
13
status of INV_REQUESTTYPE. Otherwise, the backup binding table cache shall
14
search its binding table for the entry corresponding to the supplied parameters. If
15
no entry is found it shall return a status of NO_ENTRY. Otherwise it shall delete
16
the entry and return a status of SUCCESS.
17
2.4.3.2.8 Backup_Bind_Table_req 18
19
The Backup_Bind_Table_req command (ClusterID=0x0027) shall be formatted 20
23
BindingTableEntries StartIndex BindingTableListCount BindingTableList 24
25
Figure 2.44 Format of the Backup_Bind_Table_req Command Frame 26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Table 2.69 specifies the fields of the Backup_Bind_Table_req command frame.

1
Table 2.69 Fields of the Backup_Bind_Table_req Command
2
4
BindingTableEntries Integer 0x0000 - 0xffff Total number of binding 5
table entries on the primary
binding table cache device 6
7
StartIndex Integer 0x0000 - 0xffff Starting index within the 8
binding table of entries
9
BindingTableListCount Integer 0x0000 - 0xffff Number of binding table 10
entries included within 11
BindingTableList
12
BindingTableList List of The list shall contain A list of descriptors 13
binding the number of elements beginning with the 14
descriptors given by the StartIndex element and
BindingTableListCount continuing for
15
BindingTableListCount of 16
the elements in the primary 17
binding table cache devices’s 18
binding table (see 19
Table 2.122 for details.)
20
21
23
The Backup_Bind_Table_req is generated from a local primary binding table
24
cache and sent to the remote backup binding table cache device to request backup
25
storage of its entire binding table. The destination addressing mode for this
26
request is unicast.
27
28
If the remote device is not a backup binding table cache it shall return a status of 30
NOT_SUPPORTED. If it is a backup binding table cache, it should maintain the 31
identity of the primary binding table cache from previous discovery. If it does not 32
recognize the sending device as a primary binding table cache it shall return a 33
status of INV_REQUESTTYPE. Otherwise, the backup binding table cache shall 34
overwrite the binding entries in its binding table starting with StartIndex and 35
continuing for BindingTableListCount entries. If this exceeds its table size it shall 36
fill in as many entries as possible and return a status of TABLE_FULL. Otherwise 37
it shall return a status of SUCCESS. The table is effectively truncated to the end 38
of the last entry written by this request. The new size of the table is returned in the 39
response and will be equal to StartIndex + BindingTableListCount unless 40
TABLE_FULL is being returned when it will be the maximum size of the table. 41
42
43
44
45
Chapter 2
2.4.3.2.9 Recover_Bind_Table_req
1
The Recover_Bind_Table_req command (ClusterID=0x0028) shall be formatted 2
4
Octets: 2
5
StartIndex 6
7
Figure 2.45 Fields of the Recover_Bind_Table_req Command Frame 8
9
Table 2.70 specifies the fields of the Recover_Bind_Table_req command frame. 10
Table 2.70 Fields of the Recover_Bind_Table_req Command 11
12
StartIndex Integer 0x0000 - 0xffff Starting index for the requested 14
elements of the binding table 15
16
17
18
The Recover_Bind_Table_req is generated from a local primary binding table 19
cache and sent to a remote backup binding table cache device when it wants a 20
complete restore of the binding table. The destination addressing mode for this 21
request is unicast. 22
23
25
If the remote device is not the backup binding table cache it shall return a status of 26
NOT_SUPPORTED. If it does not recognize the sending device as a primary 27
binding table cache it shall return a status of INV_REQUESTTYPE. Otherwise, 28
the backup binding table cache shall prepare a list of binding table entries from its 29
backup beginning with StartIndex. It will fit in as many entries as possible into a 30
Recover_Bind_Table_rsp command and return a status of SUCCESS. 31
2.4.3.2.10 Backup_Source_Bind_req 32
33
The Backup_Source_Bind_req command (ClusterID=0x0029) shall be formatted 34
36
Octets: 2 2 2 Variable
37
SourceTableEntries StartIndex SourceTableListCount SourceTableList 38
39
Figure 2.46 Fields of the Backup_Source_Bind_req Command Frame 40
41
42
43
44
45
Table 2.71 specifies the fields of the Backup_Source_Bind_req command frame.

1
Table 2.71 Fields of the Backup_Source_Bind_req Command
2
4
SourceTableEntries Integer 0x0000 - 0xffff Total number of source table 5
entries on the primary binding
table cache device 6
7
StartIndex Integer 0x0000 - 0xffff Starting index within the 8
binding table of the entries in
SourceTableList 9
10
SourceTableListCount Integer 0x0000 - 0xffff Number of source table entries 11
included within
SourceTableList 12
13
SourceTableList List of The list shall contain A list of addresses beginning 14
IEEE the number of with the StartIndex element and
Addresses elements given by the continuing for
15
SourceTableListCount SourceTableListCount of 16
source addresses in the primary 17
binding table cache device’s 18
source table 19
20
22
The Backup_Source_Bind_req is generated from a local primary binding table 23
cache and sent to a remote backup binding table cache device to request backup 24
storage of its entire source table. The destination addressing mode for this request 25
is unicast. 26
27
the backup binding table cache shall overwrite the source entries in its backup 32
source table starting with StartIndex and continuing for SourceTableListCount 33
entries. If this exceeds its table size it shall return a status of TABLE_FULL. 34
Otherwise it shall return a status of SUCCESS. The command always truncates 35
the backup table to a number of entries equal to its maximum size or 36
SourceTableEntries, whichever is smaller. 37
38
39
40
41
42
43
44
45
Chapter 2
2.4.3.2.11 Recover_Source_Bind_req
1
The Recover_Source_Bind_req command (ClusterID=0x002a) shall be formatted 2
4
Octets: 2
5
StartIndex 6
7
Figure 2.47 Format of the Recover_Source_Bind_req Command Frame 8
9
Table 2.72 specifies the fields of the Recover_Source_Bind_req command frame. 10
Table 2.72 Fields of the Recover_Source_Bind_req Command 11
12
StartIndex Integer 0x0000 - 0xffff Starting index for the requested 14
elements of the binding table 15
16
17
18
The Recover_Source_Bind_req is generated from a local primary binding table 19
cache and sent to the remote backup binding table cache device when it wants a 20
complete restore of the source bind table. The destination addressing mode for 21
this request is unicast. 22
23
25
the backup binding table cache shall prepare a list of source bind table entries 29
from its backup beginning with StartIndex. It will fit in as many entries as 30
possible into a Recover_Source_Bind_rsp command and return a status of 31
SUCCESS. 32
33
2.4.3.3 Network Management Client Services 34
Table 2.73 lists the commands supported by Device Profile: Network 35
Management Client Services. Each of these primitives will be discussed in the 36
following subclauses. 37
38
Table 2.73 Network Management Client Services Commands 39
Network Management Client Server 40
Client Services Transmission Processing 41
42
Mgmt_NWK_Disc_req O O
43
Mgmt_Lqi_req O O 44
45
Table 2.73 Network Management Client Services Commands

1
Mgmt_Rtg_req O O
2
Mgmt_Bind_req O O 3
Mgmt_Leave_req O O 4
5
Mgmt_Direct_Join_req O O 6
Mgmt_Permit_Joining_req O M 7
Mgmt_Cache_req O O 8
9
10
2.4.3.3.1 Mgmt_NWK_Disc_req
11
The Mgmt_NWK_Disc_req command (ClusterID=0x0030) shall be formatted as 12
14
Octets: 4 1 1 15
ScanChannels ScanDuration StartIndex
16
17
Figure 2.48 Format of the Mgmt_NWK_Disc_req Command Frame 18
19
Table 2.74 specifies the fields for the Mgmt_NWK_Disc_req command frame. 20
21
Table 2.74 Fields of the Mgmt_NWK_Disc_req Command
22
Valid 23
ScanChannels Bitmap 32 bit field See (sub-clause 3.3.2.1) for details
25
on NLME-NETWORK- 26
DISCOVERY.request ScanChannels 27
parameter. 28
ScanDuration Integer 0x00-0x0e A value used to calculate the length 29
of time to spend scanning each 30
channel. The time spent scanning 31
each channel is 32
(aBaseSuperframeDuration * (2n +
33
1)) symbols, where n is the value of
the ScanDuration parameter. For 34
more information on MAC sub-layer 35
scanning (see [B1]. 36
StartIndex Integer 0x00-0xff Starting index within the resulting 37
NLME-NETWORK- 38
DISCOVERY.confirm NetworkList 39
to begin reporting for the 40
Mgmt_NWK_Disc_rsp. 41
42
43
44
45
Chapter 2

1
The Mgmt_NWK_Disc_req is generated from a Local Device requesting that the 2
Remote Device execute a Scan to report back networks in the vicinity of the Local 3
Device. The destination addressing on this command shall be unicast. 4
5
7
The Remote Device shall execute an NLME-NETWORK-DISCOVERY.request
8
using the ScanChannels and ScanDuration parameters supplied with the
9
Mgmt_NWK_Disc_req command. The results of the Scan shall be reported back
10
to the Local Device via the Mgmt_NWK_Disc_rsp command.
11
If this command is not supported in the Remote Device, the return status provided 12
with the Mgmt_NWK_Disc_rsp shall be NOT_SUPPORTED. If the scan was 13
successful, the Mgmt_NWK_Disc_rsp command shall contain a status of 14
SUCCESS and the results of the scan shall be reported, beginning with the 15
StartIndex element of the NetworkList. If the scan was unsuccessful, the 16
Mgmt_NWK_Disc_rsp command shall contain the error code reported in the 17
NLME-NETWORK-DISCOVERY.confirm primitive. 18
19
2.4.3.3.2 Mgmt_Lqi_req
20
The Mgmt_Lqi_req command (ClusterID=0x0031) shall be formatted as 21
23
Octets: 1 24
StartIndex 25
26
Figure 2.49 Format of the Mgmt_Lqi_req Command Frame 27
28
Table 2.75 specifies the fields for the Mgmt_NWK_Disc_req command frame. 29
30
Table 2.75 Fields of the Mgmt_Lqi_req Command
31
Valid 32
StartIndex Integer 0x00-0xff Starting Index for the requested elements of the 34
Neighbor Table 35
36
37
38
The Mgmt_Lqi_req is generated from a Local Device wishing to obtain a 39
neighbor list for the Remote Device along with associated LQI values to each 40
neighbor. The destination addressing on this command shall be unicast only and 41
the destination address must be that of a ZigBee Coordinator or ZigBee Router. 42
43
44
45

1
Upon receipt, a Remote Device (ZigBee Router or ZigBee Coordinator) shall 2
retrieve the entries of the neighbor table and associated LQI values via the 3
NLME-GET.request primitive (for the nwkNeighborTable attribute) and report the 4
resulting neighbor table (obtained via the NLME-GET.confirm primitive) via the 5
Mgmt_Lqi_rsp command. 6
If this command is not supported in the Remote Device, the return status provided 7
with the Mgmt_Lqi_rsp shall be NOT_SUPPORTED. If the neighbor table was 8
obtained successfully, the Mgmt_Lqi_rsp command shall contain a status of 9
SUCCESS and the neighbor table shall be reported, beginning with the element in 10
the list enumerated as StartIndex. If the neighbor table was not obtained 11
successfully, the Mgmt_Lqi_rsp command shall contain the error code reported in 12
the NLME-GET.confirm primitive. 13
14
2.4.3.3.3 Mgmt_Rtg_req 15
The Mgmt_Rtg_req command (ClusterID=0x0032) shall be formatted as 16
18
Octets: 1 19
20
StartIndex 21
22
Figure 2.50 Format of the Mgmt_Rtg_req Command Frame
23
Table 2.76 specifies the fields for the Mgmt_Rtg_req command frame. 24
25
Table 2.76 Fields of the Mgmt_Rtg_req Command 26
28
StartIndex Integer 0x00-0xff Starting Index for the requested elements of the 29
Neighbor Table 30
31
33
The Mgmt_Rtg_req is generated from a Local Device wishing to retrieve the 34
contents of the Routing Table from the Remote Device. The destination 35
addressing on this command shall be unicast only and the destination address 36
must be that of the ZigBee Router or ZigBee Coordinator. 37
38
Upon receipt, a Remote Device (ZigBee Coordinator or ZigBee Router) shall 40
retrieve the entries of the routing table from the NWK layer via the NLME- 41
GET.request primitive (for the nwkRouteTable attribute) and report the resulting 42
43
44
45
Chapter 2
routing table (obtained via the NLME-GET.confirm primitive) via the

Mgmt_Rtg_rsp command. 1
2
If the Remote Device does not support this optional management request, it shall 3
return a Status of NOT_SUPPORTED. If the routing table was obtained 4
successfully, the Mgmt_Rtg_req command shall contain a status of SUCCESS 5
and the routing table shall be reported, beginning with the element in the list 6
enumerated as StartIndex. If the routing table was not obtained successfully, the 7
Mgmt_Rtg_rsp command shall contain the error code reported in the NLME- 8
GET.confirm primitive. 9
2.4.3.3.4 Mgmt_Bind_req 10
11
The Mgmt_Bind_req command (ClusterID=0x0033) shall be formatted as 12
14
Octets: 1
15
StartIndex 16
17
Figure 2.51 Format of the Mgmt_Bind_req Command Frame 18
19
Table 2.77 specifies the fields for the Mgmt_Bind_req command frame. 20
Table 2.77 Fields of the M gm t_Bind_req Command 21
22
StartIndex Integer 0x00-0xff Starting Index for the requested 24
elements of the Binding Table 25
26
27
28
The Mgmt_Bind_req is generated from a Local Device wishing to retrieve the 29
contents of the Binding Table from the Remote Device. The destination 30
addressing on this command shall be unicast only and the destination address 31
must be that of a Primary binding table cache or source device holding its own 32
binding table. 33
34
36
Upon receipt, a Remote Device (ZigBee Coordinator or ZigBee Router) shall 37
retrieve the entries of the binding table from the APS sub-layer via the APSME- 38
GET.request primitive (for the apsBindingTable attribute) and report the resulting 39
binding table (obtained via the APSME-GET.confirm primitive) via the 40
Mgmt_Bind_rsp command. 41
If the Remote Device does not support this optional management request, it shall 42
return a status of NOT_SUPPORTED. If the binding table was obtained 43
44
45
successfully, the Mgmt_Bind_rsp command shall contain a status of SUCCESS

and the binding table shall be reported, beginning with the element in the list 1
enumerated as StartIndex. If the binding table was not obtained successfully, the 2
Mgmt_Bind_rsp command shall contain the error code reported in the APSME- 3
GET.confirm primitive. 4
5
2.4.3.3.5 Mgmt_Leave_req 6
The Mgmt_Leave_req command (ClusterID=0x0034) shall be formatted as 7
9
Bits: 64 6 1 1 10
11
Device Address Reserved Remove Children Rejoin
12
13
Figure 2.52 Format of the Mgmt_Leave_req Command Frame
14
Table 2.78 specifies the fields for the Mgmt_Leave_req command frame. 15
16
Table 2.78 Fields of the Mgmt_Leave_req Command 17
19
DeviceAddress Device An extended 64 See (sub-clause 3.3.8.1) for details 20
Address bit, IEEE address on the DeviceAddress parameter
21
within NLME-LEAVE.request
22
Remove Bit 0 or 1 This field has a value of 1 if the 23
Children device being asked to leave the
24
network is also being asked to
remove its child devices, if any. 25
Otherwise it has a value of 0. 26
27
Rejoin Bit 0 or 1 This field has a value of 1 if the
device being asked to leave from the 28
current parent is requested to rejoin 29
the network. Otherwise, it has a 30
value of 0. 31
32
34
The Mgmt_Leave_req is generated from a Local Device requesting that a Remote 35
Device leave the network or to request that another device leave the network. The 36
Mgmt_Leave_req is generated by a management application which directs the 37
request to a Remote Device where the NLME-LEAVE.request is to be executed 38
using the parameter supplied by Mgmt_Leave_req. 39
40
Upon receipt, the remote device shall issue the NLME-LEAVE.request primitive 42
using the parameters supplied with the Mgmt_Leave_req command. The results 43
44
45
Chapter 2
of the leave attempt shall be reported back to the local device via the
Mgmt_Leave_rsp command. 1
2
If the remote device does not support this optional management request, it shall 3
return a status of NOT_SUPPORTED. If the leave attempt was executed 4
successfully, the Mgmt_Leave_rsp command shall contain a status of SUCCESS. 5
If the leave attempt was not executed successfully, the Mgmt_Leave_rsp 6
command shall contain the error code reported in the NLME-LEAVE.confirm 7
primitive. 8
2.4.3.3.6 Mgmt_Direct_Join_req 9
10
The Mgmt_Direct_Join_req command (ClusterID=0x0035) shall be formatted as 11
13
Octets: 8 1
14
Device Address Capability 15
Information 16
17
Figure 2.53 Format of the Mgmt_Direct_Join _reqCommand Frame 18
19
Table 2.79 specifies the fields for the Mgmt_Direct_Join_req command frame. 20
Table 2.79 Fields of the Mgmt_Direct_Join_req Command 21
22
DeviceAddress Device An extended 64 bit, See sub-clause 3.3.6.1 for details 24
Address IEEE address on the DeviceAddress parameter 25
within NLME-JOIN.request 26
CapabilityInformation Bitmap See Table 3.17 The operating capabilities of the 27
device being directly joined 28
29
31
The Mgmt_Direct_Join_req is generated from a Local Device requesting that a 32
Remote Device permit a device designated by DeviceAddress to join the network 33
directly. The Mgmt_Direct_Join_req is generated by a management application 34
which directs the request to a Remote Device where the NLME-DIRECT- 35
JOIN.request is to be executed using the parameter supplied by 36
Mgmt_Direct_Join_req. 37
38
40
Upon receipt, the remote device shall issue the NLME-DIRECT-JOIN.request
41
primitive using the DeviceAddress and CapabilityInformation parameters
42
supplied with the Mgmt_Direct_Join_req command. The results of the direct join
43
44
45
attempt shall be reported back to the local device via the Mgmt_Direct_Join_rsp
command. 1
2
If the remote device does not support this optional management request, it shall 3
return a status of NOT_SUPPORTED. If the direct join attempt was executed 4
successfully, the Mgmt_Direct_Join_rsp command shall contain a status of 5
SUCCESS. If the direct join attempt was not executed successfully, the 6
Mgmt_Direct_Join_rsp command shall contain the error code reported in the 7
NLME-DIRECT-JOIN.confirm primitive. 8
2.4.3.3.7 Mgmt_Permit_Joining_req 9
10
The Mgmt_Permit_Joining_req command (ClusterID=0x0036) shall be formatted 11
13
Octets: 1 1
14
PermitDuration TC_Significance 15
16
Figure 2.54 Format of the Mgmt_Permit_Joining_req Command Frame 17
18
Table 2.80 specifies the fields of the Mgmt_Permit_Joining_req command frame. 19
Table 2.80 Fields of the Mgmt_Permit_Joining_req Command 20
21
PermitDuration Integer 0x00 - 0xff See sub-clause 3.3.4.1 for details on the 23
PermitDuration parameter within NLME- 24
PERMIT-JOINING.request 25
TC_Significance Boolean 0x00 - 0x01 If this is set to 0x01 and the remote device is 26
Integer the trust center, the command affects the trust 27
center authentication policy as described in 28
the sub-clauses below; If this is set to 0x00, 29
there is no effect on the trust center
30
31
33
The Mgmt_Permit_Joining_req is generated from a Local Device requesting that
34
a remote device or devices allow or disallow association. The
35
Mgmt_Permit_Joining_req is generated by a management application or
36
commissioning tool which directs the request to a remote device(s) where the
37
NLME-PERMIT-JOINING.request is executed using the PermitDuration
38
parameter supplied by Mgmt_Permit_Joining_req. Additionally, if the remote
39
device is the Trust Center and TC_Significance is set to 1, the trust center
40
authentication policy will be affected. The addressing may be unicast or
41
‘broadcast to all RxOnWhenIdle devices’.
42
43
44
45
Chapter 2

1
Upon receipt, the remote device(s) shall issue the NLME-PERMIT- 2
JOINING.request primitive using the PermitDuration parameter supplied with the 3
Mgmt_Permit_Joining_req command. If the PermitDuration parameter is not 4
equal to zero or 0xFF, the parameter is a number of seconds and joining is 5
permitted until it counts down to zero after which time joining is not permitted. If 6
the PermitDuration is set to zero, joining is not permitted; if set to 0xFF joining is 7
permitted indefinitely or until another Mgmt_Permit_Joining_req is received. If a 8
second Mgmt_Permit_Joining_req is received whilst the previous one is still 9
counting down it will supersede the previous request. Additionally, if the remote 10
device is the Trust Center and TC_Significance is set to 1, the trust center 11
authentication policy will be affected. In this case, if PermitDuration is set to a 12
non-zero value, trust center authentication is allowed so that when the trust center 13
receives an NLME-JOIN.indication or an APSME-UPDATE-DEVICE.indication 14
indicating that a new device has joined, it will authenticate it and issue a security 15
key as appropriate. Alternatively, if PermitDuration is set to zero, trust center 16
authentication will be disallowed with the effect that if an APSME-UPDATE- 17
DEVICE.indication is received indicating that a new device has joined; The trust 18
center shall then issue an APSME-REMOVE-DEVICE.request to refuse the new 19
device. Note that the TC_Significance flag and the Trust Center action will be 20
subject to the security policy imposed by the stack profile. Particularly the Trust 21
Center may be configured not to act on this flag unless it has been sent by 22
particular trusted devices such as configuration tools which are known to the Trust 23
Center. Similarly, the main command features may be disallowed under some 24
stack profiles unless the sending device can be authenticated as a known 25
configuration device. If the command is not permitted, a response of 26
INVALID_REQUEST shall be sent (unless the command was a broadcast to all 27
RxOnWhenIdle devices in which case no response shall be sent) If the 28
Mgmt_Permit_Joining_req primitive was received as a unicast, the results of the 29
NLME-PERMIT-JOINING.request shall be reported back to the local device via 30
the Mgmt_Permit_Joining_rsp command. If the command was received as a 31
broadcast, no response shall be sent back. 32
2.4.3.3.8 Mgmt_Cache_req 33
34
The Mgmt_Cache_req command (ClusterID=0x0037) shall be formatted as 35
37
Octets: 1 38
StartIndex 39
40
Figure 2.55 Fields of the Mgmt_Cache_req Command Frame 41
42
43
44
45
Table 2.81 specifies the fields of the Mgmt_Cache_req command frame.

1
Table 2.81 Fields of the Mgmt_Cache_req Command
2
Valid 3
5
StartIndex Integer 0x00 - 0xff Starting Index for the requested
elements of the discovery cache list 6
7
8
The Mgmt_Cache_req is provided to enable ZigBee devices on the network to 10
retrieve a list of ZigBee End Devices registered with a Primary Discovery Cache 11
device. The destination addressing on this primitive shall be unicast. 12
13
15
Discovery Cache or whether this optional request primitive is supported. If it is 17
not a Primary Discovery Cache device or the Mgmt_Cache_req primitive is not 18
supported, the Remote Device shall return a status of NOT_SUPPORTED. If the 19
Remote Device is a Primary Discovery Cache and supports the Mgmt_Cache_req, 20
the Remote Device shall return SUCCESS to the Local Device along with the 21
discovery cache list which consists of the NWKAddr and IEEEaddr for each 22
ZigBee End Device registered. 23
24
2.4.4 Server Services 25
26
The Device Profile Server Services supports the processing of device and service 27
discovery requests, end device bind requests, bind requests, unbind requests and 28
network management requests. Additionally, Server Services support 29
transmission of these responses back to the requesting device. 30
31
For all broadcast addressed requests (of any broadcast address type) to the server, 32
if the command is not supported, the server shall drop the packet. No error status 33
shall be unicast back to the Local Device for any broadcast addressed client 34
request including, but not limited to, requests which are not supported on the 35
server.7 36
For all unicast addressed requests to the server, if the command is not supported, 37
the server shall formulate a response packet including the response Cluster ID and 38
status fields only. The response Cluster ID shall be created by taking the request 39
Cluster ID and setting the high order bit to create the response Cluster ID. The 40
41
42
43
7. CCB #530 44
45
Chapter 2
status field shall be set to NOT_SUPPORTED. The resulting response shall be

unicast to the requesting client.8 1
2
2.4.4.1 Device and Service Discovery Server 3
4
Table 2.82 lists the commands supported by the Device and Service Discovery 5
Server Services device profile. Each of these commands will be discussed in the 6
following subclauses. For receipt of the End_Device_Annce command, the server 7
shall check all internal references to the IEEE address supplied in the request. For 8
all references to the IEEE address in the Local Device, the corresponding NWK 9
address supplied in the End_Device_Annce shall be substituted. The server shall 10
not supply a response to the End_Device_Annce. 11
Table 2.82 Device and Service Discovery Server Service Primitives 12
13
Device and Service 14
Discovery Server
Server Services Processing 15
16
NWK_addr_rsp M 17
IEEE_addr_rsp M 18
19
Node_Desc_rsp M
20
Power_Desc_rsp M 21
Simple_Desc_rsp M 22
23
Active_EP_rsp M 24
Match_Desc_rsp M 25
Complex_Desc_rsp O
26
27
User_Desc_rsp O 28
User_Desc_conf O 29
30
System_Server_Discovery_rsp M
31
Discovery_store_rsp O 32
Node_Desc_store_rsp O 33
34
Power_Desc_store_rsp O
35
Active_EP_store_rsp O 36
Simple_Desc_store_rsp O 37
38
Remove_node_cache_rsp O 39
Find_node_cache_rsp O 40
41
42
43
8. CCB #585 44
45
2.4.4.1.1 NWK_addr_rsp
1
The NWK_addr_rsp command (ClusterID=0x8000) shall be formatted as 2
4
Octets: 1 8 2 1 1 Variable
5
Status IEEEAddr NWKAddr Num StartIndex NWKAddr 6
RemoteDev RemoteDev AssocDev AssocDevList 7
8
Figure 2.56 Format of the NWK_addr_rsp Command Frame 9
10
Table 2.83 specifies the fields of the NWK_addr_rsp command frame. 11
Table 2.83 Fields of the NWK_addr_rsp Command 12
13
Status Integer SUCCESS, The status of the 15
INV_REQUESTTYPE or NWK_addr_req command 16
DEVICE_NOT_FOUND 17
IEEEAddrRemoteDev Device An extended 64-bit, IEEE 64-bit address for the Remote 18
Address address Device 19
NWKAddrRemoteDev Device A 16-bit, NWK address 16-bit address for the Remote 20
Address Device 21
22
NumAssocDev Integer 0x00-0xff Count of the number of
associated devices to the 23
Remote Device and the 24
number of 16-bit short 25
addresses to follow; 26
If the RequestType in the 27
request is Extended Response 28
and there are no associated 29
devices on the Remote 30
Device, this field shall be set
to 0; 31
32
request is for a Single Device
Response, this field shall not 34
be included in the frame 35
36
37
38
39
40
41
42
43
44
45
Chapter 2
Table 2.83 Fields of the NWK_addr_rsp Command (Continued)

1
StartIndex Integer 0x00-0xff Starting index into the list of 3
associated devices for this 4
report; 5
and there are no associated 8
devices on the Remote 9
Device, this field shall not be
included in the frame;
10
11
request is for a Single Device
Response, this field shall not
13
15
NWKAddrAssocDevLi Device List of NumAssocDev A list of 16 bit addresses, one
16
st Address 16-bit short addresses, corresponding to each
List each with range associated device to Remote 17
0x0000 0x-ffff Device; The number of 16-bit 18
network addresses contained 19
in this field is specified in the 20
NumAssocDev field;
21
and there are no associated
24
devices on the Remote
Device, this field shall not be 25
included in the frame; 26
27
If the RequestType in the
request is for a Single Device 28
Response, this field shall not 29
31
33
The NWK_addr_rsp is generated from a Remote Device receiving a broadcast 34
NWK_addr_req who detect a match of the IEEEAddr parameter with their own 35
IEEE address or the IEEE address held in a local discovery cache. The destination 36
addressing on this command is unicast. 37
38
40
Upon receipt, a Remote Device shall attempt to match the IEEEAddr in the
41
NWK_addr_req command with the Remote Device’s IEEE address. If no match
42
exists, the request shall be discarded and no response message processing
43
performed. If a match is detected, the Remote Device shall create a unicast
44
45
message to the source indicated by the NWK_addr_req command. Included in

the NWK_addr_rsp payload is the IEEE address that matched from the 1
NWK_addr_req and the NWK address of the Remote Device. If the RequestType 2
is one of the reserved values, the Status field shall be set to INV_REQUESTTYPE 3
and the NumAssocDev, StartIndex and NWKAddrAssocDevList fields shall not 4
be included in the frame. If the RequestType was set to single response, the 5
NumAssocDev, StartIndex and NWKAddrAssocDevList fields shall not be 6
included in the frame. If the RequestType was set to extended response and the 7
Remote Device is not the ZigBee coordinator or router, the NumAssocDev field 8
shall be set to 0 and the StartIndex and NWKAddrAssocDevList fields shall not 9
be included in the frame. If the RequestType was set to extended response and the 10
Remote Device is the ZigBee coordinator or router with associated devices, The 11
NumAssocDev field shall contain the number of 16-bit NWK addresses contained 12
in the NWKAddrAssocDevList field, the StartIndex field shall be set to the value 13
contained in the NWK_addr_req command and the NWKAddrAssocDevList shall 14
contain the list of all 16-bit NWK addresses of its associated devices, starting with 15
the entry StartIndex and continuing with whole entries until the maximum APS 16
packet length is reached. 17
18
The DEVICE_NOT_FOUND status shall be treated as reserved for Version 1.0 19
and is to be used only with future unicast forms of the NWK_addr_req primitive. 20
2.4.4.1.2 IEEE_addr_rsp 21
22
The IEEE_addr_rsp command (ClusterID=0x8001) shall be formatted as 23
25
Octets: 1 8 2 1 1 Variable
26
Status IEEEAddr NWKAddr Num StartIndex NWKAddr 27
RemoteDev RemoteDev AssocDev AssocDevList 28
29
Figure 2.57 Format of the IEEE_addr_rs Command Frame 30
31
Table 2.84 specifies the fields of the IEEE_addr_rs command frame. 32
Table 2.84 IEEE_addr_rsp Parameters 33
34
INV_REQUESTTYPE or IEEE_addr_req command 37
DEVICE_NOT_FOUND 38
IEEEAddrRemoteDev Device An extended 64-bit, IEEE 64-bit address for the 39
Address address Remote Device 40
NWKAddrRemoteDev Device A 16-bit, NWK address 16-bit address for the 41
Address Remote Device 42
43
44
45
Chapter 2
Table 2.84 IEEE_addr_rsp Parameters (Continued)

1
NumAssocDev Integer 0x00-0xff Count of the number of 3
associated devices to the 4
Remote Device and the 5
number of 16-bit short 6
addresses to follow;
7
request is Extended 9
Response and there are no
associated devices on the
10
Remote Device, this field 11
shall be set to 0; 12
13
request is for a Single 14
Device Response, this 15
field shall not be included 16
in the frame 17
StartIndex Integer 0x00-0xff Starting index into the list 18
of associated devices for 19
this report; 20
Response and there are no 23
associated devices on the
24
Remote Device, this field
shall not be included in the 25
frame; 26
27
request is for a Single 28
Device Response, this 29
in the frame 31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Table 2.84 IEEE_addr_rsp Parameters (Continued)

1
NWKAddrAssocDevList Device List of NumAssocDev A list of 16 bit addresses, 3
Address 16-bit short addresses, one corresponding to each 4
List each with range associated device to 5
0x0000 0x-ffff Remote Device; The 6
number of 16-bit network
addresses contained in this
7
field is specified in the 8
NumAssocDev field; 9
10
Response and there are no 12
associated devices on the 13
Remote Device, this field 14
shall not be included in the
frame;
15
16
request is for a Single
Device Response, this
18
in the frame 20
21
23
The IEEE_addr_rsp is generated from Remote Devices in response to the unicast 24
IEEE_addr_req inquiring as to the 64 bit IEEE address of the Remote Device. The 25
destination addressing on this command shall be unicast. 26
27
29
Upon receipt, a Remote Device shall create a unicast message to the source 30
indicated by the IEEE_addr_req command. Included in the IEEE_addr_rsp 31
payload is the IEEE address and the NWK address of the Remote Device. If the 32
RequestType is one of the reserved values, the Status field shall be set to 33
INV_REQUESTTYPE and the NumAssocDev, StartIndex and 34
NWKAddrAssocDevList fields shall not be included in the frame. If the 35
RequestType was set to single response, the NumAssocDev, StartIndex and 36
NWKAddrAssocDevList fields shall not be included in the frame. If the 37
RequestType was set to extended response and the Remote Device is not the 38
ZigBee coordinator or router, the NumAssocDev field shall be set to 0 and the 39
StartIndex and NWKAddrAssocDevList fields shall not be included in the frame. 40
If the RequestType was set to extended response and the Remote Device is the 41
ZigBee coordinator or router with associated devices, The NumAssocDev field 42
shall contain the number of 16-bit NWK addresses contained in the 43
NWKAddrAssocDevList field, the StartIndex field shall be set to the value 44
45
Chapter 2
contained in the IEEE_addr_req command and the NWKAddrAssocDevList shall

contain the list of all 16-bit NWK addresses of its associated devices, starting with 1
the entry StartIndex and continuing with whole entries until the maximum APS 2
packet length is reached. 3
4
The DEVICE_NOT_FOUND status shall be treated as reserved for Version 1.0 5
and is to be used only with future forms of the IEEE_addr_req primitive. 6
2.4.4.1.3 Node_Desc_rsp 7
8
The Node_Desc_rsp command (ClusterID=0x8002) shall be formatted as 9
11
See sub-
Octets: 1 2 clause 2.3.2.4 12
13
Status NWKAddr Node 14
OfInterest Descriptor 15
16
Figure 2.58 Format of the Node_Desc_rsp Command Frame
17
18
Table 2.85 specifies the fields of the Node_Desc_rsp command frame.
19
Table 2.85 Fields of the Node_Desc_rsp Command 20
21
22
DEVICE_NOT_FOUND Node_Desc_req command 24
,INV_REQUESTTYPE
25
or NO_DESCRIPTOR
26
NWKAddrOfInterest Device 16 bit NWK address NWK address for the request 27
Address
28
NodeDescriptor Node See the Node Descriptor 29
Descriptor format in sub-clause 2.3.2.4. 30
This field shall only be 31
included in the frame if the
status field is equal to 32
SUCCESS 33
34
35
36
The Node_Desc_rsp is generated by a remote device in response to a 37
Node_Desc_req directed to the remote device. This command shall be unicast to 38
the originator of the Node_Desc_req command. 39
40
The remote device shall generate the Node_Desc_rsp command using the format 41
illustrated in Table 2.85. The NWKAddrOfInterest field shall match that specified 42
in the original Node_Desc_req command. If the NWKAddrOfInterest field 43
matches the network address of the remote device, it shall set the Status field to 44
45
SUCCESS and include its node descriptor (see sub-clause 2.3.2.4) in the
NodeDescriptor 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 and not include the NodeDescriptor field. If the 5
NWKAddrOfInterest field does not match the network address of the remote 6
device and it is the coordinator or a router, it shall determine whether the 7
NWKAddrOfInterest field matches the network address is one of its children. If 8
the NWKAddrOfInterest field does not match the network address of one of the 9
children of the remote device, it shall set the Status field to 10
DEVICE_NOT_FOUND and not include the NodeDescriptor field. If the 11
NWKAddrOfInterest matches the network address of one of the children of the 12
remote device, it shall determine whether a node descriptor for that device is 13
available. If a node descriptor is not available for the child indicated by the 14
NWKAddrOfInterest field, the remote device shall set the Status field to 15
NO_DESCRIPTOR and not include the NodeDescriptor field. If a node descriptor 16
is available for the child indicated by the NWKAddrOfInterest field, the remote 17
device shall set the Status field to SUCCESS and include the node descriptor (see 18
sub-clause 2.3.2.4) of the matching child device in the NodeDescriptor field. 19
20
On receipt of the Node_Desc_rsp command, the recipient is either notified of the 22
node descriptor of the remote device indicated in the original Node_Desc_req 23
command or notified of an error. If the Node_Desc_rsp command is received with 24
a Status of SUCCESS, the NodeDescriptor field shall contain the requested node 25
descriptor. Otherwise, the Status field indicates the error and the NodeDescriptor 26
field shall not be included. 27
28
2.4.4.1.4 Power_Desc_rsp 29
30
The Power_Desc_rsp command (ClusterID=0x8003) shall be formatted as
31
illustrated in Figure 2.59.
32
See sub- 33
Octet: 1 2 clause 2.3.2.5 34
35
Status NWKAddr Power
OfInterest Descriptor
36
37
Figure 2.59 Format of the Power_Desc_rsp Command Frame 38
39
40
41
42
43
44
45
Chapter 2
Table 2.86 specifies the fields of the Power_Desc_rsp command frame.

1
Table 2.86 Fields of the Power_Desc_rsp Command
2
4
Power_Desc_req command
DEVICE_NOT_FOUND, 6
INV_REQUESTTYPE or 7
NO_DESCRIPTOR 8
Address 10
PowerDescriptor Power See the Node Power 11
Descriptor Descriptor format in sub- 12
clause 2.3.2.5. This field shall 13
only be included in the frame 14
if the status field is equal to
SUCCESS 15
16
17
The Power_Desc_rsp is generated by a remote device in response to a 19
Power_Desc_req directed to the remote device. This command shall be unicast to 20
the originator of the Power_Desc_req command. 21
22
The remote device shall generate the Power_Desc_rsp command using the format 23
in the original Power_Desc_req command. If the NWKAddrOfInterest field 25
SUCCESS and include its power descriptor (see sub-clause 2.3.2.5) in the 27
PowerDescriptor field. 28
INV_REQUESTTYPE and not include the PowerDescriptor field. If the 31
NWKAddrOfInterest field does not match the network address of the remote 32
device and it is the coordinator or a router, it shall determine whether the 33
NWKAddrOfInterest field matches the network address is one of its children. If 34
the NWKAddrOfInterest field does not match the network address of one of the 35
children of the remote device, it shall set the Status field to 36
DEVICE_NOT_FOUND and not include the PowerDescriptor field. If the 37
NWKAddrOfInterest matches the network address of one of the children of the 38
remote device, it shall determine whether a power descriptor for that device is 39
available. If a power descriptor is not available for the child indicated by the 40
NO_DESCRIPTOR and not include the PowerDescriptor field. If a power 42
descriptor is available for the child indicated by the NWKAddrOfInterest field, 43
44
45
the remote device shall set the Status field to SUCCESS and include the power
descriptor (see sub-clause 2.3.2.5) of the matching child device in the 1
PowerDescriptor field. 2
3
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
16
Octet: 1 2 1 Variable 17
Status NWKAddr Length Simple 18
20
Figure 2.60 Format of the Simple_Desc_rsp Command Frame 21
22
Table 2.87 specifies the fields of the Simple_Desc_rsp command frame. 23
Table 2.87 Fields of the Simple_Desc_rsp Command 24
25
INVALID_EP, Simple_Desc_req command 28
NOT_ACTIVE, 29
DEVICE_NOT_FOUND, 30
INV_REQUESTTYPE or
31
NO_DESCRIPTOR
32
Address
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.6. 38
This field shall only be 39
included in the frame if the 40
status field is equal to
SUCCESS 41
42
43
44
45
Chapter 2

1
The Simple_Desc_rsp is generated by a remote device in response to a 2
Simple_Desc_req directed to the remote device. This command shall be unicast to 3
the originator of the Simple_Desc_req command. 4
The remote device shall generate the Simple_Desc_rsp command using the format 5
in the original Simple_Desc_req command. If the endpoint field specified in the 7
original Simple_Desc_req command does not fall within the correct range 8
specified in Table 2.45, the remote device shall set the Status field to 9
INVALID_EP, set the Length field to 0 and not include the SimpleDescriptor 10
field. 11
12
If the NWKAddrOfInterest field matches the network address of the remote 13
device, it shall determine whether the endpoint field specifies the identifier of an 14
active endpoint on the device. If the endpoint field corresponds to an active 15
endpoint, the remote device shall set the Status field to SUCCESS, set the Length 16
field to the length of the simple descriptor on that endpoint and include the simple 17
descriptor (see sub-clause 2.3.2.6) for that endpoint in the SimpleDescriptor field. 18
If the endpoint field does not correspond to an active endpoint, the remote device 19
shall set the Status field to NOT_ACTIVE, set the Length field to 0 and not 20
include the SimpleDescriptor field. 21
INV_REQUESTTYPE, set the Length field to 0 and not include the 24
SimpleDescriptor field. If the NWKAddrOfInterest field does not match the 25
network address of the remote device and it is the coordinator or a router, it shall 26
determine whether the NWKAddrOfInterest field matches the network address is 27
one of its children. If the NWKAddrOfInterest field does not match the network 28
address of one of the children of the remote device, it shall set the Status field to 29
DEVICE_NOT_FOUND, set the Length field to 0 and not include the 30
SimpleDescriptor field. 31
32
If the NWKAddrOfInterest matches the network address of one of the children of 33
the remote device, it shall determine whether a simple descriptor for that device 34
and on the requested endpoint is available. If a simple descriptor is not available 35
on the requested endpoint of the child indicated by the NWKAddrOfInterest field, 36
the remote device shall set the Status field to NO_DESCRIPTOR, set the Length 37
field to 0 and not include the SimpleDescriptor field. If a simple descriptor is 38
available on the requested endpoint of the child indicated by the 39
SUCCESS, set the Length field to the length of the simple descriptor on that 41
endpoint and include the simple descriptor (see sub-clause 2.3.2.6) for that 42
endpoint of the matching child device in the SimpleDescriptor field. 43
44
45

1
On receipt of the Simple_Desc_rsp command, the recipient is either notified of 2
the simple descriptor on the endpoint of the remote device indicated in the original 3
Simple_Desc_req command or notified of an error. If the Simple_Desc_rsp 4
command is received with a Status of SUCCESS, the SimpleDescriptor field shall 5
contain the requested simple descriptor. Otherwise, the Status field indicates the 6
error and the SimpleDescriptor field shall not be included. 7
2.4.4.1.6 Active_EP_rsp 8
9
The Active_EP_rsp command (ClusterID=0x8005) shall be formatted as 10
12
Status NWKAddr ActiveEP ActiveEP 14
OfInterest Count List 15
16
Figure 2.61 Format of the Active_EP_rsp Command Frame 17
18
Table 2.88 specifies the fields of the Active_EP_rsp command frame. 19
Table 2.88 Fields of the Active_EP_rsp Command 20
21
Status Integer SUCCESS, The status of the Active_EP_req 23
command 24
DEVICE_NOT_FOUND,
INV_REQUESTTYPE 25
or NO_DESCRIPTOR 26
27
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request
Address 28
29
ActiveEPCount Integer 0x00-0xff The count of active endpoints on 30
the Remote Device
31
ActiveEPList List of bytes each of which 32
represents an 8-bit endpoint 33
34
36
The Active_EP_rsp is generated by a remote device in response to an 37
Active_EP_req directed to the remote device. This command shall be unicast to 38
the originator of the Active_EP_req command. 39
The remote device shall generate the Active_EP_rsp command using the format 40
in the original Active_EP_req command. If the NWKAddrOfInterest field 42
44
45
Chapter 2
SUCCESS, set the ActiveEPCount field to the number of active endpoints on that
device and include an ascending list of all the identifiers of the active endpoints on 1
that device in the ActiveEPList field. 2
3
If the NWKAddrOfInterest field does not match the network address of the remote device 4
and it is an end device, it shall set the Status field to INV_REQUESTTYPE, set the 5
ActiveEPCount field to 0 and not include the ActiveEPList field. If the 6
NWKAddrOfInterest field does not match the network address of the remote device and it 7
is the coordinator or a router, it shall determine whether the NWKAddrOfInterest field 8
matches the network address of a device it holds in a discovery cache. If the 9
NWKAddrOfInterest field does not match the network address of a device it holds in a 10
discovery cache, it shall set the Status field to DEVICE_NOT_FOUND, set the 11
ActiveEPCount field to 0 and not include the ActiveEPList field. If the 12
NWKAddrOfInterest matches the network address of a device held in a discovery cache 13
on the remote device, it shall determine whether that device has any active endpoints. If 14
the discovery information corresponding to the ActiveEP request has not yet been 15
uploaded to 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 ActiveEPList 17
field. If the cached device has no active endpoints, the remote device shall set the Status 18
field to SUCCESS, set the ActiveEPCount field to 0 and not include the ActiveEPList 19
field. If the cached device has active endpoints, the remote device shall set the Status field 20
to SUCCESS, set the ActiveEPCount field to the number of active endpoints on that 21
device and include an ascending list of all the identifiers of the active endpoints on that 22
device in the ActiveEPList field. 23
24
On receipt of the Active_EP_rsp command, the recipient is either notified of the 26
active endpoints of the remote device indicated in the original Active_EP_req 27
command or notified of an error. If the Active_EP_rsp command is received with 28
a Status of SUCCESS, the ActiveEPCount field indicates the number of entries in 29
the ActiveEPList field. Otherwise, the Status field indicates the error and the 30
ActiveEPList field shall not be included. 31
32
2.4.4.1.7 Match_Desc_rsp 33
34
The Match_Desc_rsp command (ClusterID=0x8006) shall be formatted as
35
36
38
Status NWKAddr Match Match 39
OfInterest Length List
40
41
Figure 2.62 Format of the Match_Desc_rsp Command Frame
42
43
44
45
Table 2.89 specifies the fields of the Match_Desc_rsp command frame.

1
Table 2.89 Fields of the Match_Desc_rsp Command
2
4
Match_Desc_req command
DEVICE_NOT_FOUND, 6
NO_DESCRIPTOR 8
Address 10
MatchLength Integer 0x00-0xff The count of endpoints on the 11
Remote Device that match the 12
request criteria 13
MatchList List of bytes each of which 14
represents an 8-bit endpoint 15
16
18
The Match_Desc_rsp is generated by a remote device in response to a 19
Match_Desc_req either broadcast or directed to the remote device. This command 20
shall be unicast to the originator of the Match_Desc_req command. 21
22
The remote device shall generate the Match_Desc_rsp command using the format
23
illustrated in Table 2.89. If the NWKAddrOfInterest field of the original
24
Match_Desc_req was equal to the broadcast network address for all
25
RxOnWhenIdle devices (0xfffd), the remote device shall apply the match
26
criterion, as described below, that was specified in the original Match_Desc_req
27
command to each of its simple descriptors. If the remote device is the coordinator
28
or a router, it shall also apply the match criterion, as described below, to each
29
simple descriptor that it may have obtained from each of its children.
30
If the NWKAddrOfInterest field of the original Match_Desc_req was not equal to 31
the broadcast network address for all RxOnWhenIdle devices (0xfffd), the remote 32
device shall set the NWKAddrOfInterest field to the same network address that 33
was specified in the original Match_Desc_req command. 34
35
If the NWKAddrOfInterest field matches the network address of the remote
36
device, it shall apply the match criterion, as described below, that was specified in
37
the original Match_Desc_req command to each of its simple descriptors.
38
INV_REQUESTTYPE, set the MatchLength field to 0 and not include the 41
MatchList field. If the NWKAddrOfInterest field does not match the network 42
address of the remote device and it is the coordinator or a router, it shall determine 43
whether the NWKAddrOfInterest field matches the network address is one of its 44
45
Chapter 2
children. If the NWKAddrOfInterest field does not match the network address of
one of the children of the remote device, it shall set the Status field to 1
DEVICE_NOT_FOUND, set the MatchLength field to 0 and not include the 2
MatchList field. 3
4
If the NWKAddrOfInterest matches the network address of one of the children of 5
the remote device, it shall determine whether any simple descriptors for that 6
device are available. If no simple descriptors are available for the child indicated 7
by the NWKAddrOfInterest field, the remote device shall set the Status field to 8
NO_DESCRIPTOR, set the MatchLength field to 0 and not include the MatchList 9
field. If any simple descriptors are available for the child indicated by the 10
NWKAddrOfInterest field, the remote device shall apply the match criterion, as 11
described below, that was specified in the original Match_Desc_req command to 12
each of these simple descriptors. 13
The remote device shall apply the match criteria to each simple descriptor (see 14
sub-clause 2.3.2.6) as follows. The remote device shall first check that the 15
ProfileID field matches the application profile identifier field of the simple 16
descriptor. If the profile identifiers do not match, the remote device shall assume 17
the match to be unsuccessful and perform no further matching. 18
19
If the profile identifiers match, the remote device shall determine whether the 20
match criteria contains a list of input clusters (the NumInClusters field is not equal 21
to 0). If the match criteria contains a list of input clusters, the remote device shall 22
check that at least one of the cluster identifiers listed in the InClusterList field 23
matches one of the cluster identifiers in the application input cluster list field of 24
the simple descriptor. If at least one matching input cluster is found, the remote 25
device shall assume the match to be successful, note the identifier of the endpoint 26
to which this simple descriptor refers and perform no further matching. 27
If the remote device is unable to find any matching input clusters, it shall 28
determine whether the match criterion contains a list of output clusters (the 29
NumOutClusters field is not equal to 0). If the match criterion contains a list of 30
output clusters, the remote device shall check that at least one of the cluster 31
identifiers listed in the OutClusterList field matches one of the cluster identifiers 32
in the application output cluster list field of the simple descriptor. If at least one 33
matching output cluster is found, the remote device shall assume the match to be 34
successful and note the identifier of the endpoint to which this simple descriptor 35
refers. If the remote device is unable to find any output matching clusters, it shall 36
assume to be unsuccessful. 37
38
If the above procedure produces one or more matches, the remote device shall 39
construct a separate Match_Desc_rsp command for each matching device 40
(including itself). For each response, the Status field shall be set to SUCCESS, the 41
NWKAddrOfInterest field shall be set to the address of the appropriate matching 42
device, the MatchLength field shall be set to the number of simple descriptors that 43
matched the criteria for the appropriate matching device and the MatchList field 44
45
shall contain an ascending list of the endpoints on which a simple descriptor

matched the criteria for the appropriate matching device. 1
2
4
On receipt of the Match_Desc_rsp command, the recipient is either notified of the 5
results of its match criterion query indicated in the original Match_Desc_req 6
command or notified of an error. If the Match_Desc_rsp command is received 7
with a Status of SUCCESS, the MatchList field shall contain the list of endpoints 8
containing simple descriptors that matched the criterion. Otherwise, the Status 9
field indicates the error and the MatchList field shall not be included. 10
2.4.4.1.8 Complex_Desc_rsp 11
12
The Complex_Desc_rsp command (ClusterID=0x8010) shall be formatted as 13
15
Status NWKAddr Length Complex 17
19
Figure 2.63 Format of the Complex_Desc_rsp Command Frame 20
21
Table 2.90 specifies the fields of the Complex_Desc_rsp command frame. 22
Table 2.90 Fields of the Complex_Desc_rsp Command 23
24
DEVICE_NOT_FOUND, Complex_Desc_req command 27
NO_DESCRIPTOR 29
NWKAddrOfInterest Device 16 bit NWK address NWK address for the request 30
Address 31
Length Integer 0x00-0xff Length in bytes of the 32
ComplexDescriptor field 33
34
ComplexDescriptor Complex See the Complex Descriptor
Descript format in sub-clause 2.3.2.7. 35
or This field shall only be 36
included in the frame if the 37
status field is equal to 38
SUCCESS 39
40
41
42
43
44
45
Chapter 2

1
The Complex_Desc_rsp is generated by a remote device in response to a 2
Complex_Desc_req directed to the remote device. This command shall be unicast 3
to the originator of the Complex_Desc_req command. 4
The remote device shall generate the Complex_Desc_rsp command using the 5
format illustrated in Table 2.90. The NWKAddrOfInterest field shall match that 6
specified in the original Complex_Desc_req command. If the 7
NWKAddrOfInterest field matches the network address of the remote device but a 8
complex descriptor does not exist, it shall set the Status field to 9
NOT_SUPPORTED, set the Length field to 0 and not include the 10
ComplexDescriptor field. If the NWKAddrOfInterest field matches the network 11
address of the remote device and a complex descriptor exists, it shall set the Status 12
field to SUCCESS, set the Length field to the length of the complex descriptor 13
and include its complex descriptor (see sub-clause 2.3.2.7) in the 14
ComplexDescriptor field. 15
16
ComplexDescriptor field. If the NWKAddrOfInterest field does not match the 20
ComplexDescriptor field. If the NWKAddrOfInterest matches the network 26
address of one of the children of the remote device, it shall determine whether a 27
complex descriptor for that device is available. If a complex descriptor is not 28
available for the child indicated by the NWKAddrOfInterest field, the remote 29
device shall set the Status field to NO_DESCRIPTOR, set the Length field to 0 30
and not include the ComplexDescriptor field. If a complex descriptor is available 31
for the child indicated by the NWKAddrOfInterest field, the remote device shall 32
set the Status field to SUCCESS, set the Length field to the length of the complex 33
descriptor for that device and include the complex descriptor (see sub- 34
clause 2.3.2.7) of the matching child device in the ComplexDescriptor field. 35
36
38
On receipt of the Complex_Desc_rsp command, the recipient is either notified of
39
the complex descriptor of the remote device indicated in the original
40
Complex_Desc_req command or notified of an error. If the Complex_Desc_rsp
41
command is received with a Status of SUCCESS, the ComplexDescriptor field
42
shall contain the requested complex descriptor. Otherwise, the Status field
43
indicates the error and the ComplexDescriptor field shall not be included.
44
45
2.4.4.1.9 User_Desc_rsp
1
The User_Desc_rsp command (ClusterID=0x8011) shall be formatted as 2
4
Octet: 1 2 1 Variable
5
Status NWKAddr Length User 6
8
Figure 2.64 Format of the User_Desc_rsp Command Frame 9
10
Table 2.91 specifies the fields of the User_Desc_rsp command frame. 11
Table 2.91 Fields of the User_Desc_rsp Command 12
13
NOT_SUPPORTED, User_Desc_req 16
DEVICE_NOT_FOUND, command 17
INV_REQUESTTYPE or
18
NO_DESCRIPTOR
19
NWKAddrOfInterest Device 16-bit NWK address NWK address for the 20
Address request
21
Length Integer 0x00-0x10 Length in bytes of the 22
UserDescriptor field 23
UserDescriptor User See the User Descriptor 24
Descriptor format in sub- 25
clause 2.3.2.8. This 26
field shall only be 27
included in the frame if
the status field is equal 28
to SUCCESS 29
30
31
32
The User_Desc_rsp is generated by a remote device in response to a 33
User_Desc_req directed to the remote device. This command shall be unicast to 34
the originator of the User_Desc_req command. 35
36
The remote device shall generate the User_Desc_rsp command using the format 37
in the original User_Desc_req command. If the NWKAddrOfInterest field 39
matches the network address of the remote device but a user descriptor does not 40
exist, it shall set the Status field to NO_DESCRIPTOR, set the Length field to 0 41
and not include the UserDescriptor field. If the NWKAddrOfInterest field 42
matches the network address of the remote device and a user descriptor exists, it 43
shall set the Status field to SUCCESS, set the Length field to the length of the user 44
45
Chapter 2
descriptor and include its user descriptor (see sub-clause 2.3.2.8) in the
UserDescriptor field. 1
2
UserDescriptor field. If the NWKAddrOfInterest field does not match the network 6
address of the remote device and it is the coordinator or a router, it shall determine 7
whether the NWKAddrOfInterest field matches the network address is one of its 8
children. If the NWKAddrOfInterest field does not match the network address of 9
one of the children of the remote device, it shall set the Status field to 10
UserDescriptor field. If the NWKAddrOfInterest matches the network address of 12
one of the children of the remote device, it shall determine whether a user 13
descriptor for that device is available. If a user descriptor is not available for the 14
child indicated by the NWKAddrOfInterest field, the remote device shall set the 15
Status field to NO_DESCRIPTOR, set the Length field to 0 and not include the 16
UserDescriptor field. If a user descriptor is available for the child indicated by the 17
SUCCESS, set the Length field to the length of the user descriptor for that device 19
and include the user descriptor (see sub-clause 2.3.2.8) of the matching child 20
device in the UserDescriptor field. 21
22
On receipt of the User_Desc_rsp command, the recipient is either notified of the 24
user descriptor of the remote device indicated in the original User_Desc_req 25
command or notified of an error. If the User_Desc_rsp command is received with 26
a Status of SUCCESS, the UserDescriptor field shall contain the requested user 27
descriptor. Otherwise, the Status field indicates the error and the UserDescriptor 28
field shall not be included. 29
30
2.4.4.1.10 System_Server_Discovery_rsp 31
32
The System_Server_Discovery_rsp command (ClusterID=0x8015) shall be
33
formatted as illustrated in Figure 2.68.
34
Octet: 1 2 35
36
Status ServerMask 37
38
Figure 2.65 System_Server_Discovery_rsp Command Frame
39
40
41
42
43
44
45
Table 2.92 specifies the fields of the Discovery_register_rsp command frame.

1
Table 2.92 Fields of the System_Server_Discovery_rsp Command
2
4
Status Integer SUCCESS The status of the 5
System_Server_Discovery_rsp command
6
ServerMask Integer Bitmap See Table 2.29 for bit assignments 7
8
10
The System_Server_Discovery_rsp is generated from Remote Devices on receipt 11
of a System_Server_Discovery_req primitive if the parameter matches the Server 12
Mask field in its node descriptor. (If there is no match, the 13
System_Server_Discovery_req shall be ignored and no response given). Matching 14
is performed by masking the ServerMask parameter of the 15
System_Server_Discovery_req with the Server Mask field in the node descriptor. 16
This command shall be unicast to the device which sent 17
System_Server_Discovery_req with Acknowledge request set in TxOptions. The 18
parameter ServerMask contains the bits in the parameter of the request which 19
match the server mask in the node descriptor. 20
21
23
The requesting device is notified that this device has some of the system server
24
functionality that the requesting device is seeking.
25
2.4.4.1.11 User_Desc_conf 26
27
The User_Desc_conf command (ClusterID=0x8014) shall be formatted as
28
29
Octets: 1 2 30
31
Status NWKAddr 32
OfInterest
33
34
Figure 2.66 Format of the User_Desc_conf Command Frame
35
36
37
38
39
40
41
42
43
44
45
Chapter 2
Table 2.93 specifies the fields of the User_Desc_conf command frame.

1
Table 2.93 Fields of the User_Desc_conf Command
2
4
NOT_SUPPORTED, User_Desc_set command
DEVICE_NOT_FOUND, 6
NO_DESCRIPTOR 8
NWKAddrOfInterest Device Any 16-bit NWK address The network address of the 9
Address device on which the user 10
descriptor set attempt was 11
made 12
13
15
The User_Desc_conf is generated by a remote device in response to a 16
User_Desc_set directed to the remote device. This command shall be unicast to 17
the originator of the User_Desc_set command. 18
The remote device shall generate the User_Desc_conf command using the format 19
in the original User_Desc_set command. If the NWKAddrOfInterest field 21
matches the network address of the remote device but a user descriptor does not 22
exist, it shall set the Status field to NOT_SUPPORTED. If the 23
NWKAddrOfInterest field matches the network address of the remote device and 24
a user descriptor exists, it shall set the Status field to SUCCESS and configure the 25
user descriptor with the ASCII character string specified in the original 26
User_Desc_set command. 27
28
INV_REQUESTTYPE. If the NWKAddrOfInterest field does not match the 31
DEVICE_NOT_FOUND. If the NWKAddrOfInterest matches the network 36
address of one of the children of the remote device, it shall determine whether a 37
user descriptor for that device is available. If a user descriptor is not available for 38
the child indicated by the NWKAddrOfInterest field, the remote device shall set 39
the Status field to NO_DESCRIPTOR. If a user descriptor is available for the 40
child indicated by the NWKAddrOfInterest field, the remote device shall set the 41
Status field to SUCCESS and configure the user descriptor with the ASCII 42
character string specified in the original User_Desc_set command. 43
44
45

1
The local device is notified of the results of its attempt to configure the user 2
descriptor on a remote device. 3
2.4.4.1.12 Discovery_Cache_rsp 4
5
The Discovery_Cache_rsp command (ClusterID=0x8012) shall be formatted as 6
8
Octets: 1 9
Status 10
11
Figure 2.67 Format of the Discovery_Cache_rsp Command Frame 12
13
Table 2.94. specifies the fields of the Discovery_Cache_rsp Command Frame. 14
Table 2.94 Fields of the Discovery_Cache_rsp Command 15
16
Status Integer SUCCESS The status of the 18
Discovery_Cache_req command 19
20
21
22
The Discovery_Cache_rsp is generated by Primary Discovery Cache devices 23
receiving the Discovery_Cache_req. Remote Devices which are not Primary 24
Discovery Cache devices (as designated in its Node Descriptor) should not 25
respond to the Discovery_Cache_req command. 26
27
29
Upon receipt of the Discovery_Cache_rsp, the Local Device determines if a 30
SUCCESS status was returned. If no Discovery_Cache_rsp messages were 31
returned from the original Discovery_Cache_req command, then the Local Device 32
should increase the radius for the request to locate Primary Discovery Cache 33
devices beyond the radius supplied in the previous request. If a SUCCESS status 34
is returned, the Local Device should use the Discovery_Store_req, targeted to the 35
Remote Device supplying the response, to determine whether sufficient discovery 36
cache storage is available. 37
38
39
40
41
42
43
44
45
Chapter 2
2.4.4.1.13 Discovery_store_rsp
1
The Discovery_store_rsp command (ClusterID=0x8016) shall be formatted as 2
4
Octets: 1
5
Status 6
7
Figure 2.68 Format of the Discovery_store_rsp Command Frame 8
9
Table 2.95 specifies the fields of the Discovery_store_rsp command frame 10
Table 2.95 Fields of the Discovery_store_rsp Command 11
12
INSUFFICIENT_SPACE Discovery_store_req command 15
or NOT_SUPPORTED 16
17
19
The Discovery_store_rsp is provided to notify a Local Device of the request status 20
from a Primary Discovery Cache device. Included in the response is a status code 21
to notify the Local Device whether the request is successful (the Primary Cache 22
Device has space to store the discovery cache data for the Local Device), whether 23
the request is unsupported (meaning the Remote Device is not a Primary 24
Discovery Cache device) or whether insufficient space exists. 25
26
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 process any other Discovery_store_rsp devices from other Remote
32
Devices or re-perform the Discovery_Cache_req to determine the address of
33
another Primary Discovery Cache device (eliminating the address of the Remote
34
Device that responded with NOT_SUPPORTED if it responds again to the
35
Discovery_Cache_req). If an INSUFFICIENT_SPACE status is returned, the
36
Local Device should also process any other Discovery_store_rsp and re-perform
37
the Discovery_Cache_req if none of the responses indicate SUCCESS (with the
38
radius field increased to include more Remote Devices). If a SUCCESS status is
39
returned, the Local Device shall upload its discovery cache information to the
40
Remote Device via the Node_Desc_store_req, Power_Desc_store_req,
41
Active_EP_store_req and Simple_Desc_store_req.
42
43
44
45
2.4.4.1.14 Node_Desc_store_rsp
1
The Node_Desc_store_rsp command (ClusterID=0x8017) shall be formatted as 2
4
Octets: 1
5
Status 6
7
Figure 2.69 Format of the Node_Desc_store_rsp Command Frame 8
9
Table 2.96 specifies the fields of the Node_Desc_store_rsp command frame. 10
Table 2.96 Fields of the Node_Desc_store_rsp Command 11
12
Status Integer SUCCESS, The status of the Node_store_rsp 14
INSUFFICIENT_SPACE command 15
or NOT_SUPPORTED 16
17
19
The Node_store_rsp is provided to notify a Local Device of the request status 20
from a Primary Discovery Cache device. Included in the response is a status code 21
to notify the Local Device whether the request is successful (the Primary Cache 22
Device has space to store the discovery cache data for the Local Device), whether 23
the request is not supported (meaning the Remote Device is not a Primary 24
26
28
29
30
31
Device should re-perform discovery of the Primary Discovery Cache device. If
32
an INSUFFICIENT_SPACE status is returned, the Local Device shall also send
33
the Remote Device a Remove_node_cache_req. If a SUCCESS status is returned,
34
the Local Device should continue to upload its remaining discovery cache
35
information to the Remote Device via the Power_Desc_store_req,
36
Active_EP_store_req and Simple_Desc_store_req.
37
38
39
40
41
42
43
44
45
Chapter 2
2.4.4.1.15 Power_Desc_store_rsp
1
The Power_Desc_store_rsp command (ClusterID=0x8018) shall be formatted as 2
4
5
Status IEEEAddr PowerDescriptor 6
7
Figure 2.70 Format of the Power_Desc_store_rsp Command Frame 8
9
Table 2.97 specifies the fields of the Power_Desc_store_rsp command frame. 10
Table 2.97 Fields of the Power_Desc_store_rsp Command 11
12
Status Integer SUCCESS, The status of the Power_store_rsp 14
INSUFFICIENT_SPACE command 15
or NOT_SUPPORTED 16
17
19
The Power_Desc_store_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 space to store the discovery cache data for the Local Device), 23
whether the request is not supported (meaning the Remote Device is not a Primary 24
26
28
29
30
31
Device should re-perform discovery on the Primary Discovery Cache. If an
32
INSUFFICIENT_SPACE status is returned, the Local Device shall discontinue
33
upload of discovery information, issue a Remove_node_cache_req (citing the
34
Local Device) and cease attempts to upload discovery information to the Remote
35
Device.
36
If a SUCCESS status is returned, the Local Device should continue to upload its 37
remaining discovery cache information to the Remote Device via the 38
Active_EP_store_req and Simple_Desc_store_req. 39
40
41
42
43
44
45
2.4.4.1.16 Active_EP_store_rsp
1
The Active_EP_store_rsp command (ClusterID=0x8019) shall be formatted as 2
4
Octets: 1
5
Status 6
7
Figure 2.71 Format of the Active_EP_store_rsp Command Frame 8
9
Table 2.98 specifies the fields of the Active_EP_store_rsp command frame. 10
Table 2.98 Fields of the Active_EP_store_rsp Command 11
12
INSUFFICIENT_SPACE Active_EP_store_rsp command 15
or NOT_SUPPORTED 16
17
19
The Active_EP_store_rsp is provided to notify a Local Device of the request 20
26
28
29
30
31
32
33
34
35
Device. If a SUCCESS status is returned, the Local Device should continue to
36
upload its remaining discovery cache information to the Remote Device via the
37
Simple_Desc_store_req.
38
39
40
41
42
43
44
45
Chapter 2
2.4.4.1.17 Simple_Desc_store_rsp
1
The Simple_Desc_store_rsp command (ClusterID=0x801a) shall be formatted as 2
4
Octets: 1
5
Status 6
7
Figure 2.72 Format of the Simple_Desc_store_rsp Command Frame 8
9
Table 2.99 specifies the fields of the Simple_Desc_store_rsp command frame. 10
Table 2.99 Fields of the Simple_Desc_store_rsp Command 11
12
INSUFFICIENT_SPACE Simple_desc_store_rsp 15
or NOT_SUPPORTED command 16
17
19
The Simple_Desc_store_rsp is provided to notify a Local Device of the request 20
26
28
29
30
31
32
33
34
35
Device. If a SUCCESS status is returned, the Local Device should continue to
36
upload its remaining discovery cache information to the Remote Device via the
37
Simple_Desc_store_req for other endpoints on the Local Device.
38
39
40
41
42
43
44
45
2.4.4.1.18 Remove_node_cache_rsp
1
The Remove_node_cache_rsp command (ClusterID=0x801b) shall be formatted 2
4
Octets: 1
5
Status 6
7
Figure 2.73 Format of the Remove_node_cache_rsp Command Frame 8
9
Table 2.100 specifies the fields of the Remove_node_cache_rsp command frame. 10
Table 2.100 Fields of the Remove_node_cache_rsp Command 11
12
DEVICE_NOT_FOUND Remove_node_cache_rsp 15
or NOT_SUPPORTED command 16
17
19
The Remove_node_cache_rsp is provided to notify a Local Device of the request 20
Cache Device has removed the discovery cache data for the indicated device of 23
interest) or whether the request is not supported (meaning the Remote Device is 24
not a Primary Discovery Cache device). 25
26
28
29
30
31
Device should re-perform Find_node_cache_req to locate the Primary Discovery
32
Cache device holding the discovery cache information for the indicated device of
33
interest. When the Primary Discovery Cache device holding the discovery
34
information for the device of interest is located, the Local Device should repeat
35
the Remove_node_cache_req to successfully remove the discovery information. If
36
a status of DEVICE_NOT_FOUND is received, this indicates that the Remote
37
Device is the Primary Discovery Cache but does not hold the discovery
38
information for the NWKAddr and the IEEEAddr presented in the request. The
39
Local Device should employ the device discovery commands NWK_Addr_req
40
and IEEE_Addr_req to determine the correct values for NWKAddr and
41
IEEEAddr. If a SUCCESS status is returned, the Local Device has successfully
42
removed the discovery cache information for the indicated device of interest
43
within the request.
44
45
Chapter 2
2.4.4.1.19 Find_node_cache_rsp
1
The Find_node_cache_rsp command (ClusterID=0x801c) shall be formatted as 2
4
Octets: 2 2 8
5
CacheNWKAddress NWKAddr IEEEAddr 6
7
Figure 2.74 Format of the Find_node_cache_rsp Command Frame 8
9
Table 2.101 specifies the fields of the Find_node_cache_rsp command frame. 10
Table 2.101 Fields of the Find_node_cache_rsp Command 11
12
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 17
the request directly)
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
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
35
Upon receipt, the Local Device shall utilize the CacheNWKAddr as the Remote 36
Device address for subsequent discovery requests relative to the NWKAddr and 37
IEEEAddr in the response. 38
39
40
41
42
43
44
45
2.4.4.2 End Device Bind, Bind, Unbind Bind Management

1
Server Services 2
Table 2.102 lists the commands supported by Device Profile: End Device Bind, 3
Bind and Unbind Server Services. Each of these primitives will be discussed in 4
the following subclauses. 5
6
Table 2.102 End Device Bind, Unbind and Bind Management
Server Services Primitives 7
8
End Device Bind, Bind and Unbind Server 9
Server Service Commands Processing 10
End_Device_Bind_rsp O 11
12
Bind_rsp O 13
Unbind_rsp O 14
Bind_Register_rsp O
15
16
Replace_Device_rsp O 17
Store_Bkup_Bind_Entry_rsp O 18
19
Remove_Bkup_Bind_Entry_rsp O
20
Backup_Bind_Table_rsp O 21
Recover_Bind_Table_rsp O 22
23
Backup_Source_Bind_rsp O
24
Recover_Source_Bind_rsp O 25
26
2.4.4.2.1 End_Device_Bind_rsp 27
28
The End_Device_Bind_rsp command (ClusterID=0x8020) shall be formatted as 29
31
Octets: 1
32
Status 33
34
Figure 2.75 Format of the End_Device_Bind_rsp Command Frame 35
36
37
38
39
40
41
42
43
44
45
Chapter 2
Table 2.103 specifies the fields of the End_Device_Bind_rsp command frame.

1
Table 2.103 Fields of the End_Device_Bind_rsp Command
2
4
Status Integer SUCCESS, The status of the End_Device_Bind_req 5
NOT_SUPPORTED, command
INVALID_EP, 6
TIMEOUT or 7
NO_MATCH 8
9
11
The End_Device_Bind_rsp is generated by the ZigBee Coordinator in response to 12
an End_Device_Bind_req and contains the status of the request. This command 13
shall be unicast to each device involved in the bind attempt, using the 14
acknowledged data service. 15
A Status of NOT_SUPPORTED indicates that the request was directed to a device 16
which was not the ZigBee Coordinator or that the ZigBee Coordinator does not 17
support End Device Binding. Else, End_Device_Bind_req processing is 18
performed as described below including transmission of the 19
End_Device_Bind_rsp. 20
21
22
23
When an End_Device_Bind_req is received, determination is made if a Status of 24
NOT_SUPPORTED is warranted as indicated in the previous section. Assuming 25
this device is the ZigBee Coordinator, the supplied endpoint shall be checked to 26
determine whether it falls within the specified range. If it does not, a Status of 27
INVALID_EP shall be returned. If the supplied endpoint falls within the specified 28
range and if this is the first End_Device_Bind_req submitted for evaluation, it 29
shall be stored and a timer started which expires at a pre-configured timeout 30
value. This timeout values shall be a configurable item on the ZigBee 31
Coordinator. If the timer expires before a second End_Device_Bind_req is 32
received, a Status of TIMEOUT is returned. Else, if a second 33
End_Device_Bind_req is received within the timeout window, the two 34
End_Device_Bind_req's are compared for a match. A Status of NO_MATCH 35
indicates that two End_Device_Bind_req were evaluated for a match but either 36
the ProfileID parameters did not match or the ProfileID parameter matched but 37
there was no match of any element of the InClusterList or OutClusterList. A 38
Status of SUCCESS means that a match was detected and a resulting Bind_req 39
will subsequently be9 directed to the Local Device supplying the 40
End_Device_Bind_req with matched elements of the OutClusterList.10 41
42
43
9. CCB #602 44
45
2.4.4.2.2 Bind_rsp
1
The Bind_rsp command (ClusterID=0x8021) shall be formatted as illustrated in 2
Figure 2.76. 3
4
Octets: 1
5
Status 6
7
Figure 2.76 Format of the Bind_rsp Command Frame 8
9
Table 2.104 specifies the fields of the Bind_rsp command frame. 10
Table 2.104 Fields of the Bind_rsp Command 11
12
Status Integer SUCCESS, The status of the Bind_req command 14
NOT_SUPPORTED, 15
16
INVALID_EP or
TABLE_FULL 17
18
19
The Bind_rsp is generated in response to a Bind_req. If the Bind_req is processed 21
and the Binding Table entry committed on the Remote Device, a Status of 22
SUCCESS is returned. If the Remote Device is not the a Primary binding table 23
cache or the SrcAddress, a Status of NOT_SUPPORTED is returned. The 24
supplied endpoint shall be checked to determine whether it falls within the 25
specified range. If it does not, a Status of INVALID_EP shall be returned.11 If the 26
Remote Device is the Primary binding table cache or SrcAddress but does not 27
have Binding Table resources for the request, a Status of TABLE_FULL is 28
returned. 29
30
32
Upon receipt, error checking is performed on the request as described in the 33
previous section. Assuming the Status is SUCCESS, the parameters from the 34
Bind_req are entered into the Binding Table at the Remote Device via the 35
APSME-BIND.request primitive. 36
37
38
39
40
41
42
10. CCB #518 43
11. CCB #531 44
45
Chapter 2
2.4.4.2.3 Unbind_rsp
1
The Unbind_rsp command (ClusterID=0x8022) shall be formatted as illustrated in 2
Figure 2.77. 3
4
Octets: 1
5
Status 6
7
Figure 2.77 Format of the Unbind_rsp Command Frame 8
9
Table 2.105 specifies the fields of the Unbind_rsp command frame. 10
Table 2.105 Fields of the Unbind_rsp Command 11
12
Status Integer SUCCESS, The status of the Unbind_req command 14
NOT_SUPPORTED, 15
16
INVALID_EP or
NO_ENTRY 17
18
19
The Unbind_rsp is generated in response to an Unbind_req. If the Unbind_req is 21
processed and the corresponding Binding Table entry is removed from the Remote 22
Device, a Status of SUCCESS is returned. If the Remote Device is not the ZigBee 23
Coordinator or the SrcAddress, a Status of NOT_SUPPORTED is returned. The 24
supplied endpoint shall be checked to determine whether it falls within the 25
specified range. If it does not, a Status of INVALID_EP shall be returned.12 If the 26
Remote Device is the ZigBee Coordinator or SrcAddress but does not have a 27
Binding Table entry corresponding to the parameters received in the request, a 28
Status of NO_ENTRY is returned. 29
30
32
Upon receipt, error checking is performed on the response. If the status is 33
SUCCESS, the device has successfully removed the binding entry for the 34
parameters specified in the Unbind_req. 35
36
37
38
39
40
41
42
43
12. CCB #531 44
45
2.4.4.2.4 Bind_Register_rsp
1
The Bind_Register_rsp command (ClusterID=0x8023) shall be formatted as 2
4
Octets: 1 2 2 Variable
5
Status BindingTableEntries BindingTableListCount BindingTableList 6
7
Figure 2.78 Format of the Bind_Register_rsp Command Frame 8
9
Table 2.106 specifies the fields of the Bind_Register_rsp command frame. 10
Table 2.106 Fields of the Bind_Register_rsp Command 11
12
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
22
BindingTable List of This list shall contain the A list of source binding
List source number of elements 23
binding given by the 24
descriptors BindingTableListCount 25
26
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
32
If the device receiving the Bind_Register_req is not a primary binding table cache
33
a Status of NOT_SUPPORTED is returned. If its list of devices which choose to
34
store their own binding table entries is full a status of TABLE_FULL is returned.
35
In these error cases, BindingTableEntries and BindingTableListCount shall be
36
zero and BindingTableList shall be empty. A Status of SUCCESS indicates that
37
the requesting device has been successfully registered.
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
Chapter 2
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
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
13
Octets: 1 14
Status 15
16
Figure 2.79 Format of the Replace_Device_rsp Command Frame 17
18
Table 2.107 specifies the fields of the Replace_Device_rsp command frame 19
Table 2.107 Fields of the Replace_Device_rsp Command 20
21
23
Status Integer NOT_SUPPORTED, The status of the Replace_Device_req
INV_REQUESTTYPE command 24
25
26
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
40
The requesting device is notified of the status of its Replace_Device_req 41
command. 42
43
44
45
2.4.4.2.6 Store_Bkup_Bind_Entry_rsp
1
The Store_Bkup_Bind_Entry_rsp command (ClusterID=0x8025) shall be 2
4
Octets: 1
5
Status 6
7
Figure 2.80 Format of the Store_Bkup_Bind_Entry_rsp Command Frame 8
9
Table 2.108 specifies the fields of the Store_Bkup_Bind_Entry_rsp command 10
frame. 11
Table 2.108 Fields of the Store_Bkup_Bind_Entry_rsp Command 12
13
NOT_SUPPORTED, Store_Bkup_Bind_Entry_rsp command 16
INV_REQUESTTYPE. 17
TABLE_FULL 18
19
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
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
36
The Remove_Bkup_Bind_Entry_rsp command (ClusterID=0x8026) shall be
37
formatted as illustrated in Figure 2.81.
38
Octets: 1 39
40
Status 41
42
Figure 2.81 Format of the Remove_Bkup_Bind_Entry_rsp Command Frame
43
44
45
Chapter 2
Table 2.109 specifies the fields of the Remove_Bkup_Bind_Entry_rsp command

frame. 1
2
Table 2.109 Fields of the Remove_Bkup_Bind_Entry_rsp Command
3
5
NOT_SUPPORTED, Remove_Bkup_Bind_Entry_rsp
INV_REQUESTTYPE, command 7
NO_ENTRY 8
9
10
11
The Remove_Bkup_Bind_Entry_rsp is generated from a backup binding table 12
cache device in response to a Remove_Bkup_Bind_Entry_req from the primary 13
binding table cache and contains the status of the request. This command shall be 14
unicast to the requesting device. If the remote device is not a backup binding table 15
cache it shall return a status of NOT_SUPPORTED. If the originator of the 16
request is not recognized as a primary binding table cache it shall return a status of 17
INV_REQUESTTYPE. Otherwise, the backup binding table cache shall delete 18
the binding entry from its binding table and return a status of SUCCESS. If the 19
entry is not found it shall return a status of NO_ENTRY. 20
21
23
The requesting device is notified of the status of its attempt to remove a bind entry 24
from the backup cache. 25
2.4.4.2.8 Backup_Bind_Table_rsp 26
27
The Backup_Bind_Table_rsp command (ClusterID=0x8027) shall be formatted as 28
30
Octets: 1 2 31
Status EntryCount 32
33
Figure 2.82 Format of the Backup_Bind_Table_rsp Command Frame 34
35
36
37
38
39
40
41
42
43
44
45
Table 2.110 specifies the fields of the Backup_Bind_Table_rsp command frame.

1
Table 2.110 Fields of the Backup_Bind_Table_rsp Command
2
4
NOT_SUPPORTED, Backup_Bind_Table_rsp command
TABLE_FULL, 6
INV_REQUESTTYPE 7
8
EntryCount Integer 0x0000 - 0xFFFF The number of entries in the backup
bind table 9
10
11
The Backup_Bind_Table_rsp is generated from a backup binding table cache 13
device in response to a Backup_Bind_Table_req from a primary binding table 14
INV_REQUESTTYPE. Otherwise, the backup binding table cache shall 19
overwrite the binding entries in its binding table starting with StartIndex and 20
continuing for BindingTableListCount entries. If this exceeds its table size it shall 21
fill in as many entries as possible and return a status of TABLE_FULL and the 22
EntryCount parameter will be the number of entries in the table. Otherwise it shall 23
return a status of SUCCESS and EntryCount will be equal to StartIndex + 24
BindingTableListCount from Backup_Bind_Table_req. 25
26
28
The requesting device is notified of the status of its attempt to store a bind table. 29
30
2.4.4.2.9 Recover_Bind_Table_rsp
31
The Backup_Bind_Table_rsp command (ClusterID=0x8028) shall be formatted as 32
34
Octets: 1 2 2 2 Variable 35
Status BindingTableEntries StartIndex BindingTableListCount BindingTableList 36
37
Figure 2.83 Format of the Backup_Bind_Table_rsp Command Frame 38
39
40
41
42
43
44
45
Chapter 2
Table 2.111 specifies the fields of the Recover_Bind_Table_rsp command frame.

1
Table 2.111 Fields of the Recover_Bind_Table_rsp Command
2
4
NOT_SUPPORTED, Recover_Bind_Table_rsp command
INV_REQUESTTYPE, 6
NO_ENTRY 7
8
BindingTable Integer 0x0000 - 0xffff Total number of binding table
Entries entries in the backup binding cache 9
10
StartIndex Integer 0x0000 - 0xffff Starting index within the binding 11
table to begin reporting for the
binding table list 12
13
BindingTable Integer 0x0000 - 0xffff Number of binding entries included 14
ListCount within BindingTableList
15
BindingTable Integer The list shall contain the A list of descriptors, beginning with 16
List number of elements given the StartIndex element and 17
by BindingTableListCount continuing for
18
BindingTableListCount of elements
in the backup binding table cache 19
20
21
The Recover_Bind_Table_rsp is generated from a backup binding table cache 23
device in response to a Recover_Bind_Table_req from a primary binding table 24
requesting device. If the responding device is not a backup binding table cache it 26
shall return a status of NOT_SUPPORTED. If the originator of the request is not 27
INV_REQUESTTYPE. Otherwise, the backup binding table cache shall prepare a 29
list of binding table entries from its backup beginning with StartIndex. It will fit in 30
as many entries as possible into a Recover_Bind_Table_rsp command and return a 31
status of SUCCESS. If StartIndex is more than the number of entries in the 32
Binding table, a status of NO_ENTRY is returned. For a successful response, 33
BindingTableEntries is the total number of entries in the backup binding table, 34
BindingTableListCount is the number of entries which is being returned in the 35
response. 36
37
39
The requesting device is notified of the status of its attempt to restore a bind table. 40
41
42
43
44
45
2.4.4.2.10 Backup_Source_Bind_rsp
1
The Backup_Source_Bind_rsp command (ClusterID=0x8029) shall be formatted 2
4
Octets: 1
5
Status 6
7
Figure 2.84 Format of the Backup_Source_Bind_rsp Command Frame 8
9
Table 2.112 specifies the fields of the Backup_Source_Bind_rsp command frame. 10
Table 2.112 Fields of the Backup_Source_Bind_rsp Command 11
12
NOT_SUPPORTED, Backup_Source_Bind_rsp 15
TABLE_FULL, command 16
INV_REQUESTTYPE 17
18
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
INV_REQUESTTYPE. Otherwise, the backup binding table cache shall 27
overwrite its backup source bind table starting with StartIndex and continuing for 28
BindingTableListCount entries. If this exceeds its table size it shall return a status 29
of TABLE_FULL. Otherwise it shall return a status of SUCCESS. 30
31
The requesting device is notified of the status of its attempt to backup the source 33
bind table. 34
35
2.4.4.2.11 Recover_Source_Bind_rsp 36
37
The Recover_Source_Bind_rsp command (ClusterID=0x802a) shall be formatted
38
as illustrated in Figure 2.85.
39
41
Status SourceTableEntries StartIndex SourceTableListCount SourceTableList 42
43
Figure 2.85 Format of the Recover_Source_Bind_rsp Command Frame
44
45
Chapter 2
Table 2.113 specifies the fields of the Recover_Source_Bind_rsp command

frame. 1
2
Table 2.113 Fields of the Recover_Source_Bind_rsp Command
3
5
NOT_SUPPORTED, Recover_Source_Bind_rsp
TABLE_FULL, command 7
INV_REQUESTTYPE 8
9
SourceTableE Integer 0x0000 - 0xffff Total number of source table entries
ntries in the backup binding cache 10
11
StartIndex Integer 0x0000 - 0xffff Starting index within the source 12
table to begin reporting for the
source table list 13
14
SourceTableL Integer 0x0000 - 0xffff Number of source table entries 15
istCount included within SourceTableList
16
SourceTableL List of source The list shall contain A list of descriptors, beginning with 17
ist descriptors the number of elements the StartIndex element and 18
given by continuing for
19
SourceTableListCount SourceTableListCount of elements
in the backup source table cache 20
(consisting of IEEE addresses) 21
22
23
24
The Recover_Source_Bind_rsp is generated from a backup binding table cache 25
device in response to a Recover_Source_Bind_req from a primary binding table 26
requesting device. If the responding device is not a backup binding table cache it 28
shall return a status of NOT_SUPPORTED. If the originator of the request is not 29
INV_REQUESTTYPE. Otherwise, the backup binding table cache shall prepare a 31
list of binding table entries from its backup beginning with StartIndex. It will fit in 32
as many entries as possible into a Recover_Source_Bind_rsp command and return 33
a status of SUCCESS. If StartIndex is more than the number of entries in the 34
Source table, a status of NO_ENTRY is returned. For a successful response, 35
SourceTableEntries is the total number of entries in the backup source table, 36
SourceTableListCount is the number of entries which is being returned in the 37
response. 38
39
41
The requesting device is notified of the status of its attempt to restore a source 42
bind table. 43
44
45
2.4.4.3 Network Management Server Services

1
Table 2.114 lists the commands supported by Device Profile: Network 2
Management Server Services. Each of these commands will be discussed in the 3
following sub-clauses. 4
Table 2.114 Network Management Server Service Commands 5
6
Network Management 7
Server Service Server 8
Command Processing
9
Mgmt_NWK_Disc_rsp O 10
11
Mgmt_Lqi_rsp O
12
Mgmt_Rtg_rsp O 13
Mgmt_Bind_rsp O 14
15
Mgmt_Leave_rsp O
16
Mgmt_Direct_Join_rsp O 17
Mgmt_Permit_Joining_rsp M 18
19
Mgmt_Cache_rsp O
20
21
2.4.4.3.1 Mgmt_NWK_Disc_rsp 22
The Mgmt_NWK_Disc_rsp command (ClusterID=0x8030) shall be formatted as 23
25
27
Status Network Start NetworkList NetworkList 28
Count Index Count
29
Figure 2.86 Format of the Mgmt_NWK_Disc_rsp Command Frame 30
31
Table 2.115 specifies the fields of the Mgmt_NWK_Disc_rsp command frame. 32
33
Table 2.115 Fields of the Mgmt_NWK_Disc_rsp Command 34
36
Status Integer NOT_SUPPORTED or The status of the 37
any status code returned Mgmt_NWK_Disc_req
from the command.
38
NLME-NETWORK- 39
DISCOVERY.request 40
primitive. 41
42
43
44
45
Chapter 2
Table 2.115 Fields of the Mgmt_NWK_Disc_rsp Command (Continued)

1
NetworkCount Integer 0x00-0xff The total number of networks
reported by the NLME-
2
NETWORK- 3
DISCOVERY.confirm. 4
5
StartIndex Integer 0x00-0xff The starting point in the
NetworkList from the NLME- 6
NETWORK- 7
DISCOVERY.confirm where 8
reporting begins for this 9
response.
10
NetworkListCount Integer 0x00-0xff The number of network list 11
descriptors reported within this 12
response.
13
NetworkList List of The list shall contain the A list of descriptors, one for each 14
Network number of elements of the networks discovered, 15
Descriptors given by the beginning with the StartIndex 16
NetworkListCount element and continuing for
parameter. NetworkListCount, of the 17
elements returned by the NLME- 18
NETWORK- 19
DISCOVERY.confirm primitive. 20
Each entry shall be formatted as 21
illustrated in table Table 2.116.
22
23
Table 2.116 NetworkList Record Format
24
Size 25
Name (Bits) Valid Range Description 26
27
ExtendedPanID 64 A 64-bit PAN The 64-bit extended PAN identifier of the
identifier discovered network. 28
29
LogicalChannel 8 Selected from the The current logical channel occupied by 30
available logical the network.
channels supported by 31
the PHY (see [B1]) 32
33
StackProfile 4 0x0-0xf A ZigBee stack profile identifier indicating
the stack profile in use in the discovered
34
network. 35
36
ZigBeeVersion 4 0x0-0xf The version of the ZigBee protocol in use
37
in the discovered network.
38
BeaconOrder 4 0x0-0xf This specifies how often the MAC sub- 39
layer beacon is to be transmitted by a given
40
device on the network. For a discussion of
MAC sub-layer beacon order see [B1]. 41
42
43
44
45
Table 2.116 NetworkList Record Format

1
SuperframeOrder 4 0x0-0xf For beacon-oriented networks, i.e. beacon
order < 15, this specifies the length of the
2
active period of the superframe. For a 3
discussion of MAC sub-layer superframe 4
order see [B1]. 5
PermitJoining 1 TRUE or FALSE A value of TRUE indicates that at least one 6
ZigBee router on the network currently 7
permits joining, i.e. its NWK has been 8
issued an NLME-PERMIT-JOINING 9
primitive and the time limit, if given, has
10
not yet expired.
11
Reserved - Each of these bit shall be set to 0. 12
13
15
The Mgmt_NWK_Disc_rsp is generated in response to an 16
Mgmt_NWK_Disc_req. If this management command is not supported, a status 17
of NOT_SUPPORTED shall be returned and all parameter fields after the Status 18
field shall be omitted. Otherwise, the Remote Device shall implement the 19
following processing. 20
Upon receipt of and after support for the Mgmt_NWK_Disc_req has been 21
verified, the Remote Device shall issue an NLME-NETWORK- 22
DISCOVERY.request primitive using the ScanChannels and ScanDuration 23
parameters, supplied in the Mgmt_NWK_Disc_req command. Upon receipt of the 24
NLME-NETWORK-DISCOVERY.confirm primitive, the Remote Device shall 25
report the results, starting with the StartIndex element, via the 26
Mgmt_NWK_Disc_rsp command. The NetworkList field shall contain whole 27
NetworkList records, formatted as specified in Table 2.116, until the limit on 28
MSDU size, i.e. aMaxMACFrameSize (see [B1]), is reached. The number of 29
results reported shall be set in the NetworkListCount. 30
31
33
The local device is notified of the results of its attempt to perform a remote 34
network discovery. 35
36
37
38
39
40
41
42
43
44
45
Chapter 2
2.4.4.3.2 Mgmt_Lqi_rsp
1
The Mgmt_Lqi_rsp command (ClusterID=0x8031) shall be formatted as 2
4
Octets: 1 1 1 1 Variable
5
Status NeighborTable Start NeighborTable NeighborTable 6
Entries Index ListCount List 7
8
Figure 2.87 Format of the Mgmt_Lqi_rsp Command Frame 9
10
Table 2.117 specifies the fields of the Mgmt_Lqi_rsp command frame. 11
Table 2.117 Fields of the Mgmt_Lqi_rsp Command 12
13
any status code returned Mgmt_Lqi_req command 16
from the NLME- 17
GET.confirm primitive
18
NeighborTableEntries Integer 0x00-0x02 Total number of Neighbor 19
Table entries within the 20
Remote Device
21
StartIndex Integer 0x00-0xff Starting index within the 22
Neighbor Table to begin 23
reporting for the 24
NeighborTableList.
25
NeighborTableListCount Integer 0x00-0xff Number of Neighbor Table 26
entries included within 27
NeighborTableList.
28
NeighborTableList List of The list shall contain the A list of descriptors, 29
Neighbor number elements given beginning with the 30
Descripto by the StartIndex element and
rs NeighborTableListCount continuing for 31
NeighborTableListCount, 32
of the elements in the 33
Remote Device's Neighbor 34
Table including the device 35
address and associated LQI
(see Table 2.118 for 36
details). 37
38
39
40
41
42
43
44
45
Table 2.118 NeighborTableList Record Format

1
Size 2
Name (Bits) Valid Range Description
3
Extended PAN Id 64 A 64-bit PAN identifier The 64-bit extended PAN identifier 4
of the neighboring device 5
Extended address 64 An extended 64-bit, IEEE 64-bit IEEE address that is unique to 6
address every device. If this value is 7
unknown at the time of the request, 8
this field shall be set to 9
0xffffffffffffffff.
10
Network address 16 Network address The 16-bit network address of the 11
neighboring device 12
Device type 2 0x0-0x3 The type of the neighbor device: 13
14
0x0 = ZigBee coordinator
15
0x1 = ZigBee router
16
0x2 = ZigBee end device 17
0x3 = Unknown 18
RxOnWhenIdle 2 0x0-0x2 Indicates if neighbor's receiver is 19
enabled during idle portions of the 20
CAP: 21
0x0 = Receiver is off 22
0x1 = Receiver is on 23
0x2 = unknown 24
25
Relationship 3 0x0-0x4 The relationship between the
26
neighbor and the current device:
27
0x0 = neighbor is the parent 28
0x1 = neighbor is a child 29
0x2 = neighbor is a sibling 30
0x3 = None of the above 31
0x4 = previous child 32
33
Reserved 1 This reserved bit shall be set to 0.
34
Permit joining 2 0x0-0x2 An indication of whether the 35
neighbor device is accepting join 36
requests:
37
0x0 = neighbor is not accepting join 38
requests 39
0x1 = neighbor is accepting join 40
requests
41
0x2 = unknown 42
43
44
45
Chapter 2
Table 2.118 NeighborTableList Record Format (Continued) (Continued)

1
Size 2
3
Reserved 6 Each of these reserved bits shall be 4
set to 0. 5
Depth 8 0x00-nwkcMaxDepth The tree depth of the neighbor 6
device. A value of 0x00 indicates 7
that the device is the ZigBee 8
coordinator for the network 9
LQI 8 0x00-0xff The estimated link quality for RF 10
transmissions from this device. See 11
[B1] for discussion of how this is 12
calculated
13
14
16
The Mgmt_Lqi_rsp is generated in response to an Mgmt_Lqi_req. If this
17
management command is not supported, a status of NOT_SUPPORTED shall be
18
returned and all parameter fields after the Status field shall be omitted. Otherwise,
19
the Remote Device shall implement the following processing.
20
Upon receipt of and after support for the Mgmt_Lqi_req has been verified, the 21
Remote Device shall perform an NLME-GET.request (for the nwkNeighborTable 22
attribute) and process the resulting neighbor table (obtained via the NLME- 23
GET.confirm primitive) to create the Mgmt_Lqi_rsp command. If 24
nwkNeighborTable was successfully obtained but one or more of the fields 25
required in the NeighborTableList record (see Table 2.118) are not supported (as 26
they are optional), the Mgmt_Lqi_rsp shall return a status of NOT_SUPPORTED 27
and all parameter fields after the Status field shall be omitted. Otherwise, the 28
Mgmt_Lqi_rsp command shall contain the same status that was contained in the 29
NLME-GET.confirm primitive and if this was not SUCCESS, all parameter fields 30
after the status field shall be omitted. 31
32
From the nwkNeighborTable attribute, the neighbor table shall be accessed,
33
starting with the index specified by StartIndex, shall be moved to the
34
NeighborTableList field of the Mgmt_Lqi_rsp command. The entries reported
35
from the neighbor table shall be those, starting with StartIndex and including
36
whole NeighborTableList records (see Table 2.118) until the limit on MSDU size,
37
i.e., aMaxMACFrameSize (see [B1]), is reached. Within the Mgmt_Lqi_Rsp
38
command, the NeighborTableEntries field shall represent the total number of
39
Neighbor Table entries in the Remote Device. The parameter
40
NeighborTableListCount shall be the number of entries reported in the
41
NeighborTableList field of the Mgmt_Lqi_rsp command.
42
The extended address, device type, rxOnWhenIdle and permit joining fields have 43
“unknown” values which shall be returned where the values are not available. 44
45

1
The local device is notified of the results of its attempt to obtain the neighbor 2
table. 3
2.4.4.3.3 Mgmt_Rtg_rsp 4
5
The Mgmt_Rtg_rsp command (ClusterID=0x8032) shall be formatted as 6
8
Status RoutingTable Start RoutingTable RoutingTable 10
12
Figure 2.88 Format of the Mgmt_Rtg_rsp Command Frame 13
14
Table 2.119 specifies the fields of the Mgmt_Rtg_rsp command frame. . 15
Table 2.119 Fields of the Mgmt_Rtg_rsp Command 16
17
Status Integer NOT_SUPPORTED or The status of the Mgmt_Rtg_req 19
any status code returned command. 20
from the NLME- 21
GET.confirm primitive 22
RoutingTableEntries Integer 0x00-0xff Total number of Routing Table 23
entries within the Remote Device. 24
StartIndex Integer 0x00-0xff Starting index within the Routing 25
Table to begin reporting for the 26
RoutingTableList. 27
RoutingTableListCou Integer 0x00-0xff Number of Routing Table entries 28
nt included within RoutingTableList. 29
30
RoutingTableList List of The list shall contain the A list of descriptors, beginning
Routin number elements given with the StartIndex element and 31
g by the continuing for 32
Descri RoutingTableListCount RoutingTableListCount, of the 33
ptors elements in the Remote Device's 34
Routing Table (see the
35
Table 2.120 for details).
36
37
38
Table 2.120 RoutingTableList Record Format 39
40
Size 41
42
Destination 16 The 16-bit network Destination address. 43
address address of this route. 44
45
Chapter 2
Table 2.120 RoutingTableList Record Format (Continued)

1
Size 2
3
Status 3 The status of the 0x0=ACTIVE. 4
route. 0x1=DISCOVERY_UNDERWAY. 5
0x2=DISCOVERY_FAILED. 6
0x3=INACTIVE. 7
0x4-0x7=RESERVED.
8
9
Reserved 5 Each of these reserved bits shall be 10
set to zero.
11
Next-hop 16 The 16-bit network Next-hop address. 12
address address of the next 13
hop on the way to the
14
destination.
15
16
CCB Comment #250 17
18
20
The Mgmt_Rtg_rsp is generated in response to an Mgmt_Rtg_req. If this 21
management command is not supported, a status of NOT_SUPPORTED shall be 22
returned and all parameter fields after the Status field shall be omitted. Otherwise, 23
the Remote Device shall implement the following processing. 24
Upon receipt of and after support for the Mgmt_Rtg_req has been verified, the 25
Remote Device shall perform an NLME-GET.request (for the nwkRouteTable 26
attribute) and process the resulting NLME-GET.confirm (containing the 27
nwkRouteTable attribute) to create the Mgmt_Rtg_rsp command. The 28
Mgmt_Rtg_rsp command shall contain the same status that was contained in the 29
NLME-GET.confirm primitive and if this was not SUCCESS, all parameter fields 30
after the status field shall be omitted. 31
32
From the nwkRouteTable attribute, the routing table shall be accessed, starting 33
with the index specified by StartIndex, and moved to the RoutingTableList field of 34
the Mgmt_Rtg_rsp command. The entries reported from the routing table shall be 35
those, starting with StartIndex and including whole RoutingTableList records (see 36
Table 2.119) until MSDU size limit, i.e aMaxMACFrameSize (see [B1]) , is 37
reached. Within the Mgmt_Rtg_Rsp command, the RoutingTableEntries field 38
shall represent the total number of Routing Table entries in the Remote Device. 39
The RoutingTableListCount field shall be the number of entries reported in the 40
RoutingTableList field of the Mgmt_Rtg_req command. 41
42
43
44
45

1
The local device is notified of the results of its attempt to obtain the routing table. 2
2.4.4.3.4 Mgmt_Bind_rsp 3
4
The Mgmt_Bind_rsp command (ClusterID=0x8033) shall be formatted as 5
7
Status BindingTable Start BindingTable BindingTable 9
11
Figure 2.89 Format of the Mgmt_Bind_rsp Command Frame 12
13
Table 2.121 specifies the fields of the Mgmt_Bind_rsp command frame. 14
Table 2.121 Fields of the Mgmt_Bind_rsp Command 15
16
any status code returned Mgmt_Bind_req command. 19
from the APSME- 20
GET.confirm primitive 21
BindingTableEntries Integer 0x00-0xff Total number of Binding Table 22
entries within the Remote 23
Device. 24
StartIndex Integer 0x00-0xff Starting index within the 25
Binding Table to begin 26
reporting for the 27
BindingTableList.
28
BindingTableListCou Integer 0x00-0xff Number of Binding Table 29
nt entries included within 30
BindingTableList.
31
BindingTableList List of The list shall contain the A list of descriptors, beginning 32
Binding number elements given with the StartIndex element 33
Descriptors by the and continuing for
34
BindingTableListCount BindingTableListCount, of the
elements in the Remote 35
Device's Binding Table (see 36
Table 2.122 for details). 37
38
39
40
41
42
43
44
45
Chapter 2
1
Table 2.122 BindingTableList Record Format
2
Size 3
5
SrcAddr 64 A valid 64-bit IEEE The source IEEE address for the
address binding entry. 6
7
SrcEndpoint 8 0x01 - 0xff The source endpoint for the binding 8
entry.
9
ClusterId 16a 0x0000 - 0xffff The identifier of the cluster on the 10
source device that is bound to the 11
destination device.
12
DstAddrMode 8 0x00 - 0xff The addressing mode for the 13
destination address. This field can 14
take one of the non-reserved values
from the following list:
15
16
0x00 = reserved 17
DstAddr and DstEndpoint not 19
present
20
0x02 = reserved
21
DstAddr and DstEndp present
23
0x04 – 0xff = reserved
24
DstAddr 16/64 As specified by the The destination address for the 25
DstAddrMode field binding entry. 26
DstEndpoint 0/8 0x01 - 0xff This field shall be present only if 27
the DstAddrMode field has a value 28
of 0x03 and, if present, shall be the 29
destination endpoint for the binding
30
entry.
31
a. CCB #603 32
33
35
The Mgmt_Bind_rsp is generated in response to a Mgmt_Bind_req. If this 36
returned and all parameter fields after the Status field shall be omitted. Otherwise, 38
the Remote Device shall implement the following processing. 39
Upon receipt of and after support for the Mgmt_Bind_req has been verified, the 40
Remote Device shall perform an APSME-GET.request (for the apsBindingTable 41
attribute) and process the resulting APSME-GET.confirm (containing the 42
apsBindingTable attribute) to create the Mgmt_Bind_rsp command. The 43
44
45
Mgmt_Bind_rsp command shall contain the same status that was contained in the
APSME-GET.confirm primitive and if this was not SUCCESS, all parameter 1
fields after the status field shall be omitted. 2
3
From the apsBindingTable attribute, the binding table shall be accessed, starting 4
with the index specified by StartIndex, and moved to the BindingTableList field of 5
the Mgmt_Bind_rsp command. The entries reported from the binding table shall 6
be those, starting with StartIndex and including whole BindingTableList records 7
(see Table 2.122) until the MSDU size limit, i.e. aMaxMACFrameSize (see [B1]), 8
is reached. Within the Mgmt_Bind_Rsp command, the BindingTableEntries field 9
shall represent the total number of Binding Table entries in the Remote Device. 10
The BindingTableListCount field shall be the number of entries reported in the 11
BindingTableList field of the Mgmt_Bind_req command. 12
13
The local device is notified of the results of its attempt to obtain the binding table. 15
16
2.4.4.3.5 Mgmt_Leave_rsp 17
18
The Mgmt_Leave_rsp command (ClusterID=0x8034) shall be formatted as
19
20
Octets: 1 21
22
Status 23
24
Figure 2.90 Format of the Mgmt_Leave_rsp Command Frame
25
26
Table 2.123 specifies the fields of the Mgmt_Leave_rsp command frame.
27
Table 2.123 Fields of the Mgmt_Leave_rsp Command 28
29
30
any status code returned Mgmt_Leave_req 32
from the NLME- command.
33
LEAVE.confirm primitive
34
35
The Mgmt_Leave_rsp is generated in response to a Mgmt_Leave_req. If this 37
returned. Otherwise, the Remote Device shall implement the following 39
processing. 40
41
Upon receipt of and after support for the Mgmt_Leave_req has been verified, the 42
Remote Device shall execute the NLME-LEAVE.request to disassociate from the 43
44
45
Chapter 2
currently associated network. The Mgmt_Leave_rsp shall contain the same status
that was contained in the NLME-LEAVE.confirm primitive. 1
2
Once a device has disassociated, it may13 execute pre-programmed logic to 3
perform NLME-NETWORK-DISCOVERY and NLME-JOIN to join/re-join a 4
network. 5
6
The local device is notified of the results of its attempt to cause a remote device to 8
leave the network. 9
10
2.4.4.3.6 Mgmt_Direct_Join_rsp 11
12
The Mgmt_Direct_Join_rsp (ClusterID=0x8035) shall be formatted as illustrated
13
in Figure 2.91.
14
Octets: 1 15
16
Status 17
18
Figure 2.91 Format of the Mgmt_Direct_Join_rsp Command Frame
19
20
Table 2.124 specifies the fields of the Mgmt_Direct_Join_rsp command frame.
21
Table 2.124 Fields of the Mgmt_Direct_Join_rsp Command 22
23
24
Status Integer NOT_SUPPORTED or any The status of the 25
status code returned from the Mgmt_Direct_Join_req 26
NLME-DIRECT-JOIN.confirm command.
27
primitive
28
29
The Mgmt_Direct_Join_rsp is generated in response to a Mgmt_Direct_Join_req. 31
If this management command is not supported, a status of NOT_SUPPORTED 32
shall be returned. Otherwise, the Remote Device shall implement the following 33
processing. 34
35
Upon receipt of and after support for the Mgmt_Direct_Join_req has been 36
verified, the Remote Device shall execute the NLME-DIRECT-JOIN.request to 37
directly associate the DeviceAddress contained in the Mgmt_Direct_Join_req to 38
the network. The Mgmt_Direct_Join_rsp shall contain the same status that was 39
contained in the NLME-DIRECT-JOIN.confirm primitive. 40
41
42
43
13. CCB #553 44
45

1
Upon receipt and after support for the Mgmt_Direct_Join_req has been verified, 2
the Remote Device shall execute the NLME-DIRECT-JOIN.request to directly 3
associate the DeviceAddress contained in the Mgmt_Direct_Join_req to the 4
network. 5
2.4.4.3.7 Mgmt_Permit_Joining_rsp 6
7
The Mgmt_Permit_Joining_rsp command (ClusterID=0x8036) shall be formatted 8
10
Octets: 1 11
Status 12
13
Figure 2.92 Format of the Mgmt_Permit_Joining_rsp Command Frame 14
15
Table 2.125 specifies the fields of the Mgmt_Permit_Joining_rsp command frame 16
. 17
Table 2.125 Fields of the Mgmt_Permit_Joining_rsp Command 18
19
INVALID_REQUEST Mgmt_Permit_Joining_rsp 22
or any status code command 23
returned from the 24
NLME-PERMIT- 25
JOINING.confirm
primitive 26
27
28
The Mgmt_Permit_Joining_rsp is generated in response to a unicast 30
Mgmt_Permit_Joining_req. In the description which follows, note that no 31
response shall be sent if the Mgmt_Permit_Joining_req was received as a 32
broadcast to all routers. If this management command is not permitted by the 33
requesting device, a status of INVALID_REQUEST shall be returned. Upon 34
receipt and after support for Mgmt_Permit_Joining_req has been verified, the 35
Remote Device shall execute the NLME-PERMIT-JOINING.request. The 36
Mgmt_Permit-Joining_rsp shall contain the same status that was contained in the 37
NLME-PERMIT-JOINING.confirm primitive. 38
39
41
The status of the Mgmt_Permit_Joining_req command is notified to the requestor. 42
43
44
45
Chapter 2
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.93 3
4
Octets: 1 1 1 1 Variable
5
Status DiscoveryCacheEntr StartIndex DiscoveryCacheList DiscoveryCacheList 6
ies Count 7
8
Figure 2.93 Format of the Mgmt_Cache_rsp Command Frame 9
10
Table 2.126 specifies the fields of the Mgmt_Cache_rsp command frame. 11
Table 2.126 Fields of the Mgmt_Cache_rsp Command 12
13
Status Integer SUCCESS or The status of the 15
NOT_SUPPORTED Mgmt_Cache_rsp command 16
DiscoveryCacheEntri Integer 0x00 - 0xff DiscoveryCacheEntries 17
es 18
19
StartIndex Integer 0x00 - 0xff StartIndex
20
DiscoveryCacheListC Integer 0x00 - 0xff The list shall contain the number 21
ount of elements given by the 22
DiscoveryCacheListCount
parameter 23
24
DiscoveryCacheList Integer List of DiscoveryCache A list of descriptors, one for each 25
descriptors of the Discovery cache devices
registered, beginning with the 26
StartIndex element and continuing 27
for DiscoveryCacheListCount, of 28
the registered devices in the 29
Primary Discovery Cache. Each 30
entry shall be formatted as
illustrated in sub-clause . 31
32
33
34
Table 2.127 DiscoveryCacheList Record Format 35
36
Size
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

1
The Mgmt_Cache_rsp is generated in response to an Mgmt_Cache_req. If this 2
management command is not Supported or the Remote Device is not a Primary 3
Cache Device, a status of NOT_SUPPORTED shall be returned and all parameter 4
fields after the Status field shall be omitted. Otherwise, the Remote Device shall 5
implement the following processing. Upon receipt of the Mgmt_Cache_req and 6
after support for the Mgmt_Cache_req has been verified, the Remote Device shall 7
access an internally maintained list of registered ZigBee End Devices utilizing the 8
discovery cache on this Primary Discovery Cache device. The entries reported 9
shall be those, starting with StartIndex and including whole DiscoveryCacheList 10
records (see Table 2.129) until the limit on MSDU size, i.e. aMaxMACFrameSize 11
(see [B1]), is reached. Within the Mgmt_Cache_rsp command, the 12
DiscoveryCacheListEntries field shall represent the total number of registered 13
entries in the Remote Device. The parameter DiscoveryCacheListCount shall be 14
the number of entries reported in the DiscoveryCacheList field of the 15
Mgmt_Cache_rsp command. 16
17
19
The local device is notified of the results of its attempt to obtain the discovery
20
cache list.
21
22
2.4.5 ZDP Enumeration Description 23
24
This subclause explains the meaning of the enumerations used in the ZDP. Table 25
shows a description of the ZDP enumeration values. 26
27
I
28
Table 2.128 ZDP Enumerations Description 29
Enumeration Value Description 30
31
SUCCESS 0x00 The requested operation or transmission 32
was completed successfully. 33
- 0x01-0x7f Reserved 34
35
INV_REQUESTTYPE 0x80 The supplied request type was invalid.
36
DEVICE_NOT_FOUND 0x81 The requested device did not exist on a 37
device following a child descriptor 38
request to a parent.
39
INVALID_EP 0x82 The supplied endpoint was equal to 0x00 40
or between 0xf1 and 0xff. 41
NOT_ACTIVE 0x83 The requested endpoint is not described 42
by a simple descriptor. 43
44
45
Chapter 2
Table 2.128 ZDP Enumerations Description (Continued)

1
NOT_SUPPORTED 0x84 The requested optional feature is not 3
supported on the target device. 4
5
TIMEOUT 0x85 A timeout has occurred with the
requested operation. 6
7
NO_MATCH 0x86 The end device bind request was
8
unsuccessful due to a failure to match
any suitable clusters. 9
10
- 0x87 Reserved 11
NO_ENTRY 0x88 The unbind request was unsuccessful due 12
to the coordinator or source device not 13
having an entry in its binding table to 14
unbind.
15
NO_DESCRIPTOR 0x89 A child descriptor was not available 16
following a discovery request to a parent. 17
INSUFFICIENT_SPACE 0x8a The device does not have storage space 18
to support the requested operation 19
NOT_PERMITTED 0x8b The device is not in the proper state to 20
support the requested operation 21
22
TABLE_FULL 0x8c The device does not have table space to
support the operation 23
24
0x8d-0xff Reserved 25
26
2.4.6 Conformance 27
28
When conformance to this Profile is claimed, all capabilities indicated mandatory 29
for this Profile shall be supported in the specified manner (process mandatory). 30
This also applies to optional and conditional capabilities, for which support is 31
indicated, and subject to verification as part of the ZigBee certification program. 32
33
34
2.5 The ZigBee Device Objects (ZDO) 35
36
37
2.5.1 Scope 38
39
This section describes the concepts, structures and primitives needed to 40
implement a ZigBee Device Objects application on top of a ZigBee Application 41
Support Sub-layer (Reference [B1]) and ZigBee Network Layer (Chapter 3). 42
43
44
45
ZigBee Device Objects is an application which employs network and application

support layer primitives to implement ZigBee End Devices, ZigBee Routers and 1
ZigBee Coordinators . 2
3
The ZigBee Device Object Profile employs Clusters to describe its primitives. 4
The ZigBee Device Profile Clusters do not employ attributes and are analogous to 5
messages in a message transfer protocol. Cluster identifiers are employed within 6
the ZigBee Device Profile to enumerate the messages employed within ZigBee 7
Device Objects. 8
ZigBee Device Objects also employ configuration attributes. These attributes are 9
not the elements of any cluster. The configuration attributes within ZigBee Device 10
Objects are configuration parameters set by the application or stack profile. The 11
configuration attributes are also not related to the ZigBee Device Profile, though 12
both the configuration attributes and the ZigBee Device Profile are employed with 13
ZigBee Device Objects. 14
15
16
2.5.2 Device Object Descriptions 17
18
• The ZigBee Device Objects are an application solution residing within the 19
Application Layer (APL) and above the Application Support Sub-layer (APS) 20
in the ZigBee stack architecture as illustrated in Figure 1.1. 21
The ZigBee Device Objects are responsible for the following functions: 22
23
• Initializing the Application Support Sublayer (APS), Network Layer (NWK), 24
Security Service Provider (SSP) and any other ZigBee device layer other than 25
the end applications residing over Endpoints 1-240. 26
• Assembling configuration information from the end applications to determine 27
and implement the functions described in the following subclauses. 28
29
2.5.2.1 Primary Discovery Cache Device Operation 30
31
The Primary Discovery Cache device is designated through configuration of the 32
device and advertisement in the Node Descriptor. The Primary Discovery Cache 33
device operates as a state machine with respect to clients wishing to utilize the 34
services of the Primary Discovery Cache. The following states and operations, as 35
described in Figure 2.94, shall be supported by the Primary Discovery Cache 36
device: 37
• Undiscovered: 38
39
• The client employs the radius limited broadcast to all RxOnWhenIdle 40
devices message Discovery Register request to locate a Primary Discovery 41
Cache device within the radius supplied by the request 42
• Discovered: 43
44
45
Chapter 2
• The client employs the unicast Discovery cache request directed to the
Discovery Cache device containing the sizes of the discovery cache 1
information it wishes to store. The Discovery Cache Device will respond 2
with a SUCCESS or TABLE_FULL. 3
4
• Registered: 5
• This state is reached when a SUCCESS status was received by the client 6
from the Discovery Cache device from a previous Discovery cache request. 7
The client must now upload its discovery information using the Node 8
Descriptor store request, Power Descriptor store request, Active Endpoint 9
store request and Simple Descriptor store requests to enable the Primary 10
Discovery Cache device to fully respond on its behalf. 11
12
• Unregistered: 13
• The client (or any other device) may request to be unregistered. The Remove 14
Node Cache request removes the device from the Primary Discovery Cache 15
device. 16
17
The Primary Cache Device responds to device and service discovery requests for 18
all registered clients it supports. The Find Node Cache request is employed by 19
clients wanting to locate the device and service discovery location for a given 20
device of interest. Note that if the discovery information is held by the device 21
itself, that device must also respond to identify itself as the repository of discovery 22
information. See Figure 2.94 for details on state machine processing for the 23
Primary Discovery Cache device. 24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Discovery_cache_req 1
2
Discovery_cache_rsp 3
Until (STATUS)
STATUS is
4
SUCCESS Discovery_store_req 5
6
Discovery_store_rsp (STATUS) 7
8
Node_Desc_store_req 9
If STATUS is not SUCCESS for 10
any descriptor storage request, Node_Desc_store_rsp (STATUS) 11
then Remove_node_cache_req 12
Repeat for:
Power_Desc_store_req, 13
Active_EP_store_req,
Simple Desc_store_req
14
15
16
17
End Device Sleeps and 18
Primary Discovery Cache
handles any discovery 19
requests for the device 20
End Device (client) Primary Discovery Cache 21
(server)
22
Figure 2.94 Primary Discovery Cache State Machine 23
24
2.5.2.2 Device and Service Discovery 25
26
This function shall support device and service discovery within a single PAN. 27
Additionally, for ZigBee Coordinator, ZigBee Router and ZigBee End Device 28
types, this function shall perform the following: 29
30
• Within each network employing sleeping ZigBee End Devices, some ZigBee
31
Routers (or the ZigBee Coordinator) must be designated as Primary Discovery
32
Cache Devices as described by their Node Descriptor. These Primary Cache
33
Devices are themselves discoverable and provide server services to upload and
34
store discovery information on behalf of sleeping ZigBee End Devices.
35
Additionally, the Primary Cache Devices respond to discovery requests on
36
behalf of the sleeping ZigBee End Devices. Each Primary Discovery Cache
37
Device shall be either a ZigBee Router or the ZigBee Coordinator.
38
• For ZigBee End Devices which intend to sleep as indicated by 39
:Config_Node_Power, Device and Service Discovery shall manage upload and 40
storage of the NWK Address, IEEE Address, Active Endpoints, Simple 41
Descriptors, Node Descriptor and Power Descriptor onto a Primary Discovery 42
Cache device selected by the ZigBee End Device to permit device and service 43
discovery operations on these sleeping devices. 44
45
Chapter 2
• For the ZigBee Coordinator and ZigBee Routers designated as Primary

Discovery Cache Devices, this function shall respond to discovery requests on 1
behalf of sleeping ZigBee End Devices who have registered and uploaded their 2
discovery information. 3
4
• For all ZigBee devices, Device and Service Discovery shall support device and 5
service discovery requests from other devices and permit generation of requests 6
from their local Application Objects. Note that Device and Service Discovery 7
services may be provided by the Primary Discovery Cache devices on behalf of 8
other ZigBee End Devices. In cases where the Primary Discovery Cache 9
Device is the target of the request, the NWKAddrOfInterest or Device of 10
Interest fields shall be filled in the request and/or response to differentiate the 11
target of the request from the device that is the target of discovery. The 12
following discovery features shall be supported: 13
• Device Discovery: 14
15
—Based on a unicast inquiry of a ZigBee Coordinator or ZigBee Router’s 16
IEEE address, the IEEE Address of the requested device plus, option- 17
ally, the NWK Addresses of all associated devices shall be returned. 18
19
—Based on a unicast inquiry of a ZigBee End Device’s IEEE address, the
20
IEEE Address of the requested device shall be returned. 21
—Based on a broadcast inquiry (of any broadcast address type) of a Zig- 22
Bee Coordinator or ZigBee Router’s NWK Address with a supplied 23
IEEE Address, the NWK Address of the requested device plus, option- 24
ally, the NWK Addresses of all associated devices shall be returned. 25
26
—Based on a broadcast inquiry (of any broadcast address type) of a Zig- 27
Bee End Device’s NWK Address with a supplied IEEE Address, the 28
NWK Address of the requested device shall be returned. The responding 29
device shall employ APS acknowledged service for the unicast response 30
to the broadcast inquiry. 31
32
• Service Discovery: Based on the following inputs, the corresponding 33
responses shall be supplied: 34
—NWK address plus Active Endpoint query type – Specified device shall 35
36
return the endpoint number of all applications residing in that device.
37
—NWK address or broadcast address (of any broadcast address type) plus 38
Service Match including Profile ID and, optionally, Input and Output 39
Clusters – Specified device matches Profile ID with all active endpoints 40
to determine a match. If no input or output clusters are specified, the 41
endpoints that match the request are returned. If input and/or output 42
43
clusters are provided in the request, those are matched as well and any
44
45
matches are provided in the response with the list of endpoints on the
device providing the match. The responding device shall employ APS 1
acknowledged service for the unicast response to the broadcast inquiry. 2
3
In cases where the application profiles wish to enumerate input clusters
4
and their resulting response output clusters with the same cluster identi- 5
fier, the application profile shall list only the input cluster within the 6
Simple Descriptor for the purposes of Service Discovery. It shall be 7
assumed, in these cases, that the application profile provides details 8
about the use of the cluster identifier for both inputs and response out- 9
put. 10
11
—NWK address plus Node Descriptor or Power Descriptor query type – 12
Specified device shall return the Node or Power Descriptor for the 13
device. 14
—NWK address, Endpoint Number plus Simple Descriptor query type – 15
Specified address shall return the Simple Descriptor associated with that 16
17
Endpoint for the device.
18
—Optionally, NWK address plus Complex or User Descriptor query type 19
– If supported, specified address shall return the Complex or User 20
Descriptor for the device 21
22
2.5.2.3 Security Manager 23
24
This function determines whether security is enabled or disabled and, if enabled, 25
shall perform the following: 26
• Establish Key 27
28
• Transport Key 29
• Request Key 30
31
• Update Device 32
• Remove Device 33
34
• Switch Key 35
The Security Manager function addresses the Security Services Specification 36
(Chapter 4). Security Management, implemented by APSME primitive calls by 37
ZDO, performs the following: 38
39
• Contacts the Trust Center (assumed to be located on the ZigBee Coordinator) 40
to obtain the Master Key between this device and the Trust Center (step is 41
omitted if this device is the ZigBee Coordinator or the Master Key with the 42
Trust Center has been pre-configured). This step employs the Transport Key 43
primitive. 44
45
Chapter 2
• Establishes a Link Key with the Trust Center. This step employs the APSME-
Establish-Key primitive. 1
2
• Obtains the NWK Key from the Trust Center using secured communication 3
with the Trust Center. This step employs the APSME-TRANSPORT-KEY 4
primitive. 5
• Establishes Link Keys and master keys, as required, with specific devices in the 6
network identified as messaging destinations. These steps employ the APSME- 7
ESTABLISH-KEY and/or APSME-REQUEST-KEY primitives. 8
9
• Informs the trust center of any devices that join the network using the APSME- 10
DEVICE-UPDATE primitives. This function is only performed if the device is 11
a ZigBee router. 12
• Permits devices to obtain keys from the Trust Center using the APSME- 13
REQUEST-KEY primitives. 14
15
• Permits the Trust Center to remove devices from the network using the 16
APSME-REMOVE-DEVICE primitives. 17
• Permits the Trust Center to switch the active network key using the APSME- 18
SWITCH-KEY primitives. 19
20
2.5.2.4 Network Manager 21
22
This function shall implement the ZigBee Coordinator, ZigBee Router or ZigBee 23
End Device logical device types according to configuration settings established 24
either via a programmed application or during installation. If the device type is a 25
ZigBee Router or ZigBee End Device, this function shall provide the ability to 26
select an existing PAN to join and implement procedures which permit the device 27
to rejoin if network communication is lost. If the device type is a ZigBee 28
Coordinator or ZigBee Router, this function shall provide the ability to select an 29
unused channel for creation of a new PAN. Note that it is possible to deploy a 30
network without a device pre-designated as ZigBee Coordinator where the first 31
Full Function Device (FFD) activated assumes the role of ZigBee Coordinator. 32
The following description covers processing addressed by Network Management: 33
• Permits specification of a channel list for network scan procedures. Default is 34
to specify use of all channels in the selected band of operation. 35
36
• Manages network scan procedures to determine neighboring networks and the 37
identity of their ZigBee coordinators and routers. 38
• Permits selection of a channel to start a PAN (ZigBee Coordinator) or selection 39
of an existing PAN to join (ZigBee Router or ZigBee End Device). 40
41
• Supports orphaning and extended procedures to rejoin the network, including 42
support for intra_PAN portability. 43
44
45
• May support direct join and join by proxy features provided by the Network
Layer. For ZigBee Coordinators and ZigBee Routers, a local version of direct 1
join may be supported to enable the device to join via the orphaning or rejoin 2
procedures. 3
4
• May support Management Entities that permit external network management. 5
6
2.5.2.5 Binding Manager 7
The Binding Manager performs the following: 8
9
• Establishes resource size for the Binding Table. The size of this resource is 10
determined via a programmed application or via a configuration parameter 11
defined during installation. 12
• Processes bind requests for adding or deleting entries from the APS binding 13
table. 14
15
• Supports Bind and Unbind commands from external applications such as those 16
that may be hosted on a PDA to support assisted binding. Bind and Unbind 17
commands shall be supported via the ZigBee Device Profile (see clause 2.4). 18
• For the ZigBee Coordinator, supports the End Device Bind that permits binding 19
on the basis of button presses or other manual means. 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
• Permits source devices to register with a primary binding table cache their 36
ability to hold their own binding table 37
• Permits configuration tools to exchange one device for another in all of the 38
binding table entries which refer to it 39
40
• Permits the primary binding table cache to backup and recover individual bind 41
entries or the entire binding table or the table of source devices holding their 42
own binding tables 43
44
45
Chapter 2
• Provides a remote management command to Permit or disallow joining on

particular routers or to generally allow or disallow joining via the Trust center. 1
2
3
2.5.3 Layer Interface Description 4
5
Unlike other device descriptors for applications residing above Endpoints 1-240, 6
the ZigBee Device Objects (ZDO) interface to the APS via the APSME-SAP and 7
to NWK via the NLME-SAP in addition to the APSDE-SAP. ZDO communicates 8
over Endpoint 0 using the APSDE-SAP via Profiles like all other applications. 9
The Profile used by ZDO is the ZigBee Device Profile (See clause 2.4). 10
Due to the omission of a Simple Descriptor for the Device Profile and due to the 11
role of the Device Profile in discovery itself, the use of binding and indirect 12
messaging on endpoint 0 is prohibited. 13
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
2.5.4 System Usage 1

2
The header will be on the same page as the diagram with the release version of the
3
specification.
4
5
1 Device and Service Device and Service 6
2 Discovery Object Discovery Object
3
Mandatory Mandatory 7
4
5
Mandatory Attributes Optional Attributes 8
(continued)
6
7
NWK_addr_rsp 9
10
8 IEEE_addr_rsp Discovery_cache_req
9 Node_Desc_rsp Discovery_cache_rsp
10
11
Active_EP_rsp Discovery_store_req 11
12
13
Match_Desc_rsp
Power_Desc_rsp
Discovery_store_rsp
12
Node_desc_store_req
14
15 Simple_Desc_rsp Node_desc_store_rsp 13
14
16 Power_desc_store_req
17 Optional Attributes
18 Power_desc_store_rsp
19
NWK_addr_req Active_EP_store_req 15
20
21 IEEE_addr_req Active_EP_store_rsp
16
22 Simple_desc_store_req
23
24
Node_Desc_req
Power_Desc_req Simple_desc_store_rsp 17
25
26
Simple_Desc_req Remove_node_cache_req 18
Remove_node_cache_rsp
27
28
Active_EP_req
Match_Desc_req Find_node_cache_req 19
29
30
Complex_Desc_req Find_node_cache_rsp 20
System_Server_
31
32
Complex_Desc_rsp
User_Desc_req
Discovery req 21
33
34 User_Desc_rsp
System_Server_
Discovery_rsp 22
35
36
End_Device_annce
User_Desc_set
23
37
38 User_Desc_conf 24
39
40 25
41
42 26
43
44
45
27
46
47
28
48
49
29
50
51
30
52
53
31
54
32
33
Figure 2.95 System Usage ZigBee Device Object Details
34
35
36
37
38
39
40
41
42
43
44
45
Chapter 2
55
56
1
57
58
59
Binding Manager Object
Optional
Network Manager Object
Mandatory 2
3
60
61 Mandatory Attributes Mandatory Attributes
62
4
63
64 NLME-NETWORK-
65 DISCOVERY.request
Optional Attributes
66
5
NLME-NETWORK-
67 DISCOVERY.confirm
End_Device_Bind_req
68
69 End_Device_Bind_rsp NLME-GET.request
70
71
72 Bind_rsp
Bind_req NLME-GET.confirm
NLME-SET.request 6
7
73 Unbind_req NLME-SET.confirm
74
Unbind_rsp
75
Optional Attributes
8
76 Bind_Register_req
77 Bind_Register_rsp NLME-NETWORK-
78 FORMATION.request
Replace_Device_req
9
79
80 NLME-NETWORK-
Replace_Device_rsp FORMATION.confirm
81
82 Store_Bkup_ NLME-DIRECT-
10
83 Bind Entry req JOIN.request
Store_Bkup_
112
84 NLME-DIRECT- 113
85 Bind Entry rsp JOIN.confirm Configuration Attributes
11
86 Backup_Bind_ 114
NLME-JOIN.request
87 Table req 115 Mandatory
88 NLME-JOIN.confirm
Backup_Bind_ 116
12
89 Table rsp NLME-JOIN.indication
90
117 :Config_Node_Descriptor
91 Recover_Bind_ 118
NLME-START-
ROUTER.request
119 :Config_Power_Descriptor
13
92 Table req
93 Recover_Bind_ NLME-START- 120
ROUTER.confirm
:Config_Simple_Descriptors
94 Table rsp 121 :Config_NWK_Mode_and_Params
95
14
Backup_Source_Bind_req NLME-LEAVE.request
96 122
NLME-LEAVE.confirm :Config_NWK_Scan_Attempts
97 Backup_Source_Bind_rsp 123
98 NLME-LEAVE.indication
124 :Config_NWK_Time_btwn_Scans
99
100
101
Recover_Source_Bind_req
Recover_Source_Bind_rsp
NLME-SYNC.request
125
126
NLME-SYNC.indication
15
Optional
16
102 127
NLME-PERMIT-
103 128
JOINING.request
104 NLME-PERMIT-129 :Config_Complex_Descriptor
17
105 JOINING.confirm
106
130 :Config_User_Descriptor
NLME-RESET.request
107 131
NLME-RESET.confirm :Config_Max_Bind
132
18
108
109 133 :Config_Master_Key
110
134 :Config_NWK_Join_Direct_Addrs
135
136
137
:Config_Max_Assoc 19
:Config_EndDev_Bind_Timeout
:Config_Permit_Join_Duration 20
21
111 :Config_Nwk_Security_Level
Node Manager Object :Config_Nwk_Secure_All_Frames
Security Manager Object
Optional
Mandatory Attributes
Optional
:Config_NWK_Leave_removeChildren
:Config_NWK_BroadcastDeliveryTime 22
23
Mandatory Attributes :Config_NWK_TransactionPersistenceTim
:Config_NWK_indirectPollRate
:Config_NWK_Alt_protocol_version
24
Optional Attributes 25
APSME-ESTABLISH-
KEY.request
APSME-ESTABLISH-
26
Optional Attributes
KEY.indication
APSME-ESTABLISH-
KEY.response
27
Mgmt_NWK_Disc_req
Mgmt_NWK_Disc_rsp
APSME-ESTABLISH-
KEY.confirm 28
Mgmt_Lqi_req
Mgmt_Lqi_rsp
APSME-TRANSPORT-
KEY.request
APSME-TRANSPORT-
29
30
Mgmt_Rtg_req KEY.indication
Mgmt_Rtg_rsp APSME-UPDATE-
DEVICE.request
31
Mgmt_Bind_req
APSME-UPDATE-
Mgmt_Bind_rsp
DEVICE.indication
Mgmt_Leave_req
32
APSME-REMOVE-
Mgmt_Leave_rsp DEVICE.request
Mgmt_Direct_Join_req APSME-REMOVE-
Mgmt_Direct_Join_rsp
Mgmt_Cache_req
DEVICE.indication
APSME-REQUEST-
KEY.request
33
Mgmt_Cache_rsp APSME-REQUEST-
KEY.indication 34
35
APSME-SWITCH-
KEY.request
APSME-SWITCH-
36
KEY.indication
37
38
39
40
41
42
43
44
45
2.5.5 Object Definition and Behavior 1

2
2.5.5.1 Object Overview 3
ZigBee Device Objects contains five Objects: 4
5
• Device and Service Discovery 6
• Network Manager 7
8
• Binding Manager 9
• Security Manager 10
11
• Node Manager 12
Table 2.129 describes these ZigBee Device Objects. 13
14
Table 2.129 ZigBee Device Objects
15
Object Description 16
17
Name Status 18
:Device_and_Service M Handles device and service discovery. 19
_Discovery 20
21
:Network_Manager M Handles network activities such as network
discovery, leaving/joining a network, 22
resetting a network connection and creating 23
a network. 24
:Binding_Manager O Handles end device binding, binding and 25
unbinding activities. 26
27
:Security_Manager O Handles security services such as key
loading, key establishment, key transport
28
and authentication. 29
30
:Node_Manager O Handles management functions.
31
32
2.5.5.2 Optional and Mandatory Objects and Attributes 33
34
Objects listed as Mandatory shall be present on all ZigBee devices. However, for 35
certain ZigBee logical types, Objects listed as Optional for all ZigBee devices 36
may be Mandatory in specific logical device types. For example, the NLME- 37
NETWORK-FORMATION.request within the Network_Manager object is in a 38
Mandatory object and is an Optional attribute, though the attribute is required for 39
ZigBee Coordinator logical device types. The introduction section of each Device 40
Object section will detail the support requirements for Objects and Attributes by 41
logical device type. 42
43
44
45
Chapter 2
2.5.5.3 Security Key Usage

1
ZigBee Device Objects may employ security for packets created by ZigBee 2
Device Profile primitives. These application packets using APSDE on Endpoint 0 3
shall utilize the Network Key, as opposed to individual Link Keys. 4
5
2.5.5.4 Public and Private Methods 6
7
Methods that are accessible to any endpoint application on the device are called 8
public methods. Private methods are only accessible to the Device Application on 9
endpoint 0 and not to the end applications (which run on endpoints 1 through 10
240). 11
12
2.5.5.5 State Machine Functional Descriptions 13
2.5.5.5.1 ZigBee Coordinator 14
15
2.5.5.5.1.1 Initialization 16
17
Provision shall be made within the implementation to supply a single copy of desired 18
network configuration parameters (:Config_NWK_Mode_and_Params) to the 19
Network Object of ZigBee Device Objects. Additionally, provision shall be made to 20
provide configuration elements to describe the Node Descriptor, Power Descriptor, 21
Simple Descriptor for each active endpoint and application plus the list of active 22
endpoints. These configuration shall be embodied in :Config_Node_Descriptor, 23
:Config_Power_Descriptor and :Config_Simple_Descriptors. If the 24
:Config_Node_Descriptor configuration object indicates that this device is a Primary 25
Discovery Cache device, the device shall be configured to process server commands 26
for the ZigBee Device Profile associated with requests to the Primary Discovery 27
Cache and shall operate according to the state machine description provided in sub- 28
clause 2.5.2.1. 29
If supported, provision shall be made to supply configuration elements for the 30
Complex Descriptor, User Descriptor, the maximum number of bind entries and 31
the master key. These elements shall be embodied in 32
:Config_Complex_Descriptor, :Config_User_Descriptor, :Config_Max_Bind and 33
:Config_Master_Key. 34
35
The device application shall use NLME-NETWORK-DISCOVERY.request with 36
the ChannelList portion of :Config_NWK_Mode_and_Params to scan the specified 37
channels. The resulting NLME-NETWORK-DISCOVERY.confirm shall supply a 38
NetworkList detailing active PANs within that range. The device application shall 39
compare the ChannelList to the NetworkList and select an unused channel. 40
Specification of the algorithm for selection of the unused channel shall be left to the 41
implementer. Once the unused channel is identified, the device application shall set 42
the nwkSecurityLevel and nwkSecureAllFrames NIB attributes according to the 43
values established by convention within the Stack Profile employed by the device. It 44
45
shall then employ the NLME-NETWORK-FORMATION.request using the

parameters specified within :Config_NWK_Mode_and_Params to establish a PAN 1
on that channel. The Extended PAN ID field shall be set within 2
nwkExtendedPANID. The device application shall check the return status via the 3
NLME-NETWORK-FORMATION.confirm to verify successful creation of the 4
PAN. The :Config_Permit_Join_Duration shall be set according to the default 5
parameter value supplied using the NLME-PERMIT-JOINING.request. 6
Additionally, the nwkNetworkBroadcastDeliveryTime and 7
nwkTransactionPersistenceTime Network Information Block parameters shall be set 8
with :Config_NWK_BroadcastDeliveryTime and 9
:Config_NWK_TransactionPersistenceTime respectively (see Chapter 3). 10
11
Provision shall be made to ensure APS primitive calls from the end applications 12
over EP 1 through EP 240 return appropriate error status values prior to 13
completion of the Initialization state by ZigBee Device Objects and transition to 14
the normal operating state. 15
16
2.5.5.5.1.2 Normal Operating State 17
In this state, the ZigBee Coordinator shall process the list of direct joined 18
addresses in :Config_NWK_Join_Direct_Addrs by issuing an NLME-DIRECT- 19
JOIN.request for each included address in the list. Processing of the direct joined 20
addresses shall employ the :Config_Max_Assoc parameter in evaluating whether 21
to successfully process a direct joined address within 22
:Config_NWK_Join_Direct_Addrs. 23
24
The ZigBee coordinator shall allow other devices to join the network based on the 25
configuration items :Config_Permit_Join_Duration and :Config_Max_Assoc. 26
When a new device joins the network, the device application shall be informed via 27
the NLME-JOIN.indication. Should the device be admitted to the PAN, the 28
ZigBee coordinator shall indicate this via the NLME-JOIN.confirm with 29
SUCCESS status. 30
The ZigBee coordinator shall respond to any device discovery or service 31
discovery operations requested of its own device, and if it is designated as a 32
Primary Discovery Cache device, shall also respond on behalf of registered 33
devices that have stored discovery information. The device application shall also 34
ensure that the number of binding entries does not exceed the :Config_Max_Bind 35
attribute. 36
37
The ZigBee coordinator shall support the NLME-PERMIT-JOINING.request and 38
NLME-PERMIT-JOINING.confirm to permit application control of network join 39
processing. 40
The ZigBee coordinator shall support the NLME-LEAVE.request and NLME- 41
LEAVE.indication employing the :Config_NWK_Leave_removeChildren 42
43
attribute where appropriate to permit removal of associated devices under applica- 44
45
Chapter 2
tion control. Conditions that lead to removal of associated devices may include
1
lack of security credentials, removal of the device via a privileged application or 2
detection of exception. When a ZigBee end device is asked to leave the network, 3
the ReuseAddress parameter of the NLME-LEAVE.request primitive should have 4
5
a value of TRUE indicating that the NWK layer may give the address formerly in
6
use by the leaving device to another end device that joins subsequently.14 7
8
The ZigBee coordinator shall maintain a list of currently associated devices and
9
facilitate support of orphan scan and rejoin processing to enable previously
10
associated devices to rejoin the network. The ZigBee coordinator may support the
11
ability for devices to be directly included in the network via the NLME-DIRECT-
12
JOIN.request and NLME-DIRECT-JOIN.confirm. This feature shall permit lists
13
of ZigBee IEEE addresses to be provided to the ZigBee coordinator and for those
14
addresses to be included as previously associated devices. It shall be possible for
15
ZigBee devices with those addresses to directly join the network via orphaning or
16
rejoin procedures rather than associating directly.
17
The ZigBee coordinator shall process End_Device_Bind_req from ZigBee 18
Routers and ZigBee End Devices. Upon receipt of an End_Device_Bind_req, the 19
ZigBee Coordinator shall use the :Config_EndDev_Bind_Timeout value in the 20
attribute and await a second End_Device_Bind_req. Should the second indication 21
arrive within the timeout period, the ZigBee coordinator shall match the Profile 22
ID in the two indications. If the Profile IDs in the two indications do not match, an 23
appropriate error status is returned to each device via End_Device_Bind_rsp. 24
Should the Profile IDs match, the ZigBee Coordinator shall match the 25
AppInClusterLists and AppOutClusterLists in the two indications. Cluster IDs in 26
the AppInClusterList of the first indication which match Cluster IDs in the 27
AppOutClusterList of the second indication shall be saved in a list for inclusion in 28
the End_Dev_Bind_rsp. 29
30
The ZigBee coordinator shall process End_Device_annce messages from ZigBee
31
End Devices. Upon receipt of an End_Device_annce, the ZigBee coordinator shall
32
check all internal tables holding 64 bit IEEE addresses for devices within the PAN
33
for a match with the address supplied in the End_Device_annce message. At
34
minimum, the Binding Table and Trust Center tables shall be checked. If a match
35
is detected, the ZigBee coordinator shall update its APS Information Block
36
address map entries corresponding to the matched 64 bit IEEE address to reflect
37
the updated 16 bit NWK address contained in the End_Device_annce.
38
39
40
41
42
43
14. CCB #675 44
45
2.5.5.5.1.3 Trust Center Operation

1
The Zigbee coordinator shall also function as the trust center when security is 2
enabled on the network. 3
The trust center is notified of new devices on the network via the APSME- 4
DEVICE-UPDATE .indication. The trust center can either choose to allow the 5
device to remain on the network or force it out of the network using the APSME- 6
REMOVE-DEVICE.request. This choice is made using a network access control 7
policy that is beyond the scope of this specification. 8
9
If the trust center decides to allow the device to remain in the network, it shall 10
establish a master key with that device using APSME-TRANSPORT- 11
KEY.request, unless the master key is already available to both the device and 12
trust center using out-of-band mechanisms that guarantee secrecy and 13
authenticity. Upon exchange of the master key, the trust center shall use APSME- 14
ESTABLISH-KEY.request to set up a link key with the device and shall respond 15
to request for link key establishment using the APSME-ESTABLISH- 16
KEY.response. 17
The trust center shall then provide the device with the NWK key using APSME- 18
TRANSPORT-KEY.request. It shall also provide the NWK key upon receiving a 19
request from the device via the APSME-REQUEST-KEY.indication. 20
21
The trust center shall support the establishment of link keys between any two 22
devices by providing them with a common key. Upon receipt of a APSME- 23
REQUEST-KEY.indication requesting an application key, the trust center shall 24
create a master key or link key and transport it to both devices using the APSME- 25
TRANSPORT-KEY.request. 26
The trust center shall periodically update the NWK key according to a policy 27
whose details are beyond the scope of this specification. All devices on the 28
network shall be updated with the new NWK key using the APSME- 29
TRANSPORT-KEY.request. 30
31
2.5.5.5.2 ZigBee Router 32
33
35
Provision shall be made within the implementation to supply a single copy of 36
desired network configuration parameters (:Config_NWK_Mode_and_Params) to 37
the Network Object of ZigBee Device Objects. If the :Config_Node_Descriptor 38
configuration object indicates that this device is a Primary Discovery Cache 39
device, the device shall be configured to process server commands for the ZigBee 40
Device Profile associated with requests to the Primary Discovery Cache and shall 41
operate according to the state machine description provided in sub-clause 2.5.2.1. 42
If supported, provision shall be made to supply configuration elements for the 43
Complex Descriptor, User Descriptor, the maximum number of bind entries and 44
45
Chapter 2
the master key. These elements shall be embodied in

:Config_Complex_Descriptor, :Config_User_Descriptor, :Config_Max_Bind and 1
:Config_Master_Key. 2
3
the ChannelList portion of :Config_NWK_Mode_and_Params and then use the 5
NLME-NETWORK-DISCOVERY.request attribute to scan the specified 6
NetworkList detailing active PANs within that range. The NLME-NETWORK- 8
DISCOVERY.request procedure shall be implemented 9
:Config_NWK_Scan_Attempts, each separated in time by 10
:Config_NWK_Time_btwn_Scans. The purpose of repeating the NLME- 11
NETWORK-DISCOVERY.request is to provide a more accurate neighbor list and 12
associated link quality indications to the NWK layer. The device application shall 13
compare the ChannelList to the NetworkList and select an existing PAN to join. 14
Specification of the algorithm for selection of the PAN shall be left to the profile 15
description and may include use of the Extended PAN ID, PAN ID, operational 16
mode of the network, identity of the ZigBee Router or Coordinator identified on 17
the PAN, depth of the ZigBee Router on the PAN from the ZigBee Coordinator for 18
the PAN, capacity of the ZigBee Router or Coordinator, the routing cost or the 19
Protocol Version Number (these parameters are supplied by the NLME- 20
NETWORK-DISCOVERY.confirm and the beacon payload). 21
The ZigBee router may join networks employing the current protocol version 22
number or may join networks employing a previous protocol version number, 23
under application control, if backward compatibility is supported in the device. A 24
single ZigBee PAN shall consist of devices employing only a single protocol 25
version number (networks with devices employing different protocol version 26
numbers and frame formats within the same PAN are not permitted). An optional 27
configuration attribute, :Config_NWK_alt_protocol_version, provides the 28
protocol version numbers which the device may choose to employ other than the 29
current protocol version number. Once the ZigBee router chooses a PAN and a 30
specific protocol version number, it shall modify its 31
:Config_NWK_Mode_and_Params protocol version number field and employ 32
that protocol version number as its nwkcProtocolVersion. Additionally, the 33
ZigBee router shall then adhere to all frame formats and processing rules supplied 34
by the version of the ZigBee Specification employing that protocol version 35
number. 36
37
Once the PAN to join is identified, the device application shall employ the 38
NLME-JOIN.request to join the PAN on that channel. The device application shall 39
check the return status via the NLME-JOIN.confirm to verify association to the 40
selected ZigBee Router or ZigBee Coordinator on that PAN. The Extended PAN 41
ID field from the beacon payload of the PAN shall be set within 42
nwkExtendedPANID. The :Config_Permit_Join_Duration shall be set according to 43
the default parameter value supplied using NLME-PERMIT-JOINING.request. 44
45
The router shall support the NLME-START-ROUTER.request and NLME-

START-ROUTER.confirm to begin operations as a router within the PAN it has 1
joined. Additionally, the nwkNetworkBroadcastDeliveryTime and 2
nwkTransactionPersistenceTime Network Information Block parameters shall be 3
set with :Config_NWK_BroadcastDeliveryTime and 4
:Config_NWK_TransactionPersistenceTime respectively (see Chapter 2). 5
6
If the network has security enabled, the device shall wait for the trust center to 11
supply it with a master key via the APSME-TRANSPORT-KEY.indication and 12
then respond to a request from the trust center to establish a link key using the 13
APSME-ESTABLISH-KEY.request. The device shall then wait for the trust center 14
to provide it with a NWK key using APSME-TRANSPORT-KEY.indication. 15
Upon successful acquisition of the NWK key, the device is authenticated and can 16
start functioning as a router in the network. 17
18
The device application shall set the nwkSecurityLevel and nwkSecureAllFrames 19
NIB attributes to the values used in the network and begin functioning as a router 20
using NLME-START-ROUTER.req. 21
22
2.5.5.5.2.2 Normal Operating State 23
In this state, the ZigBee router shall allow other devices to join the network based 24
on the configuration items :Config_Permit_Join_Duration and 25
:Config_Max_Assoc. When a new device joins the network, the device 26
application shall be informed via the NLME-JOIN.indication attribute. Should the 27
device be admitted to the PAN, the ZigBee router shall indicate this via the 28
NLME-JOIN.confirm with SUCCESS status. If security is enabled on the 29
network, the device application shall inform the trust center via the APSME- 30
UPDATE-DEVICE. request. 31
32
Orphan indications for which this device is not the parent are notified to the ZDO 33
from the NWK layer by receipt of an NLME-JOIN.indication primitive with 34
parameter IsParent set to value FALSE. The mechanism by which this is handled 35
is described in 2.5.5.5.4. 36
The ZigBee router shall respond to any device discovery or service discovery 37
operations requested of its own device, and if it is designated as a Primary 38
Discovery Cache device, shall also respond on behalf of registered devices that 39
have stored discovery information. The device application shall also ensure that 40
the number of binding entries does not exceed the :Config_Max_Bind attribute. 41
42
If security is supported, the ZigBee router shall support the :Config_Master_Key 43
and shall employ the Master Key in key establishment procedures for Link Keys. 44
45
Chapter 2
Upon presentation of a remote destination address requiring secure

communications, the ZigBee router shall support APSME-ESTABLISH- 1
KEY.request to establish a link key with the remote device and APSME- 2
ESTABLISH-KEY.indication to present the request to the destination and shall 3
support APSME-ESTABLISH-KEY.confirm and APSME-ESTABLISH- 4
KEY.response to complete the key establishment of the Link Key. The ZigBee 5
router shall provide the ability to store Link Keys for known destinations 6
requiring secure communications and shall manage key storage of Link Keys. The 7
ZigBee router shall support APSME-TRANSPORT-KEY.indication to receive 8
keys from the trust center. The ZigBee router shall request the trust center to 9
update its NWK key via the APSME-REQUEST-KEY.request. 10
11
The ZigBee router shall support the NLME-PERMIT-JOINING.request and 12
NLME-PERMIT-JOINING.confirm to permit application control of network join 13
processing. 14
The ZigBee router shall support the NLME-LEAVE.request and NLME- 15
LEAVE.confirm employing the :Config_NWK_Leave_removeChildren attribute 16
where appropriate to permit removal of associated devices under application 17
control. Conditions that lead to removal of associated devices may include lack of 18
security credentials, removal of the device via a privileged application or 19
detection of exception. The ZigBee coordinator shall support the NLME- 20
LEAVE.request and NLME-LEAVE.indication employing the 21
:Config_NWK_Leave_removeChildren attribute where appropriate to permit 22
removal of associated devices under application control. Conditions that lead to 23
removal of associated devices may include lack of security credentials, removal of 24
the device via a privileged application or detection of exception. When a ZigBee 25
end device is asked to leave the network, the ReuseAddress parameter of the 26
NLME-LEAVE.request primitive should have a value of TRUE indicating that the 27
NWK layer may give the address formerly in use by the leaving device to another 28
end device that joins subsequently.15 29
30
The ZigBee router shall process End_Device_annce messages from ZigBee End 31
Devices. Upon receipt of an End_Device_annce, the ZigBee router shall check all 32
internal tables holding 64 bit IEEE addresses for devices within the PAN for a 33
match with the address supplied in the End_Device_annce message. At minimum, 34
any Binding Table entries held by the ZigBee router shall be checked. If a match 35
is detected, the ZigBee router shall update its APS Information Block address map 36
entries corresponding to the matched 64 bit IEEE address to reflect the updated 16 37
bit NWK address contained in the End_Device_annce. 38
The ZigBee router shall maintain a list of currently associated devices and 39
facilitate support of orphan scan and rejoin processing to enable previously 40
associated devices to rejoin the network. 41
42
43
15. CCB #675 44
45
2.5.5.5.3 Binding Table Cache Operation

1
Any router (including the coordinator) may be designated as either a primary 2
binding table cache or a backup binding table cache. 3
It shall respond to the System_Server_Discovery_req primitive to enable other 4
devices to discover it and use its facilities. 5
6
A primary binding table cache shall maintain a binding table and a table of 7
devices registered as holding their own source binding tables. If the stack profile 8
specifies it, the primary binding table cache shall provide message reflection 9
using the binding table. If the stack profile specifies that message reflection is not 10
supported, binding entries shall only be kept for devices registered as holding 11
their own source binding tables. 12
A primary binding table cache shall respond to the Bind_Register_req and 13
Replace_Device_req primitives described in clause 2.4.3.2. 14
15
If a backup binding table cache is available, a primary binding table cache shall 16
use the additional bind management primitives to backup and restore its binding 17
table and its table of source binding devices. 18
A backup binding table cache shall maintain a backup of the binding table and 19
table of source binding devices for one or more primary binding table caches. It 20
shall support the bind management primitives for backup and restore of these 21
tables. 22
23
2.5.5.5.4 Operations to Support Intra-PAN Portability 24
25
2.5.5.5.4.1 Overview 26
27
The operations described in this section are carried out by ZigBee Coordinator 28
and ZigBee Router Devices for support of intra-PAN portability. 29
The main steps are summarized as follows:- 30
31
• Detect the problem - The ZDO of the moved device is notified of 32
acknowledgement failures via the NLME-ROUTE-ERROR.indication 33
primitive, and identifies a problem. 34
• Carry out the NWK layer rejoin procedure - The ZDO of a moved ZED 35
initiates this process using the NLME-JOIN.request primitive. This process 36
closely mirrors the MAC association procedure. Note that ZigBee Routers shall 37
also carry out this procedure periodically if they find that they are no longer in 38
contact with the trust center. 39
40
• Security verification - Secured and unsecured protocol steps are described to 41
ensure that the orphaned device should really be accepted. (See 42
clause 2.5.5.5.4.2) 43
44
45
Chapter 2
• Inform the rest of the network - if the short address changed than an
End_Device_annce ZDO command is broadcast to indicate the updated short 1
address. (See clause 2.4.3.1.11) 2
3
These steps are described in detail in the subsections below. The mechanism is 4
illustrated for a ZED and ZR in Figure 2.96 and Figure 2.97, respectively. 5
6
Child’s Child’s
New New
Trust 7
Old parent parent’s parent’s
NWK ZDO
NWK ZDO
Centre 8
9
10
NO_ACK (x12) 11
ROUTE-ERROR. 12
indication 13
Optional active scan. Select parent, eg: by 14
EPID. If rejoin fails then retry later. 15
JOIN.request 16
(RejoinNetwork=2)
Rejoin request
17
(unsecured, from IEEE address) JOIN.indication 18
Rejoin response (unsecured, to IEEE Update device
address, includes short address)
(rejoin) 19
JOIN.confirm
Key transport 20
(dummy key)
(SUCCESS)
SET and GET Alternatively 21
Remove device.
(relationship) 22
Key transport (dummy key, unsecured)
23
Entity authentication [if required]
24
End_Device_annce 25
(if short address changed) End_Device_annce 26
27
Figure 2.96 Portability Message Sequence Chart: ZED Rejoin 28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Z R 1 ’s Z R 1 ’s Z R 2 ’s Z R 2 ’s T ru st
1
NW K ZDO NW K ZDO C en tre
2
3
S o m e m e ssa ge (e g: a b ro a d c ast M A N Y -T O -O N E -R O U T IN G u p d a te )
4
If w e h a ve n ’t h e ard a n y m essag e fro m th e 5
tru st c e n tre fo r tim e o u t p e rio d T (se t b y
sta c k p ro file ), th e n c a rry o u t a n a c tive sc a n . 6
N o te e a c h n e igh b o r th a t in d ic a te s in its 7
b e a c o n th at it c a n h ea r th e T C . S e le c t o n e
(e g: b y E P ID ). If re jo in fa ils th e n re try la te r. 8
9
JO IN .re q u e st
(R e jo in N e tw o rk = 2 ) 10
R ejo in re q u e st (u n se c u re d , fro m IE E E 11
a d d re ss, in c lu d e e x istin g sh o rt a d d re ss) JO IN .in d ic a tio n
R e jo in resp o n se (rejo in ) U p d a te d e vic e 12
(u n se c u re d , to IE E E a d d re ss)
K e y tran sp o rt 13
JO IN .c o n firm
(S U C C E S S )
(d u m m y k e y) 14
SET and G E T A lte rn a tive ly
(re la tio n sh ip ) R e m o ve d e vic e . 15
K e y tra n sp o rt (d u m m y k e y , u n se c u re d ) 16
E n tity a u th e n tic atio n [if re q u ire d ] 17
18
19
20
Figure 2.97 Portability Message Sequence Chart: ZR Rejoin 21
22
2.5.5.5.4.2 Description of Operations for Security Verification 23
24
As for MAC association, a ZigBee Coordinator or ZigBee Router device is 25
informed of a rejoined device when the NLME issues an NLME-JOIN.indication 26
primitive. This shall be handled in the same way as for an association indication. 27
28
Note that due to the absence of an entity authentication this child status is initially
29
provisional, and full network operation shall not be permitted until the verification
30
steps described below have been carried out.
31
Measures shall be taken by a newly (re-)joined node and by its new parent to 32
verify that it is really allowed to be on this network. Two cases are envisaged: 33
34
• One or other device is not implemented according to this specification, and
35
should not have joined. The measures described here allow both sides to revoke
36
the join in this case.
37
• One or other device is a compromised/hacked device. In the case that security 38
is enabled, the measures in sub-clause 4.7.3.6 are additionally applied so that 39
an unauthorized join is revoked. 40
41
This verification is carried out using existing commands. Sub-clause 2.5.5.5.4.3
42
below describes the transmission of an End_Device_annce command to the new
43
parent. The new parent shall check that this or some other message is correctly
44
45
Chapter 2
formed and contains the addressing fields corresponding to the orphaned device.
If security is enabled then this command shall be secured with the network key, 1
and the new parent shall verify that all security processing is carried out correctly. 2
If all these checks succeed then the orphaned device shall become joined to the 3
network, otherwise it shall not become joined to the network at this time. As 4
normal, messages sent from a device not joined to the network shall not be 5
forwarded across the network, and commands shall not be carried out. 6
Correspondingly the orphaned device shall only become joined to the network 7
once it receives at least one correctly formed ZigBee message from the new 8
parent. If security is enabled this message must be secured with the network key 9
and all security processing must be carried out correctly. If messages cannot be 10
exchanged in protocol then the orphaned device shall not become joined to the 11
network at this time. 12
13
2.5.5.5.4.3 Description of Operations for Informing the Rest of the Network 14
15
If the ZigBee End Device gets a new short address after rejoining a new parent 16
using the orphaning process, it shall issue an End_Device_annce providing its 64 17
bit IEEE address, new 16 bit NWK address and its capability information. The 18
message is broadcast to all devices in the network. Upon receiving the 19
End_Device_annce all devices shall check their internal tables holding 64 bit 20
IEEE addresses for devices within the PAN for a match with the address supplied 21
in the End_Device_annce message. At minimum, any Binding Table shall be 22
checked. If a match is detected, the device shall update its APS Information Block 23
address map entries corresponding to the matched 64 bit IEEE address to reflect 24
the updated 16 bit NWK address contained in the End_Device_annce. In 25
addition, all devices shall use the NLME-SET and NLME-GET primitives to 26
update the nwkNeighborTable in the NWK NIB. The previous parent of this ZED 27
shall remove the ZED as one of its children by changing the Relationship field of 28
the nwkNeighborTable to 0x04, "previous child". Note that any unicast message 29
sent to an address with this status shall result in an NLME-ROUTE- 30
ERROR.indication primitive with status code of "Target Device Unavailable", 31
(see sub-clause 3.3.12.1). As address conflict detection is not provided, parent 32
devices are not permitted, following intra-PAN portability, remove device or any 33
other operation, to reissue a short address for use by a child with a different IEEE 34
address. Also, the ZDO shall arrange that any IEEE address to short address 35
mappings which have become known to applications running on this device be 36
updated. This behavior is mandatory but the mechanism by which it is achieved is 37
outside the scope of this specification. 38
39
40
41
42
43
44
45
2.5.5.5.5 ZigBee End Device

1
3
Provision shall be made within the implementation to supply a single copy of 4
desired network configuration parameters (:Config_NWK_Mode_and_Params) to 5
the Network Object of ZigBee Device Objects. 6
7
If supported, provision shall be made to supply configuration elements for the
8
Complex Descriptor, User Descriptor, the maximum number of bind entries and
9
the master key. These elements shall be embodied in
10
:Config_Complex_Descriptor, :Config_User_Descriptor, :Config_Max_Bind and
11
:Config_Master_Key. If the device application set the NLME-JOIN
12
RxOnWhenIdle parameter to FALSE, the end device shall utilize the procedure
13
described in sub-clause 2.5.2.1 to discover a Primary Discovery Cache device,
14
register with it and to successfully upload its device and service discovery
15
information prior to turning off its receiver as a sleeping end device. Prior to
16
registering with any Primary Discovery Cache device, the end device shall utilize
17
the Find Node Cache request to ensure it has not previously registered with any
18
other Primary Discovery Cache device. If a server response indicates the end
19
device has a previous registration, the end device shall update its discovery cache
20
information on that Primary Discovery Cache device or shall remove its discovery
21
cache information from that previous registration and create a new registration.
22
the ChannelList portion of :Config_NWK_Mode_and_Params and then use the 24
NLME-NETWORK-DISCOVERY.request attribute to scan the specified 25
NetworkList detailing active PANs within that range. The NLME-NETWORK- 27
DISCOVERY.request procedure shall be implemented 28
:Config_NWK_Scan_Attempts, each separated in time by 29
:Config_NWK_Time_btwn_Scans. The purpose of repeating the NLME- 30
NETWORK-DISCOVERY.request is to provide a more accurate neighbor list and 31
associated link quality indications to the NWK layer. The device application shall 32
compare the ChannelList to the NetworkList and select an existing PAN to join. 33
Specification of the algorithm for selection of the PAN shall be left to the profile 34
descriptions and may include use of the PAN ID, operational mode of the 35
network, identity of the ZigBee Router or Coordinator identified on the PAN, 36
depth of the ZigBee Router on the PAN from the ZigBee Coordinator for the PAN, 37
capacity of the ZigBee Router or Coordinator, the routing cost or the protocol 38
version number (these parameters are supplied by the NLME-NETWORK- 39
DISCOVERY.confirm and the beacon payload). 40
41
The ZigBee end device may join networks employing the current protocol version
42
number or may join networks employing a previous protocol version number,
43
under application control, if backward compatibility is supported in the device. A
44
45
Chapter 2
single ZigBee PAN shall consist of devices employing only a single protocol
version number (networks with devices employing different protocol version 1
numbers and frame formats within the same PAN are not permitted). An optional 2
configuration attribute, :Config_NWK_alt_protocol_version, provides the 3
protocol version numbers which the device may choose to employ other than the 4
current protocol version number. Once the ZigBee end device chooses a PAN and 5
a specific protocol version number, it shall modify its 6
:Config_NWK_Mode_and_Params protocol version number field and employ 7
that protocol version number as its nwkcProtocolVersion. Additionally, the 8
ZigBee end device shall then adhere to all frame formats and processing rules 9
supplied by the version of the ZigBee Specification employing that protocol 10
version number. 11
12
Once the PAN to join is identified, the device application shall employ the 13
NLME-JOIN. request to join the PAN on that channel. The device application 14
shall check the return status via the NLME-JOIN.confirm to verify association to 15
the selected ZigBee Router or ZigBee Coordinator on that PAN. The Extended 16
PAN ID field from the beacon payload of the PAN shall also be set within 17
nwkExtendedPANID. 18
If the device application sets the NLME-JOIN RxOnWhenIdle parameter to 19
FALSE, the :Config_NWK_indirectPollRate shall be used to determine the 20
polling rate for indirect message requests. The :Config_NWK_indirectPollRate 21
shall be set according to the value established by the application profile(s) 22
supported on the device. Once polling for indirect message requests is initiated, if 23
communications failure with the parent is detected determined by failure of 24
indirect message requests :Config_Parent_Link_Threshold_Retry consecutive 25
attempts, the device application shall employ the network rejoin procedure. 26
27
Once the End Device has successfully joined a network, the device shall issue an 28
End_Device_annce providing its 64 bit IEEE address and 16 bit NWK address. 29
34
If the network has security enabled, the device shall wait for the trust center to 35
supply it with a master key via the APSME-TRANSPORT-KEY.indication and 36
then respond to a request from the trust center to establish a link key using the 37
APSME-ESTABLISH-KEY.response. The device shall then wait for the trust 38
center to provide it with a NWK key using APSME-TRANSPORT- 39
KEY.indication. Upon successful acquisition of the NWK key, the device is 40
joined and authenticated. 41
42
43
44
45
2.5.5.5.5.2 Normal Operating State

1
If the device application set the NLME-JOIN RxOnWhenIdle parameter to 2
FALSE, the :Config_NWK_indirectPollRate shall be used to poll the parent for 3
indirect transmissions while in the normal operating state. 4
The ZigBee end device shall respond to any device discovery or service discovery 5
operations requested of its own device using the attributes described in sub- 6
clause 2.5.4. 7
8
If security is enabled, the ZigBee end device shall support the 9
:Config_Master_Key and shall employ the Master Key in key establishment 10
procedures for Link Keys. Upon presentation of a remote destination address 11
requiring secure communications, the ZigBee end device shall support APSME- 12
ESTABLISH-KEY.request to establish a link key with the remote device and 13
support APSME-ESTABLISH-KEY.indication to present the request to the 14
destination and shall support APSME-ESTABLISH-KEY.confirm and APSME- 15
ESTABLISH-KEY.response to complete the key establishment of the Link Key. 16
The ZigBee end device shall provide the ability to store Link Keys for known 17
destinations requiring secure communications and shall manage key storage of 18
Link Keys. The ZigBee end device shall support APSME-TRANSPORT- 19
KEY.indication to receive keys from the trust center. The ZigBee end device shall 20
request the trust center to update its NWK key via the APSME-REQUEST- 21
KEY.request. 22
The ZigBee End Device shall process End_Device_annce messages from other 23
ZigBee End Devices. Upon receipt of an End_Device_annce, the ZigBee End 24
Device shall check all internal tables holding 64 bit IEEE addresses for devices 25
within the PAN for a match with the address supplied in the End_Device_annce 26
message. At minimum, any Binding Table entries held by the ZigBee End Device 27
shall be checked. If a match is detected, the ZigBee End Device shall update its 28
APS Information Block address map entries corresponding to the matched 64 bit 29
IEEE address to reflect the updated 16 bit NWK address contained in the 30
End_Device_annce. 31
32
The ZigBee End Device shall process the NLME-ROUTE-ERROR.indication 33
sent from the NWK layer. If the error code equals to 0x09 (Parent Link Failure), 34
the ZED will update its failure counter maintained in ZDO. If the value of the 35
failure counter is smaller than the :Config_Parent_Link_Retry_Threshold 36
attribute, the ZED may decide to issue further commands to attempt to 37
communicate with the parent node, depending on the application of the ZED. If 38
the value of the failure counter exceeds the 39
:Config_Parent_Link_Retry_Threshold attribute, the ZED shall then prepare to 40
start the rejoin process. Note that implementers may optionally use a more 41
accurate time-windowed scheme to identify a link failure. 42
43
44
45
Chapter 2
The rejoin process mirrors the MAC association process very closely, however a
device is permitted to rejoin a parent that is not accepting new associations. The 1
ZDO may use the NLME-NETWORK-DISCOVERY.request primitive to detect 2
potential alternative parents, and in order to optimize recovery latency and 3
reliability, shall select an appropriate new parent based on the following 4
information from that device's beacon: 5
6
• PAN ID 7
• EPID (Extended PAN ID) 8
9
• Channel 10
• Signal strength 11
12
• Whether the potential parent indicates that it is currently able to communicate 13
with its trust center 14
• Whether this device has recently failed to join this parent, or this network. 15
16
Once a potential parent has been selected the ZDO shall issue an NLME- 17
JOIN.request primitive with RejoinNetwork set to 0x02. 18
The start time of the rejoin process is determined by the time the last NLME- 19
JOIN.request primitive was sent and by the attribute :Config_Rejoin_Interval. 20
Only if the interval between the current and the previous NLME-JOIN.request 21
sent time is longer than the :Config_Rejoin_Interval shall a new NLME- 22
JOIN.request primitive be sent. The application may want to gradually increase 23
the :Config_Rejoin_Interval if a certain number of retries have been done (or a 24
certain period of time has passed) but none of them were successful. The 25
:Config_Rejoin_Interval should not exceed the :Config_Max_Rejoin_Interval. 26
Every time an NLME-JOIN.confirm has been successfully received, the ZDO 27
shall reset its failure counter to zero and the :Config_Rejoin_Interval attribute to 28
its initial value. The choice of the default initial value and the algorithm of 29
increasing the rejoin interval shall be determined by the application and is out of 30
the scope of this document. 31
32
If the ZigBee End Device gets a new short address after rejoining a new parent 33
using the rejoin process, it shall issue an End_Device_annce providing its 64 bit 34
IEEE address, new 16 bit NWK address and its capability information. The 35
message is broadcast to all devices in the network. 36
37
2.5.5.6 Device and Service Discovery 38
The Device and Service Discovery function supports: 39
40
• Device Discovery 41
• Service Discovery 42
43
44
45
Device Management performs the above functions with the ZigBee Device Profile
(See clause 2.4). 1
2
2.5.5.6.1 Optional and Mandatory Attributes Within Device and Service 3
Discovery 4
All of the request attributes within the Device and Service Discovery Object are 5
optional for all ZigBee logical device types. The responses listed in Table 2.130 as 6
mandatory are mandatory for all ZigBee logical device types and the responses 7
listed as optional are optional for all ZigBee logical device types. See clause 2.4 8
for a description of any of these attributes. 9
10
Table 2.130 Device and Service Discovery Attributes 11
Attribute M/O Type 12
13
NWK_addr_req O Public 14
NWK_addr_rsp M Public 15
16
IEEE_addr_req O Public
17
IEEE_addr_rsp M Public 18
Node_Desc_req O Public 19
20
Node_Desc_rsp M Public
21
Power_Desc_req O Public 22
Power_Desc_rsp M Public 23
24
Simple_Desc_req O Public 25
Simple_Desc_rsp M Public 26
Active_EP_req O Public
27
28
Active_EP_rsp M Public 29
Match_Desc_req O Public 30
31
Match_Desc_rsp M Public
32
Complex_Desc_req O Public 33
Complex_Desc_rsp O Public 34
35
User_Desc_req O Public
36
User_Desc_rsp O Public 37
End_Device_annce O Public 38
39
User_Desc_set O Public 40
User_Desc_conf O Public 41
System_Server_Discovery_req O Public 42
43
System_Server_Discovery_rsp O Public 44
45
Chapter 2
Table 2.130 Device and Service Discovery Attributes (Continued)

1
Discovery_Cache_req O Public 3
4
Discovery_Cache_rsp O Public
5
Discovery_store_req O Public 6
Discovery_store_rsp O Public 7
8
Node_Desc_store_req O Public 9
Node_Desc_store_rsp O Public 10
Power_Desc_store_req O Public
11
12
Power_Desc_store_rsp O Public 13
Active_EP_store_req O Public 14
15
Active_EP_store_rsp O Public
16
Simple_Desc_store_req O Public 17
Simple_Desc_store_rsp O Public 18
19
Remove_node_cache_req O Public
20
Remove_node_cache_rsp O Public 21
Find_node_cache_req O Public 22
23
Find_node_cache_rsp M Public
24
25
2.5.5.7 Security Manager 26
27
The security manager determines whether security is enabled or disabled and, if
28
enabled, shall perform the following:
29
• Establish Key 30
31
• Transport Key
32
• Authentication 33
34
2.5.5.7.1 Optional and Mandatory Attributes Within Security Manager
35
The Security Manager itself is an optional object for all ZigBee Device Types. If 36
the Security Manager is present, all requests and responses are mandatory for all 37
ZigBee device types. If the Security Manager is not present, none of the attributes 38
39
40
41
42
43
44
45
in the Security Manager are present for any ZigBee logical device type. See
clause 2.4 for a description of any of the primitives listed in Table 2.131. 1
2
Table 2.131 Security Manager Attributes
3
5
APSME-ESTABLISH-KEY.request O Public 6
APSME-ESTABLISH-KEY.response O Public 7
APSME-ESTABLISH-KEY. indication O Public 8
9
APSME-ESTABLISH-KEY.confirm O Public 10
APSME-TRANSPORT-KEY.request O Public 11
12
APSME-TRANSPORT-KEY.indication O Public
13
APSME-UPDATE-DEVICE.request O Public 14
APSME-UPDATE-DEVICE.indication O Public 15
16
APSME-REMOVE-DEVICE.request O Public
17
APSME-REMOVE-DEVICE.indication O Public 18
APSME-REQUEST-KEY.request O Public 19
20
APSME-REQUEST-KEY.indication O Public
21
APSME-SWITCH-KEY.request O Public 22
APSME-SWITCH-KEY.indication O Public 23
24
25
2.5.5.8 Binding Manager 26
The Binding Management function supports: 27
28
• End Device Binding 29
• Bind and Unbind 30
31
Binding Management performs the above functions with ZigBee Device Profile 32
commands plus APSME-SAP primitives to commit/remove binding table entries 33
once the indication arrives on the Zigbee coordinator or router, supporting the 34
binding table. 35
2.5.5.8.1 Optional and Mandatory Attributes Within Binding Manager 36
37
The Binding Manager is an optional object for all ZigBee Device Types. 38
If the Binding Manager is present, all requests are optional for all ZigBee logical 39
device types. Additionally, responses shall be supported on the ZigBee 40
Coordinator or responses shall be supported on ZigBee Routers and ZigBee End 41
Devices which correspond to the source address for the binding table entries held 42
on those devices. 43
44
45
Chapter 2
If the Binding Manager is not present, all requests and all responses for all ZigBee
logical device types shall not be supported. Table 2.132 summarizes Binding 1
Manager attributes. 2
3
Table 2.132 Binding Manager Attributes
4
Attribute Method M/O Type 5
6
End_Device_Bind_req See clause 2.4. O Public 7
End_Device_Bind_rsp See clause 2.4. O Public 8
Bind_req See clause 2.4. O Public 9
10
Bind_rsp See clause 2.4. O Public 11
Unbind_req See clause 2.4. O Public 12
13
Unbind_rsp See clause 2.4. O Public
14
Bind_Register_req See clause 2.4. O Public 15
Bind_Register_rsp See clause 2.4. O Public 16
17
Replace_Device_req See clause 2.4. O Public
18
Replace_Device_rsp See clause 2.4. O Public 19
Store_Bkup_Bind_Entry_req See clause 2.4. O Public 20
21
Store_Bkup_Bind_Entry_rsp See clause 2.4. O Public
22
Remove_Bkup_Bind_req See clause 2.4. O Public 23
Remove_Bkup_Bind_rsp See clause 2.4. O Public 24
25
Backup_Bind_Table_req See clause 2.4. O Public 26
Backup_Bind_Table_rsp See clause 2.4. O Public 27
Recover_Bind_Table_req See clause 2.4. O Public
28
29
Recover_Bind_Table_rsp See clause 2.4. O Public 30
Backup_Source_Bind_req See clause 2.4. O Public 31
32
Backup_Source_Bind_rsp See clause 2.4. O Public
33
Recover_Source_Bind_req See clause 2.4. O Public 34
Recover_Source_Bind_rsp See clause 2.4. O Public 35
36
APSME-BIND.request See clause 2.2. O Private
37
APSME-BIND.confirm See clause 2.2. O Private 38
APSME-UNBIND.request See clause 2.2. O Private 39
40
APSME-UNBIND.confirm See clause 2.2. O Private
41
42
43
44
45
2.5.5.9 Network Manager

1
The Network Management function supports: 2
3
• Network Discovery
4
• Network Formation 5
6
• Permit/Disable Associations
7
• Association and Disassociation 8
9
• Route Discovery
10
• Network Reset 11
12
• Radio Receiver State Enable/Disable
13
• Get and Set of Network Management Information Block Data 14
15
Network Management performs the above functions with NLME-SAP primitives
16
(see Chapter 3).
17
2.5.5.9.1 Optional and Mandatory Attributes Within Network Manager 18
19
The Network Manager is a mandatory object for all ZigBee Device Types. 20
The Network Discovery, Get and Set attributes (both requests and confirms) are 21
mandatory for all ZigBee logical device types. 22
23
If the ZigBee logical device type is ZigBee Coordinator, the NWK Formation 24
request and confirm, the NWK Leave request, NWK Leave indication, NWK 25
Leave confirm, NWK Join indication, NWK Permit Joining request, and NWK 26
Permit Joining confirm shall be supported. The NWK Direct Join request, NWK 27
Direct Join confirm, NWK Route Discovery request and NWK Route Discovery 28
confirm may be supported. The NWK Join request and the NWK Join response 29
shall not be supported. 30
If the ZigBee logical device type is ZigBee Router, the NWK Formation request 31
and confirm shall not be supported. Additionally, the NWK Start Router request, 32
NWK Start Router confirm, NWK Join request, NWK Join confirm, NWK Join 33
indication, NWK Leave request, NWK Leave confirm, NWK Leave indication, 34
NWK Permit Joining request and NWK Permit Joining confirm shall be 35
supported. The NWK Direct Join request, NWK Direct Join confirm, NWK Route 36
Discovery request and NWK Route Discovery confirm may be supported. 37
38
If the ZigBee logical device type is ZigBee End Device, the NWK Formation 39
request and confirm plus the NWK Start Router request and confirm shall not be 40
supported. Additionally, the NWK Join indication, NWK Leave indication and 41
NWK Permit Joining request shall not be supported. The NWK Join request, 42
NWK Join confirm, NWK Leave request, NWK Leave confirm shall be 43
supported. 44
45
Chapter 2
For all ZigBee logical devices types, the NWK Sync request, indication and
confirm plus NWK reset request and confirm plus NWK route discovery request 1
and confirm shall be optional. Table 2.133 summarizes Network Manager 2
Attributes. See Chapter 3 for a description of any of the primitives listed in 3
Table 2.133. 4
5
For all ZigBee logical device types, reception of the NWK Route Error indication 6
shall be supported, but no action is required in this version of the specification. 7
Table 2.133 Network Manager Attributes 8
9
NLME-GET.request M Private 11
12
NLME-GET.confirm M Private
13
NLME-SET.request M Private 14
NLME-SET.confirm M Private 15
16
NLME-NETWORK-DISCOVERY.request M Public
17
NLME-NETWORK-DISCOVERY.confirm M Public 18
NLME-NETWORK-FORMATION.request O Private 19
20
NLME-NETWORK- O Private 21
FORMATION.confirm
22
NLME-START-ROUTER.request O Private 23
NLME-START-ROUTER.confirm a O Private 24
25
NLME-JOIN.request O Private
26
NLME-JOIN.confirm O Private 27
NLME-PERMIT-JOINING.request O Public 28
29
NLME-PERMIT-JOINING.confirmb O Public 30
NLME-DIRECT-JOIN.request O Public 31
NLME-DIRECT-JOIN.confirm O Public 32
33
NLME_LEAVE.request M Public 34
NLME-LEAVE.confirm M Public 35
36
NLME-RESET.request O Private
37
NLME-RESET.confirm O Private 38
NLME-SYNC.request O Public 39
40
NLME-SYNC.indication O Public
41
NLME-SYNC.confirm O Public 42
43
44
45
Table 2.133 Network Manager Attributes (Continued)

1
NLME-ROUTE-ERROR.indication M Private 3
4
NLME-ROUTE-DISCOVERY.request O Public
5
NLME-ROUTE-DISCOVERY.confirm O Private 6
7
a. CCB #563
8
b. CCB #563 9
10
2.5.5.10 Node Manager 11
12
The node manager supports the ability to request and respond to management
13
functions. These management functions only provide visibility to external devices
14
regarding the operating state of the device receiving the request.
15
2.5.5.10.1 Optional and Mandatory Attributes Within Node Manager 16
17
The Node Manager is an optional object for all ZigBee Device Types. All request 18
and response attributes within Node Manager are also optional if the Node 19
Manager object is present. Table 2.134 summarizes Node Manager attributes. See 20
clause 2.4 for a description of these attributes. 21
Table 2.134 Node Manager Attributes 22
23
Attribute M/O Type
24
Mgmt_NWK_Disc_req O Public 25
26
Mgmt_NWK_Disc_rsp O Public
27
Mgmt_Lqi_req O Public 28
Mgmt_Lqi_rsp O Public 29
30
Mgmt_Rtg_req O Public
31
Mgmt_Rtg_rsp O Public 32
Mgmt_Bind_req O Public 33
34
Mgmt_Bind_rsp O Public
35
Mgmt_Leave_req O Public 36
Mgmt_Leave_rsp O Public 37
38
Mgmt_Direct_Join_req O Public 39
Mgmt_Direct_Join_rsp O Public 40
Mgmt_Permit_Joining_req O Public 41
42
43
44
45
Chapter 2
Table 2.134 Node Manager Attributes

1
Mgmt_Permit_Joining_rsp O Public
2
Mgmt_Cache_req O Public 3
Mgmt_Cache_req O Public 4
5
6
2.5.6 Configuration Attributes 7
8
This attribute is used to represent the minimum mandatory and/or optional 9
attributes used as configuration attributes for a device. 10
Table 2.135 Configuration Attributes 11
12
:Config_Node_Descriptor M Public
14
15
:Config_Power_Descriptor M Public 16
:Config_Simple_Descriptors M Public 17
18
:Config_NWK_Mode_and_Params M Public
19
:Config_NWK_Scan_Attempts M Private 20
:Config_NWK_Time_btwn_Scans M Private 21
22
:Config_Complex_Descriptor O Public
23
:Config_User_Descriptor O Public 24
:Config_Max_Bind O Private 25
26
:Config_Master_Key O Private
27
:Config_EndDev_Bind_Timeout O Private 28
:Config_Permit_Join_Duration O Public 29
30
:Config_NWK_Security_Level O Private 31
:Config_NWK_Secure_All_Frames O Private 32
:Config_NWK_Leave_removeChildren O Private
33
34
:Config_NWK_BroadcastDeliveryTime O Private 35
:Config_NWK_TransactionPersistenceTime O Private 36
37
:Config_NWK_indirectPollRate O Private
38
:Config_Max_Assoc O Private 39
:Config_NWK_Join_Direct_Addrs O Public 40
41
42
43
44
45
Table 2.135 Configuration Attributes (Continued)

1
:Config_Parent_Link_Retry_Threshold O Public 3
4
:Config_Rejoin_Interval O Public
5
:Config_Max_Rejoin_Interval O Public 6
7
8
9
10
11
12
13
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
Chapter 2
2.5.6.1 Configuration Attribute Definitions

1
Table 2.136 Configuration Attribute Definitions 2
Attribute Description When Updated 3
4
:Config_Node_Descriptor Contents of the Node The :Config_Node_Descriptor is 5
Descriptor for this either created when the application 6
device (see sub- is first loaded or initialized with a
clause 2.3.2.4). commissioning tool prior to when 7
the device begins operations in the 8
network. It is used for service 9
discovery to describe node features 10
to external inquiring devices. 11
:Config_Power_Descriptor Contents of the Power The :Config_Power_Descriptor is 12
Descriptor for this either created when the application 13
device (see sub- is first loaded or initialized with a 14
clause 2.3.2.5). commissioning tool prior to when
discovery to describe node power 17
features to external inquiring 18
devices. 19
:Config_Simple_Descriptors Contents of the Simple The :Config_Simple_Descriptors 20
Descriptor(s) for each are created when the application is 21
active endpoint for first loaded and are treated as 22
this device (see sub- “read-only”. The Simple
clause 2.3.2.6). Descriptor are used for service 23
discovery to describe interfacing 24
features to external inquiring 25
devices. 26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Table 2.136 Configuration Attribute Definitions (Continued)

1
:Config_NWK_Mode_and_Params Consists of the The :Config_Node_Descriptor 3
following fields: contains a field describing this 4
device’s Logical Device Type. 5
Channel List – The That information plus the specific
list of channels to be 6
logic employed in this device’s
scanned when using ZDO permits the device
7
NLME-NETWORK- application to use the parameters 8
DISCOVERY. in 9
Extended PAN ID - :Config_NWK_Mode_and_Param 10
Used in NLME- s to form or join a network 11
NETWORK- consistent with the applications
supported on the device.
12
FORMATION and
NLME-JOIN
13
(Chapter 3) 14
15
Protocol Version –
Used in NLME-
16
NETWORK- 17
FORMATION and 18
NLME-JOIN 19
(Chapter 3). 20
Stack Profile – Used 21
in NLME- 22
NETWORK- 23
FORMATION and
NLME-JOIN
24
(Chapter 3). 25
26
Beacon Order – Used
in NLME-
27
NETWORK- 28
FORMATION 29
(Chapter 3). 30
Superframe Order – 31
Used in NLME- 32
NETORK- 33
FORMATION 34
(Chapter 3).
35
BatteryLifeExtension 36
– TRUE or FALSE 37
(sub-clause 3.3.3)
38
39
40
41
42
43
44
45
Chapter 2

1
:Config_NWK_Scan_Attempts Integer value The 3
representing the :Config_NWK_Scan_Attempts is 4
number of scan employed within ZDO to call the 5
attempts to make NLME-NETWORK- 6
before the NWK layer DISCOVERY.request primitive
decides which ZigBee the indicated number of times (for
7
coordinator or router routers and end devices). 8
to associate with (see 9
sub-clause 2.5.5.5). 10
This attribute has 11
default value of 5 and 12
valid values between 1 13
and 255. 14
:Config_NWK_Time_btwn_ Integer value The 15
Scans representing the time :Config_NWK_Time_btwn_Scans 16
duration (in seconds) is employed within ZDO to 17
between each NWK provide a time duration between
18
discovery attempt the NLME-NETWORK-
described by DISCOVERY.request attempts. 19
:Config_NWK_Scan_ 20
Attempts (see sub- 21
clause 2.5.5.5). 22
This attribute has a 23
default value of 1 24
(second) and valid 25
values between 1 and
26
255 (seconds).
27
:Config_Complex_Descriptor Contents of the The :Config_Complex_Descriptor 28
(optional) Complex is either created when the
29
Descriptor for this application is first loaded or
device (see sub- initialized with a commissioning 30
clause 2.3.2.7). tool prior to when the device 31
begins operations in the network. It 32
is used for service discovery to 33
describe extended device features
34
for external inquiring devices.
35
:Config_User_Descriptor Contents of the The :Config_User_Descriptor is 36
(optional) User either created when the application 37
Descriptor for this is first loaded or initialized with a
device (see sub- commissioning tool prior to when 38
clause 2.3.2.8). the device begins operations in the 39
discovery to provide a descriptive 41
character string for this device to 42
external inquiring devices.
43
44
45

1
:Config_Max_Bind A constant which The :Config_Max_Bind is a 3
describes the maximum number of supported 4
maximum number of Binding Table entries for this 5
binding entries device. 6
permitted if this
device is a ZigBee
7
Coordinator or ZigBee 8
Router. 9
10
:Config_Master_Key Master Key used if The :Config_Master_Key is either
security is enabled for present when the application is 11
this device (see first loaded or initialized with a 12
Chapter 4). commissioning tool prior to when 13
network. It is used for security
15
operations on the device if security
is supported and enabled. 16
17
:Config_EndDev_Bind_Timeout Timeout value in The
18
seconds employed in :Config_EndDev_Bind_Timeout
End Device Binding is employed only on ZigBee 19
(see sub- Coordinators and used to 20
clause 2.4.3.2). determine whether end device bind 21
requests have been received within 22
the timeout window.
23
:Config_Permit_Join_Duration Permit Join Duration The default value for 24
value set by the :Config_Permit_Join_Duration is 25
NLME-PERMIT- 0x00, however, this value can be 26
JOINING.request established differently according
primitive (see to the needs of the profile. 27
Chapter 3). 28
29
:Config_NWK_Security_Level Security level of the This attribute is used only on the
network (see trust center and is used to set the 30
Chapter 3). level of security on the network. 31
32
:Config_NWK_Secure_All_Fram If all network frames This attribute is used only on the
es should be secured (see trust center and is used to 33
Chapter 3). determine if network layer security 34
shall be applied to all frames in the 35
network. 36
:Config_NWK_Leave_removeCh Sets the policy as to The policy for setting this 37
ildren whether child devices parameter is found in the Stack 38
are to be removed if Profile employed. 39
the device is asked to 40
leave the network via
NLME-LEAVE (see
41
Chapter 3). 42
43
44
45
Chapter 2

1
:Config_NWK_BroadcastDeliver See Table 3.1. The value for this configuration 3
yTime attribute is established in the Stack 4
Profile. 5
:Config_NWK_TransactionPersis See Table 3.41. The value for this configuration 6
tenceTime attribute is established in the Stack 7
This attribute is Profile. 8
mandatory for the
ZigBee coordinator 9
and ZigBee routers 10
and not used for 11
ZigBee End Devices. 12
:Config_NWK_ Sets the list of :Config_NWK_ 13
protocol version 14
Alt_protocol_version numbers, other than Alt_protocol_version permits
ZigBee routers and ZigBee end 15
the current protocol
devices to join networks 16
version number, that
the device may choose discovered that employ an earlier 17
to employ in a PAN version of the ZigBee 18
Specification; Since this parameter
that it joins; This 19
attribute is applicable is optional, devices may also be
created omitting this attribute 20
only to ZigBee routers
which require only the current 21
or end devices; The
protocol version version of the ZigBee 22
numbers in the list Specification; This attribute would 23
be omitted in cases where certain
must refer to older 24
versions of the ZigBee features are required that are
contained only in the current 25
Specification.
specification or where code size is 26
limited in the device. 27
:Config_NWK_indirectPollRate Sets the poll rate for The value for this configuration 28
the device to request attribute is established by the 29
indirect transmission application profile deployed on the 30
messages from the device. 31
parent. 32
:Config_Max_Assoc Sets the maximum The value for this configuration 33
allowed associations, attribute is established by the stack 34
either of routers, end profile in use on the device. Note 35
devices or both, to a that for some stack profiles, the
parent router or maximum associations may have a 36
coordinator. dimension which provides for 37
separate maximums for router 38
associations and end device 39
associations (such as with the 40
Home Controls stack profile).
41
42
43
44
45

1
:Config_NWK_Join_Direct_Addr Consists of the :Config_NWK_Join_Direct_Addr 3
s following fields: s permits the ZigBee Coordinator 4
or Router to be pre-configured 5
DeviceAddress - 64 with a list of addresses to be direct
bit IEEE address for 6
joined.
the device to be direct 7
joined 8
CapabilityInformation 9
- Operating 10
capabilities of the 11
device to be direct 12
joined
13
MasterKey - If 14
security is enabled, 15
master key for use in
the key-pair descriptor
16
for this new device 17
(see Table 4.29) 18
See sub-clause 3.3.7.1
19
for details. 20
21
:Config_Parent_Link_Retry_Thre Contents of the link The
22
shold retry threshold for :Config_Parent_Link_Retry_Thres
parent link (see sub- hold is either created when the 23
clause 2.5.5.5.5.2) application is first loaded or 24
initialized with a commissioning 25
tool. It is used for the ZED to 26
decide how many times it should
27
retry to connect to the parent router
before initiating the rejoin process. 28
29
:Config_Rejoin_Interval Contents of the rejoin The :Config_Rejoin_Interval is
30
interval (see sub- either created when the application
clause 2.5.5.5.5.2) is first loaded or initialized with a 31
commissioning tool. It is used for 32
the ZED to decide how often it 33
should initiate the rejoin process. 34
:Config_MAX_Rejoin_Interval Contents of the The 35
maximal rejoin :Config_MAX_Rejoin_Interval is 36
interval 2.5.5.5.5.2) either created when the application 37
is first loaded or initialized with a 38
commissioning tool. It is used for
the ZED to decide how often it 39
should initiate the rejoin process. 40
41
42
43
44
45
Chapter 2
1
2
3
4
5
6
7
8
9
10
11
12
13
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
C H A P T E R
1
3
2
3
4
5
6
7
8
9
CHAPTER 3NETWORK SPECIFICATION 10

11
12
13
3.1 NWK Layer Status Values 14
15
Network (NWK) layer confirmation primitives often include a parameter that 16
reports on the status of the request to which the confirmation applies. Values for 17
NWK layer status parameters appear in Table 3.1. 18
19
Table 3.1 NWK Layer Status Values 20
Name Value Description 21
22
SUCCESS 0x00 A request has been executed successfully 23
INVALID_PARAMETER 0xc1 An invalid or out-of-range parameter has been 24
passed to a primitive from the next higher layer 25
INVALID_REQUEST 0xc2 The next higher layer has issued a request that is
26
invalid or cannot be executed given the current 27
state of the NWK layer 28
NOT_PERMITTED 0xc3 An NLME-JOIN.request has been disallowed
29
30
STARTUP_FAILURE 0xc4 An NLME-NETWORK-FORMATION.request 31
has failed to start a network
32
ALREADY_PRESENT 0xc5 A device with the address supplied to the NLME- 33
DIRECT-JOIN.request is already present in the 34
neighbor table of the device on which the NLME- 35
DIRECT-JOIN.request was issued
36
SYNC_FAILURE 0xc6 Used to indicate that an NLME-SYNC.request has 37
failed at the MAC layer 38
NEIGHBOR_TABLE_FULL 0xc7 An NLME-JOIN-DIRECTLY.request has failed 39
because there is no more room in the neighbor 40
table 41
UNKNOWN_DEVICE 0xc8 An NLME-LEAVE.request has failed because the 42
device addressed in the parameter list is not in the 43
neighbor table of the issuing device 44
45
Chapter 3
244 Network Specification
Table 3.1 NWK Layer Status Values (Continued)

1
Name Value Description 2
UNSUPPORTED_ 0xc9 An NLME-GET.request or NLME-SET.request 3
ATTRIBUTE has been issued with an unknown attribute 4
identifier 5
NO_NETWORKS 0xca An NLME-JOIN.request has been issued in an 6
environment where no networks are detectable 7
8
LEAVE_UNCONFIRMED 0xcb A device failed to confirm its departure from the
network 9
10
MAX_FRM_CNTR 0xcc Security processing has been attempted on an 11
outgoing frame, and has failed because the frame
counter has reached its maximum value 12
13
NO_KEY 0xcd Security processing has been attempted on an 14
outgoing frame, and has failed because no key was
available with which to process it 15
16
BAD_CCM_OUTPUT 0xce Security processing has been attempted on an 17
outgoing frame, and has failed because security
engine produced erroneous output 18
19
NO_ROUTING CAPACITY 0xcf An attempt to discover a route has failed due to a 20
lack of routing table or discovery table capacity
21
ROUTE_DISCOVERY_FAILED 0xd0 An attempt to discover a route has failed due to a 22
reason other than a lack of routing capacity 23
ROUTE_ERROR 0xd1 An NLDE-DATA.request has failed due to a 24
routing failure on the sending device 25
BT_TABLE_FULL 0xd2 An attempt to send a broadcast frame or member 26
mode multicast has failed due to the fact that there 27
is no room in the BTT 28
FRAME_NOT_BUFFERED 0xd3 A non-member mode multicast frame was 29
discarded pending route discovery 30
31
32
34
35
3.2.1 Network (NWK) Layer Overview 36
37
The network layer is required to provide functionality to ensure correct operation 38
of the IEEE 802.15.4-2003 MAC sub-layer and to provide a suitable service 39
interface to the application layer. To interface with the application layer, the 40
network layer conceptually includes two service entities that provide the 41
necessary functionality. These service entities are the data service and the 42
management service. The NWK layer data entity (NLDE) provides the data 43
transmission service via its associated SAP, the NLDE-SAP, and the NWK layer 44
45
management entity (NLME) provides the management service via its associated
SAP, the NLME-SAP. The NLME utilizes the NLDE to achieve some of its 1
management tasks and it also maintains a database of managed objects known as 2
the network information base (NIB). 3
4
3.2.1.1 Network Layer Data Entity (NLDE) 5
6
The NLDE shall provide a data service to allow an application to transport 7
application protocol data units (APDU) between two or more devices. The 8
devices themselves must be located on the same network. 9
The NLDE will provide the following services: 10
11
• Generation of the Network level PDU (NPDU): The NLDE shall be capable 12
of generating an NPDU from an application support sub-layer PDU through the 13
addition of an appropriate protocol header. 14
• Topology specific routing: The NLDE shall be able to transmit an NPDU to 15
an appropriate device that is either the final destination of the communication 16
or the next step toward the final destination in the communication chain. 17
18
• Security: The ability to ensure both the authenticity and confidentiality of a 19
transmission. 20
21
3.2.1.2 Network Layer Management Entity (NLME) 22
The NLME shall provide a management service to allow an application to interact 23
with the stack. 24
25
The NLME shall provide the following services: 26
• Configuring a new device: The ability to sufficiently configure the stack for 27
operation as required. Configuration options include beginning an operation as 28
a ZigBee coordinator or joining an existing network. 29
30
• Starting a network: The ability to establish a new network. 31
• Joining and leaving a network: The ability to join or leave a network as well 32
as the ability for a ZigBee coordinator or ZigBee router to request that a device 33
leave the network. 34
35
• Addressing: The ability of ZigBee coordinators and routers to assign addresses 36
to devices joining the network. 37
• Neighbor discovery: The ability to discover, record, and report information 38
pertaining to the one-hop neighbors of a device. 39
40
• Route discovery: The ability to discover and record paths through the network, 41
whereby messages may be efficiently routed. 42
43
44
45
Chapter 3
• Reception control: The ability for a device to control when the receiver is
activated and for how long, enabling MAC sub-layer synchronization or direct 1
reception. 2
3
4
3.3 Service Specification 5
6
Figure 3.1 depicts the components and interfaces of the NWK layer. 7
8
The NWK layer provides two services, accessed through two service access 9
points (SAPs). These are the NWK data service, accessed through the NWK layer 10
data entity SAP (NLDE-SAP) and the NWK management service, accessed 11
though the NWK layer management entity SAP (NLME-SAP). These two 12
services provide the interface between the application and the MAC sub-layer, via 13
the MCPS-SAP and MLME-SAP interfaces. (See [B1]). In addition to these 14
external interfaces, there is also an implicit interface between the NLME and the 15
NLDE that allows the NLME to use the NWK data service. 16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Figure 3.1 The NWK Layer Reference Model 33
34
3.3.1 NWK Data Service 35
36
The NWK layer data entity SAP (NLDE-SAP) supports the transport of 37
application protocol data units (APDUs) between peer application entities. 38
39
40
41
42
43
44
45
Table 3.2 lists the primitives supported by the NLDE-SAP and the sub-clauses in
which these primitives are discussed. 1
2
Table 3.2 NLDE-SAP Primitives
3
NLDE-SAP Primitive Request Confirm Indication 4
5
NLDE-DATA 3.3.1.1 3.3.1.2 3.3.1.3 6
7
3.3.1.1 NLDE-DATA.request 8
9
This primitive requests the transfer of a data PDU (NSDU) from the local APS 10
sub-layer entity to a single or multiple peer APS sub-layer entities. 11
3.3.1.1.1 Semantics of the Service Primitive 12
13
NLDE-DATA.request { 15
16
DstAddrMode,
17
DstAddr,
18
NsduLength,
19
Nsdu, 20
NsduHandle, 21
Radius, 22
NonmemberRadius, 23
DiscoverRoute, 24
SecurityEnable 25
} 26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Chapter 3
Table 3.3 specifies the parameters for the NLDE-DATA.request primitive.

1
Table 3.3 NLDE-DATA.request Parameters
2
4
DstAddrMode Integer 0x01 or 0x02 The type of destination address 5
supplied by the DstAddr parameter;
This may have one of the following 6
two values: 7
8
0x01=16-bit multicast group address
9
0x02=16-bit NWK address of a device
or a 16-bit broadcast address
10
11
DstAddr 16-bit 0x0000-0xFFFF Destination address 12
Address
13
NsduLength Integer < aMaxMACFrameSize The number of octets comprising the 14
- NSDU to be transferred 15
nwkcMinHeaderOverh
16
ead
17
Nsdu Set of - The set of octets comprising the 18
Octets NSDU to be transferred 19
NsduHandle Integer 0x00 – 0xff The handle associated with the NSDU 20
to be transmitted by the NWK layer 21
entity 22
Radius Unsigned 0x00 – 0xff The distance, in hops, that a frame 23
Integer will be allowed to travel through the 24
network 25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Table 3.3 NLDE-DATA.request Parameters (Continued)

1
NonmemberRa Integer 0x00 – 0x07 The distance, in hops, that a multicast 3
dius frame will be relayed by nodes not a 4
member of the group; A value of 0x07 5
is treated as infinity 6
DiscoverRoute Integer 0x00 – 0x01 The DiscoverRoute parameter may be 7
used to control route discovery 8
operations for the transit of this frame 9
(see sub-clause 3.7.3.4):
10
0x00 = suppress route discovery 11
0x01 = enable route discovery 12
SecurityEnable Boolean TRUE or FALSE The SecurityEnable parameter may be 13
used to enable NWK layer security 14
processing for the current frame; If the 15
security level specified in the NIB is 16
0, meaning no security, then this 17
parameter will be ignored; Otherwise,
a value of TRUE denotes that the 18
security processing specified by the 19
security level will be applied and a 20
value of FALSE denotes that no 21
security processing will be applied 22
23
3.3.1.1.2 When Generated 24
25
This primitive is generated by a local APS sub-layer entity whenever a data PDU
26
(NSDU) is to be transferred to a peer APS sub-layer entity.
27
3.3.1.1.3 Effect on Receipt 28
29
If this primitive is received on a device that is not currently associated, the NWK
30
layer will issue an NLDE-DATA.confirm primitive with a status of
31
INVALID_REQUEST.
32
On receipt of this primitive, the NLDE first constructs an NPDU in order to 33
transmit the supplied NSDU. If, during processing, the NLDE issues the NLDE- 34
DATA.confirm primitive prior to transmission of the NSDU, all further processing 35
is aborted. In constructing the new NPDU, the destination address field of the 36
NWK header will be set to the value provided in the DstAddr parameter and the 37
source address field will have the value of the macShortAddress attribute in the 38
MAC PIB. The discover route sub-field of the frame control field of the NWK 39
header will be set to the value provided in the DiscoverRoute parameter. If a value 40
has been supplied for the Radius parameter, it will be placed in the radius field of 41
the NWK header. If a value is not supplied, then the radius field of the NWK 42
header will be set to twice the value of the nwkMaxDepth attribute of the NWK 43
IB. The NWK layer will generate a sequence number for the frame as described in 44
45
Chapter 3
sub-clause 3.7.2.1. The sequence number value shall be inserted into the sequence
number field of the NWK header of the frame. The multicast flag field of the 1
NWK header will be set according to the value of the DstAddrMode parameter. If 2
the DstAddrMode parameter has a value of 0x01, the NWK header will contain a 3
multicast control field whose fields will be set as follows: 4
5
• The multicast mode field will be set to 0x01 if this node is a member of the 6
group specified in the DstAddr parameter 7
• Otherwise, the multicast mode field will be set to 0x00 8
9
• The non-member radius and the max non-member radius fields will be set to 10
the value of the NonmemberRadius parameter 11
Once the NPDU is constructed, the NSDU is routed using the procedure described 12
in sub-clause 3.7.3.3, if it is a unicast; sub-clause 3.7.5 if it is a broadcast; or sub- 13
clause 3.7.6.1 if it is a multicast. When the routing procedure specifies that the 14
NSDU is to be transmitted, this is accomplished by issuing the MCPS- 15
DATA.request primitive with both the SrcAddrMode and DstAddrMode 16
parameters set to 0x02, indicating the use of 16-bit network addresses. The 17
SrcPANId and DstPANId parameters should be set to the current value of 18
macPANId from the MAC PIB. The SrcAddr parameter will be set to the value of 19
macShortAddr from the MAC PIB. The value of the DstAddr parameter is the 20
next hop address determined by the routing procedure. The TxOptions parameter 21
should always be non-zero when bitwise ANDed with the value 0x01, denoting 22
that acknowledged transmission is required. On receipt of the MCPS- 23
DATA.confirm primitive, the NLDE issues the NLDE-DATA.confirm primitive 24
with a status equal to that received from the MAC sub-layer. 25
26
If the network-wide security level specified in the NIB has a non-zero value and 27
the SecurityEnable parameter has a value of TRUE, then NWK layer security 28
processing will be applied to the frame before transmission as described in 29
clause 4.4. Otherwise, no security processing will be performed at the NWK layer 30
for this frame. If security processing is done and it fails for any reason, then the 31
frame is discarded and the NLDE issues the NLDE-DATA.confirm primitive with 32
a status parameter value equal to that returned by the security suite. 33
34
3.3.1.2 NLDE-DATA.confirm 35
This primitive reports the results of a request to transfer a data PDU (NSDU) from 36
a local APS sub-layer entity to a single peer APS sub-layer entity. 37
38
39
40
41
42
43
44
45
3.3.1.2.1 Semantics of the Service Primitive

1
NLDE-DATA.confirm {
3
4
NsduHandle,
5
Status
6
} 7
8
Table 3.4 specifies the parameters for the NLDE-DATA.confirm primitive. 9
Table 3.4 NLDE-DATA.confirm Parameters 10
11
NsduHandle Integer 0x00 – 0xff The handle associated with the NSDU 13
being confirmed 14
15
Status Status INVALID_REQUEST, The status of the corresponding request
MAX_FRM_COUNTER, 16
NO_KEY, 17
BAD_CCM_OUTPUT, 18
ROUTE_ERROR, 19
BT_TABLE_FULL, 20
FRAME_NOT_BUFFER
ED or any status values 21
returned from security 22
suite or the MCPS- 23
DATA.confirm primitive 24
(see [B1]) 25
26
28
This primitive is generated by the local NLDE in response to the reception of an
29
NLDE-DATA.request primitive.
30
The Status field will reflect the status of the corresponding request, as described in 31
sub-clause 3.3.1.1.3. 32
33
3.3.1.2.3 Effect on Receipt
34
On receipt of this primitive, the APS sub-layer of the initiating device is notified 35
of the result of its request to transmit. If the transmission attempt was successful, 36
the status parameter will be set to SUCCESS. Otherwise, the status parameter will 37
indicate the error. 38
39
3.3.1.3 NLDE-DATA.indication 40
41
This primitive indicates the transfer of a data PDU (NSDU) from the NWK layer 42
to the local APS sub-layer entity. 43
44
45
Chapter 3

1
NLDE-DATA.indication {
3
4
DstAddrMode,
5
DstAddr,
6
SrcAddr, 7
NsduLength, 8
Nsdu, 9
LinkQuality 10
} 11
12
Table 3.5 specifies the parameters for the NLDE-DATA.indication primitive. 13
14
Table 3.5 NLDE-DATA.indication Parameters
15
17
DstAddrMo Integer 0x01 or 0x02 The type of destination address 18
de supplied by the DstAddr parameter;
This may have one of the following 19
two values: 20
21
0x01=16-bit multicast group
address 22
23
0x02=16-bit NWK address of a
device or a 16-bit broadcast address 24
25
DstAddr 16-bit 0x0000-0xFFFF The destination address where the
26
Address NSDU is sent
27
SrcAddr 16-bit Any valid device address The individual device address from 28
Device except a broadcast address which the NSDU originated 29
address
30
NsduLength Integer < aMaxMACFrameSize – The number of octets comprising 31
nwkcMinHeaderOverhead the NSDU being indicated 32
Nsdu Set of octets – The set of octets comprising the 33
NSDU being indicated 34
LinkQuality Integer 0x00 – 0xff The link quality indication 35
delivered by the MAC on receipt of 36
this frame as a parameter of the 37
MCPS-DATA.indication primitive 38
(see [B1])
39
40
41
42
43
44
45
3.3.1.3.2 When Generated

1
This primitive is generated by the NLDE and issued to the APS sub-layer on 2
receipt of an appropriately addressed data frame from the local MAC sub-layer 3
entity. 4
6
On receipt of this primitive, the APS sub-layer is notified of the arrival of data at 7
the device. 8
3.3.1.3.4 NWK Management Service 9
10
The NWK layer management entity SAP (NLME-SAP) allows the transport of 11
management commands between the next higher layer and the NLME. Table 3.6 12
lists the primitives supported by the NLME through the NLME-SAP interface and 13
the sub-clauses containing details on each of these primitives. 14
Table 3.6 Summary of the Primitives Accessed Through the NLME-SAP 15
16
Subclause Number in this Specification 17
18
Name Request Indication Response Confirm
19
NLME-NETWORK-DISCOVERY 3.3.2.1 3.3.2.2 20
21
NLME-NETWORK-FORMATION 3.3.3.1 3.3.3.2
22
NLME-PERMIT-JOINING 3.3.4.1 3.3.4.2 23
NLME-START-ROUTER 3.3.5.1 3.3.5.2 24
25
NLME-JOIN 3.3.6.1 3.3.6.2 3.3.6.3
26
NLME-DIRECT-JOIN 3.3.7.1 3.3.7.2 27
NLME-LEAVE 3.3.8.1 3.3.8.2 3.3.8.3 28
29
NLME-RESET 3.3.9.1 3.3.9.2
30
NLME-SYNC 3.3.10.1 3.3.10.2 3.3.10.3 31
NLME-GET 3.3.11.1 3.3.11.2 32
33
NLME-SET 3.3.11.3 3.3.11.4 34
NLME-ROUTE-ERROR 3.3.12.1 35
NLME-ROUTE-DISCOVERY 3.3.13.1 3.3.13.2 36
37
38
3.3.2 Network Discovery 39
40
The NWK layer management entity SAP (NLME-SAP) supports the discovery of 41
operating networks. The primitives employed in network discovery are the 42
NLME-NETWORK-DISCOVERY primitives. 43
44
45
Chapter 3
3.3.2.1 NLME-NETWORK-DISCOVERY.request
1
This primitive allows the next higher layer to request that the NWK layer discover 2
networks currently operating within the POS. 3
4
5
7
NLME-NETWORK-DISCOVERY.request { 8
ScanChannels, 9
ScanDuration 10
} 11
12
Table 3.7 specifies the parameters for the NLME-NETWORK- 13
DISCOVERY.request primitive. 14
15
Table 3.7 NLME-NETWORK-DISCOVERY.request Parameters
16
18
ScanChannels Bitmap 32-bit field The five most significant bits (b27,...,
19
b31) are reserved; the 27 least significant
bits (b0, b1,... b26) indicate which 20
channels are to be scanned (1 = scan, 0 = 21
do not scan) for each of the 27 valid 22
channels (see [B1]) 23
ScanDuration Integer 0x00 – 0x0e A value used to calculate the length of 24
time to spend scanning each channel; 25
The time spent scanning each channel is 26
(aBaseSuperframeDuration * (2n + 1)) 27
symbols, where n is the value of the 28
ScanDuration parameter; for more 29
information on MAC sub-layer scanning
30
(see [B1])
31
32
This primitive is generated by the next higher layer of a ZigBee device and issued 34
to its NLME to request the discovery of networks operating within the device’s 35
personal operating space (POS). 36
37
On receipt of this primitive, the NWK layer will attempt to discover networks 39
operating within the device’s POS by scanning over the channels specified in the 40
ScanChannels argument for the period specified in the ScanDuration parameter. 41
42
If the device is an IEEE 802.15.4-2003 FFD [B1], then it will perform an active 43
scan. If it is an RFD, it will perform an active scan provided that the device 44
45
implements active scan. Otherwise, it will perform a passive scan using the
MLME-SCAN.request primitive. On receipt of the MLME-SCAN.confirm 1
primitive is assembled and the NLME issues the NLME-NETWORK- 2
DISCOVERY.confirm primitive containing the information about the discovered 3
networks with a Status parameter value equal to that returned with the MLME- 4
SCAN.confirm. 5
6
3.3.2.2 NLME-NETWORK-DISCOVERY.confirm 7
8
This primitive reports the results of a network discovery operation. 9
11
13
NLME-NETWORK-DISCOVERY.confirm {
14
NetworkCount,
15
NetworkDescriptor, 16
Status 17
} 18
19
Table 3.8 describes the arguments of the NLME-NETWORK- 20
22
Table 3.8 NLME-NETWORK-DISCOVERY.confirm Parameters
23
25
NetworkCount Integer 0x00 – 0xff Gives the number of networks
discovered by the search 26
27
NetworkDescriptor List of The list contains the A list of descriptors, one for 28
network number of elements given each of the networks
descriptors by the NetworkCount discovered; Table 3.9 gives a 29
parameter detailed account of the contents 30
of each item 31
Status Status Any Status value returned See [B1]
32
with the MLME- 33
SCAN.confirm primitive 34
35
36
37
38
39
40
41
42
43
44
45
Chapter 3
Table 3.9 gives a detailed account of the contents of a network descriptor from the
NetworkDescriptor parameter. 1
2
Table 3.9 Network Descriptor Information Fields
3
5
PanID Integer 0x0000 – 0x3fff The 16-bit PAN identifier of the 6
discovered network; the 2 highest-
order bits of this parameter are 7
reserved and shall be set to 0 8
9
ExtendedPanID Integer 0x0000000000000001 - The 64-bit PAN identifier of the
0xfffffffffffffffe network. 10
11
LogicalChannel Integer Selected from the The current logical channel 12
available logical occupied by the network
channels supported by 13
the PHY (see [B1]) 14
15
StackProfile Integer 0x00 – 0x0f A ZigBee stack profile identifier
indicating the stack profile in use in
16
the discovered network 17
18
ZigBeeVersion Integer 0x00 – 0x0f The version of the ZigBee protocol
19
in use in the discovered network
20
BeaconOrder Integer 0x00 – 0x0f This specifies how often the MAC 21
sub-layer beacon is to be
22
transmitted by a given device on the
network; for a discussion of MAC 23
sub-layer beacon order (see [B1]) 24
25
SuperframeOrder Integer 0x00 – 0x0f For beacon-oriented networks, that
is, beacon order < 15, this specifies 26
the length of the active period of the 27
superframe; for a discussion of 28
MAC sub-layer superframe order 29
(see [B1]) 30
PermitJoining Boolean TRUE or FALSE A value of TRUE indicates that at 31
least one ZigBee router on the 32
network currently permits joining; 33
That is, its NWK has been issued an
NLME-PERMIT-JOINING 34
primitive and, the time limit if 35
given, has not yet expired 36
37
39
This primitive is generated by the NLME and issued to its next higher layer on 40
completion of the discovery task initiated by an NLME-NETWORK- 41
DISCOVERY.request primitive. 42
43
44
45

1
On receipt of this primitive, the next higher layer is notified of the results of a 2
network search. 3
4
3.3.3 Network Formation 5
6
This set of primitives defines how the next higher layer of a device can initialize 7
itself as the ZigBee coordinator of a new network and subsequently make changes 8
to its superframe configuration. 9
10
3.3.3.1 NLME-NETWORK-FORMATION.request 11
12
This primitive allows the next higher layer to request that the device start a new 13
ZigBee network with itself as the coordinator and subsequently make changes to 14
its superframe configuration. 15
17
19
NLME-NETWORK-FORMATION.request {
20
ScanChannels, 21
ScanDuration, 22
BeaconOrder, 23
SuperframeOrder, 24
} 26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Chapter 3
Table 3.10 specifies the parameters for the NLME-NETWORK-

FORMATION.request primitive. 1
2
Table 3.10 NLME-NETWORK-FORMATION.request Parameters
3
5
ScanChannels Bitmap 32-bit field The five most significant bits (b27,..., 6
b31) are reserved. The 27 least
significant bits (b0, b1,... b26) indicate 7
which channels are to be scanned in 8
preparation for starting a network 9
(1=scan, 0=do not scan) for each of the 10
27 valid channels (see [B1]) 11
ScanDuration Integer 0x00 – 0x0e A value used to calculate the length of 12
time to spend scanning each channel; 13
The time spent scanning each channel is 14
ScanDuration parameter (see [B1]) 17
BeaconOrder Integer 0x00 – 0x0f The beacon order of the network that the 18
higher layers wish to form 19
SuperframeOrder Integer 0x00 – 0x0f The superframe order of the network 20
that the higher layers wish to form 21
22
BatteryLifeExtension Boolean TRUE or FALSE If this value is TRUE, the NLME will
request that the ZigBee coordinator is 23
started supporting battery life extension 24
mode; If this value is FALSE, the 25
NLME will request that the ZigBee 26
coordinator is started without supporting
27
battery life extension mode
28
29
This primitive is generated by the next higher layer of a ZigBee coordinator- 31
capable device and issued to its NLME to request the initialization of itself as the 32
ZigBee coordinator of a new network and subsequently make changes to its 33
superframe configuration. 34
35
On receipt of this primitive by a device that is not capable of being a ZigBee 37
coordinator the NLME issues the NLME-NETWORK-FORMATION.confirm 38
primitive with the Status parameter set to INVALID_REQUEST. 39
40
If the device is to be initialized as a ZigBee coordinator, the NLME requests that 41
the MAC sub-layer first perform an energy detection scan and then an active scan 42
on the specified set of channels. To do this, the NLME issues the MLME- 43
SCAN.request primitive to the MAC sub-layer with the ScanType parameter set to 44
45
indicate an energy detection scan and then issues the primitive again with the
ScanType parameter set to indicate an active scan. After the completion of the 1
active scan, on receipt of the MLME-SCAN.confirm primitive from the MAC 2
sub-layer, the NLME selects a suitable channel. The NWK layer will pick a PAN 3
identifier that does not conflict with that of any network known to be operating on 4
the chosen channel. Once a suitable channel and PAN identifier are found, the 5
NLME will choose 0x0000 as the 16-bit short MAC address and inform the MAC 6
sub-layer. To do this, the NLME issues the MLME-SET.request primitive to the 7
MAC sub-layer to set the MAC PIB attribute macShortAddress. If the NIB 8
attribute nwkExtendedPANId is equal to 0x0000000000000000, this 9
attribute shall be initialized with the value of the MAC constant 10
aExtendedAddress. If no suitable channel or PAN identifier can be found, the 11
NLME issues the NLME-NETWORK-FORMATION.confirm primitive with the 12
Status parameter set to STARTUP_FAILURE. 13
14
To initialize a new superframe configuration or modify an existing one, the 15
NLME issues the MLME-START.request primitive to the MAC sub-layer. The 16
PANCoordinator parameter of the MLME-START.request primitive is set to 17
TRUE. The BeaconOrder and SuperframeOrder given to the MLME- 18
START.request primitive will be the same as those given to the NLME- 19
NETWORK-FORMATION.request. The CoordRealignment parameter in the 20
MLME-START.request primitive is set to FALSE if the primitive is issued to 21
initialize a new superframe. The CoordRealignment parameter is set to TRUE if 22
the primitive is issued to change any of the PAN configuration attributes. On 23
receipt of the associated MLME-START.confirm primitive, the NLME issues the 24
NLME-NETWORK-FORMATION.confirm primitive to the next higher layer 25
with the status returned from the MLME-START.confirm primitive. 26
27
3.3.3.2 NLME-NETWORK-FORMATION.confirm 28
This primitive reports the results of the request to initialize a ZigBee coordinator 29
in a network. 30
31
34
NLME-NETWORK-FORMATION.confirm { 35
Status 36
} 37
38
39
40
41
42
43
44
45
Chapter 3
Table 3.11 specifies the parameters for the NLME-NETWORK-

FORMATION.confirm primitive. 1
2
Table 3.11 NLME-NETWORK-FORMATION.confirm Parameters
3
5
Status Status INVALID_REQUEST, The result of the attempt to initialize a 6
STARTUP_FAILURE ZigBee coordinator or request a
or any status value returned from change to the superframe 7
the MLME-START.confirm configuration 8
primitive 9
10
12
This primitive is generated by the NLME and issued to its next higher layer in 13
response to an NLME-NETWORK-FORMATION.request primitive. This 14
primitive returns a status value of INVALID_REQUEST, STARTUP_FAILURE 15
or any status value returned from the MLME-START.confirm primitive. 16
Conditions under which these values may be returned are described in sub- 17
clause 3.3.3.1.3. 18
20
request to initialize the device as a ZigBee coordinator or request a change to the 22
superframe configuration. If the NLME has been successful, the status parameter 23
will be set to SUCCESS. Otherwise, the status parameter indicates the error. 24
25
3.3.4 Allowing Devices to Join 26
27
This primitive defines how the next higher layer of a ZigBee coordinator or router 28
can request that devices be permitted to join its network. 29
30
3.3.4.1 NLME-PERMIT-JOINING.request 31
32
This primitive allows the next higher layer of a ZigBee coordinator or router to set 33
its MAC sub-layer association permit flag for a fixed period when it may accept 34
devices onto its network. 35
36
37
39
NLME-PERMIT-JOINING.request { 40
PermitDuration 41
} 42
43
44
45
Table 3.12 specifies the parameters for the NLME-PERMIT-JOINING.request

primitive. 1
2
Table 3.12 NLME-PERMIT-JOINING.request Parameters
3
5
PermitDuration Integer 0x00 – 0xff The length of time in seconds during 6
which the ZigBee coordinator or router
will allow associations; The value 0x00 7
and 0xff indicate that permission is 8
disabled or enabled, respectively, without 9
a specified time limit 10
11
13
This primitive is generated by the next higher layer of a ZigBee coordinator or 14
router and issued to its NLME whenever it would like to permit or prohibit the 15
joining of the network by new devices. 16
18
It is only permissible that the next higher layer of a ZigBee coordinator or router 19
issue this primitive. On receipt of this primitive by the NWK layer of a ZigBee 20
end device, the NLME-PERMIT-JOINING.confirm primitive returns a status of 21
INVALID_REQUEST. 22
On receipt of this primitive with the PermitDuration parameter set to 0x00, the 23
NLME sets the MAC PIB attribute, macAssociationPermit, to FALSE by issuing 24
the MLME-SET.request primitive to the MAC sub-layer. Once the MLME- 25
SET.confirm primitive is received, the NLME issues the NLME-PERMIT- 26
JOINING.confirm primitive with a status equal to that received from the MAC 27
sub-layer. 28
29
On receipt of this primitive with the PermitDuration parameter set to 0xff, the 30
NLME sets the MAC PIB attribute, macAssociationPermit, to TRUE by issuing 31
the MLME-SET.request primitive to the MAC sub-layer. Once the MLME- 32
SET.confirm primitive is received, the NLME issues the NLME-PERMIT- 33
JOINING.confirm primitive with a status equal to that received from the MAC 34
sub-layer. 35
On receipt of this primitive with the PermitDuration parameter set to any value 36
other than 0x00 or 0xff, the NLME sets the MAC PIB attribute, 37
macAssociationPermit, to TRUE as described above. Following the receipt of the 38
MLME-SET.confirm primitive, the NLME starts a timer to expire after 39
PermitDuration seconds. Once the timer is set, the NLME issues the NLME- 40
PERMIT-JOINING.confirm primitive with a status equal to that received by the 41
MAC sub-layer. On expiration of the timer, the NLME sets macAssociationPermit 42
to FALSE by issuing the MLME-SET.request primitive. 43
44
45
Chapter 3
Every NLME-PERMIT-JOINING.request primitive issued by the next higher

layer supersedes all previous requests. 1
2
3.3.4.2 NLME-PERMIT-JOINING.confirm 3
4
This primitive allows the next higher layer of a ZigBee coordinator or router to be 5
notified of the results of its request to permit the acceptance of devices onto the 6
network. 7
9
11
NLME-PERMIT-JOINING.confirm {
12
Status
13
} 14
15
Table 3.13 specifies the parameters for the NLME-PERMIT-JOINING.confirm 16
primitive. 17
Table 3.13 NLME-PERMIT-JOINING.confirm Parameters 18
19
Status Status INVALID_REQUEST The status of the corresponding request 21
or any status returned from 22
the MLME-SET.confirm 23
primitive (see [B1]) 24
25
27
This primitive is generated by the initiating NLME of a ZigBee coordinator or 28
router and issued to its next higher layer in response to an NLME-PERMIT- 29
JOINING.request. The status parameter either indicates the status received from 30
the MAC sub-layer or issues an error code of INVALID_REQUEST. The reasons 31
for these status values are described in sub-clause 3.3.4.1. 32
34
On receipt of this primitive, the next higher layer of the initiating device is 35
notified of the results of its request to permit devices to join the network. 36
37
3.3.5 Begin as a Router 38
39
This set of primitives allows a ZigBee router that is newly joined to a network to 40
begin engaging in the activities expected of a ZigBee router including the routing 41
of data frames, route discovery, route repair and the accepting of requests to join 42
the network from other devices. It also allows a ZigBee router to set up its 43
44
45
superframe configuration. It may also be used by a ZigBee router to reconfigure

its superframe. 1
2
3.3.5.1 NLME-START-ROUTER.request 3
4
This primitive allows the next higher layer of a ZigBee router to initialize or 5
change its superframe configuration. 6
8
10
NLME-START-ROUTER.request {
11
BeaconOrder,
12
SuperframeOrder, 13
} 15
16
Table 3.14 specifies the parameters for NLME-START-ROUTER.request. 17
18
Table 3.14 NLME-START-ROUTER.request Parameters
19
21
BeaconOrder Integer 0x00 – 0x0f The beacon order of the network that
the higher layers wish to form 22
23
SuperframeOrder Integer 0x00 – 0x0f The superframe order of the network 24
that the higher layers wish to form
25
BatteryLifeExtension Boolean TRUE or FALSE If this value is TRUE, the NLME will 26
request that the ZigBee router is started 27
supporting battery life extension mode;
If this value is FALSE, the NLME will
28
request that the ZigBee router is 29
started without supporting battery life 30
extension mode 31
32
34
This primitive is generated by the next higher layer of a new device and issued to 35
its NLME to request the initialization of itself as a ZigBee router. It may also be 36
issued to the NLME of a device that is already operating as a ZigBee router to 37
adjust the configuration of its superframe. 38
40
On receipt of this primitive by a device that is not already joined to a ZigBee 41
network as a router, the NLME issues the NLME-START-ROUTER.confirm 42
primitive with the Status parameter set to INVALID_REQUEST. 43
44
45
Chapter 3
To initialize a new superframe configuration or to reconfigure an already existing

one, the NLME issues the MLME-START.request primitive to the MAC sub- 1
layer. The CoordRealignment parameter in the MLME-START.request primitive 2
is set to FALSE if the primitive is issued to initialize a new superframe. The 3
CoordRealignment parameter is set to TRUE if the primitive is issued to change 4
any of the PAN configuration attributes. 5
6
On receipt of the associated MLME-START.confirm primitive, the NLME issues 7
the NLME-START-ROUTER.confirm primitive to the next higher layer with the 8
status returned from the MLME-START.confirm primitive. If, and only if, the 9
status returned from the MLME-START.confirm primitive is SUCCESS, the 10
device may then begin to engage in the activities expected of a ZigBee router 11
including the routing of data frames, route discovery, route repair and the 12
accepting of requests to join the network from other devices. Otherwise, the 13
device is expressly forbidden to engage in these activities. 14
15
3.3.5.2 NLME-START-ROUTER.confirm 16
This primitive reports the results of the request to initialize or change the 17
superframe configuration of a ZigBee router. 18
19
22
NLME-START-ROUTER.confirm { 23
Status 24
} 25
26
Table 3.15 specifies the parameters for NLME-START-ROUTER.confirm. 27
28
Table 3.15 NLME-START-ROUTER.confirm Parameters 29
31
Status Status INVALID_REQUEST The result of the attempt to initialize a 32
or any status value returned ZigBee router 33
from the MLME-
START.confirm primitive 34
35
36
response to an NLME-START-ROUTER.request primitive. This primitive returns 39
a status value of INVALID_REQUEST or any status value returned from the 40
MLME-START.confirm primitive. Conditions under which these values may be 41
returned are described in sub-clause 3.3.5.1.3. 42
43
44
45

1
request to initialize or change the superframe configuration of a ZigBee router. If 3
the NLME has been successful, the status parameter will be set to SUCCESS. 4
Otherwise, the status parameter indicates the error. 5
6
3.3.6 Joining a Network 7
8
This set of primitives defines how the next higher layer of a device can: 9
10
• Request to join a network through association 11
• Request to join a network directly 12
13
• Request to re-join a network if orphaned 14
15
3.3.6.1 NLME-JOIN.request 16
This primitive allows the next higher layer to request to join a network either 17
through association or directly or to re-join a network if orphaned. 18
19
21
22
NLME-JOIN.request { 23
ExtendedPANId, 24
JoinAsRouter, 25
RejoinNetwork, 26
ScanChannels,
27
28
ScanDuration,
29
PowerSource,
30
RxOnWhenIdle, 31
MACSecurity 32
} 33
34
35
36
37
38
39
40
41
42
43
44
45
Chapter 3
Table 3.16 specifies the parameters for the NLME-JOIN.request primitive.

1
Table 3.16 NLME-JOIN.request Parameters
2
4
ExtendedPANId Integer 0x0000000000000 The 64-bit PAN identifier of the network 5
001 – to join
0xfffffffffffffffe 6
7
JoinAsRouter Boolean TRUE or FALSE The parameter is TRUE if the device is 8
attempting to join the network in the
capacity of a ZigBee router; Otherwise, it 9
is FALSE; The parameter is valid in 10
requests to join through association and 11
ignored in requests to join directly or to re- 12
join through orphaning 13
RejoinNetwork Integer 0x00 – 0x02 This parameter controls the method of 14
joining the network. 15
The parameter is 0x00 if the device is 16
requesting to join a network through 17
association. 18
joining directly or rejoining the network 20
using the orphaning procedure. 21
joining the network using the NWK 23
rejoining procedure. 24
ScanChannels Bitmap 32-bit field The five most significant bits (b27,..., b31) 25
are reserved. The 27 least significant bits 26
(b0, b1,... b26) indicate which channels 27
are to be scanned (1=scan, 0=do not scan) 28
for each of the 27 valid channels (see
[B1])
29
30
ScanDuration Integer 0x00-0x0e A value used to calculate the length of 31
time to spend scanning each channel; The
32
time spent scanning each channel is
ScanDuration parameter [B1] 35
36
37
38
39
40
41
42
43
44
45
Table 3.16 NLME-JOIN.request Parameters (Continued)

1
PowerSource Integer 0x00 – 0x01 This parameter becomes a part of the 3
CapabilityInformation parameter passed 4
to the MLME-ASSOCIATE.request 5
primitive that is generated as the result of 6
a successful executing of a NWK join.
The values are:
7
8
0x01 = Mains-powered device 9
0x00 = other power source (see [B1]) 10
RxOnWhenIdle Boolean TRUE or FALSE This parameter indicates whether the 11
device can be expected to receive packets 12
over the air during idle portions of the 13
CAP. The values are: 14
TRUE = The receiver is enabled when the 15
device is idle 16
FALSE = The receiver may be disabled 17
when the device is idle 18
RxOnWhenIdle shall have a value of 19
TRUE for ZigBee coordinators and 20
ZigBee routers operating in a non-beacon-
oriented network. 21
22
MACSecurity Integer 0x00 – 0x01 This parameter becomes a part of the 23
CapabilityInformation parameter passed
to the MLME-ASSOCIATE.request 24
primitive that is generated as the result of 25
a successful executing of a NWK join; 26
The values are: 27
0x01 = MAC security enabled 28
0x00 = MAC security disabled (see [B1]) 29
30
31
32
The next higher layer of a device generates this primitive to request to: 33
34
• Join a new network using the MAC sub-layer association procedure
35
• Join a new network directly using the MAC sub-layer orphaning procedure, or 36
37
• Locate and re-join a network after being orphaned.
38
40
On receipt of this primitive by a device that is currently joined to a network and 41
with the RejoinNetwork parameter equal to 0x00, the NLME issues an NLME- 42
JOIN.confirm primitive with the status parameter set to INVALID_REQUEST. 43
44
45
Chapter 3
On receipt of this primitive by a device that is not currently joined to a network

and with the RejoinNetwork parameter equal to 0x00, the device attempts to join 1
the network specified by the ExtendedPANId parameter. The NLME issues an 2
MLME-ASSOCIATE.request with its CoordAddress parameter set to the address 3
of a router for which following conditions are true: 4
5
• The router belongs to the network identified by the ExtendedPANId parameter 6
• The router is open to join requests and is advertising capacity of the correct 7
device type 8
9
• The link quality for frames received from this device is such that a link cost of 10
at most 3 is produced when calculated as described in sub-clause 3.7.3.1 11
If a device exists in the neighbor table for which these conditions are true, the 12
LogicalChannel parameter of the MLME-ASSOCIATE.request primitive is set to 13
that found in the neighbor table entry corresponding to the coordinator address of 14
the potential parent. The bit-fields of the CapabilityInformation parameter shall 15
have the values shown in Table 3.17 and the capability information assembled 16
here shall be stored as the value of the nwkCapabilityInformation NIB attribute 17
(see Table 3.41). If more than one device meets these requirements and the 18
nwkUseTreeAlloc attribute of the NIB has a value of TRUE, then the joining 19
device shall select the parent with the smallest tree depth. 20
21
Table 3.17 Capability Information Bit-fields
22
Bit Name Description 23
24
0 Alternate PAN This field will always have a value of 0 in 25
coordinator implementations of this specification
26
1 Device type This field will have a value of 1 if the 27
joining device is a ZigBee router and the 28
JoinAsRouter parameter has a value of
TRUE; It will have a value of 0 if the 29
device is a ZigBee end device or else a 30
router-capable device that is joining as an 31
end device 32
2 Power source This field shall be set to the value of 33
lowest-order bit of the PowerSource 34
parameter passed to the NLME-JOIN- 35
request primitive; The values are: 36
0x01 = Mains-powered device 37
0x00 = other power source 38
39
40
41
42
43
44
45
Table 3.17 Capability Information Bit-fields (Continued)

1
Bit Name Description 2
3 Receiver on when idle This field shall be set to the value of the 3
lowest-order bit of the RxOnWhenIdle 4
parameter passed to the NLME- 5
JOIN.request primitive. 6
0x01 = The receiver is enabled when the 7
device is idle 8
0x00 = The receiver may be disabled 9
when the device is idle 10
4–5 Reserved This field will always have a value of 0 in 11
implementations of this specification 12
6 Security capability This field shall be set to the value of 13
lowest-order bit of the MACSecurity 14
parameter passed to the NLME-JOIN- 15
request primitive. The values are: 16
0x01 = MAC security enabled 17
0x00 = MAC security disabled 18
19
7 Allocate address This field will always have a value of 1 in 20
implementations of this specification,
indicating that the joining device must be 21
issued a 16-bit short address 22
23
If no device exists in the neighbor table for which the conditions are true, then the 24
NWK layer will issue an NLME-JOIN.confirm with the Status parameter set to 25
NOT_PERMITTED. Otherwise, the NLME issues the NLME-JOIN.confirm with 26
the Status parameter set to the status parameter value returned from the MLME- 27
ASSOCIATE.confirm primitive. 28
29
If the RejoinNetwork parameter is 0x00 and the JoinAsRouter parameter is set to 30
TRUE, the device will function as a ZigBee router in the network. If the 31
JoinAsRouter parameter is FALSE, then it will join as an end device and not 32
participate in routing. 33
If a device receives this primitive and the RejoinNetwork parameter is equal to 34
0x01 then it issues an MLME-SCAN.request with the ScanType parameter set to 35
indicate an orphan scan. Values for the ScanChannels and ScanDuration 36
parameters of the MLME-SCAN.request primitive will equal those provided by 37
the NLME-JOIN.request primitive. Upon receipt of the MLME-SCAN.confirm 38
primitive, the NLME issues the NLME-JOIN.confirm with the Status parameter 39
set to NO_NETWORKS, if the device was unable to find a network to join, or else 40
to the status parameter value returned by the MLME-SCAN.confirm primitive. 41
42
43
44
45
Chapter 3
On receipt of this primitive by a device that is currently not joined to a network

and the RejoinNetwork parameter is equal to 0x02, the NLME issues an NLME- 1
JOIN.confirm primitive with the status parameter set to INVALID_REQUEST. 2
3
On receipt of this primitive by a device that is currently joined to a network, with 4
the RejoinNetwork parameter is equal to 0x02, the device attempts to rejoin its 5
current network. In this case the NLME initiates the rejoin procedure by sending a 6
rejoin request command to the address of a router in its neighbor table for which 7
following conditions are true: 8
1 The router is advertising capacity to accept the device type defined by the 9
JoinAsRouter parameter. 10
11
2 The link quality for frames received from this device is such that a link cost of 12
at most 3 is produced when calculated as described in sub-clause 3.7.3.1. 13
3 If the nwkUseTreeAddrAlloc NIB attribute has a value of TRUE and more than 14
one potential parent exists that meets the previous two conditions, then the 15
joining device shall select the address of the router with the smallest tree depth. 16
17
If a device exists in the neighbor table for which these conditions are true, the 18
destination of the rejoin request command is set to the network address of the 19
potential parent. The bit-fields of the CapabilityInformation parameter shall have 20
the values shown in Table 3.17 and the capability information assembled here 21
shall be stored as the value of the nwkCapabilityInformation NIB attribute (see 22
Table 3.41). 23
If no device exists in the neighbor table for which the conditions are true, then the 24
NWK layer will issue an NLME-JOIN.confirm with the Status parameter set to 25
NOT_PERMITTED. Otherwise, the NLME issues the NLME-JOIN.confirm with 26
the Status parameter set to the status parameter value received in the rejoin 27
response command. 28
29
Once the device has successfully joined a network, it will set the value of the 30
nwkExtendedPANID NIB attribute to the extended PAN identifier of the network 31
to which it is joined. 32
33
3.3.6.2 NLME-JOIN.indication 34
This primitive allows the next higher layer of a ZigBee coordinator or ZigBee 35
router to be notified when a new device has successfully joined its network by 36
association or rejoined using the NWK rejoin procedure as described in sub- 37
clause 3.7.1.3.3. 38
39
40
41
42
43
44
45

1
NLME-JOIN.indication {
3
4
ShortAddress,
5
ExtendedAddress,
6
CapabilityInformation, 7
SecureJoin 8
} 9
10
Table 3.18 specifies the parameters for the NLME-JOIN.indication primitive. 11
12
Table 3.18 NLME-JOIN.indication Parameters
13
15
ShortAddress Network 0x0001 – 0xfff7 The network address of an entity that
address has been added to the network 16
17
ExtendedAddress 64-bit Any 64-bit, IEEE The 64-bit IEEE address of an entity 18
IEEE address that has been added to the network
address 19
20
CapabilityInformation Bitmap See [B1] Specifies the operational capabilities 21
of the joining device
22
SecureJoin Boolean TRUE or FALSE This parameter will be TRUE if the 23
underlying MAC association was 24
performed in a secure manner;
25
Otherwise this parameter will be
FALSE 26
27
28
29
This primitive is generated by the NLME of a ZigBee coordinator or router and 30
issued to its next higher layer on successfully adding a new device to the network 31
using the MAC association procedure as shown in Figure 3.24, or on allowing a 32
device to rejoin the network using the NWK rejoining procedure as shown in 33
Figure 3.29. 34
35
On receipt of this primitive, the next higher layer of a ZigBee coordinator or 37
ZigBee router is notified that a new device has joined its network. 38
39
3.3.6.3 NLME-JOIN.confirm 40
41
request to join a network. 43
44
45
Chapter 3

1
NLME-JOIN.confirm {
3
4
ShortAddress,
5
PANId,
6
HaveNetworkKey 7
Status 8
} 9
10
Table 3.19 specifies the parameters for the NLME-JOIN.confirm primitive. 11
12
Table 3.19 NLME-JOIN.confirm Parameters
13
15
ShortAddress Integer 0x0001 – 0xFFFF The 16-bit short address that was
allocated to this device; This 16
parameter will be equal to 0xFFFF if 17
the join attempt was unsuccessful 18
PANId Integer 0x0000 – 0x3fff The PAN identifier for the network of 19
which the device is now a member. 20
21
HaveNetwork Boolean TRUE or FALSE The parameter is TRUE if this device
Key and its parent are known to have the
22
same network key sequence number 23
and FALSE otherwise. 24
25
Status Status INVALID_REQUEST, The status of the corresponding
NOT_PERMITTED, request 26
NO_NETWORKS 27
28
or any status value
returned from the MLME- 29
ASSOCIATE.confirm 30
primitive or the MLME- 31
SCAN.confirm primitive 32
33
35
This primitive is generated by the initiating NLME and issued to its next higher 36
layer in response to an NLME-JOIN.request primitive. If the request was 37
successful, the status parameter shall have a value of SUCCESS. Otherwise, the 38
status parameter indicates an error code of INVALID_REQUEST, 39
NOT_PERMITTED, NO_NETWORKS or any status value returned from either 40
the MLME-ASSOCIATE.confirm primitive or the MLME-SCAN.confirm 41
primitive. The reasons for these status values are fully described in sub- 42
clause 3.3.6.1.3. 43
44
45

1
notified of the results of its request to join a network using the MAC sub-layer 3
association procedure, in order to join directly using the MAC sub-layer 4
orphaning procedure or to re-join a network once it has been orphaned. 5
6
3.3.7 Joining a Device Directly to a Network 7
8
This set of optional primitives defines how the next higher layer of a ZigBee 9
coordinator or router can request to directly join another device to its network. 10
11
3.3.7.1 NLME-DIRECT-JOIN.request 12
13
This optional primitive allows the next higher layer of a ZigBee coordinator or 14
router to request to directly join another device to its network. 15
17
The semantics of this optional primitive are as follows: 18
19
NLME-DIRECT-JOIN.request {
20
DeviceAddress, 21
CapabilityInformation 22
} 23
24
Table 3.20 specifies the parameters for the NLME-DIRECT-JOIN.request 25
primitive. 26
27
Table 3.20 NLME-DIRECT-JOIN.request Parameters
28
30
DeviceAddress 64-bit IEEE Any 64-bit IEEE address The IEEE address of the
address device to be directly joined 31
32
CapabilityInformation Bitmap See Table 3.17 The operating capabilities 33
of the device being directly
joined 34
35
36
The next higher layer of a ZigBee coordinator or router generates this primitive to 38
add a new device directly to its network. This process is completed without any 39
over the air transmissions. 40
41
42
43
44
45
Chapter 3

1
On receipt of this primitive, the NLME will attempt to add the device specified by 2
the DeviceAddress parameter to its neighbor table. The CapabilityInformation 3
parameter will contain a description of the device being joined. The alternate PAN 4
coordinator bit is set to 0 in devices implementing this specification. The device 5
type bit is set to 1 if the device is a ZigBee router or to 0 if it is an end device. The 6
power source bit is set to 1 if the device is receiving power from the alternating 7
current mains or to 0 otherwise. The receiver on when idle bit is set to 1 if the 8
device does not disable its receiver during idle periods or to 0 otherwise. The 9
security capability bit is set to 1 if the device is capable of secure operation or to 0 10
otherwise. 11
If the NLME successfully adds the device to its neighbor table, the NLME issues 12
the NLME-DIRECT-JOIN.confirm primitive with a status of SUCCESS. If the 13
NLME finds that the requested device is already present in its neighbor tables, the 14
NLME issues the NLME-DIRECT-JOIN.confirm primitive with a status of 15
ALREADY_PRESENT. If no capacity is available to add a new device to the 16
device list, the NLME issues the NLME-DIRECT-JOIN.confirm primitive with a 17
status of NEIGHBOR_TABLE_FULL. 18
19
3.3.7.2 NLME-DIRECT-JOIN.confirm 20
21
This primitive allows the next higher layer of a ZigBee coordinator or router to be 22
notified of the results of its request to directly join another device to its network. 23
25
27
NLME-DIRECT-JOIN.confirm {
28
DeviceAddress, 29
Status 30
} 31
32
Table 3.21 specifies the parameters for the NLME-DIRECT-JOIN.confirm 33
primitive. 34
35
Table 3.21 NLME-DIRECT-JOIN.confirm Parameters
36
38
DeviceAddress 64-bit Any 64-bit, IEEE address The 64-bit IEEE address in the
IEEE request to which this is a 39
address confirmation 40
41
Status Status SUCCESS, The status of the corresponding
ALREADY_PRESENT, request 42
NEIGHBOR_TABLE_FULL 43
44
45

1
layer in response to an NLME-DIRECT-JOIN.request primitive. If the request 3
was successful, the status parameter indicates a successful join attempt. 4
Otherwise, the status parameter indicates an error code of ALREADY_PRESENT 5
or NEIGHBOR_TABLE_FULL. The reasons for these status values are fully 6
described in sub-clause 3.3.7.1.3. 7
9
notified of the results of its request to directly join another device to a network. 11
12
3.3.8 Leaving a Network 13
14
This set of primitives defines how the next higher layer of a device can request to 15
leave or request that a child device leaves a network. This set of primitives also 16
defines how the next higher layer of a ZigBee coordinator device can be notified 17
of an attempt by a device to leave its network. 18
19
3.3.8.1 NLME-LEAVE.request 20
21
This primitive allows the next higher layer to request that it or another device 22
leaves the network. 23
24
25
This semantics of this primitive are as follows: 26
27
NLME-LEAVE.request { 28
DeviceAddress, 29
RemoveChildren, 30
Rejoin, 31
ReuseAddress, 32
Silent 33
} 34
35
36
37
38
39
40
41
42
43
44
45
Chapter 3
Table 3.22 specifies the parameters for the NLME-LEAVE.request primitive.

1
Table 3.22 NLME-LEAVE.request Parameters
2
4
DeviceAddress Device Any 64-bit, IEEE The 64-bit IEEE address of the entity to 5
address address be removed from the network or NULL
if the device removes itself from the 6
network 7
8
RemoveChildren Boolean TRUE or FALSE This parameter has a value of TRUE if
the device being asked to leave the 9
network is also being asked to remove 10
its child devices, if any. Otherwise it 11
has a value of FALSE. 12
Rejoin Boolean TRUE or FALSE This parameter has a value of a TRUE 13
if the device being asked to leave from 14
the current parent is requested to rejoin 15
the network; Otherwise, the parameter 16
has a value of FALSE
17
ReuseAddress Boolean TRUE or FALSE In the case where the DeviceAddress 18
parameter has a non-NULL value, 19
indicating that another device is being
asked to leave the network, this
20
parameter has a value of TRUE if the 21
NWK layer may reuse the address 22
formerly in use by the leaving device 23
and FALSE otherwise. 24
Silent Boolean TRUE or FALSE In the case where the DeviceAddress 25
parameter has a non-NULL value, 26
indicating that another device is being 27
asked to leave the network, this
28
parameter, if it has a value of TRUE,
indicates that the leave procedure 29
outlined here and in sub- 30
clause 3.7.1.8.2 but without actually 31
transmitting a leave command frame. 32
33
35
The next higher layer of a device generates this primitive to request to leave the 36
network. The next higher layer of a ZigBee coordinator or router may also 37
generate this primitive to remove a device from the network. 38
40
On receipt of this primitive by the NLME of a device that is not currently joined to 41
a network, the NLME issues the NLME-LEAVE.confirm primitive with a status 42
of INVALID_REQUEST. On receipt of this primitive by the NLME of a device 43
that is currently joined to a network, with the DeviceAddress parameter equal to 44
45
NULL and the RemoveChildren parameter equal to FALSE, the NLME will
remove the device itself from the network using the procedure described in sub- 1
clause 3.7.1.8.1. The NLME will then clear its routing table and route discovery 2
table and issue an MLME-RESET.request primitive to the MAC sub-layer. If the 3
NLME receives an MLME-RESET.confirm primitive with the Status parameter 4
set to anything other than SUCCESS, the NLME may choose to re-issue the reset 5
request. The NLME will also set the relationship field of the neighbor table entry 6
corresponding to its former parent to 0x03, indicating no relationship. If the 7
NLME-LEAVE.request primitive is received with the DeviceAddress parameter 8
equal to NULL and the RemoveChildren parameter equal to TRUE, then the 9
NLME will attempt to remove the device's children, as described in sub- 10
clause 3.7.1.8.3. 11
12
On receipt of this primitive by a ZigBee coordinator or ZigBee router and with the 13
DeviceAddress parameter not equal to NULL, the NLME determines whether the 14
specified device is a child device. If the requested device does not exist, the 15
NLME issues the NLME-LEAVE.confirm primitive with a status of 16
UNKNOWN_DEVICE. If the requested device exists, the NLME will attempt to 17
remove it from the network using the procedure described in sub-clause 3.7.1.8.2. 18
If the RemoveChildren parameter is equal to TRUE then the device will be 19
requested to remove its children as well. Following the removal, the NLME will 20
issue the NLME-LEAVE.confirm primitive with the DeviceAddress equal to the 21
64-bit IEEE address of the removed device and the Status parameter equal to the 22
status delivered by the MCPS-DATA.confirm primitive. Then the relationship 23
field for the neighbor table entry corresponding to the removed device will be 24
updated. The relationship field will be updated according to the value of the 25
Rejoin parameter from the NLME-LEAVE.request. If Rejoin is equal to FALSE 26
then the relationship field is set to 0x03, indicating no relationship. If however 27
Rejoin is equal to TRUE then the relationship field is set to 0x04, indicating that 28
the address belonged to a previous child. 29
30
3.3.8.2 NLME-LEAVE.indication 31
This primitive allows the next higher layer of a ZigBee device to be notified if that 32
ZigBee device has left the network or if a neighboring device has left the network. 33
34
37
NLME-LEAVE.indication { 38
DeviceAddress, 39
Rejoin 40
} 41
42
43
44
45
Chapter 3
Table 3.23 specifies the parameters for the NLME-LEAVE.indication primitive.

1
Table 3.23 NLME-LEAVE.indication Parameters
2
4
DeviceAddress 64-bit Any 64-bit, IEEE address The 64-bit IEEE address of an entity 5
IEEE that has removed itself from the
address network or NULL in the case that 6
the device issuing the primitive has 7
been removed from the network by 8
its parent 9
Rejoin Boolean TRUE or FALSE This parameter has a value of TRUE 10
if the device being asked to 11
disassociate from the current parent 12
is requested to rejoin the network; 13
Otherwise, this parameter has a
value of FALSE 14
15
16
This primitive is generated by the NLME of a ZigBee coordinator or ZigBee 18
router and issued to its next higher layer on the receipt of a broadcast leave 19
command pertaining to a device on its PAN. It is also generated by the NLME of a 20
ZigBee router or end device and issued to its next higher layer to indicate that it 21
has been successfully removed from the network by its associated router or 22
ZigBee coordinator. 23
24
On receipt of this primitive, the next higher layer of a ZigBee coordinator or 26
ZigBee router is notified that a device, formerly on the network, has left. The 27
primitive can also indicate that the next higher layer of a ZigBee router or end 28
device is informed that it has been removed from the network by its associated 29
ZigBee router or ZigBee coordinator. 30
31
If the Rejoin parameter is equal to TRUE, it is expected that the next higher layer 32
will subsequently rejoin the network using the NLME-JOIN.request primitive and 33
may employ the entire procedure outlined in sub-clause 3.7.1.3. If the Rejoin 34
parameter is equal to FALSE, the leaving device should not automatically attempt 35
to rejoin the network, although it may rejoin at a later point in response to 36
instructions from a higher layer. 37
38
3.3.8.3 NLME-LEAVE.confirm 39
request for itself or another device to leave the network. 41
42
43
44
45

1
NLME-LEAVE.confirm {
3
4
DeviceAddress,
5
Status
6
} 7
8
Table 3.24 specifies the parameters for the NLME-LEAVE.confirm primitive. 9
Table 3.24 NLME-LEAVE.confirm Parameters 10
11
DeviceAddress 64-bit Any 64-bit, IEEE address The 64-bit IEEE address 13
IEEE in the request to which 14
address this is a confirmation or 15
null if the device 16
requested to remove 17
itself from the network
18
Status Status SUCCESS, INVALID_REQUEST, The status of the 19
UNKNOWN_DEVICE or any corresponding request 20
status returned by the MCPS-
DATA.confirm primitive 21
22
23
layer in response to an NLME-LEAVE.request primitive. If the request was 26
successful, the status parameter indicates a successful leave attempt. Otherwise, 27
the status parameter indicates an error code of INVALID_REQUEST, 28
UNKNOWN_DEVICE or a status delivered by the MCPS-DATA.confirm 29
primitive. The reasons for these status values are fully described in sub- 30
clause 3.3.8.1.3. 31
32
notified of the results of its request for itself or a child device to leave the network. 35
36
37
3.3.9 Resetting a Device 38
39
This set of primitives defines how the next higher layer of a device can request 40
that the NWK layer is reset. 41
42
43
44
45
Chapter 3
3.3.9.1 NLME-RESET.request
1
This primitive allows the next higher layer to request that the NWK layer 2
performs a reset operation. 3
4
5
7
NLME-RESET.request { 8
} 9
10
This primitive has no parameters. 11
12
13
This primitive is generated by the next higher layer and issued to its NLME to 14
request the reset of the NWK layer to its initial condition. 15
16
On receipt of this primitive, the NLME issues the MLME-RESET.request 18
primitive to the MAC sub-layer with the SetDefaultPIB parameter set to TRUE. 19
On receipt of the corresponding MLME-RESET.confirm primitive, the NWK 20
layer resets itself by clearing all internal variables, routing table and route 21
discovery table entries and by setting all NIB attributes to their default values. 22
Once the NWK layer is reset, the NLME issues the NLME-RESET.confirm with 23
the Status parameter set to SUCCESS if the MAC sub-layer was successfully reset 24
or DISABLE_TRX_FAILURE otherwise. 25
26
If this primitive is issued to the NLME of a device that is currently joined to a 27
network, any required leave attempts using the NLME-LEAVE.request primitive 28
should be made a priori at the discretion of the next higher layer. 29
30
3.3.9.2 NLME-RESET.confirm 31
request to reset the NWK layer. 33
34
37
NLME-RESET.confirm { 38
Status 39
} 40
41
42
43
44
45

1
Table 3.25 NLME-RESET.confirm Parameters
2
4
Status Status Any status value returned The result of the reset operation 5
from the MLME-
RESET.confirm primitive 6
(see [B1]) 7
8
10
response to an NLME-RESET.request primitive. If the request was successful, the 12
status parameter indicates a successful reset attempt. Otherwise, the status 13
parameter indicates an error code of DISABLE_TRX_FAILURE. The reasons for 14
these status values are fully described in sub-clause 3.3.9.1.3. 15
16
17
request to reset the NWK layer. 19
20
3.3.9.3 Network Layer Reset Message Sequence Chart 21
22
Figure 3.2 illustrates the sequence of messages necessary for resetting the NWK 23
layer. 24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Chapter 3
Device Device Device 1

APL NWK MAC 2
3
NLME- 4
RESET.request MLME- 5
RESET.request 6
7
8
MLME-RESET.confirm
9
(SUCCESS)
10
11
12
13
Clear internal state. 14
15
NLME-RESET.confirm 16
(SUCCESS) 17
18
19
20
Figure 3.2 Message Sequence Chart for Resetting the Network Layer 21
22
3.3.10 Receiver Synchronization 23
24
25
This set of primitives defines how the next higher layer of a device can
26
synchronize with a ZigBee coordinator or router and extract pending data from it.
27
3.3.10.1 NLME-SYNC.request 28
29
This primitive allows the next higher layer to synchronize or extract data from its 30
ZigBee coordinator or router. 31
32
33
35
NLME-SYNC.request { 36
Track 37
} 38
39
40
41
42
43
44
45

1
Table 3.26 NLME-SYNC.request Parameters
2
4
Track Boolean TRUE or FALSE Whether or not the synchronization should 5
be maintained for future beacons
6
7
This primitive is generated whenever the next higher layer wishes to achieve 9
synchronization or check for pending data at its ZigBee coordinator or router. 10
11
If the TRACK parameter is set to FALSE and the device is operating on a non- 13
beacon enabled network, the NLME issues the MLME-POLL.request primitive to 14
the MAC sub-layer. On receipt of the corresponding MLME-POLL.confirm 15
primitive, the NLME issues the NLME-SYNC.confirm primitive with the Status 16
parameter set to the value reported in the MLME-POLL.confirm. 17
18
If the TRACK parameter is set to FALSE and the device is operating on a beacon 19
enabled network, the NLME first sets the macAutoRequest PIB attribute in the 20
MAC sub-layer to TRUE by issuing the MLME-SET.request primitive. It then 21
issues the MLME-SYNC.request primitive with the TrackBeacon parameter set to 22
FALSE. The NLME then issues the NLME-SYNC.confirm primitive with the 23
Status parameter set to SUCCESS. 24
If the TRACK parameter is set to TRUE and the device is operating on a non- 25
beacon enabled network, the NLME will issue the NLME-SYNC.confirm 26
primitive with a status parameter set to INVALID_PARAMETER. 27
28
If the TRACK parameter is set to TRUE and the device is operating on a beacon 29
enabled network, the NLME first sets the macAutoRequest PIB attribute in the 30
MAC sub-layer to TRUE by issuing the MLME-SET.request primitive. It then 31
issues the MLME-SYNC.request primitive with the TrackBeacon parameter set to 32
TRUE. The NLME then issues the NLME-SYNC.confirm primitive with the 33
Status parameter set to SUCCESS. 34
35
3.3.10.2 NLME-SYNC.indication 36
37
This primitive allows the next higher layer to be notified of the loss of
38
synchronization at the MAC sub-layer.
39
40
41
42
43
44
45
Chapter 3

1
NLME-SYNC.indication {
3
4
}
5
6
This primitive has no parameters. 7
9
This primitive is generated following a loss of synchronization notification from 10
the MAC sub-layer via the MLME-SYNC-LOSS.indication primitive with a 11
LossReason of BEACON_LOST. This follows a prior NLME-SYNC.request 12
primitive being issued to the NLME. 13
15
The next higher layer is notified of the loss of synchronization with the beacon. 16
17
3.3.10.3 NLME-SYNC.confirm 18
19
This primitive allows the next higher layer to be notified of the results of its
20
request to synchronize or extract data from its ZigBee coordinator or router.
21
23
NLME-SYNC.confirm { 25
Status 26
} 27
28
29
Table 3.27 NLME-SYNC.confirm Parameters 31
32
33
Status Status SUCCESS, The result of the request to synchronize with 34
SYNC_FAILURE, the ZigBee coordinator or router 35
INVALID_PARAME 36
TER or any status
value returned from the 37
MLME_POLL.confirm 38
primitive (see [B1]) 39
40
42
layer in response to an NLME-SYNC.request primitive. If the request was 44
45
successful, the status parameter indicates a successful state change attempt.

Otherwise, the status parameter indicates an error code. The reasons for these 1
status values are fully described in sub-clause 3.3.10.1.3. 2
3
request to synchronize or extract data from its ZigBee coordinator or router. If the 6
NLME has been successful, the Status parameter will be set to SUCCESS. 7
Otherwise, the Status parameter indicates the error. 8
9
3.3.10.4 Message Sequence Charts For Synchronizing with a 10
11
Coordinator 12
Figure 3.3 and Figure 3.4 illustrate the sequence of messages necessary for a 13
device to successfully synchronize with a ZigBee coordinator. Figure 3.3 14
illustrates the case for a non-beaconing network, and Figure 3.4 illustrates the 15
case for a beaconing network. 16
17
18
APL NWK MAC 20
21
NLME-SYNC.request 22
(TRACK=FALSE) 23
24
MLME- 25
POLL.request 26
27
28
29
MLME-POLL.confirm
30
(SUCCESS)
31
32
NLME-SYNC.confirm 33
(SUCCESS) 34
35
36
37
38
Figure 3.3 Message Sequence Chart for Synchronizing in a Non-Beaconing 39
Network
40
41
42
43
44
45
Chapter 3

APL NWK MAC 2
3
NLME- 4
SYNC.request ML ME- 5
SET.request 6
7
Set 8
macAutoRequest to
9
TRUE
10
ML ME-SET.confirm 11
(SUCCESS) 12
13
ML ME- 14
SYNC.request 15
16
NLME-SYNC.confirm 17
(SUCCESS) 18
19
20
Figure 3.4 Message Sequence Chart for Synchronizing in a Beacon-Enabled 21
Network 22
23
24
3.3.11 Information Base Maintenance 25
26
This set of primitives defines how the next higher layer of a device can read and
27
write attributes in the NIB.
28
29
3.3.11.1 NLME-GET.request
30
This primitive allows the next higher layer to read the value of an attribute from 31
the NIB. 32
33
36
NLME-GET.request { 37
NIBAttribute 38
} 39
40
41
42
43
44
45

1
Table 3.28 NLME-GET.request Parameters
2
4
NIBAttribute Integer See Table 3.41 The identifier of the NIB attribute to read 5
6
8
This primitive is generated by the next higher layer and issued to its NLME in
9
order to read an attribute from the NIB.
10
12
On receipt of this primitive, the NLME attempts to retrieve the requested NIB 13
attribute from its database. If the identifier of the NIB attribute is not found in the 14
database, the NLME issues the NLME-GET.confirm primitive with a status of 15
UNSUPPORTED_ATTRIBUTE. 16
If the requested NIB attribute is successfully retrieved, the NLME issues the 17
NLME-GET.confirm primitive with a status of SUCCESS and the NIB attribute 18
identifier and value. 19
20
3.3.11.2 NLME-GET.confirm 21
22
This primitive reports the results of an attempt to read the value of an attribute 23
from the NIB. 24
26
NLME-GET.confirm { 28
29
Status,
30
NIBAttribute,
31
NIBAttributeLength,
32
NIBAttributeValue 33
} 34
35
36
37
38
39
40
41
42
43
44
45
Chapter 3

1
Table 3.29 NLME-GET.confirm Parameters
2
4
Status Enumeration SUCCESS or The results of the request to read a 5
UNSUPPORTED NIB attribute value
_ATTRIBUTE 6
7
NIBAttribute Integer See Table 3.41 The identifier of the NIB attribute 8
that was read.
9
NIBAttributeLength Integer 0x0000 – 0xffff The length, in octets, of the 10
attribute value being returned. 11
NIBAttributeValue Various Attribute Specific The value of the NIB attribute that 12
(see Table 3.41) was read. 13
14
16
response to an NLME-GET.request primitive. This primitive returns either a 18
status of SUCCESS, indicating that the request to read a NIB attribute was 19
successful, or an error code of UNSUPPORTED_ATTRIBUTE. The reasons for 20
these status values are fully described in sub-clause 3.3.11.1.3. 21
23
request to read a NIB attribute. If the request to read a NIB attribute was 25
successful, the Status parameter will be set to SUCCESS. Otherwise, the status 26
parameter indicates the error. 27
28
3.3.11.3 NLME-SET.request 29
This primitive allows the next higher layer to write the value of an attribute into 30
the NIB. 31
32
34
35
NLME-SET.request { 36
NIBAttribute, 37
NIBAttributeLength, 38
NIBAttributeValue 39
40
}
41
42
43
44
45

1
Table 3.30 NLME-SET.request Parameters
2
4
NIBAttribute Integer See Table 3.41 The identifier of the NIB attribute 5
to be written
6
NIBAttributeLength Integer 0x0000 – 0xffff The length, in octets, of the 7
attribute value being set 8
NIBAttributeValue Various Attribute Specific The value of the NIB attribute that 9
(see Table 3.41) should be written 10
11
13
This primitive is to be generated by the next higher layer and issued to its NLME 14
in order to write the value of an attribute in the NIB. 15
17
On receipt of this primitive the NLME attempts to write the given value to the 18
indicated NIB attribute in its database. If the NIBAttribute parameter specifies an 19
attribute that is not found in the database, the NLME issues the NLME- 20
SET.confirm primitive with a status of UNSUPPORTED_ATTRIBUTE. If the 21
NIBAttributeValue parameter specifies a value that is out of the valid range for the 22
given attribute, the NLME issues the NLME-SET.confirm primitive with a status 23
of INVALID_PARAMETER. 24
If the requested NIB attribute is successfully written, the NLME issues the 25
NLME-SET.confirm primitive with a status of SUCCESS. 26
27
3.3.11.4 NLME-SET.confirm 28
29
This primitive reports the results of an attempt to write a value to a NIB attribute. 30
32
34
NLME-SET.confirm {
35
Status, 36
NIBAttribute 37
} 38
39
40
41
42
43
44
45
Chapter 3

1
Table 3.31 NLME-SET.confirm Parameters
2
4
Status Enumeration SUCCESS, The result of the request to 5
INVALID_PARAMETER or write the NIB Attribute
UNSUPPORTED_ATTRIBUTE 6
7
NIBAttribute Integer See Table 3.41 The identifier of the NIB 8
attribute that was written
9
10
response to an NLME-SET.request primitive. This primitive returns a status of 13
either SUCCESS, indicating that the requested value was written to the indicated 14
NIB attribute, or an error code of INVALID_PARAMETER or 15
UNSUPPORTED_ATTRIBUTE. The reasons for these status values are fully 16
described in sub-clause 3.3.11.3.3. 17
18
20
21
request to write the value of a NIB attribute. If the requested value was written to
22
the indicated NIB attribute, the Status parameter will be set to SUCCESS.
23
Otherwise, the Status parameter indicates the error.
24
25
3.3.12 Route Error Reporting 26
27
The primitive described here enables the NWK layer to inform higher layers on a 28
particular device that a routing failure has occurred and, as a result, at least one 29
unicast or multicast frame sent or relayed by that device has not been delivered as 30
intended. Route errors for broadcast frames, that is, frames sent to one of the 31
broadcast addresses listed in Table 3.32, are not reported. 32
33
3.3.12.1 NLME-ROUTE-ERROR.indication 34
35
This primitive allows the next higher layer to be notified of the failure of a
36
communication path across the network.
37
38
39
40
41
42
43
44
45

1
NLME-ROUTE-ERROR.indication {
3
4
ShortAddr,
5
Status
6
} 7
8
Table 3.32 NLME-ROUTE-ERROR.indication Parameters 10
11
ShortAddr Integer 0x0000 – The 16-bit network address of the destination 13
0xFFF7 device associated with the routing failure 14
15
Status Status Any route error The error code associated with the routing failure
status code (see 16
Table 3.39) 17
18
19
20
This primitive is generated by the NWK layer on a device and passed to the next 21
higher layer when one of the following occurs: 22
23
• The device has failed to discover or repair a route to the destination given by
24
the ShortAddr parameter
25
• The NWK layer on that device has failed to deliver a frame to its end-device 26
child with the 16-bit network address given by the ShortAddr parameter, due to 27
one of the reasons given in Table 3.39 28
29
• The NWK layer has received a route error command frame destined for the
30
device. In this case, the values of the ShortAddr and Status parameters will
31
reflect the values of the destination address and error code fields of the
32
command frame.
33
35
The next higher layer is notified of a failure to communicate with the identified 36
device. 37
38
3.3.13 Route Discovery 39
40
This set of primitives defines how the next higher layer can initiate route 41
discovery of various kinds — specifically, unicast route discovery, multicast route 42
discovery and many-to-one route discovery — and be informed of the results. 43
44
45
Chapter 3
3.3.13.1 NLME-ROUTE-DISCOVERY.request
1
This primitive allows the next higher layer to initiate route discovery. 2
3
4
6
NLME-ROUTE-DISCOVERY.request { 7
DstAddrMode, 8
DstAddr, 9
Radius 10
} 11
12
14
Table 3.33 NLME-ROUTE-DISCOVERY.request Parameters
15
Valid 16
18
DstAddrMode Integer 0x00 – 0x02 A parameter specifying the kind of
destination address provided; The 19
DstAddrMode parameter may take one of the 20
following three values: 21
0x00 = No destination address 22
23
0x01 = 16-bit NWK address of a multicast
group 24
0x02 = 16-bit NWK address of an individual 25
device 26
27
DstAddr 16-bit Any NWK The destination of the route discovery.
NWK address or 28
Address multicast If the DstAddrMode parameter has a value of 29
address 0x00 then no DstAddr will be supplied. This 30
indicates that the route discovery will be a
many-to-one discovery with the device 31
issuing the discovery command as a target. 32
33
If the DstAddrMode parameter has a value of
0x01, indicating multicast route discovery 34
then the destination shall be the 16-bit NWK 35
address of a multicast group. 36
If the DstAddrMode parameter has a value of 37
0x02, this indicates unicast route discovery. 38
The DstAddr will be the 16-bit NWK address 39
of a device to be discovered. 40
Radius Integer 0x00 – 0xff This optional parameter describes the number 41
of hops that the route request will travel 42
through the network. 43
44
45

1
This primitive is generated by the next higher layer of a ZigBee coordinator or 2
router and issued to its NLME to request the initiation of route discovery. 3
5
On receipt of this primitive by the NLME of a ZigBee end device, the NLME 6
shall issue the NLME-ROUTE-DISCOVERY.confirm primitive to the next higher 7
layer with a Status value of INVALID_REQUEST. 8
On receipt of this primitive by the NLME with the DstAddrMode parameter not 9
equal to 0x00 and the DstAddr parameter equal to a broadcast address the NLME 10
shall issue the NLME-ROUTE-DISCOVERY.confirm primitive to the next higher 11
layer with a Status value of INVALID_REQUEST. 12
13
On receipt of this primitive by the NLME of a ZigBee router or ZigBee 14
coordinator with no routing capacity and with the DstAddrMode parameter equal 15
to 0x01 or 0x02, the NLME shall issue the NLME-ROUTE- 16
DISCOVERY.confirm to the next higher layer with a Status value of 17
NO_ROUTING_CAPACITY. 18
On receipt of this primitive on a ZigBee router or ZigBee coordinator that has 19
routing capacity, with the DstAddrMode parameter equal to 0x02, the NLME 20
shall initiate discovery of an unicast route between the current device and the 21
network device with the 16-bit NWK address given by the DstAddr parameter. 22
The procedure for initiating discovery of an unicast route is outlined in sub- 23
clause 3.7.3.4.1. 24
25
On receipt of this primitive on a ZigBee router or ZigBee coordinator that has 26
routing capacity, with the DstAddrMode parameter equal to 0x01, the NLME 27
shall first check to see if the device is a member of the multicast group identified 28
by the DstAddr parameter. That is, it will check if there is an entry in the 29
nwkGroupIDTable corresponding to the destination address. If the device is a 30
member of the multicast group, then the NLME will immediately issue the 31
NLME-ROUTE-DISCOVERY.confirm primitive with a status value of 32
SUCCESS and discontinue further processing of the NLME-ROUTE- 33
DISCOVERY.request primitive. If the device is not a member of the multicast 34
group, the NLME will initiate discovery of an unicast route between the current 35
device and the multicast group having the identified by the DstAddr parameter. 36
The procedure for initiating discovery of an unicast route is also outlined in sub- 37
clause 3.7.3.4.1. 38
On receipt of this primitive on a ZigBee router or ZigBee coordinator with the 39
DstAddrMode parameter equal to 0x00, the NLME shall initiate many-to-one 40
route discovery. The procedure for initiating many-to-one route discovery is 41
outlined in sub-clause 3.7.3.4.1. 42
43
44
45
Chapter 3
In each of the three cases of actual route discovery described above, the NLME
will initiate route discovery by attempting to transmit a route discovery command 1
frame using the MCPS-DATA.request primitive of the MAC sub-layer. If a value 2
has been supplied for the optional Radius parameter, that value will be placed in 3
the radius field of the NWK header of the outgoing frame. If a value has not been 4
supplied then the radius field of the NWK header will be set to twice the value of 5
the nwkMaxDepth attribute of the NWK IB as would be the case for data frame 6
transmissions. If the MAC sub-layer fails, for any reason, to transmit the route 7
request command frame, the NLME will issue the ROUTE-DISCOVERY.confirm 8
primitive to the next higher layer with a Status parameter value equal to that 9
returned by the MCPS-DATA.confirm. If the route discovery command frame is 10
sent successfully and if the DstAddrMode parameter has a value of 0x00, 11
indicating many-to-one route discovery, the NLME will immediately issue the 12
ROUTE-DISCOVERY.confirm primitive with a value of SUCCESS. Otherwise, 13
the NLME will wait until either a route reply command frame is received or else 14
the route discovery operation times out as described in sub-clause 3.7.3.4. If a 15
route reply command frame is received before the route discovery operation times 16
out, the NLME will issue the NLME-ROUTE-DISCOVERY.confirm primitive to 17
the next higher layer with a Status value of SUCCESS. If the operation times out, 18
it will issue the NLME_ROUTE-DISCOVERY.confirm primitive with a Status of 19
ROUTE_DISCOVERY_FAILED. 20
21
3.3.13.2 NLME-ROUTE-DISCOVERY.confirm 22
23
This primitive informs the next higher layer about the results of an attempt to 24
initiate route discovery. 25
27
29
NLME-ROUTE-DISCOVERY.confirm {
30
Status
31
} 32
33
Table 3.34 specifies the parameters for the NLME-ROUTE- 34
Table 3.34 NLME-ROUTE-DISCOVERY.confirm Parameters 36
37
Status Status Value INVALID_REQUEST, The status of an attempt to 39
NO_ROUTING_CAPACITY, initiate route discovery 40
ROUTE_DISCOVERY_FAILED 41
or any status value returned by the 42
MCPS-DATA.confirm primitive 43
44
45

1
This primitive is generated by the NLME and passed to the next higher layer as a 2
result of an attempt to initiate route discovery. 3
5
The next higher layer is informed of the status of its attempt to initiate route 6
discovery. Possible values for the Status parameter and the circumstances under 7
which they are generated are described in sub-clause 3.3.13.1.3. 8
9
10
3.4 Frame Formats 11
12
This sub-clause specifies the format of the NWK frame (NPDU). Each NWK 13
frame consists of the following basic components: 14
15
• A NWK header, which comprises frame control, addressing and sequencing
16
information
17
• A NWK payload, of variable length, which contains information specific to the 18
frame type 19
20
The frames in the NWK layer are described as a sequence of fields in a specific
21
order. All frame formats in this sub-clause are depicted in the order in which they
22
are transmitted by the MAC sub-layer, from left to right, where the left-most bit is
23
transmitted first in time. Bits within each field are numbered from 0 (left-most and
24
least significant) to k-1 (right-most and most significant), where the length of the
25
field is k bits. Fields that are longer than a single octet are sent to the MAC sub-
26
layer in the order from the octet containing the lowest numbered bits to the octet
27
containing the highest numbered bits.
28
29
3.4.1 General NPDU Frame Format 30
31
The NWK frame format is composed of a NWK header and a NWK payload. The 32
fields of the NWK header appear in a fixed order. However, the multicast control 33
field is present only if the multicast flag has the value 1. The NWK frame shall be 34
36
Octet Varia Varia 37
s: 2 2 2 1 1 0/8 0/8 0/1 ble ble
38
Frame Destinati Source Radius Sequenc Destinati Source Multicas Source Frame 39
control on address e on IEEE IEEE t control route payload
address number Address Address subfram 40
e 41
NWK Header Payload 42
43
Figure 3.5 General NWK Frame Format
44
45
Chapter 3
3.4.1.1 Frame Control Field

1
The frame control field is 16 bits in length and contains information defining the 2
frame type, addressing and sequencing fields and other control flags. The frame 3
control field shall be formatted as illustrated in Figure 3.6. 4
5
Bits: 6
0-1 2-5 6-7 8 9 10 11 12 13-15
7
Frame Protocol Discover Multicas Security Source Destinati Source Reserve 8
type version route t flag Route on IEEE IEEE d
Address Address 9
10
Figure 3.6 Frame Control Field 11
12
3.4.1.1.1 Frame Type Sub-field 13
14
The frame type sub-field is 2 bits in length and shall be set to one of the non- 15
reserved values listed in Table 3.35. 16
Table 3.35 Values of the Frame Type Sub-field 17
18
Frame Type Value 19
b1 b0 Frame Type Name
20
00 Data 21
01 NWK command 22
23
10 – 11 Reserved 24
25
3.4.1.1.2 Protocol Version Sub-field 26
27
The protocol version sub-field is 4 bits in length and shall be set to a number 28
reflecting the ZigBee NWK protocol version in use. The protocol version in use 29
on a particular device shall be made available as the value of the NWK constant 30
nwkcProtocolVersion. 31
3.4.1.1.3 Discover Route Sub-field 32
33
The discover route sub-field may be used to control route discovery operations for 34
the transit of this frame (see sub-clause 3.7.3.4). 35
Table 3.36 Values of the Discover Route Sub-field 36
37
Discover Route Field Value Field Meaning 38
0x00 Suppress route discovery 39
40
0x01 Enable route discovery
41
0x02 Force route discovery 42
0x03 Reserved 43
44
45
For NWK layer command frames, the discover route sub-field shall be set to 0x00
indicating suppression of route discovery. 1
2
3.4.1.1.4 Multicast Flag Sub-field 3
The multicast flag sub-field is 1 bit in length and has the value 0 if the frame is a 4
unicast or broadcast frame and the value 1 if it is a multicast frame. 5
6
3.4.1.1.5 Security Sub-field 7
The security sub-field shall have a value of 1, if and only if, the frame is to have 8
NWK security operations enabled. If security for this frame is implemented at 9
another layer or disabled entirely, it shall have a value of 0. 10
11
3.4.1.1.6 Source Route Sub-field 12
13
The source route sub-field shall have a value of 1 if and only if a source route
14
subframe is present in the NWK header. If the source route subframe is not
15
present the source route sub-field shall have a value of 0.
16
3.4.1.1.7 Destination IEEE Address Sub-field 17
18
The Destination IEEE address shall have a value of 1, if and only if the network 19
header is to include the full IEEE address of the destination. 20
3.4.1.1.8 Source IEEE Address Sub-field 21
22
The Source IEEE address shall have a value of 1, if and only if the network header 23
is to include the full IEEE address of the source device. 24
25
3.4.1.2 Destination Address Field 26
The destination address field shall always be present and shall be 2 octets in 27
length. If the multicast flag sub-field of the frame control field has the value 0, the 28
destination address field shall hold the 16-bit network address of the destination 29
device or a broadcast address (see Table ). If the multicast flag sub-field has the 30
value 1, the destination address field shall hold the 16-bit Group ID of the 31
destination multicast group. Note that the network address of a device shall 32
always be the same as its IEEE 802.15.4-2003 MAC short address. 33
34
3.4.1.3 Source Address Field 35
36
The source address field shall always be present. It will always be 2 octets in 37
length and shall hold the network address of the source device of the frame. Note 38
that the network address of a device shall always be the same as its IEEE 39
802.15.4-2003 MAC short address. 40
41
42
43
44
45
Chapter 3
3.4.1.4 Radius Field

1
The radius field shall always be present. It will be 1 octet in length and specifies 2
the range of a radius transmission. The field shall be decremented by 1 by each 3
receiving device. 4
5
3.4.1.5 Sequence Number Field 6
7
The sequence number field is present in every frame and is 1 octet in length. The 8
sequence number value will be incremented by 1 with each new transmitted 9
frame. The values of the source address and sequence number fields of a frame, 10
taken as a pair, may be used to uniquely identify a frame within the constraints 11
imposed by the sequence number's 1-octet range. For more details on the use of 12
the sequence number field, see sub-clause 3.7.2. 13
14
3.4.1.6 Destination IEEE Address Field 15
The destination IEEE address field is present if the corresponding sub-field in the 16
frame control field is set and, if present, contains the 64-bit IEEE address of the 17
eventual destination of the frame. 18
19
3.4.1.7 Source IEEE Address Field 20
21
The source IEEE address field is present if the corresponding sub-field in the 22
frame control field is set and, if present, contains the 64-bit IEEE address of the 23
source of the frame. 24
25
3.4.1.8 Multicast Control Field 26
The multicast control sub-field is 1 octet in length and is only present if the 27
multicast flag sub-field has value 1. It is divided into three sub-fields as illustrated 28
in Figure 3.7. 29
30
Bits: 0 – 1 2–4 5–7 31
32
Multicast mode NonmemberRadius MaxNonmemberRadius
33
34
35
Figure 3.7 Multicast Control Field Format 36
37
3.4.1.8.1 Multicast Mode Sub-field 38
The multicast mode sub-field indicates whether the frame is to be transmitted 39
using member or non-member mode. Member mode is used to propagate 40
multicasts between the devices that are members of the destination group. Non- 41
42
43
44
45
member mode is used to transmit a multicast frame from a device that is not a
member of the multicast group to a device that is part of the multicast group. 1
2
Table 3.37 Values of the Multicast Mode Sub-field
3
Multicast Mode Field 4
Value: b0 b1 Field Meaning 5
6
00 Non-member mode
7
01 Member mode 8
10 Reserved 9
10
11 Reserved
11
12
3.4.1.8.2 NonmemberRadius Sub-field 13
The NonmemberRadius field indicates the range of a member mode multicast 14
when relayed by devices that are not members of the destination group. Receiving 15
devices that are members of the destination group will set this field to the value of 16
the MaxNonmemberRadius field. Receiving devices that are not members of the 17
destination group will discard the frame if the NonmemberRadius field has value 18
0 and will decrement the field if the NonmemberRadius field has a value in the 19
range 0x01 through 0x06. A value of 0x07 indicates an infinite range and is not 20
decremented. 21
22
3.4.1.8.3 MaxNonmemberRadius Sub-field 23
24
The maximum value of the NonmemberRadius field for this frame.
25
26
3.4.1.9 Source Route Subframe Field
27
The source route subframe field is only present if the source route sub-field of the 28
frame control field has a value of 1. It is divided into three sub-fields as illustrated 29
in Figure 3.8. 30
31
Octets: 1 1 Variable 32
Relay count Relay Relay list 33
index 34
35
36
Figure 3.8 Source Route Subframe Format
37
38
3.4.1.9.1 Relay Count Sub-field
39
The relay count sub-field indicates the number of relays contained in the relay list 40
sub-field of the source route subframe. 41
42
43
44
45
Chapter 3
3.4.1.9.2 Relay Index

1
The relay index sub-field indicates the index of the next relay in the relay list sub- 2
field to which the packet will be transmitted. This field is initialized to 0 by the 3
originator of the packet, and is incremented by 1 by each receiving relay. 4
3.4.1.9.3 Relay List Sub-field 5
6
The relay list sub-field is a list of the 2-byte short addresses of the nodes to be 7
used as relays for the purpose of source routing the packet. Addresses are 8
formatted least significant byte first, and appear in the order they are used in the 9
source route. 10
11
3.4.1.10 Frame Payload Field 12
13
The frame payload field has a variable length and contains information specific to
14
individual frame types.
15
16
3.4.2 Format of Individual Frame Types 17
18
There are two defined NWK frame types: data and NWK command. Each of these 19
frame types is discussed in the following sub-clauses. 20
21
3.4.2.1 Data Frame Format 22
23
The data frame shall be formatted as illustrated in Figure 3.9. 24
Octets: 2 Variable Variable 25
26
Frame control Routing fields Data payload 27
NWK header NWK payload 28
29
Figure 3.9 Data Frame Format 30
31
The order of the fields of the data frame shall conform to the order of the general 32
NWK frame format as illustrated in Figure 3.5. 33
3.4.2.1.1 Data Frame Nwk Header Field 34
35
The NWK header field of a data frame shall contain the frame control field and an 36
appropriate combination of routing fields as required. 37
indicates a data frame, as shown in Table 3.35. All other sub-fields shall be set 39
according to the intended use of the data frame. 40
41
The routing fields shall contain an appropriate combination of address and 42
broadcast fields, depending on the settings in the frame control field (see 43
Figure 3.6). 44
45
3.4.2.1.2 Data Payload Field

1
The data payload field of a data frame shall contain the sequence of octets, which 2
the next higher layer has requested the NWK layer to transmit. 3
4
3.4.2.2 NWK Command Frame Format 5
The NWK command frame shall be formatted as illustrated in Figure 3.10. 6
7
Octets: 2 Variable 1 Variable 8
9
Frame control Routing fields NWK command NWK command 10
identifier payload
11
NWK header NWK payload 12
13
Figure 3.10 NWK Command Frame Format
14
The order of the fields of the NWK command frame shall conform to the order of 15
the general NWK frame as illustrated in Figure 3.5. 16
17
3.4.2.2.1 NWK Command Frame NWK Header Field 18
19
The NWK header field of a NWK command frame shall contain the frame control
20
field and an appropriate combination of routing fields as required.
21
indicates a NWK command frame, as shown in Table 3.35. All other sub-fields 23
shall be set according to the intended use of the NWK command frame. 24
25
The routing fields shall contain an appropriate combination of address and
26
broadcast fields, depending on the settings in the frame control field.
27
3.4.2.2.2 NWK Command Identifier Field 28
29
The NWK command identifier field indicates the NWK command being used.
30
This field shall be set to one of the non-reserved values listed in Table 3.38.
31
3.4.2.2.3 NWK Command Payload Field 32
33
The NWK command payload field of a NWK command frame shall contain the 34
NWK command itself. 35
36
37
38
39
40
41
42
43
44
45
Chapter 3
3.5 Command Frames 1

2
The command frames defined by the NWK layer are listed in Table 3.38. The 3
following sub-clauses detail how the NLME shall construct the individual 4
commands for transmission. 5
Table 3.38 NWK Command Frames 6
7
Command Frame Identifier Command Name Reference 8
0x01 Route request 3.5.1 9
10
0x02 Route reply 3.5.2
11
0x03 Route Error 3.5.3 12
0x04 Leave 3.5.4 13
14
0x05 Route Record 3.5.5
15
0x06 Rejoin request 3.5.6 16
0x07 Rejoin response 3.5.7 17
18
0x00, 0x08 – 0xff Reserved — 19
20
3.5.1 Route Request Command 21
22
The route request command allows a device to request that other devices within 23
radio range engage in a search for a particular destination device and establish a 24
state within the network that will allow messages to be routed to that destination 25
more easily and economically in the future. The payload of a route request 26
command shall be formatted as illustrated in Figure 3.11. 27
28
Octets: 1 1 1 2 1 29
30
Command frame Command Route Destination Path cost 31
identifier options request address
(see Table 3.38) identifier 32
33
NWK payload 34
Figure 3.11 Route Request Command Frame Format 35
36
3.5.1.1 MAC Data Service Requirements 37
38
In order to transmit this command using the MAC data service, specified in IEEE 39
802.15.4-2003 [B1], the following information shall be included in the MAC 40
frame header: 41
42
• The destination PAN identifier shall be set to the PAN identifier of the device
43
sending the route request command
44
45
• The destination address must be set to the broadcast address of 0xffff

1
• The source MAC address and PAN identifier shall be set to the address and 2
PAN identifier of the device sending the route request command, which may or 3
may not be the device from which the command originated 4
• The frame control field shall be set to specify that the frame is a MAC data 5
frame with MAC security disabled, since any secured frame originating from 6
the NWK layer shall use NWK layer security; Because the frame is broadcast, 7
no acknowledgment request shall be specified 8
9
• The addressing mode and intra-PAN flags shall be set to support the addressing 10
fields described here 11
12
3.5.1.2 NWK Header Fields 13
In order to send the route request command frame, the source address field in the 14
NWK header shall be set to the address of the originating device. 15
16
The destination address in the NWK header shall be set to the router-only 17
broadcast address (see Table 3.50). 18
19
3.5.1.3 NWK Payload Fields 20
The NWK frame payload contains a command identifier field, a command options 21
field, the route request identifier field, the address of the intended destination, and 22
an up-to-date summation of the path cost. 23
24
The command frame identify shall contain the value indicating a route request 25
command frame. 26
3.5.1.3.1 Command Options Field 27
28
The format of the 8-bit command options field is shown in Figure 3.12. 29
30
Bit: 0-5 6 7 31
32
Reserved Multicast Route repair 33
Figure 3.12 Route Request Command Options Field 34
35
3.5.1.3.1.1 The Multicast Sub-field 36
37
The multicast sub-field is a single-bit field. It shall have a value of 1, if and only 38
if, the command frame is a request for a route to a multicast group, in which case 39
the destination address field contains the Group ID of the desired group. 40
41
42
43
44
45
Chapter 3
3.5.1.3.1.2 The Route Repair Sub-field

1
The route repair sub-field is a single-bit field. It shall have a value of 1 if and only 2
if the route request command frame is being generated as part of a route repair 3
operation for mesh network topology (see sub-clause 3.7.3.6.1). 4
3.5.1.3.2 Route Request Identifier 5
6
The route request identifier is an 8-bit sequence number for route requests and is 7
incremented by 1 every time the NWK layer on a particular device issues a route 8
request. 9
3.5.1.3.3 Destination Address 10
11
The destination address shall be 2 octets in length and represents the intended 12
destination of the route request command frame. 13
14
3.5.1.3.4 Path Cost
15
The path cost field is 8 bits in length and is used to accumulate routing cost 16
information as a route request command frame moves through the network (see 17
sub-clause 3.7.3.4.2). 18
19
20
3.5.2 Route Reply Command 21
22
The route reply command allows the specified destination device of a route 23
request command to inform the originator of the route request that the request has 24
been received. It also allows ZigBee routers along the path taken by the route 25
request to establish state information that will enable frames sent from the source 26
device to the destination device to travel more efficiently. The payload of the route 27
reply command shall be formatted as illustrated in Figure 3.13. 28
Octets: 1 1 1 2 2 1 29
30
Command frame Command Route Originator Responder Path cost 31
identifier options request address address 32
(see Table 3.38) identifier
33
NWK payload 34
35
Figure 3.13 Route Reply Command Format
36
37
3.5.2.1 MAC Data Service Requirements
38
802.15.4-2003 [B1], the following information shall be included in the MAC 40
frame header. 41
42
The destination MAC address and PAN identifier shall be set to the network 43
address and PAN identifier, respectively, of the first hop in the path back to the 44
45
originator of the corresponding route request command frame. The destination

PAN identifier shall be the same as the PAN identifier of the originator. 1
2
The source MAC address and PAN identifier shall be set to the address and PAN 3
identifier of the device sending the route reply command, which may or may not 4
be the device from which the command originated. 5
The frame control field shall be set to specify that the frame is a MAC data frame 6
with MAC security disabled, since any secured frame originating from the NWK 7
layer shall use NWK layer security. The transmission options shall be set to 8
require acknowledgment. The addressing mode and intra-PAN flags shall be set to 9
support the addressing fields described here. 10
11
13
In order for this route reply to reach its destination and for the route discovery 14
process to complete correctly, the following information must be provided: 15
• The frame type sub-field of the NWK frame control field should be set to 16
indicate that this frame is a NWK layer command frame. 17
18
• The destination address field in the NWK header shall be set to the network 19
address of the first hop in the path back to the originator of the corresponding 20
route request. 21
• The source address in the NWK header shall be set to the NWK 16-bit network 22
address of the device that is transmitting the frame. 23
24
26
The NWK frame payload contains a command identifier field, a command options 27
field, the route request identifier, originator and responder addresses and an up-to- 28
date summation of the path cost. 29
The command frame identifier shall contain the value indicating a route reply 30
command frame. 31
32
34
The format of the 8-bit command options field is shown in Figure 3.14.
35
Bit: 0 – 5 6 7 36
37
Reserved Multicast Route repair 38
Figure 3.14 Route Reply Command Options Field 39
40
3.5.2.3.1.1 Multicast Sub-field 41
42
The multicast sub-field is a single bit field. It shall have a value of 1 if and only if 43
the command frame is a reply to a request for a route to a multicast group, in 44
45
Chapter 3
which case the responder address field contains the Group ID of the desired
group. 1
2
3.5.2.3.1.2 Route Repair Sub-field 3
4
The route repair sub-field is a single-bit field. It shall have a value of 1 if and only 5
if the route reply command frame is being generated as part of a route repair 6
operation for mesh network topology (see sub-clause 3.7.3.6.1). 7
3.5.2.3.2 Route Request Identifier 8
9
The route request identifier is the 8-bit sequence number of the route request to 10
which this frame is a reply. 11
12
3.5.2.3.3 Originator Address
13
The originator address field shall be 2 octets in length and shall contain the 16-bit 14
network address of the originator of the route request command frame to which 15
this frame is a reply. 16
17
3.5.2.3.4 Responder Address 18
The responder address field shall be 2 octets in length and shall always be the 19
same as the value in the destination address field of the corresponding route 20
request command frame. 21
22
3.5.2.3.5 Path Cost 23
The path cost field is used to sum link cost as the route reply command frame 24
transits the network (see sub-clause 3.7.3.4.3). 25
26
27
3.5.3 Route Error Command 28
29
A device uses the route error command when it is unable to forward a data frame. 30
The command notifies the source device of the data frame about the failure in 31
forwarding the frame. The payload of a route error command shall be formatted as 32
34
Octets: 1 1 2
35
Command frame Error code Destination 36
identifier address 37
(see Table 3.38) 38
Figure 3.15 Route Error Command Frame Format 39
40
42
802.15.4-2003 [B1], the following information shall be provided: 44
45
• The destination MAC address and PAN identifier shall be set to the address and
PAN identifier, respectively, of the first hop in the path back to the source of 1
the data frame that encountered a forwarding failure. 2
3
PAN identifier of the device sending the route error command. 5
the NWK layer shall use NWK layer security. The implementer shall determine 8
whether an acknowledgment shall be requested. 9
10
fields described here. 12
13
In order to send the route error command frame, the destination address field in 15
the NWK header shall be set to the same value as the source address field of the 16
data frame that encountered a forwarding failure. 17
18
The source address in the NWK header shall be set to the address of the device 19
sending the route error command. 20
21
The NWK frame payload of the route error command frame contains a command 23
frame identifier field, an error code field and a destination address field as 24
described below. The command frame identifier shall be set so as to specify the 25
route error command frame as defined in Table 3.38. 26
27
3.5.3.3.1 Error Code 28
29
The error code shall be set to one of the non-reserved values shown in Table 3.39.
30
Table 3.39 Error Codes for Route Error Command Frame 31
Value Error Code 32
33
0x00 No route available 34
0x01 Tree link failure 35
36
0x02 Non-tree link failure
37
0x03 Low battery level 38
0x04 No routing capacity 39
40
0x05 No Indirect Capacity 41
0x06 Indirect Transaction Expiry 42
43
0x07 Target Device Unavailable
44
45
Chapter 3
Table 3.39 Error Codes for Route Error Command Frame (Continued)
1
Value Error Code 2
0x08 Target Address Unallocated 3
4
0x09 Parent Link Failure
5
0x0a Validate route 6
0x0b Source route failure 7
8
0x0c Many-to-one route failure 9
0x0d – 0xff Reserved 10
11
These error codes are used both as values for the error code field of a route error 12
command frame and as values of the Status parameter of the NLME-ROUTE- 13
ERROR.indication primitive. A brief explanation of each follows: 14
15
• No route available: Route discovery and/or repair has been attempted and no 16
route to the intended destination address has been discovered. 17
• Tree link failure: The routing failure occurred as a result of the failure of an 18
attempt to route the frame along the tree. 19
20
• Non-tree link failure: The failure did not occur as a result of an attempt to 21
route along the tree. 22
• Low battery level: The frame was not relayed because the relaying device was 23
running low on battery power. 24
25
• No routing capacity: The failure occurred because the relaying device has no 26
routing capacity. 27
• No indirect capacity: The failure occurred as the result of an attempt to buffer 28
a frame for a sleeping end device child and the relaying device had no buffer 29
capacity to use. 30
31
• Indirect transaction expiry: A frame that was buffered on behalf of a sleeping 32
end device child has been dropped as a result of a time-out. 33
• Target device unavailable: An end device child of the relaying device is, for 34
some reason, unavailable. 35
36
• Target address unallocated: The frame was addressed to a non-existent end 37
device child of the relaying device. 38
• Parent link failure: The failure occurred as a result of a failure in the RF link 39
to the device’s parent. 40
41
• Validate route: The multicast route identified in the destination address field 42
should be validated. 43
44
45
• Source route failure: Source routing has failed, probably indicating a link
failure in one of the source route’s links. 1
2
• Many-to-one route failure: A route established as a result of a many-to-one 3
route request has failed. 4
3.5.3.3.2 Destination Address 5
6
The destination address is 2 octets in length and shall contain the destination 7
address from the data frame that encountered the forwarding failure. 8
9
3.5.4 Leave Command 10
11
The leave command is used by the NLME to inform other devices on the network 12
that a device is leaving the network or else to request that a device leave the 13
network. The payload of the leave command shall be formatted as shown in 14
Figure 3.16 15
16
Octets: 1 1 17
18
Command frame identifier Command options
(see Table 3.38)
19
20
Figure 3.16 Leave Command Frame Format 21
22
3.5.4.1 MAC Data Service Requirement 23
24
• The destination MAC address and PAN identifier shall be set to the address and 27
PAN identifier, respectively, of the neighbor device to which the frame is being 28
sent. 29
30
PAN identifier of the device sending the leave command. 32
the NWK layer shall use NWK layer security. Acknowledgment shall be 35
requested. 36
37
40
In order to send a leave command frame, if the request subfield is set to 1 then the 42
destination address field in the NWK header shall be set to the network address of 43
44
45
Chapter 3
the child device being requested to leave, the destination IEEE address sub-field
of the frame control field shall be set to 1, and the destination IEEE address field 1
shall be set to the IEEE address of the device being requested to leave. If the 2
request subfield is set to 0 then the destination address field in the NWK header 3
shall be set to 0xFFFC so that the indication is received by all ZigBee Routers, the 4
source IEEE address sub-field of the frame control field shall be set to 1, and the 5
source IEEE address field shall be set to the IEEE address of the device leaving 6
the network. The radius field in the NWK header shall be set to 1. 7
8
10
The NWK payload of the leave command frame contains a command frame 11
identifier field and a command options field. The command frame identifier field 12
shall be set to specify the leave command frame as described in Table 3.38. 13
15
The format of the 8-bit command options field is shown in Figure 3.17. 16
17
Bit: 0 – 4 5 6 7 18
Reserved Rejoin Request Remove children 19
20
Figure 3.17 Leave Command Options Field 21
22
3.5.4.3.1.1 Rejoin Sub-field 23
The Rejoin sub-field is a single-bit field located at bit 5. If the value of this sub- 24
field is 1, the device that is leaving from its current parent will rejoin the network. 25
If the value of this sub-field is 0, the device will not join the network again. 26
27
3.5.4.3.1.2 Request Sub-field 28
29
The request sub-field is a single bit field located at bit 6. If the value of this sub- 30
field is 1 then the leave command frame is a request for another device to leave 31
the network. If the value of this sub-field is 0 then the leave command frame is an 32
indication that the sending device plans to leave the network. 33
34
3.5.4.3.1.3 Remove Children Sub-field 35
36
The remove children sub-field is a single bit field located at bit 7. If this sub-field 37
has a value of 1 then the children of the device that is leaving the network will also 38
be removed. 39
40
41
42
43
44
45
3.5.5 Route Record Command 1

2
The route record command allows the route taken by a unicast packet through the
3
network to be recorded in the command payload and delivered to the destination
4
device. The payload of the route record command shall be formatted as illustrated
5
in Figure 3.18.
6
Octets: 1 1 Variable 7
8
Command frame Relay count Relay list 9
identifier
(see Table 3.38)
10
11
NWK Payload 12
Figure 3.18 Route Record Command Format 13
14
16
19
• The destination MAC address and PAN identifier shall be set to the address
20
and PAN identifier, respectively, of the neighbor device to which the frame is
21
being sent.
22
PAN identifier of the device sending the route record command. 24
25
• The frame control field shall be set to specify that the frame is a MAC data
26
frame with MAC security disabled, since any secured frame originating from
27
the NWK layer shall use NWK layer security. Acknowledgment shall be
28
requested.
29
32
34
The frame type sub-field of the NWK frame control field shall be set to indicate 35
that this frame is a NWK command frame. The source and destination address 36
fields in the NWK header shall be set to the address of the originating and 37
destination devices, respectively. The source route sub-field of the frame control 38
field shall be set to 0. 39
40
41
42
43
44
45
Chapter 3
3.5.5.3 NWK Payload

1
The NWK frame payload contains a command identifier field, a relay count field, 2
and a relay list field. The command frame identifier shall contain the value 3
indicating a route record command frame. 4
5
3.5.5.3.1 Relay Count Field
6
This 1-byte field contains the number of relays in the relay list field of the route 7
record command. It is initialized to 0 by the originator and is incremented by each 8
receiving relay. 9
10
3.5.5.3.2 Relay List Field 11
The relay list field is a list of the 2-byte short addresses of the nodes that have 12
relayed the packet. Addresses are formatted least significant byte first. Receiving 13
relay nodes append their short address to the list before forwarding the packet. 14
15
16
3.5.6 Rejoin Request Command 17
18
The rejoin request command allows a device to rejoin its network. This is 19
normally done in response to a communication failure, such as when an end 20
device can no longer communicate with its original parent. 21
Octets:1 1 22
23
Command frame identifier Capability 24
(see Table 3.38) Information 25
NWK payload 26
27
Figure 3.19 Rejoin Request Command Frame Format 28
29
In order to transmit this command using the MAC data service, specified in [B1], 31
the following information shall be provided: 32
33
• The destination address and PAN identifier shall be set to the short address and 34
PAN identifier, respectively, of the prospective parent. 35
• The source MAC address shall be set to the previous short address and PAN 36
identifier of the device transmitting the rejoin command frame. 37
38
• The transmission options shall be set to require acknowledgement. 39
42
43
44
45
3.5.6.2 NWK Header Fields

1
When sending the rejoin request command frame, the NLME shall set the source 2
address field of the NWK header to the previous short address of the device 3
transmitting the frame, the source IEEE address sub-field of the frame control 4
field shall be set to 1, and the source IEEE address field shall be set to the IEEE 5
address of the device issuing the request. The radius field shall be set to 1. 6
7
9
The NWK frame payload contains a command identifier field and a capability 10
information field. The command frame identifier shall contain the value 11
indicating a rejoin request command frame. 12
3.5.6.3.1 Capability Information Field 13
14
This one-byte field has the format of the capability information field in the 15
association request command in [B1], which is also described in Table 3.17. 16
17
3.5.7 Rejoin Response Command 18
19
The rejoin response command is sent by a device to inform a child of its short 20
address and rejoin status.. 21
22
Octets:1 2 1 23
Command frame Short address Rejoin status
24
identifier 25
(see Table 3.38) 26
27
NWK payload
28
Figure 3.20 Rejoin Response Command Frame Format 29
30
32
In order to transmit this command using the MAC data service, specified in [B1], 33
the following information shall be provided: 34
• The destination MAC address and PAN identifier shall be set to the previous 35
network address and PAN identifier, respectively, of the device requesting to 36
rejoin the network. 37
38
• The source MAC address and PAN identifier shall be set to the network 39
address and PAN identifier of the device that received and processed the rejoin 40
request command frame. 41
• Acknowledgment shall be requested. 42
43
44
45
Chapter 3
• The addressing mode and intra-PAN flags shall be set to support the addressing
fields described here. The TXOptions will request 'indirect transmission' to be 1
used if the 'Receiver on when idle' bit of the 'Capability Information' byte 2
contained in the rejoin request command is equal to 0x00. Otherwise 'direct 3
transmission' will be used. 4
5
7
When sending the rejoin response command frame, the NLME shall set the 8
destination address field of the NWK header to the previous short address of the 9
rejoining device. Both the destination IEEE address sub-field and the source IEEE 10
address sub-fields of the frame control field shall be set to 1. The destination IEEE 11
address field shall be set to the IEEE address of the rejoining device and the 12
source IEEE address field shall be set to the IEEE address of the parent. 13
14
The NWK frame payload contains a command identifier field, a short address 16
field, and a rejoin status field. The command frame identifier shall contain the 17
value indicating a rejoin response command frame. 18
19
3.5.7.3.1 Short Address Field 20
21
If the rejoin was successful this two-byte field contains the new short address
22
assigned to the rejoining device. If the rejoin was not successful this contains the
23
broadcast address (0xfffd).
24
3.5.7.3.2 Rejoin Status Field 25
26
This one-byte field shall contain one of the nonreserved association status values 27
specified in [B1]. 28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
3.6 Constants and NIB Attributes 1

2
3.6.1 NWK Constants 3
4
The constants that define the characteristics of the NWK layer are presented in 5
Table 3.40. 6
7
Table 3.40 NWK Layer Constants 8
10
nwkcCoordinatorCapable A Boolean flag indicating whether the device Set at build time 11
is capable of becoming the ZigBee 12
coordinator; A value of 0x00 indicates that
the device is not capable of becoming a 13
coordinator while a value of 0x01 indicates 14
that the device is capable of becoming a 15
coordinator 16
nwkcDefaultSecurityLevel The default security level to be used (see ENC-MIC-64 17
Chapter 4) 18
nwkcDiscoveryRetryLimit The maximum number of times a route 0x03 19
discovery will be retried 20
21
nwkcMaxDepth The maximum depth (minimum number of 0x0f
logical hops from the ZigBee coordinator) a
22
device can have 23
24
nwkcMinHeaderOverhead The minimum number of octets added by the 0x08
25
NWK layer to a NSDU
26
nwkcProtocolVersion The version of the ZigBee NWK protocol in 0x02 27
the device
28
nwkcWaitBeforeValidation Time duration in milliseconds, on the 0x500 29
originator of a multicast route request, 30
between receiving a route reply and sending a 31
message to validate the route
32
nwkcRepairThreshold Maximum number of allowed communication 0x03 33
errors after which the route repair mechanism 34
is initiated
35
nwkcRouteDiscoveryTime Time duration in milliseconds until a route 0x2710 36
discovery expires 37
nwkcMaxBroadcastJitter The maximum broadcast jitter time measured 0x40 38
in milliseconds. 39
nwkcInitialRREQRetries The number of times the first broadcast 0x03 40
transmission of a route request command 41
frame is retried 42
43
44
45
Chapter 3
Table 3.40 NWK Layer Constants (Continued)

1
nwkcRREQRetries The number of times the broadcast 0x02 3
transmission of a route request command 4
frame is retried on relay by an intermediate 5
ZigBee router or ZigBee coordinator 6
nwkcRREQRetryInterval The number of milliseconds between retries 0xfe 7
of a broadcast route request command frame 8
nwkcMinRREQJitter The minimum jitter, in 2 millisecond slots, for 0x01 9
broadcast retransmission of a route request 10
command frame 11
nwkcMaxRREQJitter The maximum jitter, in 2 millisecond slots, 0x40 12
for broadcast retransmission of a route 13
request command frame 14
15
16
3.6.2 NWK Information Base 17
18
The NWK information base (NIB) comprises the attributes required to manage the 19
NWK layer of a device. Each of these attributes can be read or written using the 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
NLME-GET.request and NLME-SET.request primitives, respectively. The

attributes of the NIB are presented in Table 3.41. 1
2
Table 3.41 NWK IB Attributes
3
Attribute Id Type Range Description Default 4
5
nwkSequenceNumber 0x81 Integer 0x00 – 0xff A sequence Random value 6
number used to from within the
identify outgoing range 7
frames (see sub- 8
clause 3.7.2) 9
nwkPassiveAckTimeout 0x82 Integer 0x00 – 0x0a The maximum 0x03 10
time duration in 11
seconds allowed 12
for the parent 13
and all child 14
devices to
retransmit a 15
broadcast 16
message (passive 17
acknowledgment 18
time-out) 19
nwkMaxBroadcastRetries 0x83 Integer 0x00 – 0x5 The maximum 0x03 20
number of retries 21
allowed after a 22
broadcast
transmission 23
failure 24
25
nwkMaxChildren 0x84 Integer 0x00 – 0xff The number of 0x07
children a device
26
is allowed to 27
have on its 28
current network 29
nwkMaxDepth 0x85 Integer 0x01 – The depth a 0x05 30
nwkcMax device can have 31
Depth 32
nwkMaxRouters 0x86 Integer 0x01-0xff The number of 0x05 33
routers any one 34
device is allowed 35
to have as 36
children; This
37
value is
determined by 38
the ZigBee 39
coordinator for 40
all devices in the 41
network
42
43
44
45
Chapter 3
Table 3.41 NWK IB Attributes (Continued)

1
nwkNeighborTable 0x87 Set Variable The current set Null set 3
of neighbor table 4
entries in the 5
device (see 6
Table 3.43)
7
nwkNetworkBroadcastDel 0x88 Integer (nwkPassiv Time duration in nwkPassiveAck 8
iveryTime eAckTimeo seconds that a Timeout * 9
uT* broadcast nwkBroadcastR
10
nwkBroadc message needs to etries
astRetries0 encompass the 11
– 0xff entire network 12
13
nwkReportConstantCost 0x89 Integer 0x00-0x01 If this is set to 0, 0x00
the NWK layer 14
shall calculate 15
link cost from all 16
neighbor nodes 17
using the LQI
18
values reported
by the MAC 19
layer; Otherwise, 20
it shall report a 21
constant value 22
nwkRouteDiscoveryRetries 0x8a Integer 0x00-x03 The number of nwkcDiscovery 23
Permitted retries allowed RetryLimit 24
after an 25
unsuccessful 26
route request
27
nwkRouteTable 0x8b Set Variable The current set Null set 28
of routing table 29
entries in the
device (see 30
Table 3.46) 31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

1
nwkSymLink 0x8e Boolea TRUE or The current route FALSE 3
n FALSE symmetry 4
setting: 5
TRUE means 6
that routes are 7
considers to be 8
comprised of 9
symmetric links.
Backward and
10
forward routes 11
are created 12
during one-route 13
discovery and 14
they are
identical.
15
16
FALSE indicates 17
that routes are
not consider to
18
be comprised of 19
symmetric links. 20
Only the forward 21
route is stored 22
during route
discovery
23
24
nwkCapabilityInformation 0x8f Bit See This field shall 0x00 25
vector Table 3.17 contain the
26
capability device
capability 27
information 28
established at 29
network joining 30
time.
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Chapter 3

1
nwkUseTreeAddrAlloc 0x90 Boolea TRUE or A flag that TRUE 3
n FALSE determines 4
whether the 5
NWK layer 6
should use the
default
7
distributed 8
address 9
allocation 10
scheme or allow 11
the next higher
layer to define a
12
block of 13
addresses for the 14
NWK layer to 15
allocate to its 16
children:
17
TRUE = use 18
distributed 19
address
allocation.
20
21
FALSE = allow 22
the next higher
layer to define
23
address 24
allocation. 25
26
nwkUseTreeRouting 0x91 Boolea TRUE or A flag that TRUE
n FALSE determines 27
whether the 28
NWK layer 29
should assume 30
the ability to use
31
hierarchical
routing: 32
33
TRUE = assume
34
the ability to use
hierarchical 35
routing. 36
37
FALSE = never
use hierarchical 38
routing. 39
40
41
42
43
44
45

1
nwkNextAddress 0x92 Integer 0x0000 - The next 0x0000 3
0xfffd network address 4
that will be 5
assigned to a 6
device
requesting
7
association. This 8
value shall be 9
incremented by 10
nwkAddressIncr 11
ement every time
an address is
12
assigned. 13
14
nwkAvailableAddresses 0x93 Integer 0x0000 - The size of 0x0000
15
0xfffd remaining block
of addresses to 16
be assigned. This 17
value will be 18
decremented by 19
1 every time an
20
address is
assigned. When 21
this attribute has 22
a value of 0, no 23
more 24
associations may
25
be accepted.
26
nwkAddressIncrement 0x94 Integer 0x0000 - The amount by 0x0001 27
0xfffd which
28
nwkNextAddress
is incremented 29
each time an 30
address is 31
assigned. 32
33
34
35
36
37
38
39
40
41
42
43
44
45
Chapter 3

1
nwkTransactionPersistenc 0x95 Integer 0x0000 - The maximum 0x01f4 3
eTime 0xffff time (in 4
superframe 5
periods) that a 6
transaction is
stored by a
7
coordinator and 8
indicated in its 9
beacon. This 10
attribute reflects 11
the value of the
MAC PIB
12
attribute 13
macTransaction 14
PersistenceTime 15
(see [B1]) and 16
any changes
made by the
17
higher layer will 18
be reflected in 19
the MAC PIB 20
attribute value as 21
well.
22
nwkShortAddress 0x96 Integer 0x0000 - The 16-bit 0xffff 23
0xffff address that the 24
device uses to
25
communicate
with the PAN. 26
This attribute 27
reflects the value 28
of the MAC PIB 29
attribute
30
macShortAd
dress (see 31
[B1]) and any 32
changes made by 33
the higher layer 34
will be reflected
35
in the MAC PIB
attribute value as 36
well. 37
38
nwkStackProfile 0x97 Integer 0x00-0x0f The identifier of 0
the ZigBee stack 39
profile in use for 40
this device. 41
42
43
44
45

1
nwkProtocolVersion 0x98 Integer 0x00-0x0f The version of nwkProtocolVe 3
the ZigBee rsion 4
protocol 5
currently in use 6
by the NWK
layer.
7
8
nwkGroupIDTable 0x99 Set Variable The Group ID 9
Table (see
10
Table 3.43)
11
nwkExtendedPANID 0x9 64-bit 0x0000000 The Extended 0x0000000000 12
A extend 000000000- PAN Identifier 000000
13
ed 0xfffffffffff for the PAN of
addres ffffe which the device 14
s is a member. The 15
value 16
0x00000000000 17
00000 means the
18
Extended PAN
Identifier is 19
unknown. 20
21
22
23
Table 3.42 Group Table Entry Format 24
Field Name Field Type Valid Range Reference 25
26
GroupID Integer 0x0000 – 0xffff The identifier 27
of a multicast
group of which
28
this device is a 29
member 30
31
32
3.7 Functional Description 33
34
35
3.7.1 Network and Device Maintenance 36
37
All ZigBee devices shall provide the following functionality: 38
39
• Join a network
40
• Leave a network 41
42
Both ZigBee coordinators and routers shall provide the following additional
43
functionality:
44
45
Chapter 3
• Permit devices to join the network using the following:

1
• Association indications from the MAC 2
• Explicit join requests from the application 3
4
• Permit devices to leave the network using the following: 5
• Network Leave command frames. 6
7
• Explicit leave requests from the application. 8
• Participate in assignment of logical network addresses. 9
10
• Maintain a list of neighboring devices. 11
ZigBee coordinators shall provide functionality to establish a new network. 12
ZigBee routers and end devices shall provide the support of portability within a 13
network. 14
15
3.7.1.1 Establishing a New Network 16
17
The procedure to establish a new network is initiated through the use of the 18
NLME-NETWORK-FORMATION.request primitive. Only devices that are 19
ZigBee coordinator capable and are not currently joined to a network shall attempt 20
to establish a new network. If this procedure is initiated on any other device, the 21
NLME shall terminate the procedure and notify the next higher layer of the illegal 22
request. This is achieved by issuing the NLME-NETWORK- 23
FORMATION.confirm primitive with the Status parameter set to 24
INVALID_REQUEST. 25
When this procedure is initiated, the NLME shall first request that the MAC sub- 26
layer perform an energy detection scan over either a specified set of channels or, 27
by default, the complete set of available channels, as dictated by the PHY layer 28
(see [B1]), to search for possible interferers. A channel scan is initiated by issuing 29
the MLME-SCAN.request primitive, with the ScanType parameter set to energy 30
detection scan, to the MAC sub-layer. The results are communicated back via the 31
MLME-SCAN.confirm primitive. 32
33
On receipt of the results from a successful energy detection scan, the NLME shall 34
order the channels according to increasing energy measurement and discard those 35
channels whose energy levels are beyond an acceptable level. The choice of an 36
acceptable energy level is left to the implementation. The NLME shall then 37
perform an active scan, by issuing the MLME-SCAN.request primitive with a 38
ScanType parameter set to active scan and ChannelList set to the list of acceptable 39
channels, to search for other ZigBee devices. To determine the best channel on 40
which to establish a new network, the NLME shall review the list of returned PAN 41
descriptors and find the first channel with the lowest number of existing networks, 42
favoring a channel with no detected networks. 43
44
45
If no suitable channel is found, the NLME shall terminate the procedure and
notify the next higher layer of the startup failure. This is achieved by issuing the 1
NLME-NETWORK-FORMATION.confirm primitive with the Status parameter 2
set to STARTUP_FAILURE. 3
4
If a suitable channel is found, the NLME shall select a PAN identifier for the new 5
network. To do this the device shall choose a random PAN identifier less than 6
0x3fff that is not already in use on the selected channel. Once the NLME makes 7
its choice, it shall set the macPANID attribute in the MAC sub-layer to this value 8
by issuing the MLME-SET.request primitive. 9
If no unique PAN identifier can be chosen, the NLME shall terminate the 10
procedure and notify the next higher layer of the startup failure by issuing the 11
NLME-NETWORK-FORMATION.confirm primitive with the Status parameter 12
set to STARTUP_FAILURE. 13
14
Once a PAN identifier is selected, the NLME shall select a 16-bit network address 15
equal to 0x0000 and set the macShortAddress PIB attribute in the MAC sub-layer 16
equal to the selected network address. 17
Once a network address is selected, the NLME shall check the value of the 18
nwkExtendedPANId attribute of the NIB. If this value is 0x0000000000000000 19
this attribute is initialized with the value of the MAC constant aExtendedAddress. 20
21
Once the value of the nwkExtendedPANId is checked, the NLME shall begin 22
operation of the new PAN by issuing the MLME-START.request primitive to the 23
MAC sub-layer. The parameters of the MLME-START.request primitive shall be 24
set according to those passed in the NLME-NETWORK-FORMATION.request, 25
the results of the channel scan, and the chosen PAN identifier. The status of the 26
PAN startup is communicated back via the MLME-START.confirm primitive. 27
On receipt of the status of the PAN startup, the NLME shall inform the next higher 28
layer of the status of its request to initialize the ZigBee coordinator. This is 29
achieved by issuing the NLME-NETWORK-FORMATION.confirm primitive 30
with the Status parameter set to the primitive returned in the MLME- 31
START.confirm from the MAC sub-layer. 32
33
The procedure to successfully start a new network is illustrated in the message 34
sequence chart (MSC) shown in Figure 3.21. 35
36
37
38
39
40
41
42
43
44
45
Chapter 3
ZigBee Coord. ZigBee Coord. ZigBee Coord. 1

APL NWK MAC 2
3
NLME-NETWORK- 4
FORMATION.request
MLME- 5
SCAN.request 6
7
Perform energy 8
MLME- detection scan
SCAN.confir m
9
10
MLME- 11
SCAN.request 12
13
Perform active scan 14
MLME- 15
SCAN.confir m
16
Select channel, PAN ID
17
and logical address MLME- 18
SET.request 19
20
MLME- 21
SET.confir m
22
MLME- 23
START.request 24
25
MLME- 26
NLME-NETWORK- START.confirm 27
FORMATION.confirm 28
29
30
31
Figure 3.21 Establishing a New Network 32
33
3.7.1.2 Permitting Devices to Join a Network 34
35
The procedure for permitting devices to join a network is initiated through the 36
NLME-PERMIT-JOINING.request primitive. Only devices that are either the 37
ZigBee coordinator or a ZigBee router shall attempt to permit devices to join the 38
network. 39
When this procedure is initiated with the PermitDuration parameter set to 0x00, 40
the NLME shall set the macAssociationPermit PIB attribute in the MAC sub-layer 41
to FALSE. A MAC sub-layer attribute setting is initiated by issuing the MLME- 42
SET.request primitive. 43
44
45
When this procedure is initiated with the PermitDuration parameter set to a value
between 0x01 and 0xfe, the NLME shall set the macAssociationPermit PIB 1
attribute in the MAC sub-layer to TRUE. The NLME shall then start a timer to 2
expire after the specified duration. On expiry of this timer, the NLME shall set the 3
macAssociationPermit PIB attribute in the MAC sub-layer to FALSE. 4
5
When this procedure is initiated with the PermitDuration parameter set to 0xff, the 6
NLME shall set the macAssociationPermit PIB attribute in the MAC sub-layer to 7
TRUE for an unlimited amount of time, unless another NLME-PERMIT- 8
JOINING.request primitive is issued. 9
The procedure for permitting devices to join a network is illustrated in the MSC 10
shown in Figure 3.22. 11
12
13
APL NWK MAC 15
16
NLME- 17
PERMIT-JOINING.request MLME-
SET.request 18
19
MLME- 20
SET.confirm
21
22
23
Duration to permit
joining 24
25
MLME- 26
SET.request
27
28
MLME- 29
NLME- SET.confirm
30
PERMIT-JOINING.confirm
31
32
Figure 3.22 Permitting Devices to Join a Network 33
34
3.7.1.3 Joining a Network 35
36
A parent-child relationship is formed when a device having membership in the 37
network allows a new device to join. The new device becomes the child, while the 38
first device becomes the parent. A child can be added to a network in the 39
following two ways: 40
• The child can join the network using the MAC layer association procedure 41
42
• Or, the child can be added to the network directly by a previously designated 43
parent device. 44
45
Chapter 3
3.7.1.3.1 Joining a Network Through Association

1
This sub-clause specifies the procedure a device (child) shall follow to join a 2
network, as well as the procedure a ZigBee coordinator or router (parent) shall 3
follow upon receipt of a join request. Any device may accept a join request from a 4
new device so long as it has the necessary physical capabilities and the available 5
network address space. Only a ZigBee coordinator or a router is physically 6
capable of accepting a join request, while an end device is not. 7
8
3.7.1.3.1.1 Child Procedure 9
10
The procedure for joining a network using the MAC layer association procedure
11
shall be initiated by issuing the NLME-NETWORK-DISCOVERY.request
12
primitive with the ScanChannels parameter set to indicate which channels are to
13
be scanned for networks and the ScanDuration parameter set to indicate the length
14
of time to be spent scanning each channel. Upon receipt of this primitive, the
15
NWK layer shall issue an MLME-SCAN.request primitive asking the MAC sub-
16
layer to perform a passive or active scan.
17
Every beacon frame received during the scan having a non-zero length payload 18
shall cause the MLME-BEACON-NOTIFY.indication primitive to be issued from 19
the MAC sub-layer of the scanning device to its NLME. This primitive includes 20
information such as the addressing information of the beaconing device, whether 21
or not it is permitting association and the beacon payload. (See [B1] for the 22
complete list of parameters). The NLME of the scanning device shall check the 23
protocol ID field in the beacon payload and verify that it matches the ZigBee 24
protocol identifier. If not, the beacon is ignored. Otherwise, the device shall copy 25
the relevant information from each received beacon (see Figure 3.37 for the 26
structure of the beacon payload) into its neighbor table (see Table 3.43 for the 27
contents of a neighbor table entry). 28
29
Once the MAC sub-layer signals the completion of the scan by issuing the
30
MLME-SCAN.confirm primitive to the NLME, the NWK layer shall issue the
31
NLME-NETWORK-DISCOVERY.confirm primitive containing a description of
32
each network that was heard. Every network description contains the ZigBee
33
version, stack profile, Extended PAN Id, PAN Id, logical channel, and information
34
on whether it is permitting joining (see Table 3.9).
35
Upon receipt of the NLME-NETWORK-DISCOVERY.confirm primitive, the 36
next higher layer is informed of the networks present in the neighborhood. The 37
next higher layer may choose to redo the network discovery to discover more 38
networks or for other reasons. If not, it shall choose a network to join from the 39
discovered networks. It shall then issue the NLME-JOIN.request with the 40
RejoinNetwork parameter set to 0x00 and the JoinAsRouter parameter set to 41
indicate whether the device wants to join as a routing device. 42
43
44
45
Only those devices that are not already joined to a network shall initiate the join
procedure. If any other device initiates this procedure, the NLME shall terminate 1
the procedure and notify the next higher layer of the illegal request by issuing the 2
NLME-JOIN.confirm primitive with the Status parameter set to 3
INVALID_REQUEST. 4
5
For a device that is not already joined to a network, the NLME-JOIN.request 6
primitive shall cause the NWK layer to search its neighbor table for a suitable 7
parent device. A suitable parent device shall permit association and shall have a 8
link cost (see sub-clause 3.7.3.1 for details on link cost) of 3, at most. It shall also 9
have the potential parent field set to 1, if that field is present in the neighbor table 10
entry. 11
If the neighbor table contains no devices that are suitable parents, the NLME shall 12
respond with an NLME-JOIN.confirm with a status parameter of 13
NOT_PERMITTED. If the neighbor table has more than one device that could be 14
a suitable parent, the device which is at a minimum depth from the ZigBee 15
coordinator shall be chosen. If more than one device has a minimum depth, the 16
NWK layer is free to choose from among them. 17
18
Once a suitable parent is identified, the NLME shall issue an MLME- 19
ASSOCIATE.request primitive to the MAC sub-layer. The addressing parameters 20
in the MLME-ASSOCIATE.request primitive (see Chapter 2) shall be set to 21
contain the addressing information for the device chosen from the neighbor table. 22
The status of the association is communicated back to the NLME via the MLME- 23
ASSOCIATE.confirm primitive. 24
If the attempt to join was unsuccessful, the NWK layer shall receive an MLME- 25
ASSOCIATE.confirm primitive from the MAC sub-layer with the status 26
parameter indicating the error. If the status parameter indicates a refusal to permit 27
joining on the part of the neighboring device (that is, PAN at capacity or PAN 28
access denied), then the device attempting to join should set the Potential parent 29
bit to 0 in the corresponding neighbor table entry to indicate a failed join attempt. 30
Setting the Potential parent bit to 0 ensures that the NWK layer shall not issue 31
another request to associate to the same neighboring device. The Potential parent 32
bit should be set to 1 for every entry in the neighbor table each time an MLME- 33
SCAN.request primitive is issued. 34
35
A join request may also be unsuccessful, if the potential parent is not allowing 36
new routers to associate (for example, the max number of routers, 37
nwkMaxRouters may already have associated with the device) and the joining 38
device has set the JoinAsRouter parameter to TRUE. In this case the NLME- 39
JOIN.confirm primitive will indicate a status of NOT_PERMITTED. In this case 40
the child device’s application may wish to attempt to join again as an end device 41
instead, by issuing another NLME-JOIN.request with the JoinAsRouter parameter 42
set to FALSE. 43
44
45
Chapter 3
If the attempt to join was unsuccessful, the NLME shall attempt to find another
suitable parent from the neighbor table. If no such device could be found, the 1
NLME shall issue the NLME-JOIN.confirm primitive with the Status parameter 2
set to the value returned in the MLME-ASSOCIATE.confirm primitive. 3
4
If the attempt to join was unsuccessful and there is a second neighboring device 5
that could be a suitable parent, the NWK layer shall initiate the MAC sub-layer 6
association procedure with the second device. The NWK layer shall repeat this 7
procedure until it either joins the PAN successfully or exhausts its options to join 8
the PAN. 9
If the device cannot successfully join the PAN specified by the next higher layer, 10
the NLME shall terminate the procedure by issuing the NLME-JOIN.confirm 11
primitive with the Status parameter set to the value returned in the last received 12
MLME-ASSOCIATE.confirm primitive. In this case, the device shall not receive 13
a valid logical address and shall not be permitted to transmit on the network. 14
15
If the attempt to join was successful, the MLME-ASSOCIATE.confirm primitive 16
received by the NWK layer shall contain a 16-bit logical address unique to that 17
network that the child can use in future transmissions. The NWK layer shall then 18
set the Relationship field in the corresponding neighbor table entry to indicate that 19
the neighbor is its parent. By this time, the parent shall have each added the new 20
device to its neighbor table. Furthermore, the NWK layer will update the value of 21
nwkShortAddress in the NIB. 22
If the device is attempting to join a secure network and it is a router, it will need to 23
wait until its parent has authenticated it before transmitting beacons. The device 24
shall therefore wait for an NLME-START-ROUTER.request primitive to be 25
issued from the next higher layer. Upon receipt of this primitive, the NLME shall 26
issue an MLME-START.request primitive if it is a router. If the NLME-START- 27
ROUTER.request primitive is issued on an end device, the NWK layer shall issue 28
an NLME-START-ROUTER.confirm primitive with the status value set to 29
INVALID_REQUEST. 30
31
Once the device has successfully joined the network, if it is a router and the next 32
higher layer has issued a NLME-START-ROUTER.request, the NWK layer shall 33
issue the MLME-START.request primitive to its MAC sub-layer to setup its 34
superframe configuration and begin transmitting beacon frames, if applicable. 35
Beacon frames are only transmitted if the BeaconOrder parameter is not equal to 36
15 (See [B1]). The PANId, LogicalChannel, BeaconOrder and SuperframeOrder 37
parameters shall be set equal to the corresponding values held in the neighbor 38
table entry for its parent. The PANCoordinator and CoordRealignment parameters 39
shall both be set to FALSE. Upon receipt of the MLME-START.confirm 40
primitive, the NWK layer shall issue an NLME-START-ROUTER.confirm 41
primitive with the same status value. 42
43
44
45
Child Child Child 1

APL NWK MAC 2
3
4
NLME-NETWORK- 5
DISCOVERY.request MLME- 6
SCAN.request 7
8
Perform active or passive scan 9
10
MLME-BEACON-
NOTIFY.indication 11
12
.
13
.
14
.
15
MLME-BEACON- 16
NOTIFY.indication 17
18
MLME- 19
SCAN.confirm 20
NLME-NETWORK- 21
DISCOVERY.confirm
22
23
24
Select suitable PAN
25
NLME- 26
JOIN.request MLME-
ASSOCIATE.request 27
28
29
Association procedure
MLME-
30
NLME- ASSOCIATE.confirm 31
JOIN.confirm 32
33
Authentication procedure 34
NLME- 35
START-ROUTER.request MLME- 36
START.request 37
MLME- 38
NLME- START.confirm 39
START-ROUTER.confirm 40
41
42
Figure 3.23 Procedure for Joining a Network Through Association 43
44
45
Chapter 3
3.7.1.3.1.2 Parent Procedure

1
The procedure for a ZigBee coordinator or router to join a device to its network 2
using the MAC sub-layer association procedure is initiated by the MLME- 3
ASSOCIATE.indication primitive arriving from the MAC sub-layer. Only those 4
devices that are either a ZigBee coordinator or a ZigBee router and that are 5
permitting devices to join the network shall initiate this procedure. If this 6
procedure is initiated on any other device, the NLME shall terminate the 7
procedure. 8
When this procedure is initiated, the NLME of a potential parent shall first 9
determine whether the device wishing to join already exists on its network. To do 10
this, the NLME shall search its neighbor table in order to determine whether a 11
matching 64-bit, extended address can be found. If a match is found, the NLME 12
shall obtain the corresponding 16-bit network address and issue an association 13
response to the MAC sub-layer. If a match is not found, the NLME shall, if 14
possible, allocate a 16-bit network address for the new device that is unique to that 15
network. A finite address space is allocated to every potential parent device, and a 16
device may disallow a join request once this address space is exhausted. The 17
ZigBee coordinator determines the amount of address space given. See sub- 18
clause 3.7.1.5 and sub-clause 3.7.1.6 for an explanation of the address assignment 19
mechanisms. 20
21
If the potential parent has exhausted its allocated address space, the NLME shall 22
terminate the procedure and indicate this fact in the subsequent MLME- 23
ASSOCIATE.response primitive to the MAC sub-layer. The Status parameter of 24
this primitive shall indicate that the PAN is at capacity. This status value uses 25
MAC sub-layer terminology and indicates only that the potential parent does not 26
have the capacity to accept any more children. It is possible in a multi-hop 27
network that other potential parents still having sufficient address space exist 28
within the same network. 29
If the request to join is granted, the NLME of the parent shall create a new entry 30
for the child in its neighbor table using the supplied device information and 31
indicate a successful association in the subsequent MLME-ASSOCIATE.response 32
primitive to the MAC sub-layer. The status of the response transmission to the 33
child is communicated back to the network layer via the MLME-COMM- 34
STATUS.indication primitive. 35
36
If the transmission was unsuccessful (the MLME-COMM-STATUS.indication 37
primitive contained a Status parameter not equal to SUCCESS), the NLME shall 38
terminate the procedure. If the transmission was successful, the NLME shall 39
notify the next higher layer that a child has just joined the network by issuing the 40
NLME-JOIN.indication primitive. 41
The procedure for successfully joining a device to the network is illustrated in the 42
MSC shown in Figure 3.23. 43
44
45
Parent Parent Parent 1

APL NWK MAC 2
3
MLME- 4
ASSOCIATE.indication
5
6
Check extended address and 7
assign logical address 8
MLME- 9
ASSOCIATE.response 10
11
MLME- 12
NLME- COMM-STATUS.i ndication 13
JOIN.indication 14
15
16
Figure 3.24 Procedure for Handling a Join Request 17
18
3.7.1.3.2 Rejoining a Network Using NWK Rejoin 19
20
Devices that have lost all connection to the network, for example a ZED that can 21
no longer communicate successfully with its parent, can rejoin the network using 22
the NWK rejoin request and NWK rejoin response commands. The rejoining 23
procedure is identical to the association procedure described in the previous 24
section, except that MAC association procedure is replaced by an exchange 25
involving the rejoin request and rejoin response commands, and, because NWK 26
commands make use of NWK security, no authentication step is performed. Using 27
these commands instead of the MAC procedure allows a device to rejoin a 28
network that does not currently allow new devices to join. 29
30
The procedure for rejoining a network using the NWK rejoin procedure shall be 32
initiated by issuing the NLME-JOIN.request primitive, as shown in Figure 3.25, 33
with the RejoinNetwork parameter set to 0x02 and the ExtendedPANId parameter 34
set to the ExtendedPANId of the network to rejoin. The JoinAsRouter parameter 35
will be set to indicate whether the device wants to join as a routing device. 36
37
The ScanChannels parameter will be set to indicate which channels are to be 38
scanned to locate this network and the ScanDuration parameter set to indicate the 39
length of time to be spent scanning each channel. 40
Upon receipt of this primitive, the NWK layer shall issue an MLME- 41
SCAN.request primitive asking the MAC sub-layer to perform a passive or active 42
scan. 43
44
45
Chapter 3
Every beacon frame received during the scan having a non-zero length payload
shall cause the MLME-BEACON-NOTIFY.indication primitive to be issued from 1
the MAC sub-layer of the scanning device to its NLME. The NLME of the 2
scanning device shall check the ExtendedPANId contained within the beacon 3
payload to see if it is of the correct value. If not, the beacon is ignored. Otherwise, 4
the device shall copy the relevant information from each received beacon (see 5
Figure 3.37 for the structure of the beacon payload) into its neighbor table (see 6
Table 3.43 and Table 3.44 for the contents of a neighbor table entry). 7
8
Once the MAC sub-layer signals the completion of the scan by issuing the 9
MLME-SCAN.confirm primitive to the NLME, the NWK layer shall search its 10
neighbor table for a suitable parent device. A suitable parent device shall advertise 11
device capacity of the type requested in the JoinAsRouter parameter and shall 12
have a link cost (see sub-clause 3.7.3.1) of 3, at most. If the neighbor table 13
contains no devices that are suitable parents, the NLME shall respond with an 14
NLME-JOIN.confirm with a status parameter of NOT_PERMITTED. If the 15
neighbor table has more than one device that could be a suitable parent and the 16
nwkUseTreeAddrAlloc NIG attribute has a value of TRUE, the device which is at 17
a minimum depth from the ZigBee coordinator shall be chosen. Once a suitable 18
parent is identified, the NLME shall construct a NWK rejoin request command 19
frame. The addressing parameters in the rejoin request command shall be set to 20
contain the addressing information for the device chosen from the neighbor table. 21
After the successful transmission of the rejoin request command using the MAC 22
data service the network layer will load a count down timer with a value of 23
aResponseWaitTime ([B1]), If the RxOnWhenIdle parameter is equal to FALSE, 24
when the timer expires the NWK layer will issue a MLME-POLL.request to the 25
potential parent, to retrieve the rejoin response command. 26
27
On receipt of a rejoin response command frame, after the above procedure or at 28
any other time, the device shall check the rejoining device IEEE address field and 29
the parent device IEEE address field of the command frame payload. If the 30
rejoining device IEEE address field is not equal in value to the IEEE address of 31
the receiving device or if the parent device IEEE address field is not equal in value 32
to the IEEE address of the most recent potential parent to which a rejoin request 33
command frame was sent, or the current parent in the case of an unsolicited rejoin 34
response, then the rejoin response command frame shall be discarded without 35
further processing. 36
If the rejoin status field within the rejoin response command frame indicates a 37
refusal to permit rejoining on the part of the neighboring device (that is, PAN at 38
capacity or PAN access denied), then the device attempting to rejoin should set the 39
potential parent bit to 0 in the corresponding neighbor table entry to indicate a 40
failed join attempt. Setting the potential parent bit to 0 ensures that the NWK layer 41
shall not issue another request to rejoin to the same neighboring device. If the 42
attempt to join was unsuccessful, the NLME shall attempt to find another suitable 43
44
45
parent from the neighbor table. If no such device could be found, the NLME shall
issue the NLME-JOIN.confirm primitive with the Status parameter set to 1
NOT_PERMITTED. If the attempt to join was unsuccessful and there is a second 2
neighboring device that could be a suitable parent, the NWK layer shall initiate 3
the NWK rejoin procedure with the second device. The NWK layer shall repeat 4
this procedure until it either rejoins the PAN successfully or exhausts its options to 5
rejoin the PAN. If the device cannot successfully rejoin the PAN specified by the 6
next higher layer, the NLME shall terminate the procedure by issuing the NLME- 7
JOIN.confirm primitive with the Status parameter set to NOT_PERMITTED. In 8
this case, the device shall not receive a valid logical address and shall not be 9
permitted to transmit on the network. If the attempt to rejoin was successful, the 10
NWK rejoin response command received by the NWK layer shall contain a 16-bit 11
logical address unique to that network that the child can use in future 12
transmissions. The NWK layer shall then set the relationship field in the 13
corresponding neighbor table entry to indicate that the neighbor is its parent. By 14
this time, the parent shall have each added the new device to its neighbor table. 15
Furthermore, the NWK layer will update the value of nwkShortAddress in the 16
NIB. 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
Figure 3.25 Child Rejoin Procedure 42
43
44
45
Chapter 3
3.7.1.3.2.2 Parent Procedure

1
The procedure for a ZigBee coordinator or router to rejoin a device to its network 2
using the NWK rejoin procedure is initiated by the arrival of a NWK layer rejoin 3
command frame via the MAC data service. Only those devices that are either a 4
ZigBee coordinator or a ZigBee router shall initiate this procedure. If this 5
procedure is initiated on any other device, the NLME shall terminate the 6
procedure. When this procedure is initiated, the NLME of a potential parent shall 7
first determine whether it already has knowledge of the requesting device. To do 8
this, the NLME shall search its neighbor table in order to determine whether a 9
matching 64-bit, extended address can be found. If a match is found, the NLME 10
shall consider the join attempt successful and use the 16-bit network address 11
found in its neighbor table as the network address of the joining device. If a match 12
is not found, the NLME shall, if possible, allocate a 16-bit network address for the 13
new device that is unique to that network. A finite address space is allocated to 14
every potential parent device, and a device may disallow a join request once this 15
address space is exhausted. The ZigBee coordinator determines the amount of 16
address space given. See sub-clause 3.7.1.5 and sub-clause 3.7.1.6 for an 17
explanation of the address assignment mechanisms. If the potential parent has 18
exhausted its allocated address space, the NLME shall terminate the procedure 19
and indicate this fact in the subsequent rejoin response command. The Status 20
parameter of this command shall indicate that the PAN is at capacity. If the request 21
to rejoin is granted, the NLME of the parent shall create a new entry for the child 22
in its neighbor table, or modify the existing entry if one such already exists, using 23
the supplied device information, and indicate a successful rejoin by replying to the 24
requesting device with a NWK rejoin response command. The NLME shall then 25
notify the next higher layer that a child has just rejoined the network by issuing 26
the NLME-JOIN.indication primitive. The procedure for successfully rejoining a 27
device to the network is illustrated in the MSC shown in Figure 3.26. 28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Figure 3.26 Parent Rejoin Procedure 17
18
3.7.1.3.3 Joining a Network Directly 19
This sub-clause specifies how a device can be directly added to a network by a 20
previously designated parent device (ZigBee coordinator or router). In this case, 21
the parent device is preconfigured with the 64-bit address of the child device. The 22
following text describes how this prior address knowledge may be used to 23
establish the parent-child relationship. 24
25
The procedure for a ZigBee coordinator or router to directly join a device to its 26
network is initiated by issuing the NLME-DIRECT-JOIN.request primitive with 27
the DeviceAddress parameter set to the address of the device to be joined to the 28
network. Only those devices that are either a ZigBee coordinator or a ZigBee 29
router may initiate this procedure. If this procedure is initiated on any other 30
device, the NLME may terminate the procedure and notify the next higher layer of 31
the illegal request by issuing the NLME-DIRECT-JOIN.confirm primitive with 32
the Status parameter set to INVALID_REQUEST. 33
When this procedure is initiated, the NLME of the parent shall first determine 34
whether the specified device already exists on its network. To do this, the NLME 35
shall search its neighbor table in order to determine whether a matching 64-bit, 36
extended address can be found. If a match is found, the NLME shall terminate the 37
procedure and notify the next higher layer that the device is already present in the 38
device list by issuing the NLME-DIRECT-JOIN.confirm primitive with the Status 39
parameter set to ALREADY_PRESENT. 40
41
If a match is not found, the NLME shall, if possible, allocate a 16-bit network 42
address for the new device, which is unique to that network. A finite address space 43
is allocated to every potential parent device, and the potential parent shall create a 44
45
Chapter 3
new entry for the device in its neighbor table only if it has sufficient capacity. If
capacity is not available, the NLME shall terminate the procedure and notify the 1
next higher layer of the unavailable capacity by issuing the NLME-DIRECT- 2
JOIN.confirm primitive with the Status parameter set to 3
NEIGHBOR_TABLE_FULL. If capacity is available, the NLME shall inform the 4
next higher layer that the device has joined the network by issuing the NLME- 5
DIRECT-JOIN.confirm primitive with the Status parameter set to SUCCESS. 6
7
The ZigBee coordinator determines the amount of address space given to every 8
potential parent device. See sub-clause 3.7.1.5 and sub-clause 3.7.1.6 for an 9
explanation of the address assignment mechanism. 10
Once the parent has added the child to its network, it is still necessary for the child 11
to make contact with the parent to complete the establishment of the parent-child 12
relationship. The child shall fulfill this requirement by initiating the orphaning 13
procedure, which is described in sub-clause 3.7.1.3.3.1. 14
15
A parent that supports direct joining shall follow the procedure illustrated in 16
Figure 3.27 to successfully join a device to the network directly. This procedure 17
does not require any over-the-air transmissions. 18
19
20
Parent Parent Parent 21
APL NWK MAC 22
23
NLME-DIRECT-
JOIN.request(DeviceAddress)
24
25
26
Check extended address and
assign logical address
27
28
NLME-DIRECT- 29
JOIN.confirm 30
31
32
Figure 3.27 Joining a Device to a Network Directly 33
34
3.7.1.3.3.1 Joining or Re-joining a Network Through Orphaning 35
36
This sub-clause specifies how the orphaning procedure can be initiated by a
37
device that has been directly joined to a network (joining through orphaning) or
38
by a device that was previously joined to a network but has lost contact with its
39
parent (re-joining through orphaning).
40
A device that has been added to a network directly shall initiate the orphan 41
procedure in order to complete the establishment of its relationship with its parent. 42
The application on the device will determine whether to initiate this procedure 43
and, if so, will notify the network layer upon power up. 44
45
A device that was previously joined to a network has the option of initiating the
orphan procedure if its NLME repeatedly receives communications failure 1
notifications from its MAC sub-layer. 2
3
5
The optional joining through orphaning procedure is initiated by a device using 6
the NLME-JOIN.request primitive with the RejoinNetwork parameter set to 0x01. 7
When this procedure is initiated, the NLME shall first request that the MAC sub- 8
layer perform an orphan scan over the over the set of channels given by the 9
ScanChannels parameter. An orphan scan is initiated by issuing the MLME- 10
SCAN.request primitive to the MAC sub-layer, and the result is communicated 11
back to the NLME via the MLME-SCAN.confirm primitive. 12
13
If the orphan scan was successful — that is, the child has found its parent — the 14
NLME shall inform the next higher layer of the success of its request to join or re- 15
join the network by issuing the NLME-JOIN.confirm primitive with the Status 16
parameter set to SUCCESS. 17
Note that if the child device is joining for the first time or if the child device has 18
previously been joined to the network but has failed to retain tree depth 19
information as prescribed in sub-clause 3.7.7.1, it may not be able to operate 20
correctly on the network without taking measures, outside the scope of this 21
specification, for the recovery of this information. 22
23
If the orphan scan was unsuccessful (the parent has not been found), the NLME 24
shall terminate the procedure and notify the next higher layer that no networks 25
were found. This is achieved by issuing the NLME-JOIN.confirm primitive with 26
the Status parameter set to NO_NETWORKS. 27
The procedure for a child to successfully join or re-join a network through 28
orphaning is illustrated in the MSC shown in Figure 3.28 29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Chapter 3
Child Child Child 1

APL NWK MAC 2
3
NLME- 4
JOIN.request(True) 5
MLME-
SCAN.request 6
7
8
Perform orphan scan
9
MLME - 10
NLME- SCAN.confirm 11
JOIN.confirm
12
13
.
14
Figure 3.28 Child Procedure for Joining or Re-joining a Network 15
Through Orphaning 16
17
3.7.1.3.3.3 Parent Procedure 18
A device is notified of the presence of an orphaned device when it receives the 19
MLME-ORPHAN.indication primitive from the MAC sub-layer. Only devices 20
that are either ZigBee coordinators or a ZigBee routers (that is, devices with 21
parental capabilities) shall initiate this procedure. If this procedure is initiated on 22
any other device, the NLME shall terminate the procedure. 23
24
When this procedure is initiated, the NLME shall first determine whether the 25
orphaned device is its child. This is accomplished by comparing the extended 26
address of the orphaned device with the addresses of its children, as recorded in its 27
neighbor table. If a match is found (the orphaned device is its child), the NLME 28
shall obtain the corresponding 16-bit network address and include it in its 29
subsequent orphan response to the MAC sub-layer. The orphan response to the 30
MAC sub-layer is initiated by issuing the MLME-ORPHAN.response primitive, 31
and the status of the transmission is communicated back to the NLME via the 32
MLME-COMM-STATUS.indication primitive. 33
If an address match is not found (the orphaned device is not its child) the 34
procedure shall be terminated without indication to the higher layer. 35
36
The procedure for a parent to join or re-join its orphaned child to the network is 37
illustrated in the MSC shown in Figure 3.29. 38
39
40
41
42
43
44
45
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Figure 3.29 Parent Procedure for Joining or Re-joining a Device to its Network
Through Orphaning 18
19
3.7.1.4 Neighbor Tables 20
21
The neighbor table of a device shall contain information on every device within 22
transmission range, up to some implementation-dependent limit. 23
24
The neighbor table is useful in two contexts. First of all, it is used during network
25
discovery or rejoining to store information about routers within RF reception
26
range that may be candidate parents. Second, after the device has joined a
27
network, it is used to store relationship and link-state information about
28
neighboring devices in that network. A table entry shall be updated every time a
29
device receives any frame from the corresponding neighbor.
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Chapter 3
Mandatory and optional data that are used in normal network operation are listed
in Table 3.43. 1
2
Table 3.43 Neighbor Table Entry Format
3
Field 4
Field Name Type Valid Range Description 5
6
Extended address Integer An extended 64-bit, 64-bit IEEE address that is unique
IEEE address to every device; This field shall be 7
present if the neighbor is a parent 8
or child of the device 9
Network address Network 0x0000 – 0xffff The 16-bit network address of the 10
address neighboring device. 11
12
This field shall be present in every
neighbor table entry 13
14
Device type Integer 0x00 – 0x02 The type of the neighbor device: 15
0x00 = ZigBee coordinator 16
0x01 = ZigBee router; 17
0x02 = ZigBee end device 18
This field shall be present in every 19
21
RxOnWhenIdle Boolean TRUE or FALSE Indicates if neighbor’s receiver is
enabled during idle portions of the 22
CAP: 23
24
TRUE = Receiver is on
25
FALSE = Receiver is off
26
This field should be present for 27
entries that record the parent or
children of a ZigBee router or 28
ZigBee coordinator 29
30
Relationship Integer 0x00 – 0x03 The relationship between the
neighbor and the current device: 31
32
0x00=neighbor is the parent 33
0x01=neighbor is a child 34
0x02=neighbor is a sibling 35
0x03=none of the above 36
0x04=previous child 37
40
41
42
43
44
45
Table 3.43 Neighbor Table Entry Format (Continued)

1
Field 2
Field Name Type Valid Range Description
3
Transmit Failure Integer 0x00 – 0xff A value indicating if previous 4
transmissions to the device were 5
successful or not; Higher values 6
indicate more failures/
7
neighbor table entry. 9
LQI Integer 0x00 – 0xff The estimated link quality for RF 10
transmissions from this device. 11
See sub-clause 3.7.3.1 for 12
discussion of how this is
13
calculated.
14
neighbor table entry.
16
Incoming beacon Integer 0x000000-0xffffff The time, in symbols, at which the 17
timestamp last beacon frame was received 18
from the neighbor. This value is
19
equal to the timestamp taken when
the beacon frame was received, as 20
described in IEEE 802.15.4-2003 21
[B1]. 22
This field is optional. 23
24
Beacon transmission Integer 0x000000-0xffffff The transmission time difference, 25
time offset in symbols, between the
neighbor’s beacon and its parent’s 26
beacon. This difference may be 27
subtracted from the corresponding 28
incoming beacon timestamp to 29
calculate the beacon transmission 30
time of the neighbor’s parent.
31
This field is optional. 32
33
Information that may be used during network discovery and rejoining, as 34
described above, is shown in Table 3.44. All of the fields shown are optional and 35
should not be retained after the NLME has chosen a network to join. Neighbor 36
37
38
39
40
41
42
43
44
45
Chapter 3
table entries corresponding to devices that are not members of the chosen network
should similarly be discarded. 1
2
Table 3.44 Additional Neighbor Table Fields
3
Field 4
Field Name Type Valid Range Description 5
6
Extended PAN ID Integer 0x00000000000000 The 64-bit unique identifier of the
01 - network to which the device 7
0xfffffffffffffffe belongs. 8
9
Logical channel Integer Selected from the The logical channel on which the
available logical network is operating. 10
channels supported 11
by the PHY. 12
Depth Integer 0x00 – The tree depth of the neighbor 13
nwkcMaxDepth device. 14
15
Beacon order Integer 0x00 – 0x0f The IEEE 802.15.4 beacon order
for the device.
16
17
Permit joining Boolean TRUE or FALSE An indication of whether the 18
device is accepting joining
19
requests.
20
TRUE = device is accepting join 21
requests.
22
FALSE - device is not accepting 23
join requests.
24
Potential parent Integer 0x00 – 0x01 An indication of whether the 25
device has been ruled out as a 26
potential parent.
27
0x00 indicates that the device is 28
not a potential parent. 29
0x01 indicates that the device is a 30
potential parent.
31
32
3.7.1.5 Distributed Address Assignment Mechanism 33
34
The default value for the NIB attribute nwkUseTreeAddrAlloc is TRUE, network 35
addresses are assigned using a distributed addressing scheme that is designed to 36
provide every potential parent with a finite sub-block of network addresses. These 37
addresses are unique within a particular network and are given by a parent to its 38
children. The ZigBee coordinator determines the maximum number of children 39
any device, within its network, is allowed. Of these children, a maximum of 40
nwkMaxRouters can be router-capable devices. The remaining devices shall be 41
reserved for end devices. Every device has an associated depth which indicates 42
the minimum number of hops a transmitted frame must travel, using only parent- 43
child links, to reach the ZigBee coordinator. The ZigBee coordinator itself has a 44
45
depth of 0, while its children have a depth of 1. Multi-hop networks have a

maximum depth that is greater than 1. The ZigBee coordinator also determines the 1
maximum depth of the network. 2
3
Given values for the maximum number of children a parent may have, 4
nwkMaxChildren (Cm), the maximum depth in the network, nwkMaxDepth (Lm), 5
and the maximum number of routers a parent may have as children, 6
nwkMaxRouters (Rm), we may compute the function, Cskip(d), essentially the 7
size of the address sub-block being distributed by each parent at that depth to its 8
router-capable child devices for a given network depth, d, as follows: 9
10
⎧1 + Cm ⋅ ( Lm − d − 1), if Rm = 1 11
⎪ 12
Cskip (d ) = ⎨1 + Cm − Rm − Cm ⋅ Rm Lm − d −1
, otherwise 13
⎪⎩ 1 − Rm 14
15
If a device has a Cskip(d) value of 0, then it shall not be capable of accepting 16
children and shall be treated as a ZigBee end device for purposes of this 17
discussion. The NLME of the device shall set the macAssociationPermit PIB 18
attribute in the MAC sub-layer to FALSE by issuing the MLME-SET.request 19
primitive. It shall respond to any future NLME-PERMIT-JOINING.request 20
primitive with a PermitDuration value greater than or equal to 0x01 by sending a 21
NLME-PERMIT-JOINING.confirm primitive with a Status of 22
INVALID_REQUEST. It shall then terminate the permit joining procedure. 23
24
A parent device that has a Cskip(d) value greater than 0 shall accept child devices
25
and shall assign addresses to them differently depending on whether or not the
26
child device is router-capable.
27
Network addresses shall be assigned to router-capable child devices using the 28
value of Cskip(d) as an offset. A parent assigns an address that is 1 greater than 29
its own to its first router-capable child device. Subsequently assigned addresses to 30
router-capable child devices are separated from each other by Cskip(d). A 31
maximum of nwkMaxRouters of such addresses shall be assigned. 32
33
Network addresses shall be assigned to end devices in a sequential manner with
34
the nth address, An , given by the following equation:
35
36
A n = A parent + Cskip ( d ) ⋅ Rm + n 37
38
39
Where 1 ≤ n ≤ ( Cm – Rm ) and Aparent represents the address of the parent. 40
41
42
43
44
45
Chapter 3
The Cskip(d) values for an example network having nwkMaxChildren=4,

nwkMaxRouters=4 and nwkMaxDepth=3 are calculated and listed in Table 3.45. 1
Figure 3.30 illustrates the example network. 2
3
Table 3.45 Example Addressing Offset Values for Each Given
Depth Within the Network 4
5
Offset Value, 6
Depth in the Network, d Cskip(d) 7
0 21 8
9
1 5 10
2 1 11
3 0
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
Figure 3.30 Address Assignment in an Example Network 35
36
Because an address sub-block cannot be shared between devices, it is possible that 37
one parent exhausts its list of addresses while a second parent has addresses that 38
go unused. A parent having no available addresses shall not permit a new device 39
to join the network. In this situation, the new device shall find another parent. If 40
no other parent is available within transmission range of the new device, the 41
device shall be unable to join the network unless it is physically moved or there is 42
some other change. 43
44
45
3.7.1.6 Higher-layer Address Assignment Mechanism

1
When the NIB attribute nwkUseTreeAddrAlloc has a value of FALSE, an alternate 2
addressing scheme is used where the block of addresses to be assigned by a device 3
is set by the next higher layer using the NIB attributes nwkNextAddress, 4
nwkAvailableAddresses and nwkAddressIncrement. In this scheme, when a device 5
has nwkAvailableAddresses equal to 0, it shall be incapable of accepting 6
association requests. The NLME of such a device shall set the 7
macAssociationPermit PIB attribute in the MAC sub-layer to FALSE by issuing 8
the MLME-SET.request primitive and shall respond to future NLME-PERMIT- 9
JOINING.request primitives with a PermitDuration of equal to or greater than 10
0x01 by sending a NLME-PERMIT-JOINING.confirm primitive with a Status 11
parameter of INVALID_REQUEST. It shall then terminate the permit joining 12
procedure. If the device has nwkAvailableAddresses greater than 0, it shall accept 13
association requests by setting the macAssociationPermit PIB attribute in the 14
MAC sub-layer to TRUE by issuing the MLME-SET.request primitive. In 15
addition, it shall respond to any future NLME-PERMIT-JOINING.request 16
primitives with a PermitDuration greater than or equal to 0x01 by emitting a 17
NLME-PERMIT-JOINING.confirm primitive with a Status parameter value of 18
SUCCESS. While a device is accepting associations, it shall use the value of 19
nwkNextAddress as the address to be assigned to the next device that successfully 20
associates. After a successful association, the value of nwkNextAddress shall be 21
incremented by the value of nwkAddressIncrement and the value of 22
nwkAvailableAddresses shall be decremented by 1. 23
24
3.7.1.7 Installation and Addressing 25
26
It should be clear that nwkMaxDepth roughly determines the “distance” in 27
network terms from the root of the tree to the farthest end device. In principle, 28
nwkMaxDepth also determines the overall network diameter. In particular, for an 29
ideal network layout in which the ZigBee coordinator is located in the center of 30
the network, as illustrated in Figure 3.30, the network diameter should be 2 * 31
nwkMaxDepth. In practice, application-driven placement decisions and order of 32
deployment may lead to a smaller diameter. In this case, nwkMaxDepth provides a 33
lower bound on the network diameter while the 2* nwkMaxDepth provides the 34
upper bound. 35
Finally, due to the fact that the tree, when nwkUseTreeAddrAlloc has a value of 36
TRUE, is not dynamically balanced, the possibility exists that certain installation 37
scenarios, such as long lines of devices, may exhaust the address capacity of the 38
network long before the real capacity is reached. 39
40
41
42
43
44
45
Chapter 3
3.7.1.8 Leaving a Network

1
This sub-clause specifies methods for a device to remove itself from the network 2
and for the parent of a device to request its removal. In both cases, the children of 3
the removed device, if any, may be slated for removal as well. 4
5
3.7.1.8.1 Method for a Device to Initiate Its Own Removal from a Network
6
This sub-clause describes how a device can initiate its own removal from the 7
network in response to the receipt of an NLME-LEAVE.request primitive from 8
the next higher layer as shown in Figure 3.31. 9
10
11
12
13
14
15
16
17
18
19
20
21
22
Figure 3.31 Initiation of the Leave Procedure 23
24
On receipt, by the NWK layer of a ZigBee router or ZigBee coordinator, of the 25
NLME-LEAVE.request primitive with the DeviceAddress parameter equal to 26
NULL (indicating that the device is to remove itself) the device shall send a leave 27
command frame using the MCPS-DATA.request primitive with the DstAddr 28
parameter set to 0xffff indicating a MAC broadcast. The request sub-field of the 29
command options field of the leave command frame shall be set to 0. The value of 30
the remove children sub-field of the command options field of the leave command 31
shall reflect the value of the RemoveChildren parameter of the NLME- 32
LEAVE.request primitive, and the value of the Rejoin sub-field of the leave 33
command shall reflect the value of the Rejoin parameter of the NLME- 34
LEAVE.request primitive. After transmission of the leave command frame, it shall 35
issue a NLME-LEAVE.confirm primitive to the higher layer with the 36
DeviceAddress parameter equal to NULL. The Status parameter shall be 37
SUCCESS if the leave command frame was transmitted successfully. Otherwise 38
the status parameter of the NLME-LEAVE.confirm shall have the same value as 39
the status parameter returned by the MCPS-DATA.confirm primitive. 40
If the device receiving the NLME-LEAVE.request primitive is a ZigBee end 41
device, then the device shall send a leave command frame using the MCPS- 42
DATA.request primitive with the DstAddr parameter set to the 16-bit network 43
44
45
address of its parent device, indicating a MAC unicast. The request and remove
children sub-fields of the command options field of the leave command frame 1
shall be set to 0. After transmission of the leave command frame, it shall issue a 2
NWK-LEAVE.confirm primitive to the higher layer with the DeviceAddress 3
parameter equal to NULL. The status parameter shall be SUCCESS if the leave 4
command frame was transmitted successfully. Otherwise, the status parameter of 5
the NLME-LEAVE.confirm shall have the same value as the status parameter 6
returned by the MCPS-DATA.confirm primitive. 7
8
3.7.1.8.2 Method for a Device to Remove Its Child from the Network 9
This sub-clause describes how a device can initiate the removal from the network 10
of one of its child devices in response to the receipt of an NLME-LEAVE.request 11
primitive from the next higher layer as shown in Figure 3.32. 12
13
14
15
16
17
18
19
20
21
22
23
24
25
Figure 3.32 Procedure for a Device to Remove Its Child 26
27
On receipt, by the NWK layer of a ZigBee coordinator or ZigBee router, of the 28
NLME-LEAVE.request primitive with the DeviceAddress parameter equal to the 29
64-bit IEEE address of a child device, if the Silent parameter of the NLME- 30
LEAVE.request primitive has a value of FALSE, the device shall send a network 31
leave command frame using the MCPS-DATA.request primitive with the DstAddr 32
parameter set to the 16-bit network address of that child device. The request sub- 33
field of the command options field of the leave command frame shall have a value 34
of 1, indicating a request to leave the network. The value of the remove children 35
sub-field of the command options field of the leave command shall reflect the 36
value of the RemoveChildren parameter of the NLME-LEAVE.request primitive, 37
and the value of the Rejoin sub-field of the leave command shall reflect the value 38
of the Rejoin parameter of the NLME-LEAVE.request primitive. 39
40
If the Silent parameter has a value of TRUE the device shall not send a network 41
leave command frame. 42
The NWK layer shall then issue the NLME-LEAVE.confirm primitive with the 43
DeviceAddress parameter set to the 64-bit IEEE address of the child device being 44
45
Chapter 3
removed and with a status of SUCCESS or, if a network leave command was
transmitted and the transition was unsuccessful, with the same value as the status 1
parameter returned by the MCPS-DATA.indication primitive. 2
3
After the child device has been removed, the NWK layer of the parent should 4
modify its neighbor table, and any other internal data structures that refer to the 5
child device, to indicate that the device is no longer on the network. It is an error 6
for the next higher layer to address and transmit frames to a child device after that 7
device has been removed. 8
If the ReuseAddress parameter of the NLME-LEAVE.request primitive has a 9
value of TRUE then the address formerly in use by the device being asked to leave 10
may be assigned to another device that joins subsequently. 11
12
ZigBee end devices have no child devices to remove and should not receive 13
NLME-LEAVE.request primitives with non-NULL DeviceAddress parameters. 14
3.7.1.8.3 Upon Receipt of the Leave Command Frame 15
16
Upon receipt of the leave command frame by the NWK layer via the MCPS- 17
DATA.indication primitive, as shown in Figure 3.33, the device shall check the 18
value of the request sub-field of the command options field of the command 19
frame. If the request sub-field has a value of 0 then the NWK layer shall issue the 20
NLME-LEAVE.indication primitive to the next higher layer with the device 21
address parameter equal to the value contained in the Leaving Device IEEE 22
Address subfield of the leave command frame. The device should also modify its 23
neighbor table, and any other internal data structures that refer to the leaving 24
device, to indicate that it is no longer on the network. It is an error for the next 25
higher layer to address and transmit frames to a device after that device has left 26
the network. 27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Figure 3.33 On Receipt of a Leave Command 16
17
If, on receipt, by the NWK layer of a ZigBee router, of a leave command frame as 18
described above, the SrcAddr parameter of the MCPS-DATA.indication that 19
delivered the command frame is the 16-bit network address of the parent of the 20
recipient, and either the value of the request sub-field of the command options 21
field is found to have a value of 1 or the value of the remove children sub-field of 22
the command options field is found to have a value of 1 then the recipient shall 23
send a leave command frame using the MCPS-DATA.request primitive with the 24
DstAddr parameter set to 0xffff indicating a MAC broadcast. The request subfield 25
of the command options field of the leave command frame shall be set to 0. 26
The value of the remove children sub-field of the command options field of the 27
outgoing leave command shall reflect the value of the same field for the incoming 28
leave command frame. After transmission of the leave command frame it shall 29
issue a NLME-LEAVE.indication primitive to the higher layer with 30
DeviceAddress parameter equal to NULL. 31
32
If the request sub-field has a value of 1 and the source of the leave command 33
frame is a device other than the parent of the recipient, the frame shall be 34
immediately and silently discarded. 35
If a ZigBee end device receives a leave command frame as described above and 36
the SrcAddr parameter of the MCPS-DATA.indication that delivered the 37
command frame is the 16-bit network address of the parent of the recipient, the 38
receiver shall issue a NLME-LEAVE.indication primitive to the higher layer with 39
DeviceAddress parameter equal to NULL. 40
41
The NWK layer may employ retry techniques, as described in sub-clause 3.7.5 to 42
enhance the reliability of the leave procedure but, beyond this note, these 43
mechanisms are outside the scope of this specification. 44
45
Chapter 3
3.7.1.9 Changing the ZigBee Coordinator Configuration

1
If the next higher layer of a ZigBee coordinator device wishes to change the 2
configuration of the network, it shall request that the MAC sub-layer instigate the 3
changes in its PIB. The ZigBee coordinator configuration is composed of the 4
following items: 5
6
• Whether or not the device wishes to be the ZigBee parent
7
• The beacon order of the MAC superframe 8
9
• The superframe order of the MAC superframe
10
• Whether or not battery life extension mode is to be used 11
12
A change to the ZigBee coordinator configuration is initiated by issuing the
13
NLME-NETWORK-FORMATION.request primitive to the NLME. The status of
14
the attempt is communicated back via the NLME-NETWORK-
15
FORMATION.confirm primitive.
16
For more details on the impact of such changes imposed on the MAC sub-layer 17
see IEEE 802.15.4-2003 [B1]. 18
19
3.7.1.10 Resetting a Device 20
21
The NWK layer of a device shall be reset immediately following initial power-up, 22
before a join attempt and after a leave attempt. This process should not be initiated 23
at any other time. A reset is initiated by issuing the NLME-RESET.request 24
primitive to the NLME and the status of the attempt is communicated back via the 25
NLME-RESET.confirm primitive. The reset process shall clear the routing table 26
entries of the device. 27
Some devices may store NWK layer quantities in non-volatile memory and 28
restore them after a reset. However, a device shall discard its network address 29
after the reset. Such a device shall look for an association and get a network 30
address from its parent. The new network address may be different from its old 31
network address. In such a case, any device that is communicating with the device 32
that has been reset must rediscover the device using higher-layer protocols and 33
procedures out of the scope of this specification. 34
35
36
3.7.2 Transmission and Reception 37
38
3.7.2.1 Transmission 39
Only those devices that are currently associated shall send data frames from the 40
NWK layer. If a device that is not associated receives a request to transmit a 41
frame, it shall discard the frame and notify the higher layer of the error by issuing 42
an NLDE-DATA.confirm primitive with a status of INVALID_REQUEST. 43
44
45
All frames handled by or generated within the NWK layer shall be constructed
according to the general frame format specified in Figure 3.5 and transmitted 1
using the MAC sub-layer data service. 2
3
In addition to source address and destination address fields, all NWK layer 4
transmissions shall include a radius field and a sequence number field. For data 5
frames originating at a higher layer, the value of the radius field may be supplied 6
using the Radius parameter of the NLDE-DATA.request primitive. If a value is 7
not supplied, then the radius field of the NWK header shall be set to twice the 8
value of the nwkMaxDepth attribute of the NWK IB (see clause 3.6). The NWK 9
layer on every device shall maintain a sequence number that is initialized with a 10
random value. The sequence number shall be incremented by 1, each time the 11
NWK layer constructs a new NWK frame, either as a result of a request from the 12
next higher layer to transmit a new NWK data frame or when it needs to construct 13
a new NWK layer command frame. After being incremented, the value of the 14
sequence number shall be inserted into the sequence number field of the frame's 15
NWK header. 16
Once an NPDU is complete, if security is required for the frame, it shall be passed 17
to the security service provider for subsequent processing according to the 18
specified security suite (see sub-clause 4.2.3). Security processing is not required 19
if the SecurityEnable parameter of the NLDE-DATA.request is equal to FALSE. If 20
the NWK security level as specified in nwkSecurityLevel is equal to 0, or if the 21
frame originated at the higher layer and the nwkSecureAllFrames NIB attribute is 22
set to 0x00, then the security sub-field of the frame control field shall always be 23
set to 0. 24
25
On successful completion of the secure processing, the security suite returns the 26
frame to the NWK layer for transmission. The processed frame will have the 27
correct auxiliary header attached. If security processing of the frame fails and the 28
frame was a data frame, the frame will inform the higher layer of the NLDE- 29
DATA.confirm primitive’s status. If security processing of the frame fails and the 30
frame is a network command frame, it is discarded and no further processing shall 31
take place. 32
When the frame is constructed and ready for transmission, it shall be passed to the 33
MAC data service. An NPDU transmission is initiated by issuing the MCPS- 34
DATA.request primitive to the MAC sub-layer. The MCPS-DATA.confirm 35
primitive then returns the results of the transmission. 36
37
3.7.2.2 Reception and Rejection 38
39
In order to receive data, a device must enable its receiver. The next higher layer 40
may initiate reception using the NLME-SYNC.request primitive. On a beacon- 41
enabled network, receipt of this primitive by the NWK layer will cause a device to 42
synchronize with its parent’s next beacon and, optionally, to track future beacons. 43
The NWK layer shall accomplish this by issuing an MLME-SYNC.request to the 44
45
Chapter 3
MAC sub-layer. On a non-beacon-enabled network the NLME-SYNC.request

will cause the NWK layer to poll the device’s parent using the MLME- 1
POLL.request primitive. 2
3
On a non-beacon-enabled network, the NWK layer on a ZigBee coordinator or 4
ZigBee router shall ensure, to the maximum extent feasible, that the receiver is 5
enabled whenever the device is not transmitting. On a beacon-enabled network, 6
the NWK layer should ensure that the receiver is enabled when the device is not 7
transmitting during the active period of its own superframe and of its parent’s 8
superframe. The NWK layer may use the macRxOnWhenIdle attribute of the 9
MAC PIB for this purpose. 10
Once the receiver is enabled, the NWK layer will begin to receive frames via the 11
MAC data service. On receipt of each frame, the radius field of the NWK header 12
shall be decremented by 1. If, as a result of being decremented, this value falls to 13
0, the frame shall not, under any circumstances, be retransmitted. It may, however, 14
be passed to the next higher layer or otherwise processed by the NWK layer as 15
outlined elsewhere in this specification. The following data frames shall be passed 16
to the next higher layer using the NLDE-DATA.indication primitive: 17
18
• Frames with a broadcast address that matches a broadcast group of which the 19
device is a member 20
• Unicast data frames and source-addressed data frames for which the destination 21
address matches the device's network address 22
23
• Multicast data frames whose group ID is listed in the nwkGroupIDTable 24
If the receiving device is a ZigBee coordinator or an operating ZigBee router, that 25
is, a router that has already invoked the NLME-START-ROUTER.request 26
primitive, it shall process data frames as follows: 27
28
• Broadcast and multicast data frames shall be relayed according to the 29
procedures outlined in sub-clauses 3.7.5 and 3.7.6. 30
• Unicast data frames with a destination address that does not match the device's 31
network address shall be relayed according to the procedures outlined in sub- 32
clause 3.7.3.3. (Under all other circumstances, unicast data frames shall be 33
discarded immediately.) 34
35
• Source routed data frames with a destination address that does not match the 36
device’s network address shall be relayed according to the procedures outlined 37
in sub-clause 3.7.3.3.2. 38
• The procedure for handling route request command frames is outlined in sub- 39
clause 3.7.3.4.2. 40
41
The procedure for handling route reply command frames for which the destination 42
address matches the device's network address is outlined in sub-clause 3.7.3.4.3. 43
44
45
• Route reply command frames for which the destination address does not match
the device's network address shall be discarded immediately. Route error 1
command frames shall be handled in the same manner as data frames. 2
3
The NWK layer shall indicate the receipt of a data frame to the next higher layer 4
using the NLDE-DATA.indication primitive. 5
On receipt of a frame, the NLDE shall check the value of the security sub-field of 6
the frame control field. If this value is non-zero, the NLDE shall pass the frame to 7
the security service provider (see 4.2.3) for subsequent processing according to 8
the specified security suite. If the security sub-field is set to 0, the 9
nwkSecurityLevel attribute in the NIB is non-zero and the incoming frame is a 10
NWK command frame, the NLDE shall discard the frame. If the security sub-field 11
is set to 0, the nwkSecurityLevel attribute in the NIB is non-zero and the incoming 12
frame is a NWK data frame, the NLDE shall check the nwkSecureAllFrames NIB 13
attribute. If this attribute is set to 0x01, the NLDE shall only accept the frame if it 14
is destined to itself, that is, if it does not need to be forwarded to another device. 15
16
17
3.7.3 Routing 18
19
ZigBee coordinators and routers shall provide the following functionality: 20
• Relay data frames on behalf of higher layers 21
22
• Relay data frames on behalf of other ZigBee routers 23
• Participate in route discovery in order to establish routes for subsequent data 24
frames 25
26
• Participate in route discovery on behalf of end devices 27
• Participate in end-to-end route repair 28
29
• Participate in local route repair 30
• Employ the ZigBee path cost metric as specified in route discovery and route 31
repair 32
33
ZigBee coordinators or routers may provide the following functionality: 34
• Maintain routing tables in order to remember best available routes 35
36
• Initiate route discovery on behalf of higher layers 37
• Initiate route discovery on behalf of other ZigBee routers 38
39
• Initiate end-to-end route repair 40
• Initiate local route repair on behalf of other ZigBee routers 41
42
43
44
45
Chapter 3
3.7.3.1 Routing Cost

1
The ZigBee routing algorithm uses a path cost metric for route comparison during 2
route discovery and maintenance. In order to compute this metric, a cost, known 3
as the link cost, is associated with each link in the path and link cost values are 4
summed to produce the cost for the path as a whole. 5
6
More formally, if we define a path P of length L as an ordered set of
7
devices [ D 1, D 2 …DL ] and a link, [ Di, Di + 1 ] as a sub-path of length 2, then the path 8
cost 9
10
L–1
11
C{ P} = ∑ C { [ D i, D i + 1 ] } 12
where each
i = 1 of the values C { [ Di, D i + 1 ] } is referred to as a link cost. The link cost 13
C{l} for a link l is a function with values in the interval [ 0…7 ] defined as: 14
15
16
⎧7,
⎪ 17
C{l} = ⎨ ⎛ ⎛ 1 ⎞⎞ 18
⎜ ⎟
⎪min⎜ 7, round⎜⎜ p 4 ⎟⎟ ⎟ 19
⎩ ⎝ ⎝ l ⎠ ⎠ 20
21
22
where pl is defined as the probability of packet delivery on the link l.
23
Thus, implementers may report a constant value of 7 for link cost or they may 24
report a value that reflects the probability pl of reception — specifically, the 25
reciprocal of that probability — which should, in turn, reflect the number of 26
expected attempts required to get a packet through on that link each time it is 27
used. A device that offers both options may be forced to report a constant link cost 28
by setting the value of the NIB attribute nwkReportConstantCost to TRUE. 29
30
The question that remains, however, is how pl is to be estimated or measured. This
31
is primarily an implementation issue and implementers are free to apply their
32
ingenuity. pl may be estimated over time by actually counting received beacon
33
and data frames and observing the appropriate sequence numbers to detect lost
34
frames. This is generally regarded as the most accurate measure of reception
35
probability. However, the most straightforward method, available to all, is to form
36
estimates based on an average over the per-frame LQI value provided by the IEEE
37
802.15.4-2003 MAC and PHY. Even if some other method is used, the initial cost
38
estimates shall be based on average LQI. A table-driven function may be used to
39
map average LQI values onto C{l} values. It is strongly recommended that
40
implementers check their tables against data derived from tests on production
41
hardware, as inaccurate costs will hamper the operating ability of the ZigBee
42
routing algorithm.
43
44
45
3.7.3.2 Routing Tables

1
A ZigBee router or ZigBee coordinator may maintain a routing table. The 2
information that shall be stored in a ZigBee routing table is shown in Table 3.46. 3
The aging and retirement of routing table entries in order to reclaim table space 4
from entries that are no longer in use is a recommended practice; it is, however, 5
out of scope of this specification. 6
Table 3.46 Routing Table 7
8
Field Name Size Description 9
Destination address 2 bytes The 16-bit network address or Group ID of this route; If the
10
destination device is a ZigBee router or ZigBee coordinator, 11
this field shall contain the actual 16-bit address of that device; 12
If the destination device is an end device, this field shall 13
contain the 16-bit network address of that device’s parent 14
Status 3 bits The status of the route. See Table 3.47 for values 15
16
Many-to-one 1 bit A flag indicating that the destination is a concentrator that
issued a many-to-one route request 17
18
Route record 1 bit A flag indicating that a route record command frame should 19
required be sent to the destination prior to the next data packet
20
GroupID flag 1 bit A flag indicating that the destination address is a Group ID 21
Next-hop address 2 bytes The 16-bit network address of the next hop on the way to the 22
destination 23
24
Table 3.47 enumerates the values for the route status field. 25
26
Table 3.47 Route Status Values 27
Numeric Value Status 28
29
0x0 ACTIVE 30
0x1 DISCOVERY_UNDERWAY 31
32
0x2 DISCOVERY_FAILED
33
0x3 INACTIVE 34
0x4 VALIDATION_UNDERWAY 35
36
0x5 – 0x7 Reserved
37
38
This section describes the routing algorithm. The term “routing table capacity” is 39
used to describe a situation in which a device has the ability to use its routing table 40
to establish a route to a particular destination device. A device is said to have 41
routing table capacity if: 42
• It is a ZigBee coordinator or ZigBee router 43
44
45
Chapter 3
• It maintains a routing table

1
• It has a free routing table entry or it already has a routing table entry 2
corresponding to the destination 3
If a ZigBee router or ZigBee coordinator maintains a routing table it shall also 4
maintain a route discovery table containing the information shown in Table 3.48. 5
Routing table entries are long-lived and persistent, while route discovery table 6
entries last only as long as the duration of a single route discovery operation and 7
may be reused. 8
9
Table 3.48 Route Discovery Table
10
Field Name Size Description 11
12
Route request ID 1 byte A sequence number for a route request command frame that is 13
incremented each time a device initiates a route request
14
Source address 2 bytes The 16-bit network address of the route request’s initiator 15
Sender address 2 bytes The 16-bit network address of the device that has sent the most 16
recent lowest cost route request command frame corresponding to 17
this entry’s Route request identifier and Source address; This field 18
is used to determine the path that an eventual route reply command 19
frame should follow
20
Forward Cost 1 byte The accumulated path cost from the source of the route request to 21
the current device 22
Residual cost 1 byte The accumulated path cost from the current device to the 23
Expiration time 2 bytes A countdown timer indicating the number of milliseconds until 25
route discovery expires; The initial value is 26
nwkcRouteDiscoveryTime 27
28
A device is said to have “route discovery table capacity” if: 29
30
• It maintains a route discovery table 31
• It has a free entry in its route discovery table 32
33
If a device has both routing table capacity and route discovery table capacity then 34
it may be said to have “routing capacity.” 35
If a device has the capability to initiate a many-to-one route request, it shall also 36
maintain a source route table. 37
38
3.7.3.3 Upon Receipt of a Unicast Data Frame 39
40
On receipt of a unicast data frame, either from the MAC sub-layer or from the 41
next higher layer, the NWK layer routes it according to the following procedure. 42
43
44
45
If the receiving device is a ZigBee router or ZigBee coordinator and the

destination of the frame is a ZigBee end device and also the child of the receiving 1
device, the frame shall be routed directly to the destination using the MCPS- 2
DATA.request primitive, as described in sub-clause 3.7.2.1. The frame shall also 3
set the next hop destination address equal to the final destination address. 4
Otherwise, for purposes of the ensuing discussion, define the routing address of a 5
device to be its short address if it is a router or the coordinator, or the short address 6
of its parent if it is an end device. Define the routing destination of a frame to be 7
the routing address of the frame’s NWK destination. Note that ZigBee address 8
assignment makes it possible to derive the routing address of any device from its 9
address. See sub-clause 3.7.1.5 for details. 10
11
A device that has routing capacity shall check its routing table for an entry 12
corresponding to the routing destination of the frame. If there is such an entry , 13
and if the value of the route status field for that entry is ACTIVE or 14
VALIDATION_UNDERWAY, the device shall relay the frame using the MCPS- 15
DATA.request primitive and set the route status field of that entry to ACTIVE if it 16
does not already have that value. If the route record required field of the routing 17
table entry is set to TRUE, and the frame being relayed was initiated locally or by 18
a child end device, the device shall first initiate a route record command frame 19
to the destination as specified in sub-clause 3.7.3.4.4. 20
When relaying a data frame, the SrcAddrMode and DstAddrMode parameters of 21
the MCPS-DATA.request primitive shall both have a value of 0x02, indicating 16- 22
bit addressing. The SrcPANId and DstPANId parameters shall both have the value 23
provided by the macPANId attribute of the MAC PIB for the relaying device. The 24
SrcAddr parameter will be set to the value of macShortAddress from the MAC 25
PIB of the relaying device, and the DstAddr parameter shall be the value provided 26
by the next-hop address field of the routing table entry corresponding to the 27
routing destination. The TxOptions parameter should always be non-zero when 28
bitwise ANDed, with the value 0x01, indicating acknowledged transmission. If 29
the device has a routing table entry corresponding to the routing destination of the 30
frame but the value of the route status field for that entry is 31
DISCOVERY_UNDERWAY, the frame shall be treated as though route discovery 32
has been initiated for this frame, as described in sub-clause 3.7.3.4.1. The frame 33
may optionally be buffered pending route discovery or routed along the tree using 34
hierarchical routing, provided that the NIB attribute nwkUseTreeRouting has a 35
value of TRUE. If the frame is routed along the tree, the discover route sub-field 36
of the NWK header frame control field shall be set to 0x00. 37
38
If the device has a routing table entry corresponding to the routing destination of 39
the frame but the route status field for that entry has a value of 40
DISCOVERY_FAILED or INACTIVE, the device may route the frame along the 41
tree using hierarchical routing. Again, provided that the NIB attribute 42
nwkUseTreeRouting has a value of TRUE. If the device does not have a routing 43
table entry for the routing destination with a status value of ACTIVE, and it 44
45
Chapter 3
received the frame from the next higher layer, it shall check its source route table
for an entry corresponding to the routing destination. If such an entry is found, the 1
device shall transmit the frame using source routing as described in sub- 2
clause 3.7.3.3.1. If the device does not have a routing table entry for the routing 3
destination and it is not originating the frame using source routing, it shall 4
examine the discover route sub-field of the NWK header frame control field. If 5
the discover route sub-field has a value of 0x01, the device shall initiate route 6
discovery, as described in sub-clause 3.7.3.4.1. If the discover route sub-field has 7
a value of 0 and the NIB attribute nwkUseTreeRouting has a value of TRUE then 8
the device shall route along the tree using hierarchical routing. If the discover 9
route sub-field has a value of 0, the NIB attribute nwkUseTreeRouting has a value 10
of FALSE and there is no routing table corresponding to the routing destination of 11
the frame, the frame shall be discarded and the NLDE shall issue the NLDE- 12
DATA.confirm primitive with a Status value of ROUTE_ERROR. 13
14
A device without routing capacity shall route along the tree using hierarchical 15
routing provided that the value of the NIB attribute nwkUseTreeRouting is TRUE. 16
For hierarchical routing, if the destination is a descendant of the device, the device 17
shall route the frame to the appropriate child. If the destination is a child, and it is 18
also an end device, delivery of the frame can fail due to the macRxOnWhenIdle 19
state of the child device. If the child has macRxOnWhenIdle set to FALSE, 20
indirect transmission as described in IEEE 802.15.4-2003 [B1] may be used be 21
used to deliver the frame. If the destination is not a descendant, the device shall 22
route the frame to its parent. 23
24
Every other device in the network is a descendant of the ZigBee coordinator and 25
no device in the network is the descendant of any ZigBee end device. For a 26
ZigBee router with address A at depth d, if the following logical expression is true, 27
then a destination device with address D is a descendant: 28
A < D < A + Cskip ( d – 1 ) 29
30
For a definition of Cskip ( d ) , see sub-clause 3.7.1.5. 31
If it is determined that the destination is a descendant of the receiving device, the 32
address N of the next hop device is given by: 33
34
N = D 35
for ZigBee end devices, where D > A + Rm × Cskip ( d ) , and otherwise: 36
37
38
⎢ D − ( A + 1) ⎥ 39
N = A +1+ ⎢ ⎥ × Cskip (d ) 40
⎣ Cskip (d ) ⎦ 41
42
If the NWK layer on a ZigBee router or ZigBee coordinator fails to deliver a
43
unicast or multicast data frame for any reason, the router or coordinator shall
44
45
make its best effort to report the failure. This reporting may take one of two forms.
If the failed data frame was being relayed as a result of a request from the next 1
higher layer, then the NWK layer shall issue an NLME-ROUTE- 2
ERROR.indication to the next higher layer. The value of the ShortAddr parameter 3
of the primitive shall be the intended destination of the frame. If the frame was 4
being relayed on behalf of another device, then the relaying device shall both 5
issue the NLME-ROUTE-ERROR.indication primitive and send a route error 6
command frame back to the source of the data frame. The destination address 7
field of the route error command frame shall be taken from the destination address 8
field of the failed data frame. 9
10
In either case, the reasons for failure that may be reported appear in Table 3.39. 11
3.7.3.3.1 Originating a Source Routed Data Frame 12
13
On receipt of a data frame from the next higher layer, the device shall transmit the 14
frame using source routing under the conditions described in sub-clause 3.7.3.3. 15
The source route shall be retrieved from the source route table. 16
17
If there are no intermediate relay nodes, the frame shall be transmitted directly to 18
the routing destination without source routing by using the MCPS-DATA.request 19
primitive, with the DstAddr parameter value indicating the routing destination. 20
If there is at least one relay node, the source route flag of the NWK header frame 21
control field shall be set, and the NWK header source route subframe shall be 22
present. The relay count sub-field of the source route subframe shall have a value 23
equal to the number of relays in the relay list. The relay index sub-field shall have 24
a value equal to 1 less than the number of relays. The relay list sub-field shall 25
contain the list of relay addresses, least significant byte first. The relay closest to 26
the destination shall be listed first. The relay closest to the originator shall be 27
listed last. 28
29
The device shall relay the frame using the MCPS-DATA.request primitive. The 30
DstAddr parameter shall have the value of the final relay address in the relay list. 31
3.7.3.3.2 Relaying a Source Routed Data Frame 32
33
To relay a source routed data frame received from the MAC sub-layer as 34
described in sub-clause 3.7.3.3, the device shall search the relay list sub-field of 35
the NWK header source route subframe for its short address. If the short address is 36
not found, or if its index in the relay list does not match the value of the relay 37
index sub-field, the frame shall be discarded and no further action shall be taken. 38
If the relay index sub-field has a value of 0, the device shall relay the frame 39
directly to the NWK header destination using the MCPS-DATA.request primitive. 40
41
If the relay index sub-field has a value other than 0, the device shall decrement the 42
relay index sub-field by 1, and relay the frame to the address immediately prior to 43
its own address in the relay list sub-field. 44
45
Chapter 3
3.7.3.4 Route Discovery

1
Route discovery is the procedure whereby network devices cooperate to find and 2
establish routes through the NWK. Unicast route discovery is always performed 3
with regard to a particular source device and a particular destination device. 4
Multicast route discovery is performed with respect to a particular source device 5
and multicast group. Many-to-one route discovery is performed by a source device 6
to establish routes to itself from all ZigBee routers and ZigBee coordinators 7
within a given radius. Throughout sub-clause 3.7.3.4 a destination address may 8
be a 16-bit broadcast address, the 16-bit NWK address of a particular device or a 9
16-bit multicast address, also known as a multicast group ID. A route request 10
command whose destination address is the routing address of a particular device 11
and whose route request option field does not have the multicast bit set, is a 12
unicast route request. A route request command whose route request option field 13
has the multicast bit set is a multicast route request. The destination address field 14
of a multicast route request shall be a multicast group ID. A route request 15
command payload whose destination address sub-field is a broadcast address (see 16
Table ) is a many-to-one route request. The multicast bit in the route request 17
option field of a many-to-one route request shall be set to 0. 18
19
3.7.3.4.1 Initiation of Route Discovery
20
The unicast route discovery procedure for a device shall be initiated on a ZigBee 21
router or ZigBee coordinator by the NWK layer on receipt of an NLDE-ROUTE- 22
DISCOVERY.request primitive from the next higher layer where the 23
DstAddrMode parameter has a value of 0x00; Or, on receipt of an NLDE- 24
DATA.request primitive from a higher layer with the DstAddrMode set to 0x00 25
and the discover route sub-field set to 0x01 for which there is no routing table 26
entry corresponding to the routing address of the destination device, the 16-bit 27
network address indicated by the DstAddr parameter; Or, on receipt of a frame 28
from the MAC sub-layer for which the value of the destination address field in the 29
NWK header is not the address of the current device, the address of an end-device 30
child of the current device, or a broadcast address and in which the discover route 31
sub-field of the frame control field has a value of 0x01 and there is no routing 32
table entry corresponding to the routing destination of the frame. In any of these 33
cases, if the device does not have routing capacity and the NIB attribute 34
nwkUseTreeRouting has a value of TRUE, the data frame in question shall be 35
routed along the tree using hierarchical routing. If the device does not have 36
routing capacity and the NIB attribute nwkUseTreeRouting has a value of FALSE, 37
then the frame shall be discarded and the NWK shall generate a NLME-ROUTE- 38
ERROR.indication or route error command frame as described in 3.7.3.6. 39
40
The route discovery procedure for a multicast address shall be initiated by the 41
NWK layer either in response to the receipt of an NLME-ROUTE- 42
44
45
DstAddrMode parameter has a value of 0x01, or as specified in sub-

clause 3.7.6.1.2. 1
2
If the device initiating route discovery has no routing table entry corresponding to 3
the routing address of the destination device, it shall establish a routing table entry 4
with status equal to DISCOVERY_UNDERWAY. If the device has an existing 5
routing table entry corresponding to the routing address of the destination with 6
status equal to ACTIVE or VALIDATION _UNDERWAY, that entry shall be used 7
and the status field of that entry shall retain its current value. If it has an existing 8
routing table entry with a status value other than ACTIVE, that entry shall be used 9
and the status of that entry shall be set to DISCOVERY_UNDERWAY. The 10
device shall also establish the corresponding route discovery table entry if one 11
does not already exist. 12
Each device issuing a route request command frame shall maintain a counter used 13
to generate route request identifiers. When a new route request command frame is 14
created, the route request counter is incremented and the value is stored in the 15
device’s route discovery table in the Route request identifier field. Other fields in 16
the routing table and route discovery table are set as described in sub- 17
clause 3.7.3.2. 18
19
The NWK layer may choose to buffer the received frame pending route discovery 20
or, if the frame is a unicast frame and the NIB attribute nwkUseTreeRouting has a 21
value of TRUE, set the discover route sub-field of the frame control field in the 22
NWK header to 0 and forward the data frame along the tree. 23
Once the device creates the route discovery table and routing table entries, the 24
route request command frame shall be created with the payload depicted in 25
Figure 3.12. The individual fields are populated as follows: 26
27
• The command frame identifier field shall be set to indicate the command frame 28
is a route request, see Table 3.38. 29
• The Route request identifier field shall be set to the value stored in the route 30
discovery table entry. 31
32
• The multicast flag and destination address fields shall be set in accordance to 33
the destination address for which the route is to be discovered. 34
• The path cost field shall be set to 0. 35
36
Once created the route request command frame is ready for broadcast and is 37
passed to the MAC sub-layer using the MCPS-DATA.request primitive. 38
When broadcasting a route request command frame at the initiation of route 39
discovery, the NWK layer shall retry the broadcast nwkcInitialRREQRetries times 40
after the initial broadcast, resulting in a maximum of nwkcInitialRREQRetries + 1 41
transmissions. The retries will be separated by a time interval of 42
nwkcRREQRetryInterval milliseconds. 43
44
45
Chapter 3
The many-to-one route discovery procedure shall be initiated by the NWK layer
of a ZigBee router or coordinator on receipt of an NLME-ROUTE- 1
DstAddrMode parameter has a value of 0x00. It is not necessary for the device to 3
create a route table entry in this case. A route request command frame with 4
destination address set to the broadcast address 0xffff shall be created and 5
broadcast as described in this sub-clause. 6
7
3.7.3.4.2 Upon Receipt of a Route Request Command Frame 8
Upon receipt of a route request command frame, if the device is an end-device, it 9
shall drop the frame. Otherwise, it shall determine if it has routing capacity. 10
11
If the device does not have routing capacity and the route request is a multicast 12
route request or a many-to-one-route request, the route request shall be discarded 13
and route request processing shall be terminated. 14
If the device does not have routing capacity and the route request is a unicast route 15
request, the device shall check if the frame was received along a valid path. A path 16
is valid if the frame was received from one of the device’s child devices and the 17
source device is a descendant of that child device, or if the frame was received 18
from the device’s parent device and the source device is not a descendant of the 19
device. If the route request command frame was not received along a valid path, it 20
shall be discarded. Otherwise, the device shall check if it is the intended 21
destination. It shall also check if the destination of the command frame is one of 22
its end-device children by comparing the destination address field of the route 23
request command frame payload with the address of each of its end-device 24
children, if any. If either the device or one of its end-device children is the 25
destination of the route request command frame, it shall reply with a route reply 26
command frame. When replying to a route request with a route reply command 27
frame, the device shall construct a frame with the frame type field set to 0x01. The 28
route reply’s source address shall be set to the 16-bit network address of the 29
device creating the route reply and the destination address shall be set to the 30
calculated next hop address, considering the originator of the route request as a 31
destination. The link cost from the next hop device to the current device shall be 32
computed as described in sub-clause 3.7.3.1 and inserted into the path cost field of 33
the route reply command frame. The route reply command frame shall be unicast 34
to the next hop device by issuing an MCPS-DATA.request primitive. 35
36
If the device is not the destination of the route request command frame, the device 37
shall compute the link cost from the previous device that transmitted the frame, as 38
described in sub-clause 3.7.3.1. This value shall be added to the path cost value 39
stored in the route request command frame. The route request command frame 40
shall then be unicast towards the destination using the MCPS-DATA.request 41
service primitive. The next hop for this unicast transmission is determined in the 42
same manner as if the frame were a data frame addressed to the device identified 43
by the destination address field in the payload. 44
45
If the device does have routing capacity and the received request is a unicast route
request, the device shall check if it is the destination of the command frame by 1
comparing the destination address field of the route request command frame 2
payload with its own address. It shall also check if the destination of the command 3
frame is one of its end-device children by comparing the destination address field 4
of the route request command frame payload with the address of each of its end- 5
device children, if any. If either the device or one of its end-device children is the 6
destination of the route request command frame, the device shall determine if a 7
route discovery table (see Table 3.48) entry exists with the same route request 8
identifier and source address field. If no such entry exists, one shall be created. 9
10
If the device does have routing capacity and the multicast sub-field of route 11
request command options field of the received route request frame indicates a 12
multicast route request, the device shall determine whether an entry already exists 13
in the nwkGroupIDTable for which the GroupID field matches the destination 14
address field of the frame. If a matching entry is found, the device shall determine 15
if a route discovery table (see Table 3.48) entry exists with the same route request 16
identifier and source address field. If no such entry exists, one shall be created. 17
When creating the route discovery table entry, the fields are set to the 18
corresponding values in the route request command frame. The only exception is 19
the forward cost field, which is determined by using the previous sender of the 20
command frame to compute the link cost, as described in sub-clause 3.7.3.1, and 21
adding it to the path cost contained the route request command frame. The result 22
of the above calculation is stored in the forward cost field of the newly created 23
route discovery table entry. If the nwkSymLink attribute is set to TRUE, the device 24
shall also create a routing table entry with the destination address field set to the 25
source address of the route request command frame and the next hop field set to 26
the address of the previous device that transmitted the command frame. The status 27
field shall be set to ACTIVE. The device shall then issue a route reply command 28
frame to the source of the route request command frame. In the case that the 29
device already has a route discovery table entry for the source address and route 30
request identifier pair, the device shall determine if the path cost in the route 31
request command frame is less than the forward cost stored in the route discovery 32
table entry. The comparison is made by first computing the link cost from the 33
previous device that sent this frame, as described in sub-clause 3.7.3.1, and adding 34
it to the path cost value in the route request command frame. If this value is 35
greater than the value in the route discovery table entry, the frame shall be 36
dropped and no further processing is required. Otherwise, the forward cost and 37
sender address fields, in the route discovery table, are updated with the new cost 38
and the previous device address from the route request command frame. 39
40
If the nwkSymLink attribute is set to TRUE and the received route request 41
command frame is a unicast route request, the device shall also create a routing 42
table entry with the destination address field set to the source address of the route 43
request command frame and the next hop field set to the address of the previous 44
45
Chapter 3
device that transmitted the command frame. The status field shall be set to
ACTIVE. The device shall then respond with a route reply command frame. In 1
either of these cases, if the device is responding on behalf of one of its end-device 2
children, the responder address in the route reply command frame payload shall 3
be set equal to the address of the end device child and not of the responding 4
device. 5
6
When a device with routing capacity is not the destination of the received route 7
request command frame, it shall determine if a route discovery table entry (see 8
Table 3.48) exists with the same route request identifier and source address field. 9
If no such entry exists, one shall be created. The route request timer shall be set to 10
expire in nwkcRouteDiscoveryTime milliseconds. If a routing table entry 11
corresponding to the routing address of the destination exists and its status is not 12
ACTIVE, the status shall be set to DISCOVERY_UNDERWAY. If no such entry 13
exists and the frame is a unicast route request, an entry shall be created and its 14
status set to DISCOVERY_UNDERWAY. If the nwkSymLink attribute is set to 15
TRUE, or the frame is a many-to-one route request, the device shall also create a 16
routing table entry with the destination address field equal to the source address of 17
the route request command frame by setting the next hop field to the address of 18
the previous device that transmitted the command frame. If the frame is a many- 19
to-one route request, the many-to-one field and route table entry shall be set to 20
TRUE, and if the next hop field changed, the route record required field shall be 21
set to TRUE. The status field shall be set to ACTIVE. When the route vrequest 22
timer expires, the device deletes the route request entry from the route discovery 23
table. When this happens, the routing table entry corresponding to the routing 24
address of the destination shall also be deleted, if its status field has a value of 25
DISCOVERY_UNDERWAY and there are no other entries in the route discovery 26
table created as a result of a route discovery for that destination address. If an 27
entry in the route discovery table already exists, the path cost in the route request 28
command frame shall be compared to the forward cost value in the route 29
discovery table entry. The comparison is made by computing the link cost from 30
the previous device, as described in sub-clause 3.7.3.1, and adding it to the path 31
cost value in the route request command frame. If this path cost is greater, the 32
route request command frame is dropped and no further processing is required. 33
Otherwise, the forward cost and sender address fields in the route discovery table 34
are updated with the new cost and the previous device address from the route 35
request command frame. Additionally, the path cost field in the route request 36
command frame shall be updated with the cost computed for comparison 37
purposes. If the nwkSymLink attribute is set to TRUE and the received route 38
request command frame is a unicast route request, the device shall also update any 39
routing table entry with the destination address field set to the source address of 40
the route request command frame and the next hop field set to the address of the 41
previous device that transmitted the command frame. The status field shall be set 42
43
44
45
to ACTIVE. The device shall then rebroadcast the route request command frame
using the MCPS-DATA.request primitive. 1
2
When rebroadcasting a route request command frame, the NWK layer shall delay 3
retransmission by a random jitter amount calculated using the formula: 4
2 × R [ nwkcMinRREQJitter ,nwkcMaxRREQJitter ] 5
6
where R [ a, b ] is a random function on the interval [ a, b ] . The units of this jitter 7
amount are milliseconds. Implementers may adjust the jitter amount so that route 8
request command frames arriving with large path cost are delayed more than 9
frames arriving with lower path cost. The NWK layer shall retry the broadcast 10
nwkcRREQRetries times after the original relay resulting in a maximum of 11
nwkcRREQRetries + 1 relays per relay attempt. Implementers may choose to 12
discard route request command frames awaiting retransmission in the case that a 13
frame with the same source and route request identifier arrives with a lower path 14
cost than the one awaiting retransmission. 15
The device shall also set the status field of the routing table entry corresponding to 16
the routing address of the destination field in the payload to 17
DISCOVERY_UNDERWAY. If no such entry exists, it shall be created. 18
19
When replying to a route request with a route reply command frame, a device that 20
has a route discovery table entry corresponding to the source address and route 21
request identifier of the route request shall construct a command frame with the 22
frame type field set to 0x01. The source address field of the network header shall 23
be set to the 16-bit network address of the current device and the destination 24
address field shall be set to the value of the sender address field from the 25
corresponding route discovery table entry. The device constructing the route reply 26
shall populate the payload fields in the following manner. The NWK command 27
identifier shall be set to route reply. The route request identifier field shall be set 28
to the same value found in the route request identifier field of the route request 29
command frame. The originator address field shall be set to the source address in 30
the network header of route request command frame. Using the sender address 31
field from the route discovery table entry corresponding to the source address in 32
the network header of route request command frame, the device shall compute the 33
link cost as described in sub-clause 3.7.3.1. This link cost shall be entered in the 34
path cost field. The route reply command frame is then unicast to the destination 35
by using MCPS-DATA.request primitive and the sender address obtained from the 36
route discovery table as the next hop. 37
3.7.3.4.3 Upon Receipt of a Route Reply Command Frame 38
39
On receipt of a route reply command frame, a device performs the following 40
procedure. 41
If the receiving device has no routing capacity and its NIB attribute 42
nwkUseTreeRouting has a value of TRUE, it shall forward the route reply using 43
44
45
Chapter 3
tree routing. If the receiving device has no routing capacity and its NIB attribute
nwkUseTreeRouting has a value of FALSE, it shall discard the command frame. 1
Before forwarding the route reply command frame the device shall update the 2
path cost field in the payload by computing the link cost from the next hop device 3
to itself as described in sub-clause 3.7.3.1 and adding this to the value in the route 4
reply path cost field. 5
6
If the receiving device has routing capacity, it shall check whether it is the 7
destination of the route reply command frame by comparing the contents of the 8
originator address field of the command frame payload with its own address. If so, 9
it shall search its route discovery table for an entry corresponding to the route 10
request identifier in the route reply command frame payload. If there is no such 11
entry, the route reply command frame shall be discarded and route reply 12
processing shall be terminated. If a route discovery table entry exists, the device 13
shall search its routing table for an entry with a destination address field equal to 14
the routing address corresponding to the responder address in the route reply 15
command frame. If there is no such routing table entry the route reply command 16
frame shall be discarded and, if a route discovery table entry corresponding to the 17
route request identifier in the route reply command frame exists, it shall also be 18
removed, and route reply processing shall be terminated. If a routing table entry 19
and a route discovery table entry exist and if the status field of the routing table 20
entry is set to DISCOVERY_UNDERWAY, it shall be changed to 21
VALIDATION_UNDERWAY if the routing table entry’s GroupId flag is TRUE 22
and to ACTIVE otherwise; the next hop field in the routing table shall be set to the 23
previous device that forwarded the route reply command frame. The residual cost 24
field in the route discovery table entry shall be set to the path cost field in the route 25
reply payload. 26
If the status field was already set to ACTIVE or VALIDATION_UNDERWAY, the 27
device shall compare the path cost in the route reply command frame to the 28
residual cost recorded in the route discovery table entry, and update the residual 29
cost field and next hop field in the routing table entry if the cost in the route reply 30
command frame is smaller. If the path cost in the route reply is not smaller, the 31
route reply shall be discarded and no further processing shall take place. 32
33
If the device receiving the route reply is not the destination, the device shall find 34
the route discovery table entry corresponding to the originator address and route 35
request identifier in the route reply command frame payload. If no such route 36
discovery table entry exists, the route reply command frame shall be discarded. If 37
a route discovery table entry exists, the path cost value in the route reply 38
command frame and the residual cost field in the route discovery table entry shall 39
be compared. If the route discovery table entry value is less than the route reply 40
value, the route reply command frame shall be discarded. 41
Otherwise, the device shall find the routing table entry with a destination address 42
field equal to the routing address corresponding to the responder address in the 43
44
45
route reply command frame. It is an error here if the route discovery table entry
exists and there is no corresponding routing table entry, and the route reply 1
command frame should be discarded. The routing table entry shall be updated by 2
replacing the next hop field with the address of the previous device that forwarded 3
the route reply command frame. The route discovery table entry shall also be 4
updated by replacing the residual cost field with the value in the route reply 5
command frame. 6
7
Whenever the receipt of a route reply causes the next hop field of the 8
corresponding route table entry to be modified, and the route table entry's GroupId 9
flag is TRUE, the device shall set the expiration time field of the corresponding 10
route discovery table entry to expire in nwkcWaitBeforeValidation milliseconds if 11
the device is the destination of the route reply and nwkcRouteDiscoveryTime 12
milliseconds if it is not. 13
After updating its own route entry, the device shall forward the route reply to the 14
destination. Before forwarding the route reply, the path cost value shall be 15
updated. The sender shall find the next hop to the route reply’s destination by 16
searching its route discovery table for the entry matching the route request 17
identifier and the source address and extracting the sender address. It shall use this 18
next hop address to compute the link cost as described in sub-clause 3.7.3.1. This 19
cost shall be added to the path cost field in the route reply. The destination address 20
in the command frame network header shall be set to the next hop address and the 21
frame shall be unicast to the next hop device using the MCPS-DATA.request 22
primitive.The DstAddr parameter of the MCPS-DATA.request primitive shall be 23
set to the next-hop address from the route discovery table. 24
25
3.7.3.4.4 Initiation and Processing of a Route Record Command Frame 26
As described in sub-clause 3.7.3.3, if a device is forwarding a unicast data 27
message and the route record required field of the destination’s route table entry 28
has a value of TRUE, then the device shall unicast a route record command to the 29
destination, and if it is transmitted successfully to the next hop, the route record 30
required field of the routing table entry shall be set to FALSE. 31
32
Each relay node that receives the route record command shall append its network 33
address to the command payload, increment the relay count, and forward the 34
message. If the route record command is transmitted successfully to the next hop, 35
the route record required field of the destination’s route table entry shall be set to 36
FALSE. If no next hop is available, or if delivery to the next hop fails, or if there is 37
insufficient space in the payload for the id, the command frame shall be discarded 38
and the NWK will inform the next higher layer using the NLME-ROUTE- 39
ERROR.indication primitive. 40
Upon receipt of the route record command by the destination, the route shall be 41
stored in the source route table. Any existing source routes to the message source 42
or intermediary nodes shall be replaced by the new route information. 43
44
45
Chapter 3
3.7.3.5 Upon Expiration of a Route Discovery Table Entry

1
When a route discovery table entry is created the expiration timer shall be set to 2
expire in nwkcRouteDiscoveryTime milliseconds. For entries whose GroupId flag 3
is TRUE, when a route reply is received that causes the next hop to change, the 4
expiration time field of the corresponding route discovery table entry is set to 5
expire in nwkcWaitBeforeValidation milliseconds if the device is the destination of 6
the route reply and nwkcRouteDiscoveryTime milliseconds if it is not. When the 7
timer expires, the device shall delete the route request entry from the route 8
discovery table. If the device is the originator of the route request and the routing 9
table entry corresponding to the destination address has a Status field value of 10
VALIDATION_UNDERWAY, then the device shall transmit a message to validate 11
the route, either one buffered pending route discovery or a route error command 12
with a error code of 0x0a (validate route). If the routing table entry corresponding 13
to the destination address has any Status field value other than ACTIVE and there 14
are no other entries in the route discovery table with the same destination field 15
value, that routing table entry shall also be deleted. 16
17
3.7.3.6 Route Maintenance 18
19
A device NWK layer shall maintain a failure counter for each neighbor to which it 20
has an outgoing link, that is, to which it has been required to send data frames. If 21
the value of the outgoing link failure counter ever exceeds nwkcRepairThreshold 22
then the link is classified as a failed link and the device shall initiate route repair 23
as described in the following paragraphs. Implementers may choose a simple 24
failure-counting scheme to generate this failure counter value or they may use a 25
more accurate time-windowed scheme. Note that it is important not to initiate 26
repair too frequently since repair operations may flood the network and cause 27
other traffic disruptions. The procedure for retiring links and ceasing to keep track 28
of their failure counter is out of the scope of this specification. 29
3.7.3.6.1 Route Repair for Mesh Network Topology 30
31
If a failed link is encountered while a device is forwarding a source routed frame, 32
a route error with error code “Source route failure” shall be unicast back to the 33
source device, where it shall be passed up to the next higher layer using the 34
NLME-ROUTE-ERROR.indication primitive. 35
If a failed link is encountered while a device is forwarding a unicast data frame 36
using a routing table entry with the many-to-one field set to TRUE, a route error 37
with error code “Many-to-one route failure” shall be generated. The destination 38
address field in the NWK header of the route error command frame shall be equal 39
to the destination address field in the NWK header of the frame causing the error. 40
The destination address field of the route error command payload shall be equal to 41
the source address field in the NWK header of the frame causing the error. The 42
route error shall be unicast to a random router neighbor using the MCPS- 43
DATA.request primitive. Because it is a many-to-one route, all neighbors are 44
45
expected to have a route table entry to the destination. Upon receipt of the route
error frame, if no route table entry for the destination is present, or if delivery of 1
the route error to the next hop in the route table entry fails, the route error shall 2
again be unicast to a random router neighbor using the MCPS-DATA.request 3
primitive. The radius counter in the NWK header will limit the maximum number 4
of times the route error is relayed. Upon receipt of the route error frame by the 5
destination, it shall be passed up to the next higher layer using the NLME- 6
ROUTE-ERROR.indication primitive. The route is not automatically 7
rediscovered by the NWK layer. 8
9
If a failed link is encountered that is not part of a many-to-one route and the frame 10
being forwarded is not source routed, the upstream device shall initiate route 11
repair. If the upstream device is unable to initiate route repair due to a lack of 12
routing capacity or some other limitation, the device shall issue a route error 13
command frame back to the source device with the error code indicating the 14
reason for the failure (see Table 3.39), and issue an NLME-ROUTE- 15
ERROR.indication to the next higher layer. 16
If the upstream device is able to initiate route repair, it shall do so by broadcasting 17
a route request command frame with the source address set to its own address and 18
the destination address set to the destination address of the frame that failed in 19
transmission. The route request command frame shall have the route repair sub- 20
field in the command options field of the command frame payload set to 1 21
indicating route repair. 22
23
While a device is performing route repair for a particular destination, a device 24
shall not forward frames to that destination. Any frames that it has pending for 25
that destination at the time route repair is initiated and any frames for that 26
destination that arrive before the completion of route repair shall either be 27
buffered until the completion of route repair or discarded depending on the 28
capabilities of the device. 29
On receipt of a route request command frame a routing node shall perform the 30
procedure outlined in sub-clause 3.7.3.4.2. If the routing node is the destination of 31
the route request command frame or the destination is one of its end-device 32
children, it shall reply with a route reply command frame. The route reply 33
command frame shall have the route repair sub-field in the command options field 34
of the command frame payload set to 1 indicating route repair. 35
36
If a route reply command frame does not arrive at the upstream device within 37
nwkcRouteDiscoveryTime milliseconds, the upstream device shall send a route 38
error command frame to the source device. If the upstream device does receive a 39
route reply within the designated time, it will forward any data that it may have 40
buffered pending the repair to the destination. 41
If the source device receiving a route error command frame does not have routing 42
capacity and its NIB attribute nwkUseTreeRouting has a value of TRUE, it shall 43
44
45
Chapter 3
construct a route request command frame as described in sub-clause 3.7.3.4.1 and

unicast the command frame towards its destination along the tree using 1
hierarchical routing. If the source device does have routing capacity, it shall 2
initiate normal route discovery as described in sub-clause 3.7.3.4.1. If route 3
discovery fails, then the NWK shall issue the NLME_ROUTE-ERROR.indication 4
primitive to the next higher layer. 5
6
If an end device that is also an RFD encounters a failed link to its parent, the end 7
device shall inform the next higher layer using the NLME-ROUTE- 8
ERROR.indication primitive with a Status parameter value of 0x09 indicating 9
parent link failure (see Table 3.39). Similarly if a ZigBee router without routing 10
capacity for which nwkUseTreeRouting has a value of TRUE encounters a failed 11
link to its parent, it shall inform the next higher layer using the NLME-ROUTE- 12
ERROR.indication primitive with a Status parameter value of 0x09 indicating 13
parent link failure. 14
15
3.7.4 Scheduling Beacon Transmissions 16
17
Beacon scheduling is necessary in a multi-hop topology to prevent the beacon 18
frames of one device from colliding with either the beacon frames or data 19
transmissions of its neighboring devices. Beacon scheduling is necessary when 20
implementing a tree topology but not a mesh topology, as beaconing is not 21
permitted in ZigBee mesh networks. 22
23
3.7.4.1 Scheduling Method 24
25
The ZigBee coordinator shall determine the beacon order and superframe order 26
for every device in the network (see [B1] for more information on these 27
attributes). Because one purpose of multi-hop beaconing networks is to allow 28
routing nodes the opportunity to sleep in order to conserve power, the beacon 29
order shall be set much larger than the superframe order. Setting the attributes in 30
this manner makes it possible to schedule the active portion of the superframes of 31
every device in any neighborhood such that they are non-overlapping in time. In 32
other words, time is divided into approximately (macBeaconInterval/ 33
macSuperframeDuration) non-overlapping time slots, and the active portion of 34
the superframe of every device in the network shall occupy one of these non- 35
overlapping time slots. An example of the resulting frame structure for a single 36
beaconing device is shown in Figure 3.34. 37
38
39
40
41
42
43
44
45
Beacon Interval Beacon CAP 1

2
3
4
Inactive Period 5
Superframe Duration
6
7
Figure 3.34 Typical Frame Structure for a Beaconing Device 8
9
The beacon frame of a device shall be transmitted at the start of its non- 10
overlapping time slot, and the transmit time shall be measured relative to the 11
beacon transmit time of the parent device. This time offset shall be included in the 12
beacon payload of every device in a multi-hop beaconing network (see sub- 13
clause 3.7.7 for a complete list of beacon payload parameters). Therefore a device 14
receiving a beacon frame shall know the beacon transmission time of both the 15
neighboring device and the parent of the neighboring device, since the 16
transmission time of the parent may be calculated by subtracting the time offset 17
from the timestamp of the beacon frame. The receiving device shall store both the 18
local timestamp of the beacon frame and the offset included in the beacon payload 19
in its neighbor table. The purpose of having a device know when the parent of its 20
neighbor is active is to maintain the integrity of the parent-child communication 21
link by alleviating the hidden node problem. In other words, a device will never 22
transmit at the same time as the parent of its neighbor. 23
24
Communication in a tree network shall be accomplished using the parent-child 25
links to route along the tree. Since every child tracks the beacon of its parent, 26
transmissions from a parent to its child shall be completed using the indirect 27
transmission technique. Transmissions from a child to its parent shall be 28
completed during the CAP of the parent. Details for the communication 29
procedures can be found in IEEE 802.15.4-2003 [B1]. 30
A new device wishing to join the network shall follow the procedure outlined in 31
sub-clause 3.3.6. In the process of joining the network, the new device shall build 32
its neighbor table based on the information collected during the MAC scan 33
procedure. Using this information, the new device shall choose an appropriate 34
time for its beacon transmission and CAP (the active portion of its superframe 35
structure) such that the active portion of its superframe structure does not overlap 36
with that of any neighbor or of the parent of any neighbor. If there is no available 37
non-overlapping time slot in the neighborhood, the device shall not transmit 38
beacons and shall operate on the network as an end device. If a non-overlapping 39
time slot is available, the time offset between the beacon frames of the parent and 40
the new device shall be chosen and included in the beacon payload of the new 41
device. Any algorithm for selecting the beacon transmission time that avoids 42
beacon transmission during the active portion of the superframes of its neighbors 43
and their parents may be employed, as interoperability will be ensured. 44
45
Chapter 3
To counteract drift, the new device shall track the beacon of its parent and adjust
its own beacon transmission time such that the time offset between the two 1
remains constant. Therefore the beacon frames of every device in the network are 2
essentially synchronized with those of the ZigBee coordinator. Figure 3.35 3
illustrates the relationship between the active superframe portions of a parent and 4
its child. 5
6
7
8
9
10
11
Beacon Tracking 12
13
14
15
Beacon 16
Tx Offset 17
18
Figure 3.35 Parent-Child Superframe Positioning Relationship
19
20
The density of devices that can be supported in the network is inversely
21
proportional to the ratio of the superframe order to the beacon order. The smaller
22
the ratio, the longer the inactive period of each device and the more devices that
23
can transmit beacon frames in the same neighborhood. It is recommended that a
24
tree network utilize a superframe order of 0, which, when operating in the 2.4
25
GHz band, gives a superframe duration of 15.36 ms and a beacon order of
26
between 6 and 10, which, in the 2.4 GHz band, gives a beacon interval between
27
0.98304s and 15.72864s. Using these superframe and beacon order values, a
28
typical duty cycle for devices in the network will be between ~2% and ~0.1%
29
regardless of the frequency band.
30
3.7.4.2 MAC Enhancement 31
32
In order to employ the beacon scheduling algorithm just described, it is necessary 33
to implement the following enhancement to the IEEE Std 802.15.4-2003 MAC 34
sub-layer. 35
36
37
38
39
40
41
42
43
44
45
A new parameter, StartTime, shall be added to the MLME-START.request

primitive to specify the time to begin transmitting beacons. The new format of the 1
primitive is as follows: 2
3
MLME-START.request { 4
PANID, 5
LogicalChannel, 6
BeaconOrder, 7
SuperframeOrder, 8
PANCoordinator, 9
BatteryLifeExtention, 10
CoordRealignment,
11
12
SecurityEnable,
13
StartTime
14
} 15
16
The StartTime parameter is fully described in Table 3.49, and the description of all 17
other parameters can be found in IEEE 802.15.4-2003 [B1]. 18
Table 3.49 Start Time for Beacon Transmissions 19
20
StartTime Integer 0x000000 – 0xffffff The time at which to begin transmitting 22
beacons. If the device issuing the 23
primitive is the PAN coordinator, this 24
parameter is ignored and beacon 25
transmissions will begin immediately. 26
Otherwise, this parameter specifies the
time relative to its parent’s beacon. The 27
parameter is specified in symbols and is 28
rounded to a backoff slot boundary. The 29
precision of this value is a minimum of 30
20 bits, with the lowest 4 bits being the 31
least significant.
32
33
3.7.5 Broadcast Communication 34
35
This subclause specifies how a broadcast transmission is accomplished within a 36
ZigBee network. This mechanism is used to broadcast all network layer data 37
frames. Any device within a network may initiate a broadcast transmission 38
intended for a number of other devices that are part of the same network. A 39
broadcast transmission is initiated by the local APS sub-layer entity through the 40
41
42
43
44
45
Chapter 3
use of the NLDE-DATA.request primitive by setting the DstAddr parameter to a

broadcast address as shown in Table 3.50. 1
2
Table 3.50 Broadcast Addresses
3
Broadcast Address Destination Group 4
5
0xffff All devices in PAN 6
0xfffe Reserved 7
0xfffd macRxOnWhenIdle = TRUE 8
9
0xfffc All routers and coordinator 10
0xfff8-0xfffb Reserved 11
12
To transmit a broadcast MSDU, the NWK layer of a ZigBee router or ZigBee 13
coordinator issues an MCPS-DATA.request primitive to the MAC sub-layer with 14
the DstAddrMode parameter set to 0x02 (16-bit network address) and the 15
DstAddr parameter set to 0xffff. For a ZigBee end device, the MAC destination 16
address of the broadcast frame shall be set equal to the 16-bit network address of 17
the parent of the end device. The PANId parameter shall be set to the PANId of the 18
ZigBee network. This specification does not support broadcasting across multiple 19
networks. Broadcast transmissions shall not use the MAC sub-layer 20
acknowledgement; instead a passive acknowledgement mechanism may be used 21
in the case of non-beacon-enabled ZigBee networks. Passive acknowledgement 22
means that every ZigBee router and ZigBee coordinator keeps track if its 23
neighboring devices have successfully relayed the broadcast transmission. The 24
MAC sub-layer acknowledgement is disabled by setting the acknowledged 25
transmission flag of the TxOptions parameter to FALSE. All other flags of the 26
TxOptions parameter shall be set based on the network configuration. 27
28
The ZigBee coordinator and each ZigBee router shall keep a record of any new 29
broadcast transaction that is either initiated locally or received from a neighboring 30
device. This record is called the broadcast transaction record (BTR) and shall 31
contain at least the sequence number and the source address of the broadcast 32
frame. The broadcast transaction records are stored in the broadcast transaction 33
table (BTT). 34
When a device receives a broadcast frame from a neighboring device, it shall 35
compare the destination address of the frame with its device type. If the 36
destination address does not correspond to the device type of the receiver as 37
outlined in Table , the frame shall be discarded. If the destination address 38
corresponds to the device type of the receiver, the device will compare the 39
sequence number and the source address of the broadcast frame with the records 40
in its BTT. 41
42
If the device has a BTR of this particular broadcast frame in its BTT, it may 43
update the BTR to mark the neighboring device as having relayed the broadcast 44
45
frame. It shall then drop the frame. If no record is found, it shall create a new BTR
in its BTT and may mark the neighboring device as having relayed the broadcast. 1
The NWK layer shall then indicate to the higher layer that a new broadcast frame 2
has been received. If the radius field value is greater than 0 it shall retransmit the 3
frame. Otherwise it shall drop the frame. Before the retransmission, it shall wait 4
for a random time period called broadcast jitter. This time period shall be bounded 5
by the value of the nwkcMaxBroadcastJitter attribute. ZigBee end devices with 6
macRxOnWhenIdle equal to FALSE shall not participate in the relaying of 7
broadcast frames and need not maintain a BTT for broadcast frames that they 8
originate. 9
10
If, on receipt of a broadcast frame, the NWK layer finds that the BTT is full and 11
contains no expired entries, then the frame should be ignored. In this situation the 12
frame should not be retransmitted, nor should it be passed up to the next higher 13
layer. 14
A ZigBee coordinator or ZigBee router, operating in a non-beacon-enabled 15
ZigBee network, shall retransmit a previously broadcast frame at most 16
nwkMaxBroadcastRetries times. If the device does not support passive 17
acknowledgement then it shall retransmit the frame exactly 18
nwkMaxBroadcastRetries times. If the device supports passive acknowledgement 19
and any of its neighboring devices have not relayed the broadcast frame within 20
nwkPassiveAckTimeout seconds then it shall continue to retransmit the frame up 21
to a maximum of nwkMaxBroadcastRetries times. 22
23
A device should change the status of a BTT entry after 24
nwkNetworkBroadcastDeliveryTime seconds have elapsed since its creation. The 25
entry should change status to expired and thus the entry can be overwritten if 26
required when a new broadcast is received. 27
When a ZigBee router that has the macRxOnWhenIdle MAC PIB attribute set to 28
FALSE receives a broadcast transmission, it shall use a different procedure for 29
retransmission than the one outlined above. It shall retransmit the frame without 30
delay to each of its neighbors individually, using a MAC layer unicast, that is, 31
with the DstAddr parameter of the MCPS-DATA.request primitive set to the 32
address of the receiving device and not to the broadcast address. Similarly, a 33
router or coordinator with the macRxOnWhenIdle MAC PIB attribute set to 34
TRUE, which has one or more neighbors with the macRxOnWhenIdle MAC PIB 35
parameter set to FALSE, shall, in the case where the destination address is 0xffff 36
denoting broadcast to all devices, retransmit the broadcast frame to each of these 37
neighbors in turn as a MAC layer unicast in addition to performing the more 38
general broadcast procedure spelled out in the previous paragraphs. Indirect 39
transmission, as described in IEEE 802.15.4-2003 [B1], may be employed to 40
ensure that these unicasts reach their destination. 41
42
Every ZigBee router shall have the ability to buffer at least 1 frame at the NWK 43
layer in order to facilitate retransmission of broadcasts. 44
45
Chapter 3
Figure 3.36 shows a broadcast transaction between a device and two neighboring
devices. 1
2
3
Neighbor 1 Device Neigbor 2
4
NWK NWK NWK
5
6
Broadcast Transmission 7
Add new BTR 8
Mark neighbor 1 as having 9
relayed the message
10
Random 11
broadcast 12
delay 13
15
Mark device as having Add new BTR
relayed the message Mark device as having 16
relayed the message 17
Broadcast
18
Random 19
retry timer
broadcast
delay 20
21
23
Ignore
broadcast Mark neighbor 2 as having 24
relayed the message 25
26
27
28
29
30
Figure 3.36 Broadcast Transaction Message Sequence Chart
31
32
3.7.6 Multicast Communication 33
34
This sub-clause specifies how multicast transmission is accomplished within a 35
ZigBee network. Multicasts provide many-to-many routing. Multicast addressing 36
is done using 16-bit multicast group Ids. Each device has a multicast table 37
indicating which multicast groups that device is a member of. A multicast 38
message is sent to a particular destination group and is received by all devices that 39
list that group's ID in their multicast table. Only data frames are multicast; there 40
are no multicast command frames. Multicast frames have a mode flag that 41
indicates whether they are in non-member mode or member mode. Member mode 42
is used to propagate multicasts between the devices that are members of the 43
destination group. Member mode multicasts are recorded in the BTT as if they 44
45
were broadcasts. Non-member mode is used to transmit a multicast frame from a

device that is not a member of the multicast group to a device that is. Multicasts 1
transmitted by members of the destination multicast group are always in member 2
mode. Multicasts transmitted by non-members are in member mode if they have 3
previously been transmitted by a group member and in non-member mode if not. 4
5
3.7.6.1 Upon Receipt of a Multicast Frame from the Next 6
Higher Layer 7
8
If a data frame is received by the NWK layer from its next higher layer and the 9
multicast control field is 0x01, the NWK layer shall determine whether an entry 10
exists in the nwkGroupIDTable which group ID field matches the destination 11
group ID of the frame. If a matching entry is found, the NWK layer shall multicast 12
the frame according to the procedure outlined in sub-clause 3.7.6.1.1. If a 13
matching entry is not found, the frame shall be initiated as a non-member mode 14
multicast using the procedure outlined in sub-clause 3.7.6.1.2. 15
16
3.7.6.1.1 Initiating a Member Mode Multicast 17
The NWK layer shall set the multicast mode sub-field of the multicast control 18
field to 0x01 (member mode). If the BTT table is full and contains no expired 19
entries the message will not be sent and the NLDE shall issue the NLDE- 20
DATA.confirm primitive with a Status value of BT_TABLE_FULL. If the BTT is 21
not full or contains an expired BTR, a new BTR shall be created with the local 22
node as the source and the multicast frame's sequence number. The message will 23
then be transmitted according to the procedure described in the final paragraph of 24
sub-clause 3.7.6.2 25
26
3.7.6.1.2 Initiating a Non-member Mode Multicast 27
The NWK layer shall set the multicast mode sub-field of the multicast control 28
field to 0x00 (non-member mode). Then, the NWK layer shall check its routing 29
table for an entry corresponding to the GroupID destination of the frame. If there 30
is such an entry the NWK layer shall examine the entry's status field. If the status 31
is ACTIVE, then the device shall (re)transmit the frame. If the status is 32
VALIDATION_UNDERWAY, then the status shall be changed to ACTIVE, the 33
device shall transmit the frame according to the procedure described in the final 34
paragraph of sub-clause 3.7.6.3, and the NLDE shall issue the NLDE- 35
DATA.confirm primitive with the Status value received from the MCPS- 36
DATA.confirm primitive. If there is no routing table entry corresponding to the 37
GroupID destination of the frame and the value of the DiscoverRoute parameter is 38
0x00 (suppress route discovery), the frame shall be discarded and the NLDE shall 39
issue the NLDE-DATA.confirm primitive with a Status value of 40
ROUTE_DISCOVERY_FAILED. If the DiscoverRoute parameter has a value of 41
0x01 (enable route discovery) and there is no routing table entry corresponding to 42
the GroupID destination of the frame, then the device shall initiate route discovery 43
44
45
Chapter 3
immediately as described in sub-clause 3.7.3.4.1. The frame may optionally be

buffered pending route discovery. If it is not buffered the frame shall be discarded 1
and the NLDE shall issue the NLDE-DATA.confirm primitive with a Status value 2
of FRAME_NOT_BUFFERED. 3
4
3.7.6.2 Upon Receipt of a Member Mode Multicast Frame 5
6
When a device receives a member mode multicast frame from a neighboring 7
device, it shall compare the sequence number and the source address of the 8
multicast frame with the records in its BTT. If the device has a BTR of this 9
particular multicast frame in its BTT it shall discard the frame. If no record is 10
found and the BTT is full and contains no expired entries, it shall discard the 11
frame. If no record is found and the BTT is not full or contains an expired BTR, it 12
shall create a new BTR and continue processing the message as outlined in the 13
following paragraph. When a member mode multicast frame has been received 14
from a neighbor and added to the BTT, the NWK layer shall then determine 15
whether an entry exists in the nwkGroupIDTable whose group ID field matches 16
the destination group ID of the frame. If a matching entry is found, the message 17
will be passed to the next higher layer, the multicast control field shall be set to 18
0x01 (member mode), the value of the NonmemberRadius field will be set to the 19
value of the maximum NonmemberRadius field, and the message will be 20
transmitted as outlined in the following paragraph. If a matching entry is not 21
found the NWK layer shall examine the frame's multicast NonmemberRadius 22
field. If the value of the multicast NonmemberRadius field is 0 the message will 23
be discarded, along with the newly added BTR. Otherwise, the 24
NonmemberRadius field will be decremented if it is less than 0x07 and the frame 25
will be transmitted as outlined in following paragraphs. Each member mode 26
multicast message shall be transmitted nwkMaxBroadcastRetries times. For 27
member mode multicast frames that did not originate on the local device, the 28
initial transmission shall be delayed by a random time bounded by the value of the 29
nwkcMaxBroadcastJitter attribute. A device shall delay a period 30
nwkPassiveAckTimeout seconds between retransmissions of a particular member 31
mode multicast message. Unlike broadcasts, there is no passive acknowledgement 32
for multicasts. ZigBee end devices shall not participate in the relaying of multicast 33
frames. To transmit a member mode multicast MSDU, the NWK layer issues an 34
MCPS-DATA.request primitive to the MAC sub-layer with the DstAddrMode 35
parameter set to 0x02 (16-bit network address) and the DstAddr parameter set to 36
0xffff, which is the broadcast network address. The PANId parameter shall be set 37
to the PANId of the ZigBee network. Member mode multicast transmissions shall 38
not use the MAC sub-layer acknowledgement or the passive acknowledgement 39
used for broadcasts. The MAC sub-layer acknowledgement is disabled by setting 40
the acknowledged transmission flag of the TxOptions parameter to FALSE. All 41
other flags of the TxOptions parameter shall be set based on the network 42
configuration. 43
44
45
3.7.6.3 Upon Receipt of a Non-member Mode Multicast

1
Frame 2
When a device receives a non-member mode multicast frame from a neighboring 3
device, the NWK layer shall then determine whether an entry exists in the 4
nwkGroupIDTable which group ID field matches the destination group ID of the 5
frame. If a matching entry is found, the multicast control field shall be set to 0x01 6
(member mode) and the message shall be processed as if it had been received as a 7
member mode multicast. If no matching nwkGroupIDTable entry is found, the 8
device shall check its routing table for an entry corresponding to the GroupID 9
destination of the frame. If there is no such routing table entry, the message shall 10
be discarded. If there is such an entry, the NWK layer shall examine the entry's 11
status field. If the status is ACTIVE, then the device shall (re)transmit the frame. 12
If the status is VALIDATION_UNDERWAY, then the status shall be changed to 13
ACTIVE and the device shall (re)transmit the frame. To transmit a non-member 14
mode multicast MSDU, the NWK layer issues an MCPS-DATA.request primitive 15
to the MAC sublayer with the DstAddrMode parameter set to 0x02 (16-bit 16
network address) and the DstAddr parameter set to the next hop as determined 17
from the matching route table entry. The PANId parameter shall be set to the 18
PANId of the ZigBee network. The MAC sub-layer acknowledgement shall be 19
enabled by setting the acknowledged transmission flag of the TxOptions 20
parameter to TRUE. All other flags of the TxOptions parameter shall be set based 21
on the network configuration. 22
23
24
3.7.7 NWK Information in the MAC Beacons 25
26
This subclause specifies how the NWK layer uses the beacon payload of a MAC 27
sub-layer beacon frame to convey NWK layer-specific information to neighboring 28
devices. 29
When the association permit sub-field of the superframe specification field of the 30
beacon frame of the device, as defined in IEEE 802.15.4-2003 [B1], is set to 1 31
indicating that association is permitted, then the beacon payload shall contain the 32
information shown in Table 3.51. This enables the NWK layer to provide 33
additional information to new devices that are performing network discovery and 34
allows these new devices to more efficiently select a network and particular 35
neighbor to join. Refer to sub-clause 3.7.1.3.1.1 for a detailed description of the 36
network discovery procedure. This information is not required to be in the beacon 37
payload when the association permit sub-field of the superframe specification 38
39
40
41
42
43
44
45
Chapter 3
field of the beacon frame of the device is set to 0 indicating that association is not
permitted. 1
2
Table 3.51 NWK Layer Information Fields
3
5
Protocol ID Integer 0x00 – 0xff This field identifies the network 6
layer protocols in use and, for
purposes of this specification 7
shall always be set to 0, indicating 8
the ZigBee protocols; The value 9
0xff shall also be reserved for 10
future use by the ZigBee Alliance 11
Stack profile Integer 0x00 – 0x0f A ZigBee stack profile identifier 12
nwkcProtocolVersio Integer 0x00 – 0x0f The version of the ZigBee 13
n protocol 14
15
Router capacity Boolean TRUE or FALSE This value is set to TRUE if this
device is capable of accepting
16
join requests from router-capable 17
devices and is set to FALSE 18
otherwise. 19
Device depth Integer 0x00 – nwkMaxDepth The tree depth of this device. A 20
value of 0x00 indicates that this 21
device is the ZigBee coordinator 22
for the network 23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Table 3.51 NWK Layer Information Fields (Continued)

1
End device capacity Boolean TRUE or FALSE This value is set to TRUE if the 3
device is capable of accepting 4
join requests from end devices 5
seeking to join the network and is 6
set to FALSE otherwise
7
nwkExtendedPANID 64-bit 0x0000000000000001 The globally unique ID for the 8
Extended – 0xfffffffffffffffe PAN of which the beaconing 9
address device is a member. By default,
10
this is the 64-bit IEEE address of
the ZigBee coordinator that 11
formed the network, but other 12
values are possible and there is no 13
required structure to the address 14
TxOffset Integer 0x000000 – 0xffffff This value indicates the difference 15
in time, measured in symbols, 16
between the beacon transmission 17
time of the device and the beacon
18
transmission time of its parent;
This offset may be subtracted 19
from the beacon transmission 20
time of the device to calculate the 21
beacon transmission time of the 22
parent;
23
This parameter is only included 24
when implementing a multi-hop 25
beaconing network
26
27
The NWK layer of the ZigBee coordinator shall update the beacon payload 28
immediately following network formation. All other ZigBee devices shall update 29
it immediately after the join is completed and anytime the network configuration 30
(any of the parameters specified in Table 3.11) changes. The beacon payload is 31
written into the MAC sub-layer PIB using the MLME-SET.request primitive. The 32
macBeaconPayloadLength attribute is set to the length of the beacon payload, and 33
the byte sequence representing the beacon payload is written into the 34
macBeaconPayload attribute. The formatting of the byte sequence representing 35
the beacon payload is shown in Figure 3.37. 36
37
Bits:
0–7 8 – 11 12 – 15 16 – 17 18 19 – 22 23 24 – 87 88 – 111 38
39
Protocol Stack nwkcProtocol Reserved Router Device End nwk Tx Offset 40
ID profile Version capacity depth device Extended (optional) 41
capacity PANID
42
Figure 3.37 Format of the MAC Sub-Layer Beacon Payload 43
44
45
Chapter 3
3.7.7.1 Persistent Data

1
Devices operating in the field may be reset either manually or programmatically 2
by maintenance personnel, or may be reset accidentally for any number of 3
reasons, including localized or network-wide power failures, battery replacement 4
during the course of normal maintenance, impact and so on. At a minimum, the 5
following information should be preserved across resets in order to maintain an 6
operating network: 7
8
• The device's PAN Id and Extended PAN Id
9
• The device's 16-bit network address 10
11
• The 64-bit IEEE address and 16-bit network address of each associated child
12
• The stack profile in use 13
14
• The values of nwkNextAddress and nwkAvailableAddresses NIB attributes, if
15
the alternative addressing is in use
16
• The device's tree depth, if the distributed addressing scheme is in use 17
18
The method by which these data are made to persist is beyond the scope of this
19
specification.
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
C H A P T E R
1
4
2
3
4
5
6
7
8
9
CHAPTER 4SECURITY SERVICES SPECIFICATION 10

11
12
13
4.1 Document Organization 14
15
The remaining portions of this document specify in greater detail the various 16
security services available within the ZigBee stack. Basic definitions and 17
references are given in clause 4.2. A general description of the security services is 18
given in sub-clause 4.2.1. In this clause, the overall security architecture is 19
discussed; basic security services provided by each layer of this architecture are 20
introduced. Sub-clauses 4.2.2, 4.2.3, and 4.2.4 give the ZigBee Alliance’s security 21
specifications for the Medium Access Control (MAC) layer, the Network (NWK) 22
layer, and the Application Support Sublayer (APS) layer, respectively. These 23
clauses introduce the security mechanisms, give the primitives, and define any 24
frame formats used for security purposes. Clause 4.6 describes security elements 25
common to the MAC, NWK, and APS layers. Clause 4.7 provides a basic 26
functional description of the available security features. Finally, annexes provide 27
technical details and test vectors needed to implement and test the cryptographic 28
mechanisms and protocols used by the MAC, NWK, and APS layers. 29
30
31
33
34
Security services provided for ZigBee include methods for key establishment, key
35
transport, frame protection, and device management. These services form the
36
building blocks for implementing security policies within a ZigBee device.
37
Specifications for the security services and a functional description of how these
38
services shall be used are given in this document.
39
40
41
42
43
44
45
Chapter 4
386 Security Services Specification
4.2.1 Security Architecture and Design 1

2
In this clause, security architecture is described. Where applicable, this
3
architecture complements and makes use of the security services that are already
4
present in the IEEE Std. 802.15.4 802 [B1] security specification.
5
4.2.1.1 Security Assumptions 6
7
The level of security provided by the ZigBee security architecture depends on the 8
safekeeping of the symmetric keys, on the protection mechanisms employed, and 9
on the proper implementation of the cryptographic mechanisms and associated 10
security policies involved. Trust in the security architecture ultimately reduces to 11
trust in the secure initialization and installation of keying material and to trust in 12
the secure processing and storage of keying material. In the case of indirect 13
addressing, it is assumed that the binding manager is trusted. 14
15
Implementations of security protocols, such as key establishment, are assumed to 16
properly execute the complete protocol and do not leave out any steps hereof. 17
Random number generators are assumed to operate as expected. Furthermore, it is 18
assumed that secret keys do not become available outside the device in an 19
unsecured way. That is, a device will not intentionally or inadvertently transmit its 20
keying material to other devices, unless the keying material is protected, such as 21
during key-transport. An exception to this assumption occurs when a device that 22
has not been preconfigured joins the network. In this case, a single key may be 23
sent unprotected, thus resulting in a brief moment of vulnerability. 24
The following caveat in these assumptions applies: due to the low-cost nature of 25
ad hoc network devices, one cannot generally assume the availability of tamper- 26
resistant hardware. Hence, physical access to a device may yield access to secret 27
keying material and other privileged information and access to the security 28
software and hardware. 29
30
Due to cost constraints, ZigBee has to assume that different applications using the 31
same radio are not logically separated; for example, by using a firewall). In 32
addition, from the perspective of a given device, it is even not possible (barring 33
certification) to verify whether cryptographic separation between different 34
applications on another device, or even between different layers of the 35
communication stack hereof, is indeed properly implemented. Hence, one has to 36
assume that separate applications using the same radio trust each other; that is, 37
there is no cryptographic task separation. In addition, lower layers (for example, 38
APS, NWK, or MAC) are fully accessible by any of the applications. These 39
assumptions lead to an open trust model for a device; different layers of the 40
communication stack and all applications running on a single device trust each 41
other. 42
43
44
45
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
Another consideration is whether one is concerned with the ability of malevolent 15
network devices to use the network to transport frames across the network without 16
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 MAC layer disassociate 21
frame needs protection, MAC layer security shall be used. Likewise, if a NWK 22
command frame needs protection, NWK layer security shall be used. 23
24
• Second, if protection from theft of service is required (that is, malevolent 25
network devices), NWK layer security shall be used for all frames, except those 26
passed between a router and a newly joined device (until the newly joined 27
device receives the Network key). Thus, only a device that has joined the 28
network and successfully received the Network key will be able to have its 29
messages communicated more than one hop across the network. 30
• Third, due to the open trust model, security can be based on the reuse of keys 31
by each layer. For example, the active Network key shall be used to secure APS 32
layer broadcast frames, NWK layer frames, or MAC layer commands. Reuse of 33
keys helps reduce storage costs. 34
35
• Fourth, end-to-end security is enabled such as to make it possible that only 36
source and destination devices have access to their shared key. This limits the 37
trust requirement to those devices whose information is at stake. Additionally, 38
this ensures that routing of messages between devices can be realized 39
independent of trust considerations (thus, facilitating considerable separation of 40
concern). 41
• Fifth, to simplify interoperability of devices, the security level used by all 42
devices in a given network, and by all layers of a device, shall be the same if 43
44
45
Chapter 4
security is used. In particular, the security level indicated in the PIB and NIB
shall be the same. If an application needs more security for its payload than is 1
provided by a given network, it shall form its own separate network with a 2
higher security level. 3
4
There are several policy decisions which any real implementation must address 5
correctly. Application profiles should include policies to: 6
• Handle error conditions arising from securing and unsecuring packets. Some 7
error conditions may indicate loss of synchronization of security material, or 8
may indicate ongoing attacks; 9
10
• Detect and handle loss of counter synchronization and counter overflow; 11
• Detect and handle loss of key synchronization; 12
13
• Expire and periodically update keys, if desired. 14
15
4.2.1.3 Security Keys 16
Security amongst a network of ZigBee devices is based on ‘link’ keys and a 17
“network” key. Unicast communication between APL peer entities is secured by 18
means of a 128-bit link key shared by two devices, while broadcast 19
communications are secured by means of a 128-bit Network key shared amongst 20
all devices in the network. The intended recipient is always aware of the exact 21
security arrangement; that is, the recipient knows whether a frame is protected 22
with a link or a Network key. 23
24
A device shall acquire link keys either via key-transport, key-establishment, or 25
pre-installation (for example, during factory installation). A device shall acquire a 26
Network key via key-transport or pre-installation. The key-establishment 27
technique for acquiring a link key (see sub-clause 4.2.4.1) is based on a 'master' 28
key. A device shall acquire a master key (for purposes of establishing 29
corresponding link keys) via key-transport or pre-installation. Ultimately, security 30
between devices depends on the secure initialization and installation of these 31
keys. 32
In a secured network there are a variety of security services available. Prudence 33
dictates that one would like to avoid re-use of keys across different security 34
services, which otherwise may cause security leaks due to unwanted interactions. 35
As such, these different services use a key derived from a one-way function using 36
the link key (as specified in sub-clause 4.6.3). The use of uncorrelated keys 37
ensures the logical separation of executions of different security protocols. The 38
key-load key is used to protect transported master keys; the key-transport key is 39
used to protect other transported keys. The Network key may be used by the 40
MAC, NWK, and APL layers of ZigBee. As such, the same Network key and 41
associated outgoing and incoming frame counters shall be available to all of these 42
43
44
45
layers. The link and master keys may be used only by the APS sublayer. As such,
the link and master keys shall be available only to the APL layer. 1
2
4.2.1.4 ZigBee Security Architecture 3
4
ZigBee applications communicate using the IEEE 802.15.4 wireless standard 5
[B1], which specifies two layers, the Physical (PHY) and Medium Access Control 6
(MAC) layers. ZigBee builds on these layers a Network (NWK) layer and an 7
Application (APL) layer. The PHY layer provides the basic communication 8
capabilities of the physical radio. The MAC layer provides services to enable 9
reliable, single-hop communication links between devices. The ZigBee NWK 10
layer provides routing and multi-hop functions needed for creating different 11
network topologies; for example, star, tree, and mesh structures. The APL layer 12
includes an Application Support (APS) sublayer, the ZigBee Device 13
Object (ZDO), and applications. The ZDO is responsible for overall device 14
management. The APS layer provides a foundation for servicing the ZDO and 15
ZigBee applications. 16
The architecture includes security mechanisms at three layers of the protocol 17
stack. The MAC, NWK, and APS layers are responsible for the secure transport of 18
their respective frames. Furthermore, the APS sublayer provides services for the 19
establishment, and maintenance of security relationships. The ZigBee Device 20
Object (ZDO) manages the security policies and the security configuration of a 21
device. Figure 1.1 shows a complete view of the ZigBee protocol stack. The 22
security mechanisms provided by the APS and NWK layers are described in this 23
version of the specification, as is the processing of secure MAC frames. 24
25
26
4.2.2 MAC Layer Security 27
28
When a frame originating at the MAC layer needs to be secured, ZigBee shall use 29
MAC layer security as specified by the 802.15.4 specification [B1] and 30
augmented by clause 4.3. A security corrigendum proposal [B3] is being 31
developed to augment the MAC layer specification and include the security 32
elements needed by ZigBee. Specifically, at least one of ZigBee’s security needs 33
is the ability to protect incoming and outgoing frames using the security levels 34
based on CCM* (see sub-clause 4.6.2.1, and Table 4.30 for a description of 35
ZigBee security levels). CCM* is a minor modification of CCM specified in 36
Clause 7 and Annex B of the 802.15.4 MAC layer specification [B1]. CCM* 37
includes all of the features of CCM and additionally offers encryption-only and 38
integrity-only capabilities. These extra capabilities simplify security by 39
eliminating the need for CTR and CBC-MAC modes. Also, unlike other MAC 40
layer security modes which require a different key for every security level, the use 41
of CCM* enables the use of a single key for all CCM* security levels. With the 42
use of CCM* throughout the ZigBee stack, the MAC, NWK, and APS layers can 43
reuse the same key. 44
45
Chapter 4
The MAC layer is responsible for its own security processing, but the upper layers
shall determine which security level to use. For ZigBee, MAC layer frames 1
requiring security processing shall be processed using the security material from 2
the macDefaultSecurityMaterial or the macACLEntryDescriptorSet attributes of 3
the MAC PIB. The upper layer (for example, APL) shall set 4
macDefaultSecurityMaterial to coincide with the active Network key and 5
counters from the NWK layer and shall set macACLEntryDescriptorSet to 6
coincide with any link keys from the APS layer that are shared with neighboring 7
devices, for example, a parent and child. The security suite shall be CCM* and the 8
upper layers shall set the security level to coincide with the nwkSecurityLevel 9
attribute in the NIB. For ZigBee, MAC layer link keys shall be preferred, but if 10
not available, the default key (that is, macDefaultSecurityMaterial) shall be used. 11
Figure 4.1 shows an example of the security fields that may be included in an 12
outgoing frame with security applied at the MAC level. 13
14
15
Application of security suite adds auxiliary security 16
information, and may add an integrity code 17
18
PHY MAC Auxiliary 19
SYNC Encrypted MAC Payload MIC
HDR HDR HDR 20
21
22
When integrity protection is employed, the entire MAC frame is protected 23
24
Figure 4.1 ZigBee Frame with Security at the MAC Level 25
26
4.2.3 NWK Layer Security 27
28
When a frame originating at the NWK layer with nwkSecurityLevel > 0, or when 29
a frame originates at a higher layer and the nwkSecureAllFrames attribute in the 30
NIB is TRUE, ZigBee shall use the frame protection mechanism specified in sub- 31
clause 4.4.1 of this specification, unless the SecurityEnable parameter of the 32
NLDE-DATA.request primitive is FALSE, explicitly prohibiting security. Like the 33
MAC layer, the NWK layer's frame protection mechanism shall make use of the 34
Advanced Encryption Standard (AES) [B8] and use CCM* as specified in 35
Annex A. The security level applied to a NWK frame shall be given by the 36
nwkSecurityLevel attribute in the NIB. Upper layers manage NWK layer security 37
by setting up active and alternate Network keys and by determining which 38
security level to use. 39
40
One responsibility of the NWK layer is to route messages over multi-hop links.
41
As part of this responsibility, the NWK layer will broadcast route request
42
messages and process received route reply messages. Route request messages are
43
simultaneously broadcast to nearby devices and route reply messages originate
44
45
from nearby devices. If the appropriate link key is available, the NWK layer shall
use the link key to secure outgoing NWK frames. If the appropriate link key is not 1
available, in order to secure messages against outsiders the NWK layer shall use 2
its active Network key to secure outgoing NWK frames and either its active 3
Network key or an alternate Network key to secure incoming NWK frames. 4
5
In this scenario, the frame format explicitly indicates the key used to protect the 6
frame; Thus, intended recipients can deduce which key to use for processing an 7
incoming frame and also determine if the message is readable by all network 8
devices, rather than just by itself. 9
Figure 4.2 shows an example of the security fields that may be included in a NWK 10
frame. 11
12
13
Application of security suite adds auxiliary header 14
and also an integrity code
15
16
PHY MAC NWK Auxiliary 17
SYNC Encrypted NWK Payload MIC 18
HDR HDR HDR HDR
19
20
All of the above NWK frame is integrity-protected 21
22
Figure 4.2 ZigBee Frame with Security on the NWK Level 23
24
4.2.4 APL Layer Security 25
26
When a frame originating at the APL layer needs to be secured, the APS sublayer 27
shall handle security. The APS layer's frame protection mechanism is specified in 28
sub-clause 4.5.1 of this specification. The APS layer allows frame security to be 29
based on link keys or the Network key. Figure 4.3 shows an example of the 30
security fields that may be included in an APL frame. Another security 31
responsibility of the APS layer is to provide applications and the ZDO with key 32
establishment, key transport, and device management services. 33
34
35
36
37
38
39
40
41
42
43
44
45
Chapter 4
Application of security suite adds auxiliary header

and also an integrity code 1
2
3
SYNC
PHY MAC NWK APS Auxiliary
Encrypted APS Payload MIC 4
HDR HDR HDR HDR HDR
5
6
7
All of the above APS frame is integrity-protected
8
Figure 4.3 ZigBee Frame with Security on the APS Level 9
10
4.2.4.1 Key Establishment 11
12
The APS sublayer's key establishment services provide the mechanism by which a 13
ZigBee device may derive a shared secret key, the so-called link key (see sub- 14
clause 4.2.1.3), with another ZigBee device. Key establishment involves two 15
entities, an initiator device and a responder device, and is prefaced by a trust- 16
provisioning step. 17
18
Trust information (for example, a master key) provides a starting point for
19
establishing a link key and can be provisioned in-band or out-band. Once trust
20
information is provisioned, a key-establishment protocol involves three
21
conceptual steps:
22
• The exchange of ephemeral data; 23
24
• The use of this ephemeral data to derive the link key;
25
• The confirmation that this link key was correctly computed. 26
27
In the Symmetric-Key Key Establishment (SKKE) protocol, an initiator device
28
establishes a link key with a responder device using a master key. This master key,
29
for example, may be pre-installed during manufacturing, may be installed by a
30
trust center (for example, from the initiator, the responder, or a third party device
31
acting as a trust center), or may be based on user-entered data (for example, PIN,
32
password, or key). The secrecy and authenticity of the master key needs to be
33
upheld in order to maintain a trust foundation.
34
35
4.2.4.2 Transport Key
36
The transport-key service provides secured and unsecured means to transport a 37
key to another device or other devices. The secured transport-key command 38
provides a means to transport a master, link, or Network key from a key source 39
(for example, trust center) to other devices. The unsecured transport-key 40
command provides a means for loading a device with an initial key. This 41
command does not cryptographically protect the key being loaded. In this case, 42
the security of the transported key can be realized by non-cryptographic means, 43
44
45
for example, by communicating the command via an out-of-band channel that

guarantees secrecy and authenticity. 1
2
4.2.4.3 Update Device 3
4
The update-device service provides a secure means for a device (for example, a 5
router) to inform a second device (for example, a trust center) that a third device 6
has had a change of status that must be updated (for example, the device joined or 7
left the network). This is the mechanism by which the trust center maintains an 8
accurate list of active network devices. 9
10
4.2.4.4 Remove Device 11
The remove device service provides a secure means by which a device (for 12
example, a trust center) may inform another device (for example, a router) that 13
one of its children should be removed from the network. For example, this may be 14
employed to remove a device from the network that has not satisfied the trust 15
center’s security requirements for network devices. 16
17
4.2.4.5 Request Key 18
19
The request-key service provides a secure means for a device to request the 20
current Network key, or an end-to-end application master key, from another 21
device (for example, its trust center). 22
23
4.2.4.6 Switch Key 24
25
The switch-key service provides a secure means for a device (for example, a trust 26
center) to inform another device that it should switch to a different active Network 27
key. 28
29
4.2.5 Trust Center Role 30
31
For security purposes, ZigBee defines the role of trust center. The trust center is 32
the device trusted by devices within a network to distribute keys for the purpose of 33
network and end-to-end application configuration management. All members of 34
the network shall recognize exactly one trust center, and there shall be exactly one 35
trust center in each secure network. 36
37
In high-security, commercial applications (see sub-clause 4.7.2.1) a device can be 38
pre-loaded with the trust center address and initial master key (for example, via an 39
unspecified mechanism). Alternatively, if the application can tolerate a moment of 40
vulnerability, the master key can be sent via an in-band unsecured key transport. If 41
not pre-loaded, a device’s trust center defaults to the ZigBee coordinator or a 42
device designated by the ZigBee coordinator. 43
44
45
Chapter 4
In low-security, residential applications (see sub-clause 4.7.2.2) a device securely

communicates with its trust center using the Network key, which can be 1
preconfigured or sent via an in-band unsecured key transport. 2
3
The functions performed by the trust center can be subdivided into three sub- 4
roles: trust manager, network manager, and configuration manager. A device 5
trusts its trust manager to identify the device(s) that take on the role of its network 6
and configuration manager. A network manager is responsible for the network and 7
distributes and maintains the Network key to devices it manages. A configuration 8
manager is responsible for binding two applications and enabling end-to-end 9
security between devices it manages (for example, by distributing master keys or 10
link keys). To simplify trust management, these three sub-roles are contained 11
within a single device – the trust center. 12
For purposes of trust management, a device shall accept an initial master or 13
Network key originating from its trust center via unsecured key transport. For 14
purposes of network management, a device shall accept an initial Network key 15
and updated Network keys only from its trust center (that is, its network manager). 16
For purpose of configuration, a device shall accept master keys or link keys for 17
the purpose of establishing end-to-end security between two devices only from its 18
trust center (that is, its configuration manager). Aside from the initial master key, 19
additional link, master, and Network keys shall only be accepted if they originate 20
from a device’s trust center via secured key transport. 21
22
23
4.3 MAC Layer Security 24
25
The MAC layer is responsible for the processing steps needed to securely transmit 26
outgoing MAC frames and securely receive incoming MAC frames. Upper layers 27
control the security processing operations, by setting up the appropriate keys and 28
frame counters and establishing which security level to use. 29
30
31
4.3.1 Frame Security 32
33
The detailed steps involved in security processing of outgoing and incoming 34
MAC frames are described in sub-clauses 4.3.1.1 and 4.3.1.2, respectively. 35
36
4.3.1.1 Security Processing of Outgoing Frames 37
If the MAC layer has a frame requiring security protection, that consists of a 38
header MacHeader and payload Payload, it shall apply security as follows: 39
40
1 Obtain the security material (as specified in sub-clause 4.3.2), including the 41
key, outgoing frame counter FrameCount, key sequence count SeqCount, and 42
security level identifier (as specified in Table 4.30) from the MAC PIB using 43
the following procedure. If the outgoing frame counter has as its value the 4- 44
45
octet representation of the integer 232-1 or any of this security material cannot
be determined, then security processing shall fail and no further security 1
processing shall be done on this frame. 2
3
a First, an attempt shall be made to retrieve the security material and security 4
level identifier associated with the destination address of the outgoing frame 5
from the macACLEntryDescriptorSet attribute in the MAC PIB. 6
b If the first attempt fails, then security material shall be obtained by using the 7
macDefaultSecurityMaterial attribute from the MAC PIB and the security 8
level identifier shall be obtained from the MacDefaultSecuritySuite attribute 9
from the MAC PIB. 10
11
2 The Security Control Field SecField is the 1-octet field formatted as in sub- 12
clause 4.6.1.1, with the following settings: 13
a The security level subfield shall be set to the security level obtained in 14
step 1; 15
16
b The key identifier subfield shall be set to the 2-bit field '00'; 17
c The extended nonce subfield shall be set to the 1-bit field '0'; 18
19
d The reserved bits shall be set to the 2-bit field '00'. 20
3 Execute the CCM* mode encryption and authentication operation, as specified 21
in Annex A, with the following instantiations: 22
23
a The parameter M shall be obtained from Table 4.30 corresponding to the 24
security level from step 1; 25
b The bit string Key shall be the key obtained from step 1; 26
27
c The nonce N shall be the 13-octet string constructed using the local device’s 28
64-bit extended address, SecField from step 1, and FrameCount from step 1 29
(see Figure 72 from [B1]); 30
d If the security level requires encryption, the octet string a shall be the string 31
MacHeader and the octet string m shall be the string Payload. Otherwise, 32
the octet string a shall be the string MacHeader || Payload and the octet 33
string m shall be a string of length zero. Note that ZigBee interprets IEEE 34
Std. 802.15.4 802 [B1] to mean that frame counters are authenticated. 35
36
4 If the CCM* mode invoked in step 3 outputs ‘invalid’, security processing shall 37
fail and no further security processing shall be done on this frame. 38
5 Let c be the output from step 4. If the security level requires encryption, the 39
secured outgoing frame shall be MacHeader || FrameCount || SeqCount || c, 40
otherwise the secured outgoing frame shall be MacHeader || FrameCount || 41
SeqCount || Payload || c. 42
43
44
45
Chapter 4
6 If the secured outgoing frame size is greater than aMaxPHYPacketSize (from [B1]),
security processing shall fail and no further security processing shall be done 1
on this frame. 2
3
7 The outgoing frame counter from step 1 shall be incremented by one and stored 4
in the location from which the security material was obtained in step 1 (that is, 5
either the macDefaultSecurityMaterial attribute or the 6
MacDefaultSecuritySuite attribute). 7
8
4.3.1.2 Security Processing of Incoming Frames 9
If the MAC layer receives a secured frame (consisting of a header MacHeader, 10
frame count ReceivedFrameCount, sequence count ReceivedSeqCount, and 11
payload SecuredPayload) it shall perform security processing as follows: 12
13
1 If ReceivedFrameCount has as value the 4-octet representation of the integer 14
232-1, security processing shall fail and no further security processing shall be 15
done on this frame. 16
2 Obtain the security material (as specified in sub-clause 4.3.2), including the 17
key, optional external frame counter FrameCount, optional key sequence count 18
SeqCount, and security level identifier (as specified in Table 4.30) from the 19
MAC PIB using the following procedure. If the security material cannot be 20
obtained or if SeqCount exists and does not match ReceivedSeqCount, security 21
processing shall fail and no further security processing shall be done on this 22
frame. 23
24
a First, an attempt shall be made to retrieve the security material and security 25
level identifier associated with the source address of the incoming frame 26
from the macACLEntryDescriptorSet attribute in the MAC PIB. 27
b If the first attempt fails, then security material shall be obtained by using the 28
macDefaultSecurityMaterial attribute from the MAC PIB and the security 29
level identifier shall be obtained from the MacDefaultSecuritySuite attribute 30
from the MAC PIB. 31
32
3 If FrameCount exists and if ReceivedFrameCount is less than FrameCount, 33
on this frame. 35
4 The Security Control Field SecField is the 1-octet field formatted as in sub- 36
clause 4.6.1.1, Table 4.17, with the following settings: 37
38
a The security level subfield shall be set to the security level from the 39
MACPIB (as specified in Table 4.30); 40
b The key identifier subfield shall be set to the 2-bit field '00'; 41
42
c The extended nonce subfield shall be set to the 1-bit field '0'; 43
44
45
d The reserved bits shall be set to the 2-bit field '00'.

1
5 Execute the CCM* mode decryption and authentication checking operation, as 2
specified in sub-clause A.3, with the following instantiations: 3
6
c The nonce N shall be the 13-octet string constructed using the 64-bit 8
extended sender address, SecField from step 4, and ReceivedFrameCount 9
from step 1 (see Figure 72 from [B1]); The nonce N shall be formatted 10
according to the endianness convention used in this specification (the octet 11
containing the lowest numbered bits first to the octet containing the higher 12
numbered bits). 13
14
d Parse the octet string SecuredPayload as Payload1 || Payload2, where the 15
right-most string Payload2 is an M-octet string. If this operation fails, 16
on this frame; 18
e If the security level requires encryption, the octet string a shall be the string 19
MacHeader || ReceivedFrameCount || ReceivedSeqCount and the octet string 20
c shall be the string SecuredPayload. Otherwise, the octet string a shall be 21
the string MacHeader || ReceivedFrameCount || ReceivedSeqCount || 22
Payload1 and the octet string c shall be the string Payload2. 23
24
6 Return the results of the CCM* operation: 25
a If the CCM* mode invoked in step 5 outputs ‘invalid’, security processing 26
shall fail and no further security processing shall be done on this frame; 27
28
b Let m be the output of step 5. If the security level requires encryption, set the 29
octet string UnsecuredMacFrame to the string MACHeader || m. Otherwise, 30
set the octet string UnsecuredMacFrame to the string MACHeader || 31
Payload1. 32
7 If the optional FrameCount (obtained in step 2) exists, set it to 33
ReceivedFrameCount and update MAC PIB. UnsecuredMacFrame now 34
represents the unsecured received MAC layer frame. 35
36
37
4.3.2 Security-related MAC PIB Attributes 38
39
The security-related MAC PIB attributes shall be those as defined in Table 72 of 40
[B1]. The security material used for CCM* mode shall the same as given for 41
CCM mode in Figure 70 of IEEE Std. 802.15.4 802 [B1]. 42
43
44
45
Chapter 4
For the macDefaultSecurityMaterial attribute from the MAC PIB, the upper layer
shall set the symmetric key, outgoing frame counter, and optional external key 1
sequence counter equal to the corresponding elements of the network security 2
material descriptor in the nwkSecurityMaterialSet of the NIB referenced by the 3
nwkActiveKeySeqNumber attribute of the NIB. The optional external frame 4
counter shall not be used and the optional external key sequence counter shall 5
correspond to the sequence number of the Network key. 6
7
For the macACLEntryDescriptorSet attribute from the MAC PIB, the upper layer 8
shall set the symmetric key, and outgoing frame counter equal to the 9
corresponding elements of the Network key-pair descriptor in the 10
apsDeviceKeyPairSet of the AIB. The optional external frame counter shall be set 11
to the incoming frame counter, The key sequence counter shall be set to 0x00, and 12
the optional external key sequence counter shall not be used. 13
14
15
4.4 NWK Layer Security 16
17
The NWK layer is responsible for the processing steps needed to securely transmit 18
outgoing frames and securely receive incoming frames. Upper layers control the 19
security processing operations, by setting up the appropriate keys and frame 20
counters and establishing which security level to use. 21
22
24
The detailed steps involved in security processing of outgoing and incoming 25
NWK frames are described in sub-clauses 4.4.1.1 and 4.4.1.2, respectively. 26
27
29
If the NWK layer has a frame, consisting of a header NwkHeader and payload 30
Payload, that needs security protection and nwkSecurityLevel > 0, it shall apply 31
security as follows: 32
1 Obtain the nwkActiveKeySeqNumber from the NIB and use it to retrieve the 33
active Network key key, outgoing frame counter OutgoingFrameCounter, and 34
key sequence number KeySeqNumber from the nwkSecurityMaterialSet 35
attribute in the NIB. Obtain the security level from the nwkSecurityLevel 36
attribute from the NIB. If the outgoing frame counter has as its value the 4-octet 37
representation of the integer 232-1, or if the key cannot be obtained, security 38
frame. 40
41
2 Construct auxiliary header AuxiliaryHeader (see sub-clause 4.6.1): 42
a The security control field shall be set as follows: 43
44
45
i The security level sub-field shall be the security level obtained from
step 1. 1
2
ii The key identifier sub-field shall be set to ‘01’ (that is, the Network key). 3
iii The extended nonce sub-field shall be set to 1. 4
5
iv The source address field shall be set to the 64-bit extended address of the 6
local device. 7
b The frame counter field shall be set to the outgoing frame counter from 8
step 1. 9
10
c The key sequence number field shall be set to the sequence number from 11
step 1. 12
in Annex A, with the following instantiations: 14
15
19
c The nonce N shall be the 13-octet string constructed using the security 20
control field from step a, the frame counter field from step c, and the source 21
address field from step b (see sub-clause 4.6.2.2); 22
NwkHeader || AuxiliaryHeader and the octet string m shall be the string 24
Payload. Otherwise, the octet string a shall be the string NwkHeader || 25
AuxiliaryHeader || Payload and the octet string m shall be a string of length 26
zero. 27
28
secured outgoing frame shall be NwkHeader || AuxiliaryHeader || c, otherwise 32
the secured outgoing frame shall be NwkHeader || AuxiliaryHeader || Payload || 33
c. 34
35
6 If the secured outgoing frame size is greater than aMaxMACFrameSize (see 36
IEEE Std. 802.15.4 802 [B1]), security processing shall fail and no further 37
security processing shall be done on this frame. 38
7 The outgoing frame counter from step 1 shall be incremented by one and stored 39
in the OutgoingFrameCounter element of the network security material 40
descriptor referenced by the nwkActiveKeySeqNumber in the NIB; that is, the 41
outgoing frame counter value associated with the key used to protect the frame 42
is updated. 43
44
45
Chapter 4
8 Over-write the security level subfield of the security control field by the 3-bit
all-zero string '000'. 1
2
4
If the NWK layer receives a secured frame (consisting of a header NwkHeader, 5
auxiliary header AuxiliaryHeader, and payload SecuredPayload) as indicated by 6
the security sub-field of the NWK header frame control field it shall perform 7
security processing as follows: 8
1 Determine the security level from the nwkSecurityLevel attribute from the NIB. 9
Over-write the 3-bit security level subfield of the security control field of the 10
AuxillaryHeader with this value. Determine the sequence number 11
SequenceNumber, sender address SenderAddress, and received frame count 12
ReceivedFrameCount from the auxiliary header AuxiliaryHeader (see sub- 13
clause 4.6.1). If ReceivedFrameCounter has as value the 4-octet representation 14
of the integer 232-1, security processing shall fail and no further security 15
17
2 Obtain the appropriate security material (consisting of the key and other 18
attributes) by matching SequenceNumber to the sequence number of any key in 19
the nwkSecurityMaterialSet attribute in the NIB. If the SequenceNumber does 20
not equal nwkActiveKeySeqNumber, the neighbor table entry corresponding to 21
SenderAddress shall be modified to show that the network key is stale. If the 22
security material cannot be obtained, security processing shall fail and no 23
further security processing shall be done on this frame.16 24
3 If there is an incoming frame count FrameCount corresponding to 25
SenderAddress from the security material obtained in step 2, and if 26
ReceivedFrameCount is less than FrameCount, security processing shall fail 27
and no further security processing shall be done on this frame. 28
29
a The parameter M shall obtained from Table 4.30 corresponding to the 32
34
control, the frame counter, and the source address fields from 37
AuxiliaryHeader (see sub-clause 4.6.2.2). Note that the security level 38
subfield of the security control field has been overwritten in step 1 and now 39
contains the value determined from the nwkSecurityLevel attribute from the 40
NIB. 41
42
43
16. CCB #666 44
45
d Parse the octet string SecuredPayload as Payload1 || Payload2, where the

on this frame; 3
4
NwkHeader || AuxiliaryHeader and the octet string c shall be the string 6
SecuredPayload. Otherwise, the octet string a shall be the string NwkHeader 7
|| AuxiliaryHeader || Payload1 and the octet string c shall be the string 8
Payload2. 9
11
a If the CCM* mode invoked in step 4 outputs ‘invalid’, security processing 12
shall fail and no further security processing shall be done on this frame; 13
b Let m be the output of step 4. If the security level requires encryption, set the 14
octet string UnsecuredNwkFrame to the string NwkHeader || m. Otherwise, 15
set the octet string UnsecuredNwkFrame to the string NwkHeader || 16
Payload1. 17
18
6 Set FrameCount to (ReceivedFrameCount + 1) and store both FrameCount and 19
SenderAddress in the NIB. UnsecuredNwkFrame now represents the unsecured 20
received network frame and security processing shall succeed. So as to never 21
cause the storage of the frame count and address information to exceed the 22
available memory, the memory allocated for incoming frame counters needed 23
for NWK layer security shall be bounded by M*N, where M and N represent the 24
cardinality of nwkSecurityMaterialSet and nwkNeighborTable in the NIB, 25
respectively. 26
7 If the sequence number of the received frame belongs to a newer entry in the 27
nwkSecurityMaterialSet, then the nwkActiveKeySeqNumber shall be set to 28
received sequence number.17 29
30
31
4.4.2 Secured NPDU Frame 32
33
The NWK layer frame format (see sub-clause 3.4.1) consists of a NWK header 34
and NWK payload field. The NWK header consists of frame control and routing 35
fields. When security is applied to an NPDU frame, the security bit in the NWK 36
frame control field shall be set to 1 to indicate the presence of the auxiliary frame 37
header. The format for the auxiliary frame header is given in sub-clause 4.6.1. The 38
39
40
41
42
43
17. CCB #666 44
45
Chapter 4
format of a secured NWK layer frame is shown in Figure 4.4. The auxiliary frame
header is situated between the NWK header and payload fields. 1
2
Octets: Variable 14 Variable 3
4
Original NWK Header Auxiliary Encrypted Encrypted Message Integrity Code
([B3], Clause 7.1) frame Payload (MIC) 5
header 6
Secure frame payload = Output of CCM* 7
Full NWK header Secured NWK payload 8
9
Figure 4.4 Secured NWK Layer Frame Format 10
11
4.4.3 Security-related NIB Attributes 12
13
The NWK PIB contains attributes that are required to manage security for the 14
NWK layer. Each of these attributes can be read and written using the NLME- 15
GET.request and NLME-SET.request primitives, respectively. The security- 16
related attributes contained in the NWK PIB are presented in Tables 4.1 through 17
4.3. 18
Table 4.1 NIB Security Attributes
19
20
22
nwkSecurityLevel 0xa0 Octet 0x00-07 The security level for 0x06
outgoing and incoming 23
NWK frames; the 24
allowable security 25
level identifiers are 26
presented in Table 4.30 27
nwkSecurity- 0xa1 A set of 0, Variable Set of network security - 28
MaterialSet 1, or 2 material descriptors 29
network capable of maintaining 30
security an active and alternate
material Network key 31
descriptors 32
(See Table 33
4.2) 34
nwkActiveKey 0xa2 Octet 0x00- The sequence number 0x00 35
SeqNumber 0xFF of the active Network 36
key in 37
nwkSecurityMaterialSet 38
39
40
41
42
43
44
45
Table 4.1 NIB Security Attributes (Continued)

1
nwkAllFresh 0xa3 Boolean TRUE | Indicates whether TRUE 3
FALSE incoming NWK frames 4
must be all checked for 5
freshness when the 6
memory for incoming
frame counts is
7
exceeded 8
9
nwkSecureAll 0xa5 Boolean TRUE | This indicates if TRUE
10
Frames FALSE security shall be
applied to incoming 11
and outgoing NWK 12
data frames; if set to 13
0x01, security 14
processing shall be
15
applied to all incoming
and outgoing frames 16
except data frames 17
destined for the current 18
device that have the 19
security sub-field of
20
the frame control field
set to 0; if this attribute 21
has a value of 0x01 the 22
NWK layer shall not 23
relay frames that have 24
the security sub-field
25
of the frame control
field set to 0; The 26
SecurityEnable 27
parameter of the 28
NLDE-DATA.request 29
primitive shall override
30
the setting of this
attribute 31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Chapter 4
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
24
4.5 APS Layer Security 25
26
Table 4.3 Elements of the Incoming Frame Counter Descriptor 27
28
SenderAddress Device Any valid 64-bit Extended device Device 30
address address address specific 31
32
IncomingFrame Ordered set 0x00000000- Incoming frame 0x00000000
Counter of 4 octets 0xFFFFFFFF counter used for 33
incoming frames 34
35
The APS layer is responsible for the processing steps needed to securely transmit 36
outgoing frames, securely receive incoming frames, and securely establish and 37
manage cryptographic keys. Upper layers control the management of 38
cryptographic keys by issuing primitives to the APS layer. 39
40
41
42
43
44
45
Table 4.4 lists the primitives available for key management and maintenance.
Upper layers also determine which security level to use when protecting outgoing 1
frames. 2
3
Table 4.4 The APS Layer Security Primitives
4
APSME 5
Security 6
Primitives Request Confirm Indication Response Description 7
APSME- 4.5.2.1 4.5.2.2 4.5.2.3 4.5.2.4 Establishes link key 8
ESTABLISH with another ZigBee 9
-KEY device using the SKKE 10
method 11
APSME- 4.5.3.1 - 4.5.3.2 - Transports security 12
TRANSPOR material from one 13
T-KEY device to another 14
APSME- 4.5.4.1 - 4.5.4.2 - Notifies the trust center 15
UPDATE- when a new device has 16
DEVICE joined, or an existing 17
device has left the 18
network
19
APSME- 4.5.5.1 - 4.5.5.2 - Used by the trust 20
REMOVE- center to notify a router 21
DEVICE that one of the router’s
child devices should be
22
removed from the 23
network 24
25
APSME- 4.5.6.1 - 4.5.6.2 - Used by a device to
REQUEST- request that the trust 26
KEY center send an 27
application master key 28
or current Network key 29
APSME- 4.5.7.1 - 4.5.7.2 - Used by the trust 30
SWITCH- center to tell a device 31
KEY to switch to a new 32
Network key
33
34
36
The detailed steps involved in security processing of outgoing and incoming APS 37
frames are described in sub-clauses 4.5.1.1 and 4.5.1.2, respectively. 38
39
41
If the APS layer has a frame, consisting of a header ApsHeader and payload 42
Payload, that needs security protection and nwkSecurityLevel > 0, it shall apply 43
security as follows: 44
45
Chapter 4
1 Obtain the security material and key identifier KeyIdentifier using the
following procedure. If security material or key identifier cannot be 1
determined, then security processing shall fail and no further security 2
4
a If the frame is a result of a APSDE-DATA.request primitive: 5
i If the TxOptions parameter specifies that the NWK key is required to 6
secure the data frame, then security material shall be obtained by using 7
the nwkActiveKeySeqNumber from the NIB to retrieve the active Network 8
key, outgoing frame counter, and sequence number from the 9
nwkSecurityMaterialSet attribute in the NIB. KeyIdentifier shall be set to 10
‘01’ (that is, the Network key). 11
12
ii Otherwise, the security material associated with the destination address of 13
the outgoing frame shall be obtained from the apsDeviceKeyPairSet 14
attribute in the AIB. KeyIdentifier shall be set to ‘00’ (that is, a data key). 15
Note, if the frame is being transmitted using indirect addressing, the 16
destination address shall be the address of the binding manager. 17
b If the frame is a result of an APS command: 18
19
i First, an attempt shall be made to retrieve the security material associated 20
with the destination address of the outgoing frame from the 21
apsDeviceKeyPairSet attribute in the AIB. For all cases, except transport- 22
key commands, KeyIdentifier shall be set to ‘00’(that is, a data key). For 23
the case of transport-key commands, KeyIdentifier shall be set to ‘02’ 24
(that is, the key-transport key) when transporting a Network key and shall 25
be set to ‘03’ (that is, the key-load key) when transporting an application 26
link key, application master key, or trust center master key. See sub- 27
clause 4.6.3 for a description of the key-transport and key-load keys. 28
ii If the first attempt fails, then security material shall be obtained by using 29
the nwkActiveKeySeqNumber from the NIB to retrieve the active Network 30
key, outgoing frame counter, and sequence number from the 31
nwkSecurityMaterialSet attribute in the NIB. KeyIdentifier shall be set to 32
‘01’ (that is, the Network key). 33
34
2 If the key identifier is equal to 01 (that is, network key), the APS layer shall 35
first verify that the NWK layer is not also applying security. If the NWK layer 36
is applying security, then the APS layer shall not apply any security. The APS 37
layer can determine that the NWK layer is applying security by verifying that 38
the value of the nwkSecureAllFrames attribute of the NIB has a value of TRUE 39
and the nwkSecurityLevel NIB attribute has a non-zero value. 40
41
42
43
44
45
3 Extract the outgoing frame counter (and, if KeyIdentifier is 01, the key
sequence number) from the security material obtained from step 1. If the 1
outgoing frame counter has as its value the 4-octet representation of the integer 2
232-1, or if the key cannot be obtained, security processing shall fail and no 3
further security processing shall be done on this frame. 4
5
4 Obtain the security level from the nwkSecurityLevel attribute from the NIB. If 6
the frame is a result of an APS command, the security level identifier shall be 7
forced to 7 (ENC-MIC-128, as indicated in Table 4.30.) 8
5 Construct auxiliary header AuxiliaryHeader (see sub-clause 4.6.1): the security 9
control field shall be set as follows: 10
11
a The security level sub-field shall be the security level obtained from step 4. 12
i The key identifier sub-field shall be set to KeyIdentifier. 13
14
ii The extended nonce sub-field shall be set to 0. 15
b The frame counter field shall be set to the outgoing frame counter from 16
step 3. 17
18
c If KeyIdentifier is 1, the key sequence number field shall be present and set 19
to the key sequence number from step 3. Otherwise, the key sequence 20
number field shall not be present. 21
in sub-clause A.2, with the following instantiations: 23
24
28
control and frame counter fields from step 5 and the 64-bit extended address 30
of the local device (see sub-clause 4.6.2.2); 31
ApsHeader || AuxiliaryHeader and the octet string m shall be the string 33
Payload. Otherwise, the octet string a shall be the string ApsHeader || 34
AuxiliaryHeader || Payload and the octet string m shall be a string of length 35
zero. 36
37
secured outgoing frame shall be ApsHeader || AuxiliaryHeader || c, otherwise 41
the secured outgoing frame shall be ApsHeader || AuxiliaryHeader || Payload || 42
c. 43
44
45
Chapter 4
9 If the secured outgoing frame size will result in the MSDU being greater than
aMaxMACFrameSize octets (see IEEE Std. 802.15.4 802 [B1]), security 1
frame. 3
4
10 The outgoing frame counter from step 3 shall be incremented and stored in the 5
appropriate location(s) of the NIB, AIB, and MAC PIB corresponding to the 6
key that was used to protect the outgoing frame. 7
11 Over-write the security level subfield of the security control field by the 3-bit 8
all-zero string '000'. 9
10
12
If the APS layer receives a secured frame (consisting of a header ApsHeader, 13
auxiliary header AuxiliaryHeader, and payload SecuredPayload) as indicated by 14
the security sub-field of the APS header frame control field it shall perform 15
security processing as follows: 16
1 Determine the sequence number SequenceNumber, key identifier KeyIdentifier, 17
and received frame counter value ReceivedFrameCounter from the auxiliary 18
header AuxiliaryHeader. If ReceivedFrameCounter is the 4-octet 19
representation of the integer 232-1, security processing shall fail and no further 20
22
2 Determine the source address SourceAddress from the address-map table in the 23
AIB, using the source address in the APS frame as the index. If the source 24
address is incomplete or unavailable, security processing shall fail and no 25
further security processing shall be done on this frame. If the delivery-mode 26
sub-field of the frame control field of ApsHeader has a value of 1 (that is, 27
indirect addressing), the source address shall be the address of the binding 28
manager, as described in the APS specification [B7]. 29
3 Obtain the appropriate security material in the following manner. If the security 30
material cannot be obtained, security processing shall fail and no further 31
33
a If KeyIdentifier is ‘00’ (that is, data key), the security material associated 34
with the SourceAddress of the incoming frame shall be obtained from the 35
apsDeviceKeyPairSet attribute in the AIB. 36
b If KeyIdentifier is ‘01’ (that is, Network key), the security material shall be 37
obtained by matching SequenceNumber to the sequence number of any key 38
in the nwkSecurityMaterialSet attribute in the NIB. 39
40
c If KeyIdentifier is ‘02’ (that is, key-transport key), the security material 41
associated with the SourceAddress of the incoming frame shall be obtained 42
from the apsDeviceKeyPairSet attribute in the AIB; the key for this 43
44
45
operation shall be derived from the security material as specified in sub-

clause 4.6.3 for the key-transport key. 1
2
d If KeyIdentifier is ‘03’ (that is, key-load key), the security material 3
associated with the SourceAddress of the incoming frame shall be obtained 4
from the apsDeviceKeyPairSet attribute in the AIB and the key for this 5
operation shall be derived from the security material as specified in sub- 6
clause 4.6.3 for the key-load key. 7
4 If there is an incoming frame count FrameCount corresponding to 8
SourceAddress from the security material obtained in step 3 and if 9
ReceivedFrameCount is less than FrameCount, security processing shall fail 10
and no further security processing shall be done on this frame. 11
12
5 Determine the security level SecLevel as follows. If the frame type subfield of 13
the frame control field of ApsHeader indicates an APS data frame, then 14
SecLevel shall be set to the nwkSecurityLevel attribute in the NIB. Otherwise 15
SecLevel shall be set to 7 (ENC-MIC-128). Overwrite the security level 16
subfield of the security control field in the AuxillaryHeader with the value of 17
SecLevel. 18
21
25
control and frame counter fields from AuxiliaryHeader, and SourceAddress 27
from step 2 (see sub-clause 4.6.2.2); 28
d Parse the octet string SecuredPayload as Payload1 || Payload2, where the 29
on this frame; 32
33
ApsHeader || AuxiliaryHeader and the octet string c shall be the string 35
SecuredPayload. Otherwise, the octet string a shall be the string ApsHeader 36
|| AuxiliaryHeader || Payload1 and the octet string c shall be the string 37
Payload2. 38
40
a If the CCM* mode invoked in step 6 outputs invalid, security processing 41
shall fail and no further security processing shall be done on this frame. 42
43
44
45
Chapter 4
b Let m be the output of step 6. If the security level requires encryption, set the
octet string UnsecuredApsFrame to the string ApsHeader || m. Otherwise, 1
set the octet string UnsecuredApsFrame to the string ApsHeader || Payload. 2
3
8 Set FrameCount to (ReceivedFrameCount + 1) and store both FrameCount and 4
SourceAddress in the appropriate security material as obtained in step 3. If 5
storing this frame count and address information will cause the memory 6
allocation for this type of information to be exceeded and the nwkAllFresh 7
attribute in the NIB is TRUE, then security processing shall fail and no further 8
security processing shall be done on this frame. Otherwise security processing 9
shall succeed. 10
9 If the sequence number of the received frame belongs to a newer entry in the 11
nwkSecurityMaterialSet, and the source address of the packet is the trust center, 12
then the nwkActiveKeySeqNumber may be set to received sequence number. If 13
the security material associated with the SourceAddress of the incoming frame 14
cannot be obtained from the attribute in the AIB, then security processing shall 15
17
18
4.5.2 Key-establishment Services 19
20
The APSME provides services that allow two devices to mutually establish a link 21
key. Initial trust information (for example, a master key) must be installed in each 22
device prior to running the key establishment protocol (see sub-clause 4.5.3 for 23
mechanisms to provision initial trust information). 24
25
4.5.2.1 APSME-ESTABLISH-KEY.request 26
The APSME-ESTABLISH-KEY request primitive is used for initiating a key- 27
establishment protocol. This primitive can be used when there is a need to 28
securely communicate with another device. 29
30
One device will act as an initiator device, and another device will act as the 31
responder. The initiator shall start the key-establishment protocol by issuing: 32
• The APSME-ESTABLISH-KEY.request with parameters indicating the 33
address of the responder device; 34
35
• An indication of which key-establishment protocol to use (that is, SKKE direct 36
or indirect). 37
38
39
40
41
42
43
44
45

1
This primitive shall provide the following interface 2
APSME-ESTABLISH-KEY.request {
3
4
ResponderAddress,
5
UseParent,
6
ResponderParentAddress, 7
KeyEstablishmentMethod 8
} 9
10
Table 4.5 specifies the parameters for the APSME-ESTABLISH-KEY.request 11
primitive. 12
13
Table 4.5 APSME-ESTABLISH-KEY.request Parameters
14
Valid 15
Parameter Name Type Range Description 16
Responder-Address Device Any valid The extended 64-bit address of the responder 17
Address 64-bit device 18
address 19
UseParent Boolean TRUE | This parameter indicates if the responder’s 20
FALSE parent shall be used to forward messages 21
between the initiator and responder devices: 22
TRUE: Use parent 23
24
FALSE: Do not use parent
25
Responder- Device Any valid If the UseParent is TRUE, then 26
ParentAddress Address 64-bit ResponderParentAddress parameter shall 27
address contain the extended 64-bit address of the
responder’s parent device; Otherwise, this 28
parameter is not used and need not be set 29
30
KeyEstablishment- Integer 0x00 - The requested key-establishment method shall
Method 0x03 be one of the following: 31
32
0x00 = SKKE method 33
0x01-0x03: reserved 34
35
37
A higher layer on an initiator device shall generate this primitive when it requires 38
a link key to be established with a responder device. If the initiator device wishes 39
to use the responder’s parent as a liaison (for NWK security purposes), it shall set 40
the UseParent parameter to TRUE and shall set the ResponderParentAddress 41
parameter to the 64-bit extended address of the responder’s parent. 42
43
44
45
Chapter 4

1
The receipt of an APSME-ESTABLISH_KEY.request primitive, with the 2
KeyEstablishmentMethod parameter equal to SKKE, shall cause the APSME to 3
execute the SKKE protocol, as described in sub-clause 4.5.2.6. The local APSME 4
shall act as the initiator of this protocol, the APSME indicated by the 5
ResponderAddress parameter shall act as the responder of this protocol, and the 6
UseParent parameter will control whether the messages are sent indirectly via the 7
responder’s parent device given by the ResponderParentAddress parameter. 8
9
4.5.2.2 APSME-ESTABLISH-KEY.confirm 10
This primitive is issued to the ZDO upon completion or failure of a key- 11
establishment protocol. 12
13
15
This primitive shall provide the following interface:
16
APSME-ESTABLISH-KEY.confirm { 17
Address, 18
Status 19
} 20
21
22
Table 4.6 specifies the parameters of the APSME-ESTABLISH-KEY.confirm 23
primitive. Table 4.10 gives a description of some codes that can be returned in the 24
Status parameter of this primitive. In addition to these codes, if, when sending one 25
of the protocol messages, an NLDE-DATA.confirm primitive with a Status 26
parameter set to a value other than SUCCESS is issued, the Status parameter of 27
the APSME-ESTABLISH-KEY.confirm primitive shall be set to that received 28
from the NWK layer. 29
Table 4.6 APSME-ESTABLISH-KEY.confirm Parameters 30
31
32
Address Device Any valid 64-bit address The extended 64-bit address of the device 33
Address with which the key-establishment 34
protocol was executed 35
Status Enumeration Value given by Table This parameter indicates the final status 36
4.10 or any status value of the key-establishment protocol 37
returned from the 38
NLDE-DATA.confirm
primitive 39
40
41
42
43
44
45

1
The APSME in both the responder and initiator devices shall issue this primitive 2
to the ZDO upon completion of a key-establishment protocol. 3
5
If key establishment is successful, the AIB of the initiator and responder shall be 6
updated with the new link key and the initiator shall be able to securely 7
communicate with the responder. If the key establishment was not successful, then 8
the AIB shall not be changed. 9
10
4.5.2.3 APSME-ESTABLISH-KEY.indication 11
12
The APSME in the responder shall issue this primitive to its ZDO when it receives
13
an initial key-establishment message (for example, an SKKE-1 frame) from an
14
initiator.
15
17
This primitive shall provide the following interface: 18
APSME-ESTABLISH-KEY.indication { 19
InitiatorAddress, 20
KeyEstablishmentMethod 21
}
22
23
24
Table 4.7 specifies the parameters of the APSME-ESTABLISH-KEY.indication 25
primitive. 26
Table 4.7 APSME-ESTABLISH-KEY.indication Parameters 27
28
InitiatorAddress Device Any valid 64- The extended 64-bit address of the 30
Address bit address initiator device 31
KeyEstablishmentMethod Integer 0x00 - 0x03 The requested key-establishment 32
method shall be one of the following: 33
34
0x00 = SKKE method
35
0x01-0x03: reserved
36
37
The APSME in the responder device shall issue this primitive to the ZDO when a 39
request to start a key-establishment protocol (for example, an SKKE-1 frame) is 40
received from an initiator and a master key associated with the initiator device is 41
present in the AIB. 42
43
44
45
Chapter 4

1
Upon receiving the APSME-ESTABLISH-KEY.indication primitive, the ZDO 2
may use the KeyEstablishmentMethod and InitiatorAddress parameters to 3
determine whether to establish a key with the initiator. The ZDO shall respond 4
using the APSME-ESTABLISH-KEY.response primitive. 5
6
4.5.2.4 APSME-ESTABLISH-KEY.response 7
The ZDO of the responder device shall use the APSME-ESTABLISH- 8
KEY.response primitive to respond to an APSME-ESTABLISH-KEY.indication 9
primitive. The ZDO determines whether to continue with the key establishment or 10
halt it. This decision is indicated in the Accept parameter of the APSME- 11
ESTABLISH-KEY.response primitive. 12
13
15
16
APSME-ESTABLISH-KEY.response { 17
InitiatorAddress, 18
Accept 19
} 20
21
22
Table 4.8 specifies the parameters of the APSME-ESTABLISH-KEY.response 23
primitive 24
Table 4.8 APSME-ESTABLISH-KEY.response Parameters 25
26
27
InitiatorAddress Device Any valid The extended 64-bit address of the device that 28
Address 64-bit address initiated key establishment 29
Accept Boolean TRUE | This parameter indicates the response to an 30
FALSE initiator's request to execute a key- 31
establishment protocol. The response shall be 32
either: 33
TRUE = Accept 34
FALSE = Reject 35
36
38
The APSME-ESTABLISH-KEY.response primitive shall be generated by the 39
ZDO and provided to the APSME following a request from an initiator device to 40
start a key-establishment protocol (that is, after receipt of an APSME- 41
ESTABLISH-KEY.indication). This primitive provides the responder's ZDO with 42
an opportunity to determine whether to accept or reject a request to establish a key 43
with a given initiator. 44
45

1
If the Accept parameter is TRUE, then the APSME of the responder will attempt 2
to execute the key establishment protocol indicated by the 3
KeyEstablishmentMethod parameter. If KeyEstablishmentMethod is equal to 4
SKKE, the APSME shall execute the SKKE protocol, described in sub- 5
clause 4.5.2.6. The local APSME shall act as the responder of this protocol and 6
the APSME indicated by the InitiatorAddress parameter shall act as the initiator 7
of this protocol. If the Accept parameter is FALSE, the local APSME shall halt 8
and erase all intermediate data pertaining to the pending key-establishment 9
protocol. 10
11
4.5.2.5 Data Service Message Sequence Chart 12
Figure 4.5 illustrates the sequence of primitives necessary for a successful key 13
establishment between two devices. 14
15
16
Initiator Responder 17
Device Device
18
19
ZDO APSME APSME ZDO
20
1. APSME-ESTABLISH-KEY.request 2. APSME-ESTABLISH-KEY.indication 21
3. APSME-ESTABLISH-KEY.response
22
SKKE
23
4. APSME-ESTABLISH-KEY.confirm Protocol 5. APSME-ESTABLISH-KEY.confirm 24
25
26
27
Figure 4.5 Sequence Chart for Successful APSME-ESTABLISH- 28
KEY Primitives 29
30
4.5.2.6 The SKKE Protocol 31
The APSME on the initiator and responder execute the symmetric-key key- 32
agreement scheme instantiated in sub-clause B.2.1 and specified in B.1. The 33
shared key (as specified in B.1 prerequisite step 2), shall be the master key shared 34
between the initiator and responder devices as obtained from the appropriate 35
master key element in the DeviceKeyPairSet attribute in the AIB. The messages 36
sent during the scheme specified in B.1 shall be assigned to the frame names 37
given in Table 4.9. The formats for these SKKE frames are given in sub- 38
clause 4.5.8.1. The initiator device is responsible for sending the SKKE-1 and 39
SKKE-3 frames and the responder device is responsible for sending the SKKE-2 40
and SKKE-4 frames. Additionally, if the UseParent parameter to the APSME- 41
ESTABLISH-KEY.request primitive is TRUE, the responder device’s parent (as 42
indicated by the ResponderParentAddress parameter to the APSME- 43
44
45
Chapter 4
ESTABLISH-KEY.request primitive) shall act as a liaison and forward messages

between the initiator and responder devices. 1
2
During the key-establishment scheme, if the responder or initiator device detects 3
any error condition listed in Table 4.10, the scheme shall be aborted and the local 4
APSME shall issue the APSME-ESTABLISH-KEY.confirm primitive with the 5
Status parameter set as indicated in Table 4.10. If no error conditions occur (that 6
is, the key-agreement scheme outputs 'valid'), then the initiator and responder 7
shall consider the derived key (that is, KeyData) as their newly shared link key. 8
Both the initiator and responder shall update or add this link key to their AIB, set 9
the corresponding incoming and outgoing frame counts to zero, and issue the 10
APSME-ESTABLISH-KEY.confirm primitive with the Status parameter set to 11
SUCCESS. 12
Table 4.9 Mapping of Frame Names to Symmetric-key Key 13
Agreement Scheme Messages 14
15
Frame
Name Description Reference 16
17
SKKE-1 Sent by initiator during action step 1 (B.7.1) 4.5.2.6.2 18
SKKE-2 Sent by responder during action step 2 (B.7.2) 4.5.2.6.3 19
20
SKKE-3 Sent by initiator during action step 8 (B.7.1) 4.5.2.6.4
21
SKKE-4 Sent by responder during action step 9 (B.7.2) 4.5.2.6.5 22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Table 4.10 Mapping of Symmetric-key Key Agreement Error 1

Conditions to Status Codes 2
Status Description Status Code Value 3
4
No errors occur SUCCESS 0x00 5
An invalid parameter was input to one of the key INVALID_PARAMETER 0x01 6
establishment primitives 7
No master key is available NO_MASTER_KEY 0x02 8
9
Challenge is invalid: INVALID_CHALLENGE 0x03 10
Initiator during action step 3 (B.7.1)
Responder during action step 3 (B.7.2) 11
12
SKG outputs invalid: INVALID_SKG 0x04 13
Responder during action step 3 (B.7.2) 14
15
MAC transformation outputs invalid: INVALID_MAC 0x05 16
Responder during action step 10 (B.7.2 17
18
Tag checking transformation outputs invalid: INVALID_KEY 0x06 19
Responder during action step 8 (B.7.2)
20
21
Either the initiator or responder waits for an expected TIMEOUT 0x07 22
incoming message for time greater than the
apsSecurityTimeOutPeriod attribute of the AIB
23
24
Either the initiator or responder receives an SKKE BAD_FRAME 0x08 25
frame out of order
26
27
4.5.2.6.1 Generating and Sending the Initial SKKE-1 Frame 28
29
The SKKE protocol begins with the initiator device sending an SKKE-1 frame.
30
The SKKE-1 command frame shall be constructed as specified in sub-
31
clause 4.5.8.1.
32
If the UseParent parameter to the APSME-ESTABLISH-KEY.request primitive is 33
FALSE, the initiator device shall begin the protocol by sending this SKKE-1 34
frame directly to the responder device (as indicated by the ResponderAddress 35
parameter to the APSME-ESTABLISH-KEY.request primitive). Otherwise, the 36
initiator device shall begin the protocol by sending this SKKE-1 frame to the 37
responder device’s parent (as indicated by the ResponderParentAddress parameter 38
to the APSME-ESTABLISH-KEY.request primitive). The SKKE-1 frame shall be 39
sent using the NLDE-DATA.request primitive with NWK layer security set to the 40
default NWK layer security level. 41
42
43
44
45
Chapter 4
4.5.2.6.2 On Receipt of the SKKE-1 Frame

1
If the responder address field of the SKKE-1 frame does not equal the local device 2
address, the APSME shall perform the following steps: 3
1 If the device given by the responder address field is not a child of the local 4
device, the SKKE-1 frame shall be discarded. 5
6
2 Otherwise, the APSME of the local device shall send the SKKE-1 frame to the 7
responder device using the NLDE-DATA.request primitive with: 8
• The DestAddr parameter set to the 16-bit address corresponding to the 64-bit 9
address in the responder address field of the SKKE-1 frame; 10
11
• The DiscoverRoute parameter set to 0x01; 12
• The SecurityEnable parameter set to FALSE. 13
14
3 Otherwise, the APSME shall perform the following steps: 15
i If the device does not have a master key corresponding to the initiator 16
address field, the SKKE-1 frame shall be discarded and the APSME- 17
ESTABLISH-KEY.confirm primitive shall be issued with the Status 18
parameter set to NO_MASTER_KEY (see Table 4.10). The APSME 19
should halt processing for this SKKE protocol. 20
21
ii Otherwise, the APSME shall issue an APSME-ESTABLISH- 22
KEY.indication primitive with the InitiatorAddress parameter set to the 23
initiator address field of the SKKE-1 frame and the 24
KeyEstablishmentMethod parameter set to 0 (that is, the SKKE protocol). 25
iii After issuing the APSME-ESTABLISH-KEY.indication primitive, and 26
upon receipt of the corresponding APSME-ESTABLISH-KEY.response 27
primitive, the APSME shall evaluate the InitiatorAddress and Accept 28
parameters of the received APSME-ESTABLISH-KEY.response 29
primitive. If the InitiatorAddress parameter is set to the initiator address 30
of the SKKE-1 frame and the Accept parameter set to FALSE, the 31
APSME shall halt the SKKE protocol and discard the SKKE-1 frame. 32
33
iv Otherwise, it shall construct an SKKE-2 frame as specified in sub- 34
clause 4.5.8.1. If the source of the SKKE-1 frame indicates the same 35
device as the initiator address field of the SKKE-1 frame, the device shall 36
send this SKKE-2 frame directly to the initiator device using the NLDE- 37
DATA.request primitive, with the DestAddr parameter set to the source of 38
the SKKE-1 frame, the DiscoverRoute parameter set to 0x01, and the 39
SecurityEnable parameter set to TRUE. Otherwise, the device shall send 40
the SKKE-2 frame to its parent using the NLDE-DATA.request primitive, 41
with the DiscoverRoute parameter set to 0x01, and the SecurityEnable 42
parameter set to FALSE.18 43
44
45

1
If the initiator address field of the SKKE-2 frame does not equal the local device 2
6
2 Otherwise, the device shall send the SKKE-2 to the initiator device using the 7
NLDE-DATA.request primitive with NWK layer set to the default level. 8
Otherwise, the device shall construct an SKKE-3 frame as specified in sub- 9
clause 4.5.8.1. If the source of the SKKE-2 frame is the same as the responder 10
address field of the SKKE-2 frame, the device shall send this SKKE-3 frame 11
directly to the responder device. Otherwise, the device shall send the SKKE-3 12
frame to the responder’s parent. The SKKE-3 frame shall be sent using the 13
NLDE-DATA.request primitive with NWK layer security set to the default NWK 14
layer security level. 15
16
4.5.2.6.4 On Receipt of the SKKE-3 Frame 17
If the responder address field of the SKKE-3 frame does not equal the local device 18
20
device, the SKKE-3 frame shall be discarded; 22
2 Otherwise, the device shall send the SKKE-3 to the responder device using the 23
NLDE-DATA.request primitive with NWK layer security disabled; 24
25
3 Otherwise, the device shall process the SKKE-3 data field and if the protocol 26
was not a success it shall issue an APSME-ESTABLISH-KEY.confirm 27
primitive with the Address parameter set to the initiator’s address and the 28
Status parameter set appropriately; 29
4 If, from the device’s perspective, the protocol was a success, the device shall 30
construct an SKKE-4 frame as specified in sub-clause 4.5.8.1. If the source of 31
the SKKE-3 frame is the same as the initiator address field of the SKKE-3 32
frame, the device shall send this SKKE-4 frame directly to the initiator device 33
using the NLDE-DATA.request primitive with NWK layer security set to the 34
default level. Otherwise, the device shall send the SKKE-4 frame to its parent 35
using the NLDE-DATA.request primitive with NWK layer security disabled. 36
Finally, the device shall issue an APSME-ESTABLISH-KEY.confirm 37
primitive with the Address parameter set the initiator’s address and the Status 38
parameter set to success. 39
40
41
42
43
18. CCB #437 44
45
Chapter 4

1
If the initiator address field of the SKKE-4 frame does not equal the local device 2
6
2 Otherwise, the APSME of the local device shall send the SKKE-4 to the 7
initiator device using the NLDE-DATA.request primitive with NWK layer set 8
to the default level. 9
Otherwise, the APSME shall process the SKKE-4 frame and issue an APSME- 10
ESTABLISH-KEY.confirm primitive with the Address parameter set the 11
responder’s address and the Status parameter set appropriately. 12
13
14
4.5.3 Transport-key Services 15
16
The APSME provides services that allow an initiator to transport keying material 17
to a responder. The different types of keying material that can be transported are 18
shown in Tables 4.12 to 4.15. 19
20
4.5.3.1 APSME-TRANSPORT-KEY.request 21
The APSME-TRANSPORT-KEY.request primitive is used for transporting a key 22
to another device. 23
24
26
27
APSME-TRANSPORT-KEY.request { 28
DestAddress, 29
KeyType, 30
TransportKeyData 31
}
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Table 4.11 specifies the parameters for the APSME-TRANSPORT-KEY.request

primitive. 1
2
Table 4.11 APSME-TRANSPORT-KEY.request Parameters
3
Parameter Name Type Valid Range Description 4
5
DestAddress Device Any valid The extended 64-bit address of the 6
address 64-bit address destination device
7
KeyType Integer 0x00 – 0x03 Identifies the type of key material that 8
should be transported; see Table 4.12 9
TransportKeyData Variable Variable The key being transported along with 10
identification and usage parameters. The 11
type of this parameter depends on the 12
KeyType parameter as follows:
13
KeyType = 0x00 see Table 4.12 14
18
19
20
Table 4.12 KeyType Parameter of The Transport-Key Primitive 21
23
Trust-center 0x00 Indicates the key is a master key which is used to set up link keys 24
master key between the trust center and another device 25
Network key 0x01 Indicates the key is a Network key 26
Application master 0x02 Indicates the key is a master key which is used to set up link keys 27
key between two devices 28
29
Application link 0x03 Indicates the key is a link key which is used as a basis of security
key between two devices
30
31
32
33
35
Parameter
36
37
ParentAddress Device Any valid The extended 64-bit address of the parent 38
address 64-bit address of the destination device given by the 39
DestAddress parameter
40
TrustCenter- Set of 16 Variable The trust center master key 41
MasterKey octets 42
43
44
45
Chapter 4
1
Table 4.14 TransportKeyData Parameter for a Network Key
2
Parameter Valid 3
5
KeySeqNumber Octet 0x00-0xFF A sequence number assigned to a Network key by
the trust center and used to distinguish Network 6
keys for purposes of key updates, and incoming 7
frame security operations 8
NetworkKey Set of Variable The Network key 9
16 10
octets 11
UseParent Boolean TRUE | This parameter indicates if the destination device’s 12
FALSE parent shall be used to forward the key to the 13
destination device: 14
TRUE: Use parent 15
16
FALSE: Do not use parent
17
ParentAddress Device Any valid If the UseParent is TRUE, then ParentAddress 18
address 64-bit parameter shall contain the extended 64-bit address 19
address of the destination device’s parent device; otherwise,
this parameter is not used and need not be set 20
21
22
23
Table 4.15 TransportKeyData Parameter for an Application Master or Link Key 24
25
Parameter
27
PartnerAddress Device Any valid The extended 64-bit address of the device that 28
address 64-bit address was also sent this master key 29
Initiator Boolean TRUE | This parameter indicates if the destination 30
FALSE device of this master key requested it: 31
TRUE: If the destination requested the key 32
FALSE: Otherwise 33
34
Key Set of 16 Variable The master or link key (as indicated by the 35
octets KeyType parameter)
36
37
The ZDO on an initiator device shall generate this primitive when it requires a key 39
to be transported to a responder device. 40
41
42
43
44
45

1
The receipt of an APSME-TRANSPORT-KEY.request primitive shall cause the 2
APSME to create a transport-key command packet (see sub-clause 4.5.8.2) 3
If the KeyType parameter is 0x00 (that is, trust center master key), the key 4
descriptor field of the transport-key command shall be set as follows: 5
6
• The key sub-field shall be set to the Key sub-parameter of the 7
TransportKeyData parameter; 8
• The destination address sub-field shall be set to the DestinationAddress 9
parameter; 10
11
• The source address sub-field shall be set to the local device address. 12
This command frame shall be security protected as specified in sub-clause 4.5.1.1. 13
Then, if security processing succeeds, sent to the device specified by the 14
ParentAddress sub-parameter of the TransportKeyData parameter by issuing a 15
NLDE-DATA.request primitive. 16
17
If the KeyType parameter is 0x01 (that is, Network key), the key descriptor field of 18
the transport-key command shall be set as follows: 19
22
• The sequence number sub-field shall be set to the KeySeqNumber sub- 23
parameter of the TransportKeyData parameter; 24
• The destination address sub-field shall be set to the DestinationAddress 25
parameter; 26
27
• The source address sub-field shall be set to the local device address. 28
This command frame shall be security protected as specified in sub-clause 4.5.1.1 29
and then, if security processing succeeds, sent to the device specified by the 30
ParentAddress sub-parameter of the TransportKeyData parameter (if the 31
UseParent sub-parameter of the TransportKeyData parameter is TRUE) or the 32
DestinationAddress parameter (if the UseParent sub-parameter of the 33
TransportKeyData parameter is FALSE) by issuing a NLDE-DATA.request 34
primitive. 35
36
If the KeyType parameter is 0x02 or 0x03 (that is, an application master or link 37
key), the key descriptor field of the transport-key command shall be set as 38
follows: 39
42
• The partner address sub-field shall be set to the PartnerAddress sub-parameter 43
of the TransportKeyData parameter; 44
45
Chapter 4
• The initiator sub-field shall be set 1 (if the Initiator sub-parameter of the
TransportKeyData parameter is TRUE) or 0 (if the Initiator sub-parameter of 1
the TransportKeyData parameter is FALSE). 2
3
DestinationAddress parameter by issuing a NLDE-DATA.request primitive. 6
7
4.5.3.2 APSME-TRANSPORT-KEY.indication 8
The APSME-TRANSPORT-KEY.indication primitive is used to inform the ZDO 9
of the receipt of keying material. 10
11
14
APSME-TRANSPORT-KEY.indication { 15
SrcAddress, 16
KeyType, 17
TransportKeyData 18
} 19
20
21
Table 4.16 specifies the parameters of the APSME-TRANSPORT-KEY.indication 22
primitive. 23
Table 4.16 APSME-TRANSPORT-KEY.indication Parameters 24
25
26
SrcAddress Device Any valid 64- The extended 64-bit address of the device 27
Address bit address that is the original source of the transported 28
key 29
KeyType Octet 0x00 – 0x03 Identifies the type of key material that was be 30
transported; see Table 4.12 31
TransportKeyData Variable Variable The key that was transported along with 32
identification and usage parameters; the type 33
of this parameter depends on the KeyType 34
parameter as follows: 35
40
41
42
43
44
45

3
TrustCenter- Set of 16 Variable The trust center master key 4
MasterKey octets 5
6
7
Table 4.18 TransportKeyData Parameter for a Network Key
8
Parameter 9
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
The APSME shall generate this primitive when it receives a transport-key 20
command that is successfully decrypted and authenticated, as specified in sub- 21
clause 4.5.1.2, that has the key type field set to 2 or 3 (that is, application link or 22
master key). 23
24
Alternatively, the APSME shall generate this primitive when it receives a
25
transport-key command that is successfully decrypted and authenticated, (as
26
specified in sub-clause 4.5.1.2,) that has the key type field set to 0 or 1, (that is, a
27
trust center master key or Network key) and the destination address sub-field of
28
the key descriptor field is equal to the local address.
29
31
Upon receipt of this primitive, the ZDO is informed of the receipt of the keying 32
material. 33
34
4.5.3.3 Upon Receipt of a Transport-key Command 35
Upon receipt of a transport-key command, the APSME shall execute security 36
processing as specified in sub-clause 4.5.1.2 and then check the key type sub- 37
field. 38
39
If the key type field is set to 2 or 3 (that is, application link or master key), the 40
APSME shall issue the APSME-TRANSPORT-KEY.indication primitive with: 41
the SrcAddress parameter set to the source of the key-transport command (as 42
indicated by the NLDE-DATA.indication SrcAddress parameter), the KeyType 43
44
45
Chapter 4
parameter set to the key type field. The TransportKeyData parameter shall be set
as follows: 1
2
• The Key sub-parameter shall be set to the key field; 3
• The PartnerAddress sub-parameter shall be set to the partner address field; 4
5
• The Initiator parameter shall be set to TRUE, if the initiator field is 1, 6
otherwise 0. 7
If the key type field is set to 0 or 1 (that is, trust center master key or NWK key) 8
and the destination address field is equal to the local address, the APSME shall 9
issue the APSME-TRANSPORT-KEY.indication primitive, with the SrcAddress 10
parameter set to the source address field of the key-transport command and the 11
KeyType parameter set to the key type field. The TransportKeyData parameter 12
shall be set as follows: the Key sub-parameter shall be set to the key field and, in 13
the case of a Network key (that is, the key type field is set to 1), the 14
KeySeqNumber sub-parameter shall be set to the sequence number field. 15
16
If the key type field is set to 0 or 1 (that is, trust center master key or NWK key) 17
and the destination address field is not equal to the local address, the APSME 18
shall send the command to the address indicated by the destination address field 19
by issuing the NLDE-DATA.request primitive with security disabled. 20
Upon receipt of an unsecured transport-key command, the APSME shall check 21
the key type sub-field. If the key type field is set to 0 (that is, a trust center master 22
key), the destination address field is equal to the local address, and the device does 23
not have a trust center master key and address (that is, the apsTrustCenterAddress 24
in the AIB), then the APSME shall issue the APSME-TRANSPORT- 25
KEY.indication primitive. Also, if the key type field is set to 1 (that is, Network 26
key), the destination address field is equal to the local address, and the device does 27
not have a Network key, then the APSME shall issue the APSME-TRANSPORT- 28
KEY.indication primitive. If an APSME-TRANSPORT-KEY.indication primitive 29
is issued, the SrcAddress parameter shall be set to the source address field of the 30
key-transport command, and the KeyType parameter shall be set to the key type 31
field. The TransportKeyData parameter shall be set as follows: the Key sub- 32
parameter shall be set to the key field and, in the case of a Network key (that is, 33
the key type field is set to 1), the KeySeqNumber sub-parameter shall be set to the 34
sequence number field. 35
36
37
4.5.4 Update Device Services 38
39
The APSME provides services that allow a device (for example, a router) to 40
inform another device (for example, a trust center) that a third device has changed 41
its status (for example, joined or left the network). 42
43
44
45
4.5.4.1 APSME-UPDATE-DEVICE.request
1
The ZDO shall issue this primitive when it wants to inform a device (for example, 2
a trust center) that another device has a status that needs to be updated (for 3
example, the device joined or left the network). 4
5
6
8
APSME-UPDATE-DEVICE.request { 9
DestAddress, 10
DeviceAddress, 11
Status, 12
DeviceShortAddress 13
} 14
15
Table 4.19 specifies the parameters for the APSME-UPDATE-DEVICE.request 16
primitive. 17
18
Table 4.19 APSME-UPDATE-DEVICE.request Parameters 19
Parameter 20
22
DestAddress Device Any valid The extended 64-bit address of the device
23
Address 64-bit address that shall be sent the update information
24
DeviceAddress Device Any valid The extended 64-bit address of the device 25
Address 64-bit address whose status is being updated
26
Status Integer 0x00 – 0x08 Indicates the updated status of the device 27
given by the DeviceAddress parameter: 28
0x00: device secured join 29
0x01: device unsecured join 30
0x02: device left 31
0x03-0x08 reserved
32
33
DeviceShortAd Network 0x0000 - 0xffff The 16-bit network address of the device 34
dress address whose status is being updated
35
36
38
The ZDO (for example, on a router or ZigBee coordinator) shall initiate the
39
APSME-UPDATE-DEVICE.request primitive when it wants to send updated
40
device information to another device (for example, the trust center). Effect on
41
receipt
42
43
44
45
Chapter 4

1
Upon receipt of the APSME-UPDATE-DEVICE.request primitive the device 2
shall first create an update-device command frame (see sub-clause 4.5.8.4). The 3
device address field of this command frame shall be set to the DeviceAddress 4
parameter and the status field shall be set according to the Status parameter and 5
the device short address field shall be set to the DeviceShortAddress parameter. 6
DestAddress parameter by issuing a NLDE-DATA.request primitive. 9
10
4.5.4.2 APSME-UPDATE-DEVICE.indication 11
The APSME shall issue this primitive to inform the ZDO that it received an 12
update-device command frame. 13
14
16
17
APSME-UPDATE-DEVICE.indication { 18
SrcAddress, 19
DeviceAddress, 20
Status, 21
DeviceShortAddress
22
23
}
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Table 4.20 specifies the parameters for the APSME-UPDATE-

DEVICE.indication primitive. 1
2
Table 4.20 APSME-UPDATE-DEVICE.indication Parameters
3
5
SrcAddress Device Any valid The extended 64-bit address of the 6
Address 64-bit address device originating the update-device
command 7
8
DeviceAddress Device Any valid The extended 64-bit address of the 9
Address 64-bit address device whose status is being updated
10
Status Octet 0x00 – 0xFF Indicates the updated status of the device 11
given by the DeviceAddress parameter 12
0x00: device secured join. 13
0x01: device unsecured join. 14
0x02: device left. 15
0x03-0xFF reserved. 16
17
DeviceShortAddress Network 0x0000 - 0xffff The 16-bit network address of the device 18
address whose status is being updated
19
20
The APSME shall generate this primitive when it receives an update-device 22
command frame that is successfully decrypted and authenticated, as specified in 23
sub-clause 4.5.1.2. 24
25
Upon receipt of the APSME-UPDATE-DEVICE.indication primitive the ZDO 27
will be informed that the device referenced by the DeviceAddress parameter has 28
undergone a status update according to the Status parameter. 29
30
31
4.5.5 Remove Device Services 32
33
The APSME provides services that allow a device (for example, a trust center) to 34
inform another device (for example, a router) that one of its children should be 35
removed from the network. 36
37
4.5.5.1 APSME-REMOVE-DEVICE.request 38
39
The ZDO of a device (for example, a trust center) shall issue this primitive when it
40
wants to request that a parent device (for example, a router) remove one of its
41
children from the network. For example, a trust center can use this primitive to
42
remove a child device that fails to authenticate properly.
43
44
45
Chapter 4

1
APSME-REMOVE-DEVICE.request {
3
4
ParentAddress,
5
ChildAddress
6
} 7
8
Table 4.21 specifies the parameters for the APSME-REMOVE-DEVICE.request 9
primitive. 10
Table 4.21 APSME-REMOVE-DEVICE.request Parameters 11
12
Parameter 13
ParentAddress Device Any valid The extended 64-bit address of the device 15
Address 64-bit address that is the parent of the child device that is 16
requested to be removed 17
ChildAddress Device Any valid The extended 64-bit address of the child 18
Address 64-bit address device that is requested to be removed 19
20
22
The ZDO (for example, on a trust) shall initiate the APSME-REMOVE- 23
DEVICE.request primitive when it wants to request that a parent device (specified 24
by the ParentAddress parameter) remove one of its child devices (as specified by 25
the ChildAddress parameter). 26
28
Upon receipt of the APSME-REMOVE-DEVICE.request primitive the device 29
shall first create a remove-device command frame (see sub-clause 4.5.8.4). The 30
child address field of this command frame shall be set to the ChildAddress 31
parameter. This command frame shall be security protected as specified in sub- 32
clause 4.5.1.1 and then, if security processing succeeds, sent to the device 33
specified by the ParentAddress parameter by issuing a NLDE-DATA.request 34
primitive. 35
36
4.5.5.2 APSME-REMOVE-DEVICE.indication 37
38
The APSME shall issue this primitive to inform the ZDO that it received a
39
remove-device command frame.
40
41
42
43
44
45

1
APSME-REMOVE-DEVICE.indication {
3
4
SrcAddress,
5
ChildAddress
6
} 7
8
Table 4.22 specifies the parameters for the APSME-REMOVE- 9
DEVICE.indication primitive. 10
Table 4.22 APSME-REMOVE-DEVICE.indication Parameters 11
12
Parameter 13
SrcAddress Device Any valid The extended 64-bit address of the device 15
Address 64-bit address requesting that a child device be removed 16
ChildAddress Device Any valid The extended 64-bit address of the child 17
Address 64-bit address device that is requested to be removed 18
19
20
21
The APSME shall generate this primitive when it receives a remove-device 22
25
26
Upon receipt of the APSME-REMOVE-DEVICE.indication primitive the ZDO 27
shall be informed that the device referenced by the SrcAddress parameter is 28
requesting that the child device referenced by the ChildAddress parameter be 29
removed from the network. 30
31
32
4.5.6 Request Key Services 33
34
The APSME provides services that allow a device to request the current Network 35
key or a master key from another device (for example, its trust center). 36
37
4.5.6.1 APSME-REQUEST-KEY.request 38
This primitive allows the ZDO to request either the current Network key or a new 39
end-to-end application master key. 40
41
42
43
44
45
Chapter 4

1
APSME-REQUEST-KEY.request {
3
4
DestAddress,
5
KeyType,
6
PartnerAddress 7
} 8
9
Table 4.23 specifies the parameters for the APSME-REQUEST-KEY.request 10
primitive. 11
Table 4.23 APSME-REQUEST-KEY.request Parameters 12
13
Parameter 14
DestAddress Device Any valid 64-bit The extended 64-bit address of the 16
Address address device to which the request-key 17
command should be sent 18
KeyType Octet 0x00-0xFF The type of key being requested: 19
20
0x01 = Network key
21
0x02 = Application key 22
0x00 and 0x03-0xFF = Reserved 23
PartnerAddress Device Any valid 64-bit In the case that KeyType parameter 24
Address address indicates an application key, this 25
parameter shall indicate an extended 64- 26
bit address of a device that shall receive 27
the same key as the device requesting the
key 28
29
30
The ZDO of a device shall generate the APSME-REQUEST-KEY.request 32
primitive when it requires either the current Network key or a new end-to-end 33
application master key. 34
35
Upon receipt of the APSME-REQUEST-KEY.request primitive the device shall 37
first create a request-key command frame (see sub-clause 4.5.8.6). The key type 38
field of this command frame shall be set to the same value as the KeyType 39
parameter. If the KeyType parameter is 0x02 (that is, an application key), then the 40
partner address field of this command frame shall be the PartnerAddress 41
parameter. Otherwise, the partner address field of this command frame shall not 42
be present. 43
44
45
This command frame shall be security protected as specified in sub-clause 4.5.1.1

3
4.5.6.2 APSME-REQUEST-KEY.indication 4
5
The APSME shall issue this primitive to inform the ZDO that it received a 6
request-key command frame. 7
9
11
APSME-REQUEST-KEY.indication {
12
SrcAddress,
13
KeyType, 14
PartnerAddress 15
} 16
17
Table 4.24 specifies the parameters for the APSME-REQUEST-KEY.indication 18
primitive. 19
20
Table 4.24 APSME-REQUEST-KEY.indication Parameters
21
Parameter 22
SrcAddress Device Any valid 64-bit The extended 64-bit address of the device 24
Address address that sent the request-key command 25
26
KeyType Octet 0x00-0xFF The type of key being requested:
27
0x01 = Network key 28
0x02 = Application key 29
0x00 and 0x03-0xFF = Reserved 30
PartnerAddress Device Any valid 64-bit In the case that KeyType parameter indicates
31
Address address an application key, this parameter shall 32
indicate an extended 64-bit address of a 33
device that shall receive the same key as the 34
device requesting the key 35
36
38
The APSME shall generate this primitive when it receives a request-key 39
42
43
44
45
Chapter 4

1
Upon receipt of the APSME-REQUEST-KEY.indication primitive the ZDO shall 2
be informed that the device referenced by the SrcAddress parameter is requesting 3
a key. The type of key being requested shall be indicated by the KeyType 4
parameter and if the KeyType parameter is 0x02 (that is, an application key), the 5
PartnerAddress parameter shall indicate a partner device that shall receive the 6
same key as the device requesting the key (that is, the device indicated by the 7
SrcAddress parameter). 8
9
4.5.7 Switch Key Services 10
11
The APSME provides services that allow a device (for example, a trust center) to 12
inform another device that it should switch to a new active Network key. 13
14
4.5.7.1 APSME-SWITCH-KEY.request 15
16
This primitive allows a device (for example, the trust center) to request that 17
another device switch to a new active Network key. 18
20
22
APSME-SWITCH-KEY.request {
23
DestAddress, 24
KeySeqNumber 25
} 26
27
Table 4.25 specifies the parameters for the APSME-SWITCH-KEY.request 28
primitive. 29
30
Table 4.25 APSME-SWITCH-KEY.request Parameters
31
Parameter Valid 32
DestAddress Device Any valid The extended 64-bit address of the device to 34
Address 64-bit address which the switch-key command is sent 35
36
KeySeqNumber Octet 0x00-0xFF A sequence number assigned to a Network
key by the trust center and used to distinguish 37
Network keys 38
39
40
41
The ZDO of a device (for example, the trust center) shall generate the APSME- 42
SWITCH-KEY.request primitive when it wants to inform a device to switch to a 43
new active Network key. 44
45

1
Upon receipt of the APSME-SWITCH-KEY.request primitive the device shall 2
first create a switch-key command frame (see sub-clause 4.5.8.7). The sequence 3
number field of this command frame shall be set to the same value as the 4
KeySeqNumber parameter. 5
9
4.5.7.2 APSME-SWITCH-KEY.indication 10
11
The APSME shall issue this primitive to inform the ZDO that it received a switch- 12
key command frame. 13
15
17
APSME-SWITCH-KEY.indication {
18
SrcAddress, 19
KeySeqNumber 20
} 21
22
Table 4.26 specifies the parameters for the APSME-SWITCH-KEY.indication 23
primitive. 24
25
Table 4.26 APSME-SWITCH-KEY.indication Parameters
26
Valid 27
Parameter Name Type Range Description 28
SrcAddress Device Any valid The extended 64-bit address of the device 29
Address 64-bit that sent the switch-key command 30
address 31
KeySeqNumber Octet 0x00- A sequence number assigned to a Network 32
0xFF key by the trust center and used to distinguish 33
Network keys 34
35
37
The APSME shall generate this primitive when it receives a switch-key command 38
frame that is successfully decrypted and authenticated, as specified in sub- 39
clause 4.5.1.2. 40
42
Upon receipt of the APSME-SWITCH-KEY.indication primitive the ZDO shall 43
be informed that the device referenced by the SrcAddress parameter is requesting 44
45
Chapter 4
that the Network key referenced by the KeySeqNumber parameter become the
new active Network key. 1
2
4.5.7.3 Secured APDU Frame 3
4
The APS layer frame format consists of APS header and APS payload fields (see 5
Figure 2.4.) The APS header consists of frame control and addressing fields. 6
When security is applied to an APDU frame, the security bit in the APS frame 7
control field shall be set to 1 to indicate the presence of the auxiliary frame header. 8
The format for the auxiliary frame header is given in sub-clause 4.6.1. The format 9
of a secured APS layer frame is shown in Figure 4.6. The auxiliary frame header 10
is situated between the APS header and payload fields. 11
12
Octets: Variable 5 or 6 Variable
13
Original APS Header Auxiliary Encrypted Payload Encrypted Message 14
([B7], Clause 7.1) frame Integrity Code (MIC) 15
header 16
Secure frame payload = Output of CCM*
17
Full APS header Secured APS payload
18
Figure 4.6 Secured APS Layer Frame Format 19
20
21
4.5.8 Command Frames 22
23
The APS layer command frame formats are given in this clause. 24
Command identifier values are shown in Table 4.27. 25
26
Table 4.27 Command Identifier Values
27
Command Identifier Value 28
29
APS_CMD_SKKE_1 0X01
30
APS_CMD_SKKE_2 0X02 31
33
APS_CMD_TRANSPORT_KEY 0X05 35
APS_CMD_UPDATE_DEVICE 0X06 36
37
APS_CMD_REMOVE_DEVICE 0X07 38
APS_CMD_REQUEST_KEY 0X08 39
40
APS_CMD_SWITCH_KEY 0X09
41
42
43
44
45
4.5.8.1 Key-establishment Commands

1
The APS command frames used during key establishment is specified in this 2
clause. The optional fields of the APS header portion of the general APS frame 3
format shall not be present. 4
5
The generic SKKE command frame shall be formatted as illustrated in Figure 4.7.
6
Octets: 1 1 8 8 16 7
8
Frame control Command Initiator Responder Data 9
identifier Address Address
10
APS Header Payload 11
12
Figure 4.7 Generic SKKE Frame Command Format
13
14
4.5.8.1.1 Command Identifier Field
15
The command identifier field shall indicate the APS command type. For SKKE 16
frames, the command identifier shall indicate either an SKKE-1, SKKE-2, SKKE- 17
3, or SKKE-4 frame, depending on the frame type (see Table 4.27). 18
19
4.5.8.1.2 Initiator Address Field
20
The initiator address field shall be the 64-bit extended address of the device that 21
acts as the initiator in the key-establishment protocol. 22
23
4.5.8.1.3 Responder Address Field 24
The responder address field shall be the 64-bit extended address of the device that 25
acts as the responder in the key-establishment protocol. 26
27
4.5.8.1.4 Data Field 28
The content of the data field depends on the command identifier field (that is, 29
SKKE-1, SKKE-2, SKKE-3, or SKKE-4). Clauses 4.5.8.1.4.1 through 4.5.8.1.4.4 30
describe the content of the data field for each command type. 31
32
4.5.8.1.4.1 SKKE-1 Frame 33
34
The data field shall be the octet representation of the challenge QEU generated by 35
the initiator during action step 1 of sub-clause B.7.1. 36
37
4.5.8.1.4.2 SKKE-2 Frame 38
39
The data field shall be the octet representation of the challenge QEV generated by 40
the responder during action step 2 of sub-clause B.7.2. 41
42
43
44
45
Chapter 4
4.5.8.1.4.3 SKKE-3 Frame

1
The data field shall be the octet representation of the string MacTag2 generated by 2
the initiator during action step 1 of sub-clause B.7.1. 3
4
4.5.8.1.4.4 SKKE-4 Frame 5
6
The data field shall be the octet representation of the string MacTag1 generated by
7
the responder during action step 10 of sub-clause B.7.2.
8
4.5.8.2 Transport-key Commands 9
10
The transport-key command frame shall be formatted as illustrated in Figure 4.8. 11
The optional fields of the APS header portion of the general APS frame format 12
shall not be present. 13
14
Frame control APS Key Type Key descriptor 16
command 17
identifier 18
20
Figure 4.8 Transport-Key Command Frame 21
22
4.5.8.3 Command Identifier Field 23
24
This field is 8-bits in length shall be set to indicate that this is a transport-key 25
command frame (see Table 4.27). 26
4.5.8.3.1 Key Type Field 27
28
This field is 8-bits in length and describes the type of key being transported. The 29
different types of keys are enumerated in Table 4.12. 30
4.5.8.3.2 Key Descriptor Field 31
32
This field is variable in length and shall contain the actual (unprotected) value of 33
the transported key along with any relevant identification and usage parameters. 34
The information in this field depends on the type of key being transported (as 35
indicated by the key type field – see sub-clause 4.5.8.3.1) and shall be set to one 36
of the formats described in the following subsections. 37
38
39
40
41
42
43
44
45
4.5.8.3.2.1 Trust Center Master Key Descriptor Field

1
If the key type field is set to 0, the key descriptor field shall be formatted as shown 2
in Figure 4.9. 3
4
Octets: 16 8 8
5
Key Destination address Source address 6
7
Figure 4.9 Trust Center Master Key Descriptor Field in Transport-Key 8
Command
9
• The key sub-field shall contain the master key that should be used to set up link 10
keys with the trust center; 11
12
• The destination address sub-field shall contain the address of the device which 13
should use this master key; 14
• The source address sub-field shall contain the address of the device (for 15
example, the trust center) which originally sent this master key. 16
17
18
4.5.8.3.2.2 Network Key Descriptor Field
19
If the key type field is set to 1, this field shall be formatted as shown in 20
Figure 4.10. 21
22
Octets: 16 1 8 8 23
Key Sequence number Destination address Source address 24
25
Figure 4.10 Network Key Descriptor Field in Transport-Key Command 26
27
• The key sub-field shall contain a Network key; 28
• The sequence number sub-field shall contain the sequence number associated 29
with this Network key; 30
31
• The destination address sub-field shall contain the address of the device which 32
should use this Network key; 33
• If the Network key is sent to a broadcast address, the destination address sub- 34
field shall be set to the all-zero string and shall be ignored upon reception; 35
36
• The source address field sub-shall contain the address of the device (for 37
example, the trust center) which originally sent this Network key. 38
39
40
41
42
43
44
45
Chapter 4
4.5.8.3.2.3 Application Master and Link Key Descriptor Field

1
If the key type field is set to 2 or 3, this field shall be formatted as shown in 2
Figure 4.11. 3
4
Octets: 16 8 1
5
Key Partner address Initiator flag 6
7
Figure 4.11 Application Master Key Descriptor in Transport-Key Command 8
9
• The key sub-field shall contain a master or link key that is shared with the 10
device identified in the partner address field; 11
• The partner address sub-field shall contain the address of the other device that 12
was sent this link or master key; 13
14
• The initiator flag sub-field shall be set to 1 if the device receiving this packet 15
requested this key. Otherwise, this sub-field shall be set to 0. 16
17
4.5.8.4 Update Device Commands 18
The APS command frame used for device updates is specified in this clause. The 19
optional fields of the APS header portion of the general APS frame format shall 20
not be present. 21
22
The update-device command frame shall be formatted as illustrated in 23
Figure 4.12. 24
25
Octets: 1 1 8 2 1
26
Frame control Command Device Address Device short address Status 27
identifier 28
30
Figure 4.12 Update-Device Command Frame Format 31
32
4.5.8.4.1 Command Identifier Field 33
The command identifier field shall indicate the APS command type update-device 34
(see Tables 4.27). 35
36
4.5.8.4.2 Device Address Field 37
The device address field shall be the 64-bit extended address of the device whose 38
status is being updated. 39
40
4.5.8.4.3 Device Short Address Field 41
The device short address field shall be the 16-bit network address of the device 42
whose status is being updated. 43
44
45
4.5.8.4.4 Status Field

1
The status field shall be assigned a value as described for the Status parameter in 2
Table 4.19. 3
4
4.5.8.5 Remove Device Commands 5
The APS command frame used for removing a device is specified in this clause. 6
The optional fields of the APS header portion of the general APS frame format 7
shall not be present. 8
9
The remove-device command frame shall be formatted as illustrated in 10
Figure 4.13. 11
12
Octets: 1 1 8 13
Frame control Command identifier Child address 14
15
APS Header Payload
16
Figure 4.13 Remove-Device Command Frame Format 17
18
20
The command identifier field shall indicate the APS command type remove- 21
device (see Table 4.27). 22
4.5.8.5.2 Child Address Field 23
24
The child address field shall be the 64-bit extended address of the device that is 25
requested to be removed from the network. 26
27
4.5.8.6 Request-key Commands 28
The APS command frame used by a device for requesting a key is specified in this 29
32
The request-key command frame shall be formatted as illustrated in Figure 4.14 33
34
Octets: 1 1 1 0/8
35
Frame control Command identifier Key type Partner address 36
APS Header Payload
37
38
Figure 4.14 Request-Key Command Frame Format 39
40
42
The command identifier field shall indicate the APS command type request-key
43
(see Table 4.27).
44
45
Chapter 4
4.5.8.6.2 Key Type Field

1
The key type field shall be set to 1 when the Network key is being requested and 2
shall be set to 2 when an application key is being requested. 3
4.5.8.6.3 Partner Address Field 4
5
When the key type field is 2 (that is, an application key), the partner address field 6
shall contain the extended 64-bit address of the partner device that shall be sent 7
the key. Both the partner device and the device originating the request-key 8
command will be sent the key. 9
When the key-type field is 1 (that is, a Network key), the partner address field will 10
not be present. 11
12
4.5.8.7 Switch-key Commands 13
14
The APS command frame used by a device for requesting a key is specified in this 15
18
The switch-key command frame shall be formatted as illustrated in Figure 4.15.
19
Octets: 1 1 1 20
21
Frame control Command identifier Sequence number 22
24
Figure 4.15 Switch-key Command Frame Format 25
26
The command identifier field shall indicate the APS command type switch-key 28
(see Table 4.27). 29
30
4.5.8.7.2 Sequence Number Field 31
The sequence number field shall contain the sequence number identifying the 32
Network key to make active. 33
34
35
4.5.9 Security-related AIB Attributes 36
37
The AIB contains attributes that are required to manage security for the APS 38
layer. Each of these attributes can be read or written using the APSME- 39
40
41
42
43
44
45
GET.request and APSME-SET.request primitives, respectively. The security-

related attributes contained in the APS PIB are presented in Tables 4.28 and 4.29. 1
2
Table 4.28 AIB Security Attributes
3
5
apsDeviceKeyPairSet 0xaa Set of Key- Variable A set of key-pair - 6
Pair descriptors
Descriptor containing master 7
entries. See and link key pairs 8
Table 4.29 shared with other 9
devices 10
apsTrustCenterAddress 0xab Device Any Identifies the - 11
address valid address of the 12
64-bit device’s trust 13
address center 14
apsSecurityTimeOutPe 0xac Integer 0x0000- The period of time 1000 15
riod 0xFFFF a device will wait 16
for an expected 17
security protocol
frame (in 18
milliseconds) 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
Chapter 4
Table 4.29 Elements of the Key-Pair Descriptor 1

3
DeviceAddress Device Any valid Identifies the address of the entity - 4
address 64-bit with which this key-pair is shared 5
address
6
MasterKey Set of - The actual value of the master key - 7
16 8
octets
9
LinkKey Set of - The actual value of the link key - 10
16 11
octets
12
OutgoingFrame- Set of 4 0x00000000- Unique identifier of the key 0x00000000 13
Counter octets 0xFFFFFFFF originating with the device 14
indicated by KeySrcAddress 15
IncomingFrame- Set of 4 0x00000000- Incoming frame counter value 0x00000000 16
Counter octets 0xFFFFFFFF corresponding to DeviceAddress 17
18
19
4.6 Common Security Elements 20
21
This clause describes security-related features that are used in more than one 22
ZigBee layer. The NWK and APS layers shall use the auxiliary header as 23
specified in sub-clause 4.6.1. The MAC, NWK, and APS layers shall use the 24
security parameters specified in sub-clause 4.6.2. The formatting of all frames and 25
fields in this specification are depicted in the order in which they are transmitted 26
by the NWK layer, from left to right, where the leftmost bit is transmitted first in 27
time. Bits within each field are numbered from 0 (left-most and least significant) 28
to k-1 (right-most and most significant), where the length of the field is k bits. 29
Fields that are longer than a single octet are sent to the next layer in the order from 30
the octet containing the lowest numbered bits to the octet containing the highest 31
numbered bits. 32
33
34
35
36
37
38
39
40
41
42
43
44
45
4.6.1 Auxiliary Frame Header Format 1

2
The auxiliary frame header, as illustrated by Figure 4.16, shall include a security
3
control field and a frame counter field, and may include a sender address field and
4
key sequence number field.
5
Octets: 1 4 0/8 0/1 6
7
Security control Frame Counter Source Address Key Sequence 8
Number
9
Figure 4.16 Auxiliary Frame Header Format 10
11
4.6.1.1 Security Control Field 12
13
The security control field shall consist of a security level, a key identifier, and an 14
extended nonce sub-field and shall be formatted as shown in Figure 4.17. 15
16
Bit: 0-2 3-4 5 6-7 17
Security level Key identifier Extended Nonce Reserved 18
19
Figure 4.17 Security Control Field Format 20
21
4.6.1.1.1 Security Level Sub-field 22
The security level identifier indicates how an outgoing frame is to be secured, 23
respectively, how an incoming frame purportedly has been secured: it indicates 24
whether or not the payload is encrypted and to what extent data authenticity over 25
the frame is provided, as reflected by the length of the message integrity code 26
(MIC). The bit-length of the MIC may take the values 0, 32, 64 or 128 and 27
determines the probability that a random guess of the MIC would be correct. The 28
security properties of the security levels are listed in Table 4.30. Note that security 29
level identifiers are not indicative of the relative strength of the various security 30
levels. Also note that security levels 0 and 4 should not be used for frame security. 31
32
Table 4.30 Security Levels Available to the MAC, NWK, and APS layers
33
Security Frame Integrity 34
Security Level Sub- (length M of MIC, 35
Level field Security Data in Number of 36
Identifier (Table 4.17) Attributes Encryption Octets) 37
0x00 ‘000’ None OFF NO (M = 0) 38
39
0x01 ‘001’ MIC-32 OFF YES (M=4)
40
0x02 ‘010’ MIC-64 OFF YES (M=8) 41
0x03 ‘011’ MIC-128 OFF YES (M=16) 42
43
44
45
Chapter 4
Table 4.30 Security Levels Available to the MAC, NWK, and APS layers
1
Security Frame Integrity 2
Security Level Sub- (length M of MIC,
Level field Security Data in Number of 3
Identifier (Table 4.17) 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.6.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.31. 16
Table 4.31 Encoding for the Key Identifier Sub-field 17
18
Key Identifier Sub-field
Key Identifier (Table 4.17) Description 19
20
0x00 ‘00’ A link 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.6.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.6.1.2 Source Address Field 32
The source address field shall only be present when the extended nonce sub-field 33
of the security control field is 1. When present, the source address field shall 34
indicate the extended 64-bit address of the device responsible for securing the 35
frame. 36
37
4.6.1.3 Counter Field 38
39
The counter field is used to provide for frame freshness and to prevent processing 40
of duplicate frames. 41
42
43
44
45
4.6.1.4 Key Sequence Number Field

1
The key sequence number field shall only be present when the key identifier sub- 2
field of the security control field is 1 (that is, the Network key). When present, the 3
key sequence number field shall indicate the key sequence number of the Network 4
key used to secure the frame. 5
6
7
4.6.2 Security Parameters 8
9
This sub-clause specifies the parameters used for the CCM* security operations.
10
4.6.2.1 CCM* Mode of Operation and Parameters 11
12
Applying security to a MAC, NWK, or APS frame on a particular security level 13
corresponds to a particular instantiation of the AES-CCM* mode of operation as 14
specified in sub-clause B.1.2. The AES-CCM* mode of operation is an extension 15
of the AES-CCM mode that is used in the 802.15.4-2003 MAC specification and 16
provides capabilities for authentication, encryption, or both. 17
18
The nonce shall be formatted as specified in sub-clause 4.6.2.2. 19
Table 4.30 gives the relationship between the security level subfield of the 20
security control field (Table 4.17), the security level identifier, and the CCM* 21
encryption/authentication properties used for these operations. 22
23
4.6.2.2 CCM* Nonce 24
25
The nonce input used for the CCM* encryption and authentication transformation 26
and for the CCM* decryption and authentication checking transformation consists 27
of data explicitly included in the frame and data that both devices can 28
independently obtain. Figure 4.18 specifies the order and length of the subfields 29
of the CCM* nonce. The nonce's security control and frame counter fields shall be 30
the same as the auxiliary header’s security control and frame counter fields (as 31
defined in sub-clause 4.6.1) of the frame being processed. The nonce’s source 32
address field shall be set to the extended 64-bit MAC address of the device 33
originating security protection of the frame. When the extended nonce sub-field of 34
the auxiliary header’s security control field is 1, the extended 64-bit MAC address 35
of the device originating security protection of the frame shall correspond to the 36
auxiliary header’s source address field (as defined in sub-clause 4.6.1) of the 37
frame being processed 38
Octets: 8 4 1 39
40
Source address Frame counter Security control 41
42
Figure 4.18 CCM* Nonce
43
44
45
Chapter 4
4.6.3 Cryptographic Key Hierarchy 1

2
The link key established between two (or more) devices via one of the key-
3
establishment schemes specified in sub-clause 4.5.2 (or transport-key commands
4
specified in sub-clause 4.5.3) is used to determine related secret keys, including
5
data keys, key-transport keys, and key-load keys. These keys are determined as
6
follows:
7
1 Key-Transport Key. This key is the outcome of executing the specialized keyed 8
hash function specified in sub-clause B.1.4 under the link key with as input 9
string the 1-octet string ‘0x00’. 10
11
2 Key-Load Key. This key is the outcome of executing the specialized keyed hash
12
function specified in sub-clause B.1.4 under the link key with as input string
13
the 1-octet string ‘0x02’.
14
3 Data Key. This key is equal to the link key. 15
16
All keys derived from the link key shall share the associated frame counters. Also,
17
all layers of ZigBee shall share the Network key and associated outgoing and
18
incoming frame counters.
19
20
4.6.4 Implementation Guidelines (Informative) 21
22
This clause provides general guidelines that should be followed to ensure a secure 23
implementation. 24
25
4.6.4.1 Random Number Generator 26
27
A ZigBee device implementing the key-establishment (that is, see sub- 28
clause 4.2.4.1) security service may need a strong method of random number 29
generation. For example, when link keys are pre-installed (for example, in the 30
factory), a random number may not be needed. 31
In all cases that require random numbers, it is critical that the random numbers are 32
not predictable or have enough entropy, so an attacker will not be able determine 33
them by exhaustive search. The general recommendation is that the random 34
number generation shall meet the random number tests specified in FIPS140- 35
2 [B12]. Methods for generation of random numbers include: 36
37
1 Base the random number on random clocks and counters within the ZigBee
38
hardware; 39
2 Base the random number on random external events; 40
41
3 Seed each ZigBee device with a good random number from an external source
42
during production. This random number can then used as a seed to generate 43
additional random numbers. 44
45
A combination of these methods can be used. Since the random number

generation is likely integrated into the ZigBee IC, its design and hence the 1
ultimate viability of any encryption/security scheme is left up to the IC 2
manufacturers. 3
4
4.6.4.2 Security Implementation 5
6
To avoid “bugs” that an attacker can use to his advantage, it is crucial that security 7
be well implemented and tested. It is also desirable that the security 8
implementation does not need to be re-certified for every application. Security 9
services should be implemented and tested by security experts and should not be 10
re-implemented or modified for different applications. 11
12
4.6.4.3 Conformance 13
Conformance shall be defined by the profile inheriting from this specification. 14
Correct implementation of selected cryptographic protocols should be verified as 15
part of the ZigBee certification process. This verification shall include known 16
value tests: an implementation must show that given particular parameters, it will 17
correctly compute the corresponding results. 18
19
20
4.7 Functional Description 21
22
23
This sub-clause provides detailed descriptions of how the security services shall
24
be used in a ZigBee network. A description of the ZigBee coordinator’s security
25
initialization responsibilities is given in sub-clause 4.7.1. A brief description of
26
the trust center application is given in sub-clause 4.7.2. Detailed security
27
procedures are given in sub-clause 4.7.3.
28
29
4.7.1 ZigBee Coordinator 30
31
The ZigBee coordinator shall configure the security level of the network by 32
setting the NwkSecurityLevel attribute in the NWK layer PIB table. If the 33
NwkSecurityLevel attribute is set to zero, the network will be unsecured, otherwise 34
it will be secured. 35
36
The ZigBee coordinator shall configure the address of the trust center by setting
37
the AIB attribute apsTrustCenterAddress. The default value of this address is the
38
ZigBee coordinator’s address itself, otherwise, the ZigBee coordinator may
39
designate an alternate trust center.
40
41
42
43
44
45
Chapter 4
4.7.2 Trust Center Application 1

2
The trust center application runs on a device trusted by devices within a ZigBee
3
network to distribute keys for the purpose of network and end-to-end application
4
configuration management. The trust center shall be configured to operate in
5
either commercial or residential mode and may be used to help establish end-to-
6
end application keys either by sending out link keys directly (that is, key-escrow
7
capability) or by sending out master keys. These keys shall be generated at
8
random.
9
4.7.2.1 Commercial Mode 10
11
The commercial mode of the trust center is designed for high-security commercial 12
applications. In this mode, the trust center shall maintain a list of devices, master 13
keys, link keys, and Network keys that it needs to control and enforce the policies 14
of Network key updates and network admittance. In this mode, the memory 15
required for the trust center grows with the number of devices in the network and 16
the nwkAllFresh attribute in the NIB shall be set to TRUE. 17
18
4.7.2.2 Residential Mode 19
20
The residential mode of the trust center is designed for low-security residential 21
applications. In this mode, the trust center may maintain a list of devices, master 22
keys, or link keys with all the devices in the network; however, it shall maintain 23
the Network key and controls policies of network admittance. In this mode, the 24
memory required for the trust center does not grow with the number of devices in 25
the network and the nwkAllFresh attribute in the NIB shall be set to FALSE. 26
27
4.7.3 Security Procedures 28
29
This sub-clause gives message sequence charts for joining a secured network, 30
authenticating a newly joined device, updating the Network key, recovering the 31
Network key, establishing end-to-end application keys, and leaving a secured 32
network. 33
34
4.7.3.1 Joining a Secured Network 35
36
Figure 4.19 shows an example message sequence chart ensuing from when a 37
joiner device communicates with a router device to join a secured network. 38
39
40
41
42
43
44
45
Router Joiner
1
ZDO NWK MAC MAC NWK ZDO
2
NLME-PERMIT-JOINING.request NLME-NETWORK-DISCOVERY.request 3
MLME-SET.request(macAssociationPermit = TRUE) MLME-SCAN.request 4
Beacon request command (unsecured)
5
6
Beacon (unsecured)
MLME-SCAN.confirm 7
NLME-NETWORK-DISCOVERY.confirm
8
9
NLME-JOIN.request
10
MLME-ASSOCIATE.request
Association request command 11
MLME-ASSOCIATE.indication
12
13
NLME-JOIN.indication
14
MLME-ASSOCIATE.response
Association response command
15
MLME-ASSOCIATE.confirm
16
NLME-JOIN.confirm
17
18
Joined (unauthenticated) 19
20
Successful Authenticate Routine (see 8.3.2) 21
22
NLME-START-ROUTER.request (only if B is a router) 23
MLME-START.request (only if B is a router) 24
25
Joined (authenticated)
26
27
Figure 4.19 Example of Joining a Secured Network 28
29
The joiner device may begin the join procedure by issuing an NLME- 30
NETWORK-DISCOVERY.request primitive. This primitive will invoke an 31
MLME-SCAN.request primitive which may cause the transmission of an 32
unsecured beacon request frame (depending on whether the scan is an active or 33
passive scan). 34
The joiner device receives beacons from nearby routers and the NWK layer will 35
issue an NLME-NETWORK-DISCOVERY.confirm primitive. The NetworkList 36
parameter of this primitive will indicate all of the nearby PANs along with their 37
nwkSecurityLevel and nwkSecureAllFrames attributes. In Figure 4.19, the shown 38
router device has already been placed in a state such that its beacons have the 39
“association permit” sub-field set to “1” (permit association). 40
41
The joiner device shall decide which PAN to join (for example, based on the 42
security attributes received in NLME-NETWORK-DISCOVERY.confirm 43
primitive) and shall issue the NLME-JOIN.request primitive to join that PAN. If 44
45
Chapter 4
the joiner already has a Network key for this PAN, the SecurityEnable parameter
for the NLME-JOIN.request primitive shall be set to TRUE; otherwise it shall be 1
set to FALSE. As shown in Figure 4.19, the NLME-JOIN.request primitive causes 2
an association request command to be sent to the router. 3
4
Upon receipt of the association request command, the router shall issue an 5
MLME-ASSOCIATE.indication primitive with the SecurityUse parameter set to 6
TRUE or FALSE, depending on whether or not the association request command 7
was secured. Next, the NWK layer will issue an NLME-JOIN.indication primitive 8
to the router’s ZDO. The router shall now know the joiner device’s address and 9
whether the Network key was used to secure the association request command. 10
The router will also issue an MLME-ASSOCIATE.response primitive with the 11
SecurityEnable parameter set to TRUE or FALSE, depending on whether or not 12
the association request command was secured or not, respectively. This primitive 13
will cause an association response command to be sent to the joiner. 14
Upon receipt of the association response command, the joiner shall issue the 15
NLME-JOIN.confirm primitive The joiner is now declared “joined, but 16
unauthenticated” to the network. The authentication routine (see sub- 17
clause 4.7.3.2) shall follow. 18
19
If the joiner is not a router, it is declared “joined and authenticated” immediately 20
following the successful completion of the authentication routine. 21
If the joiner is a router, it is declared “joined and authenticated” only after the 22
successful completion of the authentication routine followed by the initiation of 23
routing operations. Routing operations shall be initiated by the joiner’s ZDO 24
issuing the NLME-START.request primitive to cause the MLME-START.request 25
primitive to be sent to the MAC layer of the joiner. 26
27
If the router refuses the joiner, its association response frame shall contain the 28
association status field set to a value other than “0x00”, and, after this parameter 29
reaches the ZDO of the joiner in the NLME-JOIN.confirm primitive, the joiner 30
shall not begin the authentication routine. 31
32
4.7.3.2 Authentication 33
Once a device joins a secured network and is declared “joined but 34
unauthenticated”, it must be authenticated as specified in this sub-clause. 35
36
4.7.3.2.1 Router Operation 37
If the router is not the trust center, it shall begin the authentication procedure 38
immediately after receipt of the NLME-JOIN.indication primitive by issuing an 39
APSME-UPDATE-DEVICE.request primitive with the DestAddress parameter 40
set to the apsTrustCenterAddress in the AIB and the DeviceAddress parameter set 41
to the address of the newly joined device. The Status parameter of this primitive 42
shall be set to 0x00 (that is, secured join) if the newly joined device secured the 43
44
45
associate request command. Otherwise, the Status parameter shall be set to 0x01
(that is, unsecured join). 1
2
If the router is the trust center, it shall begin the authentication procedure by 3
simply operating as a trust center. 4
4.7.3.2.2 Trust Center Operation 5
6
The trust center role in the authentication procedure shall be activated upon 7
receipt of an incoming update-device command or immediately after receipt of the 8
NLME-JOIN.indication primitive (in the case where the router is the trust center). 9
The trust center behaves differently depending on at least five factors: 10
• Whether the trust center decides to allow the new device to join the network 11
(for example, the trust center is in a mode that allows new devices to join); 12
13
• Whether the trust center is operating in residential or commercial mode (see 14
sub-clause 4.7.2.1 and sub-clause 4.7.2.2, respectively); 15
• If in residential mode, whether the device is joining unsecured or secured (that 16
is, as indicated by the Status sub-field of the update-device command); 17
18
• If in commercial mode, whether the trust center has a master key corresponding 19
to the newly joined device; 20
• The nwkSecureAllFrames parameter of the NIB. 21
22
If, at any time during the authentication procedure, the trust center decides not to 23
allow the new device to join the network (for example, a policy decision or a 24
failed key-establishment protocol), it shall take actions to remove the device from 25
the network. If the trust center is not the router of the newly joined device, it shall 26
remove the device from the network by issuing the APSME-REMOVE- 27
DEVICE.request primitive with the ParentAddress parameter set to the address of 28
the router originating the update-device command and the ChildAddress 29
parameter set to the address of the joined (but unauthenticated) device. If the trust 30
center is the router of the newly joined device, it shall remove the device from the 31
network by issuing the NLME-LEAVE.request primitive with the DeviceAddress 32
parameter set to the address of the joined (but unauthenticated) device, the Rejoin 33
parameter set to 0, the SilentLeave parameter set to 1 and the ReuseAddress 34
parameter set to 1. Other fields are defined by the stack profile.19 35
36
4.7.3.2.2.1 Residential Mode 37
38
After being activated for the authentication procedure the trust center shall send
39
the device the active Network key by issuing the APSME-TRANSPORT-
40
KEY.request primitive with the DestAddress parameter set to the address of the
41
newly joined device, and the KeyType parameter to 0x01 (that is, Network key).
42
43
19. CCB #676 44
45
Chapter 4
If the joining device already has the Network key (that is, the Status sub-field of
the update-device command is 0x00), the TransportKeyData sub-parameters shall 1
be set as follows: the KeySeqNumber sub-parameter shall be set to 0, the 2
NetworkKey sub-parameter shall be set to all zeros, and the UseParent sub- 3
parameter shall be set to FALSE. 4
5
Otherwise, the KeySeqNumber sub-parameter shall be set to the sequence count 6
value for this Network key, the NetworkKey sub-parameter shall be set to Network 7
key. The UseParent sub-parameter shall be set to FALSE if the trust center is the 8
router; otherwise, the UseParent sub-parameter shall be set to TRUE and the 9
ParentAddress sub-parameter shall be set to the address of the router originating 10
the update-device command. 11
In the case of a joining device that is not pre-configured with a Network key, the 12
issuance of this transport-key primitive will cause the Network key to be sent 13
unsecured from the router to the newly joined device — security is assumed to be 14
present here via non-cryptographic means — such as only sending this key once, 15
at low power, immediately after external input to both router and joiner, that can 16
guarantee secrecy and authenticity. If the joining device did not receive the key 17
within apsSecurityTimeOutPeriod, it shall reset and may choose to start the 18
joining procedure again. 19
20
4.7.3.2.2.2 Commercial Mode 21
22
After being activated for the authentication procedure, the trust center operation in 23
commercial mode depends on if the device joining the network is preconfigured 24
with a trust center master key. 25
If the trust center does not already share a master key with the newly joined 26
device, it shall send the device a master key by issuing the APSME- 27
TRANSPORT-KEY.request primitive with the DestAddress parameter set to the 28
address of the newly joined device, and the KeyType parameter to 0x00 (that is, 29
trust center master key). The TransportKeyData sub-parameters shall be set as 30
follows: the TrustCenterMasterKey sub-parameter shall be set to trust center 31
master key, and the ParentAddress sub-parameter shall set to the address of the 32
local device if the trust center is the router. Otherwise, the ParentAddress sub- 33
parameter shall set to the address of the router originating the update-device 34
command. The issuance of this primitive will cause the master key to be sent 35
unsecured from the router to the newly joined device—security is assumed to be 36
present here via non-cryptographic means, such as only sending this key once, at 37
low power, immediately after external input to both router and joiner, etc. 38
39
The trust center shall initiate the establishment of a link key by issuing the 40
APSME-ESTABLISH-KEY.request primitive with the ResponderAddress 41
parameter set to the address of the newly joined device and the 42
KeyEstablishmentMethod set to 0x00 (that is, SKKE). Additionally, if the 43
nwkSecureAllFrames parameter of the NIB is FALSE or the trust center is the 44
45
router, the UseParent parameter shall be set to FALSE. Otherwise, the UseParent
parameter shall be set to TRUE and the ResponderParentAddress parameter shall 1
be set to the address of the router originating the update-device command. 2
3
Upon receipt of the corresponding APSME-ESTABLISH-KEY.confirm primitive 4
with Status equal to 0x00 (that is, success), the trust center shall send the new 5
device the Network key by issuing the APSME-TRANSPORT-KEY.request 6
primitive with the DestAddress parameter set to the address of the newly joined 7
device, and the KeyType parameter to 0x01 (that is, Network key). The 8
TransportKeyData sub-parameters shall be set as follows: 9
• The KeySeqNumber sub-parameter shall be set to the sequence count value for 10
this Network key; 11
12
• The NetworkKey sub-parameter shall be set to Network key; 13
• The UseParent sub-parameter shall be set to FALSE. 14
15
4.7.3.2.3 Joining Device Operation 16
After successfully associating to a secured network, the joining device shall 17
participate in the authentication procedure described in this sub-clause. Following 18
a successful authentication procedure, the joining device shall set the 19
nwkSecurityLevel and nwkSecureAllFrames attributes in the NIB to the values 20
indicated in the beacon from the router. 21
22
A joined and authenticated device in a secured network with nwkSecureAllFrames 23
equal to TRUE shall always apply NWK layer security to outgoing (incoming) 24
frames unless the frame is destined for (originated from) a newly joined but 25
unauthenticated child. No such restrictions exist if nwkSecureAllFrames is equal 26
to FALSE. 27
The joining device’s participation in the authentication procedure depends on the 28
state of the device. There are three possible initial states to consider: 29
30
• Preconfigured with a Network key (that is, residential mode) 31
• Preconfigured with a trust center master key and address (that is, commercial 32
mode) 33
34
• Not preconfigured (that is, undetermined mode – either residential or 35
commercial mode) 36
In a secured network, if the device does not become authenticated within a 37
preconfigured amount of time, it shall leave the network. 38
39
4.7.3.2.3.1 Preconfigured Network Key 40
41
If the joining device was preconfigured with just a Network key (and the 42
association was successful), it shall set the outgoing frame counter for this key to 43
zero, and empty the incoming frame counter set for this key, and wait to receive a 44
45
Chapter 4
dummy (all zero) Network key from the trust center. Upon receipt of the APSME-
TRANSPORT-KEY.indication primitive with the KeyType parameter set to 0x01 1
(that is, the Network key), the joining device shall set the apsTrustCenterAddress 2
attribute in its AIB to the SrcAddress parameter of the APSME-TRANSPORT- 3
KEY.indication primitive. The joining device is now considered authenticated and 4
shall enter the normal operating state for residential mode. 5
6
4.7.3.2.3.2 Preconfigured Trust Center Key 7
8
If the joining device is preconfigured with a trust center master key and address 9
(that is, the apsTrustCenterAddress attribute in the AIB) it shall wait to establish a 10
link key and receive a Network key from the trust center. Therefore, upon receipt 11
of the APSME-ESTABLISH-KEY.indication primitive with the InitiatorAddress 12
parameter set to the trust center’s address and the KeyEstablishmentMethod 13
parameter set to SKKE, the joining device shall respond with the APSME- 14
ESTABLISH-KEY.response primitive with the InitiatorAddress parameter set to 15
the trust center’s address and the Accept parameter set to TRUE. After receipt of 16
the APSME-ESTABLISH-KEY.confirm primitive with the Address parameter set 17
to the trust center’s address and the Status parameter set to 0x00 (that is, success), 18
the joining device shall expect to receive the Network key. Upon receipt of the 19
APSME-TRANSPORT-KEY.indication primitive with SourceAddress parameter 20
set to the trust center’s address and with the KeyType parameter set to 0x01 (that 21
is, the Network key), the joining device shall use the data in the 22
TransportKeyData parameter for configuring the Network key. All incoming 23
frame counters and the outgoing frame counter of the Network key shall be set to 24
0.20 The joining device is now considered authenticated and shall enter the normal 25
operating state for commercial mode. If the joining device did not receive the 26
APSME-ESTABLISH-KEY.indication primitive with the InitiatorAddress 27
parameter set to the trust center’s address and the KeyEstablishmentMethod 28
parameter set to SKKE within apsSecurityTimeOutPeriod, it shall reset and may 29
choose to start the joining procedure again. 30
31
4.7.3.2.3.3 Not Preconfigured 32
33
If the joining device is not preconfigured with a Network key nor a trust center 34
master key and address (that is, the apsTrustCenterAddress attribute in the AIB) it 35
shall wait to receive either an unsecured trust center master key or a Network key. 36
Implementers should note that transmission of an unsecured key represents a 37
security risk and that if security is a concern, keys should be preconfigured – 38
preferable via an out-of-band mechanism that guarantees secrecy and authenticity. 39
If the joining device did not receive either of the keys within 40
apsSecurityTimeOutPeriod, it shall reset and may choose to start the joining 41
procedure again. 42
43
20. CCB #671 44
45
Upon receipt of the APSME-TRANSPORT-KEY.indication primitive with the

KeyType parameter set to 0x01 (that is, the Network key), the joining device shall 1
make the data in the TransportKeyData parameter its active Network key and 2
shall set the apsTrustCenterAddress attribute in its AIB to the SrcAddress 3
parameter of the APSME-TRANSPORT-KEY.indication primitive. The joining 4
device is now considered authenticated and shall enter the normal operating state 5
for residential mode. 6
7
Upon receipt of the APSME-TRANSPORT-KEY.indication primitive with the 8
KeyType parameter set to 0x00 (that is, the trust center master key), the joining 9
device shall make its trust center master key the data in the TransportKeyData 10
parameter and the apsTrustCenterAddress attribute in its AIB the SrcAddress 11
parameter. Next, upon receipt of the APSME-ESTABLISH-KEY.indication 12
primitive with the InitiatorAddress parameter set to the trust center’s address and 13
the KeyEstablishmentMethod parameter set to SKKE, the joining device shall 14
respond with the APSME-ESTABLISH-KEY.response primitive with the 15
InitiatorAddress parameter set to the trust center’s address and the Accept 16
parameter set to TRUE. After receipt of the APSME-ESTABLISH-KEY.confirm 17
primitive with the Address parameter set to the trust center’s address and the 18
Status parameter set to 0x00 (that is, success), the joining device shall expect to 19
receive the Network key. Upon receipt of the APSME-TRANSPORT- 20
KEY.indication primitive with SourceAddress parameter set to the trust center’s 21
address and with the KeyType parameter set to 0x01 (that is, the Network key), 22
the joining device shall use the data in the TransportKeyData parameter for 23
configuring the Network key. All incoming frame counters and the outgoing 24
frame counter of the Network key shall be set to 0.21 The joining device is now 25
considered authenticated and shall enter the normal operating state for 26
commercial mode. 27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
21. CCB #671 44
45
Chapter 4
Trust Center Router Joiner

1
2
Joined (unauthenticated)
3
Update-Device Command 4
5
Decision to accept 6
new device
7
Secured Transport-Key Command(NWK key)
1
1
8
Unsecured Transport-Key Command(NWK key) 9
Joined (authenticated)
10
11
Note: 12
1. The trust center sends a dummy all-zero NWK key if the joiner securely joined using a preconfigured network key.
13
14
Figure 4.20 Example Residential-Mode Authentication Procedure
15
4.7.3.2.4 Message Sequence Charts 16
17
Figure 4.20 and 4.21 give example message sequence charts for the authentication 18
procedure when the router and trust center are separate devices operating in 19
residential or commercial mode, respectively. 20
In Figure 4.20 the update-device and transport-key commands communicated 21
between the trust center and the router shall be secured at the APS layer based on 22
the Network key; If the nwkSecureAllFrames NIB attribute is TRUE, it is also 23
secured at the NWK layer with the Network key. The transport-key command sent 24
from the router to joiner shall not be secured. 25
26
In Figure 4.21, the update-device and transport-key commands communicated 27
between the trust center, and the router shall be secured at the APS layer based on 28
the trust center link key; If the nwkSecureAllFrames NIB attribute is TRUE, it is 29
also secured at the NWK layer with the Network key. The transport-key command 30
sent from the router to joiner shall not be secured. The SKKE commands shall be 31
sent using the router as a liaison when the nwkSecureAllFrames NIB attribute is 32
TRUE, such that SKKE commands between the trust center and router shall be 33
secured at the NWK layer with the Network key and commands between the 34
router and joiner shall not be secured. Otherwise, the SKKE commands shall be 35
unsecured between the trust center and joiner. The final transport-key 36
communicated between the trust center and the joiner shall be secured at the APS 37
layer based on the trust center link key and, if the nwkSecureAllFrames NIB 38
attribute is TRUE, also secured at the NWK layer with the Network key. 39
40
41
42
43
44
45
Trust Center Router Joiner 1

2
Joined (unauthenticated) 3
4
Update-Device Command
5
Decision to accept 6
new device 7
Secured Transport-Key Command (Master key)
1 8
1 9
Unsecured Transport-Key Command (Master key)
10
SKKE-1 Command
11
SKKE-2 Command 12
SKKE-3 Command
See 13
Note 2
14
SKKE-4 Command 15
Secured Transport-Key Command(NWK key) 16
17
Joined (authenticated) 18
19
Notes:
1. The trust center does not send a master key if it already shares one with the joiner device (i.e., the pre-configured situation) 20
2. SKKE commands shall be sent using the router as a liaison when the nwkSecureAllFrame NIB attribute is TRUE (i.e., these 21
commands will be secured between the trust center and router at the NWK layer, but not between the router and joiner). 22
23
Figure 4.21 Example Commercial-Mode Authentication Procedure 24
25
4.7.3.3 Network Key Update 26
The trust center and network device shall follow the procedures described in this 27
sub-clause when updating the Network key. 28
29
31
When operating in residential mode, the trust center may update the Network key
32
for all devices on the network. To update the Network key, the trust center shall
33
first send the new Network key by issuing the APSME-TRANSPORT-
34
KEY.request primitive with the DestAddress parameter set to the broadcast
35
address and the KeyType parameter set to 0x01 (that is, Network key). The
36
TransportKeyData sub-parameters shall be set as follows:
37
• The KeySeqNumber sub-parameter shall be set to the sequence count value for 38
40
• The NetworkKey sub-parameter shall be set to Network key;
41
• The UseParent sub-parameter shall be set to FALSE. 42
43
44
45
Chapter 4
If the sequence count for the previously distributed Network key is represented as
N, then the sequence count for this new Network key shall be (N+1) mod 256. The 1
trust center may cause a switch with this new key by issuing the APSEME- 2
SWITCH-KEY.request primitive with the DestAddress parameter set to the 3
broadcast address and the KeySeqNumber parameter set to the sequence count 4
value for the updated Network key. 5
6
When operating in commercial mode, the trust center shall maintain a list of all 7
devices in the network. To update the Network key, the trust center shall first send 8
the new Network key to each device on this list and then ask each device to switch 9
to this new key. The new Network key shall be sent to a device on the list by 10
issuing the APSME-TRANSPORT-KEY.request primitive with the DestAddress 11
parameter set to the address of the device on the list and the KeyType parameter 12
set to 0x01 (that is, Network key). The TransportKeyData sub-parameters shall be 13
set as follows: 14
The KeySeqNumber sub-parameter shall be set to the sequence count value for 15
17
The NetworkKey sub-parameter shall be set to the Network key; 18
The UseParent sub-parameter shall be set to FALSE. 19
20
If the sequence count for the previously distributed Network key is represented as 21
N, then the sequence count for this new Network key shall be (N+1) mod 256. The 22
trust center shall ask a device to switch to this new key by issuing the APSME- 23
SWITCH-KEY.request primitive with the DestAddress parameter set to the 24
address of the device on the list and the KeySeqNumber parameter set to the 25
sequence count value for the updated Network key. 26
4.7.3.3.2 Network Device Operation 27
28
When in the normal operating state and upon receipt of a APSME-TRANSPORT- 29
KEY.indication primitive with the KeyType parameter set to 0x01 (that is, 30
Network key), a device shall accept the TransportKeyData parameters as a 31
Network key only if the SrcAddress parameter is the same as the trust center’s 32
address (as maintained in the apsTrustCenterAddress attribute of the AIB). If 33
accepted and if the device is capable of storing an alternate Network key, the key 34
and sequence number data contained in the TransportKeyData parameter shall 35
replace the alternate Network key. Otherwise, the key and sequence number data 36
contained in the TransportKeyData parameter shall replace the active Network 37
key. In either case, all incoming frame counters and the outgoing frame counter of 38
the Network key shall be set to 0.22 39
When in the normal operating state and upon receipt of a APSME-SWITCH- 40
KEY.indication primitive, a device shall switch its active Network key to the one 41
42
43
22. CCB #671 44
45
designated by the KeySeqNumber parameter only if the SrcAddress parameter is

the same as the trust center’s address (as maintained in the apsTrustCenterAddress 1
attribute of the AIB). 2
3
4
Trust Center Device 1 Device 2
5
Transport-Key Command(NWK key, N) 6
7
Replace alternate network
key with network key N. 8
9
Transport-Key Command(NWK key, N)
10
Switch-Key Command(N) Replace active network 11
key with network key N. 12
Make network key N the 13
active network key.
14
Switch-Key Command(N)
15
Ignore command.
16
17
18
Figure 4.22 Example Network Key-Update Procedure 19
20
4.7.3.3.3 Message Sequence Chart 21
22
An example of a successful Network key-update procedure for two devices is
23
shown in Figure 4.22. In this example, the trust center sends the Network key with
24
sequence number N to devices 1 and 2. In this example, device 1 is an FD capable
25
of storing two Network keys, an active and alternate, and device 2 is an RFD that
26
can store only a single Network key. Upon receipt of the transport-key command,
27
device 1 replaces its alternate Network key with the new Network key; however
28
device 2 must replace its active Network key with the new key. Next, upon receipt
29
of the switch-key command, device 1 makes the new Network key the active
30
Network key; however device 2 has just one active Network key, so it ignores this
31
command.
32
33
4.7.3.4 Network Key Recovery
34
A network device and trust center shall follow the procedures described in this 35
sub-clause when recovering the Network key. 36
37
4.7.3.4.1 Network Device Operation 38
When in the normal operating state a network device shall request the current 39
Network key by issuing the APSME-REQUEST-KEY.request primitive with the 40
DestAddress parameter set to the trust center’s address (as maintained in the 41
apsTrustCenterAddress attribute of the AIB), the KeyType parameter set to 0x01 42
(that is, Network key), and the PartnerAddress parameter set to 0. 43
44
45
Chapter 4
Trust Center Device A

Request-Key Command(NWK key)
1
2
Make sure device A is 3
part of the network.
Transport-Key Command(NWK key, N)
4
5
Replace alternate network 6
key with network key N.
Switch-Key Command(N) 7
8
Make network key N the
active network key.
9
10
11
12
13
Figure 4.23 Example Network Key-Recovery Procedure 14
15
When operating in commercial mode and receipt of APSME-REQUEST- 17
KEY.indication primitives with the KeyType parameter set to 0x01 (that is, 18
Network key), the trust center shall determine whether the device indicated by the 19
SrcAddress parameter is present on its list of all devices on the network. When 20
operating in residential mode and receipt of APSME-REQUEST-KEY.indication 21
primitive with the KeyType parameter set to 0x01 (that is, Network key), the trust 22
center shall assume the device indicated by the SrcAdress parameter to be present 23
on the list of devices on the network. If the device is present on this list, the trust 24
center shall issue the APSME-TRANSPORT-KEY.request primitive with the 25
DestAddress parameter set to the address of the device requesting the key and the 26
KeyType parameter set to 0x01 (that is, Network key). The TransportKeyData 27
sub-parameters shall be set as follows. The KeySeqNumber sub-parameter shall be 28
set to the sequence count value for this Network key, the NetworkKey sub- 29
parameter shall be set to the Network key, and the UseParent sub-parameter shall 30
be set to FALSE. Next, the trust center shall ask a device to switch to this new key 31
by issuing the APSME-SWITCH-KEY.request primitive with the DestAddress 32
parameter set to the address of the device that requested the key and the 33
KeySeqNumber parameter set to the sequence count value for the updated 34
Network key. 35
36
An example of a successful Network key-recovery procedure is shown in 38
Figure 4.23. In this example, the network device requests the current Network key 39
from the trust center. The trust center responds with current key and then tells the 40
device to switch to this key. 41
42
43
44
45
4.7.3.5 End-to-End Application Key Establishment

1
An initiator device, a trust center, and a responder device shall follow the 2
procedures described in this sub-clause when establishing a link key for purposes 3
of end-to-end application security between initiator and responder devices. 4
5
4.7.3.5.1 Device Operation
6
The initiator device shall begin the procedure to establish a link key with a 7
responder device by issuing the APSME-REQUEST-KEY.request primitive. The 8
DstDevice parameter shall be set to the address of its trust center, the KeyType 9
parameter shall be set to 0x02 (that is, application key), and the PartnerAddress 10
parameter shall be set to the address of the responder device. 11
12
4.7.3.5.1.1 Upon Receipt of a Link Key 13
14
Upon receipt of an APSME-TRANSPORT-KEY.indication primitive with the 15
KeyType parameter set to 0x03 (that is, application link key), a device may accept 16
the TransportKeyData parameters as a link key with the device indicated by the 17
PartnerAddress parameter only if the SrcAddress parameter is the same as the 18
apsTrustCenterAddress attribute of the AIB. If accepted, the DeviceKeyPairSet 19
attribute in AIB table will be updated. A key-pair descriptor in the AIB shall be 20
created (or updated if already present), for the device indicated by the 21
PartnerAddress parameter, by setting the DeviceAddress element to the 22
PartnerAddress parameter, the LinkKey element to the link key from the 23
TransportKeyData parameter, and the OutgoingFrameCounter and 24
IncomingFrameCounter elements to 0. 25
26
4.7.3.5.1.2 Upon Receipt of a Master Key 27
Upon receipt of an APSME-TRANSPORT-KEY.indication primitive with the 28
KeyType parameter set to 0x02 (that is, application master key), a device may 29
accept the TransportKeyData parameters as a master key with the device 30
indicated by the PartnerAddress sub-parameter only if the SrcAddress parameter 31
is the same as the apsTrustCenterAddress attribute of the AIB. If accepted, the 32
DeviceKeyPairSet attribute in AIB table will be updated. A key-pair descriptor 33
shall be created (or updated if already present), for the device indicated by the 34
PartnerAddress parameter, by setting the DeviceAddress element to the 35
PartnerAddress parameter, the MasterKey element to the master key from the 36
TransportKeyData parameter, and the OutgoingFrameCounter and 37
IncomingFrameCounter elements to 0. 38
39
Next, if the Initiator sub-parameter of the TransportKeyData parameter of the 40
APSME-TRANSPORT-KEY.indication primitive was TRUE, the device shall 41
issue the APSME-ESTABLISH-KEY.request primitive. The ResponderAddress 42
parameter shall be set to the PartnerAddress sub-parameter of the 43
44
45
Chapter 4
TransportKeyData parameter, the UseParent parameter shall be set to FALSE,

and the KeyEstablishmentMethod shall be set to 0x00 (that is, SKKE). 1
2
Upon receipt of the APSME-ESTABLISH-KEY.indication primitive, the 3
responder device shall be informed that the initiator device wishes to establish a 4
link key. If the responder decides to establish a link key, it shall issue the APSME- 5
ESTABLISH-KEY.response primitive with the InitiatorAddress parameter set to 6
the address of the initiator and the Accept parameter set to TRUE. Otherwise, it 7
shall set the Accept parameter set to FALSE. 8
If the responder decided to set up a key with the initiator, the SKKE protocol will 9
ensue and the APSME-ESTABLISH-KEY.confirm primitive will be issued to 10
both the responder and initiator. 11
12
Upon receipt of APSME-REQUEST-KEY.indication primitives with the KeyType 14
parameter set to 0x02 (that is, application key), the trust center behavior depends 15
on if it has been configured to send out application link keys or master keys. 16
17
The trust center shall issue two APSME-TRANSPORT-KEY.request primitives. If 18
configured to send out application link keys the KeyType parameter shall be set to 19
0x03 (that is, application link key); otherwise, the KeyType parameter shall be set 20
to 0x02 (that is, application master key). The first primitive shall have the 21
DestAddress parameter set to the address of the device requesting the key. The 22
TransportKeyData sub-parameters shall be set as follows: 23
• The PartnerAddress sub-parameter shall be set to the PartnerAddress sub- 24
parameter of the APSME-REQUEST-KEY.indication primitive’s 25
27
• The Initiator sub-parameter shall be set to TRUE; 28
• The Key sub-parameter shall be set to a new key K (a master or link key). 29
30
The key shall have been generated in a random fashion. The second primitive 31
shall have the DestAddress parameter set to the PartnerAddress sub-parameter of 32
the APSME-REQUEST-KEY.indication primitive’s TransportKeyData parameter. 33
The TransportKeyData sub-parameters shall be set as follows: the PartnerAddress 34
sub-parameter shall be set to the address of the device requesting the key, the 35
Initiator sub-parameter shall be set to FALSE, and the Key sub-parameter shall be 36
set to K. 37
39
An example message sequence chart of the end-to-end application key 40
establishment procedure is shown in Figure 4.24. The procedure begins with the 41
transmission of the request-key command from the initiator to the trust center. 42
Next, the trust center starts a time-out timer. For the duration of this timer (that is, 43
44
45
until it expires), the trust center shall discard any new request-key commands for
this pair of devices unless they are from the initiator. 1
2
The trust center shall now send transport-key commands containing the 3
application link or master key to the initiator and responder devices. Only the 4
initiator’s transport-key command will have the Initiator field set to 1 (that is, 5
TRUE), so if a master key was sent, only the initiator device will begin the key- 6
establishment protocol by sending the SKKE-1 command. If the responder 7
decides to accept establishing a key with the initiator, the SKKE protocol will 8
progress via the exchange of the SKKE-2, SKKE-3, and SKKE-4 commands. 9
Upon completion (or time-out), the status of the protocol is reported to the ZDOs 10
of the initiator and responder devices. If successful, the initiator and responder 11
will now share a link key and secure communications will be possible. 12
13
Initiator Trust Center Responder 14
15
Learn address of responder via discovery
or other means (e.g., preloaded) 16
Request-Key Command(key, responder address)
17
18
Start a timer and send a link or master key to initiator and responder. The 19
trust center shall discard new request-key commands for this pair of
devices, unless they are from the initiator, until after the timer expires.
20
21
Transport-Key Command(key, Initiator=TRUE,
PartnerAddress = Responder’s address) Transport-Key Command(key, Initiator=FALSE, 22
PartnerAddress = Initiator’s address) 23
24
Stores key and, if a master key,
initiates key establishment
Decides whether
to the store key
25
26
SKKE-1 Command 27
Responder decides whether to run
28
key-establishment protocol 29
SKKE-2 Command 30
31
SKKE-3 Command
32
SKKE-4 Command 33
34
Status of SKKE reported to ZDO Status of SKKE reported to ZDO
35
36
Figure 4.24 Example End-to-End Application Key Establishment Procedure 37
38
4.7.3.6 Network Leave 39
40
A device, its router, and the trust center shall follow the procedures described in 41
this sub-clause when the device is to leave the network. 42
43
44
45
Chapter 4
4.7.3.6.1 Trust Center Operation

1
If a trust center wants a device to leave and if the trust center is not the router for 2
that device, the trust center shall send issue the APSME-REMOVE- 3
DEVICE.request primitive, with the ParentAddress parameter set to the router’s 4
address and the ChildAddress parameter set to the address of the device it wishes 5
to leave the network. 6
The trust center will also be informed of devices that leave the network. Upon 7
receipt of an APSME-UPDATE-DEVICE.indication primitive with the Status 8
parameter set to 0x02 (that is, device left), the DeviceAddress parameter shall 9
indicate the address of the device that left the network and the SrcAddress 10
parameter shall indicate the address of parent of this device. If operating in 11
commercial mode, the trust center shall delete the leaving device from its list of 12
network devices. 13
14
Routers are responsible for receiving remove-device commands and for sending 16
update-device commands. 17
18
Upon receipt of an APSME-REMOVE-DEVICE.indication primitive, if the 19
SrcAddress parameter is equal to the apsTrustCenterAddress attribute of the AIB, 20
a router shall issue an NLME-LEAVE.request primitive with the DeviceAddress 21
parameter the same as the DeviceAddress parameter of the APSME-REMOVE- 22
23
DEVICE.indication primitive, the rejoin parameter set to 0 and the ReuseAddress 24
parameter set to 1. If the device corresponding to the DeviceAddress parameter of 25
the APSME-REMOVE-DEVICE.indication primitive is declared "joined but 26
27
unauthenticated" (see sub-clause 4.7.3.2), the SilentLeave parameter shall be set
28
to 1. Otherwise the the SilentLeave parameter shall be set to 0. Other fields are 29
defined by the stack profile.23 30
31
The router shall ignore APSME-REMOVE-DEVICE.indication primitives with 32
the SrcAddress parameter not equal to the apsTrustCenterAddress attribute of the 33
AIB.24
34
• Upon receipt of an NLME-LEAVE.indication primitive with the 35
DeviceAddress parameter set to one of its children, a router that is not also the 36
trust center shall issue an APSME-UPDATE-DEVICE.request primitive with: 37
• The DstAddress parameter set to the address of the trust center; 38
39
• The Status parameter set to 0x02 (that is, device left); 40
41
42
23. CCB #676 43
24. CCB #676 44
45
• The DeviceAddress parameter set to the DeviceAddress parameter of the

NLME-LEAVE.indication primitive. 1
2
If the router is the trust center, it should simply operate as the trust center and shall 3
not issue the APSME-UPDATE-DEVICE.request primitive (see sub- 4
clause 4.7.3.6.1). 5
4.7.3.6.3 Leaving Device Operation 6
7
Devices are responsible for receiving and sending leave notification commands. 8
In a secured ZigBee network, leave25 notification commands shall be secured 9
with the Network key and sent with security enabled at the level indicated by the 10
nwkSecurityLevel attribute in the NIB. 11
12
In a secured ZigBee network, leave26 notification commands shall be received 13
and processed only if secured with the Network key and received with security 14
enabled at the level indicated by the nwkSecurityLevel attribute in the NIB. 15
4.7.3.6.4 Message Sequence Charts 16
17
Figure 4.25 shows an example message sequence chart in which a trust center 18
asks a router to remove one of its children from the network. If a trust center 19
wants a device to leave and if the trust center is not the router for that device, the 20
trust center shall send the router a remove-device command with the address of 21
the device it wishes to leave the network. In a secure network, the remove-device 22
command shall be secured with a link key if present; otherwise shall be secured 23
with the Network key. Upon receipt of the remove-device command, a router shall 24
send a disassociation notification command to the device to leave the network. 25
26
Trust Center Router Device 27
Remove-Device Command
1 28
29
Disassociation Notification Command
2 30
31
Note:
1. If a trust center wants a device to leave and if the trust center is not the router for that device, the trust center shall send the router
32
a remove-device command with the address of the device it wishes to leave the network. 33
2. A router shall send a disassociation command to cause one of its children to leave the network. 34
35
Figure 4.25 Example Remove-Device Procedure 36
37
Figure 4.26 shows an example message sequence chart whereby a device notifies 38
its router that it is disassociating from the network. In this example, the device 39
sends a disassociation notification command (secured with the Network key) to its 40
41
42
25. CCB #676 43
26. CCB #676 44
45
Chapter 4
router. The router then sends a device-update command to the trust center. In a
secured network, the device-update command must be secured with the link key, 1
if present, or the Network key. 2
3
4
Trust Center Router
1
Device 5
Disassociation Notification Command
2
6
Update-Device Command 7
8
Note:
9
1. A device leaving the network shall send a disassociation command to its router. 10
2. Upon receipt of a valid disassociation command, a router shall send an update-device command to the trust center to inform it 11
that a device has left the network. 12
13
Figure 4.26 Example Device-Leave Procedure
14
15
4.7.3.7 Intra-PAN Portability 16
Devices shall follow the procedures described in this sub-clause as necessary to 17
support portability, in conjunction with the mechanism described in 2.5.5.5.2.2. 18
19
At present, the security support for intra-PAN portability is minimized. In most 20
cases security operation is not different from normal, as described in these 21
sections. 22
24
This text describes the security operations for support of intra-PAN security which 25
are to be carried out by the ZigBee Coordinator and by ZigBee Routers. 26
Following the steps described in 2.5.5.5.2.2, an orphaned device shall be 27
provisionally accepted onto the network for at least apsSecurityTimeOutPeriod 28
milliseconds. During this period it shall be required to send at least one correctly 29
formed ZigBee message to the new parent secured with the network key. If this 30
message successfully passes all the security processing steps described in this 31
document it shall be accepted as a member of the network. 32
33
This specification neither specifies nor requires any action from the parent in the 34
case that a message from an orphaned device fails security processing above that 35
required by text elsewhere in this document. 36
Entity authentication of (re-)joined devices is neither specified nor required by 37
this specification. 38
39
4.7.3.7.2 End-device Operation 40
Following the steps described in 2.5.5.5.2.2, an orphaned device shall be 41
provisionally accepted onto the network for at least apsSecurityTimeOutPeriod 42
milliseconds. During this period, it shall be required to send at least one ZigBee 43
44
45
message to the new parent secured with the network key. Further, it shall verify
that at least one ZigBee message is received from the new parent secured using 1
the current network key. If this message successfully passes all the security 2
processing steps described in this document, the device shall operate as a member 3
of the network. If this protocol cannot be completed correctly, the device shall 4
abandon its attempt to join this parent. 5
6
Entity authentication of the new parent is neither specified nor required by this 7
specification. 8
As normal, when operating in residential mode the end device shall not accept an 9
unsecured Network key from the trust center, except as required by this document 10
when activated to join a new network. Accordingly power cycling of devices 11
without persistent memory is not supported within this specification. 12
13
As normal, when operating in commercial mode the end device shall be 14
configured to accept an updated network key from the trust center, even when not 15
activated for the authentication procedure. In this case, the key shall be 16
transported using the APSME-TRANSPORT-KEY.request primitive, and 17
appropriate security shall be verified. 18
Note that a ZigBee router may also carry out an orphan scan as described in 19
2.5.5.5.2.2. In this case it shall, at this time, also follow the steps described in this 20
sub-section. 21
22
In this specification, there is no special additional role for the trust center above 24
that of other routing devices. 25
26
As normal, when operating in residential mode the trust center shall not issue or 27
reissue the Network key unsecured to orphaned devices, except when activated 28
for the authentication procedure. 29
As normal, when operating in commercial mode the trust center may optionally 30
issue or reissue the current or an updated network key to orphaned devices when 31
not activated for the authentication procedure. In this case, the key shall be 32
transported using the APSME-TRANSPORT-KEY.request primitive, and shall be 33
secured appropriately. Initiation of such an update is beyond the scope of this 34
specification. 35
36
37
38
39
40
41
42
43
44
45
Chapter 4
1
2
3
4
5
6
7
8
9
10
11
12
13
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
A N N E X
1
A
2
3
4
5
6
7
8
9
ANNEX ACCM* MODE OF OPERATION 10

11
12
13
CCM* is a generic combined encryption and authentication block cipher mode. 14
CCM* is only defined for use with block ciphers with a 128-bit block size, such as 15
AES-128 [B8]. The CCM* ideas can easily be extended to other block sizes, but 16
this will require further definitions. 17
The CCM* mode coincides with the original CCM mode specification [B20] for 18
messages that require authentication and, possibly, encryption, but does also offer 19
support for messages that require only encryption. As with the CCM mode, the 20
CCM* mode requires only one key. The security proof for the CCM mode, [B21] 21
and [B22], carries over to the CCM* mode described here. The design of the 22
CCM* mode takes into account the results of [B23]; thus allowing it to be 23
securely used in implementation environments for which the use of variable- 24
length authentication tags, rather than fixed-length authentication tags only, is 25
beneficial. 26
27
Prerequisites: The following are the prerequisites for the operation of the generic 28
CCM* mode: 29
1 A block-cipher encryption function E shall have been chosen, with a 128-bit 30
block size. The length in bits of the keys used by the chosen encryption 31
function is denoted by keylen. 32
33
2 A fixed representation of octets as binary strings shall have been chosen (for 34
example, most-significant-bit first order or least-significant-bit-first order). 35
3 The length L of the message length field, in octets, shall have been chosen. 36
Valid values for L are the integers 2, 3,..., 8 (the value L=1 is reserved). 37
38
4 The length M of the authentication field, in octets, shall have been chosen. 39
Valid values for M are the integers 0, 4, 6, 8, 10, 12, 14, and 16. (The value 40
M=0 corresponds to disabling authenticity, since then the authentication field is 41
the empty string.) 42
43
44
45
Annex A
472 CCM* Mode of Operation
A.1 Notation and Representation 1

2
Throughout this specification, the representation of integers as octet strings shall 3
be fixed. All integers shall be represented as octet strings in most-significant-octet 4
first order. This representation conforms to the conventions in Section 4.3 of 5
ANSI X9.63-2001 [B7]. 6
7
8
A.2 CCM* Mode Encryption and Authentication 9
Transformation 10
11
The CCM* mode forward transformation involves the execution, in order, of an 12
input transformation (A.2.1), an authentication transformation (A.2.2), and 13
encryption transformation (A.2.3). 14
15
Input: The CCM* mode forward transformation takes as inputs: 16
1 A bit string Key of length keylen bits to be used as the key. Each entity shall 17
have evidence that access to this key is restricted to the entity itself and its 18
intended key sharing group member(s). 19
20
2 A nonce N of 15-L octets. Within the scope of any encryption key Key, the 21
nonce value shall be unique. 22
3 An octet string m of length l(m) octets, where 0 ≤ l(m)l < 28L. 23
24
4 An octet string a of length l(a) octets, where 0 ≤ l(a) < 264. 25
The nonce N shall encode the potential values for M such that one can uniquely 26
determine from N the actually used value of M. The exact format of the nonce N is 27
outside the scope of this specification and shall be determined and fixed by the 28
actual implementation environment of the CCM* mode. 29
30
Note: The exact format of the nonce N is left to the application, to allow 31
simplified hardware and software implementations in particular settings. Actual 32
implementations of the CCM* mode may restrict the values of M that are allowed 33
throughout the life-cycle of the encryption key Key to a strict subset of those 34
allowed in the generic CCM* mode. If so, the format of the nonce N shall be such 35
that one can uniquely determine from N the actually used value of M in that 36
particular subset. In particular, if M is fixed and the value M=0 is not allowed, 37
then there are no restrictions on N, in which case the CCM* mode reduces to the 38
CCM mode. 39
40
41
42
43
44
45
A.2.1 Input Transformation 1

2
This step involves the transformation of the input strings a and m to the strings
3
AuthData and PlainTextData, to be used by the authentication transformation and
4
the encryption transformation, respectively.
5
This step involves the following steps, in order: 6
7
1 Form the octet string representation L(a) of the length l(a) of the octet string a,
8
as follows:
9
a If l(a)=0, then L(a) is the empty string. 10
11
b If 0 < l(a) < 216-28, then L(a) is the 2-octets encoding of l(a).
12
c If 216-28 ≤ l(a) < 232, then L(a) is the right-concatenation of the octet 0xff, 13
the octet 0xfe, and the 4-octets encoding of l(a). 14
15
d If 232 ≤ l(a) < 264, then L(a) is the right-concatenation of the octet 0xff, the
16
octet 0xff, and the 8-octets encoding of l(a).
17
2 Right-concatenate the octet string L(a) with the octet string a itself. Note that 18
the resulting string contains l(a) and a encoded in a reversible manner. 19
20
3 Form the padded message AddAuthData by right-concatenating the resulting
21
string with the smallest non-negative number of all-zero octets such that the
22
octet string AddAuthData has length divisible by 16.
23
4 Form the padded message PlaintextData by right-concatenating the octet string 24
m with the smallest non-negative number of all-zero octets such that the octet 25
string PlaintextData has length divisible by 16. 26
27
5 Form the message AuthData consisting of the octet strings AddAuthData and
28
PlaintextData:
29
30
AuthData = AddAuthData || PlaintextData 31
32
A.2.2 Authentication Transformation 33
34
The data AuthData that was established above shall be tagged using the tagging 35
transformation as follows: 36
37
1 Form the 1-octet Flags field consisting of the 1-bit Reserved field, the 1-bit
38
Adata field, and the 3-bit representations of the integers M and L, as follows:
39
40
Flags = Reserved || Adata || M || L 41
42
Here, the 1-bit Reserved field is reserved for future expansions and shall be set 43
to ‘0’. The 1-bit Adata field is set to ‘0’ if l(a)=0, and set to ‘1’ if l(a)>0. The L 44
45
Annex A
field is the 3-bit representation of the integer L-1, in most-significant-bit-first

order. The M field is the 3-bit representation of the integer (M-2)/2 if M>0 and 1
of the integer 0 if M=0, in most-significant-bit-first order. 2
3
2 Form the 16-octet B0 field consisting of the 1-octet Flags field defined above, 4
the 15-L octet nonce field N, and the L-octet representation of the length field 5
l(m), as follows: 6
7
B0 = Flags || Nonce N || l(m) 8
9
3 Parse the message AuthData as B1 || B2 || ... ||Bt, where each message block Bi 10
is a 16-octet string. 11
12
The CBC-MAC value Xt+1 is defined by:
13
14
X0 := 0128; Xi+1 := E(Key, Xi ⊕ Bi ) for i=0, ... , t. 15
16
Here, E(K, x) is the cipher-text that results from encryption of the plaintext x using 17
the established block-cipher encryption function E with key Key; the string 0128 is 18
the 16-octet all-zero bit string. 19
20
The authentication tag T is the result of omitting all but the leftmost M octets of
21
the CBC-MAC value Xn+1 thus computed.
22
23
A.2.3 Encryption Transformation 24
25
The data PlaintextData that was established in sub-clause A.2.1 (step 4) and the 26
authentication tag T that was established in sub-clause A.2.2 (step 3) shall be 27
encrypted using the encryption transformation as follows: 28
29
1 Form the 1-octet Flags field consisting of two 1-bit Reserved fields, and the 3-
30
bit representations of the integers 0 and L, as follo33ws:
31
32
Flags = Reserved || Reserved || 0 || L
33
34
Here, the two 1-bit Reserved fields are reserved for future expansions and shall
35
be set to ‘0’. The L field is the 3-bit representation of the integer L-1, in most-
36
significant-bit-first order. The ‘0’ field is the 3-bit representation of the integer
37
0, in most-significant-bit-first order.
38
Define the 16-octet Ai field consisting of the 1-octet Flags field defined above, 39
the 15-L octet nonce field N, and the L-octet representation of the integer i, as 40
follows: 41
42
Ai = Flags || Nonce N || Counter i, for i=0, 1, 2, … 43
44
45
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
Annex A
1 Parse the message c as C ||U, where the right-most 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 as inputs the data 7
CipherTextData and the tag U. 8
9
4 Parse the output string resulting from applying this transformation as m || T, 10
where the right-most 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 as inputs the string a and the octet string m that was 19
established in sub-clause A.3.1 (step 4). 20
2 Use the authentication transformation in sub-clause A.2.2, with as input the 21
message AuthData. 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
A N N E X
1
B
2
3
4
5
6
7
8
9
ANNEX BSECURITY BUILDING BLOCKS 10

11
12
13
This annex specifies the cryptographic primitives and mechanisms that are used to 14
implement the security protocols in this standard. 15
16
17
B.1 Symmetric-key Cryptographic Building Blocks 18
19
The following symmetric-key cryptographic primitives and data elements are 20
defined for use with all security-processing operations specified in this standard. 21
22
23
B.1.1 Block-cipher 24
25
The block-cipher used in this specification shall be the Advanced Encryption
26
Standard AES-128, as specified in FIPS Pub 197. This block-cipher has a key size
27
keylen that is equal to the block size, in bits, i.e., keylen=128.
28
29
B.1.2 Mode of Operation 30
31
The block-cipher mode of operation used in this specification shall be the CCM* 32
mode of operation, as specified in sub-clause A.2.3, with the following 33
instantiations: 34
35
1 Each entity shall use the block-cipher E as specified in sub-clause B.1.1;
36
2 All octets shall be represented as specified in the “Conventions and 37
Abbreviations”; 38
39
3 The parameter L shall have the integer value 2;
40
4 The parameter M shall have one of the following integer values: 0, 4, 8, or 16. 41
42
43
44
45
Annex B
478 Security Building Blocks
B.1.3 Cryptographic Hash Function 1

2
The cryptographic hash function used in this specification shall be the block-
3
cipher based cryptographic hash function specified in Chapter 1, with the
4
following instantiations:
5
1 Each entity shall use the block-cipher E as specified in section sub- 6
clause B.1.1; 7
8
2 All integers and octets shall be represented as specified in Chapter 1.
9
The Matyas-Meyer-Oseas hash function (specified in Chapter 1) has a message 10
digest size hashlen that is equal to the block size, in bits, of the established block- 11
cipher. 12
13
14
B.1.4 Keyed Hash Function for Message Authentication 15
16
The keyed hash message authentication code (HMAC) used in this specification
17
shall be HMAC, as specified in the FIPS Pub 198 [B9], with the following
18
instantiations:
19
1 Each entity shall use the cryptographic hash H function as specified in sub- 20
clause B.1.3; 21
22
2 The block size B shall have the integer value 16 (this block size specifies the
23
length of the data integrity key, in bytes, that is used by the keyed hash
24
function, i.e., it uses a 128-bit data integrity key);
25
3 The output size HMAClen of the HMAC function shall have the same integer 26
value as the message digest parameter hashlen as specified in sub-clause B.1.3. 27
28
29
B.1.5 Specialized Keyed Hash Function for 30
Message Authentication 31
32
The specialized27 keyed hash message authentication code used in this 33
specification shall be the keyed hash message authentication code, as specified in 34
sub-clause B.1.4. 35
36
37
38
39
40
27. This refers to a MAC scheme where the MAC function has the additional property 41
that it is also pre-image and collision resistant for parties knowing the key (see also 42
Remark 9.8 of [B18]). Such MAC functions allow key derivation in contexts where 43
unilateral key control is undesirable. 44
45
B.1.6 Challenge Domain Parameters 1

2
The challenge domain parameters used in the specification shall be as specified in
3
sub-clause B.3.1, with the following instantiation: (minchallengelen,
4
maxchallengelen)=(128,128).
5
All challenges shall be validated using the challenge validation primitive as 6
specified in Chapter 1. 7
8
9
B.2 Key Agreement Schemes 10
11
12
B.2.1 Symmetric-key Key Agreement Scheme 13
14
The symmetric-key key agreement protocols in this standard shall use the full 15
symmetric-key with key confirmation scheme as specified in Chapter 1, with the 16
following instantiations: 17
1 Each entity shall be identified as specified in Chapter 1; 18
19
2 Each entity shall use the HMAC-scheme as specified in sub-clause B.1.4; 20
3 Each entity shall use the specialized HMAC-scheme as specified in sub- 21
clause B.1.5; 22
23
4 Each entity shall use the cryptographic hash function as specified in sub- 24
clause B.1.3., 25
5 The parameter keydatalen shall have the same integer value as the key size 26
parameter keylen as specified in sub-clause B.1.1; 27
28
6 The parameter SharedData shall be the empty string; parameter shareddatalen 29
shall have the integer value 0; 30
7 The optional parameters Text1 and Text2 as specified in sub-clause B.7.1 and 31
sub-clause B.7.2 shall both be the empty string. 32
33
8 Each entity shall use the challenge domain parameters as specified in sub- 34
clause B.1.6. 35
9 All octets shall be represented as specified in section Chapter 1. 36
37
38
B.3 Challenge Domain Parameter Generation and 39
40
Validation 41
42
This section specifies the primitives that shall be used to generate and validate 43
challenge domain parameters. 44
45
Annex B
Challenge domain parameters impose constraints on the length(s) of bit

challenges a scheme expects. As such, this determine a bound on the entropy of 1
challenges and, thereby, on the security of the cryptographic schemes in which 2
these challenges are used. In most schemes, the challenge domain parameters will 3
be such that only challenges of a fixed length will be accepted (e.g., 128-bit 4
challenges). However, one may define the challenge domain parameters such that 5
challenges of varying length might be accepted. The latter is useful in contexts 6
where entities that wish to engage in cryptographic schemes might have a bad 7
random number generator on-board. Allowing both entities that engage in a 8
scheme to contribute sufficiently long inputs enables each of these to contribute 9
sufficient entropy to the scheme at hand. 10
11
In this standard, challenge domain parameters will be shared by a number of 12
entities using a scheme of the standard. The challenge domain parameters may be 13
public; the security of the system does not rely on these parameters being secret. 14
15
B.3.1 Challenge Domain Parameter Generation 16
17
Challenge domain parameters shall be generated using the following routine. 18
19
Input: This routine does not take any input. 20
Actions: The following actions are taken: 21
22
1 Choose two nonnegative integers minchallengelen and maxchallengelen, such 23
that minchallengelen ≤ maxchallengelen. 24
Output: Challenge domain parameters D=(minchallengelen, maxchallengelen). 25
26
27
B.3.2 Challenge Domain Parameter Verification 28
29
Challenge domain parameters shall be verified using the following routine. 30
Input: Purported set of challenge domain parameters D=(minchallengelen, 31
maxchallengelen). 32
33
Actions: The following checks are made: 34
1 Check that minchallengelen and maxchallengelen are nonnegative integers. 35
36
2 Check that minchallengelen ≤ maxchallengelen. 37
reject the challenge domain parameters. Otherwise, output ‘valid’ and accept the 39
challenge domain parameters. 40
41
42
43
44
45
B.4 Challenge Validation Primitive 1

2
Challenge validation refers to the process of checking the length properties of a 3
challenge. It is used to check whether a challenge to be used by a scheme in the 4
standard has sufficient length (e.g., messages that are too short are discarded, due 5
to insufficient entropy). 6
The challenge validation primitive is used in Chapter 1. 7
8
Input: The input of the validation transformation is a valid set of challenge 9
domain parameters D=(minchallengelen, maxchallengelen), together with the bit 10
string Challenge. 11
13
1 Compute the bit-length challengelen of the bit string Challenge. 14
2 Verify that challengelen ∈ [minchallengelen, maxchallengelen]. (That is, 15
verify that the challenge has an appropriate length.) 16
17
Output: If the above verification fails, then output ‘invalid’ and reject the 18
challenge. Otherwise, output ‘valid’ and accept the challenge. 19
20
21
B.5 Secret Key Generation (SKG) Primitive 22
23
This section specifies the SKG primitive that shall be used by the symmetric-key 24
key agreement schemes specified in this standard. 25
This primitive derives a shared secret value from a challenge owned by an entity 26
U1 and a challenge owned by an entity U2 when all the challenges share the same 27
challenge domain parameters. If the two entities both correctly execute this 28
primitive with corresponding challenges as inputs, the same shared secret value 29
will be produced. 30
31
The shared secret value shall be calculated as follows: 32
Prerequisites: The following are the prerequisites for the use of the SKG 33
primitive: 34
35
1 Each entity shall be bound to a unique identifier (e.g., distinguished names). 36
All identifiers shall be bit strings of the same length entlen bits. Entity U1’s 37
identifier will be denoted by the bit string U1. Entity U2’s identifier will be 38
denoted by the bit string U2. 39
2 A specialized28 MAC scheme shall have been chosen, with tagging 40
transformation as specified in Section 5.7.1 of ANSI X9.63-2001 [B7]. The 41
length in bits of the keys used by the specialized MAC scheme is denoted by 42
mackeylen. 43
44
45
Annex B
Input: The SKG primitive takes as input:

1
• A bit string MACKey of length mackeylen bits to be used as the key of the 2
established specialized MAC scheme. 3
• A bit string QEU1 owned by U1. 4
5
• A bit string QEU2 owned by U2. 6
8
1 Form the bit string consisting of U1’s identifier, U2’s identifier, the bit string 9
QEU1 corresponding to U1’s challenge, and the bit string QEU2 corresponding 10
to QEU2’s challenge: 11
12
MacData = U1 || U2 || QEU1 || QEU2 13
14
2 Calculate the tag MacTag for MacData under the key MacKey using the 15
tagging transformation of the established specialized MAC scheme: 16
17
MacTag = MACMacKey(MacData) 18
19
3 If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. 20
21
4 Set Z=MacTag. 22
Output: The bit string Z as the shared secret value. 23
24
25
B.6 Block-cipher-based Cryptographic Hash Function 26
27
This section specifies the Matyas-Meyer-Oseas hash function, a cryptographic 28
hash function based on block-ciphers. We define this hash function for block- 29
ciphers with a key size that is equal to the block size, such as AES-128, and with a 30
particular choice for the fixed initialization vector IV (we take IV=0). For a more 31
general definition of the Matyas-Meyer-Oseas hash function, we refer to Section 32
9.4.1 of [B18]. 33
34
Prerequisites: The following are the prerequisites for the operation of Matyas- 35
Meyer-Oseas hash function: 36
37
38
39
40
28. This refers to a MAC scheme where the MAC function has the additional property 41
that it is also pre-image and collision resistant for parties knowing the key (see also 42
Remark 9.8 of [B18]). Such MAC functions allow key derivation in contexts where 43
unilateral key control is undesirable. 44
45
1 A block-cipher encryption function E shall have been chosen, with a key size
that is equal to the block size. The Matyas-Meyer-Oseas hash function has a 1
message digest size that is equal to the block size of the established encryption 2
function. It operates on bit strings of length less than 2n, where n is the block 3
size, in octets, of the established block-cipher. 4
5
2 A fixed representation of integers as binary strings or octet strings shall have 6
been chosen. 7
Input: The input to the Matyas-Meyer-Oseas hash function is as follows: 8
9
1 A bit string M of length l bits, where 0≤ l < 2n. 10
Actions: The hash value shall be derived as follows: 11
12
1 Pad the message M according to the following method: 13
a Right-concatenate to the message M the binary consisting of the bit ‘1’ 14
followed by k ‘0’ bits, where k is the smallest non-negative solution to the 15
equation: 16
17
l+1+k ≡ 7n (mod 8n) (1) 18
19
b Form the padded message M’ by right-concatenating to the resulting string 20
the n-bit string that is equal to the binary representation of the integer l. 21
22
2 Parse the padded message M’ as M1 || M2|| … || Mt where each message block 23
Mi is an n-octet string. 24
3 The output Hasht is defined by 25
26
27
Hash0 =08n; Hashj =E(Hashj-1, Mj) ⊕ Mj for j=1,…,t (2) 28
29
Here, E(K, x) is the ciphertext that results from encryption of the plaintext x, 30
using the established block-cipher encryption function E with key K; the string 31
08n is the n-octet all-zero bit string. 32
Output: The bit string Hasht as the hash value. 33
34
Note that the cryptographic hash function operates on bit strength of length less 35
than 2n bits, where n is the block size (or key size) of the established block cipher, 36
in bytes. For example, the Matyas-Meyer-Oseas hash function with AES-128 37
operates on bit strings of length less than 216 bits. It is assumed that all hash 38
function calls are on bit strings of length less than 2n bits. Any scheme attempting 39
to call the hash function on a bit string exceeding 2n bits shall output ‘invalid’ and 40
stop. 41
42
43
44
45
Annex B
B.7 Symmetric-key Authenticated Key Agreement 1

Scheme 2
3
This section specifies the full symmetric-key key agreement with key 4
confirmation scheme. A MAC scheme is used to provide key confirmation. 5
6
Figure B.1 illustrates the messaging involved in the use of the full symmetric-key 7
key agreement with key confirmation scheme. 8
46 9
47 Key 10
48 11
49 12
50 13
51 QEU 14
52 15
U
53 V 16
54 17
18
QEV, MACMacKey(0216 || V || U || QEV || QEU || [Text1]), [Text1]
19
20
21
22
MACMacKey(0316 || U || V || QEU || QEV || [Text2]), [Text2]
23
24
Figure B.1 Symmetric-Key Authenticated Key Agreement Scheme 25
26
The scheme is ‘asymmetric’ so two transformations are specified. U uses the 27
transformation specified in sub-clause B.7.1 to agree on keying data with V if U is 28
the protocol’s initiator, and V uses the transformation specified in sub-clause B.7.2 29
to agree on keying data with U if V is the protocol’s responder. 30
The essential difference between the role of the initiator and the role of the 31
responder is merely that the initiator sends the first pass of the exchange. 32
33
If U executes the initiator transformation, and V executes the responder 34
transformation with the shared secret keying material as input, then U and V will 35
compute the same keying data. 36
Prerequisites: The following are the prerequisites for the use of the scheme: 37
38
1 Each entity has an authentic copy of the system’s challenge domain parameters 39
D=(minchallengelen, maxchallengelen). 40
41
42
43
44
45
2 Each entity shall have access to a bit string Key of length keylen bits to be used
as the key. Each party shall have evidence that access to this key is restricted to 1
the entity itself and the other entity involved in the symmetric-key 2
authenticated key agreement scheme. 3
4
3 Each entity shall be bound to a unique identifier (e.g., distinguished names). 5
All identifiers shall be bit strings of the same length entlen bits. Entity U’s 6
identifier will be denoted by the bit string U. Entity V’s identifier will be 7
denoted by the bit string V. 8
4 Each entity shall have decided which MAC scheme to use as specified in 9
Section 5.7 of ANSI X9.63-2001 [B7]. The length in bits of the keys used by 10
the chosen MAC scheme is denoted by mackeylen. 11
12
5 A cryptographic hash function shall have been chosen for use with the key 13
derivation function. 14
6 A specialized29 MAC scheme shall have been chosen for use with the secret 15
key generation primitive with tagging transformation as specified in Section 16
5.7.1 of ANSI X9.63-2001 [B7]. The length in bits of the keys used by the 17
specialized MAC scheme is denoted by keylen. 18
19
7 A fixed representation of octets as binary strings shall have been chosen. (e.g., 20
most-significant-bit-first order or least-significant-bit-first order). 21
22
B.7.1 Initiator Transformation 23
24
U shall execute the following transformation to agree on keying data with V if U is 25
the protocol’s initiator. U shall obtain an authentic copy of V’s identifier and an 26
authentic copy of the static secret key Key shared with V. 27
28
Input: The input to the initiator transformation is: 29
1 An integer keydatalen that is the length in bits of the keying data to be 30
generated. 31
32
2 (Optional) A bit string SharedData of length shareddatalen bits that consists of 33
some data shared by U and V. 34
3 (Optional) A bit string Text2 that consists of some additional data to be 35
provided from U to V. 36
37
Ingredients: The initiator transformation employs the challenge generation 38
primitive in Section 5.3 of ANSI X9.63-2001 [B7], the challenge validation 39
40
29. This refers to a MAC function with the additional property that it is also pre-image 41
and collision resistant for parties knowing the key (see also Remark 9.8 of [B18]. 42
Specialized MAC functions allow key derivation in contexts where unilateral key 43
control is undesirable. 44
45
Annex B
primitive in sub-clause B.3.2, the SKG primitive in sub-clause B.5, the key
derivation function in Section 5.6.3 of ANSI X9.63-2001 [B7] , and one of the 1
MAC schemes in Section 5.7 of ANSI X9.63-2001 [B7]. 2
3
Actions: Keying data shall be derived as follows: 4
1 Use the challenge generation primitive in Section 5.3 of ANSI X9.63-2001 5
[B7] to generate a challenge QEU for the challenge domain parameters D. Send 6
QEU to V. 7
8
2 Then receive from V a challenge QEV’ purportedly owned by V. If this value is 9
not received, output ‘invalid’ and stop. 10
3 Verify that QEV’ is a valid challenge for the challenge domain parameters D as 11
specified in section sub-clause B.3.2. If the validation primitive rejects the 12
challenge, output ‘invalid’ and stop. 13
14
4 Use the SKG primitive in Chapter 1 to derive a shared secret bit string Z from 15
the challenges Q1=QEU owned by U and Q2=QEV’ owned by V, using as key 16
the shared key Key. If the SKG primitive outputs ‘invalid’, output ‘invalid’ and 17
stop. 18
5 Use the key derivation function in Section 5.6.3 of ANSI X9.63-2001 [B7] with 19
the established hash function to derive keying data KKeyData of length 20
mackeylen+keydatalen bits from the shared secret value Z and the shared data 21
[SharedData]. 22
23
6 Parse the leftmost mackeylen bits of KKeyData as a MAC key MacKey and the 24
remaining bits as keying data KeyData. 25
7 Form the bit string consisting of the octet 0216, V’s identifier, U’s identifier, the 26
bit string QEV’, the bit string QEU, and if present Text1: 27
28
MacData1 = 0216 || V || U || QEV’ || QEU || [Text1] 29
30
8 Verify that MacTag1’ is the tag for MacData1 under the key MacKey using the 31
tag checking transformation of the appropriate MAC scheme specified in 32
Section 5.7.2 of ANSI X9.63-2001 [B7]. If the tag checking transformation 33
outputs ‘invalid’, output ‘invalid’ and stop. 34
9 Form the bit string consisting of the octet 0316, U’s identifier, V’s identifier, the 35
bit string QEU corresponding to U’s challenge, the bit string QEV’ 36
corresponding to V’s challenge, and optionally a bit string Text2: 37
38
MacData2 = 0316 || U || V || QEU || QEV’ || [Text2] 39
40
10 Calculate the tag MacTag2 on MacData2 under the key MacKey using the 41
tagging transformation of the appropriate MAC scheme specified in Section 42
5.7.1 of ANSI X9.63-2001 [B7]: 43
44
45
MacTag2 = MACMacKey(MacData2) (3)

1
11 If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send 2
MacTag2 and, if present, Text2 to V. 3
4
12 Receive from V an optional bit string Text1, and a purported tag MacTag1’. If 5
these values are not received, output ‘invalid’ and stop. 6
reject the bit strings KeyData and Text1. Otherwise, output ‘valid’, accept the bit 8
string KeyData as the keying data of length keydatalen bits shared with V and 9
accept V as the source of the bit string Text1 (if present). 10
11
12
B.7.2 Responder Transformation 13
14
V shall execute the following transformation to agree on keying data with U if V is 15
the protocol’s responder. V shall obtain an authentic copy of U’s identifier and an 16
authentic copy of the static secret key Key shared with U. 17
Input: The input to the responder transformation is: 18
19
1 A challenge QEU’ purportedly owned by U. 20
2 An integer keydatalen that is the length in bits of the keying data to be 21
generated. 22
23
3 (Optional) A bit string SharedData of length shareddatalen bits that consists of 24
some data shared by U and V. 25
4 (Optional) A bit string Text1 that consists of some additional data to be 26
provided from V to U. 27
28
Ingredients: The responder transformation employs the challenge generation 29
primitive in Section 5.3 of ANSI X9.63-2001 [B7], the challenge validation 30
primitive in sub-clause B.3.2, the SKG primitive in Chapter 1, the key derivation 31
function in Section 5.6.3 of ANSI X9.63-2001 [B7], and one of the MAC schemes 32
in Section 5.7 of ANSI X9.63-2001 [B7]. 33
Actions: Keying data shall be derived as follows: 34
35
1 Verify that QEU’ 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
2 Use the challenge generation primitive in Section 5.3 of ANSI X9.63-2001 39
[B7] to generate a challenge QEV for the challenge domain parameters D. Send 40
to U the challenge QEV. 41
42
3 Then receive from U an optional bit string Text2 and a purported tag MacTag2’. 43
If this data is not received, output ‘invalid’ and stop. 44
45
Annex B
4 Form the bit string consisting of the octet 0316, U’s identifier, V’s identifier, the
bit string QEU’ corresponding to U’s purported challenge, the bit string QEV 1
corresponding to V’s challenge, and the bit string Text2 (if present): 2
3
MacData2 = 0316 || U || V || QEU’ || QEV || [Text2] 4
5
5 Verify that MacTag2’ is the valid tag on MacData2 under the key MacKey 6
using the tag checking transformation of the appropriate MAC scheme 7
specified in Section 5.7 ANSI X9.63-2001 [B7]. If the tag checking 8
transformation outputs ‘invalid’, output ‘invalid’ and stop. 9
6 Use the SKG primitive in Chapter 1 to derive a shared secret bit string Z from 10
the challenges Q1=QEU’ owned by U and Q2=QEV owned by V, using as key 11
stop. 13
14
7 Use the key derivation function in Section 5.6.3 of ANSI X9.63-2001 [B7] with 15
the established hash function to derive keying data KKeyData of length 16
mackeylen+keydatalen bits from the shared secret value Z and the shared data 17
[SharedData]. 18
8 Parse the leftmost mackeylen bits of KKeyData as a MAC key MacKey and the 19
21
9 Form the bit string consisting of the octet 0216, V’s identifier, U’s identifier, the 22
bit string QEV, the bit string QEU’, and, optionally, a bit string Text1: 23
24
MacData1 = 0216 || V || U || QEV || QEU’ || [Text1] 25
26
10 Calculate the tag MacTag1 for MacData1 under the key MacKey using the 27
tagging transformation of the appropriate MAC scheme specified in Section 5.7 28
of ANSI X9.63-2001 [B7]: 29
30
MacTag1 = MACMacKey(MacData1) 31
32
33
If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send to 34
U, if present the bit string Text1, and MacTag1. 35
reject the bit strings KeyData and Text2. Otherwise, output ‘valid’, accept the bit 37
string KeyData as the keying data of length keydatalen bits shared with U and 38
accept U as the source of the bit string Text2 (if present). 39
40
41
42
43
44
45
A N N E X
1
C
2
3
4
5
6
7
8
9
ANNEX CTEST VECTORS FOR CRYPTOGRAPHIC 10

11
BUILDING BLOCKS
12
13
14
15
This annex provides sample test vectors for the ZigBee community, aimed at 16
assisting in building interoperable security implementations. The sample test 17
vectors are provided as is, pending independent validation. 18
19
20
C.1 Data Conversions 21
22
For test vectors, see Appendix J1 of ANSI X9.63-2001 [B7]. 23
24
25
C.2 AES Block Cipher 26
27
This annex provides sample test vectors for the block-cipher specified in sub- 28
clause B.1.1. 29
30
For test vectors, see FIPS Pub 197 [B8]. 31
32
33
C.3 CCM* Mode Encryption and Authentication 34
Transformation 35
36
37
This annex provides sample test vectors for the mode of operation as specified in
38
sub-clause B.1.2.
39
Prerequisites: The following prerequisites are established for the operation of the 40
mode of operation: 41
42
1 The parameter M shall have the integer value 8.
43
44
45
Annex C
490 Test Vectors For Cryptographic Building
Input: The inputs to the mode of operation are:

1
1 The key Key of size keylen=128 bits to be used: 2
3
Key = C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF 4
2 The nonce N of 15-L=13 octets to be used: 5
6
Nonce = A0 A1 A2 A3 A4 A5 A6 A7 || 03 02 01 00 || 06 7
8
3 The octet string m of length l(m)=23 octets to be used: 9
10
m = 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 11
4 The octet string a of length l(a)=8 octets to be used: 12
13
a = 00 01 02 03 04 05 06 07 14
15
16
C.3.1 Input Transformation 17
18
This step involves the transformation of the input strings a and m to the strings 19
AuthData and PlainTextData, to be used by the authentication transformation and 20
the encryption transformation, respectively. 21
1 Form the octet string representation L(a) of the length l(a) of the octet string a: 22
23
L(a) = 00 08 24
25
2 Right-concatenate the octet string L(a) and the octet string a itself: 26
27
L(a) || a = 00 08 || 00 01 02 03 04 05 06 07 28
3 Form the padded message AddAuthData by right-concatenating the resulting 29
string with the smallest non-negative number of all-zero octets such that the 30
octet string AddAuthData has length divisible by 16: 31
32
AddAuthData = 00 08 || 00 01 02 03 04 05 06 07 || 00 00 00 00 00 00 33
34
4 Form the padded message PlaintextData by right-concatenating the octet string 35
m with the smallest non-negative number of all-zero octets such that the octet 36
string PlaintextData has length divisible by 16: 37
38
PlaintextData = 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 || 39
18 19 1A 1B 1C 1D 1E || 00 00 00 00 00 00 00 00 00 40
5 Form the message AuthData consisting of the octet strings AddAuthData and 41
PlaintextData: 42
43
44
45
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 tagging 7
transformation as follows: 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 encryption transformation as 38
follows: 39
40
1 Form the 1-octet Flags field as follows: 41
42
Flags = 01 43
44
45
Annex C
2 Define the 16-octet Ai field as follows

1
i Ai 2
3
0 01 || A0 A1 A2 A3 A4 A5 A6 A7 03 02 01 00 06 || 00 00 4
5
1 01 || A0 A1 A2 A3 A4 A5 A6 A7 03 02 01 00 06 || 00 01
6
2 01 || A0 A1 A2 A3 A4 A5 A6 A7 03 02 01 00 06 || 00 02 7
8
3 Parse the message PlaintextData as M1 ||M2, where each message block Mi is a 9
16-octet string. 10
11
4 The ciphertext blocks C1, C2 are computed as follows: 12
13
i AES(Key,Ai) Ci = AES(Key,Ai) ⊕ Mi 14
15
1 12 5C A9 61 B7 61 6F 02 16 7A 21 66 70 89 F9 07 1A 55 A3 6A BB 6C 61 0D 06 6B 33 75 64 9C EF 10
16
2 CC 7F 54 D1 C4 49 B6 35 46 21 46 03 AA C6 2A 17 D4 66 4E CA D8 54 A8 35 46 21 46 03 AA C6 2A 17 17
18
5 The string Ciphertext is the result of omitting all but the leftmost l(m)=23 octets 19
of the string C1 ||C2: 20
21
CipherText = 1A 55 A3 6A BB 6C 61 0D 06 6B 33 75 64 9C EF 10 || D4 66 4E 22
CA D8 54 A8 23
24
6 Define the 16-octet encryption block S0 by: 25
26
S0 = E(Key, A0 )= B3 5E D5 A6 DC 43 6E 49 D6 17 2F 54 77 EB B4 39 27
28
7 The encrypted authentication tag U is the result of XOR-ing the string 29
consisting of the leftmost M=8 octets of S0 and the authentication tag T: 30
31
U = 0A 89 5C C1 D8 FF 94 69 32
33
Output: the right-concatenation c of the encrypted message Ciphertext and the
34
encrypted authentication tag U:
35
36
c = 1A 55 A3 6A BB 6C 61 0D 06 6B 33 75 64 9C EF 10 || D4 66 4E CA D8 54 A8
37
|| 0A 89 5C C1 D8 FF 94 69
38
39
40
41
42
43
44
45
C.4 CCM* Mode Decryption and Authentication 1

Checking Transformation 2
3
This annex provides sample test vectors for the inverse of the mode of operation 4
as specified in sub-clause B.1.2. 5
6
Prerequisites: The following prerequisites are established for the operation of the 7
mode of operation: 8
1 The parameter M shall have the integer value 8. 9
10
Input: The inputs to the inverse mode of operation are: 11
13
Key = C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF 14
15
2 The nonce N of 15-L=13 octets to be used: 16
17
Nonce = A0 A1 A2 A3 A4 A5 A6 A7 || 03 02 01 00 || 06 18
3 The octet string c of length l(c)=31 octets to be used: 19
20
c = 1A 55 A3 6A BB 6C 61 0D 06 6B 33 75 64 9C EF 10 || D4 66 4E CA D8 54 21
A8 || 0A 89 5C C1 D8 FF 94 69 22
23
4 The octet string a of length l(a)=8 octets to be used: 24
25
a = 00 01 02 03 04 05 06 07 26
27
C.4.1 Decryption Transformation 28
29
The decryption transformation involves the following steps, in order: 30
31
1 Parse the message c as C ||U, where the right-most string U is an M-octet string: 32
33
C = 1A 55 A3 6A BB 6C 61 0D 06 6B 33 75 64 9C EF 10 || D4 66 4E CA D8 54 A8; 34
35
U = 0A 89 5C C1 D8 FF 94 69 36
2 Form the padded message CiphertextData by right-concatenating the string C 37
with the smallest non-negative number of all-zero octets such that the octet 38
string CiphertextData has length divisible by 16. 39
40
CipherTextData = 1A 55 A3 6A BB 6C 61 0D 06 6B 33 75 64 9C EF 10 || D4 41
66 4E CA D8 54 A8 || 00 00 00 00 00 00 00 00 42
43
44
45
Annex C
3 Form the 1-octet Flags field as follows:

1
Flags = 01 2
3
4 Define the 16-octet Ai field as follows: 4
5
i Ai 6
7
0 01 || A0 A1 A2 A3 A4 A5 A6 A7 03 02 01 00 06 || 00 00
8
1 01 || A0 A1 A2 A3 A4 A5 A6 A7 03 02 01 00 06 || 00 01 9
10
2 01 || A0 A1 A2 A3 A4 A5 A6 A7 03 02 01 00 06 || 00 02
11
12
5 Parse the message CiphertextData as C1 ||C2, where each message block Ci is a 13
16-octet string. 14
6 The ciphertext blocks P1, P2 are computed as follows: 15
16
AES(Key,Ai) Pi= AES(Key,Ai) ⊕ Ci
17
i
18
1 12 5C A9 61 B7 61 6F 02 16 7A 21 66 70 89 F9 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 19
20
2 CC 7F 54 D1 C4 49 B6 35 46 21 46 03 AA C6 2A 17 18 19 1A 1B 1C 1D 1E 00 00 00 00 00 00 00 00 00
21
22
7 The octet string m is the result of omitting all but the leftmost l(m)=23 octets of 23
the string P1 || P2: 24
25
m = 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 || 18 19 1A 1B 1C 1D 1E 26
8 Define the 16-octet encryption block S0 by 27
28
S0 = E(Key, A0 ) = B3 5E D5 A6 DC 43 6E 49 D6 17 2F 54 77 EB B4 39 29
30
9 The purported authentication tag T is the result of XOR-ing the string 31
consisting of the leftmost M=8 octets of S0 and the octet string U: 32
33
T = B9 D7 89 67 04 BC FA 20 34
35
C.4.2 Authentication Checking Transformation 36
37
The authentication checking transformation involves the following steps: 38
39
1 Form the message AuthData using the input transformation in sub- 40
clause C.3.1, with as inputs the string a and the octet string m that was 41
established in sub-clause C.4.1 (step 7): 42
43
44
45
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 as input the 4
message AuthData to compute the authentication tag MACTag: 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
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
Annex C
4 The hash value Hash1 is computed as follows:

1
i Hashi Mi 2
3
0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 æ 4
5
1 AE 3A 10 2A 28 D4 3E E0 D4 A0 9E 22 78 8B 20 6C C0 80 00 00 00 00 00 00 00 00 00 00 00 00 00 08
6
7
Output: the 16-octet string Hash = Hash1 = AE 3A 10 2A 28 D4 3E E0 D4 A0 9E 22 78 8
8B 20 6C. 9
10
12
Input: The input to the cryptographic hash function is as follows: 13
14
16
M=C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF 17
19
1 Pad the message M by right-concatenating to M the bit ‘1’ followed by the 20
smallest non-negative number of ‘0’ bits, such that the resulting string has 21
length 14 (mod 16) octets: 22
23
C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF || 24
80 00 00 00 00 00 00 00 00 00 00 00 00 00 25
2 Form the padded message M’ by right-concatenating to the resulting string the 26
16-bit string that is equal to the binary representation of the integer l: 27
28
M’ = C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF || 29
80 00 00 00 00 00 00 00 00 00 00 00 00 00 || 00 80 30
31
3 Parse the padded message M’ as M1 || M2, where each message block Mi is a 32
16-octet string. 33
4 The hash value Hash2 is computed as follows: 34
35
i Hashi Mi 36
37
0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 æ 38
1 84 EE 75 E5 4F 9A 52 0F 0B 30 9C 35 29 1F 83 4F C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF
39
40
2 A7 97 7E 88 BC 0B 61 E8 21 08 27 10 9A 22 8F 2D 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 41
42
Output: the 16-octet string Hash = Hash2 = A7 97 7E 88 BC 0B 61 E8 21 08 27 43
10 9A 22 8F 2D. 44
45
C.6 Keyed Hash Function for Message Authentication 1

2
This annex provides sample test vectors for the keyed hash function for message 3
authentication as specified in clause C.6. 4
5
7
Input: The input to the keyed hash function is as follows: 8
9
11
Key = 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 12
14
M=C0 15
16
Actions: The keyed hash value shall be derived as follows: 17
1 Create the 16-octet string ipad (inner pad) as follows: 18
19
ipad = 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 20
21
2 Form the inner key Key1 by XOR-ing the bit string Key and the octet string 22
ipad: 23
24
Key1 = Key ⊕ ipad = 76 77 74 75 72 73 70 71 7E 7F 7C 7D 7A 7B 78 79 25
3 Form the padded message M1 by right-concatenating the bit string Key1 with 26
the bit string M: 27
28
M1 = Key1 || M = 76 77 74 75 72 73 70 71 7E 7F 7C 7D 7A 7B 78 79 || C0 29
30
4 Compute the hash value Hash1 of the bit string M1: 31
32
Hash1 = 3C 3D 53 75 29 A7 A9 A0 3F 66 9D CD 88 6C B5 2C 33
5 Create the 16-octet string opad (outer pad) as follows: 34
35
opad = 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 36
37
6 Form the outer key Key2 by XOR-ing the bit string Key and the octet string 38
opad: 39
40
Key2 = Key ⊕ opad = 1C 1D 1E 1F 18 19 1A 1B 14 15 16 17 10 11 12 13 41
42
43
44
45
Annex C
7 Form the padded message M2 by right-concatenating the bit string Key2 with
the bit string Hash1: 1
2
M2 = Key2 || Hash1 = 1C 1D 1E 1F 18 19 1A 1B 14 15 16 17 10 11 12 13 || 3
3C 3D 53 75 29 A7 A9 A0 3F 66 9D CD 88 6C B5 2C 4
5
7
Hash2 = 45 12 80 7B F9 4C B3 40 0F 0E 2C 25 FB 76 E9 99 8
Output: the 16-octet string HMAC = Hash2 = 45 12 80 7B F9 4C B3 40 0F 0E 2C 9
25 FB 76 E9 99 10
11
12
14
Input: The input to the keyed hash function is as follows: 15
Key = 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F || 17
50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 18
19
21
M = C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF 22
Actions: The keyed hash value shall be derived as follows: 23
24
1 Compute the hash value Key0 of the bit string Key: 25
26
Key0 = 22 F4 0C BE 15 66 AC CF EB 77 77 E1 C4 A9 BB 43 27
2 Create the 16-octet string ipad (inner pad) as follows: 28
29
ipad = 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 30
31
3 Form the inner key Key1 by XOR-ing the bit key Key0 and the octet string ipad: 32
33
Key1 = Key0 ⊕ ipad = 14 C2 3A 88 23 50 9A F9 DD 41 41 D7 F2 9F 8D 75 34
the bit string M: 36
37
M1 = Key1 || M = 14 C2 3A 88 23 50 9A F9 DD 41 41 D7 F2 9F 8D 75 || 38
C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF 39
40
42
Hash1 = 42 65 BE 29 74 55 8C A2 7B 77 85 AC 73 F2 22 10 43
44
45
6 Create the 16-octet string opad (outer pad) as follows:

1
opad = 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 2
3
7 Form the outer key Key2 by XOR-ing the bit string Key0 and the octet string opad: 4
5
Key2 = Key0 ⊕ opad = 7E A8 50 E2 49 3A F0 93 B7 2B 2B BD 98 F5 E7 1F 6
the bit string Hash1: 8
9
M2 = Key2 || Hash1 =7E A8 50 E2 49 3A F0 93 B7 2B 2B BD 98 F5 E7 1F || 10
42 65 BE 29 74 55 8C A2 7B 77 85 AC 73 F2 22 10 11
12
14
Hash2 = A3 B0 07 99 84 BF 15 57 F7 4A 0D 63 87 E0 A1 1A 15
Output: the 16-octet string HMAC = Hash2 = A3 B0 07 99 84 BF 15 57 F7 4A 16
0D 63 87 E0 A1 1A 17
18
19
C.6.3 Specialized Keyed Hash Function for Message 20
Authentication 21
22
This annex provides sample test vectors for the specialized keyed hash function 23
for message authentication as specified in clause C.6.3. 24
25
For test vectors, see clause C.6.
26
27
C.6.4 Symmetric-key Key Agreement Scheme 28
29
This annex provides sample test vectors for the symmetric-key key agreement 30
scheme as specified in clause C.6.4. 31
32
Prerequisites: The following are the prerequisites for the use of the scheme:
33
1 The unique identifiers of the entities U and V to be used: 34
35
U’s identifier: U=55 73 65 72 20 55 0D 0A 36
37
V’s identifier: V=55 73 65 72 20 56 0D 0A 38
39
2 The key Key of length keylen=128 bits to be used:
40
41
Key = C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF
42
43
44
45
Annex C
3 The optional parameter SharedData of length shareddatalen=48 bits to be

used: 1
2
SharedData = D0 D1 D2 D3 D4 D5 3
4
5
C.6.5 Initiator Transformation 6
7
U obtains an authentic copy of V’s identifier and an authentic copy of the static 8
secret key Key shared with V. 9
Input: The input to the initiator transformation is: 10
11
1 The length keydatalen in bits of the keying data to be generated: 12
keydatalen=128. 13
2 The optional bit string Text2 to be used is not present, i.e., Text2 = ε (the empty 14
string). 15
16
Actions: U derives keying data as follows: 17
1 Use the challenge generation primitive in Section 5.3 of ANSI X9.63- 18
2001 [B7] to generate a challenge QEU for the challenge domain parameters D. 19
Send QEU to V. 20
QEU = 9E 3F 0C 19 05 4B 05 44 D5 A7 17 62 0A F2 7D 96
21
22
2 Then receive from V a challenge QEV’ purportedly owned by V. If this value is 23
not received, output ‘invalid’ and stop. 24
QEV’ = BF 14 DF 94 94 39 D2 CE 24 C9 09 53 B5 72 D6 53 25
26
3 Verify that QEV’ is a valid challenge for the challenge domain parameters D as 27
4 Use the SKG primitive in clause B.5 to derive a shared secret bit string Z from 30
the challenges Q1=QEU owned by U and Q2=QEV’ owned by V, using as key 31
stop. 33
34
a Form the bit string MACData = U || V || QEU || QEV’: 35
MACData = 55 73 65 72 20 55 0D 0A || 55 73 65 72 20 56 0D 0A || 36
9E 3F 0C 19 05 4B 05 44 D5 A7 17 62 0A F2 7D 96 || 37
BF 14 DF 94 94 39 D2 CE 24 C9 09 53 B5 72 D6 53
38
b Calculate the MACTag for MACData under the key Key using the tagging 39
transformation of the HMAC-Matyas-Meyer-Oseas MAC scheme: 40
MACTag=MACKey(MACData)= 78 7C DE F6 80 13 12 CD 41 1B CD 62 14 41
91 F8 6D 42
43
c Set Z=MACTag: 44
45
Z = 78 7C DE F6 80 13 12 CD 41 1B CD 62 14 91 F8 6D
1
5 Use the key derivation function in Section 5.6.3 of ANSI X9.63-2001 [B7] 2
with the Matyas-Meyer-Oseas hash function to derive keying data KKeyData 3
of length 256 bits from the shared secret value Z and the shared data 4
SharedData: 5
a The hash values Hash1, Hash2 are computed as follows: 6
7
i Hashi=H(Xi) Xi 8
9
E4 D4 5F 76 2A 36 B7 99 F9 5E C2 C6 FD E9 A1 78 7C DE F6 80 13 12 CD 41 1B CD 62 14 91 F8 6D || 00
1 50 00 00 01 || D0 D1 D2 D3 D4 D5 10
11
72 57 7D 02 CC E1 39 33 1A BF F4 0B C5 6E A3 78 7C DE F6 80 13 12 CD 41 1B CD 62 14 91 F8 6D || 00 12
2 7F 00 00 02 || D0 D1 D2 D3 D4 D5
13
14
b Set KKeyData=Hash1 || Hash2: 15
KKeyData = E4 D4 5F 76 2A 36 B7 99 F9 5E C2 C6 FD E9 A1 50 || 16
72 57 7D 02 CC E1 39 33 1A BF F4 0B C5 6E A3 7F 17
6 Parse the leftmost 128 bits of KKeyData as a MAC key MacKey and the 18
20
MacKey = E4 D4 5F 76 2A 36 B7 99 F9 5E C2 C6 FD E9 A1 50;
21
KeyData = 72 57 7D 02 CC E1 39 33 1A BF F4 0B C5 6E A3 7F 22
7 Form the bit string MacData1 = 0216 || V || U || QEV’ || QEU || [Text1]: 23
MacData1 = 02 || 55 73 65 72 20 56 0D 0A || 55 73 65 72 20 55 0D 0A ||
24
BF 14 DF 94 94 39 D2 CE 24 C9 09 53 B5 72 D6 53 || 25
9E 3F 0C 19 05 4B 05 44 D5 A7 17 62 0A F2 7D 96 26
27
8 Verify that MacTag1’ is the tag for MacData1 under the key MacKey using the 28
tag checking transformation specified in Section 5.7.2 of ANSI X9.63- 29
2001 [B7]. If the tag checking transformation outputs ‘invalid’, output ‘invalid’ 30
and stop. 31
a Calculate MacTag1=MACMacKe y (MacData1) = E6 C3 DE 1F E8 63 15 B9 32
E6 A0 2B 44 FF 63 D8 D0 33
34
b Verify that MacTag1=MacTag1’ 35
9 Form the bit string MacData2 = 0316 || U || V || QEU || QEV’ || [Text2]: 36
MacData2 = 03 || 55 73 65 72 20 55 0D 0A || 55 73 65 72 20 56 0D 0A || 37
9E 3F 0C 19 05 4B 05 44 D5 A7 17 62 0A F2 7D 96 || 38
BF 14 DF 94 94 39 D2 CE 24 C9 09 53 B5 72 D6 53 39
40
10 Calculate the tag MacTag2 on MacData2 under the key MacKey using the 41
tagging transformation specified in Section 5.7.1 of ANSI X9.63-2001 [B7] 42
with the HMAC-Matyas-Meyer-Oseas MAC scheme: 43
44
45
Annex C
MacTag2 = MACMacKey (MacData2) = 66 36 8D 61 0F E0 0B 7F 06 3E

74 C4 78 0A A3 6D 1
If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send 2
MacTag2 and, if present, Text2 to V. 3
4
11 Receive from V an optional bit string Text1, and a purported tag MacTag1’. If
5
these values are not received, output ‘invalid’ and stop. 6
7
Text1 = ε (the empty string); 8
12 MacTag1’ = E6 C3 DE 1F E8 63 15 B9 E6 A0 2B 44 FF 63 D8 D0 9
10
11
Output: output ‘valid’ and accept the 128-bit string KeyData = 72 57 7D 02 CC E1 12
39 33 1A BF F4 0B C5 6E A3 7F as the keying data shared with V. 13
14
15
C.6.6 Responder Transformation 16
17
V obtains an authentic copy of U’s identifier and an authentic copy of the static 18
secret key Key shared with U. 19
Input: The input to the responder transformation is: 20
21
1 A challenge QEU’ purportedly owned by U.
22
QEU’ = 9E 3F 0C 19 05 4B 05 44 D5 A7 17 62 0A F2 7D 96 23
2 The length keydatalen in bits of the keying data to be generated: 24
keydatalen=128 25
26
3 The optional bit string Text1 to be used is not present, i.e., Text1 = ε (the empty 27
string). 28
Actions: V derives keying data as follows: 29
30
1 Verify that QEU’ is a valid challenge for the challenge domain parameters D as 31
2 Use the challenge generation primitive in Section 5.3 of ANSI X9.63- 34
2001 [B7] to generate a challenge QEV for the challenge domain parameters D. 35
Send to U the challenge QEV. 36
37
QEV = BF 14 DF 94 94 39 D2 CE 24 C9 09 53 B5 72 D6 53
38
3 Then receive from U an optional bit string Text2 and a purported tag MacTag2’. 39
If this data is not received, output ‘invalid’ and stop. 40
Text2 = ε (the empty string); 41
MacTag2’ = 66 36 8D 61 0F E0 0B 7F 06 3E 74 C4 78 0A A3 6D
42
43
4 Form the bit string MacData2 = 0316 || U || V || QEU’ || QEV || [Text2]: 44
45
MacData2 = 03 || 55 73 65 72 20 55 0D 0A || 55 73 65 72 20 56 0D 0A ||
9E 3F 0C 19 05 4B 05 44 D5 A7 17 62 0A F2 7D 96 || 1
BF 14 DF 94 94 39 D2 CE 24 C9 09 53 B5 72 D6 53 2
5 Verify that MacTag2’ is the valid tag on MacData2 under the key MacKey 3
using the tag checking transformation specified in Section 5.7 ANSI X9.63- 4
2001 [B7]. If the tag checking transformation outputs ‘invalid’, output ‘invalid’ 5
and stop. 6
7
a Calculate MacTag2=MACMacKey (MacData2) = 66 36 8D 61 0F E0 0B 7F 06 8
3E 74 C4 78 0A A3 6D 9
b Verify that MacTag2=MacTag2’ 10
11
6 Use the SKG primitive in clause B.5 to derive a shared secret bit string Z from 12
the challenges Q1=QEU’ owned by U and Q2=QEV owned by V, using as key 13
the shared key SharedKey. If the SKG primitive outputs ‘invalid’, output 14
‘invalid’ and stop. 15
a Form the bit string MACData=U || V || QEU’ || QEV: 16
17
MACData = 55 73 65 72 20 55 0D 0A || 55 73 65 72 20 56 0D 0A ||
9E 3F 0C 19 05 4B 05 44 D5 A7 17 62 0A F2 7D 96 ||
18
BF 14 DF 94 94 39 D2 CE 24 C9 09 53 B5 72 D6 53 19
20
b Calculate the MACTag for MACData under the key Key using the tagging 21
transformation of the HMAC-Matyas-Meyer-Oseas MAC scheme: 22
MACTag = MACKey (MACData) = 78 7C DE F6 80 13 12 CD 41 1B CD 62 14 23
91 F8 6D 24
c Set Z=MACTag: 25
26
Z = 78 7C DE F6 80 13 12 CD 41 1B CD 62 14 91 F8 6D
27
7 Use the key derivation function in Section 5.6.3 of ANSI X9.63-2001 [B7] 28
with the Matyas-Meyer-Oseas hash function to derive keying data KKeyData 29
of length 256 bits from the shared secret value Z and the shared data 30
SharedData: 31
32
a The hash values Hash1, Hash2 are computed as follows: 33
34
i Hashi=H(Xi) Xi
35
78 7C DE F6 80 13 12 CD 41 1B CD 62 14 91 F8 6D || 00 36
1 E4 D4 5F 76 2A 36 B7 99 F9 5E C2 C6 FD E9 A1 50
00 00 01 || D0 D1 D2 D3 D4 D5 37
78 7C DE F6 80 13 12 CD 41 1B CD 62 14 91 F8 6D || 00 38
2 72 57 7D 02 CC E1 39 33 1A BF F4 0B C5 6E A3 7F
00 00 02 || D0 D1 D2 D3 D4 D5 39
40
b Set KKeyData=Hash1 || Hash2: 41
KKeyData = E4 D4 5F 76 2A 36 B7 99 F9 5E C2 C6 FD E9 A1 50 ||
42
72 57 7D 02 CC E1 39 33 1A BF F4 0B C5 6E A3 7F 43
44
45
Annex C
8 Parse the leftmost 128 bits of KKeyData as a MAC key MacKey and the
MacKey = E4 D4 5F 76 2A 36 B7 99 F9 5E C2 C6 FD E9 A1 50;
2
3
KeyData = 72 57 7D 02 CC E1 39 33 1A BF F4 0B C5 6E A3 7F
4
9 Form the bit string MacData1 = 0216 || V || U || QEV || QEU’ || [Text1]: 5
MacData1 = 02 || 55 73 65 72 20 56 0D 0A || 55 73 65 72 20 55 0D 0A || 6
BF 14 DF 94 94 39 D2 CE 24 C9 09 53 B5 72 D6 53 || 7
9E 3F 0C 19 05 4B 05 44 D5 A7 17 62 0A F2 7D 96 8
9
10 Calculate the tag MacTag1 for MacData1 under the key MacKey using the 10
tagging transformation specified in Section 5.7 of ANSI X9.63-2001 [B7] with 11
the HMAC-Matyas-Meyer-Oseas MAC scheme: 12
MacTag1 = MACMacKey(MacData1)= E6 C3 DE 1F E8 63 15 B9 E6 A0 2B 44 13
63 D8 D0 14
11 If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send 15
to U, if present the bit string Text1, and MacTag1. 16
17
Output: output ‘valid’ and accept the 128-bit string KeyData = 72 57 7D 02 CC E1 39 18
33 1A BF F4 0B C5 6E A3 7F as the keying data shared with U. 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
A N N E X
1
D
2
3
4
5
6
7
8
9
ANNEX DMAC AND PHY SUB-LAYER 10

11
CLARIFICATIONS
12
13
14
15
D.1 Introduction 16
17
18
D.1.1 Scope 19
20
This Annex applies to the IEEE 802.15.4 2003 Medium Access Control sub-layer 21
(MAC) and Physical Layer (PHY) specification when used in conjunction with 22
higher layers defined by the ZigBee specification. Nothing is implied about the 23
usage under other circumstances. 24
25
26
D.1.2 Purpose 27
28
The current ZigBee specification assumes the use of the MAC and PHY sub- 29
layers defined in the IEEE 802.15.4 2003 specification. However, as developers 30
have put the MAC and PHY sub-layers into use, they have uncovered problems 31
that may or may not have been anticipated by the authors of the specification, or 32
are not covered in the IEEE 802.15.4 2003 specification. This document is 33
intended to provided solutions to such problems, for use by the ZigBee Alliance. 34
35
D.1.3 Stack Size Issues 36
37
Both MAC and ZigBee stack developers have discovered that implementation of a 38
full-blown MAC is a major undertaking and requires a great deal of code space. 39
Even with the optional GTS and MAC security features eliminated, it is not 40
surprising to find the MAC taking up more than 24K of code space on a processor 41
with 64K of available space. 42
43
44
45
Annex D
506 MAC and PHY Sub-Layer Clarifications
The ZigBee Alliance has adopted a compensating policy to declare MAC features
that are not required to support a particular stack profile, optional with respect to 1
that stack profile. In particular, any MAC feature that will not be exploited as a 2
result of platform compliance testing for a particular stack profile, need not be 3
present in order for an implementation to be declared platform compliant. Thus, 4
for example, since the HC stack profile relies on a beaconless network, the 5
platform compliance testing for the HS stack profile does not employ beaconing; 6
the code to support regular beaconing, beacon track, and so on, may be absent 7
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.1.4 MAC Association 13
14
At association time, according to the IEEE 802.15.4 2003 specification, a number 15
of frames, including an association request command, an associate response 16
command and a data request. There is some ambiguity in the specification 17
regarding the addressing fields in the headers for these frames. Tables D.1–D.3 18
outline the allowable options that shall be recognized by devices implementing 19
the ZigBee specification. In each case, the first option given is the preferred 20
option and should be used. 21
Table D.1 Associate Request Header Fields 22
23
DstPANId DstAddr SrcPANId SrcAddr 24
The PANId of the The 16-bit short 0xffff The 64-bit extended 25
destination device address of the address of the source 26
destination device device 27
PANId omitted 28
because the IntraPAN 29
sub-field in the frame 30
control field is set to 31
one
32
The PANId of the 33
Not present if the Not present if the 35
destination device is destination device is 36
the PAN coordinator the PAN coordinator 37
38
39
40
41
42
43
44
45
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
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
34
35
36
37
38
39
40
41
42
43
44
45
Annex D
508 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
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

054024r01ZB AFG ZigBee Specification 2006 Download

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

054024r01ZB AFG ZigBee Specification 2006 Download

Uploaded by

Copyright:

Available Formats

ZigBee Specification

NOTICE OF USE AND DISCLOSURE 1

2.2.4 Service Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.11 Information Base Maintenance . . . . . . . . . . . . . . . . . . . . . . 286

4.4.2 Secured NPDU Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401

B.1.5 Specialized Keyed Hash Function for

D.1.1 Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505

Table 2.34 Values of the Current Power Source Level Field . . . . . . 85

Table 2.71 Fields of the Backup_Source_Bind_req Command . . . . . 133

Table 2.108 Fields of the Store_Bkup_Bind_Entry_rsp Command . 179

Table 3.9 Network Descriptor Information Fields . . . . . . . . . . . . . . . 256

Table 3.46 Routing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

Table 4.28 AIB Security Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 443

Figure 2.32 Format of the Power_Desc_store_req Command Frame 113

Figure 2.63 Format of the Complex_Desc_rsp Command Frame . . . 159

Figure 2.95 System Usage ZigBee Device Object Details . . . . . . . . 209

Figure 3.32 Procedure for a Device to Remove Its Child . . . . . . . . . 349

CHAPTER 1ZIGBEE PROTOCOL OVERVIEW 10

Application (APL) Layer

ZDO Management Plane

The responsibilities of the ZDO include:

APSME Application support sub-layer management entity

PDU Protocol data unit

Shall: A key word indicating mandatory requirements to be strictly followed in

Binding: the creation of a unidirectional logical link between a source

Device application: a special application that is responsible for Device

source address/endpoint/cluster ID within its binding table and re-issues the

ZigBee end device: an IEEE 802.15.4-2003 RFD or FFD participating in a

Cryptography, American Bankers Association, November 20, 2001. Available

[B19] FIPS Pub 113, Computer Data Authentication, Federal Information

CHAPTER 2APPLICATION LAYER SPECIFICATION 10

• Initiating and/or responding to binding requests

is the radio, it is not possible to identify or address the individual subunits, so it

Binding is always performed after a communications link has been established.

• Assembling configuration information from the end applications to determine

2.2 ZigBee Application Support (APS) Sub-Layer 1

Table 2.2 specifies the parameters for the APSDE-DATA.request primitive.

Table 2.2 APSDE-DATA.request Parameters

destination NWK address is employed for immediate application responses and

Table 2.3 specifies the parameters for the APSDE-DATA.confirm primitive.

2.2.4.1.2.2 When Generated

Table 2.4 specifies the parameters for the APSDE-DATA.indication primitive.

Table 2.4 APSDE-DATA.indication Parameters

2.2.4.1.3.3 Effect on Receipt

2.2.4.3.1.1 Semantics of the Service Primitive

2.2.4.3.1.2 When Generated

Table 2.7 specifies the parameters for the APSME-BIND.confirm primitive.

2.2.4.3.2.2 When Generated

Table 2.8 APSME-UNBIND.request Parameters

Table 2.9 APSME-UNBIND.confirm Parameters

2.2.4.4.1.1 Semantics of the Service Primitive

Table 2.11 specifies the parameters for this primitive.

Table 2.12 specifies the parameters for this primitive.

Table 2.13 specifies the parameters for this primitive.

Table 2.14 specifies the parameters for this primitive.

2.2.4.5.2.1 Semantics of the Service Primitive

2.2.4.5.3.1 Semantics of the Service Primitive

2.2.4.5.6.1 Semantics of the Service Primitive

2.2.5.1.1.1 Frame Type Sub-field

2.2.5.1.1.3 Indirect Address Mode Sub-field

2.2.5.1.4 Cluster Identifier Field

2.2.5.2.1 Data Frame Format

2.2.5.2.2 APS Command Frame Format