Vous êtes sur la page 1sur 604

ZigBee Specification

Document 053474r17

1
2
3
4
5
6
7
8
9
10
11

ZIGBEE SPECIFICATION 12
13
14
15
16
17
18
19
ZigBee Document 053474r17
20
January 17, 2008 11:09 am 21
Sponsored by: ZigBee Alliance 22
23
Accepted by ZigBee Alliance Board of Directors 24
Abstract The ZigBee Specification describes the infrastructure and services 25
available to applications operating on the ZigBee platform. 26
Keywords ZigBee, Stack, Network, Application, Profile, Framework, Device 27
Description, Binding, Security 28
29
30
31
32
33
34
January 17, 2008 35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
This page intentionally blank 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 i

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. (2007). All Rights Reserved. The 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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
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
This page intentionally blank 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 iii

DOCUMENT HISTORY 1
2
3
4
5
ZigBee Specification History 6
7
Version
Number Date Comments 8
9
December 14, 2004 ZigBee v.1.0 draft ratified 10
r06 February 17, 2006 ZigBee Specification (ZigBee document 11
number 053474r06/07) incorporating errata 12
and clarifications: ZigBee document 13
numbers 053920r02, 053954r02, 06084r00, 14
and 053474r07
15
r07 April 28, 2006 Changes made per Editorial comments on 16
spreadsheet, 17
r13 October 9, 2006 ZigBee-2006 Specification (see letter ballot 18
comments and resolution in ZigBee 19
document 064112) 20
r14 November 3, 2006 ZigBee-2007 Specification (adds features 21
described in 064270, 064269, 064268, 22
064281, 064319, and 064293) 23
r15 December 12, 2006 ZigBee-2007 Specification incorporating 24
errata and clarifications: 074746 25
r16 May 31, 2007 ZigBee-2007 Specification incorporating
26
errata and clarifications: 07819 27
28
r17 October 19, 2007 ZigBee-2007 specification incorporating
errata: 075318, 075053, 075164, 075098
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
iv Document History

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
This page intentionally blank 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 v

TABLE OF CONTENTS 1
2
3
4
Notice of Use and Disclosure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i 5
Document History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii 6
7
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi 8
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix 9
10
Chapter 1 ZigBee Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . 1 11
1.1 Protocol Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 12
1.1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 13
1.1.2 Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 14
1.1.3 Stack Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 15
16
1.1.4 Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
17
1.2 Conventions and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 18
1.2.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 19
1.3 Acronyms and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 20
1.4 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 21
1.4.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 22
23
1.5 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
24
1.5.1 ZigBee/IEEE References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 25
1.5.2 Normative References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 26
1.5.3 Informative References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 27
28
Chapter 2 Application Layer Specification . . . . . . . . . . . . . . . . . . . 17
29
2.1 General Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 30
2.1.1 Application Support Sub-Layer . . . . . . . . . . . . . . . . . . . . . . . 17 31
2.1.2 Application Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 32
2.1.3 ZigBee Device Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 33
2.2 ZigBee Application Support (APS) Sub-Layer . . . . . . . . . . . . . . . 19 34
35
2.2.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
36
2.2.2 Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 37
2.2.3 Application Support (APS) Sub-Layer Overview . . . . . . . . . 20 38
2.2.4 Service Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 39
2.2.5 Frame Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 40
2.2.6 Command Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 41
42
2.2.7 Constants and PIB Attributes. . . . . . . . . . . . . . . . . . . . . . . . . 60
43
2.2.8 Functional Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
vi Table of Contents

2.2.9 APS Sub-Layer Status Values . . . . . . . . . . . . . . . . . . . . . . . . 74


1
2.3 The ZigBee Application Framework . . . . . . . . . . . . . . . . . . . . . . . 76
2
2.3.1 Creating a ZigBee Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 3
2.3.2 ZigBee Descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4
2.3.3 Functional Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5
2.4 The ZigBee Device Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 6
2.4.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 7
8
2.4.2 Device Profile Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
9
2.4.3 Client Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 10
2.4.4 Server Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 11
2.4.5 ZDP Enumeration Description. . . . . . . . . . . . . . . . . . . . . . . . 211 12
2.4.6 Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 13
2.5 The ZigBee Device Objects (ZDO) . . . . . . . . . . . . . . . . . . . . . . . . 213 14
15
2.5.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
16
2.5.2 Device Object Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . 213 17
2.5.3 Layer Interface Description . . . . . . . . . . . . . . . . . . . . . . . . . . 220 18
2.5.4 System Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 19
2.5.5 Object Definition and Behavior . . . . . . . . . . . . . . . . . . . . . . . 224 20
2.5.6 Configuration Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 21
22
Chapter 3 Network Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 23
3.1 General Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 24
3.1.1 Network (NWK) Layer Overview . . . . . . . . . . . . . . . . . . . . . 259 25
3.2 Service Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 26
27
3.2.1 NWK Data Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
28
3.2.2 NWK Management Service . . . . . . . . . . . . . . . . . . . . . . . . . . 268 29
3.3 Frame Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 30
3.3.1 General NPDU Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 307 31
3.3.2 Format of Individual Frame Types . . . . . . . . . . . . . . . . . . . . 312 32
3.4 Command Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 33
34
3.4.1 Route Request Command . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
35
3.4.2 Route Reply Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 36
3.4.3 Network Status Command . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 37
3.4.4 Leave Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 38
3.4.5 Route Record Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 39
3.4.6 Rejoin Request Command . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 40
41
3.4.7 Rejoin Response Command. . . . . . . . . . . . . . . . . . . . . . . . . . 329
42
3.4.8 Link Status Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 43
3.4.9 Network Report Command . . . . . . . . . . . . . . . . . . . . . . . . . . 332 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 vii

3.4.10 Network Update Command . . . . . . . . . . . . . . . . . . . . . . . . . 335


1
3.5 Constants and NIB Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
2
3.5.1 NWK Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 3
3.5.2 NWK Information Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 4
3.6 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 5
3.6.1 Network and Device Maintenance. . . . . . . . . . . . . . . . . . . . . 347 6
3.6.2 Transmission and Reception . . . . . . . . . . . . . . . . . . . . . . . . . 382 7
8
3.6.3 Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
9
3.6.4 Scheduling Beacon Transmissions . . . . . . . . . . . . . . . . . . . . 405 10
3.6.5 Broadcast Communication. . . . . . . . . . . . . . . . . . . . . . . . . . . 407 11
3.6.6 Multicast Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 12
3.6.7 NWK Information in the MAC Beacons . . . . . . . . . . . . . . . . 414 13
3.6.8 Persistent Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 14
15
3.6.9 Low Power Routers (LPR) . . . . . . . . . . . . . . . . . . . . . . . . . . 416
16
3.7 NWK Layer Status Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 17
Chapter 4 Security Services Specification . . . . . . . . . . . . . . . . . . . . 419 18
4.1 Document Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419 19
20
4.2 General Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
21
4.2.1 Security Architecture and Design . . . . . . . . . . . . . . . . . . . . . 420 22
4.2.2 NWK Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423 23
4.2.3 APL Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424 24
4.2.4 Trust Center Role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 25
4.3 NWK Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 26
27
4.3.1 Frame Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
28
4.3.2 Secured NPDU Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430 29
4.3.3 Security-Related NIB Attributes . . . . . . . . . . . . . . . . . . . . . . 430 30
4.4 APS Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 31
4.4.1 Frame Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 32
4.4.2 Key-Establishment Services . . . . . . . . . . . . . . . . . . . . . . . . . 439 33
34
4.4.3 Transport-Key Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
35
4.4.4 Update Device Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 36
4.4.5 Remove Device Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 37
4.4.6 Request Key Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 38
4.4.7 Switch Key Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 39
4.4.8 Entity Authentication Services . . . . . . . . . . . . . . . . . . . . . . . 467 40
41
4.4.9 Command Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
42
4.4.10 Security-Related AIB Attributes . . . . . . . . . . . . . . . . . . . . . 488 43
4.5 Common Security Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
viii Table of Contents

4.5.1 Auxiliary Frame Header Format . . . . . . . . . . . . . . . . . . . . . . 490


1
4.5.2 Security Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
2
4.5.3 Cryptographic Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 493 3
4.5.4 Implementation Guidelines (Informative) . . . . . . . . . . . . . . . 493 4
4.6 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494 5
4.6.1 ZigBee Coordinator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494 6
4.6.2 Trust Center Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495 7
8
4.6.3 Security Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
9
Annex A CCM* Mode of Operation . . . . . . . . . . . . . . . . . . . . . . . . . 521 10
A.1 Notation and Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522 11
A.2 CCM* Mode Encryption and Authentication Transformation . . . 522 12
13
A.2.1 Input Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
14
A.2.2 Authentication Transformation . . . . . . . . . . . . . . . . . . . . . . . 523 15
A.2.3 Encryption Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 524 16
A.3 CCM* Mode Decryption and Authentication 17
Checking Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 18
A.3.1 Decryption Transformation. . . . . . . . . . . . . . . . . . . . . . . . . . 525 19
20
A.3.2 Authentication Checking Transformation. . . . . . . . . . . . . . . 526
21
A.4 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526 22
Annex B Security Building Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . 527 23
B.1 Symmetric-Key Cryptographic Building Blocks . . . . . . . . . . . . . . 527 24
25
B.1.1 Block-Cipher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
26
B.1.2 Mode of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527 27
B.1.3 Cryptographic Hash Function . . . . . . . . . . . . . . . . . . . . . . . . 528 28
B.1.4 Keyed Hash Function for Message Authentication . . . . . . . 528 29
B.1.5 Specialized Keyed Hash Function for 30
Message Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528 31
32
B.1.6 Challenge Domain Parameters . . . . . . . . . . . . . . . . . . . . . . . 528
33
B.2 Key Agreement Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529 34
B.2.1 Symmetric-Key Key Agreement Scheme . . . . . . . . . . . . . . . 529 35
B.3 Challenge Domain Parameter Generation and Validation . . . . . . . 529 36
B.3.1 Challenge Domain Parameter Generation. . . . . . . . . . . . . . . 530 37
B.3.2 Challenge Domain Parameter Verification . . . . . . . . . . . . . . 530 38
39
B.4 Challenge Validation Primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
40
B.5 Secret Key Generation (SKG) Primitive . . . . . . . . . . . . . . . . . . . . 531 41
B.6 Block-Cipher-Based Cryptographic Hash Function . . . . . . . . . . . 532 42
B.7 Symmetric-Key Authenticated Key Agreement Scheme. . . . . . . . 533 43
B.7.1 Initiator Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 ix

B.7.2 Responder Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 536


1
B.8 Mutual Symmetric-Key Entity Authentication . . . . . . . . . . . . . . . 538
2
B.8.1 Initiator Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540 3
B.8.2 Responder Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 541 4
Annex C Test Vectors For Cryptographic Building Blocks . . . . . . 543 5
6
C.1 Data Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
7
C.2 AES Block Cipher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 8
C.3 CCM* Mode Encryption and Authentication Transformation . . . 543 9
C.3.1 Input Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544 10
C.3.2 Authentication Transformation . . . . . . . . . . . . . . . . . . . . . . . 545 11
C.3.3 Encryption Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 545 12
13
C.4 CCM* Mode Decryption and Authentication
14
Checking Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547 15
C.4.1 Decryption Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 547 16
C.4.2 Authentication Checking Transformation. . . . . . . . . . . . . . . 548 17
C.5 Cryptographic Hash Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549 18
C.5.1 Test Vector Set 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549 19
20
C.5.2 Test Vector Set 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
21
C.6 Keyed Hash Function for Message Authentication . . . . . . . . . . . . 551 22
C.6.1 Test Vector Set 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551 23
C.6.2 Test Vector Set 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552 24
C.6.3 Specialized Keyed Hash Function for Message 25
Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553 26
27
C.6.4 Symmetric-Key Key Agreement Scheme and Entity
28
Authentication Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553 29
Annex D MAC and PHY Sub-Layer Clarifications . . . . . . . . . . . . 567 30
D.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567 31
32
D.1.1 Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
33
D.1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567 34
D.2 Stack Size Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567 35
D.3 MAC Association. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568 36
D.4 aMaxMACFrameSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569 37
D.5 Beacon Timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570 38
39
Annex E Operation of Network Manager as Network 40
Channel Manager for Interference Reporting and Resolution . . . 573 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
x Table of Contents

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
This page intentionally blank 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 xi

LIST OF TABLES 1
2
3
4
Table 1.1 ZigBee Protocol Versions . . . . . . . . . . . . . . . . . . . . . . . . . 7 5
Table 2.1 APSDE-SAP Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6
Table 2.2 APSDE-DATA.request Parameters . . . . . . . . . . . . . . . . . . 23 7
Table 2.3 APSDE-DATA.confirm Parameters . . . . . . . . . . . . . . . . . 28 8
Table 2.4 APSDE-DATA.indication Parameters . . . . . . . . . . . . . . . . 30 9
10
Table 2.5 Summary of the Primitives Accessed Through the
11
APSME-SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12
Table 2.6 APSME-BIND.request Parameters . . . . . . . . . . . . . . . . . . 34 13
Table 2.7 APSME-BIND.confirm Parameters . . . . . . . . . . . . . . . . . . 36 14
Table 2.8 APSME-UNBIND.request Parameters . . . . . . . . . . . . . . . 38 15
Table 2.9 APSME-UNBIND.confirm Parameters . . . . . . . . . . . . . . . 40 16
17
Table 2.10 APSME-GET.request Parameters . . . . . . . . . . . . . . . . . . 41
18
Table 2.11 APSME-GET.confirm Parameters . . . . . . . . . . . . . . . . . . 42 19
Table 2.12 APSME-SET.request Parameters . . . . . . . . . . . . . . . . . . . 43 20
Table 2.13 APSME-SET.confirm Parameters . . . . . . . . . . . . . . . . . . 44 21
Table 2.14 APSME-ADD-GROUP.request Parameters . . . . . . . . . . 45 22
Table 2.15 APSME-ADD-GROUP.confirm Parameters . . . . . . . . . . 46 23
24
Table 2.16 APSME-REMOVE-GROUP.request Parameters . . . . . . 47
25
Table 2.17 APSME-REMOVE-GROUP.confirm Parameters . . . . . . 49 26
Table 2.18 APSME-REMOVE-ALL-GROUPS.request Parameters . 50 27
Table 2.19 APSME-REMOVE-ALL-GROUPS.confirm Parameters 51 28
Table 2.20 Values of the Frame Type Sub-Field . . . . . . . . . . . . . . . . 52 29
Table 2.21 Values of the Delivery Mode Sub-Field . . . . . . . . . . . . . 53 30
31
Table 2.22 Values of the Fragmentation Sub-Field . . . . . . . . . . . . . . 56
32
Table 2.23 APS Sub-Layer Constants . . . . . . . . . . . . . . . . . . . . . . . . 60 33
Table 2.24 APS IB Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 34
Table 2.25 Group Table Entry Format . . . . . . . . . . . . . . . . . . . . . . . . 62 35
Table 2.26 APS Sub-layer Status Values . . . . . . . . . . . . . . . . . . . . . . 74 36
Table 2.27 ZigBee Descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 37
38
Table 2.28 Fields of the Node Descriptor . . . . . . . . . . . . . . . . . . . . . 81
39
Table 2.29 Values of the Logical Type Field . . . . . . . . . . . . . . . . . . . 82 40
Table 2.30 Values of the Frequency Band Field . . . . . . . . . . . . . . . . 83 41
Table 2.31 Server Mask Bit Assignments . . . . . . . . . . . . . . . . . . . . . 84 42
Table 2.32 Descriptor Capability Bit Assignments . . . . . . . . . . . . . . 85 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
xii List of Tables

Table 2.33 Fields of the Node Power Descriptor . . . . . . . . . . . . . . . . 85


1
Table 2.34 Values of the Current Power Mode Field . . . . . . . . . . . . 86
2
Table 2.35 Values of the Available Power Sources Field . . . . . . . . . 86 3
Table 2.36 Values of the Current Power Sources Field . . . . . . . . . . . 87 4
Table 2.37 Values of the Current Power Source Level Field . . . . . . 87 5
Table 2.38 Fields of the Simple Descriptor . . . . . . . . . . . . . . . . . . . . 88 6
Table 2.39 Values of the Application Device Version Field . . . . . . . 89 7
8
Table 2.40 Fields of the Complex Descriptor . . . . . . . . . . . . . . . . . . 90
9
Table 2.41 Values of the Character Set Identifier Sub-Field . . . . . . . 91 10
Table 2.42 Fields of the User Descriptor . . . . . . . . . . . . . . . . . . . . . . 92 11
Table 2.43 Device and Service Discovery Client Services 12
Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 13
Table 2.44 Fields of the NWK_addr_req Command . . . . . . . . . . . . . 99 14
15
Table 2.45 Fields of the IEEE_addr_req Command . . . . . . . . . . . . . 101
16
Table 2.46 Fields of the Node_Desc_req Command . . . . . . . . . . . . . 102 17
Table 2.47 Fields of the Power_Desc_req Command . . . . . . . . . . . . 103 18
Table 2.48 Fields of the Simple_Desc_req Command . . . . . . . . . . . . 104 19
Table 2.49 Fields of the Active_EP_req Command . . . . . . . . . . . . . . 105 20
Table 2.50 Fields of the Match_Desc_req Command . . . . . . . . . . . . 106 21
22
Table 2.51 Fields of the Complex_Desc_req Command . . . . . . . . . . 107
23
Table 2.52 Fields of the User_Desc_req Command . . . . . . . . . . . . . 108 24
Table 2.53 Fields of the Discovery_Cache_req Command . . . . . . . . 109 25
Table 2.54 Fields of the Device_annce Command . . . . . . . . . . . . . . 110 26
Table 2.55 Fields of the User_Desc_set Command . . . . . . . . . . . . . . 111 27
Table 2.56 Fields of the System_Server_Discovery_req Command . 112 28
29
Table 2.57 Fields of the Discovery_store_req Command . . . . . . . . . 113
30
Table 2.58 Fields of the Node_Desc_store_req Command . . . . . . . . 114 31
Table 2.59 Fields of the Power_Desc_store_req Command . . . . . . . 115 32
Table 2.60 Fields of the Active_EP_store_req Command . . . . . . . . . 116 33
Table 2.61 Fields of the Simple_Desc_store_req Command . . . . . . . 117 34
Table 2.62 Fields of the Remove_node_cache_req Command . . . . . 118 35
36
Table 2.63 Fields of the Find_node_cache_req Command Frame . . 119
37
Table 2.64 Fields of the Extended_Simple_Desc_req Command . . . 120 38
Table 2.65 Fields of the Extended_Active_EP_req Command . . . . . 121 39
Table 2.66 End Device Bind, Bind, Unbind, and Bind 40
Management Client Service Commands . . . . . . . . . . . . . . . . . . . 122 41
Table 2.67 Fields of the End_Device_Bind_req Command . . . . . . . 123 42
43
Table 2.68 Fields of the Bind_req Command . . . . . . . . . . . . . . . . . . 125
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 xiii

Table 2.69 Fields of the Unbind_req Command . . . . . . . . . . . . . . . . 127


1
Table 2.70 Fields of the Bind_Register_req Command . . . . . . . . . . . 128
2
Table 2.71 Fields of the Replace_Device_req Command . . . . . . . . . 129 3
Table 2.72 Fields of the Store_Bkup_Bind_Entry_req Command . . 131 4
Table 2.73 Fields of the Remove_Bkup_Bind_Entry_req Command 132 5
Table 2.74 Fields of the Backup_Bind_Table_req Command . . . . . . 134 6
Table 2.75 Fields of the Recover_Bind_Table_req Command . . . . . 135 7
8
Table 2.76 Fields of the Backup_Source_Bind_req Command . . . . . 136
9
Table 2.77 Fields of the Recover_Source_Bind_req Command . . . . 137 10
Table 2.78 Network Management Client Services Commands . . . . . 138 11
Table 2.79 Fields of the Mgmt_NWK_Disc_req Command . . . . . . . 139 12
Table 2.80 Fields of the Mgmt_Lqi_req Command . . . . . . . . . . . . . . 140 13
Table 2.81 Fields of the Mgmt_Rtg_req Command . . . . . . . . . . . . . 141 14
15
Table 2.82 Fields of the Mgmt_Bind_req Command . . . . . . . . . . . . 142
16
Table 2.83 Fields of the Mgmt_Leave_req Command . . . . . . . . . . . 143 17
Table 2.84 Fields of the Mgmt_Direct_Join_req Command . . . . . . . 144 18
Table 2.85 Fields of the Mgmt_Permit_Joining_req Command . . . . 145 19
Table 2.86 Fields of the Mgmt_Cache_req Command . . . . . . . . . . . 147 20
Table 2.87 Fields of the Mgmt_NWK_Update_req Command . . . . . 148 21
22
Table 2.88 Device and Service Discovery Server Service Primitives 150
23
Table 2.89 Fields of the NWK_addr_rsp Command . . . . . . . . . . . . . 151 24
Table 2.90 IEEE_addr_rsp Parameters . . . . . . . . . . . . . . . . . . . . . . . 154 25
Table 2.91 Fields of the Node_Desc_rsp Command . . . . . . . . . . . . . 156 26
Table 2.92 Fields of the Power_Desc_rsp Command . . . . . . . . . . . . 158 27
Table 2.93 Fields of the Simple_Desc_rsp Command . . . . . . . . . . . . 159 28
29
Table 2.94 Fields of the Active_EP_rsp Command . . . . . . . . . . . . . . 161
30
Table 2.95 Fields of the Match_Desc_rsp Command . . . . . . . . . . . . 163 31
Table 2.96 Fields of the Complex_Desc_rsp Command . . . . . . . . . . 165 32
Table 2.97 Fields of the User_Desc_rsp Command . . . . . . . . . . . . . . 167 33
Table 2.98 Fields of the System_Server_Discovery_rsp Command . 169 34
Table 2.99 Fields of the User_Desc_conf Command . . . . . . . . . . . . 170 35
36
Table 2.100 Fields of the Discovery_Cache_rsp Command . . . . . . . 171
37
Table 2.101 Fields of the Discovery_store_rsp Command . . . . . . . . 172 38
Table 2.102 Fields of the Node_Desc_store_rsp Command . . . . . . . 173 39
Table 2.103 Fields of the Power_Desc_store_rsp Command . . . . . . 174 40
Table 2.104 Fields of the Active_EP_store_rsp Command . . . . . . . . 175 41
Table 2.105 Fields of the Simple_Desc_store_rsp Command . . . . . . 176 42
43
Table 2.106 Fields of the Remove_node_cache_rsp Command . . . . 177
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
xiv List of Tables

Table 2.107 Fields of the Find_node_cache_rsp Command . . . . . . . 178


1
Table 2.108 Fields of the Extended_Simple_Desc_rsp Command . . 179
2
Table 2.109 Fields of the Extended_Active_EP_rsp Command . . . . 181 3
Table 2.110 End Device Bind, Unbind and Bind Management 4
Server Services Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 5
Table 2.111 Fields of the End_Device_Bind_rsp Command . . . . . . . 184 6
Table 2.112 Fields of the Bind_rsp Command . . . . . . . . . . . . . . . . . 185 7
8
Table 2.113 Fields of the Unbind_rsp Command . . . . . . . . . . . . . . . 186
9
Table 2.114 Fields of the Bind_Register_rsp Command . . . . . . . . . . 187 10
Table 2.115 Fields of the Replace_Device_rsp Command . . . . . . . . 188 11
Table 2.116 Fields of the Store_Bkup_Bind_Entry_rsp Command . 189 12
Table 2.117 Fields of the Remove_Bkup_Bind_Entry_rsp Command 190 13
Table 2.118 Fields of the Backup_Bind_Table_rsp Command . . . . . 191 14
15
Table 2.119 Fields of the Recover_Bind_Table_rsp Command . . . . 192
16
Table 2.120 Fields of the Backup_Source_Bind_rsp Command . . . . 193 17
Table 2.121 Fields of the Recover_Source_Bind_rsp Command . . . 194 18
Table 2.122 Network Management Server Service Commands . . . . 195 19
Table 2.123 Fields of the Mgmt_NWK_Disc_rsp Command . . . . . . 195 20
Table 2.124 NetworkList Record Format . . . . . . . . . . . . . . . . . . . . . 196 21
22
Table 2.125 Fields of the Mgmt_Lqi_rsp Command . . . . . . . . . . . . . 198
23
Table 2.126 NeighborTableList Record Format . . . . . . . . . . . . . . . . 199 24
Table 2.127 Fields of the Mgmt_Rtg_rsp Command . . . . . . . . . . . . . 201 25
Table 2.128 RoutingTableList Record Format . . . . . . . . . . . . . . . . . 202 26
Table 2.129 Fields of the Mgmt_Bind_rsp Command . . . . . . . . . . . . 203 27
Table 2.130 BindingTableList Record Format . . . . . . . . . . . . . . . . . 204 28
29
Table 2.131 Fields of the Mgmt_Leave_rsp Command . . . . . . . . . . . 206
30
Table 2.132 Fields of the Mgmt_Direct_Join_rsp Command . . . . . . 207 31
Table 2.133 Fields of the Mgmt_Permit_Joining_rsp Command . . . 208 32
Table 2.134 Fields of the Mgmt_Cache_rsp Command . . . . . . . . . . 209 33
Table 2.135 DiscoveryCacheList Record Format . . . . . . . . . . . . . . . 209 34
Table 2.136 Fields of the Mgmt_NWK_Update_notify Command . . 211 35
36
Table 2.137 ZDP Enumerations Description . . . . . . . . . . . . . . . . . . . 212
37
Table 2.138 ZigBee Device Objects . . . . . . . . . . . . . . . . . . . . . . . . . 225 38
Table 2.139 Startup Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 39
Table 2.140 Additional Commissioning Parameters . . . . . . . . . . . . . 244 40
Table 2.141 Device and Service Discovery Attributes . . . . . . . . . . . 245 41
Table 2.142 Security Manager Attributes . . . . . . . . . . . . . . . . . . . . . 247 42
43
Table 2.143 Binding Manager Attributes . . . . . . . . . . . . . . . . . . . . . . 248
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 xv

Table 2.144 Network Manager Attributes . . . . . . . . . . . . . . . . . . . . . 250


1
Table 2.145 Node Manager Attributes . . . . . . . . . . . . . . . . . . . . . . . . 252
2
Table 2.146 Group Manager Attributes . . . . . . . . . . . . . . . . . . . . . . . 253 3
Table 2.147 Configuration Attributes . . . . . . . . . . . . . . . . . . . . . . . . 253 4
Table 2.148 Configuration Attribute Definitions . . . . . . . . . . . . . . . . 254 5
Table 3.1 NLDE-SAP Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 6
Table 3.2 NLDE-DATA.request Parameters . . . . . . . . . . . . . . . . . . . 262 7
8
Table 3.3 NLDE-DATA.confirm Parameters . . . . . . . . . . . . . . . . . . 265
9
Table 3.4 NLDE-DATA.indication Parameters . . . . . . . . . . . . . . . . . 266 10
Table 3.5 Summary of the Primitives Accessed Through the 11
NLME-SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 12
Table 3.6 NLME-NETWORK-DISCOVERY.request Parameters . . 269 13
Table 3.7 NLME-NETWORK-DISCOVERY.confirm Parameters . 270 14
15
Table 3.8 Network Descriptor Information Fields . . . . . . . . . . . . . . . 270
16
Table 3.9 NLME-NETWORK-FORMATION.request Parameters . . 272 17
Table 3.10 NLME-NETWORK-FORMATION.confirm Parameters 274 18
Table 3.11 NLME-PERMIT-JOINING.request Parameters . . . . . . . 275 19
Table 3.12 NLME-PERMIT-JOINING.confirm Parameters . . . . . . . 276 20
Table 3.13 NLME-START-ROUTER.request Parameters . . . . . . . . 277 21
22
Table 3.14 NLME-START-ROUTER.confirm Parameters . . . . . . . . 278
23
Table 3.15 NLME-ED-SCAN.request Parameters . . . . . . . . . . . . . . 279 24
Table 3.16 NLME-ED-SCAN.confirm . . . . . . . . . . . . . . . . . . . . . . . 280 25
Table 3.17 NLME-JOIN.request Parameters . . . . . . . . . . . . . . . . . . . 282 26
Table 3.18 NLME-JOIN.indication Parameters . . . . . . . . . . . . . . . . . 284 27
Table 3.19 NLME-JOIN.confirm Parameters . . . . . . . . . . . . . . . . . . 285 28
29
Table 3.20 NLME-DIRECT-JOIN.request Parameters . . . . . . . . . . . 286
30
Table 3.21 NLME-DIRECT-JOIN.confirm Parameters . . . . . . . . . . 288 31
Table 3.22 NLME-LEAVE.request Parameters . . . . . . . . . . . . . . . . . 289 32
Table 3.23 NLME-LEAVE.indication Parameters . . . . . . . . . . . . . . 290 33
Table 3.24 NLME-LEAVE.confirm Parameters . . . . . . . . . . . . . . . . 291 34
Table 3.25 NLME-RESET.request Parameters . . . . . . . . . . . . . . . . . 292 35
36
Table 3.26 NLME-RESET.confirm Parameters . . . . . . . . . . . . . . . . 293
37
Table 3.27 NLME-SYNC.request Parameters . . . . . . . . . . . . . . . . . . 295 38
Table 3.28 NLME-SYNC.confirm Parameters . . . . . . . . . . . . . . . . . 296 39
Table 3.29 NLME-GET.request Parameters . . . . . . . . . . . . . . . . . . . 298 40
Table 3.30 NLME-GET.confirm Parameters . . . . . . . . . . . . . . . . . . . 299 41
Table 3.31 NLME-SET.request Parameters . . . . . . . . . . . . . . . . . . . . 300 42
43
Table 3.32 NLME-SET.confirm Parameters . . . . . . . . . . . . . . . . . . . 301
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
xvi List of Tables

Table 3.33 NLME-NWK-STATUS.indication Parameters . . . . . . . . 302


1
Table 3.34 NLME-ROUTE-DISCOVERY.request Parameters . . . . 304
2
Table 3.35 NLME_ROUTE-DISCOVERY.confirm Parameters . . . 306 3
Table 3.36 Allowable Frame Control Sub-Field Configurations . . . . 308 4
Table 3.37 Values of the Frame Type Sub-Field . . . . . . . . . . . . . . . . 308 5
Table 3.38 Values of the Discover Route Sub-Field . . . . . . . . . . . . . 309 6
Table 3.39 Values of the Multicast Mode Sub-Field . . . . . . . . . . . . . 311 7
8
Table 3.40 NWK Command Frames . . . . . . . . . . . . . . . . . . . . . . . . . 314
9
Table 3.41 Many-to-One Field Values . . . . . . . . . . . . . . . . . . . . . . . . 316 10
Table 3.42 Status Codes for Network Status Command Frame . . . . . 322 11
Table 3.43 NWK Layer Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 12
Table 3.44 NIB Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 13
Table 3.45 Route Record Table Entry Format . . . . . . . . . . . . . . . . . . 346 14
15
Table 3.46 Network Address Map . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
16
Table 3.47 Capability Information Bit-Fields . . . . . . . . . . . . . . . . . . 353 17
Table 3.48 Neighbor Table Entry Format . . . . . . . . . . . . . . . . . . . . . 367 18
Table 3.49 Additional Neighbor Table Fields . . . . . . . . . . . . . . . . . . 369 19
Table 3.50 Example Addressing Offset Values for Each Given 20
Depth Within the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 21
22
Table 3.51 Routing Table Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
23
Table 3.52 Route Status Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 24
Table 3.53 Route Discovery Table Entry . . . . . . . . . . . . . . . . . . . . . . 388 25
Table 3.54 Broadcast Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 26
Table 3.55 Broadcast Transaction Record . . . . . . . . . . . . . . . . . . . . . 408 27
Table 3.56 NWK Layer Information Fields . . . . . . . . . . . . . . . . . . . . 414 28
29
Table 3.57 NWK Layer Status Values . . . . . . . . . . . . . . . . . . . . . . . . 417
30
Table 4.1 NIB Security Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . 431 31
Table 4.2 Elements of the Network Security Material Descriptor . . . 433 32
Table 4.3 Elements of the Incoming Frame Counter Descriptor . . . . 433 33
Table 4.4 The APS Layer Security Primitives . . . . . . . . . . . . . . . . . . 434 34
Table 4.5 APSME-ESTABLISH-KEY.request Parameters . . . . . . . . 440 35
36
Table 4.6 APSME-ESTABLISH-KEY.confirm Parameters . . . . . . . 441
37
Table 4.7 APSME-ESTABLISH-KEY.indication Parameters . . . . . 442 38
Table 4.8 APSME-ESTABLISH-KEY.response Parameters . . . . . . 443 39
Table 4.9 Mapping of Frame Names to Symmetric-Key Key 40
Agreement Scheme Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 41
Table 4.10 Mapping of Symmetric-Key Key Agreement Error 42
43
Conditions to Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 xvii

Table 4.11 APSME-TRANSPORT-KEY.request Parameters . . . . . . 450


1
Table 4.12 KeyType Parameter of the Transport-Key Primitive . . . . 450
2
Table 4.13 TransportKeyData Parameter for a Trust 3
Center Master Key or Link Key . . . . . . . . . . . . . . . . . . . . . . . . . 451 4
Table 4.14 TransportKeyData Parameter for a Network Key . . . . . . 451 5
Table 4.15 TransportKeyData Parameter for an Application 6
Master or Link Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 7
8
Table 4.16 APSME-TRANSPORT-KEY.indication Parameters . . . 454
9
Table 4.17 TransportKeyData Parameter for a Trust Center 10
Master or Link Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455 11
Table 4.18 TransportKeyData Parameter for a Network Key . . . . . . 455 12
Table 4.19 TransportKeyData Parameter for an 13
Application Master or Link Key . . . . . . . . . . . . . . . . . . . . . . . . . 455 14
15
Table 4.20 APSME-UPDATE-DEVICE.request Parameters . . . . . . 458
16
Table 4.21 APSME-UPDATE-DEVICE.indication Parameters . . . . 460 17
Table 4.22 APSME-REMOVE-DEVICE.request Parameters . . . . . . 461 18
Table 4.23 APSME-REMOVE-DEVICE.indication Parameters . . . 462 19
Table 4.24 APSME-REQUEST-KEY.request Parameters . . . . . . . . 463 20
Table 4.25 APSME-REQUEST-KEY.indication Parameters . . . . . . 464 21
22
Table 4.26 APSME-SWITCH-KEY.request Parameters . . . . . . . . . . 465
23
Table 4.27 APSME-SWITCH-KEY.indication Parameters . . . . . . . 466 24
Table 4.28 APSME-AUTHENTICATE.request Parameter . . . . . . . . 468 25
Table 4.29 Action Parameter Enumeration . . . . . . . . . . . . . . . . . . . . 468 26
Table 4.30 APSME-AUTHENTICATE.confirm Parameters . . . . . . 470 27
Table 4.31 APSME-AUTHENTICATE.indication Parameters . . . . . 471 28
29
Table 4.32 Mapping of Frame Names to Mutual Entity Authentication
30
Scheme Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 31
Table 4.33 Mapping of Mutual Entity Authentication Error 32
Conditions to Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474 33
Table 4.34 Command Identifier Values . . . . . . . . . . . . . . . . . . . . . . . 474 34
Table 4.35 Values of the KeyType Sub-Field . . . . . . . . . . . . . . . . . . 483 35
36
Table 4.36 AIB Security Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 489
37
Table 4.37 Elements of the Key-Pair Descriptor . . . . . . . . . . . . . . . . 489 38
Table 4.38 Security Levels Available to the NWK, and APS Layers 491 39
Table 4.39 Encoding for the Key Identifier Sub-Field . . . . . . . . . . . 491 40
Table 4.40 Mapping of NLME-JOIN.indication Parameters to 41
Update Device Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498 42
43
Table 4.41 Elements of the Permissions Configuration Table . . . . . . 517
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
xviii List of Tables

Table 4.42 Elements of the Permissions Descriptor . . . . . . . . . . . . . 518


1
Table D.1 Associate Request Header Fields . . . . . . . . . . . . . . . . . . . 568
2
Table D.2 Data Request Header Fields . . . . . . . . . . . . . . . . . . . . . . . 569 3
Table D.3 Association Response Header Fields . . . . . . . . . . . . . . . . 569 4
Table D.4 Start Time for Beacon Transmissions . . . . . . . . . . . . . . . . 571 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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 xix

LIST OF FIGURES 1
2
3
4
Figure 1.1 Outline of the ZigBee Stack Architecture . . . . . . . . . . . . 2 5
Figure 2.1 The APS Sub-Layer Reference Model . . . . . . . . . . . . . . . 21 6
Figure 2.2 General APS Frame Format . . . . . . . . . . . . . . . . . . . . . . . 52 7
Figure 2.3 Format of the Frame Control Field . . . . . . . . . . . . . . . . . . 52 8
Figure 2.4 Format of the Extended Header Sub-Frame . . . . . . . . . . . 55 9
10
Figure 2.5 Format of the Extended Frame Control Field . . . . . . . . . . 56
11
Figure 2.6 Data Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 12
Figure 2.7 APS Command Frame Format . . . . . . . . . . . . . . . . . . . . . 58 13
Figure 2.8 Acknowledgement Frame Format . . . . . . . . . . . . . . . . . . 58 14
Figure 2.9 Binding on a Device Supporting a Binding Table . . . . . . 65 15
Figure 2.10 Successful Data Transmission Without an 16
17
Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
18
Figure 2.11 Successful Data Transmission With an 19
Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 20
Figure 2.12 Successful Data Transmission With Fragmentation . . . . 72 21
Figure 2.13 Fragmented Data Transmission With a Single 22
Retransmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 23
24
Figure 2.14 Fragmented Data Transmission With Multiple
25
Retransmissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 26
Figure 2.15 Format of the Complex Descriptor . . . . . . . . . . . . . . . . . 80 27
Figure 2.16 Format of an Individual Complex Descriptor Field . . . . 80 28
Figure 2.17 Format of the MAC Capability Flags Field . . . . . . . . . . 83 29
Figure 2.18 Format of the Language and Character Set Field . . . . . . 90 30
31
Figure 2.19 Format of the ZDP Frame . . . . . . . . . . . . . . . . . . . . . . . . 97
32
Figure 2.20 Format of the NWK_addr_req Command . . . . . . . . . . . 99 33
Figure 2.21 Format of the IEEE_addr_req_Command Frame . . . . . . 101 34
Figure 2.22 Format of the Node_Desc_req Command Frame . . . . . . 102 35
Figure 2.23 Format of the Power_Desc_req Command Frame . . . . . 103 36
Figure 2.24 Format of the Simple_Desc_req Command Frame . . . . 104 37
38
Figure 2.25 Format of the Active_EP_req Command Frame . . . . . . 104
39
Figure 2.26 Format of the Match_Desc_req Command Frame . . . . . 105 40
Figure 2.27 Format of the Complex_Desc_req Command Frame . . . 107 41
Figure 2.28 Format of the User_Desc_req Command Frame . . . . . . 108 42
Figure 2.29 Format of the Discovery_Cache_req Command Frame . 109 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
xx List of Figures

Figure 2.30 Format of the Device_annce Command Frame . . . . . . . 109


1
Figure 2.31 Format of the User_Desc_set Command Frame . . . . . . 110
2
Figure 2.32 Format of the System_Server_Discovery_req 3
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 4
Figure 2.33 Format of the Discovery_Store_req Command Frame . 112 5
Figure 2.34 Format of the Node_Desc_store_req Command Frame . 114 6
Figure 2.35 Format of the Power_Desc_store_req Command Frame 115 7
8
Figure 2.36 Format of the Active_EP_store_req Command Frame . 116
9
Figure 2.37 Format of the Simple_Desc_store_req Command Frame 117 10
Figure 2.38 Format of the Remove_node_cache_req 11
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 12
Figure 2.39 Format of the Find_node_cache Command Frame . . . . 119 13
Figure 2.40 Format of the Extended_Simple_Desc_req 14
15
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
16
Figure 2.41 Format of the Extended_Active_EP_req 17
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 18
Figure 2.42 Format of the End_Device_Bind_req Command Frame 123 19
Figure 2.43 Format of the Bind_req Command Frame . . . . . . . . . . . 125 20
Figure 2.44 Format of the Unbind_req Command Frame . . . . . . . . . 127 21
22
Figure 2.45 Format of the Bind_Register_req Command Frame . . . 128
23
Figure 2.46 Format of the Replace_Device_req Command Frame . . 129 24
Figure 2.47 Format of the Store_Bkup_Bind_Entry_req 25
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 26
Figure 2.48 Format of the Remove_Bkup_Bind_Entry_req 27
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 28
29
Figure 2.49 Format of the Backup_Bind_Table_req
30
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 31
Figure 2.50 Fields of the Recover_Bind_Table_req Command Frame 135 32
Figure 2.51 Fields of the Backup_Source_Bind_req 33
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 34
Figure 2.52 Format of the Recover_Source_Bind_req 35
36
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
37
Figure 2.53 Format of the Mgmt_NWK_Disc_req Command Frame 138 38
Figure 2.54 Format of the Mgmt_Lqi_req Command Frame . . . . . . 140 39
Figure 2.55 Format of the Mgmt_Rtg_req Command Frame . . . . . . 141 40
Figure 2.56 Format of the Mgmt_Bind_req Command Frame . . . . . 142 41
Figure 2.57 Format of the Mgmt_Leave_req Command Frame . . . . 143 42
43
Figure 2.58 Format of the Mgmt_Direct_Join _req Command Frame 144
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 xxi

Figure 2.59 Format of the Mgmt_Permit_Joining_req


1
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
2
Figure 2.60 Fields of the Mgmt_Cache_req Command Frame . . . . . 147 3
Figure 2.61 Fields of the Mgmt_NWK_Update_req 4
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 5
Figure 2.62 Format of the NWK_addr_rsp Command Frame . . . . . . 151 6
Figure 2.63 Format of the IEEE_addr_rs Command Frame . . . . . . . 154 7
8
Figure 2.64 Format of the Node_Desc_rsp Command Frame . . . . . . 156
9
Figure 2.65 Format of the Power_Desc_rsp Command Frame . . . . . 157 10
Figure 2.66 Format of the Simple_Desc_rsp Command Frame . . . . 159 11
Figure 2.67 Format of the Active_EP_rsp Command Frame . . . . . . 161 12
Figure 2.68 Format of the Match_Desc_rsp Command Frame . . . . . 162 13
Figure 2.69 Format of the Complex_Desc_rsp Command Frame . . . 165 14
15
Figure 2.70 Format of the User_Desc_rsp Command Frame . . . . . . 167
16
Figure 2.71 System_Server_Discovery_rsp Command Frame . . . . . 168 17
Figure 2.72 Format of the User_Desc_conf Command Frame . . . . . 169 18
Figure 2.73 Format of the Discovery_Cache_rsp Command Frame . 171 19
Figure 2.74 Format of the Discovery_store_rsp Command Frame . . 172 20
Figure 2.75 Format of the Node_Desc_store_rsp Command Frame . 173 21
22
Figure 2.76 Format of the Power_Desc_store_rsp Command Frame 174
23
Figure 2.77 Format of the Active_EP_store_rsp Command Frame . 175 24
Figure 2.78 Format of the Simple_Desc_store_rsp Command Frame 176 25
Figure 2.79 Format of the Remove_node_cache_rsp 26
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 27
Figure 2.80 Format of the Find_node_cache_rsp Command Frame . 178 28
29
Figure 2.81 Format of the Extended_Simple_Desc_rsp
30
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 31
Figure 2.82 Format of the Extended_Active_EP_rsp 32
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 33
Figure 2.83 Format of the End_Device_Bind_rsp Command Frame 184 34
Figure 2.84 Format of the Bind_rsp Command Frame . . . . . . . . . . . 185 35
36
Figure 2.85 Format of the Unbind_rsp Command Frame . . . . . . . . . 186
37
Figure 2.86 Format of the Bind_Register_rsp Command Frame . . . 187 38
Figure 2.87 Format of the Replace_Device_rsp Command Frame . . 188 39
Figure 2.88 Format of the Store_Bkup_Bind_Entry_rsp 40
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 41
Figure 2.89 Format of the Remove_Bkup_Bind_Entry_rsp 42
43
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
xxii List of Figures

Figure 2.90 Format of the Backup_Bind_Table_rsp


1
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
2
Figure 2.91 Format of the Backup_Bind_Table_rsp 3
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 4
Figure 2.92 Format of the Backup_Source_Bind_rsp 5
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 6
Figure 2.93 Format of the Recover_Source_Bind_rsp 7
8
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
9
Figure 2.94 Format of the Mgmt_NWK_Disc_rsp Command Frame 195 10
Figure 2.95 Format of the Mgmt_Lqi_rsp Command Frame . . . . . . 198 11
Figure 2.96 Format of the Mgmt_Rtg_rsp Command Frame . . . . . . 201 12
Figure 2.97 Format of the Mgmt_Bind_rsp Command Frame . . . . . 203 13
Figure 2.98 Format of the Mgmt_Leave_rsp Command Frame . . . . 206 14
15
Figure 2.99 Format of the Mgmt_Direct_Join_rsp Command Frame 207
16
Figure 2.100 Format of the Mgmt_Permit_Joining_rsp 17
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 18
Figure 2.101 Format of the Mgmt_Cache_rsp Command Frame . . . 209 19
Figure 2.102 Format of the Mgmt_NWK_Update_notify 20
Command Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 21
22
Figure 2.103 Primary Discovery Cache State Machine . . . . . . . . . . . 215
23
Figure 2.104 System Usage ZigBee Device Object Details . . . . . . . 221 24
Figure 2.105 System Usage ZigBee Device Object Details — Node 25
Manager Object and Security Manager Object . . . . . . . . . . . . . . 222 26
Figure 2.106 System Usage ZigBee Device Object Details — 27
Binding Manager Object and Network Manager Object . . . . . . . 223 28
29
Figure 2.107 System Usage ZigBee Device Object Details — Group
30
Manager Object and Configuration Attributes . . . . . . . . . . . . . . 224 31
Figure 2.108 Portability Message Sequence Chart: ZED 32
Secured Rejoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 33
Figure 2.109 Portability Message Sequence Chart: ZED 34
Unsecured Rejoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 35
36
Figure 2.110 Portability Message Sequence Chart: ZR
37
Unsecured Rejoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 38
Figure 3.1 The NWK Layer Reference Model . . . . . . . . . . . . . . . . . 261 39
Figure 3.2 Message Sequence Chart for Resetting the 40
Network Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 41
Figure 3.3 Message Sequence Chart for Synchronizing in a Non- 42
43
Beaconing Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 xxiii

Figure 3.4 Message Sequence Chart for Synchronizing in a Beacon-


1
Enabled Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
2
Figure 3.5 General NWK Frame Format . . . . . . . . . . . . . . . . . . . . . . 307 3
Figure 3.6 Frame Control Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 4
Figure 3.7 Multicast Control Field Format . . . . . . . . . . . . . . . . . . . . 311 5
Figure 3.8 Source Route Subframe Format . . . . . . . . . . . . . . . . . . . . 312 6
Figure 3.9 Data Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 7
8
Figure 3.10 NWK Command Frame Format . . . . . . . . . . . . . . . . . . . 313
9
Figure 3.11 Route Request Command Frame Format . . . . . . . . . . . . 315 10
Figure 3.12 Route Request Command Options Field . . . . . . . . . . . . 316 11
Figure 3.13 Route Reply Command Format . . . . . . . . . . . . . . . . . . . 318 12
Figure 3.14 Route Reply Command Options Field . . . . . . . . . . . . . . 319 13
Figure 3.15 Network Status Command Frame Format . . . . . . . . . . . 320 14
15
Figure 3.16 Leave Command Frame Format . . . . . . . . . . . . . . . . . . . 324
16
Figure 3.17 Leave Command Options Field . . . . . . . . . . . . . . . . . . . 325 17
Figure 3.18 Route Record Command Format . . . . . . . . . . . . . . . . . . 326 18
Figure 3.19 Rejoin Request Command Frame Format . . . . . . . . . . . 328 19
Figure 3.20 Rejoin Response Command Frame Format . . . . . . . . . . 329 20
Figure 3.21 Link Status Command Format . . . . . . . . . . . . . . . . . . . . 331 21
22
Figure 3.22 Link Status Command Options Field . . . . . . . . . . . . . . . 332
23
Figure 3.23 Link Status Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 24
Figure 3.24 Network Report Command Frame Format . . . . . . . . . . . 333 25
Figure 3.25 Network Report Command Options Field . . . . . . . . . . . 334 26
Figure 3.26 Report Command Identifier Sub-Field . . . . . . . . . . . . . . 334 27
Figure 3.27 PAN Identifier Conflict Report . . . . . . . . . . . . . . . . . . . 335 28
29
Figure 3.28 Network Update Command Frame Format . . . . . . . . . . 335
30
Figure 3.29 Network Update Command Options Field . . . . . . . . . . . 337 31
Figure 3.30 Update Command Identifier Sub-Field . . . . . . . . . . . . . 337 32
Figure 3.31 PAN Identifier Update . . . . . . . . . . . . . . . . . . . . . . . . . . 338 33
Figure 3.32 Establishing a New Network . . . . . . . . . . . . . . . . . . . . . 349 34
Figure 3.33 Permitting Devices to Join a Network . . . . . . . . . . . . . . 350 35
36
Figure 3.34 Procedure for Joining a Network Through Association . 356
37
Figure 3.35 Procedure for Handling a Join Request . . . . . . . . . . . . . 357 38
Figure 3.36 Child Rejoin Procedure . . . . . . . . . . . . . . . . . . . . . . . . . 361 39
Figure 3.37 Parent Rejoin Procedure . . . . . . . . . . . . . . . . . . . . . . . . . 363 40
Figure 3.38 Joining a Device to a Network Directly . . . . . . . . . . . . . 364 41
Figure 3.39 Child Procedure for Joining or Re-Joining a Network 42
43
Through Orphaning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
xxiv List of Figures

Figure 3.40 Parent Procedure for Joining or Re-Joining a Device to its


1
Network Through Orphaning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
2
Figure 3.41 Address Assignment in an Example Network . . . . . . . . 372 3
Figure 3.42 Initiation of the Leave Procedure . . . . . . . . . . . . . . . . . . 376 4
Figure 3.43 Procedure for a Device to Remove Its Child . . . . . . . . . 377 5
Figure 3.44 On Receipt of a Leave Command . . . . . . . . . . . . . . . . . 378 6
Figure 3.45 On Receipt of a Leave Command by a ZED . . . . . . . . . 379 7
8
Figure 3.46 Typical Frame Structure for a Beaconing Device . . . . . 405
9
Figure 3.47 Parent-Child Superframe Positioning Relationship . . . . 407 10
Figure 3.48 Broadcast Transaction Message Sequence Chart . . . . . . 410 11
Figure 3.49 Format of the MAC Sub-Layer Beacon Payload . . . . . . 416 12
Figure 4.1 ZigBee Frame with Security on the NWK Level . . . . . . . 423 13
Figure 4.2 ZigBee Frame with Security on the APS Level . . . . . . . . 424 14
15
Figure 4.3 Secured NWK Layer Frame Format . . . . . . . . . . . . . . . . . 430
16
Figure 4.4 Sequence Chart for Successful APSME-ESTABLISH- 17
KEY Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 18
Figure 4.5 Secured APS Layer Frame Format . . . . . . . . . . . . . . . . . . 467 19
Figure 4.6 Sequence Chart for Successful APSME-AUTHENTICATE 20
Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472 21
22
Figure 4.7 Generic SKKE Frame Command Format . . . . . . . . . . . . . 475
23
Figure 4.8 Transport-Key Command Frame . . . . . . . . . . . . . . . . . . . 477 24
Figure 4.9 Trust Center Master Key Descriptor Field in 25
Transport-Key Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 26
Figure 4.10 Network Key Descriptor Field in Transport-Key 27
Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478 28
29
Figure 4.11 Application Master Key Descriptor in Transport-Key
30
Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478 31
Figure 4.12 Update-Device Command Frame Format . . . . . . . . . . . 479 32
Figure 4.13 Remove-Device Command Frame Format . . . . . . . . . . . 480 33
Figure 4.14 Request-Key Command Frame Format . . . . . . . . . . . . . 481 34
Figure 4.15 Switch-key Command Frame Format . . . . . . . . . . . . . . 482 35
36
Figure 4.16 Entity Authentication Initiator Challenge Frame Format 483
37
Figure 4.17 KeyInfo Field Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 38
Figure 4.18 Entity Authentication Responder Challenge 39
Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 40
Figure 4.19 KeyInfo Field Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 485 41
Figure 4.20 Entity Authentication Initiator MAC and Data 42
43
Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 xxv

Figure 4.21 Entity Authentication Responder MAC and Data Frame


1
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
2
Figure 4.22 Tunnel Command Frame Format . . . . . . . . . . . . . . . . . . 488 3
Figure 4.23 Auxiliary Frame Header Format . . . . . . . . . . . . . . . . . . 490 4
Figure 4.24 Security Control Field Format . . . . . . . . . . . . . . . . . . . . 490 5
Figure 4.25 CCM* Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493 6
Figure 4.26 Example of Joining a Secured Network . . . . . . . . . . . . . 496 7
8
Figure 4.27 Example Standard Security Mode Authentication
9
Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504 10
Figure 4.28 Example High Security Mode Authentication Procedure 506 11
Figure 4.29 Example Network Key-Update Procedure . . . . . . . . . . . 509 12
Figure 4.30 Example End-to-End Application Key Establishment 13
Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512 14
15
Figure 4.31 Example Remove-Device Procedure . . . . . . . . . . . . . . . 514
16
Figure 4.32 Example Device-Leave Procedure . . . . . . . . . . . . . . . . . 515 17
Figure B.1 Symmetric-Key Authenticated Key Agreement Scheme 534 18
Figure B.2 Mutual Symmetric-Key Entity Authentication Scheme . 539 19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 1
xxvi

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
This page intentionally blank 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 1

C H A P T E R
1

1
2
3
4
5
6
7
8
9

CHAPTER 1ZIGBEE PROTOCOL OVERVIEW 10


11
12
13
1.1 Protocol Description 14
15
The ZigBee Alliance has developed a very low-cost, very low-power- 16
consumption, two-way, wireless communications standard. Solutions adopting the 17
ZigBee 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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
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 IEEE 802.15.4-2003 standard defines the two lower layers: the physical 4
(PHY) layer and the medium access control (MAC) sub-layer. The ZigBee 5
Alliance builds on this foundation by providing the network (NWK) layer and the 6
framework for the application layer. The application layer framework consists of 7
the application support sub-layer (APS) and the ZigBee device objects (ZDO). 8
Manufacturer-defined application objects use the framework and share APS and 9
security services with the ZDO. 10
IEEE 802.15.4-2003 has two PHY layers that operate in two separate frequency 11
ranges: 868/915 MHz and 2.4 GHz. The lower frequency PHY layer covers both 12
the 868 MHz European band and the 915 MHz band, used in countries such as the 13
United States and Australia. The higher frequency PHY layer is used virtually 14
worldwide. A complete description of the IEEE 802.15.4-2003 PHY layers can be 15
found in [B1]. 16
17
The IEEE 802.15.4-2003 MAC sub-layer controls access to the radio channel 18
using a CSMA-CA mechanism. Its responsibilities may also include transmitting 19
beacon frames, synchronization, and providing a reliable transmission 20
mechanism. A complete description of the IEEE 802.15.4-2003 MAC sub-layer 21
can be found in [B1]. 22
23
Application (APL) Layer 24
Application Framework 25
ZigBee Stack 26
ZigBee Device Object 27
Architecture (ZDO)
ZDO Public

Application
Interfaces

Application
Object 240 … Object 1
28
29
Endpoint 240 Endpoint 1 Endpoint 0
30
APSDE-SAP APSDE-SAP APSDE-SAP
31
Application Support Sublayer (APS)
ZDO Management Plane

32
APSME-
SAP

APS Security APS Message Reflector


Security
Managemen
Management
t
Broker Management 33
Service NLDE-SAP NLME-SAP - 34
Provider Network (NWK) Layer
35
NLME-SAP

IEEE 802.15.4
Security Message Routing Network
defined Broker Management Management 36
Management
ZigBee TM
Alliance
defined MLDE-SAP MLME-SAP
37
End manufacturer
Medium Access Control (MAC) Layer 38
defined 39
PLME-SAP
Layer
PD-SAP
Physical (PHY) Layer 40
function
2.4 GHz Radio 868/915 MHz Radio 41
Layer
interface 42
43
Figure 1.1 Outline of the ZigBee Stack Architecture 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 3

1.1.4 Network Topology 1


2
The ZigBee network layer (NWK) supports star, tree, and mesh topologies. In a
3
star topology, the network is controlled by one single device called the ZigBee
4
coordinator. The ZigBee coordinator is responsible for initiating and maintaining
5
the devices on the network. All other devices, known as end devices, directly
6
communicate with the ZigBee coordinator. In mesh and tree topologies, the
7
ZigBee coordinator is responsible for starting the network and for choosing
8
certain key network parameters, but the network may be extended through the use
9
of ZigBee routers. In tree networks, routers move data and control messages
10
through the network using a hierarchical routing strategy. Tree networks may
11
employ beacon-oriented communication as described in the IEEE 802.15.4-2003
12
specification. Mesh networks allow full peer-to-peer communication. ZigBee
13
routers in mesh networks do not currently emit regular IEEE 802.15.4-2003
14
beacons. This specification describes only intra-PAN networks, that is, networks
15
in which communications begin and terminate within the same network.
16
17
1.2 Conventions and Abbreviations 18
19
20
1.2.1 Conventions 21
22
1.2.1.1 Symbols and Notation 23
24
Notation follows from ANSI X9.63-2001, §2.2 [B7]. 25
26
1.2.1.2 Integers, Octets, and Their Representation 27
28
Throughout Annexes A through D, the representation of integers as octet strings 29
and of octet strings as binary strings shall be fixed. All integers shall be 30
represented as octet strings in most-significant-octet first order. This 31
representation conforms to the convention in Section 4.3 of ANSI X9.63- 32
2001 [B7]. All octets shall be represented as binary strings in most-significant-bit 33
first order. 34
35
1.2.1.3 Transmission Order 36
Unless otherwise indicated, the transmission order of all frames in this 37
specification follows the conventions used in IEEE Std. 802.15.4-2003 [B1]): 38
39
• Frame formats are depicted in the order in which they are transmitted by the 40
PHY layer—from left to right—where the leftmost bit is transmitted first in 41
time. 42
• Bits within each field are numbered from 0 (leftmost, and least significant) to k- 43
1 (rightmost, and most significant), where the length of the field is k bits. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 1
4 ZigBee Protocol Overview

• Fields that are longer than a single octet are sent to the PHY in order from the
octet containing the lowest numbered bits to the octet containing the highest- 1
numbered bits. 2
3
1.2.1.4 Strings and String Operations 4
5
A string is a sequence of symbols over a specific set (e.g., the binary alphabet 6
{0,1} or the set of all octets). The length of a string is the number of symbols it 7
contains (over the same alphabet). The empty string has length 0. The right- 8
concatenation of two strings x and y of length m and n respectively (notation: x || 9
y), is the string z of length m+n that coincides with x on its leftmost m symbols 10
and with y on its rightmost n symbols. An octet is a symbol string of length 8. In 11
our context, all octets are strings over the binary alphabet. 12
13
14
1.3 Acronyms and Abbreviations 15
16
For the purposes of this standard, the following acronyms and abbreviations 17
apply: 18
19
AIB Application support layer information base
20
AF Application framework 21
APDU Application support sub-layer protocol data unit 22
23
APL Application layer
24
APS Application support sub-layer 25
APSDE Application support sub-layer data entity 26
27
APSDE-SAP Application support sub-layer data entity – service access point 28
APSME Application support sub-layer management entity 29
APSME-SAP Application support sub-layer management entity – service access point 30
31
ASDU APS service data unit 32
BRT Broadcast retry timer 33
34
BTR Broadcast transaction record
35
BTT Broadcast transaction table 36
CCM* Enhanced counter with CBC-MAC mode of operation 37
38
CSMA-CA Carrier sense multiple access – collision avoidance
39
EPID Extended PAN ID 40
FFD Full function device 41
42
GTS Guaranteed time slot
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 5

HDR Header
1
IB Information base 2
LQI Link quality indicator 3
4
LR-WPAN Low rate wireless personal area network
5
MAC Medium access control 6
MCPS-SAP Medium access control common part sub-layer – service access point 7
8
MIC Message integrity code
9
MLME-SAP Medium access control sub-layer management entity – service access point 10
MSC Message sequence chart 11
12
MSDU Medium access control sub-layer service data unit 13
MSG Message service type 14
NBDT Network broadcast delivery time 15
16
NHLE Next higher layer entity 17
NIB Network layer information base 18
19
NLDE Network layer data entity
20
NLDE-SAP Network layer data entity – service access point 21
NLME Network layer management entity 22
23
NLME-SAP Network layer management entity – service access point
24
NPDU Network layer protocol data unit 25
NSDU Network service data unit 26
27
NWK Network
28
OSI Open systems interconnection 29
PAN Personal area network 30
31
PD-SAP Physical layer data – service access point 32
PDU Protocol data unit 33
PHY Physical layer 34
35
PIB Personal area network information base 36
PLME-SAP Physical layer management entity – service access point 37
38
POS Personal operating space
39
QOS Quality of service 40
RFD Reduced function device 41
42
RREP Route reply
43
RREQ Route request 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 1
6 ZigBee Protocol Overview

RN Routing node
1
SAP Service access point 2
SKG Secret key generation 3
4
SKKE Symmetric-key key establishment
5
SSP Security services provider 6
SSS Security services specification 7
8
WPAN Wireless personal area network
9
XML Extensible markup language 10
ZB ZigBee 11
12
ZDO ZigBee device object 13
14
15
1.4 Glossary 16
17
18
1.4.1 Definitions 19
20
1.4.1.1 Conformance Levels 21
The conformance level definitions shall follow those in clause 13, section 1 of the 22
IEEE Style Manual [B13]. 23
24
Expected: A key word used to describe the behavior of the hardware or 25
software in the design models assumed by this Specification. Other hardware 26
and software design models may also be implemented. 27
May: A key word indicating a course of action permissible within the limits of 28
the standard (may equals is permitted to). 29
30
Shall: A key word indicating mandatory requirements to be strictly followed in 31
order to conform to the standard; deviations from shall are prohibited (shall 32
equals is required to). 33
Should: A key word indicating that, among several possibilities, one is 34
recommended as being particularly suitable, without mentioning or excluding 35
others; that a certain course of action is preferred but not necessarily required; 36
or, that (in the negative form) a certain course of action is deprecated but not 37
prohibited (should equals is recommended that). 38
39
Reserved Codes: A set of codes that are defined in this specification, but not 40
otherwise used. Future specifications may implement the use of these codes. A 41
product implementing this specification shall not generate these codes. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 7

Reserved Fields: A set of fields that are defined in this specification, but are
not otherwise used. Products that implement this specification shall zero these 1
fields and shall make no further assumptions about these fields nor perform 2
processing based on their content. 3
4
ZigBee Protocol Version: The name of the ZigBee protocol version governed 5
by this specification. The protocol version sub-field of the frame control field 6
in the NWK header of all ZigBee Protocol Stack frames conforming to this 7
specification shall have a value of 0x02. The protocol version support required 8
by various ZigBee specification revisions appears below in Table 1.1. 9
Table 1.1 ZigBee Protocol Versions 10
11
Protocol 12
Specification Version Comment
13
Current 0x02 Backwards compatibility with ZigBee 2006 14
required. 15
Backwards compatibility with ZigBee 2004 not 16
required. 17
ZigBee 2006 0x02 Backwards compatibility with ZigBee 2004 not 18
required. 19
ZigBee 2004 0x01 Original ZigBee version. 20
21
22
A ZigBee device that conforms to this version of the specification may elect to 23
provide backward compatibility with the 2004 revision of the specification. If it 24
so elects, it shall do so by supporting, in addition to the frame formats and 25
features described in this specification version, all frame formats and features 26
as specified in the older version. [All devices in an operating network, 27
regardless of which revisions of the ZigBee specification they support 28
internally, shall, with respect to their external, observable behavior, 29
consistently conform to a single ZigBee protocol version.] A single ZigBee 30
network shall not contain devices that conform, in terms of their external 31
behavior, to multiple ZigBee protocol versions. [The protocol version of the 32
network to join shall be determined by a backwardly compatible device in 33
examining the beacon payload prior to deciding to join the network; or shall be 34
established by the application if the device is a ZigBee coordinator.] A ZigBee 35
device conforming to this specification may elect to support only protocol 36
version 0x02, whereby it shall join only networks that advertise commensurate 37
beacon payload support. A ZigBee device that conforms to this specification 38
shall discard all frames carrying a protocol version sub-field value other than 39
0x01 or 0x02, and shall process only protocol versions of 0x01 or 0x02, 40
consistent with the protocol version of the network that the device participates 41
within. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 1
8 ZigBee Protocol Overview

1.4.1.2 ZigBee Definitions


1
For the purposes of this standard, the following terms and definitions apply. Terms 2
not defined in this clause can be found in IEEE P802.15.4 §3 [B1] or in ANSI 3
X9.63-2001 §2.1 [B7]. 4
5
Access control list: This is a table used by a device to determine which devices
6
are authorized to perform a specific function. This table may also store the
7
security material (e.g., cryptographic keys, frame counts, key counts, security
8
level information) used for securely communicating with other devices.
9
Active network key: This is the key used by a ZigBee device to secure 10
outgoing NWK frames and that is available for use to process incoming NWK 11
frames. 12
13
Alternate network key: This is a key available to process incoming NWK
14
frames in lieu of the active network key.
15
Application domain: This describes a broad area of applications, such as 16
building automation. 17
18
Application key: This is a master key or a link key transported by the Trust
19
center to a device for the purpose of securing end-to-end communication.
20
Application object: This is a component of the top portion of the application 21
layer defined by the manufacturer that actually implements the application. 22
23
Application profile: This is a collection of device descriptions, which together
24
form a cooperative application. For instance, a thermostat on one node
25
communicates with a furnace on another node. Together, they cooperatively
26
form a heating application profile.
27
Application support sub-layer protocol data unit: This is a unit of data that 28
is exchanged between the application support sub-layers of two peer entities. 29
30
APS command frame: This is a command frame from the APSME on a device
31
addressed to the peer entity on another device.
32
Association: This is the service provided by the IEEE 802.15.4-2003 MAC 33
sub-layer that is used to establish membership in a network. 34
35
Attribute: This is a data entity which represents a physical quantity or state.
36
This data is communicated to other devices using commands.
37
Beacon-enabled personal area network: This is a personal area network 38
containing at least one device that transmits beacon frames at a regular interval. 39
40
Binding: This is the creation of a unidirectional logical link between a source
41
endpoint/cluster identifier pair and a destination endpoint, which may exist on
42
one or more devices.
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 9

Broadcast: This is the transmission of a message to every device in a particular


PAN belonging to one of a small number of statically defined broadcast groups, 1
e.g. all routers, and within a given transmission radius measured in hops. 2
3
Broadcast jitter: This is a random delay time introduced by a device before 4
relaying a broadcast transaction. 5
Broadcast transaction record: This is a local receipt of a broadcast message 6
that was either initiated or relayed by a device. 7
8
Broadcast transaction table: This is a collection of broadcast transaction 9
records. 10
Cluster: This is an application message, which may be a container for one or 11
more attributes. As an example, the ZigBee Device Profile defines commands 12
and responses. These are contained in Clusters with the cluster identifiers 13
enumerated for each command and response. Each ZigBee Device Profile 14
message is then defined as a cluster. Alternatively, an application profile may 15
create sub-types within the cluster known as attributes. In this case, the cluster 16
is a collection of attributes specified to accompany a specific cluster identifier 17
(sub-type messages.) 18
19
Cluster identifier: This is a reference to an enumeration of clusters within a 20
specific application profile or collection of application profiles. The cluster 21
identifier is a 16-bit number unique within the scope of each application profile 22
and identifies a specific cluster. Conventions may be established across 23
application profiles for common definitions of cluster identifiers whereby each 24
application profile defines a set of cluster identifiers identically. Cluster 25
identifiers are designated as inputs or outputs in the simple descriptor for use in 26
creating a binding table. 27
Coordinator: This is an IEEE 802.15.4-2003 device responsible for 28
associating and disassociating devices into its PAN. A coordinator must be a 29
full function device (FFD). 30
31
Data integrity: This is assurance that the data has not been modified from its 32
original form. 33
Data key: This is a key derived from a link key used to protect data messages. 34
35
Device: This is any entity that contains an implementation of the ZigBee 36
protocol stack. 37
Device application: This is a special application that is responsible for Device 38
operation. The device application resides on endpoint 0 by convention and 39
contains logic to manage the device’s networking and general maintenance 40
features. 41
42
Device description: This is a description of a specific device within an 43
application profile. For example, the light sensor device description is a 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 1
10 ZigBee Protocol Overview

member of the home automation application profile. The device description


also has a unique identifier that is exchanged as part of the discovery process. 1
2
Direct addressing: This is a mode of addressing in which the destination of a 3
frame is completely specified in the frame itself. 4
Direct transmission: This is a frame transmission using direct addressing. 5
6
Disassociation: This is the service provided by the IEEE 802.15.4-2003 MAC 7
sub-layer that is used to discontinue the membership of a device in a network. 8
End application: This is for applications that reside on endpoints 1 through 9
240 on a Device. The end applications implement features that are non- 10
networking and ZigBee protocol related. 11
12
End device binding: This is the procedure for creating or removing a binding 13
link initiated by each of the end devices that will form the link. The procedure 14
may or may not involve user intervention. 15
Endpoint: This is a particular component within a unit. Each ZigBee device 16
may support up to 240 such components. 17
18
Endpoint address: This is the address assigned to an endpoint. This address is 19
assigned in addition to the unique, 64-bit IEEE address and 16-bit network 20
address. 21
Extended PAN ID: This is the globally unique 64-bit PAN identifier of the 22
network. This identifier should be unique among the PAN overlapping in a 23
given area. This identifier is used to avoid PAN ID conflicts between distinct 24
networks. 25
26
Information base: This is a collection of variables that define certain behavior 27
in a layer. These variables can be specified or obtained from a layer through its 28
management service. 29
Key establishment: This is a mechanism that involves the execution of a 30
protocol by two devices to derive a mutually shared secret key. 31
32
Key-load key: This is a key derived from a link key used to protect key 33
transport messages carrying a master key. 34
Key transport: This is a mechanism for communicating a key from one device 35
to another device or other devices. 36
37
Key-transport key: This is a key derived from a link key used to protect key 38
transport messages carrying a key other than a master key. 39
Key update: This is a mechanism implementing the replacement of a key 40
shared amongst two or more devices by means of another key available to that 41
same group. 42
43
Local device: This is the initiator of a ZDP command. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 11

Link key: This is a key that is shared exclusively between two, and only two,
peer application-layer entities within a PAN. 1
2
Master key: This is a shared key used during the execution of a symmetric-key 3
key establishment protocol. The master key is the basis for long-term security 4
between the two devices, and may be used to generate link keys. 5
Mesh network: This is a network in which the routing of messages is 6
performed as a decentralized, cooperative process involving many peer devices 7
routing on each other’s behalf. 8
9
Multicast: This is a transmission to every device in a particular PAN 10
belonging to a dynamically defined multicast group, and within a given 11
transmission radius measured in hops. 12
Multihop network: This is a network, in particular a wireless network, in 13
which there is no guarantee that the transmitter and the receiver of a given 14
message are connected or linked to each other. This implies that intermediate 15
devices must be used as routers. 16
17
Non-beacon-enabled personal area network: This is a personal area network 18
that does not contain any devices that transmit beacon frames at a regular 19
interval. 20
Neighbor table: This is a table used by a ZigBee device to keep track of other 21
devices within the POS. 22
23
Network address: This is the address assigned to a device by the network 24
layer and used by the network layer for routing messages between devices. 25
Network broadcast delivery time: This is the time required by a broadcast 26
transaction to reach every device of a given network. 27
28
Network manager: This is a ZigBee device that implements network 29
management functions as described in Clause 3, including PAN ID conflict 30
resolution and frequency agility measures in the face of interference. 31
Network protocol data unit: This is a unit of data that is exchanged between 32
the network layers of two peer entities. 33
34
Network service data unit: This is the information that is delivered as a unit 35
through a network service access point. 36
Node: This is a collection of independent device descriptions and applications 37
residing in a single unit and sharing a common 802.15.4 radio. 38
39
Normal operating state: This is the processing which occurs after all startup 40
and initialization processing has occurred and prior to initiation of shutdown 41
processing. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 1
12 ZigBee Protocol Overview

NULL: a parameter or variable value that means unspecified, undefined, or


unknown. The exact value of NULL is implementation-specific, and must not 1
conflict with any other parameters or values. 2
3
Octet: eight bits of data, used as a synonym for a byte. 4
One-way function: a function that is a much easier computation to perform 5
than its inverse. 6
7
Orphaned device: a device, typically a ZigBee end device, that has lost 8
communication with the ZigBee device through which it has its PAN 9
membership. 10
PAN coordinator: the principal controller of an IEEE 802.15.4-2003-based 11
network that is responsible for network formation. The PAN coordinator must 12
be a full function device (FFD). 13
14
PAN information base: a collection of variables in the IEEE 802.15.4-2003 15
standard that are passed between layers, in order to exchange information. This 16
database may include the access control list, which stores the security material. 17
Personal operating space: the area within reception range of a single device. 18
19
Private method: attributes and commands which are accessible to ZigBee 20
device objects only and unavailable to the end applications. 21
Protocol data unit: the unit of data that is exchanged between two peer 22
entities. 23
24
Public method: attributes and commands which are accessible to end 25
applications. 26
Radio: the IEEE 802.15.4-2003 radio that is part of every ZigBee device. 27
28
Remote device: the target of a ZDP command. 29
Route discovery: an operation in which a ZigBee coordinator or ZigBee router 30
attempts to discover a route to a remote device by issuing a route request 31
command frame. 32
33
Route discovery table: a table used by a ZigBee coordinator or ZigBee router 34
to store temporary information used during route discovery. 35
Route reply: a ZigBee network layer command frame used to reply to route 36
requests. 37
38
Route request: a ZigBee network layer command frame used to discover paths 39
through the network over which subsequent messages may be delivered. 40
Routing table: a table in which a ZigBee coordinator or ZigBee router stores 41
information required to participate in the routing of frames. 42
43
Service discovery: the ability of a device to locate services of interest. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 13

Stack profile: an agreement by convention outside the scope of the ZigBee


specification on a set of additional restrictions with respect to features declared 1
optional by the specification itself. 2
3
Symmetric-key key establishment: a mechanism by which two parties 4
establish a shared secret, based on a pre-shared secret (a so-called master key). 5
Trust center: the device trusted by devices within a ZigBee network to 6
distribute keys for the purpose of network and end-to-end application 7
configuration management. 8
9
Unicast: the transmission of a message to a single device in a network. 10
ZigBee coordinator: an IEEE 802.15.4-2003 PAN coordinator. 11
12
ZigBee device object: the portion of the application layer responsible for 13
defining the role of the device within the network (e.g., ZigBee coordinator or 14
end device), initiating and/or responding to binding and discovery requests, and 15
establishing a secure relationship between network devices. 16
ZigBee end device: an IEEE 802.15.4-2003 RFD or FFD participating in a 17
ZigBee network, which is neither the ZigBee coordinator nor a ZigBee router. 18
19
ZigBee router: an IEEE 802.15.4-2003 FFD participating in a ZigBee 20
network, which is not the ZigBee coordinator but may act as an IEEE 802.15.4- 21
2003 coordinator within its personal operating space, that is capable of routing 22
messages between devices and supporting associations. 23
24
25
1.5 References 26
27
The following standards contain provisions, which, through reference in this 28
document, constitute provisions of this standard. Normative references are given 29
in “ZigBee/IEEE References,” and “Normative References,” and informative 30
references are given in “Informative References.” At the time of publication, the 31
editions indicated were valid. All standards are subject to revision, and parties to 32
agreements based on this standard are encouraged to investigate the possibility of 33
applying the most recent editions of the references, as indicated in this sub-clause. 34
35
1.5.1 ZigBee/IEEE References 36
37
[B1] Institute of Electrical and Electronics Engineers, Inc., IEEE Std. 802.15.4- 38
2003, IEEE Standard for Information Technology — Telecommunications and 39
Information Exchange between Systems — Local and Metropolitan Area 40
Networks — Specific Requirements — Part 15.4: Wireless Medium Access 41
Control (MAC) and Physical Layer (PHY) Specifications for Low Rate 42
Wireless Personal Area Networks (WPANs). New York: IEEE Press. 2003. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 1
14 ZigBee Protocol Overview

[B2] IEEE 754-1985, IEEE Standard for Binary Floating-Point Arithmetic,


IEEE, 1985. 1
2
[B3] Document 03285r0: Suggestions for the Improvement of the IEEE 3
802.15.4 Standard, July 2003. 4
[B4] Document 02055r4: Network Requirements Definition, August 2003. 5
6
7
1.5.2 Normative References 8
9
[B5] ISO/IEC 639-1:2002 Codes for the representation of names of languages 10
— Part 1: Alpha-2 code. 11
[B6] ISO/IEC 646:199 Information technology — ISO 7-bit coded character 12
set for information interchange. 13
14
[B7] ANSI X9.63-2001, Public Key Cryptography for the Financial Services 15
Industry - Key Agreement and Key Transport Using Elliptic Curve 16
Cryptography, American Bankers Association, November 20, 2001. Available 17
from http://www.ansi.org. 18
[B8] FIPS Pub 197, Advanced Encryption Standard (AES), Federal 19
Information Processing Standards Publication 197, US Department of 20
Commerce/N.I.S.T, Springfield, Virginia, November 26, 2001. Available from 21
http://csrc.nist.gov/. 22
23
[B9] FIPS Pub 198, The Keyed-Hash Message Authentication Code (HMAC), 24
Federal Information Processing Standards Publication 198, US Department of 25
Commerce/N.I.S.T., Springfield, Virginia, March 6, 2002. Available from 26
http://csrc.nist.gov/. 27
[B10] ISO/IEC 9798-2, Information Technology - Security Techniques — 28
Entity Authentication Mechanisms — Part 2: Mechanisms Using Symmetric 29
Encipherment Algorithms, International Standardization Organization, 30
Geneva, Switzerland, 1994 (first edition). Available from http://www.iso.org/. 31
32
[B11] NIST Pub 800-38A 2001 ED, Recommendation for Block Cipher Modes 33
of Operation — Methods and Techniques, NIST Special Publication 800-38A, 34
2001 Edition, US Department of Commerce/N.I.S.T., December 2001. 35
Available from http://csrc.nist.gov/. 36
[B12] NIST, Random Number Generation and Testing. Available from http:// 37
csrc.nist.gov/rng/. 38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 15

1.5.3 Informative References 1


2
[B13] FIPS Pub 140-2, Security requirements for Cryptographic Modules, US
3
Department of Commerce/N.I.S.T., Springfield, Virginia, June 2001
4
(supersedes FIPS Pub 140-1). Available from http://csrc.nist.gov/.
5
[B14] IEEE Standards Style Manual, published and distributed in May 2000 6
and revised on September 20, 2001. Available from http://standards.ieee.org/ 7
guides/style/. 8
9
[B15] ISO/IEC 7498-1:1994 Information technology — Open systems
10
interconnection — Basic reference model: The basic model.
11
[B16] ISO/IEC 10731:1994, Information technology — Open Systems 12
Interconnection — Conventions for the definition of OSI services. 13
14
[B17] ISO/IEC 9646-1:1991, Information technology — Open systems
15
Interconnection — Conformance testing methodology and framework — Part
16
1: General concepts.
17
[B18] ISO/IEC 9646-7:1995, Information technology — Open Systems 18
Interconnection — Conformance testing methodology and framework — Part 19
7. Implementation conformance statements. 20
21
[B19] A.J. Menezes, P.C. van Oorschot, S.A. Vanstone, Handbook of Applied
22
Cryptography, Boca Raton: CRC Press, 1997.
23
[B20] FIPS Pub 113, Computer Data Authentication, Federal Information 24
Processing Standard Publication 113, US Department of Commerce/N.I.S.T., 25
May 30, 1985. Available from http://csrc.nist.gov/. 26
27
[B21] R. Housley, D. Whiting, N. Ferguson, Counter with CBC-MAC (CCM),
28
submitted to N.I.S.T., June 3, 2002. Available from http://csrc.nist.gov/
29
encryption/modules/proposedmodes/.
30
[B22] J. Jonsson, On the Security of CTR + CBC-MAC, in Proceedings of 31
Selected Areas in Cryptography — SAC 2002, K. Nyberg, H. Heys, Eds., 32
Lecture Notes in Computer Science, Vol. 2595, pp. 76-93, Berlin: Springer, 33
2002. 34
35
[B23] J. Jonsson, On the Security of CTR + CBC-MAC, NIST Mode of
36
Operation — Additional CCM Documentation. Available from http://
37
csrc.nist.gov/encryption/modes/proposedmodes/.
38
[B24] P. Rogaway, D. Wagner, A Critique of CCM, IACR ePrint Archive 39
2003-070, April 13, 2003. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 1
16 ZigBee Protocol Overview

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
This page intentionally blank 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 17

C H A P T E R
1

2
2
3
4
5
6
7
8
9

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
27
2.1.1 Application Support Sub-Layer 28
29
The application support sub-layer (APS) provides an interface between the 30
network layer (NWK) and the application layer (APL) through a general set of 31
services that are used by both the ZDO and the manufacturer-defined application 32
objects. The services are provided by two entities: 33
34
• The APS data entity (APSDE) through the APSDE service access point 35
(APSDE-SAP). 36
• The APS management entity (APSME) through the APSME service access 37
point (APSME-SAP). 38
39
The APSDE provides the data transmission service between two or more 40
application entities located on the same network. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
18 Application Layer Specification

The APSME provides a variety of services to application objects including


security services and binding of devices. It also maintains a database of managed 1
objects, known as the APS information base (AIB). 2
3
4
2.1.2 Application Framework 5
6
The application framework in ZigBee is the environment in which application 7
objects are hosted on ZigBee devices. 8
Up to 240 distinct application objects can be defined, each identified by an 9
endpoint address from 1 to 240. Two additional endpoints are defined for APSDE- 10
SAP usage: endpoint 0 is reserved for the data interface to the ZDO, and endpoint 11
255 is reserved for the data interface function to broadcast data to all application 12
objects. Endpoints 241-254 are reserved for future use. 13
14
2.1.2.1 Application Profiles 15
16
Application profiles are agreements for messages, message formats, and 17
processing actions that enable developers to create an interoperable, distributed 18
application employing application entities that reside on separate devices. These 19
application profiles enable applications to send commands, request data, and 20
process commands and requests. 21
22
2.1.2.2 Clusters 23
Clusters are identified by a cluster identifier, which is associated with data 24
flowing out of, or into, the device. Cluster identifiers are unique within the scope 25
of a particular application profile. 26
27
28
2.1.3 ZigBee Device Objects 29
30
The ZigBee device objects (ZDO), represent a base class of functionality that 31
provides an interface between the application objects, the device profile, and the 32
APS. The ZDO is located between the application framework and the application 33
support sub-layer. It satisfies common requirements of all applications operating 34
in a ZigBee protocol stack. The ZDO is responsible for the following: 35
• Initializing the application support sub-layer (APS), the network layer (NWK), 36
and the Security Service Provider. 37
38
• Assembling configuration information from the end applications to determine 39
and implement discovery, security management, network management, and 40
binding management. 41
The ZDO presents public interfaces to the application objects in the application 42
framework layer for control of device and network functions by the application 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 19

objects. The ZDO interfaces with the lower portions of the ZigBee protocol stack,
on endpoint 0, through the APSDE-SAP for data, and through the APSME-SAP 1
and NLME-SAP for control messages. The public interface provides address 2
management of the device, discovery, binding, and security functions within the 3
application framework layer of the ZigBee protocol stack. The ZDO is fully 4
described in clause 2.5. 5
6
2.1.3.1 Device Discovery 7
8
Device discovery is the process whereby a ZigBee device can discover other 9
ZigBee devices. There are two forms of device discovery requests: IEEE address 10
requests and NWK address requests. The IEEE address request is unicast to a 11
particular device and assumes the NWK address is known. The NWK address 12
request is broadcast and carries the known IEEE address as data payload. 13
14
2.1.3.2 Service Discovery 15
Service discovery is the process whereby the capabilities of a given device are 16
discovered by other devices. Service discovery can be accomplished by issuing a 17
query for each endpoint on a given device or by using a match service feature 18
(either broadcast or unicast). The service discovery facility defines and utilizes 19
various descriptors to outline the capabilities of a device. 20
21
Service discovery information may also be cached in the network in the case 22
where the device proffering a particular service may be inaccessible at the time 23
the discovery operation takes place. 24
25
26
2.2 ZigBee Application Support (APS) Sub-Layer 27
28
29
2.2.1 Scope 30
31
This clause specifies the portion of the application layer providing the service 32
specification and interface to both the manufacturer-defined application objects 33
and the ZigBee device objects. The specification defines a data service to allow 34
the application objects to transport data, and a management service providing 35
mechanisms for binding. In addition, it also defines the application support sub- 36
layer frame format and frame-type specifications. 37
38
2.2.2 Purpose 39
40
The purpose of this clause is to define the functionality of the ZigBee application 41
support (APS) sub-layer. This functionality is based on both the driver 42
functionality necessary to enable correct operation of the ZigBee network layer 43
and the functionality required by the manufacturer-defined application objects. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
20 Application Layer Specification

2.2.3 Application Support (APS) Sub-Layer Overview 1


2
The application support sub-layer provides the interface between the network
3
layer and the application layer through a general set of services for use by both the
4
ZigBee device object (ZDO) and the manufacturer-defined application objects.
5
These services are offered via two entities: the data service and the management
6
service. The APS data entity (APSDE) provides the data transmission service via
7
its associated SAP, the APSDE-SAP. The APS management entity (APSME)
8
provides the management service via its associated SAP, the APSME-SAP, and
9
maintains a database of managed objects known as the APS information base
10
(AIB).
11
2.2.3.1 Application Support Sub-Layer Data Entity (APSDE) 12
13
The APSDE shall provide a data service to the network layer and both ZDO and 14
application objects to enable the transport of application PDUs between two or 15
more devices. The devices themselves must be located on the same network. 16
17
The APSDE will provide the following services: 18
• Generation of the application level PDU (APDU): the APSDE shall take an 19
application PDU and generate an APS PDU by adding the appropriate protocol 20
overhead. 21
22
• Binding: once two devices are bound, the APSDE shall be able to transfer a 23
message from one bound device to the second device. 24
• Group address filtering: this provides the ability to filter group-addressed 25
messages based on endpoint group membership. 26
27
• Reliable transport: this increases the reliability of transactions above that 28
available from the NWK layer alone by employing end-to-end retries. 29
• Duplicate rejection: messages offered for transmission will not be received 30
more than once. 31
32
• Fragmentation: this enables segmentation and reassembly of messages longer 33
than the payload of a single NWK layer frame. 34
35
2.2.3.2 Application Support Sub-Layer Management Entity 36
(APSME) 37
The APSME shall provide a management service to allow an application to 38
interact with the stack. 39
40
The APSME shall provide the ability to match two devices together based on their 41
services and their needs. This service is called the binding service, and the 42
APSME shall be able to construct and maintain a table to store this information. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 21

In addition, the APSME will provide the following services:


1
• Binding management: this is the ability to match two devices together based 2
on their services and their needs. 3
• AIB management: the ability to get and set attributes in the device’s AIB. 4
5
• Security: the ability to set up authentic relationships with other devices 6
through the use of secure keys. 7
• Group management: this provides the ability to declare a single address 8
shared by multiple devices, to add devices to the group, and to remove devices 9
from the group. 10
11
12
2.2.4 Service Specification 13
14
The APS sub-layer provides an interface between a next higher layer entity 15
(NHLE) and the NWK layer. The APS sub-layer conceptually includes a 16
management entity called the APS sub-layer management entity (APSME). This 17
entity provides the service interfaces through which sub-layer management 18
functions may be invoked. The APSME is also responsible for maintaining a 19
database of managed objects pertaining to the APS sub-layer. This database is 20
referred to as the APS sub-layer information base (AIB). Figure 2.1 depicts the 21
components and interfaces of the APS sub-layer. 22
23
24
Next Higher Layer Entity 25
26
27
APSDE-SAP APSME-SAP 28
29
30
APSME 31
APSDE 32
APS 33
IB 34
35
NLDE-SAP NLME-SAP 36
37
38
NWK Layer Entity 39
40
41
Figure 2.1 The APS Sub-Layer Reference Model 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
22 Application Layer Specification

The APS sub-layer provides two services, accessed through two service access
points (SAPs). These are the APS data service, accessed through the APS sub- 1
layer data entity SAP (APSDE-SAP), and the APS management service, accessed 2
though the APS sub-layer management entity SAP (APSME-SAP). These two 3
services provide the interface between the NHLE and the NWK layer, via the 4
NLDE-SAP and, to a limited extent, NLME-SAP interfaces (see sub-clause 3.1). 5
The NLME-SAP interface between the NWK layer and the APS sub-layer 6
supports only the NLME-GET and NLME-SET primitives; all other NLME-SAP 7
primitives are available only via the ZDO (see sub-clause 2.5). In addition to these 8
external interfaces, there is also an implicit interface between the APSME and the 9
APSDE that allows the APSME to use the APS data service. 10
11
2.2.4.1 APS Data Service 12
13
The APS sub-layer data entity SAP (APSDE-SAP) supports the transport of 14
application protocol data units between peer application entities. Table 2.1 lists 15
the primitives supported by the APSDE-SAP. Each of these primitives will be 16
discussed in the following sub-clauses. 17
Table 2.1 APSDE-SAP Primitives 18
19
APSDE- 20
SAP
Primitive Request Confirm Indication 21
22
APSDE- 2.2.4.1.1 2.2.4.1.2 2.2.4.1.3 23
DATA 24
25
2.2.4.1.1 APSDE-DATA.request 26
27
This primitive requests the transfer of a NHLE PDU (ASDU) from the local 28
NHLE to one or more peer NHLE entities. 29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 23

2.2.4.1.1.1 Semantics of the Service Primitive


1
The semantics of this primitive are as follows: 2
APSDE-DATA.request {
3
4
DstAddrMode,
5
DstAddress,
6
DstEndpoint, 7
ProfileId, 8
ClusterId, 9
SrcEndpoint, 10
ADSULength, 11
ADSU, 12
TxOptions, 13
RadiusCounter 14
} 15
16
17
Table 2.2 specifies the parameters for the APSDE-DATA.request primitive. 18
Table 2.2 APSDE-DATA.request Parameters 19
20
Name Type Valid Range Description
21
DstAddrMode Integer 0x00 – 0xff The addressing mode for the destination 22
address used in this primitive and of the 23
APDU to be transferred. This parameter can 24
take one of the non-reserved values from the
following list: 25
26
0x00 = DstAddress and DstEndpoint not 27
present
28
0x01 = 16-bit group address for DstAddress;
29
DstEndpoint not present
30
0x02 = 16-bit address for DstAddress and
DstEndpoint present 31
32
0x03 = 64-bit extended address for
DstAddress and DstEndpoint present 33
0x04 – 0xff = reserved 34
35
DstAddress Address As specified by The individual device address or group 36
the DstAddrMode address of the entity to which the ASDU is
parameter being transferred. 37
38
DstEndpoint Integer 0x00 – 0xf0, 0xff This parameter shall be present if, and only 39
if, the DstAddrMode parameter has a value
of 0x02 or 0x03 and, if present, shall be
40
either the number of the individual endpoint 41
of the entity to which the ASDU is being 42
transferred or the broadcast endpoint (0xff). 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
24 Application Layer Specification

Table 2.2 APSDE-DATA.request Parameters


1
Name Type Valid Range Description 2
ProfileId Integer 0x0000 – 0xffff The identifier of the profile for which this 3
frame is intended. 4
5
ClusterId Integer 0x0000 – 0xffff The identifier of the object for which this
frame is intended. 6
7
SrcEndpoint Integer 0x00 – 0xf0 The individual endpoint of the entity from
8
which the ASDU is being transferred.
9
ADSULength Integer 0x00 - The number of octets comprising the ASDU 10
256*(NsduLengt to be transferred. The maximum length of an 11
h- individual APS frame payload is given as
apscMinHeader NsduLength-apscMinHeaderOverhead. 12
Overhead) Assuming fragmentation is used, there can be 13
256 such blocks comprising a single 14
maximum sized ASDU. 15
Asdu Set of - The set of octets comprising the ASDU to be 16
octets transferred. 17
TxOptions Bitmap 0000 xxxx The transmission options for the ASDU to be 18
transferred. These are a bitwise OR of one or 19
(Where x can be 0 more of the following: 20
or 1) 21
0x01 = Security enabled transmission
22
0x02 = Use NWK key
23
0x04 = Acknowledged transmission
24
0x08 = Fragmentation permitted
25
Radius Unsigned 0x00-0xff The distance, in hops, that a transmitted 26
integer frame will be allowed to travel through the 27
network. 28
29
2.2.4.1.1.2 When Generated 30
31
This primitive is generated by a local NHLE whenever a data PDU (ASDU) is to
32
be transferred to one or more peer NHLEs.
33
34
2.2.4.1.1.3 Effect on Receipt 35
On receipt of this primitive, the APS sub-layer entity begins the transmission of 36
the supplied ASDU. 37
38
If the DstAddrMode parameter is set to 0x00 and this primitive was received by 39
the APSDE of a device supporting a binding table, a search is made in the binding 40
table with the endpoint and cluster identifiers specified in the SrcEndpoint and 41
ClusterId parameters, respectively, for associated binding table entries. If no 42
binding table entries are found, the APSDE issues the APSDE-DATA.confirm 43
primitive with a status of NO_BOUND_DEVICE. If one or more binding table 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 25

entries are found, then the APSDE examines the destination address information
in each binding table entry. If this indicates a device itself, then the APSDE shall 1
issue an APSDE-DATA.indication primitive to the next higher layer with the 2
DstEndpoint parameter set to the destination endpoint identifier in the binding 3
table entry. Otherwise, the APSDE constructs the APDU with the endpoint 4
information from the binding table entry, if present, and uses the destination 5
address information from the binding table entry when transmitting the frame via 6
the NWK layer. If more than one binding table entry is present, then the APSDE 7
processes each binding table entry as described above; until no more binding table 8
entries remain. If this primitive was received by the APSDE of a device that does 9
not support a binding table, the APSDE issues the APSDE-DATA.confirm 10
primitive with a status of NOT_SUPPORTED. 11
12
If the DstAddrMode parameter is set to 0x03, the DstAddress parameter contains 13
an extended 64-bit IEEE address and must first be mapped to a corresponding 16- 14
bit NWK address by using the nwkAddressMap attribute of the NIB (see 15
Table 3.43). If a corresponding 16-bit NWK address could not be found, the 16
APSDE issues the APSDE-DATA.confirm primitive with a status of 17
NO_SHORT_ADDRESS. If a corresponding 16-bit NWK address is found, it will 18
be used in the invocation of the NLDE-DATA.request primitive and the value of 19
the DstEndpoint parameter will be placed in the resulting APDU. The delivery 20
mode sub-field of the frame control field of the APS header shall have a value of 21
0x00 in this case. 22
If the DstAddrMode parameter has a value of 0x01, indicating group addressing, 23
the DstAddress parameter will be interpreted as a 16-bit group address. This 24
address will be placed in the group address field of the APS header, the 25
DstEndpoint parameter will be ignored, and the destination endpoint field will be 26
omitted from the APS header. The delivery mode sub-field of the frame control 27
field of the APS header shall have a value of 0x03 in this case. 28
29
If the DstAddrMode parameter is set to 0x02, the DstAddress parameter contains 30
a 16-bit NWK address, and the DstEndpoint parameter is supplied. The next 31
higher layer should only employ DstAddrMode of 0x02 in cases where the 32
destination NWK address is employed for immediate application responses and 33
the NWK address is not retained for later data transmission requests. 34
The application may limit the number of hops a transmitted frame is allowed to 35
travel through the network by setting the RadiusCounter parameter of the NLDE- 36
DATA.request primitive to a non-zero value. 37
38
If the DstAddrMode parameter has a value of 0x01, indicating group addressing, 39
or the DstAddrMode parameter has a value of 0x00 and the corresponding binding 40
table entry contains a group address, then the APSME will check the value of the 41
nwkUseMulticast attribute of the NIB (see Table 3.44). If this attribute has a value 42
of FALSE, then the delivery mode sub-field of the frame control field of the 43
resulting APDU will be set to 0b11, the 16-bit address of the destination group 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
26 Application Layer Specification

will be placed in the group address field of the APS header of the outgoing frame,
and the NSDU frame will be transmitted as a broadcast. A value of 0xfffd, that is, 1
the broadcast to all devices for which macRxOnWhenIdle = TRUE, will be 2
supplied for the DstAddr parameter of the NLDE-DATA.request that is used to 3
transmit the frame. If the nwkUseMulticast attribute has a value of TRUE, then the 4
outgoing frame will be transmitted using NWK layer multicast, with the delivery 5
mode sub-field of the frame control field of the APDU set to 0b10, the destination 6
endpoint field set to 0xff, and the group address not placed in the APS header. 7
8
If the TxOptions parameter specifies that secured transmission is required, the 9
APS sub-layer shall use the security service provider (see sub-clause 4.2.3) to 10
secure the ASDU. If the security processing fails, the APSDE shall issue the 11
APSDE-DATA.confirm primitive with a status of SECURITY_FAIL. 12
The APSDE transmits the constructed frame by issuing the NLDE-DATA.request 13
primitive to the NWK layer. When the APSDE has completed all operations 14
related to this transmission request, including transmitting frames as required, any 15
retransmissions, and the receipt or timeout of any acknowledgements, then the 16
APSDE shall issue the APSDE-DATA.confirm primitive (see sub- 17
clause 2.2.4.1.2). If one or more NLDE-DATA.confirm primitives failed, then the 18
Status parameter shall be set to that received from the NWK layer. Otherwise, if 19
one or more APS acknowledgements were not correctly received, then the Status 20
parameter shall be set to NO_ACK. If the ASDU was successfully transferred to 21
all intended targets, then the Status parameter shall be set to SUCCESS. 22
23
If NWK layer multicast is being used, the NonmemberRadius parameter of the 24
NLDE-DATA.request primitive shall be set to apsNonmemberRadius. 25
The APSDE will ensure that route discovery is always enabled at the network 26
layer by setting the DiscoverRoute parameter of the NLDE-DATA.request 27
primitive to 0x01, each time it is issued. 28
29
If the ASDU to be transmitted is larger than will fit in a single frame and 30
fragmentation is not possible, then the ASDU is not transmitted and the APSDE 31
shall issue the APSDE-DATA.confirm primitive with a status of 32
ASDU_TOO_LONG. Fragmentation is not possible if either an acknowledged 33
transmission is not requested, or if the fragmentation permitted flag in the 34
TxOptions field is set to 0, or if the ASDU is too large to be handled by the 35
APSDE. 36
If the ASDU to be transmitted is larger than will fit in a single frame, an 37
acknowledged transmission is requested, and the fragmentation permitted flag of 38
the TxOptions field is set to 1, and the ASDU is not too large to be handled by the 39
APSDE, then the ASDU shall be fragmented across multiple APDUs, as 40
described in sub-clause 2.2.8.4.5. Transmission and security processing where 41
requested, shall be carried out for each individual APDU independently. Note that 42
fragmentation shall not be used unless relevant higher-layer documentation and/or 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 27

interactions explicitly indicate that fragmentation is permitted for the frame being
sent, and that the other end is able to receive the fragmented transmission, both in 1
terms of number of blocks and total transmission size. 2
3
2.2.4.1.2 APSDE-DATA.confirm 4
The primitive reports the results of a request to transfer a data PDU (ASDU) from 5
a local NHLE to one or more peer NHLEs. 6
7
2.2.4.1.2.1 Semantics of the Service Primitive 8
9
This semantics of this primitive are as follows: 10
11
APSDE-DATA.confirm {
12
DstAddrMode, 13
DstAddress, 14
DstEndpoint, 15
SrcEndpoint, 16
Status, 17
TxTime 18
} 19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
28 Application Layer Specification

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


1
Table 2.3 APSDE-DATA.confirm Parameters
2
Name Type Valid Range Description 3
4
DstAddrMode Integer 0x00 – 0xff The addressing mode for the 5
destination 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; 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
0x04 – 0xff = reserved 20
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 – 0xf0, 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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 29

Table 2.3 APSDE-DATA.confirm Parameters


1
SrcEndpoint Integer 0x00 – 0xf0 The individual endpoint of the
entity from which the ASDU is
2
being transferred. 3
4
Status Enumerati SUCCESS, The status of the corresponding
5
on NO_SHORT_ADDRESS, request.
NO_BOUND_DEVICE, 6
SECURITY_FAIL, 7
NO_ACK, 8
ADSU_TOO_LONG or 9
any status values returned
10
from the NLDE-
DATA.confirm primitive 11
12
TxTime Integer Implementation specific A time indication for the
13
transmitted packet based on the
local clock, as provided by the 14
NWK layer. 15
16
2.2.4.1.2.2 When Generated 17
18
This primitive is generated by the local APS sub-layer entity in response to an 19
APSDE-DATA.request primitive. This primitive returns a status of either 20
SUCCESS, indicating that the request to transmit was successful, or an error code 21
of NO_SHORT_ADDRESS, NO_BOUND_DEVICE, SECURITY_FAIL, 22
ASDU_TOO_LONG, or any status values returned from the NLDE- 23
DATA.confirm primitive. The reasons for these status values are fully described 24
in 2.2.4.1.1.3. 25
26
2.2.4.1.2.3 Effect on Receipt 27
28
On receipt of this primitive, the next higher layer of the initiating device is 29
notified of the result of its request to transmit. If the transmission attempt was 30
successful, the Status parameter will be set to SUCCESS. Otherwise, the Status 31
parameter will indicate the error. 32
2.2.4.1.3 APSDE-DATA.indication 33
34
This primitive indicates the transfer of a data PDU (ASDU) from the APS sub- 35
layer to the local application entity. 36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
30 Application Layer Specification

2.2.4.1.3.1 Semantics of the Service Primitive


1
The semantics of this primitive are as follows: 2
APSDE-DATA.indication {
3
4
DstAddrMode,
5
DstAddress,
6
DstEndpoint, 7
SrcAddrMode, 8
SrcAddress, 9
SrcEndpoint, 10
ProfileId, 11
ClusterId, 12
asduLength, 13
asdu, 14
Status, 15
SecurityStatus,
16
17
LinkQuality,
18
RxTime
19
} 20
21
Table 2.4 specifies the parameters for the APSDE-DATA.indication primitive. 22
Table 2.4 APSDE-DATA.indication Parameters 23
24
Name Type Valid Range Description 25
DstAddrMode Integer 0x00 - 0xff The addressing mode for the destination 26
address used in this primitive and of the 27
APDU that has been received. This 28
parameter can take one of the non- 29
reserved values from the following list: 30
0x00 = reserved 31
0x01 = 16-bit group address for 32
DstAddress; DstEndpoint not present 33
0x02 = 16-bit address for DstAddress and 34
DstEndpoint present 35
0x03 – 0xff = reserved 36
DstAddress Address As specified by The individual device address or group 37
the DstAddrMode address to which the ASDU is directed. 38
parameter 39
DstEndpoint Integer 0x00 – 0xf0 The target endpoint on the local entity to 40
which the ASDU is directed. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 31

Table 2.4 APSDE-DATA.indication Parameters


1
Name Type Valid Range Description 2
SrcAddrMode Integer 0x00 – 0xff The addressing mode for the source 3
address used in this primitive and of the 4
APDU that has been received. This 5
parameter can take one of the non- 6
reserved values from the following list:
7
0x00 = reserved 8
0x01 = reserved 9
0x02 = 16-bit short address for 10
SrcAddress and SrcEndpoint present 11
0x03 = 64-bit extended address for 12
SrcAddress and SrcEndpoint present 13
0x04 – 0xff = reserved 14
SrcAddress Address As specified by The individual device address of the 15
the SrcAddrMode entity from which the ASDU has been 16
parameter received. 17
SrcEndpoint Integer 0x00 – 0xf0 The number of the individual endpoint of 18
the entity from which the ASDU has been 19
received. 20
ProfileId Integer 0x0000 - 0xffff The identifier of the profile from which 21
this frame originated. 22
23
ClusterId Integer 0x0000-0xffff The identifier of the received object.
24
asduLength Integer The number of octets comprising the 25
ASDU being indicated by the APSDE. 26
asdu Set of octets - The set of octets comprising the ASDU 27
being indicated by the APSDE. 28
Status Enumeration SUCCESS, The status of the incoming frame 29
DEFRAG_UNSU processing. 30
PPORTED, 31
DEFRAG_DEFE 32
RRED or any
status returned
33
from the security 34
processing of the 35
frame 36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
32 Application Layer Specification

Table 2.4 APSDE-DATA.indication Parameters


1
Name Type Valid Range Description 2
SecurityStatus Enumeration UNSECURED, UNSECURED if the ASDU was received 3
SECURED_NW without any security. 4
K_KEY, 5
SECURED_LIN SECURED_NWK_KEY if the received
ASDU was secured with the NWK key. 6
K_KEY
7
SECURED_LINK_KEY if the ASDU
was secured with a link key.
8
9
LinkQuality Integer 0x00 - 0xff The link quality indication 10
delivered by the NLDE. 11
RxTime Integer Implementation A time indication for the received packet 12
specific based on the local clock, as provided by 13
14
the NWK layer.
15
16
2.2.4.1.3.2 When Generated 17
This primitive is generated by the APS sub-layer and issued to the next higher 18
layer on receipt of an appropriately addressed data frame from the local NWK 19
layer entity or following receipt of an APSDE-DATA.request in which the 20
DstAddrMode parameter was set to 0x00 and the binding table entry has directed 21
the frame to the device itself. If the frame control field of the ASDU header 22
indicates that the frame is secured, security processing shall be done as specified 23
in sub-clause 4.2.3. 24
25
This primitive is generated by the APS sub-layer entity and issued to the next 26
higher layer entity on receipt of an appropriately addressed data frame from the 27
local network layer entity, via the NLDE-DATA.indication primitive. 28
If the frame control field of the APDU header indicates that the frame is secured, 29
then security processing must be undertaken as specified in sub-clause 4.2.3. If 30
the security processing fails, the APSDE sets the status parameter to the security 31
error code returned from the security processing. 32
33
If the frame is not secured or the security processing was successful, the APSDE 34
must check for the frame being fragmented. If the extended header is included in 35
the APDU header and the fragmentation sub-field of the extended frame control 36
field indicates that the frame is fragmented but this device does not support 37
fragmentation, the APSDE sets the status parameter to DEFRAG_- 38
UNSUPPORTED. If the extended header is included in the APDU header, the 39
fragmentation sub-field of the extended frame control field indicates that the 40
frame is fragmented and the device supports fragmentation, but is not currently 41
able to defragment the frame, the APSDE sets the status parameter to DEFRAG_- 42
DEFERRED. 43
Under all other circumstances, the APSDE sets the status parameter to SUCCESS. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 33

If the Status parameter is not set to SUCCESS, the APSDE sets the ASDULength
parameter to 0 and the ASDU parameter to the null set of bytes. 1
2
The APS sub-layer entity shall attempt to map the source address from the 3
received frame to its corresponding extended 64-bit IEEE address by using the 4
nwkAddressMap attribute of the NIB (see Table 3.43). If a corresponding 64-bit 5
IEEE address was found, the APSDE issues this primitive with the SrcAddrMode 6
parameter set to 0x03 and the SrcAddress parameter set to the corresponding 64- 7
bit IEEE address. If a corresponding 64-bit IEEE address was not found, the 8
APSDE issues this primitive with the SrcAddrMode parameter set to 0x02, and 9
the SrcAddress parameter set to the 16-bit source address as contained in the 10
received frame. 11
12
2.2.4.1.3.3 Effect on Receipt 13
On receipt of this primitive, the next higher layer is notified of the arrival of data 14
at the device. 15
16
2.2.4.2 APS Management Service 17
18
The APS management entity SAP (APSME-SAP) supports the transport of 19
management commands between the next higher layer and the APSME. Table 2.5 20
summarizes the primitives supported by the APSME through the APSME-SAP 21
interface. See the following sub-clauses for more details on the individual 22
primitives. 23
Table 2.5 Summary of the Primitives Accessed Through the APSME-SAP 24
25
Name Request Indication Response Confirm 26
APSME-BIND 2.2.4.3.1 2.2.4.3.2
27
28
APSME-UNBIND 2.2.4.3.3 2.2.4.3.4 29
APSME-GET 2.2.4.4.1 2.2.4.4.2 30
31
APSME-SET 2.2.4.4.3 2.2.4.4.4
32
APSME-ADD-GROUP 2.2.4.5.1 2.2.4.5.2 33
APSME-REMOVE- 2.2.4.5.3 2.2.4.5.4 34
GROUP 35
APSME-REMOVE- 2.2.4.5.5 2.2.4.5.6
36
ALL-GROUPS 37
38
39
2.2.4.3 Binding Primitives 40
This set of primitives defines how the next higher layer of a device can add 41
(commit) a binding record to its local binding table or remove a binding record 42
from its local binding table. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
34 Application Layer Specification

Only a device supporting a binding table or a binding table cache may process
these primitives. If any other device receives these primitives from their next 1
higher layer, the primitives should be rejected. 2
3
2.2.4.3.1 APSME-BIND.request 4
This primitive allows the next higher layer to request to bind two devices together, 5
or to bind a device to a group, by creating an entry in its local binding table, if 6
supported. 7
8
2.2.4.3.1.1 Semantics of the Service Primitive 9
10
The semantics of this primitive are as follows: 11
12
APSME-BIND.request {
13
SrcAddr, 14
SrcEndpoint, 15
ClusterId, 16
DstAddrMode, 17
DstAddr, 18
DstEndpoint 19
} 20
21
Table 2.6 specifies the parameters for the APSME-BIND.request primitive. 22
23
Table 2.6 APSME-BIND.request Parameters 24
Name Type Valid Range Description 25
26
SrcAddr IEEE A valid 64-bit The source IEEE address for the binding 27
address IEEE address entry. 28
SrcEndpoint Integer 0x01 – 0xf0 The source endpoint for the binding entry. 29
ClusterId Integer 0x0000 – 0xffff The identifier of the cluster on the source
30
device that is to be bound to the destination 31
device. 32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 35

Table 2.6 APSME-BIND.request Parameters


1
DstAddrMode Integer 0x00 – 0xff The addressing mode for the destination
address used in this primitive. This parameter
2
can take one of the non-reserved values from 3
the following list: 4
0x00 = reserved
5
6
0x01 = 16-bit group address for DstAddr and
DstEndpoint not present 7
0x02 = reserved
8
9
0x03 = 64-bit extended address for DstAddr
and DstEndpoint present 10
0x04 – 0xff = reserved
11
12
DstAddr Address As specified by The destination address for the binding entry. 13
the DstAddrMode
14
parameter
15
DstEndpoint Integer 0x01 – 0xf0, 0xff This parameter will be present only if the 16
DstAddrMode parameter has a value of 0x03
17
and, if present, will be the destination
endpoint for the binding entry. 18
19
20
2.2.4.3.1.2 When Generated
21
This primitive is generated by the next higher layer and issued to the APS sub- 22
layer in order to instigate a binding operation on a device that supports a binding 23
table. 24
25
2.2.4.3.1.3 Effect on Receipt 26
27
On receipt of this primitive by a device that is not currently joined to a network, or 28
by a device that does not support a binding table, or if any of the parameters has a 29
value which is out of range, the APSME issues the APSME-BIND.confirm 30
primitive with the Status parameter set to ILLEGAL_REQUEST. 31
If the APS sub-layer on a device that supports a binding table receives this 32
primitive from the NHLE, the APSME attempts to create the specified entry 33
directly in its binding table. If the entry could be created, the APSME issues the 34
APSME-BIND.confirm primitive with the Status parameter set to SUCCESS. If 35
the entry could not be created due to a lack of capacity in the binding table, the 36
APSME issues the APSME-BIND.confirm primitive with the Status parameter set 37
to TABLE_FULL. 38
39
2.2.4.3.2 APSME-BIND.confirm 40
This primitive allows the next higher layer to be notified of the results of its 41
request to bind two devices together, or to bind a device to a group. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
36 Application Layer Specification

2.2.4.3.2.1 Semantics of the Service Primitive


1
The semantics of this primitive are as follows: 2
APSME-BIND.confirm {
3
4
Status,
5
SrcAddr,
6
SrcEndpoint, 7
ClusterId, 8
DstAddrMode, 9
DstAddr, 10
DstEndpoint 11
} 12
13
Table 2.7 specifies the parameters for the APSME-BIND.confirm primitive. 14
15
Table 2.7 APSME-BIND.confirm Parameters 16
Name Type Valid Range Description 17
18
Status Enumeration SUCCESS, The results of the binding 19
ILLEGAL_REQUEST, request.
20
TABLE_FULL,
NOT_SUPPORTED 21
22
SrcAddr IEEE address A valid 64-bit IEEE The source IEEE address for
23
address the binding entry.
24
SrcEndpoint Integer 0x01 – 0xf0 The source endpoint for the 25
binding entry. 26
ClusterId Integer 0x0000 – 0xffff The identifier of the cluster 27
on the source device that is 28
to be bound to the 29
destination device.
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 37

Table 2.7 APSME-BIND.confirm Parameters


1
DstAddrMode Integer 0x00 – 0xff The addressing mode for the
destination address used in
2
this primitive. This 3
parameter can take one of 4
the non-reserved values 5
from the following list: 6
0x00 = reserved 7
0x01 = 16-bit group address 8
for DstAddr and 9
DstEndpoint not present 10
0x02 = reserved 11
0x03 = 64-bit extended 12
address for DstAddr and 13
DstEndpoint present 14
0x04 – 0xff = reserved 15
DstAddr Address As specified by the The destination address for 16
DstAddrMode parameter the binding entry. 17
DstEndpoint Integer 0x01 – 0xf0, 0xff This parameter will be 18
present only if the 19
DstAddrMode parameter 20
has a value of 0x03 and, if 21
present, will be the
22
destination endpoint for the
binding entry. 23
24
25
2.2.4.3.2.2 When Generated
26
This primitive is generated by the APSME and issued to its NHLE in response to 27
an APSME-BIND.request primitive. If the request was successful, the Status 28
parameter will indicate a successful bind request. Otherwise, the Status parameter 29
indicates an error code of NOT_SUPPORTED, ILLEGAL_REQUEST or 30
TABLE_FULL. 31
32
2.2.4.3.2.3 Effect on Receipt 33
34
On receipt of this primitive, the next higher layer is notified of the results of its 35
bind request. If the bind request was successful, the Status parameter is set to 36
SUCCESS. Otherwise, the Status parameter indicates the error. 37
2.2.4.3.3 APSME-UNBIND.request 38
39
This primitive allows the next higher layer to request to unbind two devices, or to 40
unbind a device from a group, by removing an entry in its local binding table, if 41
supported. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
38 Application Layer Specification

2.2.4.3.3.1 Semantics of the Service Primitive


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

2.2.4.3.3.2 When Generated


1
This primitive is generated by the next higher layer and issued to the APS sub- 2
layer in order to instigate an unbind operation on a device that supports a binding 3
table. 4
5
2.2.4.3.3.3 Effect on Receipt 6
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, or if any of the parameters has a
9
value which is out of range, the APSME issues the APSME-UNBIND.confirm
10
primitive with the Status parameter set to ILLEGAL_REQUEST.
11
If the APS on a device that supports a binding table receives this primitive from 12
the NHLE, the APSME searches for the specified entry in its binding table. If the 13
entry exists, the APSME removes the entry and issues the APSME- 14
UNBIND.confirm (see sub-clause 2.2.4.3.4) primitive with the Status parameter 15
set to SUCCESS. If the entry could not be found, the APSME issues the APSME- 16
UNBIND.confirm primitive with the Status parameter set to 17
INVALID_BINDING. 18
19
2.2.4.3.4 APSME-UNBIND.confirm
20
This primitive allows the next higher layer to be notified of the results of its 21
request to unbind two devices, or to unbind a device from a group. 22
23
2.2.4.3.4.1 Semantics of the Service Primitive 24
25
The semantics of this primitive are as follows: 26
APSME-UNBIND.confirm { 27
Status,
28
29
SrcAddr,
30
SrcEndpoint,
31
ClusterId, 32
DstAddrMode, 33
DstAddr, 34
DstEndpoint 35
} 36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
40 Application Layer Specification

Table 2.9 specifies the parameters for the APSME-UNBIND.confirm primitive.


1
Table 2.9 APSME-UNBIND.confirm Parameters
2
Name Type Valid Range Description 3
4
Status Enumeration SUCCESS, The results of the unbind 5
ILLEGAL_REQUEST, request.
INVALID_BINDING 6
7
SrcAddr IEEE address A valid 64-bit IEEE The source IEEE address for 8
address the binding entry.
9
SrcEndpoint Integer 0x01 – 0xf0 The source endpoint for the 10
binding entry. 11
ClusterId Integer 0x0000 – 0xffff The identifier of the cluster on 12
the source device that is bound 13
to the destination device. 14
DstAddrMode Integer 0x00 – 0xff The addressing mode for the 15
destination address used in this 16
primitive. This parameter can 17
take one of the non-reserved
18
values from the following list:
19
0x00 = reserved 20
0x01 = 16-bit group address 21
for DstAddr and DstEndpoint 22
not present
23
0x02 = reserved
24
0x03 = 64-bit extended address 25
for DstAddr and DstEndpoint
present 26
27
0x04 – 0xff = reserved
28
DstAddr Address As specified by the The destination address for the 29
DstAddrMode parameter binding entry.
30
DstEndpoint Integer 0x01 – 0xf0, 0xff The destination endpoint for 31
the binding entry. 32
33
2.2.4.3.4.2 When Generated 34
35
This primitive is generated by the APSME and issued to its NHLE in response to 36
an APSME-UNBIND.request primitive. If the request was successful, the Status 37
parameter will indicate a successful unbind request. Otherwise, the Status 38
parameter indicates an error code of ILLEGAL_REQUEST, or 39
INVALID_BINDING. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 41

2.2.4.3.4.3 Effect on Receipt


1
On receipt of this primitive, the next higher layer is notified of the results of its 2
unbind request. If the unbind request was successful, the Status parameter is set to 3
SUCCESS. Otherwise, the Status parameter indicates the error. 4
5
2.2.4.4 Information Base Maintenance 6
This set of primitives defines how the next higher layer of a device can read and 7
write attributes in the AIB. 8
9
2.2.4.4.1 APSME-GET.request 10
11
This primitive allows the next higher layer to read the value of an attribute from
12
the AIB.
13
14
2.2.4.4.1.1 Semantics of the Service Primitive 15
The semantics of this primitive are as follows: 16
17
APSME-GET.request { 18
AIBAttribute 19
} 20
21
Table 2.10 specifies the parameters for this primitive. 22
23
Table 2.10 APSME-GET.request Parameters
24
Name Type Valid Range Description 25
26
AIBAttribute Integer See Table 2.24 The identifier of the AIB attribute to read.
27
28
2.2.4.4.1.2 When Generated 29
30
This primitive is generated by the next higher layer and issued to its APSME in
31
order to read an attribute from the AIB.
32
33
2.2.4.4.1.3 Effect on Receipt 34
On receipt of this primitive, the APSME attempts to retrieve the requested AIB 35
attribute from its database. If the identifier of the AIB attribute is not found in the 36
database, the APSME issues the APSME-GET.confirm primitive with a status of 37
UNSUPPORTED_ATTRIBUTE. 38
39
If the requested AIB attribute is successfully retrieved, the APSME issues the 40
APSME-GET.confirm primitive with a status of SUCCESS such that it contains 41
the AIB attribute identifier and value. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
42 Application Layer Specification

2.2.4.4.2 APSME-GET.confirm
1
This primitive reports the results of an attempt to read the value of an attribute 2
from the AIB. 3
4
2.2.4.4.2.1 Semantics of the Service Primitive 5
6
The semantics of this primitive are as follows:
7
APSME-GET.confirm { 8
Status, 9
AIBAttribute, 10
AIBAttributeLength, 11
AIBAttributeValue
12
13
}
14
15
Table 2.11 specifies the parameters for this primitive. 16
Table 2.11 APSME-GET.confirm Parameters 17
18
Name Type Valid Range Description 19
Status Enumeration SUCCESS or The results of the request to read an 20
UNSUPPORTED AIB attribute value. 21
_ATTRIBUTE 22
AIBAttribute Integer See Table 2.24 The identifier of the AIB attribute 23
that was read. 24
AIBAttributeLength Integer 0x0001 - 0xffff The length, in octets, of the
25
attribute value being returned. 26
27
AIBAttributeValue Various Attribute specific The value of the AIB attribute that
28
(see Table 2.24) was read.
29
30
2.2.4.4.2.2 When Generated 31
This primitive is generated by the APSME and issued to its next higher layer in 32
response to an APSME-GET.request primitive. This primitive returns a status of 33
SUCCESS, indicating that the request to read an AIB attribute was successful, or 34
an error code of UNSUPPORTED_ATTRIBUTE. The reasons for these status 35
values are fully described in sub-clause 2.2.4.4.1.3. 36
37
38
2.2.4.4.2.3 Effect on Receipt
39
On receipt of this primitive, the next higher layer is notified of the results of its 40
request to read an AIB attribute. If the request to read an AIB attribute was 41
successful, the Status parameter will be set to SUCCESS. Otherwise, the Status 42
parameter indicates the error. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 43

2.2.4.4.3 APSME-SET.request
1
This primitive allows the next higher layer to write the value of an attribute into 2
the AIB. 3
4
2.2.4.4.3.1 Semantics of the Service Primitive 5
6
The semantics of this primitive are as follows:
7
APSME-SET.request { 8
AIBAttribute, 9
AIBAttributeLength, 10
AIBAttributeValue 11
}
12
13
14
Table 2.12 specifies the parameters for this primitive. 15
Table 2.12 APSME-SET.request Parameters 16
17
Name Type Valid Range Description 18
AIBAttribute Integer See Table 2.24. The identifier of the AIB attribute to be 19
written. 20
AIBAttributeLength Integer 0x0000 - 0xffff The length, in octets, of the attribute 21
value being set. 22
23
AIBAttributeValue Various Attribute specific The value of the AIB attribute that should
(see Table 2.24). be written. 24
25
26
2.2.4.4.3.2 When Generated 27
This primitive is to be generated by the next higher layer and issued to its APSME 28
in order to write the value of an attribute in the AIB. 29
30
2.2.4.4.3.3 Effect on Receipt 31
32
On receipt of this primitive, the APSME attempts to write the given value to the 33
indicated AIB attribute in its database. If the AIBAttribute parameter specifies an 34
attribute that is not found in the database, the APSME issues the APSME- 35
SET.confirm primitive with a status of UNSUPPORTED_ATTRIBUTE. If the 36
AIBAttributeValue parameter specifies a value that is outside the valid range for 37
the given attribute, the APSME issues the APSME-SET.confirm primitive with a 38
status of INVALID_PARAMETER. 39
If the requested AIB attribute is successfully written, the APSME issues the 40
APSME-SET.confirm primitive with a status of SUCCESS. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
44 Application Layer Specification

2.2.4.4.4 APSME-SET.confirm
1
This primitive reports the results of an attempt to write a value to an AIB attribute. 2
3
2.2.4.4.4.1 Semantics of the Service Primitive 4
5
The semantics of this primitive are as follows:
6
APSME-SET.confirm { 7
Status, 8
AIBAttribute 9
} 10
11
12
Table 2.13 specifies the parameters for this primitive. 13
Table 2.13 APSME-SET.confirm Parameters 14
15
Name Type Valid Range Description
16
Status Enumeration SUCCESS, The result of the request to 17
INVALID_PARAMETER or write the AIB Attribute. 18
UNSUPPORTED_ATTRIBUTE 19
AIBAttribute Integer See Table 2.24. The identifier of the AIB 20
attribute that was written. 21
22
2.2.4.4.4.2 When Generated 23
24
This primitive is generated by the APSME and issued to its next higher layer in 25
response to an APSME-SET.request primitive. This primitive returns a status of 26
either SUCCESS, indicating that the requested value was written to the indicated 27
AIB attribute, or an error code of INVALID_PARAMETER or 28
UNSUPPORTED_ATTRIBUTE. The reasons for these status values are 29
completely described in sub-clause 2.2.4.4.3.3. 30
31
2.2.4.4.4.3 Effect on Receipt 32
33
On receipt of this primitive, the next higher layer is notified of the results of its
34
request to write the value of a AIB attribute. If the requested value was written to
35
the indicated AIB attribute, the Status parameter will be set to SUCCESS.
36
Otherwise, the Status parameter indicates the error.
37
2.2.4.5 Group Management 38
39
This set of primitives allows the next higher layer to manage group membership 40
for endpoints on the current device by adding and removing entries in the group 41
table. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 45

2.2.4.5.1 APSME-ADD-GROUP.request
1
This primitive allows the next higher layer to request that group membership for a 2
particular group be added for a particular endpoint. 3
4
2.2.4.5.1.1 Semantics of the Service Primitive 5
6
The semantics of this primitive are as follows:
7
APSME-ADD-GROUP.request { 8
GroupAddress, 9
Endpoint 10
} 11
12
13
Table 2.14 specifies the parameters for this primitive. 14
Table 2.14 APSME-ADD-GROUP.request Parameters 15
16
Name Type Valid Range Description
17
GroupAddress 16-bit 0x0000 - 0xffff The 16-bit address of the 18
group group being added. 19
address 20
Endpoint Integer 0x01 - 0xf0 The endpoint to which the 21
given group is being 22
added. 23
24
2.2.4.5.1.2 When Generated 25
26
This primitive is generated by the next higher layer when it wants to add 27
membership in a particular group to an endpoint, so that frames addressed to the 28
group will be delivered to that endpoint in the future. 29
30
2.2.4.5.1.3 Effect on Receipt 31
If, on receipt of this primitive, the GroupAddress parameter is found to be outside 32
the valid range, then the APSME will issue the APSME-ADD-GROUP.confirm 33
primitive to the next higher layer with a status value of INVALID_PARAMETER. 34
Similarly, if the Endpoint parameter has a value which is out of range or else 35
enumerates an endpoint that is not implemented on the current device, the 36
APSME will issue the APSME-ADD-GROUP.confirm primitive with a Status of 37
INVALID_PARAMETER. 38
39
After checking the parameters as described above, the APSME will check the 40
group table to see if an entry already exists containing the values given by the 41
GroupAddress and Endpoint parameters. If such an entry already exists in the 42
table then the APSME will issue the APSME-ADD-GROUP.confirm primitive to 43
the next higher layer with a status value of SUCCESS. If there is no such entry 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
46 Application Layer Specification

and there is space in the table for another entry then the APSME will add a new
entry to the group table with the values given by the GroupAddress and Endpoint 1
parameters. After the entry is added to the APS group table, and if the NWK layer 2
is maintaining a group table, then the APSME ensures that the corresponding 3
NWK group table is consistent by issuing the NLME-SET.request primitive, for 4
the nwkGroupIDTable attribute, with the list of group addresses contained in the 5
group table of the APS sub-layer. Once both tables are consistent, the APSME 6
issues the APSME-ADD-GROUP.confirm primitive to the next higher layer with 7
a status value of SUCCESS. If no entry for the given GroupAddress and Endpoint 8
is present but there is no room in the group table for another entry, then the 9
APSME will issue the APSME-ADD-GROUP.confirm primitive to the next 10
higher layer with a status value of TABLE_FULL. 11
12
2.2.4.5.2 APSME-ADD-GROUP.confirm 13
This primitive allows the next higher layer to be informed of the results of its 14
request to add a group to an endpoint. 15
16
2.2.4.5.2.1 Semantics of the Service Primitive 17
18
The semantics of the service primitive are as follows: 19
20
APSME-ADD-GROUP.confirm {
21
Status, 22
GroupAddress, 23
Endpoint 24
} 25
26
Table 2.15 specifies the parameters for this primitive. 27
28
Table 2.15 APSME-ADD-GROUP.confirm Parameters
29
Name Type Valid Range Description 30
31
Status Enumeration SUCCESS, The status of the request to
32
INVALID_PARAMETER add a group.
or TABLE_FULL 33
34
GroupAddress 16-bit group 0x0000 - 0xffff The 16-bit address of the
35
address group being added.
36
Endpoint Integer 0x01 - 0xf0 The endpoint to which the 37
given group is being 38
added.
39
40
2.2.4.5.2.2 When Generated 41
This primitive is generated by the APSME and issued to the next higher layer in 42
response to an APMSE-ADD-GROUP.request primitive. If the APSME-ADD- 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 47

GROUP.request was successful, then the Status parameter value will be


SUCCESS. If one of the parameters of the APMSE-ADD-GROUP.request 1
primitive had an invalid value, then the status value will be set to 2
INVALID_PARAMETER. If the APMSE attempted to add a group table entry but 3
there was no room in the table for another entry, then the status value will be 4
TABLE_FULL. 5
6
2.2.4.5.2.3 Effect on Receipt 7
8
On receipt of this primitive, the next higher layer is informed of the status of its 9
request to add a group. The Status parameter values will be as described above. 10
2.2.4.5.3 APSME-REMOVE-GROUP.request 11
12
This primitive allows the next higher layer to request that group membership in a 13
particular group for a particular endpoint be removed. 14
15
2.2.4.5.3.1 Semantics of the Service Primitive 16
17
The semantics of the service primitive are as follows: 18
APSME-REMOVE-GROUP.request { 19
GroupAddress, 20
Endpoint
21
22
}
23
24
Table 2.16 specifies the parameters for this primitive. 25
Table 2.16 APSME-REMOVE-GROUP.request Parameters 26
27
Name Type Valid Range Description 28
GroupAddress 16-bit group 0x0000 - 0xffff The 16-bit address of the 29
address group being removed. 30
Endpoint Integer 0x01 - 0xf0 The endpoint to which the 31
given group is being 32
removed. 33
34
2.2.4.5.3.2 When Generated 35
36
This primitive is generated by the next higher layer when it wants to remove 37
membership in a particular group from an endpoint so that frames addressed to the 38
group will no longer be delivered to that endpoint. 39
40
2.2.4.5.3.3 Effect on Receipt 41
42
If, on receipt of this primitive, the GroupAddress parameter is found to be outside 43
the valid range, then the APSME will issue the APSME-REMOVE- 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
48 Application Layer Specification

GROUP.confirm primitive to the next higher layer with a status value of


INVALID_PARAMETER. Similarly, if the Endpoint parameter has a value which 1
is out of range or else enumerates an endpoint that is not implemented on the 2
current device, the APSME will issue the APSME-REMOVE-GROUP.confirm 3
primitive with a Status of INVALID_PARAMETER. 4
5
After checking the parameters as described above, the APSME will check the 6
group table to see if an entry exists containing the values given by the 7
GroupAddress and Endpoint parameters. If such an entry already exists in the 8
table, then that entry will be removed. If the NWK layer is maintaining a group 9
table, then the APSME ensures that the NWK group table is consistent by issuing 10
the NLME-SET.request primitive, for the nwkGroupIDTable attribute, with the 11
list of group addresses contained in the group table of the APS sub-layer. Once 12
both tables are consistent, the APSME issues the APSME-REMOVE- 13
GROUP.confirm primitive to the next higher layer with a status value of 14
SUCCESS. If there is no such entry, the APSME will issue the APSME- 15
REMOVE-GROUP.confirm primitive to the next higher layer with a status value 16
of INVALID_GROUP. 17
2.2.4.5.4 APSME-REMOVE-GROUP.confirm 18
19
This primitive allows the next higher layer to be informed of the results of its 20
request to remove a group from an endpoint. 21
22
2.2.4.5.4.1 Semantics of the Service Primitive 23
24
The semantics of the service primitive are as follows:
25
APSME-REMOVE-GROUP.confirm { 26
Status, 27
GroupAddress, 28
Endpoint 29
}
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 49

Table 2.17 specifies the parameters for this primitive.


1
Table 2.17 APSME-REMOVE-GROUP.confirm Parameters
2
Name Type Valid Range Description 3
4
Status Enumeration SUCCESS, The status of the request to 5
INVALID_GROUP or remove a group.
INVALID_PARAMETER 6
7
GroupAddress 16-bit group 0x0000 - 0xffff The 16-bit address of the 8
address group being removed.
9
Endpoint Integer 0x01 - 0xf0 The endpoint which is to 10
be removed from the 11
group.
12
13
2.2.4.5.4.2 When Generated 14
15
This primitive is generated by the APSME and issued to the next higher layer in
16
response to an APMSE-REMOVE-GROUP.request primitive. If the APSME-
17
REMOVE-GROUP.request was successful, the Status parameter value will be
18
SUCCESS. If the APSME-REMOVE-GROUP.request was not successful
19
because an entry containing the values given by the GroupAddress and Endpoint
20
parameters did not exist, then the status value will be INVALID_GROUP. If one
21
of the parameters of the APMSE-REMOVE-GROUP.request primitive had an
22
invalid value, then the status value will be INVALID_PARAMETER.
23
24
2.2.4.5.4.3 Effect on Receipt
25
On receipt of this primitive, the next higher layer is informed of the status of its 26
request to remove a group. The Status parameter values will be as described 27
above. 28
29
2.2.4.5.5 APSME-REMOVE-ALL-GROUPS.request 30
This primitive is generated by the next higher layer when it wants to remove 31
membership in all groups from an endpoint, so that no group-addressed frames 32
will be delivered to that endpoint. 33
34
2.2.4.5.5.1 Semantics of the Service Primitive 35
36
The semantics of the service primitive are as follows: 37
38
APSME-REMOVE-ALL-GROUPS.request {
39
Endpoint
40
} 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
50 Application Layer Specification

Table 2.18 specifies the parameters for this primitive.


1
Table 2.18 APSME-REMOVE-ALL-GROUPS.request Parameters
2
Name Type Valid Range Description 3
4
Endpoint Integer 0x01 - 0xf0 The endpoint to which the 5
given group is being
removed. 6
7
8
2.2.4.5.5.2 When Generated 9
This primitive is generated by the next higher layer when it wants to remove 10
membership in all groups from an endpoint so that no group addressed frames will 11
be delivered to that endpoint. 12
13
2.2.4.5.5.3 Effect on Receipt 14
15
If, on receipt of this primitive, the Endpoint parameter has a value which is out of 16
range or else enumerates an endpoint that is not implemented on the current 17
device the APSME will issue the APSME-REMOVE-ALL-GROUPS.confirm 18
primitive with a Status of INVALID_PARAMETER. 19
After checking the Endpoint parameter as described above, the APSME will 20
remove all entries related to this endpoint from the group table. The APSME 21
ensures that the corresponding NWK group table is consistent by issuing the 22
NLME-SET.request primitive, for the nwkGroupIDTable attribute, with the list of 23
group addresses contained in the group table of the APS sub-layer. Once both 24
tables are consistent, the APSME issues the APSME-REMOVE-ALL- 25
GROUPS.confirm primitive to the next higher layer with a status value of 26
SUCCESS. 27
28
2.2.4.5.6 APSME-REMOVE-ALL-GROUPS.confirm 29
30
This primitive allows the next higher layer to be informed of the results of its
31
request to remove all groups from an endpoint.
32
33
2.2.4.5.6.1 Semantics of the Service Primitive 34
The semantics of the service primitive are as follows: 35
36
APSME-REMOVE-ALL-GROUPS.confirm { 37
Status, 38
Endpoint 39
} 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 51

Table 2.19 specifies the parameters for this primitive.


1
Table 2.19 APSME-REMOVE-ALL-GROUPS.confirm Parameters
2
Name Type Valid Range Description 3
4
Status Enumeration SUCCESS or The status of the request to 5
INVALID_PARAMETER remove all groups.
6
Endpoint Integer 0x01 - 0xf0 The endpoint which is to 7
be removed from all 8
groups.
9
10
2.2.4.5.6.2 When Generated 11
12
This primitive is generated by the APSME and issued to the next higher layer in
13
response to an APSME-REMOVE-ALL-GROUPS.request primitive. If the
14
APSME-REMOVE-ALL-GROUPS.request was successful, then the Status
15
parameter value will be SUCCESS. If the Endpoint parameter of the APSME-
16
REMOVE-ALL-GROUPS.request primitive had an invalid value, then the status
17
value will be INVALID_PARAMETER.
18
19
2.2.4.5.6.3 Effect on Receipt
20
On receipt of this primitive, the next higher layer is informed of the status of its 21
request to remove all groups from an endpoint. The Status parameter values will 22
be as described above. 23
24
25
2.2.5 Frame Formats 26
27
This sub-clause specifies the format of the APS frame (APDU). Each APS frame 28
consists of the following basic components: 29
• An APS header, which comprises frame control and addressing information. 30
31
• An APS payload, of variable length, which contains information specific to the 32
frame type. 33
The frames in the APS sub-layer are described as a sequence of fields in a specific 34
order. All frame formats in this sub-clause are depicted in the order in which they 35
are transmitted by the NWK layer, from left to right, where the leftmost bit is 36
transmitted first in time. Bits within each field are numbered from 0 (leftmost and 37
least significant) to k-1 (rightmost and most significant), where the length of the 38
field is k bits. Fields that are longer than a single octet are sent to the NWK layer 39
in order from the octet containing the lowest-numbered bits to the octet containing 40
the highest-numbered bits. 41
42
On transmission, all fields marked as reserved shall be set to zero. On reception, 43
all fields marked as reserved in this version of the specification shall be checked 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
52 Application Layer Specification

for being equal to zero. If such a reserved field is not equal to zero, no further
processing shall be applied to the frame and the frame shall be discarded. 1
2
2.2.5.1 General APDU Frame Format 3
4
The APS frame format is composed of an APS header and an APS payload. The 5
fields of the APS header appear in a fixed order, however, the addressing fields 6
may not be included in all frames. The general APS frame shall be formatted as 7
illustrated in Figure 2.2. 8
9
Octets: 0/
1 0/1 0/2 0/2 0/2 0/1 1 Variable Variable 10
11
Frame Destination Group Cluster Profile Source APS Extended Frame 12
control endpoint address identifier identifier endpoint counter header payload 13
Addressing fields 14
15
APS header APS
payload 16
17
Figure 2.2 General APS Frame Format 18
19
2.2.5.1.1 Frame Control Field 20
The frame control field is 8-bits in length and contains information defining the 21
frame type, addressing fields, and other control flags. The frame control field shall 22
be formatted as illustrated in Figure 2.3. 23
24
Bits: 0-1 2-3 4 5 6 7 25
26
Frame type Delivery mode Ack. formata Security Ack. request Extended
header
27
present 28
29
a. CCB #813 30
Figure 2.3 Format of the Frame Control Field 31
32
2.2.5.1.1.1 Frame Type Sub-Field 33
34
The frame type sub-field is two bits in length and shall be set to one of the non- 35
reserved values listed in Table 2.20. 36
Table 2.20 Values of the Frame Type Sub-Field 37
38
Frame Type Value 39
b1 b0 Frame Type Name
40
00 Data 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 53

Table 2.20 Values of the Frame Type Sub-Field (Continued)


1
01 Command
2
10 Acknowledgement 3
11 Reserved 4
5
6
2.2.5.1.1.2 Delivery Mode Sub-Field
7
The delivery mode sub-field is two bits in length and shall be set to one of the 8
non-reserved values from Table 2.21. 9
10
Table 2.21 Values of the Delivery Mode Sub-Field
11
Delivery Mode Value 12
b1 b0 Delivery Mode Name 13
00 Normal unicast delivery
14
15
01 Indirect 16
10 Broadcast 17
18
11 Group addressing
19
20
If the value is 0b00, the frame will be delivered to a given endpoint on the 21
receiving device. 22
If the value is 0b10, the message is a broadcast. In this case, the message will go 23
to all devices defined for the selected broadcast address in use as defined in sub- 24
clause 3.6.5. The destination endpoint field shall be set to a value between 0x01- 25
0xf0 (for broadcasts to specific endpoints) or to 0xff (for broadcasts to all active 26
endpoints). 27
28
If the value is 0b11, then group addressing is in use and that frame will only be 29
delivered to device endpoints that express group membership in the group 30
identified by the group address field in the APS header. Note that other endpoints 31
on the source device may be members of the group addressed by the outgoing 32
frame. The frame shall be delivered to any member of the group, including other 33
endpoints on the source device that are members of the specified group. 34
Devices where nwkUseMulticast is set to TRUE, shall never set the delivery mode 35
of an outgoing frame to 0b11. In this case, the delivery mode of the outgoing 36
frame shall be set to 0b10 (broadcast) and the frame shall be sent using an NLDE- 37
DATA.request with the destination address mode set to group addressing. 38
39
2.2.5.1.1.3 Ack Format Field 40
41
This bit indicates if the destination endpoint, cluster identifier, profile identifier 42
and source endpoint fields shall be present in the acknowledgement frame. This is 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
54 Application Layer Specification

set to 0 for data frame acknowledgement and 1 for APS command frame
acknowledgement.1 1
2
2.2.5.1.1.4 Security Sub-Field 3
4
The Security Services Provider (see Chapter 4) manages the security sub-field. 5
6
2.2.5.1.1.5 Acknowledgement Request Sub-Field 7
8
The acknowledgement request sub-field is one bit in length and specifies whether 9
the current transmission requires an acknowledgement frame to be sent to the 10
originator on receipt of the frame. If this sub-field is set to 1, the recipient shall 11
construct and send an acknowledgement frame back to the originator after 12
determining that the frame is valid. If this sub-field is set to 0, the recipient shall 13
not send an acknowledgement frame back to the originator. 14
This sub-field shall be set to 0 for all frames that are broadcast or multicast. 15
16
2.2.5.1.1.6 Extended Header Present 17
18
The extended header present sub-field is one bit in length and specifies whether 19
the extended header shall be included in the frame. If this sub-field is set to 1, then 20
the extended header shall be included in the frame. Otherwise, it shall not be 21
included in the frame. 22
2.2.5.1.2 Destination Endpoint Field 23
24
The destination endpoint field is 8-bits in length and specifies the endpoint of the 25
final recipient of the frame. This field shall be included in the frame only if the 26
delivery mode sub-field of the frame control field is set to 0b00 (normal unicast 27
delivery), 0b01 (indirect delivery where the indirect address mode sub-field of the 28
frame control field is also set to 0), or 0b10 (broadcast delivery). In the case of 29
broadcast delivery, the frame shall be delivered to the destination endpoint 30
specified within the range 0x01-0xf0 or to all active endpoints if specified as 0xff. 31
A destination endpoint value of 0x00 addresses the frame to the ZigBee device 32
object (ZDO), resident in each device. A destination endpoint value of 0x01-0xf0 33
addresses the frame to an application operating on that endpoint. A destination 34
endpoint value of 0xff addresses the frame to all active endpoints except endpoint 35
0x00. All other endpoints (0xf1-0xfe) are reserved. 36
37
2.2.5.1.3 Group Address Field 38
The group address field is 16 bits in length and will only be present if the delivery 39
mode sub-field of the frame control has a value of 0b11. In this case, the 40
destination endpoint shall not be present. If the APS header of a frame contains a 41
42
43
1. CCB #813 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 55

group address field, the frame will be delivered to all endpoints for which the
group table in the device contains an association between that endpoint and the 1
group identified by the contents of the group address field. 2
3
Devices where nwkUseMulticast is set to TRUE shall never set the group address 4
field of an outgoing frame. 5
2.2.5.1.4 Cluster Identifier Field 6
7
The cluster identifier field is 16 bits in length and specifies the identifier of the 8
cluster to which the frame relates and which shall be made available for filtering 9
and interpretation of messages at each device that takes delivery of the frame. 10
This field shall be present only for data or acknowledgement frames. 11
2.2.5.1.5 Profile Identifier Field 12
13
The profile identifier is two octets in length and specifies the ZigBee profile 14
identifier for which the frame is intended and shall be used during the filtering of 15
messages at each device that takes delivery of the frame. This field shall be 16
present only for data or acknowledgement frames. 17
2.2.5.1.6 Source Endpoint Field 18
19
The source endpoint field is eight-bits in length and specifies the endpoint of the 20
initial originator of the frame. A source endpoint value of 0x00 indicates that the 21
frame originated from the ZigBee device object (ZDO) resident in each device. A 22
source endpoint value of 0x01-0xf0 indicates that the frame originated from an 23
application operating on that endpoint. All other endpoints (0xf1-0xff) are 24
reserved. 25
26
2.2.5.1.7 APS Counter
27
This field is eight bits in length and is used as described in sub-clause 2.2.8.4.2 to 28
prevent the reception of duplicate frames. This value shall be incremented by one 29
for each new transmission. 30
31
2.2.5.1.8 Extended Header Sub-Frame 32
The extended header sub-frame contains further sub-fields and shall be formatted 33
as illustrated in Figure 2.4. 34
35
Octets: 1 0/1 0/1 36
Extended frame control Block number ACK bitfield
37
38
Figure 2.4 Format of the Extended Header Sub-Frame 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
56 Application Layer Specification

2.2.5.1.8.1 Extended Frame Control Field


1
The extended frame control field is eight-bits in length and contains information 2
defining the use of fragmentation. The extended frame control field shall be 3
formatted as illustrated in Figure 2.5. 4
5
Bits: 0-1 2-7
6
Fragmentation Reserved 7
8
Figure 2.5 Format of the Extended Frame Control Field 9
10
The fragmentation sub-field is two bits in length and shall be set to one of the non- 11
reserved values listed in Table 2.22. 12
Table 2.22 Values of the Fragmentation Sub-Field 13
14
Fragmentation Value
b1 b 0 Description 15
16
00 Transmission is not fragmented. 17
01 Frame is first fragment of a 18
fragmented transmission. 19
10 Frame is part of a fragmented
20
transmission but not the first part. 21
22
11 Reserved
23
24
2.2.5.1.8.2 Block Number 25
26
The block number field is one octet in length and is used for fragmentation control
27
as follows: If the fragmentation sub-field is set to indicate that the transmission is
28
not fragmented then the block number field shall not be included in the sub-frame.
29
If the fragmentation sub-field is set to 01, then the block number field shall be
30
included in the sub-frame and shall indicate the number of blocks in the
31
fragmented transmission. If the fragmentation sub-field is set to 10, then the block
32
number field shall be included in the sub-frame and shall indicate which block
33
number of the transmission the current frame represents, taking the value 0x01 for
34
the second fragment, 0x02 for the third, etc.
35
36
2.2.5.1.8.3 Ack Bitfield 37
The ack bitfield field is one octet in length and is used in an APS 38
acknowledgement as described in sub-clause 2.2.8.4.5.2 to indicate which blocks 39
of a fragmented ASDU have been successfully received. This field is only present 40
if the frame type sub-field indicates an acknowledgement and the fragmentation 41
sub-field indicates a fragmented transmission. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 57

2.2.5.1.9 Frame Payload Field


1
The frame payload field has a variable length and contains information specific to 2
individual frame types. 3
4
2.2.5.2 Format of Individual Frame Types 5
There are three defined frame types: data, APS command, and acknowledgement. 6
Each of these frame types is discussed in the following sub-clauses. 7
8
2.2.5.2.1 Data Frame Format 9
10
The data frame shall be formatted as illustrated in Figure 2.6.
11
Octets: 0/ 12
1 0/1 0/2 2 2 1 1 Variable Variable 13
14
Frame Destination Group Cluster Profile Source APS Extended Frame
control endpoint address identifier Identifier endpoint counter header payload
15
16
Addressing fields 17
APS header APS 18
payload 19
20
Figure 2.6 Data Frame Format
21
The order of the fields of the data frame shall conform to the order of the general 22
APS frame as illustrated in Figure 2.2. 23
24
25
2.2.5.2.1.1 Data Frame APS Header Fields
26
The APS header field for a data frame shall contain the frame control, cluster 27
identifier, profile identifier, source endpoint and APS counter fields. The 28
destination endpoint, group address and extended header fields shall be included 29
in a data frame according to the values of the delivery mode and extended header 30
present sub-fields of the frame control field. 31
32
In the frame control field, the frame type sub-field shall contain the value that
33
indicates a data frame, as shown in Table 2.20. All other sub-fields shall be set
34
appropriately according to the intended use of the data frame.
35
36
2.2.5.2.1.2 Data Payload Field 37
For an outgoing data frame, the data payload field shall contain part or all of the 38
sequence of octets that the next higher layer has requested the APS data service to 39
transmit. For an incoming data frame, the data payload field shall contain all or 40
part of the sequence of octets that has been received by the APS data service and 41
that is to be delivered to the next higher layer. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
58 Application Layer Specification

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 1 1 Variable
4
Frame APS APS APS 5
control 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.2. 13
14
2.2.5.2.2.1 APS Command Frame APS Header Fields 15
The APS header field for an APS command frame shall contain the frame control 16
and APS counter fields. In this version of the specification, the APS command 17
frame shall not be fragmented and the extended header field shall not be present. 18
19
In the frame control field, the frame type sub-field shall contain the value that 20
indicates an APS command frame, as shown in Table 2.20. The APS Command 21
Payload shall be set appropriately according to the intended use of the APS 22
command frame. 23
24
2.2.5.2.2.2 APS Command Identifier Field 25
26
The APS command identifier field identifies the APS command being used.
27
28
2.2.5.2.2.3 APS Command Payload Field
29
The APS command payload field of an APS command frame shall contain the 30
APS command itself. 31
32
2.2.5.2.3 Acknowledgement Frame Format 33
The acknowledgement frame shall be formatted as illustrated in Figure 2.8. 34
35
0/ 36
Octets: 1 0/1 0/2 0/2 0/1 1 Variable 37
Frame Destination Cluster Profile Source APS Extended 38
control endpoint identifier identifier endpoint counter header 39
40
APS header
41
Figure 2.8 Acknowledgement Frame Format 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 59

The order of the fields of the acknowledgement frame shall conform to the order
of the general APS frame as illustrated in Figure 2.2. 1
2
2.2.5.2.3.1 Acknowledgement Frame APS Header Fields 3
4
If the ack format field is not set in the frame control field, the destination 5
endpoint, cluster identifier, profile identifier and source endpoint shall be present. 6
This is not set for data frame acknowledgement.2 Both the source and destination 7
endpoint fields shall be included in an acknowledgement frame. The extended 8
header field shall be included in a data frame according to the value of the 9
extended header present sub-field of the frame control field. 10
In the frame control field, the frame type sub-field shall contain the value that 11
indicates an acknowledgement frame, as shown in Table 2.20. The extended 12
header present sub-field shall contain the same value as in the frame to which this 13
frame is an acknowledgement. All other sub-fields shall be set appropriately 14
according to the intended use of the acknowledgement frame. 15
16
If the ack format field is set in the frame control field, the frame is an APS 17
command frame acknowledgement and the destination endpoint, cluster identifier, 18
profile identifier and source endpoint fields shall not be set.3 Alternatively, if an 19
APS data frame is being acknowledged, the source endpoint field shall reflect the 20
value in the destination endpoint field of the frame that is being acknowledged. 21
Similarly, the destination endpoint field shall reflect the value in the source 22
endpoint field of the frame that is being acknowledged. 23
The APS counter field shall contain the same value as the frame to which this 24
frame is an acknowledgment. 25
26
Where the extended header is present, the fragmentation sub-field of the extended 27
frame control field shall contain the same value as in the frame to which this 28
frame is an acknowledgement. If fragmentation is in use for this frame, then the 29
block number and ack bitfield fields shall be present. Where present, the block 30
number field shall contain the value zero if this is the first frame of a fragmented 31
transmission, and otherwise shall contain the same value as in the frame to which 32
this frame is an acknowledgement. 33
34
2.2.6 Command Frames 35
36
This specification defines no command frames. Refer to sub-clause 4.4.9 for a 37
thorough description of the APS command frames and primitives related to 38
security. 39
40
41
42
2. CCB #813 43
3. CCB #813 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
60 Application Layer Specification

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.23. 5
6
Table 2.23 APS Sub-Layer Constants
7
Constant Description Value 8
9
apscMaxDescriptorSize The maximum number of octets 64 10
contained in a non-complex descriptor.
11
apscMaxFrameRetries The maximum number of retries 3 12
allowed after a transmission failure. 13
apscAckWaitDuration The maximum number of seconds to 0.05 * 14
wait for an acknowledgement to a (2*nwkcMaxDepth) + 15
transmitted frame. (security encrypt/ 16
decrypt delay), where
the (security encrypt/ 17
decrypt delay) = 0.1 18
19
20
(assume 0.05 per 21
encrypt or decrypt 22
cycle)
23
apscMinDuplicateRejecti The minimum required size of the APS 1 24
onTableSize duplicate rejection table. 25
apscMaxWindowSize Fragmentation parameter - The Set by stack profile 26
maximum number of unacknowledged 27
frames that can be active at once (see (1-8 supported)
28
sub-clause 2.2.8.4.5).
29
apscInterframeDelay Fragmentation parameter - The standard Set by stack profile 30
delay between sending two blocks of a 31
fragmented transmission (see sub-
32
clause 2.2.8.4.5).
33
apscMinHeaderOverhead The minimum number of octets added 0x0C 34
by the APS sub-layer to an ASDU. 35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 61

2.2.7.2 APS Information Base


1
The APS information base comprises the attributes required to manage the APS 2
layer of a device. The attributes of the AIB are listed in Table 2.24. The security- 3
related AIB attributes are described in sub-clause 4.4.10. 4
Table 2.24 APS IB Attributes 5
6
Attribute Identifier Type Range Description Default 7
apsBindingTable 0xc1 Set Variable The current set of Null set
8
binding table entries in 9
the device (see sub- 10
clause 2.2.8.2.1). 11
apsDesignatedCoord 0xc2 Boolean TRUE or TRUE if the device FALSE 12
inator FALSE should become the 13
ZigBee Coordinator on 14
startup, FALSE if 15
otherwise.
16
apsChannelMask 0xc3 IEEE80 Any legal The mask of allowable All 17
2.15.4 mask for channels for this device channels 18
channel the PHY to use for network
19
mask operations.
20
apsUseExtendedPA 0xc4 64-bit 0x000000 The 64-bit address of a 0x00000 21
NID extende 00000000 network to form or to 0000000 22
d 00 to join. 0000
address 0xfffffffff 23
ffffffe 24
25
apsGroupTable 0x0c5 Set Variable The current set of group Null set
table entries (see 26
Table 2.25). 27
28
apsNonmemberRadi 0xc6 Integer 0x00- The value to be used for 2
us 0x07 the NonmemberRadius 29
parameter when using 30
NWK layer multicast. 31
apsPermissionsConf 0xc7 See Variable The current set of Null set
32
iguration Table 2. permission configuration 33
23 items. 34
apsUseInsecureJoin 0xc8 Boolean TRUE or A flag controlling the TRUE
35
FALSE use of insecure join at 36
startup. 37
38
apsInterframeDelay 0xc9 Integer 0x00- Fragmentation parameter Set by
0xff, - the standard delay, in stack 39
(may be milliseconds, between profile 40
restricted sending two blocks of a 41
by stack fragmented transmission 42
profile) (see sub-
43
clause 2.2.8.4.5).
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
62 Application Layer Specification

Table 2.24 APS IB Attributes (Continued)


1
apsLastChannelEner 0xca Integer 0x00 - The energy measurement Null set
gy 0xff for the channel energy
2
scan performed on the 3
previous channel just 4
before a channel change 5
(in accordance with 6
[B1]).
7
apsLastChannelFail xcb Integer 0-100 The latest percentage of Null set 8
ureRate (decimal) transmission network 9
transmission failures for
10
the previous channel just
before a channel change 11
(in percentage of failed 12
transmissions to the total 13
number of transmissions 14
attempted)
15
apsChannelTimer 0xcc Integer 1-24 A countdown timer (in Null set 16
(decimal) hours) indicating the 17
time to the next
18
permitted frequency
agility channel change. 19
A value of NULL 20
indicates the channel has 21
not been changed 22
previously.
23
24
25
Table 2.25 Group Table Entry Format 26
27
Group ID Endpoint List 28
16-bit group address List of endpoints on this device 29
which are members of the group. 30
31
32
2.2.8 Functional Description 33
34
2.2.8.1 Persistent Data 35
The APS is required to maintain a minimum set of data in persistent memory. This 36
37
data set shall persist over power fail, device reset, or other processing events. The
38
following data shall be maintained in persistent memory within APS: 39
• apsBindingTable (if supported on the device) 40
41
• apsDesignatedCoordinator (if supported on the device) 42
• apsChannelMask 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 63

• apsUseExtendedPANID
1
• apsUseInsecureJoin 2
• apsGroupTable (if supported on the device) 3
4
• Binding Table Cache (if the device is designated as a primary or backup 5
binding table cache, see clause 2.4.2.4) 6
• Discovery Cache (if the device is designated as a primary discovery cache, see 7
clause 2.4.2.1) 8
9
• Node Descriptor, Power Descriptor plus the Simple Descriptor(s) for each 10
active endpoint on the device 11
• Network manager address4 12
13
The method by which these data are made to persist is beyond the scope of this
14
specification. 15
16
2.2.8.2 Binding 17
The APS may maintain a binding table, which allows ZigBee devices to establish 18
a designated destination for frames from a given source endpoint and with a given 19
cluster ID. Each designated destination shall represent either a specific endpoint 20
on a specific device, or a group address. 21
22
2.2.8.2.1 Binding Table Implementation 23
A device designated as containing a binding table shall be able to support a 24
binding table of implementation-specific length. The binding table shall 25
implement the following mapping: 26
27
(as, es, cs) = {(ad1|, ed1|), (ad2|, ed2|) … (adn|, edn |)} 28
29
30
Where: 31
as = the address of the device as the source of the binding link. 32
33
es = the endpoint identifier of the device as the source of the binding link.
34
cs = the cluster identifier used in the binding link. 35
adi = the ith destination address or destination group address associated with the binding link. 36
37
edi = the ith optional destination endpoint identifier associated with the binding link. Note that 38
edi will only be present when adi is a device address.
39
40
41
42
43
4. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
64 Application Layer Specification

2.2.8.2.2 Binding
1
The APSME-BIND.request or APSME-UNBIND.request primitives initiate the 2
procedure for creating or removing a binding link. Only a device supporting a 3
binding table cache, or a device that wishes to store source bindings, shall initiate 4
this procedure. If this procedure is initiated by another type of device, then the 5
APSME shall issue the APSME-BIND.confirm or APSME-UNBIND.confirm 6
primitive with the Status parameter set to ILLEGAL_REQUEST. 7
When this procedure is initiated, the APSME shall first extract the address and 8
endpoint for both the source and destination of the binding link. If the 9
DstAddrMode parameter has a value of 0x01, indicating group addressing, then 10
only the source address is treated in the way just described. The 16-bit group 11
address is used directly as a destination address and, in this case, no destination 12
endpoint is specified. With this information, the APSME shall either create a new 13
entry or remove the corresponding entry from its binding table, depending on 14
whether the bind or unbind procedure, respectively, was initiated. 15
16
If a bind operation was requested, the APSME shall create a new entry in the 17
binding table. The device shall only create a new entry in the binding table if it has 18
the capacity to do so. If the binding table does not have capacity, then the APSME 19
shall issue the APSME-BIND.confirm primitive with the Status parameter set to 20
TABLE_FULL. 21
If an unbind operation was requested, the APSME shall search the binding table 22
for an existing entry that matches the information contained in the initiation 23
request. If an entry is not found, the APSME shall terminate the procedure and 24
notify the NHLE of the invalid binding. This is achieved by issuing the APSME- 25
UNBIND.confirm primitive with the Status parameter set to 26
INVALID_BINDING. If an entry is found, the APSME shall remove the entry in 27
the binding table. 28
29
If the binding link is successfully created or removed, the APSME shall notify the 30
NHLE of the results of the binding attempt and the success of the procedure. This 31
is achieved by issuing the APSME-BIND.confirm or APSME-UNBIND.confirm 32
primitive, respectively, with the binding results and the Status parameter set to 33
SUCCESS. 34
The procedure for a successful binding is illustrated in the MSC shown in 35
Figure 2.9. 36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 65

1
APL APS NWK 2
3
APSME- 4
(UN)BIND.request 5
6
Create a new entry or 7
remove an existing entry 8
in the binding table 9
APSME- 10
(UN)BIND.confirm 11
12
13
14
Figure 2.9 Binding on a Device Supporting a Binding Table 15
16
2.2.8.3 Group Addressing 17
18
The APS sub-layer shall maintain a group table, which allows endpoints to be 19
associated with groups and allows group-addressed frames to be delivered 20
selectively to those endpoints that are associated in the table with a particular 21
group. 22
The list of group addresses in the APS sub-layer group table shall be kept 23
consistent with the list of group IDs in the NWK layer group table, stored in the 24
nwkGroupIDTable attribute. 25
26
2.2.8.3.1 The Group Table 27
For purposes of this discussion, the group table shall be viewed as a set of 28
associations between groups and endpoints as follows: 29
30
{(g1 - ep11, ep12…ep1n), (g2 - ep21, ep22… ep2m)… (gi - epi1, epi2… epik)} 31
32
33
where:
34
gi = the ith group represented in the table. 35
epij = the jth endpoint associated with the ith group.
36
37
38
Implementers of this specification are free to implement the group table in any 39
manner that is convenient and efficient, as long as it represents the associations 40
just described. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
66 Application Layer Specification

2.2.8.4 Transmission, Reception, and Acknowledgement


1
This sub-clause describes the fundamental procedures for transmission, reception, 2
and acknowledgement. 3
4
2.2.8.4.1 Transmission
5
Only those devices that are currently part of a network shall send frames from the 6
APS sub-layer. If any other device receives a request to transmit a frame, it shall 7
discard the frame and notify the instigating layer of the error. An APSDE- 8
DATA.confirm primitive with a status of CHANNEL_ACCESS_FAILURE 9
indicates that the attempt at transmission of the frame was unsuccessful due to the 10
channel being busy. 11
12
All frames handled by or generated within the APS sub-layer shall be constructed 13
according to the general frame format specified in sub-clause 2.2.5.1 and 14
transmitted using the NWK layer data service. 15
Transmissions employing delivery modes 0b00 (Normal Unicast) and 0b10 16
(Broadcast) shall include both the source endpoint and destination endpoint fields. 17
Group addressed transmissions, having a delivery mode sub-field value of 0b11 18
shall contain a source endpoint field and group address field, but no destination 19
endpoint field. Note that other endpoints on the source device are legal group 20
members and possible destinations for group-addressed frames. 21
22
For all devices where the transmission is due to a binding table entry stored on the 23
source device, the APSDE of the source device shall determine whether the 24
binding table entry contains a unicast destination device address or a destination 25
group address. In the case where a binding table entry contains a unicast 26
destination device address and this destination device address is that of the source 27
device itself, the APSDE shall issue an APSDE-DATA.indication primitive to the 28
next higher layer and shall not transmit a frame. Otherwise, the APSDE shall 29
transmit the frame to the 16-bit NWK address corresponding to the destination 30
address indicated by the binding table entry, and the delivery mode sub-field of 31
the frame control field shall be set to 0b00. In the case where the binding table 32
entry contains a destination group address and nwkUseMulticast is FALSE, the 33
delivery mode sub-field of the frame control field shall have a value of 0b11, the 34
destination group address shall be placed in the APS header, and the destination 35
endpoint shall be omitted. The frame shall then be broadcast using the NLDE- 36
DATA.request primitive and employing a broadcast address of 0xfffd. In the case 37
where the binding table entry contains a destination group address and 38
nwkUseMulticast is TRUE, the delivery mode sub-field of the frame control field 39
shall have a value of 0b10 and the destination endpoint shall have a value of 0xff. 40
The frame shall then be multicast using the NLDE-DATA.request primitive and 41
employing the group address supplied in the binding table entry. 42
If security is required, the frame shall be processed as described in clause 4.4. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 67

If fragmentation is required, and is permitted for this frame, then the frame shall
be processed as described in clause 2.2.8.4.5. 1
2
When the frame is constructed and ready for transmission, it shall be passed to the 3
NWK data service with suitable destination and source addresses. In addition, the 4
APS layer shall ensure that route discovery is enabled at the network layer. An 5
APDU transmission is initiated by issuing the NLDE-DATA.request primitive to 6
the NWK layer and the results of the transmission returned via the NLDE- 7
DATA.confirm primitive. 8
2.2.8.4.2 Reception and Rejection 9
10
The APS sub-layer shall be able to filter frames arriving via the NWK layer data 11
service and only present the frames that are of interest to the NHLE. 12
If the APSDE receives a secured frame, it shall process the frame as described in 13
clause 4.4 to remove the security. 14
15
If the APSDE receives a frame containing the destination endpoint field, then the 16
APSDE shall pass it directly to the NHLE at the destination endpoint supplied, 17
unless it is part of an incomplete fragmented transmission or it is determined to 18
have been a duplicate of a frame that has been passed up previously. Subject to the 19
same incomplete fragmented transmission and duplicate frame detection, if the 20
destination endpoint is set to the broadcast endpoint (0xff) and the DstAddrMode 21
parameter of the received NLDE-DATA.indication primitive was not 0x01, then 22
the APSDE shall also present the frame to all non-reserved endpoints (0x01-0xf0) 23
supported by the NHLE. 24
If the APSDE of a device receives a transmission with the delivery mode sub-field 25
of the frame control field set to 0b11, indicating group addressing, it shall deliver 26
the frame to each endpoint on the device that is associated in the group table with 27
the 16-bit group address found in the group address field of the APS header. 28
Similarly, if the APSDE of a device receives a NLDE-DATA.indication primitive 29
where the DstAddrMode parameter has a value of 0x01, also indicating group 30
addressing, it shall deliver the frame to each endpoint on the device that is 31
associated in the group table with the 16-bit group address given as the value of 32
the DstAddr parameter. In either case, it shall search the group table and, for each 33
endpoint associated with the given group address, it shall issue the NLDE- 34
DATA.indication primitive to the next higher layer with a value of the 35
DstEndpoint parameter equal to the number of the associated endpoint. All other 36
parameters of the NLDE-DATA.indication primitive shall remain the same for all 37
instances of the primitive issued. 38
39
The APSDE shall maintain a duplicate rejection table to include at least source 40
address, APS counter, and timing information, such that frames transmitted 41
according to this specification and received more than once are identified as 42
duplicates and only delivered to the NHLE once. The size of this table shall be at 43
least apscMinDuplicateRejectionTableSize. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
68 Application Layer Specification

2.2.8.4.3 Use of Acknowledgements


1
A data or APS command frame shall be sent with its acknowledgement request 2
sub-field set appropriately for the frame. An acknowledgement frame shall always 3
be sent with the acknowledgement request sub-field set to 0. Similarly, any frame 4
that is broadcast or multicast shall be sent with its acknowledgement request sub- 5
field set to 0. 6
7
2.2.8.4.3.1 No Acknowledgement 8
9
A frame that is received by its intended recipient with its acknowledgement
10
request (AR) sub-field set to 0 shall not be acknowledged. The originating device
11
shall assume that the transmission of the frame was successful. Figure 2.10 shows
12
the scenario for transmitting a single frame of data from an originator to a
13
recipient without requiring an acknowledgement. In this case, the originator
14
transmits the data frame with the AR sub-field equal to 0.
15
16
Originator Recipient 17
next higher Originator Recipient next higher
APS APS
18
layer layer
19
APSDE-DATA.request (AR=0) 20
Data (AR=0)
APSDE-DATA.indication
21
APSDE-DATA.confirm
22
23
24
25
Figure 2.10 Successful Data Transmission Without an Acknowledgement 26
27
2.2.8.4.3.2 Acknowledgement 28
29
A frame that is received by its intended recipient with its acknowledgement
30
request (AR) sub-field set to 1 shall be acknowledged. If the intended recipient
31
correctly receives the frame, it shall generate and send an acknowledgement
32
frame to the originator of the frame that is being acknowledged.
33
The transmission of an acknowledgement frame shall commence when the APS 34
sub-layer determines that the frame is valid. 35
36
Figure 2.11 shows the scenario for transmitting a single frame of data from an
37
originator to a recipient with an acknowledgement. In this case, the originator
38
indicates to the recipient that it requires an acknowledgement by transmitting the
39
data frame with the AR sub-field set to 1.
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 69

Originator Recipient 1
next higher Originator Recipient next higher
layer APS APS layer 2
APSDE-DATA.request (AR=1)
3
Data (AR=1) 4
5
Acknowldgement
6
APSDE-DATA.indication
7
APSDE-DATA.confirm 8
9
10
11
Figure 2.11 Successful Data Transmission With an Acknowledgement 12
13
2.2.8.4.4 Retransmissions 14
A device that sends a frame with its acknowledgement request sub-field set to 0 15
shall assume that the transmission was successfully received and shall hence not 16
perform the retransmission procedure. 17
18
A device that sends a frame with its acknowledgement request sub-field set to 1 19
shall wait for a maximum of apscAckWaitDuration seconds for the corresponding 20
acknowledgement frame to be received. 21
If an acknowledgement frame is received within apscAckWaitDuration seconds, 22
containing the same cluster identifier and APS counter as the original frame and 23
has a source endpoint equal to the destination endpoint to which the original frame 24
was transmitted, the transmission shall be considered successful and no further 25
action shall be taken by the device. If an acknowledgement is not received within 26
apscAckWaitDuration seconds, or an acknowledgement is received within 27
apscAckWaitDuration seconds but contains an unexpected cluster identifier or 28
APS counter or has a source endpoint that is not equal to the destination endpoint 29
to which the original frame was transmitted, the device shall conclude that the 30
single transmission attempt has failed. 31
32
If a single transmission attempt has failed, the device shall repeat the process of 33
transmitting the frame and waiting for the acknowledgement, up to a maximum of 34
apscMaxFrameRetries times. If an acknowledgement is still not received after 35
apscMaxFrameRetries retransmissions, the APS sub-layer shall assume the 36
transmission has failed and notify the next higher layer of the failure. 37
Retransmissions of a secured frame shall use the same frame counter as the 38
original frame. 39
40
2.2.8.4.5 Fragmented Transmissions 41
Where an ASDU is too large to be transmitted within a single MAC data frame, an 42
acknowledged unicast transmission was requested, and fragmentation is permitted 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
70 Application Layer Specification

for this frame, the ASDU shall be fragmented into a number of smaller byte
strings, here referred to as “blocks.” Each block is transmitted in a separate frame. 1
2
A “transmission window” is used to arrange an orderly transaction. The window 3
size is set by the stack profile, and may be set as high as eight blocks. The protocol 4
below arranges that all blocks in a transmission window must be received and 5
acknowledged before the window can move on. An acknowledgement is sent 6
when all blocks in the transmission window have been successfully received or, 7
according to the protocol below, to request retransmission of one or more 8
unreceived blocks. 9
Transactions not using APS acknowledgements may not be fragmented. Multicast 10
and broadcast transmissions are not permitted to use fragmentation. 11
12
2.2.8.4.5.1 Transmission 13
14
All blocks in a fragmented transmission shall have the same APS Counter value. 15
The extended header sub-frame shall be included in the frame. The fragmentation 16
sub-field of the extended frame control field shall be set to 0b01 for the first block 17
and 0b10 for all subsequent blocks of the a fragmented transmission. The block 18
number field shall indicate the total number of blocks in the transmission in the 19
first block, shall take the value 0x01 in the second block, and thereafter shall be 20
incremented for each subsequent block. 21
A transmission window shall be maintained, initially covering blocks 0 to 22
(apscMaxWindowSize-1), or the total number of blocks if this is less. 23
24
If security is required, then each frame shall be processed independently, as 25
described in clause 4. Following transmission of each block, the APS shall start a 26
timer. If there are more unacknowledged blocks to send in the current 27
transmission window, then after a delay of apsInterframeDelay milliseconds the 28
next block shall be passed to the NWK data service. Otherwise, the timer shall be 29
set for apscAckWaitDuration seconds. 30
A retryCounter parameter shall be maintained and is reset to zero for each new 31
transaction. If an apscAckWaitDuration timer expires, then the block with the 32
lowest unacknowledged block number shall be passed to the NWK data service 33
again, and the retryCounter parameter shall be incremented. If the retryCounter 34
parameter reaches the value apscMaxFrameRetries, the transaction shall be 35
deemed to have failed, and an APSDE-DATA.confirm primitive returned to the 36
NHLE with a status value of NO_ACK. 37
38
On receipt of an acknowledgement frame with matching values in the APS 39
counter, block number, and addressing fields, outgoing blocks are acknowledged 40
as described in the section below. If at least one previously unacknowledged block 41
is acknowledged, then the timer shall be stopped and the retryCounter parameter 42
reset. If all blocks in the current transmission window have been acknowledged, 43
then the transmission window shall be increased by apscMaxWindowSize. If all 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 71

blocks have now been transmitted and acknowledged, then the transaction is
complete, and an APSDE-DATA.confirm primitive shall be returned to the NHLE 1
with a status value of SUCCESS. Otherwise, the block with the lowest 2
unacknowledged block number shall be passed to the NWK data service. 3
4
2.2.8.4.5.2 Reception and Rejection, and Acknowledgements 5
6
If the fields required for a fragmentation-enabled transmission are not present in 7
the frame it shall be rejected. Also, any frames with parameters that fall outside 8
the bounds of this protocol shall be rejected. 9
If an incoming fragmented transaction is already in progress but the addressing 10
and APS counter fields do not match those of the received frame, then the 11
received frame may optionally be rejected or handled independently as a further 12
transaction. 13
14
If no transaction is in progress and a fragmented frame is received, then 15
reassembly shall be attempted. Initially the receive window shall be from 0 to 16
(apscMaxWindowSize-1). 17
If a transaction is initiated with APS counter and source address field values 18
matching a previously received transaction, then the new transaction may be 19
rejected as a duplicate. 20
21
If the receive window does not move forward within any (apscAckWaitDuration 22
+ apscAckWaitDuration * apscMaxFrameRetries) time period, the transaction 23
shall be deemed to have failed. The receiver shall send an acknowledgement to 24
the sender with the block or blocks missed.5 25
If all blocks in the current receive window have been received and a block is 26
received with a block number higher than the current receive window, then the 27
receive window shall be increased by apsMaxWindowSize blocks. 28
29
If the last block in the transaction is received, or if a block is received with its 30
block number value equal to or higher than the highest previously 31
unacknowledged block number in the window, then an acknowledgement shall be 32
generated. 33
Once all blocks in the transaction have been received, the APS shall issue an 34
APSDE-DATA.indication primitive containing the reassembled message, and the 35
transaction shall be deemed to be complete. A period of persistence of 36
apscAckWaitDuration seconds is encouraged in order to facilitate any 37
retransmission of the final acknowledgement. 38
39
Where generated, the acknowledgement is formatted according to the 40
acknowledgement frame format specified in sub-clause 2.2.5.2.3. The APS 41
counter field shall reflect the value in the corresponding field of the frame(s) 42
43
5. CCB #817 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
72 Application Layer Specification

being acknowledged. The block number field shall contain the value of the lowest
block number in the current receive window, using the value 0 as the value of the 1
first block. 2
3
The first bit of the ack bitfield shall be set to 1 if the first fragment in the current 4
receive window has been correctly received, and 0 otherwise. Subsequent bits 5
shall be set similarly, with values corresponding to subsequent fragments in the 6
current receive window. If apsMaxWindowSize is less than 8, then the remaining 7
bits shall be set to 1. 8
The process is illustrated in the following diagrams. In Figure 2.12, the 9
transmission is successful immediately. (These examples assume that 10
apscMaxWindowSize takes the value 3). 11
12
13
Originator Recipient
14
next higher
Originator
APS
Recipient
APS
next higher 15
layer layer
16
17
APSDE-DATA.request
Data (first fragment,
18
block number=5) 19
Data (block number=1, …)
20
21
Data (block number=2, …)
22
Acknowledgement
(block number=0, …,
23
Ack bitfield=0xFF) 24
Data (block number=3, …) 25
26
Data (block number=4, …)
27
Acknowledgement
(block number=3, …, APSDE-DATA.indication
28
APSDE-DATA.confirm
Ack bitfield=0xFF) 29
30
31
32
33
34
35
Figure 2.12 Successful Data Transmission With Fragmentation
36
37
In Figure 2.13, a single frame is lost during transit across the network, and is
38
retransmitted.
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 73

Originator Recipient
1
Originator Recipient
next higher
APS APS
next higher 2
layer layer
3
4
APSDE-DATA.request
Data (first fragment,
5
block number=5) 6
Data (block number=1, …)
7
8
Data (block number=2, …)
9
Acknowledgement
(block number=0, …, 10
Ack bitfield=0xFD) 11
Data (block number=1, …) 12
Acknowledgement 13
(block number=0, …, 14
Ack bitfield=0xFF)
15
Data (block number=3, …) 16
Data (block number=4, …) 17
Acknowledgement 18
(block number=3, …, APSDE-DATA.indication 19
Ack bitfield=0xFF)
APSDE-DATA.confirm 20
21
22
Figure 2.13 Fragmented Data Transmission With a Single Retransmission
23
24
In Figure 2.14, multiple frames are lost in the network, including a frame which
25
has the highest block number in the window. Slightly more traffic is required in
26
this case, but the source backs off and gives the network a chance to recover, and
27
the ASDU is delivered successfully.
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
74 Application Layer Specification

Originator Recipient 1
Originator Recipient
next higher
APS APS
next higher 2
layer layer
3
APSDE-DATA.request
Data (first fragment, 4
block number=5) 5
Data (block number=1, …) 6
7
Data (block number=2, …)
8
apsFragmentation-
RetryTimeout 9
seconds Data (block number=0, …) 10
Data (block number=1, …) 11
Data (block number=2, …)
12
Acknowledgement
13
(block number=0, …, 14
Ack bitfield=0xFF) 15
Data (block number=3, …) 16
Data (block number=4, …) 17
Acknowledgement 18
(block number=3, …, APSDE-DATA.indication 19
Ack bitfield=0xFF)
APSDE-DATA.confirm 20
21
22
Figure 2.14 Fragmented Data Transmission With Multiple Retransmissions
23
24
2.2.9 APS Sub-Layer Status Values 25
26
Application support (APS) sub-layer confirm primitives often include a parameter 27
that reports on the status of the request to which the confirmation applies. Values 28
for APS sub-layer Status parameters appear in Table 2.26. 29
Table 2.26 APS Sub-layer Status Values 30
31
Name Value Description 32
SUCCESS 0x00 A request has been executed successfully.
33
34
ASDU_TOO_LONG 0xa0 A transmit request failed since the ASDU is 35
too large and fragmentation is not supported.
36
DEFRAG_DEFERRED 0xa1 A received fragmented frame could not be 37
defragmented at the current time. 38
DEFRAG_UNSUPPORTED 0xa2 A received fragmented frame could not be 39
defragmented since the device does not 40
support fragmentation. 41
ILLEGAL_REQUEST 0xa3 A parameter value was out of range. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 75

Table 2.26 APS Sub-layer Status Values (Continued)


1
Name Value Description 2
INVALID_BINDING 0xa4 An APSME-UNBIND.request failed due to 3
the requested binding link not existing in the 4
binding table. 5
INVALID_GROUP 0xa5 An APSME-REMOVE-GROUP.request has 6
been issued with a group identifier that does 7
not appear in the group table. 8
INVALID_PARAMETER 0xa6 A parameter value was invalid or out of 9
range. 10
11
NO_ACK 0xa7 An APSDE-DATA.request requesting
acknowledged transmission failed due to no 12
acknowledgement being received. 13
14
NO_BOUND_DEVICE 0xa8 An APSDE-DATA.request with a destination
addressing mode set to 0x00 failed due to 15
there being no devices bound to this device. 16
17
NO_SHORT_ADDRESS 0xa9 An APSDE-DATA.request with a destination
addressing mode set to 0x03 failed due to no 18
corresponding short address found in the 19
address map table. 20
NOT_SUPPORTED 0xaa An APSDE-DATA.request with a destination
21
addressing mode set to 0x00 failed due to a 22
binding table not being supported on the 23
device. 24
SECURED_LINK_KEY 0xab An ASDU was received that was secured 25
using a link key. 26
27
SECURED_NWK_KEY 0xac An ASDU was received that was secured
using a network key. 28
29
SECURITY_FAIL 0xad An APSDE-DATA.request requesting 30
security has resulted in an error during the
corresponding security processing. 31
32
TABLE_FULL 0xae An APSME-BIND.request or APSME.ADD- 33
GROUP.request issued when the binding or
group tables, respectively, were full. 34
35
UNSECURED 0xaf An ASDU was received without any security. 36
UNSUPPORTED_ATTRIBUTE 0xb0 An APSME-GET.request or APSME- 37
SET.request has been issued with an 38
unknown attribute identifier. 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
76 Application Layer Specification

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 a 8
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: manufacturer-specific and public. 22
The exact definition and criteria for these classes are an administrative issue 23
within the ZigBee Alliance and outside the scope of this document. For the 24
purposes of this technical specification, the only criterion is for profile identifiers 25
to be unique. To that end, every profile effort must start with a request to the 26
ZigBee Alliance for allocation of a profile identifier. Once the profile identifier is 27
obtained, that profile identifier permits the profile designer to define the 28
following: 29
30
• Device descriptions
31
• Cluster identifiers 32
33
The application of profile identifiers to market space is a key criterion for issuance
34
of a profile identifier from the ZigBee Alliance. The profile needs to cover a broad
35
enough range of devices to permit interoperability to occur between devices,
36
without being overly broad and resulting in a shortage of cluster identifiers to
37
describe their interfaces. Conversely, the profile cannot be defined to be too
38
narrowly, resulting in many devices described by individual profile identifiers,
39
resulting in a waste of the profile identifier addressing space and interoperability
40
issues in describing how the devices are interfaced. Policy groups within the
41
ZigBee Alliance will establish criteria on how profiles are to be defined and to
42
help requestors tailor their profile identifier requests.
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 77

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 contains up to 10
65,536 attributes. It is the responsibility of the profile developer to define and 11
allocate device descriptions, cluster identifiers, and attributes within their 12
allocated profile identifier. Note that the definition of device descriptions, cluster 13
identifiers, and attribute identifiers must be undertaken with care to ensure 14
efficient creation of simple descriptors and simplified processing when 15
exchanging messages. 16
17
For public profile identifiers defined within the ZigBee Alliance, a cluster library
18
has been created which provides a common definition and enumeration of clusters
19
and their attributes. The cluster library is designed to sponsor re-use of cluster and
20
attribute definitions across application profiles. By convention, when public
21
profiles employ the cluster library, they will share a common enumeration and
22
definition of cluster and attribute identifiers.
23
Device descriptions and cluster identifiers must be accompanied by knowledge of 24
the profile identifier to be processed. Prior to any messages being directed to a 25
device, it is assumed by the ZigBee protocol that service discovery has been 26
employed to determine profile support on devices and endpoints. Likewise, the 27
binding process assumes similar service discovery and profile matching has 28
occurred, since the resulting match is distilled to source address, source endpoint, 29
cluster identifier, destination address, and destination endpoint. 30
31
2.3.1.3 Deploying the Profile on Endpoints 32
33
A single ZigBee device may contain support for many profiles, provide for 34
subsets of various cluster identifiers defined within those profiles, and may 35
support multiple device descriptions. This capability is defined using a hierarchy 36
of addressing within the device as follows: 37
• Device: the entire device is supported by a single radio with a unique IEEE and 38
NWK address. 39
40
• Endpoints: this is an 8-bit field that describes different applications that are 41
supported by a single radio. Endpoint 0x00 is used to address the device 42
profile, which each ZigBee device must employ, endpoint 0xff is used to 43
address all active endpoints (the broadcast endpoint) and endpoints 0xf1-0xfe 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
78 Application Layer Specification

are reserved. Consequently, a single physical ZigBee radio can support up to


240 applications on endpoints 0x01-0xf0. 1
2
It is an application decision as to how to deploy applications on a device endpoint 3
and which endpoints to advertise. The only requirement is that simple descriptors 4
be created for each endpoint and those descriptors made available for service 5
discovery. 6
7
2.3.1.4 Enabling Service Discovery 8
Once a device is created to support specific profiles and made consistent with 9
cluster identifier usage for device descriptions within those profiles, the 10
applications can be deployed. To do this, each application is assigned to individual 11
endpoints and each described using simple descriptors (an endpoint can support 12
only a single application profile). It is via the simple descriptors and other service 13
discovery mechanisms described in the ZigBee device profile that service 14
discovery is enabled, binding of devices is supported, and application messaging 15
between complementary devices is facilitated. 16
17
One important point is that service discovery is made on the basis of profile 18
identifier, input cluster identifier list, and output cluster identifier list (device 19
description is notably missing). The device description is simply a convention for 20
specifying mandatory and optional cluster identifier support within devices of that 21
type for the indicated profile. Additionally, it is expected that the device 22
description enumeration would be employed within PDAs or other assisted 23
binding devices to provide external descriptions of device capabilities. 24
25
2.3.1.5 Mixing Standard and Proprietary Profiles 26
As an example, a ZigBee device could be developed to ZigBee public profile 27
identifier “XX.” If a manufacturer wanted to deploy a ZigBee device supporting 28
public profile “XX” and also provide manufacturer specific extensions, these 29
extensions could be added to the manufacturer’s implementation of public profile 30
“XX” if manufacturer extensions are supported within the definition of profile 31
“XX.” Alternatively, if manufacturer extensions are not supported or the type of 32
desired manufacturer extensions aren’t supported in profile “XX,” the 33
manufacturer may deploy the extensions in a separate manufacturer-specific 34
profile identifier advertised on a separate endpoint within the same physical 35
device. In either case, devices that support the profile identifier “XX” but not 36
containing the manufacturer extensions, would only advertise support for the base 37
features of public profile identifier “XX” and could not respond to or create 38
messages using the manufacturer extensions. 39
40
2.3.1.6 Enabling Backward Compatibility 41
42
In the previous example, a device is created using ZigBee public profile identifier 43
“XX.” If the ZigBee Alliance were to update this public profile at a later time to 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 79

add new features, the revisions could either be incorporated directly into public
profile identifier “XX” if such extensions are supported via the definition of the 1
profile, or could be introduced into a new public profile with a new profile 2
identifier (say “XY”). Assuming extensibility is not supported in public profile 3
“XX,” devices manufactured with just profile identifier “XX” could still be 4
compatible with newer devices manufactured later by having the newer devices 5
advertise support for both profile identifier “XX” and profile identifier “XY.” In 6
this manner, the newer device may communicate with older devices using profile 7
identifier “XX,” however, it may also communicate with newer devices using 8
profile identifier “XY” from within the same application. The service discovery 9
feature within ZigBee enables devices on the network to determine the level of 10
support. 11
12
It is the goal of the ZigBee Alliance to provide extensibility, both for 13
manufacturer extensions to public profiles as well as future enhancements to 14
public profiles. That goal includes maintaining those extensions and 15
enhancements within the same profile identifier whenever possible. This section 16
illustrates that the profile definition features within ZigBee permit deployment of 17
manufacturer extensions and feature enhancements, whether the goal of profile 18
extensibility is achievable or not. The subject of profile extensibility, both for 19
manufacturer extensions and feature enhancements, is beyond the scope of this 20
document and addressed in other Alliance documents. 21
22
2.3.2 ZigBee Descriptors 23
24
ZigBee devices describe themselves using descriptor data structures. The actual 25
data contained in these descriptors is defined in the individual device descriptions. 26
There are five descriptors: node, node power, simple, complex, and user, shown in 27
Table 2.27. 28
29
Table 2.27 ZigBee Descriptors
30
Descriptor 31
Name Status Description 32
33
Node M Type and capabilities of the node.
34
Node power M Node power characteristics. 35
Simple M Device descriptions contained in node. 36
37
Complex O Further information about the device descriptions.
38
User O User-definable descriptor. 39
40
2.3.2.1 Transmission of Descriptors 41
42
The node, node power, simple, and user descriptors shall be transmitted in the 43
order that they appear in their respective tables, i.e., the field at the top of the table 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
80 Application Layer Specification

is transmitted first and the field at the bottom of the table is transmitted last. Each
individual field shall follow the transmission order specified in sub-clause 1.2.1.4. 1
2
Each descriptor shall be less than or equal to apscMaxDescriptorSize unless 3
provision has been made to enable transmission of discovery information without 4
the mandatory use of fragmentation. 5
In the case of the Simple Descriptor (see 2.3.2.5), transmission primitives exist 6
which permit the descriptor to extend beyond apscMaxDescriptorSize (see 7
2.4.3.1.21 and 2.4.4.1.20). When extended transmission primitives are employed, 8
the standard transmission primitives (see 2.4.3.1.5 and 2.4.4.1.5) require 9
transmission of an abbreviated Simple Descriptor, and the Node Descriptor of the 10
device shall indicate availability of extended transmission primitives (see 11
2.3.2.3.12). 12
13
The complex descriptor shall be formatted and transmitted as illustrated in 14
Figure 2.15. 15
16
Octets: 1 Variable … Variable 17
Field count Field 1 … Field n 18
19
Figure 2.15 Format of the Complex Descriptor
20
21
Each field included in the complex descriptor shall be formatted as illustrated in 22
Figure 2.16. 23
24
Octets: 1 Variable 25
26
Compressed Field data 27
XML tag 28
Figure 2.16 Format of an Individual Complex Descriptor Field 29
30
2.3.2.1.1 Field Count Field 31
32
The field count field is one octet in length and specifies the number of fields 33
included in the Complex Descriptor, each formatted as illustrated in Figure 2.16. 34
35
2.3.2.1.1.1 Compressed XML Tag Field 36
The compressed XML tag field is one octet in length and specifies the XML tag 37
for the current field. The compressed XML tags for the complex descriptor are 38
listed in Table 2.40. 39
40
41
2.3.2.1.1.2 Field Data Field
42
The field data field has a variable length and contains the information specific to 43
the current field, as indicated by the compressed XML tag field. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 81

2.3.2.2 Discovery via Descriptors


1
Descriptor information is queried in the ZDO management entity device and 2
service discovery, using the ZigBee device profile request primitive addressed to 3
endpoint 0. For details of the discovery operation, see sub-clause 2.4.2.1. 4
Information is returned via the ZigBee device profile indication primitive. 5
6
The node, node power, complex, and user descriptors apply to the complete node.
7
The simple descriptor must be specified for each endpoint defined in the node. If a
8
node contains multiple subunits, these will be on separate endpoints and the
9
specific descriptors for these endpoints are read by including the relevant endpoint
10
number in the ZigBee device profile primitive.
11
2.3.2.3 Node Descriptor 12
13
The node descriptor contains information about the capabilities of the ZigBee 14
node and is mandatory for each node. There shall be only one node descriptor in a 15
node. 16
17
The fields of the node descriptor are shown in Table 2.28 in their order of 18
transmission. 19
Table 2.28 Fields of the Node Descriptor 20
21
Field Name Length (Bits)
22
Logical type 3 23
Complex descriptor available 1 24
25
User descriptor available 1 26
Reserved 3 27
28
APS flags 3
29
Frequency band 5 30
MAC capability flags 8 31
32
Manufacturer code 16
33
Maximum buffer size 8 34
Maximum incoming transfer size 16 35
36
Server mask 16
37
Maximum outgoing transfer size 16 38
Descriptor capability field 8 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
82 Application Layer Specification

2.3.2.3.1 Logical Type Field


1
The logical type field of the node descriptor is three bits in length and specifies the 2
device type of the ZigBee node. The logical type field shall be set to one of the 3
non-reserved values listed in Table 2.29. 4
Table 2.29 Values of the Logical Type Field 5
6
Logical Type Value 7
b 2b1b0 Description
8
000 ZigBee coordinator 9
10
001 ZigBee router
11
010 ZigBee end device 12
011-111 Reserved 13
14
2.3.2.3.2 Complex Descriptor Available Field 15
16
The complex descriptor available field of the node descriptor is one bit in length 17
and specifies whether a complex descriptor is available on this device. If this field 18
is set to 1, a complex descriptor is available. If this field is set to 0, a complex 19
descriptor is not available. 20
21
2.3.2.3.3 User Descriptor Available Field
22
The user descriptor available field of the node descriptor is one bit in length and 23
specifies whether a user descriptor is available on this device. If this field is set to 24
1, a user descriptor is available. If this field is set to 0, a user descriptor is not 25
available. 26
27
2.3.2.3.4 APS Flags Field 28
The APS flags field of the node descriptor is three bits in length and specifies the 29
application support sub-layer capabilities of the node. 30
31
This field is currently not supported and shall be set to zero. 32
2.3.2.3.5 Frequency Band Field 33
34
The frequency band field of the node descriptor is five bits in length and specifies 35
the frequency bands that are supported by the underlying IEEE 802.15.4 radio 36
utilized by the node. For each frequency band supported by the underlying IEEE 37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 83

802.15.4 radio, the corresponding bit of the frequency band field, as listed in
Table 2.30, shall be set to 1. All other bits shall be set to 0. 1
2
Table 2.30 Values of the Frequency Band Field
3
Frequency 4
Band Field Bit Supported 5
Number Frequency Band 6
0 868 – 868.6 MHz 7
8
1 Reserved 9
2 902 – 928 MHz 10
3 2400 – 2483.5 MHz
11
12
4 Reserved 13
14
2.3.2.3.6 MAC Capability Flags Field 15
16
The MAC capability flags field is eight bits in length and specifies the node 17
capabilities, as required by the IEEE 802.15.4-2003 MAC sub-layer [B1]. The 18
MAC capability flags field shall be formatted as illustrated in Figure 2.17. 19
Bits: 0 1 2 3 4-5 6 7 20
21
Alternate Device Power Receiver on Reserved Security Allocate 22
PAN type source when idle capability address 23
coordinator
24
Figure 2.17 Format of the MAC Capability Flags Field 25
26
The alternate PAN coordinator sub-field is one bit in length and shall be set to 1 if 27
this node is capable of becoming a PAN coordinator. Otherwise, the alternative 28
PAN coordinator sub-field shall be set to 0. 29
30
The device type sub-field is one bit in length and shall be set to 1 if this node is a
31
full function device (FFD). Otherwise, the device type sub-field shall be set to 0,
32
indicating a reduced function device (RFD).
33
The power source sub-field is one bit in length and shall be set to 1 if the current 34
power source is mains power. Otherwise, the power source sub-field shall be set to 35
0. This information is derived from the node current power source field of the 36
node power descriptor. 37
38
The receiver on when idle sub-field is one bit in length and shall be set to 1 if the
39
device does not disable its receiver to conserve power during idle periods.
40
Otherwise, the receiver on when idle sub-field shall be set to 0 (see also sub-
41
clause 2.3.2.4.)
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
84 Application Layer Specification

The security capability sub-field is one bit in length and shall be set to 1 if the
device is capable of sending and receiving frames secured using the security suite 1
specified in [B1]. Otherwise, the security capability sub-field shall be set to 0. 2
3
The allocate address sub-field is one bit in length and shall be set to 0 or 1.6 4
2.3.2.3.7 Manufacturer Code Field 5
6
The manufacturer code field of the node descriptor is sixteen bits in length and 7
specifies a manufacturer code that is allocated by the ZigBee Alliance, relating the 8
manufacturer to the device. 9
2.3.2.3.8 Maximum Buffer Size Field 10
11
The maximum buffer size field of the node descriptor is eight bits in length, with a 12
valid range of 0x00-0x7f. This field specifies the maximum size, in octets, of the 13
network sub-layer data unit (NSDU) for this node. This is the maximum size of 14
data or commands passed to or from the application by the application support 15
sub-layer, before any fragmentation or re-assembly. 16
This field can be used as a high-level indication for network management. 17
18
2.3.2.3.9 Maximum Incoming Transfer Size Field 19
20
The maximum transfer size field of the node descriptor is sixteen bits in length,
21
with a valid range of 0x0000-0x7fff. This field specifies the maximum size, in
22
octets, of the application sub-layer data unit (ASDU) that can be transferred to this
23
node in one single message transfer. This value can exceed the value of the node
24
maximum buffer size field (see sub-clause 2.3.2.3.8) through the use of
25
fragmentation.
26
2.3.2.3.10 Server Mask Field 27
28
The server mask field of the node descriptor is sixteen bits in length, with bit 29
settings signifying the system server capabilities of this node. It is used to 30
facilitate discovery of particular system servers by other nodes on the system. The 31
bit settings are defined inTable 2.31. 32
Table 2.31 Server Mask Bit Assignments 33
34
Bit Number Assignment
35
0 Primary Trust Center 36
1 Backup Trust Center 37
38
2 Primary Binding Table Cache 39
3 Backup Binding Table Cache 40
41
4 Primary Discovery Cache
42
43
6. CCB #841 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 85

Table 2.31 Server Mask Bit Assignments (Continued)


1
Bit Number Assignment 2
5 Backup Discovery Cache 3
4
6 Network Manager
5
7 – 15 Reserved 6
7
2.3.2.3.11 Maximum Outgoing Transfer Size Field 8
9
The maximum transfer size field of the node descriptor is sixteen bits in length, 10
with a valid range of 0x0000-0x7fff. This field specifies the maximum size, in 11
octets, of the application sub-layer data unit (ASDU) that can be transferred from 12
this node in one single message transfer. This value can exceed the value of the 13
node maximum buffer size field (see sub-clause 2.3.2.3.8) through the use of 14
fragmentation. 15
2.3.2.3.12 Descriptor Capability Field 16
17
The descriptor capability field of the node descriptor is eight bits in length, with 18
bit settings signifying the descriptor capabilities of this node. It is used to facilitate 19
discovery of particular features of the descriptor fields by other nodes on the 20
system. The bit settings are defined in Table 2.32. 21
Table 2.32 Descriptor Capability Bit Assignments 22
23
Bit Number Assignment 24
0 Extended Active Endpoint List Available 25
26
1 Extended Simple Descriptor List Available
27
2-7 Reserved 28
29
2.3.2.4 Node Power Descriptor 30
31
The node power descriptor gives a dynamic indication of the power status of the 32
node and is mandatory for each node. There shall be only one node power 33
descriptor in a node. 34
35
The fields of the node power descriptor are shown in Table 2.33 in the order of
36
their transmission.
37
Table 2.33 Fields of the Node Power Descriptor 38
Field Name Length (Bits) 39
40
Current power mode 4 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
86 Application Layer Specification

Table 2.33 Fields of the Node Power Descriptor (Continued)


1
Available power sources 4
2
Current power source 4 3
Current power source level 4 4
5
6
2.3.2.4.1 Current Power Mode Field
7
The current power mode field of the node power descriptor is four bits in length 8
and specifies the current sleep/power-saving mode of the node. The current power 9
mode field shall be set to one of the non-reserved values listed in Table 2.34. 10
Table 2.34 Values of the Current Power Mode Field
11
12
Current Power Mode 13
Value b3b2b1b0 Description 14
0000 Receiver synchronized with the receiver on when idle sub- 15
field of the node descriptor. 16
17
0001 Receiver comes on periodically as defined by the node
power descriptor. 18
19
0010 Receiver comes on when stimulated, e.g. by a user pressing a 20
button.
21
0011-1111 Reserved. 22
23
2.3.2.4.2 Available Power Sources Field 24
25
The available power sources field of the node power descriptor is four bits in 26
length and specifies the power sources available on this node. For each power 27
source supported on this node, the corresponding bit of the available power sources 28
field, as listed in Table 2.35, shall be set to 1. All other bits shall be set to 0. 29
Table 2.35 Values of the Available Power Sources Field 30
31
Available Power Sources 32
Field Bit Number Supported Power Source
33
0 Constant (mains) power 34
1 Rechargeable battery 35
36
2 Disposable battery 37
3 Reserved 38
39
2.3.2.4.3 Current Power Source Field 40
41
The current power source field of the node power descriptor is four bits in length 42
and specifies the current power source being utilized by the node. For the current 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 87

power source selected, the corresponding bit of the current power source field, as
listed in Table 2.36, shall be set to 1. All other bits shall be set to 0. 1
2
Table 2.36 Values of the Current Power Sources Field
3
Current Power Source 4
Field Bit Number Current Power Source 5
6
0 Constant (mains) power
7
1 Rechargeable battery 8
2 Disposable battery 9
10
3 Reserved
11
12
2.3.2.4.4 Current Power Source Level Field 13
The current power source level field of the node power descriptor is four bits in 14
length and specifies the level of charge of the power source. The current power 15
source level field shall be set to one of the non-reserved values listed in 16
Table 2.37. 17
18
Table 2.37 Values of the Current Power Source Level Field 19
Current Power Source 20
Level Field b3b2b1b0 Charge Level 21
22
0000 Critical 23
0100 33% 24
1000 66%
25
26
1100 100% 27
All other values Reserved 28
29
30
2.3.2.5 Simple Descriptor 31
The simple descriptor contains information specific to each endpoint contained in 32
this node. The simple descriptor is mandatory for each endpoint present in the 33
node. 34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
88 Application Layer Specification

The fields of the simple descriptor are shown in Table 2.38 in their order of
transmission. As this descriptor needs to be transmitted over air, the overall length 1
of the simple descriptor shall be less than or equal to apscMaxDescriptorSize. 2
3
Table 2.38 Fields of the Simple Descriptor
4
Field Name Length (Bits) 5
6
Endpoint 8 7
Application profile identifier 16 8
Application device identifier 16 9
10
Application device version 4 11
Reserved 4 12
13
Application input cluster count 8
14
Application input cluster list 16*i (where i is the value of the application 15
input cluster count) 16
Application output cluster count 8 17
Application output cluster list 16*o (where o is the value of the application 18
output cluster count) 19
20
21
2.3.2.5.1 Endpoint Field
22
The endpoint field of the simple descriptor is eight bits in length and specifies the 23
endpoint within the node to which this description refers. Applications shall only 24
use endpoints 1-240. 25
26
2.3.2.5.2 Application Profile Identifier Field
27
The application profile identifier field of the simple descriptor is sixteen bits in 28
length and specifies the profile that is supported on this endpoint. Profile 29
identifiers shall be obtained from the ZigBee Alliance. 30
31
2.3.2.5.3 Application Device Identifier Field 32
The application device identifier field of the simple descriptor is sixteen bits in 33
length and specifies the device description supported on this endpoint. Device 34
description identifiers shall be obtained from the ZigBee Alliance. 35
36
2.3.2.5.4 Application Device Version Field 37
The application device version field of the simple descriptor is four bits in length 38
and specifies the version of the device description supported on this endpoint. The 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 89

application device version field shall be set to one of the non-reserved values
listed in Table 2.39. 1
2
Table 2.39 Values of the Application Device Version Field
3
Application Device Version 4
Value b3b2b1b0 Description 5
6
0000-1111 Specific values to be set by the
application profile described by the 7
application profile identifier in this 8
descriptor. Default shall be 0000 unless 9
otherwise defined by the application 10
profile. 11
12
2.3.2.5.5 Application Input Cluster Count Field 13
14
The application input cluster count field of the simple descriptor is eight bits in
15
length and specifies the number of input clusters, supported on this endpoint, that
16
will appear in the application input cluster list field. If the value of this field is
17
zero, the application input cluster list field shall not be included.
18
2.3.2.5.6 Application Input Cluster List 19
20
The application input cluster list of the simple descriptor is 16*i bits in length, 21
where i is the value of the application input cluster count field. This field specifies 22
the list of input clusters supported on this endpoint, for use during the service 23
discovery and binding procedures. 24
The application input cluster list field shall be included only if the value of the 25
application input cluster count field is greater than zero. 26
27
2.3.2.5.7 Application Output Cluster Count Field 28
The application output cluster count field of the simple descriptor is eight bits in 29
length and specifies the number of output clusters, supported on this endpoint, that 30
will appear in the application output cluster list field. If the value of this field is 31
zero, the application output cluster list field shall not be included. 32
33
2.3.2.5.8 Application Output Cluster List 34
The application output cluster list of the simple descriptor is 16*o bits in length, 35
where o is the value of the application output cluster count field. This field 36
specifies the list of output clusters supported on this endpoint, for use during the 37
service discovery and binding procedures. 38
39
The application output cluster list field shall be included only if the value of the 40
application output cluster count field is greater than zero. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
90 Application Layer Specification

2.3.2.6 Complex Descriptor


1
The complex descriptor contains extended information for each of the device 2
descriptions contained in this node. The use of the complex descriptor is optional. 3
4
Due to the extended and complex nature of the data in this descriptor, it is
5
presented in XML form using compressed XML tags. Each field of the descriptor,
6
shown in Table 2.40, can therefore be transmitted in any order. As this descriptor
7
needs to be transmitted over air, the overall length of the complex descriptor shall
8
be less than or equal to apscMaxDescriptorSize.
9
Table 2.40 Fields of the Complex Descriptor 10
Compressed 11
XML Tag 12
Value 13
Field Name XML Tag x 1x 0 Data Type 14
Reserved - 00 -
15
16
Language and character set <languageChar> 01 See sub- 17
clause 2.3.2.6.1
18
Manufacturer name <manufacturerName> 02 Character string 19
Model name <modelName> 03 Character string 20
21
Serial number <serialNumber> 04 Character string 22
Device URL <deviceURL> 05 Character string 23
Icon <icon> 06 Octet string
24
25
Icon URL <outliner> 07 Character string 26
Reserved - 08 – ff - 27
28
2.3.2.6.1 Language and Character Set Field 29
30
The language and character set field is three octets in length and specifies the 31
language and character set used by the character strings in the complex descriptor. 32
The format of the language and character set field is illustrated in Figure 2.18. 33
34
Octets: 2 1 35
36
ISO 639-1 language code Character set identifier
37
38
Figure 2.18 Format of the Language and Character Set Field 39
40
The ISO 639-1 language code sub-field is two octets in length and specifies the
41
language used for character strings, as defined in [B5].
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 91

The character set identifier sub-field is one octet in length and specifies the
encoding used by the characters in the character set. This sub-field shall be set to 1
one of the non-reserved values listed in Table 2.41. 2
3
Table 2.41 Values of the Character Set Identifier Sub-Field
4
Character Set Bits Per 5
Identifier Value Character Description 6
7
0x00 8 ISO 646, ASCII character set. Each character is fitted into
the least significant 7 bits of an octet with the most 8
significant bit set to zero (see also [B6]). 9
10
0x01 – 0xff - Reserved.
11
12
If the language and character sets have not been specified, the language shall 13
default to English (language code = “EN”) and the character set to ISO 646. 14
2.3.2.6.2 Manufacturer Name Field 15
16
The manufacturer name field has a variable length and contains a character string 17
representing the name of the manufacturer of the device. 18
2.3.2.6.3 Model Name Field 19
20
The model name field has a variable length and contains a character string 21
representing the name of the manufacturers model of the device. 22
23
2.3.2.6.4 Serial Number Field
24
The serial number field has a variable length and contains a character string 25
representing the manufacturers serial number of the device. 26
27
2.3.2.6.5 Device URL Field
28
The device URL field has a variable length and contains a character string 29
representing the URL through which more information relating to the device can 30
be obtained. 31
32
2.3.2.6.6 Icon Field 33
The icon field has a variable length and contains an octet string which carries the 34
data for an icon that can represent the device on a computer, gateway, or PDA. 35
The format of the icon shall be a 32-by-32-pixel PNG image. 36
37
2.3.2.6.7 Icon URL Field 38
The icon URL field has a variable length and contains a character string 39
representing the URL through which the icon for the device can be obtained. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
92 Application Layer Specification

2.3.2.7 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, and shall contain a maximum of 16 5
characters. 6
7
The fields of the user descriptor are shown in Table 2.42 in the order of their
8
transmission.
9
Table 2.42 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
implemented within ZigBee Device Objects. The ZigBee Device Profile operates 42
like any ZigBee profile by defining clusters. Unlike application specific profiles, 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 93

the clusters within the ZigBee Device Profile define capabilities supported in all
ZigBee devices. As with any profile document, this document details the 1
mandatory and/or optional clusters. 2
3
4
2.4.2 Device Profile Overview 5
6
The Device Profile supports four key inter-device communication functions 7
within the ZigBee protocol. These functions are explained in the following 8
sections: 9
• Device and Service Discovery Overview 10
11
• End Device Bind Overview 12
• Bind and Unbind Overview 13
14
• Binding Table Management Overview 15
• Network Management Overview 16
17
2.4.2.1 Device and Service Discovery Overview 18
19
Device and Service Discovery are distributed operations where individual devices 20
or designated discovery cache devices respond to discovery requests. The “device 21
address of interest” field enables responses from either the device itself or a 22
discovery cache device. In selected cases where both the discovery cache device 23
and the “device address of interest” device respond, the response from the “device 24
address of interest” shall be used. 25
The following capabilities exist for device and service discovery: 26
27
• Device Discovery: Provides the ability for a device to determine the identity of 28
other devices on the PAN. Device Discovery is supported for both the 64-bit 29
IEEE address and the 16-bit Network address. 30
• Device Discovery messages can be used in one of two ways: 31
32
—Broadcast addressed: All devices on the network shall respond accord- 33
ing to the Logical Device Type and the matching criteria. ZigBee End 34
Devices shall respond with just their address. ZigBee Coordinators and 35
ZigBee Routers with associated devices shall respond with their address 36
as the first entry followed by the addresses of their associated devices 37
depending on the type of request. The responding devices shall employ 38
APS acknowledged service on the unicast responses. 39
40
—Unicast addressed: Only the specified device responds. A ZigBee End 41
Device shall respond only with its address. A ZigBee Coordinator or 42
Router shall reply with its own address and the address of each associ- 43
ated child device. Inclusion of the associated child devices allows the 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
94 Application Layer Specification

requestor to determine the network topology underlying the specified


device. 1
2
• Service Discovery: Provides the ability for a device to determine services 3
offered by other devices on the PAN. 4
• Service Discovery messages can be used in one of two ways: 5
6
—Broadcast addressed: Due to the volume of information that could be 7
returned, only the individual device or the primary discovery cache shall 8
respond with the matching criteria established in the request. The pri- 9
mary discovery cache shall only respond in this case if it holds cached 10
discovery information for the NWKAddrOfInterest from the request. 11
The responding devices shall also employ APS acknowledged service 12
on the unicast responses. 13
14
—Unicast addressed: Only the specified device shall respond. In the case 15
of a ZigBee Coordinator or ZigBee Router, these devices shall cache the 16
Service Discovery information for sleeping associated devices and 17
respond on their behalf. 18
19
• Service Discovery is supported with the following query types: 20
—Active Endpoint: This command permits an enquiring device to deter- 21
mine the active endpoints. An active endpoint is one with an application 22
23
supporting a single profile, described by a Simple Descriptor. The com-
24
mand shall be unicast addressed. 25
—Match Simple Descriptor: This command permits enquiring devices to 26
supply a Profile ID (and, optionally, lists of input and/or output Cluster 27
IDs) and ask for a return of the identity of an endpoint on the destination 28
device which matches the supplied criteria. This command may be 29
30
broadcast to all devices for which macRxOnWhenIdle = TRUE, or uni-
31
cast addressed. For broadcast addressed requests, the responding device 32
shall employ APS acknowledged service on the unicast responses. 33
—Simple Descriptor: This command permits an enquiring device to 34
return the Simple Descriptor for the supplied endpoint. This command 35
shall be unicast addressed. 36
37
—Node Descriptor: This command permits an enquiring device to return 38
the Node Descriptor from the specified device. This command shall be 39
unicast addressed. 40
41
—Power Descriptor: This command permits an enquiring device to 42
return the Power Descriptor from the specified device. This command 43
shall be unicast addressed. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 95

—Complex Descriptor: This optional command permits an enquiring


device to return the Complex Descriptor from the specified device. This 1
command shall be unicast addressed. 2
3
—User Descriptor: This optional command permits an enquiring device 4
to return the User Descriptor from the specified device. This command 5
shall be unicast addressed. 6
7
2.4.2.2 End Device Bind Overview 8
9
The following capabilities exist for end device bind: 10
• End Device Bind: 11
12
• Provides the ability for an application to support a simplified method of 13
binding where user intervention is employed to identify command/control 14
device pairs. Typical usage would be where a user is asked to push buttons 15
on two devices for installation purposes. Using this mechanism a second 16
time allows the user to remove the binding table entry. 17
18
2.4.2.3 Bind and Unbind Overview 19
The following capabilities exist for directly configuring binding table entries: 20
21
• Bind: provides the ability for creation of a Binding Table entry that maps 22
control messages to their intended destination. 23
• Unbind: provides the ability to remove Binding Table entries. 24
25
2.4.2.4 Binding Table Management Overview 26
27
The following capabilities exist for management of binding tables: 28
29
• Registering devices that implement source binding:
30
• Provides the ability for a source device to instruct its primary binding table 31
cache to hold its own binding table. 32
33
• Replacing a device with another wherever it occurs in the binding table:
34
• Provides the ability to replace one device for another, by replacing all 35
instances of its address in the binding table. 36
37
• Backing up a binding table entry:
38
• Provides the ability for a primary binding table cache to send details of a 39
newly created entry to the backup binding table cache (after receiving a bind 40
request). 41
42
• Removing a backup binding table entry:
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
96 Application Layer Specification

• Provides the ability for a primary binding table cache to request that a
specific entry be removed from the backup binding table cache (after 1
receiving an unbind request). 2
3
• Backing up of the entire binding table: 4
• Provides the ability for a primary binding table cache to request backup of 5
its entire binding table, using the backup binding table cache. 6
7
• Restoring the entire binding table: 8
• Provides the ability for a primary binding table cache to request restoration 9
of its entire binding table, using the backup binding table cache. 10
11
• Backing up the Primary Binding Table Cache: 12
• Provides the ability for a primary binding table cache to request backup of 13
its entire source devices address table (which contains the addresses of any 14
source device containing its own binding table). 15
16
• Restoring the Primary Binding Table Cache: 17
• Provides the ability for a primary binding table cache to request restoration 18
of its entire source devices address table (which contains the addresses of 19
any source device containing its own binding table). 20
21
2.4.2.5 Network Management Overview 22
23
The following capabilities exist for network management: 24
• Provides the ability to retrieve management information from the devices 25
including: 26
27
• Network discovery results 28
• Link quality to neighbor nodes 29
30
• Routing table contents 31
• Binding table contents 32
33
• Discovery cache contents 34
• Energy detection scan results 35
36
• Provides the ability to set management information controls including: 37
• Network leave 38
39
• Network direct join 40
• Permit joining 41
42
• Network update and fault notification 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 97

2.4.2.6 Device Descriptions for the Device Profile


1
The ZigBee Device Profile utilizes a single Device Description. Each cluster 2
specified as Mandatory shall be present in all ZigBee devices. The response 3
behavior to some messages is logical device type specific. The support for 4
optional clusters is not dependent on the logical device type. 5
6
2.4.2.7 Configuration and Roles 7
8
The Device Profile assumes a client/server topology. A device making Device 9
Discovery, Service Discovery, Binding or Network Management requests does so 10
via a client role. A device which services these requests and responds does so via 11
a server role. The client and server roles are non-exclusive in that a given device 12
may supply both client and server roles. 13
Since many client requests and server responses are public and accessible to 14
application objects other than ZigBee Device Objects, the Transaction Sequence 15
number in the Application Framework header shall be the same on client requests 16
and their associated server responses. 17
18
The Device Profile describes devices in one of two configurations: 19
• Client: A client issues requests to the server via Device Profile messages. 20
21
• Server: A server issues responses to the client that initiated the Device Profile 22
message. 23
24
2.4.2.8 Transmission of ZDP Commands 25
All ZDP commands shall be transmitted via the APS data service and shall be 26
formatted according to the ZDP frame structure, as illustrated in Figure 2.19. 27
28
Octets: 1 Variable 29
Transaction sequence number Transaction data
30
31
Figure 2.19 Format of the ZDP Frame 32
33
2.4.2.8.1 Transaction Sequence Number Field 34
35
The transaction sequence number field is eight bits in length and specifies an
36
identification number for the ZDP transaction so that a response command frame
37
can be related to the request frame. The application object itself shall maintain an
38
eight-bit counter that is copied into this field and incremented by one for each
39
command sent. When a value of 0xff is reached, the next command shall restart
40
the counter with a value of 0x00.
41
If a device sends a ZDP request command that requires a response, the target 42
device shall respond with the relevant ZDP response command and include the 43
transaction sequence number contained in the original request command. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
98 Application Layer Specification

The transaction sequence number field can be used by a controlling device, which
may have issued multiple commands, so that it can match the incoming responses 1
to the relevant command. 2
3
2.4.2.8.2 Transaction Data Field 4
The transaction data field has a variable length and contains the data for the 5
individual ZDP transaction. The format and length of this field is dependent on 6
the command being transmitted, as defined in sub-clauses 2.4.3 and 2.4.4. 7
8
9
2.4.3 Client Services 10
11
The Device Profile Client Services support the transport of device and service 12
discovery requests, end device binding requests, bind requests, unbind requests, 13
and network management requests from client to server. Additionally, Client 14
Services support receipt of responses to these requests from the server. 15
16
2.4.3.1 Device and Service Discovery Client Services 17
Table 2.43 lists the commands supported by Device Profile, Device, and Service 18
Discovery Client Services. Each of these commands will be discussed in the 19
following sub-clauses. 20
21
Table 2.43 Device and Service Discovery Client Services Commands 22
Device and Service 23
Discovery Client Server 24
Client Services Transmission Processing 25
26
NWK_addr_req O M
27
IEEE_addr_req O M 28
Node_Desc_req O M 29
30
Power_Desc_req O M
31
Simple_Desc_req O M 32
Active_EP_req O M 33
34
Match_Desc_req O M 35
Complex_Desc_req O O 36
User_Desc_req O O 37
38
Discovery_Cache_req O O 39
Device_annce O M 40
41
User_Desc_set O O
42
System_Server_Discover_req O O 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 99

Table 2.43 Device and Service Discovery Client Services Commands (Continued)
1
Discovery_store_req O O
2
Node_Desc_store_req O O 3
Power_Desc_store_req O O 4
5
Active_EP_store_req O O 6
Simple_Desc_store_req O O 7
Remove_node_cache_req O O 8
9
Find_node_cache_req O O 10
Extended_Simple_Desc_req O O 11
12
Extended_Active_EP_req O O
13
14
2.4.3.1.1 NWK_addr_req 15
The NWK_addr_req command (ClusterID=0x0000) shall be formatted as 16
illustrated in Figure 2.20. 17
18
Octets: 8 1 1 19
20
IEEEAddress RequestType StartIndex
21
Figure 2.20 Format of the NWK_addr_req Command 22
23
Table 2.44 specifies the fields of the NWK_addr_req Command Frame. 24
Table 2.44 Fields of the NWK_addr_req Command 25
26
Name Type Valid Range Description 27
IEEEAddr IEEE A valid 64-bit IEEE The IEEE address to be matched by the
28
Address address Remote Device 29
30
RequestType Integer 0x00-0xff Request type for this command:
31
0x00 – Single device response 32
0x01 – Extended response 33
34
0x02-0xFF – reserved
35
StartIndex Integer 0x00-0xff If the Request type for this command is 36
Extended response, the StartIndex 37
provides the starting index for the
38
requested elements of the associated
devices list 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
100 Application Layer Specification

2.4.3.1.1.1 When Generated


1
The NWK_addr_req is generated from a Local Device wishing to inquire as to the 2
16-bit address of the Remote Device based on its known IEEE address. The 3
destination addressing on this command shall be unicast or broadcast to all 4
devices for which macRxOnWhenIdle = TRUE. 5
6
2.4.3.1.1.2 Effect on Receipt 7
8
Upon receipt, a Remote Device shall compare the IEEEAddr to its local IEEE
9
address or any IEEE address held in its local discovery cache. If there is no match
10
and the request was unicast, a NWK_addr_resp command shall be generated and
11
sent back to the local device with the Status field set to DEVICE_NOT_FOUND,
12
the IEEEAddrRemoteDev field set to the IEEE address of the request; the
13
NWKAddrRemoteDev field set to the NWK address of this device; and the
14
NumAssocDev, StartIndex, and NWKAddrAssocDevList fields shall not be
15
included in the frame. If there is no match and the command was received as a
16
broadcast, the request shall be discarded and no response generated.
17
If a match is detected between the contained IEEEAddr and the Remote Device's 18
IEEE address or one held in the discovery cache, the RequestType shall be used to 19
create a response. If the RequestType is one of the reserved values, a 20
NWK_addr_resp command shall be generated and sent back to the local device 21
with the Status field set to INV_REQUESTTYPE; the IEEEAddrRemoteDev 22
field set to the IEEE address of the request; the NWKAddrRemoteDev field set to 23
the network address corresponding to the IEEE address of the request; and the 24
NumAssocDev, StartIndex, and NWKAddrAssocDevList fields shall not be 25
included in the frame. 26
27
If the RequestType is single device response, a NWK_addr_resp command shall
28
be generated and sent back to the local device with the Status field set to
29
SUCCESS, the IEEEAddrRemoteDev field set to the IEEE address of the request;
30
the NWKAddrRemoteDev field set to the NWK address of the discovered device;
31
and the NumAssocDev, StartIndex, and NWKAddrAssocDevList fields shall not
32
be included in the frame.
33
If the RequestType was Extended response and the Remote Device is either the 34
ZigBee coordinator or router with associated devices, a NWK_addr_resp 35
command shall be generated and sent back to the local device with the Status field 36
set to SUCCESS, the IEEEAddrRemoteDev field set to the IEEE address of the 37
device itself, and the NWKAddrRemoteDev field set to the NWK address of the 38
device itself. The Remote Device shall also supply a list of all 16-bit NWK 39
addresses in the NWKAddrAssocDevList field, starting with the entry StartIndex 40
and continuing with whole entries until the maximum APS packet length is 41
reached, for its associated devices. It shall then set the NumAssocDev field to the 42
number of entries in the NWKAddrAssocDevList field. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 101

2.4.3.1.2 IEEE_addr_req
1
The IEEE_addr_req command (ClusterID=0x0001) shall be formatted as 2
illustrated in Figure 2.21. 3
4
Octets: 2 1 1
5
NWKAddrOfInterest RequestType StartIndex 6
7
Figure 2.21 Format of the IEEE_addr_req_Command Frame 8
9
Table 2.45 specifies the fields of the IEEE_addr_req command frame. 10
Table 2.45 Fields of the IEEE_addr_req Command 11
12
Name Type Valid Range Description
13
NWKAddrOfInterest Device 16-bit NWK address NWK address that is used for IEEE 14
Address address mapping. 15
RequestType Integer 0x00-0xff Request type for this command: 16
17
0x00 – Single device response
18
0x01 – Extended response
19
0x02-0xff – reserved 20
StartIndex Integer 0x00-0xff If the Request type for this 21
command is Extended response, the 22
StartIndex provides the starting 23
index for the requested elements of
the associated devices list.
24
25
26
2.4.3.1.2.1 When Generated 27
The IEEE_addr_req is generated from a Local Device wishing to inquire as to the 28
64-bit IEEE address of the Remote Device based on their known 16-bit address. 29
The destination addressing on this command shall be unicast. 30
31
2.4.3.1.2.2 Effect on Receipt 32
33
Upon receipt, a Remote Device shall compare the NWKAddrOfInterest to its 34
local NWK address or any NWK address held in its local discovery cache. If there 35
is no match, an IEEE_addr_resp command shall be generated and sent back to the 36
local device with the Status field set to DEVICE_NOT_FOUND; the 37
IEEEAddrRemoteDev field set to the IEEE address of this device; the 38
NWKAddrRemoteDev field set to the NWK address of the request; and the 39
NumAssocDev, StartIndex, and NWKAddrAssocDevList fields shall not be 40
included in the frame. 41
42
If a match is detected between the contained NWKAddrOfInterest and the Remote
43
Device's NWK address or one held in the discovery cache, the RequestType shall
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
102 Application Layer Specification

be used to create a response. If the RequestType is one of the reserved values, an


IEEE_addr_resp command shall be generated and sent back to the local device 1
with the Status field set to INV_REQUESTTYPE, the IEEEAddrRemoteDev field 2
set to the IEEE address of this device, the NWKAddrRemoteDev field set to the 3
network address of this device and the NumAssocDev, StartIndex, and 4
NWKAddrAssocDevList fields shall not be included in the frame. 5
6
If the RequestType is single device response, an IEEE_addr_resp command shall 7
be generated and sent back to the local device with the Status field set to 8
SUCCESS, the IEEEAddrRemoteDev field set to the IEEE address of the 9
discovered device, the NWKAddrRemoteDev field set to the NWK address of the 10
request and the NumAssocDev, StartIndex, and NWKAddrAssocDevList fields 11
shall not be included in the frame. 12
If the RequestType indicates an Extended Response and the Remote Device is the 13
ZigBee coordinator or router with associated devices, an IEEE_addr_resp 14
command shall be generated and sent back to the local device with the Status field 15
set to SUCCESS, the IEEEAddrRemoteDev field set to the IEEE address of the 16
device itself, and the NWKAddrRemoteDev field set to the NWK address of the 17
device itself. The Remote Device shall also supply a list of all 16-bit network 18
addresses in the NWKAddrAssocDevList field, starting with the entry StartIndex 19
and continuing with whole entries until the maximum APS packet length is 20
reached, for its associated devices. It shall then set the NumAssocDev field to the 21
number of entries in the NWKAddrAssocDevList field. 22
23
2.4.3.1.3 Node_Desc_req 24
The Node_Desc_req_command (ClusterID=0x0002) shall be formatted as 25
illustrated in Figure 2.22. 26
27
Octets: 2 28
29
NWKAddrOfInterest
30
Figure 2.22 Format of the Node_Desc_req Command Frame 31
32
Table 2.46 specifies the fields for the Node_Desc_req command frame. 33
34
Table 2.46 Fields of the Node_Desc_req Command
35
Name Type Valid Range Description 36
37
NWKAddrOfInterest Device Address 16-bit NWK address NWK address for the request
38
39
2.4.3.1.3.1 When Generated 40
41
The Node_Desc_req command is generated from a local device wishing to inquire
42
as to the node descriptor of a remote device. This command shall be unicast either
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 103

to the remote device itself or to an alternative device that contains the discovery
information of the remote device. 1
2
The local device shall generate the Node_Desc_req command using the format 3
illustrated in Table 2.46. The NWKAddrOfInterest field shall contain the network 4
address of the remote device for which the node descriptor is required. 5
6
2.4.3.1.3.2 Effect on Receipt 7
Upon receipt of this command, the recipient device shall process the command 8
and generate a Node_Desc_rsp command in response, according to the 9
description in sub-clause 2.4.4.1.3.1. 10
11
2.4.3.1.4 Power_Desc_req 12
13
The Power_Desc_req command (ClusterID=0x0003) shall be formatted as
14
illustrated in Figure 2.23.
15
Octets: 2 16
17
NWKAddrOfInterest 18
Figure 2.23 Format of the Power_Desc_req Command Frame 19
20
Table 2.47 specifies the fields of the Power_Desc_req command frame. 21
22
Table 2.47 Fields of the Power_Desc_req Command
23
Name Type Valid Range Description 24
25
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request. 26
Address
27
28
2.4.3.1.4.1 When Generated 29
30
The Power_Desc_req command is generated from a local device wishing to
31
inquire as to the power descriptor of a remote device. This command shall be
32
unicast either to the remote device itself or to an alternative device that contains
33
the discovery information of the remote device.
34
The local device shall generate the Power_Desc_req command using the format 35
illustrated in Table 2.47. The NWKAddrOfInterest field shall contain the network 36
address of the remote device for which the power descriptor is required. 37
38
2.4.3.1.4.2 Effect on Receipt 39
40
Upon receipt of this command, the recipient device shall process the command 41
and generate a Power_Desc_rsp command in response according to the 42
description in sub-clause 2.4.4.1.4.1. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
104 Application Layer Specification

2.4.3.1.5 Simple_Desc_req
1
The Simple_Desc_req command (ClusterID=0x0004) shall be formatted as 2
illustrated in Figure 2.24. 3
4
Octets: 2 1
5
NWKAddrOfInterest EndPoint 6
7
Figure 2.24 Format of the Simple_Desc_req Command Frame 8
9
Table 2.48 specifies the fields of the Simple_Desc_req command frame. 10
Table 2.48 Fields of the Simple_Desc_req Command 11
12
Name Type Valid Range Description
13
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request 14
Address 15
Endpoint 8 bits 1-240 The endpoint on the destination 16
17
18
2.4.3.1.5.1 When Generated
19
The Simple_Desc_req command is generated from a local device wishing to 20
inquire as to the simple descriptor of a remote device on a specified endpoint. This 21
command shall be unicast either to the remote device itself or to an alternative 22
device that contains the discovery information of the remote device. 23
24
The local device shall generate the Simple_Desc_req command using the format 25
illustrated in Table 2.48. The NWKAddrOfInterest field shall contain the network 26
address of the remote device for which the simple descriptor is required and the 27
endpoint field shall contain the endpoint identifier from which to obtain the 28
required simple descriptor. 29
30
2.4.3.1.5.2 Effect on Receipt 31
Upon receipt of this command, the recipient device shall process the command 32
and generate a Simple_Desc_rsp command in response, according to the 33
description in sub-clause 2.4.4.1.5.1. 34
35
2.4.3.1.6 Active_EP_req 36
The Active_EP_req command (ClusterID=0x0005) shall be formatted as 37
illustrated in Figure 2.25. 38
39
Octets: 2 40
41
NWKAddrOfInterest 42
Figure 2.25 Format of the Active_EP_req Command Frame 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 105

Table 2.49 specifies the fields of the Active_EP_req command frame.


1
Table 2.49 Fields of the Active_EP_req Command
2
Name Type Valid Range Description 3
4
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request. 5
Address
6
7
2.4.3.1.6.1 When Generated 8
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
illustrated in Table 2.49. The NWKAddrOfInterest field shall contain the network 15
address of the remote device for which the active endpoint list is required. 16
17
2.4.3.1.6.2 Effect on Receipt 18
19
Upon receipt of this command, the recipient device shall process the command 20
and generate an Active_EP_rsp command in response, according to the 21
description in sub-clause 2.4.4.1.6.1. 22
2.4.3.1.7 Match_Desc_req 23
24
The Match_Desc_req command (ClusterID=0x0006) shall be formatted as 25
illustrated in Figure 2.26. 26
27
Octets: 2 2 1 Variable 1 Variable
28
NWKAddrOfInte ProfileID NumInClusters InClusterList NumOutCl OutClusterList 29
rest usters 30
Figure 2.26 Format of the Match_Desc_req Command Frame 31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
106 Application Layer Specification

Table 2.50 specifies the fields of the Match_Desc_req command frame.


1
Table 2.50 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 27
Device). 28
29
30
2.4.3.1.7.1 When Generated
31
The Match_Desc_req command is generated from a local device wishing to find 32
remote devices supporting a specific simple descriptor match criterion. This 33
command shall either be broadcast to all devices for which macRxOnWhenIdle = 34
TRUE, or unicast. If the command is unicast, it shall be directed either to the 35
remote device itself or to an alternative device that contains the discovery 36
information of the remote device. 37
38
The local device shall generate the Match_Desc_req command using the format
39
illustrated in Table 2.50. The NWKAddrOfInterest field shall contain the network
40
address indicating a broadcast to all devices for which macRxOnWhenIdle =
41
TRUE (0xfffd) if the command is to be broadcast, or the network address of the
42
remote device for which the match is required.
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 107

The remaining fields shall contain the required criterion for which the simple
descriptor match is requested. The ProfileID field shall contain the identifier of 1
the profile for which the match is being sought. 2
3
The NumInClusters field shall contain the number of elements in the InClusterList 4
field. If the value of this field is 0, the InClusterList field shall not be included. If 5
the value of the NumInClusters field is not equal to 0, the InClusterList field shall 6
contain the list of input cluster identifiers for which the match is being sought. 7
The NumOutClusters field shall contain the number of elements in the 8
OutClusterList field. If the value of this field is 0, the OutClusterList field shall 9
not be included. If the value of the NumOutClusters field is not equal to 0, the 10
OutClusterList field shall contain the list of output cluster identifiers for which the 11
match is being sought. 12
13
2.4.3.1.7.2 Effect on Receipt 14
15
Upon receipt of this command, the recipient device shall process the command 16
and generate a Match_Desc_rsp command in response, according to the 17
description in sub-clause 2.4.4.1.7.1. 18
2.4.3.1.8 Complex_Desc_req 19
20
The Complex_Desc_req command (ClusterID=0x0010) shall be formatted as 21
illustrated in Figure 2.27. 22
23
Octets: 2 24
NWKAddrOfInterest 25
26
Figure 2.27 Format of the Complex_Desc_req Command Frame 27
28
Table 2.51 specifies the fields of the Complex_Desc_req command frame. 29
Table 2.51 Fields of the Complex_Desc_req Command 30
31
Name Type Valid Range Description 32
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request 33
Address 34
35
2.4.3.1.8.1 When Generated 36
37
The Complex_Desc_req command is generated from a local device wishing to 38
inquire as to the complex descriptor of a remote device. This command shall be 39
unicast either to the remote device itself or to an alternative device that contains 40
the discovery information of the remote device. 41
42
The local device shall generate the Complex_Desc_req command using the
43
format illustrated in Table 2.51. The NWKAddrOfInterest field shall contain the
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
108 Application Layer Specification

network address of the remote device for which the complex descriptor is
required. 1
2
2.4.3.1.8.2 Effect on Receipt 3
4
Upon receipt of this command, the recipient device shall process the command 5
and generate a Complex_Desc_rsp command in response, according to the 6
description in sub-clause 2.4.4.1.8.1. 7
2.4.3.1.9 User_Desc_req 8
9
The User_Desc_req (ClusterID=0x0011) command shall be formatted as 10
illustrated in Figure 2.28. 11
12
Octets: 2 13
NWKAddrOfInterest 14
15
Figure 2.28 Format of the User_Desc_req Command Frame 16
17
Table 2.52 specifies the fields of the User_Desc_req command frame. 18
Table 2.52 Fields of the User_Desc_req Command 19
20
Name Type Valid Range Description 21
NWKAddrOfInterest Device Address 16-bit NWK address NWK address for the request. 22
23
24
2.4.3.1.9.1 When Generated
25
The User_Desc_req command is generated from a local device wishing to inquire 26
as to the user descriptor of a remote device. This command shall be unicast either 27
to the remote device itself or to an alternative device that contains the discovery 28
information of the remote device. 29
30
The local device shall generate the User_Desc_req command using the format 31
illustrated in Table 2.52. The NWKAddrOfInterest field shall contain the network 32
address of the remote device for which the user descriptor is required. 33
34
2.4.3.1.9.2 Effect on Receipt 35
Upon receipt of this command, the recipient device shall process the command 36
and generate a User_Desc_rsp command in response, according to the description 37
in sub-clause 2.4.4.1.9.1. 38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 109

2.4.3.1.10 Discovery_Cache_req
1
The Discovery_Cache_req command (ClusterID=0x0012) shall be formatted as 2
illustrated in Figure 2.29. 3
4
Octets: 2 8
5
NWKAddr IEEEAddr 6
7
Figure 2.29 Format of the Discovery_Cache_req Command Frame 8
9
Table 2.53 specifies the parameters for the Discovery_Cache_req command 10
frame. 11
Table 2.53 Fields of the Discovery_Cache_req Command 12
13
Name Type Valid Range Description
14
NWKAddr Device Address 16-bit NWK address NWK address for the Local Device. 15
IEEEAddr Device Address 64-bit IEEE address IEEE address for the Local Device. 16
17
18
2.4.3.1.10.1 When Generated 19
The Discovery_Cache_req is provided to enable devices on the network to locate 20
a Primary Discovery Cache device on the network. The destination addressing on 21
this primitive shall be broadcast to all devices for which macRxOnWhenIdle = 22
TRUE. 23
24
2.4.3.1.10.2 Effect on Receipt 25
26
Upon receipt, if the Remote Device does not support the Discovery_Cache_req, 27
the request shall be dropped and no further processing performed. If the 28
Discovery_Cache_req is supported, the Remote Device shall create a unicast 29
Discovery_Cache_rsp message to the source indicated by the 30
Discovery_Cache_req and include a SUCCESS status. 31
32
2.4.3.1.11 Device_annce
33
The Device_annce command (ClusterID=0x0013) shall be formatted as illustrated 34
in Figure 2.30. 35
36
Octets: 2 8 1 37
NWKAddr IEEEAddr Capability 38
39
Figure 2.30 Format of the Device_annce Command Frame 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
110 Application Layer Specification

Table 2.54 specifies the fields of the Device_annce command frame.


1
Table 2.54 Fields of the Device_annce Command
2
Name Type Valid Range Description 3
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.17 Capability of the local device 7
8
9
2.4.3.1.11.1 When Generated 10
The Device_annce is provided to enable ZigBee devices on the network to notify 11
other ZigBee devices that the device has joined or re-joined the network, 12
identifying the device’s 64-bit IEEE address and new 16-bit NWK address, and 13
informing the Remote Devices of the capability of the ZigBee device. This 14
command shall be invoked for all ZigBee end devices upon join or rejoin. This 15
command may also be invoked by ZigBee routers upon join or rejoin as part of 16
NWK address conflict resolution. The destination addressing on this primitive is 17
broadcast to all devices for which macRxOnWhenIdle = TRUE. 18
19
2.4.3.1.11.2 Effect on Receipt 20
21
Upon receipt, the Remote Device shall use the IEEEAddr in the message to find a 22
match with any other IEEE address held in the Remote Device. If a match is 23
detected, the Remote Device shall update the nwkAddressMap attribute of the NIB 24
with the updated NWKAddr corresponding to the IEEEAddr received. 25
26
The Remote Device shall also use the NWKAddr in the message to find a match
27
with any other 16-bit NWK address held in the Remote Device. If a match is
28
detected for a device with an IEEE address other than that indicated in the
29
IEEEAddr field received, then this entry shall be marked as not having a known
30
valid 16-bit NWK address.
31
2.4.3.1.12 User_Desc_set 32
33
The User_Desc_set command (ClusterID=0x0014) shall be formatted as
34
illustrated in Figure 2.31.
35
Octets: 2 1 Various 36
37
NWKAddrOfInterest Length UserDescriptor 38
39
Figure 2.31 Format of the User_Desc_set Command Frame
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 111

Table 2.55 specifies the fields of the User_Desc_set command frame.


1
Table 2.55 Fields of the User_Desc_set Command
2
Valid 3
Name Type Range Description 4
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
10
UserDescription User Descriptor The user description to configure; if 11
the ASCII character string to be
entered here is less than 16 characters 12
in length, it shall be padded with 13
space characters (0x20) to make a 14
total length of 16 characters. 15
Characters with codes 0x00-0x1f are 16
not permitted.
17
18
2.4.3.1.12.1 When Generated 19
20
The User_Desc_set command is generated from a local device wishing to
21
configure the user descriptor on a remote device. This command shall be unicast
22
either to the remote device itself or to an alternative device that contains the
23
discovery information of the remote device.
24
The local device shall generate the User_Desc_set command using the format 25
illustrated in Table 2.55. The NWKAddrOfInterest field shall contain the network 26
address of the remote device for which the user descriptor is to be configured and 27
the UserDescription field shall contain the ASCII character string that is to be 28
configured in the user descriptor. Characters with ASCII codes numbered 0x00 29
through 0x1f are not permitted to be included in this string. 30
31
2.4.3.1.12.2 Effect on Receipt 32
33
Upon receipt of this command, the recipient device shall process the command 34
and generate a User_Desc_conf command in response, according to the 35
description in sub-clause 2.4.4.1.11.1. 36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
112 Application Layer Specification

2.4.3.1.13 System_Server_Discovery_req
1
The System_Server_Discovery_req command (ClusterID=0x0015) shall be 2
formatted as illustrated in Figure 2.32. 3
4
Octets: 2
5
ServerMask 6
7
Figure 2.32 Format of the System_Server_Discovery_req Command Frame 8
9
Table 2.56 specifies the fields of the System_Server_Discovery_req command 10
frame. 11
Table 2.56 Fields of the System_Server_Discovery_req Command 12
13
Name Type Valid Range Description
14
ServerMask Bitmap 16 bits See Table 2.31 for bit assignments 15
16
2.4.3.1.13.1 When Generated 17
18
The System_Server_Discovery_req is generated from a Local Device wishing to 19
discover the location of a particular system server or servers as indicated by the 20
ServerMask parameter. The destination addressing on this request is ‘broadcast to 21
all devices for which macRxOnWhenIdle = TRUE.’ 22
23
2.4.3.1.13.2 Effect on Receipt 24
25
Upon receipt, remote devices shall compare the ServerMask parameter to the 26
Server Mask field in their own Node descriptor. If no bits are found to match, no 27
action is taken. If any matching bits are found, the remote device shall send a 28
System_Server_Discovery_rsp back to the originator using unicast transmission 29
(with acknowledgement request) and indicating the matching bits. 30
2.4.3.1.14 Discovery_store_req 31
32
The Discovery_Store_req command (ClusterID=0x0016) shall be formatted as 33
illustrated in Figure 2.33. 34
35
Octets: 2 8 1 1 1 1 Variable
36
NWKAddr IEEEAddr NodeDes PowerDe ActiveEPSize SimpleDes SimpleDesc- 37
c-Size sc-Size c-Count SizeList 38
Figure 2.33 Format of the Discovery_Store_req Command Frame
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 113

Table 2.57 specifies the fields of the Discovery_store_req command frame.


1
Table 2.57 Fields of the Discovery_store_req Command
2
Name Type Valid Range Description 3
4
NWKAddr Device 16-bit NWK NWK Address for the Local 5
Address Address Device.
6
IEEEAddr Device 64-bit IEEE IEEE Address for the Local 7
Address Address Device. 8
NodeDescSize Integer 0x00-oxff Size in bytes of the Node 9
Descriptor for the Local Device. 10
PowerDescSize Integer 0x00 - 0xff Size in bytes of the Power 11
Descriptor for the Local Device. 12
13
ActiveEPSize Integer 0x00 - 0xff Size in bytes of the ActiveEPCount
and ActiveEPList fields of the 14
Active_EP_rsp for the Local 15
Device. 16
SimpleDescCount Integer 0x00 - 0xff Number of Simple Descriptors 17
supported by the Local Device 18
(should be the same value as the 19
ActiveEPSize). 20
SimpleDescSizeList Array of bytes List of bytes of SimpleDescCount 21
length, each of which represents 22
the size in bytes of the Simple 23
Descriptor for each Active 24
Endpoint on the Local Device.
25
26
2.4.3.1.14.1 When Generated 27
The Discovery_store_req is provided to enable ZigBee end devices on the 28
network to request storage of their discovery cache information on a Primary 29
Discovery Cache device. Included in the request is the amount of storage space 30
the Local Device requires. 31
32
The destination addressing on this request is unicast. 33
34
2.4.3.1.14.2 Effect on Receipt 35
36
Upon receipt, the Remote Device shall determine whether it is a Primary 37
Discovery Cache device. If it is not a Primary Discovery Cache device, the 38
Remote Device shall return a status of NOT_SUPPORTED. Next, the Remote 39
Device shall determine whether it has storage for the requested discovery cache 40
size determined by summing the sizes of the NWKAddr and IEEEAddr plus the 41
NodeDescSize, PowerDescSize, ActiveEPSize, and the sizes from the 42
SimpleDescSizeList. If sufficient space exists, the Local Device shall be provided 43
a SUCCESS status. Otherwise, the Local Device shall return 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
114 Application Layer Specification

INSUFFICIENT_SPACE. If a SUCCESS status is returned, the Remote Device


shall reserve the storage requested for the upload of the discovery information 1
from the Local Device. Additionally, if the Local Device supplies an IEEEAddr 2
which matches a previously stored entry, but the NWKAddr differs from the 3
previous entry, the Remote Device shall remove the previous entry and discovery 4
cache information in favor of the newly registered data. 5
6
2.4.3.1.15 Node_Desc_store_req 7
The Node_Desc_store_req command (ClusterID=0x0017) shall be formatted as 8
illustrated in Figure 2.34. 9
10
Octets: 2 8 Variable 11
12
NWKAddr IEEEAddr NodeDescriptor
13
Figure 2.34 Format of the Node_Desc_store_req Command Frame 14
15
Table 2.58 specifies the fields of the Node_Desc_store_req command frame. 16
17
Table 2.58 Fields of the Node_Desc_store_req Command
18
Name Type Valid Range Description 19
20
NWKAddr Device 16-bit NWK Address NWK Address for the Local Device
Address 21
22
IEEEAddr Device 64-bit IEEE Address IEEE address for the Local Device 23
Address
24
NodeDescriptor Node See the Node Descriptor format in sub- 25
Descriptor clause 2.3.2.3 26
27
2.4.3.1.15.1 When Generated 28
29
The Node_Desc_store_req is provided to enable ZigBee end devices on the 30
network to request storage of their Node Descriptor on a Primary Discovery 31
Cache device which has previously received a SUCCESS status from a 32
Discovery_store_req to the same Primary Discovery Cache device. Included in 33
this request is the Node Descriptor the Local Device wishes to cache. 34
35
2.4.3.1.15.2 Effect on Receipt 36
Upon receipt, the Remote Device shall determine whether it is a Primary 37
Discovery Cache device. If it is not a Primary Discovery Cache device, the 38
Remote Device shall return a status of NOT_SUPPORTED. Next, the Remote 39
Device shall determine whether it has previously processed a 40
Discovery_store_req for the Local Device and returned a status of SUCCESS. If a 41
previous Discovery_store_req has not been processed with a SUCCESS status, 42
the Remote Device shall return NOT_PERMITTED. Next, the Remote Device 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 115

shall determine if enough space is available to store the Node Descriptor for the
Local Device. If not, the Remote Device shall return INSUFFICIENT_SPACE. 1
Finally, the Remote Device shall store the Node Descriptor for the Local Device 2
and return SUCCESS. If the request returned a status of SUCCESS and the 3
NWKAddr and IEEEAddr in the request referred to addresses already held in the 4
Primary Discovery Cache, the descriptor in this request shall overwrite the 5
previously held entry. 6
7
2.4.3.1.16 Power_Desc_store_req 8
The Power_Desc_store_req command (ClusterID=0x0018) shall be formatted as 9
illustrated in Figure 2.35. 10
11
Octets: 2 8 Variable 12
13
NWKAddr IEEEAddr PowerDescriptor
14
Figure 2.35 Format of the Power_Desc_store_req Command Frame 15
16
Table 2.59 specifies the fields of the Power_Desc_store_req command frame. 17
18
Table 2.59 Fields of the Power_Desc_store_req Command
19
Name Type Valid Range Description 20
21
NWKAddr Device 16-bit NWK Address NWK Address for the Local Device.
Address 22
23
IEEEAddr Device 64-bit Address IEEE address for the Local Device. 24
Address
25
PowerDescriptor Power See the Power Descriptor format in 26
Descriptor sub-clause 2.3.2.4; This field shall only 27
be included in the frame if the status
field is equal to SUCCESS.
28
29
30
2.4.3.1.16.1 When Generated 31
The Power_Desc_store_req is provided to enable ZigBee end devices on the 32
network to request storage of their Power Descriptor on a Primary Discovery 33
Cache device which has previously received a SUCCESS status from a 34
Discovery_store_req to the same Primary Discovery Cache device. Included in 35
this request is the Power Descriptor the Local Device wishes to cache. 36
37
2.4.3.1.16.2 Effect on Receipt 38
39
Upon receipt, the Remote Device shall determine whether it is a Primary 40
Discovery Cache device. If it is not a Primary Discovery Cache device, the 41
Remote Device shall return a status of NOT_SUPPORTED. Next, the Remote 42
Device shall determine whether it has previously processed a 43
Discovery_store_req for the Local Device and returned a status of SUCCESS. If a 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
116 Application Layer Specification

previous Discovery_store_req has not been processed with a SUCCESS status,


the Remote Device shall return NOT_PERMITTED. Next, the Remote Device 1
shall determine if enough space is available to store the Power Descriptor for the 2
Local Device. If not, the Remote Device shall return INSUFFICIENT_SPACE. 3
Finally, the Remote Device shall store the Power Descriptor for the Local Device 4
and return SUCCESS. If the request returned a status of SUCCESS, and the 5
NWKAddr and IEEEAddr in the request referred to addresses already held in the 6
Primary Discovery Cache, the descriptor in this request shall overwrite the 7
previously held entry. 8
9
2.4.3.1.17 Active_EP_store_req 10
The Active_EP_store_req command (ClusterID=0x0019) shall be formatted as 11
illustrated in Figure 2.36. 12
13
Octets: 2 8 1 Variable 14
15
NWKAddr IEEEAddr ActiveEPCount ActiveEPList
16
Figure 2.36 Format of the Active_EP_store_req Command Frame 17
18
Table 2.60 specifies the fields of the Active_EP_store_req command frame 19
20
Table 2.60 Fields of the Active_EP_store_req Command
21
Name Type Valid Range Description 22
23
NWKAddr Device 16-bit NWK NWK Address for the Local Device.
Address Address 24
25
IEEEAddr Device 64-bit IEEE IEEE Address for the Local Device. 26
Address Address
27
ActiveEPCount Integer 0x00-0xff The count of active endpoints on the 28
Local Device. 29
ActiveEPList List of bytes, each of which represents 30
an 8-bit endpoint number. 31
32
2.4.3.1.17.1 When Generated 33
34
The Active_EP_store_req is provided to enable ZigBee end devices on the 35
network to request storage of their list of Active Endpoints on a Primary 36
Discovery Cache device which has previously received a SUCCESS status from a 37
Discovery_store_req to the same Primary Discovery Cache device. Included in 38
this request is the count of Active Endpoints the Local Device wishes to cache and 39
the endpoint list itself. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 117

2.4.3.1.17.2 Effect on Receipt


1
Upon receipt, the Remote Device shall determine whether it is a Primary 2
Discovery Cache device. If it is not a Primary Discovery Cache device, the 3
Remote Device shall return a status of NOT_SUPPORTED. Next, the Remote 4
Device shall determine whether it has previously processed a 5
Discovery_store_req for the Local Device and returned a status of SUCCESS. If a 6
previous Discovery_store_req has not been processed with a SUCCESS status, 7
the Remote Device shall return NOT_PERMITTED. Next, the Remote Device 8
shall determine if enough space is available to store the Active Endpoint count 9
and list for the Local Device. If not, the Remote Device shall return 10
INSUFFICIENT_SPACE. Finally, the Remote Device shall store the Active 11
Endpoint count and list for the Local Device and return SUCCESS. If the request 12
returned a status of SUCCESS, and the NWKAddr and the IEEEAddr in the 13
request referred to addresses already held in the Primary Discovery Cache, the 14
descriptor in this request shall overwrite the previously held entry. 15
2.4.3.1.18 Simple_Desc_store_req 16
17
The Simple_Desc_store_req command (ClusterID=0x001a) shall be formatted as 18
illustrated in Figure 2.37. 19
20
Octets: 2 8 1 Variable 21
NWKAddr IEEEAddr Length SimpleDescriptor 22
23
Figure 2.37 Format of the Simple_Desc_store_req Command Frame 24
25
Table 2.61 specifies the fields of the Simple_Desc_store_req command frame. 26
Table 2.61 Fields of the Simple_Desc_store_req Command 27
28
Name Type Valid Range Description 29
NWKAddr Device 16-bit NWK Address NWK Address for the Local 30
Address Device. 31
IEEEAddr Device 64-bit IEEE Address IEEE Address for the Local 32
Address Device. 33
34
Length Device 0x00 - 0xff The length in bytes of the
Address Simple Descriptor to follow. 35
36
SimpleDescriptor Simple See the Simple Descriptor 37
Descriptor format in sub-clause 2.3.2.5.
38
39
2.4.3.1.18.1 When Generated 40
41
The Simple_desc_store_req is provided to enable ZigBee end devices on the
42
network to request storage of their list of Simple Descriptors on a Primary
43
Discovery Cache device which has previously received a SUCCESS status from a
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
118 Application Layer Specification

Discovery_store_req to the same Primary Discovery Cache device. Note that each
Simple Descriptor for every active endpoint on the Local Device must be 1
individually uploaded to the Primary Discovery Cache device via this command 2
to enable cached discovery. Included in this request is the length of the Simple 3
Descriptor the Local Device wishes to cache and the Simple Descriptor itself. The 4
endpoint is a field within the Simple Descriptor and is accessed by the Remote 5
Device to manage the discovery cache information for the Local Device. 6
7
2.4.3.1.18.2 Effect on Receipt 8
9
Upon receipt, the Remote Device shall determine whether it is a Primary 10
Discovery Cache device. If it is not a Primary Discovery Cache device, the 11
Remote Device shall return a status of NOT_SUPPORTED. Next, the Remote 12
Device shall determine whether it has previously processed a 13
Discovery_store_req for the Local Device and returned a status of SUCCESS. If a 14
previous Discovery_store_req has not been processed with a SUCCESS status, 15
the Remote Device shall return NOT_PERMITTED. Next, the Remote Device 16
shall determine if enough space is available to store the Simple Descriptor for the 17
Local Device. If not, the Remote Device shall return INSUFFICIENT_SPACE. 18
Finally, the Remote Device shall store the Simple Descriptor for the Local Device 19
and return SUCCESS. If the request returned a status of SUCCESS and the 20
NWKAddr and the IEEEAddr in the request referred to addresses already held in 21
the Primary Discovery Cache, the descriptor in this request shall overwrite the 22
previously held entry. 23
2.4.3.1.19 Remove_node_cache_req 24
25
The Remove_node_cache_req command (ClusterID=0x001b) shall be formatted 26
as illustrated in Figure 2.38. 27
28
Octets: 2 8 29
NWKAddr IEEEAddr 30
31
Figure 2.38 Format of the Remove_node_cache_req Command Frame 32
33
Table 2.62 specifies the fields of the Remove_node_cache_req command frame. 34
Table 2.62 Fields of the Remove_node_cache_req Command 35
36
Name Type Valid Range Description 37
NWKAddr Device Address 16-bit NWK Address NWK Address for the device of 38
interest. 39
IEEEAddr Device Address 64-bit IEEE Address IEEE Address for the device of interest. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 119

2.4.3.1.19.1 When Generated


1
The Remove_node_cache_req is provided to enable ZigBee devices on the 2
network to request removal of discovery cache information for a specified ZigBee 3
end device from a Primary Discovery Cache device. The effect of a successful 4
Remove_node_cache_req is to undo a previously successful Discovery_store_req 5
and additionally remove any cache information stored on behalf of the specified 6
ZigBee end device on the Primary Discovery Cache device. 7
8
2.4.3.1.19.2 Effect on Receipt 9
10
Upon receipt, the Remote Device shall determine whether it is a Primary
11
Discovery Cache device. If it is not a Primary Discovery Cache device, the
12
Remote Device shall return a status of NOT_SUPPORTED. Next, the Remote
13
Device shall determine whether it has previously processed a
14
Discovery_store_req for the indicated device and returned a status of SUCCESS.
15
If a previous Discovery_store_req has not been processed with a SUCCESS
16
status, the Remote Device shall return DEVICE_NOT_FOUND. Finally, the
17
Remote Device shall remove all cached discovery information for the device of
18
interest and return SUCCESS to the Local Device.
19
2.4.3.1.20 Find_node_cache_req 20
21
The Find_node_cache_req command (ClusterID=0x001c) shall be formatted as 22
illustrated in Figure 2.39. 23
Octets: 2 8 24
25
NWKAddr IEEEAddr 26
27
Figure 2.39 Format of the Find_node_cache Command Frame
28
Table 2.63 specifies the fields of the Find_node_cache_req command frame. 29
30
Table 2.63 Fields of the Find_node_cache_req Command Frame 31
Name Type Valid Range Description 32
33
NWKAddr Device 16-bit NWK Address NWK Address for the device of 34
Address interest.
35
IEEEAddr Device 64-bit IEEE Address IEEE Address for the device of 36
Address interest. 37
38
2.4.3.1.20.1 When Generated 39
40
The Find_node_cache_req is provided to enable ZigBee devices on the network to 41
broadcast to all devices for which macRxOnWhenIdle = TRUE a request to find a 42
device on the network that holds discovery information for the device of interest, 43
as specified in the request parameters. The effect of a successful 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
120 Application Layer Specification

Find_node_cache_req is to have the Primary Discovery Cache device, holding


discovery information for the device of interest, unicast a Find_node_cache_rsp 1
back to the Local Device. Note that, like the NWK_addr_req, only the device 2
meeting this criteria shall respond to the request generated by 3
Find_node_cache_req. 4
5
2.4.3.1.20.2 Effect on Receipt 6
7
Upon receipt, the Remote Device shall determine whether it is the device of 8
interest or a Primary Discovery Cache device, and if so, if it holds discovery cache 9
information for the device of interest. If it is not the device of interest or a Primary 10
Discovery Cache device, and does not hold discovery cache information for the 11
device of interest, the Remote Device shall cease processing the request and not 12
supply a response. If the Remote Device is the device of interest, or a Primary 13
Discovery Cache device, and, if the device holds discovery information for the 14
indicated device of interest, the Remote Device shall return the NWKAddr and 15
IEEEaddr for the device of interest. 16
2.4.3.1.21 Extended_Simple_Desc_req 17
18
The Extended_Simple_Desc_req command (ClusterID=0x001d) shall be 19
formatted as illustrated in Figure 2.40. 20
21
Octets: 2 1 1 22
NWKAddrOfInterest EndPoint StartIndex 23
24
Figure 2.40 Format of the Extended_Simple_Desc_req Command Frame 25
26
Table 2.64 specifies the fields of the Extended_Simple_Desc_req command 27
frame. 28
Table 2.64 Fields of the Extended_Simple_Desc_req Command 29
30
Name Type Valid Range Description 31
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request. 32
Address 33
Endpoint 8 bits 1-240 The endpoint on the destination. 34
35
StartIndex 8 bits 0x00-0xff Starting index within the cluster 36
list of the response represented by
an ordered list of the Application
37
Input Cluster List and Application 38
Output Cluster List. 39
40
2.4.3.1.21.1 When Generated 41
42
The Extended_Simple_Desc_req command is generated from a local device 43
wishing to inquire as to the simple descriptor of a remote device on a specified 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 121

endpoint. This command shall be unicast either to the remote device itself or to an
alternative device that contains the discovery information of the remote device. 1
The Extended_Simple_Desc_req is intended for use with devices which employ a 2
larger number of application input or output clusters than can be described by the 3
Simple_Desc_req. 4
5
The local device shall generate the Extended_Simple_Desc_req command using 6
the format illustrated in Table 2.64. The NWKAddrOfInterest field shall contain 7
the network address of the remote device for which the simple descriptor is 8
required and the endpoint field shall contain the endpoint identifier from which to 9
obtain the required simple descriptor. The StartIndex is the first entry requested in 10
the Application Input Cluster List and Application Output Cluster List sequence 11
within the resulting response. 12
13
2.4.3.1.21.2 Effect on Receipt 14
Upon receipt of this command, the recipient device shall process the command 15
and generate an Extended_Simple_Desc_rsp command in response, according to 16
the description in sub-clause 2.4.4.1.20.1. 17
18
The results in the Extended_Simple_Desc_rsp shall include the elements 19
described in Table 2.108 with a selectable set of the application input cluster and 20
application output cluster lists starting with the entry StartIndex and continuing 21
with whole entries until the maximum APS packet length is reached, along with a 22
status of SUCCESS. 23
2.4.3.1.22 Extended_Active_EP_req 24
25
The Extended_Active_EP_req command (ClusterID=0x001e) shall be formatted 26
as illustrated in Figure 2.41. 27
28
Octets: 2 1 29
NWKAddrOfInterest StartIndex 30
31
Figure 2.41 Format of the Extended_Active_EP_req Command Frame 32
33
Table 2.65 specifies the fields of the Extended_Active_EP_req command frame. 34
Table 2.65 Fields of the Extended_Active_EP_req Command 35
36
Name Type Valid Range Description 37
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request. 38
Address 39
StartIndex 8 bits 0x00-0xff Starting index within the Active 40
Endpoint list in the response. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
122 Application Layer Specification

2.4.3.1.22.1 When Generated


1
The Extended_Active_EP_req command is generated from a local device wishing 2
to acquire the list of endpoints on a remote device with simple descriptors. This 3
command shall be unicast either to the remote device itself or to an alternative 4
device that contains the discovery information of the remote device. The 5
Extended_Active_EP_req is used for devices which support more active 6
endpoints than can be returned by a single Active_EP_req. 7
The local device shall generate the Extended_Active_EP_req command using the 8
format illustrated in Table 2.65. The NWKAddrOfInterest field shall contain the 9
network address of the remote device for which the active endpoint list is 10
required. The StartIndex field shall be set in the request to enable retrieval of lists 11
of active endpoints from devices whose list exceeds the size of a single ASDU and 12
where fragmentation is not supported. 13
14
2.4.3.1.22.2 Effect on Receipt 15
16
Upon receipt of this command, the recipient device shall process the command 17
and generate an Extended_Active_EP_rsp command in response, according to the 18
description in sub-clause 2.4.4.1.21.1. 19
20
The results in the Extended_Active_EP_rsp shall include the elements described
21
in Table 2.109 with a selectable set of the list of active endpoints on the remote
22
device starting with the entry StartIndex and continuing with whole entries until
23
the maximum APS packet length is reached or the application input and output
24
cluster lists is exhausted, along with a status of SUCCESS.
25
2.4.3.2 End Device Bind, Bind, Unbind, and Bind 26
27
Management Client Services Primitives 28
Table 2.66 lists the primitives supported by Device Profile: End Device Bind, 29
Bind and Unbind Client Services. Each of these commands will be discussed in 30
the following sub-clauses. 31
32
Table 2.66 End Device Bind, Bind, Unbind, and Bind 33
Management Client Service Commands
34
End Device Bind, Bind and 35
Unbind Client Server 36
Client Services Transmission Processing 37
End_Device_Bind_req O O 38
39
Bind_req O O
40
Unbind_req O O 41
Bind_Register_req O O 42
43
Replace_Device_req O O 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 123

Table 2.66 End Device Bind, Bind, Unbind, and Bind


Management Client Service Commands (Continued) 1
Store_Bkup_Bind_Entry_req O O
2
3
Remove_Bkup_Bind_Entry_req O O 4
Backup_Bind_Table_req O O 5
6
Recover_Bind_Table_req O O
7
Backup_Source_Bind_req O O 8
Recover_Source_Bind_req O O 9
10
2.4.3.2.1 End_Device_Bind_req 11
12
The End_Device_Bind_req command (ClusterID=0x0020) shall be formatted as 13
illustrated in Figure 2.42. 14
15
Octets: 16
2 8 1 2 1 Variable 1 Variable
17
Binding SrcIEEE Src Profile Num InCluster Num OutCluster 18
Target Address Endpoint ID InClusters List OutClusters List 19
20
Figure 2.42 Format of the End_Device_Bind_req Command Frame
21
Table 2.67 specifies the fields of the End_Device_Bind_req command frame. 22
23
Table 2.67 Fields of the End_Device_Bind_req Command 24
Name Type Valid Range Description 25
26
BindingTarget Device Address 16-bit NWK The address of the target for the binding. 27
address This can be either the primary binding 28
cache device or the short address of the
local device. 29
30
SrcIEEEAddre IEEE Address A valid 64-bit The IEEE address of the device 31
ss IEEE Address generating the request.
32
SrcEndpoint 8 bits 1-240 The endpoint on the device generating 33
the request. 34
ProfileID Integer 0x0000-0xffff ProfileID which is to be matched 35
between two End_Device_Bind_req 36
received at the ZigBee Coordinator 37
within the timeout value pre-configured
in the ZigBee Coordinator.
38
39
NumInClusters Integer 0x00-0xff The number of Input Clusters provided 40
for end device binding within the
41
InClusterList.
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
124 Application Layer Specification

Table 2.67 Fields of the End_Device_Bind_req Command (Continued)


1
Name Type Valid Range Description 2
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). 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). 17
18
2.4.3.2.1.1 When Generated 19
20
The End_Device_Bind_req is generated from a Local Device wishing to perform 21
End Device Bind with a Remote Device. The End_Device_Bind_req is generated, 22
typically based on some user action like a button press. The destination addressing 23
on this command shall be unicast, and the destination address shall be that of the 24
ZigBee Coordinator. 25
26
2.4.3.2.1.2 Effect on Receipt 27
On receipt of this command, the ZigBee coordinator shall first check that the 28
supplied endpoint is within the specified range. If the supplied endpoint does not 29
fall within the specified range, the ZigBee coordinator shall return an 30
End_Device_Bind_rsp with a status of INVALID_EP. 31
32
If the supplied endpoint is within the specified range, the ZigBee Coordinator 33
shall retain the End_Device_Bind_req for a pre-configured timeout duration 34
awaiting a second End_Device_Bind_req. If the second request does not appear 35
within the timeout period, the ZigBee Coordinator shall generate a TIMEOUT 36
status and return it with the End_Device_Bind_rsp to the originating Local 37
Device. Assuming the second End_Device_Bind_req is received within the 38
timeout period, it shall be matched with the first request on the basis of the 39
ProfileID, InClusterList and OutClusterList. 40
If no match of the ProfileID is detected or if the ProfileID matches but none of the 41
InClusterList or OutClusterList elements match, a status of NO_MATCH shall be 42
supplied to both Local Devices via End_Device_Bind_rsp to each device. If a 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 125

match of Profile ID and at least one input or output clusterID is detected, an


End_Device_Bind_rsp with status SUCCESS shall be issued to each Local 1
Device which generated the End_Device_Bind_req. 2
3
In order to facilitate a toggle action, the ZigBee Coordinator shall then issue an 4
Unbind_req command to the BindingTarget, specifying any one of the matched 5
ClusterID values. If the returned status value is NO_ENTRY, the ZigBee 6
Coordinator shall issue a Bind_req command for each matched ClusterID value. 7
Otherwise, the ZigBee Coordinator shall conclude that the binding records are 8
instead to be removed and shall issue an Unbind_req command for any further 9
matched ClusterID values. 10
The initial Unbind_req and any subsequent Bind_reqs or Unbind_reqs containing 11
the matched clusters shall be directed to one of the BindingTargets specified by 12
the generating devices. The BindingTarget is selected on an individual basis for 13
each matched cluster, as the Binding Target selected by the generating device 14
having that cluster as an output cluster. The SrcAddress field shall contain the 64- 15
bit IEEE address of that same generating device and the SrcEndp field shall 16
contain its endpoint. The DstAddress field shall contain the 64-bit IEEE address 17
of the generating device having the matched cluster in its input cluster list and the 18
DstEndp field shall contain its endpoint. 19
20
2.4.3.2.2 Bind_req 21
The Bind_req command (ClusterID=0x0021) shall be formatted as illustrated in 22
Figure 2.43. 23
24
Octets: 8 1 2 1 2/8 0/1 25
26
SrcAddress SrcEndp ClusterID DstAddrMode DstAddress DstEndp
27
Figure 2.43 Format of the Bind_req Command Frame 28
29
Table 2.68 specifies the fields of the Bind_req command frame. 30
31
Table 2.68 Fields of the Bind_req Command
32
Name Type Valid Range Description 33
34
SrcAddress IEEE A valid 64-bit IEEE The IEEE address for the source.
Address address 35
36
SrcEndp Integer 0x01-0xf0 The source endpoint for the binding 37
entry.
38
ClusterID Integer 0x0000-0xffff The identifier of the cluster on the 39
source device that is bound to the 40
destination.
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
126 Application Layer Specification

Table 2.68 Fields of the Bind_req Command (Continued)


1
Name Type Valid Range Description 2
DstAddrMode Integer 0x00-0xff The addressing mode for the 3
destination address used in this 4
command. This field can take one of 5
the non-reserved values from the 6
following list:
7
0x00 = reserved 8
0x01 = 16-bit group address for 9
DstAddress and DstEndp not present 10
0x02 = reserved
11
12
0x03 = 64-bit extended address for 13
DstAddress and DstEndp present
14
0x04 – 0xff = reserved 15
DstAddress Address As specified by the The destination address for the binding 16
DstAddrMode field entry. 17
18
DstEndp Integer 0x01-0xf0 This field shall be present only if the
DstAddrMode field has a value of 19
0x03 and, if present, shall be the 20
destination endpoint for the binding 21
entry. 22
23
2.4.3.2.2.1 When Generated 24
25
The Bind_req is generated from a Local Device wishing to create a Binding Table 26
entry for the source and destination addresses contained as parameters. The 27
destination addressing on this command shall be unicast only, and the destination 28
address shall be that of a Primary binding table cache or to the SrcAddress itself. 29
The Binding Manager is optionally supported on the source device (unless that 30
device is also the ZigBee Coordinator) so that device shall issue a 31
NOT_SUPPORTED status to the Bind_req if not supported. 32
33
2.4.3.2.2.2 Effect on Receipt 34
Upon receipt, a Remote Device (a Primary binding table cache or the device 35
designated by SrcAddress) shall create a Binding Table entry based on the 36
parameters supplied in the Bind_req if the Binding Manager is supported. If the 37
remote device is a primary binding table cache, the following additional 38
processing is required. First, the primary cache shall check its table of devices 39
holding their own source bindings for the device in SrcAddress and, if it is found, 40
shall issue another Bind_req to that device with the same entry. Second, the 41
primary cache shall check if there is a backup binding table cache and, if so, shall 42
issue a Store_Bkup_Binding_Entry_req command to backup the new entry. The 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 127

Remote Device shall then respond with SUCCESS if the entry has been created by
the Binding Manager; otherwise, the Remote Device shall respond with 1
NOT_SUPPORTED. 2
3
This command shall be subject to a permissions check as defined in sub- 4
clause 4.6.3.8. On failure, the remote device shall not carry out the command, and 5
shall respond with NOT_AUTHORIZED. 6
2.4.3.2.3 Unbind_req 7
8
The Unbind_req command (ClusterID=0x0022) shall be formatted as illustrated 9
in Figure 2.44. 10
11
Octets: 8 1 2 1 2/8 0/1
12
SrcAddress SrcEndp ClusterID DstAddrMode DstAddress DstEndp 13
14
Figure 2.44 Format of the Unbind_req Command Frame 15
16
Table 2.69 specifies the fields of the Unbind_req command frame.
17
Table 2.69 Fields of the Unbind_req Command 18
19
Name Type Valid Range Description
20
SrcAddress IEEE A valid 64-bit IEEE The IEEE address for the source 21
Address address 22
SrcEndp Integer 0x01-0xf0 The source endpoint for the binding 23
entry 24
ClusterID Integer 0x0000-0xffff The identifier of the cluster on the source
25
device that is bound to the destination. 26
27
DstAddrMode Integer 0x00-0xff The addressing mode for the destination
28
address used in this command. This field
can take one of the non-reserved values 29
from the following list: 30
31
0x00 = reserved
32
0x01 = 16-bit group address for
DstAddress and DstEndp not present 33
34
0x02 = reserved
35
0x03 = 64-bit extended address for
DstAddress and DstEndp present 36
37
0x04 – 0xff = reserved
38
DstAddress Address As specified by the The destination address for the binding 39
DstAddrMode field entry.
40
DstEndp Integer 0x01-0xf0 This field shall be present only if the 41
DstAddrMode field has a value of 0x03 42
and, if present, shall be the destination 43
endpoint for the binding entry.
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
128 Application Layer Specification

2.4.3.2.3.1 When Generated


1
The Unbind_req is generated from a Local Device wishing to remove a Binding 2
Table entry for the source and destination addresses contained as parameters. The 3
destination addressing on this command shall be unicast only and the destination 4
address must be that of the a Primary binding table cache or the SrcAddress. 5
6
2.4.3.2.3.2 Effect on Receipt 7
8
The Remote Device shall evaluate whether this request is supported. If the request
9
is not supported, a Status of NOT_SUPPORTED shall be returned. If the request
10
is supported, the Remote Device (a Primary binding table cache or the
11
SrcAddress) shall remove a Binding Table entry based on the parameters supplied
12
in the Unbind_req. If the Remote Device is a primary binding table cache, the
13
following additional processing is required. First, the primary cache shall check
14
its table of devices holding their own source bindings for the device in SrcAddress
15
and, if it is found, shall issue another Unbind_req to that device with the same
16
entry. Second, the primary cache shall check if there is a backup binding table
17
cache and, if so, shall issue a Remove_Bkup_Bind_Entry_req command to
18
remove the backup of this entry. If a Binding Table entry for the SrcAddress,
19
SrcEndp, ClusterID, DstAddress, DstEndp contained as parameters does not exist,
20
the Remote Device shall respond with NO_ENTRY. Otherwise, the Remote
21
Device shall delete the indicated Binding Table entry and respond with
22
SUCCESS.
23
This command shall be subject to a permissions check as defined in sub- 24
clause 4.6.3.8. On failure the remote device shall not carry out the command, and 25
shall respond with NOT_AUTHORIZED. 26
27
2.4.3.2.4 Bind_Register_req
28
The Bind_Register_req command (ClusterID=0x0023) shall be formatted as 29
illustrated in Figure 2.45. 30
31
Octets: 8 32
NodeAddress 33
34
Figure 2.45 Format of the Bind_Register_req Command Frame 35
36
Table 2.70 specifies the fields for the Bind_Register_req command frame. 37
Table 2.70 Fields of the Bind_Register_req Command 38
39
Name Type Valid Range Description 40
NodeAddress IEEE A valid 64-bit IEEE The address of the node wishing to hold 41
Address address its own binding table. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 129

2.4.3.2.4.1 When Generated


1
The Bind_Register_req is generated from a Local Device and sent to a primary 2
binding table cache device to register that the local device wishes to hold its own 3
binding table entries. The destination addressing mode for this request is unicast. 4
5
2.4.3.2.4.2 Effect on Receipt 6
7
If the remote device is not a primary binding table cache it shall return a status of
8
NOT_SUPPORTED. Otherwise, the primary binding table cache shall add the
9
NodeAddress given by the parameter to its table of source devices which have
10
chosen to store their own binding table. If this fails, it shall return a status of
11
TABLE_FULL. Otherwise, it returns a status of SUCCESS. If an entry for the
12
NodeAddress already exists in the table of source devices, the behavior will be the
13
same as if it had been newly added. The source device should clear its source
14
binding table before issuing this command to avoid synchronization problems. In
15
the successful case, any existing bind entries from the binding table whose source
16
address is NodeAddress will be sent to the requesting device for inclusion in its
17
source binding table. See Bind_Register_rsp for further details. Subsequent bind
18
entries written to the binding list will cause copies to be written to the source
19
device using Bind_req.
20
2.4.3.2.5 Replace_Device_req 21
22
The Replace_Device_req command (ClusterID=0x0024) shall be formatted as 23
illustrated in Figure 2.46. 24
Octets: 8 1 8 1 25
26
OldAddress OldEndpoint NewAddress NewEndpoint 27
28
Figure 2.46 Format of the Replace_Device_req Command Frame
29
Table 2.71 specifies the fields for the Replace_Device_req command frame. 30
31
Table 2.71 Fields of the Replace_Device_req Command 32
Name Type Valid Range Description 33
34
OldAddress IEEE Address A valid 64-bit IEEE The address of the node being 35
replaced.
36
OldEndpoint Integer 0x00 - 0xf0 The endpoint being replaced. 37
NewAddress IEEE Address A valid 64-bit IEEE The replacement address. 38
39
NewEndpoint Integer 0x01 - 0xf0 The replacement endpoint. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
130 Application Layer Specification

2.4.3.2.5.1 When Generated


1
The Replace_Device_req is intended for use by a special device such as a 2
Commissioning tool and is sent to a primary binding table cache device to change 3
all binding table entries which match OldAddress and OldEndpoint as specified. 4
Note that OldEndpoint = 0 has special meaning and signifies that only the address 5
needs to be matched. The endpoint in the binding table will not be changed in this 6
case and so NewEndpoint is ignored. The processing changes all binding table 7
entries for which the source address is the same as OldAddress and, if 8
OldEndpoint is non-zero, for which the source endpoint is the same as 9
OldEndpoint. It shall also change all binding table entries which have the 10
destination address the same as OldAddress and, if OldEndpoint is non-zero, the 11
destination endpoint the same as OldEndpoint. The destination addressing mode 12
for this request is unicast. 13
14
2.4.3.2.5.2 Effect on Receipt 15
16
If the remote device is not a primary binding table cache, it shall return a status of
17
NOT_SUPPORTED. The primary binding table cache shall check if the
18
OldAddress parameter is non-zero and, if so, shall search its binding table for
19
entries of source addresses and source endpoint, or destination addresses and
20
destination endpoint, that are set the same as OldAddress and OldEndpoint. It
21
shall change these entries to have NewAddress and NewEndpoint. In the case that
22
OldEndpoint is zero, the primary binding table cache shall search its binding table
23
for entries whose source address or destination address match OldAddress. It shall
24
change these entries to have NewAddress leaving the endpoint value unchanged
25
and ignoring NewEndpoint. It shall then return a response of SUCCESS. The
26
primary binding table cache shall also be responsible for notifying affected
27
devices which are registered as holding their own source binding table of the
28
changes. This will be necessary for each changed binding table entry, where the
29
destination address was changed and the source address appears in the list of
30
source devices which have chosen to store their own binding table. In each of
31
these cases, the amended binding table entry will be sent to the source device
32
using an Unbind_req command for the old entry followed by a Bind_req
33
command for the new one. In the case that the source address of the bind entry has
34
been changed, it will be necessary for the primary binding table cache to send an
35
Unbind_req command to the old source device if it is a source bind device and to
36
send a Bind_req command to the new source bind device if it is a source bind
37
device. The primary binding table cache shall also update the backup binding
38
table cache by means of the Remove_bkup_binding_entry_req command for the
39
old entry and Store_bkup_binding_entry_req for the altered entry.
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 131

2.4.3.2.6 Store_Bkup_Bind_Entry_req
1
The Store_Bkup_Bind_Entry_req command (ClusterID=0x0025) shall be 2
formatted as illustrated in Figure . 3
4
Octets: 8 1 2 1 2/8 0/1
5
SrcAddress SrcEndp ClusterID DstAddrMode DstAddress DstEndp 6
7
Figure 2.47 Format of the Store_Bkup_Bind_Entry_req Command Frame 8
9
Table 2.72 specifies the fields of the Store_Bkup_Bind_Entry_req command 10
frame. 11
Table 2.72 Fields of the Store_Bkup_Bind_Entry_req Command 12
13
Name Type Valid Range Description
14
SrcAddress IEEE Address A valid 64-bit The IEEE address for the source. 15
IEEE address 16
SrcEndpoint Integer 0x01 - 0xf0 The source endpoint for the binding entry. 17
18
ClusterId Integer 0x0000 - 0xffff The identifier of the cluster on the source
device that is bound to the destination.
19
20
DstAddrMo Integer 0x00-0xff The addressing mode for the destination 21
de address used in this command. This field
22
can take one of the non-reserved values
from the following list: 23
24
0x00 = reserved
25
0x01 = 16-bit group address for 26
DstAddress and DstEndp not present
27
0x02 = reserved
28
0x03 = 64-bit extended address for 29
DstAddress and DstEndp present
30
0x04 – 0xff = reserved
31
DstAddress Address As specified by The destination address for the binding 32
the entry. 33
DstAddrMode
34
field
35
DstEndp Integer 0x01-0xf0 This field shall be present only if the 36
DstAddrMode field has a value of 0x03 37
and, if present, shall be the destination
endpoint for the binding entry. 38
39
40
2.4.3.2.6.1 When Generated 41
The Store_Bkup_Bind_Entry_req is generated from a local primary binding table 42
cache and sent to a remote backup binding table cache device to request backup 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
132 Application Layer Specification

storage of the entry. It will be generated whenever a new binding table entry has
been created by the primary binding table cache. The destination addressing mode 1
for this request is unicast. 2
3
2.4.3.2.6.2 Effect on Receipt 4
5
If the remote device is not a backup binding table cache it shall return a status of 6
NOT_SUPPORTED. If it is the backup binding table cache, it should maintain the 7
identity of the primary binding table cache from previous discovery. If the 8
contents of the Store_Bkup_Bind_Entry parameters match an existing entry in the 9
binding table cache, then the remote device shall return SUCCESS. Otherwise, 10
the backup binding table cache shall add the binding entry to its binding table and 11
return a status of SUCCESS. If there is no room, it shall return a status of 12
TABLE_FULL. 13
2.4.3.2.7 Remove_Bkup_Bind_Entry_req 14
15
The Remove_Bkup_Bind_Entry_req command (ClusterID=0x0026) shall be 16
formatted as illustrated in Figure 2.48. 17
18
Octets: 8 1 2 1 2/8 0/1 19
SrcAddress SrcEndp ClusterID DstAddrMode DstAddress DstEndp 20
21
Figure 2.48 Format of the Remove_Bkup_Bind_Entry_req Command Frame 22
23
Table 2.73 specifies the fields of the Remove_Bkup_Bind_Entry_req command 24
frame. 25
Table 2.73 Fields of the Remove_Bkup_Bind_Entry_req Command 26
27
Name Type Valid Range Description 28
SrcAddress IEEE A valid 64-bit The IEEE address for the source. 29
Address IEEE address 30
SrcEndpoint Integer 0x01 - 0xf0 The IEEE address for the binding entry. 31
32
ClusterId Integer 0x0000 - 0xffff The identifier of the cluster on the source 33
device that is bound to the destination.
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 133

Table 2.73 Fields of the Remove_Bkup_Bind_Entry_req Command (Continued)


1
DstAddrMode Integer 0x00-0xff The addressing mode for the destination
address used in this command. This field can
2
take one of the non-reserved values from the 3
following list: 4
0x00 = reserved
5
6
0x01 = 16-bit group address for DstAddress
and DstEndp not present 7
0x02 = reserved
8
9
0x03 = 64-bit extended address for
DstAddress and DstEndp present 10
0x04 – 0xff = reserved
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 endpoint 18
for the binding entry. 19
20
2.4.3.2.7.1 When Generated 21
22
The Remove_Bkup_Bind_Entry_req is generated from a local primary binding 23
table cache and sent to a remote backup binding table cache device to request 24
removal of the entry from backup storage. It will be generated whenever a binding 25
table entry has been unbound by the primary binding table cache. The destination 26
addressing mode for this request is unicast. 27
28
2.4.3.2.7.2 Effect on Receipt 29
30
If the remote device is not a backup binding table cache, it shall return a status of 31
NOT_SUPPORTED. If it is a backup binding table cache, it should maintain the 32
identity of the primary binding table cache from previous discovery. If it does not 33
recognize the sending device as the primary binding table cache, it shall return a 34
status of INV_REQUESTTYPE. Otherwise, the backup binding table cache shall 35
search its binding table for the entry corresponding to the supplied parameters. If 36
no entry is found, it shall return a status of NO_ENTRY. Otherwise, it shall delete 37
the entry and return a status of SUCCESS. 38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
134 Application Layer Specification

2.4.3.2.8 Backup_Bind_Table_req
1
The Backup_Bind_Table_req command (ClusterID=0x0027) shall be formatted 2
as illustrated in Figure 2.49. 3
4
Octets: 2 2 2 Variable
5
BindingTableEntries StartIndex BindingTableListCount BindingTableList 6
7
Figure 2.49 Format of the Backup_Bind_Table_req Command Frame 8
9
Table 2.74 specifies the fields of the Backup_Bind_Table_req command frame. 10
Table 2.74 Fields of the Backup_Bind_Table_req Command 11
12
Name Type Valid Range Description
13
BindingTableEntries Integer 0x0000 - 0xffff Total number of binding 14
table entries on the primary 15
binding table cache device. 16
StartIndex Integer 0x0000 - 0xffff Starting index within the 17
binding table of entries. 18
BindingTableListCount Integer 0x0000 - 0xffff Number of binding table 19
entries included within 20
BindingTableList. 21
BindingTableList List of The list shall contain A list of descriptors 22
binding the number of elements beginning with the 23
descriptors given by the StartIndex element and 24
BindingTableListCount continuing for 25
BindingTableListCount of
26
the elements in the primary
binding table cache devices’s 27
binding table (see 28
Table 2.130 for details.) 29
30
2.4.3.2.8.1 When Generated 31
32
The Backup_Bind_Table_req is generated from a local primary binding table 33
cache and sent to the remote backup binding table cache device to request backup 34
storage of its entire binding table. The destination addressing mode for this 35
request is unicast. 36
37
2.4.3.2.8.2 Effect on Receipt 38
39
If the remote device is not a backup binding table cache, it shall return a status of
40
NOT_SUPPORTED. If it is a backup binding table cache, it should maintain the
41
identity of the primary binding table cache from previous discovery. If it does not
42
recognize the sending device as a primary binding table cache, it shall return a
43
status of INV_REQUESTTYPE. Otherwise, the backup binding table cache shall
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 135

overwrite the binding entries in its binding table starting with StartIndex and
continuing for BindingTableListCount entries. If this exceeds its table size, it shall 1
fill in as many entries as possible and return a status of TABLE_FULL. 2
Otherwise, it shall return a status of SUCCESS. The table is effectively truncated 3
to the end of the last entry written by this request. The new size of the table is 4
returned in the response and will be equal to StartIndex + BindingTableListCount 5
unless TABLE_FULL is being returned it which case it will be the maximum size 6
of the table. 7
8
2.4.3.2.9 Recover_Bind_Table_req 9
The Recover_Bind_Table_req command (ClusterID=0x0028) shall be formatted 10
as illustrated in Figure 2.50. 11
12
Octets: 2 13
14
StartIndex
15
Figure 2.50 Fields of the Recover_Bind_Table_req Command Frame 16
17
Table 2.75 specifies the fields of the Recover_Bind_Table_req command frame. 18
19
Table 2.75 Fields of the Recover_Bind_Table_req Command
20
Name Type Valid Range Description 21
22
StartIndex Integer 0x0000 - 0xffff Starting index for the requested
elements of the binding table 23
24
25
2.4.3.2.9.1 When Generated 26
The Recover_Bind_Table_req is generated from a local primary binding table 27
cache and sent to a remote backup binding table cache device when it wants a 28
complete restore of the binding table. The destination addressing mode for this 29
request is unicast. 30
31
2.4.3.2.9.2 Effect on Receipt 32
33
If the remote device is not the backup binding table cache, it shall return a status 34
of NOT_SUPPORTED. If it does not recognize the sending device as a primary 35
binding table cache it shall return a status of INV_REQUESTTYPE. Otherwise, 36
the backup binding table cache shall prepare a list of binding table entries from its 37
backup beginning with StartIndex. It will fit in as many entries as possible into a 38
Recover_Bind_Table_rsp command and return a status of SUCCESS. 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
136 Application Layer Specification

2.4.3.2.10 Backup_Source_Bind_req
1
The Backup_Source_Bind_req command (ClusterID=0x0029) shall be formatted 2
as illustrated in Figure 2.51. 3
4
Octets: 2 2 2 Variable
5
SourceTableEntries StartIndex SourceTableListCount SourceTableList 6
7
Figure 2.51 Fields of the Backup_Source_Bind_req Command Frame 8
9
Table 2.76 specifies the fields of the Backup_Source_Bind_req command frame. 10
Table 2.76 Fields of the Backup_Source_Bind_req Command 11
12
Name Type Valid Range Description
13
SourceTableEntries Integer 0x0000 - 0xffff Total number of source table 14
entries on the primary binding 15
table cache device. 16
StartIndex Integer 0x0000 - 0xffff Starting index within the 17
binding table of the entries in 18
SourceTableList. 19
SourceTableListCount Integer 0x0000 - 0xffff Number of source table entries 20
included within 21
SourceTableList. 22
SourceTableList List of The list shall contain A list of addresses beginning 23
IEEE the number of with the StartIndex element and 24
Addresses elements given by the continuing for 25
SourceTableListCount SourceTableListCount of
26
source addresses in the primary
binding table cache device’s 27
source table. 28
29
30
2.4.3.2.10.1 When Generated
31
The Backup_Source_Bind_req is generated from a local primary binding table 32
cache and sent to a remote backup binding table cache device to request backup 33
storage of its entire source table. The destination addressing mode for this request 34
is unicast. 35
36
2.4.3.2.10.2 Effect on Receipt 37
38
If the remote device is not the backup binding table cache, it shall return a status 39
of NOT_SUPPORTED. If it does not recognize the sending device as a primary 40
binding table cache, it shall return a status of INV_REQUESTTYPE. Otherwise, 41
the backup binding table cache shall overwrite the source entries in its backup 42
source table starting with StartIndex and continuing for SourceTableListCount 43
entries. If this exceeds its table size, it shall return a status of TABLE_FULL. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 137

Otherwise, it shall return a status of SUCCESS. The command always truncates


the backup table to a number of entries equal to its maximum size or 1
SourceTableEntries, whichever is smaller. 2
3
2.4.3.2.11 Recover_Source_Bind_req 4
The Recover_Source_Bind_req command (ClusterID=0x002a) shall be formatted 5
as illustrated in Figure 2.52. 6
7
Octets: 2 8
9
StartIndex
10
Figure 2.52 Format of the Recover_Source_Bind_req Command Frame 11
12
Table 2.77 specifies the fields of the Recover_Source_Bind_req command frame. 13
14
Table 2.77 Fields of the Recover_Source_Bind_req Command
15
Name Type Valid Range Description 16
17
StartIndex Integer 0x0000 - 0xffff Starting index for the requested
elements of the binding table 18
19
20
2.4.3.2.11.1 When Generated 21
The Recover_Source_Bind_req is generated from a local primary binding table 22
cache and sent to the remote backup binding table cache device when it wants a 23
complete restore of the source binding table. The destination addressing mode for 24
this request is unicast. 25
26
2.4.3.2.11.2 Effect on Receipt 27
28
If the remote device is not the backup binding table cache it shall return a status of 29
NOT_SUPPORTED. If it does not recognize the sending device as a primary 30
binding table cache, it shall return a status of INV_REQUESTTYPE. Otherwise, 31
the backup binding table cache shall prepare a list of source binding table entries 32
from its backup beginning with StartIndex. It will fit in as many entries as 33
possible into a Recover_Source_Bind_rsp command and return a status of 34
SUCCESS. 35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
138 Application Layer Specification

2.4.3.3 Network Management Client Services


1
Table 2.78 lists the commands supported by Device Profile: Network 2
Management Client Services. Each of these primitives will be discussed in the 3
following sub-clauses. 4
Table 2.78 Network Management Client Services Commands 5
6
Network Management Client Server 7
Client Services Transmission Processing 8
Mgmt_NWK_Disc_req O O 9
10
Mgmt_Lqi_req O O
11
Mgmt_Rtg_req O O 12
Mgmt_Bind_req O O 13
14
Mgmt_Leave_req O O 15
Mgmt_Direct_Join_req O O 16
Mgmt_Permit_Joining_req O M
17
18
Mgmt_Cache_req O O 19
Mgmt_NWK_Update_req O O 20
21
2.4.3.3.1 Mgmt_NWK_Disc_req 22
23
The Mgmt_NWK_Disc_req command (ClusterID=0x0030) shall be formatted as 24
illustrated in Figure 2.53. 25
26
Octets: 4 1 1 27
ScanChannels ScanDuration StartIndex 28
29
Figure 2.53 Format of the Mgmt_NWK_Disc_req Command Frame 30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 139

Table 2.79 specifies the fields for the Mgmt_NWK_Disc_req command frame.
1
Table 2.79 Fields of the Mgmt_NWK_Disc_req Command
2
Valid 3
Name Type Range Description 4
5
ScanChannels Bitmap 32-bit field See (sub-clause 3.2.2.1) for details
on NLME-NETWORK- 6
DISCOVERY.request ScanChannels 7
parameter. 8
ScanDuration Integer 0x00-0x0e A value used to calculate the length 9
of time to spend scanning each 10
channel. The time spent scanning 11
each channel is 12
(aBaseSuperframeDuration * (2n + 13
1)) symbols, where n is the value of
the ScanDuration parameter. For 14
more information on MAC sub-layer 15
scanning (see [B1]. 16
StartIndex Integer 0x00-0xff Starting index within the resulting 17
NLME-NETWORK- 18
DISCOVERY.confirm NetworkList 19
to begin reporting for the 20
Mgmt_NWK_Disc_rsp. 21
22
2.4.3.3.1.1 When Generated 23
24
The Mgmt_NWK_Disc_req is generated from a Local Device requesting that the 25
Remote Device execute a Scan to report back networks in the vicinity of the Local 26
Device. The destination addressing on this command shall be unicast. 27
28
2.4.3.3.1.2 Effect on Receipt 29
The Remote Device shall execute an NLME-NETWORK-DISCOVERY.request 30
using the ScanChannels and ScanDuration parameters supplied with the 31
Mgmt_NWK_Disc_req command. The results of the Scan shall be reported back 32
to the Local Device via the Mgmt_NWK_Disc_rsp command. 33
34
If this command is not supported in the Remote Device, the return status provided 35
with the Mgmt_NWK_Disc_rsp shall be NOT_SUPPORTED. If the scan was 36
successful, the Mgmt_NWK_Disc_rsp command shall contain a status of 37
SUCCESS and the results of the scan shall be reported, beginning with the 38
StartIndex element of the NetworkList. If the scan was unsuccessful, the 39
Mgmt_NWK_Disc_rsp command shall contain the error code reported in the 40
NLME-NETWORK-DISCOVERY.confirm primitive. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
140 Application Layer Specification

2.4.3.3.2 Mgmt_Lqi_req
1
The Mgmt_Lqi_req command (ClusterID=0x0031) shall be formatted as 2
illustrated in Figure 2.54. 3
4
Octets: 1
5
StartIndex 6
7
Figure 2.54 Format of the Mgmt_Lqi_req Command Frame 8
9
Table 2.80 specifies the fields for the Mgmt_NWK_Disc_req command frame. 10
Table 2.80 Fields of the Mgmt_Lqi_req Command 11
12
Valid
Name Type Range Description 13
14
StartIndex Integer 0x00-0xff Starting Index for the requested elements of the 15
Neighbor Table. 16
17
2.4.3.3.2.1 When Generated 18
19
The Mgmt_Lqi_req is generated from a Local Device wishing to obtain a 20
neighbor list for the Remote Device along with associated LQI values to each 21
neighbor. The destination addressing on this command shall be unicast only and 22
the destination address must be that of a ZigBee Coordinator or ZigBee Router. 23
24
2.4.3.3.2.2 Effect on Receipt 25
Upon receipt, a Remote Device (ZigBee Router or ZigBee Coordinator) shall 26
retrieve the entries of the neighbor table and associated LQI values via the 27
NLME-GET.request primitive (for the nwkNeighborTable attribute) and report the 28
resulting neighbor table (obtained via the NLME-GET.confirm primitive) via the 29
Mgmt_Lqi_rsp command. 30
31
If this command is not supported in the Remote Device, the return status provided 32
with the Mgmt_Lqi_rsp shall be NOT_SUPPORTED. If the neighbor table was 33
obtained successfully, the Mgmt_Lqi_rsp command shall contain a status of 34
SUCCESS and the neighbor table shall be reported, beginning with the element in 35
the list enumerated as StartIndex. If the neighbor table was not obtained 36
successfully, the Mgmt_Lqi_rsp command shall contain the error code reported in 37
the NLME-GET.confirm primitive. 38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 141

2.4.3.3.3 Mgmt_Rtg_req
1
The Mgmt_Rtg_req command (ClusterID=0x0032) shall be formatted as 2
illustrated in Figure 2.55. 3
4
Octets: 1
5
StartIndex 6
7
Figure 2.55 Format of the Mgmt_Rtg_req Command Frame 8
9
Table 2.81 specifies the fields for the Mgmt_Rtg_req command frame. 10
Table 2.81 Fields of the Mgmt_Rtg_req Command 11
12
Name Type Valid Range Description
13
StartIndex Integer 0x00-0xff Starting Index for the requested elements of the 14
Routing Table 15
16
2.4.3.3.3.1 When Generated 17
18
The Mgmt_Rtg_req is generated from a Local Device wishing to retrieve the 19
contents of the Routing Table from the Remote Device. The destination 20
addressing on this command shall be unicast only and the destination address 21
must be that of the ZigBee Router or ZigBee Coordinator. 22
23
2.4.3.3.3.2 Effect on Receipt 24
25
Upon receipt, a Remote Device (ZigBee Coordinator or ZigBee Router) shall
26
retrieve the entries of the routing table from the NWK layer via the NLME-
27
GET.request primitive (for the nwkRouteTable attribute) and report the resulting
28
routing table (obtained via the NLME-GET.confirm primitive) via the
29
Mgmt_Rtg_rsp command.
30
If the Remote Device does not support this optional management request, it shall 31
return a Status of NOT_SUPPORTED. If the routing table was obtained 32
successfully, the Mgmt_Rtg_req command shall contain a status of SUCCESS 33
and the routing table shall be reported, beginning with the element in the list 34
enumerated as StartIndex. If the routing table was not obtained successfully, the 35
Mgmt_Rtg_rsp command shall contain the error code reported in the NLME- 36
GET.confirm primitive. 37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
142 Application Layer Specification

2.4.3.3.4 Mgmt_Bind_req
1
The Mgmt_Bind_req command (ClusterID=0x0033) shall be formatted as 2
illustrated in Figure 2.56. 3
4
Octets: 1
5
StartIndex 6
7
Figure 2.56 Format of the Mgmt_Bind_req Command Frame 8
9
Table 2.82 specifies the fields for the Mgmt_Bind_req command frame. 10
Table 2.82 Fields of the Mgmt_Bind_req Command 11
12
Name Type Valid Range Description
13
StartIndex Integer 0x00-0xff Starting Index for the requested 14
elements of the Binding Table. 15
16
2.4.3.3.4.1 When Generated 17
18
The Mgmt_Bind_req is generated from a Local Device wishing to retrieve the 19
contents of the Binding Table from the Remote Device. The destination 20
addressing on this command shall be unicast only and the destination address 21
must be that of a Primary binding table cache or source device holding its own 22
binding table. 23
24
2.4.3.3.4.2 Effect on Receipt 25
26
Upon receipt, a Remote Device shall retrieve the entries of the binding table from
27
the APS sub-layer via the APSME-GET.request primitive (for the
28
apsBindingTable attribute) and report the resulting binding table (obtained via the
29
APSME-GET.confirm primitive) via the Mgmt_Bind_rsp command.
30
If the Remote Device does not support this optional management request, it shall 31
return a status of NOT_SUPPORTED. If the binding table was obtained 32
successfully, the Mgmt_Bind_rsp command shall contain a status of SUCCESS 33
and the binding table shall be reported, beginning with the element in the list 34
enumerated as StartIndex. If the binding table was not obtained successfully, the 35
Mgmt_Bind_rsp command shall contain the error code reported in the APSME- 36
GET.confirm primitive. 37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 143

2.4.3.3.5 Mgmt_Leave_req
1
The Mgmt_Leave_req command (ClusterID=0x0034) shall be formatted as 2
illustrated in Figure 2.57. 3
4
Bits: 64 6 1 1
5
Device Address Reserved Remove Children Rejoin 6
7
Figure 2.57 Format of the Mgmt_Leave_req Command Frame 8
9
Table 2.83 specifies the fields for the Mgmt_Leave_req command frame. 10
Table 2.83 Fields of the Mgmt_Leave_req Command 11
12
Name Type Valid Range Description
13
DeviceAddress Device An extended 64- See (sub-clause 3.2.2.16) for details 14
Address bit, IEEE address on the DeviceAddress parameter 15
within NLME-LEAVE.request. For 16
DeviceAddress of NULL, a value of
0x0000000000000000 shall be 17
used.a 18
19
Remove Bit 0 or 1 This field has a value of 1 if the
Children device being asked to leave the 20
network is also being asked to 21
remove its child devices, if any. 22
Otherwise, it has a value of 0. 23
Rejoin Bit 0 or 1 This field has a value of 1 if the 24
device being asked to leave from the 25
current parent is requested to rejoin 26
the network. Otherwise, it has a 27
value of 0.
28
a. CCB #849 29
30
2.4.3.3.5.1 When Generated 31
32
The Mgmt_Leave_req is generated from a Local Device requesting that a Remote 33
Device leave the network or to request that another device leave the network. The 34
Mgmt_Leave_req is generated by a management application which directs the 35
request to a Remote Device where the NLME-LEAVE.request is to be executed 36
using the parameter supplied by Mgmt_Leave_req. 37
38
2.4.3.3.5.2 Effect on Receipt 39
40
Upon receipt, the remote device shall issue the NLME-LEAVE.request primitive
41
using the parameters supplied with the Mgmt_Leave_req command. The results
42
of the leave attempt shall be reported back to the local device via the
43
Mgmt_Leave_rsp command.
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
144 Application Layer Specification

If the remote device does not support this optional management request, it shall
return a status of NOT_SUPPORTED. If the leave attempt was executed 1
successfully, the Mgmt_Leave_rsp command shall contain a status of SUCCESS. 2
If the leave attempt was not executed successfully, the Mgmt_Leave_rsp 3
command shall contain the error code reported in the NLME-LEAVE.confirm 4
primitive. 5
6
This command shall be subject to a permissions check as defined in sub- 7
clause 4.6.3.8. On failure the remote device shall not carry out the command, and 8
shall respond with NOT_AUTHORIZED. 9
2.4.3.3.6 Mgmt_Direct_Join_req 10
11
The Mgmt_Direct_Join_req command (ClusterID=0x0035) shall be formatted as 12
illustrated in Figure 2.58. 13
14
Octets: 8 1
15
Device Address Capability 16
Information 17
18
Figure 2.58 Format of the Mgmt_Direct_Join _req Command Frame
19
Table 2.84 specifies the fields for the Mgmt_Direct_Join_req command frame. 20
21
Table 2.84 Fields of the Mgmt_Direct_Join_req Command 22
Name Type Valid Range Description 23
24
DeviceAddress Device An extended 64-bit, See sub-clause 3.2.2.14 for details 25
Address IEEE address on the DeviceAddress parameter 26
within NLME-DIRECT-
JOIN.request. 27
28
CapabilityInformation Bitmap See Table 3.47 The operating capabilities of the 29
device being directly joined.
30
31
2.4.3.3.6.1 When Generated 32
33
The Mgmt_Direct_Join_req is generated from a Local Device requesting that a
34
Remote Device permit a device designated by DeviceAddress to join the network
35
directly. The Mgmt_Direct_Join_req is generated by a management application
36
which directs the request to a Remote Device where the NLME-DIRECT-
37
JOIN.request is to be executed using the parameter supplied by
38
Mgmt_Direct_Join_req.
39
40
2.4.3.3.6.2 Effect on Receipt
41
Upon receipt, the remote device shall issue the NLME-DIRECT-JOIN.request 42
primitive using the DeviceAddress and CapabilityInformation parameters 43
supplied with the Mgmt_Direct_Join_req command. The results of the direct join 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 145

attempt shall be reported back to the local device via the Mgmt_Direct_Join_rsp
command. 1
2
If the remote device does not support this optional management request, it shall 3
return a status of NOT_SUPPORTED. If the direct join attempt was executed 4
successfully, the Mgmt_Direct_Join_rsp command shall contain a status of 5
SUCCESS. If the direct join attempt was not executed successfully, the 6
Mgmt_Direct_Join_rsp command shall contain the error code reported in the 7
NLME-DIRECT-JOIN.confirm primitive. 8
This command shall be subject to a permissions check as defined in sub- 9
clause 4.6.3.8. On failure the remote device shall not carry out the command, and 10
shall respond with NOT_AUTHORIZED. 11
12
2.4.3.3.7 Mgmt_Permit_Joining_req 13
The Mgmt_Permit_Joining_req command (ClusterID=0x0036) shall be formatted 14
as illustrated in Figure 2.59. 15
16
Octets: 1 1 17
18
PermitDuration TC_Significance
19
Figure 2.59 Format of the Mgmt_Permit_Joining_req Command Frame 20
21
Table 2.85 specifies the fields of the Mgmt_Permit_Joining_req command frame. 22
23
Table 2.85 Fields of the Mgmt_Permit_Joining_req Command
24
Name Type Valid Range Description 25
26
PermitDuration Integer 0x00 - 0xff See sub-clause 3.2.2.5 for details on the
PermitDuration parameter within NLME- 27
PERMIT-JOINING.request. 28
29
TC_Significance Boolean 0x00 - 0x01 If this is set to 0x01 and the remote device is
Integer the Trust Center, the command affects the 30
Trust Center authentication policy as 31
described in the sub-clauses below; If this is 32
set to 0x00, there is no effect on the Trust 33
Center. 34
35
2.4.3.3.7.1 When Generated 36
37
The Mgmt_Permit_Joining_req is generated from a Local Device requesting that 38
a remote device or devices allow or disallow association. The 39
Mgmt_Permit_Joining_req is generated by a management application or 40
commissioning tool which directs the request to a remote device(s) where the 41
NLME-PERMIT-JOINING.request is executed using the PermitDuration 42
parameter supplied by Mgmt_Permit_Joining_req. Additionally, if the remote 43
device is the Trust Center and TC_Significance is set to 1, the Trust Center 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
146 Application Layer Specification

authentication policy will be affected. The addressing may be unicast or


‘broadcast to all routers and coordinator’. 1
2
2.4.3.3.7.2 Effect on Receipt 3
4
Upon receipt, the remote device(s) shall issue the NLME-PERMIT- 5
JOINING.request primitive using the PermitDuration parameter supplied with the 6
Mgmt_Permit_Joining_req command. If the PermitDuration parameter is not 7
equal to zero or 0xFF, the parameter is a number of seconds and joining is 8
permitted until it counts down to zero, after which time, joining is not permitted. 9
If the PermitDuration is set to zero, joining is not permitted. If set to 0xFF, joining 10
is permitted indefinitely or until another Mgmt_Permit_Joining_req is received. If 11
a second Mgmt_Permit_Joining_req is received while the previous one is still 12
counting down, it will supersede the previous request. Additionally, if the remote 13
device is the Trust Center and TC_Significance is set to 1, the Trust Center 14
authentication policy will be affected. In this case, if PermitDuration is set to a 15
non-zero value, Trust Center authentication is allowed so that when the Trust 16
Center receives an NLME-JOIN.indication or an APSME-UPDATE- 17
DEVICE.indication indicating that a new device has joined, it will authenticate it 18
and issue a security key as appropriate. Alternatively, if PermitDuration is set to 19
zero, Trust Center authentication will be disallowed with the effect that if an 20
APSME-UPDATE-DEVICE.indication is received indicating that a new device 21
has joined, The Trust Center shall then issue an APSME-REMOVE- 22
DEVICE.request to refuse the new device. Note that the TC_Significance flag and 23
the Trust Center action will be subject to the security policy imposed by the stack 24
profile. Particularly, the Trust Center may be configured not to act on this flag 25
unless it has been sent by particular trusted devices such as configuration tools 26
which are known to the Trust Center. Similarly, the main command features may 27
be disallowed under some stack profiles unless the sending device can be 28
authenticated as a known configuration device. If the command is not permitted, a 29
response of INVALID_REQUEST shall be sent (unless the command was a 30
‘broadcast to all routers and coordinator’ in which case no response shall be sent) 31
If the Mgmt_Permit_Joining_req primitive was received as a unicast, the results 32
of the NLME-PERMIT-JOINING.request shall be reported back to the local 33
device via the Mgmt_Permit_Joining_rsp command. If the command was 34
received as a broadcast, no response shall be sent back. 35
This command shall be subject to a permissions check as defined in sub- 36
clause 4.6.3.8. On failure, the remote device shall not carry out the command, and 37
shall respond with NOT_AUTHORIZED if the Mgmt_Permit_Joining_req was 38
received as an unicast, and shall not respond otherwise. 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 147

2.4.3.3.8 Mgmt_Cache_req
1
The Mgmt_Cache_req command (ClusterID=0x0037) shall be formatted as 2
illustrated in Figure 2.60. 3
4
Octets: 1
5
StartIndex 6
7
Figure 2.60 Fields of the Mgmt_Cache_req Command Frame 8
9
Table 2.86 specifies the fields of the Mgmt_Cache_req command frame. 10
Table 2.86 Fields of the Mgmt_Cache_req Command 11
12
Valid
Name Type Range Description 13
14
StartIndex Integer 0x00 - 0xff Starting Index for the requested 15
elements of the discovery cache list. 16
17
2.4.3.3.8.1 When Generated 18
19
The Mgmt_Cache_req is provided to enable ZigBee devices on the network to 20
retrieve a list of ZigBee End Devices registered with a Primary Discovery Cache 21
device. The destination addressing on this primitive shall be unicast. 22
23
2.4.3.3.8.2 Effect on Receipt 24
Upon receipt, the Remote Device shall determine whether it is a Primary 25
Discovery Cache or whether this optional request primitive is supported. If it is 26
not a Primary Discovery Cache device or the Mgmt_Cache_req primitive is not 27
supported, the Remote Device shall return a status of NOT_SUPPORTED. If the 28
Remote Device is a Primary Discovery Cache and supports the Mgmt_Cache_req, 29
the Remote Device shall return SUCCESS to the Local Device along with the 30
discovery cache list which consists of the NWKAddr and IEEEaddr for each 31
ZigBee End Device registered. 32
33
2.4.3.3.9 Mgmt_NWK_Update_req 34
The Mgmt_NWK_Update_req command (ClusterID=0x0038) shall be formatted 35
as illustrated in Figure 2.61. 36
37
Octets: 4 1 0/1 0/1 0/2 38
39
ScanChannels ScanDuration ScanCount nwkUpdateId nwkManagerAddr
40
Figure 2.61 Fields of the Mgmt_NWK_Update_req Command Frame 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
148 Application Layer Specification

Table 2.87 specifies the fields of the Mgmt_NWK_Update_req command frame.


1
Table 2.87 Fields of the Mgmt_NWK_Update_req Command
2
Valid 3
Name Type Range Description 4
5
ScanChannels Bitmap 32-bit field See (sub-clause 3.2.2.1) for details
on NLME-ED-SCAN.request 6
ScanChannels parameter. 7
8
ScanDuration Integer 0x00-0x05 or A value used to calculate the length
0xff of time to spend scanning each 9
channel. The time spent scanning 10
each channel is 11
(aBaseSuperframeDuration * (2n + 12
1)) symbols, where n is the value of 13
the ScanDuration parameter. For
more information on MAC sub-layer 14
scanning (see [B1]). 15
16
If ScanDuration has a value of 0xfe
this is a request for channel change. 17
18
If ScanDuration has a value of 0xff 19
this is a request to change the
apsChannelMask and 20
nwkManagerAddr parameters. 21
22
ScanCount Integer 0x00 - 0x05 This field represents the number of
energy scans to be conducted and 23
reported. 24
25
This field shall be present only if the
ScanDuration is within the range of 26
0x00 to 0x05. 27
28
nwkUpdateId Integer 0x00 - 0xFF The value of the nwkUpdateId
contained in this request. This value
29
is set by the Network Channel 30
Manager prior to sending the 31
message. 32
This field shall only be present of the 33
ScanDuration is 0xfe or 0xff. 34
35
nwkManagerAddr Device 16-bit NWK This field shall be present only if the
Address address ScanDuration is set to 0xff, and, 36
where present, indicates the NWK 37
address for the device with the 38
Network Manager bit set in its Node 39
Descriptor.
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 149

2.4.3.3.9.1 When Generated


1
This command is provided to allow updating of network configuration parameters 2
or to request information from devices on network conditions in the local 3
operating environment. The destination addressing on this primitive shall be 4
unicast or broadcast to all devices for which macRxOnWhenIdle = TRUE. 5
6
2.4.3.3.9.2 Effect on Receipt 7
8
Upon receipt, the Remote Device shall determine from the contents of the
9
ScanDuration parameter whether this request is an update to the apsChannelMask
10
and nwkManagerAddr parameters, a channel change command, or a request to
11
scan channels and report the results.
12
If the ScanDuration parameter is equal to 0xfe, the command provides a new 13
active channel as a single channel in the ChannelMask in which case the APS IB 14
is not updated but the procedure for changing channels is completed. 15
16
If the ScanDuration parameter is equal to 0xff, the command provides a set of new
17
apsChannelMask along with a new nwkManagerAddr. The Remote Device shall
18
store the apsChannelMask in the APS IB and the nwkManagerAddr in the NIB
19
without invocation of an NLME-ED-SCAN.request.
20
If this command is unicast with ScanDuration set to 0xfe or 0xff, the Remote 21
Device shall not respond. The network manager should request an APS 22
acknowledgement in this case. 23
24
If the ScanDuration is equal to 0x00 to 0x05 and the destination addressing on this
25
command was unicast then the command is interpreted as a request to scan the
26
channels described in ChannelMask, using the parameter ScanDuration and
27
ScanCount, via invocation of an NLME-ED-SCAN.request. If the Remote Device
28
does not support fragmentation and the resulting response will exceed the APDU,
29
the Remote Device shall perform the Energy Detect Scan on as many of the
30
requested channels as will fit into a single APDU, highlighting the list of actual
31
scanned channels in the response parameter. If multiple scans are requested in the
32
ScanCount, each scan is reported as a separate result. The Remote Device will
33
employ an Energy Detect Scan using the request parameters, modified by the
34
limitation described for fragmentation, and supply the results to the requesting
35
device with a Mgmt_NWK_Update_notify with a SUCCESS status.
36
Otherwise, if the ScanDuration is equal to 0x06 to 0xfd and the destination 37
addressing on this command was unicast then the Remote Device shall return a 38
status of INVALID_REQUEST. 39
40
If the destination addressing on this command was not unicast then the Remote
41
Device shall not transmit a response.
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
150 Application Layer Specification

2.4.4 Server Services 1


2
The Device Profile Server Services support the processing of device and service
3
discovery requests, end device bind requests, bind requests, unbind requests, and
4
network management requests. Additionally, Server Services support
5
transmission of these responses back to the requesting device.
6
For all broadcast addressed requests (of any broadcast address type) to the server, 7
if the command is not supported, the server shall drop the packet. No error status 8
shall be unicast back to the Local Device for any broadcast addressed client 9
request including, but not limited to, requests which are not supported on the 10
server. 11
12
For all unicast addressed requests to the server, if the command is not supported,
13
the server shall formulate a response packet including the response Cluster ID and
14
status fields only. The response Cluster ID shall be created by taking the request
15
Cluster ID and setting the high order bit to create the response Cluster ID. The
16
status field shall be set to NOT_SUPPORTED. The resulting response shall be
17
unicast to the requesting client.
18
2.4.4.1 Device and Service Discovery Server 19
20
Table 2.88 lists the commands supported by the Device and Service Discovery 21
Server Services device profile. Each of these commands will be discussed in the 22
following sub-clauses. For receipt of the Device_annce command, the server shall 23
check all internal references to the IEEE and 16-bit NWK addresses supplied in 24
the request. For all references to the IEEE address in the Local Device, the 25
corresponding NWK address supplied in the Device_annce shall be substituted. 26
For any other references to the NWK address in the Local Device, the 27
corresponding entry shall be marked as not having a known valid 16-bit NWK 28
address. The server shall not supply a response to the Device_annce. 29
Table 2.88 Device and Service Discovery Server Service Primitives
30
31
Device and Service 32
Discovery Server 33
Server Services Processing 34
NWK_addr_rsp M 35
36
IEEE_addr_rsp M
37
Node_Desc_rsp M 38
Power_Desc_rsp M 39
40
Simple_Desc_rsp M
41
Active_EP_rsp M 42
Match_Desc_rsp M 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 151

Table 2.88 Device and Service Discovery Server Service Primitives (Continued)
1
Device and Service 2
Discovery Server
Server Services Processing 3
4
Complex_Desc_rsp O 5
User_Desc_rsp O 6
7
User_Desc_conf O
8
System_Server_Discovery_rsp O 9
Discovery_store_rsp O 10
11
Node_Desc_store_rsp O 12
Power_Desc_store_rsp O 13
Active_EP_store_rsp O
14
15
Simple_Desc_store_rsp O 16
Remove_node_cache_rsp O 17
18
Find_node_cache_rsp O
19
Extended_Simple_Desc_rsp O 20
Extended_Active_EP_rsp O 21
22
2.4.4.1.1 NWK_addr_rsp 23
24
The NWK_addr_rsp command (ClusterID=0x8000) shall be formatted as 25
illustrated in Figure 2.62. 26
27
Octets: 1 8 2 0/1 0/1 Variable 28
Status IEEEAddr NWKAddr Num StartIndex NWKAddr 29
RemoteDev RemoteDev AssocDev AssocDevList 30
31
Figure 2.62 Format of the NWK_addr_rsp Command Frame 32
33
Table 2.89 specifies the fields of the NWK_addr_rsp command frame. 34
Table 2.89 Fields of the NWK_addr_rsp Command 35
36
Name Type Valid Range Description
37
Status Integer SUCCESS, The status of the 38
INV_REQUESTTYPE or NWK_addr_req command. 39
DEVICE_NOT_FOUND 40
IEEEAddrRemoteDev Device An extended 64-bit, IEEE 64-bit address for the Remote 41
Address address Device. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
152 Application Layer Specification

Table 2.89 Fields of the NWK_addr_rsp Command (Continued)


1
Name Type Valid Range Description 2
NWKAddrRemoteDev Device A 16-bit, NWK address 16-bit address for the Remote 3
Address Device. 4
5
NumAssocDev Integer 0x00-0xff Count of the number of 16-
bit short addresses to follow. 6
7
If the RequestType in the
8
request is Extended Response
and there are no associated 9
devices on the Remote 10
Device, this field shall be set 11
to 0. 12
If an error occurs or the 13
RequestType in the request is 14
for a Single Device 15
Response, this field shall not
16
be included in the frame.
17
StartIndex Integer 0x00-0xff Starting index into the list of 18
associated devices for this
19
report.
20
If the RequestType in the 21
request is Extended Response
22
and there are no associated
devices on the Remote 23
Device, this field shall not be 24
included in the frame. 25
If an error occurs or the 26
RequestType in the request is 27
for a Single Device 28
Response, this field shall not 29
be included in the frame.
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 153

Table 2.89 Fields of the NWK_addr_rsp Command (Continued)


1
Name Type Valid Range Description 2
NWKAddrAssocDevLi Device List of NumAssocDev A list of 16-bit addresses, one 3
st Address 16-bit short addresses, corresponding to each 4
List each with range associated device to Remote 5
0x0000 - 0xffff Device; The number of 16-bit 6
network addresses contained
in this field is specified in the
7
NumAssocDev field. 8
9
If the RequestType in the
request is Extended Response
10
and there are no associated 11
devices on the Remote 12
Device, this field shall not be 13
included in the frame. 14
If an error occurs or the 15
RequestType in the request is 16
for a Single Device 17
Response, this field shall not
be included in the frame.
18
19
20
2.4.4.1.1.1 When Generated 21
The NWK_addr_rsp is generated by a Remote Device in response to a 22
NWK_addr_req command inquiring as to the NWK address of the Remote Device 23
or the NWK address of an address held in a local discovery cache (see sub- 24
clause 2.4.3.1.1.2 for a detailed description). The destination addressing on this 25
command is unicast. 26
27
2.4.4.1.1.2 Effect on Receipt 28
29
On receipt of the NWK_addr_rsp command, the recipient is either notified of the 30
status of its attempt to discover a NWK address from an IEEE address or notified 31
of an error. If the NWK_addr_rsp command is received with a Status of 32
SUCCESS, the remaining fields of the command contain the appropriate 33
discovery information, according to the RequestType as specified in the original 34
NWK_Addr_req command. Otherwise, the Status field indicates the error and the 35
NumAssocDev, StartIndex, and NWKAddrAssocDevList fields shall not be 36
included. 37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
154 Application Layer Specification

2.4.4.1.2 IEEE_addr_rsp
1
The IEEE_addr_rsp command (ClusterID=0x8001) shall be formatted as 2
illustrated in Figure 2.63. 3
4
Octets: 1 8 2 0/1 0/1 Variable
5
Status IEEEAddr NWKAddr Num StartIndex NWKAddr 6
RemoteDev RemoteDev AssocDev AssocDevList 7
8
Figure 2.63 Format of the IEEE_addr_rs Command Frame
9
Table 2.90 specifies the fields of the IEEE_addr_rs command frame. 10
11
Table 2.90 IEEE_addr_rsp Parameters 12
Name Type Valid Range Description 13
14
Status Integer SUCCESS, The status of the 15
INV_REQUESTTYPE or IEEE_addr_req command. 16
DEVICE_NOT_FOUND
17
IEEEAddrRemoteDev Device An extended 64-bit, IEEE 64-bit address for the 18
Address address Remote Device. 19
NWKAddrRemoteDev Device A 16-bit, NWK address 16-bit address for the 20
Address Remote Device. 21
NumAssocDev Integer 0x00-0xff Count of the number of 22
16-bit short addresses to 23
follow. 24
If the RequestType in the 25
request is Extended 26
Response and there are no 27
associated devices on the 28
Remote Device, this field
29
shall be set to 0.
30
If an error occurs or the 31
RequestType in the
32
request is for a Single
Device Response, this 33
field shall not be included 34
in the frame. 35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 155

Table 2.90 IEEE_addr_rsp Parameters (Continued)


1
Name Type Valid Range Description 2
StartIndex Integer 0x00-0xff Starting index into the list 3
of associated devices for 4
this report. 5
If the RequestType in the 6
request is Extended 7
Response and there are no 8
associated devices on the 9
Remote Device, this field
shall not be included in the
10
frame. 11
12
If an error occurs or the
RequestType in the
13
request is for a Single 14
Device Response, this 15
field shall not be included 16
in the frame. 17
NWKAddrAssocDevList Device List of NumAssocDev A list of 16-bit addresses, 18
Address 16-bit short addresses, one corresponding to each 19
List each with range associated device to 20
0x0000 - 0xffff Remote Device; The
21
number of 16-bit network
addresses contained in this 22
field is specified in the 23
NumAssocDev field. 24
If the RequestType in the 25
request is Extended 26
Response and there are no 27
associated devices on the 28
Remote Device, this field
29
shall not be included in the
frame. 30
31
If an error occurs or the
32
RequestType in the
request is for a Single 33
Device Response, this 34
field shall not be included 35
in the frame 36
37
2.4.4.1.2.1 When Generated 38
39
The IEEE_addr_rsp is generated by a Remote Device in response to an 40
IEEE_addr_req command inquiring as to the 64-bit IEEE address of the Remote 41
Device or the 64-bit IEEE address of an address held in a local discovery cache 42
(see sub-clause 2.4.3.1.2.2 for a detailed description). The destination addressing 43
on this command shall be unicast. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
156 Application Layer Specification

2.4.4.1.2.2 Effect on Receipt


1
On receipt of the IEEE_addr_rsp command, the recipient is either notified of the 2
status of its attempt to discover an IEEE address from an NWK address or notified 3
of an error. If the IEEE_addr_rsp command is received with a Status of 4
SUCCESS, the remaining fields of the command contain the appropriate 5
discovery information, according to the RequestType as specified in the original 6
IEEE_Addr_req command. Otherwise, the Status field indicates the error and the 7
NumAssocDev, StartIndex, and NWKAddrAssocDevList fields shall not be 8
included. 9
2.4.4.1.3 Node_Desc_rsp 10
11
The Node_Desc_rsp command (ClusterID=0x8002) shall be formatted as 12
illustrated in Figure 2.64. 13
14
See sub- 15
Octets: 1 2 clause 2.3.2.3
16
Status NWKAddr Node 17
OfInterest Descriptor 18
19
Figure 2.64 Format of the Node_Desc_rsp Command Frame
20
Table 2.91 specifies the fields of the Node_Desc_rsp command frame. 21
22
Table 2.91 Fields of the Node_Desc_rsp Command 23
Name Type Valid Range Description 24
25
Status Integer SUCCESS, The status of the 26
DEVICE_NOT_FOUND Node_Desc_req command.
27
,INV_REQUESTTYPE
or NO_DESCRIPTOR 28
29
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request.
30
Address
31
NodeDescriptor Node See the Node Descriptor 32
Descriptor format in sub-clause 2.3.2.3. 33
This field shall only be
included in the frame if the 34
status field is equal to 35
SUCCESS. 36
37
2.4.4.1.3.1 When Generated 38
39
The Node_Desc_rsp is generated by a remote device in response to a 40
Node_Desc_req directed to the remote device. This command shall be unicast to 41
the originator of the Node_Desc_req command. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 157

The remote device shall generate the Node_Desc_rsp command using the format
illustrated in Table 2.91. The NWKAddrOfInterest field shall match that specified 1
in the original Node_Desc_req command. If the NWKAddrOfInterest field 2
matches the network address of the remote device, it shall set the Status field to 3
SUCCESS and include its node descriptor (see sub-clause 2.3.2.3) in the 4
NodeDescriptor field. 5
6
If the NWKAddrOfInterest field does not match the network address of the 7
remote device and it is an end device, it shall set the Status field to 8
INV_REQUESTTYPE and not include the NodeDescriptor field. If the 9
NWKAddrOfInterest field does not match the network address of the remote 10
device and it is the coordinator or a router, it shall determine whether the 11
NWKAddrOfInterest field matches the network address of one of its children. If 12
the NWKAddrOfInterest field does not match the network address of one of the 13
children of the remote device, it shall set the Status field to 14
DEVICE_NOT_FOUND and not include the NodeDescriptor field. If the 15
NWKAddrOfInterest matches the network address of one of the children of the 16
remote device, it shall determine whether a node descriptor for that device is 17
available. If a node descriptor is not available for the child indicated by the 18
NWKAddrOfInterest field, the remote device shall set the Status field to 19
NO_DESCRIPTOR and not include the NodeDescriptor field. If a node descriptor 20
is available for the child indicated by the NWKAddrOfInterest field, the remote 21
device shall set the Status field to SUCCESS and include the node descriptor (see 22
sub-clause 2.3.2.3) of the matching child device in the NodeDescriptor field. 23
24
2.4.4.1.3.2 Effect on Receipt 25
On receipt of the Node_Desc_rsp command, the recipient is either notified of the 26
node descriptor of the remote device indicated in the original Node_Desc_req 27
command or notified of an error. If the Node_Desc_rsp command is received with 28
a Status of SUCCESS, the NodeDescriptor field shall contain the requested node 29
descriptor. Otherwise, the Status field indicates the error and the NodeDescriptor 30
field shall not be included. 31
32
2.4.4.1.4 Power_Desc_rsp 33
34
The Power_Desc_rsp command (ClusterID=0x8003) shall be formatted as
35
illustrated in Figure 2.65.
36
Octet: 1 2 Variable 37
38
Status NWKAddr Power 39
OfInterest Descriptor
40
Figure 2.65 Format of the Power_Desc_rsp Command Frame 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
158 Application Layer Specification

Table 2.92 specifies the fields of the Power_Desc_rsp command frame.


1
Table 2.92 Fields of the Power_Desc_rsp Command
2
Name Type Valid Range Description 3
4
Status Integer SUCCESS, The status of the 5
Power_Desc_req command.
DEVICE_NOT_FOUND, 6
INV_REQUESTTYPE or 7
NO_DESCRIPTOR 8
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request. 9
Address 10
PowerDescriptor Power See the Node Power 11
Descriptor Descriptor format in sub- 12
clause 2.3.2.4. This field shall 13
only be included in the frame 14
if the status field is equal to
SUCCESS. 15
16
17
2.4.4.1.4.1 When Generated 18
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
illustrated in Table 2.92. The NWKAddrOfInterest field shall match that specified 24
in the original Power_Desc_req command. If the NWKAddrOfInterest field 25
matches the network address of the remote device, it shall set the Status field to 26
SUCCESS and include its power descriptor (see sub-clause 2.3.2.4) in the 27
PowerDescriptor field. 28
If the NWKAddrOfInterest field does not match the network address of the 29
remote device and it is an end device, it shall set the Status field to 30
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 of 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
NWKAddrOfInterest field, the remote device shall set the Status field to 41
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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 159

the remote device shall set the Status field to SUCCESS and include the power
descriptor (see sub-clause 2.3.2.4) of the matching child device in the 1
PowerDescriptor field. 2
3
2.4.4.1.4.2 Effect on Receipt 4
5
On receipt of the Power_Desc_rsp command, the recipient is either notified of the 6
power descriptor of the remote device indicated in the original Power_Desc_req 7
command or notified of an error. If the Power_Desc_rsp command is received 8
with a Status of SUCCESS, the PowerDescriptor field shall contain the requested 9
power descriptor. Otherwise, the Status field indicates the error and the 10
PowerDescriptor field shall not be included. 11
2.4.4.1.5 Simple_Desc_rsp 12
13
The Simple_Desc_rsp command (ClusterID=0x8004) shall be formatted as 14
illustrated in Figure 2.66. 15
16
Octet: 1 2 1 Variable 17
Status NWKAddr Length Simple 18
OfInterest Descriptor 19
20
Figure 2.66 Format of the Simple_Desc_rsp Command Frame 21
22
Table 2.93 specifies the fields of the Simple_Desc_rsp command frame. 23
Table 2.93 Fields of the Simple_Desc_rsp Command 24
25
Name Type Valid Range Description
26
Status Integer SUCCESS, The status of the 27
INVALID_EP, Simple_Desc_req command. 28
NOT_ACTIVE, 29
DEVICE_NOT_FOUND,
INV_REQUESTTYPE or 30
NO_DESCRIPTOR 31
32
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request.
Address 33
34
Length Integer 0x00-0xff Length in bytes of the Simple 35
Descriptor to follow.
36
SimpleDescriptor Simple See the Simple Descriptor 37
Descriptor format in sub-clause 2.3.2.5. 38
This field shall only be
39
included in the frame if the
status field is equal to 40
SUCCESS. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
160 Application Layer Specification

2.4.4.1.5.1 When Generated


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
illustrated in Table 2.93. The NWKAddrOfInterest field shall match that specified 6
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.48, 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.5) 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
If the NWKAddrOfInterest field does not match the network address of the 22
remote device and it is an end device, it shall set the Status field to 23
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 of 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
NWKAddrOfInterest field, the remote device shall set the Status field to 40
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.5) for that 42
endpoint of the matching child device in the SimpleDescriptor field. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 161

2.4.4.1.5.2 Effect on Receipt


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
illustrated in Figure 2.67. 11
12
Octet: 1 2 1 Variable 13
Status NWKAddr ActiveEP ActiveEP 14
OfInterest Count List 15
16
Figure 2.67 Format of the Active_EP_rsp Command Frame
17
18
Table 2.94 specifies the fields of the Active_EP_rsp command frame.
19
Table 2.94 Fields of the Active_EP_rsp Command 20
21
Name Type Valid Range Description
22
Status Integer SUCCESS, The status of the Active_EP_req 23
DEVICE_NOT_FOUND command. 24
, INV_REQUESTTYPE
25
or NO_DESCRIPTOR
26
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request. 27
Address
28
ActiveEPCount Integer 0x00-0xff The count of active endpoints on 29
the Remote Device. 30
ActiveEPList List of bytes each of which 31
represents an 8-bit endpoint. 32
33
2.4.4.1.6.1 When Generated 34
35
The Active_EP_rsp is generated by a remote device in response to an 36
Active_EP_req directed to the remote device. This command shall be unicast to 37
the originator of the Active_EP_req command. 38
39
The remote device shall generate the Active_EP_rsp command using the format
40
illustrated in Table 2.94. The NWKAddrOfInterest field shall match that specified
41
in the original Active_EP_req command. If the NWKAddrOfInterest field
42
matches the network address of the remote device, it shall set the Status field to
43
SUCCESS, set the ActiveEPCount field to the number of active endpoints on that
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
162 Application Layer Specification

device and include an ascending list of all the identifiers of the active endpoints on
that device in the ActiveEPList field. 1
2
If the NWKAddrOfInterest field does not match the network address of the 3
remote device and it is an end device, it shall set the Status field to 4
INV_REQUESTTYPE, set the ActiveEPCount field to 0, and not include the 5
ActiveEPList field. If the NWKAddrOfInterest field does not match the network 6
address of the remote device and it is the coordinator or a router, it shall determine 7
whether the NWKAddrOfInterest field matches the network address of a device it 8
holds in a discovery cache. If the NWKAddrOfInterest field does not match the 9
network address of a device it holds in a discovery cache, it shall set the Status 10
field to DEVICE_NOT_FOUND, set the ActiveEPCount field to 0, and not 11
include the ActiveEPList field. If the NWKAddrOfInterest matches the network 12
address of a device held in a discovery cache on the remote device, it shall 13
determine whether that device has any active endpoints. If the discovery 14
information corresponding to the ActiveEP request has not yet been uploaded to 15
the discovery cache, the remote device shall set the Status field to 16
NO_DESCRIPTOR, set the ActiveEPCount field to 0 and not include the 17
ActiveEPList field. If the cached device has no active endpoints, the remote 18
device shall set the Status field to SUCCESS, set the ActiveEPCount field to 0, 19
and not include the ActiveEPList field. If the cached device has active endpoints, 20
the remote device shall set the Status field to SUCCESS, set the ActiveEPCount 21
field to the number of active endpoints on that device, and include an ascending 22
list of all the identifiers of the active endpoints on that device in the ActiveEPList 23
field. 24
25
2.4.4.1.6.2 Effect on Receipt 26
On receipt of the Active_EP_rsp command, the recipient is either notified of the 27
active endpoints of the remote device indicated in the original Active_EP_req 28
command or notified of an error. If the Active_EP_rsp command is received with 29
a Status of SUCCESS, the ActiveEPCount field indicates the number of entries in 30
the ActiveEPList field. Otherwise, the Status field indicates the error and the 31
ActiveEPList field shall not be included. 32
33
2.4.4.1.7 Match_Desc_rsp 34
35
The Match_Desc_rsp command (ClusterID=0x8006) shall be formatted as
36
illustrated in Figure 2.68.
37
Octet: 1 2 1 Variable 38
39
Status NWKAddr Match Match 40
OfInterest Length List
41
Figure 2.68 Format of the Match_Desc_rsp Command Frame 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 163

Table 2.95 specifies the fields of the Match_Desc_rsp command frame.


1
Table 2.95 Fields of the Match_Desc_rsp Command
2
Name Type Valid Range Description 3
4
Status Integer SUCCESS, The status of the 5
Match_Desc_req command.
DEVICE_NOT_FOUND, 6
INV_REQUESTTYPE or 7
NO_DESCRIPTOR 8
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request. 9
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
2.4.4.1.7.1 When Generated 17
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.95. If the NWKAddrOfInterest field of the original
24
Match_Desc_req was equal to the broadcast network address for all devices for
25
which macRxOnWhenIdle = TRUE (0xfffd), the remote device shall apply the
26
match criterion, as described below, that was specified in the original
27
Match_Desc_req command to each of its simple descriptors. If the remote device
28
is the coordinator or a router, it shall also apply the match criterion, as described
29
below, to each simple descriptor that it may have obtained from each of its
30
children.
31
If the NWKAddrOfInterest field of the original Match_Desc_req was not equal to 32
the broadcast network address for all devices for which macRxOnWhenIdle = 33
TRUE (0xfffd), the remote device shall set the NWKAddrOfInterest field to the 34
same network address that was specified in the original Match_Desc_req 35
command. 36
37
If the NWKAddrOfInterest field matches the network address of the remote
38
device, it shall apply the match criterion, as described below, that was specified in
39
the original Match_Desc_req command to each of its simple descriptors.
40
If the NWKAddrOfInterest field does not match the network address of the 41
remote device and it is an end device, it shall set the Status field to 42
INV_REQUESTTYPE, set the MatchLength field to 0, and not include the 43
MatchList field. If the NWKAddrOfInterest field does not match the network 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
164 Application Layer Specification

address of the remote device and it is the coordinator or a router, it shall determine
whether the NWKAddrOfInterest field matches the network address of one of its 1
children. If the NWKAddrOfInterest field does not match the network address of 2
one of the children of the remote device, it shall set the Status field to 3
DEVICE_NOT_FOUND, set the MatchLength field to 0, and not include the 4
MatchList field. 5
6
If the NWKAddrOfInterest matches the network address of one of the children of 7
the remote device, it shall determine whether any simple descriptors for that 8
device are available. If no simple descriptors are available for the child indicated 9
by the NWKAddrOfInterest field, the remote device shall set the Status field to 10
NO_DESCRIPTOR, set the MatchLength field to 0, and not include the 11
MatchList field. If any simple descriptors are available for the child indicated by 12
the NWKAddrOfInterest field, the remote device shall apply the match criterion, 13
as described below, that was specified in the original Match_Desc_req command 14
to each of these simple descriptors. 15
The remote device shall apply the match criteria to each simple descriptor (see 16
sub-clause 2.3.2.5) as follows. The remote device shall first check that the 17
ProfileID field matches the application profile identifier field of the simple 18
descriptor. If the profile identifiers do not match, the remote device shall assume 19
the match to be unsuccessful and perform no further matching. 20
21
If the profile identifiers match, the remote device shall determine whether the 22
match criteria contains a list of input clusters (the NumInClusters field is not equal 23
to 0). If the match criteria contains a list of input clusters, the remote device shall 24
check that at least one of the cluster identifiers listed in the InClusterList field 25
matches one of the cluster identifiers in the application input cluster list field of 26
the simple descriptor. If at least one matching input cluster is found, the remote 27
device shall assume the match to be successful, note the identifier of the endpoint 28
to which this simple descriptor refers and perform no further matching. 29
If the remote device is unable to find any matching input clusters, it shall 30
determine whether the match criterion contains a list of output clusters (the 31
NumOutClusters field is not equal to 0). If the match criterion contains a list of 32
output clusters, the remote device shall check that at least one of the cluster 33
identifiers listed in the OutClusterList field matches one of the cluster identifiers 34
in the application output cluster list field of the simple descriptor. If at least one 35
matching output cluster is found, the remote device shall assume the match to be 36
successful and note the identifier of the endpoint to which this simple descriptor 37
refers. If the remote device is unable to find any output matching clusters, it shall 38
assume the match to be unsuccessful. 39
40
If the above procedure produces one or more matches, the remote device shall 41
construct a separate Match_Desc_rsp command for each matching device 42
(including itself). For each response, the Status field shall be set to SUCCESS, the 43
NWKAddrOfInterest field shall be set to the address of the appropriate matching 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 165

device, the MatchLength field shall be set to the number of simple descriptors that
matched the criteria for the appropriate matching device, and the MatchList field 1
shall contain an ascending list of the endpoints on which a simple descriptor 2
matched the criteria for the appropriate matching device. 3
4
2.4.4.1.7.2 Effect on Receipt 5
6
On receipt of the Match_Desc_rsp command, the recipient is either notified of the 7
results of its match criterion query indicated in the original Match_Desc_req 8
command or notified of an error. If the Match_Desc_rsp command is received 9
with a Status of SUCCESS, the MatchList field shall contain the list of endpoints 10
containing simple descriptors that matched the criterion. Otherwise, the Status 11
field indicates the error and the MatchList field shall not be included. 12
2.4.4.1.8 Complex_Desc_rsp 13
14
The Complex_Desc_rsp command (ClusterID=0x8010) shall be formatted as 15
illustrated in Figure 2.69. 16
17
Octet: 1 2 1 Variable 18
Status NWKAddr Length Complex 19
OfInterest Descriptor 20
21
Figure 2.69 Format of the Complex_Desc_rsp Command Frame 22
23
Table 2.96 specifies the fields of the Complex_Desc_rsp command frame. 24
Table 2.96 Fields of the Complex_Desc_rsp Command 25
26
Name Type Valid Range Description
27
Status Integer SUCCESS, The status of the 28
DEVICE_NOT_FOUND, Complex_Desc_req command. 29
INV_REQUESTTYPE or 30
NO_DESCRIPTOR
31
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request. 32
Address 33
Length Integer 0x00-0xff Length in bytes of the 34
ComplexDescriptor field. 35
ComplexDescriptor Complex See the Complex Descriptor 36
Descript format in sub-clause 2.3.2.6. 37
or This field shall only be 38
included in the frame if the 39
status field is equal to
40
SUCCESS.
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
166 Application Layer Specification

2.4.4.1.8.1 When Generated


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.96. 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.6) in the 14
ComplexDescriptor field. 15
16
If the NWKAddrOfInterest field does not match the network address of the 17
remote device and it is an end device, it shall set the Status field to 18
INV_REQUESTTYPE, set the Length field to 0, and not include the 19
ComplexDescriptor field. If the NWKAddrOfInterest field does not match the 20
network address of the remote device and it is the coordinator or a router, it shall 21
determine whether the NWKAddrOfInterest field matches the network address of 22
one of its children. If the NWKAddrOfInterest field does not match the network 23
address of one of the children of the remote device, it shall set the Status field to 24
DEVICE_NOT_FOUND, set the Length field to 0, and not include the 25
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.6) of the matching child device in the ComplexDescriptor field. 35
36
2.4.4.1.8.2 Effect on Receipt 37
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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 167

2.4.4.1.9 User_Desc_rsp
1
The User_Desc_rsp command (ClusterID=0x8011) shall be formatted as 2
illustrated in Figure 2.70. 3
4
Octet: 1 2 1 Variable
5
Status NWKAddr Length User 6
OfInterest Descriptor 7
8
Figure 2.70 Format of the User_Desc_rsp Command Frame
9
Table 2.97 specifies the fields of the User_Desc_rsp command frame. 10
11
Table 2.97 Fields of the User_Desc_rsp Command 12
Name Type Valid Range Description 13
14
Status Integer SUCCESS, The status of the 15
NOT_SUPPORTED, User_Desc_req 16
DEVICE_NOT_FOUND, command.
INV_REQUESTTYPE or 17
NO_DESCRIPTOR 18
19
NWKAddrOfInterest Device 16-bit NWK address NWK address for the
Address request. 20
21
Length Integer 0x00-0x10 Length in bytes of the 22
UserDescriptor field.
23
UserDescriptor User See the User Descriptor 24
Descriptor format in sub- 25
clause 2.3.2.7. This
26
field shall only be
included in the frame if 27
the status field is equal 28
to SUCCESS. 29
30
2.4.4.1.9.1 When Generated 31
32
The User_Desc_rsp is generated by a remote device in response to a 33
User_Desc_req directed to the remote device. This command shall be unicast to 34
the originator of the User_Desc_req command. 35
The remote device shall generate the User_Desc_rsp command using the format 36
illustrated in Table 2.97. The NWKAddrOfInterest field shall match that specified 37
in the original User_Desc_req command. If the NWKAddrOfInterest field 38
matches the network address of the remote device but a user descriptor does not 39
exist, it shall set the Status field to NO_DESCRIPTOR, set the Length field to 0, 40
and not include the UserDescriptor field. If the NWKAddrOfInterest field 41
matches the network address of the remote device and a user descriptor exists, it 42
shall set the Status field to SUCCESS, set the Length field to the length of the user 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
168 Application Layer Specification

descriptor, and include its user descriptor (see sub-clause 2.3.2.7) in the
UserDescriptor field. 1
2
If the NWKAddrOfInterest field does not match the network address of the 3
remote device and it is an end device, it shall set the Status field to 4
INV_REQUESTTYPE, set the Length field to 0, and not include the 5
UserDescriptor field. If the NWKAddrOfInterest field does not match the network 6
address of the remote device and it is the coordinator or a router, it shall determine 7
whether the NWKAddrOfInterest field matches the network address of one of its 8
children. If the NWKAddrOfInterest field does not match the network address of 9
one of the children of the remote device, it shall set the Status field to 10
DEVICE_NOT_FOUND, set the Length field to 0, and not include the 11
UserDescriptor field. If the NWKAddrOfInterest matches the network address of 12
one of the children of the remote device, it shall determine whether a user 13
descriptor for that device is available. If a user descriptor is not available for the 14
child indicated by the NWKAddrOfInterest field, the remote device shall set the 15
Status field to NO_DESCRIPTOR, set the Length field to 0, and not include the 16
UserDescriptor field. If a user descriptor is available for the child indicated by the 17
NWKAddrOfInterest field, the remote device shall set the Status field to 18
SUCCESS, set the Length field to the length of the user descriptor for that device, 19
and include the user descriptor (see sub-clause 2.3.2.7) of the matching child 20
device in the UserDescriptor field. 21
22
2.4.4.1.9.2 Effect on Receipt 23
On receipt of the User_Desc_rsp command, the recipient is either notified of the 24
user descriptor of the remote device indicated in the original User_Desc_req 25
command or notified of an error. If the User_Desc_rsp command is received with 26
a Status of SUCCESS, the UserDescriptor field shall contain the requested user 27
descriptor. Otherwise, the Status field indicates the error and the UserDescriptor 28
field shall not be included. 29
30
2.4.4.1.10 System_Server_Discovery_rsp 31
32
The System_Server_Discovery_rsp command (ClusterID=0x8015) shall be
33
formatted as illustrated in Figure 2.74.
34
Octet: 1 2 35
36
Status ServerMask 37
Figure 2.71 System_Server_Discovery_rsp Command Frame 38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 169

Table 2.98 specifies the fields of the System_Server_Discovery_rsp command


frame. 1
2
Table 2.98 Fields of the System_Server_Discovery_rsp Command
3
Name Type Valid Range Description 4
5
Status Integer SUCCESS The status of the 6
System_Server_Discovery_rsp
command. 7
8
ServerMask Integer Bitmap See Table 2.31 for bit assignments. 9
10
2.4.4.1.10.1 When Generated 11
12
The System_Server_Discovery_rsp is generated from Remote Devices on receipt 13
of a System_Server_Discovery_req primitive if the parameter matches the Server 14
Mask field in its node descriptor. If there is no match, the 15
System_Server_Discovery_req shall be ignored and no response given. Matching 16
is performed by masking the ServerMask parameter of the 17
System_Server_Discovery_req with the Server Mask field in the node descriptor. 18
This command shall be unicast to the device which sent 19
System_Server_Discovery_req with Acknowledge request set in TxOptions. The 20
parameter ServerMask contains the bits in the parameter of the request which 21
match the server mask in the node descriptor. 22
23
2.4.4.1.10.2 Effect on Receipt 24
The requesting device is notified that this device has some of the system server 25
functionality that the requesting device is seeking. 26
27
If the Network Manager bit was set in the System_Server_Discovery_rsp, then the 28
Remote Device’s NWK address shall be set into the nwkManagerAddr of the NIB. 29
2.4.4.1.11 User_Desc_conf 30
31
The User_Desc_conf command (ClusterID=0x8014) shall be formatted as 32
illustrated in Figure 2.72. 33
34
Octets: 1 2 35
Status NWKAddr 36
OfInterest 37
38
Figure 2.72 Format of the User_Desc_conf Command Frame
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
170 Application Layer Specification

Table 2.99 specifies the fields of the User_Desc_conf command frame.


1
Table 2.99 Fields of the User_Desc_conf Command
2
Name Type Valid Range Description 3
4
Status Integer SUCCESS, The status of the 5
NOT_SUPPORTED, User_Desc_set command.
DEVICE_NOT_FOUND, 6
INV_REQUESTTYPE or 7
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
2.4.4.1.11.1 When Generated 14
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
illustrated in Table 2.99. The NWKAddrOfInterest field shall match that specified 20
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
If the NWKAddrOfInterest field does not match the network address of the 29
remote device and it is an end device, it shall set the Status field to 30
INV_REQUESTTYPE. If the NWKAddrOfInterest field does not match the 31
network address of the remote device and it is the coordinator or a router, it shall 32
determine whether the NWKAddrOfInterest field matches the network address of 33
one of its children. If the NWKAddrOfInterest field does not match the network 34
address of one of the children of the remote device, it shall set the Status field to 35
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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 171

2.4.4.1.11.2 Effect on Receipt


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
illustrated in Figure 2.73. 7
8
Octets: 1 9
Status 10
11
Figure 2.73 Format of the Discovery_Cache_rsp Command Frame 12
13
Table 2.100. specifies the fields of the Discovery_Cache_rsp Command Frame. 14
Table 2.100 Fields of the Discovery_Cache_rsp Command 15
16
Name Type Valid Range Description 17
Status Integer SUCCESS The status of the 18
Discovery_Cache_req command. 19
20
2.4.4.1.12.1 When Generated 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
2.4.4.1.12.2 Effect on Receipt 28
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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
172 Application Layer Specification

2.4.4.1.13 Discovery_store_rsp
1
The Discovery_store_rsp command (ClusterID=0x8016) shall be formatted as 2
illustrated in Figure 2.74. 3
4
Octets: 1
5
Status 6
7
Figure 2.74 Format of the Discovery_store_rsp Command Frame 8
9
Table 2.101 specifies the fields of the Discovery_store_rsp command frame 10
Table 2.101 Fields of the Discovery_store_rsp Command 11
12
Name Type Valid Range Description
13
Status Integer SUCCESS, The status of the 14
INSUFFICIENT_SPACE Discovery_store_req 15
or NOT_SUPPORTED command. 16
17
2.4.4.1.13.1 When Generated 18
19
The Discovery_store_rsp is provided to notify a Local Device of the request status 20
from a Primary Discovery Cache device. Included in the response is a status code 21
to notify the Local Device whether the request is successful (the Primary Cache 22
Device has space to store the discovery cache data for the Local Device), whether 23
the request is unsupported (meaning the Remote Device is not a Primary 24
Discovery Cache device), or insufficient space exists. 25
26
2.4.4.1.13.2 Effect on Receipt 27
Upon receipt, the Local Device shall determine whether the response status 28
indicates that the Remote Device is not a Primary Cache Device as indicated by a 29
NOT_SUPPORTED status. If a NOT_SUPPORTED status is returned, the Local 30
Device should process any other Discovery_store_rsp devices from other Remote 31
Devices or re-perform the Discovery_Cache_req to determine the address of 32
another Primary Discovery Cache device (eliminating the address of the Remote 33
Device that responded with NOT_SUPPORTED if it responds again to the 34
Discovery_Cache_req). If an INSUFFICIENT_SPACE status is returned, the 35
Local Device should also process any other Discovery_store_rsp and re-perform 36
the Discovery_Cache_req if none of the responses indicate SUCCESS (with the 37
radius field increased to include more Remote Devices). If a SUCCESS status is 38
returned, the Local Device shall upload its discovery cache information to the 39
Remote Device via the Node_Desc_store_req, Power_Desc_store_req, 40
Active_EP_store_req, and Simple_Desc_store_req. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 173

2.4.4.1.14 Node_Desc_store_rsp
1
The Node_Desc_store_rsp command (ClusterID=0x8017) shall be formatted as 2
illustrated in Figure 2.75. 3
4
Octets: 1
5
Status 6
7
Figure 2.75 Format of the Node_Desc_store_rsp Command Frame 8
9
Table 2.102 specifies the fields of the Node_Desc_store_rsp command frame. 10
Table 2.102 Fields of the Node_Desc_store_rsp Command 11
12
Name Type Valid Range Description
13
Status Integer SUCCESS, The status of the Node_store_rsp 14
INSUFFICIENT_SPACE, command. 15
NOT_PERMITTED or 16
NOT_SUPPORTED 17
18
2.4.4.1.14.1 When Generated 19
20
The Node_store_rsp is provided to notify a Local Device of the request status 21
from a Primary Discovery Cache device. Included in the response is a status code 22
to notify the Local Device whether the request is successful (the Primary Cache 23
Device has space to store the discovery cache data for the Local Device), whether 24
the request is not supported (meaning the Remote Device is not a Primary 25
Discovery Cache device), or insufficient space exists. 26
27
2.4.4.1.14.2 Effect on Receipt 28
29
Upon receipt, the Local Device shall determine whether the response status 30
indicates that the Remote Device is not a Primary Cache Device as indicated by a 31
NOT_SUPPORTED status. If a NOT_SUPPORTED status is returned, the Local 32
Device should re-perform discovery of the Primary Discovery Cache device. If a 33
NOT_PERMITTED status is returned, the local device must first issue a 34
Discovery_store_req with a returned SUCCESS status. If an 35
INSUFFICIENT_SPACE status is returned, the Local Device shall also send the 36
Remote Device a Remove_node_cache_req. If a SUCCESS status is returned, the 37
Local Device should continue to upload its remaining discovery cache 38
information to the Remote Device via the Power_Desc_store_req, 39
Active_EP_store_req, and Simple_Desc_store_req. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
174 Application Layer Specification

2.4.4.1.15 Power_Desc_store_rsp
1
The Power_Desc_store_rsp command (ClusterID=0x8018) shall be formatted as 2
illustrated in Figure 2.76. 3
4
Octets: 1 8 Variable
5
Status IEEEAddr PowerDescriptor 6
7
Figure 2.76 Format of the Power_Desc_store_rsp Command Frame 8
9
Table 2.103 specifies the fields of the Power_Desc_store_rsp command frame. 10
Table 2.103 Fields of the Power_Desc_store_rsp Command 11
12
Name Type Valid Range Description
13
Status Integer SUCCESS, The status of the Power_store_rsp 14
INSUFFICIENT_SPACE, command. 15
NOT_PERMITTED or 16
NOT_SUPPORTED 17
18
2.4.4.1.15.1 When Generated 19
20
The Power_Desc_store_rsp is provided to notify a Local Device of the request 21
status from a Primary Discovery Cache device. Included in the response is a status 22
code to notify the Local Device whether the request is successful (the Primary 23
Cache Device has space to store the discovery cache data for the Local Device), 24
whether the request is not supported (meaning the Remote Device is not a Primary 25
Discovery Cache device), or insufficient space exists. 26
27
2.4.4.1.15.2 Effect on Receipt 28
29
Upon receipt, the Local Device shall determine whether the response status 30
indicates that the Remote Device is not a Primary Cache Device as indicated by a 31
NOT_SUPPORTED status. If a NOT_SUPPORTED status is returned, the Local 32
Device should re-perform discovery on the Primary Discovery Cache. If a 33
NOT_PERMITTED status is returned, the local device must first issue a 34
Discovery_store_req with a returned SUCCESS status. If an 35
INSUFFICIENT_SPACE status is returned, the Local Device shall discontinue 36
upload of discovery information, issue a Remove_node_cache_req (citing the 37
Local Device), and cease attempts to upload discovery information to the Remote 38
Device. 39
If a SUCCESS status is returned, the Local Device should continue to upload its 40
remaining discovery cache information to the Remote Device via the 41
Active_EP_store_req and Simple_Desc_store_req. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 175

2.4.4.1.16 Active_EP_store_rsp
1
The Active_EP_store_rsp command (ClusterID=0x8019) shall be formatted as 2
illustrated in Figure 2.77. 3
4
Octets: 1
5
Status 6
7
Figure 2.77 Format of the Active_EP_store_rsp Command Frame 8
9
Table 2.104 specifies the fields of the Active_EP_store_rsp command frame. 10
Table 2.104 Fields of the Active_EP_store_rsp Command 11
12
Name Type Valid Range Description
13
Status Integer SUCCESS, The status of the 14
INSUFFICIENT_SPACE Active_EP_store_rsp command. 15
, NOT_PERMITTED or 16
NOT_SUPPORTED
17
18
2.4.4.1.16.1 When Generated 19
20
The Active_EP_store_rsp is provided to notify a Local Device of the request
21
status from a Primary Discovery Cache device. Included in the response is a status
22
code to notify the Local Device whether the request is successful (the Primary
23
Cache Device has space to store the discovery cache data for the Local Device),
24
the request is not supported (meaning the Remote Device is not a Primary
25
Discovery Cache device), or insufficient space exists.
26
27
2.4.4.1.16.2 Effect on Receipt
28
Upon receipt, the Local Device shall determine whether the response status 29
indicates that the Remote Device is not a Primary Cache Device as indicated by a 30
NOT_SUPPORTED status. If a NOT_SUPPORTED status is returned, the Local 31
Device should re-perform discovery on the Primary Discovery Cache. If a 32
NOT_PERMITTED status is returned, the local device must first issue a 33
Discovery_store_req with a returned SUCCESS status. If an 34
INSUFFICIENT_SPACE status is returned, the Local Device shall discontinue 35
upload of discovery information, issue a Remove_node_cache_req (citing the 36
Local Device), and cease attempts to upload discovery information to the Remote 37
Device. If a SUCCESS status is returned, the Local Device should continue to 38
upload its remaining discovery cache information to the Remote Device via the 39
Simple_Desc_store_req. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
176 Application Layer Specification

2.4.4.1.17 Simple_Desc_store_rsp
1
The Simple_Desc_store_rsp command (ClusterID=0x801a) shall be formatted as 2
illustrated in Figure 2.78. 3
4
Octets: 1
5
Status 6
7
Figure 2.78 Format of the Simple_Desc_store_rsp Command Frame 8
9
Table 2.105 specifies the fields of the Simple_Desc_store_rsp command frame. 10
Table 2.105 Fields of the Simple_Desc_store_rsp Command 11
12
Name Type Valid Range Description
13
Status Integer SUCCESS, The status of the 14
INSUFFICIENT_SPACE, Simple_desc_store_rsp 15
NOT_PERMITTED or command. 16
NOT_SUPPORTED
17
18
2.4.4.1.17.1 When Generated 19
20
The Simple_Desc_store_rsp is provided to notify a Local Device of the request
21
status from a Primary Discovery Cache device. Included in the response is a status
22
code to notify the Local Device whether the request is successful (the Primary
23
Cache Device has space to store the discovery cache data for the Local Device),
24
the request is not supported (meaning the Remote Device is not a Primary
25
Discovery Cache device), or insufficient space exists.
26
27
2.4.4.1.17.2 Effect on Receipt
28
Upon receipt, the Local Device shall determine whether the response status 29
indicates that the Remote Device is not a Primary Cache Device as indicated by a 30
NOT_SUPPORTED status. If a NOT_SUPPORTED status is returned, the Local 31
Device should re-perform discovery on the Primary Discovery Cache. If a 32
NOT_PERMITTED status is returned, the local device must first issue a 33
Discovery_store_req with a returned SUCCESS status. If an 34
INSUFFICIENT_SPACE status is returned, the Local Device shall discontinue 35
upload of discovery information, issue a Remove_node_cache_req (citing the 36
Local Device), and cease attempts to upload discovery information to the Remote 37
Device. If a SUCCESS status is returned, the Local Device should continue to 38
upload its remaining discovery cache information to the Remote Device via the 39
Simple_Desc_store_req for other endpoints on the Local Device. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 177

2.4.4.1.18 Remove_node_cache_rsp
1
The Remove_node_cache_rsp command (ClusterID=0x801b) shall be formatted 2
as illustrated in Figure 2.79. 3
4
Octets: 1
5
Status 6
7
Figure 2.79 Format of the Remove_node_cache_rsp Command Frame 8
9
Table 2.106 specifies the fields of the Remove_node_cache_rsp command frame. 10
Table 2.106 Fields of the Remove_node_cache_rsp Command 11
12
Name Type Valid Range Description
13
Status Integer SUCCESS, The status of the 14
DEVICE_NOT_FOUND Remove_node_cache_rsp command 15
or NOT_SUPPORTED 16
17
2.4.4.1.18.1 When Generated 18
19
The Remove_node_cache_rsp is provided to notify a Local Device of the request 20
status from a Primary Discovery Cache device. Included in the response is a status 21
code to notify the Local Device whether the request is successful (the Primary 22
Cache Device has removed the discovery cache data for the indicated device of 23
interest), or the request is not supported (meaning the Remote Device is not a 24
Primary Discovery Cache device). 25
26
2.4.4.1.18.2 Effect on Receipt 27
Upon receipt, the Local Device shall determine whether the response status 28
indicates that the Remote Device is not a Primary Cache Device as indicated by a 29
NOT_SUPPORTED status. If a NOT_SUPPORTED status is returned, the Local 30
Device should re-perform Find_node_cache_req to locate the Primary Discovery 31
Cache device holding the discovery cache information for the indicated device of 32
interest. When the Primary Discovery Cache device holding the discovery 33
information for the device of interest is located, the Local Device should repeat 34
the Remove_node_cache_req to successfully remove the discovery information. If 35
a status of DEVICE_NOT_FOUND is received, this indicates that the Remote 36
Device is the Primary Discovery Cache but does not hold the discovery 37
information for the NWKAddr and the IEEEAddr presented in the request. The 38
Local Device should employ the device discovery commands NWK_Addr_req 39
and IEEE_Addr_req to determine the correct values for NWKAddr and 40
IEEEAddr. If a SUCCESS status is returned, the Local Device has successfully 41
removed the discovery cache information for the indicated device of interest 42
within the request. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
178 Application Layer Specification

2.4.4.1.19 Find_node_cache_rsp
1
The Find_node_cache_rsp command (ClusterID=0x801c) shall be formatted as 2
illustrated in Figure 2.80. 3
4
Octets: 2 2 8
5
CacheNWKAddress NWKAddr IEEEAddr 6
7
Figure 2.80 Format of the Find_node_cache_rsp Command Frame 8
9
Table 2.107 specifies the fields of the Find_node_cache_rsp command frame. 10
Table 2.107 Fields of the Find_node_cache_rsp Command 11
12
Name Type Valid Range Description
13
CacheNWKAddr Device 16-bit NWK Address NWK Address for the Primary 14
Address Discovery Cache device holding 15
the discovery information (or the 16
device of interest if it responded to
the request directly). 17
18
NWKAddr Device 16-bit NWK Address NWK Address for the device of 19
Address interest.
20
IEEEAddr Device 64-bit IEEE Address IEEE address for the device of 21
Address interest. 22
23
2.4.4.1.19.1 When Generated 24
25
The Find_node_cache_rsp is provided to notify a Local Device of the successful 26
discovery of the Primary Discovery Cache device for the given NWKAddr and 27
IEEEAddr fields supplied in the request, or to signify that the device of interest is 28
capable of responding to discovery requests. The Find_node_cache_rsp shall be 29
generated only by Primary Discovery Cache devices holding discovery 30
information for the NWKAddr and IEEEAddr in the request or the device of 31
interest itself and all other Remote Devices shall not supply a response. 32
33
2.4.4.1.19.2 Effect on Receipt 34
Upon receipt, the Local Device shall utilize the CacheNWKAddr as the Remote 35
Device address for subsequent discovery requests relative to the NWKAddr and 36
IEEEAddr in the response. 37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 179

2.4.4.1.20 Extended_Simple_Desc_rsp
1
The Extended_Simple_Desc_rsp command (ClusterID=0x801d) shall be 2
formatted as illustrated in Figure 2.81. 3
4
Octet:1 2 1 1 1 1 Variable
5
Status NWKAddr Endpoint AppInput AppOutput StartIndex AppCluster 6
OfInterest ClusterCount ClusterCount List 7
8
Figure 2.81 Format of the Extended_Simple_Desc_rsp Command Frame
9
Table 2.108 specifies the fields of the Extended_Simple_Desc_rsp command 10
frame. 11
12
Table 2.108 Fields of the Extended_Simple_Desc_rsp Command 13
Name Type Valid Range Description 14
15
Status Integer SUCCESS, The status of the 16
INVALID_EP, Extended_Simple_Desc_req 17
NOT_ACTIVE, command.
DEVICE_NOT_FOUND, 18
INV_REQUESTTYPE or 19
NO_DESCRIPTOR 20
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request. 21
Address 22
23
Endpoint 8 bits 1-240 The endpoint on the
destination.
24
25
AppInputClusterCou 8 bits 0x00-0xff The total count of application 26
nt input clusters in the Simple
27
Descriptor for this endpoint.
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
180 Application Layer Specification

Table 2.108 Fields of the Extended_Simple_Desc_rsp Command (Continued)


1
AppOutputClusterC 8 bits 0x00-0xff The total count of application
ount output clusters in the Simple
2
Descriptor for this endpoint. 3
4
StartIndex 8 bits 0x00-0xff Starting index within the
5
AppClusterList of the response
represented by an ordered list 6
of the Application Input 7
Cluster List and Application 8
Output Cluster List from the 9
Simple Descriptor for this
10
endpoint.
11
AppClusterList A concatenated, ordered list of 12
the AppInputClusterList and
13
AppOutputClusterList,
beginning with StartIndex, 14
from the Simple Descriptor. 15
This field shall only be 16
included in the frame if the 17
status field is equal to
18
SUCCESS.
19
20
2.4.4.1.20.1 When Generated 21
The Extended_Simple_Desc_rsp is generated by a remote device in response to an 22
Extended_Simple_Desc_req directed to the remote device. This command shall 23
be unicast to the originator of the Extended_Simple_Desc_req command. 24
25
The remote device shall generate the Extended_Simple_Desc_rsp command using 26
the format illustrated in Table 2.108. The NWKAddrOfInterest field shall match 27
that specified in the original Extended_Simple_Desc_req command. If the 28
endpoint field specified in the original Extended_Simple_Desc_req command 29
does not fall within the correct range specified in Table 2.48, the remote device 30
shall set the Status field to INVALID_EP, set the Endpoint and StartIndex fields to 31
their respective values supplied in the request, and not include the AppClusterList 32
field. 33
If the NWKAddrOfInterest field matches the network address of the remote 34
device, it shall determine whether the endpoint field specifies the identifier of an 35
active endpoint on the device. If the endpoint field corresponds to an active 36
endpoint, the remote device shall set the Status field to SUCCESS, set the 37
AppClusterList field to the sequence of octets from the concatenated AppInput 38
ClusterList and AppOutputClusterList from the Simple Descriptor (Tables 2.38), 39
and supply that field as AppClusterList in the response. Note that dependent on 40
the value of StartIndex in the request, the results in AppClusterList may be empty 41
(for example, the StartIndex begins after the sequence of octets given by the 42
concatenation of AppInputClusterList and AppOutputClusterList). If the endpoint 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 181

field does not correspond to an active endpoint, the remote device shall set the
Status field to NOT_ACTIVE, set the StartIndex field to the value supplied in the 1
request, and not include the AppClusterList field. 2
3
2.4.4.1.20.2 Effect on Receipt 4
5
On receipt of the Extended_Simple_Desc_rsp command, the recipient is either 6
notified of the requested AppClusterList on the endpoint of the remote device 7
indicated in the original Extended_Simple_Desc_req command or notified of an 8
error. If the Extended_Simple_Desc_rsp command is received with a Status of 9
SUCCESS, the AppClusterList field shall contain the requested portion of the 10
application input cluster list and application output cluster list, starting with the 11
StartIndex. Otherwise, the Status field indicates the error and the AppClusterList 12
field shall not be included. 13
2.4.4.1.21 Extended_Active_EP_rsp 14
15
The Extended_Active_EP_rsp command (ClusterID=0x801e) shall be formatted 16
as illustrated in Figure 2.82. 17
18
Octet: 1 2 1 1 Variable 19
Status NWKAddr ActiveEP StartIndex ActiveEP 20
OfInterest Count List 21
22
Figure 2.82 Format of the Extended_Active_EP_rsp Command Frame 23
24
Table 2.109 specifies the fields of the Extended_Active_EP_rsp command frame. 25
Table 2.109 Fields of the Extended_Active_EP_rsp Command 26
27
Name Type Valid Range Description
28
Status Integer SUCCESS, The status of the 29
DEVICE_NOT_FOUND Extended_Active_EP_req 30
, INV_REQUESTTYPE command. 31
or NO_DESCRIPTOR
32
NWKAddrOfInterest Device 16-bit NWK address NWK address for the request. 33
Address 34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
182 Application Layer Specification

Table 2.109 Fields of the Extended_Active_EP_rsp Command


1
ActiveEPCount Integer 0x00-0xff The count of active endpoints on
the Remote Device.
2
3
StartIndex Integer 0x00-0xff Starting index for the list of 4
active endpoints for this report.
5
ActiveEPList List of bytes each of which 6
represents an 8-bit endpoint. The 7
list begins with the entry starting
8
with StartIndex and continues
until the remaining active 9
endpoints are listed or the ASDU 10
size is exhausted with whole 11
endpoint entries. 12
13
2.4.4.1.21.1 When Generated 14
15
The Extended_Active_EP_rsp is generated by a remote device in response to an 16
Extended_Active_EP_req directed to the remote device. This command shall be 17
unicast to the originator of the Extended_Active_EP_req command. 18
The remote device shall generate the Extended_Active_EP_rsp command using 19
the format illustrated in Table 2.109. The NWKAddrOfInterest field shall match 20
that specified in the original Extended_Active_EP_req command. If the 21
NWKAddrOfInterest field matches the network address of the remote device, it 22
shall set the Status field to SUCCESS, set the ActiveEPCount field to the number 23
of active endpoints on that device, and include an ascending list of all the 24
identifiers of the active endpoints, beginning with StartIndex, on that device in the 25
ActiveEPList field and continuing until the remaining list of active endpoints 26
from StartIndex forward is listed or until the ASDU size is exhausted with whole 27
endpoint entries. 28
29
If the NWKAddrOfInterest field does not match the network address of the 30
remote device and it is an end device, it shall set the Status field to 31
INV_REQUESTTYPE, set the ActiveEPCount field to 0, and not include the 32
ActiveEPList field. If the NWKAddrOfInterest field does not match the network 33
address of the remote device and it is the coordinator or a router, it shall determine 34
whether the NWKAddrOfInterest field matches the network address of a device it 35
holds in a discovery cache. If the NWKAddrOfInterest field does not match the 36
network address of a device it holds in a discovery cache, it shall set the Status 37
field to DEVICE_NOT_FOUND, set the ActiveEPCount field to 0, and not 38
include the ActiveEPList field. If the NWKAddrOfInterest matches the network 39
address of a device held in a discovery cache on the remote device, it shall 40
determine whether that device has any active endpoints. If the discovery 41
information corresponding to the ActiveEP request has not yet been uploaded to 42
the discovery cache, the remote device shall set the Status field to 43
NO_DESCRIPTOR, set the ActiveEPCount field to 0, and not include the 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 183

ActiveEPList field. If the cached device has no active endpoints, the remote
device shall set the Status field to SUCCESS, set the ActiveEPCount field to 0, 1
and not include the ActiveEPList field. If the cached device has active endpoints, 2
the remote device shall set the Status field to SUCCESS, set the ActiveEPCount 3
field to the number of active endpoints on that device and include an ascending 4
list of all the identifiers of the active endpoints, beginning with StartIndex, on that 5
device in the ActiveEPList field. 6
7
2.4.4.1.21.2 Effect on Receipt 8
9
On receipt of the Extended_Active_EP_rsp command, the recipient is either 10
notified of the active endpoints of the remote device indicated in the original 11
Extended_Active_EP_req command or notified of an error. If the 12
Extended_Active_EP_rsp command is received with a Status of SUCCESS, the 13
ActiveEPCount field indicates the number of entries in the ActiveEPList field. 14
Otherwise, the Status field indicates the error and the ActiveEPList field shall not 15
be included. The requesting device may need to employ 16
Extended_Active_EP_req multiple times, with different StartIndex values, to 17
receive the full ActiveEPList from the remote device. 18
19
2.4.4.2 End Device Bind, Bind, Unbind Bind Management 20
Server Services 21
22
Table 2.110 lists the commands supported by Device Profile: End Device Bind, 23
Bind and Unbind Server Services. Each of these primitives will be discussed in 24
the following sub-clauses. 25
Table 2.110 End Device Bind, Unbind and Bind Management 26
Server Services Primitives 27
28
End Device Bind, Bind and Unbind Server
Server Service Commands Processing 29
30
End_Device_Bind_rsp O 31
Bind_rsp O 32
33
Unbind_rsp O
34
Bind_Register_rsp O 35
Replace_Device_rsp O 36
37
Store_Bkup_Bind_Entry_rsp O
38
Remove_Bkup_Bind_Entry_rsp O 39
Backup_Bind_Table_rsp O 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
184 Application Layer Specification

Table 2.110 End Device Bind, Unbind and Bind Management


Server Services Primitives 1
Recover_Bind_Table_rsp O
2
3
Backup_Source_Bind_rsp O 4
Recover_Source_Bind_rsp O 5
6
2.4.4.2.1 End_Device_Bind_rsp 7
8
The End_Device_Bind_rsp command (ClusterID=0x8020) shall be formatted as 9
illustrated in Figure 2.83. 10
11
Octets: 1 12
Status 13
14
Figure 2.83 Format of the End_Device_Bind_rsp Command Frame 15
16
Table 2.111 specifies the fields of the End_Device_Bind_rsp command frame. 17
Table 2.111 Fields of the End_Device_Bind_rsp Command 18
19
Name Type Valid Range Description 20
Status Integer SUCCESS, The status of the End_Device_Bind_req 21
NOT_SUPPORTED, command 22
INVALID_EP, 23
TIMEOUT or
24
NO_MATCH
25
26
2.4.4.2.1.1 When Generated 27
The End_Device_Bind_rsp is generated by the ZigBee Coordinator in response to 28
an End_Device_Bind_req and contains the status of the request. This command 29
shall be unicast to each device involved in the bind attempt, using the 30
acknowledged data service. 31
32
A Status of NOT_SUPPORTED indicates that the request was directed to a device 33
which was not the ZigBee Coordinator or that the ZigBee Coordinator does not 34
support End Device Binding. Otherwise, End_Device_Bind_req processing is 35
performed as described below, including transmission of the 36
End_Device_Bind_rsp. 37
38
2.4.4.2.1.2 Effect on Receipt 39
40
When an End_Device_Bind_req is received, determination is made if a Status of
41
NOT_SUPPORTED is warranted as indicated in the previous section. Assuming
42
this device is the ZigBee Coordinator, the supplied endpoint shall be checked to
43
determine whether it falls within the specified range. If it does not, a Status of
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 185

INVALID_EP shall be returned. If the supplied endpoint falls within the specified
range and if this is the first End_Device_Bind_req submitted for evaluation, it 1
shall be stored and a timer started which expires at a pre-configured timeout 2
value. This timeout value shall be a configurable item on the ZigBee Coordinator. 3
If the timer expires before a second End_Device_Bind_req is received, a Status of 4
TIMEOUT is returned. Otherwise, if a second End_Device_Bind_req is received 5
within the timeout window, the two End_Device_Bind_req's are compared for a 6
match. A Status of NO_MATCH indicates that two End_Device_Bind_req were 7
evaluated for a match, but either the ProfileID parameters did not match or the 8
ProfileID parameter matched but there was no match of any element of the 9
InClusterList or OutClusterList. A Status of SUCCESS means that a match was 10
detected and a resulting Bind_req will subsequently be directed to the device 11
indicated by the BindingTarget field of the End_Device_Bind_req with matched 12
elements of the OutClusterList. 13
14
2.4.4.2.2 Bind_rsp 15
The Bind_rsp command (ClusterID=0x8021) shall be formatted as illustrated in 16
Figure 2.84. 17
18
Octets: 1 19
20
Status
21
Figure 2.84 Format of the Bind_rsp Command Frame 22
23
Table 2.112 specifies the fields of the Bind_rsp command frame. 24
25
Table 2.112 Fields of the Bind_rsp Command
26
Name Type Valid Range Description 27
28
Status Integer SUCCESS, The status of the Bind_req command.
NOT_SUPPORTED, 29
INVALID_EP, 30
TABLE_FULL or 31
NOT_AUTHORIZED 32
33
2.4.4.2.2.1 When Generated 34
35
The Bind_rsp is generated in response to a Bind_req. If the Bind_req is processed 36
and the Binding Table entry committed on the Remote Device, a Status of 37
SUCCESS is returned. If the Remote Device is not a Primary binding table cache 38
or the SrcAddress, a Status of NOT_SUPPORTED is returned. The supplied 39
endpoint shall be checked to determine whether it falls within the specified range. 40
If it does not, a Status of INVALID_EP shall be returned. If the Remote Device is 41
the Primary binding table cache or SrcAddress but does not have Binding Table 42
resources for the request, a Status of TABLE_FULL is returned. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
186 Application Layer Specification

2.4.4.2.2.2 Effect on Receipt


1
Upon receipt, error checking is performed on the request as described in the 2
previous section. Assuming the Status is SUCCESS, the parameters from the 3
Bind_req are entered into the Binding Table at the Remote Device via the 4
APSME-BIND.request primitive. 5
2.4.4.2.3 Unbind_rsp 6
7
The Unbind_rsp command (ClusterID=0x8022) shall be formatted as illustrated in 8
Figure 2.85. 9
10
Octets: 1 11
Status 12
13
Figure 2.85 Format of the Unbind_rsp Command Frame 14
15
Table 2.113 specifies the fields of the Unbind_rsp command frame. 16
Table 2.113 Fields of the Unbind_rsp Command 17
18
Name Type Valid Range Description 19
Status Integer SUCCESS, The status of the Unbind_req command. 20
NOT_SUPPORTED, 21
INVALID_EP, 22
NO_ENTRY or
23
NOT_AUTHORIZED
24
25
2.4.4.2.3.1 When Generated 26
The Unbind_rsp is generated in response to an Unbind_req. If the Unbind_req is 27
processed and the corresponding Binding Table entry is removed from the Remote 28
Device, a Status of SUCCESS is returned. If the Remote Device is not the ZigBee 29
Coordinator or the SrcAddress, a Status of NOT_SUPPORTED is returned. The 30
supplied endpoint shall be checked to determine whether it falls within the 31
specified range. If it does not, a Status of INVALID_EP shall be returned If the 32
Remote Device is the ZigBee Coordinator or SrcAddress but does not have a 33
Binding Table entry corresponding to the parameters received in the request, a 34
Status of NO_ENTRY is returned. 35
36
37
2.4.4.2.3.2 Effect on Receipt
38
Upon receipt, error checking is performed on the response. If the status is 39
SUCCESS, the device has successfully removed the binding entry for the 40
parameters specified in the Unbind_req. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 187

2.4.4.2.4 Bind_Register_rsp
1
The Bind_Register_rsp command (ClusterID=0x8023) shall be formatted as 2
illustrated in Figure 2.86. 3
4
Octets: 1 2 2 Variable
5
Status BindingTableEntries BindingTableListCount BindingTableList 6
7
Figure 2.86 Format of the Bind_Register_rsp Command Frame 8
9
Table 2.114 specifies the fields of the Bind_Register_rsp command frame. 10
Table 2.114 Fields of the Bind_Register_rsp Command 11
12
Name Type Valid Range Description
13
Status Integer SUCCESS, The status of the Bind_Register_reg 14
NOT_SUPPORTED, command. 15
TABLE_FULL 16
BindingTable Integer 0x0000 - 0ffff Number of binding table entries for 17
Entries the requesting device held by the 18
primary binding table cache. 19
BindingTable Integer 0x0000 - 0xffff Number of source binding table 20
ListCount entries contained in this response. 21
BindingTable List of This list shall contain the A list of source binding. 22
List source number of elements 23
binding given by the 24
descriptors BindingTableListCount 25
26
2.4.4.2.4.1 When Generated 27
28
The Bind_Register_rsp is generated from a primary binding table cache device in 29
response to a Bind_Register_req and contains the status of the request. This 30
command shall be unicast to the requesting device. 31
If the device receiving the Bind_Register_req is not a primary binding table cache 32
a Status of NOT_SUPPORTED is returned. If its list of devices which choose to 33
store their own binding table entries is full, a status of TABLE_FULL is returned. 34
In these error cases, BindingTableEntries and BindingTableListCount shall be 35
zero and BindingTableList shall be empty. A Status of SUCCESS indicates that 36
the requesting device has been successfully registered. 37
38
In the successful case, the primary binding table cache device shall search its 39
cache for existing entries whose source address is the same as the parameter 40
supplied in the Bind_Register_req command. The number of such entries is given 41
in the response as BindingTableEntries. The entries are used to generate 42
BindingTableList up to the maximum that can be contained in the response. The 43
actual number of entries is given in the response as BindingTableListCount and 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
188 Application Layer Specification

may be less than BindingTableEntries if this is too large. In this case (which is
expected to be rare) the primary binding table cache device shall use Bind_req 1
commands to send the rest of the entries to the requesting device. 2
3
2.4.4.2.4.2 Effect on Receipt 4
5
The requesting device is notified of the results of its attempt to register. If 6
successful, it shall store the source binding table entries from the response into its 7
source binding table. 8
2.4.4.2.5 Replace_Device_rsp 9
10
The Replace_Device_rsp command (ClusterID=0x8024) shall be formatted as 11
illustrated in Figure 2.87. 12
13
Octets: 1 14
Status 15
16
Figure 2.87 Format of the Replace_Device_rsp Command Frame 17
18
Table 2.115 specifies the fields of the Replace_Device_rsp command frame 19
Table 2.115 Fields of the Replace_Device_rsp Command 20
21
Name Type Valid Range Description 22
Status Integer NOT_SUPPORTED, The status of the Replace_Device_req 23
INV_REQUESTTYPE command. 24
25
2.4.4.2.5.1 When Generated 26
27
The Replace_Device_rsp is generated from a primary binding table cache device 28
in response to a Replace_Device_req and contains the status of the request. This 29
command shall be unicast to the requesting device. If the device receiving the 30
Replace_Device_req is not a primary binding table cache, a Status of 31
NOT_SUPPORTED is returned. The primary binding table cache shall search its 32
binding table for entries whose source address and source endpoint, or whose 33
destination address and destination endpoint match OldAddress and OldEndpoint, 34
as described in the text for Replace_Device_req. It shall change these entries to 35
have NewAddress and possibly NewEndpoint. It shall then return a response of 36
SUCCESS. 37
38
2.4.4.2.5.2 Effect on Receipt 39
40
The requesting device is notified of the status of its Replace_Device_req 41
command. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 189

2.4.4.2.6 Store_Bkup_Bind_Entry_rsp
1
The Store_Bkup_Bind_Entry_rsp command (ClusterID=0x8025) shall be 2
formatted as illustrated in Figure 2.88. 3
4
Octets: 1
5
Status 6
7
Figure 2.88 Format of the Store_Bkup_Bind_Entry_rsp Command Frame 8
9
Table 2.116 specifies the fields of the Store_Bkup_Bind_Entry_rsp command 10
frame. 11
Table 2.116 Fields of the Store_Bkup_Bind_Entry_rsp Command 12
13
Name Type Valid Range Description
14
Status Integer SUCCESS, The status of the 15
NOT_SUPPORTED, Store_Bkup_Bind_Entry_rsp command. 16
INV_REQUESTTYPE. 17
TABLE_FULL
18
19
2.4.4.2.6.1 When Generated 20
21
The Store_Bkup_Bind_Entry_rsp is generated from a backup binding table cache
22
device in response to a Store_Bkup_Bind_Entry_req from a primary binding table
23
cache, and contains the status of the request. This command shall be unicast to the
24
requesting device. If the remote device is not a backup binding table cache, it shall
25
return a status of NOT_SUPPORTED. If the originator of the request is not
26
recognized as a primary binding table cache, it shall return a status of
27
INV_REQUESTTYPE. Otherwise, the backup binding table cache shall add the
28
binding entry to its binding table and return a status of SUCCESS. If there is no
29
room, it shall return a status of TABLE_FULL.
30
31
2.4.4.2.6.2 Effect on Receipt
32
The requesting device is notified of the status of its attempt to store a bind entry. 33
34
2.4.4.2.7 Remove_Bkup_Bind_Entry_rsp 35
The Remove_Bkup_Bind_Entry_rsp command (ClusterID=0x8026) shall be 36
formatted as illustrated in Figure 2.89. 37
38
Octets: 1 39
40
Status
41
Figure 2.89 Format of the Remove_Bkup_Bind_Entry_rsp Command Frame 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
190 Application Layer Specification

Table 2.117 specifies the fields of the Remove_Bkup_Bind_Entry_rsp command


frame. 1
2
Table 2.117 Fields of the Remove_Bkup_Bind_Entry_rsp Command
3
Name Type Valid Range Description 4
5
Status Integer SUCCESS, The status of the 6
NOT_SUPPORTED, Remove_Bkup_Bind_Entry_rsp
INV_REQUESTTYPE, command. 7
NO_ENTRY 8
9
10
2.4.4.2.7.1 When Generated
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 17
of 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
2.4.4.2.7.2 Effect on Receipt 22
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
illustrated in Figure 2.90. 29
30
Octets: 1 2 31
Status EntryCount 32
33
Figure 2.90 Format of the Backup_Bind_Table_rsp Command Frame 34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 191

Table 2.118 specifies the fields of the Backup_Bind_Table_rsp command frame.


1
Table 2.118 Fields of the Backup_Bind_Table_rsp Command
2
Name Type Valid Range Description 3
4
Status Integer SUCCESS, The status of the 5
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
binding table. 9
10
11
2.4.4.2.8.1 When Generated 12
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
cache and contains the status of the request. This command shall be unicast to the 15
requesting device. If the remote device is not a backup binding table cache, it shall 16
return a status of NOT_SUPPORTED. If the originator of the request is not 17
recognized as a primary binding table cache, it shall return a status of 18
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 23
shall return a status of SUCCESS and EntryCount will be equal to StartIndex + 24
BindingTableListCount from Backup_Bind_Table_req. 25
26
2.4.4.2.8.2 Effect on Receipt 27
28
The requesting device is notified of the status of its attempt to store a binding 29
table. 30
31
2.4.4.2.9 Recover_Bind_Table_rsp
32
The Backup_Bind_Table_rsp command (ClusterID=0x8028) shall be formatted as 33
illustrated in Figure 2.91. 34
35
Octets: 1 2 2 2 Variable 36
Status BindingTableEntries StartIndex BindingTableListCount BindingTableList 37
38
Figure 2.91 Format of the Backup_Bind_Table_rsp Command Frame 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
192 Application Layer Specification

Table 2.119 specifies the fields of the Recover_Bind_Table_rsp command frame.


1
Table 2.119 Fields of the Recover_Bind_Table_rsp Command
2
Name Type Valid Range Description 3
4
Status Integer SUCCESS, The status of the 5
NOT_SUPPORTED, Recover_Bind_Table_rsp
INV_REQUESTTYPE, command. 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
2.4.4.2.9.1 When Generated 22
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
cache and contains the status of the request. This command shall be unicast to the 25
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
recognized as a primary binding table cache it shall return a status of 28
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, and 34
BindingTableListCount is the number of entries which is being returned in the 35
response. 36
37
2.4.4.2.9.2 Effect on Receipt 38
39
The requesting device is notified of the status of its attempt to restore a binding 40
table. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 193

2.4.4.2.10 Backup_Source_Bind_rsp
1
The Backup_Source_Bind_rsp command (ClusterID=0x8029) shall be formatted 2
as illustrated in Figure 2.92. 3
4
Octets: 1
5
Status 6
7
Figure 2.92 Format of the Backup_Source_Bind_rsp Command Frame 8
9
Table 2.120 specifies the fields of the Backup_Source_Bind_rsp command frame. 10
Table 2.120 Fields of the Backup_Source_Bind_rsp Command 11
12
Name Type Valid Range Description
13
Status Integer SUCCESS, The status of the 14
NOT_SUPPORTED, Backup_Source_Bind_rsp 15
TABLE_FULL, command. 16
INV_REQUESTTYPE
17
18
2.4.4.2.10.1 When Generated 19
20
The Backup_Source_Bind_rsp is generated from a backup binding table cache
21
device in response to a Backup_Source_Bind_req from a primary binding table
22
cache and contains the status of the request. This command shall be unicast to the
23
requesting device. If the remote device is not a backup binding table cache, it shall
24
return a status of NOT_SUPPORTED. If the originator of the request is not
25
recognized as a primary binding table cache, it shall return a status of
26
INV_REQUESTTYPE. Otherwise, the backup binding table cache shall
27
overwrite its backup source binding table starting with StartIndex and continuing
28
for BindingTableListCount entries. If this exceeds its table size, it shall return a
29
status of TABLE_FULL. Otherwise it shall return a status of SUCCESS.
30
31
2.4.4.2.10.2 Effect on Receipt
32
The requesting device is notified of the status of its attempt to backup the source 33
binding table. 34
35
2.4.4.2.11 Recover_Source_Bind_rsp 36
The Recover_Source_Bind_rsp command (ClusterID=0x802a) shall be formatted 37
as illustrated in Figure 2.93. 38
39
Octets: 1 2 2 2 Variable 40
41
Status SourceTableEntries StartIndex SourceTableListCount SourceTableList
42
Figure 2.93 Format of the Recover_Source_Bind_rsp Command Frame 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
194 Application Layer Specification

Table 2.121 specifies the fields of the Recover_Source_Bind_rsp command


frame. 1
2
Table 2.121 Fields of the Recover_Source_Bind_rsp Command
3
Name Type Valid Range Description 4
5
Status Integer SUCCESS, The status of the 6
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
2.4.4.2.11.1 When Generated
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
cache and contains the status of the request. This command shall be unicast to the 27
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
recognized as a primary binding table cache, it shall return a status of 30
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, and 36
SourceTableListCount is the number of entries which is being returned in the 37
response. 38
39
2.4.4.2.11.2 Effect on Receipt 40
41
The requesting device is notified of the status of its attempt to restore a source 42
binding table. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 195

2.4.4.3 Network Management Server Services


1
Table 2.122 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.122 Network Management Server Service Commands 5
6
Network Management Server 7
Server Service Command Processing 8
Mgmt_NWK_Disc_rsp O 9
10
Mgmt_Lqi_rsp O
11
Mgmt_Rtg_rsp O 12
Mgmt_Bind_rsp O 13
14
Mgmt_Leave_rsp O 15
Mgmt_Direct_Join_rsp O 16
Mgmt_Permit_Joining_rsp M
17
18
Mgmt_Cache_rsp O 19
Mgmt_NWK_Update_notify O 20
21
2.4.4.3.1 Mgmt_NWK_Disc_rsp 22
23
The Mgmt_NWK_Disc_rsp command (ClusterID=0x8030) shall be formatted as 24
illustrated in Figure 2.94. 25
26
Octets: 1 1 1 1 Variable 27
Status Network Start NetworkList NetworkList 28
Count Index Count 29
30
Figure 2.94 Format of the Mgmt_NWK_Disc_rsp Command Frame 31
32
Table 2.123 specifies the fields of the Mgmt_NWK_Disc_rsp command frame. 33
Table 2.123 Fields of the Mgmt_NWK_Disc_rsp Command 34
35
Name Type Valid Range Description
36
Status Integer NOT_SUPPORTED or The status of the 37
any status code returned Mgmt_NWK_Disc_req 38
from the command. 39
NLME-NETWORK-
DISCOVERY.request 40
primitive. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
196 Application Layer Specification

Table 2.123 Fields of the Mgmt_NWK_Disc_rsp Command (Continued)


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

Table 2.124 NetworkList Record Format


1
Size 2
Name (Bits) Valid Range Description
3
SuperframeOrder 4 0x0-0xf For beacon-oriented networks, i.e., beacon 4
order < 15, this specifies the length of the 5
active period of the superframe. For a 6
discussion of MAC sub-layer superframe
order see [B1].
7
8
PermitJoining 1 TRUE or FALSE A value of TRUE indicates that at least one 9
ZigBee router on the network currently
10
permits joining, i.e., its NWK has been
issued an NLME-PERMIT-JOINING 11
primitive and the time limit, if given, has 12
not yet expired. 13
Reserved 7 Each of these bits shall be set to 0. 14
15
16
2.4.4.3.1.1 When Generated
17
The Mgmt_NWK_Disc_rsp is generated in response to an 18
Mgmt_NWK_Disc_req. If this management command is not supported, a status 19
of NOT_SUPPORTED shall be returned and all parameter fields after the Status 20
field shall be omitted. Otherwise, the Remote Device shall implement the 21
following process. 22
23
Upon receipt of and after support for the Mgmt_NWK_Disc_req has been 24
verified, the Remote Device shall issue an NLME-NETWORK- 25
DISCOVERY.request primitive using the ScanChannels and ScanDuration 26
parameters, supplied in the Mgmt_NWK_Disc_req command. Upon receipt of the 27
NLME-NETWORK-DISCOVERY.confirm primitive, the Remote Device shall 28
report the results, starting with the StartIndex element, via the 29
Mgmt_NWK_Disc_rsp command. The NetworkList field shall contain whole 30
NetworkList records, formatted as specified in Table 2.124, until the limit on 31
MSDU size, i.e., aMaxMACFrameSize (see [B1]), is reached. The number of 32
results reported shall be set in the NetworkListCount. 33
34
2.4.4.3.1.2 Effect on Receipt 35
The local device is notified of the results of its attempt to perform a remote 36
network discovery. 37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
198 Application Layer Specification

2.4.4.3.2 Mgmt_Lqi_rsp
1
The Mgmt_Lqi_rsp command (ClusterID=0x8031) shall be formatted as 2
illustrated in Figure 2.95. 3
4
Octets: 1 1 1 1 Variable
5
Status NeighborTable Start NeighborTable NeighborTable 6
Entries Index ListCount List 7
8
Figure 2.95 Format of the Mgmt_Lqi_rsp Command Frame
9
Table 2.125 specifies the fields of the Mgmt_Lqi_rsp command frame. 10
11
Table 2.125 Fields of the Mgmt_Lqi_rsp Command 12
Name Type Valid Range Description 13
14
Status Integer NOT_SUPPORTED or The status of the 15
any status code returned Mgmt_Lqi_req command. 16
from the NLME-
GET.confirm primitive 17
18
NeighborTableEntries Integer 0x00-0xff Total number of Neighbor 19
Table entries within the
Remote Device. 20
21
StartIndex Integer 0x00-0xff Starting index within the 22
Neighbor Table to begin
reporting for the
23
NeighborTableList. 24
25
NeighborTableListCount Integer 0x00-0x02 Number of Neighbor Table
26
entries included within
NeighborTableList. 27
28
NeighborTableList List of The list shall contain the A list of descriptors,
29
Neighbor number elements given beginning with the
Descriptors by the StartIndex element and 30
NeighborTableListCount continuing for 31
NeighborTableListCount, 32
of the elements in the 33
Remote Device's Neighbor
34
Table including the device
address and associated LQI 35
(see Table 2.126 for 36
details). 37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 199

Table 2.126 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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
200 Application Layer Specification

Table 2.126 NeighborTableList Record Format (Continued)


1
Size 2
Name (Bits) Valid Range Description
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
2.4.4.3.2.1 When Generated 15
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.126) 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, and 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.126) 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
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 201

The extended address, device type, RxOnWhenIdle, and permit joining fields
have “unknown” values which shall be returned where the values are not 1
available. 2
3
2.4.4.3.2.2 Effect on Receipt 4
5
The local device is notified of the results of its attempt to obtain the neighbor 6
table. 7
2.4.4.3.3 Mgmt_Rtg_rsp 8
9
The Mgmt_Rtg_rsp command (ClusterID=0x8032) shall be formatted as 10
illustrated in Figure 2.96. 11
12
Octets: 1 1 1 1 Variable 13
Status RoutingTable Start RoutingTable RoutingTable 14
Entries Index ListCount List 15
16
Figure 2.96 Format of the Mgmt_Rtg_rsp Command Frame 17
18
Table 2.127 specifies the fields of the Mgmt_Rtg_rsp command frame. 19
Table 2.127 Fields of the Mgmt_Rtg_rsp Command 20
21
Name Type Valid Range Description
22
Status Integer NOT_SUPPORTED or The status of the Mgmt_Rtg_req 23
any status code returned command. 24
from the NLME- 25
GET.confirm primitive
26
RoutingTableEntries Integer 0x00-0xff Total number of Routing Table 27
entries within the Remote Device. 28
StartIndex Integer 0x00-0xff Starting index within the Routing 29
Table to begin reporting for the 30
RoutingTableList. 31
RoutingTableListCou Integer 0x00-0xff Number of Routing Table entries 32
nt included within RoutingTableList. 33
RoutingTableList List of The list shall contain the A list of descriptors, beginning 34
Routin number elements given with the StartIndex element and 35
g by the continuing for 36
Descri RoutingTableListCount RoutingTableListCount, of the 37
ptors elements in the Remote Device's
38
Routing Table (see the
Table 2.128 for details). 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
202 Application Layer Specification

1
Table 2.128 RoutingTableList Record Format
2
Size 3
Name (Bits) Valid Range Description 4
5
Destination 16 The 16-bit network Destination address.
address address of this route. 6
7
Status 3 The status of the 0x0=ACTIVE. 8
route. 0x1=DISCOVERY_UNDERWAY. 9
0x2=DISCOVERY_FAILED. 10
0x3=INACTIVE. 11
0x4=VALIDATION_UNDERWAY 12
0x5-0x7=RESERVED. 13
14
Memory 1 A flag indicating whether the device
Constrained is a memory constrained 15
concentrator. 16
17
Many-to-one 1 A flag indicating that the destination
is a concentrator that issued a many- 18
to-one request. 19
20
Route record 1 A flag indicating that a route record
required command frame should be sent to the 21
destination prior to the next data 22
packet. 23
Reserved 2 24
25
Next-hop 16 The 16-bit network Next-hop address. 26
address address of the next
hop on the way to the
27
destination. 28
29
30
CCB #250 31
32
2.4.4.3.3.1 When Generated 33
34
The Mgmt_Rtg_rsp is generated in response to an Mgmt_Rtg_req. If this
35
management command is not supported, a status of NOT_SUPPORTED shall be
36
returned and all parameter fields after the Status field shall be omitted. Otherwise,
37
the Remote Device shall implement the following processing.
38
Upon receipt of and after support for the Mgmt_Rtg_req has been verified, the 39
Remote Device shall perform an NLME-GET.request (for the nwkRouteTable 40
attribute) and process the resulting NLME-GET.confirm (containing the 41
nwkRouteTable attribute) to create the Mgmt_Rtg_rsp command. The 42
Mgmt_Rtg_rsp command shall contain the same status that was contained in the 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 203

NLME-GET.confirm primitive and if this was not SUCCESS, all parameter fields
after the status field shall be omitted. 1
2
From the nwkRouteTable attribute, the routing table shall be accessed, starting 3
with the index specified by StartIndex, and moved to the RoutingTableList field of 4
the Mgmt_Rtg_rsp command. The entries reported from the routing table shall be 5
those, starting with StartIndex and including whole RoutingTableList records (see 6
Table 2.127) until MSDU size limit, i.e., aMaxMACFrameSize (see [B1]), is 7
reached. Within the Mgmt_Rtg_Rsp command, the RoutingTableEntries field 8
shall represent the total number of Routing Table entries in the Remote Device. 9
The RoutingTableListCount field shall be the number of entries reported in the 10
RoutingTableList field of the Mgmt_Rtg_req command. 11
12
2.4.4.3.3.2 Effect on Receipt 13
The local device is notified of the results of its attempt to obtain the routing table. 14
15
2.4.4.3.4 Mgmt_Bind_rsp 16
17
The Mgmt_Bind_rsp command (ClusterID=0x8033) shall be formatted as
18
illustrated in Figure 2.97.
19
Octets: 1 1 1 1 Variable 20
21
Status BindingTable Start BindingTable BindingTable 22
Entries Index ListCount List
23
Figure 2.97 Format of the Mgmt_Bind_rsp Command Frame 24
25
Table 2.129 specifies the fields of the Mgmt_Bind_rsp command frame. 26
27
Table 2.129 Fields of the Mgmt_Bind_rsp Command
28
Name Type Valid Range Description 29
30
Status Integer NOT_SUPPORTED or The status of the
any status code returned Mgmt_Bind_req command. 31
from the APSME- 32
GET.confirm primitive 33
BindingTableEntries Integer 0x00-0xff Total number of Binding 34
Table entries within the 35
Remote Device. 36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
204 Application Layer Specification

Table 2.129 Fields of the Mgmt_Bind_rsp Command (Continued)


1
Name Type Valid Range Description 2
StartIndex Integer 0x00-0xff Starting index within the 3
Binding Table to begin 4
reporting for the 5
BindingTableList. 6
BindingTableListCou Integer 0x00-0xff Number of Binding Table 7
nt entries included within 8
BindingTableList. 9
BindingTableList List of The list shall contain the A list of descriptors, 10
Binding number elements given beginning with the StartIndex 11
Descriptors by the element and continuing for 12
BindingTableListCount BindingTableListCount, of
13
the elements in the Remote
Device's Binding Table (see 14
Table 2.130 for details). 15
16
17
18
Table 2.130 BindingTableList Record Format 19
Size 20
Name (Bits) Valid Range Description 21
22
SrcAddr 64 A valid 64-bit IEEE The source IEEE address for the
address binding entry.
23
24
SrcEndpoint 8 0x01 - 0xf0 The source endpoint for the binding 25
entry.
26
ClusterId 16 0x0000 - 0xffff The identifier of the cluster on the 27
source device that is bound to the 28
destination device.
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 205

Table 2.130 BindingTableList Record Format (Continued)


1
Size 2
Name (Bits) Valid Range Description
3
DstAddrMode 8 0x00 - 0xff The addressing mode for the 4
destination address. This field can 5
take one of the non-reserved values 6
from the following list:
7
0x00 = reserved 8
0x01 = 16-bit group address for 9
DstAddr and DstEndpoint not 10
present 11
0x02 = reserved 12
0x03 = 64-bit extended address for 13
DstAddr and DstEndp present 14
0x04 – 0xff = reserved 15
DstAddr 16/64 As specified by the The destination address for the 16
DstAddrMode field binding entry. 17
DstEndpoint 0/8 0x01 - 0xf0, 0xff This field shall be present only if 18
the DstAddrMode field has a value 19
of 0x03 and, if present, shall be the 20
destination endpoint for the binding 21
entry.
22
23
2.4.4.3.4.1 When Generated 24
25
The Mgmt_Bind_rsp is generated in response to a Mgmt_Bind_req. If this
26
management command is not supported, a status of NOT_SUPPORTED shall be
27
returned and all parameter fields after the Status field shall be omitted. Otherwise,
28
the Remote Device shall implement the following processing.
29
Upon receipt of and after support for the Mgmt_Bind_req has been verified, the 30
Remote Device shall perform an APSME-GET.request (for the apsBindingTable 31
attribute) and process the resulting APSME-GET.confirm (containing the 32
apsBindingTable attribute) to create the Mgmt_Bind_rsp command. The 33
Mgmt_Bind_rsp command shall contain the same status that was contained in the 34
APSME-GET.confirm primitive and if this was not SUCCESS, all parameter 35
fields after the status field shall be omitted. 36
37
From the apsBindingTable attribute, the binding table shall be accessed, starting
38
with the index specified by StartIndex, and moved to the BindingTableList field of
39
the Mgmt_Bind_rsp command. The entries reported from the binding table shall
40
be those, starting with StartIndex and including whole BindingTableList records
41
(see Table 2.130) until the MSDU size limit, i.e., aMaxMACFrameSize (see [B1]),
42
is reached. Within the Mgmt_Bind_Rsp command, the BindingTableEntries field
43
shall represent the total number of Binding Table entries in the Remote Device.
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
206 Application Layer Specification

The BindingTableListCount field shall be the number of entries reported in the


BindingTableList field of the Mgmt_Bind_req command. 1
2
2.4.4.3.4.2 Effect on Receipt 3
4
The local device is notified of the results of its attempt to obtain the binding table. 5
2.4.4.3.5 Mgmt_Leave_rsp 6
7
The Mgmt_Leave_rsp command (ClusterID=0x8034) shall be formatted as 8
illustrated in Figure 2.98. 9
10
Octets: 1 11
Status 12
13
Figure 2.98 Format of the Mgmt_Leave_rsp Command Frame 14
15
Table 2.131 specifies the fields of the Mgmt_Leave_rsp command frame. 16
Table 2.131 Fields of the Mgmt_Leave_rsp Command 17
18
Name Type Valid Range Description 19
Status Integer NOT_SUPPORTED, The status of the 20
NOT_AUTHORIZED or Mgmt_Leave_req 21
any status code returned command. 22
from the NLME- 23
LEAVE.confirm primitive
24
25
2.4.4.3.5.1 When Generated 26
27
The Mgmt_Leave_rsp is generated in response to a Mgmt_Leave_req. If this
28
management command is not supported, a status of NOT_SUPPORTED shall be
29
returned. Otherwise, the Remote Device shall implement the following
30
processing.
31
Upon receipt of and after support for the Mgmt_Leave_req has been verified, the 32
Remote Device shall execute the NLME-LEAVE.request to disassociate from the 33
currently associated network. The Mgmt_Leave_rsp shall contain the same status 34
that was contained in the NLME-LEAVE.confirm primitive. 35
36
Once a device has disassociated, it may execute pre-programmed logic to perform
37
NLME-NETWORK-DISCOVERY and NLME-JOIN to join/re-join a network.
38
39
2.4.4.3.5.2 Effect on Receipt
40
The local device is notified of the results of its attempt to cause a remote device to 41
leave the network. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 207

2.4.4.3.6 Mgmt_Direct_Join_rsp
1
The Mgmt_Direct_Join_rsp (ClusterID=0x8035) shall be formatted as illustrated 2
in Figure 2.99. 3
4
Octets: 1
5
Status 6
7
Figure 2.99 Format of the Mgmt_Direct_Join_rsp Command Frame 8
9
Table 2.132 specifies the fields of the Mgmt_Direct_Join_rsp command frame. 10
Table 2.132 Fields of the Mgmt_Direct_Join_rsp Command 11
12
Name Type Valid Range Description
13
Status Integer NOT_SUPPORTED, The status of the 14
NOT_AUTHORIZED or any Mgmt_Direct_Join_req 15
status code returned from the command. 16
NLME-DIRECT-JOIN.confirm
primitive 17
18
19
2.4.4.3.6.1 When Generated 20
The Mgmt_Direct_Join_rsp is generated in response to a Mgmt_Direct_Join_req. 21
If this management command is not supported, a status of NOT_SUPPORTED 22
shall be returned. Otherwise, the Remote Device shall implement the following 23
processing. 24
25
Upon receipt and after support for the Mgmt_Direct_Join_req has been verified, 26
the Remote Device shall execute the NLME-DIRECT-JOIN.request to directly 27
associate the DeviceAddress contained in the Mgmt_Direct_Join_req to the 28
network. The Mgmt_Direct_Join_rsp shall contain the same status that was 29
contained in the NLME-DIRECT-JOIN.confirm primitive. 30
31
2.4.4.3.6.2 Effect on Receipt 32
33
Upon receipt and after support for the Mgmt_Direct_Join_req has been verified,
34
the Remote Device shall execute the NLME-DIRECT-JOIN.request to directly
35
associate the DeviceAddress contained in the Mgmt_Direct_Join_req to the
36
network.
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
208 Application Layer Specification

2.4.4.3.7 Mgmt_Permit_Joining_rsp
1
The Mgmt_Permit_Joining_rsp command (ClusterID=0x8036) shall be formatted 2
as illustrated in Figure 2.100. 3
4
Octets: 1
5
Status 6
7
Figure 2.100 Format of the Mgmt_Permit_Joining_rsp Command Frame 8
9
Table 2.133 specifies the fields of the Mgmt_Permit_Joining_rsp command 10
frame. 11
Table 2.133 Fields of the Mgmt_Permit_Joining_rsp Command 12
13
Name Type Valid Range Description
14
Status Integer SUCCESS, The status of the 15
INVALID_REQUEST, Mgmt_Permit_Joining_rsp 16
NOT_AUTHORIZED or command. 17
any status code returned
from the NLME- 18
PERMIT- 19
JOINING.confirm 20
primitive 21
22
2.4.4.3.7.1 When Generated 23
24
The Mgmt_Permit_Joining_rsp is generated in response to a unicast 25
Mgmt_Permit_Joining_req. In the description which follows, note that no 26
response shall be sent if the Mgmt_Permit_Joining_req was received as a 27
broadcast to all routers. If this management command is not permitted by the 28
requesting device, a status of INVALID_REQUEST shall be returned. Upon 29
receipt and after support for Mgmt_Permit_Joining_req has been verified, the 30
Remote Device shall execute the NLME-PERMIT-JOINING.request. The 31
Mgmt_Permit-Joining_rsp shall contain the same status that was contained in the 32
NLME-PERMIT-JOINING.confirm primitive. 33
34
2.4.4.3.7.2 Effect on Receipt 35
36
The status of the Mgmt_Permit_Joining_req command is notified to the requestor.
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 209

2.4.4.3.8 Mgmt_Cache_rsp
1
The Mgmt_Cache_rsp command (ClusterID=0x8037) shall be formatted as 2
illustrated in Figure 2.101 3
4
Octets: 1 1 1 1 Variable
5
Status DiscoveryCache StartIndex DiscoveryCacheList DiscoveryCacheList 6
Entries Count 7
8
Figure 2.101 Format of the Mgmt_Cache_rsp Command Frame
9
Table 2.134 specifies the fields of the Mgmt_Cache_rsp command frame. 10
11
Table 2.134 Fields of the Mgmt_Cache_rsp Command 12
Name Type Valid Range Description 13
14
Status Integer SUCCESS or The status of the 15
NOT_SUPPORTED Mgmt_Cache_rsp command. 16
DiscoveryCacheEntries Integer 0x00 - 0xff DiscoveryCacheEntries. 17
StartIndex Integer 0x00 - 0xff StartIndex.
18
19
DiscoveryCacheListCount Integer 0x00 - 0xff The list shall contain the number 20
of elements given by the
21
DiscoveryCacheListCount
parameter. 22
23
DiscoveryCacheList Integer List of A list of descriptors, one for each
24
DiscoveryCache of the Discovery cache devices
descriptors registered, beginning with the 25
StartIndex element and 26
continuing for 27
DiscoveryCacheListCount, of 28
the registered devices in the
29
Primary Discovery Cache. Each
entry shall be formatted as 30
illustrated in Table 2.135. 31
32
33
34
Table 2.135 DiscoveryCacheList Record Format 35
Size 36
Name (Bits) Valid Range Description 37
38
Extended 64 An extended 64-bit IEEE 64-bit IEEE Address of 39
Address Address the cached device.
40
Network 16 Network address The 16-bit network 41
Address address of the cached 42
device.
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
210 Application Layer Specification

2.4.4.3.8.1 When Generated


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.138) 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
2.4.4.3.8.2 Effect on Receipt 18
19
The local device is notified of the results of its attempt to obtain the discovery
20
cache list.
21
2.4.4.3.9 Mgmt_NWK_Update_notify 22
23
The Mgmt_NWK_Update_notify command (ClusterID=0x8038) shall be 24
formatted as illustrated in Figure 2.102. 25
Octets: 1 4 2 2 1 Variable 26
27
Status ScannedChan TotalTransmi Transmission ScannedChan EnergyValues 28
nels ssions Failures nelsListCount 29
Figure 2.102 Format of the Mgmt_NWK_Update_notify Command Frame 30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 211

Table 2.136 specifies the fields of the Mgmt_NWK_Update_notify command


frame. 1
2
Table 2.136 Fields of the Mgmt_NWK_Update_notify Command
3
Name Type Valid Range Description 4
5
Status Integer SUCCESS, The status of the 6
Mgmt_NWK_Update_notify
INVALID_REQUEST command. 7
or NOT_SUPPORTED 8
ScannedChannels Bitmap 0x00000000 - 0xffffffff. List of channels scanned by the 9
request. 10
TotalTransmissions Integer 0x0000 -0xffff Count of the total transmissions 11
reported by the device. 12
13
TransmissionFailure Integer x0000 -0xffff Sum of the total transmission
s failures reported by the device.
14
15
ScannedChannelsLi Integer 0x00 - 0xff The list shall contain the number 16
stCount of records contained in the
17
EnergyValues parameter.
18
EnergyValues Integer List of ED values each of The result of an energy 19
which can be in the measurement made on this
20
range of 0x00 - 0xff channel in accordance with [B1].
21
22
2.4.4.3.9.1 When Generated 23
The Mgmt_NWK_Update_notify is provided to enable ZigBee devices to report 24
the condition on local channels to a network manager. The scanned channel list is 25
the report of channels scanned and it is followed by a list of records, one for each 26
channel scanned, each record including one byte of the energy level measured 27
during the scan, or 0xff if there is too much interference on this channel. 28
29
When sent in response to a Mgmt_NWK_Update_req command the status field 30
shall represent the status of the request. When sent unsolicited the status field 31
shall be set to SUCCESS. 32
33
2.4.4.3.9.2 Effect on Receipt 34
35
The local device is notified of the local channel conditions at the transmitting
36
device, or of its attempt to update network configuration parameters.
37
38
2.4.5 ZDP Enumeration Description 39
40
This sub-clause explains the meaning of the enumerations used in the ZDP. 41
Table 2.137 shows a description of the ZDP enumeration values. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
212 Application Layer Specification

I
1
Table 2.137 ZDP Enumerations Description
2
Enumeration Value Description 3
4
SUCCESS 0x00 The requested operation or transmission 5
was completed successfully.
6
- 0x01-0x7f Reserved. 7
INV_REQUESTTYPE 0x80 The supplied request type was invalid. 8
9
DEVICE_NOT_FOUND 0x81 The requested device did not exist on a
device following a child descriptor
10
request to a parent. 11
12
INVALID_EP 0x82 The supplied endpoint was equal to 0x00
13
or between 0xf1 and 0xff.
14
NOT_ACTIVE 0x83 The requested endpoint is not described 15
by a simple descriptor.
16
NOT_SUPPORTED 0x84 The requested optional feature is not 17
supported on the target device. 18
TIMEOUT 0x85 A timeout has occurred with the 19
requested operation. 20
NO_MATCH 0x86 The end device bind request was 21
unsuccessful due to a failure to match 22
any suitable clusters. 23
- 0x87 Reserved.
24
25
NO_ENTRY 0x88 The unbind request was unsuccessful due 26
to the coordinator or source device not
having an entry in its binding table to
27
unbind. 28
29
NO_DESCRIPTOR 0x89 A child descriptor was not available
30
following a discovery request to a parent.
31
INSUFFICIENT_SPACE 0x8a The device does not have storage space 32
to support the requested operation.
33
NOT_PERMITTED 0x8b The device is not in the proper state to 34
support the requested operation. 35
TABLE_FULL 0x8c The device does not have table space to 36
support the operation. 37
NOT_AUTHORIZED 0x8d The permissions configuration table on 38
the target indicates that the request is not 39
authorized from this device. 40
- 0x8e-0xff Reserved.
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 213

2.4.6 Conformance 1
2
When conformance to this Profile is claimed, all capabilities indicated mandatory
3
for this Profile shall be supported in the specified manner (process mandatory).
4
This also applies to optional and conditional capabilities, for which support is
5
indicated, and is subject to verification as part of the ZigBee certification
6
program.
7
8
2.5 The ZigBee Device Objects (ZDO) 9
10
11
2.5.1 Scope 12
13
This section describes the concepts, structures, and primitives needed to 14
implement a ZigBee Device Objects application on top of a ZigBee Application 15
Support Sub-layer (sub-clause 2.2) and ZigBee Network Layer (Chapter 3). 16
17
ZigBee Device Objects are applications which employ network and application 18
support layer primitives to implement ZigBee End Devices, ZigBee Routers, and 19
ZigBee Coordinators. 20
The ZigBee Device Object Profile employs Clusters to describe its primitives. 21
The ZigBee Device Profile Clusters do not employ attributes and are analogous to 22
messages in a message transfer protocol. Cluster identifiers are employed within 23
the ZigBee Device Profile to enumerate the messages employed within ZigBee 24
Device Objects. 25
26
ZigBee Device Objects also employ configuration attributes. The configuration 27
attributes within ZigBee Device Objects are configuration parameters set by the 28
application or stack profile. The configuration attributes are also not related to the 29
ZigBee Device Profile, though both the configuration attributes and the ZigBee 30
Device Profile are employed with ZigBee Device Objects. 31
32
2.5.2 Device Object Descriptions 33
34
The ZigBee Device Objects are an application solution residing within the 35
Application Layer (APL) and above the Application Support Sub-layer (APS) in 36
the ZigBee stack architecture as illustrated in Figure 1.1. 37
38
The ZigBee Device Objects are responsible for the following functions: 39
• Initializing the Application Support Sublayer (APS), Network Layer (NWK), 40
Security Service Provider (SSP) and any other ZigBee device layer other than 41
the end applications residing over Endpoints 1-240. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
214 Application Layer Specification

• Assembling configuration information from the end applications to determine


and implement the functions described in the following sub-clauses. 1
2
2.5.2.1 Primary Discovery Cache Device Operation 3
4
The Primary Discovery Cache device is designated through configuration of the 5
device and advertisement in the Node Descriptor. The Primary Discovery Cache 6
device operates as a state machine with respect to clients wishing to utilize the 7
services of the Primary Discovery Cache. The following states and operations, as 8
described in Figure 2.103, shall be supported by the Primary Discovery Cache 9
device: 10
• Undiscovered: 11
12
• The client employs the Find Node Cache request, broadcast to all devices for 13
which macRxOnWhenIdle=TRUE to determine if there is an existing 14
discovery cache entry for the Local Device. If a discovery cache device 15
responds to the request, the Local Device may update the discovery 16
information and shall transition to the Registered state. 17
• The client employs the radius limited message System Server Discovery 18
request, broadcast to all devices for which macRxOnWhenIdle = TRUE, to 19
locate a Primary Discovery Cache device within the radius supplied by the 20
request. 21
22
• Discovered: 23
• The client employs the unicast Discovery store request directed to the 24
Discovery Cache device containing the sizes of the discovery cache 25
information it wishes to store. The Discovery Cache Device will respond 26
with a SUCCESS, INSUFFICIENT_SPACE or NOT_SUPPORTED. 27
28
• Registered: 29
• This state is reached when a SUCCESS status was received by the client 30
from the Discovery Cache device from a previous Discovery cache request 31
or the Find Node Cache request found a pre-existing discovery cache entry. 32
The client must now upload its discovery information using the Node 33
Descriptor store request, Power Descriptor store request, Active Endpoint 34
store request, and Simple Descriptor store requests to enable the Primary 35
Discovery Cache device to fully respond on its behalf. 36
37
• Unregistered: 38
• The client (or any other device) may request to be unregistered. The Remove 39
Node Cache request removes the device from the Primary Discovery Cache 40
device. The Primary Cache Device responds to device and service discovery 41
requests for all registered clients it supports. The Find Node Cache request is 42
employed by clients wanting to locate the device and service discovery 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 215

location for a given device of interest. Note that if the discovery information
is held by the device itself, that device must also respond to identify itself as 1
the repository of discovery information. See Figure 2.103 for details on state 2
machine processing for the Primary Discovery Cache device. 3
4
5
System_Server_Discovery_req 6
System_Server_Discovery_rsp 7
Until (STATUS) 8
STATUS is
SUCCESS Discovery_store_req 9
10
Discovery_store_rsp(STATUS)
11
Node_Desc_store_req
12
13
If STATUS is not SUCCESS Node_Desc_store_rsp(STATUS) 14
for any descriptor storage
request, then Repeat for: 15
Remove_node_cahe_req Power_Desc_store_req, 16
Active_EP_store_req, 17
Simple_Desc_store_req
18
19
End Device sleeps and
Primary Discovery Cache
20
handles any discovery 21
requests for the device. 22
End Device (client) Primary Discovery Cache
23
(server)
24
25
Figure 2.103 Primary Discovery Cache State Machine
26
27
2.5.2.2 Device and Service Discovery 28
This function shall support device and service discovery within a single PAN. 29
Additionally, for all ZigBee device types, this function shall perform the 30
following: 31
32
• Within each network employing sleeping ZigBee End Devices, some ZigBee 33
Routers (or the ZigBee Coordinator) may be designated as Primary Discovery 34
Cache Devices as described by their Node Descriptor. These Primary Cache 35
Devices are themselves discoverable and provide server services to upload and 36
store discovery information on behalf of sleeping ZigBee End Devices. 37
Additionally, the Primary Cache Devices respond to discovery requests on 38
behalf of the sleeping ZigBee End Devices. Each Primary Discovery Cache 39
Device shall be either a ZigBee Router or the ZigBee Coordinator. 40
• For ZigBee End Devices which intend to sleep as indicated 41
by:Config_Node_Power, Device and Service Discovery may manage upload 42
and storage of the NWK Address, IEEE Address, Active Endpoints, Simple 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
216 Application Layer Specification

Descriptors, Node Descriptor, and Power Descriptor onto a Primary Discovery


Cache device selected by the ZigBee End Device to permit device and service 1
discovery operations on these sleeping devices. 2
3
• For the ZigBee Coordinator and ZigBee Routers designated as Primary 4
Discovery Cache Devices, this function shall respond to discovery requests on 5
behalf of sleeping ZigBee End Devices who have registered and uploaded their 6
discovery information. 7
• For all ZigBee devices, Device and Service Discovery shall support device and 8
service discovery requests from other devices and permit generation of requests 9
from their local Application Objects. Note that Device and Service Discovery 10
services may be provided by the Primary Discovery Cache devices on behalf of 11
other ZigBee End Devices. In cases where the Primary Discovery Cache 12
Device is the target of the request, the NWKAddrOfInterest or Device of 13
Interest fields shall be filled in the request and/or response to differentiate the 14
target of the request from the device that is the target of discovery. The 15
following discovery features shall be supported: 16
17
• Device Discovery: 18
—Based on a unicast inquiry of a ZigBee Coordinator or ZigBee Router’s 19
IEEE address, the IEEE Address of the requested device plus, option- 20
ally, the NWK Addresses of all associated devices shall be returned. 21
22
—Based on a unicast inquiry of a ZigBee End Device’s IEEE address, the 23
IEEE Address of the requested device shall be returned. 24
25
—Based on a broadcast inquiry (of any broadcast address type) of a Zig- 26
Bee Coordinator or ZigBee Router’s NWK Address with a supplied 27
IEEE Address, the NWK Address of the requested device plus, option- 28
ally, the NWK Addresses of all associated devices shall be returned. 29
30
—Based on a broadcast inquiry (of any broadcast address type) of a Zig-
31
Bee End Device’s NWK Address with a supplied IEEE Address, the 32
NWK Address of the requested device shall be returned. The responding 33
device shall employ APS acknowledged service for the unicast response 34
to the broadcast inquiry. 35
• Service Discovery: Based on the following inputs, the corresponding 36
responses shall be supplied: 37
38
—NWK address plus Active Endpoint query type – Specified device shall 39
return the endpoint number of all applications residing in that device. 40
Should the list of active endpoints exceed the ASDU size and where 41
fragmentation is not supported on the server device, an extended version 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 217

of the query type is also provided to return the full list through multiple
requests. 1
2
—NWK address or broadcast address (of any broadcast address type) plus 3
Service Match including Profile ID and, optionally, Input and Output 4
Clusters – Specified device matches Profile ID with all active endpoints 5
to determine a match. If no input or output clusters are specified, the 6
endpoints that match the request are returned. If input and/or output 7
clusters are provided in the request, those are matched as well, and any 8
matches are provided in the response with the list of endpoints on the 9
10
device providing the match. The responding device shall employ APS
11
acknowledged service for the unicast response to the broadcast inquiry. 12
By convention, in cases where the application profile enumerates input 13
clusters and their response output clusters with the same cluster identi- 14
fier, the application profile shall list only the input cluster within the 15
Simple Descriptor for the purposes of Service Discovery. 16
17
—NWK address plus Node Descriptor or Power Descriptor query type –
18
Specified device shall return the Node or Power Descriptor for the 19
device. 20
—NWK address, Endpoint Number plus Simple Descriptor query type – 21
Specified address shall return the Simple Descriptor associated with that 22
Endpoint for the device. Should the list of input and/or output clusters 23
24
exceed the ASDU size capacity to return the Simple Descriptor in a sin-
25
gle packet an extended version of the query type is also provided to 26
return the full list through multiple requests. 27
—Optionally, NWK address plus Complex or User Descriptor query type 28
– If supported, specified address shall return the Complex or User 29
Descriptor for the device 30
31
2.5.2.3 Security Manager 32
33
This function determines whether security is enabled or disabled and, if enabled, 34
shall perform the following: 35
36
• Establish Key 37
• Transport Key 38
39
• Request Key 40
• Update Device 41
42
• Remove Device 43
• Switch Key 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
218 Application Layer Specification

• Authenticate Device
1
The Security Manager function addresses the Security Services Specification 2
(Chapter 4). Security Management, implemented by APSME primitive calls by 3
ZDO, performs the following: 4
• Contacts the Trust Center to obtain the Master Key between this device and the 5
Trust Center (step is omitted if this device is the Trust Center, the Master Key 6
with the Trust Center has been pre-configured, or the network is operating in 7
residential mode). This step employs the Transport Key primitive. 8
9
• Establishes a Link Key with the Trust Center. This step employs the APSME- 10
Establish-Key primitive (omitted in residential mode). 11
• Obtains the NWK Key from the Trust Center using secured communication 12
with the Trust Center (commercial mode). Alternatively, the NWK Key from 13
the Trust Center may be sent from the Trust Center using unsecured 14
communication (residential mode). This step employs the APSME- 15
TRANSPORT-KEY primitive. 16
17
• Establishes or transports Link Keys and master keys, as required, with specific 18
devices in the network identified as messaging destinations (commercial 19
mode). These steps employ the APSME-ESTABLISH-KEY, APSME- 20
TRANSPORT-KEY and/or APSME-REQUEST-KEY primitives. 21
• Informs the Trust Center of any devices that join the network using the 22
APSME-UPDATE-DEVICE primitives. This function is only performed if the 23
device is a ZigBee router. 24
25
• Permits devices to obtain keys from the Trust Center using the APSME- 26
REQUEST-KEY primitives. 27
• Permits the Trust Center to remove devices from the network using the 28
APSME-REMOVE-DEVICE primitives. 29
30
• Permits the Trust Center to switch the active network key using the APSME- 31
SWITCH-KEY primitives. 32
• Permits devices in the network to authenticate other devices using the APSME- 33
AUTHENTICATE primitives. 34
35
2.5.2.4 Network Manager 36
37
This function shall implement the ZigBee Coordinator, ZigBee Router, or ZigBee 38
End Device logical device types according to configuration settings established 39
either via a programmed application or during installation. If the device type is a 40
ZigBee Router or ZigBee End Device, this function shall provide the ability to 41
select an existing PAN to join and implement procedures which permit the device 42
to rejoin if network communication is lost. If the device type is a ZigBee 43
Coordinator or ZigBee Router, this function shall provide the ability to select an 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 219

unused channel for creation of a new PAN. Note that it is possible to deploy a
network without a device pre-designated as ZigBee Coordinator where the first 1
Full Function Device (FFD) activated assumes the role of ZigBee Coordinator. 2
The following description covers processing addressed by Network Management: 3
4
• Permits specification of a channel list for network scan procedures. Default is 5
to specify use of all channels in the selected band of operation. 6
• Manages network scan procedures to determine neighboring networks and the 7
identity of their ZigBee coordinators and routers. 8
9
• Permits selection of a channel to start a PAN (ZigBee Coordinator) or selection 10
of an existing PAN to join (ZigBee Router or ZigBee End Device). 11
• Supports orphaning and extended procedures to rejoin the network, including 12
support for intra_PAN portability. 13
14
• May support direct join. For ZigBee Coordinators and ZigBee Routers, a local 15
version of direct join may be supported to enable the device to join via the 16
orphaning or rejoin procedures. 17
• May support Management Entities that permit external network management. 18
19
• Detects and reports interference to support changing network channels. 20
• Manages network interference reporting and selection of a new channel for 21
network operation if interference exists on the initial channel if the particular 22
node is identified as the network manager for the overall PAN. 23
24
2.5.2.5 Binding Manager 25
26
The Binding Manager performs the following: 27
• Establishes resource size for the Binding Table. The size of this resource is 28
determined via a programmed application or via a configuration parameter 29
defined during installation. 30
31
• Processes bind requests for adding or deleting entries from the APS binding 32
table. 33
• Supports Bind and Unbind commands from external applications such as those 34
that may be hosted on a commissioning or network management tool to support 35
assisted binding. Bind and Unbind commands shall be supported via the 36
ZigBee Device Profile (see clause 2.4). 37
38
• For the ZigBee Coordinator, supports the End Device Bind that permits binding 39
on the basis of button presses or other manual means. 40
• Permits source devices to register with a primary binding table cache their 41
ability to hold their own binding table. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
220 Application Layer Specification

• Permits configuration tools to exchange one device for another in all the
binding table entries which refer to it. 1
2
• Permits the primary binding table cache to backup and recover individual bind 3
entries or the entire binding table or the table of source devices holding their 4
own binding tables. 5
6
2.5.2.6 Node Manager 7
For ZigBee Coordinators and ZigBee Routers, the Node Management function 8
performs the following: 9
10
• Permits remote management commands to perform network discovery. 11
• Provides remote management commands to retrieve the routing table. 12
13
• Provides remote management commands to retrieve the binding table. 14
• Provides a remote management command to have the device leave the network 15
or to direct that another device leave the network. 16
17
• Provides a remote management command to retrieve the LQI for neighbors of 18
the remote device. 19
• Provides a remote management command to Permit or disallow joining on 20
particular routers or to generally allow or disallow joining via the Trust Center. 21
22
2.5.2.7 Group Manager 23
24
The Group Manager performs the following: 25
• Provides for inclusion of application objects within the local device into groups 26
under application control. 27
28
• Provides for removal of application objects within the local device from group 29
membership under application control. 30
31
2.5.3 Layer Interface Description 32
33
Unlike other device descriptors for applications residing above Endpoints 1-240, 34
the ZigBee Device Objects (ZDO) interface to the APS via the APSME-SAP in 35
addition to the APSDE-SAP. ZDO communicates over Endpoint 0 using the 36
APSDE-SAP via Profiles like all other applications. The Profile used by ZDO is 37
the ZigBee Device Profile (See clause 2.4). ZDO frames shall not be fragmented. 38
39
ZigBee Device Objects shall employ Endpoint 0 as the source and destination 40
endpoint in any transmitted ZigBee Device Profile request frames, and shall 41
expect Endpoint 0 as the source and destination endpoint in any received response 42
frames. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 221

2.5.4 System Usage 1


2
3
Device and Service Device and Service 4
Discovery Object Discovery Object 5
Mandatory Mandatory 6
7
Mandatory Attributes Optional Attributes 8
(continued) 9
NWK_addr_rsp
10
IEEE_addr_rsp Discovery_cache_req 11
Node_Desc_rsp Discovery_cache_rsp 12
Active_EP_rsp Discovery_store_req 13
Match_Desc_rsp Discovery_store_rsp 14
Power_Desc_rsp 15
Node_Desc_store_req
16
Simple_Desc_rsp Node_Desc_store_rsp 17
Power_Desc_store_req 18
Optional Attributes Power_Desc_store_rsp 19
Active_EP_store_req 20
NWK_addr_req
21
IEEE_addr_req Active_EP_store_rsp
22
Node_Desc_req Simple_Desc_store_req 23
Power_Desc_req Simple_Desc_store_rsp 24
Simple_Desc_req Remove_node_cache_req 25
Remove_node_cache_rsp 26
Active_EP_req
27
Match_Desc_req Find_node_cache_req
28
Find_node_cache_rsp
Complex_Desc_req 29
Complex_Desc_rsp System_Server_ 30
Discovery req 31
User_Desc_req
System_Server_ 32
User_Desc_rsp Discovery_rsp
33
Device_annce Extended_Simple_
34
Desc req
User_Desc_set 35
Extended_Simple_
User_Desc_conf Desc_rsp
36
37
Extended_Active_
EP req 38
Extended_Active_ 39
EP_rsp 40
41
42
43
Figure 2.104 System Usage ZigBee Device Object Details 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
222 Application Layer Specification

11

Node Manager Object 1


Security Manager Object
Optional 2
Optional 3
Mandatory Attributes 4
Mandatory Attributes
5
Mgmt_Permit_Joining_rsp 6
7
8
9
Optional Attributes Optional Attributes 10
11
APSME-ESTABLISH-
Mgmt_NWK_Disc_req
KEY.request
12
Mgmt_NWK_Disc_rsp APSME-ESTABLISH-
13
Mgmt_Lqi_req KEY.indication 14
Mgmt_Lqi_rsp APSME-ESTABLISH- 15
Mgmt_Rtg_req
KEY.response 16
Mgmt_Rtg_rsp
APSME-ESTABLISH- 17
KEY.confirm
Mgmt_Bind_req
18
APSME-TRANSPORT-
Mgmt_Bind_rsp KEY.request
19
APSME-TRANSPORT-
20
Mgmt_Leave_req
KEY.indication 21
Mgmt_Leave_rsp
APSME-UPDATE- 22
Mgmt_Direct_Join_req DEVICE.request 23
Mgmt_Direct_Join_rsp APSME-UPDATE- 24
Mgmt_Cache_req DEVICE.indication
APSME-REMOVE-
25
Mgmt_Cache_rsp 26
DEVICE.request
Mgmt_NWK_Update_req APSME-REMOVE- 27
DEVICE.indication 28
Mgmt_Permit_Joining_req APSME-REQUEST- 29
KEY.request 30
Mgmt_NWK_Update_notify APSME-REQUEST- 31
KEY.indication
APSME-SWITCH-
32
KEY.request 33
APSME-SWITCH- 34
KEY.indication 35
APSME- 36
AUTHENTICATE.request 37
APSME- 38
AUTHENTICATE.confirm
APSME- 39
AUTHENTICATE.indication 40
41
Figure 2.105 System Usage ZigBee Device Object Details — Node Manager 42
Object and Security Manager Object 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 223

Node Manager Object 1


Security Manager Object
Optional
2
Optional 3
Mandatory Attributes 4
Mandatory Attributes
5
Mgmt_Permit_Joining_rsp 6
7
8
9
Optional Attributes
Optional Attributes 10
APSME-ESTABLISH-
11
Mgmt_NWK_Disc_req
KEY.request 12
Mgmt_NWK_Disc_rsp APSME-ESTABLISH- 13
Mgmt_Lqi_req KEY.indication
14
Mgmt_Lqi_rsp APSME-ESTABLISH-
KEY.response 15
Mgmt_Rtg_req
APSME-ESTABLISH- 16
Mgmt_Rtg_rsp KEY.confirm 17
Mgmt_Bind_req APSME-TRANSPORT- 18
Mgmt_Bind_rsp KEY.request 19
APSME-TRANSPORT-
Mgmt_Leave_req
KEY.indication
20
Mgmt_Leave_rsp
APSME-UPDATE- 21
Mgmt_Direct_Join_req DEVICE.request 22
Mgmt_Direct_Join_rsp APSME-UPDATE- 23
DEVICE.indication
Mgmt_Cache_req 24
APSME-REMOVE-
Mgmt_Cache_rsp
DEVICE.request 25
Mgmt_NWK_Update_req APSME-REMOVE-
26
DEVICE.indication 27
Mgmt_Permit_Joining_req APSME-REQUEST- 28
KEY.request 29
Mgmt_NWK_Update_notify APSME-REQUEST-
KEY.indication
30
APSME-SWITCH- 31
KEY.request 32
APSME-SWITCH- 33
KEY.indication
34
APSME- 35
AUTHENTICATE.request
36
APSME-
AUTHENTICATE.confirm 37
APSME- 38
AUTHENTICATE.indication
39
40
Figure 2.106 System Usage ZigBee Device Object Details — Binding 41
Manager Object and Network Manager Object 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
224 Application Layer Specification

1
Configuration Attributes
Group Manager Object 2
Optional Mandatory 3
4
Mandatory Attributes :Config_Node_Descriptor
5
:Config_Power_Descriptor
6
:Config_Simple_Descriptors
:Config_NWK_Mode_and_Params
7
:Config_NWK_Scan_Attempts
8
:Config_NWK_Time_btwn_Scans
9
Optional Attributes 10
Optional
11
APSME-ADD-
GROUP.request 12
:Config_Complex_Descriptor
APSME-ADD- 13
:Config_User_Descriptor
GROUP.confirm 14
:Config_Max_Bind
APSME-REMOVE- 15
GROUP.request :Config_Master_Key 16
APSME-REMOVE- :Config_NWK_Join_Direct_Addrs
GROUP.confirm 17
APSME-REMOVE-ALL-
:Config_Max_Assoc 18
GROUPS.request :Config_EndDev_Bind_Timeout 19
APSME-REMOVE-ALL- :Config_Permit_Join_Duration 20
GROUPS.confirm :Config_Nwk_Security_Level 21
:Config_Nwk_Secure_All_Frames 22
:Config_NWK_Leave_removeChildren 23
:Config_NWK_BroadcastDeliveryTime 24
:Config_NWK_TransactionPersistenceTim 25
:Config_NWK_indirectPollRate 26
:Config_NWK_Alt_protocol_version 27
28
29
30
Figure 2.107 System Usage ZigBee Device Object Details — Group Manager 31
Object and Configuration Attributes 32
33
2.5.5 Object Definition and Behavior 34
35
2.5.5.1 Object Overview 36
37
ZigBee Device Objects contain six Objects: 38
39
• Device and Service Discovery
40
• Network Manager 41
42
• Binding Manager
43
• Security Manager 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 225

• Node Manager
1
• Group Manager 2
Table 2.138 describes these ZigBee Device Objects. 3
4
Table 2.138 ZigBee Device Objects
5
Object Description 6
7
Name Status 8
:Device_and_Service M Handles device and service discovery. 9
_Discovery 10
11
:Network_Manager M Handles network activities such as network
discovery, leaving/joining a network, 12
resetting a network connection and creating 13
a network. 14
:Binding_Manager O Handles end device binding, binding and 15
unbinding activities. 16
17
:Security_Manager O Handles security services such as key
loading, key establishment, key transport
18
and authentication. 19
20
:Node_Manager O Handles management functions.
21
:Group Manager O Handles management of groups 22
23
2.5.5.2 Optional and Mandatory Objects and Attributes 24
25
Objects listed as Mandatory shall be present on all ZigBee devices. However, for 26
certain ZigBee logical types, Objects listed as Optional for all ZigBee devices 27
may be Mandatory in specific logical device types. For example, the NLME- 28
NETWORK-FORMATION.request within the Network_Manager object is in a 29
Mandatory object and is an Optional attribute, though the attribute is required for 30
ZigBee Coordinator logical device types. The introduction section of each Device 31
Object section will detail the support requirements for Objects and Attributes by 32
logical device type. 33
34
2.5.5.3 Security Key Usage 35
36
ZigBee Device Objects may employ security for packets created by ZigBee
37
Device Profile primitives. These application packets using APSDE on Endpoint 0
38
shall utilize the APSDE Security Service Provider interface like all other
39
Application Objects.
40
41
2.5.5.4 Public and Private Methods 42
Methods that are accessible to any endpoint application on the device are called 43
public methods. Private methods are only accessible to the Device Application on 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
226 Application Layer Specification

endpoint 0 and not to the end applications (which run on endpoints 1 through
240). 1
2
2.5.5.5 State Machine Functional Descriptions 3
4
2.5.5.5.1 ZigBee Coordinator 5
6
2.5.5.5.1.1 Initialization 7
8
The implementation shall set the startup-related IB parameters shown in Table 2.139 9
to values that reflect the desired startup behavior for the device. In particular, the 10
apsDesignatedCordinator attribute of the IB shall be set to TRUE. If the device 11
implements more than one option for ZigBee protocol version or stack profile, it shall 12
choose a single value for each and set nwkcProtocolVersion and nwkStackProfile 13
accordingly. Additionally, provision shall be made to provide configuration elements 14
to describe the Node Descriptor, Power Descriptor, Simple Descriptor for each active 15
endpoint and application plus the list of active endpoints. These configurations shall 16
be embodied in :Config_Node_Descriptor,:Config_Power_Descriptor, and 17
:Config_Simple_Descriptors. If the :Config_Node_Descriptor configuration object 18
indicates that this device is a Primary Discovery Cache device, the device shall be 19
configured to process server commands for the ZigBee Device Profile associated with 20
requests to the Primary Discovery Cache and shall operate according to the state 21
machine description provided in sub-clause 2.5.2.1. 22
If supported, provision shall be made to supply configuration elements for the 23
Complex Descriptor, User Descriptor, the maximum number of bind entries and 24
the master key. These elements shall be embodied in 25
:Config_Complex_Descriptor, :Config_User_Descriptor, :Config_Max_Bind and 26
:Config_Master_Key. 27
28
To start as a ZigBee coordinator, the device application shall execute the startup 29
procedure described in sub-clause 2.5.5.5.6.2 with startup parameters set as 30
described above. This should have the effect of executing the procedure for network 31
formation described in sub-clause 3.6.1.1. The device application shall set the 32
nwkSecurityLevel, nwkAllFresh, and nwkSecureAllFrames NIB attributes according 33
to the values established by convention within the Stack Profile employed by the 34
device. The device application shall check the return status via the NLME- 35
NETWORK-FORMATION.confirm to verify successful creation of the PAN. The 36
:Config_Permit_Join_Duration shall be set according to the default parameter value 37
supplied using the NLME-PERMIT-JOINING.request. Additionally, the 38
nwkNetworkBroadcastDeliveryTime and nwkTransactionPersistenceTime Network 39
Information Block parameters (see sub-clause 3.6.2) shall be set with 40
:Config_NWK_BroadcastDeliveryTime and 41
:Config_NWK_TransactionPersistenceTime respectively (see sub-clause 2.5.6). 42
Provision shall be made to ensure APS primitive calls from the end applications 43
over EP 1 through EP 240 return appropriate error status values prior to 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 227

completion of the Initialization state by ZigBee Device Objects and transition to


the normal operating state. 1
2
2.5.5.5.1.2 Normal Operating State 3
4
In this state, the ZigBee Coordinator shall process the list of direct joined 5
addresses in :Config_NWK_Join_Direct_Addrs by issuing an NLME-DIRECT- 6
JOIN.request for each included address in the list. Processing of the direct joined 7
addresses shall employ the :Config_Max_Assoc parameter in evaluating whether 8
to successfully process a direct joined address within 9
:Config_NWK_Join_Direct_Addrs. 10
The ZigBee coordinator shall allow other devices to join the network based on the 11
configuration items :Config_Permit_Join_Duration and :Config_Max_Assoc. 12
When a new device joins the network, the device application shall be informed via 13
the NLME-JOIN.indication. Should the device be admitted to the PAN, the 14
ZigBee coordinator shall indicate this via the NLME-JOIN.confirm with 15
SUCCESS status. 16
17
The ZigBee coordinator shall respond to any device discovery or service 18
discovery operations requested of its own device, and if it is designated as a 19
Primary Discovery Cache device, shall also respond on behalf of registered 20
devices that have stored discovery information. The device application shall also 21
ensure that the number of binding entries does not exceed the :Config_Max_Bind 22
attribute. 23
The ZigBee coordinator shall support the NLME-PERMIT-JOINING.request and 24
NLME-PERMIT-JOINING.confirm to permit application control of network join 25
processing. 26
27
The ZigBee coordinator shall support the NLME-LEAVE.request and NLME- 28
LEAVE.indication employing the :Config_NWK_Leave_removeChildren 29
attribute where appropriate to permit removal of associated devices under 30
application control. Conditions that lead to removal of associated devices may 31
include lack of security credentials, removal of the device via a privileged 32
application or detection of exception. When a ZigBee end device is asked to leave 33
the network, the ReuseAddress parameter of the NLME-LEAVE.request primitive 34
should have a value of TRUE indicating that the NWK layer may give the address 35
formerly in use by the leaving device to another end device that joins 36
subsequently. 37
The ZigBee coordinator shall maintain a list of currently associated devices and 38
facilitate support of orphan scan and rejoin processing to enable previously 39
associated devices to rejoin the network. The ZigBee coordinator may support the 40
ability for devices to be directly included in the network via the NLME-DIRECT- 41
JOIN.request and NLME-DIRECT-JOIN.confirm. This feature shall permit lists 42
of ZigBee IEEE addresses to be provided to the ZigBee coordinator and for those 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
228 Application Layer Specification

addresses to be included as previously associated devices. It shall be possible for


ZigBee devices with those addresses to directly join the network via orphaning or 1
rejoin procedures rather than associating directly. 2
3
The ZigBee coordinator shall support the NLME-NWK-STATUS.indication and 4
process those notifications per clause 3.2.2.30. 5
The ZigBee coordinator shall process End_Device_Bind_req from ZigBee 6
Routers and ZigBee End Devices. Upon receipt of an End_Device_Bind_req, the 7
ZigBee Coordinator shall use the :Config_EndDev_Bind_Timeout value in the 8
attribute and await a second End_Device_Bind_req. Should the second indication 9
arrive within the timeout period, the ZigBee coordinator shall match the Profile 10
ID in the two indications. If the Profile IDs in the two indications do not match, an 11
appropriate error status is returned to each device via End_Device_Bind_rsp. 12
Should the Profile IDs match, the ZigBee Coordinator shall match the 13
AppInClusterLists and AppOutClusterLists in the two indications. Cluster IDs in 14
the AppInClusterList of the first indication which match Cluster IDs in the 15
AppOutClusterList of the second indication shall be saved in a list for inclusion in 16
the resulting Bind_req notifying the devices of the match. 17
18
The ZigBee coordinator shall process Device_annce messages from other ZigBee 19
devices. Upon receipt of a Device_annce where nwkUseTreeRouting is TRUE, the 20
ZigBee coordinator shall check all internal tables holding 64-bit IEEE addresses 21
for devices within the PAN for a match with the address supplied in the 22
Device_annce message. If a match is detected, the ZigBee coordinator shall 23
update its nwkAddressMap attribute of the NIB corresponding to the matched 64- 24
bit IEEE address to reflect the updated 16-bit NWK address contained in the 25
Device_annce. Upon receipt of a Device_annce where nwkUseTreeRouting is 26
FALSE, the ZigBee Coordinator shall employ the address conflict resolution 27
procedure detailed in sub-clause 3.6.9. 28
The ZigBee coordinator may generate APSME-AUTHENTICATE.requests under 29
application control from other application objects, and may process and respond 30
to APSME-AUTHENTICATE.indications from other devices. The ZigBee 31
coordinator shall supply APSME-AUTHENTICATE.confirms to application 32
objects whose requests have been processed. 33
34
2.5.5.5.1.3 Trust Center Operation 35
36
The network device pointed to by the address in apsTrustCenterAddress shall 37
function as the Trust Center when security is enabled on the network. 38
The Trust Center operation is defined within sub-clause 4.6.2. 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 229

2.5.5.5.2 ZigBee Router


1
2.5.5.5.2.1 Initialization 2
3
The implementation shall set the startup-related IB parameters shown in Table 2.139 4
to values that reflect the desired startup behavior for the device. In particular, the 5
apsDesignatedCordinator attribute of the IB shall be set to FALSE. If the 6
:Config_Node_Descriptor configuration object indicates that this device is a 7
Primary Discovery Cache device, the device shall be configured to process server 8
commands for the ZigBee Device Profile associated with requests to the Primary 9
Discovery Cache and shall operate according to the state machine description 10
provided in sub-clause 2.5.2.1. 11
12
If supported, provision shall be made to supply configuration elements for the
13
Complex Descriptor, User Descriptor, the maximum number of bind entries, and
14
the master key. These elements shall be embodied in
15
:Config_Complex_Descriptor, :Config_User_Descriptor, :Config_Max_Bind and
16
:Config_Master_Key.
17
To start as a ZigBee router, the device application shall execute the startup 18
procedure described in sub-clause 2.5.5.5.6.2 with startup parameters set as 19
described above. This should have the effect of executing either the procedure for 20
network rejoin described in sub-clause 3.6.1.4.2 or else the full procedure for 21
network join through MAC association described in sub-clause 3.6.1.4.1. The 22
NLME-NETWORK-DISCOVERY.request procedure shall be implemented 23
:Config_NWK_Scan_Attempts, each separated in time by 24
:Config_NWK_Time_btwn_Scans. The purpose of repeating the NLME- 25
NETWORK-DISCOVERY.request is to provide a more accurate neighbor list and 26
associated link quality indications to the NWK layer. Specification of the 27
algorithm for selection of the PAN shall be left to the profile description and may 28
include use of the Extended PAN ID, operational mode of the network, identity of 29
the ZigBee Router or Coordinator identified on the PAN, depth of the ZigBee 30
Router on the PAN from the ZigBee Coordinator for the PAN, capacity of the 31
ZigBee Router or Coordinator, the routing cost, or the Protocol Version Number 32
(these parameters are supplied by the NLME-NETWORK-DISCOVERY.confirm 33
and the beacon payload). 34
35
The ZigBee router may join networks employing the current protocol version
36
number or may join networks employing a previous protocol version number,
37
under application control, if backward compatibility is supported in the device. A
38
single ZigBee PAN shall consist of devices employing only a single protocol
39
version number (networks with devices employing different protocol version
40
numbers and frame formats within the same PAN are not permitted). An optional
41
configuration attribute, :Config_NWK_alt_protocol_version, provides the
42
protocol version numbers which the device may choose to employ other than the
43
current protocol version number. Once the ZigBee router chooses a PAN and a
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
230 Application Layer Specification

specific protocol version number, it shall employ that protocol version number as
its nwkcProtocolVersion. Additionally, the ZigBee router shall then adhere to all 1
frame formats and processing rules supplied by the version of the ZigBee 2
Specification employing that protocol version number. 3
4
The :Config_Permit_Join_Duration shall be set according to the default parameter 5
value supplied using NLME-PERMIT-JOINING.request. The router shall support 6
the NLME-START-ROUTER.request and NLME-START-ROUTER.confirm to 7
begin operations as a router within the PAN it has joined. Additionally, the 8
nwkNetworkBroadcastDeliveryTime and nwkTransactionPersistenceTime 9
Network Information Block parameters (see sub-clause 3.6.2) shall be set with 10
:Config_NWK_BroadcastDeliveryTime and 11
:Config_NWK_TransactionPersistenceTime respectively (see sub-clause 2.5.6). 12
Provision shall be made to ensure APS primitive calls from the end applications 13
over EP 1 through EP 240 return appropriate error status values prior to 14
completion of the Initialization state by ZigBee Device Objects and transition to 15
the normal operating state. 16
17
If the network has security enabled, the device shall wait to be authenticated by 18
the Trust Center, and for successful acquisition of the NWK key to start 19
functioning as a router in the network. See sub-clause 4.6.2 for details on Trust 20
Center operations. 21
The device application shall set the nwkSecurityLevel and nwkSecureAllFrames 22
NIB attributes to the values used in the network and begin functioning as a router 23
using NLME-START-ROUTER.req. 24
25
2.5.5.5.2.2 Normal Operating State 26
27
In this state, the ZigBee router shall allow other devices to join the network based 28
on the configuration items :Config_Permit_Join_Duration and 29
:Config_Max_Assoc. When a new device joins the network, the device 30
application shall be informed via the NLME-JOIN.indication attribute. Should the 31
device be admitted to the PAN, the ZigBee router shall indicate this via the 32
NLME-JOIN.confirm with SUCCESS status. If security is enabled on the 33
network, the device application shall inform the Trust Center via the APSME- 34
UPDATE-DEVICE. request. 35
Orphan indications for which this device is not the parent are notified to the ZDO 36
from the NWK layer by receipt of an NLME-JOIN.indication primitive with 37
parameter IsParent set to value FALSE. The mechanism by which this is handled 38
is described in 2.5.5.5.4. 39
40
The ZigBee router shall respond to any device discovery or service discovery 41
operations requested of its own device, and if it is designated as a Primary 42
Discovery Cache device, shall also respond on behalf of registered devices that 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 231

have stored discovery information. The device application shall also ensure that
the number of binding entries does not exceed the :Config_Max_Bind attribute. 1
2
If security is supported operating in commercial mode, the ZigBee router shall 3
support the :Config_Master_Key and shall employ the Master Key in key 4
establishment procedures for Link Keys. Upon presentation of a remote 5
destination address requiring secure communications, the ZigBee router shall 6
support APSME-ESTABLISH-KEY.request to establish a link key with the 7
remote device and APSME-ESTABLISH-KEY.indication to present the request to 8
the destination and shall support APSME-ESTABLISH-KEY.confirm and 9
APSME-ESTABLISH-KEY.response to complete the key establishment of the 10
Link Key. The ZigBee router shall provide the ability to store Link Keys for 11
known destinations requiring secure communications and shall manage key 12
storage of Link Keys. The ZigBee router shall support APSME-TRANSPORT- 13
KEY.indication to receive keys from the Trust Center. 14
If security is supported operating in commercial or residential modes, the ZigBee 15
router shall request the Trust Center to update its NWK key via the APSME- 16
REQUEST-KEY.request. 17
18
The ZigBee router shall support the NLME-PERMIT-JOINING.request and 19
NLME-PERMIT-JOINING.confirm to permit application control of network join 20
processing. 21
The ZigBee router shall support the NLME-NWK-STATUS.indication and 22
process those notifications per sub-clause 3.2.2.30. 23
24
The ZigBee router shall support the NLME-LEAVE.request and NLME- 25
LEAVE.confirm employing the :Config_NWK_Leave_removeChildren attribute 26
where appropriate to permit removal of associated devices under application 27
control. Conditions that lead to removal of associated devices may include lack of 28
security credentials, removal of the device via a privileged application or 29
detection of exception. When a ZigBee end device is asked to leave the network, 30
the ReuseAddress parameter of the NLME-LEAVE.request primitive should have 31
a value of TRUE indicating that the NWK layer may give the address formerly in 32
use by the leaving device to another end device that joins subsequently. 33
The ZigBee router shall process Device_annce messages from other ZigBee 34
devices. Upon receipt of a Device_annce where nwkUseTreeRouting is TRUE, the 35
ZigBee router shall check all internal tables holding 64-bit IEEE addresses for 36
devices within the PAN for a match with the address supplied in the Device_annce 37
message. If a match is detected, the ZigBee router shall update its 38
nwkAddressMap of the NIB corresponding to the matched 64-bit IEEE address to 39
reflect the updated 16-bit NWK address contained in the Device_annce. Upon 40
receipt of a Device_annce where nwkUseTreeRouting is FALSE, the ZigBee 41
Router shall employ the address conflict resolution procedure detailed in sub- 42
clause 3.6.9. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
232 Application Layer Specification

The ZigBee router shall maintain a list of currently associated devices and
facilitate support of orphan scan and rejoin processing to enable previously 1
associated devices to rejoin the network. 2
3
The ZigBee router may generate APSME-AUTHENTICATE.requests under 4
application control from other application objects and may process and respond to 5
APSME-AUTHENTICATE.indications from other devices. The ZigBee router 6
shall supply APSME-AUTHENTICATE.confirms to application objects whose 7
requests have been processed. 8
The ZigBee router may decide it has lost contact with the network it was joined to. 9
In this situation, the router should conduct an active scan to find the network. If 10
the network is found more than once the router should attempt to rejoin where 11
there is a more recent value of nwkUpdateId in the beacon payload. 12
13
2.5.5.5.3 Binding Table Cache Operation 14
Any router (including the coordinator) may be designated as either a primary 15
binding table cache or a backup binding table cache. 16
17
It shall respond to the System_Server_Discovery_req primitive to enable other 18
devices to discover it and use its facilities. 19
A primary binding table cache shall maintain a binding table and a table of 20
devices registered to cache their binding tables. 21
22
A primary binding table cache shall respond to the Bind_Register_req and 23
Replace_Device_req primitives described in clause 2.4.3.2. 24
If a backup binding table cache is available, a primary binding table cache shall 25
use the additional bind management primitives to backup and restore its binding 26
table and its table of source binding devices. 27
28
A backup binding table cache shall maintain a backup of the binding table and 29
table of registered binding devices for one or more primary binding table caches. 30
It shall support the bind management primitives for backup and restore of these 31
tables. 32
2.5.5.5.4 Operations to Support Intra-PAN Portability 33
34
35
2.5.5.5.4.1 Overview
36
The operations described in this section are carried out by ZigBee Coordinator 37
and ZigBee Router Devices for support of intra-PAN portability. 38
39
The main steps are summarized as follows:- 40
• Detect the problem - The ZDO of the moved device is notified of 41
acknowledgement failures via the NLME-NWK-STATUS.indication 42
primitive, and identifies a problem. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 233

• Carry out the NWK layer rejoin procedure - The ZDO of a moved ZED
initiates this process using the NLME-JOIN.request primitive, either through a 1
secured or un-secured rejoining procedure. The NWK rejoin procedures closely 2
mirror the MAC association procedure. Note that ZigBee Routers shall also 3
carry out this procedure periodically if they find that they are no longer in 4
contact with the Trust Center. 5
6
• Security verification - Secured and unsecured protocol steps are described to 7
ensure that the orphaned device should really be accepted. (See 8
clause 2.5.5.5.4.2.) 9
• Inform the rest of the network - when a device changes parents the steps to 10
complete address conflict detection in sub-clause 3.6.1.9 must be completed. 11
These actions also serve to notify the old parent that the End Device has 12
changed parents.7 13
14
These steps are described in detail in the subsections below. The mechanism is 15
illustrated for secured rejoin of a ZED in Figure 2.108, unsecured rejoin of a ZED 16
in Figure 2.109, and unsecured rejoin of a ZR in Figure 2.110 respectively. Note 17
that the NWK and SEC sections on secured and unsecured rejoin (sub-clauses 18
3.2.2.11, 3.2.2.12, 3.2.2.13, 3.6.1.4 and 4.6.3) shall be the authoritative text for 19
these procedures. The diagrams in this section are provided for illustrative 20
purposes only. 21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
7. CCB #833 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
234 Application Layer Specification

New New
Old parent
Child’s Child’s
parent’s parent’s
Trust 1
NWK ZDO Centre
NWK ZDO 2
3
4
NO_ACK (x 12)
5
ROUTE-ERROR. 6
indication
7
Optional active scan. Select parent, eg: by
EPID. If rejoin fails then retry later.
8
9
JOIN.request
(RejoinNetwork=2) 10
Rejoin request 11
(secured at NWK layer with NWK key,
from IEEE address)
JOIN.indication
(secured rejoin)
12
Rejoin response (secured at NWK layer
13
with NWK key, to IEEE address, includes 14
JOIN.confirm
(SUCCESS)
short address)
15
16
Entity authentication [if required] 17
Device_annce 18
(if short address changed) Device_annce
19
20
21
Figure 2.108 Portability Message Sequence Chart: ZED Secured Rejoin 22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 235

New New
Old parent
Child’s Child’s
parent’s parent’s
Trust 1
NWK ZDO Centre
NWK ZDO 2
3
4
NO_ACK (x12)
5
ROUTE-ERROR. 6
indication
7
Optional active scan. Select parent, eg: by 8
EPID. If rejoin fails then retry later.
9
JOIN.request
(RejoinNetwork=2)
10
Rejoin request 11
(unsecured, from IEEE address) JOIN.indication
Update device
12
Rejoin response (unsecured, to IEEE (unsecured
address, includes short address) rejoin) 13
Key transport
JOIN.confirm
(NWK key) 14
(SUCCESS)
SET and GET Alternatively 15
(relationship) Remove device.
Key transport (NWK key, unsecured at 16
NWK layer) 17
Entity authentication [if required]
18
Device_annce
Device_annce
19
(if short address changed)
20
21
Figure 2.109 Portability Message Sequence Chart: ZED Unsecured Rejoin 22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
236 Application Layer Specification

ZR1’s ZR1’s ZR2’s ZR2’s Trust 1


NWK ZDO NWK ZDO Centre 2
3
Some message (eg: a broadcast MANY-TO-ONE-ROUTING update) 4
5
If we haven’t heard any message from the 6
trust centre for timeout period T (set by 7
stack profile), then carry out an active scan.
Note each neighbor that indicates in its 8
beacon that it can hear the TC. Select one 9
(eg: by EPID). If rejoin fails then retry later. 10
11
JOIN.request
(RejoinNetwork=2) 12
Rejoin request (unsecured, from IEEE 13
address, include existing short address) JOIN.indication 14
Rejoin response Update device
(unsecured 15
(unsecured, to IEEE address) rejoin)
JOIN.confirm
Key transport 16
(SUCCESS)
(NWK key) 17
SET and GET Alternatively
(relationship) Remove device. 18
Key transport (NWK key, unsecured at 19
NWK layer) 20
Entity authentication [if required]
21
22
23
24
25
Figure 2.110 Portability Message Sequence Chart: ZR Unsecured Rejoin 26
27
2.5.5.5.4.2 Description of Operations for Security Verification 28
As for MAC association, a ZigBee Coordinator or ZigBee Router device is 29
informed of a rejoined device when the NLME issues an NLME-JOIN.indication 30
primitive. This shall be handed in the same way as for an association indication, 31
except that for a secured rejoin the update device and key transport step. 32
33
Full network operation shall not be permitted until the verification steps described 34
below have been carried out. 35
Measures shall be taken by a newly (re-)joined node and by its new parent to 36
verify that it is really allowed to be on this network. Two cases are envisioned: 37
38
• One or the other is not implemented according to this specification, and should 39
not have joined. The measures described here allow both sides to revoke the 40
join in this case. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 237

• One or the other device is a compromised/hacked device. In the case that


security is enabled, the measures in sub-clause 4.6.3.6 are additionally applied 1
so that an unauthorized join is revoked. 2
3
This verification is carried out using existing commands. sub-clause 2.5.5.5.4.3 4
below describes the transmission of a Device_annce command to the new parent. 5
The new parent shall check that this or some other message is correctly formed 6
and contains the addressing fields corresponding to the orphaned device. If 7
security is enabled, then this command shall be secured with the network key, and 8
the new parent shall verify that all security processing is carried out correctly. If 9
all these checks succeed then the orphaned device shall become joined to the 10
network. Otherwise, it shall not become joined to the network at this time. As 11
normal, messages sent from a device not joined to the network shall not be 12
forwarded across the network, and commands shall not be carried out. 13
Accordingly, the orphaned device shall only become joined to the network once it 14
receives at least one correctly formed ZigBee message from the new parent. If 15
security is enabled, this message must be secured with the network key and all 16
security processing must be carried out correctly. If messages cannot be 17
exchanged in protocol, then the orphaned device shall not become joined to the 18
network at this time. 19
20
2.5.5.5.4.3 Description of Operations for Informing the Rest of the Network 21
If the ZigBee End Device rejoins a new parent using the orphaning of rejoin 22
process it shall complete the address conflict process in sub-clause 3.6.1.9.8 Upon 23
receiving the Device_annce, all devices shall check their internal tables holding 24
64-bit IEEE addresses for devices within the PAN for a match with the address 25
supplied in the Device_annce message. If a match is detected, the device shall 26
update the nwkAddressMap attribute of the NIB corresponding to the matched 64- 27
bit IEEE address to reflect the updated 16-bit NWK address contained in the 28
Device_annce. All devices shall use the NLME-SET and NLME-GET primitives 29
to update the nwkNeighborTable in the NWK NIB. The previous parent of this 30
ZED shall remove the ZED as one of its children by changing the Relationship 31
field of the nwkNeighborTable to 0x04, “previous child.” Note that any unicast 32
message sent to an address with this status shall result in an NLME-NWK- 33
STATUS.indication primitive with status code of “Target Device Unavailable”, 34
(see sub-clause 3.2.2.30). If nwkUseTreeRouting is TRUE, address conflict 35
detection is not provided and parent devices are not permitted, following intra- 36
PAN portability, to remove devices or any other operation that reissue a short 37
address for use by a child with a different IEEE address. Alternatively, if 38
nwkUseTreeRouting is FALSE, address conflict detection is provided, however, 39
devices will generally keep their existing NWK addresses during the intra-PAN 40
portability procedure. Also, if the NWK address has changed during the intra- 41
42
43
8. CCB #833 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
238 Application Layer Specification

PAN portability procedure, the ZDO shall arrange that any IEEE address to short
address mappings which have become known to applications running on this 1
device be updated. This behavior is mandatory, but the mechanism by which it is 2
achieved is outside the scope of this specification. 3
4
2.5.5.5.5 ZigBee End Device 5
6
2.5.5.5.5.1 Initialization 7
8
The implementation shall set the startup-related IB parameters shown in Table 2.139
9
to values that reflect the desired startup behavior for the device. In particular, the
10
apsDesignatedCordinator attribute of the IB shall be set to FALSE.
11
If supported, provision shall be made to supply configuration elements for the 12
Complex Descriptor, User Descriptor, the maximum number of bind entries, and 13
the master key. These elements shall be embodied in 14
:Config_Complex_Descriptor, :Config_User_Descriptor, :Config_Max_Bind, and 15
:Config_Master_Key. If the device application set the NLME-JOIN 16
RxOnWhenIdle parameter to FALSE, the end device shall utilize the procedure 17
described in sub-clause 2.5.2.1 to discover a Primary Discovery Cache device, 18
register with it, and to successfully upload its device and service discovery 19
information. To facilitate the process of uploading discovery information to the 20
Primary Discovery Cache device, the local device may temporarily increase its 21
polling rate with its parent. Prior to registering with any Primary Discovery Cache 22
device, the end device shall utilize the Find Node Cache request to ensure it has 23
not previously registered with any other Primary Discovery Cache device. If a 24
server response indicates the end device has a previous registration, the end 25
device shall update its discovery cache information on that Primary Discovery 26
Cache device or shall remove its discovery cache information from that previous 27
registration and create a new registration. 28
29
To start as a ZigBee end device, the device application shall execute the startup
30
procedure described in sub-clause 2.5.5.5.6.2 with startup parameters set as
31
described above. This should have the effect of executing either the procedure for
32
network rejoin described in sub-clause 3.6.1.4.2 or else the full procedure for
33
network join through MAC association described in sub-clause 3.6.1.4.1. The
34
NLME-NETWORK-DISCOVERY.request procedure shall be implemented
35
:Config_NWK_Scan_Attempts, each separated in time by
36
:Config_NWK_Time_btwn_Scans. The purpose of repeating the NLME-
37
NETWORK-DISCOVERY.request is to provide a more accurate neighbor list and
38
associated link quality indications to the NWK layer. Specification of the
39
algorithm for selection of the PAN shall be left to the profile description and may
40
include use of the Extended PAN ID, operational mode of the network, identity of
41
the ZigBee Router or Coordinator identified on the PAN, depth of the ZigBee
42
Router on the PAN from the ZigBee Coordinator for the PAN, capacity of the
43
ZigBee Router or Coordinator, the routing cost, or the Protocol Version Number
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 239

(these parameters are supplied by the NLME-NETWORK-DISCOVERY.confirm


and the beacon payload). 1
2
The ZigBee end device may join networks employing the current protocol version 3
number or may join networks employing a previous protocol version number, 4
under application control, if backward compatibility is supported in the device. A 5
single ZigBee PAN shall consist of devices employing only a single protocol 6
version number (networks with devices employing different protocol version 7
numbers and frame formats within the same PAN are not permitted). An optional 8
configuration attribute, :Config_NWK_alt_protocol_version, provides the 9
protocol version numbers which the device may choose to employ other than the 10
current protocol version number. Once the ZigBee end device chooses a PAN and 11
a specific protocol version number, it shall employ that protocol version number 12
as its nwkcProtocolVersion. Additionally, the ZigBee end device shall then adhere 13
to all frame formats and processing rules supplied by the version of the ZigBee 14
Specification employing that protocol version number. 15
If the device application sets the NLME-JOIN RxOnWhenIdle parameter to 16
FALSE, the :Config_NWK_indirectPollRate shall be used to determine the 17
polling rate for indirect message requests. The :Config_NWK_indirectPollRate 18
shall be set according to the value established by the application profile(s) 19
supported on the device. Once polling for indirect message requests is initiated, if 20
communications failure with the parent is detected determined by failure of 21
indirect message requests :Config_Parent_Link_Threshold_Retry consecutive 22
attempts, the device application shall employ the network rejoin procedure. 23
24
Once the End Device has successfully joined a network, the device shall issue a 25
Device_annce providing its 64-bit IEEE address and 16-bit NWK address. 26
Provision shall be made to ensure APS primitive calls from the end applications 27
over EP 1 through EP 240 return appropriate error status values prior to 28
completion of the Initialization state by ZigBee Device Objects and transition to 29
the normal operating state. 30
31
If the network has security enabled, the device shall wait to be authenticated by 32
the Trust Center and for successful acquisition of the NWK key to start 33
functioning as an end device in the network. See sub-clause 4.6.2 for details on 34
Trust Center operations. 35
36
2.5.5.5.5.2 Normal Operating State 37
If the device application set the NLME-JOIN RxOnWhenIdle parameter to 38
FALSE, the :Config_NWK_indirectPollRate shall be used to poll the parent for 39
indirect transmissions while in the normal operating state. While a fragmented 40
message is being received, the device may temporarily increase its polling rate, 41
and shall ensure that it polls its parent at least once every 42
macTransactionPersistenceTime seconds. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
240 Application Layer Specification

The ZigBee end device shall respond to any device discovery or service discovery
operations requested of its own device using the attributes described in sub- 1
clause 2.5.4. 2
3
If security is enabled operating in commercial mode, the ZigBee end device shall 4
support the :Config_Master_Key and shall employ the Master Key in key 5
establishment procedures for Link Keys. Upon presentation of a remote 6
destination address requiring secure communications, the ZigBee end device shall 7
support APSME-ESTABLISH-KEY.request to establish a link key with the 8
remote device, and support APSME-ESTABLISH-KEY.indication to present the 9
request to the destination, and shall support APSME-ESTABLISH-KEY.confirm 10
and APSME-ESTABLISH-KEY.response to complete the key establishment of 11
the Link Key. The ZigBee end device shall provide the ability to store Link Keys 12
for known destinations requiring secure communications and shall manage key 13
storage of Link Keys. The ZigBee end device shall support APSME- 14
TRANSPORT-KEY.indication to receive keys from the Trust Center. 15
If security is enabled operating in commercial mode, the ZigBee end device shall 16
request the Trust Center to update its NWK key via the APSME-REQUEST- 17
KEY.request. 18
19
The ZigBee End Device shall process Device_annce messages from other ZigBee 20
devices. Upon receipt of a Device_annce where nwkUseTreeRouting is TRUE, the 21
ZigBee End Device shall check all internal tables holding 64-bit IEEE addresses 22
for devices within the PAN for a match with the address supplied in the 23
Device_annce message. If a match is detected, the ZigBee End Device shall 24
update the nwkAddressMap of the NIB corresponding to the matched 64-bit IEEE 25
address to reflect the updated 16-bit NWK address contained in the 26
Device_annce.9 27
The ZigBee End Device shall process the NLME-NWK-STATUS.indication sent 28
from the NWK layer. If the error code equals to 0x09 (Parent Link Failure), the 29
ZED will update its failure counter maintained in ZDO. If the value of the failure 30
counter is smaller than the :Config_Parent_Link_Retry_Threshold attribute, the 31
ZED may decide to issue further commands to attempt to communicate with the 32
parent node, depending on the application of the ZED. If the value of the failure 33
counter exceeds the :Config_Parent_Link_Retry_Threshold attribute, the ZED 34
shall then prepare to start the rejoin process. Note that implementers may 35
optionally use a more accurate time-windowed scheme to identify a link failure. 36
37
The rejoin process mirrors the MAC association process very closely, however, a 38
device is permitted to rejoin a parent that is not accepting new associations. The 39
ZDO may use the NLME-NETWORK-DISCOVERY.request primitive to detect 40
potential alternative parents, and in order to optimize recovery latency and 41
42
43
9. CCB #842 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 241

reliability, shall select an appropriate new parent based on the following


information from that device's beacon: 1
2
• PAN ID 3
• EPID (Extended PAN ID) 4
5
• Channel 6
• Signal strength 7
8
• Whether the potential parent indicates that it is currently able to communicate 9
with its Trust Center 10
• Whether this device has recently failed to join this parent, or this network 11
12
Once a potential parent has been selected, the ZDO shall issue an NLME- 13
JOIN.request primitive with RejoinNetwork set to 0x02. 14
The start time of the rejoin process is determined by the time the last NLME- 15
JOIN.request primitive was sent and by the attribute :Config_Rejoin_Interval. 16
Only if the interval between the current and the previous NLME-JOIN.request 17
sent time is longer than the :Config_Rejoin_Interval shall a new NLME- 18
JOIN.request primitive be sent. The application may want to gradually increase 19
the :Config_Rejoin_Interval if a certain number of retries have been done (or a 20
certain period of time has passed) but none of them were successful. The 21
:Config_Rejoin_Interval should not exceed the :Config_Max_Rejoin_Interval. 22
Every time an NLME-JOIN.confirm has been successfully received, the ZDO 23
shall reset its failure counter to zero and the :Config_Rejoin_Interval attribute to 24
its initial value. The choice of the default initial value and the algorithm of 25
increasing the rejoin interval shall be determined by the application, and is out of 26
the scope of this document. 27
28
If the ZigBee End Device rejoins a new parent using the rejoin process, it shall 29
complete the address conflict process in sub-clause 3.6.1.9.10 30
The ZigBee end device may generate APSME-AUTHENTICATE.requests under 31
application control from other application objects and may process and respond to 32
APSME-AUTHENTICATE.indications from other devices. The ZigBee end 33
device shall supply APSME-AUTHENTICATE.confirms to application objects 34
whose requests have been processed. 35
36
2.5.5.5.6 Support for Commissioning Applications 37
ZigBee devices in the field will need commissioning, and it will be up to 38
developers to provide applications that perform such commissioning. There is a 39
risk that applications from different vendors will work differently, thereby 40
diminishing the ability of ZigBee devices from different vendors to operate 41
42
43
10. CCB #833 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
242 Application Layer Specification

seamlessly on the same network. As a partial solution to this problem, this sub-
clause lists a common set of configuration parameters for ZigBee devices and 1
outlines a common procedure for devices to use at start-up time. The other critical 2
component of the solution is a common set of commissioning protocols and 3
procedures, which are outside the scope of this document. 4
5
2.5.5.5.6.1 Configuration Parameters 6
7
The startup procedure outlined in sub-clause 2.5.5.5.6.2 is designed in such a way 8
that, by using it consistently, devices can go through all the stages of 9
commissioning up to being joined to the proper ZigBee network and able to send 10
and receive application data traffic. Later-stage commissioning, including the 11
commissioning of bindings and group membership is discussed briefly in sub- 12
clause 2.5.5.5.6.3 below. The procedure makes use of the system parameters listed 13
in Table 2.139. 14
Table 2.139 Startup Parameters 15
16
Name Reference Comment 17
nwkExtendedPANID Table 3.43 This is the extended PANID of the network 18
to which the device is joined. If it has a 19
value of 0x0000000000000000, then the 20
device is not connected to a network. 21
apsDesignatedCoordinator Table 2.24 This boolean flag indicates whether the 22
device should assume on startup that it must 23
become a ZigBee coordinator. 24
apsChannelMask Table 2.24 This is the mask containing allowable 25
channels on which the device may attempt 26
to form or join a network at startup time. 27
apsUseExtendedPANID Table 2.24 The 64-bit identifier of the network to join 28
or form. 29
30
apsUseInsecureJoin Table 2.24 A boolean flag, which defaults to TRUE and
indicates whether it is OK to use insecure 31
join on startup. 32
33
34
2.5.5.5.6.2 Startup Procedure
35
The startup procedure uses the parameters listed in sub-clause 2.5.5.5.6.1 to 36
perform a controlled startup of the ZigBee networking facilities of a device. The 37
procedure should be run whenever the device restarts, but may also be run under 38
application control at the discretion of the developer. 39
40
When a device starts up, it should check the value of nwkExtendedPANID. If
41
nwkExtendedPANID has a non-zero value, then the device should assume it has all
42
the network parameters required to operate on a network. Note that the device
43
should assume the channel identifier present in its current network parameters but
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 243

may need to scan over the ChannelMask if the nwkExtendedPANID is not found.
In order for this to work effectively across power failures and processor resets, 1
nwkExtendedPANID must be placed in non-volatile storage.11 2
3
If the device finds it is not connected to a network, then it should check the value 4
of apsDesignatedCoordinator. If this parameter has a value of TRUE, then the 5
device should follow the procedures for starting a network outlined in sub- 6
clause 3.6.1.4.1 and should use the value of apsChannelMask for the 7
ScanChannels parameter of the NLME-NETWORK-FORMATION.request 8
primitive, and set nwkExtendedPANID to the value given in 9
apsUseExtendedPANID if apsUseExtendedPANID has a non-zero value. 10
If the device is not the designated coordinator and apsUseExtendedPANID has a 11
non-zero value, the device should attempt to rejoin the network specified in 12
apsUseExtendedPANID. To do this, it should use NLME-JOIN.request with the 13
ExtendedPANID parameter equal to the value of apsUseExtendedPANID, the 14
ScanChannels parameter of the primitive equal to the value of the 15
apsChannelMask configuration parameter. The RejoinNetwork parameter of the 16
NLME-JOIN.request primitive should have a value of 0x02 indicating rejoin. 17
18
If the network rejoin attempt fails, and the value of the apsUseInsecureJoin 19
attribute of the AIB has a value of TRUE, then the device should follow the 20
procedure outlined in sub-clause 3.6.1.4.1 for joining a network, using 21
apsChannelMask any place that a ScanChannels mask is called for. If 22
apsUseExtendedPANID has a non-zero value, then the device should join only the 23
specified network and the procedure should fail if that network is found to be 24
inaccessible. If apsUseExtendedPANID is equal to 0x0000000000000000, then 25
the device should join the best available network. 26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
11. CCB #846 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
244 Application Layer Specification

2.5.5.5.6.3 Further Commissioning


1
Once a device is on a network and capable of communicating with other devices 2
on the network in a secure manner, other commissioning becomes possible. Other 3
items that should be subject to commissioning are shown in Table 2.140. 4
Table 2.140 Additional Commissioning Parameters 5
6
Name Reference Comment 7
apsBindingTable Table 2.24 The binding table for this device. Binding 8
provides a separation of concerns in the 9
sense that applications may operate without 10
having to manage recipient address 11
information for the frames they emit. This
information can be input at commissioning
12
time without the main application on the 13
device even being aware of it. 14
15
nwkGroupIDTable Table 3.43 Commissioning applications should be able
to manage group membership of a device 16
and its endpoints by accessing this table. 17
18
nwkSecurityMaterialSet Table 4.2 This set contains the network keying
material, which should be accessible to 19
commissioning applications. 20
21
apsDeviceKeyPairSet Table 4.28 Contained in the set of key pairs for a device
is the Trust Center master key, which should 22
be accessible to commissioning 23
applications. 24
apsTrustCenterAddress Table 4.28 The IEEE address of the Trust Center. 25
26
nwkShortAddress Table 3.43 Commissioning applications may set the 27
network short address of devices as long as
address conflicts that may arise as a result 28
are subject to address conflict resolution as 29
described in sub-clause 3.6.1.9. 30
31
2.5.5.6 Device and Service Discovery 32
33
The Device and Service Discovery function supports: 34
35
• Device Discovery
36
• Service Discovery 37
38
Device Management performs the above functions with the ZigBee Device Profile
39
(see clause 2.4).
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 245

2.5.5.6.1 Optional and Mandatory Attributes Within Device and Service


Discovery 1
2
All of the request attributes within the Device and Service Discovery Object are 3
optional for all ZigBee logical device types. The responses listed in Table 2.141 as 4
mandatory are mandatory for all ZigBee logical device types, and the responses 5
listed as optional are optional for all ZigBee logical device types. See clause 2.4 6
for a description of any of these attributes. 7
Table 2.141 Device and Service Discovery Attributes 8
9
Attribute M/O Type 10
NWK_addr_req O Public 11
12
NWK_addr_rsp M Public 13
IEEE_addr_req O Public 14
IEEE_addr_rsp M Public
15
16
Node_Desc_req O Public 17
Node_Desc_rsp M Public 18
19
Power_Desc_req O Public
20
Power_Desc_rsp M Public 21
Simple_Desc_req O Public 22
23
Simple_Desc_rsp M Public
24
Active_EP_req O Public 25
Active_EP_rsp M Public 26
27
Match_Desc_req O Public
28
Match_Desc_rsp M Public 29
Complex_Desc_req O Public 30
31
Complex_Desc_rsp O Public 32
User_Desc_req O Public 33
User_Desc_rsp O Public
34
35
Device_annce M Public 36
User_Desc_set O Public 37
38
User_Desc_conf O Public
39
System_Server_Discovery_req O Public 40
System_Server_Discovery_rsp O Public 41
42
Discovery_Cache_req O Public
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
246 Application Layer Specification

Table 2.141 Device and Service Discovery Attributes (Continued)


1
Attribute M/O Type 2
Discovery_Cache_rsp O Public 3
4
Discovery_store_req O Public
5
Discovery_store_rsp O Public 6
Node_Desc_store_req O Public 7
8
Node_Desc_store_rsp O Public 9
Power_Desc_store_req O Public 10
Power_Desc_store_rsp O Public
11
12
Active_EP_store_req O Public 13
Active_EP_store_rsp O Public 14
15
Simple_Desc_store_req O Public
16
Simple_Desc_store_rsp O Public 17
Remove_node_cache_req O Public 18
19
Remove_node_cache_rsp O Public
20
Find_node_cache_req O Public 21
Find_node_cache_rsp O Public 22
23
24
2.5.5.7 Security Manager 25
The security manager determines whether security is enabled or disabled and, if 26
enabled, shall perform the following: 27
28
• Establish Key 29
• Transport Key 30
31
• Authentication 32
2.5.5.7.1 Optional and Mandatory Attributes Within Security Manager 33
34
The Security Manager itself is an optional object for all ZigBee Device Types. If 35
the Security Manager is present, all requests and responses are mandatory for all 36
ZigBee device types. If the Security Manager is not present, none of the attributes 37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 247

in the Security Manager are present for any ZigBee logical device type. See
clause 2.4 for a description of any of the primitives listed in Table 2.142. 1
2
Table 2.142 Security Manager Attributes
3
Attribute M/O Type 4
5
APSME-ESTABLISH-KEY.request O Public 6
APSME-ESTABLISH-KEY.response O Public 7
APSME-ESTABLISH-KEY. indication O Public 8
9
APSME-ESTABLISH-KEY.confirm O Public 10
APSME-TRANSPORT-KEY.request O Public 11
12
APSME-TRANSPORT-KEY.indication O Public
13
APSME-UPDATE-DEVICE.request O Public 14
APSME-UPDATE-DEVICE.indication O Public 15
16
APSME-REMOVE-DEVICE.request O Public
17
APSME-REMOVE-DEVICE.indication O Public 18
APSME-REQUEST-KEY.request O Public 19
20
APSME-REQUEST-KEY.indication O Public
21
APSME-SWITCH-KEY.request O Public 22
APSME-SWITCH-KEY.indication O Public 23
24
APSME-AUTHENTICATE.request O Private 25
APSME-AUTHENTICATE.indication O Private 26
APSME-AUTHENTICATE.confirm O Private
27
28
29
2.5.5.8 Binding Manager 30
The Binding Management function supports: 31
32
• End Device Binding 33
• Bind and Unbind 34
35
Binding Management performs the above functions with ZigBee Device Profile 36
commands plus APSME-SAP primitives to commit/remove binding table entries 37
once the indication arrives on the ZigBee coordinator, router, or end device 38
supporting the binding table. 39
2.5.5.8.1 Optional and Mandatory Attributes Within Binding Manager 40
41
The Binding Manager is an optional object for all ZigBee Device Types. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
248 Application Layer Specification

If the Binding Manager is present, all requests are optional for all ZigBee logical
device types. Responses shall be supported on devices which implement a binding 1
table cache, and on devices which correspond to the source address for the 2
binding table entries held on those devices. 3
4
If the Binding Manager is not present, all requests and all responses for all ZigBee 5
logical device types shall not be supported. Table 2.143 summarizes Binding 6
Manager attributes. 7
Table 2.143 Binding Manager Attributes 8
9
Attribute M/O Type 10
End_Device_Bind_req O Public 11
12
End_Device_Bind_rsp O Public
13
Bind_req O Public 14
Bind_rsp O Public 15
16
Unbind_req O Public
17
Unbind_rsp O Public 18
Bind_Register_req O Public 19
20
Bind_Register_rsp O Public 21
Replace_Device_req O Public 22
Replace_Device_rsp O Public
23
24
Store_Bkup_Bind_Entry_req O Public 25
Store_Bkup_Bind_Entry_rsp O Public 26
27
Remove_Bkup_Bind_req O Public
28
Remove_Bkup_Bind_rsp O Public 29
Backup_Bind_Table_req O Public 30
31
Backup_Bind_Table_rsp O Public
32
Recover_Bind_Table_req O Public 33
Recover_Bind_Table_rsp O Public 34
35
Backup_Source_Bind_req O Public
36
Backup_Source_Bind_rsp O Public 37
Recover_Source_Bind_req O Public 38
39
Recover_Source_Bind_rsp O Public 40
APSME-BIND.request O Private 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 249

Table 2.143 Binding Manager Attributes (Continued)


1
Attribute M/O Type 2
APSME-BIND.confirm O Private 3
4
APSME-UNBIND.request O Private
5
APSME-UNBIND.confirm O Private 6
7
2.5.5.9 Network Manager 8
9
The Network Management function supports: 10
• Network Discovery 11
12
• Network Formation 13
• Permit/Disable Associations 14
15
• Association and Disassociation 16
• Route Discovery 17
18
• Network Reset 19
• Radio Receiver State Enable/Disable 20
21
• Get and Set of Network Management Information Block Data 22
• Detecting and reporting interference 23
24
• Receive network interference reports and change network channels if the 25
particular node is identified as the network manager for the overall PAN 26
Network Management performs the above functions with NLME-SAP primitives 27
(see Chapter 3). 28
29
2.5.5.9.1 Optional and Mandatory Attributes Within Network Manager 30
31
The Network Manager is a mandatory object for all ZigBee Device Types.
32
The Network Discovery, Get, and Set attributes (both requests and confirms) are 33
mandatory for all ZigBee logical device types. 34
35
If the ZigBee logical device type is ZigBee Coordinator, the NWK Formation
36
request and confirm, the NWK Leave request, NWK Leave indication, NWK
37
Leave confirm, NWK Join indication, NWK Permit Joining request, and NWK
38
Permit Joining confirm shall be supported. The NWK Direct Join request, NWK
39
Direct Join confirm, NWK Route Discovery request, and NWK Route Discovery
40
confirm may be supported. The NWK Join request and the NWK Join confirm
41
shall not be supported.
42
If the ZigBee logical device type is ZigBee Router, the NWK Formation request 43
and confirm shall not be supported. Additionally, the NWK Start Router request, 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
250 Application Layer Specification

NWK Start Router confirm, NWK Join request, NWK Join confirm, NWK Join
indication, NWK Leave request, NWK Leave confirm, NWK Leave indication, 1
NWK Permit Joining request, and NWK Permit Joining confirm shall be 2
supported. The NWK Direct Join request, NWK Direct Join confirm, NWK Route 3
Discovery request, and NWK Route Discovery confirm may be supported. 4
5
If the ZigBee logical device type is ZigBee End Device, the NWK Formation 6
request and confirm plus the NWK Start Router request and confirm shall not be 7
supported. Additionally, the NWK Join indication and NWK Permit Joining 8
request shall not be supported. The NWK Join request, NWK Join confirm, NWK 9
Leave request, NWK Leave indication, NWK Leave confirm shall be supported. 10
For all ZigBee logical devices types, the NWK Sync request, indication and 11
confirm plus NWK reset request and confirm plus NWK route discovery request 12
and confirm shall be optional. Table 2.144 summarizes Network Manager 13
Attributes. See Chapter 3 for a description of any of the primitives listed in 14
Table 2.144. 15
16
For all ZigBee logical device types, reception of the NWK Network Status 17
indication shall be supported, but no action is required in this version of the 18
specification. 19
Table 2.144 Network Manager Attributes 20
21
Attribute M/O Type 22
NLME-GET.request M Private 23
24
NLME-GET.confirm M Private
25
NLME-SET.request M Private 26
NLME-SET.confirm M Private 27
28
NLME-NETWORK-DISCOVERY.request M Public
29
NLME-NETWORK-DISCOVERY.confirm M Public 30
NLME-NETWORK-FORMATION.request O Private 31
32
NLME-NETWORK- O Private 33
FORMATION.confirm
34
NLME-START-ROUTER.request O Private 35
NLME-START-ROUTER.confirm O Private 36
37
NLME-JOIN.request O Private
38
NLME-JOIN.confirm O Private 39
NLME_JOIN.indication O Private 40
41
NLME-PERMIT-JOINING O Public 42
NLME-PERMIT-JOINING.confirm O Public 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 251

Table 2.144 Network Manager Attributes (Continued)


1
Attribute M/O Type 2
NLME-DIRECT-JOIN.request O Public 3
4
NLME-DIRECT-JOIN.confirm O Public
5
NLME_LEAVE.request M Public 6
NLME-LEAVE.confirm M Public 7
8
NLME_LEAVE.indication M Public 9
NLME-RESET.request O Private 10
NLME-RESET.confirm O Private
11
12
NLME-SYNC.request O Public 13
NLME-SYNC.indication O Public 14
15
NLME-SYNC.confirm O Public
16
NLME-NWK-STATUS.indication M Private 17
NLME-ROUTE-DISCOVERY.request O Public 18
19
NLME-ROUTE-DISCOVERY.confirm O Private
20
NLME-ED-SCAN.request O Private 21
NLME-ED-SCAN.confirm O Private 22
23
NLME-START-BACKOFF.request O Private
24
25
A single device in the network can become the Network Channel Manager. The 26
operation of the network channel manager is described in Annex E. All other 27
devices in the network are responsible for tracking message delivery failures and 28
reporting interference in accordance with Annex E. 29
30
2.5.5.10 Node Manager 31
The Node Manager supports the ability to request and respond to management 32
functions. These management functions only provide visibility to external devices 33
regarding the operating state of the device receiving the request. 34
35
2.5.5.10.1 Optional and Mandatory Attributes Within Node Manager 36
37
The Node Manager is an optional object for all ZigBee Device Types. All request
38
and response attributes within Node Manager are also optional if the Node
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
252 Application Layer Specification

Manager object is present. Table 2.145 summarizes Node Manager attributes. See
clause 2.4 for a description of these attributes. 1
2
Table 2.145 Node Manager Attributes
3
Attribute M/O Type 4
5
Mgmt_NWK_Disc_req O Public 6
Mgmt_NWK_Disc_rsp O Public 7
Mgmt_Lqi_req O Public 8
9
Mgmt_Lqi_rsp O Public 10
Mgmt_Rtg_req O Public 11
12
Mgmt_Rtg_rsp O Public
13
Mgmt_Bind_req O Public 14
Mgmt_Bind_rsp O Public 15
16
Mgmt_Leave_req O Public
17
Mgmt_Leave_rsp O Public 18
Mgmt_Direct_Join_req O Public 19
20
Mgmt_Direct_Join_rsp O Public
21
Mgmt_Permit_Joining_req O Public 22
Mgmt_Permit_Joining_rsp O Public 23
24
Mgmt_Cache_req O Public 25
Mgmt_Cache_rsp O Public 26
Mgmt_NWK_Update_req O Private
27
28
Mgmt_NWK_Update_notify O Private 29
30
2.5.5.11 Group Manager 31
32
The Group Manager supports the ability to include application objects within 33
groups or to remove application objects from groups. The group management 34
functions operate only on application objects within the local device. Mechanisms 35
to manage groups on other devices are beyond the scope of this document. 36
2.5.5.11.1 Optional and Mandatory Attributes Within Group Manager 37
38
The Group Manager is an optional object for all ZigBee Device Types. All request 39
and response attributes within Group Manager are also optional if the Group 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 253

Manager object is present. Table 2.146 summarizes Group Manager attributes.


See clause 2.4 for a description of these attributes. 1
2
Table 2.146 Group Manager Attributes
3
Attribute M/O Type 4
5
APSME-ADD-GROUP.request O Public 6
APSME-ADD-GROUP.confirm O Public 7
APSME-REMOVE-GROUP.request O Public 8
9
ASPME-REMOVE-GROUP.confirm O Public 10
APSME-REMOVE-ALL- O Public 11
GROUPS.request 12
APSME-REMOVE-ALL- O Public 13
GROUPS.confirm 14
15
16
2.5.6 Configuration Attributes 17
18
This attribute is used to represent the minimum mandatory and/or optional 19
attributes used as configuration attributes for a device. 20
Table 2.147 Configuration Attributes 21
22
Attribute M/O Type 23
:Config_Node_Descriptor M Public 24
25
:Config_Power_Descriptor M Public 26
:Config_Simple_Descriptors M Public 27
:Config_NWK_Scan_Attempts M Private
28
29
:Config_NWK_Time_btwn_Scans M Private 30
:Config_Complex_Descriptor O Public 31
32
:Config_User_Descriptor O Public
33
:Config_Max_Bind O Private 34
:Config_Master_Key O Private 35
36
:Config_EndDev_Bind_Timeout O Private
37
:Config_Permit_Join_Duration O Public 38
:Config_NWK_Security_Level O Private 39
40
:Config_NWK_Secure_All_Frames O Private
41
:Config_NWK_Leave_removeChildren O Private 42
:Config_NWK_BroadcastDeliveryTime O Private 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 2
254 Application Layer Specification

Table 2.147 Configuration Attributes (Continued)


1
Attribute M/O Type 2
:Config_NWK_TransactionPersistenceTime O Private 3
4
:Config_NWK_indirectPollRate O Private
5
:Config_Max_Assoc O Private 6
:Config_NWK_Join_Direct_Addrs O Public 7
8
:Config_Parent_Link_Retry_Threshold O Public 9
:Config_Rejoin_Interval O Public 10
:Config_Max_Rejoin_Interval O Public
11
12
13
2.5.6.1 Configuration Attribute Definitions 14
Table 2.148 Configuration Attribute Definitions 15
16
Attribute Description When Updated 17
:Config_Node_Descriptor Contents of the Node The :Config_Node_Descriptor is 18
Descriptor for this either created when the application 19
device (see sub- is first loaded or initialized with a 20
clause 2.3.2.3). commissioning tool prior to when 21
the device begins operations in the
network. It is used for service 22
discovery to describe node features 23
to external inquiring devices. 24
:Config_Power_Descriptor Contents of the Power The :Config_Power_Descriptor is 25
Descriptor for this either created when the application 26
device (see sub- is first loaded or initialized with a 27
clause 2.3.2.4). commissioning tool prior to when 28
the device begins operations in the 29
network. It is used for service
discovery to describe node power 30
features to external inquiring 31
devices. 32
:Config_Simple_Descriptors Contents of the Simple The :Config_Simple_Descriptors
33
Descriptor(s) for each are created when the application is 34
active endpoint for this first loaded and are treated as “read- 35
device (see sub- only.” The Simple Descriptor are 36
clause 2.3.2.5). used for service discovery to 37
describe interfacing features to
external inquiring devices.
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 255

Table 2.148 Configuration Attribute Definitions (Continued)


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

Table 2.148 Configuration Attribute Definitions (Continued)


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

Table 2.148 Configuration Attribute Definitions (Continued)


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

Table 2.148 Configuration Attribute Definitions (Continued)


1
Attribute Description When Updated 2
:Config_NWK_Join_Direct_Ad Consists of the :Config_NWK_Join_Direct_Addr 3
drs following fields: s permits the ZigBee Coordinator 4
or Router to be pre-configured 5
DeviceAddress - 64-bit with a list of addresses to be direct
IEEE address for the 6
joined.
device to be direct 7
joined 8
CapabilityInformation - 9
Operating capabilities 10
of the device to be 11
direct joined 12
MasterKey - If security 13
is enabled, master key 14
for use in the key-pair 15
descriptor for this new
device (see Table 4.37)
16
17
See sub-clause 3.2.2.14 18
for details.
19
:Config_Parent_Link_Retry_Th Contents of the link The 20
reshold retry threshold for :Config_Parent_Link_Retry_Thres 21
parent link (see sub- hold is either created when the
22
clause 2.5.5.5.5.2). application is first loaded or
initialized with a commissioning 23
tool. It is used for the ZED to 24
decide how many times it should 25
retry to connect to the parent router 26
before initiating the rejoin process.
27
:Config_Rejoin_Interval Contents of the rejoin The :Config_Rejoin_Interval is 28
interval (see sub- either created when the application 29
clause 2.5.5.5.5.2). is first loaded or initialized with a
30
commissioning tool. It is used by
the ZED to decide how often it 31
should initiate the rejoin process. 32
33
:Config_MAX_Rejoin_Interval Contents of the The
maximal rejoin interval :Config_MAX_Rejoin_Interval is 34
2.5.5.5.5.2). either created when the application 35
is first loaded or initialized with a 36
commissioning tool. It is used by 37
the ZED to set the maximum value 38
permitted for
:Config_Rejoin_Interval during 39
the rejoin procedure. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 259

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 General Description 14
15
16
3.1.1 Network (NWK) Layer Overview 17
18
The network layer is required to provide functionality to ensure correct operation 19
of the IEEE 802.15.4-2003 MAC sub-layer and to provide a suitable service 20
interface to the application layer. To interface with the application layer, the 21
network layer conceptually includes two service entities that provide the 22
necessary functionality. These service entities are the data service and the 23
management service. The NWK layer data entity (NLDE) provides the data 24
transmission service via its associated SAP, the NLDE-SAP, and the NWK layer 25
management entity (NLME) provides the management service via its associated 26
SAP, the NLME-SAP. The NLME utilizes the NLDE to achieve some of its 27
management tasks and it also maintains a database of managed objects known as 28
the network information base (NIB). 29
30
3.1.1.1 Network Layer Data Entity (NLDE) 31
32
The NLDE shall provide a data service to allow an application to transport 33
application protocol data units (APDU) between two or more devices. The 34
devices themselves must be located on the same network. 35
The NLDE will provide the following services: 36
37
• Generation of the Network level PDU (NPDU): The NLDE shall be capable 38
of generating an NPDU from an application support sub-layer PDU through the 39
addition of an appropriate protocol header. 40
• Topology-specific routing: The NLDE shall be able to transmit an NPDU to 41
an appropriate device that is either the final destination of the communication 42
or the next step toward the final destination in the communication chain. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
260 Network Specification

• Security: The ability to ensure both the authenticity and confidentiality of a


transmission. 1
2
3.1.1.2 Network Layer Management Entity (NLME) 3
4
The NLME shall provide a management service to allow an application to interact 5
with the stack. 6
The NLME shall provide the following services: 7
8
• Configuring a new device: this is the ability to sufficiently configure the stack 9
for operation as required. Configuration options include beginning an operation 10
as a ZigBee coordinator or joining an existing network. 11
• Starting a network: this is the ability to establish a new network. 12
13
• Joining, rejoining and leaving a network: this is the ability to join, rejoin or 14
leave a network as well as the ability of a ZigBee coordinator or ZigBee router 15
to request that a device leave the network. 16
• Addressing: this is the ability of ZigBee coordinators and routers to assign 17
addresses to devices joining the network. 18
19
• Neighbor discovery: this is the ability to discover, record, and report 20
information pertaining to the one-hop neighbors of a device. 21
• Route discovery: this is the ability to discover and record paths through the 22
network, whereby messages may be efficiently routed. 23
24
• Reception control: this is the ability for a device to control when the receiver 25
is activated and for how long, enabling MAC sub-layer synchronization or 26
direct reception. 27
• Routing: this is the ability to use different routing mechanisms such as unicast, 28
broadcast, multicast or many to one to efficiently exchange data in the network. 29
30
31
3.2 Service Specification 32
33
Figure 3.1 depicts the components and interfaces of the NWK layer. 34
35
The NWK layer provides two services, accessed through two service access 36
points (SAPs). These are the NWK data service, accessed through the NWK layer 37
data entity SAP (NLDE-SAP), and the NWK management service, accessed 38
through the NWK layer management entity SAP (NLME-SAP). These two 39
services provide the interface between the application and the MAC sub-layer, via 40
the MCPS-SAP and MLME-SAP interfaces (See [B1]). In addition to these 41
external interfaces, there is also an implicit interface between the NLME and the 42
NLDE that allows the NLME to use the NWK data service. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 261

1
Next Higher Layer Entity 2
3
4
NLDE-SAP NLME-SAP
5
NLME 6
NLDE 7
NWK 8
IB 9
10
MCPS-SAP MLME -SAP 11
12
MAC Sub-Layer Entity 13
14
15
Figure 3.1 The NWK Layer Reference Model 16
17
3.2.1 NWK Data Service 18
19
The NWK layer data entity SAP (NLDE-SAP) supports the transport of 20
application protocol data units (APDUs) between peer application entities. 21
Table 3.1 lists the primitives supported by the NLDE-SAP and the sub-clauses in 22
which these primitives are discussed. 23
24
Table 3.1 NLDE-SAP Primitives 25
NLDE-SAP Primitive Request Confirm Indication 26
27
NLDE-DATA 3.2.1.1 3.2.1.2 3.2.1.3 28
29
3.2.1.1 NLDE-DATA.request 30
31
This primitive requests the transfer of a data PDU (NSDU) from the local APS 32
sub-layer entity to a single or multiple peer APS sub-layer entities. 33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
262 Network Specification

3.2.1.1.1 Semantics of the Service Primitive


1
The semantics of this primitive are as follows: 2
NLDE-DATA.request { 3
4
DstAddrMode,
5
DstAddr,
6
NsduLength,
7
Nsdu, 8
NsduHandle, 9
Radius, 10
NonmemberRadius, 11
DiscoverRoute, 12
SecurityEnable 13
} 14
15
Table 3.2 specifies the parameters for the NLDE-DATA.request primitive. 16
17
Table 3.2 NLDE-DATA.request Parameters 18
Name Type Valid Range Description 19
20
DstAddrMode Integer 0x01 or 0x02 The type of destination address 21
supplied by the DstAddr parameter.
22
This may have one of the following
two values: 23
24
0x01=16-bit multicast group address
25
0x02=16-bit network address of a 26
device or a 16-bit broadcast address 27
DstAddr 16-bit 0x0000-0xffff Destination address. 28
Address 29
NsduLength Integer The number of octets comprising the 30
aMaxMACFram NSDU to be transferred. This has been 31
eSize - modified from the 32
(nwkcMACFram aMaxMACFrameSize limit specified
33
eOverhead + in the IEEE 802.15.4 specification to
nwkcMinHeader take into account that the ZigBee 34
Overhead) network layer does not use the 35
extended addressing modes. The 36
effect of this is to free the unused 37
portion of the header to be used for
38
payload. See sub-clause D.4.
39
Nsdu Set of - The set of octets comprising the 40
Octets NSDU to be transferred.
41
NsduHandle Integer 0x00 – 0xff The handle associated with the NSDU 42
to be transmitted by the NWK layer
43
entity.
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 263

Table 3.2 NLDE-DATA.request Parameters (Continued)


1
Name Type Valid Range Description 2
Radius Unsigned 0x00 – 0xff The distance, in hops, that a frame 3
Integer will be allowed to travel through the 4
network. 5
NonmemberRadius Integer 0x00 – 0x07 The distance, in hops, that a multicast 6
frame will be relayed by nodes not a 7
member of the group. A value of 0x07 8
is treated as infinity.
9
DiscoverRoute Integer 0x00 – 0x01 The DiscoverRoute parameter may be 10
used to control route discovery 11
operations for the transit of this frame
(see sub-clause 3.6.3.5): 12
13
0x00 = suppress route discovery 14
0x01 = enable route discovery 15
SecurityEnable Boolean TRUE or FALSE The SecurityEnable parameter may be 16
used to enable NWK layer security 17
processing for the current frame. If the 18
nwkSecurityLevel attribute of the NIB 19
has a value of 0, meaning no security,
20
then this parameter will be ignored.
Otherwise, a value of TRUE denotes 21
that the security processing specified 22
by the security level will be applied, 23
and a value of FALSE denotes that no 24
security processing will be applied.
25
26
3.2.1.1.2 When Generated 27
This primitive is generated by a local APS sub-layer entity whenever a data PDU 28
(NSDU) is to be transferred to a peer APS sub-layer entity. 29
30
3.2.1.1.3 Effect on Receipt 31
If this primitive is received on a device that is not currently associated, the NWK 32
layer will issue an NLDE-DATA.confirm primitive with a status of 33
INVALID_REQUEST. 34
35
On receipt of this primitive, the NLDE first constructs an NPDU in order to 36
transmit the supplied NSDU. If, during processing, the NLDE issues the NLDE- 37
DATA.confirm primitive prior to transmission of the NSDU, all further processing 38
is aborted. In constructing the new NPDU, the destination address field of the 39
NWK header will be set to the value provided in the DstAddr parameter, and the 40
source address field will have the value of the macShortAddress attribute in the 41
MAC PIB. The discover route sub-field of the frame control field of the NWK 42
header will be set to the value provided in the DiscoverRoute parameter. If the 43
supplied Radius parameter does not have a value of zero, then the radius field of 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
264 Network Specification

the NWK header will be set to the value of the Radius parameter. If the Radius
parameter has a value of zero, then the radius field of the NWK header will be set 1
to twice the value of the nwkMaxDepth attribute of the NIB. The NWK layer will 2
generate a sequence number for the frame as described in sub-clause 3.6.2.1. and 3
the sequence number field of the NWK header of the frame will be set to this 4
sequence number value. The multicast flag field of the NWK header will be set 5
according to the value of the DstAddrMode parameter. If the DstAddrMode 6
parameter has a value of 0x01, the NWK header will contain a multicast control 7
field whose fields will be set as follows: 8
9
• The multicast mode field will be set to 0x01 if this node is a member of the 10
group specified in the DstAddr parameter. 11
• Otherwise, the multicast mode field will be set to 0x00. 12
13
• The non-member radius and the max non-member radius fields will be set to 14
the value of the NonmemberRadius parameter. 15
Once the NPDU is constructed, the NSDU is routed using the procedure described 16
in sub-clause 3.6.3.3 if it is a unicast, sub-clause 3.6.5 if it is a broadcast, or sub- 17
clause 3.6.6.2 if it is a multicast. When the routing procedure specifies that the 18
NSDU is to be transmitted, this is accomplished by issuing the MCPS- 19
DATA.request primitive with both the SrcAddrMode and DstAddrMode 20
parameters set to 0x02, indicating the use of 16-bit network addresses. The 21
SrcPANId and DstPANId parameters should be set to the current value of 22
macPANId from the MAC PIB. The SrcAddr parameter will be set to the value of 23
macShortAddr from the MAC PIB. The value of the DstAddr parameter is the 24
next hop address determined by the routing procedure. If the message is a unicast, 25
bit b0 of the TxOptions parameter should be set to 1 denoting that an 26
acknowledgement is required. On receipt of the MCPS-DATA.confirm primitive, 27
the NLDE issues the NLDE-DATA.confirm primitive with a status equal to that 28
received from the MAC sub-layer. 29
30
If the nwkSecurityLevel NIB attribute has a non-zero value and the SecurityEnable 31
parameter has a value of TRUE, then NWK layer security processing will be 32
applied to the frame before transmission as described in clause 4.3. Otherwise, no 33
security processing will be performed at the NWK layer for this frame. If security 34
processing is performed and it fails for any reason, then the frame is discarded and 35
the NLDE issues the NLDE-DATA.confirm primitive with a Status parameter 36
value equal to that returned by the security suite. 37
38
3.2.1.2 NLDE-DATA.confirm 39
This primitive reports the results of a request to transfer a data PDU (NSDU) from 40
a local APS sub-layer entity to a single peer APS sub-layer entity. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 265

3.2.1.2.1 Semantics of the Service Primitive


1
The semantics of this primitive are as follows: 2
NLDE-DATA.confirm { 3
4
Status
5
NsduHandle,
6
TxTime
7
} 8
9
Table 3.3 specifies the parameters for the NLDE-DATA.confirm primitive. 10
Table 3.3 NLDE-DATA.confirm Parameters 11
12
Name Type Valid Range Description 13
Status Status INVALID_REQUEST, The status of the corresponding 14
MAX_FRM_COUNTER, request. 15
NO_KEY, 16
BAD_CCM_OUTPUT, 17
ROUTE_ERROR,
18
BT_TABLE_FULL,
FRAME_NOT_BUFFERED 19
or any status values returned 20
from security suite or the 21
MCPS-DATA.confirm 22
primitive (see [B1])
23
NsduHandle Integer 0x00 – 0xff The handle associated with the NSDU 24
being confirmed. 25
TxTime Integer Implementation specific A time indication for the transmitted 26
packet based on the local clock. The 27
time should be based on the same
28
point for each transmitted packet in a
given implementation. This value is 29
only provided if nwkTimeStamp is set 30
to TRUE. 31
32
3.2.1.2.2 When Generated 33
34
This primitive is generated by the local NLDE in response to the reception of an 35
NLDE-DATA.request primitive. 36
The Status field will reflect the status of the corresponding request, as described in 37
sub-clause 3.2.1.1.3. 38
39
3.2.1.2.3 Effect on Receipt 40
On receipt of this primitive, the APS sub-layer of the initiating device is notified 41
of the result of its request to transmit. If the transmission attempt was successful, 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
266 Network Specification

the Status parameter will be set to SUCCESS. Otherwise, the Status parameter
will indicate the error. 1
2
3.2.1.3 NLDE-DATA.indication 3
4
This primitive indicates the transfer of a data PDU (NSDU) from the NWK layer 5
to the local APS sub-layer entity. 6
3.2.1.3.1 Semantics of the Service Primitive 7
8
The semantics of this primitive are as follows: 9
10
NLDE-DATA.indication {
11
DstAddrMode,
12
DstAddr,
13
SrcAddr, 14
NsduLength, 15
Nsdu, 16
LinkQuality 17
RxTime 18
SecurityUse 19
} 20
21
Table 3.4 specifies the parameters for the NLDE-DATA.indication primitive. 22
23
Table 3.4 NLDE-DATA.indication Parameters 24
Name Type Valid Range Description 25
26
DstAddrMo Integer 0x01 or 0x02 The type of destination address 27
de supplied by the DstAddr parameter.
28
This may have one of the following
two values: 29
30
0x01=16-bit multicast group
31
address
32
0x02=16-bit network address of a 33
device or a 16-bit broadcast address
34
DstAddr 16-bit 0x0000-0xffff The destination address to which 35
Address the NSDU was sent. 36
SrcAddr 16-bit Any valid device address The individual device address from 37
Device except a broadcast address which the NSDU originated. 38
address
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 267

Table 3.4 NLDE-DATA.indication Parameters (Continued)


1
NsduLength Integer < aMaxMACFrameSize – The number of octets comprising
(nwkcMACFrameOverhea the NSDU being indicated. This 2
d+ has been modified from the 3
nwkcMinHeaderOverhead aMaxMACFrameSize limit 4
) specified in the IEEE 802.15.4 5
specification to take into account 6
that the ZigBee network layer does
not use the extended addressing 7
modes. The effect of this is to free 8
the unused portion of the header to 9
be used for payload. See sub- 10
clause D.4. 11
Nsdu Set of octets – The set of octets comprising the 12
NSDU being indicated. 13
LinkQuality Integer 0x00 – 0xff The link quality indication 14
delivered by the MAC on receipt of 15
this frame as a parameter of the 16
MCPS-DATA.indication primitive
(see [B1]). 17
18
RxTime Integer Implementation specific A time indication for the received
19
packet based on the local clock.
The time should be based on the 20
same point for each received packet 21
on a given implementation. This 22
value is only provided if 23
nwkTimeStamp is set to TRUE.
24
SecurityUse Boolean TRUE or FALSE An indication of whether the 25
received data frame is using 26
security. This value is set to TRUE
if security was applied to the 27
received frame or FALSE if the 28
received frame was unsecured. 29
30
3.2.1.3.2 When Generated 31
32
This primitive is generated by the NLDE and issued to the APS sub-layer on 33
receipt of an appropriately addressed data frame from the local MAC sub-layer 34
entity. 35
3.2.1.3.3 Effect on Receipt 36
37
On receipt of this primitive, the APS sub-layer is notified of the arrival of data at 38
the device. 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
268 Network Specification

3.2.2 NWK Management Service 1


2
The NWK layer management entity SAP (NLME-SAP) allows the transport of
3
management commands between the next higher layer and the NLME. Table 3.5
4
lists the primitives supported by the NLME through the NLME-SAP interface and
5
the sub-clauses containing details on each of these primitives.
6
Table 3.5 Summary of the Primitives Accessed Through the NLME-SAP 7
Sub-Clause Number in This Specification 8
9
Name Request Indication Response Confirm 10
11
NLME-NETWORK-DISCOVERY 3.2.2.1 3.2.2.2
12
NLME-NETWORK-FORMATION 3.2.2.3 3.2.2.4 13
NLME-PERMIT-JOINING 3.2.2.5 3.2.2.6 14
15
NLME-START-ROUTER 3.2.2.7 3.2.2.8 16
NLME-ED-SCAN 3.2.2.9 3.2.2.10 17
NLME-JOIN 3.2.2.11 3.2.2.12 3.2.2.13 18
19
NLME-DIRECT-JOIN 3.2.2.14 3.2.2.15 20
NLME-LEAVE 3.2.2.16 3.2.2.17 3.2.2.18 21
NLME-RESET
22
3.2.2.19 3.2.2.20
23
NLME-SYNC 3.2.2.22 3.2.2.24 24
NLME-SYNC-LOSS 3.2.2.23 25
26
NLME-GET 3.2.2.26 3.2.2.27
27
NLME-SET 3.2.2.28 3.2.2.29 28
NLME-NWK-STATUS 3.2.2.30 29
30
NLME-ROUTE-DISCOVERY 3.2.2.31 3.2.2.32 a
31
a. CCB #822 32
33
3.2.2.1 NLME-NETWORK-DISCOVERY.request 34
35
This primitive allows the next higher layer to request that the NWK layer discover 36
networks currently operating within the POS. 37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 269

3.2.2.1.1 Semantics of the Service Primitive


1
The semantics of this primitive are as follows: 2
NLME-NETWORK-DISCOVERY.request { 3
4
ScanChannels,
5
ScanDuration
6
}
7
8
Table 3.6 specifies the parameters for the NLME-NETWORK- 9
DISCOVERY.request primitive. 10
Table 3.6 NLME-NETWORK-DISCOVERY.request Parameters 11
12
Name Type Valid Range Description 13
ScanChannels Bitmap 32-bit field The five most significant bits (b27,..., 14
b31) are reserved. The 27 least 15
significant bits (b0, b1,... b26) indicate 16
which channels are to be scanned (1 = 17
scan, 0 = do not scan) for each of the 27
valid channels (see [B1]). 18
19
ScanDuration Integer 0x00 – 0x0e A value used to calculate the length of
20
time to spend scanning each channel:
21
The time spent scanning each channel is 22
(aBaseSuperframeDuration * (2n + 1))
23
symbols, where n is the value of the
ScanDuration parameter. For more 24
information on MAC sub-layer scanning 25
(see [B1]). 26
27
3.2.2.1.2 When Generated 28
29
This primitive is generated by the next higher layer of a ZigBee device and issued 30
to its NLME to request the discovery of networks operating within the device’s 31
personal operating space (POS). 32
3.2.2.1.3 Effect on Receipt 33
34
On receipt of this primitive, the NWK layer will attempt to discover networks 35
operating within the device’s POS by performing an active scan over the channels 36
specified in the ScanChannels argument for the period specified in the 37
ScanDuration parameter. The scan is performed by means of the MLME- 38
SCAN.request primitive. 39
On receipt of the MLME-SCAN.confirm primitive, the NLME issues the NLME- 40
NETWORK-DISCOVERY.confirm primitive containing the information about 41
the discovered networks with a Status parameter value equal to that returned with 42
the MLME-SCAN.confirm. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
270 Network Specification

3.2.2.2 NLME-NETWORK-DISCOVERY.confirm
1
This primitive reports the results of a network discovery operation. 2
3
3.2.2.2.1 Semantics of the Service Primitive
4
The semantics of this primitive are as follows: 5
6
NLME-NETWORK-DISCOVERY.confirm {
7
Status 8
NetworkCount, 9
NetworkDescriptor, 10
} 11
12
Table 3.7 describes the arguments of the NLME-NETWORK- 13
DISCOVERY.confirm primitive. 14
15
Table 3.7 NLME-NETWORK-DISCOVERY.confirm Parameters
16
Name Type Valid Range Description 17
18
Status Status Any status value returned See [B1].
with the MLME- 19
SCAN.confirm primitive. 20
21
NetworkCount Integer 0x00 – 0xff Gives the number of networks
discovered by the search. 22
23
NetworkDescriptor List of The list contains the A list of descriptors, one for
network number of elements given each of the networks 24
descriptors by the NetworkCount discovered. Table 3.8 gives a 25
parameter detailed account of the contents 26
of each item. 27
28
Table 3.8 gives a detailed account of the contents of a network descriptor from the 29
NetworkDescriptor parameter. 30
Table 3.8 Network Descriptor Information Fields
31
32
Name Type Valid Range Description 33
34
ExtendedPANId Integer 0x0000000000000 The 64-bit PAN identifier of the
001 - network. 35
0xfffffffffffffffe 36
LogicalChannel Integer Selected from the The current logical channel 37
available logical occupied by the network. 38
channels 39
supported by the 40
PHY (see [B1]). 41
StackProfile Integer 0x00 – 0x0f A ZigBee stack profile identifier 42
indicating the stack profile in use in 43
the discovered network.
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 271

Table 3.8 Network Descriptor Information Fields (Continued)


1
Name Type Valid Range Description 2
ZigBeeVersion Integer 0x00 – 0x0f The version of the ZigBee protocol 3
in use in the discovered network. 4
BeaconOrder Integer 0x00 – 0x0f This specifies how often the MAC 5
sub-layer beacon is to be 6
transmitted by a given device on the 7
network. For a discussion of MAC 8
sub-layer beacon order see [B1].
9
SuperframeOrder Integer 0x00 – 0x0f For beacon-oriented networks, that 10
is, beacon order < 15, this specifies 11
the length of the active period of the
superframe. For a discussion of 12
MAC sub-layer superframe order 13
see [B1]. 14
PermitJoining Boolean TRUE or FALSE A value of TRUE indicates that at 15
least one ZigBee router on the 16
network currently permits joining, 17
i.e. its NWK has been issued an 18
NLME-PERMIT-JOINING
19
primitive and, the time limit if
given, has not yet expired. 20
21
RouterCapacity Boolean TRUE or FALSE This value is set to true if the device
is capable of accepting join requests 22
from router-capable devices and set 23
to FALSE otherwise. 24
EndDeviceCapacity Boolean TRUE or FALSE This value is set to true if the device 25
is capable of accepting join requests 26
from end devices and set to FALSE 27
otherwise. 28
29
3.2.2.2.2 When Generated 30
31
This primitive is generated by the NLME and issued to its next higher layer on
32
completion of the discovery task initiated by an NLME-NETWORK-
33
DISCOVERY.request primitive.
34
3.2.2.2.3 Effect on Receipt 35
36
On receipt of this primitive, the next higher layer is notified of the results of a 37
network search. 38
39
3.2.2.3 NLME-NETWORK-FORMATION.request 40
This primitive allows the next higher layer to request that the device start a new 41
ZigBee network with itself as the coordinator and subsequently make changes to 42
its superframe configuration. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
272 Network Specification

3.2.2.3.1 Semantics of the Service Primitive


1
The semantics of this primitive are as follows: 2
NLME-NETWORK-FORMATION.request { 3
4
ScanChannels,
5
ScanDuration,
6
BeaconOrder,
7
SuperframeOrder, 8
BatteryLifeExtension 9
} 10
11
Table 3.9 specifies the parameters for the NLME-NETWORK- 12
FORMATION.request primitive. 13
Table 3.9 NLME-NETWORK-FORMATION.request Parameters
14
15
Name Type Valid Range Description 16
17
ScanChannels Bitmap 32-bit field The five most significant bits (b27,...,
b31) are reserved. The 27 least 18
significant bits (b0, b1,... b26) indicate 19
which channels are to be scanned in 20
preparation for starting a network 21
(1=scan, 0=do not scan) for each of the
22
27 valid 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
ScanDuration parameter (see [B1]). 28
29
BeaconOrder Integer 0x00 – 0x0f The beacon order of the network that the
30
higher layers wish to form.
31
SuperframeOrder Integer 0x00 – 0x0f The superframe order of the network 32
that the higher layers wish to form.
33
BatteryLifeExtension Boolean TRUE or FALSE If this value is TRUE, the NLME will 34
request that the ZigBee coordinator is
35
started supporting battery life extension
mode; If this value is FALSE, the 36
NLME will request that the ZigBee 37
coordinator is started without supporting 38
battery life extension mode. 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 273

3.2.2.3.2 When Generated


1
This primitive is generated by the next higher layer of a ZigBee coordinator- 2
capable device and issued to its NLME to request the initialization of itself as the 3
ZigBee coordinator of a new network. 4
3.2.2.3.3 Effect on Receipt 5
6
On receipt of this primitive by a device that is not capable of being a ZigBee 7
coordinator, the NLME issues the NLME-NETWORK-FORMATION.confirm 8
primitive with the Status parameter set to INVALID_REQUEST. 9
If the device is to be initialized as a ZigBee coordinator, the NLME requests that 10
the MAC sub-layer first perform an energy detection scan and then an active scan 11
on the specified set of channels. To do this, the NLME issues the MLME- 12
SCAN.request primitive to the MAC sub-layer with the ScanType parameter set to 13
indicate an energy detection scan and then issues the primitive again with the 14
ScanType parameter set to indicate an active scan. After the completion of the 15
active scan, on receipt of the MLME-SCAN.confirm primitive from the MAC 16
sub-layer, the NLME selects a suitable channel. The NWK layer will pick a PAN 17
identifier that does not conflict with that of any network known to be operating on 18
the chosen channel. Once a suitable channel and PAN identifier are found, the 19
NLME will choose 0x0000 as the 16-bit short MAC address and inform the MAC 20
sub-layer. To do this, the NLME issues the MLME-SET.request primitive to the 21
MAC sub-layer to set the MAC PIB attribute macShortAddress. If the NIB 22
attribute nwkExtendedPANId is equal to 0x0000000000000000, this 23
attribute will be initialized with the value of the MAC constant 24
macExtendedAddress. If no suitable channel or PAN identifier can be found, the 25
NLME issues the NLME-NETWORK-FORMATION.confirm primitive with the 26
Status parameter set to STARTUP_FAILURE. 27
28
If only a single channel is provided in the higher layer request, the NLME does 29
not need to request an energy scan prior to starting the network. An active scan is 30
still conducted to ensure a PAN identifier is selected that does not conflict with 31
that of any network known to be operating. 32
Next, the NLME issues the MLME-START.request primitive to the MAC sub- 33
layer. The PANCoordinator parameter of the MLME-START.request primitive is 34
set to TRUE. The BeaconOrder, SuperframeOrder, and BatteryLifeExtension 35
parameters will have the same values as those given to the NLME-NETWORK- 36
FORMATION.request. The CoordRealignment parameter in the MLME- 37
START.request primitive is set to FALSE if the primitive is issued to start a new 38
PAN. The CoordRealignment parameter is set to TRUE if the primitive is issued 39
to change any of the PAN configuration attributes on an exiting PAN. On receipt 40
of the associated MLME-START.confirm primitive, the NLME issues the NLME- 41
NETWORK-FORMATION.confirm primitive to the next higher layer with the 42
status returned from the MLME-START.confirm primitive. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
274 Network Specification

3.2.2.4 NLME-NETWORK-FORMATION.confirm
1
This primitive reports the results of the request to initialize a ZigBee coordinator 2
in a network. 3
4
3.2.2.4.1 Semantics of the Service Primitive
5
The semantics of this primitive are as follows: 6
7
NLME-NETWORK-FORMATION.confirm {
8
Status 9
} 10
11
Table 3.10 specifies the parameters for the NLME-NETWORK- 12
FORMATION.confirm primitive. 13
Table 3.10 NLME-NETWORK-FORMATION.confirm Parameters 14
15
Name Type Valid Range Description 16
Status Status INVALID_REQUEST, The result of the attempt to initialize a 17
STARTUP_FAILURE ZigBee coordinator. 18
or any status value returned from 19
the MLME-START.confirm 20
primitive 21
22
3.2.2.4.2 When Generated 23
24
This primitive is generated by the NLME and issued to its next higher layer in
25
response to an NLME-NETWORK-FORMATION.request primitive. This
26
primitive returns a status value of INVALID_REQUEST, STARTUP_FAILURE
27
or any status value returned from the MLME-START.confirm primitive.
28
Conditions under which these values may be returned are described in sub-
29
clause 3.2.2.3.3.
30
3.2.2.4.3 Effect on Receipt 31
32
On receipt of this primitive, the next higher layer is notified of the results of its 33
request to initialize the device as a ZigBee coordinator. If the NLME has been 34
successful, the Status parameter will be set to SUCCESS. Otherwise, the Status 35
parameter indicates the error. 36
37
3.2.2.5 NLME-PERMIT-JOINING.request 38
This primitive allows the next higher layer of a ZigBee coordinator or router to set 39
its MAC sub-layer association permit flag for a fixed period when it may accept 40
devices onto its network. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 275

3.2.2.5.1 Semantics of the Service Primitive


1
The semantics of this primitive are as follows: 2
NLME-PERMIT-JOINING.request { 3
4
PermitDuration
5
}
6
7
Table 3.11 specifies the parameters for the NLME-PERMIT-JOINING.request 8
primitive. 9
Table 3.11 NLME-PERMIT-JOINING.request Parameters 10
11
Name Type Valid Range Description 12
PermitDuration Integer 0x00 – 0xff The length of time in seconds during 13
which the ZigBee coordinator or router 14
will allow associations. The value 0x00 15
and 0xff indicate that permission is
16
disabled or enabled, respectively, without
a specified time limit. 17
18
19
3.2.2.5.2 When Generated
20
This primitive is generated by the next higher layer of a ZigBee coordinator or 21
router and issued to its NLME whenever it would like to permit or prohibit the 22
joining of the network by new devices. 23
24
3.2.2.5.3 Effect on Receipt 25
It is only permissible that the next higher layer of a ZigBee coordinator or router 26
issue this primitive. On receipt of this primitive by the NWK layer of a ZigBee 27
end device, the NLME-PERMIT-JOINING.confirm primitive returns a status of 28
INVALID_REQUEST. 29
30
On receipt of this primitive with the PermitDuration parameter set to 0x00, the 31
NLME sets the MAC PIB attribute, macAssociationPermit, to FALSE by issuing 32
the MLME-SET.request primitive to the MAC sub-layer. Once the MLME- 33
SET.confirm primitive is received, the NLME issues the NLME-PERMIT- 34
JOINING.confirm primitive with a status equal to that received from the MAC 35
sub-layer. 36
On receipt of this primitive with the PermitDuration parameter set to 0xff, the 37
NLME sets the MAC PIB attribute, macAssociationPermit, to TRUE by issuing 38
the MLME-SET.request primitive to the MAC sub-layer. Once the MLME- 39
SET.confirm primitive is received, the NLME issues the NLME-PERMIT- 40
JOINING.confirm primitive with a status equal to that received from the MAC 41
sub-layer. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
276 Network Specification

On receipt of this primitive with the PermitDuration parameter set to any value
other than 0x00 or 0xff, the NLME sets the MAC PIB attribute, 1
macAssociationPermit, to TRUE as described above. Following the receipt of the 2
MLME-SET.confirm primitive, the NLME starts a timer to expire after 3
PermitDuration seconds. Once the timer is set, the NLME issues the NLME- 4
PERMIT-JOINING.confirm primitive with a status equal to that received by the 5
MAC sub-layer. On expiration of the timer, the NLME sets macAssociationPermit 6
to FALSE by issuing the MLME-SET.request primitive. 7
8
Every NLME-PERMIT-JOINING.request primitive issued by the next higher 9
layer supersedes all previous requests. 10
11
3.2.2.6 NLME-PERMIT-JOINING.confirm 12
This primitive allows the next higher layer of a ZigBee coordinator or router to be 13
notified of the results of its request to permit the acceptance of devices onto the 14
network. 15
16
3.2.2.6.1 Semantics of the Service Primitive 17
The semantics of this primitive are as follows: 18
19
NLME-PERMIT-JOINING.confirm { 20
Status 21
} 22
23
Table 3.12 specifies the parameters for the NLME-PERMIT-JOINING.confirm 24
primitive. 25
26
Table 3.12 NLME-PERMIT-JOINING.confirm Parameters 27
Name Type Valid Range Description 28
29
Status Status INVALID_REQUEST The status of the corresponding request 30
or any status returned from
the MLME-SET.confirm 31
primitive (see [B1]). 32
33
3.2.2.6.2 When Generated 34
35
This primitive is generated by the initiating NLME of a ZigBee coordinator or 36
router and issued to its next higher layer in response to an NLME-PERMIT- 37
JOINING.request. The Status parameter either indicates the status received from 38
the MAC sub-layer or an error code of INVALID_REQUEST. The reasons for 39
these status values are described in sub-clause 3.2.2.5. 40
41
3.2.2.6.3 Effect on Receipt
42
On receipt of this primitive, the next higher layer of the initiating device is 43
notified of the results of its request to permit devices to join the network. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 277

3.2.2.7 NLME-START-ROUTER.request
1
This primitive allows the next higher layer of a ZigBee router to initiate the 2
activities expected of a ZigBee router including the routing of data frames, route 3
discovery, and the accepting of requests to join the network from other devices. 4
5
3.2.2.7.1 Semantics of the Service Primitive
6
The semantics of this primitive are as follows: 7
8
NLME-START-ROUTER.request {
9
BeaconOrder, 10
SuperframeOrder, 11
BatteryLifeExtension 12
} 13
14
Table 3.13 specifies the parameters for NLME-START-ROUTER.request. 15
16
Table 3.13 NLME-START-ROUTER.request Parameters
17
Name Type Valid Range Description 18
19
BeaconOrder Integer 0x00 – 0x0f The beacon order of the network that
the higher layers wish to form. 20
21
SuperframeOrder Integer 0x00 – 0x0f The superframe order of the network
22
that the higher layers wish to form.
23
BatteryLifeExtension Boolean TRUE or FALSE If this value is TRUE, the NLME will 24
request that the ZigBee router is started
supporting battery life extension mode; 25
If this value is FALSE, the NLME will 26
request that the ZigBee router is 27
started without supporting battery life 28
extension mode. 29
30
3.2.2.7.2 When Generated 31
32
This primitive is generated by the next higher layer of a new device and issued to
33
its NLME to request the initialization of itself as a ZigBee router.
34
3.2.2.7.3 Effect on Receipt 35
36
On receipt of this primitive by a device that is not already joined to a ZigBee 37
network as a router, the NLME issues the NLME-START-ROUTER.confirm 38
primitive with the Status parameter set to INVALID_REQUEST. 39
On receipt of this primitive by the NLME of a device that is joined to a ZigBee 40
network as a router, the NLME issues the MLME-START.request primitive to the 41
MAC sub-layer. The BeaconOrder, SuperframeOrder, and BatteryLifeExtension 42
parameters of the MLME-START.request primitive will have the values given by 43
the corresponding parameters of the NLME-START-ROUTER.request. The 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
278 Network Specification

CoordRealignment parameter in the MLME-START.request primitive is set to


FALSE if the primitive is issued to start as a router for the first time. The 1
CoordRealignment parameter is set to TRUE thereafter if the primitive is issued to 2
change any of the PAN configuration attributes. 3
4
On receipt of the associated MLME-START.confirm primitive, the NLME issues 5
the NLME-START-ROUTER.confirm primitive to the next higher layer with the 6
status returned from the MLME-START.confirm primitive. If, and only if, the 7
status returned from the MLME-START.confirm primitive is SUCCESS, the 8
device may then begin to engage in the activities expected of a ZigBee router 9
including the routing of data frames, route discovery, and the accepting of 10
requests to join the network from other devices. Otherwise, the device is expressly 11
forbidden to engage in these activities. 12
13
3.2.2.8 NLME-START-ROUTER.confirm 14
This primitive reports the results of the request to initialize a ZigBee router. 15
16
3.2.2.8.1 Semantics of the Service Primitive 17
The semantics of this primitive are as follows: 18
19
NLME-START-ROUTER.confirm { 20
Status 21
} 22
23
Table 3.14 specifies the parameters for NLME-START-ROUTER.confirm. 24
25
Table 3.14 NLME-START-ROUTER.confirm Parameters 26
Name Type Valid Range Description 27
28
Status Status INVALID_REQUEST The result of the attempt to initialize a 29
or any status value returned ZigBee router.
from the MLME- 30
START.confirm primitive. 31
32
3.2.2.8.2 When Generated 33
34
This primitive is generated by the NLME and issued to its next higher layer in 35
response to an NLME-START-ROUTER.request primitive. This primitive returns 36
a status value of INVALID_REQUEST or any status value returned from the 37
MLME-START.confirm primitive. Conditions under which these values may be 38
returned are described in sub-clause 3.2.2.7.3. 39
40
3.2.2.8.3 Effect on Receipt
41
On receipt of this primitive, the next higher layer is notified of the results of its 42
request to initialize a ZigBee router. If the NLME has been successful, the Status 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 279

parameter will be set to SUCCESS. Otherwise, the Status parameter indicates the
error. 1
2
3.2.2.9 NLME-ED-SCAN.request 3
4
This primitive allows the next higher layer to request an energy scan to evaluate 5
channels in the local area. 6
3.2.2.9.1 Semantics of the Service Primitive 7
8
The semantics of this primitive are as follows: 9
10
NLME-ED-SCAN.request {
11
ScanChannels,
12
ScanDuration,
13
} 14
15
Table 3.15 specifies the parameters for the service primitive. 16
Table 3.15 NLME-ED-SCAN.request Parameters 17
18
Valid 19
Name Type Range Description 20
ScanChannels Bitmap 32-bit field The five most significant bits (b27,..., 21
b31) are reserved. The 27 least 22
significant bits (b0, b1,... b26) indicate 23
which channels are to be scanned
24
(1=scan, 0=do not scan) for each of the
27 valid channels (see [B1]). 25
26
ScanDuration Integer 0x00-0x0e A value used to calculate the length of
time to spend scanning each channel. 27
The time spent scanning each channel is 28
(aBaseSuperframeDuration * (2n + 1)) 29
symbols, where n is the value of the 30
ScanDuration parameter [B1]. 31
32
3.2.2.9.2 When Generated 33
34
The next higher layer of a device generates this primitive to request to conduct an
35
energy scan of channels.
36
3.2.2.9.3 Effect on Receipt 37
38
On receipt of this primitive by a device that is currently joined to a network, the 39
device will temporarily stop operating on the network to conduct an energy scan. 40
To do this, the NLME issues the MLME-SCAN.request primitive to the MAC 41
sub-layer with the ScanType parameter set to indicate an energy detection scan 42
and the ScanChannels and ScanDuration from the NLME request. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
280 Network Specification

3.2.2.10 NLME-ED-SCAN.confirm
1
This primitive provides the next higher layer results from an energy scan. 2
3
3.2.2.10.1 Semantics of the Service Primitive
4
The semantics of this primitive are as follows: 5
6
NLME-ED-SCAN.confirm {
7
Status 8
UnscannedChannels, 9
EnergyDetectList 10
} 11
12
Table 3.16 specifies the parameters for the service primitive. 13
14
Table 3.16 NLME-ED-SCAN.confirm
15
Valid 16
Name Type Range Description 17
Status Status SUCCESS, The status of the request. 18
or any valid 19
code from 20
the MAC 21
UnscannedChann Bitmap 32 bit field The five most significant bits (b27,..., 22
els b31) are reserved. The 27 least 23
significant bits (b0, b1,... b26) indicate 24
which channels were not scanned
25
(0=scan, 1=did not scan) for each of the
27 valid channels (see [B1]). Note this is 26
the UnscannedChannel list of [B1]. 27
EnergyDetectList List of 0x00-0xff for The list of energy measurements in 28
integers each integer accordance with [B1], one for each 29
channel. 30
31
3.2.2.10.2 When Generated 32
33
This primitive is generated by the NLME of a ZigBee device in response to an 34
NLME-ED-SCAN.request. The status indicates the status received from the MAC 35
sub-layer primitive MLME-SCAN.confirm. UnscannedChannels indicates which 36
channels were not scanned (0= channel scanned). EnergyDetectList contains the 37
ED scan result (List of integers, 0x00 - 0xff) for the channels scanned in 38
accordance with IEEE 802.15.4-2003. 39
3.2.2.10.3 Effect on Receipt 40
41
On receipt of this primitive, the next higher layer is notified of the results of an 42
ED scan. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 281

3.2.2.11 NLME-JOIN.request
1
This primitive allows the next higher layer to request to join or rejoin a network, 2
or to change the operating channel for the device while within an operating 3
network. 4
5
3.2.2.11.1 Semantics of the Service Primitive
6
The semantics of this primitive are as follows: 7
8
NLME-JOIN.request {
9
ExtendedPANId, 10
RejoinNetwork, 11
ScanChannels, 12
ScanDuration, 13
CapabilityInformation, 14
SecurityEnable 15
} 16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
282 Network Specification

Table 3.17 specifies the parameters for the NLME-JOIN.request primitive.


1
Table 3.17 NLME-JOIN.request Parameters
2
Name Type Valid Range Description 3
4
ExtendedPANId Integer 0x0000000000000 The 64-bit PAN identifier of the network
5
001 – to join.
0xfffffffffffffffe 6
7
RejoinNetwork Integer 0x00 – 0x03 This parameter controls the method of
joining the network. 8
9
The parameter is 0x00 if the device is 10
requesting to join a network through
association. 11
12
The parameter is 0x01 if the device is 13
joining directly or rejoining the network
using the orphaning procedure. 14
15
The parameter is 0x02 if the device is 16
joining the network using the NWK
rejoining procedure. 17
18
The parameter is 0x03 if the device is to 19
change the operational network channel to
that identified in the ScanChannels 20
parameter. 21
22
ScanChannels Bitmap 32-bit field The five most significant bits (b27,..., b31)
are reserved. The 27 least significant bits 23
(b0, b1,... b26) indicate which channels 24
are to be scanned (1=scan, 0=do not scan) 25
for each of the 27 valid channels (see 26
[B1]).
27
ScanDuration Integer 0x00-0x0e A value used to calculate the length of 28
time to spend scanning each channel. The 29
time spent scanning each channel is
(aBaseSuperframeDuration * (2n + 1)) 30
symbols, where n is the value of the 31
ScanDuration parameter [B1]. 32
CapabilityInfor Bitmap See Table 3.47 The operating capabilities of the device 33
mation being directly joined. 34
SecurityEnable Boolean TRUE or FALSE If the value of RejoinNetwork is 0x02 and 35
this is TRUE than the device will try to 36
rejoin securely. 37
Otherwise, this is set to FALSE. 38
39
40
3.2.2.11.2 When Generated 41
The next higher layer of a device generates this primitive to request to: 42
43
• Join a network using the MAC association procedure. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 283

• Join or rejoin a network using the orphaning procedure.


1
• Join or rejoin a network using the NWK rejoin procedure. 2
• Switch the operating channel for a device that is joined to a network. 3
4
3.2.2.11.3 Effect on Receipt 5
On receipt of this primitive by a device that is currently joined to a network and 6
with the RejoinNetwork parameter equal to 0x00, the NLME issues an NLME- 7
JOIN.confirm primitive with the Status parameter set to INVALID_REQUEST. 8
9
On receipt of this primitive by a device that is not currently joined to a network 10
and with the RejoinNetwork parameter equal to 0x00, the device attempts to join 11
the network specified by the 64-bit ExtendedPANId parameter as described in 12
sub-clause 3.6.1.4.1.1. 13
If a device receives this primitive and the RejoinNetwork parameter is equal to 14
0x01, then it attempts to join or rejoin the network using orphaning as described in 15
sub-clause 3.6.1.4.3.2. 16
17
On receipt of this primitive with the RejoinNetwork parameter is equal to 0x02, 18
the device attempts to rejoin the network with 64-bit extended PAN ID given by 19
the ExtendedPANId parameter. The procedure for rejoining is given in sub- 20
clause 3.6.1.4.2. 21
Once the device has successfully joined a network, it will set the value of the 22
nwkExtendedPANId NIB attribute to the extended PAN identifier of the network to 23
which it joined. 24
25
If a device receives this primitive and the RejoinNetwork parameter is equal to 26
0x03, and the device supports setting the value of phyCurrentChannel then the 27
device attempts to switch the operating channel to that provided in the 28
ScanChannels parameter. If more than one channel is provided in the 29
ScanChannels parameter, the NLME issues an NLME-JOIN.confirm primitive 30
with the Status parameter set to INVALID_REQUEST. If the channel change is 31
performed successfully, then the device issues a NLME-JOIN.confirm with the 32
Status parameter set to SUCCESS. If the device does not support the setting of 33
phyCurrentChannel directly, then the NLME issues a NLME-JOIN.confirm 34
primitive with the Status parameter set to UNSUPPORTED_ATTRIBUTE.12 35
36
3.2.2.12 NLME-JOIN.indication 37
This primitive allows the next higher layer of a ZigBee coordinator or ZigBee 38
router to be notified when a new device has successfully joined its network by 39
association or rejoined using the NWK rejoin procedure as described in sub- 40
clause 3.6.1.4.3. 41
42
43
12. CCB #820 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
284 Network Specification

3.2.2.12.1 Semantics of the Service Primitive


1
The semantics of this primitive are as follows: 2
NLME-JOIN.indication { 3
4
NetworkAddress,
5
ExtendedAddress,
6
CapabilityInformation,
7
RejoinNetwork 8
SecureRejoin 9
} 10
11
Table 3.18 specifies the parameters for the NLME-JOIN.indication primitive. 12
Table 3.18 NLME-JOIN.indication Parameters
13
14
Name Type Valid Range Description 15
16
NetworkAddress Network 0x0001 – 0xfff7 The network address of an entity that has
address been added to the network. 17
18
ExtendedAddress 64-bit Any 64-bit, IEEE The 64-bit IEEE address of an entity that
IEEE address has been added to the network. 19
address 20
21
CapabilityInformation Bitmap See [B1] Specifies the operational capabilities of
the joining device. 22
23
RejoinNetwork Integer 0x00 - 0x02 The RejoinNetwork parameter
indicating the method used to join the 24
network. 25
26
The parameter is 0x00 if the device
joined through association. 27
28
The parameter is 0x01 if the device 29
joined directly or rejoined using
orphaning. 30
31
The parameter is 0x02 if the device used 32
NWK rejoin.a
33
SecureRejoin Boolean TRUE or FALSE This parameter will be TRUE if the 34
rejoin was performed in a secure
35
manner. Otherwise, this parameter will
be FALSE. 36
37
a. CCB #821 38
3.2.2.12.2 When Generated 39
40
This primitive is generated by the NLME of a ZigBee coordinator or router and 41
issued to its next higher layer on successfully adding a new device to the network 42
using the MAC association procedure as shown in Figure 3.35, or on allowing a 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 285

device to rejoin the network using the NWK rejoining procedure as shown in
Figure 3.40. 1
2
3.2.2.12.3 Effect on Receipt 3
On receipt of this primitive, the next higher layer of a ZigBee coordinator or 4
ZigBee router is notified that a new device has joined its network. 5
6
3.2.2.13 NLME-JOIN.confirm 7
8
This primitive allows the next higher layer to be notified of the results of its 9
request to join a network. 10
3.2.2.13.1 Semantics of the Service Primitive 11
12
The semantics of this primitive are as follows: 13
14
NLME-JOIN.confirm {
15
Status,
16
NetworkAddress, 17
ExtendedPANID, 18
ActiveChannel 19
} 20
21
Table 3.19 specifies the parameters for the NLME-JOIN.confirm primitive. 22
23
Table 3.19 NLME-JOIN.confirm Parameters
24
Name Type Valid Range Description 25
26
Status Status INVALID_REQUEST, The status of the corresponding
NOT_PERMITTED, request. 27
NO_NETWORKS 28
29
or any status value
returned from the MLME- 30
ASSOCIATE.confirm 31
primitive or the MLME- 32
SCAN.confirm primitive. 33
NetworkAddress Integer 0x0001 – 0xfff7 and 0xffff The 16-bit network address that 34
was allocated to this device. This 35
parameter will be equal to 0xffff if 36
the join attempt was unsuccessful.
37
ExtendedPANID Integer 0x0000000000000001 – The 64-bit extended PAN 38
0xfffffffffffffffe identifier for the network of which 39
the device is now a member.
40
ActiveChannel Integer The number of any The value of phyCurrentChannel 41
channel supported by the attribute of the PHY PIB, which is
42
PHY (see [B1]). equal to the current channel of the
network that has been joined. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
286 Network Specification

3.2.2.13.2 When Generated


1
This primitive is generated by the initiating NLME and issued to its next higher 2
layer in response to an NLME-JOIN.request primitive. If the request was 3
successful, the Status parameter will have a value of SUCCESS. Otherwise, the 4
Status parameter indicates an error code of INVALID_REQUEST, 5
NOT_PERMITTED, NO_NETWORKS or any status value returned from either 6
the MLME-ASSOCIATE.confirm primitive or the MLME-SCAN.confirm 7
primitive. The reasons for these status values are fully described in sub- 8
clause 3.2.2.11.3. 9
3.2.2.13.3 Effect on Receipt 10
11
On receipt of this primitive, the next higher layer of the initiating device is 12
notified of the results of its request to join a network using the MAC sub-layer 13
association procedure, to join directly using the MAC sub-layer orphaning 14
procedure, or to re-join a network once it has been orphaned. 15
16
3.2.2.14 NLME-DIRECT-JOIN.request 17
18
This optional primitive allows the next higher layer of a ZigBee coordinator or
19
router to request to directly join another device to its network.
20
3.2.2.14.1 Semantics of the Service Primitive 21
22
The semantics of this optional primitive are as follows: 23
NLME-DIRECT-JOIN.request { 24
DeviceAddress, 25
CapabilityInformation 26
} 27
28
29
Table 3.20 specifies the parameters for the NLME-DIRECT-JOIN.request 30
primitive. 31
Table 3.20 NLME-DIRECT-JOIN.request Parameters 32
33
Name Type Valid Range Description
34
DeviceAddress 64-bit IEEE Any 64-bit IEEE address The IEEE address of the 35
address device to be directly joined. 36
CapabilityInformation Bitmap See Table 3.47 The operating capabilities 37
of the device being directly 38
joined. 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 287

3.2.2.14.2 When Generated


1
The next higher layer of a ZigBee coordinator or router generates this primitive to 2
add a new device directly to its network. This process is completed without any 3
over the air transmissions. 4
3.2.2.14.3 Effect on Receipt 5
6
On receipt of this primitive, the NLME will attempt to add the device specified by 7
the DeviceAddress parameter to its neighbor table. The CapabilityInformation 8
parameter will contain a description of the device being joined. The alternate PAN 9
coordinator bit is set to 0 in devices implementing this specification. The device 10
type bit is set to 1 if the device is a ZigBee router, or to 0 if it is an end device. The 11
power source bit is set to 1 if the device is receiving power from the alternating 12
current mains or to 0 otherwise. The receiver on when idle bit is set to 1 if the 13
device does not disable its receiver during idle periods, or to 0 otherwise. The 14
security capability bit is set to 1 if the device is capable of secure operation, or to 15
0 otherwise. 16
If the NLME successfully adds the device to its neighbor table, the NLME issues 17
the NLME-DIRECT-JOIN.confirm primitive with a status of SUCCESS. If the 18
NLME finds that the requested device is already present in its neighbor tables, the 19
NLME issues the NLME-DIRECT-JOIN.confirm primitive with a status of 20
ALREADY_PRESENT. If no capacity is available to add a new device to the 21
device list, the NLME issues the NLME-DIRECT-JOIN.confirm primitive with a 22
status of NEIGHBOR_TABLE_FULL. 23
24
3.2.2.15 NLME-DIRECT-JOIN.confirm 25
26
This primitive allows the next higher layer of a ZigBee coordinator or router to be 27
notified of the results of its request to directly join another device to its network. 28
29
3.2.2.15.1 Semantics of the Service Primitive
30
The semantics of this primitive are as follows: 31
32
NLME-DIRECT-JOIN.confirm {
33
Status, 34
DeviceAddress 35
} 36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
288 Network Specification

Table 3.21 specifies the parameters for the NLME-DIRECT-JOIN.confirm


primitive. 1
2
Table 3.21 NLME-DIRECT-JOIN.confirm Parameters
3
Name Type Valid Range Description 4
5
Status Status SUCCESS, The status of the corresponding
6
ALREADY_PRESENT, request.
NEIGHBOR_TABLE_FUL 7
L 8
DeviceAddress 64-bit Any 64-bit, IEEE address The 64-bit IEEE address in the 9
IEEE request to which this is a 10
address confirmation. 11
12
3.2.2.15.2 When Generated 13
14
This primitive is generated by the initiating NLME and issued to its next higher 15
layer in response to an NLME-DIRECT-JOIN.request primitive. If the request 16
was successful, the Status parameter indicates a successful join attempt. 17
Otherwise, the Status parameter indicates an error code of 18
ALREADY_PRESENT or NEIGHBOR_TABLE_FULL. The reasons for these 19
status values are fully described in sub-clause 3.2.2.14.3. 20
3.2.2.15.3 Effect on Receipt 21
22
On receipt of this primitive, the next higher layer of the initiating device is 23
notified of the results of its request to directly join another device to a network. 24
25
3.2.2.16 NLME-LEAVE.request 26
27
This primitive allows the next higher layer to request that it or another device
28
leaves the network.
29
3.2.2.16.1 Semantics of the Service Primitive 30
31
The semantics of this primitive are as follows: 32
NLME-LEAVE.request { 33
DeviceAddress, 34
RemoveChildren, 35
Rejoin 36
37
}
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 289

Table 3.22 specifies the parameters for the NLME-LEAVE.request primitive.


1
Table 3.22 NLME-LEAVE.request Parameters
2
Name Type Valid Range Description 3
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
RemoveChildren Boolean TRUE or FALSE This parameter has a value of TRUE if 8
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 TRUE if 13
the device being asked to leave from 14
the current parent is requested to rejoin
15
the network. Otherwise, the parameter
has a value of FALSE. 16
17
18
3.2.2.16.2 When Generated
19
The next higher layer of a device generates this primitive to request to leave the 20
network. The next higher layer of a ZigBee coordinator or router may also 21
generate this primitive to remove a device from the network. 22
23
3.2.2.16.3 Effect on Receipt 24
On receipt of this primitive by the NLME of a device that is not currently joined to 25
a network, the NLME issues the NLME-LEAVE.confirm primitive with a status 26
of INVALID_REQUEST. On receipt of this primitive by the NLME of a device 27
that is currently joined to a network, with the DeviceAddress parameter equal to 28
NULL and the RemoveChildren parameter equal to FALSE, the NLME will 29
remove itself from the network using the procedure described in sub- 30
clause 3.6.1.10.1. The NLME will then clear its routing table and route discovery 31
table and issue an MLME-RESET.request primitive to the MAC sub-layer. The 32
NLME will also set the relationship field of the neighbor table entry 33
corresponding to its former parent to 0x03, indicating no relationship. If the 34
NLME-LEAVE.request primitive is received with the DeviceAddress parameter 35
equal to NULL and the RemoveChildren parameter equal to TRUE, then the 36
NLME will attempt to remove the device's children, as described in sub- 37
clause 3.6.1.10.3. 38
39
On receipt of this primitive by a ZigBee coordinator or ZigBee router and with the 40
DeviceAddress parameter not equal to NULL, the NLME determines whether the 41
specified device is a child device. If the requested device does not exist, the 42
NLME issues the NLME-LEAVE.confirm primitive with a status of 43
UNKNOWN_DEVICE. If the requested device exists, the NLME will attempt to 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
290 Network Specification

remove it from the network using the procedure described in sub-


clause 3.6.1.10.3. If the RemoveChildren parameter is equal to TRUE then the 1
device will be requested to remove its children as well. Following the removal, the 2
NLME will issue the NLME-LEAVE.confirm primitive with the DeviceAddress 3
equal to the 64-bit IEEE address of the removed device and the Status parameter 4
equal to the status delivered by the MCPS-DATA.confirm primitive. If the 5
relationship field of the neighbor table entry corresponding to the leaving device 6
has a value of 0x01 then it will be changed to 0x04 indicating previous child. If it 7
has a value of 0x05, indicating that the child has not yet authenticated, it will be 8
changed to 0x03, indicating no relationship. 9
10
3.2.2.17 NLME-LEAVE.indication 11
12
This primitive allows the next higher layer of a ZigBee device to be notified if that 13
ZigBee device has left the network or if a neighboring device has left the network. 14
3.2.2.17.1 Semantics of the Service Primitive 15
16
The semantics of this primitive are as follows: 17
18
NLME-LEAVE.indication {
19
DeviceAddress,
20
Rejoin
21
} 22
23
Table 3.23 specifies the parameters for the NLME-LEAVE.indication primitive. 24
Table 3.23 NLME-LEAVE.indication Parameters 25
26
Name Type Valid Range Description 27
DeviceAddress 64-bit Any 64-bit, IEEE address The 64-bit IEEE address of an entity 28
IEEE that has removed itself from the 29
address network or NULL in the case that 30
the device issuing the primitive has 31
been removed from the network by
32
its parent.
33
Rejoin Boolean TRUE or FALSE This parameter has a value of TRUE 34
if the device being asked to leave the
current parent is requested to rejoin 35
the network. Otherwise, this 36
parameter has a value of FALSE. 37
38
3.2.2.17.2 When Generated 39
40
This primitive is generated by the NLME of a ZigBee coordinator or ZigBee 41
router and issued to its next higher layer on receipt of a broadcast leave command 42
pertaining to a device on its PAN. It is also generated by the NLME of a ZigBee 43
router or end device and issued to its next higher layer to indicate that it has been 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 291

successfully removed from the network by its associated router or ZigBee


coordinator. 1
2
3.2.2.17.3 Effect on Receipt 3
On receipt of this primitive, the next higher layer of a ZigBee coordinator or 4
ZigBee router is notified that a device, formerly on the network, has left. The 5
primitive can also inform the next higher layer of a ZigBee router or end device 6
that it has been removed from the network by its associated ZigBee router or 7
ZigBee coordinator parent. In this case, the value of the Rejoin parameter 8
indicates to the next higher layer whether the peer entity on the parent device 9
wishes the device that has been removed to rejoin the same network. 10
11
3.2.2.18 NLME-LEAVE.confirm 12
13
This primitive allows the next higher layer of the initiating device to be notified of 14
the results of its request for itself or another device to leave the network. 15
3.2.2.18.1 Semantics of the Service Primitive 16
17
The semantics of this primitive are as follows: 18
19
NLME-LEAVE.confirm {
20
Status,
21
DeviceAddress 22
} 23
24
Table 3.24 specifies the parameters for the NLME-LEAVE.confirm primitive. 25
Table 3.24 NLME-LEAVE.confirm Parameters 26
27
Name Type Valid Range Description 28
Status Status SUCCESS, INVALID_REQUEST, The status of the 29
UNKNOWN_DEVICE or any corresponding request. 30
status returned by the MCPS- 31
DATA.confirm primitive 32
DeviceAddress 64-bit Any 64-bit, IEEE address The 64-bit IEEE address 33
IEEE in the request to which 34
address this is a confirmation or 35
null if the device
36
requested to remove
itself from the network. 37
38
39
3.2.2.18.2 When Generated
40
This primitive is generated by the initiating NLME and issued to its next higher 41
layer in response to an NLME-LEAVE.request primitive. If the request was 42
successful, the Status parameter indicates a successful leave attempt. Otherwise, 43
the Status parameter indicates an error code of INVALID_REQUEST, 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
292 Network Specification

UNKNOWN_DEVICE or a status delivered by the MCPS-DATA.confirm


primitive. The reasons for these status values are fully described in sub- 1
clause 3.2.2.16.3. 2
3
3.2.2.18.3 Effect on Receipt 4
On receipt of this primitive, the next higher layer of the initiating device is 5
notified of the results of its request for itself or a child device to leave the network. 6
7
3.2.2.19 NLME-RESET.request 8
9
This primitive allows the next higher layer to request the NWK layer to perform a 10
reset operation. 11
3.2.2.19.1 Semantics of the Service Primitive 12
13
The semantics of this primitive are as follows: 14
15
NLME-RESET.request {
16
WarmStart
17
} 18
19
Table 3.26 specifies the parameters for this primitive. 20
Table 3.25 NLME-RESET.request Parameters 21
22
Name Type Valid Range Description 23
WarmStart Boolean TRUE or FALSE This parameter has a value of FALSE if 24
the request is expected reset all stack 25
values to their initial default values. If this 26
value is TRUE, the device is expected to 27
resume operations according to the NIB
28
settings prior to the call.
29
30
3.2.2.19.2 When Generated 31
This primitive is generated by the next higher layer and issued to its NLME to 32
request the NWK layer be reset to its initial condition, or that it resume operations 33
according to its current NIB values prior to this primitive being issued. 34
35
3.2.2.19.3 Effect on Receipt 36
On receipt of this primitive, where the WarmStart parameter has a value of 37
FALSE, the NLME issues the MLME-RESET.request primitive to the MAC sub- 38
layer with the SetDefaultPIB parameter set to TRUE. On receipt of the 39
corresponding MLME-RESET.confirm primitive, the NWK layer resets itself by 40
clearing all internal variables, routing table and route discovery table entries and 41
by setting all NIB attributes to their default values. Once the NWK layer is reset, 42
the NLME issues the NLME-RESET.confirm with the Status parameter set to 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 293

SUCCESS if the MAC sub-layer was successfully reset or


DISABLE_TRX_FAILURE otherwise. 1
2
On receipt of this primitive where WarmStart is set to TRUE, the network layer 3
should not modify any NIB values, but rather should resume normal network 4
operations and consider itself part of the network specified in the NIB. Routing 5
table values and neighbor table values should be cleared. The method by which 6
the network and MAC layers attributes are pre-loaded is left to the implementer. 7
If this primitive is issued to the NLME of a device that is currently joined to a 8
network, any required leave attempts using the NLME-LEAVE.request primitive 9
should be made a priori at the discretion of the next higher layer. 10
11
3.2.2.20 NLME-RESET.confirm 12
13
This primitive allows the next higher layer of the initiating device to be notified of 14
the results of the request to reset the NWK layer. 15
3.2.2.20.1 Semantics of the Service Primitive 16
17
The semantics of this primitive are as follows: 18
19
NLME-RESET.confirm {
20
Status
21
}
22
23
Table 3.26 specifies the parameters for this primitive. 24
Table 3.26 NLME-RESET.confirm Parameters 25
26
Name Type Valid Range Description 27
Status Status Any status value returned The result of the reset operation 28
from the MLME- 29
RESET.confirm primitive 30
(see [B1]) 31
32
3.2.2.20.2 When Generated 33
34
This primitive is generated by the NLME and issued to its next higher layer in
35
response to an NLME-RESET.request primitive. If the request was successful, the
36
Status parameter will have a value of SUCCESS. Otherwise, the Status parameter
37
will indicate an error code of DISABLE_TRX_FAILURE. The reasons for these
38
status values are fully described in sub-clause 3.2.2.19.3.
39
3.2.2.20.3 Effect on Receipt 40
41
On receipt of this primitive, the next higher layer is notified of the results of its 42
request to reset the NWK layer. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
294 Network Specification

3.2.2.21 Network Layer Reset Message Sequence Chart


1
Figure 3.2 illustrates the sequence of messages necessary for resetting the NWK 2
layer. 3
4
5
Device Device Device 6
APL NWK MAC 7
8
NLME- 9
RESET.request MLME- 10
RESET.request 11
12
MLME-RESET.confirm 13
(SUCCESS) 14
15
16
17
18
Clear internal state
19
20
NLME-RESET.confirm 21
(SUCCESS) 22
23
24
25
Figure 3.2 Message Sequence Chart for Resetting the Network Layer 26
27
3.2.2.22 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
3.2.2.22.1 Semantics of the Service Primitive 32
33
The semantics of this primitive are as follows:
34
NLME-SYNC.request { 35
Track 36
} 37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 295

Table 3.27 specifies the parameters for this primitive.


1
Table 3.27 NLME-SYNC.request Parameters
2
Name Type Valid Range Description 3
4
Track Boolean TRUE or FALSE Whether or not the synchronization should 5
be maintained for future beacons.
6
7
3.2.2.22.2 When Generated 8
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
3.2.2.22.3 Effect on Receipt 12
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.2.2.23 NLME-SYNC-LOSS.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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
296 Network Specification

3.2.2.23.1 Semantics of the Service Primitive


1
The semantics of this primitive are as follows: 2
NLME-SYNC-LOSS.indication { 3
4
}
5
6
This primitive has no parameters. 7
3.2.2.23.2 When Generated 8
9
This primitive is generated upon receipt of a loss of synchronization notification 10
from 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
3.2.2.23.3 Effect on Receipt 14
15
The next higher layer is notified of the loss of synchronization with the beacon. 16
17
3.2.2.24 NLME-SYNC.confirm 18
This primitive allows the next higher layer to be notified of the results of its 19
request to synchronize or extract data from its ZigBee coordinator or router. 20
21
3.2.2.24.1 Semantics of the Service Primitive 22
The semantics of this primitive are as follows: 23
24
NLME-SYNC.confirm { 25
Status 26
} 27
28
Table 3.28 specifies the parameters for this primitive. 29
30
Table 3.28 NLME-SYNC.confirm Parameters 31
Name Type Valid Range Description 32
33
Status Status SUCCESS, The result of the request to synchronize with 34
SYNC_FAILURE, the ZigBee coordinator or router.
INVALID_PARAME 35
TER, or any status 36
value returned from the 37
MLME_POLL.confirm 38
primitive (see [B1]) 39
40
3.2.2.24.2 When Generated 41
42
This primitive is generated by the initiating NLME and issued to its next higher
43
layer in response to an NLME-SYNC.request primitive. If the request was
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 297

successful, the Status parameter indicates a successful synchronization attempt.


Otherwise, the Status parameter indicates an error code. The reasons for these 1
status values are fully described in sub-clause 3.2.2.22.2. 2
3
3.2.2.24.3 Effect on Receipt 4
On receipt of this primitive, the next higher layer is notified of the results of its 5
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.2.2.25 Message Sequence Charts For Synchronization 10
11
Figure 3.3 and Figure 3.4 illustrate the sequence of messages necessary for a 12
device to successfully synchronize with a ZigBee coordinator or ZigBee router. 13
Figure 3.3 illustrates the case for a non-beaconing network, and Figure 3.4 14
illustrates the case for a beaconing network. 15
16
17
Device Device Device 18
APL NWK MAC 19
20
NLME-SYNC.request 21
(TRACK=FALSE)
22
23
MLME- 24
POLL.request 25
26
27
MLME-POLL.confirm 28
(SUCCESS) 29
30
31
NLME-SYNC.confirm 32
(SUCCESS) 33
34
35
36
37
Figure 3.3 Message Sequence Chart for Synchronizing in a Non-Beaconing
Network 38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
298 Network Specification

Device Device Device 1


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
3.2.2.26 NLME-GET.request 24
25
This primitive allows the next higher layer to read the value of an attribute from 26
the NIB. 27
3.2.2.26.1 Semantics of the Service Primitive 28
29
The semantics of this primitive are as follows: 30
NLME-GET.request { 31
32
NIBAttribute
33
}
34
35
Table 3.29 specifies the parameters for this primitive. 36
Table 3.29 NLME-GET.request Parameters 37
38
Name Type Valid Range Description 39
NIBAttribute Integer See Table 3.44 The identifier of the NIB attribute to read. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 299

3.2.2.26.2 When Generated


1
This primitive is generated by the next higher layer and issued to its NLME in 2
order to read an attribute from the NIB. 3
3.2.2.26.3 Effect on Receipt 4
5
On receipt of this primitive, the NLME attempts to retrieve the requested NIB 6
attribute from its database. If the identifier of the NIB attribute is not found in the 7
database, the NLME issues the NLME-GET.confirm primitive with a status of 8
UNSUPPORTED_ATTRIBUTE. 9
If the requested NIB attribute is successfully retrieved, the NLME issues the 10
NLME-GET.confirm primitive with a status of SUCCESS and the NIB attribute 11
identifier and value. 12
13
3.2.2.27 NLME-GET.confirm 14
15
This primitive reports the results of an attempt to read the value of an attribute 16
from the NIB. 17
18
3.2.2.27.1 Semantics of the Service Primitive
19
The semantics of this primitive are as follows: 20
21
NLME-GET.confirm {
22
Status, 23
NIBAttribute, 24
NIBAttributeLength, 25
NIBAttributeValue 26
} 27
28
Table 3.30 specifies the parameters for this primitive. 29
30
Table 3.30 NLME-GET.confirm Parameters
31
Name Type Valid Range Description 32
33
Status Enumeration SUCCESS or The results of the request to read a
34
UNSUPPORTED NIB attribute value.
_ATTRIBUTE 35
36
NIBAttribute Integer See Table 3.44 The identifier of the NIB attribute
that was read. 37
38
NIBAttributeLength Integer 0x0000 – 0xffff The length, in octets, of the
39
attribute value being returned.
40
NIBAttributeValue Various Attribute specific The value of the NIB attribute that 41
(see Table 3.44) was read.
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
300 Network Specification

3.2.2.27.2 When Generated


1
This primitive is generated by the NLME and issued to its next higher layer in 2
response to an NLME-GET.request primitive. This primitive returns either a 3
status of SUCCESS, indicating that the request to read a NIB attribute was 4
successful, or an error code of UNSUPPORTED_ATTRIBUTE. The reasons for 5
these status values are fully described in sub-clause 3.2.2.26.3. 6
3.2.2.27.3 Effect on Receipt 7
8
On receipt of this primitive, the next higher layer is notified of the results of its 9
request to read a NIB attribute. If the request to read a NIB attribute was 10
successful, the Status parameter will be set to SUCCESS. Otherwise, the Status 11
parameter indicates the error. 12
13
3.2.2.28 NLME-SET.request 14
15
This primitive allows the next higher layer to write the value of an attribute into
16
the NIB.
17
3.2.2.28.1 Semantics of the Service Primitive 18
19
The semantics of this primitive are as follows: 20
NLME-SET.request { 21
NIBAttribute, 22
NIBAttributeLength, 23
NIBAttributeValue 24
25
}
26
27
Table 3.31 specifies the parameters for this primitive. 28
Table 3.31 NLME-SET.request Parameters 29
30
Name Type Valid Range Description
31
NIBAttribute Integer See Table 3.44 The identifier of the NIB attribute 32
to be written. 33
NIBAttributeLength Integer 0x0000 – 0xffff The length, in octets, of the 34
attribute value being set. 35
NIBAttributeValue Various Attribute specific The value of the NIB attribute that 36
(see Table 3.44) should be written. 37
38
3.2.2.28.2 When Generated 39
40
This primitive is to be generated by the next higher layer and issued to its NLME 41
in order to write the value of an attribute in the NIB. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 301

3.2.2.28.3 Effect on Receipt


1
On receipt of this primitive the NLME attempts to write the given value to the 2
indicated NIB attribute in its database. If the NIBAttribute parameter specifies an 3
attribute that is not found in the database, the NLME issues the NLME- 4
SET.confirm primitive with a status of UNSUPPORTED_ATTRIBUTE. If the 5
NIBAttributeValue parameter specifies a value that is out of the valid range for the 6
given attribute, the NLME issues the NLME-SET.confirm primitive with a status 7
of INVALID_PARAMETER. 8
If the requested NIB attribute is successfully written, the NLME issues the 9
NLME-SET.confirm primitive with a status of SUCCESS. 10
11
3.2.2.29 NLME-SET.confirm 12
13
This primitive reports the results of an attempt to write a value to a NIB attribute. 14
3.2.2.29.1 Semantics of the Service Primitive 15
16
The semantics of this primitive are as follows: 17
18
NLME-SET.confirm {
19
Status,
20
NIBAttribute 21
} 22
23
Table 3.32 specifies the parameters for this primitive. 24
Table 3.32 NLME-SET.confirm Parameters 25
26
Name Type Valid Range Description 27
Status Enumeration SUCCESS, The result of the request to 28
INVALID_PARAMETER or write the NIB attribute. 29
UNSUPPORTED_ATTRIBUTE 30
NIBAttribute Integer See Table 3.44 The identifier of the NIB 31
attribute that was written. 32
33
3.2.2.29.2 When Generated 34
35
This primitive is generated by the NLME and issued to its next higher layer in 36
response to an NLME-SET.request primitive. This primitive returns a status of 37
either SUCCESS, indicating that the requested value was written to the indicated 38
NIB attribute, or an error code of INVALID_PARAMETER or 39
UNSUPPORTED_ATTRIBUTE. The reasons for these status values are fully 40
described in sub-clause 3.2.2.28.3. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
302 Network Specification

3.2.2.29.3 Effect on Receipt


1
On receipt of this primitive, the next higher layer is notified of the results of its 2
request to write the value of a NIB attribute. If the requested value was written to 3
the indicated NIB attribute, the Status parameter will be set to SUCCESS. 4
Otherwise, the Status parameter indicates the error. 5
6
3.2.2.30 NLME-NWK-STATUS.indication 7
This primitive allows the next higher layer to be notified of network failures. 8
9
3.2.2.30.1 Semantics of the Service Primitive 10
11
The semantics of this primitive are as follows:
12
NLME-NWK-STATUS.indication { 13
Status, 14
NetworkAddr 15
} 16
17
18
Table 3.33 specifies the parameters for this primitive.
19
Table 3.33 NLME-NWK-STATUS.indication Parameters 20
Name Type Valid Range Description 21
22
Status Status Any network The error code associated with the failure. 23
status code (see 24
Table 3.42)
25
NetworkAddr Integer 0x0000 – 0xfff7 The 16-bit network address of the device 26
associated with the status information.
27
28
3.2.2.30.2 When Generated 29
This primitive is generated by the NWK layer on a device and passed to the next 30
higher layer when one of the following occurs: 31
32
• The device has failed to discover or repair a route to the destination given by 33
the NetworkAddr parameter. 34
• The NWK layer on that device has failed to deliver a frame to its end device 35
child with the 16-bit network address given by the NetworkAddr parameter, 36
due to one of the reasons given in Table 3.42. 37
38
• The NWK layer has received a network status command frame destined for the 39
device. In this case, the values of the NetworkAddr and Status parameters will 40
reflect the values of the destination address and error code fields of the 41
command frame. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 303

3.2.2.30.3 Effect on Receipt


1
The next higher layer is notified of a failure to communicate with the identified 2
device. 3
4
3.2.2.31 NLME-ROUTE-DISCOVERY.request 5
This primitive allows the next higher layer to initiate route discovery. 6
7
3.2.2.31.1 Semantics of the Service Primitive 8
9
The semantics of this primitive are as follows:
10
NLME-ROUTE-DISCOVERY.request { 11
DstAddrMode, 12
DstAddr, 13
Radius 14
NoRouteCache 15
16
}
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
304 Network Specification

Table 3.34 specifies the parameters for this primitive.


1
Table 3.34 NLME-ROUTE-DISCOVERY.request Parameters
2
Valid 3
Name Type Range Description 4
5
DstAddrMode Integer 0x00 – 0x02 A parameter specifying the kind of
destination address provided. The 6
DstAddrMode parameter may take one of the 7
following three values: 8
0x00 = No destination address 9
0x01 = 16-bit network address of a multicast 10
group 11
0x02 = 16-bit network address of an 12
individual device 13
DstAddr 16-bit Any network The destination of the route discovery. 14
network address or 15
address multicast If the DstAddrMode parameter has a value of 16
address 0x00 then no DstAddr will be supplied. This
indicates that the route discovery will be a 17
many-to-one discovery with the device 18
issuing the discovery command as a target. 19
If the DstAddrMode parameter has a value of 20
0x01, indicating multicast route discovery 21
then the destination will be the 16-bit network 22
address of a multicast group. 23
If the DstAddrMode parameter has a value of 24
0x02, this indicates unicast route discovery. 25
The DstAddr will be the 16-bit network 26
address of a device to be discovered. 27
Radius Integer 0x00 – 0xff This optional parameter describes the number 28
of hops that the route request will travel 29
through the network.
30
NoRouteCache Boolean TRUE or In the case where DstAddrMode has a value 31
FALSE of zero, indicating many-to-one route 32
discovery, this flag determines whether the
NWK should establish a route record table. 33
34
TRUE = no route record table should be 35
established
36
FALSE = establish a route record table 37
38
3.2.2.31.2 When Generated 39
40
This primitive is generated by the next higher layer of a ZigBee coordinator or 41
router and issued to its NLME to request the initiation of route discovery. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 305

3.2.2.31.3 Effect on Receipt


1
On receipt of this primitive by the NLME of a ZigBee end device, the NLME will 2
issue the NLME-ROUTE-DISCOVERY.confirm primitive to the next higher layer 3
with a status value of INVALID_REQUEST. 4
On receipt of this primitive by the NLME with the DstAddrMode parameter not 5
equal to 0x00 and the DstAddr parameter equal to a broadcast address, the NLME 6
will issue the NLME-ROUTE-DISCOVERY.confirm primitive to the next higher 7
layer with a status value of INVALID_REQUEST. 8
9
On receipt of this primitive by the NLME of a ZigBee router or ZigBee 10
coordinator with no routing capacity and with the DstAddrMode parameter equal 11
to 0x01 or 0x02, the NLME will issue the NLME-ROUTE-DISCOVERY.confirm 12
to the next higher layer with a status value of ROUTE_ERROR and a 13
NetworkStatusCode value of 0x04 indicating no routing capacity. 14
On receipt of this primitive by a ZigBee router or ZigBee coordinator that has 15
routing capacity, with the DstAddrMode parameter equal to 0x02, the NLME will 16
initiate discovery of an unicast route between the current device and the network 17
device with the 16-bit network address given by the DstAddr parameter. The 18
procedure for initiating discovery of a unicast route is outlined in sub- 19
clause 3.6.3.5.1. 20
21
On receipt of this primitive by a ZigBee router or ZigBee coordinator that has 22
routing capacity, with the DstAddrMode parameter equal to 0x01, the NLME will 23
first check to see if the device is a member of the multicast group identified by the 24
DstAddr parameter by checking if the nwkGroupIDTable attribute of the NIB 25
contains an entry corresponding to the destination address. If the device is a 26
member of the multicast group, then the NLME will immediately issue the 27
NLME-ROUTE-DISCOVERY.confirm primitive with a status value of 28
SUCCESS and discontinue further processing of the NLME-ROUTE- 29
DISCOVERY.request primitive. If the device is not a member of the multicast 30
group, the NLME will initiate discovery of an unicast route between the current 31
device and the multicast group identified by the DstAddr parameter. 32
On receipt of this primitive on a ZigBee router or ZigBee coordinator with the 33
DstAddrMode parameter equal to 0x00, the NLME will initiate many-to-one 34
route discovery. The procedure for initiating many-to-one route discovery is 35
outlined in sub-clause 3.6.3.5.1. 36
37
In each of the three cases of actual route discovery described above, the NLME 38
will initiate route discovery by attempting to transmit a route discovery command 39
frame using the MCPS-DATA.request primitive of the MAC sub-layer. If a value 40
has been supplied for the optional Radius parameter, that value will be placed in 41
the Radius field of the NWK header of the outgoing frame. If a value has not been 42
supplied then the radius field of the NWK header will be set to twice the value of 43
the nwkMaxDepth attribute of the NIB as would be the case for data frame 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
306 Network Specification

transmissions. If the MAC sub-layer fails, for any reason, to transmit the route
request command frame, the NLME will issue the ROUTE-DISCOVERY.confirm 1
primitive to the next higher layer with a Status parameter value equal to that 2
returned by the MCPS-DATA.confirm. If the route discovery command frame is 3
sent successfully and if the DstAddrMode parameter has a value of 0x00, 4
indicating many-to-one route discovery, the NLME will immediately issue the 5
ROUTE-DISCOVERY.confirm primitive with a value of SUCCESS. Otherwise, 6
the NLME will wait until either a route reply command frame is received or the 7
route discovery operation times out as described in sub-clause 3.6.3.5. If a route 8
reply command frame is received before the route discovery operation times out, 9
the NLME will issue the NLME-ROUTE-DISCOVERY.confirm primitive to the 10
next higher layer with a status value of SUCCESS. If the operation times out, it 11
will issue the NLME_ROUTE-DISCOVERY.confirm primitive with a Status of 12
ROUTE_ERROR and with a NetworkStatusCode value reflecting the reason for 13
failure as described in Table 3.42. 14
15
3.2.2.32 NLME_ROUTE-DISCOVERY.confirm 16
17
This primitive informs the next higher layer about the results of an attempt to 18
initiate route discovery. 19
3.2.2.32.1 Semantics of the Service Primitive 20
21
The semantics of this primitive are as follows: 22
23
NLME_ROUTE-DISCOVERY.confirm {
24
Status,
25
NetworkStatusCode
26
} 27
28
Table 3.35 specifies the parameters for the NLME-ROUTE- 29
DISCOVERY.confirm primitive. 30
Table 3.35 NLME_ROUTE-DISCOVERY.confirm Parameters 31
32
Name Type Valid Range Description 33
Status status value INVALID_REQUEST, The status of an attempt to 34
ROUTE_ERROR or any status initiate route discovery. 35
value returned by the MCPS- 36
DATA.confirm primitive 37
NetworkSt Network See Table 3.42 In the case where the 38
atusCode status code Status parameter has a 39
value of ROUTE_ERROR, 40
this code gives further
information about the kind 41
of error that occurred. 42
Otherwise, it should be 43
ignored. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 307

3.2.2.32.2 When Generated


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
3.2.2.32.3 Effect on Receipt 4
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.2.2.31.3.13 8
9
10
3.3 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 leftmost bit is
23
transmitted first. Bits within each field are numbered from 0 (leftmost and least
24
significant) to k-1 (rightmost and most significant), where the length of the field is
25
k bits. Fields that are longer than a single octet are sent to the MAC sub-layer in
26
the order from the octet containing the lowest-numbered bits to the octet
27
containing the highest-numbered bits.
28
29
3.3.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. The NWK frame shall be 33
formatted as illustrated in Figure 3.5. 34
35
Octe 36
ts: 2 2 2 1 1 0/8 0/8 0/1 Variable Variable
37
Frame Destina Source Radius Sequen Destinati Source Multica Source route Frame 38
control tion address ce on IEEE IEEE st subframe payload
address number Address Address control 39
NWK Header Payload
40
41
Figure 3.5 General NWK Frame Format 42
43
13. CCB #822 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
308 Network Specification

3.3.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 Reserved 8
type version route t flag Route on IEEE IEEE
Address Address 9
10
Figure 3.6 Frame Control Field 11
12
Table shows the allowable frame control sub-field configurations for NWK data 13
frames. Note that all frames listed below will have a frame type sub-field equal to 14
00 indicating data and a protocol version sub-field reflecting the version of the 15
ZigBee specification implemented. 16
17
Table 3.36 Allowable Frame Control Sub-Field Configurations
18
Data Destination Source 19
Transmission Discover IEEE IEEE 20
Method Route Multicast Security Address Address 21
Unicast 00 or 01 0 0 or 1 0 or 1 0 or 1 22
23
Broadcast 00 0 0 or 1 0 0 or 1
24
Multicast 00 1 0 or 1 0 0 or 1 25
Source routed 00 0 0 or 1 0 or 1 0 or 1 26
27
3.3.1.1.1 Frame Type Sub-Field 28
29
The frame type sub-field is 2 bits in length and shall be set to one of the non- 30
reserved values listed in Table 3.37. 31
Table 3.37 Values of the Frame Type Sub-Field 32
33
Frame Type Value 34
b1 b0 Frame Type Name
35
00 Data 36
01 NWK command 37
38
10 – 11 Reserved 39
40
3.3.1.1.2 Protocol Version Sub-Field 41
42
The protocol version sub-field is 4 bits in length and shall be set to a number 43
reflecting the ZigBee NWK protocol version in use. The protocol version in use 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 309

on a particular device shall be made available as the value of the NWK constant
nwkcProtocolVersion. 1
2
3.3.1.1.3 Discover Route Sub-Field 3
The discover route sub-field may be used to control route discovery operations for 4
the transit of this frame (see sub-clause 3.6.3.5). 5
6
Table 3.38 Values of the Discover Route Sub-Field 7
Discover Route Field Value Field Meaning 8
9
0x00 Suppress route discovery 10
0x01 Enable route discovery 11
Reserved
12
0x02, 0x03
13
14
For NWK layer command frames, the discover route sub-field shall be set to 0x00 15
indicating suppression of route discovery. 16
3.3.1.1.4 Multicast Flag Sub-Field 17
18
The multicast flag sub-field is 1 bit in length and has the value 0 if the frame is a 19
unicast or broadcast frame and the value 1 if it is a multicast frame. The multicast 20
control field of the NWK header shall be present only if the multicast flag has the 21
value 1. 22
3.3.1.1.5 Security Sub-Field 23
24
The security sub-field shall have a value of 1 if, and only if, the frame is to have 25
NWK security operations enabled. If security for this frame is implemented at 26
another layer or disabled entirely, it shall have a value of 0. 27
3.3.1.1.6 Source Route Sub-Field 28
29
The source route sub-field shall have a value of 1 if and only if a source route 30
subframe is present in the NWK header. If the source route subframe is not 31
present, the source route sub-field shall have a value of 0. 32
33
3.3.1.1.7 Destination IEEE Address Sub-Field
34
The destination IEEE address sub-field shall have a value of 1 if, and only if, the 35
NWK header is to include the full IEEE address of the destination. 36
37
3.3.1.1.8 Source IEEE Address Sub-Field
38
The source IEEE address sub-field shall have a value of 1 if, and only if, the NWK 39
header is to include the full IEEE address of the source device. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
310 Network Specification

3.3.1.2 Destination Address Field


1
The destination address field shall always be present and shall be 2 octets in 2
length. If the multicast flag sub-field of the frame control field has the value 0, the 3
destination address field shall hold the 16-bit network address of the destination 4
device or a broadcast address (see Table 3.54). If the multicast flag sub-field has 5
the value 1, the destination address field shall hold the 16-bit Group ID of the 6
destination multicast group. Note that the network address of a device shall be set 7
to the value of the macShortAddress attribute of the MAC PIB. 8
9
3.3.1.3 Source Address Field 10
11
The source address field shall always be present. It shall always be 2 octets in 12
length and shall hold the network address of the source device of the frame. Note 13
that the network address of a device shall be set to value of the macShortAddress 14
attribute of the MAC PIB. 15
16
3.3.1.4 Radius Field 17
The radius field shall always be present. It will be 1 octet in length and specifies 18
the range of a radius-limited transmission. The field shall be decremented by 1 by 19
each receiving device. 20
21
3.3.1.5 Sequence Number Field 22
23
The sequence number field is present in every frame and is 1 octet in length. The 24
sequence number value shall be incremented by 1 with each new frame 25
transmitted. The values of the source address and sequence number fields of a 26
frame, taken as a pair, may be used to uniquely identify a frame within the 27
constraints imposed by the sequence number's one-octet range. For more details 28
on the use of the sequence number field, see sub-clause 3.6.2. 29
30
3.3.1.6 Destination IEEE Address Field 31
The destination IEEE address field, if present, contains the 64-bit IEEE address 32
corresponding to the 16-bit network address contained in the destination address 33
field of the NWK header. Upon receipt of a frame containing a 64-bit IEEE 34
address, the contents of the nwkAddressMap and neighbor table should be 35
checked for consistency, and updated if necessary. Sub-clause 3.6.1.9.2 describes 36
the actions to take in detecting address conflicts. If the 16-bit network address is a 37
broadcast or multicast address then the destination IEEE address field shall not be 38
present. 39
40
3.3.1.7 Source IEEE Address Field 41
42
The source IEEE address field, if present, contains the 64-bit IEEE address 43
corresponding to the 16-bit network address contained in the source address field 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 311

of the NWK header. Upon receipt of a frame containing a 64-bit IEEE address, the
contents of the nwkAddressMap and Neighbor Table should be checked for 1
consistency, and updated if necessary. Sub-clause 3.6.1.9.2 describes the actions 2
to take in detecting address conflicts. 3
4
3.3.1.8 Multicast Control Field 5
6
The multicast control sub-field is 1 octet in length and shall only be present if the 7
multicast flag sub-field has a value of 1. It is divided into three sub-fields as 8
illustrated in Figure 3.7. 9
10
Bits: 0 – 1 2–4 5–7
11
Multicast mode NonmemberRadius MaxNonmemberRadius 12
13
14
Figure 3.7 Multicast Control Field Format 15
16
3.3.1.8.1 Multicast Mode Sub-Field 17
18
The multicast mode sub-field indicates whether the frame is to be transmitted 19
using member or non-member mode. Member mode is used to propagate 20
multicasts between the devices that are members of the destination group. Non- 21
member mode is used to transmit a multicast frame from a device that is not a 22
member of the multicast group to a device that is a member of the multicast group. 23
Table 3.39 Values of the Multicast Mode Sub-Field 24
25
Multicast Mode Field 26
Value Field Meaning
27
0x0 Non-member mode 28
0x1 Member mode 29
30
0x2 Reserved 31
0x3 Reserved 32
33
3.3.1.8.2 NonmemberRadius Sub-Field 34
35
The nonmemberradius sub-field indicates the range of a member mode multicast 36
when relayed by devices that are not members of the destination group. Receiving 37
devices that are members of the destination group will set this field to the value of 38
the MaxNonmemberRadius sub-field. The originating device and receiving 39
devices that are not members of the destination group will discard the frame if the 40
NonmemberRadius sub-field has value 0 and will decrement the field if the 41
NonmemberRadius sub-field has a value in the range 0x01 through 0x06. A value 42
of 0x07 indicates an infinite range and is not decremented. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
312 Network Specification

The value of the NonmemberRadius sub-field will never exceed the value of the
MaxNonmemberRadius sub-field. 1
2
3.3.1.8.3 MaxNonmemberRadius Sub-Field 3
The maximum value of the NonmemberRadius sub-field for this frame. 4
5
3.3.1.9 Source Route Subframe Field 6
7
The source route subframe field shall only be present if the source route sub-field 8
of the frame control field has a value of 1. It is divided into three sub-fields as 9
illustrated in Figure 3.8. 10
11
Octets: 1 1 Variable 12
Relay count Relay index Relay list 13
14
15
Figure 3.8 Source Route Subframe Format 16
17
3.3.1.9.1 Relay Count Sub-Field 18
19
The relay count sub-field indicates the number of relays contained in the relay list 20
sub-field of the source route subframe. 21
3.3.1.9.2 Relay Index 22
23
The relay index sub-field indicates the index of the next relay in the relay list sub- 24
field to which the packet will be transmitted. This field is initialized to 1 less than 25
the relay count by the originator of the packet, and is decremented by 1 by each 26
receiving relay. 27
3.3.1.9.3 Relay List Sub-Field 28
29
The relay list sub-field shall contain the list of relay addresses. The relay closest to 30
the destination shall be listed first. The relay closest to the originator shall be 31
listed last. 32
33
3.3.1.10 Frame Payload Field 34
35
The frame payload field has a variable length and contains information specific to 36
individual frame types. 37
38
3.3.2 Format of Individual Frame Types 39
40
There are two defined NWK frame types: data and NWK command. Each of these 41
frame types is discussed in the following sub-clauses. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 313

3.3.2.1 Data Frame Format


1
The data frame shall be formatted as illustrated in Figure 3.9. 2
3
Octets: 2 Variable Variable 4
Frame control Routing fields Data payload 5
6
NWK header NWK payload
7
Figure 3.9 Data Frame Format 8
9
The order of the fields of the data frame shall conform to the order of the general 10
NWK frame format as illustrated in Figure 3.5. 11
12
3.3.2.1.1 Data Frame NWK Header Field 13
The data frame NWK header field shall contain the frame control field and an 14
appropriate combination of routing fields as required. 15
16
In the frame control field, the frame type sub-field shall contain the value that 17
indicates a data frame, as shown in Table 3.37. All other sub-fields shall be set 18
according to the intended use of the data frame. 19
The routing fields shall contain an appropriate combination of address and 20
broadcast fields, depending on the settings in the frame control field (see 21
Figure 3.6). 22
23
3.3.2.1.2 Data Payload Field 24
The data frame data payload field shall contain the sequence of octets, that the 25
next higher layer has requested the NWK layer to transmit. 26
27
3.3.2.2 NWK Command Frame Format 28
29
The NWK command frame shall be formatted as illustrated in Figure 3.10. 30
31
Octets: 2 Variable 1 Variable 32
Frame control Routing fields NWK command NWK command 33
identifier payload 34
NWK header NWK payload 35
36
Figure 3.10 NWK Command Frame Format 37
38
The order of the fields of the NWK command frame shall conform to the order of 39
the general NWK frame as illustrated in Figure 3.5. 40
3.3.2.2.1 NWK Command Frame NWK Header Field 41
42
The NWK header field of a NWK command frame shall contain the frame control 43
field and an appropriate combination of routing fields as required. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
314 Network Specification

In the frame control field, the frame type sub-field shall contain the value that
indicates a NWK command frame, as shown in Table 3.37. All other sub-fields 1
shall be set according to the intended use of the NWK command frame. 2
3
The routing fields shall contain an appropriate combination of address and 4
broadcast fields, depending on the settings in the frame control field. 5
3.3.2.2.2 NWK Command Identifier Field 6
7
The NWK command identifier field indicates the NWK command being used. 8
This field shall be set to one of the non-reserved values listed in Table 3.40. 9
3.3.2.2.3 NWK Command Payload Field 10
11
The NWK command payload field of a NWK command frame shall contain the 12
NWK command itself. 13
14
15
3.4 Command Frames 16
17
The command frames defined by the NWK layer are listed in Table 3.40. The 18
following sub-clauses detail how the NLME shall construct the individual 19
commands for transmission. 20
21
For each of these commands, the following applies to the NWK header fields
22
unless specifically noted in the clause on NWK header in each command:
23
• The frame type sub-field of the NWK frame control field shall be set to indicate 24
that this frame is a NWK command frame. 25
26
• The discover route sub-field in the NWK header shall be set to suppress route
27
discovery (see Table 3.38).
28
• The source address field in the NWK header shall be set to the address of the 29
originating device. 30
31
32
Table 3.40 NWK Command Frames 33
Command Frame Identifier Command Name Reference 34
35
0x01 Route request 3.4.1 36
0x02 Route reply 3.4.2 37
38
0x03 Network Status 3.4.3
39
0x04 Leave 3.4.4 40
0x05 Route Record 3.4.5 41
42
0x06 Rejoin request 3.4.6 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 315

Table 3.40 NWK Command Frames (Continued)


1
0x07 Rejoin response 3.4.7
2
0x08 Link Status 3.4.8 3
0x09 Network Report 3.4.9 4
5
0x0a Network Update 3.4.10 6
0x0b – 0xff Reserved — 7
8
9
3.4.1 Route Request Command 10
11
The route request command allows a device to request other devices within radio 12
range to engage in a search for a particular destination device and establish a state 13
within the network that will allow messages to be routed to that destination more 14
easily and economically in the future. The payload of a route request command 15
shall be formatted as illustrated in Figure 3.11. 16
17
Octets: 1 1 2 1 0/8
18
Command Route Destination Path cost Destination 19
options request address IEEE 20
identifier Address
21
NWK command payload 22
23
Figure 3.11 Route Request Command Frame Format
24
25
3.4.1.1 MAC Data Service Requirements 26
In order to transmit this command using the MAC data service, specified in IEEE 27
802.15.4-2003 [B1], the following information shall be included in the MAC 28
frame header: 29
30
• The destination PAN identifier shall be set to the PAN identifier of the device 31
sending the route request command. 32
• The destination address shall be set to the broadcast address of 0xffff. 33
34
• The source address and PAN identifier shall be set to the network address and 35
PAN identifier of the device sending the route request command, which may or 36
may not be the device from which the command originated. 37
• The frame control field shall be set to specify that the frame is a MAC data 38
frame with MAC security disabled, since any secured frame originating from 39
the NWK layer shall use NWK layer security. Because the frame is broadcast, 40
no acknowledgment request shall be specified. 41
42
• The addressing mode and intra-PAN flags shall be set to support the addressing 43
fields described here. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
316 Network Specification

3.4.1.2 NWK Header Fields


1
In order for this route request to reach its destination and for the route discovery 2
process to complete correctly, the following information must be provided: 3
4
• The destination address in the NWK header shall be set to the broadcast
5
address for all devices where macRxOnWhenIdle = TRUE (see Table 3.54).
6
• The source IEEE address sub-field of the frame control field shall be set to 1 7
and the source IEEE address field of the NWK header shall be present and shall 8
contain the 64-bit IEEE address of the originator of the frame. 9
10
3.4.1.3 NWK Payload Fields 11
12
The NWK frame payload contains a command identifier field, a command options 13
field, the route request identifier field, the address of the intended destination, an 14
up-to-date summation of the path cost, and the destination IEEE address. 15
The command frame identifier shall contain the value indicating a route request 16
command frame. 17
18
3.4.1.3.1 Command Options Field 19
The format of the 8-bit command options field is shown in Figure 3.12. 20
21
22
Bit: 0-2 3-4 5 6 7
23
Reserved Many-to-one Destination IEEE address Multicast Reserved 24
25
Figure 3.12 Route Request Command Options Field
26
3.4.1.3.1.1 Many-to-One 27
28
The many-to-one field shall have one of the non-reserved values shown in 29
Table 3.41. 30
Table 3.41 Many-to-One Field Values 31
32
Value Description 33
0 The route request is not a many-to- 34
one route request. 35
36
1 The route request is a many-to-one
route request and the sender 37
supports a route record table. 38
The route request is a many-to-one 39
2
route request and the sender does not 40
support a route record table. 41
3 Reserved 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 317

3.4.1.3.1.2 Destination IEEE Address


1
The destination IEEE address field is a single-bit field. It shall have a value of 1 if, 2
and only if, the command frame contains the destination IEEE address. The 3
Destination IEEE Address field should always be added if it is known.14 4
5
3.4.1.3.1.3 Multicast Sub-Field 6
7
The multicast sub-field is a single-bit field. It shall have a value of 1 if, and only
8
if, the command frame is a request for a route to a multicast group, in which case
9
the destination address field contains the Group ID of the desired group.
10
3.4.1.3.2 Route Request Identifier 11
12
The route request identifier is an 8-bit sequence number for route requests and is 13
incremented by 1 every time the NWK layer on a particular device issues a route 14
request. 15
3.4.1.3.3 Destination Address 16
17
The destination address shall be 2 octets in length and represents the intended 18
destination of the route request command frame. 19
3.4.1.3.4 Path Cost 20
21
The path cost field is eight bits in length and is used to accumulate routing cost 22
information as a route request command frame moves through the network (see 23
sub-clause 3.6.3.5.2). 24
3.4.1.3.5 Destination IEEE Address 25
26
The destination IEEE address shall be 8 octets in length and represents the IEEE 27
address of the destination of the route request command frame. It shall be present 28
only if the destination IEEE address sub-field of the command frame options field 29
has a value of 1. 30
31
3.4.2 Route Reply Command 32
33
The route reply command allows the specified destination device of a route 34
request command to inform the originator of the route request that the request has 35
been received. It also allows ZigBee routers along the path taken by the route 36
request to establish state information that will enable frames sent from the source 37
38
39
40
41
42
43
14. CCB #816 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
318 Network Specification

device to the destination device to travel more efficiently. The payload of the route
reply command shall be formatted as illustrated in Figure 3.13. 1
2
Octets: 1 1 2 2 1 0/8 0/8 3
4
Command Route Originator Responder Path cost Originator Responder
options request address address IEEE IEEE 5
identifier address address 6
7
NWK command payload
8
Figure 3.13 Route Reply Command Format 9
10
3.4.2.1 MAC Data Service Requirements 11
12
In order to transmit this command using the MAC data service, specified in IEEE 13
802.15.4-2003 [B1], the following information shall be included in the MAC 14
frame header: 15
• The destination MAC address and PAN identifier shall be set to the network 16
address and PAN identifier, respectively, of the first hop in the path back to the 17
originator of the corresponding route request command frame. The destination 18
PAN identifier shall be the same as the PAN identifier of the originator. 19
20
• The source MAC address and PAN identifier shall be set to the network 21
address and PAN identifier of the device sending the route reply command, 22
which may or may not be the device from which the command originated. 23
• The frame control field shall be set to specify that the frame is a MAC data 24
frame with MAC security disabled, since any secured frame originating from 25
the NWK layer shall use NWK layer security. The transmission options shall 26
be set to require acknowledgment. The addressing mode and intra-PAN flags 27
shall be set to support the addressing fields described here. 28
29
3.4.2.2 NWK Header Fields 30
31
In order for this route reply to reach its destination and for the route discovery 32
process to complete correctly, the following information must be provided: 33
• The source address in the NWK header shall be set to the 16-bit network 34
address of the device transmitting the frame. 35
36
• The destination address field in the NWK header shall be set to the network 37
address of the first hop in the path back to the originator of the corresponding 38
route request. 39
• Since this is a NWK layer command frame, the source IEEE address sub-field 40
of the frame control field shall be set to 1 and the source IEEE address field of 41
the NWK header shall be present and shall contain the 64-bit IEEE address of 42
the originator of the frame. The destination IEEE address sub-field of the frame 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 319

control field shall also have a value of 1 and the destination IEEE address field
of the NWK header shall be present and shall contain the 64-bit IEEE address 1
of the first hop in the path back to the originator of the corresponding route 2
request. 3
4
3.4.2.3 NWK Payload Fields 5
6
The NWK frame payload contains a command identifier field, a command options 7
field, the route request identifier, originator and responder addresses and an up-to- 8
date summation of the path cost. 9
The command frame identifier shall contain the value indicating a route reply 10
command frame. 11
12
3.4.2.3.1 Command Options Field 13
The format of the 8-bit command options field is shown in Figure 3.14. 14
15
Bit: 0 – 3 4 5 6 7 16
17
Reserved Originator Responder Multicast Reserved 18
IEEE address IEEE address
19
Figure 3.14 Route Reply Command Options Field 20
21
3.4.2.3.1.1 Originator IEEE Address 22
23
The originator IEEE address sub-field is a single-bit field. It shall have a value of 24
1 if and only if the originator IEEE address field is included in the payload. This 25
bit shall be set when nwkUniqueAddr is FALSE. 26
27
3.4.2.3.1.2 Responder IEEE Address 28
The responder IEEE address sub-field is a single-bit field. It shall have a value of 29
1 if, and only if, the responder IEEE address field is included in the payload. This 30
bit shall be set when nwkUniqueAddr is FALSE and the multicast sub-field is set 31
to 0. 32
33
3.4.2.3.1.3 Multicast Sub-Field 34
35
The multicast sub-field is a single-bit field. It shall have a value of 1 if and only if 36
the command frame is a reply to a request for a route to a multicast group, in 37
which case the responder address field contains the Group ID of the desired 38
group. 39
40
3.4.2.3.2 Route Request Identifier
41
The route request identifier is the 8-bit sequence number of the route request to 42
which this frame is a reply. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
320 Network Specification

3.4.2.3.3 Originator Address


1
The originator address field shall be 2 octets in length and shall contain the 16-bit 2
network address of the originator of the route request command frame to which 3
this frame is a reply. 4
3.4.2.3.4 Responder Address 5
6
The responder address field shall be 2 octets in length and shall always be the 7
same as the value in the destination address field of the corresponding route 8
request command frame. 9
3.4.2.3.5 Path Cost 10
11
The path cost field is used to sum link cost as the route reply command frame 12
transits the network (see sub-clause 3.6.3.5.3). 13
14
3.4.2.3.6 Originator IEEE Address
15
The originator IEEE address field shall be 8 octets in length and shall contain the 16
64-bit address of the originator of the route request command frame to which this 17
frame is a reply. This field shall only be present if the responder IEEE address 18
sub-field of the command options field has a value of 1. 19
20
3.4.2.3.7 Responder IEEE Address 21
The responder IEEE address field shall be 8 octets in length and shall contain the 22
64-bit address of the destination of the route request command frame to which this 23
frame is a reply. This field shall only be present if the responder IEEE address 24
sub-field of the command options field has a value of 1. 25
26
27
3.4.3 Network Status Command 28
29
A device uses the network status command to report errors and other conditions 30
arising in the NWK layer of a particular device to the peer NWK layer entities of 31
other devices in the network. The NWK status command may be also used to 32
diagnose network problems, e.g. address conflicts. The payload of a network 33
status command shall be formatted as illustrated in Figure 3.15. 34
Octets: 1 2 35
36
Status code Destination address 37
NWK command payload 38
39
Figure 3.15 Network Status Command Frame Format 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 321

3.4.3.1 MAC Data Service Requirements


1
In order to transmit this command using the MAC data service, specified in IEEE 2
802.15.4-2003 [B1], the following information shall be provided: 3
4
• The destination MAC address and PAN identifier shall be set to the network
5
address and PAN identifier, respectively, of the first hop in the path to the
6
destination of the command frame or to the broadcast address 0xffff in the case
7
where the command frame is being broadcast at the NWK layer.
8
• The source MAC address and PAN identifier shall be set to the network 9
address and PAN identifier of the device sending the network status command. 10
11
• The frame control field shall be set to specify that the frame is a MAC data
12
frame with MAC security disabled, since any secured frame originating from
13
the NWK layer shall use NWK layer security. The transmission options shall
14
not be set to require acknowledgement if the destination MAC address is the
15
broadcast address 0xffff.
16
• The addressing mode and intra-PAN flags shall be set to support the addressing 17
fields described here. 18
19
3.4.3.2 NWK Header Fields 20
21
Network status commands may be either unicast or broadcast. The fields of the 22
NWK header shall be set as follows: 23
• The source address field shall always be set to the 16-bit network address of the 24
device originating the command frame. 25
26
• The source IEEE address sub-field of the frame control field shall be set to 1 27
and the source IEEE address field of the NWK header shall be present and shall 28
contain the 64-bit IEEE address of the originator of the frame. 29
• When sent in response to a routing error, the destination address field in the 30
NWK header shall be set to the same value as the source address field of the 31
data frame that encountered a forwarding failure. 32
33
• If and only if, the network status command frame is not broadcast, the 34
destination IEEE address sub-field of the frame control field shall have a value 35
of 1 and the destination IEEE address field of the NWK header shall be present 36
and shall contain the 64-bit IEEE corresponding to the 16-bit network address 37
in the destination address field if this IEEE address is known. 38
39
3.4.3.3 NWK Payload Fields 40
The NWK frame payload of the network status command frame contains a 41
command frame identifier field, a status code field and a destination address field 42
as described below. The command frame identifier shall be set to specify the 43
network status command frame as defined in Table 3.40. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
322 Network Specification

3.4.3.3.1 Status Code


1
The status code shall be set to one of the non-reserved values shown in 2
Table 3.42. 3
Table 3.42 Status Codes for Network Status Command Frame 4
5
Value Status Code 6
0x00 No route available 7
8
0x01 Tree link failure
9
0x02 Non-tree link failure 10
0x03 Low battery level 11
12
0x04 No routing capacity
13
0x05 No indirect capacity 14
0x06 Indirect transaction expiry 15
16
0x07 Target device unavailable 17
0x08 Target address unallocated 18
Parent link failure
19
0x09
20
0x0a Validate route 21
0x0b Source route failure 22
23
0x0c Many-to-one route failure
24
0x0d Address conflict 25
0x0e Verify addresses 26
27
0x0f PAN identifier update
28
0x10 Network address update 29
0x11 Bad frame countera 30
31
0x12 Bad key sequence numberb 32
0x13 – 0xff Reserved 33
34
a. CCB #765
35
b. CCB #673
36
These status codes are used both as values for the status code field of a network 37
status command frame and as values of the Status parameter of the NLME-NWK- 38
STATUS.indication primitive. A brief explanation of each follows: 39
40
• No route available: Route discovery and/or repair has been attempted and no 41
route to the intended destination address has been discovered. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 323

• Tree link failure: The routing failure occurred as a result of the failure of an
attempt to route the frame along the tree. 1
2
• Non-tree link failure: The routing failure did not occur as a result of an 3
attempt to route along the tree. 4
• Low battery level: The frame was not relayed because the relaying device was 5
running low on battery power. 6
7
• No routing capacity: The failure occurred because the relaying device has no 8
routing capacity. 9
• No indirect capacity: The failure occurred as the result of an attempt to buffer 10
a frame for a sleeping end device child and the relaying device had no buffer 11
capacity to use. 12
13
• Indirect transaction expiry: A frame that was buffered on behalf of a sleeping 14
end device child has been dropped as a result of a time-out. 15
• Target device unavailable: An end device child of the relaying device is for 16
some reason unavailable. 17
18
• Target address unallocated: The frame was addressed to a non-existent end 19
device child of the relaying device. 20
• Parent link failure: The failure occurred as a result of a failure in the RF link 21
to the device’s parent. This status is only used locally on a device to indicate 22
loss of communication with the parent. 23
24
• Validate route: The multicast route identified in the destination address field 25
should be validated as described in sub-clause 3.6.3.6. 26
• Source route failure: Source routing has failed, probably indicating a link 27
failure in one of the source route’s links. 28
29
• Many-to-one route failure: A route established as a result of a many-to-one 30
route request has failed. 31
• Address conflict: The address in the destination address field has been 32
determined to be in use by two or more devices. 33
34
• Verify addresses: The source device has the IEEE address in the Source IEEE 35
address field and, if the Destination IEEE address field is present, the value it 36
contains is the expected IEEE address of the destination. 37
• PAN identifier update: The operational network PAN identifier of the device 38
has been updated. 39
40
• Network address update: The network address of the device has been 41
updated. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
324 Network Specification

• Bad frame counter: A frame counter reported in a received frame had a value
less than or equal to that stored in nwkSecurityMaterialSet.15 1
2
• Bad key sequence number: The key sequence number reported in a received 3
frame did not match that of nwkActiveKeySeqNumber.16 4
3.4.3.3.2 Destination Address 5
6
The destination address field is 2 octets in length and shall be present if, and only 7
if, the network status command frame is being sent in response to a routing 8
failure. In this case, it shall contain the destination address from the data frame 9
that encountered the failure. 10
11
3.4.4 Leave Command 12
13
The leave command is used by the NLME to inform other devices on the network 14
that a device is leaving the network or else to request that a device leave the 15
network. The payload of the leave command shall be formatted as shown in 16
Figure 3.16 17
18
1 19
20
Command options
21
NWK command payload 22
23
Figure 3.16 Leave Command Frame Format
24
25
3.4.4.1 MAC Data Service Requirement 26
In order to transmit this command using the MAC data service, specified in IEEE 27
802.15.4-2003 [B1], the following information shall be provided: 28
29
• The destination MAC address and PAN identifier shall be set to the network 30
address and PAN identifier, respectively, of the neighbor device to which the 31
frame is being sent or else to the MAC broadcast address 0xffff in the case 32
where the NWK header also contains a broadcast address. 33
• The source MAC address and PAN identifier shall be set to the network 34
address and PAN identifier of the device sending the leave command. 35
36
• The frame control field shall be set to specify that the frame is a MAC data 37
frame with MAC security disabled, since any secured frame originating from 38
the NWK layer shall use NWK layer security. Acknowledgment shall be 39
requested. 40
41
42
15. CCB #765 43
16. CCB #765 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 325

• The addressing mode and intra-PAN flags shall be set to support the addressing
fields described here. 1
2
3.4.4.2 NWK Header Fields 3
4
The NWK header fields of the leave command frame shall be set as follows: 5
• The source IEEE address sub-field of the frame control field shall be set to 1 6
and the source IEEE address field of the NWK header shall be present and shall 7
contain the 64-bit IEEE address of the originator of the frame. 8
9
• If the request sub-field of the command options field is set to 1 then the 10
destination address field in the NWK header shall be set to the network address 11
of the child device being requested to leave. 12
• If the request sub-field is set to 0 then the destination address field in the NWK 13
header shall be set to 0xfffd so that the indication is received by devices with 14
macRxOnWhenIdle equal to TRUE. 15
16
• If and only if the command frame is not broadcast, the destination IEEE 17
address sub-field of the frame control field shall be set to 1, and the destination 18
IEEE address field shall be set to the IEEE address of the device being 19
requested to leave. 20
• The radius field shall be set to 1. 21
22
3.4.4.3 NWK Payload Fields 23
24
The NWK payload of the leave command frame contains a command frame 25
identifier field and a command options field. The command frame identifier field 26
shall be set to specify the leave command frame as described in Table 3.40. 27
3.4.4.3.1 Command Options Field 28
29
The format of the 8-bit Command Options field is shown in Figure 3.17. 30
31
Bit: 0 – 4 5 6 7 32
Reserved Rejoin Request Remove children 33
34
Figure 3.17 Leave Command Options Field 35
36
3.4.4.3.1.1 Rejoin Sub-Field 37
The Rejoin sub-field is a single-bit field. If the value of this sub-field is 1, the 38
device that is leaving from its current parent will rejoin the network. If the value 39
of this sub-field is 0, the device will not rejoin the network. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
326 Network Specification

3.4.4.3.1.2 Request Sub-Field


1
The request sub-field is a single-bit field. If the value of this sub-field is 1, then 2
the leave command frame is a request for another device to leave the network. If 3
the value of this sub-field is 0, then the leave command frame is an indication that 4
the sending device plans to leave the network. 5
6
3.4.4.3.1.3 Remove Children Sub-Field 7
8
The remove children sub-field is a single-bit field. If this sub-field has a value of
9
1, then the children of the device that is leaving the network will also be removed.
10
If this sub-field has a value of 0, then the children of the device leaving the
11
network will not be removed.
12
13
3.4.5 Route Record Command 14
15
The route record command allows the route taken by a unicast packet through the 16
network to be recorded in the command payload and delivered to the destination 17
device. The payload of the route record command shall be formatted as illustrated 18
in Figure 3.18. 19
20
Octets: 1 Variable 21
Relay count Relay list 22
23
NWK command payload
24
Figure 3.18 Route Record Command Format 25
26
3.4.5.1 MAC Data Service Requirements 27
28
In order to transmit this command using the MAC data service, specified in IEEE 29
802.15.4-2003 [B1], the following information shall be provided: 30
• The destination MAC address and PAN identifier shall be set to the network 31
address and PAN identifier, respectively, of the neighbor device to which the 32
frame is being sent. 33
34
• The source MAC address and PAN identifier shall be set to the network 35
address and PAN identifier of the device sending the route record command. 36
• The frame control field shall be set to specify that the frame is a MAC data 37
frame with MAC security disabled, since any secured frame originating from 38
the NWK layer shall use NWK layer security. Acknowledgment shall be 39
requested. 40
41
• The addressing mode and intra-PAN flags shall be set to support the addressing 42
fields described here. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 327

3.4.5.2 NWK Header Fields


1
The NWK header fields of the route record command frame shall be set as 2
follows: 3
4
• If the route record is being initiated as the result of a NLDE-DATA.request
5
primitive from the next higher layer, the source address field shall be set to the
6
16-bit network address of the originator of the frame. If the route record is
7
being initiated as a result of the relaying of a data frame on behalf of one of the
8
device’s end device children, the source address field shall contain the 16-bit
9
network address of that end device child.
10
• The source IEEE address sub-field of the frame control field shall be set to 1 11
and the source IEEE address field of the NWK header shall be present and shall 12
contain the 64-bit IEEE address corresponding to the 16-bit network address 13
contained in the source address field. 14
15
• The destination address field in the NWK header shall be set to the 16-bit
16
network address of the concentrator device that is the destination of the frame.
17
• The destination IEEE address sub-field of the frame control field shall be set to 18
1, and the destination IEEE address field shall be set to the IEEE address of the 19
concentrator device that is the destination of the frame, if this address is known. 20
21
• The Source Route sub-field of the frame control field shall be set to 0.
22
3.4.5.3 NWK Payload 23
24
The NWK frame payload contains a command identifier field, a relay count field, 25
and a relay list field. The command frame identifier shall contain the value 26
indicating a route record command frame. 27
28
3.4.5.3.1 Relay Count Field 29
This field contains the number of relays in the relay list field of the route record 30
command. If the route record is being initiated as the result of a NLDE- 31
DATA.request primitive from the next higher layer, the relay count field is 32
initialized to 0. If the route record is being initiated as a result of the relaying of a 33
data frame on behalf of one of the device’s end device children, the relay count 34
field is initialized to 1. In either case, it is incremented by each receiving relay. 35
36
3.4.5.3.2 Relay List Field 37
The relay list field is a list of the 16-bit network addresses of the nodes that have 38
relayed the packet. If the route record is being initiated as a result of the relaying 39
of a data frame on behalf of one of the device’s end device children, the initiating 40
device will initialize this field with its own 16-bit network address. Receiving 41
relay nodes append their network address to the list before forwarding the packet. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
328 Network Specification

3.4.6 Rejoin Request Command 1


2
The rejoin request command allows a device to rejoin its network. This is
3
normally done in response to a communication failure, such as when an end
4
device can no longer communicate with its original parent.
5
Octets: 1 6
7
Capability 8
Information
9
NWK command payload 10
11
Figure 3.19 Rejoin Request Command Frame Format
12
13
3.4.6.1 MAC Data Service Requirements 14
In order to transmit this command using the MAC data service, specified in IEEE 15
802.15.4.-2003, [B1], the following information shall be provided: 16
17
• The destination address and PAN identifier shall be set to the network address 18
and PAN identifier, respectively, of the prospective parent. 19
• The source MAC address and PAN identifier shall be set to the network 20
address and PAN identifier of the device transmitting the rejoin command 21
frame. 22
23
• The transmission options shall be set to require acknowledgement. 24
• The addressing mode and intra-PAN flags shall be set to support the addressing 25
fields described here. 26
27
3.4.6.2 NWK Header Fields 28
29
The NWK header fields of the rejoin request command frame shall be set as 30
follows: 31
• The source address field of the NWK header to the 16-bit network address of 32
the device issuing the request. 33
34
• The source IEEE address sub-field of the frame control field shall be set to 1, 35
and the source IEEE address field shall be set to the IEEE address of the device 36
issuing the request. 37
• The destination address field in the NWK header shall be set to the 16-bit 38
network address of the prospective parent. 39
40
• The destination IEEE address sub-field of the frame control field shall be set to 41
1, and the destination IEEE address field shall be set to the IEEE address of the 42
prospective parent, if this address is known. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 329

• The radius field shall be set to 1.


1
3.4.6.3 NWK Payload Fields 2
3
The NWK frame payload contains a command identifier field and a capability 4
information field. The command frame identifier shall contain the value 5
indicating a rejoin request command frame. 6
3.4.6.3.1 Capability Information Field 7
8
This one-octet field has the format of the capability information field in the 9
association request command in [B1], which is also described in Table 3.47. 10
11
3.4.7 Rejoin Response Command 12
13
The rejoin response command is sent by a device to inform a child of its network 14
address and rejoin status. 15
16
Octets: 2 1 17
18
Network Rejoin status 19
address
20
NWK command payload 21
22
Figure 3.20 Rejoin Response Command Frame Format
23
24
3.4.7.1 MAC Data Service Requirements
25
In order to transmit this command using the MAC data service, specified in [B1], 26
the following information shall be provided: 27
28
• The destination MAC address and PAN identifier shall be set to the network 29
address and PAN identifier, respectively, of the device that sent the rejoin 30
request to which this frame is a response. 31
• The source MAC address and PAN identifier shall be set to the network 32
address and PAN identifier of the device that received and processed the rejoin 33
request command frame. 34
35
• Acknowledgment shall be requested. 36
• The addressing mode and intra-PAN flags shall be set to support the addressing 37
fields described here. The TXOptions shall request ‘indirect transmission’ to be 38
used if the Receiver on when idle bit of the nwkCapabilityInformation 39
contained in the corresponding rejoin request command is equal to 0x00. 40
Otherwise, ‘direct transmission’ shall be used. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
330 Network Specification

3.4.7.2 NWK Header Fields


1
The NWK header fields of the rejoin response command frame shall be set as 2
follows: 3
4
• The source address field shall be set to the 16-bit network address of the device
5
that is sending the response.
6
• The source IEEE address sub-field of the frame control field shall be set to 1 7
and the source IEEE address field of the NWK header shall be present and shall 8
contain the 64-bit IEEE address of the parent device that is sending the 9
response. 10
11
• The destination address field of the NWK header shall be set to the current
12
network address of the rejoining device, i.e. the device that sent the join request
13
to which this frame is a response.
14
• The destination IEEE address sub-field of the frame control field shall have a 15
value of 1 and the destination IEEE address field of the NWK header shall be 16
present and shall contain the 64-bit IEEE address of the child device that is 17
source of the rejoin request command to which this frame is a response. 18
19
• The NWK layer will set the security of the rejoin response command frame to
20
the same level as that of the received rejoin request command frame to which it
21
is a response.
22
3.4.7.3 NWK Payload Fields 23
24
3.4.7.3.1 Network Address Field 25
26
If the rejoin was successful, this two-octet field contains the new network address 27
assigned to the rejoining device. If the rejoin was not successful, this field 28
contains the broadcast address (0xffff). 29
3.4.7.3.2 Rejoin Status Field 30
31
This field shall contain one of the nonreserved association status values specified 32
in [B1]. 33
34
3.4.8 Link Status Command 35
36
The link status command frame allows neighboring routers to communicate their 37
incoming link costs to each other as described in sub-clause 3.6.3.4. Link status 38
frames are transmitted as one-hop broadcasts without retries. 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 331

3.4.8.1 MAC Data Service Requirements


1
In order to transmit this command using the MAC data service, specified in IEEE 2
802.15.4-2003 [B1], the following information shall be included in the MAC 3
frame header: 4
5
• The destination PAN identifier shall be set to the PAN identifier of the device
6
sending the link status command.
7
• The destination address must be set to the broadcast address of 0xffff. 8
9
• The source MAC address and PAN identifier shall be set to the network.
10
address and PAN identifier of the device sending the link status command.
11
• The frame control field shall be set to specify that the frame is a MAC data 12
frame with MAC security disabled, since any secured frame originating from 13
the NWK layer shall use NWK layer security. Because the frame is broadcast, 14
no acknowledgment request shall be specified. 15
16
• The addressing mode and intra-PAN flags shall be set to support the addressing
17
fields described here.
18
3.4.8.2 NWK Header Fields 19
20
The NWK header field of the link status command frame shall be set as follows: 21
22
• The source address field, source IEEE address sub-field of the frame control 23
field and source IEEE address field of the NWK header shall be set as usual for 24
a NWK command frame. 25
• The destination address in the NWK header shall be set to the router-only 26
broadcast address (see Table 3.54). 27
28
• The destination IEEE address sub-field of the frame control field shall have a 29
value of 0 and the destination IEEE address field of the NWK header shall not 30
be present. 31
• The radius field shall be set to 1. 32
33
3.4.8.3 NWK Payload Fields 34
35
The NWK command payload of the link status command shall be formatted as 36
illustrated in Figure 3.21. 37
Octets: 1 Variable 38
39
Command Link status 40
options list 41
NWK command payload 42
43
Figure 3.21 Link Status Command Format 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
332 Network Specification

3.4.8.3.1 Command Options Field


1
The format of the 8-bit command options field is shown in Figure 3.22. 2
3
Bit: 0 – 4 5 6 7
4
Entry count First frame Last frame Reserved 5
6
Figure 3.22 Link Status Command Options Field 7
8
The entry count sub-field of the command options field indicates the number of 9
link status entries present in the link status list. The first frame sub-field is set to 1 10
if this is the first frame of the sender's link status. The last frame sub-field is set to 11
1 if this is the last frame of the sender's link status. If the sender's link status fits 12
into a single frame, the first frame and last frame bits shall both be set to 1. 13
3.4.8.3.2 Link Status List Field 14
15
An entry in the link status list is formatted as shown in Figure 3.23. 16
17
Octets: 2 1
18
Neighbor Link status 19
network 20
address
21
Figure 3.23 Link Status Entry 22
23
Link status entries are sorted in ascending order by network address. If all router 24
neighbors do not fit in a single frame, multiple frames are sent. When sending 25
multiple frames, the last network address in the link status list for frame N is equal 26
to the first network address in the link status list for frame N+1. 27
28
Each link status entry contains the network address of a router neighbor, least 29
significant octet first, followed by the link status octet. The incoming cost field 30
contains the device's estimate of the link cost for the neighbor, which is a value 31
between 1 and 7. The outgoing cost field contains the value of the outgoing cost 32
field from the neighbor table. 33
The link status field in a link status entry is formatted as follows: 34
35
Bits: 0-2 3 4-6 7 36
Incoming cost Reserved Outgoing cost Reserved 37
38
39
3.4.9 Network Report Command 40
41
The network report command allows a device to report network events to the 42
device identified by the address contained in the nwkManagerAddr in the NIB. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 333

Such events are radio channel condition and PAN ID conflicts. The payload of a
network report command shall be formatted as illustrated in Figure 3.24. 1
2
Octets: 1 8 Variable 3
4
Command EPID Report
options (see information 5
Figure 3.25) 6
7
NWK command payload
8
Figure 3.24 Network Report Command Frame Format 9
10
3.4.9.1 MAC Data Service Requirements 11
12
In order to transmit this command using the MAC data service, specified in [B1], 13
the following information shall be included in the MAC frame header: 14
• The destination PAN identifier shall be set to the PAN identifier of the device 15
sending the network report command. 16
17
• The destination address shall be set to the value of the next-hop address field in 18
the routing table entry for which the destination address field has the same 19
value as the nwkManagerAddr field in the NIB. If no such routing table entry 20
exists, then the NWK may attempt route discovery as described in sub- 21
clause 3.6.3.5. 22
• The source MAC address and PAN identifier shall be set to the network 23
address and PAN identifier of the device sending the network report command, 24
which may or may not be the device from which the command originated. 25
26
• The frame control field shall be set to specify that the frame is a MAC data 27
frame with MAC security disabled, since any secured frame originating from 28
the NWK layer shall use NWK layer security. The transmission options shall 29
be set to require acknowledgment. 30
31
3.4.9.2 NWK Header Fields 32
The NWK header fields of the network report command frame shall be set as 33
follows: 34
35
• The source address field, source IEEE address sub-field of the frame control 36
field and source IEEE address field of the NWK header shall be set as usual for 37
a NWK command frame. 38
• The destination address field in the NWK header shall be set to the 16-bit 39
network address contained in the nwkManagerAddr attribute of the NIB. 40
41
• The destination IEEE address sub-field of the frame control field shall have a 42
value of 1 and the destination IEEE address field of the NWK header shall be 43
present and shall contain the 64-bit IEEE address of the corresponding to the 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
334 Network Specification

16-bit network address contained in the nwkManagerAddr attribute of the NIB,


if this IEEE address is known. 1
2
3.4.9.3 NWK Payload Fields 3
4
The NWK frame payload contains a command identifier field, a command options 5
field, an EPID field, and a report information payload. 6
The command frame identifier shall contain the value indicating a network report 7
command frame. 8
9
3.4.9.3.1 Command Options Field 10
The format of the 8-bit command options field is shown in Figure 3.25. 11
12
Bits 0 - 4 5-7 13
14
Report Report command 15
information identifier (see
count Figure 3.26) 16
17
Figure 3.25 Network Report Command Options Field 18
19
3.4.9.3.1.1 Report Information Count Sub-Field 20
21
The report information count sub-field contains an integer indicating the number
22
of records contained within the Report Information field. The size of a record
23
depends in the value of the Report Command Identifier.
24
25
3.4.9.3.1.2 Report Command Identifier Sub-Field 26
The report command identifier sub-field contains an integer indicating the type of 27
report information command. Table 3.26 contains the values that can be inserted 28
into this field. 29
30
Report Command Report Type 31
Identifier Value 32
0x00 PAN identifier conflict 33
34
0x01 - 0x07 Reserved
35
Figure 3.26 Report Command Identifier Sub-Field17 36
37
3.4.9.3.2 EPID Field 38
39
The EPID field shall contain the 64-bit EPID that identifies the network that the
40
reporting device is a member of.
41
42
43
17. CCB #823 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 335

3.4.9.3.3 Report Information


1
The report information field provides the information being reported, the format 2
of this field depends upon the value of the Report Command Identifier sub-field. 3
4
3.4.9.3.3.1 PAN Identifier Conflict Report 5
6
If the value of the Report Command Identifier sub-field indicates a PAN identifier
7
conflict report then the Report Information field will have the format shown in
8
Figure 3.27.
9
Octets: 2 2 2 10
11
1st PAN ID ... nth PAN ID 12
Figure 3.27 PAN Identifier Conflict Report 13
14
The PAN ID conflict report shall be made up of a list of 16-bit PAN identifiers that 15
are operating in the neighborhood of the reporting device. The number of PAN 16
identifiers in the PAN ID conflict report shall be equal to the value of the report 17
information count sub-field of the command options field. 18
19
18Network Update Command 20
3.4.10 21
22
The network update command allows the device identified by the 23
nwkManagerAddr attribute of the NIB to broadcast the change of configuration 24
information to all devices in the network. For example, broadcasting the fact that 25
the network is about to change its short PAN identifier. 26
The payload of a network update command shall be formatted as illustrated in 27
Figure 3.28. 28
29
Octets: 1 8 1 Variable 30
31
Command EPID Update Id Update
Options (see Information 32
Figure 3.25) 33
34
NWK command payload
35
Figure 3.28 Network Update Command Frame Format 36
37
3.4.10.1 MAC Data Service Requirements 38
39
In order to transmit this command using the MAC data service specified in [B1], 40
the following information shall be included in the MAC frame header: 41
42
43
18. CCB #823 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
336 Network Specification

• The destination PAN identifier shall be set to the old PAN identifier of the
ZigBee coordinator in order for the command frame to reach network devices 1
which have not received this update. The destination address shall be set 2
according to the procedures for broadcast transmission outlined in sub- 3
clause 3.6.5. 4
5
• The source MAC address and PAN identifier shall be set to the network 6
address and the old PAN identifier of the device sending the network report 7
command, which may or may not be the device from which the command 8
originated. 9
• The frame control field shall be set to specify that the frame is a MAC data 10
frame with MAC security disabled, since any secured frame originating from 11
the NWK layer shall use NWK layer security. 12
13
3.4.10.2 NWK Header Fields 14
15
The NWK header fields of the network update command frame shall be set as 16
follows: 17
• The source address field, source IEEE address sub-field of the frame control 18
field, and source IEEE address field of the NWK header shall be set as usual for 19
a NWK command frame. 20
21
• The destination address in the NWK header shall be set to the broadcast 22
address 0xffff. 23
• The destination IEEE address sub-field of the frame control field shall have a 24
value of 0 and the destination IEEE address field shall not be present in the 25
NWK header. 26
27
3.4.10.3 NWK Payload Fields 28
29
The NWK frame payload contains a command identifier field, a command options 30
field, an EPID field and an Update Information variable field. 31
The command frame identifier shall contain the value indicating a network update 32
command frame. 33
34
3.4.10.3.1 Command Options Field 35
36
The format of the 8-bit command options field is shown in Figure 3.29.
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 337

1
Bits 0 - 4 5-7 2
3
Update Update
Information Command 4
Count identifier 5
6
(see Figure 3.30)
7
Figure 3.29 Network Update Command Options Field 8
9
3.4.10.3.1.1 Update Information Count Sub-Field 10
11
The update information count sub-field contains an integer indicating the number 12
of records contained within the Update Information field. The size of a record 13
depends on the value of the Update Command Identifier sub-field. 14
15
3.4.10.3.1.2 Update Command Identifier Sub-Field 16
The update command identifier sub-field contains an integer indicating the type of 17
update information command. Figure 3.30 contains the values that can be inserted 18
into this field. 19
20
21
22
Update Command 23
Identifier Value Report Type
24
0x00 PAN Identifier 25
Update 26
0x01 - 0x07 Reserveda 27
a. CCB #824
28
29
Figure 3.30 Update Command Identifier Sub-Field
30
3.4.10.3.2 EPID Field 31
32
The EPID field shall contain the 64bit EPID that identifies the network that is to 33
be updated. 34
35
3.4.10.3.3 Update Id Field
36
The update Id field will reflect the current value of the nwkUpdateId attribute of 37
the device sending the frame. 38
39
3.4.10.3.4 Update Information 40
The update information field provides the information being updated, the format 41
of this field depends upon the value of the Update Command Identifier sub-field. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
338 Network Specification

3.4.10.3.4.1 PAN Identifier Update


1
If the value of the Update Command Identifier sub-field indicates a PAN 2
identifier update, then the Update Information field shall have the format shown 3
in Figure 3.31. 4
5
6
Octets: 2 7
8
New PAN ID
9
Figure 3.31 PAN Identifier Update 10
11
The PAN identifier update shall be made up of a single 16-bit PAN identifier that 12
is the new PAN identifier for this network to use. The Update Information count 13
sub field shall be set equal to 1 as there is only a single PAN identifier contained 14
within the Update Information field. 15
16
17
3.5 Constants and NIB Attributes19 18
19
20
3.5.1 NWK Constants 21
22
The constants that define the characteristics of the NWK layer are presented in 23
Table 3.43. 24
Table 3.43 NWK Layer Constants 25
26
Constant Description Value 27
nwkcCoordinatorCapable A Boolean flag indicating whether the device Configuration 28
is capable of becoming the ZigBee dependent 29
coordinator. A value of 0x00 indicates that 30
the device is not capable of becoming a 31
coordinator while a value of 0x01 indicates
that the device is capable of becoming a
32
coordinator. 33
34
nwkcDefaultSecurityLevel The default security level to be used (see Defined in stack
Chapter 4). profile 35
36
nwkcDiscoveryRetryLimit The maximum number of times a route 0x03 37
discovery will be retried.
38
nwkcMinHeaderOverhead The minimum number of octets added by the 0x08 39
NWK layer to an NSDU.
40
nwkcProtocolVersion The version of the ZigBee NWK protocol in 0x02 41
the device. 42
43
19. CCB #824 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 339

Table 3.43 NWK Layer Constants (Continued)


1
Constant Description Value 2
nwkcWaitBeforeValidation Time duration in milliseconds, on the 0x500 3
originator of a multicast route request, 4
between receiving a route reply and sending a 5
message to validate the route. 6
nwkcRouteDiscoveryTime Time duration in milliseconds until a route 0x2710 7
discovery expires. 8
nwkcMaxBroadcastJitter The maximum broadcast jitter time measured 0x40 9
in milliseconds. 10
nwkcInitialRREQRetries The number of times the first broadcast 0x03 11
transmission of a route request command 12
frame is retried. 13
nwkcRREQRetries The number of times the broadcast 0x02 14
transmission of a route request command 15
frame is retried on relay by an intermediate 16
ZigBee router or ZigBee coordinator.
17
nwkcRREQRetryInterval The number of milliseconds between retries 0xfe 18
of a broadcast route request command frame.
19
nwkcMinRREQJitter The minimum jitter, in 2-millisecond slots, 0x01 20
for broadcast retransmission of a route 21
request command frame.
22
nwkcMaxRREQJitter The maximum jitter, in 2-millisecond slots, 0x40 23
for broadcast retransmission of a route
24
request command frame.
25
nwkcMACFrameOverhead The size of the MAC header used by the 0x0b 26
ZigBee NWK layer.
27
28
3.5.2 NWK Information Base 29
30
The NWK information base (NIB) comprises the attributes required to manage the 31
NWK layer of a device. Each of these attributes can be read or written using the 32
NLME-GET.request and NLME-SET.request primitives, respectively, except for 33
attributes for which the Read Only column contains a value of Yes. In that case, 34
the attributes value may be read using the NLME-GET.request primitive but may 35
not be set using the NLME-SET.request primitive. Generally, these read-only 36
attribute are set using some other mechanism. For example, the 37
nwkSequenceNumber attribute is set as specified in sub-clause 3.6.2.1 and 38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
340 Network Specification

incremented every time the NWK layer sends a frame. The attributes of the NIB
are presented in Table 3.44. 1
2
Table 3.44 NIB Attributes
3
Read 4
Attribute Id Type Only Range Description Default 5
6
nwkSequenceNumber 0x81 Integer Yes 0x00 – 0xff A sequence number used Random
to identify outgoing frames value from 7
(see sub-clause 3.6.2). within the 8
range 9
nwkPassiveAckTimeout 0x82 Integer No 0x0000 – The maximum time Defined in 10
0x2710 duration in milliseconds stack profile 11
allowed for the parent and 12
all child devices to 13
retransmit a broadcast 14
message (passive
acknowledgment time- 15
out). 16
nwkMaxBroadcastRetries 0x83 Integer No 0x00 – 0x5 The maximum number of
17
0x03
retries allowed after a 18
broadcast transmission 19
failure. 20
nwkMaxChildren 0x84 Integer No 0x00 – 0xff The number of children a Defined in 21
device is allowed to have the stack 22
on its current network Note profile 23
that when nwkAddrAlloc 24
has a value of 0x02,
indicating stochastic 25
addressing, the value of 26
this attribute is 27
implementation- 28
dependent. 29
nwkMaxDepth 0x85 Integer Yes 0x00 – 0xff The depth a device can Defined in 30
have. stack profile 31
nwkMaxRouters 0x86 Integer No 0x01-0xff The number of routers any Defined in 32
one device is allowed to stack profile 33
have as children. This 34
value is determined by the
ZigBee coordinator for all
35
devices in the network. 36
37
If nwkAddrAlloc is 0x02
this value not used.
38
39
nwkNeighborTable 0x87 Set No Variable The current set of neighbor Null set 40
table entries in the device
(see Table 3.48). 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 341

Table 3.44 NIB Attributes (Continued)


1
Read 2
Attribute Id Type Only Range Description Default
3
nwkNetworkBroadcastDe 0x88 Integer No 0 – 0xff Time duration in seconds NA 4
liveryTime that a broadcast message 5
needs to encompass the 6
entire network.
7
This is a calculated 8
quantity based on other 9
NIB attributes. The
formula is given in sub- 10
clause 3.5.2.1. 11
12
nwkReportConstantCost 0x89 Integer No 0x00-0x01 If this is set to 0, the NWK 0x00
layer shall calculate link 13
cost from all neighbor 14
nodes using the LQI values 15
reported by the MAC 16
layer; otherwise, it shall
17
report a constant value.
18
nwkRouteDiscoveryRetrie 0x8a Integer No 0x00-x03 The number of retries nwkcDiscov 19
sPermitted allowed after an eryRetryLim
unsuccessful route request. it
20
21
nwkRouteTable 0x8b Set No Variable The current set of routing Null set 22
table entries in the device
(see Table 3.51).
23
24
nwkSymLink 0x8e Boolean No TRUE or The current route FALSE 25
FALSE symmetry setting:
26
TRUE means that routes 27
are considered to be 28
comprised of symmetric
links. Backward and 29
forward routes are created 30
during one-route discovery 31
and they are identical. 32
FALSE indicates that 33
routes are not consider to 34
be comprised of symmetric 35
links. Only the forward 36
route is stored during route
discovery. 37
38
nwkCapabilityInformation 0x8f Bit Yes See This field shall contain the 0x00
device capability
39
vector Table 3.47
information established at 40
network joining time. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
342 Network Specification

Table 3.44 NIB Attributes (Continued)


1
Read 2
Attribute Id Type Only Range Description Default
3
nwkAddrAlloc 0x90 Integer No 0x00 - 0x02 A value that determines the 0x00 4
method used to assign 5
addresses: 6
0x00 = use distributed 7
address allocation 8
0x01 = reserved 9
10
0x02 = use stochastic
address allocation 11
12
nwkUseTreeRouting 0x91 Boolean No TRUE or A flag that determines TRUE 13
FALSE whether the NWK layer
should assume the ability 14
to use hierarchical routing: 15
16
TRUE = assume the ability
to use hierarchical routing. 17
18
FALSE = never use
19
hierarchical routing.
20
nwkManagerAddr 0x92 Integer No 0x0000 - The address of the 0x0000 21
0xfff7 designated network
channel manager 22
function.a 23
24
nwkMaxSourceRoute 0x93 Integer No 0x00 - 0xff The maximum number of 0x0c
hops in a source route. 25
26
nwkUpdateId 0x94 Integer No 0x00 - 0xFF The value identifying a 0x00
snapshot of the network 27
settings with which this 28
node is operating with. 29
nwkTransactionPersistenc 0x95 Integer No 0x0000 - The maximum time (in 0x01f4 30
eTime 0xffff superframe periods) that a 31
transaction is stored by a 32
coordinator and indicated 33
in its beacon. This attribute
34
reflects the value of the
MAC PIB attribute 35
macTransactionPersistenc 36
eTime (see [B1]) and any 37
changes made by the 38
higher layer will be
39
reflected in the MAC PIB
attribute value as well. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 343

Table 3.44 NIB Attributes (Continued)


1
Read 2
Attribute Id Type Only Range Description Default
3
nwkNetworkAddress 0x96 Integer No 0x0000 - The 16-bit address that the 0xffff 4
0xfff7 device uses to 5
communicate with the 6
PAN. This attribute
reflects the value of the 7
MAC PIB attribute 8
macShortAddress (see 9
[B1]) and any changes 10
made by the higher layer 11
will be reflected in the
MAC PIB attribute value 12
as well. 13
14
nwkStackProfile 0x97 Integer No 0x00-0x0f The identifier of the
ZigBee stack profile in use 15
for this device. 16
nwkBroadcastTransaction 0x98 Set Yes - The current set of Null set
17
Table broadcast transaction table 18
entries in the device (see 19
Table 3.55) 20
nwkGroupIDTable 0x99 Set No Variable The set of group Null Set 21
identifiers, in the range 22
0x0000 - 0xffff, for groups 23
of which this device is a
24
member.
25
nwkExtendedPANID 0x9a 64-bit No 0x0000000 The Extended PAN 0x00000000 26
extende 000000000- Identifier for the PAN of 00000000
d 0xfffffffffff which the device is a 27
address ffffe member. The value 28
0x0000000000000000 29
means the Extended PAN 30
Identifier is unknown. 31
nwkUseMulticast 0x9b Boolean No TRUE or A flag determining the TRUE 32
FALSE layer where multicast 33
messaging occurs.
34
TRUE = multicast occurs 35
at the network layer. 36
FALSE= multicast occurs 37
at the APS layer and using 38
the APS header. 39
nwkRouteRecordTable 0x9c Set No Variable The route record table (see Null Set 40
Table 3.45). 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
344 Network Specification

Table 3.44 NIB Attributes (Continued)


1
Read 2
Attribute Id Type Only Range Description Default
3
nwkIsConcentrator 0x9d Boolean No TRUE or A flag determining if this FALSE 4
FALSE device is a concentrator. 5
6
7
TRUE = Device is a
concentrator. 8
9
FALSE = Device is not a 10
concentrator.
11
nwkConcentratorRadius 0x9e Integer No 0x00 - 0xff The hop count radius for 0x0000 12
concentrator route
13
discoveries.
14
nwkConcentratorDiscover 0x9f Integer No 0x00 - 0xff The time in seconds 0x0000 15
yTime between concentrator route
discoveries. If set to 16
0x0000, the discoveries are 17
done at start up and by the 18
next higher layer only. 19
nwkSecurityLevel 0xa0 No Security attribute defined 20
in Chapter 4. 21
nwkSecurityMaterialSet 0xa1 No Security attribute defined 22
in Chapter 4. 23
nwkActiveKeySeqNumber 0xa2 No Security attribute defined 24
in Chapter 4. 25
nwkAllFresh 0xa3 No Security attribute defined 26
in Chapter 4. 27
28
nwkSecureAllFrames 0xa5 No Security attribute defined
in Chapter 4. 29
30
nwkLinkStatusPeriod 0xa6 Integer No 0x00 - 0xff The time in seconds 0x0f
between link status 31
command frames. 32
33
nwkRouterAgeLimit 0xa7 Integer No 0x00 - 0xff The number of missed link 3
status command frames 34
before resetting the link 35
costs to zero. 36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 345

Table 3.44 NIB Attributes (Continued)


1
Read 2
Attribute Id Type Only Range Description Default
3
nwkUniqueAddr 0xa8 Boolean No TRUE or A flag that determines TRUE 4
FALSE whether the NWK layer 5
should detect and correct 6
conflicting addresses:
7
TRUE = assume addresses 8
are unique. 9
FALSE = addresses may 10
not be unique. 11
nwkAddressMap 0xa9 Set No Variable The current set of 64-bit Null Set 12
IEEE to 16-bit network 13
address map (see 14
Table 3.46).
15
nwkTimeStamp 0x8Cb Boolean No TRUE or A flag that determines if a FALSE 16
FALSE time stamp indication is 17
provided on incoming and
outgoing packets. 18
19
TRUE= time indication 20
provided.
21
FALSE = no time 22
indication provided. 23
nwkPANId 0x80c 16-bit No 0x0000 - This NIB attribute should, 0xffff 24
PAN ID 0xffff at all times, have the same 25
value as macPANId.
26
nwkTxTotal 0x8Dd Integer No 0x0000 - A count of unicast 0 27
0xffff transmissions made by the 28
NWK layer on this device.
Each time the NWK layer 29
transmits a unicast frame, 30
by invoking the MCPS- 31
DATA.request primitive of 32
the MAC sub-layer, it shall 33
increment this counter.
When either the NHL 34
performs an NLME- 35
SET.request on this 36
attribute or if the value of 37
nwkTxTotal rolls over past 38
0xffff the NWK layer shall
reset to 0x00 each 39
Transmit Failure field 40
contained in the neighbor 41
table. 42
a. CCB #819 43
b. CCB #830 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
346 Network Specification

c. CCB #830
1
d. CCB #830
2
3
4
Table 3.45 Route Record Table Entry Format
5
Field Valid 6
Field Name Type Range Reference 7
8
Network Address Integer 0x0000- The destination
0xfff7 network address for 9
this route record. 10
Relay Count Integer 0x0000 - The count of relay 11
0xffff nodes from 12
concentrator to the 13
destination. 14
Path Set of The set of network 15
Network addresses that 16
Addresses represent the route in 17
order from the
18
concentrator to the
destination. 19
20
21
22
Table 3.46 Network Address Map 23
64-bit IEEE Address 16-bit Network address 24
25
A valid 64-bit IEEE Address or Null 0x0000 - 0xfff7 26
if not known 27
28
3.5.2.1 Broadcast Delivery Time 29
30
The total delivery time for a broadcast transmission, i.e. the time required for a 31
broadcast to be delivered to every device in the network, shall be calculated 32
according to the following formula: 33
nwkBroadcastDeliveryTime = 2*nwkMaxDepth* 34
((0.05+(nwkcMaxBroadcastJitter/2))+
35
36
nwkPassiveAckTimeout*nwkBroadcastRetries/
37
1000) 38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 347

3.6 Functional Description 1


2
3.6.1 Network and Device Maintenance 3
4
All ZigBee devices shall provide the following functionality: 5
6
• Join a network 7
• Leave a network 8
9
• Rejoin a network 10
Both ZigBee coordinators and routers shall provide the following additional 11
functionality: 12
13
• Permit devices to join the network using the following: 14
• Association indications from the MAC 15
16
• Explicit join requests from the application 17
• Rejoin requests 18
19
• Permit devices to leave the network using the following: 20
• Network leave command frames 21
22
• Explicit leave requests from the application 23
• Participate in assignment of logical network addresses 24
25
• Maintain a list of neighboring devices 26
ZigBee coordinators shall provide functionality to establish a new network. 27
ZigBee routers and end devices shall provide the support of portability within a 28
network. 29
30
3.6.1.1 Establishing a New Network 31
32
The procedure to establish a new network is initiated through use of the NLME- 33
NETWORK-FORMATION.request primitive. Only devices for which the 34
nwkcCoordinatorCapable constant has a value of 0x01, and which are not 35
currently joined to a network shall attempt to establish a new network. If this 36
procedure is initiated on any other device, the NLME shall terminate the 37
procedure and notify the next higher layer of the illegal request. This is achieved 38
by issuing the NLME-NETWORK-FORMATION.confirm primitive with the 39
Status parameter set to INVALID_REQUEST. 40
41
When this procedure is initiated, the NLME shall first request that the MAC sub-
42
layer perform an energy detection scan over either a specified set of channels or,
43
by default, the complete set of available channels, as dictated by the PHY layer
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
348 Network Specification

(see [B1]), to search for possible interferers. A channel scan is initiated by issuing
the MLME-SCAN.request primitive to the MAC sub-layer with the ScanType 1
parameter set to energy detection scan. The results are communicated back via the 2
MLME-SCAN.confirm primitive. This scan is not necessary if there is only one 3
channel specified. 4
5
On receipt of the results from a successful energy detection scan, the NLME shall 6
order the channels according to increasing energy measurement and discard those 7
channels whose energy levels are beyond an acceptable level. The choice of an 8
acceptable energy level is left to the implementation. The NLME shall then 9
perform an active scan, by issuing the MLME-SCAN.request primitive with the 10
ScanType parameter set to active scan and ChannelList set to the list of acceptable 11
channels, to search for other ZigBee devices. To determine the best channel on 12
which to establish a new network, the NLME shall review the list of returned PAN 13
descriptors and find the first channel with the lowest number of existing networks, 14
favoring a channel with no detected networks. 15
If no suitable channel is found, the NLME shall terminate the procedure and 16
notify the next higher layer of the startup failure. This is achieved by issuing the 17
NLME-NETWORK-FORMATION.confirm primitive with the Status parameter 18
set to STARTUP_FAILURE. 19
20
If a suitable channel is found, the NLME shall select a PAN identifier for the new 21
network. To do this the device shall choose a random PAN identifier less than 22
0xffff that is not already in use on the selected channel. Once the NLME makes its 23
choice, it shall set the macPANID attribute in the MAC sub-layer to this value by 24
issuing the MLME-SET.request primitive. 25
If no unique PAN identifier can be chosen, the NLME shall terminate the 26
procedure and notify the next higher layer of the startup failure by issuing the 27
NLME-NETWORK-FORMATION.confirm primitive with the Status parameter 28
set to STARTUP_FAILURE. 29
30
Once a PAN identifier is selected, the NLME shall select a 16-bit network address 31
equal to 0x0000 and set the nwkNetworkAddress attribute of the NIB equal to the 32
selected network address. 33
Once a network address is selected, the NLME shall check the value of the 34
nwkExtendedPANId attribute of the NIB. If this value is 0x0000000000000000 35
this attribute is initialized with the value of the MAC constant aExtendedAddress. 36
37
Once the value of the nwkExtendedPANId is checked, the NLME shall begin 38
operation of the new PAN by issuing the MLME-START.request primitive to the 39
MAC sub-layer. The parameters of the MLME-START.request primitive shall be 40
set according to those passed in the NLME-NETWORK-FORMATION.request, 41
the results of the channel scan, and the chosen PAN identifier. The status of the 42
PAN startup is communicated back via the MLME-START.confirm primitive. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 349

On receipt of the status of the PAN startup, the NLME shall inform the next higher
layer of the status of its request to initialize the ZigBee coordinator. This is 1
achieved by issuing the NLME-NETWORK-FORMATION.confirm primitive 2
with the Status parameter set to the primitive returned in the MLME- 3
START.confirm from the MAC sub-layer. 4
5
The procedure to successfully start a new network is illustrated in the message 6
sequence chart (MSC) shown in Figure 3.32. 7
8
NLME-NETWORK-FORMATION.request
9
MLME-SCAN.request 10
Perform energy
11
MLME-SCAN.confirm
detection scan 12
MLME-SCAN.request
13
14
Perform active scan 15
MLME-SCAN.confirm
16
Select Channel, PAN ID,
Beacon Payload and Short 17
Address
MLME-SET.request
18
19
MLME-SET.confirm
20
MLME-START.request
21
22
MLME-START.confirm
23
NLME- NETWORK-FORMATION.confirm
24
25
APL NWK MAC
26
Figure 3.32 Establishing a New Network 27
28
3.6.1.2 Permitting Devices to Join a Network 29
30
The procedure for permitting devices to join a network is initiated through the 31
NLME-PERMIT-JOINING.request primitive. Only devices that are either the 32
ZigBee coordinator or a ZigBee router shall attempt to permit devices to join the 33
network. 34
When this procedure is initiated with the PermitDuration parameter set to 0x00, 35
the NLME shall set the macAssociationPermit PIB attribute in the MAC sub-layer 36
to FALSE. A MAC sub-layer attribute setting is initiated by issuing the MLME- 37
SET.request primitive. 38
39
When this procedure is initiated with the PermitDuration parameter set to a value 40
between 0x01 and 0xfe, the NLME shall set the macAssociationPermit PIB 41
attribute in the MAC sub-layer to TRUE. The NLME shall then start a timer to 42
expire after the specified duration. On expiration of this timer, the NLME shall set 43
the macAssociationPermit PIB attribute in the MAC sub-layer to FALSE. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
350 Network Specification

When this procedure is initiated with the PermitDuration parameter set to 0xff, the
NLME shall set the macAssociationPermit PIB attribute in the MAC sub-layer to 1
TRUE for an unlimited amount of time, unless another NLME-PERMIT- 2
JOINING.request primitive is issued. 3
4
The procedure for permitting devices to join a network is illustrated in the MSC 5
shown in Figure 3.33. 6
7
8
NLME-PERMIT-JOINING.request
9
MLME-SET.request( macAssociationPermit ) 10
11
MLME-SET.confirm
NLME-PERMIT-JOINING.confirm 12
13
14
PermitDuration 15
16
17
MLME-SET.request( macAssociationPermit )
18
MLME-SET.confirm 19
20
21
22
APL NWK MAC 23
Figure 3.33 Permitting Devices to Join a Network 24
25
3.6.1.3 Network Discovery 26
27
The NWK layer enables higher layers to discover what networks, if any, are 28
operational in the POS of a device. 29
30
The procedure for network discovery shall be initiated by issuing the NLME-
31
NETWORK-DISCOVERY.request primitive with the ScanChannels parameter
32
set to indicate which channels are to be scanned for networks and the
33
ScanDuration parameter set to indicate the length of time to be spent scanning
34
each channel. Upon receipt of this primitive, the NWK layer shall issue an
35
MLME-SCAN.request primitive asking the MAC sub-layer to perform an active
36
scan.
37
Every beacon frame received during the scan having a non-zero length payload 38
shall cause the MLME-BEACON-NOTIFY.indication primitive to be issued from 39
the MAC sub-layer of the scanning device to its NLME. This primitive includes 40
information such as the addressing information of the beaconing device, whether 41
or not it is permitting association and the beacon payload. (See [B1] for the 42
complete list of parameters). The NLME of the scanning device shall check the 43
protocol ID field in the beacon payload and verify that it matches the ZigBee 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 351

protocol identifier. If not, the beacon is ignored. Otherwise, the device shall copy
the relevant information from each received beacon (see Figure 3.49 for the 1
structure of the beacon payload) into its neighbor table (see Table 3.48 for the 2
contents of a neighbor table entry). 3
4
Once the MAC sub-layer signals the completion of the scan by issuing the 5
MLME-SCAN.confirm primitive to the NLME, the NWK layer shall issue the 6
NLME-NETWORK-DISCOVERY.confirm primitive containing a description of 7
each network that was heard. Every network description contains the ZigBee 8
version, stack profile, Extended PAN Id, PAN Id, logical channel, and information 9
on whether it is permitting joining (see Table 3.8). 10
11
3.6.1.4 Joining a Network 12
For purposes of the ensuing discussion, a parent-child relationship is formed when 13
a device having membership in the network allows a new device to join. On 14
joining, the new device becomes the child, while the first device becomes the 15
parent. 16
17
3.6.1.4.1 Joining a Network Through Association 18
This sub-clause specifies the procedure a device (child) shall follow if it opts to 19
join a network using the underlying association capabilities provided by the 20
MAC, as well as the procedure a ZigBee coordinator or router (parent) shall 21
follow upon receipt of an MLME-ASSOCIATE.request primitive from the MAC. 22
23
24
3.6.1.4.1.1 Child Procedure
25
The procedure for joining a network using the MAC layer association procedure 26
should be preceded by network discovery as described in sub-clause 3.6.1.3. 27
Upon receipt of the NLME-NETWORK-DISCOVERY.confirm primitive, the 28
next higher layer shall either choose a network to join from the discovered 29
networks or redo the network discovery. Once a network is selected, it shall then 30
issue the NLME-JOIN.request with the RejoinNetwork parameter set to 0x00 and 31
the JoinAsRouter parameter set to indicate whether the device wants to join as a 32
routing device. 33
34
Only those devices that are not already joined to a network shall initiate the join 35
procedure. If any other device initiates this procedure, the NLME shall terminate 36
the procedure and notify the next higher layer of the illegal request by issuing the 37
NLME-JOIN.confirm primitive with the Status parameter set to 38
INVALID_REQUEST. 39
For a device that is not already joined to a network, the NLME-JOIN.request 40
primitive shall cause the NWK layer to search its neighbor table for a suitable 41
parent device, i.e. a device for which following conditions are true: 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
352 Network Specification

• The device belongs to the network identified by the ExtendedPANId


parameter. 1
2
• The device is open to join requests and is advertising capacity of the correct 3
device type. 4
• The link quality for frames received from this device is such that a link cost of 5
at most 3 is produced when calculated as described in sub-clause 3.6.3.1. 6
7
• If the neighbor table entry contains a potential parent field for this device, that 8
field shall have a value of 1 indicating that the device is a potential parent. 9
• The device shall have the most recent update id, where the determination of 10
most recent needs to take into account that the update id will wrap back to zero. 11
In particular the update id given in the beacon payload of the device should be 12
greater than or equal to — again, compensating for wrap — the nwkUpdateId 13
attribute of the NIB. 14
15
If the neighbor table contains no devices that are suitable parents, the NLME shall 16
respond with an NLME-JOIN.confirm with a Status parameter of 17
NOT_PERMITTED. If the neighbor table has more than one device that could be 18
a suitable parent, the device which is at a minimum depth from the ZigBee 19
coordinator may be chosen. If more than one device has a minimum depth, the 20
NWK layer is free to choose from among them. 21
Once a suitable parent is identified, the NLME shall issue an MLME- 22
ASSOCIATE.request primitive to the MAC sub-layer. The LogicalChannel 23
parameter of the MLME-ASSOCIATE.request primitive shall be set to that found 24
in the neighbor table entry corresponding to the coordinator address of the 25
potential parent. The bit-fields of the CapabilityInformation parameter shall have 26
the values shown in Table 3.47 and the capability information shall be stored as 27
the value of the nwkCapabilityInformation NIB attribute (see Table 3.44). If more 28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 353

than one device meets these requirements, then the joining device may select the
parent with the smallest network depth. 1
2
Table 3.47 Capability Information Bit-Fields
3
Bit Name Description 4
5
0 Alternate PAN This field will always have a value of 0 in
6
coordinator implementations of this specification.
7
1 Device type This field will have a value of 1 if the 8
joining device is a ZigBee router. It will 9
have a value of 0 if the device is a ZigBee
end device or else a router-capable device 10
that is joining as an end device. 11
This field will be set to the value of
12
2 Power source
lowest-order bit of the PowerSource 13
parameter passed to the NLME-JOIN- 14
request primitive. The values are: 15
0x01 = Mains-powered device 16
0x00 = other power source 17
18
3 Receiver on when idle This field will be set to the value of the
lowest-order bit of the RxOnWhenIdle
19
parameter passed to the NLME- 20
JOIN.request primitive. 21
0x01 = The receiver is enabled when the
22
device is idle 23
0x00 = The receiver may be disabled 24
when the device is idle 25
This field will always have a value of 0 in
26
4–5 Reserved
implementations of this specification. 27
28
6 Security capability This field shall have a value of 0 if the
device is operating in Standard Security 29
Mode and a value of 1 if the device is 30
operating in High Security Mode. Note 31
that this overrides the default meaning 32
specified in [B1].a 33
7 Allocate address This field will have a value of 1 in 34
implementations of this specification, 35
indicating that the joining device must be
issued a 16-bit network address, except in
36
the case where a device has self-selected 37
its address while using the NWK rejoin 38
command to join a network for the first 39
time in a secure manner. In this case, it 40
shall have a value of 0.
41
a. CCB #788 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
354 Network Specification

Otherwise, the NLME issues the NLME-JOIN.confirm with the Status parameter
set to the Status parameter value returned from the MLME-ASSOCIATE.confirm 1
primitive. 2
3
If the RejoinNetwork parameter is 0x00 and the JoinAsRouter parameter is set to 4
TRUE, the device will function as a ZigBee router in the network. If the 5
JoinAsRouter parameter is FALSE, then it will join as an end device and not 6
participate in routing. 7
The addressing parameters in the MLME-ASSOCIATE.request primitive (see 8
Chapter 2) shall be set to contain the addressing information for the device chosen 9
from the neighbor table. The status of the association is communicated back to the 10
NLME via the MLME-ASSOCIATE.confirm primitive. 11
12
If the attempt to join was unsuccessful, the NWK layer shall receive an MLME- 13
ASSOCIATE.confirm primitive from the MAC sub-layer with the Status 14
parameter indicating the error. If the Status parameter indicates a refusal to permit 15
joining on the part of the neighboring device (that is, PAN at capacity or PAN 16
access denied), then the device attempting to join should set the Potential parent 17
bit to 0 in the corresponding neighbor table entry to indicate a failed join attempt. 18
Setting the Potential parent bit to 0 ensures that the NWK layer shall not issue 19
another request to associate to the same neighboring device. The Potential parent 20
bit should be set to 1 for every entry in the neighbor table each time an MLME- 21
SCAN.request primitive is issued. 22
A join request may also be unsuccessful, if the potential parent is not allowing 23
new routers to associate (for example, the maximum number of routers, 24
nwkMaxRouters may already have associated with the device) and the joining 25
device has set the JoinAsRouter parameter to TRUE. In this case, the NLME- 26
JOIN.confirm primitive will indicate a status of NOT_PERMITTED. In this case, 27
the child device’s application may wish to attempt to join again as an end device 28
instead, by issuing another NLME-JOIN.request with the JoinAsRouter parameter 29
set to FALSE. 30
31
If the attempt to join was unsuccessful, the NLME shall attempt to find another 32
suitable parent from the neighbor table. If no such device could be found, the 33
NLME shall issue the NLME-JOIN.confirm primitive with the Status parameter 34
set to the value returned in the MLME-ASSOCIATE.confirm primitive. 35
If the attempt to join was unsuccessful and there is a second neighboring device 36
that could be a suitable parent, the NWK layer shall initiate the MAC sub-layer 37
association procedure with the second device. The NWK layer shall repeat this 38
procedure until it either joins the PAN successfully or exhausts its options to join 39
the PAN. 40
41
If the device cannot successfully join the PAN specified by the next higher layer, 42
the NLME shall terminate the procedure by issuing the NLME-JOIN.confirm 43
primitive with the Status parameter set to the value returned in the last received 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 355

MLME-ASSOCIATE.confirm primitive. In this case, the device shall not receive


a valid logical address and shall not be permitted to transmit on the network. 1
2
If the attempt to join was successful, the NWK shall issue the NLME- 3
JOIN.confirm primitive with a status value of SUCCESS. In this case, the 4
MLME-ASSOCIATE.confirm primitive received by the NWK layer shall contain 5
a 16-bit logical address unique to that network which the child can use in future 6
transmissions. The NWK layer shall then set the Relationship field in the 7
corresponding neighbor table entry to indicate that the neighbor is its parent. By 8
this time, the parent shall have added the new device to its neighbor table. 9
Furthermore, the NWK layer will update the values of nwkNetworkAddress, 10
nwkUpdateId and mwkPANId in the NIB. 11
If the device is attempting to join a secure network and it is a router, it will need to 12
wait until its parent has authenticated it before transmitting beacons. The device 13
shall therefore wait for an NLME-START-ROUTER.request primitive to be 14
issued from the next higher layer. Upon receipt of this primitive, the NLME shall 15
issue an MLME-START.request primitive if it is a router. If the NLME-START- 16
ROUTER.request primitive is issued on an end device, the NWK layer shall issue 17
an NLME-START-ROUTER.confirm primitive with the status value set to 18
INVALID_REQUEST. 19
20
Once the device has successfully joined the network, if it is a router and the next 21
higher layer has issued a NLME-START-ROUTER.request, the NWK layer shall 22
issue the MLME-START.request primitive to its MAC sub-layer. The PANId, 23
LogicalChannel, BeaconOrder and SuperframeOrder parameters shall be set equal 24
to the corresponding values held in the neighbor table entry for its parent. The 25
network depth is set to one more than the parent network depth unless the parent 26
network depth has a value of 0x0f, i.e. the maximum value for the 4-bit device 27
depth field in the beacon payload. In this case, the network depth shall also be set 28
to 0x0f. The PANCoordinator and CoordRealignment parameters shall both be set 29
to FALSE. Upon receipt of the MLME-START.confirm primitive, the NWK layer 30
shall issue an NLME-START-ROUTER.confirm primitive with the same status 31
value. 32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
356 Network Specification

NLME-NETWORK-DISCOVERY.request
1
MLME-SCAN.request
2
Perform active scan
3
MLME-BEACON-NOTIFY.indication 4
5
6
MLME-BEACON-NOTIFY.indication 7
MLME-SCAN.confirm 8
NLME-NETWORK-DISCOVERY.confirm 9
Select suitable EPID 10
NLME-JOIN.request 11
MLME-ASSOCIATE.request
12
MAC Association Procedure
13
MLME-ASSOCIATE.confirm
14
15
NLME-JOIN.confirm

MLME-SET.request(macBeaconPayload)
Association Procedure
16
MLME-SET.confirm

NLME-START-ROUTER.request
17
MLME-START.request
18
MLME-START.confirm
19
NLME- START_ROUTER.confirm
20
21
APL NWK MAC 22
Figure 3.34 Procedure for Joining a Network Through Association 23
24
3.6.1.4.1.2 Parent Procedure 25
26
The procedure for a ZigBee coordinator or router to join a device to its network 27
using the MAC sub-layer association procedure is initiated by the MLME- 28
ASSOCIATE.indication primitive arriving from the MAC sub-layer. Only those 29
devices that are either a ZigBee coordinator or a ZigBee router and that are 30
permitting devices to join the network shall initiate this procedure. If this 31
procedure is initiated on any other device, the NLME shall terminate the 32
procedure. 33
When this procedure is initiated, the NLME of a potential parent shall first 34
determine whether the device wishing to join already exists on its network. To do 35
this, the NLME shall search its neighbor table in order to determine whether a 36
matching 64-bit, extended address can be found. If an extended address match is 37
found, the NLME shall check that the supplied DeviceCapabilities match the 38
device type on record in the neighbor table. If the device type also matches the 39
NLME, it shall then obtain the corresponding 16-bit network address and issue an 40
association response to the MAC sub-layer. If a device type match is not found the 41
NLME shall remove all records of the device in its neighbor table and restart 42
processing of the MLME-ASSOCIATION.indication. If an extended address 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 357

match is not found, the NLME shall, if possible, allocate a 16-bit network address
for the new device. See sub-clause 3.6.1.6 and sub-clause 3.6.1.7 for an 1
explanation of the address assignment mechanisms. 2
3
If the potential parent does not have the capacity to accept more children, the 4
NLME shall terminate the procedure and indicate this fact in the subsequent 5
MLME-ASSOCIATE.response primitive to the MAC sub-layer. The Status 6
parameter of this primitive shall indicate that the PAN is at capacity. 7
If the request to join is granted, the NLME of the parent shall create a new entry 8
for the child in its neighbor table using the supplied device information and 9
indicate a successful association in the subsequent MLME-ASSOCIATE.response 10
primitive to the MAC sub-layer. If the value of nwkSecurityLevel is 0x00, the 11
relationship field of the new neighbor table entry shall be set to the value 0x01 12
indicating that the neighbor is a child; otherwise, it shall be set to 0x05 indicating 13
an unauthenticated child. The status of the response transmission to the child is 14
communicated back to the network layer via the MLME-COMM- 15
STATUS.indication primitive. 16
17
If the transmission was unsuccessful (i.e. the MLME-COMM-STATUS.indication 18
primitive contained a Status parameter not equal to SUCCESS), the NLME shall 19
terminate the procedure. If the transmission was successful, the NLME shall 20
notify the next higher layer that a child has just joined the network by issuing the 21
NLME-JOIN.indication primitive. 22
The procedure for successfully joining a device to the network is illustrated in the 23
MSC shown in Figure 3.35. 24
25
26
MLME-ASSOCIATE.indication
27
28
Check Extended Address
and assign short address 29
MLME-ASSOCIATE.response 30
MLME-COMM-STATUS.indication 31
32
Update Beacon Payload
33
MLME-SET.request(macBeaconPayload)
34
35
MLME-SET.confirm

NLME-JOIN.indication
36
37
APL NWK MAC 38
39
Figure 3.35 Procedure for Handling a Join Request 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
358 Network Specification

3.6.1.4.2 Joining or Rejoining a Network Using NWK Rejoin


1
Devices that have lost all connection to the network, for example a ZED that can 2
no longer communicate successfully with its parent, can rejoin the network using 3
the NWK rejoin request and NWK rejoin response commands. The rejoining 4
procedure is identical to the association procedure described in the previous 5
section, except that the MAC association procedure is replaced by an exchange 6
involving the rejoin request and rejoin response commands, and, because NWK 7
commands make use of NWK security, no authentication step is performed. Using 8
these commands instead of the MAC procedure allows a device to rejoin a 9
network that does not currently allow new devices to join. 10
Devices that are joining a network for the first time may also use a variant of this 11
procedure as described in the following sub-clauses. 12
13
3.6.1.4.2.1 Child Procedure 14
15
The procedure for joining or rejoining a network using the NWK rejoin procedure 16
shall be initiated by issuing the NLME-JOIN.request primitive, as shown in 17
Figure 3.36, with the RejoinNetwork parameter set to 0x02 and the 18
ExtendedPANId parameter set to the ExtendedPANId of the network to rejoin. 19
The device type field of the CapabilityInformation parameter shall be set to 1 if 20
the device is intended to join as a router and to 0 otherwise. 21
22
The ScanChannels parameter shall be set to indicate which channels are to be
23
scanned to locate this network and the ScanDuration parameter set to indicate the
24
length of time to be spent scanning each channel.
25
Upon receipt of this primitive, the NWK layer shall issue an MLME- 26
SCAN.request primitive asking the MAC sub-layer to perform an active scan. 27
28
Every beacon frame received during the scan having a non-zero length payload
29
shall cause the MLME-BEACON-NOTIFY.indication primitive to be issued from
30
the MAC sub-layer of the scanning device to its NLME. The NLME of the
31
scanning device shall check the ExtendedPANId contained within the beacon
32
payload to see if it is of the correct value. If not, the beacon is ignored. Otherwise,
33
the device shall copy the relevant information from each received beacon (see
34
Figure 3.49 for the structure of the beacon payload) into its neighbor table (see
35
Table 3.48 and Table 3.49 for the contents of a neighbor table entry).
36
Once the MAC sub-layer signals the completion of the scan by issuing the 37
MLME-SCAN.confirm primitive to the NLME, the NWK layer shall search its 38
neighbor table for a suitable parent device. A suitable parent device shall advertise 39
device capacity of the type requested in the JoinAsRouter parameter, shall have 40
the most recent update id, where the determination of most recent update id must 41
take into account that the update id will wrap back to zero, and shall have a link 42
cost (see sub-clause 3.6.3.1) of 3, at most. If the neighbor table contains no 43
devices that are suitable parents, the NLME shall respond with an NLME- 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 359

JOIN.confirm with a Status parameter of NOT_PERMITTED. If the neighbor


table has more than one device that could be a suitable parent, the device which is 1
at a minimum depth from the ZigBee coordinator shall be chosen. 2
3
Once a suitable parent is identified, the NLME shall construct a NWK rejoin 4
request command frame. The destination address field of the NWK header shall 5
have a value equal to the 16-bit network address of the parent candidate chosen 6
from the neighbor table. The source address field of the NWK header shall be set 7
to the value of the nwkNetworkAddress attribute of the NIB. Both the source IEEE 8
address field and the destination IEEE address field shall be present in the NWK 9
header. If the device is joining this network for the first time, and the value of the 10
nwkNetworkAddress attribute of its NIB has a value of 0xffff indicating that it is 11
not currently joined to a network, the device shall select a 16-bit network address 12
for itself and set the nwkNetworkAddress attribute to this value. The address 13
should be randomly selected according to the procedures outlined in sub- 14
clause 3.6.1.7. In this case, and in any case where the nwkAddrAlloc attribute of 15
the NIB has a value of 0x02 indicating stochastic addressing, the allocate address 16
sub-field of the capability information field of the command payload shall be set 17
to 0 indicating a self-selected address. 18
After the successful transmission of the rejoin request command using the MAC 19
data service, the network layer shall load a countdown timer with a value of 20
aResponseWaitTime ([B1]). If this timer elapses before a rejoin response 21
command frame is received, then the rejoin was unsuccessful. If the receiver on 22
when idle field of the CapabilityInformation parameter is equal to 1, the device 23
shall issue a MLME-POLL.request to the potential parent to retrieve the rejoin 24
response command. If the receiver on when idle field is equal to 0, polling is not 25
required.20 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 destination IEEE address field and the 29
source IEEE address fields of the command frame NWK header. If the destination 30
IEEE address field is not equal in value to the IEEE address of the receiving 31
device or if the source IEEE address field is not equal in value to the IEEE address 32
of the most recent potential parent to which a rejoin request command frame was 33
sent (or the current parent in the case of an unsolicited rejoin response), then the 34
rejoin response command frame shall be discarded without further processing. 35
If the rejoin status field within the rejoin response command frame indicates a 36
refusal to permit rejoining on the part of the neighboring device (that is, PAN at 37
capacity or PAN access denied), then the device attempting to rejoin should set the 38
potential parent bit to 0 in the corresponding neighbor table entry to indicate a 39
failed join attempt. Setting the potential parent bit to 0 ensures that the NWK layer 40
will not issue another request to rejoin to the same neighboring device. If the 41
42
43
20. CCB #802 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
360 Network Specification

attempt to join was unsuccessful, the NLME shall attempt to find another suitable
parent from the neighbor table. If no such device can be found, the NLME shall 1
issue the NLME-JOIN.confirm primitive with the Status parameter set to 2
NOT_PERMITTED. If the attempt to join is unsuccessful and there is a second 3
neighboring device that could be a suitable parent, the NWK layer shall initiate 4
the NWK rejoin procedure with the second device. The NWK layer shall repeat 5
this procedure until it either rejoins the PAN successfully or exhausts its options to 6
rejoin the PAN. If the device cannot successfully rejoin the PAN specified by the 7
next higher layer, the NLME shall terminate the procedure by issuing the NLME- 8
JOIN.confirm primitive with the Status parameter set to NOT_PERMITTED. In 9
this case, the device shall not receive a valid logical address and shall not be 10
permitted to transmit on the network. If the attempt to rejoin was successful, the 11
NWK rejoin response command received by the NWK layer shall contain a 16-bit 12
logical address unique to that network, which the child can use in future 13
transmissions. Note that this address may be identical to the current 16-bit 14
network address of the device stored in the nwkNetworkAddress attribute of the 15
NIB. The NWK layer shall then set the relationship field in the corresponding 16
neighbor table entry to indicate that the neighbor is its parent. By this time, the 17
parent shall have added the new device to its neighbor table. Furthermore, the 18
NWK layer shall update the values of nwkNetworkAddress, nwkUpdateId, and 19
nwkPANId in the NIB if necessary. 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 361

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Figure 3.36 Child Rejoin Procedure 23
24
3.6.1.4.2.2 Parent Procedure 25
26
The procedure for a ZigBee coordinator or router to rejoin a device to its network 27
using the NWK rejoin procedure is initiated by the arrival of a NWK layer rejoin 28
command frame via the MAC data service. Only those devices that are either 29
ZigBee coordinators or ZigBee routers shall initiate this procedure. If this 30
procedure is initiated on any other device, the NLME shall terminate the 31
procedure. When this procedure is initiated, the NLME of a potential parent shall 32
first determine whether it already has knowledge of the requesting device. To do 33
this, the NLME shall search its neighbor table in order to determine whether a 34
matching 64-bit, extended address can be found. If an extended address match is 35
found, the NLME shall check that the supplied DeviceCapabilities match the 36
device type on record in the neighbor table. If the device type matches, the NLME 37
shall consider the join attempt successful and use the 16-bit network address 38
found in its neighbor table as the network address of the joining device. If a device 39
type match is not found, the NLME shall remove all records of the device in its 40
neighbor table and restart processing of the NWK layer rejoin command. 41
42
If the potential parent does not have the capacity to accept the joining device, the
43
NLME shall terminate the procedure and indicate this fact in the subsequent rejoin
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
362 Network Specification

response command. The Status parameter of this command shall indicate that the
PAN is at capacity. 1
2
If the request to rejoin is granted, the NLME of the parent shall create a new entry 3
for the child in its neighbor table, or modify the existing entry if one such already 4
exists, using the supplied device information, and indicate a successful rejoin by 5
replying to the requesting device with a NWK rejoin response command. If the 6
nwkAddrAlloc attribute of the NIB has a value of 0x00, indicating tree addressing, 7
the NLME shall allocate new a 16-bit network address for the joining device. See 8
sub-clause 3.6.1.6 and sub-clause 3.6.1.7 for an explanation of the address 9
assignment mechanisms. 10
If the nwkAddrAlloc attribute of the NIB does not have a value of 0x00, the 11
allocate address sub-field of the capabilities information field of the rejoin request 12
command frame payload may have a value of 0 indicating a self-assigned or pre- 13
existing network address. In this case, as is the case with all NWK command 14
frames, the 16-bit network address in the source address field of the NWK header, 15
in combination with the 64-bit IEEE address from the source IEEE address field 16
of the network header should be checked for address conflicts as described in sub- 17
clause 3.6.1.9. If an address conflict is discovered, a new, and non-conflicting, 18
address shall be chosen for the joining device and shall be placed in the network 19
address field of command frame payload of the outgoing rejoin response 20
command frame. Otherwise, the contents of the source address field of the 21
incoming rejoin request command frame shall be placed in the network address 22
field of the command frame payload of the outgoing rejoin response command 23
frame. 24
25
The NLME shall then notify the next higher layer that a child has just rejoined the 26
network by issuing the NLME-JOIN.indication primitive. The procedure for 27
successfully rejoining a device to the network is illustrated in the MSC shown in 28
Figure 3.37. 29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 363

MCPS-DATA.indication(NWK_REJOIN_REQUEST)
1
Check Extended Address
2
and if appropriate assign 3
short address
MCPS-DATA.request(NWK_REJOIN_RESPONSE)
4
MCPS-DATA.confirm
5
6
Update Beacon Payload
7
MLME-SET.request(macBeaconPayload) 8
MLME-SET.confirm 9
NLME-JOIN.indication 10
11
12
APL NWK MAC 13
14
Figure 3.37 Parent Rejoin Procedure 15
16
3.6.1.4.3 Joining a Network Directly 17
This sub-clause specifies how a device can be directly added to a network by a 18
previously designated parent device (ZigBee coordinator or router). In this case, 19
the parent device is preconfigured with the 64-bit address of the child device. The 20
following text describes how this prior address knowledge may be used to 21
establish the parent-child relationship. 22
23
The procedure for a ZigBee coordinator or router to directly join a device to its 24
network is initiated by issuing the NLME-DIRECT-JOIN.request primitive with 25
the DeviceAddress parameter set to the address of the device to be joined to the 26
network. Only those devices that are either a ZigBee coordinator or a ZigBee 27
router may initiate this procedure. If this procedure is initiated on any other 28
device, the NLME may terminate the procedure and notify the next higher layer of 29
the illegal request by issuing the NLME-DIRECT-JOIN.confirm primitive with 30
the Status parameter set to INVALID_REQUEST. 31
When this procedure is initiated, the NLME of the parent shall first determine 32
whether the specified device already exists on its network. To do this, the NLME 33
shall search its neighbor table in order to determine whether a matching 64-bit, 34
extended address can be found. If a match is found, the NLME shall terminate the 35
procedure and notify the next higher layer that the device is already present in the 36
device list by issuing the NLME-DIRECT-JOIN.confirm primitive with the Status 37
parameter set to ALREADY_PRESENT. 38
39
If a match is not found, the NLME shall, if possible, allocate a 16-bit network 40
address for the new device as well as a new neighbor table entry. See sub- 41
clause 3.6.1.6 and sub-clause 3.6.1.7 for an explanation of the address assignment 42
mechanisms. If the parent device has no more room in its neighbor table, the 43
NLME shall terminate the procedure and notify the next higher layer of the 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
364 Network Specification

unavailable capacity by issuing the NLME-DIRECT-JOIN.confirm primitive with


the Status parameter set to NEIGHBOR_TABLE_FULL. If capacity is available, 1
the NLME shall inform the next higher layer that the device has joined the 2
network by issuing the NLME-DIRECT-JOIN.confirm primitive with the Status 3
parameter set to SUCCESS. 4
5
Once the parent has added the child to its network, it is still necessary for the child 6
to make contact with the parent to complete the establishment of the parent-child 7
relationship. The child shall fulfill this requirement by initiating the orphaning 8
procedure, which is described in sub-clause 3.6.1.4.3.1. 9
A parent that supports direct joining shall follow the procedure illustrated in 10
Figure 3.38 to successfully join a device to the network directly. This procedure 11
does not require any over-the-air transmissions. 12
13
14
Parent Parent Parent 15
16
APL NWK MAC 17
NLME-DIRECT- 18
JOIN.request(DeviceAddress) 19
20
Check extended address and 21
assign logical address 22
NLME -DIRECT- 23
JOIN.confirm 24
25
26
27
Figure 3.38 Joining a Device to a Network Directly
28
3.6.1.4.3.1 Joining or Re-joining a Network Through Orphaning 29
30
This sub-clause specifies how the orphaning procedure can be initiated by a 31
device that has been directly joined to a network (joining through orphaning) or 32
by a device that was previously joined to a network but has lost contact with its 33
parent (re-joining through orphaning). 34
35
A device that has been added to a network directly shall initiate the orphan
36
procedure in order to complete the establishment of its relationship with its parent.
37
The application on the device will determine whether to initiate this procedure
38
and, if so, will notify the network layer upon power up.
39
A device that was previously joined to a network has the option of initiating the 40
orphan procedure if its NLME repeatedly receives communication failure 41
notifications from its MAC sub-layer. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 365

3.6.1.4.3.2 Child Procedure


1
The optional joining through orphaning procedure is initiated by a device using 2
the NLME-JOIN.request primitive with the RejoinNetwork parameter set to 0x01. 3
When this procedure is initiated, the NLME shall first request that the MAC sub- 4
layer perform an orphan scan over the over the set of channels given by the 5
ScanChannels parameter. An orphan scan is initiated by issuing the MLME- 6
SCAN.request primitive to the MAC sub-layer, and the result is communicated 7
back to the NLME via the MLME-SCAN.confirm primitive. 8
9
If the child has found its parent, the orphan scan was successful and the NLME 10
shall inform the next higher layer of the success of its request to join or re-join the 11
network by issuing the NLME-JOIN.confirm primitive with the Status parameter 12
set to SUCCESS. 13
Note that if the child device is joining for the first time or if the child device has 14
previously been joined to the network, but has failed to retain tree depth 15
information as prescribed in sub-clause 3.6.8, it may not be able to operate 16
correctly on the network without taking measures, outside the scope of this 17
specification, for the recovery of this information. 18
19
If the orphan scan was unsuccessful (the parent has not been found), the NLME 20
shall terminate the procedure and notify the next higher layer that no networks 21
were found. This is achieved by issuing the NLME-JOIN.confirm primitive with 22
the Status parameter set to NO_NETWORKS. 23
The procedure for a child to successfully join or re-join a network through 24
orphaning is illustrated in the MSC shown in Figure 3.39 25
26
.
27
NLME-JOIN.request( RejoinNetwork = 0x01 ) 28
NLME-JOIN.request 29
30
MLME-SCAN.request
31
Perform
32
Orphan Scan
33
MLME-SCAN.confirm
34
NLME-JOIN.confirm
35
36
37
Child Child Child
APL NWK MAC 38
39
40
Figure 3.39 Child Procedure for Joining or Re-Joining a Network
Through Orphaning 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
366 Network Specification

3.6.1.4.3.3 Parent Procedure


1
A device is notified of the presence of an orphaned device when it receives the 2
MLME-ORPHAN.indication primitive from the MAC sub-layer. Only devices 3
that are either ZigBee coordinators or ZigBee routers (that is, devices with 4
parental capabilities) shall initiate this procedure. If this procedure is initiated by 5
any other device, the NLME shall terminate the procedure. 6
When this procedure is initiated, the NLME shall first determine whether the 7
orphaned device is its child. This is accomplished by comparing the extended 8
address of the orphaned device with the addresses of its children, as recorded in its 9
neighbor table. If a match is found (the orphaned device is its child), the NLME 10
shall obtain the corresponding 16-bit network address and include it in its 11
subsequent orphan response to the MAC sub-layer. The orphan response to the 12
MAC sub-layer is initiated by issuing the MLME-ORPHAN.response primitive, 13
and the status of the transmission is communicated back to the NLME via the 14
MLME-COMM-STATUS.indication primitive. 15
16
If an address match is not found (the orphaned device is not its child), the 17
procedure shall be terminated without indication to the higher layer. 18
The procedure for a parent to join or re-join its orphaned child to the network is 19
illustrated in the MSC shown in Figure 3.40. 20
21
22
23
MLME-ORPHAN.indication
24
25
Check Extended Address and if
appropriate assign short address 26
27
MLME-ORPHAN.response
28
MLME-COMM-STATUS.indication 29
NLME-JOIN.indication 30
31
32
APL NWK MAC 33
34
Figure 3.40 Parent Procedure for Joining or Re-Joining a Device to its 35
Network Through Orphaning 36
37
3.6.1.5 Neighbor Tables 38
39
The neighbor table of a device shall contain information on every device within 40
transmission range, up to some implementation-dependent limit. 41
The neighbor table is useful in two contexts. First of all, it is used during network 42
discovery or rejoining to store information about routers within RF reception 43
range that may be candidate parents. Second, after the device has joined a 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 367

network, it is used to store relationship and link-state information about


neighboring devices in that network. A table entry shall be updated every time a 1
device receives any frame from the corresponding neighbor. 2
3
The outgoing cost field contains the cost of the link as measured by the neighbor. 4
The value is obtained from the most recent link status command frame received 5
from the neighbor. A value of 0 indicates that no link status command listing this 6
device has been received. 7
The age field indicates the number of nwkLinkStatusPeriod intervals that have 8
passed since the last link status command frame was received, up to a maximum 9
value of nwkRouterAgeLimit. 10
11
Mandatory and optional data that are used in normal network operation are listed 12
in Table 3.48. 13
Table 3.48 Neighbor Table Entry Format 14
15
Field 16
Field Name Type Valid Range Description
17
Extended address Integer An extended 64-bit, 64-bit IEEE address that is unique 18
IEEE address to every device. This field shall be 19
present if the neighbor is a parent
20
or child of the device.
21
Network address Network 0x0000 – 0xffff The 16-bit network address of the 22
address neighboring device.
23
This field shall be present in every 24
neighbor table entry. 25
Device type Integer 0x00 – 0x02 The type of neighbor device: 26
0x00 = ZigBee coordinator 27
28
0x01 = ZigBee router
29
0x02 = ZigBee end device 30
This field shall be present in every 31
neighbor table entry. 32
RxOnWhenIdle Boolean TRUE or FALSE Indicates if neighbor’s receiver is 33
enabled during idle periods: 34
35
TRUE = Receiver is on
36
FALSE = Receiver is off 37
This field should be present for 38
entries that record the parent or 39
children of a ZigBee router or 40
ZigBee coordinator. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
368 Network Specification

Table 3.48 Neighbor Table Entry Format (Continued)


1
Field 2
Field Name Type Valid Range Description
3
Relationship Integer 0x00 – 0x05 The relationship between the 4
neighbor and the current device: 5
0x00=neighbor is the parent 6
7
0x01=neighbor is a child
8
0x02=neighbor is a sibling 9
0x03=none of the above 10
11
0x04=previous child
12
0x05=unauthenticated child 13
This field shall be present in every 14
neighbor table entry. 15
Transmit Failure Integer 0x00 – 0xff A value indicating if previous 16
transmissions to the device were 17
successful or not. Higher values 18
indicate more failures. 19
This field shall be present in every 20
neighbor table entry. 21
LQI Integer 0x00 – 0xff The estimated link quality for RF 22
transmissions from this device. 23
See sub-clause 3.6.3.1 for a 24
discussion of how this is 25
calculated.
26
This field shall be present in every 27
neighbor table entry. 28
Outgoing Cost Integer 0x00 - 0xff The cost of an outgoing link as 29
measured by the neighbor. A value 30
of 0 indicates no outgoing cost is
31
available.
32
This field is mandatory if 33
nwkSymLink = TRUE.
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 369

Table 3.48 Neighbor Table Entry Format (Continued)


1
Field 2
Field Name Type Valid Range Description
3
Age Integer 0x00 - 0xff The number of 4
nwkLinkStatusPeriod intervals 5
since a link status command was 6
received.
7
This field is mandatory if 8
nwkSymLink = TRUE. 9
Incoming beacon Integer 0x000000-0xffffff The time, in symbols, at which the 10
timestamp last beacon frame was received 11
from the neighbor. This value is
12
equal to the timestamp taken when
the beacon frame was received, as 13
described in IEEE 802.15.4-2003 14
[B1]. 15
This field is optional. 16
17
Beacon transmission Integer 0x000000-0xffffff The transmission time difference,
time offset in symbols, between the 18
neighbor’s beacon and its parent’s 19
beacon. This difference may be 20
subtracted from the corresponding 21
incoming beacon timestamp to 22
calculate the beacon transmission
time of the neighbor’s parent. 23
24
This field is optional. 25
26
Information that may be used during network discovery and rejoining, as 27
described above, is shown in Table 3.49. All of the fields shown are optional and 28
should not be retained after the NLME has chosen a network to join. Neighbor 29
table entries corresponding to devices that are not members of the chosen network 30
should similarly be discarded. 31
Table 3.49 Additional Neighbor Table Fields 32
33
Field 34
Field Name Type Valid Range Description
35
Extended PAN ID Integer 0x00000000000000 The 64-bit unique identifier of the 36
01 - network to which the device 37
0xfffffffffffffffe belongs. 38
Logical channel Integer Selected from the The logical channel on which the 39
available logical network is operating. 40
channels supported
41
by the PHY.
42
Depth Integer 0x00 – 0x0f The tree depth of the neighbor 43
device.
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
370 Network Specification

Table 3.49 Additional Neighbor Table Fields (Continued)


1
Field 2
Field Name Type Valid Range Description
3
Beacon order Integer 0x00 – 0x0f The IEEE 802.15.4 beacon order 4
for the device. 5
Permit joining Boolean TRUE or FALSE An indication of whether the 6
device is accepting joining 7
requests. 8
TRUE = device is accepting join 9
requests. 10
FALSE =device is not accepting 11
join requests. 12
Potential parent Integer 0x00 – 0x01 An indication of whether the 13
device has been ruled out as a 14
potential parent. 15
0x00 indicates that the device is 16
not a potential parent. 17
18
0x01 indicates that the device is a
potential parent. 19
20
21
3.6.1.6 Distributed Address Assignment Mechanism 22
The default value of the NIB attribute nwkAddrAlloc is 0x00, where network 23
addresses are assigned using a distributed addressing scheme that is designed to 24
provide every potential parent with a finite sub-block of network addresses. These 25
addresses are unique within a particular network and are given by a parent to its 26
children. The ZigBee coordinator determines the maximum number of children 27
any device, within its network, is allowed. Of these children, a maximum of 28
nwkMaxRouters can be router-capable devices. The remaining devices shall be 29
reserved for end devices. Every device has an associated depth that indicates the 30
minimum number of hops a transmitted frame must travel, using only parent-child 31
links, to reach the ZigBee coordinator. The ZigBee coordinator itself has a depth 32
of 0, while its children have a depth of 1. Multi-hop networks have a maximum 33
depth that is greater than 1. The ZigBee coordinator also determines the maximum 34
depth of the network. 35
36
Given values for the maximum number of children a parent may have, 37
nwkMaxChildren (Cm), the maximum depth in the network, nwkMaxDepth (Lm), 38
and the maximum number of routers a parent may have as children, 39
nwkMaxRouters (Rm), we may compute the function, Cskip(d), essentially the 40
size of the address sub-block being distributed by each parent at that depth to its 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 371

router-capable child devices for a given network depth, d, as follows:


1
2
⎧1 + Cm ( Lm - d -1), if Rm = 1 3

Cskip(d ) = ⎨1 + Cm - Rm - Cm * Rm Lm-d -1 4
⎪⎩ , otherwise 5
1 - Rm
6
7
If a device has a Cskip(d) value of 0, then it shall not be capable of accepting
8
children and shall be treated as a ZigBee end device for purposes of this
9
discussion. The NLME of the device shall set the End device Capacity and Router
10
Capacity sub fields of the MAC sub-layer beacon payload to 0.
11
A parent device that has a Cskip(d) value greater than 0 shall accept child devices 12
and shall assign addresses to them differently depending on whether or not the 13
child device is router-capable. 14
15
Network addresses shall be assigned to router-capable child devices using the
16
value of Cskip(d) as an offset. A parent assigns an address that is 1 greater than its
17
own to its first router-capable child device. Subsequently assigned addresses to
18
router-capable child devices are separated from each other by Cskip(d). A
19
maximum of nwkMaxRouters of such addresses shall be assigned.
20
Network addresses shall be assigned to end devices in a sequential manner with 21
the nth address, An , given by the following equation: 22
23
A n = A parent + Cskip (d )* Rm + n 24
25
26
27
Where d(1<n< (Cm - Rm)) and A parent represents the address of the parent. 28
The Cskip(d) values for an example network having nwkMaxChildren=8, 29
nwkMaxRouters=4 and nwkMaxDepth=3 are calculated and listed in Table 3.50. 30
Figure 3.41 illustrates the example network. 31
32
Table 3.50 Example Addressing Offset Values for Each Given
Depth Within the Network 33
34
Offset Value, 35
Depth in the Network, d Cskip(d) 36
0 31 37
38
1 7 39
2 1 40
3 0
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
372 Network Specification

[Cskip = 1, Addr = 40] 1


2
3
4
[Cskip = 7, Addr = 32]
[Cskip = 1, Addr = 33] 5
6
[Addr = 126]
[Cskip = 7, Addr = 63] 7
8
9
[Cskip = 31, Addr = 0]
[Addr = 125] 10
11
12
[Cskip = 7, Addr = 1] [Cskip = 7, Addr = 94]
13
14
[Cskip = 1, Addr = 2]
[Cskip = 1, Addr = 95] 15
[Cskip = 1, Addr = 102]
16
17
18
19
[Cskip = 0, Addr = 103] 20
21
Figure 3.41 Address Assignment in an Example Network
22
23
Because an address sub-block cannot be shared between devices, it is possible that
24
one parent exhausts its list of addresses while a second parent has addresses that
25
go unused. A parent having no available addresses shall not permit a new device
26
to join the network by setting the End Device Capacity and Router Capacity sub
27
fields of the MAC sub-layer beacon payload to 0.
28
In this situation, the new device shall find another parent. If no other parent is 29
available within transmission range of the new device, the device shall be unable 30
to join the network unless it is physically moved or there is some other change. 31
32
3.6.1.7 Stochastic Address Assignment Mechanism 33
34
When the NIB attribute nwkAddrAlloc has value 0x02, addresses shall be chosen 35
at random. The value of nwkMaxRouter is not relevant in this case. The random 36
address assigned shall conform to the NIST testing regimen described in reference 37
[B12]. When a device joins the network using MAC association, its parent shall 38
choose a random address that does not already appear in any entry in the parent’s 39
NIB. Under stochastic addressing, once a device has been assigned an address, it 40
has no reason to relinquish that address and should retain it unless it receives an 41
indication that its address is in conflict with that of another device on the network. 42
Furthermore, devices may self-assign random addresses under stochastic 43
addressing and retain them, as in the case of joining a network using the rejoin 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 373

command frame (see sub-clause 3.6.1.4.2). The ZigBee coordinator, which has no
parent, shall always have the address 0x0000. 1
2
3.6.1.8 Installation and Addressing 3
4
It should be clear that nwkMaxDepth roughly determines the number of hops in 5
network terms from the root of the tree to the farthest end device. In principle, 6
nwkMaxDepth also determines the overall network diameter. In particular, for an 7
ideal network layout in which the ZigBee coordinator is located in the center of 8
the network, as illustrated in Figure 3.41, the network diameter should be 2* 9
nwkMaxDepth. In practice, application-driven placement decisions and order of 10
deployment may lead to a smaller diameter. In this case, nwkMaxDepth provides a 11
lower bound on the network diameter while the 2* nwkMaxDepth provides the 12
upper bound. 13
Finally, due to the fact that the tree is not dynamically balanced, when 14
nwkAddrAlloc has a value of 0x00, the possibility exists that certain installation 15
scenarios, such as long lines of devices, may exhaust the address capacity of the 16
network long before the real capacity is reached. 17
18
Under stochastic address assignment, nwkMaxDepth is related to the number of 19
hops across the network. This is not a controlled value in networks using 20
stochastic address assignment. 21
22
3.6.1.9 Address Conflicts 23
An address conflict occurs when two devices in the same network have identical 24
values for nwkNetworkAddress. Preventing all such conflicts, for example by 25
using tree address assignment and prohibiting the reuse of assigned addresses, is 26
not always practical. This section describes how address conflicts that do occur 27
can be detected and corrected. Address conflict detection shall be enabled if the 28
NIB attribute nwkUniqueAddr is FALSE. 29
30
Note that the network addresses used in routing messages are verified during the 31
route discovery process. The device_annc now is also used to verify addresses. 32
The verification applies only to devices, links, and information present at the time 33
of the discovery or device_annc. Verification can be achieved at other times, such 34
as before sending a unicast directly to a neighbor, by sending a network status 35
command with a status code value of 0x0e, indicating address verification. 36
If a device receives a broadcast data frame and discovers an address conflict as a 37
result of the receipt, as discussed below in sub-clause 3.6.1.9.2, it should not 38
retransmit the frame as usual but shall discard it before taking the resolution 39
actions described below in sub-clause 3.6.1.9.3.21 40
41
42
43
21. CCB #869 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
374 Network Specification

3.6.1.9.1 Obtaining Address Information


1
The NWK layer obtains address information from incoming messages, including 2
both NWK commands and data messages. Address information from data 3
messages is passed to the NWK layer by being added to the network address map 4
table in the NIB. 5
The ability to detect address conflicts is enhanced by adding one or both of the 6
Destination IEEE Address and Source IEEE Address fields to a message’s NWK 7
frame. When nwkUniqueAddr is FALSE, all NWK command messages shall 8
contain the source IEEE address and also the destination IEEE address if it is 9
known by the source device. 10
11
When nwkUniqueAddr is FALSE, route request commands shall include the 12
sender's IEEE address in the Sender IEEE address field. This ensures that devices 13
are aware of their neighbors' IEEE addresses. 14
3.6.1.9.2 Detecting Address Conflicts 15
16
After joining a network or changing address due to a conflict, a device shall send 17
either a device_annc or initiate a route discovery prior to sending messages. 18
Upon receipt of a frame containing a 64-bit IEEE address in the NWK header, the 19
contents of the nwkAddressMap attribute of the NIB and neighbor table should be 20
checked for consistency. 21
22
If the destination address field of the NWK Header of the incoming frame is equal 23
to the nwkNetworkAddress attribute of the NIB then the NWK layer shall check 24
the destination IEEE address field, if present, against the value of 25
aExtendedAddress. If the IEEE addresses are not identical then a local address 26
conflict has been detected on nwkNetworkAddress. 27
If a neighbor table or address map entry is located in which the 64-bit address is 28
the null IEEE address (0x00....00), the 64-bit address in the table can be updated. 29
However, if the 64-bit address is not the null IEEE address and does not 30
correspond to the received 16-bit address, the device has detected a conflict 31
elsewhere in the network. 32
33
When a broadcast frame is received that creates a new BTR, if the Source Address 34
field in the NWK Header is equal to the nwkNetworkAddress attribute of the NIB 35
then a local address conflict has been detected on nwkNetworkAddress.22 36
Address conflicts are resolved as described in sub-clause 3.6.1.9.3. 37
38
3.6.1.9.3 Resolving Address Conflicts 39
40
If a ZigBee coordinator or Router determines that there are multiple users of an
41
address that is not its own, it shall inform the network by broadcasting a network
42
43
22. CCB #869 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 375

status command with a status code of 0x0d indicating address conflict, and with
the offending address in the destination address field. The network status 1
command shall be broadcast to 0xFFFD, i.e. all devices with macRxOnWhenIdle 2
= TRUE. The device shall delay initiation of this broadcast by a random jitter 3
amount bounded by nwkcMaxBroadcastJitter. If during this delay a network 4
status is received with the identical payload, the device shall cancel its own 5
broadcast. 6
7
If a device determines that there are one or more other users of its own network 8
address, or if the device receives a network status command with a status code of 9
0x0d indicating address conflict, and its own address in the destination address 10
field, then that device shall obtain a new address. 11
If the conflict is detected on a ZigBee end device or nwkAddrAlloc is not equal to 12
stochastic address assignment then the device shall perform a rejoin to obtain a 13
new address. Otherwise, the device that requires a new address shall pick a new 14
address randomly, avoiding all addresses that appear in NIB entries. 15
16
If a parent device detects or is informed of a conflict with the address of a child, 17
the parent shall pick a new address for the child and shall send an unsolicited 18
rejoin response command frame to inform the child of the new address. To notify 19
the next higher layer of an address change, an NLME-NWK-STATUS.indication 20
shall be issued with status 'Network Address Update' and the new network address 21
as the value of the ShortAddr parameter.23 22
23
3.6.1.10 Leaving a Network 24
This sub-clause specifies methods for a device to remove itself from the network 25
and for the parent of a device to request its removal. In both cases, the children of 26
the removed device, if any, may also be removed. 27
28
3.6.1.10.1 Method for a Device to Initiate Its Own Removal from the Network 29
This sub-clause describes how a device can initiate its own removal from the 30
network in response to the receipt of an NLME-LEAVE.request primitive from 31
the next higher layer as shown in Figure 3.42. 32
33
34
35
36
37
38
39
40
41
42
43
23. CCB #814 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
376 Network Specification

1
2
3
4
5
6
7
8
9
10
11
Figure 3.42 Initiation of the Leave Procedure 12
13
When the NWK layer of a ZigBee router or ZigBee coordinator, receives the 14
NLME-LEAVE.request primitive with the DeviceAddress parameter equal to 15
NULL (indicating that the device is to remove itself) the device shall send a leave 16
command frame using the MCPS-DATA.request primitive with the DstAddr 17
parameter set to 0xffff indicating a MAC broadcast. The request sub-field of the 18
command options field of the leave command frame shall be set to 0. The value of 19
the remove children sub-field of the command options field of the leave command 20
shall reflect the value of the RemoveChildren parameter of the NLME- 21
LEAVE.request primitive, and the value of the Rejoin sub-field of the leave 22
command shall reflect the value of the Rejoin parameter of the NLME- 23
LEAVE.request primitive. After transmission of the leave command frame, it shall 24
issue a NLME-LEAVE.confirm primitive to the higher layer with the 25
DeviceAddress parameter equal to NULL. The Status parameter shall be 26
SUCCESS if the leave command frame was transmitted successfully. Otherwise, 27
the Status parameter of the NLME-LEAVE.confirm shall have the same value as 28
the Status parameter returned by the MCPS-DATA.confirm primitive. 29
30
If the device receiving the NLME-LEAVE.request primitive is a ZigBee end 31
device, then the device shall send a leave command frame using the MCPS- 32
DATA.request primitive with the DstAddr parameter set to the 16-bit network 33
address of its parent device, indicating a MAC unicast. The request and remove 34
children sub-fields of the command options field of the leave command frame 35
shall be set to 0. After transmission of the leave command frame, it shall set the 36
nwkExtendedPANId attribute of the NIB to 0x0000000000000000 and issue a 37
NLME-LEAVE.confirm primitive to the higher layer with the DeviceAddress 38
parameter equal to NULL. The Status parameter shall be SUCCESS if the leave 39
command frame was transmitted successfully. Otherwise, the Status parameter of 40
the NLME-LEAVE.confirm shall have the same value as the Status parameter 41
returned by the MCPS-DATA.confirm primitive. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 377

3.6.1.10.2 Method for a Device to Remove Its Child from the Network
1
This sub-clause describes how a device can initiate the removal from the network 2
of one of its child devices in response to the receipt of an NLME-LEAVE.request 3
primitive from the next higher layer as shown in Figure 3.43. 4
5
6
7
8
9
10
11
12
13
14
15
16
17
Figure 3.43 Procedure for a Device to Remove Its Child 18
19
When the NWK layer of a ZigBee coordinator or ZigBee router, receives the 20
NLME-LEAVE.request primitive with the DeviceAddress parameter equal to the 21
64-bit IEEE address of a child device, if the relationship field of the neighbor 22
table entry corresponding to that child device does not have a value of 0x05 23
indicating that the child has not yet authenticated, the device shall send a network 24
leave command frame using the MCPS-DATA.request primitive with the DstAddr 25
parameter set to the 16-bit network address of that child device. The request sub- 26
field of the command options field of the leave command frame shall have a value 27
of 1, indicating a request to leave the network. The value of the remove children 28
sub-field of the command options field of the leave command shall reflect the 29
value of the RemoveChildren parameter of the NLME-LEAVE.request primitive, 30
and the value of the Rejoin sub-field of the leave command shall reflect the value 31
of the Rejoin parameter of the NLME-LEAVE.request primitive. 32
If the relationship field of the neighbor table entry corresponding to the device 33
being removed has a value of 0x05, indicating that it is an unauthenticated child, 34
the device shall not send a network leave command frame. 35
36
Next, the NWK layer shall issue the NLME-LEAVE.confirm primitive with the 37
DeviceAddress parameter set to the 64-bit IEEE address of the child device being 38
removed. The Status parameter of the NLME-LEAVE.confirm primitive shall 39
have a value of SUCCESS if the leave command frame was not transmitted, i.e. in 40
the case of an unauthenticated child. Otherwise, the Status parameter of the 41
NLME-LEAVE.confirm shall have the same value as the Status parameter 42
returned by the MCPS-DATA.confirm primitive. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
378 Network Specification

After the child device has been removed, the NWK layer of the parent should
modify its neighbor table, and any other internal data structures that refer to the 1
child device, to indicate that the device is no longer on the network. It is an error 2
for the next higher layer to address and transmit frames to a child device after that 3
device has been removed. 4
5
If an unauthenticated child device is removed from the network before it is 6
authenticated, then the address formerly in use by the device being asked to leave 7
may be assigned to another device that joins subsequently. 8
ZigBee end devices have no child devices to remove and should not receive 9
NLME-LEAVE.request primitives with non-NULL DeviceAddress parameters. 10
11
3.6.1.10.3 Upon Receipt of the Leave Command Frame 12
Upon receipt of the leave command frame by the NWK layer via the MCPS- 13
DATA.indication primitive, as shown in Figure 3.44, the device shall check the 14
value of the request sub-field of the command options field of the command 15
frame. If the request sub-field has a value of 0, then the NWK layer shall issue the 16
NLME-LEAVE.indication primitive to the next higher layer with the device 17
address parameter equal to the value in the source IEEE Address sub-field of the 18
leave command frame. The device should also modify its neighbor table, and any 19
other internal data structures that refer to the leaving device, to indicate that it is 20
no longer on the network. It is an error for the next higher layer to address and 21
transmit frames to a device after that device has left the network. 22
23
24
25
APL NWK MAC 26
27
MCPS-DATA.indication (NWK_LEAVE) 28
29
NLME-LEAVE.indication (Remote Device)
30
31
Continue if
RemoveChildren=1 and 32
received from Parent
33
MCPS-DATA.request (NWK_LEAVE indication)
34
35
MCPS-DATA.confirm 36
NLME-LEAVE.indication (NULL)
37
38
39
40
Figure 3.44 On Receipt of a Leave Command 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 379

MCPS-DATA.indication(NWK_LEAVE) 1
NLME-LEAVE.indication( Remote Device ) 2
3
Continue on ZigBee Routers, 4
if RemoveChildren, and
received from Parent 5
MCPS-DATA.request(NWK_LEAVE Indication) 6
MCPS-DATA.confirm 7
NLME-LEAVE.indication( NULL )
8
9
10
APL NWK MAC 11
12
Figure 3.45 On Receipt of a Leave Command by a ZED
13
If, on receipt by the NWK layer of a ZigBee router of a leave command frame as 14
described above, the SrcAddr parameter of the MCPS-DATA.indication that 15
delivered the command frame is the 16-bit network address of the parent of the 16
recipient, and either the value of the request sub-field of the command options 17
field is found to have a value of 1 or the value of the remove children sub-field of 18
the command options field is found to have a value of 1, then the recipient shall 19
send a leave command frame using the MCPS-DATA.request primitive with the 20
DstAddr parameter set to 0xffff indicating a MAC broadcast. The request sub- 21
field of the command options field of the leave command frame shall be set to 0. 22
23
The value of the remove children sub-field of the command options field of the 24
outgoing leave command shall reflect the value of the same field for the incoming 25
leave command frame. After transmission of the leave command frame, it shall set 26
the nwkExtendedPANId attribute of the NIB to 0x0000000000000000 and it shall 27
issue a NLME-LEAVE.indication primitive to the higher layer with 28
DeviceAddress parameter equal to NULL. 29
If the request sub-field has a value of 1 and the source of the leave command 30
frame is a device other than the parent of the recipient, the frame shall be 31
immediately and silently discarded. 32
33
If a ZigBee end device receives a leave command frame as described above and 34
the SrcAddr parameter of the MCPS-DATA.indication that delivered the 35
command frame is the 16-bit network address of the parent of the recipient, it 36
shall set the nwkExtendedPANId attribute of the NIB to 0x0000000000000000 and 37
shall issue a NLME-LEAVE.indication primitive to the higher layer with 38
DeviceAddress parameter equal to NULL. 39
The NWK layer may employ retry techniques, as described in sub-clause 3.6.5 to 40
enhance the reliability of the leave procedure but, beyond this note, these 41
mechanisms are outside the scope of this specification. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
380 Network Specification

3.6.1.11 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 a 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.6.1.12 Resetting a Device 20
21
The NWK layer of a device shall be reset immediately following initial power-up, 22
before a join attempt to a new network and after a leave attempt where the device 23
is not intending to rejoin the network. This process should not be initiated at any 24
other time. A reset is initiated by issuing the NLME-RESET.request primitive to 25
the NLME and the status of the attempt is communicated back via the NLME- 26
RESET.confirm primitive. The reset process shall clear the routing table entries of 27
the device. 28
Some devices may store NWK layer quantities in non-volatile memory and 29
restore them after a reset. The WarmStart parameter of the NLME-RESET.request 30
may also be used for this purpose. When nwkAddrAlloc is equal to 0x00, a device 31
always gets a network address from its parent upon joining or rejoining. The new 32
network address may be different from its old network address. In such a case, any 33
device that is communicating with the device that has been reset must rediscover 34
the device using higher-layer protocols. When nwkAddrAlloc is equal to 0x02, a 35
device may use the same address on rejoining a network and therefore should not 36
discard its address on reset unless it does not intend to rejoin the same network. 37
38
3.6.1.13 Managing a PANId Conflict 39
40
Since the 16-bit PANID is not a unique number there is a possibility of a PANId 41
conflict. The next section explains how — through the use of the Network Report 42
and Network Update command frames — the PANId of a network can be updated. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 381

3.6.1.13.1 Detecting a PANId Conflict


1
Any device that is operational on a network and receives an MLME-BEACON- 2
NOTIFY.indication in which the PAN identifier of the beacon frame matches its 3
own PAN identifier but the EPID value contained in the beacon payload is either 4
not present or not equal to nwkExtendedPANID, shall be considered to have 5
detected a PAN Identifier conflict. 6
A node that has detected a PAN identifier conflict shall construct a Network 7
Report Command frame of type PAN Identifier Conflict which shall be sent to the 8
device identified by the address given in the nwkManagerAddr attribute of the 9
NIB. The Report Information field will contain a list of all the 16-bit PAN 10
identifiers that are being used in the local neighborhood. How this list is created is 11
outside the scope of the specification, however it is recommended that it be 12
constructed from the results of an MLME-SCAN.request of type ACTIVE. 13
14
3.6.1.13.2 Upon Receipt of a Network Report Command Frame 15
The device identified by the 16-bit network address contained within the 16
nwkManagerAddr parameter of the NIB shall be the recipient of network report 17
command frames of type PAN identifier conflict. 18
19
On receipt of the network report command frame, the designated network layer 20
function manager24 shall select a new 16-bit PAN identifier for the network. The 21
new PAN identifier is chosen at random, but a check is performed to ensure that 22
the chosen PAN identifier is not already in use in the local neighborhood and also 23
not contained within the Report Information field of the network report command 24
frame. 25
Once a new PAN identifier has been selected, the designated network layer 26
function manager25 shall first increment the NIB attribute nwkUpdateId 27
(wrapping around to 0 if necessary) and then shall construct a network update 28
command frame of type PAN identifier update. The update information field shall 29
be set to the value of the new PAN identifier. 30
31
After it sends out this command frame, the designated network layer function 32
manager26 shall start a timer with a value equal to 33
nwkNetworkBroadcastDeliveryTime seconds. When the timer expires, the ZigBee 34
coordinator shall change its current PAN ID to the newly selected one by reissuing 35
the MLME-START.request with the new PANID. 36
Upon transmission of the Network Update command frame the designated 37
network layer function manager27 shall create a NLME-NWK- 38
39
40
24. CCB #819 41
25. CCB #819 42
26. CCB #819 43
27. CCB #819 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
382 Network Specification

STATUS.indication primitive with the NetworkAddr parameter set to 0 and the


Status parameter set to PAN Identifier Update. 1
2
3.6.1.13.3 Upon Receipt of a Network Update Command Frame 3
On receipt of a network update command frame of type PAN identifier update, a 4
device shall start a timer with a value equal to 5
nwkNetworkBroadcastDeliveryTime seconds. When the timer expires, the device 6
shall change its current PAN Identifier to the value contained within the Update 7
Information field. 8
9
Upon transmission of the network update command frame the device shall create 10
a NLME-NWK-STATUS.indication primitive with the NetworkAddr parameter 11
set to 0 and the Status parameter set to PAN Identifier Update. 12
Upon receipt of the Network Update command from the device identified by the 13
nwkManagerAddr attribute of the NIB, the value contained in the update id field 14
shall be stored in nwkUpdateId attribute in the NIB. The beacon payload shall 15
also be updated. 16
17
18
3.6.2 Transmission and Reception 19
20
3.6.2.1 Transmission 21
22
Only those devices that are currently associated shall send data frames from the 23
NWK layer. If a device that is not associated receives a request to transmit a 24
frame, it shall discard the frame and notify the higher layer of the error by issuing 25
an NLDE-DATA.confirm primitive with a status of INVALID_REQUEST. 26
All frames handled by or generated within the NWK layer shall be constructed 27
according to the general frame format specified in Figure 3.5 and transmitted 28
using the MAC sub-layer data service. 29
30
In addition to source address and destination address fields, all NWK layer 31
transmissions shall include a radius field and a sequence number field. For data 32
frames originating at a higher layer, the value of the radius field may be supplied 33
using the Radius parameter of the NLDE-DATA.request primitive. If a value is 34
not supplied, then the radius field of the NWK header shall be set to twice the 35
value of the nwkMaxDepth attribute of the NIB (see clause 3.5). The NWK layer 36
on every device shall maintain a sequence number that is initialized with a random 37
value. The sequence number shall be incremented by 1, each time the NWK layer 38
constructs a new NWK frame, either as a result of a request from the next higher 39
layer to transmit a new NWK data frame or when it needs to construct a new 40
NWK layer command frame. After being incremented, the value of the sequence 41
number shall be inserted into the sequence number field of the frame's NWK 42
header. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 383

Once an NPDU is complete, if security is required for the frame, it shall be passed
to the security service provider for subsequent processing according to the 1
specified security suite (see sub-clause 4.2.2). Security processing is not required 2
if the SecurityEnable parameter of the NLDE-DATA.request is equal to FALSE. If 3
the NWK security level as specified in nwkSecurityLevel is equal to 0, or if the 4
frame originated at the higher layer and the nwkSecureAllFrames NIB attribute is 5
set to 0x00, then the security sub-field of the frame control field shall always be 6
set to 0. 7
8
On successful completion of the secure processing, the security suite returns the 9
frame to the NWK layer for transmission. The processed frame will have the 10
correct auxiliary header attached. If security processing of the frame fails and the 11
frame was a data frame, the frame will inform the higher layer of the NLDE- 12
DATA.confirm primitive’s status. If security processing of the frame fails and the 13
frame is a network command frame, it is discarded and no further processing shall 14
take place. 15
When the frame is constructed and ready for transmission, it shall be passed to the 16
MAC data service. An NPDU transmission is initiated by issuing the MCPS- 17
DATA.request primitive to the MAC sub-layer. The MCPS-DATA.confirm 18
primitive then returns the results of the transmission. 19
20
3.6.2.2 Reception and Rejection 21
22
In order to receive data, a device must enable its receiver. The next higher layer 23
may initiate reception using the NLME-SYNC.request primitive. On a beacon- 24
enabled network, receipt of this primitive by the NWK layer shall cause a device 25
to synchronize with its parent’s next beacon and, optionally, to track future 26
beacons. The NWK layer shall accomplish this by issuing an MLME- 27
SYNC.request to the MAC sub-layer. On a non-beacon-enabled network, the 28
NLME-SYNC.request shall cause the NWK layer of a device with 29
macRxOnWhenIdle set to FALSE to poll the device’s parent using the MLME- 30
POLL.request primitive. 31
On a non-beacon-enabled network, the NWK layer on a ZigBee coordinator or 32
ZigBee router shall ensure, to the maximum extent feasible, that the receiver is 33
enabled whenever the device is not transmitting. On a beacon-enabled network, 34
the NWK layer should ensure that the receiver is enabled when the device is not 35
transmitting during the active period of its own superframe and of its parent’s 36
superframe. The NWK layer may use the macRxOnWhenIdle attribute of the 37
MAC PIB for this purpose. 38
39
Once the receiver is enabled, the NWK layer will begin to receive frames via the 40
MAC data service. On receipt of each frame, the radius field of the NWK header 41
shall be decremented by 1. If, as a result of being decremented, this value falls to 42
0, the frame shall not, under any circumstances, be retransmitted. It may, however, 43
be passed to the next higher layer or otherwise processed by the NWK layer as 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
384 Network Specification

outlined elsewhere in this specification. The following data frames shall be passed
to the next higher layer using the NLDE-DATA.indication primitive: 1
2
• Frames with a broadcast address that matches a broadcast group of which the 3
device is a member. 4
• Unicast data frames and source-addressed data frames for which the destination 5
address matches the device's network address. 6
7
• Multicast data frames whose group identifier is listed in the nwkGroupIDTable. 8
If the receiving device is a ZigBee coordinator or an operating ZigBee router, that 9
is, a router that has already invoked the NLME-START-ROUTER.request 10
primitive, it shall process data frames as follows: 11
12
• Broadcast and multicast data frames shall be relayed according to the 13
procedures outlined in sub-clauses 3.6.5 and 3.6.6. 14
• Unicast data frames with a destination address that does not match the device's 15
network address shall be relayed according to the procedures outlined in sub- 16
clause 3.6.3.3. (Under all other circumstances, unicast data frames shall be 17
discarded immediately.) 18
19
• Source-routed data frames with a destination address that does not match the 20
device’s network address shall be relayed according to the procedures outlined 21
in sub-clause 3.6.3.3.2. 22
• The procedure for handling route request command frames is outlined in sub- 23
clause 3.6.3.5.2. 24
25
• The procedure for handling route reply command frames for which the 26
destination address matches the device's network address is outlined in sub- 27
clause 3.6.3.5.3. 28
• Route reply command frames for which the destination address does not match 29
the device's network address shall be discarded immediately. Network status 30
command frames shall be handled in the same manner as data frames. 31
32
The NWK layer shall indicate the receipt of a data frame to the next higher layer 33
using the NLDE-DATA.indication primitive. 34
On receipt of a frame, the NLDE shall check the value of the security sub-field of 35
the frame control field. If this value is non-zero, the NLDE shall pass the frame to 36
the security service provider (see 4.2.2) for subsequent processing according to 37
the specified security suite. If the security sub-field is set to 0, the 38
nwkSecurityLevel attribute in the NIB is non-zero, and the incoming frame is a 39
NWK command frame, the NLDE shall discard the frame. If the security sub-field 40
is set to 0, the nwkSecurityLevel attribute in the NIB is non-zero, and the incoming 41
frame is a NWK data frame, the NLDE shall check the nwkSecureAllFrames NIB 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 385

attribute. If this attribute is set to 0x01, the NLDE shall only accept the frame if it
is destined to itself, that is, if it does not need to be forwarded to another device. 1
2
3
3.6.3 Routing 4
5
ZigBee coordinators and routers shall provide the following functionality: 6
• Relay data frames on behalf of higher layers 7
8
• Relay data frames on behalf of other ZigBee routers 9
• Participate in route discovery in order to establish routes for subsequent data 10
frames 11
12
• Participate in route discovery on behalf of end devices 13
• Participate in route repair 14
15
• Employ the ZigBee path cost metric as specified in route discovery 16
ZigBee coordinators or routers may provide the following functionality: 17
18
• Maintain routing tables in order to remember best available routes 19
• Initiate route discovery on behalf of higher layers 20
21
• Initiate route discovery on behalf of other ZigBee routers 22
• Initiate route repair 23
24
• Conduct neighbor routing 25
26
3.6.3.1 Routing Cost 27
The ZigBee routing algorithm uses a path cost metric for route comparison during 28
route discovery and maintenance. In order to compute this metric, a cost, known 29
as the link cost, is associated with each link in the path and link cost values are 30
summed to produce the cost for the path as a whole. 31
32
More formally, if we define a path P of length L as an ordered set of 33
devices [D 1,D 2 … D L ] and a link, [D i,D i + 1 ]as a sub-path of length 2, then the path 34
cost 35
36
L–1 37
C {P } = ∑ C {[Di,Di + 1 ]} 38
i=1 39
40
where each of the values C {[Di,Di + 1 ]} is referred to as a link cost. The link 41
cost C {l } for a link l is a function with values in the interval [0… 7 ] defined as: 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
386 Network Specification

1
⎧7, 2
⎪ 3
C{l} = ⎨ ⎛ ⎛ 1 ⎞⎞
⎜ ⎟
⎪min⎜ 7, round⎜⎜ p 4 ⎟⎟ ⎟ 4
⎩ ⎝ ⎝ l ⎠⎠ 5
6
7
where pl is defined as the probability of packet delivery on the link l. 8
Thus, implementers may report a constant value of 7 for link cost or they may 9
report a value that reflects the probability pl of reception — specifically, the 10
reciprocal of that probability — which should, in turn, reflect the number of 11
expected attempts required to get a packet through on that link each time it is 12
used. A device that offers both options may be forced to report a constant link cost 13
by setting the value of the NIB attribute nwkReportConstantCost to TRUE. If the 14
nwkSymLink attribute of the NIB has a value of TRUE, then the 15
nwkReportConstantCost attribute must have a value of FALSE, and the NWK 16
layer must calculate routing cost in the manner described above.28 17
18
The question that remains, however, is how pl is to be estimated or measured. This 19
is primarily an implementation issue, and implementers are free to apply their 20
ingenuity. pl may be estimated over time by actually counting received beacon 21
and data frames and observing the appropriate sequence numbers to detect lost 22
frames. This is generally regarded as the most accurate measure of reception 23
probability. However, the most straightforward method, available to all, is to form 24
estimates based on an average over the per-frame LQI value provided by the IEEE 25
802.15.4-2003 MAC and PHY. Even if some other method is used, the initial cost 26
estimates shall be based on average LQI. A table-driven function may be used to 27
map average LQI values onto C{l} values. It is strongly recommended that 28
implementers check their tables against data derived from tests performed on 29
production hardware, as inaccurate costs will hamper the operating ability of the 30
ZigBee routing algorithm. 31
32
3.6.3.2 Routing Tables 33
A ZigBee router or ZigBee coordinator may maintain a routing table. The 34
information that shall be stored in a ZigBee routing table entry is shown in 35
Table 3.51. The aging and retirement of routing table entries in order to reclaim 36
37
38
39
40
41
42
43
28. CCB #809 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 387

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

• It has a free routing table entry or it already has a routing table entry
corresponding to the destination 1
2
If a ZigBee router or ZigBee coordinator maintains a routing table, it shall also 3
maintain a route discovery table containing the information shown in Table 3.53. 4
Routing table entries are long-lived, while route discovery table entries last only 5
as long as the duration of a single route discovery operation and may be reused. 6
Table 3.53 Route Discovery Table Entry 7
8
Field Name Size Description 9
Route request ID 1 octet A sequence number for a route request command frame that is 10
incremented each time a device initiates a route request. 11
Source address 2 The 16-bit network address of the route request’s initiator. 12
octets 13
Sender address 2 The 16-bit network address of the device that has sent the most 14
octets recent lowest cost route request command frame corresponding to 15
this entry’s route request identifier and source address. This field is 16
used to determine the path that an eventual route reply command 17
frame should follow.
18
Forward cost 1 octet The accumulated path cost from the source of the route request to 19
the current device. 20
Residual cost 1 octet The accumulated path cost from the current device to the 21
destination device. 22
Expiration time 2 A countdown timer indicating the number of milliseconds until 23
octets route discovery expires. The initial value is 24
nwkcRouteDiscoveryTime. 25
26
A device is said to have “route discovery table capacity” if: 27
• It maintains a route discovery table 28
29
• It has a free entry in its route discovery table 30
If a device has both routing table capacity and route discovery table capacity then 31
it may be said to have “routing capacity.” 32
33
During route discovery, the information that a ZigBee router or ZigBee 34
coordinator is required to maintain in order participate in the discovery of a 35
particular route is distributed between a routing table entry and a route discovery 36
table entry. Once discovery has been completed, only the routing table entry need 37
be maintained in order for the NWK layer to perform routing along the discovered 38
route. Throughout this sub-clause, references are made to this relationship 39
between a routing table entry and its “corresponding” route discovery table entry 40
and vice versa. The maintenance of this correspondence is up to the implementer 41
since entries in the tables have no elements in common, but it is worth noting in 42
this regard that the unique “keys” that define a route discovery are the source 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 389

address of the route discovery command frame and the route request ID generated
by that device and carried in the command frame payload. 1
2
If a device has the capability to initiate a many-to-one route request, it may also 3
maintain a route record table (see Table 3.45). 4
5
3.6.3.3 Upon Receipt of a Unicast Frame 6
On receipt of a unicast frame from the MAC sub-layer, or an NLDE- 7
DATA.request from the next higher layer, the NWK layer routes it according to 8
the following procedure. 9
10
If the receiving device is a ZigBee router or ZigBee coordinator, and the 11
destination of the frame is a ZigBee end device and also the child of the receiving 12
device, the frame shall be routed directly to the destination using the MCPS- 13
DATA.request primitive, as described in sub-clause 3.6.2.1. The frame shall also 14
set the next hop destination address equal to the final destination address. 15
Otherwise, for purposes of the ensuing discussion, define the routing address of a 16
device to be its network address if it is a router or the coordinator or an end device 17
and nwkAddrAlloc has a value of 0x02, or the network address of its parent if it is 18
an end device and nwkAddrAlloc has a value of 0x00. Define the routing 19
destination of a frame to be the routing address of the frame’s NWK destination. 20
Note that distributed address assignment makes it possible to derive the routing 21
address of any device from its address. See sub-clause 3.6.1.6 for details. 22
A ZigBee router or ZigBee coordinator may check the neighbor table for an entry 23
corresponding to the routing destination of the frame. If there is such an entry, the 24
device may route the frame directly to the destination using the MCPS- 25
DATA.request primitive as described in sub-clause 3.6.2.1. 26
27
A device that has routing capacity shall check its routing table for an entry 28
corresponding to the routing destination of the frame. If there is such an entry, and 29
if the value of the route status field for that entry is ACTIVE or 30
VALIDATION_UNDERWAY, the device shall relay the frame using the MCPS- 31
DATA.request primitive and set the route status field of that entry to ACTIVE if it 32
does not already have that value. If the many-to-one field of the routing table 33
entry is set to TRUE, the NWK shall follow the procedure outlined in sub- 34
clause 3.6.3.5.4 to determine whether a route record command frame must be 35
sent. 36
When relaying a unicast frame, the SrcAddrMode and DstAddrMode parameters 37
of the MCPS-DATA.request primitive shall both have a value of 0x02, indicating 38
16-bit addressing. The SrcPANId and DstPANId parameters shall both have the 39
value provided by the macPANId attribute of the MAC PIB for the relaying 40
device. The SrcAddr parameter shall be set to the value of macShortAddress from 41
the MAC PIB of the relaying device, and the DstAddr parameter shall be the value 42
provided by the next-hop address field of the routing table entry corresponding to 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
390 Network Specification

the routing destination. Bit b0 of the TxOptions parameter should be set to 1,


indicating acknowledged transmission. 1
2
If the device has a routing table entry corresponding to the routing destination of 3
the frame but the value of the route status field for that entry is 4
DISCOVERY_UNDERWAY, the device shall determine if it initiated the 5
discovery by consulting its discovery table. If the device initiated the discovery, 6
the frame shall be treated as though route discovery has been initiated for this 7
frame, otherwise, the device shall initiate route discovery as described in sub- 8
clause 3.6.3.5.1. The frame may optionally be buffered pending route discovery or 9
routed along the tree using hierarchical routing, provided that the NIB attribute 10
nwkUseTreeRouting has a value of TRUE. If the frame is routed along the tree, the 11
discover route sub-field of the NWK header frame control field shall be set to 12
0x00. 13
If the device has a routing table entry corresponding to the routing destination of 14
the frame but the route status field for that entry has a value of 15
DISCOVERY_FAILED or INACTIVE, the device may route the frame along the 16
tree using hierarchical routing, provided that the NIB attribute 17
nwkUseTreeRouting has a value of TRUE. If the device does not have a routing 18
table entry for the routing destination with a status value of ACTIVE or 19
VALIDATION_UNDERWAY, and it received the frame from the next higher 20
layer, it shall check its source route table for an entry corresponding to the routing 21
destination. If such an entry is found and the length is less than 22
nwkMaxSourceRoute, the device shall transmit the frame using source routing as 23
described in sub-clause 3.6.3.3.1. If the device does not have a routing table entry 24
for the routing destination and it is not originating the frame using source routing, 25
it shall examine the discover route sub-field of the NWK header frame control 26
field. If the discover route sub-field has a value of 0x01, the device shall initiate 27
route discovery, as described in sub-clause 3.6.3.5.1. If the discover route sub- 28
field has a value of 0 and the NIB attribute nwkUseTreeRouting has a value of 29
TRUE then the device shall route along the tree using hierarchical routing. If the 30
discover route sub-field has a value of 0, the NIB attribute nwkUseTreeRouting 31
has a value of FALSE, and there is no routing table corresponding to the routing 32
destination of the frame, the frame shall be discarded and the NLDE shall issue 33
the NLDE-DATA.confirm primitive with a status value of ROUTE_ERROR. 34
35
A device without routing capacity shall route along the tree using hierarchical 36
routing provided that the value of the NIB attribute nwkUseTreeRouting is TRUE. 37
If the value of the NIB attribute nwkUseTreeRouting is FALSE, the frame shall be 38
discarded. If the frame is the result of an NLDE-DATA.request from the NHL of 39
the current device, the NLDE shall issue the NLDE-DATA.confirm primitive with 40
a status value of ROUTE_ERROR. If the frame is being relayed on behalf of 41
another device, the NLME shall issue a network status command frame destined 42
for the device that is the source of the frame with a status of 0x04, indicating a 43
lack of routing capacity. It shall also issue the NLME-NWK-STATUS.indication 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 391

to the next higher layer with the NetworkAddr parameter equal to the 16-bit
network address of the frame, and the Status parameter equal to 0x04, indicating a 1
lack of routing capacity. 2
3
For hierarchical routing, if the destination is a descendant of the device, the device 4
shall route the frame to the appropriate child. If the destination is a child, and it is 5
also an end device, delivery of the frame can fail due to the macRxOnWhenIdle 6
state of the child device. If the child has macRxOnWhenIdle set to FALSE, 7
indirect transmission as described in IEEE 802.15.4-2003 [B1] may be used to 8
deliver the frame. If the destination is not a descendant, the device shall route the 9
frame to its parent. 10
Every other device in the network is a descendant of the ZigBee coordinator and 11
no device in the network is the descendant of any ZigBee end device. For a 12
ZigBee router with address A at depth d, if the following logical expression is true, 13
then a destination device with address D is a descendant: 14
15
A < D < A + Cskip (d – 1 ) 16
For a definition of Cskip (d ), see sub-clause 3.6.1.6. 17
18
If it is determined that the destination is a descendant of the receiving device, the 19
address N of the next hop device is given by: 20
21
N = D
22
for ZigBee end devices, where D > A + Rm · Cskip (d ), and otherwise: 23
24
25
⎢ D - (A +1)⎥ 26
N = A +1 + ⎢ ⎥ · Cskip (d )
⎣ Cskip (d ) ⎦ 27
28
If the NWK layer on a ZigBee router or ZigBee coordinator fails to deliver a 29
unicast or multicast frame for any reason, the router or coordinator shall make its 30
best effort to report the failure. No failure should be reported as the result of a 31
failure to deliver a NLME-NWK-STATUS. The failure reporting may take one of 32
two forms. If the failed frame was being relayed as a result of a request from the 33
next higher layer, then the NWK layer shall issue an NLDE-DATA.confirm with 34
the error to the next higher layer. The value of the NetworkAddr parameter of the 35
primitive shall be the intended destination of the frame. If the frame was being 36
relayed on behalf of another device, then the relaying device shall send a network 37
status command frame back to the source of the frame. The destination address 38
field of the network status command frame shall be taken from the destination 39
address field of the failed data frame. 40
41
In either case, the reasons for failure that may be reported appear in Table 3.42.
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
392 Network Specification

3.6.3.3.1 Originating a Source Routed Data Frame


1
If, on receipt of a data frame from the next higher layer, it is determined that the 2
frame should be transmitted using source routing as described above, the source 3
route shall be retrieved from the route record table. 4
If there are no intermediate relay nodes, the frame shall be transmitted directly to 5
the routing destination without source routing by using the MCPS-DATA.request 6
primitive, with the DstAddr parameter value indicating the routing destination. 7
8
If there is at least one relay node, the source route flag of the NWK header frame 9
control field shall be set, and the NWK header source route subframe shall be 10
present. The relay count sub-field of the source route subframe shall have a value 11
equal to the number of relays in the relay list. The relay index sub-field shall have 12
a value equal to 1 less than the number of relays. The relay list sub-field shall 13
contain the list of relay addresses, least significant octet first. The relay closest to 14
the destination shall be listed first. The relay closest to the originator shall be 15
listed last. 16
The device shall relay the frame using the MCPS-DATA.request primitive. The 17
DstAddr parameter shall have the value of the final relay address in the relay list. 18
19
3.6.3.3.2 Relaying a Source Routed Data Frame 20
Upon receipt of a source routed data frame from the MAC sub-layer as described 21
in sub-clause 3.6.3.3, if the relay index sub-field of the source route sub-frame has 22
a value of 0, the device shall check the destination address field of the NWK 23
header of the frame. If the destination address field of the NWK header of the 24
frame is equal in value to the nwkNetworkAddress attribute of the NIB, then the 25
frame shall be passed to the next higher layer using the NLDE-DATA.indication 26
primitive. If the destination address field is not equal to the nwkNetworkAddress 27
attribute of the NIB, and the receiving device is a ZigBee router or ZigBee 28
coordinator, the device shall relay the frame directly to the NWK header 29
destination using the MCPS-DATA.request primitive, otherwise the frame shall be 30
discarded silently. 31
32
If the relay index sub-field has a value other than 0, the device shall compare its 33
network address with the address found at the relay index in the relay list. If the 34
addresses do not match, the frame shall be discarded and no further action shall be 35
taken. Otherwise, the device shall decrement the relay index sub-field by 1, and 36
relay the frame to the address immediately prior to its own address in the relay list 37
sub-field. 38
When relaying a source routed data frame, the NWK layer of a device shall also 39
examine the routing table entry corresponding to the source address of the frame. 40
If the no route cache field of the routing table entry has a value of FALSE, then 41
the route record required field of the routing table entry shall be set to FALSE. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 393

3.6.3.4 Link Status Messages


1
Wireless links may be asymmetric, that is, they may work well in one direction 2
but not the other. This can cause route replies to fail, since they travel backwards 3
along the links discovered by the route request. 4
5
For many-to-one routing and two-way route discovery (nwkSymLink = TRUE), it
6
is a requirement to discover routes that are reliable in both directions. To
7
accomplish this, routers exchange link cost measurements with their neighbors by
8
periodically transmitting link status frames as a one-hop broadcast. The reverse
9
link cost information is then used during route discovery to ensure that discovered
10
routes use high-quality links in both directions.
11
3.6.3.4.1 Initiation of a Link Status Command Frame 12
13
When joined to a network, a ZigBee router or coordinator shall periodically send a 14
link status command every nwkLinkStatusPeriod seconds, as a one-hop broadcast 15
without retries. It may be sent more frequently if desired. Random jitter should be 16
added to avoid synchronization with other nodes. See sub-clause 3.4.8 for the link 17
status command frame format. 18
End devices do not send link status command frames. 19
20
3.6.3.4.2 Upon Receipt of a Link Status Command Frame 21
Upon receipt of a link status command frame by a ZigBee router or coordinator, 22
the age field of the neighbor table entry corresponding to the transmitting device 23
is reset to 0. The list of addresses covered by a frame is determined from the first 24
and last addresses in the link status list, and the first frame and last frame bits of 25
the command options field. If the receiver's network address is outside the range 26
covered by the frame, the frame is discarded and processing is terminated. If the 27
receiver's network address falls within the range covered by the frame, then the 28
link status list is searched. If the receiver's address is found, the outgoing cost 29
field of the neighbor table entry corresponding to the sender is set to the incoming 30
cost value of the link status entry. If the receiver's address is not found, the 31
outgoing cost field is set to 0. 32
33
End devices do not process link status command frames. 34
3.6.3.4.3 Aging the Neighbor Table 35
36
For devices using link status messages, the age fields for routers in the neighbor 37
table are incremented every nwkLinkStatusPeriod. If the value exceeds 38
nwkRouterAgeLimit, the outgoing cost field of the neighbor table entry is set to 0. 39
In other words, if a device fails to receive nwkRouterAgeLimit link status 40
messages from a router neighbor in a row, the old outgoing cost information is 41
discarded. In this case, the neighbor entry is considered stale and may be reused if 42
necessary to make room for a new neighbor. End devices do not issue link status 43
messages and therefore should never be considered stale. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
394 Network Specification

If nwkAddrAlloc has a value of 0x00, neighbor table entries for relatives should
not be considered stale and reused. 1
2
3.6.3.5 Route Discovery 3
4
Route discovery is the procedure whereby network devices cooperate to find and 5
establish routes through the NWK. Unicast route discovery is always performed 6
with regard to a particular source device and a particular destination device. 7
Multicast route discovery is performed with respect to a particular source device 8
and a multicast group. Many-to-one route discovery is performed by a source 9
device to establish routes to itself from all ZigBee routers and ZigBee coordinator, 10
within a given radius. A source device that initiates a many-to-one route discovery 11
is designated as a concentrator and referred to as such in this document. 12
Throughout sub-clause 3.6.3.5 a destination address may be a 16-bit broadcast 13
address, the 16-bit network address of a particular device, or a 16-bit multicast 14
address, also known as a multicast group ID. A route request command whose 15
destination address is the routing address of a particular device and whose route 16
request option field does not have the multicast bit set, is a unicast route request. 17
A route request command whose route request option field has the multicast bit 18
set is a multicast route request. The destination address field of a multicast route 19
request shall be a multicast group ID. A route request command payload whose 20
destination address sub-field is a broadcast address (see Table 3.54) is a many-to- 21
one route request. The multicast bit in the route request option field of a many-to- 22
one route request shall be set to 0. 23
3.6.3.5.1 Initiation of Route Discovery 24
25
The unicast route discovery procedure for a device shall be initiated on a ZigBee 26
router or ZigBee coordinator by the NWK layer up on receipt of an NLME- 27
ROUTE-DISCOVERY.request primitive from the next higher layer where the 28
DstAddrMode parameter has a value of 0x02. Or, up on receipt of an NLDE- 29
DATA.request primitive from a higher layer with the DstAddrMode set to 0x02 30
and the discover route sub-field set to 0x01, for which there is no routing table 31
entry corresponding to the routing address of the destination device (the 16-bit 32
network address indicated by the DstAddr parameter). Or, on receipt of a frame 33
from the MAC sub-layer for which the value of the destination address field in the 34
NWK header is not the address of the current device, the address of an end device 35
child of the current device, or a broadcast address and: 36
• The discover route sub-field of the frame control field has a value of 0x01, and 37
38
• there is no routing table entry corresponding to the routing destination of the 39
frame, and 40
• either the value of the source address field of the NWK header of the received 41
frame is the same as the 16-bit network address of one of the end device 42
children of the current device, or 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 395

• the nwkUseTreeRouting attribute of the NIB has a value of TRUE.


1
The route discovery procedure for a multicast address shall be initiated by the 2
NWK layer either in response to the receipt of an NLME-ROUTE- 3
DISCOVERY.request primitive from the next higher layer where the 4
DstAddrMode parameter has a value of 0x01, or as specified in sub- 5
clause 3.6.6.2.2. 6
If the device initiating route discovery has no routing table entry corresponding to 7
the routing address of the destination device, it shall establish a routing table entry 8
with status equal to DISCOVERY_UNDERWAY. If the device has an existing 9
routing table entry corresponding to the routing address of the destination with 10
status equal to ACTIVE or VALIDATION _UNDERWAY, that entry shall be used 11
and the status field of that entry shall retain its current value. If it has an existing 12
routing table entry with a status value other than ACTIVE or 13
VALIDATION_UNDERWAY, that entry shall be used and the status of that entry 14
shall be set to DISCOVERY_UNDERWAY. The device shall also establish the 15
corresponding route discovery table entry if one with the same initiator and route 16
request ID does not already exist. 17
18
Each device issuing a route request command frame shall maintain a counter used 19
to generate route request identifiers. When a new route request command frame is 20
created, the route request counter is incremented and the value is stored in the 21
device’s route discovery table in the Route request identifier field. Other fields in 22
the routing table and route discovery table are set as described in sub- 23
clause 3.6.3.2. 24
The NWK layer may choose to buffer the received frame pending route discovery 25
or, if the frame is a unicast frame and the NIB attribute nwkUseTreeRouting has a 26
value of TRUE, set the discover route sub-field of the frame control field in the 27
NWK header to 0 and forward the data frame along the tree. 28
29
Once the device creates the route discovery table and routing table entries, the 30
route request command frame shall be created with the payload depicted in 31
Figure 3.12. The individual fields are populated as follows: 32
• The command frame identifier field shall be set to indicate the command frame 33
is a route request, see Table 3.40. 34
35
• The Route request identifier field shall be set to the value stored in the route 36
discovery table entry. 37
• The multicast flag and destination address fields shall be set in accordance with 38
the destination address for which the route is to be discovered. 39
40
• The path cost field shall be set to 0. 41
Once created, the route request command frame is ready for broadcast and is 42
passed to the MAC sub-layer using the MCPS-DATA.request primitive. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
396 Network Specification

When broadcasting a route request command frame at the initiation of route


discovery, the NWK layer shall retry the broadcast nwkcInitialRREQRetries times 1
after the initial broadcast, resulting in a maximum of nwkcInitialRREQRetries + 1 2
transmissions. The retries will be separated by a time interval of 3
nwkcRREQRetryInterval milliseconds. 4
5
The many-to-one route discovery procedure shall be initiated by the NWK layer 6
of a ZigBee router or coordinator on receipt of an NLME-ROUTE- 7
DISCOVERY.request primitive from the next higher layer where the 8
DstAddrMode parameter has a value of 0x00. A many-to-one route request 9
command frame is not retried; however, a discovery table entry is still created to 10
provide loop detection during the nwkcRouteDiscoveryTime period.29 If the 11
NoRouteCache parameter of the NLME-ROUTE-DISCOVERY.request primitive 12
is TRUE, the many-to-one sub-field of the command options field of the 13
command frame payload shall be set to 2. Otherwise, the many-to-one sub-field 14
shall be set to 1. Note that in this case, the NWK layer should maintain a route 15
record table. The destination address field of the NWK header shall be set to 16
0xfffc, the all-router broadcast address. The broadcast radius shall be set to the 17
value in nwkConcentratorRadius. A source device that initiates a many-to-one 18
route discovery is designated as a concentrator and referred to as such in this 19
document and the NIB attribute nwkIsConcentrator should be set to TRUE. If a 20
device has nwkIsConcentrator equal to TRUE and there is a non-zero value in 21
nwkConcentratorDiscoveryTime, the network layer should issue a route request 22
command frame each nwkConcentratorDiscoveryTime. 23
3.6.3.5.2 Upon Receipt of a Route Request Command Frame 24
25
Upon receipt of a route request command frame, if the device is an end device, it 26
shall drop the frame. Otherwise, it shall determine if it has routing capacity. 27
If the device does not have routing capacity and the route request is a multicast 28
route request or a many-to-one-route request, the route request shall be discarded 29
and route request processing shall be terminated. 30
31
If nwkAddrAlloc is 0x00 and the device does not have routing capacity and the 32
route request is a unicast route request, the device shall check if the frame was 33
received along a valid path. A path is valid if the frame was received from one of 34
the device’s children and the source device is a descendant of that child device, or 35
if the frame was received from the device’s parent device and the source device is 36
not a descendant of the device. If the route request command frame was not 37
received along a valid path, it shall be discarded. Otherwise, the device shall 38
check if it is the intended destination. It shall also check if the destination of the 39
command frame is one of its end device children by comparing the destination 40
address field of the route request command frame payload with the address of 41
each of its end device children, if any. If either the device or one of its end device 42
43
29. CCB #844 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 397

children is the destination of the route request command frame, it shall reply with
a route reply command frame. When replying to a route request with a route reply 1
command frame, the device shall construct a frame with the frame type field set to 2
0x01. The route reply’s source address shall be set to the 16-bit network address 3
of the device creating the route reply and the destination address shall be set to the 4
calculated next hop address, considering the originator of the route request as the 5
destination. The link cost from the next hop device to the current device shall be 6
computed as described in sub-clause 3.6.3.1 and inserted into the path cost field of 7
the route reply command frame. The route reply command frame shall be unicast 8
to the next hop device by issuing an MCPS-DATA.request primitive. 9
10
If the device is not the destination of the route request command frame, the device 11
shall compute the link cost from the previous device that transmitted the frame, as 12
described in sub-clause 3.6.3.1. This value shall be added to the path cost value 13
stored in the route request command frame. The route request command frame 14
shall then be unicast towards the destination using the MCPS-DATA.request 15
service primitive. The next hop for this unicast transmission is determined in the 16
same manner as if the frame were a data frame addressed to the device identified 17
by the destination address field in the payload. 18
If the device does have routing capacity and the received request is a unicast route 19
request, the device shall check if it is the destination of the command frame by 20
comparing the destination address field of the route request command frame 21
payload with its own address. It shall also check if the destination of the command 22
frame is one of its end device children by comparing the destination address field 23
of the route request command frame payload with the address of each of its end 24
device children, if any. If neither the device nor one of its end device children is 25
the destination of the route request command frame, the device shall determine if 26
a route discovery table (see Table 3.53) entry exists with the same route request 27
identifier and source address field. If no such entry exists, one shall be created. 28
29
If the device does have routing capacity and the multicast sub-field of the route 30
request command options field of the received route request frame indicates a 31
multicast route request, the device shall determine whether an entry already exists 32
in the nwkGroupIDTable for which the group identifier field matches the 33
destination address field of the frame. If a matching entry is found, the device 34
shall determine if a route discovery table (see Table 3.53) entry exists with the 35
same route request identifier and source address field. If no such entry exists, one 36
shall be created. 37
For many-to-one route requests, and for regular route requests if the nwkSymLink 38
parameter is TRUE, upon receipt of a route request command frame, the neighbor 39
table is searched for an entry corresponding to the transmitting device. If no such 40
entry is found, or if the outgoing cost field of the entry has a value of 0, the frame 41
is discarded and route request processing is terminated. The maximum of the 42
incoming and outgoing costs for the neighbor is used for the purposes of the path 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
398 Network Specification

cost calculation, instead of the incoming cost. This includes the value used to
increment the path cost field of the route request frame prior to retransmission. 1
2
When creating the route discovery table entry, the fields are set to the 3
corresponding values in the route request command frame. The only exception is 4
the forward cost field, which is determined by using the previous sender of the 5
command frame to compute the link cost, as described in sub-clause 3.6.3.1, and 6
adding it to the path cost contained the route request command frame. The result 7
of the above calculation is stored in the forward cost field of the newly created 8
route discovery table entry. If the nwkSymLink attribute is set to TRUE, the device 9
shall also create a routing table entry with the destination address field set to the 10
source address of the route request command frame and the next hop field set to 11
the address of the previous device that transmitted the command frame. The status 12
field shall be set to ACTIVE. The device shall then issue a route reply command 13
frame to the source of the route request command frame. In the case that the 14
device already has a route discovery table entry for the source address and route 15
request identifier pair, the device shall determine if the path cost in the route 16
request command frame is less than the forward cost stored in the route discovery 17
table entry. The comparison is made by first computing the link cost from the 18
previous device that sent this frame, as described in sub-clause 3.6.3.1, then 19
adding it to the path cost value in the route request command frame. If this value 20
is greater than the value in the route discovery table entry, the frame shall be 21
dropped and no further processing is required. Otherwise, the forward cost and 22
sender address fields in the route discovery table are updated with the new cost 23
and the previous device address from the route request command frame. 24
If the nwkSymLink attribute is set to TRUE and the received route request 25
command frame is a unicast route request, the device shall also create a routing 26
table entry with the destination address field set to the source address of the route 27
request command frame and the next hop field set to the address of the previous 28
device that transmitted the command frame. The status field shall be set to 29
ACTIVE. The device shall then respond with a route reply command frame. In 30
either of these cases, if the device is responding on behalf of one of its end device 31
children, the responder address in the route reply command frame payload shall 32
be set equal to the address of the end device child and not of the responding 33
device. 34
35
When a device with routing capacity is not the destination of the received route 36
request command frame, it shall determine if a route discovery table entry (see 37
Table 3.53) exists with the same route request identifier and source address field. 38
If no such entry exists, one shall be created. The route request timer shall be set to 39
expire in nwkcRouteDiscoveryTime milliseconds. If a routing table entry 40
corresponding to the routing address of the destination exists and its status is not 41
ACTIVE or VALIDATION_UNDERWAY, the status shall be set to 42
DISCOVERY_UNDERWAY. If no such entry exists and the frame is a unicast 43
route request, an entry shall be created and its status set to 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 399

DISCOVERY_UNDERWAY. If the frame is a many-to-one route request, the


device shall also create a routing table entry with the destination address field 1
equal to the source address of the route request command frame by setting the 2
next hop field to the address of the previous device that transmitted the command 3
frame. If the frame is a many-to-one route request (i.e. the many-to-one sub-field 4
of the command options field of the command frame payload has a non-zero 5
value), the many-to-one field in the routing table entry shall be set to TRUE, and 6
the no route cache flag shall be set to TRUE if the many-to-one sub-field of the 7
command options field of the command frame payload has a value of 2 or to 8
FALSE if it has a value of 1. If the routing table entry is new, or if the no route 9
cache flag is set to TRUE, or if the next hop field changed, the route record 10
required field shall be set to TRUE, otherwise it remains unchanged. The status 11
field shall be set to ACTIVE. When the route request timer expires, the device 12
deletes the route request entry from the route discovery table. When this happens, 13
the routing table entry corresponding to the routing address of the destination shall 14
also be deleted, if its status field has a value of DISCOVERY_UNDERWAY and 15
there are no other entries in the route discovery table created as a result of a route 16
discovery for that destination address. 17
18
If an entry in the route discovery table already exists, the path cost in the route 19
request command frame shall be compared to the forward cost value in the route 20
discovery table entry. The comparison is made by computing the link cost from 21
the previous device, as described in sub-clause 3.6.3.1, and adding it to the path 22
cost value in the route request command frame. If this path cost is greater, the 23
route request command frame is dropped and no further processing is required. 24
Otherwise, the forward cost and sender address fields in the route discovery table 25
are updated with the new cost and the previous device address from the route 26
request command frame. Additionally, the path cost field in the route request 27
command frame shall be updated with the cost computed for comparison 28
purposes. If the nwkSymLink attribute is set to TRUE and the received route 29
request command frame is a unicast route request, the device shall also update any 30
routing table entry with the destination address field set to the source address of 31
the route request command frame, and the next hop field set to the address of the 32
previous device that transmitted the command frame. The status field shall be set 33
to ACTIVE. The device shall then broadcast the route request command frame 34
using the MCPS-DATA.request primitive. 35
When broadcasting a route request command frame, the NWK layer shall delay 36
retransmission by a random jitter amount calculated using the formula: 37
38
39
2 x R[nwkcMinRREQJitter, nwkcMaxRREQJitter] 40
41
where R [a,b ] is a random function on the interval [a,b ]. The units of this jitter 42
amount are milliseconds. Implementers may adjust the jitter amount so that route 43
request command frames arriving with large path cost are delayed more than 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
400 Network Specification

frames arriving with lower path cost. The NWK layer shall retry the broadcast
nwkcRREQRetries times after the original relay resulting in a maximum of 1
nwkcRREQRetries + 1 relays per relay attempt. Implementers may choose to 2
discard route request command frames awaiting retransmission in the case that a 3
frame with the same source and route request identifier arrives with a lower path 4
cost than the one awaiting retransmission. 5
6
The device shall also set the status field of the routing table entry corresponding to 7
the routing address of the destination field in the payload to 8
DISCOVERY_UNDERWAY. If no such entry exists, it shall be created. 9
When replying to a route request with a route reply command frame, a device that 10
has a route discovery table entry corresponding to the source address and route 11
request identifier of the route request shall construct a command frame with the 12
frame type field set to 0x01. The source address field of the NWK header shall be 13
set to the 16-bit network address of the current device and the destination address 14
field shall be set to the value of the sender address field from the corresponding 15
route discovery table entry. The device constructing the route reply shall populate 16
the payload fields in the following manner. 17
18
• The NWK command identifier shall be set to route reply. 19
• The route request identifier field shall be set to the same value found in the 20
route request identifier field of the route request command frame. 21
22
• The originator address field shall be set to the source address in the NWK 23
header of the route request command frame. 24
• Using the sender address field from the route discovery table entry 25
corresponding to the source address in the NWK header of the route request 26
command frame, the device shall compute the link cost as described in sub- 27
clause 3.6.3.1. This link cost shall be entered in the path cost field. 28
29
The route reply command frame is then unicast to the destination by using the 30
MCPS-DATA.request primitive and the sender address obtained from the route 31
discovery table as the next hop. 32
3.6.3.5.3 Upon Receipt of a Route Reply Command Frame 33
34
On receipt of a route reply command frame, a device shall perform the following 35
procedure. 36
If the receiving device has no routing capacity and its NIB attribute 37
nwkUseTreeRouting has a value of TRUE, it shall send the route reply as though it 38
were a data frame being forwarded using tree routing. If the receiving device has 39
no routing capacity and its NIB attribute nwkUseTreeRouting has a value of 40
FALSE, it shall discard the command frame. Before forwarding the route reply 41
command frame the device shall update the path cost field in the payload by 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 401

computing the link cost from the next hop device to itself as described in sub-
clause 3.6.3.1 and adding this to the value in the route reply path cost field. 1
2
If the receiving device has routing capacity, it shall check whether it is the 3
destination of the route reply command frame by comparing the contents of the 4
originator address field of the command frame payload with its own address. If it 5
is, it shall search its route discovery table for an entry corresponding to the route 6
request identifier in the route reply command frame payload. If there is no such 7
entry, the route reply command frame shall be discarded and route reply 8
processing shall be terminated. If a route discovery table entry exists, the device 9
shall search its routing table for an entry with a destination address field equal to 10
the routing address corresponding to the responder address in the route reply 11
command frame. If there is no such routing table entry, the route reply command 12
frame shall be discarded and, if a route discovery table entry corresponding to the 13
route request identifier in the route reply command frame exists, it shall also be 14
removed and route reply processing shall be terminated. If a routing table entry 15
and a route discovery table entry exist and if the status field of the routing table 16
entry is set to DISCOVERY_UNDERWAY, it shall be changed to 17
VALIDATION_UNDERWAY if the routing table entry’s GroupId flag is TRUE or 18
to ACTIVE otherwise; the next hop field in the routing table shall be set to the 19
previous device that forwarded the route reply command frame. The residual cost 20
field in the route discovery table entry shall be set to the path cost field in the route 21
reply payload. 22
If the status field was already set to ACTIVE or VALIDATION_UNDERWAY, the 23
device shall compare the path cost in the route reply command frame to the 24
residual cost recorded in the route discovery table entry, and update the residual 25
cost field and next hop field in the routing table entry if the cost in the route reply 26
command frame is smaller. If the path cost in the route reply is not smaller, the 27
route reply shall be discarded and no further processing shall take place. 28
29
If the device receiving the route reply is not the destination, the device shall find 30
the route discovery table entry corresponding to the originator address and route 31
request identifier in the route reply command frame payload. If no such route 32
discovery table entry exists, the route reply command frame shall be discarded. If 33
a route discovery table entry exists, the path cost value in the route reply 34
command frame and the residual cost field in the route discovery table entry shall 35
be compared. If the route discovery table entry value is less than the route reply 36
value, the route reply command frame shall be discarded. 37
Otherwise, the device shall find the routing table entry with a destination address 38
field equal to the routing address corresponding to the responder address in the 39
route reply command frame. In this case, it is an error if the route discovery table 40
entry exists and there is no corresponding routing table entry, and the route reply 41
command frame should be discarded. The routing table entry shall be updated by 42
replacing the next hop field with the address of the previous device that forwarded 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
402 Network Specification

the route reply command frame. The route discovery table entry shall also be
updated by replacing the residual cost field with the value in the route reply 1
command frame. 2
3
Whenever the receipt of a route reply causes the next hop field of the 4
corresponding routing table entry to be modified, and the routing table entry's 5
GroupId flag is TRUE, the device shall set the expiration time field of the 6
corresponding route discovery table entry to expire in nwkcWaitBeforeValidation 7
milliseconds if the device is the destination of the route reply and 8
nwkcRouteDiscoveryTime milliseconds if it is not. 9
After updating its own route entry, the device shall forward the route reply to the 10
destination. Before forwarding the route reply, the path cost value shall be 11
updated. The sender shall find the next hop to the route reply’s destination by 12
searching its route discovery table for the entry matching the route request 13
identifier and the source address and extracting the sender address. It shall use this 14
next hop address to compute the link cost as described in sub-clause 3.6.3.1. This 15
cost shall be added to the path cost field in the route reply. The destination address 16
in the command frame NWK header shall be set to the next hop address and the 17
frame shall be unicast to the next hop device using the MCPS-DATA.request 18
primitive.The DstAddr parameter of the MCPS-DATA.request primitive shall be 19
set to the next-hop address from the route discovery table. 20
21
If the value of the nwkSymLink attribute of the NIB has a value of TRUE, the 22
NWK layer shall, upon relaying the route reply command frame, also create a 23
reverse routing table entry if such an entry does not yet exist. The value of the 24
destination address field of the routing table entry shall correspond to the value of 25
the originator address field of the route reply command frame. The status field 26
shall have a value of ACTIVE. The next-hop address field shall have a value 27
corresponding to the next hop address in the route reply command being relayed, 28
as determined in the previous paragraph. If the reverse routing table entry already 29
exists the next-hop address field shall be updated, if necessary. 30
3.6.3.5.4 Initiation and Processing of a Route Record Command Frame 31
32
If the NWK layer of a ZigBee router or ZigBee coordinator is initiating a unicast 33
data frame as a result of an NLDE-DATA.request from the next higher layer and 34
the many-to-one field of the routing table entry corresponding to the destination 35
address of the frame has a value of TRUE, then the NWK layer shall examine the 36
route record required field of that same routing table entry. If the route record 37
required field also has a value of TRUE, the NWK shall unicast a route record 38
command to the destination before transmitting the data frame. 39
If the NWK layer of a ZigBee router or ZigBee coordinator is forwarding a 40
unicast data frame on behalf of one of its end device children and the many-to-one 41
field of the destination’s routing table entry has a value of TRUE, then the device 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 403

shall unicast a route record command to the destination before relaying the data
frame. 1
2
An optional optimization is possible in which the router or coordinator may keep 3
track of which of its end device children have received source routed data frames 4
from a particular concentrator device and can thereby reduce the number of route 5
record commands it transmits to that concentrator on behalf of its end device 6
children. 7
Each relay node that receives the route record command shall append its network 8
address to the command payload, increment the relay count, and forward the 9
message. If no next hop is available, or if delivery to the next hop fails, or if there 10
is insufficient space in the payload for the network address, the command frame 11
shall be discarded and no error command shall be generated. 12
13
Upon receipt of the route record command by the destination, the route shall be 14
stored in the source route table. Any existing source routes to the message source 15
or intermediary nodes shall be replaced by the new route information. 16
17
3.6.3.6 Upon Expiration of a Route Discovery Table Entry 18
When a route discovery table entry is created, the expiration timer shall be set to 19
expire in nwkcRouteDiscoveryTime milliseconds. For entries whose GroupId flag 20
in the corresponding entry in the routing table is TRUE, when a route reply is 21
received that causes the next hop to change, the expiration time field of the 22
corresponding route discovery table entry is set to expire in 23
nwkcWaitBeforeValidation milliseconds if the device is the destination of the route 24
reply and nwkcRouteDiscoveryTime milliseconds if it is not. When the timer 25
expires, the device shall delete the entry from the route discovery table. If the 26
device is the originator of the route request and the routing table entry 27
corresponding to the destination address has a Status field value of 28
VALIDATION_UNDERWAY, then the device shall transmit a message to validate 29
the route: either the message-buffered pending route discovery or a network status 30
command with a status code of 0x0a (validate route). If the routing table entry 31
corresponding to the destination address has any Status field value other than 32
ACTIVE or VALIDATION_UNDERWAY and there are no other entries in the 33
route discovery table corresponding to that routing table entry, the routing table 34
entry shall also be deleted. 35
36
3.6.3.7 Route Maintenance 37
38
A device NWK layer shall maintain a failure counter for each neighbor to which it 39
has an outgoing link, i.e., to which it has been required to send data frames. If the 40
outgoing link is classified as a failed link, then the device shall respond as 41
described in the following paragraphs. Implementers may choose a simple failure- 42
counting scheme to generate this failure counter value or they may use a more 43
accurate time-windowed scheme. Note that it is important not to initiate repair too 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
404 Network Specification

frequently since repair operations may flood the network and cause other traffic
disruptions. The procedure for retiring links and ceasing to keep track of their 1
failure counter is out of the scope of this specification. 2
3
3.6.3.7.1 In Case of Link Failure 4
If a failed link is encountered while a device is forwarding a unicast data frame 5
using a routing table entry with the many-to-one field set to TRUE, a network 6
status command frame with status code of 0x0c indicating many-to-one route 7
failure shall be generated. The destination address field in the NWK header of the 8
network status command frame shall be equal to the destination address field in 9
the NWK header of the frame causing the error. The destination address field of 10
the network status command payload shall be equal to the source address field in 11
the NWK header of the frame causing the error. The network status command 12
frame shall be unicast to a random router neighbor using the MCPS- 13
DATA.request primitive. Because it is a many-to-one route, all neighbors are 14
expected to have a routing table entry to the destination. Upon receipt of the 15
network status command frame, if no routing table entry for the destination is 16
present, or if delivery of the network status command frame to the next hop in the 17
routing table entry fails, the network status command frame shall again be unicast 18
to a random router neighbor using the MCPS-DATA.request primitive. The radius 19
counter in the NWK header will limit the maximum number of times the network 20
status command frame is relayed. Upon receipt of the network status command 21
frame by its destination it shall be passed up to the next higher layer using the 22
NLME-NWK-STATUS.indication primitive. Many-to-one routes are not 23
automatically rediscovered by the NWK layer due to route errors. 24
25
If a failed link is encountered while the device is forwarding a unicast frame using 26
normal unicast routing, the device shall issue a network status command frame 27
back to the source device of the frame with a status code indicating the reason for 28
the failure (see Table 3.42), and issue an NLME-NWK-STATUS.indication to the 29
next higher layer with a status code indicating the reason for the failure. 30
On receipt of a network status command frame by a router that is the intended 31
destination of the command where the status code field of the command frame 32
payload has a value of 0x01 or 0x02 indicating a link failure, the NWK layer will 33
remove the routing table entry corresponding to the value of the destination 34
address field of the command frame payload, if one exists, and inform the next 35
higher layer of the failure using the NLME-NWK-STATUS.indication using the 36
same status code. 37
38
On receipt of a network status command frame by a router that is the parent of an 39
end device that is the intended destination, where the status code field of the 40
command frame payload has a value of 0x01 or 0x02 indicating a link failure, the 41
NWK layer will remove the routing table entry corresponding to the value of the 42
destination address field of the command frame payload, if one exists. It will then 43
relay the frame as usual to the end device. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 405

On receipt of a network status command frame by an end device, the NWK layer
shall inform the next higher layer of the failure using the NLME-NWK- 1
STATUS.indication. 2
3
If an end device encounters a failed link to its parent, the end device shall inform 4
the next higher layer using the NLME-NWK-STATUS.indication primitive with a 5
Status parameter value of 0x09 indicating parent link failure (see Table 3.42). 6
Similarly if a ZigBee router without routing capacity for which 7
nwkUseTreeRouting has a value of TRUE encounters a failed link to its parent, it 8
shall inform the next higher layer using the NLME-NWK-STATUS.indication 9
primitive with a Status parameter value of 0x09 indicating parent link failure. 10
11
3.6.4 Scheduling Beacon Transmissions 12
13
Beacon scheduling is necessary in a multi-hop topology to prevent the beacon 14
frames of one device from colliding with either the beacon frames or the data 15
transmissions of its neighboring devices. Beacon scheduling is necessary when 16
implementing a tree topology but not a mesh topology, as beaconing is not 17
permitted in ZigBee mesh networks. 18
19
3.6.4.1 Scheduling Method 20
21
The ZigBee coordinator shall determine the beacon order and superframe order 22
for every device in the network (see [B1] for more information on these 23
attributes). Because one purpose of multi-hop beaconing networks is to allow 24
routing nodes the opportunity to sleep in order to conserve power, the beacon 25
order shall be set much larger than the superframe order. Setting the attributes in 26
this manner makes it possible to schedule the active portion of the superframes of 27
every device in any neighborhood such that they are non-overlapping in time. In 28
other words, time is divided into approximately (macBeaconInterval/ 29
macSuperframeDuration) non-overlapping time slots, and the active portion of 30
the superframe of every device in the network shall occupy one of these non- 31
overlapping time slots. An example of the resulting frame structure for a single 32
beaconing device is shown in Figure 3.46. 33
34
Beacon Interval 35
Beacon CAP 36
37
38
39
Inactive Period
40
41
Superframe
Duration 42
43
Figure 3.46 Typical Frame Structure for a Beaconing Device 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
406 Network Specification

The beacon frame of a device shall be transmitted at the start of its non-
overlapping time slot, and the transmit time shall be measured relative to the 1
beacon transmit time of the parent device. This time offset shall be included in the 2
beacon payload of every device in a multi-hop beaconing network (see sub- 3
clause 3.6.7 for a complete list of beacon payload parameters). Therefore a device 4
receiving a beacon frame shall know the beacon transmission time of both the 5
neighboring device and the parent of the neighboring device, since the 6
transmission time of the parent may be calculated by subtracting the time offset 7
from the timestamp of the beacon frame. The receiving device shall store both the 8
local timestamp of the beacon frame and the offset included in the beacon payload 9
in its neighbor table. The purpose of having a device know when the parent of its 10
neighbor is active is to maintain the integrity of the parent-child communication 11
link by alleviating the hidden node problem. In other words, a device will never 12
transmit at the same time as the parent of its neighbor. 13
14
Communication in a tree network shall be accomplished using the parent-child 15
links to route along the tree. Since every child tracks the beacon of its parent, 16
transmissions from a parent to its child shall be completed using the indirect 17
transmission technique. Transmissions from a child to its parent shall be 18
completed during the CAP of the parent. Details for the communication 19
procedures can be found in IEEE 802.15.4-2003 [B1]. 20
A new device wishing to join the network shall follow the procedure outlined in 21
sub-clause 3.6.1.4. In the process of joining the network, the new device shall 22
build its neighbor table based on the information collected during the MAC scan 23
procedure. Using this information, the new device shall choose an appropriate 24
time for its beacon transmission and CAP (the active portion of its superframe 25
structure) such that the active portion of its superframe structure does not overlap 26
with that of any neighbor or of the parent of any neighbor. If there is no available 27
non-overlapping time slot in the neighborhood, the device shall not transmit 28
beacons and shall operate on the network as an end device. If a non-overlapping 29
time slot is available, the time offset between the beacon frames of the parent and 30
the new device shall be chosen and included in the beacon payload of the new 31
device. Any algorithm for selecting the beacon transmission time that avoids 32
beacon transmission during the active portion of the superframes of its neighbors 33
and their parents may be employed, as interoperability will be ensured. 34
35
To counteract drift, the new device shall track the beacon of its parent and adjust 36
its own beacon transmission time such that the time offset between the two 37
remains constant. Therefore, the beacon frames of every device in the network are 38
essentially synchronized with those of the ZigBee coordinator. Figure 3.47 39
illustrates the relationship between the active superframe portions of a parent and 40
its child. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 407

1
2
3
4
5
Beacon Tracking
6
7
8
9
10
Beacon 11
Tx Offset 12
Figure 3.47 Parent-Child Superframe Positioning Relationship 13
14
The density of devices that can be supported in the network is inversely 15
proportional to the ratio of the superframe order to the beacon order. The smaller 16
the ratio, the longer the inactive period of each device and the more devices that 17
can transmit beacon frames in the same neighborhood. It is recommended that a 18
tree network utilize a superframe order of 0, which, when operating in the 19
2.4 GHz band, gives a superframe duration of 15.36 ms and a beacon order of 20
between 6 and 10, which, in the 2.4 GHz band, gives a beacon interval between 21
0.98304s and 15.72864s. Using these superframe and beacon order values, a 22
typical duty cycle for devices in the network will be between ~2% and ~0.1% 23
regardless of the frequency band. 24
25
26
3.6.5 Broadcast Communication 27
28
This sub-clause specifies how a broadcast transmission is accomplished within a 29
ZigBee network. Any device within a network may initiate a broadcast 30
transmission intended for a number of other devices that are part of the same 31
network. A broadcast transmission is initiated by the local APS sub-layer entity 32
through the use of the NLDE-DATA.request primitive by setting the DstAddr 33
parameter to a broadcast address as shown in Table 3.54, or by the NWK layer 34
through the use of these same broadcast addresses in the construction of an 35
outgoing NWK header. 36
Table 3.54 Broadcast Addresses 37
38
Broadcast Address Destination Group 39
0xffff All devices in PAN 40
0xfffe Reserved 41
42
0xfffd macRxOnWhenIdle = TRUE
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
408 Network Specification

Table 3.54 Broadcast Addresses (Continued)


1
Broadcast Address Destination Group 2
0xfffc All routers and coordinator 3
4
0xfffb Low power routers only
5
0xfff8 - 0xfffa Reserved 6
7
To transmit a broadcast MSDU, the NWK layer of a ZigBee router or ZigBee 8
coordinator issues an MCPS-DATA.request primitive to the MAC sub-layer with 9
the DstAddrMode parameter set to 0x02 (16-bit network address) and the 10
DstAddr parameter set to 0xffff. For a ZigBee end device, the MAC destination 11
address of the broadcast frame shall be set equal to the 16-bit network address of 12
the parent of the end device. The PANId parameter shall be set to the PANId of the 13
ZigBee network. This specification does not support broadcasting across multiple 14
networks. Broadcast transmissions shall not use the MAC sub-layer 15
acknowledgement; instead, a passive acknowledgement mechanism may be used. 16
Passive acknowledgement means that every ZigBee router and ZigBee 17
coordinator keeps track of which of its neighboring devices have successfully 18
relayed the broadcast transmission. The MAC sub-layer acknowledgement is 19
disabled by setting the acknowledged transmission flag of the TxOptions 20
parameter to FALSE. All other flags of the TxOptions parameter shall be set based 21
on the network configuration. 22
The ZigBee coordinator, each ZigBee router and those ZigBee end devices with 23
macRxOnWhenIdle equal to TRUE, shall keep a record of any new broadcast 24
transaction that is either initiated locally or received from a neighboring device. 25
This record is called the broadcast transaction record (BTR) and shall contain at 26
least the sequence number and the source address of the broadcast frame. The 27
broadcast transaction records are stored in the nwkBroadcastTransactionTable 28
(BTT) as shown in Table 3.55. 29
30
Table 3.55 Broadcast Transaction Record 31
Field Name Size Description 32
33
Source Address 2 bytes The 16-bit network address of the broadcast 34
initiator.
35
Sequence Number 1 byte The NWK layer sequence number of the 36
initiator’s broadcast.
37
Expiration Time 1 byte A countdown timer indicating the number of 38
seconds until this entry expires; the initial 39
value is nwkNetworkBroadcastDeliveryTime.
40
41
When a device receives a broadcast frame from a neighboring device, it shall 42
compare the destination address of the frame with its device type. If the 43
destination address does not correspond to the device type of the receiver as 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 409

outlined in Table 3.54, the frame shall be discarded. If the destination address
corresponds to the device type of the receiver, the device shall compare the 1
sequence number and the source address of the broadcast frame with the records 2
in its BTT. 3
4
If the device has a BTR of this particular broadcast frame in its BTT, it may 5
update the BTR to mark the neighboring device as having relayed the broadcast 6
frame. It shall then drop the frame. If no record is found, it shall create a new BTR 7
in its BTT and may mark the neighboring device as having relayed the broadcast. 8
The NWK layer shall then indicate to the higher layer that a new broadcast frame 9
has been received using the NLDE-DATA.indication. If the radius field value is 10
greater than 0 or if the device is not a ZigBee End Device then it shall retransmit 11
the frame. Otherwise, it shall drop the frame. Before the retransmission, it shall 12
wait for a random time period called broadcast jitter. This time period shall be 13
bounded by the value of the nwkcMaxBroadcastJitter attribute. ZigBee end 14
devices with macRxOnWhenIdle equal to FALSE shall not participate in the 15
relaying of broadcast frames and need not maintain a BTT for broadcast frames 16
that they originate. 17
If, on receipt of a broadcast frame, the NWK layer finds that the BTT is full and 18
contains no expired entries, then the frame should be dropped. In this situation the 19
frame should not be retransmitted, nor should it be passed up to the next higher 20
layer. 21
22
A ZigBee coordinator or ZigBee router operating in a non-beacon-enabled ZigBee 23
network shall retransmit a previously broadcast frame at most 24
nwkMaxBroadcastRetries times. If the device does not support passive 25
acknowledgement, then it shall retransmit the frame exactly 26
nwkMaxBroadcastRetries times. If the device supports passive acknowledgement 27
and any of its neighboring devices have not relayed the broadcast frame within 28
nwkPassiveAckTimeout seconds then it shall continue to retransmit the frame up 29
to a maximum of nwkMaxBroadcastRetries times. 30
A device should change the status of a BTT entry after 31
nwkNetworkBroadcastDeliveryTime seconds have elapsed since its creation. The 32
entry status should change to expired and thus the entry can be overwritten if 33
required when a new broadcast is received. 34
35
When a ZigBee router that has the macRxOnWhenIdle MAC PIB attribute set to 36
FALSE receives a broadcast transmission, it shall use a different procedure for 37
retransmission than the one outlined above. It shall retransmit the frame without 38
delay to each of its neighbors individually, using a MAC layer unicast, that is, 39
with the DstAddr parameter of the MCPS-DATA.request primitive set to the 40
address of each neighbor device and not to the broadcast address. Similarly, a 41
router or coordinator with the macRxOnWhenIdle MAC PIB attribute set to 42
TRUE, which has one or more neighbors with the macRxOnWhenIdle MAC PIB 43
parameter set to FALSE, shall, in the case where the destination address is 0xffff 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
410 Network Specification

denoting broadcast to all devices, retransmit the broadcast frame to each of these
neighbors in turn as a MAC layer unicast in addition to performing the more 1
general broadcast procedure spelled out in the previous paragraphs. Indirect 2
transmission, as described in IEEE 802.15.4-2003 [B1], may be employed to 3
ensure that these unicasts reach their destination. 4
5
Every ZigBee router shall have the ability to buffer at least 1 frame at the NWK 6
layer in order to facilitate retransmission of broadcasts. 7
Figure 3.48 shows a broadcast transaction between a device and two neighboring 8
devices. 9
10
11
MAC Broadcast Transmission
12
Add new BTR
Mark Neighbor 1 as having 13
14
relayed the message

15
Broadcast
Jitter
16
17
18
19
MAC Broadcast Transmission MAC Broadcast Transmission MAC Broadcast Transmission

Add new BTR


Mark Device as having 20
relayed the message
21
nwkPassiveAckTimeout
22
Broadcast 23
Jitter
24
25
MAC Broadcast Transmission MAC Broadcast Transmission MAC Broadcast Transmission
26
Ignore
Broadcast Mark Neighbor 2 as 27
having relayed the
message 28
29
30
31
NWK NWK NWK 32
Neighbor 1 Device Neighbor 2
33
Figure 3.48 Broadcast Transaction Message Sequence Chart 34
35
36
3.6.6 Multicast Communication 37
38
This sub-clause specifies how multicast transmission is accomplished within a 39
ZigBee network. Multicast addressing is accomplished using 16-bit multicast 40
group IDs. A multicast group is a collection of nodes, all registered under the 41
same multicast group ID, that are physically separated by a hop distance of no 42
more than a given radius, known as the MaxNonMemberRadius. A multicast 43
message is sent to a particular destination group and is received by all members of 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 411

that group. Only data frames are multicast — no NWK command frames are
multicast. 1
2
Multicast frames are propagated through the network by both members and non- 3
members of the destination multicast group. A packet may be sent in one of two 4
modes as indicated by a mode flag in the packet which determines the method of 5
relay to the next hop. If the original message was created by a member of the 6
group, it is considered to be in ‘Member Mode’ and is relayed by means of 7
broadcasts. If the original message was created by a non-member of the group, it 8
is considered to be in ‘Non-Member Mode’ and is relayed by means of unicasts 9
towards a group member. Once a non-member message reaches any member of 10
the destination group, it is instantly transformed into a Member Mode type relay 11
for the duration of the life of the packet regardless of who relays it next. 12
Multicast messages may be originated by end devices but are not sent to devices 13
where macRxOnWhenIdle is equal to FALSE. 14
15
3.6.6.1 The Group ID Table 16
17
The NWK layer of a device may maintain a group ID table, nwkGroupIDTable, 18
accessible as an attribute of the NIB as shown in Table 3.44. If the 19
nwkGroupIDTable NIB attribute is present then it shall contain a set of 16-bit 20
group identifiers for groups of which the device is a member. 21
Note that the optional nwkGroupIDTable NIB attribute has a functional overlap 22
with the mandatory APS group table (see Table 2.18). If a device maintains both 23
tables, and thereby expects to use NWK-layer multicast as a method for receiving 24
group-addressed frames, it must assure that each 16-bit group identifiers that 25
appears in the APS group table also appears in the NWK group table. 26
27
Note also that from an implementation perspective, it would be wasteful to 28
duplicate the list of group identifiers across layers and it is assumed that 29
implementers will find a way to combine the APS and NWK group tables to avoid 30
waste. 31
32
3.6.6.2 Upon Receipt of a Multicast Frame from the Next 33
Higher Layer 34
35
If an NLDE-DATA.request is received by the NWK layer from its next higher 36
layer and the multicast control field is 0x01, the NWK layer shall determine 37
whether an entry exists in the nwkGroupIDTable having a group identifier field 38
matching the destination address of the frame. If a matching entry is found, the 39
NWK layer shall multicast the frame according to the procedure outlined in sub- 40
clause 3.6.6.2.1. If a matching entry is not found, the frame shall be initiated as a 41
non-member mode multicast using the procedure outlined in sub-clause 3.6.6.2.2. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
412 Network Specification

3.6.6.2.1 Initiating a Member Mode Multicast


1
The NWK layer shall set the multicast mode sub-field of the multicast control 2
field to 0x01 (member mode). If the BTT table is full and contains no expired 3
entries, the message shall not be sent and the NLDE shall issue the NLDE- 4
DATA.confirm primitive with a status value of BT_TABLE_FULL. If the BTT is 5
not full or contains an expired BTR, a new BTR shall be created with the local 6
node as the source and the multicast frame's sequence number. The message shall 7
then be transmitted according to the procedure described in the final paragraph of 8
sub-clause 3.6.6.3. 9
3.6.6.2.2 Initiating a Non-Member Mode Multicast 10
11
The NWK layer shall set the multicast mode sub-field of the multicast control 12
field to 0x00 (non-member mode). Then, the NWK layer shall check its routing 13
table for an entry corresponding to the GroupID destination of the frame. If there 14
is such an entry, the NWK layer shall examine the entry's status field. If the status 15
is ACTIVE, then the device shall (re)transmit the frame. If the status is 16
VALIDATION_UNDERWAY, then the status shall be changed to ACTIVE, the 17
device shall transmit the frame according to the procedure described in the final 18
paragraph of sub-clause 3.6.6.4, and the NLDE shall issue the NLDE- 19
DATA.confirm primitive with the status value received from the MCPS- 20
DATA.confirm primitive. If there is no routing table entry corresponding to the 21
GroupID destination of the frame and the value of the DiscoverRoute parameter is 22
0x00 (suppress route discovery), the frame shall be discarded and the NLDE shall 23
issue the NLDE-DATA.confirm primitive with a status value of 24
ROUTE_DISCOVERY_FAILED. If the DiscoverRoute parameter has a value of 25
0x01 (enable route discovery) and there is no routing table entry corresponding to 26
the GroupID destination of the frame, then the device shall initiate route discovery 27
immediately as described in sub-clause 3.6.3.5.1. The frame may optionally be 28
buffered pending route discovery. If it is not buffered, the frame shall be discarded 29
and the NLDE shall issue the NLDE-DATA.confirm primitive with a status value 30
of FRAME_NOT_BUFFERED. 31
32
3.6.6.3 Upon Receipt of a Member Mode Multicast Frame 33
34
When a device receives a member mode multicast frame from a neighboring
35
device, it shall compare the sequence number and the source address of the
36
multicast frame with the records in its BTT. If the device has a BTR of this
37
particular multicast frame in its BTT it shall discard the frame. If no record is
38
found and the BTT is full and contains no expired entries, it shall discard the
39
frame. If no record is found and the BTT is not full or contains an expired BTR, it
40
shall create a new BTR and continue processing the message as outlined in the
41
following paragraph.
42
When a member mode multicast frame has been received from a neighbor and 43
added to the BTT, the NWK layer shall then determine whether an entry exists in 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 413

the nwkGroupIDTable whose group identifier field matches the destination group
ID of the frame. If a matching entry is found, the message shall be passed to the 1
next higher layer, the multicast mode sub-field of the multicast control field shall 2
be set to 0x01 (member mode), the value of the NonmemberRadius sub-field shall 3
be set to the value of the MaxNonmemberRadius sub-field in the multicast control 4
field, and the message shall be transmitted as outlined in the following paragraph. 5
6
If a matching entry is not found, the NWK layer shall examine the frame's 7
multicast NonmemberRadius field. If the value of the NonmemberRadius sub- 8
field of the multicast field is 0 the message shall be discarded, along with the 9
newly added BTR. Otherwise, the NonmemberRadius sub-field shall be 10
decremented if it is less than 0x07 and the frame shall be transmitted as outlined in 11
following paragraphs. 12
Each member mode multicast message shall be transmitted 13
nwkMaxBroadcastRetries times. For member mode multicast frames that did not 14
originate on the local device, the initial transmission shall be delayed by a random 15
time bounded by the value of the nwkcMaxBroadcastJitter attribute. A device 16
shall delay a period of nwkPassiveAckTimeout seconds between retransmissions 17
of a particular member mode multicast message. Unlike broadcasts, there is no 18
passive acknowledgement for multicasts. ZigBee end devices shall not participate 19
in the relaying of multicast frames. 20
21
To transmit a member mode multicast MSDU, the NWK layer issues an MCPS- 22
DATA.request primitive to the MAC sub-layer with the DstAddrMode parameter 23
set to 0x02 (16-bit network address) and the DstAddr parameter set to 0xffff, 24
which is the broadcast network address. The PANId parameter shall be set to the 25
PANId of the ZigBee network. Member mode multicast transmissions shall not 26
use the MAC sub-layer acknowledgement or the passive acknowledgement used 27
for broadcasts. The MAC sub-layer acknowledgement is disabled by setting the 28
acknowledged transmission flag of the TxOptions parameter to FALSE. All other 29
flags of the TxOptions parameter shall be set based on the network configuration. 30
31
3.6.6.4 Upon Receipt of a Non-Member Mode Multicast 32
Frame 33
34
When a device receives a non-member mode multicast frame from a neighboring 35
device, the NWK layer shall determine whether an entry exists in the 36
nwkGroupIDTable having a group identifier field that matches the destination 37
address of the frame. If a matching entry is found, the multicast control field shall 38
be set to 0x01 (member mode) and the message shall be processed as if it had been 39
received as a member mode multicast. If no matching nwkGroupIDTable entry is 40
found, the device shall check its routing table for an entry corresponding to the 41
GroupID destination of the frame. If there is no such routing table entry, the 42
message shall be discarded. If there is such an entry, the NWK layer shall examine 43
the entry's status field. If the status is ACTIVE, the device shall (re)transmit the 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
414 Network Specification

frame. If the status is VALIDATION_UNDERWAY, the status shall be changed to


ACTIVE and the device shall (re)transmit the frame. To transmit a non-member 1
mode multicast MSDU, the NWK layer issues an MCPS-DATA.request primitive 2
to the MAC sublayer with the DstAddrMode parameter set to 0x02 (16-bit 3
network address) and the DstAddr parameter set to the next hop as determined 4
from the matching routing table entry. The PANId parameter shall be set to the 5
PANId of the ZigBee network. The MAC sub-layer acknowledgement shall be 6
enabled by setting the acknowledged transmission flag of the TxOptions 7
parameter to TRUE. All other flags of the TxOptions parameter shall be set based 8
on the network configuration. 9
10
11
3.6.7 NWK Information in the MAC Beacons 12
13
This sub-clause specifies how the NWK layer uses the beacon payload of a MAC 14
sub-layer beacon frame to convey NWK layer-specific information to neighboring 15
devices. 16
The beacon payload shall contain the information shown in Table 3.56. This 17
enables the NWK layer to provide additional information to new devices that are 18
performing network discovery and allows these new devices to more efficiently 19
select a network and a particular neighbor to join. Refer to sub-clause 3.6.1.4.1.1 20
for a detailed description of the network discovery procedure. 21
22
Table 3.56 NWK Layer Information Fields
23
Name Type Valid Range Description 24
25
Protocol ID Integer 0x00 – 0xff This field identifies the network
26
layer protocols in use and, for
purposes of this specification, 27
shall always be set to 0, 28
indicating the ZigBee protocols. 29
The value 0xff shall also be 30
reserved for future use by the
31
ZigBee Alliance.
32
Stack profile Integer 0x00 – 0x0f A ZigBee stack profile 33
identifier.
34
nwkcProtocolVersion Integer 0x00 – 0x0f The version of the ZigBee 35
protocol.
36
Router capacity Boolean TRUE or FALSE This value is set to TRUE if this 37
device is capable of accepting 38
join requests from router-
capable devices and is set to 39
FALSE otherwise. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 415

Table 3.56 NWK Layer Information Fields (Continued)


1
Name Type Valid Range Description 2
Device depth Integer 0x00 – 0x0f The network depth of this 3
device. A value of 0x00 4
indicates that this device is the 5
ZigBee coordinator for the 6
network.
7
End device capacity Boolean TRUE or FALSE This value is set to TRUE if the 8
device is capable of accepting
9
join requests from end devices
seeking to join the network and 10
is set to FALSE otherwise. 11
nwkExtendedPANId 64-bit 0x0000000000000001 The globally unique ID for the 12
extended – 0xfffffffffffffffe PAN of which the beaconing 13
address device is a member. By default, 14
this is the 64-bit IEEE address of 15
the ZigBee coordinator that 16
formed the network, but other
values are possible and there is 17
no required structure to the 18
address. 19
TxOffset Integer 0x000000 – 0xffffff This value indicates the 20
difference in time, measured in 21
symbols, between the beacon 22
transmission time of the device 23
and the beacon transmission
24
time of its parent; This offset
may be subtracted from the 25
beacon transmission time of the 26
device to calculate the beacon 27
transmission time of the parent. 28
This parameter is set to the
29
default value of 0xFFFFFF in
beaconless networks.a 30
31
nwkUpdateId Integer 0x00 - 0xFF This field reflects the value of
nwkUpdateId from the NIB.b 32
33
a. CCB #818 34
b. CCB #818 35
36
The NWK layer of the ZigBee coordinator shall update the beacon payload
37
immediately following network formation. All other ZigBee devices shall update
38
it immediately after the join is completed and any time the network configuration
39
(any of the parameters specified in Table 3.10) changes. The beacon payload is
40
written into the MAC sub-layer PIB using the MLME-SET.request primitive. The
41
macBeaconPayloadLength attribute is set to the length of the beacon payload, and
42
the octet sequence representing the beacon payload is written into the
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
416 Network Specification

macBeaconPayload attribute. The formatting of the bit sequence representing the


beacon payload is shown in Figure 3.48. 1
2
Bits: 3
0–7 8–11 12–15 16–17 18 19–22 23 24–87 88–111 112–119 4
Protoco Stack nwkcPr Reserved Router Device End nwk Tx nwkUpda 5
l profile otocolV capacity depth device Extended Offseta teIdb 6
ID ersion capacity PANId 7
8
a. CCB #818
9
b. CCB #818
10
Figure 3.49 Format of the MAC Sub-Layer Beacon Payload
11
12
3.6.8 Persistent Data 13
14
Devices operating in the field may be reset either manually or programmatically 15
by maintenance personnel, or may be reset accidentally for any number of 16
reasons, including localized or network-wide power failures, battery replacement 17
during the course of normal maintenance, impact, and so on. The following 18
information should be preserved across resets in order to maintain an operating 19
network: 20
21
• The device's PAN Id and Extended PAN Id.
22
• The device's 16-bit network address. 23
24
• The 64-bit IEEE address and 16-bit network address of each associated end
25
device child and if nwkAddrAlloc is equal to 0 then also each associated router
26
child.
27
• For end devices, the 16-bit network address of the parent device. 28
29
• The stack profile in use.
30
• The device depth. 31
32
The method by which these data are made to persist is beyond the scope of this
33
specification.
34
35
3.6.9 Low Power Routers (LPR) 36
37
Low power routers are defined as routers operating on batteries for multiple years 38
by regularly powering off their radios. LPRs shall be recognized by high power 39
routers (HPR) looking at the following capability information bit-fields (see 40
Table 3.47) during the joining phase: 41
42
• Device type set to 1
43
• Receive on when idle set to FALSE 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 417

LPR devices should be able to receive network command frames that are
broadcast in the network. This can be achieved by setting the destination address 1
in the NWK header to the broadcast address for all routers and coordinators (see 2
Table 3.54). 3
4
5
3.7 NWK Layer Status Values 6
7
Network (NWK) layer confirmation primitives often include a parameter that 8
reports on the status of the request to which the confirmation applies. Values for 9
NWK layer Status parameters appear in Table 3.57. 10
11
12
Table 3.57 NWK Layer Status Values 13
14
Name Value Description 15
SUCCESS 0x00 A request has been executed successfully. 16
17
INVALID_PARAMETER 0xc1 An invalid or out-of-range parameter has been
passed to a primitive from the next higher layer.
18
19
INVALID_REQUEST 0xc2 The next higher layer has issued a request that is 20
invalid or cannot be executed given the current
state of the NWK layer. 21
22
NOT_PERMITTED 0xc3 An NLME-JOIN.request has been disallowed.
23
STARTUP_FAILURE 0xc4 An NLME-NETWORK-FORMATION.request 24
has failed to start a network. 25
ALREADY_PRESENT 0xc5 A device with the address supplied to the NLME- 26
DIRECT-JOIN.request is already present in the 27
neighbor table of the device on which the NLME- 28
DIRECT-JOIN.request was issued.
29
SYNC_FAILURE 0xc6 Used to indicate that an NLME-SYNC.request has 30
failed at the MAC layer.
31
NEIGHBOR_TABLE_FULL 0xc7 An NLME-JOIN-DIRECTLY.request has failed 32
because there is no more room in the neighbor 33
table.
34
UNKNOWN_DEVICE 0xc8 An NLME-LEAVE.request has failed because the 35
device addressed in the parameter list is not in the
neighbor table of the issuing device.
36
37
UNSUPPORTED_ 0xc9 An NLME-GET.request or NLME-SET.request 38
ATTRIBUTE has been issued with an unknown attribute
identifier. 39
40
NO_NETWORKS 0xca An NLME-JOIN.request has been issued in an
environment where no networks are detectable.
41
42
Reserved 0xcb 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 3
418 Network Specification

Table 3.57 NWK Layer Status Values (Continued)


1
Name Value Description 2
MAX_FRM_COUNTER 0xcc Security processing has been attempted on an 3
outgoing frame, and has failed because the frame 4
counter has reached its maximum value. 5
NO_KEY 0xcd Security processing has been attempted on an 6
outgoing frame, and has failed because no key was 7
available with which to process it. 8
BAD_CCM_OUTPUT 0xce Security processing has been attempted on an 9
outgoing frame, and has failed because the 10
security engine produced erroneous output. 11
NO_ROUTING CAPACITY 0xcf An attempt to discover a route has failed due to a 12
lack of routing table or discovery table capacity. 13
ROUTE_DISCOVERY_FAILED 0xd0 An attempt to discover a route has failed due to a 14
reason other than a lack of routing capacity. 15
ROUTE_ERROR 0xd1 An NLDE-DATA.request has failed due to a 16
routing failure on the sending device. 17
BT_TABLE_FULL 0xd2 An attempt to send a broadcast frame or member 18
mode multicast has failed due to the fact that there 19
is no room in the BTT. 20
FRAME_NOT_BUFFERED 0xd3 An NLDE-DATA.request has failed due to 21
insufficient buffering available. 22
A non-member mode multicast frame was 23
discarded pending route discovery. 24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 419

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 and 4.2.3 give the ZigBee Alliance’s security 21
specifications for the Network (NWK) layer and the Application Support 22
Sublayer (APS) layer, respectively. These clauses introduce the security 23
mechanisms, give the primitives, and define any frame formats used for security 24
purposes. Clause 4.5 describes security elements common to the NWK and APS 25
layers. Clause 4.6 provides a basic functional description of the available security 26
features. Finally, annexes provide technical details and test vectors needed to 27
implement and test the cryptographic mechanisms and protocols used by the 28
NWK and APS layers. 29
30
31
4.2 General Description 32
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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
420 Security Services Specification

4.2.1 Security Architecture and Design 1


2
In this clause, the security architecture is described. Where applicable, this
3
architecture complements the security services that are already present in the
4
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. 13
14
Implementations of security protocols, such as key establishment, are assumed to 15
properly execute the complete protocol and not to leave out any steps thereof. 16
Random number generators are assumed to operate as expected. Furthermore, it is 17
assumed that secret keys do not become available outside the device in an 18
unsecured way. That is, a device will not intentionally or inadvertently transmit its 19
keying material to other devices unless the keying material is protected, such as 20
during key-transport. An exception to this assumption occurs when a device that 21
has not been preconfigured joins the network. In this case, a single key may be 22
sent unprotected, thus resulting in a brief moment of vulnerability where the key 23
could be obtained by any device. This can lead to a critical security compromise if 24
it is possible for an untrusted device to obtain the key. 25
The following caveat in these assumptions applies: due to the low-cost nature of 26
ad hoc network devices, one cannot generally assume the availability of tamper- 27
resistant hardware. Hence, physical access to a device may yield access to secret 28
keying material and other privileged information, as well as access to the security 29
software and hardware. 30
31
Due to cost constraints, ZigBee has to assume that different applications using the 32
same radio are not logically separated (for example, by using a firewall). In 33
addition, from the perspective of a given device it is not even possible (barring 34
certification) to verify whether cryptographic separation between different 35
applications on another device — or even between different layers of the 36
communication stack thereof — is indeed properly implemented. Hence, one must 37
assume that separate applications using the same radio trust each other; that is, 38
there is no cryptographic task separation. Additionally, lower layers (for example, 39
APS, NWK, or MAC) are fully accessible by any of the applications. These 40
assumptions lead to an open trust model for a device; different layers of the 41
communication stack and all applications running on a single device trust each 42
other. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 421

In summary:
1
• The provided security services cryptographically protect the interfaces between 2
different devices only. 3
• Separation of the interfaces between different stack layers on the same device 4
is arranged non-cryptographically, via proper design of security service access 5
points. 6
7
4.2.1.2 Security Design Choices 8
9
The open trust model (as described in sub-clause 4.2.1.1) on a device has far- 10
reaching consequences. It allows re-use of the same keying material among 11
different layers on the same device and it allows end-to-end security to be realized 12
on a device-to-device basis rather than between pairs of particular layers (or even 13
pairs of applications) on two communicating devices. 14
However, one must also take into consideration whether one is concerned with the 15
ability of malevolent network devices to use the network to transport frames 16
across the network without permission. 17
18
These observations lead to the following architectural design choices: 19
• First, the principle that “the layer that originates a frame is responsible for 20
initially securing it” is established. For example, if a NWK command frame 21
needs protection, NWK layer security shall be used. 22
23
• Second, if protection from theft of service is required (i.e., from malevolent 24
network devices), NWK layer security shall be used for all frames, except those 25
passed between a router and a newly joined device (until the newly joined 26
device receives the active network key). Thus, only a device that has joined the 27
network and successfully received the active network key will be able to have 28
its messages communicated more than one hop across the network. 29
• Third, due to the open trust model, security can be based on the reuse of keys 30
by each layer. For example, the active network key shall be used to secure APS 31
layer broadcast frames or NWK layer frames. Reuse of keys helps reduce 32
storage costs. 33
34
• Fourth, end-to-end security is enabled such that it is possible for only source 35
and destination devices to access their shared key. This limits the trust 36
requirement to those devices whose information is at stake. Additionally, it 37
ensures that routing of messages between devices can be realized independent 38
of trust considerations (thus if security is used, facilitating considerable 39
separation of concern). 40
• Fifth, to simplify interoperability of devices, the security level used by all 41
devices in a given network, and by all layers of a device, shall be the same. If 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
422 Security Services Specification

an application needs more security for its payload than is provided by a given
network, it shall form its own separate network with a higher security level. 1
2
There are several policy decisions which any real implementation must address 3
correctly. Application profiles should include policies to: 4
• Handle error conditions arising from securing and unsecuring packets. Some 5
error conditions may indicate loss of synchronization of security material, or 6
may indicate ongoing attacks. 7
8
• Detect and handle loss of counter synchronization and counter overflow. 9
• Detect and handle loss of key synchronization. 10
11
• Expire and periodically update keys, if desired. 12
13
4.2.1.3 Security Keys 14
Security amongst a network of ZigBee devices is based on “link” keys and a 15
“network” key. Unicast communication between APL peer entities is secured by 16
means of a 128-bit link key shared by two devices, while broadcast 17
communications are secured by means of a 128-bit network key shared amongst 18
all devices in the network. The intended recipient is always aware of the exact 19
security arrangement; that is, the recipient knows whether a frame is protected 20
with a link key or a network key. 21
22
A device shall acquire link keys either via key-transport, key-establishment, or 23
pre-installation (for example, during factory installation). A device shall acquire a 24
network key via key-transport or pre-installation. The key-establishment 25
technique for acquiring a link key (see sub-clause 4.2.3.1) is based on a “master” 26
key. A device shall acquire a master key (for purposes of establishing 27
corresponding link keys) via key-transport or pre-installation. Ultimately, security 28
between devices depends on secure initialization and installation of these keys. 29
There are two different types of network keys: standard, and high-security. The 30
type controls how a network key is distributed; and may control how network 31
frame counters are initialized. The type does not affect how messages are secured. 32
33
In a secured network there are a variety of security services available. Prudence 34
dictates that one would prefer to avoid re-use of keys across different security 35
services, which otherwise could cause security leaks due to unwanted interactions. 36
As such, these different services use a key derived from a one-way function using 37
the link key (as specified in sub-clause 4.5.3). The use of uncorrelated keys 38
ensures logical separation of the execution of different security protocols. The 39
key-load key is used to protect transported master and link keys; the key-transport 40
key is used to protect transported network keys. The active network key may be 41
used by the NWK and APL layers of ZigBee. As such, the same network key and 42
associated outgoing and incoming frame counters shall be available to all of these 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 423

layers. The link and master keys may be used only by the APS sublayer. As such,
the link and master keys shall be available only to the APL layer. 1
2
4.2.1.4 ZigBee Security Architecture 3
4
The ZigBee security architecture includes security mechanisms at two layers of 5
the protocol stack. The NWK and APS layers are responsible for the secure 6
transport of their respective frames. Furthermore, the APS sublayer provides 7
services for the establishment and maintenance of security relationships. The 8
ZigBee Device Object (ZDO) manages the security policies and the security 9
configuration of a device. Figure 1.1 shows a complete view of the ZigBee 10
protocol stack. The security mechanisms provided by the APS and NWK layers 11
are described in this version of the specification. 12
13
4.2.2 NWK Layer Security 14
15
When a frame originating at the NWK layer needs to be secured, or when a frame 16
originates at a higher layer and the nwkSecureAllFrames attribute in the NIB is 17
TRUE, ZigBee shall use the frame-protection mechanism given in sub- 18
clause 4.3.1 of this specification, unless the SecurityEnable parameter of the 19
NLDE-DATA.request primitive is FALSE, explicitly prohibiting security. The 20
NWK layer's frame-protection mechanism shall make use of the Advanced 21
Encryption Standard (AES) [B8] and use CCM* as specified in Annex A. The 22
security level applied to a NWK frame shall be determined by the 23
nwkSecurityLevel attribute in the NIB. Upper layers manage NWK layer security 24
by setting up active and alternate network keys and by determining which security 25
level to use. 26
27
Figure 4.1 shows an example of the security fields that may be included in a NWK 28
frame. 29
30
Application of security suite adds auxiliary header
31
and also an integrity code 32
33
34
SYNC
PHY MAC NWK Auxiliary
Encrypted NWK Payload MIC 35
HDR HDR HDR HDR 36
37
38
All of the above NWK frame is integrity-protected 39
Figure 4.1 ZigBee Frame with Security on the NWK Level 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
424 Security Services Specification

4.2.3 APL Layer Security 1


2
When a frame originating at the APL layer needs to be secured, the APS sublayer
3
shall handle security. The APS layer's frame-protection mechanism is given in
4
sub-clause 4.4.1 of this specification. The APS layer allows frame security to be
5
based on link keys or the network key. Figure 4.2 shows an example of the
6
security fields that may be included in an APL frame. The APS layer is also
7
responsible for providing applications and the ZDO with key establishment, key
8
transport, and device management services.
9
10
Application of security suite adds auxiliary header 11
and also an integrity code
12
13
PHY MAC NWK APS Auxiliary 14
SYNC Encrypted APS Payload MIC
HDR HDR HDR HDR HDR 15
16
17
All of the above APS frame is integrity-protected 18
19
Figure 4.2 ZigBee Frame with Security on the APS Level 20
21
4.2.3.1 Key Establishment 22
The APS sublayer’s key-establishment services provide the mechanism by which 23
a ZigBee device may derive a shared secret key (the so-called “link key”, see sub- 24
clause 4.2.1.3), with another ZigBee device. Key establishment involves two 25
entities, an initiator device and a responder device, and is prefaced by a trust- 26
provisioning step. 27
28
Trust information (for example, a master key) provides a starting point for 29
establishing a link key and can be provisioned in-band or out-of-band. Once trust 30
information is provisioned, a key-establishment protocol involves three 31
conceptual steps: 32
• The exchange of ephemeral data. 33
34
• The use of this ephemeral data to derive the link key. 35
• The confirmation that this link key was correctly computed. 36
37
In the Symmetric-Key Key Establishment (SKKE) protocol, an initiator device 38
establishes a link key with a responder device using a master key. This master key, 39
may be pre-installed during manufacturing, may be installed by a Trust Center 40
(for example, from the initiator, the responder, or a third party device acting as a 41
Trust Center), or may be based on user-entered data (for example: PIN, password, 42
or key). The secrecy and authenticity of the master key needs to be upheld in order 43
to maintain a trust foundation. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 425

4.2.3.2 Transport Key


1
The transport-key service provides secured and unsecured means to transport a 2
key to another device or other devices. The secured transport-key command 3
provides a means to transport a master, link, or network key from a key source 4
(for example, the Trust Center) to other devices. The unsecured transport-key 5
command provides a means for loading a device with an initial key. This 6
command does not cryptographically protect the key being loaded. In this case, 7
the security of the transported key can be realized by non-cryptographic means; 8
for example, by communicating the command via an out-of-band channel that 9
guarantees secrecy and authenticity. 10
11
4.2.3.3 Update Device 12
13
The update device service provides a secure means for a device (e.g., a router) to 14
inform a second device (for example, a Trust Center) that a third device has had a 15
change of status that must be updated (for example, the device joined or left the 16
network). This is the mechanism by which the Trust Center maintains an accurate 17
list of active network devices. 18
19
4.2.3.4 Remove Device 20
The remove device service provides a secure means by which a device (for 21
example, a Trust Center) may inform another device (for example, a router) that 22
one of its children should be removed from the network. For example, the remove 23
device service may be employed to remove from a network a device that has not 24
satisfied the Trust Center’s security requirements for network devices. 25
26
4.2.3.5 Request Key 27
28
The request-key service provides a secure means for a device to request the active 29
network key, or an end-to-end application master key, from another device (for 30
example, its Trust Center). 31
32
4.2.3.6 Switch Key 33
The switch-key service provides a secure means for a device (for example, a Trust 34
Center) to inform another device that it should switch to a different active network 35
key. 36
37
4.2.3.7 Entity Authentication 38
39
The entity authentication service provides a secure means for a device to 40
synchronize information with another device while simultaneously providing 41
authenticity based on a shared key. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
426 Security Services Specification

4.2.3.8 Permissions Configuration Table


1
The permissions configuration table indicates which devices have authorization to 2
carry out certain types of commands, and determines in each case whether or not 3
link key security is required. 4
5
6
4.2.4 Trust Center Role 7
8
For security purposes, ZigBee defines the role of “Trust Center”. The Trust Center
9
is the device trusted by devices within a network to distribute keys for the purpose
10
of network and end-to-end application configuration management. All members
11
of the network shall recognize exactly one Trust Center, and there shall be exactly
12
one Trust Center in each secure network.
13
In high-security, commercial applications (see sub-clause 4.6.2.1) a device can be 14
pre-loaded with the Trust Center address and initial master key. Alternatively, if 15
the application can tolerate a moment of vulnerability, the master key can be sent 16
via an in-band unsecured key transport. If not pre-loaded, a device's Trust Center 17
defaults to the ZigBee coordinator or a device designated by the ZigBee 18
coordinator. 19
20
In low-security, residential applications (see sub-clause 4.6.2.2) a device securely
21
communicates with its Trust Center using the current network key, which can be
22
preconfigured or sent via an in-band unsecured key transport.
23
For purposes of trust management, a device accepts an initial master or active 24
network key originating from its Trust Center via unsecured key transport. For 25
purposes of network management, a device accepts an initial active network key 26
and updated network keys only from its Trust Center. For purposes of 27
configuration, a device accepts master keys or link keys intended for establishing 28
end-to-end security between two devices only from its Trust Center. Aside from 29
the initial master key or network key, additional link, master, and network keys 30
are generally only accepted if they originate from a device's Trust Center via 31
secured key transport. 32
33
34
4.3 NWK Layer Security 35
36
The NWK layer is responsible for the processing steps needed to securely transmit 37
outgoing frames and securely receive incoming frames. Upper layers control the 38
security processing operations by setting up the appropriate keys and frame 39
counters and establishing which security level to use. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 427

4.3.1 Frame Security 1


2
The detailed steps involved in security processing of outgoing and incoming
3
NWK frames are described in sub-clauses 4.3.1.1 and 4.3.1.2, respectively.
4
4.3.1.1 Security Processing of Outgoing Frames 5
6
If the NWK layer has a frame, consisting of a header NwkHeader and payload 7
Payload, which needs security protection and nwkSecurityLevel > 0, and in the 8
case of a NWK data frame, the SecurityEnabled parameter in NLDE- 9
DATA.request had a value of TRUE, it shall apply security as follows: 10
11
1 Obtain the nwkActiveKeySeqNumber from the NIB and use it to retrieve the
12
active network key key, outgoing frame counter OutgoingFrameCounter, and 13
key sequence number KeySeqNumber from the nwkSecurityMaterialSet 14
attribute in the NIB. Obtain the security level from the nwkSecurityLevel 15
attribute from the NIB. If the outgoing frame counter has as its value the 4-octet 16
representation of the integer 232-1, or if the key cannot be obtained, security 17
processing shall fail and no further security processing shall be done on this 18
frame. 19
2 Construct the auxiliary header AuxiliaryHeader (see sub-clause 4.5.1): 20
21
a Set the security control field as follows:
22
i The security level sub-field shall be the security level obtained from step 1. 23
24
ii The key identifier sub-field shall be set to ‘01’ (that is, the active network key).
25
iii The extended nonce sub-field shall be set to 1. 26
27
b Set the source address field to the 64-bit extended address of the local
28
device. 29
c Set the frame counter field to the outgoing frame counter from step 1. 30
31
d Set the key sequence number field to the sequence number from step 1.
32
3 Execute the CCM* mode encryption and authentication operation, as specified 33
in Annex A, with the following instantiations: 34
35
a Obtain the parameter M from Table 4.38 corresponding to the security level
36
from step 1; 37
b The bit string Key shall be the key obtained from step 1; 38
39
c The nonce N shall be the 13-octet string constructed using the security
40
control field from step a, the frame counter field from step d, and the source 41
address field from step c (see sub-clause 4.5.2.2); 42
d If the security level requires encryption, the octet string a shall be the string 43
NwkHeader || AuxiliaryHeader and the octet string m shall be the string 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
428 Security Services Specification

Payload. Otherwise, the octet string a shall be the string NwkHeader ||


AuxiliaryHeader || Payload and the octet string m shall be a string of length 1
zero. 2
3
4 If the CCM* mode invoked in step 3 outputs ‘invalid’, security processing shall 4
fail and no further security processing shall be done on this frame. 5
5 Let c be the output from step 3. If the security level requires encryption, the 6
secured outgoing frame shall be NwkHeader || AuxiliaryHeader || c, otherwise 7
the secured outgoing frame shall be NwkHeader || AuxiliaryHeader || Payload || 8
c. 9
10
6 If the secured outgoing frame size is greater than aMaxMACFrameSize (see 11
IEEE Std. 802.15.4 802 [B1]), security processing shall fail and no further 12
security processing shall be done on this frame. 13
7 The outgoing frame counter from step 1 shall be incremented by one and stored 14
in the OutgoingFrameCounter element of the network security material 15
descriptor referenced by the nwkActiveKeySeqNumber in the NIB; that is, the 16
outgoing frame counter value associated with the key used to protect the frame 17
is updated. 18
19
8 The security level sub-field of the security control field shall be over-written by 20
the 3-bit all-zero string '000'. 21
22
4.3.1.2 Security Processing of Incoming Frames 23
If the NWK layer receives a secured frame (consisting of a header NwkHeader, 24
auxiliary header AuxiliaryHeader, and payload SecuredPayload) as indicated by 25
the security sub-field of the NWK header frame control field, it shall perform 26
security processing as follows: 27
28
1 Determine the security level from the nwkSecurityLevel attribute of the NIB. 29
Over-write the 3-bit security level sub-field of the security control field of the 30
AuxiliaryHeader with this value. Determine the sequence number 31
SequenceNumber, sender address SenderAddress, and received frame count 32
ReceivedFrameCount from the auxiliary header AuxiliaryHeader (see sub- 33
clause 4.5.1). If ReceivedFrameCounter has as value the 4-octet representation 34
of the integer 232-1, security processing shall indicate a failure to the next 35
higher layer with a status of '30bad frame counter' and no further security 36
processing shall be done on this frame. 37
2 Obtain the appropriate security material (consisting of the key and other 38
attributes) by matching SequenceNumber to the sequence number of any key in 39
the nwkSecurityMaterialSet attribute in the NIB. If the neighbor table entry 40
corresponding to SenderAddress has a relationship field with value 0x01 41
42
43
30. CCB #765 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 429

(child), that field shall be set to the value 0x05 (unauthenticated child). If the
security material cannot be obtained, security processing shall indicate a failure 1
to the next higher layer with a status of 'frame security failed' and no further 2
security processing shall be done on this frame.31 3
4
3 If there is an incoming frame count FrameCount corresponding to 5
SenderAddress from the security material obtained in step 2 and if 6
ReceivedFrameCount is less than FrameCount, security processing shall 7
indicate a failure to the next higher layer with a status of 'bad frame counter' 8
and no further security processing shall be done on this frame.32 9
4 Execute the CCM* mode decryption and authentication checking operation, as 10
specified in sub-clause A.2, with the following instantiations: 11
12
a The parameter M shall be obtained from Table 4.38 corresponding to the 13
security level from step 1. 14
b The bit string Key shall be the key obtained from step 2. 15
16
c The nonce N shall be the 13-octet string constructed using the security 17
control, the frame counter, and the source address fields from 18
AuxiliaryHeader (see sub-clause 4.5.2.2). Note that the security level sub- 19
field of the security control field has been overwritten in step 1 and now 20
contains the value determined from the nwkSecurityLevel attribute from the 21
NIB. 22
d The octet string SecuredPayload shall be parsed as Payload1 || Payload2, 23
where the rightmost string Payload2 is an M-octet string. If this operation 24
fails, security processing shall indicate a failure to the next higher layer with 25
a status of 'frame security failed' and no further security processing shall be 26
done on this frame.33 27
28
e If the security level requires decryption, the octet string a shall be the string 29
NwkHeader || AuxiliaryHeader and the octet string c shall be the string 30
SecuredPayload. Otherwise, the octet string a shall be the string NwkHeader 31
|| AuxiliaryHeader || Payload1 and the octet string c shall be the string 32
Payload2. 33
5 Return the results of the CCM* operation: 34
35
a If the CCM* mode invoked in step 4 outputs ‘invalid’, security processing 36
shall indicate a failure to the next higher layer with a status of 'frame security 37
failed' and no further security processing shall be done on this frame.34 38
39
40
31. CCB #673 41
32. CCB #765 42
33. CCB #673 43
34. CCB #673 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
430 Security Services Specification

b Let m be the output of step 4. If the security level requires encryption, set the
octet string UnsecuredNwkFrame to the string NwkHeader || m. Otherwise, 1
set the octet string UnsecuredNwkFrame to the string NwkHeader || 2
Payload1. 3
4
6 Set FrameCount to (ReceivedFrameCount + 1) and store both FrameCount and 5
SenderAddress in the NIB. UnsecuredNwkFrame now represents the unsecured 6
received network frame and security processing shall succeed. So as to never 7
cause the storage of the frame count and address information to exceed the 8
available memory, the memory allocated for incoming frame counters needed 9
for NWK layer security shall be bounded by M*N, where M and N represent the 10
cardinality of nwkSecurityMaterialSet and nwkNeighborTable in the NIB, 11
respectively. 12
7 If the sequence number of the received frame belongs to a newer entry in the 13
nwkSecurityMaterialSet, set the nwkActiveKeySeqNumber to the received 14
sequence number. 15
16
8 If there is an entry in nwkNeighborTable in the NIB whose extended address 17
matches SenderAddress and whose relationship field has value 0x05 18
(unauthenticated child), then set relationship field in that entry to the value 19
0x01 (child). 20
21
4.3.2 Secured NPDU Frame 22
23
The NWK layer frame format (see sub-clause 3.3.1) consists of a NWK header 24
and NWK payload field. The NWK header consists of frame control and routing 25
fields. When security is applied to an NPDU frame, the security bit in the NWK 26
frame control field shall be set to 1 to indicate the presence of the auxiliary frame 27
header. The format for the auxiliary frame header is given in sub-clause 4.5.1. The 28
format of a secured NWK layer frame is shown in Figure 4.3. The auxiliary frame 29
header is situated between the NWK header and payload fields. 30
31
Octets: Variable 14 Variable 32
33
Original NWK header Auxiliary Encrypted Encrypted message integrity code (MIC)
([B3], Clause 7.1) frame payload 34
header 35
Secure frame payload = output of CCM* 36
Full NWK header Secured NWK payload 37
38
Figure 4.3 Secured NWK Layer Frame Format 39
40
4.3.3 Security-Related NIB Attributes 41
42
The NWK PIB contains attributes that are required to manage security for the 43
NWK layer. Each of these attributes can be read and written using the NLME- 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 431

GET.request and NLME-SET.request primitives, respectively. The security-


related attributes contained in the NWK PIB are presented in Tables 4.1 through 1
4.3. 2
3
Table 4.1 NIB Security Attributes
4
Attribute Identifier Type Range Description Default 5
6
nwkSecurityLevel 0xa0 Octet 0x00-07 The security level for 0x05 7
outgoing and incoming
NWK frames; the 8
allowable security level 9
identifiers are presented 10
in Table 4.38. 11
nwkSecurity- 0xa1 A set of 0, Variable Set of network security - 12
MaterialSet 1, or 2 material descriptors 13
network capable of maintaining 14
security an active and alternate 15
material network key.
descriptor 16
s (see 17
Table 4.2) 18
nwkActiveKey 0xa2 Octet 0x00- The sequence number of 0x00 19
SeqNumber 0xFF the active network key 20
in 21
nwkSecurityMaterialSet. 22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
432 Security Services Specification

Table 4.1 NIB Security Attributes (Continued)


1
Attribute Identifier Type Range Description Default 2
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 | Indicates whether TRUE
10
Frames FALSE security shall be applied
to incoming and 11
outgoing NWK data 12
frames. If set to 0x01, 13
security processing 14
shall be applied to all
15
incoming and outgoing
frames except data 16
frames destined for the 17
current device that have 18
the security sub-field of 19
the frame control field
20
set to 0. If this attribute
has a value of 0x01, the 21
NWK layer shall not 22
relay frames that have 23
the security sub-field of 24
the frame control field
25
set to 0. The
SecurityEnable 26
parameter of the NLDE- 27
DATA.request 28
primitive shall override 29
the setting of this
30
attribute.
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 433

1
Table 4.2 Elements of the Network Security Material Descriptor
2
Name Type Range Description Default 3
4
KeySeqNumber Octet 0x00-0xFF A sequence number assigned to a 00 5
network key by the Trust Center
and used to distinguish network 6
keys for purposes of key updates, 7
and incoming frame security 8
operations. 9
OutgoingFrame Ordered 0x00000000- Outgoing frame counter used for 0x00000000 10
Counter set of 4 0xFFFFFFF outgoing frames. 11
octets. F 12
IncomingFrame Set of Variable Set of incoming frame counter Null set 13
CounterSet incoming values and corresponding device 14
frame addresses. 15
counter 16
descriptor
values. 17
See Table 18
4.3. 19
Key Ordered - The actual value of the key. -
20
set of 16 21
octets. 22
23
KeyType Octet 0x00 - 0xff The type of the key. 0x01
24
0x01 = standard 25
0x05 = high security 26
27
All other values are reserved.
28
29
30
Table 4.3 Elements of the Incoming Frame Counter Descriptor 31
32
Name Type Range Description Default 33
SenderAddress Device Any valid 64-bit Extended device Device 34
address address address. specific 35
IncomingFrame Ordered set 0x00000000- Incoming frame 0x00000000 36
Counter of 4 octets 0xFFFFFFFF counter used for 37
incoming 38
frames. 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
434 Security Services Specification

4.4 APS Layer Security 1


2
The APS layer is responsible for the processing steps needed to securely transmit 3
outgoing frames, securely receive incoming frames, and securely establish and 4
manage cryptographic keys. Upper layers control the management of 5
cryptographic keys by issuing primitives to the APS layer. 6
Table 4.4 lists the primitives available for key management and maintenance. 7
Upper layers also determine which security level to use when protecting outgoing 8
frames. 9
10
Table 4.4 The APS Layer Security Primitives
11
APSME 12
Security 13
Primitives Request Confirm Indication Response Description 14
APSME- sub- sub-clause sub-clause sub-clause Establishes a link key 15
ESTABLISH clause 4.4.2.2 4.4.2.3 4.4.2.4 with another ZigBee 16
-KEY 4.4.2.1 device using the SKKE 17
method. 18
APSME- sub- - sub-clause - Transports security 19
TRANSPOR clause 4.4.3.2 material from one 20
T-KEY 4.4.3.1 device to another. 21
APSME- sub- - sub-clause - Notifies the Trust 22
UPDATE- clause 4.4.4.2 Center when a new 23
DEVICE 4.4.4.1 device has joined, or an 24
existing device has left 25
the network.
26
APSME- sub- - sub-clause - Used by the Trust 27
REMOVE- clause 4.4.5.2 Center to notify a 28
DEVICE 4.4.5.1 router that one of the
router’s child devices
29
should be removed 30
from the network. 31
32
APSME- sub- - sub-clause - Used by a device to
REQUEST- clause 4.4.6.2 request that the Trust 33
KEY 4.4.6.1 Center send an 34
application master key 35
or active network key. 36
APSME- sub- - sub-clause - Used by the Trust 37
SWITCH- clause 4.4.7.2 Center to tell a device 38
KEY 4.4.7.1 to switch to a new 39
network key.
40
APSME- sub- sub-clause sub-clause - Used by two devices to 41
AUTHENTI clause 4.4.8.2 4.4.8.3 mutually authenticate 42
CATE 4.4.8.1 each other. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 435

4.4.1 Frame Security 1


2
The detailed steps involved in security processing of outgoing and incoming APS
3
frames are described in sub-clauses 4.4.1.1 and 4.4.1.2, respectively.
4
4.4.1.1 Security Processing of Outgoing Frames 5
6
If the APS layer has a frame, consisting of a header ApsHeader and payload 7
Payload, that needs security protection and nwkSecurityLevel > 0, it shall apply 8
security as follows: 9
10
1 Obtain the security material and key identifier KeyIdentifier using the
11
following procedure. If security material or key identifier cannot be 12
determined, then security processing shall fail and no further security 13
processing shall be done on this frame. 14
a If the frame is a result of a APSDE-DATA.request primitive: 15
16
i If the TxOptions parameter specifies that the active network key is required to
17
secure the data frame, then security material shall be obtained by using the 18
nwkActiveKeySeqNumber from the NIB to retrieve the active network key, 19
outgoing frame counter, and sequence number from the 20
nwkSecurityMaterialSet attribute in the NIB. KeyIdentifier shall be set to ‘01’ 21
(that is, the active network key). 22
ii Otherwise, the security material associated with the destination address of the 23
outgoing frame shall be obtained from the apsDeviceKeyPairSet attribute in the 24
AIB. KeyIdentifier shall be set to ‘00’ (that is, a data key). 25
26
b If the frame is a result of an APS command that requires securing.
27
i First, an attempt shall be made to retrieve the security material associated with 28
the destination address of the outgoing frame from the apsDeviceKeyPairSet 29
attribute in the AIB. For all cases except transport-key commands, 30
KeyIdentifier shall be set to ‘00’(that is, a data key). For the case of transport- 31
key commands, KeyIdentifier shall be set to ‘02’ (that is, the key-transport key) 32
when transporting a network key and shall be set to ‘03’ (that is, the key-load 33
key) when transporting an application link key, application master key, or Trust 34
Center master key. See sub-clause 4.5.3 for a description of the key-transport 35
and key-load keys. 36
37
ii If the first attempt fails, then security material shall be obtained by using the
38
nwkActiveKeySeqNumber from the NIB to retrieve the active network key, 39
outgoing frame counter, and sequence number from the 40
nwkSecurityMaterialSet attribute in the NIB. KeyIdentifier shall be set to ‘01’ 41
(that is, the active network key). 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
436 Security Services Specification

2 If KeyIdentifier is 01 (that is, the active network key), the APS layer shall first
verify that the NWK layer is not also applying security. If the NWK layer is 1
applying security, then the APS layer shall not apply any security. The APS 2
layer can determine that the NWK layer is applying security by verifying that 3
the value of the nwkSecureAllFrames attribute of the NIB has a value of TRUE 4
and the nwkSecurityLevel NIB attribute has a non-zero value. 5
6
3 Extract the outgoing frame counter (and, if KeyIdentifier is 01, the key 7
sequence number) from the security material obtained from step 1. If the 8
outgoing frame counter has as its value the 4-octet representation of the integer 9
232-1, or if the key cannot be obtained, security processing shall fail and no 10
further security processing shall be done on this frame. 11
4 Obtain the security level from the nwkSecurityLevel attribute from the NIB. 12
13
5 Construct auxiliary header AuxiliaryHeader (see sub-clause 4.5.1). The 14
security control field shall be set as follows: 15
a The security level sub-field shall be the security level obtained from step 4. 16
17
i The key identifier sub-field shall be set to KeyIdentifier. 18
ii The extended nonce sub-field shall be set to 0. 19
20
b The frame counter field shall be set to the outgoing frame counter from 21
step 3. 22
c If KeyIdentifier is 01, the key sequence number field shall be present and set 23
to the key sequence number from step 3. Otherwise, the key sequence 24
number field shall not be present. 25
26
6 Execute the CCM* mode encryption and authentication operation, as specified 27
in sub-clause A.2, with the following exceptions: 28
a The parameter M shall be obtained from Table 4.38 corresponding to the 29
security level from step 3. 30
31
b The bit string Key shall be the key obtained from step 1. 32
c The nonce N shall be the 13-octet string constructed using the security 33
control and frame counter fields from step 5 and the 64-bit extended address 34
of the local device (see sub-clause 4.5.2.2). 35
36
d If the security level requires encryption, the octet string a shall be the string 37
ApsHeader || AuxiliaryHeader and the octet string m shall be the string 38
Payload. Otherwise, the octet string a shall be the string ApsHeader || 39
AuxiliaryHeader || Payload and the octet string m shall be a string of length 40
zero. 41
7 If the CCM* mode invoked in step 6 outputs “invalid”, security processing 42
shall fail and no further security processing shall be done on this frame. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 437

8 Let c be the output from step 6. If the security level requires encryption, the
secured outgoing frame shall be ApsHeader || AuxiliaryHeader || c, otherwise the 1
secured outgoing frame shall be ApsHeader || AuxiliaryHeader || Payload || c. 2
3
9 If the secured outgoing frame size will result in the MSDU being greater than 4
aMaxMACFrameSize octets (see IEEE Std. 802.15.4 802 [B1]), security 5
processing shall fail and no further security processing shall be done on this 6
frame. 7
10 The outgoing frame counter from step 3 shall be incremented and stored in the 8
appropriate location(s) of the NIB, AIB, and MAC PIB corresponding to the 9
key that was used to protect the outgoing frame. 10
11
11 Over-write the security level sub-field of the security control field with the 3- 12
bit all-zero string '000'. 13
14
4.4.1.2 Security Processing of Incoming Frames 15
If the APS layer receives a secured frame (consisting of a header ApsHeader, 16
auxiliary header AuxiliaryHeader, and payload SecuredPayload) as indicated by 17
the security sub-field of the APS header frame control field it shall perform 18
security processing as follows: 19
20
1 Determine the sequence number SequenceNumber, key identifier KeyIdentifier, 21
and received frame counter value ReceivedFrameCounter from the auxiliary 22
header AuxiliaryHeader. If ReceivedFrameCounter is the 4-octet 23
representation of the integer 232-1, security processing shall fail and no further 24
security processing shall be done on this frame. 25
2 Determine the source address SourceAddress from the address-map table in the 26
NIB, using the source address in the APS frame as the index. If the source 27
address is incomplete or unavailable, security processing shall fail and no 28
further security processing shall be done on this frame. 29
30
3 Obtain the appropriate security material in the following manner. If the security 31
material cannot be obtained, security processing shall fail and no further 32
security processing shall be done on this frame. 33
a If KeyIdentifier is ‘00’ (i.e., a data key), the security material associated with 34
the SourceAddress of the incoming frame shall be obtained from the 35
apsDeviceKeyPairSet attribute in the AIB. 36
37
b If KeyIdentifier is ‘01’ (i.e., a network key), the security material shall be 38
obtained by matching SequenceNumber to the sequence number of any key 39
in the nwkSecurityMaterialSet attribute in the NIB. 40
c If KeyIdentifier is ‘02’ (i.e., a key-transport key), the security material 41
associated with the SourceAddress of the incoming frame shall be obtained 42
from the apsDeviceKeyPairSet attribute in the AIB; the key for this 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
438 Security Services Specification

operation shall be derived from the security material as specified in sub-


clause 4.5.3 for the key-transport key. 1
2
d If KeyIdentifier is ‘03’ (i.e., a key-load key), the security material associated 3
with the SourceAddress of the incoming frame shall be obtained from the 4
apsDeviceKeyPairSet attribute in the AIB and the key for this operation 5
shall be derived from the security material as specified in sub-clause 4.5.3 6
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 sub-field 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 sub- 16
field of the security control field in the AuxiliaryHeader with the value of 17
SecLevel. 18
6 Execute the CCM* mode decryption and authentication checking operation as 19
specified in sub-clause A.3, with the following instantiations: 20
21
a The parameter M shall be obtained from Table 4.38 corresponding to the 22
security level from step 5. 23
b The bit string Key shall be the key obtained from step 3. 24
25
c The nonce N shall be the 13-octet string constructed using the security 26
control and frame counter fields from AuxiliaryHeader, and SourceAddress 27
from step 2 (see sub-clause 4.5.2.2). 28
d Parse the octet string SecuredPayload as Payload1 || Payload2, where the 29
rightmost string Payload2 is an M-octet string. If this operation fails, 30
security processing shall fail and no further security processing shall be done 31
on this frame. 32
33
e If the security level requires encryption, the octet string a shall be the string 34
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
7 Return the results of the CCM* operation: 39
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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 439

b Let m be the output of step 6. If the security level requires encryption, set the
octet string UnsecuredApsFrame to the string ApsHeader || m. Otherwise, 1
set the octet string UnsecuredApsFrame to the string ApsHeader || Payload. 2
3
8 Set FrameCount to (ReceivedFrameCount + 1) and store both FrameCount and 4
SourceAddress in the appropriate security material as obtained in step 3. If 5
storing this frame count and address information will cause the memory 6
allocation for this type of information to be exceeded, and the nwkAllFresh 7
attribute in the NIB is TRUE, then security processing shall fail and no further 8
security processing shall be done on this frame. Otherwise, security processing 9
shall succeed. 10
9 If the sequence number of the received frame belongs to a newer entry in the 11
nwkSecurityMaterialSet then the nwkActiveKeySeqNumber shall be set to 12
received sequence number. 13
14
15
4.4.2 Key-Establishment Services 16
17
The APSME provides services that allow two devices to mutually establish a link 18
key. Initial trust information (for example, a master key) must be installed in each 19
device prior to running the key establishment protocol (see sub-clause 4.4.3 for 20
mechanisms to provision initial trust information). 21
22
4.4.2.1 APSME-ESTABLISH-KEY.request 23
The APSME-ESTABLISH-KEY request primitive is used for initiating a key- 24
establishment protocol. This primitive can be used when there is a need to 25
securely communicate with another device. 26
27
One device will act as an initiator device, and the other device will act as the 28
responder. The initiator shall start the key-establishment protocol by issuing: 29
• The APSME-ESTABLISH-KEY.request with parameters indicating the 30
address of the responder device. 31
32
• An indication of which key-establishment protocol to use (currently SKKE). 33
4.4.2.1.1 Semantics of the Service Primitive 34
35
This primitive shall provide the following interface 36
37
APSME-ESTABLISH-KEY.request {
38
ResponderAddress,
39
UseParent, 40
ResponderParentAddress, 41
KeyEstablishmentMethod 42
} 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
440 Security Services Specification

Table 4.5 specifies the parameters for the APSME-ESTABLISH-KEY.request


primitive. 1
2
Table 4.5 APSME-ESTABLISH-KEY.request Parameters
3
Valid 4
Parameter Name Type Range Description 5
6
Responder-Address Device Any valid The extended 64-bit address of the responder
Address 64-bit device. 7
address 8
9
UseParent Boolean TRUE | This parameter indicates if the responder’s
FALSE parent shall be used to forward messages 10
between the initiator and responder devices: 11
12
TRUE: Use parent
13
FALSE: Do not use parent 14
Responder- Device Any valid If UseParent is TRUE, then the 15
ParentAddress Address 64-bit ResponderParentAddress parameter shall 16
address contain the extended 64-bit address of the 17
responder’s parent device. Otherwise, this 18
parameter is not used and need not be set.
19
KeyEstablishment- Integer 0x00 - The requested key-establishment method shall 20
Method 0x03 be one of the following: 21
0x00 = SKKE method 22
0x01-0x03 = reserved
23
24
25
4.4.2.1.2 When Generated 26
A higher layer on an initiator device shall generate this primitive when it requires 27
a link key to be established with a responder device. If the initiator device wishes 28
to use the responder’s parent as a liaison (for NWK security purposes), it shall set 29
the UseParent parameter to TRUE and shall set the ResponderParentAddress 30
parameter to the 64-bit extended address of the responder’s parent. 31
32
4.4.2.1.3 Effect on Receipt 33
The receipt of an APSME-ESTABLISH_KEY.request primitive, with the 34
KeyEstablishmentMethod parameter equal to SKKE, shall cause the APSME to 35
execute the SKKE protocol, as described in sub-clause 4.4.2.6. The local APSME 36
shall act as the initiator of this protocol, the APSME indicated by the 37
ResponderAddress parameter shall act as the responder of this protocol, and the 38
UseParent parameter will control whether the messages are sent indirectly via the 39
responder’s parent device given by the ResponderParentAddress parameter. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 441

4.4.2.2 APSME-ESTABLISH-KEY.confirm
1
This primitive is issued to the ZDO upon completion or failure of a key- 2
establishment protocol. 3
4
4.4.2.2.1 Semantics of the Service Primitive
5
This primitive shall provide the following interface: 6
7
APSME-ESTABLISH-KEY.confirm { 8
Address, 9
Status 10
} 11
12
Table 4.6 specifies the parameters of the APSME-ESTABLISH-KEY.confirm 13
primitive. Table 4.10 gives a description of some codes that can be returned in the 14
Status parameter of this primitive. In addition to these codes, if, when sending one 15
of the protocol messages, an NLDE-DATA.confirm primitive with a Status 16
parameter set to a value other than SUCCESS is issued, the Status parameter of 17
the APSME-ESTABLISH-KEY.confirm primitive shall be set to that received 18
from the NWK layer. 19
20
Table 4.6 APSME-ESTABLISH-KEY.confirm Parameters
21
Name Type Valid Range Description 22
23
Address Device Any valid 64-bit The extended 64-bit address of the device
24
Address address. with which the key-establishment
protocol was executed. 25
26
Status Enumeration Value given by Table This parameter indicates the final status
27
4.10 or any status value of the key-establishment protocol.
returned from the 28
NLDE-DATA.confirm 29
primitive. 30
31
4.4.2.2.2 When Generated 32
33
The APSME in both the responder and initiator devices shall issue this primitive 34
to the ZDO upon completion of a key-establishment protocol. 35
4.4.2.2.3 Effect on Receipt 36
37
If key establishment is successful, the AIB of the initiator and responder shall be 38
updated with the new link key and the initiator shall be able to securely 39
communicate with the responder. If the key establishment was not successful, then 40
the AIB shall not be changed. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
442 Security Services Specification

4.4.2.3 APSME-ESTABLISH-KEY.indication
1
The APSME in the responder shall issue this primitive to its ZDO when it receives 2
an initial key-establishment message (for example, an SKKE-1 frame) from an 3
initiator. 4
5
4.4.2.3.1 Semantics of the Service Primitive
6
This primitive shall provide the following interface: 7
8
APSME-ESTABLISH-KEY.indication { 9
InitiatorAddress, 10
KeyEstablishmentMethod 11
} 12
13
Table 4.7 specifies the parameters of the APSME-ESTABLISH-KEY.indication 14
primitive. 15
16
Table 4.7 APSME-ESTABLISH-KEY.indication Parameters
17
Name Type Valid Range Description 18
19
InitiatorAddress Device Any valid 64- The extended 64-bit address of the
20
Address bit address initiator device.
21
KeyEstablishmentMethod Integer 0x00 - 0x03 The requested key-establishment 22
method shall be one of the following:
23
0x00 = SKKE method 24
0x01-0x03 = reserved 25
26
4.4.2.3.2 When Generated 27
28
The APSME in the responder device shall issue this primitive to the ZDO when a 29
request to start a key-establishment protocol (for example, an SKKE-1 frame) is 30
received from an initiator device and a master key associated with the initiator is 31
present in the AIB. 32
4.4.2.3.3 Effect on Receipt 33
34
Upon receiving the APSME-ESTABLISH-KEY.indication primitive, the ZDO 35
may use the KeyEstablishmentMethod and InitiatorAddress parameters to 36
determine whether to establish a key with the initiator. The ZDO shall respond 37
using the APSME-ESTABLISH-KEY.response primitive. 38
39
4.4.2.4 APSME-ESTABLISH-KEY.response 40
41
The ZDO of the responder device shall use the APSME-ESTABLISH-
42
KEY.response primitive to respond to an APSME-ESTABLISH-KEY.indication
43
primitive. The ZDO determines whether to continue with the key establishment or
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 443

halt it. This decision is indicated in the Accept parameter of the APSME-
ESTABLISH-KEY.response primitive. 1
2
4.4.2.4.1 Semantics of the Service Primitive 3
This primitive shall provide the following interface: 4
5
APSME-ESTABLISH-KEY.response { 6
InitiatorAddress, 7
Accept 8
} 9
10
Table 4.8 specifies the parameters of the APSME-ESTABLISH-KEY.response 11
primitive. 12
13
Table 4.8 APSME-ESTABLISH-KEY.response Parameters 14
Name Type Valid Range Description 15
16
InitiatorAddress Device Any valid The extended 64-bit address of the device that 17
Address 64-bit address initiated key establishment 18
Accept Boolean TRUE | This parameter indicates the response to an 19
FALSE initiator's request to execute a key- 20
establishment protocol. The response shall be 21
either:
22
TRUE = Accept 23
FALSE = Reject 24
25
4.4.2.4.2 When Generated 26
27
The APSME-ESTABLISH-KEY.response primitive shall be generated by the 28
ZDO and provided to the APSME following a request from an initiator device to 29
start a key-establishment protocol (that is, after receipt of an APSME- 30
ESTABLISH-KEY.indication). This primitive provides the responder's ZDO with 31
an opportunity to determine whether to accept or reject a request to establish a key 32
with a given initiator. 33
In addition to any other criterion for this decision, the responder’s ZDO shall 34
check the permissions configuration table as detailed in sub-clause 4.6.3.8. 35
36
4.4.2.4.3 Effect on Receipt 37
If the Accept parameter is TRUE, then the APSME of the responder will attempt 38
to execute the key establishment protocol indicated by the 39
KeyEstablishmentMethod parameter. If KeyEstablishmentMethod is equal to 40
SKKE, the APSME shall execute the SKKE protocol, described in sub- 41
clause 4.4.2.6. The local APSME shall act as the responder of this protocol and 42
the APSME indicated by the InitiatorAddress parameter shall act as the initiator of 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
444 Security Services Specification

this protocol. If the Accept parameter is FALSE, the local APSME shall halt and
erase all intermediate data pertaining to the pending key-establishment protocol. 1
2
If the UseParent sub-parameter of the TransportKeyData parameter and the 3
nwkSecureAllFrame NIB attribute are both TRUE, the command frame shall be 4
embedded in a tunnel command frame as described in sub-clause 4.6.3.7 and the 5
tunnel command shall be sent in place of the transport key command. 6
7
4.4.2.5 Data Service Message Sequence Chart 8
Figure 4.4 illustrates the sequence of primitives necessary for a successful key 9
establishment between two devices. 10
11
12
Initiator Responder
Device
13
Device
14
15
ZDO APSME APSME ZDO
16
1. APSME-ESTABLISH-KEY.request 2. APSME-ESTABLISH-KEY.indication 17
3. APSME-ESTABLISH-KEY.response
18
SKKE 19
4. APSME-ESTABLISH-KEY.confirm Protocol 5. APSME-ESTABLISH-KEY.confirm 20
21
22
23
Figure 4.4 Sequence Chart for Successful APSME-ESTABLISH- 24
KEY Primitives
25
26
4.4.2.6 The SKKE Protocol 27
The APSME on the initiator and responder execute the symmetric-key key- 28
agreement scheme instantiated in sub-clause B.2.1 and specified in sub-clause 29
B.1. The shared key (as specified in sub-clause B.1 prerequisite step 2), shall be 30
the master key shared between the initiator and responder devices as obtained 31
from the appropriate master key element in the apsDeviceKeyPairSet attribute in 32
the AIB. The messages sent during the scheme specified in sub-clause B.1 shall be 33
assigned to the frame names given in Table 4.9. The formats for these SKKE 34
frames are given in sub-clause 4.4.9.1. The initiator device is responsible for 35
sending the SKKE-1 and SKKE-3 frames and the responder device is responsible 36
for sending the SKKE-2 and SKKE-4 frames. Additionally, if the UseParent 37
parameter of the APSME-ESTABLISH-KEY.request primitive is TRUE, the 38
responder device’s parent (as indicated by the ResponderParentAddress parameter 39
of the APSME-ESTABLISH-KEY.request primitive) shall act as a liaison and 40
forward messages between the initiator and responder devices. 41
42
During the key-establishment scheme, if the responder or initiator device detects 43
any error condition listed in Table 4.10, the scheme shall be aborted and the local 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 445

APSME shall issue the APSME-ESTABLISH-KEY.confirm primitive with the


Status parameter set as indicated in Table 4.10. If no error conditions occur (that 1
is, the key-agreement scheme outputs “valid”), then the initiator and responder 2
shall consider the derived key (that is, KeyData) as their newly shared link key. 3
Both the initiator and responder shall update or add this link key to their AIB, set 4
the corresponding incoming and outgoing frame counts to zero, and issue the 5
APSME-ESTABLISH-KEY.confirm primitive with the Status parameter set to 6
SUCCESS. 7
8
Table 4.9 Mapping of Frame Names to Symmetric-Key Key
Agreement Scheme Messages 9
10
Frame 11
Name Description Reference 12
SKKE-1 Sent by initiator during action step 1 (sub-clause B.7.1) sub-clause 13
4.4.2.6.2 14
15
SKKE-2 Sent by responder during action step 2 (sub-clause B.7.2) sub-clause
4.4.2.6.3 16
17
SKKE-3 Sent by initiator during action step 8 (sub-clause B.7.1) sub-clause 18
4.4.2.6.4
19
SKKE-4 Sent by responder during action step 9 (sub-clause B.7.2) sub-clause 20
4.4.2.6.5 21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
446 Security Services Specification

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 (sub-clause B.7.1)
Responder during action step 3 (sub-clause B.7.2) 11
12
SKG outputs invalid: INVALID_SKG 0x04 13
Initiator during action step 4 (sub-clause B.7.1)
Responder during action step 3 (sub-clause B.7.2) 14
15
MAC transformation outputs invalid: INVALID_MAC 0x05 16
Initiator during action step 8 (sub-clause B.7.1)
Responder during action step 10 (sub-clause B.7.2) 17
18
Tag checking transformation outputs invalid: INVALID_KEY 0x06 19
Initiator during action step 12 (sub-clause B.7.1)
Responder during action step 8 (sub-clause 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.4.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.4.9.1.
32
If the UseParent parameter of 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 of 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
of 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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 447

4.4.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
Otherwise, the APSME shall perform the following steps: 15
If the device does not have a master key corresponding to the initiator address 16
field: 17
18
1 the SKKE-1 frame shall be discarded and the APSME-ESTABLISH- 19
KEY.confirm primitive shall be issued with the Status parameter set to 20
NO_MASTER_KEY (see Table 4.10). The APSME shall halt processing for 21
this SKKE protocol. 22
2 Otherwise, the APSME shall issue an APSME-ESTABLISH-KEY.indication 23
primitive with the InitiatorAddress parameter set to the initiator address field of 24
the SKKE-1 frame and the KeyEstablishmentMethod parameter set to 0 (that 25
is, the SKKE protocol). 26
27
3 After issuing the APSME-ESTABLISH-KEY.indication primitive, and upon 28
receipt of the corresponding APSME-ESTABLISH-KEY.response primitive, 29
the APSME shall evaluate the InitiatorAddress and Accept parameters of the 30
received APSME-ESTABLISH-KEY.response primitive. If the 31
InitiatorAddress parameter is set to the initiator address of the SKKE-1 frame 32
and the Accept parameter set to FALSE, the APSME shall halt the SKKE 33
protocol and discard the SKKE-1 frame. 34
Otherwise: 35
36
1 The device shall construct an SKKE-2 frame as specified in sub-clause 4.4.9.1. 37
If the source of the SKKE-1 frame indicates the same device as the initiator 38
address field of the SKKE-1 frame, the device shall send this SKKE-2 frame 39
directly to the initiator device using the NLDE-DATA.request primitive, with 40
the DestAddr parameter set to the source of the SKKE-1 frame, the 41
DiscoverRoute parameter set to 0x01, and the SecurityEnable parameter set to 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
448 Security Services Specification

TRUE. Otherwise, the device shall send the SKKE-2 frame to its parent using
the NLDE-DATA.request primitive, with the DiscoverRoute parameter set to 1
0x01, and the SecurityEnable parameter set to FALSE. 2
3
4.4.2.6.3 On Receipt of the SKKE-2 Frame 4
If the initiator address field of the SKKE-2 frame does not equal the local device 5
address, the APSME shall perform the following steps: 6
7
1 If the device indicated by the responder address field is not a child of the local 8
device, the SKKE-2 frame shall be discarded. 9
2 Otherwise, the device shall send the SKKE-2 frame to the initiator device using 10
the NLDE-DATA.request primitive with NWK layer set to the default level. 11
12
Otherwise, the device shall construct an SKKE-3 frame as specified in sub- 13
clause 4.4.9.1. If the source of the SKKE-2 frame is the same as the responder 14
address field of the SKKE-2 frame, the device shall send this SKKE-3 frame 15
directly to the responder device. Otherwise, the device shall send the SKKE-3 16
frame to the responder’s parent. The SKKE-3 frame shall be sent using the 17
NLDE-DATA.request primitive with NWK layer security set to the default NWK 18
layer security level. 19
4.4.2.6.4 On Receipt of the SKKE-3 Frame 20
21
If the responder address field of the SKKE-3 frame does not equal the local device 22
address, the APSME shall perform the following steps: 23
1 If the responder address field of the SKKE-3 frame does not equal the local 24
device address, the APSME shall perform the following steps: 25
26
i If the device given by the responder address field is not a child of the local 27
device, the SKKE-3 frame shall be discarded. 28
ii Otherwise, the device shall send the SKKE-3 to the responder device using the 29
NLDE-DATA.request primitive with NWK layer security disabled. 30
31
iii Otherwise, the device shall process the SKKE-3 data field and if the protocol 32
was not a success it shall issue an APSME-ESTABLISH-KEY.confirm 33
primitive with the Address parameter set to the initiator’s address and the 34
Status parameter set appropriately. 35
2 If, from the device’s perspective, the protocol was a success, the device shall 36
construct an SKKE-4 frame as specified in sub-clause 4.4.9.1. If the source of 37
the SKKE-3 frame is the same as the initiator address field of the SKKE-3 38
frame, the device shall send this SKKE-4 frame directly to the initiator device 39
using the NLDE-DATA.request primitive with NWK layer security set to the 40
default level. Otherwise, the device shall send the SKKE-4 frame to its parent 41
using the NLDE-DATA.request primitive with NWK layer security disabled. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 449

Finally, the device shall issue an APSME-ESTABLISH-KEY.confirm


primitive with the Address parameter set the initiator’s address and the Status 1
parameter set to success. 2
3
4.4.2.6.5 On Receipt of the SKKE-4 Frame 4
If the initiator address field of the SKKE-4 frame does not equal the local device 5
address, the APSME shall perform the following steps: 6
7
1 If the device given by the responder address field is not a child of the local 8
device, the SKKE-4 frame shall be discarded. 9
2 Otherwise, the APSME of the local device shall send the SKKE-4 frame to the 10
initiator device using the NLDE-DATA.request primitive with NWK layer set 11
to the default level. 12
13
Otherwise, the APSME shall process the SKKE-4 frame and issue an APSME- 14
ESTABLISH-KEY.confirm primitive with the Address parameter set to the 15
responder’s address and the Status parameter set appropriately. 16
17
4.4.3 Transport-Key Services 18
19
The APSME provides services that allow an initiator to transport keying material 20
to a responder. The different types of keying material that can be transported are 21
shown in Tables 4.12 to 4.15. 22
23
4.4.3.1 APSME-TRANSPORT-KEY.request 24
25
The APSME-TRANSPORT-KEY.request primitive is used for transporting a key 26
to another device. 27
4.4.3.1.1 Semantics of the Service Primitive 28
29
This primitive shall provide the following interface: 30
31
APSME-TRANSPORT-KEY.request {
32
DestAddress, 33
KeyType, 34
TransportKeyData 35
} 36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
450 Security Services Specification

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 – 0x06 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.13 14
KeyType = 0x01 see Table 4.14 15
KeyType = 0x02 see Table 4.15 16
KeyType = 0x03 see Table 4.15 17
KeyType = 0x04 see Table 4.13 18
KeyType = 0x05 see Table 4.14 19
20
21
22
Table 4.12 KeyType Parameter of the Transport-Key Primitive 23
24
Enumeration Value Description
25
Trust-center 0x00 Indicates the key is a master key used to set up link keys between 26
master key the Trust Center and another device. 27
Standard network 0x01 Indicates that the key is a network key to be used in standard 28
key security mode and may be distributed using key-transport or a 29
standard network key. 30
Application master 0x02 Indicates the key is a master key used to set up link keys between 31
key two devices. 32
Application link 0x03 Indicates the key is a link key used as a basis of security between
33
key two devices. 34
35
Trust-center link 0x04 Indicates that the key is a link key used as a basis for security
key between the Trust Center and another device.
36
37
High-security 0x05 Indicates that the key is a network key to be used in high security 38
network key mode and may be distributed using key-transport only.
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 451

1
Table 4.13 TransportKeyData Parameter for a Trust
Center Master Key or Link Key 2
3
Parameter 4
Name Type Valid Range Description 5
ParentAddress Device Any valid The extended 64-bit address of the parent 6
address 64-bit address of the destination device given by the 7
DestAddress parameter. 8
Key Set of 16 Variable The Trust Center master or link key. 9
octets 10
11
12
13
Table 4.14 TransportKeyData Parameter for a Network Key 14
Parameter Valid 15
Name Type Range Description 16
17
KeySeqNumber Octet 0x00-0xFF A sequence number assigned to a network key by 18
the Trust Center and used to distinguish network
keys for purposes of key updates and incoming 19
frame security operations. 20
21
NetworkKey Set of Variable The network key.
16
22
octets 23
24
UseParent Boolean TRUE | This parameter indicates if the destination device’s
25
FALSE parent shall be used to forward the key to the
destination device: 26
27
TRUE = Use parent
28
FALSE = Do not use parent 29
ParentAddress Device Any valid If the UseParent is TRUE, then ParentAddress 30
address 64-bit parameter shall contain the extended 64-bit address 31
address of the destination device’s parent device; 32
otherwise, this parameter is not used and need not 33
be set.
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
452 Security Services Specification

1
Table 4.15 TransportKeyData Parameter for an Application Master or Link Key
2
Parameter 3
Name Type Valid Range Description 4
5
PartnerAddress Device Any valid The extended 64-bit address of the device that
address 64-bit address was also sent this master key. 6
7
Initiator Boolean TRUE | This parameter indicates if the destination 8
FALSE device of this master key requested it:
9
TRUE = If the destination requested the key 10
FALSE = Otherwise 11
12
Key Set of 16 Variable The master or link key (as indicated by the
octets KeyType parameter). 13
14
15
4.4.3.1.2 When Generated 16
The ZDO on an initiator device shall generate this primitive when it requires a key 17
to be transported to a responder device. 18
19
4.4.3.1.3 Effect on Receipt 20
The receipt of an APSME-TRANSPORT-KEY.request primitive shall cause the 21
APSME to create a transport-key command packet (see sub-clause 4.4.9.2). 22
23
If the KeyType parameter is 0x00 or 0x04 (that is, Trust Center master or link 24
key), the key descriptor field of the transport-key command shall be set as 25
follows: 26
• The key sub-field shall be set to the Key sub-parameter of the 27
TransportKeyData parameter. 28
29
• The destination address sub-field shall be set to the DestinationAddress 30
parameter. 31
• The source address sub-field shall be set to the local device address. 32
33
This command frame shall be security-protected as specified in sub- 34
clause 4.4.1.1. Then, if security processing succeeds, it is sent to the device 35
specified by the ParentAddress sub-parameter of the TransportKeyData parameter 36
by issuing a NLDE-DATA.request primitive. 37
If the DestinationAddress parameter is all zeros, the secured command frame shall 38
be unicast to any and all rx-off-when-idle children of the device. These unicasts 39
shall be repeated until successful, or a subsequent APSME-TRANSPORT- 40
KEY.request primitive with the KeyType parameter equal to 0x01 or 0x05 has 41
been received, or a period of twice the recommended maximum polling interval 42
has passed. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 453

If the KeyType parameter is 0x01 or 0x05 (that is, a network key), the key
descriptor field of the transport-key command shall be set as follows: 1
2
• The key sub-field shall be set to the Key sub-parameter of the 3
TransportKeyData parameter. 4
• The sequence number sub-field shall be set to the KeySeqNumber sub- 5
parameter of the TransportKeyData parameter. 6
7
• The destination address sub-field shall be set to the DestinationAddress 8
parameter. 9
• The source address sub-field shall be set to the local device address. 10
11
This command frame shall be security-protected as specified in sub-clause 4.4.1.1 12
and then, if security processing succeeds, sent to the device specified by the 13
ParentAddress sub-parameter of the TransportKeyData parameter (if the 14
UseParent sub-parameter of the TransportKeyData parameter is TRUE) or the 15
DestinationAddress parameter (if the UseParent sub-parameter of the 16
TransportKeyData parameter is FALSE) by issuing a NLDE-DATA.request 17
primitive. 18
If the UseParent sub-parameter of the TransportKeyData parameter is FALSE, 19
and there is an entry in nwkNeighborTable whose extended address matches the 20
SenderAddress parameter and whose relationship field has value 0x05 21
(unauthenticated child), then the relationship field in that entry shall be set to the 22
value 0x01 (child). 23
24
If the KeyType parameter is 0x02 or 0x03 (that is, an application master or link 25
key), the key descriptor field of the transport-key command shall be set as 26
follows: 27
• The key sub-field shall be set to the Key sub-parameter of the 28
TransportKeyData parameter. 29
30
• The partner address sub-field shall be set to the PartnerAddress sub-parameter 31
of the TransportKeyData parameter. 32
• The initiator sub-field shall be set 1 (if the Initiator sub-parameter of the 33
TransportKeyData parameter is TRUE) or 0 (if the Initiator sub-parameter of 34
the TransportKeyData parameter is FALSE). 35
36
This command frame shall be security-protected as specified in sub-clause 4.4.1.1 37
and then, if security processing succeeds, sent to the device specified by the 38
DestinationAddress parameter by issuing a NLDE-DATA.request primitive. 39
40
4.4.3.2 APSME-TRANSPORT-KEY.indication 41
The APSME-TRANSPORT-KEY.indication primitive is used to inform the ZDO 42
of the receipt of keying material. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
454 Security Services Specification

4.4.3.2.1 Semantics of the Service Primitive


1
This primitive shall provide the following interface: 2
APSME-TRANSPORT-KEY.indication {
3
4
SrcAddress,
5
KeyType,
6
TransportKeyData 7
} 8
9
Table 4.16 specifies the parameters of the APSME-TRANSPORT-KEY.indication 10
primitive. 11
Table 4.16 APSME-TRANSPORT-KEY.indication Parameters 12
13
Name Type Valid Range Description 14
15
SrcAddress Device Any valid 64- The extended 64-bit address of the device
Address bit address that is the original source of the transported 16
key. 17
18
KeyType Octet 0x00 – 0x06 Identifies the type of key material that was be
transported; see Table 4.12. 19
20
TransportKeyData Variable Variable The key that was transported along with 21
identification and usage parameters. The type
of this parameter depends on the KeyType 22
parameter as follows: 23
24
KeyType = 0x00 see Table 4.17
25
KeyType = 0x01 see Table 4.18
26
KeyType = 0x02 see Table 4.20 27
KeyType = 0x03 see Table 4.20 28
KeyType = 0x04 see Table 4.17 29
KeyType = 0x05 see Table 4.18 30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 455

Table 4.17 TransportKeyData Parameter for a Trust Center Master or Link Key 1
Parameter Name Type Valid Range Description 2
3
TrustCenter- Set of 16 Variable The Trust Center master key. 4
MasterKey octets 5
6
7
Table 4.18 TransportKeyData Parameter for a Network Key
8
Parameter 9
Name Type Valid Range Description 10
11
KeySeqNumber Octet 0x00-0xFF A sequence number assigned to a network key
by the Trust Center and used to distinguish; 12
network keys for purposes of key updates and 13
incoming frame security operations. 14
NetworkKey Set of 16 Variable The network key. 15
octets 16
17
18
19
Table 4.19 TransportKeyData Parameter for an Application Master or Link Key 20
Valid 21
Parameter Name Type Range Description 22
23
PartnerAddress Device Any valid The extended 64-bit address 24
address 64-bit of the device that was also
address sent this master key.
25
26
Key Set of 16 Variable The master or link key (as 27
octets indicated by the KeyType
28
parameter).
29
30
4.4.3.2.2 When Generated 31
The APSME shall generate this primitive when it receives a transport-key 32
command as specified in sub-clause 4.4.3.3. 33
34
4.4.3.2.3 Effect on Receipt 35
Upon receipt of this primitive, the ZDO is informed of the receipt of the keying 36
material. 37
38
4.4.3.3 Upon Receipt of a Transport-Key Command 39
40
Upon receipt of a transport-key command, the APSME shall execute security 41
processing as specified in, then check the key type sub-field. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
456 Security Services Specification

Upon receipt of a secured transport-key command, the APSME shall check the
key type sub-field. If the key type field is set to 0x02, 0x03, 0x04, or 0x05 (that is, 1
application link or master key, Trust Center link key, or high-security network 2
key) and the command was not secured using a Trust Center link key, the 3
command shall be discarded. If the key type field is set to 0x01 (that is, standard 4
network key) and the command was not secured using a Trust Center link key or 5
the active network key, the command shall be discarded. 6
7
If the key type field is set to 0x02 or 0x03 (that is, application link or master key), 8
the APSME shall issue the APSME-TRANSPORT-KEY.indication primitive 9
with: the SrcAddress parameter set to the source of the key-transport command 10
(as indicated by the NLDE-DATA.indication SrcAddress parameter), and the 11
KeyType parameter set to the key type field. The TransportKeyData parameter 12
shall be set as follows: 13
• The Key sub-parameter shall be set to the key field. 14
15
• The PartnerAddress sub-parameter shall be set to the partner address field. 16
• The Initiator parameter shall be set to TRUE, if the initiator field is 1. 17
Otherwise it shall be set to 0. 18
19
If the key type field is set to 0x00, 0x01, 0x04, or 0x05 (that is, Trust Center 20
master or link key, or a network key) and the destination field is equal to the local 21
address, or if the key type field is set to 0x01 (that is, a standard network key), the 22
destination field is the all-zero string, and the current network key type is equal to 23
the value of the key type field, the APSME shall issue the APSME-TRANSPORT- 24
KEY.indication primitive with the SrcAddress parameter set to the source address 25
field of the key-transport command and the KeyType parameter set to the key type 26
field. The TransportKeyData parameter shall be set as follows: the Key sub- 27
parameter shall be set to the key field and, in the case of a network key (that is, the 28
key type field is set to 0x01 or 0x05), the KeySeqNumber sub-parameter shall be 29
set to the sequence number field. 30
If the key type field is set to 0x00 or 0x01 (that is, Trust Center master or link key 31
or standard network key) and the destination address field is not equal to the local 32
address, the APSME shall send the command to the address indicated by the 33
destination address field by issuing the NLDE-DATA.request primitive with 34
security disabled. 35
36
If the key type field is set to 0x01 (that is, the standard network key) and there is 37
an entry in nwkNeighborTable whose extended address matches value of the 38
destination address field and whose relationship field has value 0x05 39
(unauthenticated child), then the relationship field in that entry shall be set to the 40
value 0x01 (child). 41
Upon receipt of a secured transport-key command with the key type field set to 42
0x01, if the destination field is all zeros and the source address field is set to the 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 457

value of apsTrustCenterAddress, the router shall attempt to unicast this transport-


key command to any and all rx-off-when-idle children. The router shall continue 1
to do so until successful, or until a subsequent transport-key command with the 2
key type field set to 0x01 or 0x05 has been received, or until a period of twice the 3
recommended maximum polling interval has passed. 4
5
Upon receipt of an unsecured transport-key command, the APSME shall check 6
the key type sub-field. If the key type field is set to 0x00 (that is, a Trust Center 7
master key), the destination address field is equal to the local address, and the 8
device does not have a Trust Center master key and address (i.e., the 9
apsTrustCenterAddress in the AIB), then the APSME shall issue the APSME- 10
TRANSPORT-KEY.indication primitive. If the key type field is set to 0x01 or 11
0x05 (that is, a network key), the destination address field is equal to the local 12
address, and the device does not have a network key, then the APSME shall issue 13
the APSME-TRANSPORT-KEY.indication primitive. If the key type field is set to 14
0x04 (i.e., the Trust Center link key), the destination address field is equal to the 15
local address, and the device does not have a Trust Center link key, then the 16
APSME shall issue the APSME-TRANSPORT-KEY.indication primitive. If an 17
APSME-TRANSPORT-KEY.indication primitive is issued, the SrcAddress 18
parameter shall be set to the source address field of the key-transport command, 19
and the KeyType parameter shall be set to the key type field. The 20
TransportKeyData parameter shall be set as follows: the Key sub-parameter shall 21
be set to the key field and, in the case of a network key (that is, the key type field 22
is set to 0x01 or 0x05), the KeySeqNumber sub-parameter shall be set to the 23
sequence number field. 24
25
4.4.4 Update Device Services 26
27
The APSME provides services that allow a device (for example, a router) to 28
inform another device (for example, a Trust Center) that a third device has 29
changed its status (for example, joined or left the network). 30
31
4.4.4.1 APSME-UPDATE-DEVICE.request 32
33
The ZDO shall issue this primitive when it wants to inform a device (for example, 34
a Trust Center) that another device has a status that needs to be updated (for 35
example, the device joined or left the network). 36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
458 Security Services Specification

4.4.4.1.1 Semantics of the Service Primitive


1
This primitive shall provide the following interface: 2
APSME-UPDATE-DEVICE.request {
3
4
DestAddress,
5
DeviceAddress,
6
Status, 7
DeviceShortAddress 8
} 9
10
Table 4.20 specifies the parameters for the APSME-UPDATE-DEVICE.request 11
primitive. 12
13
Table 4.20 APSME-UPDATE-DEVICE.request Parameters
14
Parameter 15
Name Type Valid Range Description 16
DestAddress Device Any valid The extended 64-bit address of the device 17
Address 64-bit address that shall be sent the update information. 18
19
DeviceAddress Device Any valid The extended 64-bit address of the device
Address 64-bit address whose status is being updated. 20
21
Status Integer 0x00 – 0x07 Indicates the updated status of the device 22
given by the DeviceAddress parameter:
23
0x00 = Standard device secured rejoin 24
0x01 = Standard device unsecured join 25
0x02 = Device left 26
0x03 = Standard device unsecured rejoin 27
0x04 = High security device secured rejoin 28
0x05 = High security device unsecured join 29
0x06 = Reserved
30
31
0x07 = High security device unsecured
rejoin 32
33
DeviceShortAd Network 0x0000 - 0xffff The 16-bit network address of the device 34
dress address whose status is being updated.
35
36
4.4.4.1.2 When Generated 37
The ZDO (for example, on a router or ZigBee coordinator) shall initiate the 38
APSME-UPDATE-DEVICE.request primitive when it wants to send updated 39
device information to another device (for example, the Trust Center). 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 459

4.4.4.1.3 Effect on Receipt


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.4.9.3). The 3
device address field of this command frame shall be set to the DeviceAddress 4
parameter, the status field shall be set according to the Status parameter, and the 5
device short address field shall be set to the DeviceShortAddress parameter. This 6
command frame shall be security-protected as specified in sub-clause 4.4.1.1 and 7
then, if security processing succeeds, sent to the device specified in the 8
DestAddress parameter by issuing a NLDE-DATA.request primitive. 9
10
4.4.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
4.4.4.2.1 Semantics of the Service Primitive 15
16
This primitive shall provide the following interface:
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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
460 Security Services Specification

Table 4.21 specifies the parameters for the APSME-UPDATE-


DEVICE.indication primitive. 1
2
Table 4.21 APSME-UPDATE-DEVICE.indication Parameters
3
Parameter Name Type Valid Range Description 4
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 Integer 0x00 – 0x07 Indicates the updated status of the device 11
given by the DeviceAddress parameter: 12
0x00 = Standard device secured rejoin 13
0x01 = Standard device unsecured join 14
15
0x02 = Device left 16
0x03 = Standard device unsecured rejoin 17
0x04 = High security device secured 18
rejoin 19
20
0x05 = High security device unsecured
join 21
22
0x06 = Reserved 23
0x07 = High security device unsecured 24
rejoin 25
DeviceShortAddress Network 0x0000-0xffff The 16-bit network address of the device 26
Address whose status is being updated. 27
28
4.4.4.2.2 When Generated 29
30
The APSME shall generate this primitive when it receives an update-device 31
command frame that is successfully decrypted and authenticated, as specified in 32
sub-clause 4.4.1.2. 33
4.4.4.2.3 Effect on Receipt 34
35
Upon receipt of the APSME-UPDATE-DEVICE.indication primitive, the ZDO 36
will be informed that the device referenced by the DeviceAddress parameter has 37
undergone a status update according to the Status parameter. 38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 461

4.4.5 Remove Device Services 1


2
The APSME provides services that allow a device (for example, a Trust Center) to
3
inform another device (for example, a router) that one of its children should be
4
removed from the network.
5
4.4.5.1 APSME-REMOVE-DEVICE.request 6
7
The ZDO of a device (for example, a Trust Center) shall issue this primitive when 8
it wants to request that a parent device (for example, a router) remove one of its 9
children from the network. For example, a Trust Center can use this primitive to 10
remove a child device that fails to authenticate properly. 11
12
4.4.5.1.1 Semantics of the Service Primitive 13
This primitive shall provide the following interface: 14
15
APSME-REMOVE-DEVICE.request { 16
ParentAddress, 17
ChildAddress 18
} 19
20
Table 4.22 specifies the parameters for the APSME-REMOVE-DEVICE.request 21
primitive. 22
23
Table 4.22 APSME-REMOVE-DEVICE.request Parameters
24
Parameter 25
Name Type Valid Range Description 26
27
ParentAddress Device Any valid The extended 64-bit address of the device
Address 64-bit address that is the parent of the child device that is 28
requested to be removed. 29
30
ChildAddress Device Any valid The extended 64-bit address of the child
Address 64-bit address device that is requested to be removed. 31
32
33
4.4.5.1.2 When Generated 34
The ZDO (for example, on a Trust Center) shall initiate the APSME-REMOVE- 35
DEVICE.request primitive when it wants to request that a parent device (specified 36
by the ParentAddress parameter) remove one of its child devices (as specified by 37
the ChildAddress parameter). 38
39
4.4.5.1.3 Effect on Receipt 40
Upon receipt of the APSME-REMOVE-DEVICE.request primitive the device 41
shall first create a remove-device command frame (see sub-clause 4.4.9.3). The 42
child address field of this command frame shall be set to the ChildAddress 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
462 Security Services Specification

parameter. This command frame shall be security-protected as specified in sub-


clause 4.4.1.1 and then, if security processing succeeds, sent to the device 1
specified by the ParentAddress parameter by issuing a NLDE-DATA.request 2
primitive. 3
4
4.4.5.2 APSME-REMOVE-DEVICE.indication 5
6
The APSME shall issue this primitive to inform the ZDO that it received a 7
remove-device command frame. 8
4.4.5.2.1 Semantics of the Service Primitive 9
10
This primitive shall provide the following interface: 11
12
APSME-REMOVE-DEVICE.indication {
13
SrcAddress,
14
ChildAddress 15
} 16
17
Table 4.23 specifies the parameters for the APSME-REMOVE- 18
DEVICE.indication primitive. 19
Table 4.23 APSME-REMOVE-DEVICE.indication Parameters 20
21
Parameter 22
Name Type Valid Range Description 23
SrcAddress Device Any valid The extended 64-bit address of the device 24
Address 64-bit address requesting that a child device be removed. 25
26
ChildAddress Device Any valid The extended 64-bit address of the child
Address 64-bit address device that is requested to be removed. 27
28
29
4.4.5.2.2 When Generated
30
The APSME shall generate this primitive when it receives a remove-device 31
command frame that is successfully decrypted and authenticated, as specified in 32
sub-clause 4.4.1.2. 33
34
4.4.5.2.3 Effect on Receipt 35
Upon receipt of the APSME-REMOVE-DEVICE.indication primitive the ZDO 36
shall be informed that the device referenced by the SrcAddress parameter is 37
requesting that the child device referenced by the ChildAddress parameter be 38
removed from the network. 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 463

4.4.6 Request Key Services 1


2
The APSME provides services that allow a device to request the active network
3
key or a master key from another device (for example, its Trust Center).
4
4.4.6.1 APSME-REQUEST-KEY.request 5
6
This primitive allows the ZDO to request either the active network key or a new 7
end-to-end application key (master or link). 8
9
4.4.6.1.1 Semantics of the Service Primitive 10
This primitive shall provide the following interface: 11
12
APSME-REQUEST-KEY.request { 13
DestAddress, 14
KeyType, 15
PartnerAddress 16
} 17
18
Table 4.24 specifies the parameters for the APSME-REQUEST-KEY.request 19
primitive. 20
21
Table 4.24 APSME-REQUEST-KEY.request Parameters 22
Parameter 23
Name Type Valid Range Description 24
25
DestAddress Device Any valid 64-bit The extended 64-bit address of the
26
Address address device to which the request-key
command should be sent. 27
28
KeyType Octet 0x00-0xFF The type of key being requested:
29
0x01 = Network key 30
0x02 = Application key 31
0x00 and 0x03-0xFF = Reserved 32
33
PartnerAddress Device Any valid 64-bit If the KeyType parameter indicates an
Address address application key, this parameter shall 34
indicate an extended 64-bit address of a 35
device that shall receive the same key as 36
the device requesting the key. 37
38
4.4.6.1.2 When Generated 39
40
The ZDO of a device shall generate the APSME-REQUEST-KEY.request 41
primitive when it requires either the active network key or a new end-to-end 42
application key (master or link). 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
464 Security Services Specification

4.4.6.1.3 Effect on Receipt


1
Upon receipt of the APSME-REQUEST-KEY.request primitive, the device shall 2
first create a request-key command frame (see sub-clause 4.4.9.5). The key type 3
field of this command frame shall be set to the same value as the KeyType 4
parameter. If the KeyType parameter is 0x02 (that is, an application key), then the 5
partner address field of this command frame shall be the PartnerAddress 6
parameter. Otherwise, the partner address field of this command frame shall not 7
be present. 8
This command frame shall be security-protected as specified in sub-clause 4.4.1.1 9
and then, if security processing succeeds, sent to the device specified by the 10
DestAddress parameter by issuing a NLDE-DATA.request primitive. 11
12
4.4.6.2 APSME-REQUEST-KEY.indication 13
14
The APSME shall issue this primitive to inform the ZDO that it received a 15
request-key command frame. 16
4.4.6.2.1 Semantics of the Service Primitive 17
18
This primitive shall provide the following interface: 19
20
APSME-REQUEST-KEY.indication {
21
SrcAddress, 22
KeyType, 23
PartnerAddress 24
} 25
26
Table 4.25 specifies the parameters for the APSME-REQUEST-KEY.indication 27
primitive. 28
29
Table 4.25 APSME-REQUEST-KEY.indication Parameters
30
Parameter 31
Name Type Valid Range Description 32
33
SrcAddress Device Any valid 64-bit The extended 64-bit address of the device
Address address that sent the request-key command. 34
35
KeyType Octet 0x00-0xFF The type of key being requested:
36
0x01 = Network key 37
0x02 = Application key 38
0x00 and 0x03-0xFF = Reserved 39
40
PartnerAddress Device Any valid 64-bit If the KeyType parameter indicates an
Address address application key, this parameter shall indicate 41
an extended 64-bit address of a device that 42
shall receive the same key as the device 43
requesting the key. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 465

4.4.6.2.2 When Generated


1
The APSME shall generate this primitive when it receives a request-key 2
command frame that is successfully decrypted and authenticated, as specified in 3
sub-clause 4.4.1.2. 4
4.4.6.2.3 Effect on Receipt 5
6
Upon receipt of the APSME-REQUEST-KEY.indication primitive, the ZDO shall 7
be informed that the device referenced by the SrcAddress parameter is requesting 8
a key. The type of key being requested shall be indicated by the KeyType 9
parameter and if the KeyType parameter is 0x02 (that is, an application key), the 10
PartnerAddress parameter shall indicate a partner device which shall receive the 11
same key as the device requesting the key (that is, the device indicated by the 12
SrcAddress parameter). 13
14
4.4.7 Switch Key Services 15
16
The APSME provides services that allow a device (for example, the Trust Center) 17
to inform another device that it should switch to a new active network key. 18
19
4.4.7.1 APSME-SWITCH-KEY.request 20
21
This primitive allows a device (for example, the Trust Center) to request that 22
another device switch to a new active network key. 23
24
4.4.7.1.1 Semantics of the Service Primitive
25
This primitive shall provide the following interface: 26
27
APSME-SWITCH-KEY.request { 28
DestAddress, 29
KeySeqNumber 30
} 31
32
Table 4.26 specifies the parameters for the APSME-SWITCH-KEY.request 33
primitive. 34
35
Table 4.26 APSME-SWITCH-KEY.request Parameters
36
Parameter Valid 37
Name Type Range Description 38
39
DestAddress Device Any valid The extended 64-bit address of the device to
Address 64-bit address which the switch-key command is sent. 40
41
KeySeqNumber Octet 0x00-0xFF A sequence number assigned to a network
42
key by the Trust Center and used to
distinguish network keys. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
466 Security Services Specification

4.4.7.1.2 When Generated


1
The ZDO of a device (for example, the Trust Center) shall generate the APSME- 2
SWITCH-KEY.request primitive when it wants to inform a device to switch to a 3
new active network key. 4
4.4.7.1.3 Effect on Receipt 5
6
Upon receipt of the APSME-SWITCH-KEY.request primitive, the device shall 7
first create a switch-key command frame (see sub-clause 4.4.9.6). The sequence 8
number field of this command frame shall be set to the same value as the 9
KeySeqNumber parameter. 10
This command frame shall be security-protected as specified in sub-clause 4.4.1.1 11
and then, if security processing succeeds, sent to the device specified by the 12
DestAddress parameter by issuing a NLDE-DATA.request primitive. 13
14
4.4.7.2 APSME-SWITCH-KEY.indication 15
16
The APSME shall issue this primitive to inform the ZDO that it received a switch- 17
key command frame. 18
19
4.4.7.2.1 Semantics of the Service Primitive
20
This primitive shall provide the following interface: 21
22
APSME-SWITCH-KEY.indication { 23
SrcAddress, 24
KeySeqNumber 25
} 26
27
Table 4.27 specifies the parameters for the APSME-SWITCH-KEY.indication 28
primitive. 29
30
Table 4.27 APSME-SWITCH-KEY.indication Parameters
31
Valid 32
Parameter Name Type Range Description 33
34
SrcAddress Device Any valid The extended 64-bit address of the device
Address 64-bit that sent the switch-key command. 35
address 36
37
KeySeqNumber Octet 0x00- A sequence number assigned to a network
0xFF key by the Trust Center and used to 38
distinguish network keys. 39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 467

4.4.7.2.2 When Generated


1
The APSME shall generate this primitive when it receives a switch-key command 2
frame that is successfully decrypted and authenticated, as specified in sub- 3
clause 4.4.1.2. 4
4.4.7.2.3 Effect on Receipt 5
6
Upon receipt of the APSME-SWITCH-KEY.indication primitive the ZDO shall 7
be informed that the device referenced by the SrcAddress parameter is requesting 8
that the network key referenced by the KeySeqNumber parameter become the 9
new active network key. 10
11
4.4.7.3 Secured APDU Frame 12
13
The APS layer frame format consists of APS header and APS payload fields (see
14
Figure 2.4.) The APS header consists of frame control and addressing fields.
15
When security is applied to an APDU frame, the security bit in the APS frame
16
control field shall be set to 1 to indicate the presence of the auxiliary frame header.
17
The format for the auxiliary frame header is given in sub-clause 4.5.1. The format
18
of a secured APS layer frame is shown in Figure 4.5. The auxiliary frame header
19
is situated between the APS header and payload fields.
20
Octets: Variable 5 or 6 Variable 21
22
Original APS header Auxiliary Encrypted payload Encrypted message 23
([B7], clause 7.1) frame integrity code (MIC)
header
24
Secure frame payload = output of CCM* 25
Full APS header Secured APS payload 26
27
Figure 4.5 Secured APS Layer Frame Format 28
29
4.4.8 Entity Authentication Services 30
31
The APSME provides services that allow two devices to mutually authenticate 32
each other. The process authenticates the originator of the data by using a random 33
challenge with a response based on a pre-shared secret, in this case, a key. It also 34
allows optional authenticated data transfer. 35
36
4.4.8.1 APSME-AUTHENTICATE.request 37
38
The APSME-AUTHENTICATE.request primitive is used for initiating entity 39
authentication or responding to an entity authentication initiated by another 40
device. This primitive can be used when there is a need to authenticate another 41
device without using frame security. The protocol confirms authenticity based on 42
the two devices sharing a pre-shared key. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
468 Security Services Specification

4.4.8.1.1 Semantics of the Service Primitive


1
This primitive shall provide the following interface: 2
APSME-AUTHENTICATE.request {
3
4
PartnerAddress,
5
Action,
6
RandomChallenge 7
} 8
9
Table 4.28 specifies the parameters for the APSME-AUTHENTICATE.request 10
primitive. 11
Table 4.28 APSME-AUTHENTICATE.request Parameter 12
13
Parameter Name Type Valid Range Description 14
15
PartnerAddress DevAddress Any valid 64-bit The extended, 64-bit IEEE address
address of the counterpart device in the 16
entity authentication request. 17
18
Action Enumeration INITIATE, Indicates the action required. See
RESPOND_AC Table 4.29. 19
CEPT, 20
RESPOND_REJ 21
ECT 22
RandomChallenge Set of 16 - The 16-octet random challenge 23
octets originally received from the 24
initiator. This parameter is only 25
valid if the Action parameter is 26
equal to RESPOND_ACCEPT.
27
28
29
Table 4.29 Action Parameter Enumeration 30
31
Enumeration Value Description 32
INITIATE 0x00 Initiate the entity authentication. 33
34
RESPOND_ACCEPT 0x01 Respond to the entity authentication request, accepting it. 35
RESPOND_REJECT 0x02 Respond to the entity authentication request, rejecting it. 36
37
4.4.8.1.2 When Generated 38
39
The ZDO on an initiator or responder device will generate this primitive when it 40
needs to initiate or respond to entity authentication. If the ZDO is responding to an 41
APSME-AUTHENTICATE.indication primitive, it will set the RandomChallenge 42
parameter to the corresponding RandomChallenge parameter in the indication. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 469

4.4.8.1.3 Effect on Receipt


1
The receipt of an APSME-AUTHENTICATE.request primitive with the Action 2
parameter set to INITIATE shall cause the APSME to initiate the mutual entity 3
authentication protocol, described in clause 4.4.8.5. The local APSME shall act as 4
the initiator of this protocol and the APSME indicated by the PartnerAddress 5
parameter shall act as the responder of this protocol. 6
The receipt of an APSME-AUTHENTICATE.request primitive with the Action 7
parameter set to RESPOND_ACCEPT shall cause the APSME to participate in 8
the response of the mutual entity authentication protocol, described in 9
clause 4.4.8.5. The local APSME shall act as the responder of this protocol and 10
the APSME indicated by the PartnerAddress parameter shall act as the initiator of 11
this protocol. If the Action parameter is set to RESPOND_REJECT, the entity 12
authentication will not take place. 13
14
4.4.8.2 APSME-AUTHENTICATE.confirm 15
16
This primitive shall be issued to the ZDO of the initiator and responder devices 17
upon completion or failure of entity authentication. 18
4.4.8.2.1 Semantics of the Service Primitive 19
20
This primitive shall provide the following interface: 21
22
APSME-AUTHENTICATE.confirm {
23
Address, 24
Status 25
} 26
27
Table 4.30 specifies the parameters of the APSME-AUTHENTICATE.confirm 28
primitive. In addition to these codes, if an NLDE-DATA.confirm primitive with a 29
Status parameter set to a value other than SUCCESS is issued when sending one 30
of the protocol messages, the Status parameter of the APSME- 31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
470 Security Services Specification

AUTHENTICATE.confirm primitive shall be set to that received from the NWK


layer. 1
2
Table 4.30 APSME-AUTHENTICATE.confirm Parameters
3
Parameter 4
Name Type Valid Range Description 5
6
Address DevAddress Any valid 64-bit The extended, 64-bit IEEE
address. address of the device with 7
which the entity authentication 8
took place. 9
Status Enumeration Value given by The final status of the entity 10
Table 4.29 or any status authentication. 11
value returned from the 12
NLDE-DATA.confirm 13
primitive. 14
15
4.4.8.2.2 When Generated 16
17
The APSME of the initiator or responder shall issue this primitive to its ZDO
18
upon completion of entity authentication.
19
4.4.8.2.3 Effect on Receipt 20
21
Upon receiving the APSME-AUTHENTICATE.confirm primitive, the ZDO of 22
the initiator is notified of the result of its request to authenticate the responder. If 23
the transfer was successful, the Status parameter will be set to SUCCESS and the 24
ZDO will learn that it shares a key with the responder and that it has received 25
authenticated data from the responder. Otherwise, the Status parameter will 26
indicate the error. 27
The ZDO of the responder is notified of the result of the transfer of authenticated 28
data from the initiator. If the transfer was successful, the Status parameter will be 29
set to SUCCESS and the ZDO will learn that it shares a key with the initiator and 30
that it has received authenticated data from the initiator. Otherwise, the Status 31
parameter will indicate the error. 32
33
4.4.8.3 APSME-AUTHENTICATE.indication 34
35
The APSME in the responder issues this primitive to its ZDO when it receives an 36
initial authentication message from an initiator. 37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 471

4.4.8.3.1 Semantics of the Service Primitive


1
This primitive shall provide the following interface: 2
APSME-AUTHENTICATE.indication {
3
4
InitiatorAddress,
5
RandomChallenge,
6
} 7
8
Table 4.31 specifies the parameters of the APSME-AUTHENTICATE.indication 9
primitive. 10
Table 4.31 APSME-AUTHENTICATE.indication Parameters 11
12
Parameter 13
Name Type Valid Range Description 14
InitiatorAddress DevAddress Any valid 64-bit The extended, 64-bit IEEE 15
address address of the initiator device. 16
Enumeration
17
RandomChallenge Set of 16 - The 16-octet random challenge 18
octets received from the initiator. 19
20
4.4.8.3.2 When Generated 21
22
The APSME in the responder device shall issue this primitive to the ZDO when a
23
request to start an entity authentication is received from an initiator.
24
4.4.8.3.3 Effect on Receipt 25
26
Upon receiving the APSME-AUTHENTICATE.indication primitive, the ZDO 27
will determine whether it wishes to participate in entity authentication with the 28
initiator specified by the InitiatorAddress parameter. If it does, the ZDO will 29
respond using the APSME-AUTHENTICATE.request primitive, setting the 30
Action parameter to RESPOND_ACCEPT and the corresponding 31
RandomChallenge parameter in the APSME-AUTHENTICATE.request primitive 32
to the RandomChallenge parameter. If it does not wish to participate in entity 33
authentication with the initiator, the ZDO will respond using the APSME- 34
AUTHENTICATE.request primitive, setting the Action parameter to 35
RESPOND_REJECT. 36
37
4.4.8.4 Data Service Message Sequence Chart 38
Figure 4.6 illustrates the sequence of primitives necessary for a successful entity 39
authentication between two devices. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
472 Security Services Specification

ZDO APSME APSME ZDO


1. APSME-AUTHENTICATE.request
1
(initiator) 2. APSME-AUTHENTICATE.indication 2
3. APSME-AUTHENTICATE.request
3
(responder) 4
5
Mutual Entity 6
Authentication
4. APSME-AUTHENTICATE.confirm 5. APSME-AUTHENTICATE.confirm 7
8
9
10
Figure 4.6 Sequence Chart for Successful APSME-AUTHENTICATE 11
Primitives 12
13
4.4.8.5 The Mutual Entity Authentication Protocol 14
The APSME on the initiator and responder execute the mutual entity 15
authentication scheme specified in sub-clause B.8. The messages sent during the 16
scheme specified in sub-clause B.8 shall be assigned to the frame names given in 17
Table 4.32. The formats for these entity authentication frames are given in sub- 18
clause 4.4.9.7. 19
20
The KeyType sub-field in the initiator and responder challenge frames shall be set 21
to 0x00 to indicate that the shared key is the active network key shared between 22
the initiator and the responder. 23
The MacKey as specified in sub-clause B.8.2 prerequisite step 2 shall be the active 24
network key shared between the initiator and the responder obtained using 25
NLME-GET.request on the nwkSecurityMaterialSet, using the key corresponding 26
to nwkActiveKeySeqNumber. If the KeySeqNumber sub-field of the incoming 27
initiator or responder challenge frame does not match nwkActiveKeySeqNumber 28
or the network key is not available, the local APSME shall issue the APSME- 29
AUTHENTICATE.confirm primitive with the Status parameter set to NO_KEY. 30
31
Text1 as specified in sub-clause B.8.2 prerequisite 2 and sub-clause B.8.2 step 7 32
shall be set to the outgoing frame counter associated with the active network key 33
of the responder using the octet representation specified in sub-clause A.1. Using 34
NLME-GET.request, this is the OutgoingFrameCounter entry of the 35
nwkSecurityMaterialSet entry which has its KeySeqNumber entry equal to 36
nwkActiveKeySeqNumber. If the frame counter is not available, the responder 37
APSME shall issue the APSME-AUTHENTICATE.confirm primitive with the 38
Status parameter set to NO_DATA. The incoming frame counter corresponding to 39
the responder, associated with the active network key of the initiator shall be set to 40
Text1 as specified in sub-clause B.8.1 step 6. Using NLME-SET.request, this is 41
the IncomingFrameCounter entry of the IncomingFrameCounterSet entry, where 42
the SenderAddress entry corresponds to the responder, of the 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 473

nwkSecurityMaterialSet entry which has its KeySeqNumber entry equal to


nwkActiveKeySeqNumber. 1
2
Text2 as specified in sub-clause B.8.1 prerequisite 1 and sub-clause B.8.1 step 4 3
shall be set to the outgoing frame counter associated with the active network key 4
of the initiator using the octet representation specified in sub-clause A.1. Using 5
NLME-GET.request, this is the OutgoingFrameCounter entry of the 6
nwkSecurityMaterialSet entry which has its KeySeqNumber entry equal to 7
nwkActiveKeySeqNumber. If the frame counter is not available, the responder 8
APSME shall issue the APSME-AUTHENTICATE.confirm primitive with the 9
Status parameter set to NO_DATA. The incoming frame counter corresponding to 10
the initiator associated with the active network key of the responder shall be set to 11
Text2 as specified in sub-clause B.8.2 step 3. Using NLME-SET.request, this is 12
the IncomingFrameCounter entry of the IncomingFrameCounterSet entry, where 13
the SenderAddress entry corresponds to the initiator, of the 14
nwkSecurityMaterialSet entry which has its KeySeqNumber entry equal to 15
nwkActiveKeySeqNumber. 16
When the NLDE-DATA.request primitive is issued to send either the challenge 17
frame or the MAC and data frame, the SecurityEnable parameter shall always be 18
set to FALSE to indicate that no security is used at the network layer. 19
20
The authentication scheme shall be guarded by starting a timer of period 21
apsSecurityTimeoutPeriod when the initiator or responder challenge is sent. 22
During the authentication scheme, if any error condition listed in Table 4.33 is 23
detected then the scheme shall be aborted and the local APSME shall issue the 24
APSME-AUTHENTICATE.confirm primitive with the Status parameter set as 25
indicated in Table 4.33. If no error conditions occur (i.e., the authentication 26
scheme outputs “valid”), then the initiator shall consider that secure 27
communications with the responder using the indicated key are possible. The 28
initiator and responder shall issue the APSME-AUTHENTICATE.confirm 29
primitive with the Status parameter set to SUCCESS. 30
31
Table 4.32 Mapping of Frame Names to Mutual Entity Authentication Scheme
Messages 32
33
Frame Name Description Reference 34
35
APS_CMD_EA_INIT_CHLNG Sent by initiator during action step 1 4.4.9.7.1
(sub-clause B.8.1). 36
37
APS_CMD_EA_RSP_CHLNG Sent by responder during action step 2 4.4.9.7.2 38
(sub-clause B.8.2).
39
APS_CMD_EA_INIT_MAC_DATA Sent by initiator during action step 5 4.4.9.7.3 40
(sub-clause B.8.1). 41
APS_CMD_EA_RSP_MAC_DATA Sent by responder during action step 8 4.4.9.7.4 42
(sub-clause B.8.2). 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
474 Security Services Specification

1
Table 4.33 Mapping of Mutual Entity Authentication Error
Conditions to Status Codes 2
3
Status Description Status Code Value 4
5
No errors occur. SUCCESS 0x00
6
An invalid parameter was input to one of the key INVALID_PARAMETER 0x01 7
establishment primitives. 8
No authentication key exists. NO_KEY 0x02 9
No authentication data exists. NO_DATA 0x03
10
11
Challenge is invalid: INVALID_CHALLENGE 0x04 12
Initiator during action step 2 (sub-clause B.8.1). 13
14
Responder during action step 1 (sub-clause B.8.2).
15
MAC transformation outputs invalid: INVALID_MAC 0x05 16
Initiator during action step 4 (sub-clause B.8.1). 17
18
Responder during action steps 4 and 7 (sub-clause B.8.2).
19
Tag checking transformation outputs invalid: INVALID_KEY 0x06 20
Initiator during action step 3 (sub-clause B.8.1). 21
22
Responder during action step 6 (sub-clause B.8.2).
23
The initiator or responder waits for an expected incoming TIMEOUT 0x07 24
message for time greater than apsSecurityTimeoutPeriod. 25
26
4.4.9 Command Frames 27
28
The APS layer command frame formats are given in this clause. 29
30
All APS layer command frames are sent secured unless explicitly specified. 31
Command identifier values are shown in Table 4.34. 32
33
Table 4.34 Command Identifier Values 34
Command Identifier Value 35
36
APS_CMD_SKKE_1 0x01 37
APS_CMD_SKKE_2 0x02 38
39
APS_CMD_SKKE_3 0x03a
40
APS_CMD_SKKE_4 0x04 41
APS_CMD_TRANSPORT_KEY 0x05 42
43
APS_CMD_UPDATE_DEVICE 0x06 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 475

Table 4.34 Command Identifier Values (Continued)


1
Command Identifier Value 2
APS_CMD_REMOVE_DEVICE 0x07 3
4
APS_CMD_REQUEST_KEY 0x08
5
APS_CMD_SWITCH_KEY 0x09 6
APS_CMD_EA_INIT_CHLNG 0x0A 7
8
APS_CMD_EA_RSP_CHLNG 0x0B 9
APS_CMD_EA_INIT_MAC_DATA 0x0C 10
APS_CMD_EA_RSP_MAC_DATA 0x0D
11
12
APS_CMD_TUNNEL 0x0E 13
a. CCB #746 14
15
4.4.9.1 Key-Establishment Commands 16
17
The APS command frames used during key establishment are specified in this 18
clause. The optional fields of the APS header portion of the general APS frame 19
format shall not be present. All key establishment command frames are sent 20
unsecured. 21
22
The generic SKKE command frame shall be formatted as illustrated in Figure 4.7.
23
Octets: 1 1 1 8 8 16 24
25
Frame control APS APS command Initiator Responder Data 26
countera identifierb address address
27
APS headerc Payload 28
a. CCB #811 29
b. CCB #811 30
c. CCB #811 31
32
Figure 4.7 Generic SKKE Frame Command Format
33
34
4.4.9.1.1 Command Identifier Field
35
The command identifier field shall indicate the APS command type. For SKKE 36
frames, the command identifier shall indicate either an SKKE-1, SKKE-2, SKKE- 37
3, or SKKE-4 frame, depending on the frame type (APS_CMD_SKKE_1, 38
APS_CMD_SKKE_2, APS_CMD_SKKE_3, APS_CMD_SKKE_4, see Table 39
4.34).35 40
41
42
43
35. CCB #811 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
476 Security Services Specification

4.4.9.1.2 Initiator Address Field


1
The initiator address field shall be the 64-bit extended address of the device that 2
acts as the initiator in the key-establishment protocol. 3
4.4.9.1.3 Responder Address Field 4
5
The responder address field shall be the 64-bit extended address of the device that 6
acts as the responder in the key-establishment protocol. 7
4.4.9.1.4 Data Field 8
9
The content of the data field depends on the command identifier field (that is, 10
SKKE-1, SKKE-2, SKKE-3, or SKKE-4). Clauses 4.4.9.1.4.1 through 4.4.9.1.4.4 11
describe the content of the data field for each command type. 12
13
4.4.9.1.4.1 SKKE-1 Frame 14
15
The data field shall be the octet representation of the challenge QEU generated by 16
the initiator during action step 1 of sub-clause B.7.1. 17
18
4.4.9.1.4.2 SKKE-2 Frame 19
The data field shall be the octet representation of the challenge QEV generated by 20
the responder during action step 2 of sub-clause B.7.2. 21
22
4.4.9.1.4.3 SKKE-3 Frame 23
24
The data field shall be the octet representation of the string MacTag2 generated by 25
the initiator during action step 1 of sub-clause B.7.1. 26
27
4.4.9.1.4.4 SKKE-4 Frame 28
29
The data field shall be the octet representation of the string MacTag1 generated by 30
the responder during action step 10 of sub-clause B.7.2. 31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 477

4.4.9.2 Transport-Key Commands


1
The transport-key command frame shall be formatted as illustrated in Figure 4.8. 2
The optional fields of the APS header portion of the general APS frame format 3
shall not be present. 4
5
Octets: 1 1 1 1 Variable 6
Frame control APS countera APS Key type Key descriptor 7
command 8
identifierb 9
APS headerc Payload 10
a. CCB #811 11
b. CCB #811 12
c. CCB #811 13
14
Figure 4.8 Transport-Key Command Frame 15
16
4.4.9.2.1 Command Identifier Field 17
The command identifier field shall indicate the transport-key APS command type 18
(APS_CMD_TRANSPORT_KEY, see Table 4.34).36 19
20
4.4.9.2.2 Key Type Field 21
22
This field is 8 -bits in length and describes the type of key being transported. The
23
different types of keys are enumerated in Table 4.12.
24
4.4.9.2.3 Key Descriptor Field 25
26
This field is variable in length and shall contain the actual (unprotected) value of
27
the transported key along with any relevant identification and usage parameters.
28
The information in this field depends on the type of key being transported (as
29
indicated by the key type field — see sub-clause 4.4.9.2.2) and shall be set to one
30
of the formats described in the following subsections.
31
32
4.4.9.2.3.1 Trust Center Master or Link Key Descriptor Field 33
If the key type field is set to 0 or 4, the key descriptor field shall be formatted as 34
shown in Figure 4.9. 35
36
Octets: 16 8 8 37
38
Key Destination address Source address
39
Figure 4.9 Trust Center Master Key Descriptor Field in Transport-Key 40
Command 41
42
43
36. CCB #811 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
478 Security Services Specification

• The key sub-field shall contain the master key that should be used to set up link
keys with the Trust Center. 1
2
• The destination address sub-field shall contain the address of the device which 3
should use this master key. 4
• The source address sub-field shall contain the address of the device (for 5
example, the Trust Center) which originally sent this master key. 6
7
4.4.9.2.3.2 Network Key Descriptor Field 8
9
If the key type field is set to 1, 5 or 6, this field shall be formatted as shown in 10
Figure 4.10. 11
12
Octets: 16 1 8 8 13
Key Sequence number Destination address Source address 14
15
Figure 4.10 Network Key Descriptor Field in Transport-Key Command 16
17
• The key sub-field shall contain a network key. 18
• The sequence number sub-field shall contain the sequence number associated 19
with this network key. 20
21
• The destination address sub-field shall contain the address of the device which 22
should use this network key. 23
• If the network key is sent to a broadcast address, the destination address sub- 24
field shall be set to the all-zero string and shall be ignored upon reception. 25
26
• The source address field sub-shall contain the address of the device (for 27
example, the Trust Center) which originally sent this network key. 28
29
4.4.9.2.3.3 Application Master and Link Key Descriptor Field 30
If the key type field is set to 2 or 3, this field shall be formatted as shown in 31
Figure 4.11. 32
33
Octets: 16 8 1 34
35
Key Partner address Initiator flag
36
Figure 4.11 Application Master Key Descriptor in Transport-Key Command 37
38
• The key sub-field shall contain a master or link key that is shared with the 39
device identified in the partner address sub-field. 40
41
• The partner address sub-field shall contain the address of the other device that 42
was sent this link or master key. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 479

• The initiator flag sub-field shall be set to 1 if the device receiving this packet
requested this key. Otherwise, this sub-field shall be set to 0. 1
2
4.4.9.3 Update Device Commands 3
4
The APS command frame used for device updates is specified in this clause. The 5
optional fields of the APS header portion of the general APS frame format shall 6
not be present. 7
The update-device command frame shall be formatted as illustrated in 8
Figure 4.12. 9
10
Octets: 1 1 1 8 2 1 11
12
Frame control APS countera APS Device Address Device short Status
command address
13
identifierb 14
15
APS Headerc Payload
16
a. CCB #811 17
b. CCB #811 18
c. CCB #811 19
Figure 4.12 Update-Device Command Frame Format 20
21
4.4.9.3.1 Command Identifier Field 22
23
The command identifier field shall indicate the update-device APS command type 24
(APS_CMD_UPDATE_DEVICE, see Tables 4.34). 37 25
4.4.9.3.2 Device Address Field 26
27
The device address field shall be the 64-bit extended address of the device whose 28
status is being updated. 29
4.4.9.3.3 Device Short Address Field 30
31
The device short address field shall be the 16-bit network address of the device 32
whose status is being updated. 33
4.4.9.3.4 Status Field 34
35
The status field shall be assigned a value as described for the Status parameter in 36
Table 4.20. 37
38
39
40
41
42
43
37. CCB #811 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
480 Security Services Specification

4.4.9.4 Remove Device Commands


1
The APS command frame used for removing a device is specified in this clause. 2
The optional fields of the APS header portion of the general APS frame format 3
shall not be present. 4
5
The remove-device command frame shall be formatted as illustrated in
6
Figure 4.13.
7
Octets: 1 1 1 8 8
9
Frame control APS countera APS command Child address 10
identifierb
11
APS Headerc Payload 12
a. CCB #811 13
b. CCB #811 14
c. CCB #811 15
16
Figure 4.13 Remove-Device Command Frame Format
17
18
4.4.9.4.1 Command Identifier Field
19
The command identifier field shall indicate the remove-device APS command 20
type (APS_CMD_REMOVE_DEVICE, see Table 4.34).38 21
22
4.4.9.4.2 Child Address Field
23
The child address field shall be the 64-bit extended address of the device that is 24
requested to be removed from the network. 25
26
4.4.9.5 Request-Key Commands 27
28
The APS command frame used by a device for requesting a key is specified in this 29
clause. The optional fields of the APS header portion of the general APS frame 30
format shall not be present. 31
32
33
34
35
36
37
38
39
40
41
42
43
38. CCB #811 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 481

The request-key command frame shall be formatted as illustrated in Figure 4.14.


1
Octets: 1 1 1 1 0/8 2
3
Frame control APS countera APS command Key type Partner address
identifierb 4
5
APS Headerc Payload 6
a. CCB #811 7
b. CCB #811 8
c. CCB #811 9
Figure 4.14 Request-Key Command Frame Format 10
11
4.4.9.5.1 Command Identifier Field 12
13
The command identifier field shall indicate the request-key APS command type 14
(APS_CMD_REQUEST_KEY, see Table 4.34).39 15
4.4.9.5.2 Key Type Field 16
17
The key type field shall be set to 1 when the network key is being requested, shall 18
be set to 2 when an application key is being requested, and 4 when a Trust Center 19
link key is being requested. 20
4.4.9.5.3 Partner Address Field 21
22
When the key type field is 2 (that is, an application key), the partner address field 23
shall contain the extended 64-bit address of the partner device that shall be sent 24
the key. Both the partner device and the device originating the request-key 25
command will be sent the key. 26
27
When the key-type field is 1 (that is, a network key), the partner address field will
28
not be present.
29
4.4.9.6 Switch-Key Commands 30
31
The APS command frame used by a device for switching a key is specified in this 32
clause. The optional fields of the APS header portion of the general APS frame 33
format shall not be present. 34
35
36
37
38
39
40
41
42
43
39. CCB #811 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
482 Security Services Specification

The switch-key command frame shall be formatted as illustrated in Figure 4.15.


1
Octets: 1 1 1 1 2
3
Frame control APS countera APS command Sequence number
identifierb 4
5
APS Headerc Payload 6
a. CCB #811 7
b. CCB #811 8
c. CCB #811 9
Figure 4.15 Switch-key Command Frame Format 10
11
4.4.9.6.1 Command Identifier Field 12
13
The command identifier field shall indicate the switch-key APS command type 14
(APS_CMD_SWITCH_KEY, see Table 4.34).40 15
4.4.9.6.2 Sequence Number Field 16
17
The sequence number field shall contain the sequence number identifying the 18
network key to be made active. 19
20
4.4.9.7 Entity Authentication Frames 21
22
The APS command frames used during entity authentication are specified in this
23
clause. The optional fields of the APS header portion of the general APS frame
24
format shall not be present. The initiator and responder should implement
25
random delays on their respective transmissions to avoid packet transmission
26
collisions.41
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
40. CCB #811 43
41. CCB #674 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 483

4.4.9.7.1 Entity Authentication Initiator Challenge Frame


1
This frame is the first frame sent by the initiator to the responder during the 2
mutual entity authentication protocol and shall be formatted as illustrated in 3
Figure 4.16. 4
5
Octets: 1 1 1 Variable 8 8 16
6
Frame APS APS command KeyInfo Initiator Responder Challenge 7
control countera identifierb 8
APS Headerc Payloadd 9
a. CCB #811 10
b. CCB #811 11
c. CCB #811 12
d. CCB #811 13
14
Figure 4.16 Entity Authentication Initiator Challenge Frame Format 15
16
4.4.9.7.1.1 Command Identifier Field 17
18
The command identifier field shall indicate the Entity Authentication Initiator
19
Challenge APS command type (APS_CMD_EA_INIT_CHLNG, see Table
20
4.34).42
21
22
4.4.9.7.1.2 KeyInfo Field
23
The KeyInfo field is divided into two subfields as illustrated in Figure 4.17. 24
25
Octets: 1 0/1 26
KeyType KeySeqNumber 27
28
Figure 4.17 KeyInfo Field Format 29
30
4.4.9.7.1.2.1 KeyType Subfield 31
32
The KeyType field is 1 octet in length and shall be set to one of the non-reserved
33
values in Table 4.35.
34
Table 4.35 Values of the KeyType Sub-Field 35
36
Value Description
37
0x00 Active network key. 38
0x01 Link key shared between initiator and responder. 39
40
0x02-0xff Reserved. 41
42
43
42. CCB #811 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
484 Security Services Specification

4.4.9.7.1.2.2 KeySeqNumber Subfield


1
The KeySeqNumber sub-field shall be set to the key sequence number of the 2
active network key. 3
4
4.4.9.7.1.3 Initiator Field 5
6
The initiator field shall be set to the 64-bit extended address of the device that acts
7
as the initiator of the scheme.
8
9
4.4.9.7.1.4 Responder Field 10
The responder field shall be set to the 64-bit extended address of the device that 11
acts as the responder to the scheme. 12
13
4.4.9.7.1.5 Challenge Field 14
15
The challenge field shall be the octet representation of the challenge QEU 16
generated by the initiator during action step 1 of sub-clause B.8.1. 17
4.4.9.7.2 Entity Authentication Response Challenge Frame 18
19
This frame is the first frame sent by the responder to the initiator during the 20
mutual entity authentication protocol and shall be formatted as illustrated in 21
Figure 4.18. 22
23
Octets: 1 1 1 Variable 8 8 16 24
Frame APS APS command KeyInfo Initiator Responder Challenge 25
control countera identifierb 26
APS Headerc Payloadd 27
28
a. CCB #811
29
b. CCB #811
30
c. CCB #811
31
d. CCB #811
32
Figure 4.18 Entity Authentication Responder Challenge Frame Format 33
34
4.4.9.7.2.1 Command Identifier Field 35
36
The command identifier field shall indicate the Entity Authentication Responder
37
Challenge APS command type (APS_CMD_EA_RSP_CHLNG, see Table
38
4.34).43
39
40
41
42
43
43. CCB #811 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 485

4.4.9.7.2.2 KeyInfo Field


1
The KeyInfo field is divided into two subfields as illustrated in Figure 4.19. 2
3
Octets: 1 0/1
4
KeyType KeySeqNumber 5
6
Figure 4.19 KeyInfo Field Format 7
8
4.4.9.7.2.2.1 KeyType Sub-Field 9
The KeyType field shall be set to 0x00 to indicate that the shared key is the active 10
network key shared between the initiator and the responder. 11
12
4.4.9.7.2.2.2 KeySeqNumber Sub-Field 13
14
The KeySeqNumber sub-field shall be set to the key sequence number of the 15
active network key. 16
17
4.4.9.7.2.3 Initiator Field 18
19
The initiator field shall be set to the 64-bit extended address of the device that acts 20
as the initiator of the scheme. 21
22
4.4.9.7.2.4 Responder Field 23
The responder field shall be set to the 64-bit extended address of the device that 24
acts as the responder to the scheme. 25
26
4.4.9.7.2.5 Challenge Field 27
28
The challenge field shall be the octet representation of the challenge QEV 29
generated by the responder during action step 2 of sub-clause B.8.2. 30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
486 Security Services Specification

4.4.9.7.3 Entity Authentication Initiator MAC and Data Frame


1
This is the second frame sent by initiator to the responder during the mutual entity 2
authentication protocol, and shall be formatted as illustrated in Figure 4.20. 3
4
Octets: 1 1 1 16 1 4
5
Frame APS APS MAC DataType Data 6
control countera command 7
identifierb 8
APS Headerc Payloadd 9
a. CCB #811 10
b. CCB #811 11
c. CCB #811 12
d. CCB #811 13
14
Figure 4.20 Entity Authentication Initiator MAC and Data Frame Format 15
16
4.4.9.7.3.1 Command Identifier Field 17
The command identifier field shall indicate the Entity Authentication Initiator 18
MAC and Data APS command type (APS_CMD_EA_RSP_MAC_DATA, see 19
Table 4.34).44 20
21
4.4.9.7.3.2 MAC Field 22
23
The MAC field shall be the octet representation of the string MacTag2 generated 24
by the initiator during action step 4 of sub-clause B.8.1. 25
26
4.4.9.7.3.3 DataType Field 27
28
The DataType field shall be set to 0x00 to indicate the frame counter associated 29
with the active network key. 30
31
4.4.9.7.3.4 Data Field 32
The Data field shall be octet representation of the string Text2, i.e. the frame 33
counter associated with the active network key. 34
35
36
37
38
39
40
41
42
43
44. CCB #811 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 487

4.4.9.7.4 Entity Authentication Responder MAC and Data Frame


1
This is the second frame sent by the responder to the initiator during mutual entity 2
authentication protocol, and shall be formatted as illustrated in Figure 4.21. 3
4
Octets: 1 1 1 16 1 4
5
Frame APS APS MAC DataType Data 6
control countera command 7
identifierb 8
APS Headerc Payloadd 9
a. CCB #811 10
b. CCB #811 11
c. CCB #811 12
d. CCB #811 13
14
Figure 4.21 Entity Authentication Responder MAC and Data Frame Format 15
16
4.4.9.7.4.1 Command Identifier Field 17
The command identifier field shall indicate the Entity Authentication Responder 18
MAC and Data command (APS_CMD_EA_RSP_MAC_DATA, see Table 19
4.34).45 20
21
4.4.9.7.4.2 MAC Field 22
23
The MAC field shall be the octet representation of the string MacTag1 generated 24
by the responder during action step 8 of sub-clause B.8.2 25
26
4.4.9.7.4.3 DataType Field 27
28
The DataType field shall be set to 0x00 to indicate the frame counter associated 29
with the active network key. 30
31
4.4.9.7.4.4 Data Field 32
The Data field shall be octet representation of the string Text1, i.e. the frame 33
counter associated with the active network key. 34
35
4.4.9.8 Tunnel Commands 36
37
The APS command frame used by a device for sending a command to a device 38
that lacks the current network key is specified in this clause. The optional fields of 39
the APS header portion of the general APS frame format shall not be present. The 40
tunnel-key command frame is sent unsecured.46 41
42
45. CCB #811 43
46. CCB #850 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
488 Security Services Specification

The tunnel-key command frame shall be formatted as illustrated in Figure 4.22.


1
Octets:1 1 1 8 2 13 Variable 4 2
3
Frame APS APS Destination Tunneled Tunneled Tunneled Tunneled
control counter command address APS header auxiliary command APS 4
a identifier frame MICb 5
6
APS Headerc Payloadd
7
Figure 4.22 Tunnel Command Frame Format 8
a. CCB #811 9
b. CCB #811 10
c. CCB #811 11
d. CCB #811 12
13
4.4.9.8.1 Command Identifier Field
14
The command identifier field shall indicate the tunnel APS command type 15
(APS_CMD_TUNNEL, see Table 4.34).47 16
17
4.4.9.8.2 Destination Address
18
The destination address field shall be the 64-bit extended address of the device 19
that is to receive the tunnelled command. 20
21
4.4.9.8.3 Tunnelled Auxiliary Frame Field 22
The tunnelled auxiliary frame field shall be the auxiliary frame (see sub- 23
clause 4.5.1) used to encrypt the tunnelled command. The auxiliary frame shall 24
indicate that a link key was used and shall included the extended nonce field. 25
26
4.4.9.8.4 Tunnelled Command Field 27
The tunnelled command field shall be the APS command frame to be sent to the 28
destination. 29
30
31
4.4.10 Security-Related AIB Attributes 32
33
The AIB contains attributes that are required to manage security for the APS 34
layer. Each of these attributes can be read or written using the APSME- 35
36
37
38
39
40
41
42
43
47. CCB #811 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 489

GET.request and APSME-SET.request primitives, respectively. The security-


related attributes contained in the APS PIB are presented in Tables 4.36 and 4.37. 1
2
Table 4.36 AIB Security Attributes
3
Attribute Identifier Type Range Description Default 4
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 shared with other 9
4.37. 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
Table 4.37 Elements of the Key-Pair Descriptor 22
23
Name Type Range Description Default 24
DeviceAddress Device Any valid Identifies the address of the entity - 25
address 64-bit with which this key-pair is 26
address shared. 27
MasterKey Set of - The actual value of the master - 28
16 key. 29
octets 30
LinkKey Set of - The actual value of the link key. - 31
16 32
octets 33
OutgoingFrame- Set of 4 0x00000000- Outgoing frame counter for use 0x00000000 34
Counter octets 0xFFFFFFFF with this link key. 35
IncomingFrame- Set of 4 0x00000000- Incoming frame counter value 0x00000000
36
Counter octets 0xFFFFFFFF corresponding to DeviceAddress. 37
38
39
4.5 Common Security Elements 40
41
42
This clause describes security-related features that are used in more than one
43
ZigBee layer. The NWK and APS layers shall use the auxiliary header as
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
490 Security Services Specification

specified in sub-clause 4.5.1 and the security parameters specified in sub-


clause 4.5.2. The formatting of all frames and fields in this specification are 1
depicted in the order in which they are transmitted by the NWK layer, from left to 2
right, where the leftmost bit is transmitted first in time. Bits within each field are 3
numbered from 0 (leftmost and least significant) to k-1 (rightmost and most 4
significant), where the length of the field is k bits. Fields that are longer than a 5
single octet are sent to the next layer in the order from the octet containing the 6
lowest numbered bits to the octet containing the highest numbered bits. 7
8
9
4.5.1 Auxiliary Frame Header Format 10
11
The auxiliary frame header, as illustrated by Figure 4.23, shall include a security 12
control field and a frame counter field, and may include a sender address field and 13
key sequence number field. 14
15
Octets: 1 4 0/8 0/1
16
Security control Frame counter Source address Key sequence 17
number 18
19
Figure 4.23 Auxiliary Frame Header Format
20
21
4.5.1.1 Security Control Field
22
The security control field shall consist of a security level, a key identifier, and an 23
extended nonce sub-field and shall be formatted as shown in Figure 4.24. 24
25
Bit: 0-2 3-4 5 6-7 26
Security level Key identifier Extended nonce Reserved 27
28
Figure 4.24 Security Control Field Format 29
30
4.5.1.1.1 Security Level Sub-Field 31
32
The security level identifier indicates how an outgoing frame is to be secured,
33
how an incoming frame purportedly has been secured; it also indicates whether or
34
not the payload is encrypted and to what extent data authenticity over the frame is
35
provided, as reflected by the length of the message integrity code (MIC). The bit-
36
length of the MIC may take the values 0, 32, 64 or 128 and determines the
37
probability that a random guess of the MIC would be correct. The security
38
properties of the security levels are listed in Table 4.38. Note that security level
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 491

identifiers are not indicative of the relative strength of the various security levels.
Also note that security levels 0 and 4 should not be used for frame security. 1
2
Table 4.38 Security Levels Available to the NWK, and APS Layers
3
Security Frame Integrity 4
Security Level Sub- (length M of MIC, 5
Level Field Security Data in Number of 6
Identifier (Table 4.24) Attributes Encryption Octets) 7
0x00 ‘000’ None OFF NO (M = 0) 8
9
0x01 ‘001’ MIC-32 OFF YES (M=4)
10
0x02 ‘010’ MIC-64 OFF YES (M=8) 11
0x03 ‘011’ MIC-128 OFF YES (M=16) 12
13
0x04 ‘100’ ENC ON NO (M = 0)
14
0x05 ‘101’ ENC-MIC-32 ON YES (M=4) 15
0x06 ‘110’ ENC-MIC-64 ON YES (M=8) 16
17
0x07 ‘111’ ENC-MIC-128 ON YES (M=16) 18
19
4.5.1.1.2 Key Identifier Sub-Field 20
21
The key identifier sub-field consists of two bits that are used to identify the key
22
used to protect the frame. The encoding for the key identifier sub-field shall be as
23
listed in Table 4.39.
24
Table 4.39 Encoding for the Key Identifier Sub-Field 25
26
Key Identifier Sub-Field
Key Identifier (Table 4.24) Description 27
28
0x00 ‘00’ A data key. 29
0x01 ‘01’ A network key. 30
31
0x02 ‘10’ A key-transport key.
32
0x03 ‘11’ A key-load key. 33
34
4.5.1.1.3 Extended Nonce Sub-Field 35
36
The extended nonce sub-field shall be set to 1 if the sender address field of the 37
auxiliary header is present. Otherwise, it shall be set to 0. 38
39
4.5.1.2 Counter Field 40
The counter field is used to provide frame freshness and to prevent processing of 41
duplicate frames. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
492 Security Services Specification

4.5.1.3 Source Address Field


1
The source address field shall only be present when the extended nonce sub-field 2
of the security control field is 1. When present, the source address field shall 3
indicate the extended 64-bit address of the device responsible for securing the 4
frame. 5
6
4.5.1.4 Key Sequence Number Field 7
8
The key sequence number field shall only be present when the key identifier sub- 9
field of the security control field is 1 (that is, a network key). When present, the 10
key sequence number field shall indicate the key sequence number of the network 11
key used to secure the frame. 12
13
4.5.2 Security Parameters 14
15
This sub-clause specifies the parameters used for the CCM* security operations. 16
17
4.5.2.1 CCM* Mode of Operation and Parameters 18
19
Applying security to a NWK or APS frame on a particular security level 20
corresponds to a particular instantiation of the AES-CCM* mode of operation as 21
specified in sub-clause B.1.2. The AES-CCM* mode of operation is an extension 22
of the AES-CCM mode that is used in the 802.15.4-2003 MAC specification and 23
provides capabilities for authentication, encryption, or both. 24
The nonce shall be formatted as specified in sub-clause 4.5.2.2. 25
26
Table 4.38 gives the relationship between the security level sub-field of the 27
security control field (Table 4.24), the security level identifier, and the CCM* 28
encryption/authentication properties used for these operations. 29
30
4.5.2.2 CCM* Nonce 31
The nonce input used for the CCM* encryption and authentication transformation 32
and for the CCM* decryption and authentication checking transformation consists 33
of data explicitly included in the frame and data that both devices can 34
independently obtain. Figure 4.25 specifies the order and length of the subfields 35
of the CCM* nonce. The nonce's security control and frame counter fields shall be 36
the same as the auxiliary header’s security control and frame counter fields (as 37
defined in sub-clause 4.5.1) of the frame being processed. The nonce’s source 38
address field shall be set to the extended 64-bit IEEE address of the device 39
originating security protection of the frame. When the extended nonce sub-field of 40
the auxiliary header’s security control field is 1, the extended 64-bit IEEE address 41
of the device originating security protection of the frame shall correspond to the 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 493

auxiliary header’s source address field (as defined in sub-clause 4.5.1) of the
frame being processed 1
2
Octets: 8 4 1 3
4
Source address Frame counter Security control
5
Figure 4.25 CCM* Nonce 6
7
8
4.5.3 Cryptographic Key Hierarchy 9
10
The link key established between two (or more) devices via one of the key-
11
establishment schemes specified in sub-clause 4.4.2 (or transport-key commands
12
specified in sub-clause 4.4.3) is used to determine related secret keys, including
13
data keys, key-transport keys, and key-load keys. These keys are determined as
14
follows:
15
1 Key-Transport Key. This key is the outcome of executing the specialized keyed 16
hash function specified in sub-clause B.1.4 under the link key with the 1-octet 17
string ‘0x00’as the input string. 18
19
2 Key-Load Key. This key is the outcome of executing the specialized keyed hash
20
function specified in sub-clause B.1.4 under the link key with as input string
21
the 1-octet string ‘0x02’as the input string.
22
3 Data Key. This key is equal to the link key. 23
24
All keys derived from the link key shall share the associated frame counters. Also,
25
all layers of ZigBee shall share the active network key and associated outgoing
26
and incoming frame counters.
27
28
4.5.4 Implementation Guidelines (Informative) 29
30
This clause provides general guidelines that should be followed to ensure a secure 31
implementation. 32
33
4.5.4.1 Random Number Generator 34
35
A ZigBee device implementing the key-establishment security service, (see sub- 36
clause 4.2.3.1) may need a strong method of random number generation. For 37
example, when link keys are pre-installed (e.g., in the factory), a random number 38
may not be needed. 39
In all cases that require random numbers, it is critical that the random numbers are 40
not predictable or have enough entropy, so an attacker will not be able determine 41
them by exhaustive search. The general recommendation is that the random 42
number generation shall meet the random number tests specified in FIPS140- 43
2 [B13]. Methods for generation of random numbers include: 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
494 Security Services Specification

1 Base the random number on random clocks and counters within the ZigBee
hardware; 1
2
2 Base the random number on random external events; 3
3 Seed each ZigBee device with a good random number from an external source 4
during production. This random number can then used as a seed to generate 5
additional random numbers. 6
7
A combination of these methods can be used. Since the random number 8
generation is likely integrated into the ZigBee IC, its design — and hence the 9
ultimate viability of any encryption/security scheme — is left up to the IC 10
manufacturers. 11
12
4.5.4.2 Security Implementation 13
To avoid “bugs” that an attacker can use to his advantage, it is crucial that security 14
be well implemented and tested. It is also desirable that the security 15
implementation does not require re-certification for every application. Security 16
services should be implemented and tested by security experts and should not be 17
re-implemented or modified for different applications. 18
19
4.5.4.3 Conformance 20
21
Conformance shall be defined by the profile inheriting given in this specification. 22
Correct implementation of selected cryptographic protocols should be verified as 23
part of the ZigBee certification process. This verification shall include known 24
value tests: an implementation must show that, given particular parameters, it will 25
correctly compute the corresponding results. 26
27
28
4.6 Functional Description 29
30
This sub-clause provides detailed descriptions of how the security services shall 31
be used in a ZigBee network. A description of the ZigBee coordinator’s security 32
initialization responsibilities is given in sub-clause 4.6.1. A brief description of 33
the Trust Center application is given in sub-clause 4.6.2. Detailed security 34
procedures are given in sub-clause 4.6.3. 35
36
37
4.6.1 ZigBee Coordinator 38
39
The ZigBee coordinator shall configure the security level of the network by
40
setting the nwkSecurityLevel attribute in the NIB. If the nwkSecurityLevel
41
attribute is set to zero, the network will be unsecured, otherwise it will be secured.
42
The ZigBee coordinator shall configure the address of the Trust Center by setting 43
the AIB attribute apsTrustCenterAddress. The default value of this address is the 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 495

ZigBee coordinator’s own address, otherwise, the ZigBee coordinator may


designate an alternate Trust Center. 1
2
3
4.6.2 Trust Center Application 4
5
The Trust Center application runs on a device trusted by devices within a ZigBee 6
network to distribute keys for the purpose of network and end-to-end application 7
configuration management. The Trust Center shall be configured to operate in 8
either standard or high security mode and may be used to help establish end-to- 9
end application keys either by sending out link keys directly (that is, key-escrow 10
capability) or by sending out master keys. These keys shall be generated at 11
random. 12
13
4.6.2.1 High Security Mode 14
The high security mode of the Trust Center is designed for high security 15
commercial applications. In this mode, the Trust Center shall maintain a list of 16
devices, master keys, link keys and network keys that it needs to control and 17
enforce the policies of network key updates and network admittance. In this mode, 18
the memory required for the Trust Center grows with the number of devices in the 19
network and the nwkAllFresh attribute in the NIB shall be set to TRUE. It also 20
mandates the implementation of key establishment using SKKE and entity 21
authentication. 22
23
4.6.2.2 Standard Security Mode 24
25
The standard security mode of the Trust Center is designed for lower-security 26
residential applications. In this mode, the Trust Center may maintain a list of 27
devices, master keys, link keys and network keys with all the devices in the 28
network; however, it shall maintain a standard network key and controls policies 29
of network admittance. In this mode, the memory required for the Trust Center 30
does not grow with the number of devices in the network and the nwkAllFresh 31
attribute in the NIB shall be set to FALSE. 32
33
4.6.3 Security Procedures 34
35
This sub-clause gives message sequence charts for joining a secured network, 36
authenticating a newly joined device, updating the network key, recovering the 37
network key, establishing end-to-end application keys, and leaving a secured 38
network. 39
40
4.6.3.1 Joining a Secured Network 41
42
Figure 4.26 shows an example message sequence chart ensuing from when a 43
joiner device communicates with a router device to join a secured network. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
496 Security Services Specification

A device that is operating in a network and has missed a key update may also use
these procedures to receive the latest network key. 1
2
3
Router Joiner
4
ZDO NWK MAC MAC NWK ZDO
5
NLME-PERMIT-JOINING.request NLME-NETWORK-DISCOVERY.request 6
MLME-SET.request(macAssociationPermit = TRUE) MLME-SCAN.request 7
8
Beacon request command (unsecured)
9
Beacon (unsecured)
MLME-SCAN.confirm 10
NLME-NETWORK-DISCOVERY.confirm
11
12
NLME-JOIN.request
13
MLME-ASSOCIATE.request
Association request command 14
MLME-ASSOCIATE.indication
15
16
NLME-JOIN.indication
17
MLME-ASSOCIATE.response
Association response command
18
19
MLME-ASSOCIATE.confirm
NLME-JOIN.confirm
20
21
Joined (unauthenticated) 22
23
Successful Authenticate Routine (see 8.3.2) 24
25
NLME-START-ROUTER.request (only if B is a router) 26
MLME-START.request (only if B is a router) 27
28
Joined (authenticated)
29
30
Figure 4.26 Example of Joining a Secured Network 31
32
The joiner device may begin the join procedure by issuing an NLME- 33
NETWORK-DISCOVERY.request primitive. This primitive will invoke an 34
MLME-SCAN.request primitive which may cause the transmission of an 35
unsecured beacon request frame (depending on whether the scan is an active or 36
passive scan). 37
The joiner device receives beacons from nearby routers and the NWK layer issues 38
an NLME-NETWORK-DISCOVERY.confirm primitive. The NetworkList 39
parameter of this primitive will indicate all of the nearby PANs. In Figure 4.26, 40
the shown router device has already been placed in a state such that its beacons 41
have the “association permit” sub-field set to “1” (permit association). 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 497

The joiner device shall decide which PAN to join and shall issue the NLME-
JOIN.request primitive to join that PAN. If the joiner already has a network key 1
for this PAN, the SecurityEnable parameter for the NLME-JOIN.request primitive 2
shall be set to TRUE; otherwise it shall be set to FALSE. As shown in Figure 4.26, 3
the NLME-JOIN.request primitive causes an association request or rejoin request 4
command to be sent to the router. 5
6
Upon receipt of an association request MAC command, the router shall issue an 7
MLME-ASSOCIATE.indication primitive. Next, the NWK layer will issue an 8
NLME-JOIN.indication primitive to the router’s ZDO. The router shall now know 9
the joiner device's address and security capabilities. The router will also issue an 10
MLME-ASSOCIATE.response. This primitive will cause an association response 11
command to be sent to the joiner. 12
Alternatively, upon receipt of a rejoin request network command, the NWK layer 13
will issue an NLME-JOIN.indication primitive to the router’s ZDO. The router 14
shall now know the joiner device's address, security capabilities, and whether the 15
network key was used to secure the rejoin request command. The router will also 16
issue a rejoin response command to the joiner. 17
18
Upon receipt of the association response MAC command or the rejoin response 19
network command, the joiner shall issue the NLME-JOIN.confirm primitive. The 20
joiner is now declared “joined, but unauthenticated” to the network. The 21
authentication routine (see sub-clause 4.6.3.2) shall follow. 22
If the joiner is not a router, it is declared “joined and authenticated” immediately 23
following the successful completion of the authentication routine. 24
25
If the joiner is a router, it is declared “joined and authenticated” only after the 26
successful completion of the authentication routine followed by the initiation of 27
routing operations. Routing operations shall be initiated by the joiner’s ZDO 28
issuing the NLME-START.request primitive to cause the MLME-START.request 29
primitive to be sent to the MAC layer of the joiner. 30
If the router refuses the joiner, its association response frame or rejoin response 31
frame shall contain the association status field set to a value other than 0x00, and, 32
after this parameter reaches the ZDO of the joiner in the NLME-JOIN.confirm 33
primitive, the joiner shall not begin the authentication routine. 34
35
4.6.3.2 Authentication 36
37
Once a device joins a secured network and is declared “joined but 38
unauthenticated”, it must be authenticated as specified in this sub-clause. In high 39
security mode, neighboring routers must also be authenticated as described in sub- 40
clause 4.4.8. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
498 Security Services Specification

4.6.3.2.1 Router Operation


1
If the router is not the Trust Center, it shall begin the authentication procedure 2
immediately after receipt of the NLME-JOIN.indication primitive by issuing an 3
APSME-UPDATE-DEVICE.request primitive with the DestAddress parameter 4
set to the apsTrustCenterAddress in the AIB and the DeviceAddress parameter set 5
to the address of the newly joined device. The Status parameter of this primitive 6
shall be set by the NLME-JOIN.indication primitive parameters according to 7
Table 4.40. 8
Table 4.40 Mapping of NLME-JOIN.indication Parameters to 9
Update Device Status 10
11
NLME-JOIN.indication Parameters Update Device Status
12
Capability 13
Information RejoinNetwork SecuredJoin Status Description 14
Bit 6 15
0 TRUE FALSE 0x00 Standard security
16
device secured rejoin 17
18
0 FALSE FALSE 0x01 Standard security
19
device unsecured join
20
0 TRUE TRUE 0x03 Standard security 21
device unsecured
22
rejoin
23
1 TRUE FALSE 0x04 High security device 24
secured rejoin 25
1 FALSE FALSE 0x05 High security device 26
unsecured join 27
1 TRUE TRUE 0x07 High security device 28
unsecured rejoin 29
30
If the router is the Trust Center, it shall begin the authentication procedure by 31
simply operating as a Trust Center. 32
33
If initiated by the joining device, the router shall complete the authentication 34
procedure by responding to an entity authentication initiated by the joining device 35
by using APSME-AUTHENTICATION.request with the PartnerAddress 36
parameter set to the joining device address, the Action parameter set to respond, 37
and the RandomChallenge parameter set to a new random value. 38
The router shall not forward messages to a child device, or respond to ZDO 39
requests or NWK command requests on that child's behalf, while the value of the 40
relationship field entry in the corresponding nwkNeighborTable in the NIB is 41
0x05 (unauthenticated child). 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 499

4.6.3.2.2 Trust Center Operation


1
The Trust Center role in the authentication procedure shall be activated upon 2
receipt of an incoming update-device command or immediately after receipt of the 3
NLME-JOIN.indication primitive (in the case where the router is the Trust 4
Center). The Trust Center behaves differently depending on at least five factors: 5
• Whether the Trust Center decides to allow the new device to join the network 6
(for example, the Trust Center is in a mode that allows new devices to join). 7
8
• Whether the Trust Center is operating in residential or commercial mode (see 9
sub-clause 4.6.2.1 and sub-clause 4.6.2.2, respectively). 10
• If in standard security mode, whether the device is joining unsecured or secured 11
and the security capabilities of the joining device as indicated by the Status 12
sub-field of the update-device command. 13
14
• If in high security mode, whether the device is joining unsecured or secured, 15
the security capabilities of the joining device as indicated by the Status sub- 16
field of the update-device command and whether the Trust Center has a master 17
key corresponding to the newly joined device. 18
• The nwkSecureAllFrames attribute of the NIB. 19
20
• The type of the current network key. 21
If, at any time during the authentication procedure, the Trust Center decides not to 22
allow the new device to join the network (for example, a policy decision or a 23
failed key-establishment protocol), it shall take actions to remove the device from 24
the network. If the Trust Center is not the router of the newly joined device, it 25
shall remove the device from the network by issuing the APSME-REMOVE- 26
DEVICE.request primitive with the ParentAddress parameter set to the address of 27
the router originating the update-device command and the ChildAddress 28
parameter set to the address of the joined (but unauthenticated) device. 29
30
4.6.3.2.2.1 Standard Security Mode 31
32
After being activated for the authentication procedure, the Trust Center shall send 33
the device the active network key by issuing the APSME-TRANSPORT- 34
KEY.request primitive with the DestAddress parameter set to the address of the 35
newly joined device, and the KeyType parameter set to 0x01 (that is, standard 36
network key). 37
38
If the joining device already has the network key (that is, the Status sub-field of
39
the update-device command is 0x00), the TransportKeyData sub-parameters shall
40
be set as follows: the KeySeqNumber sub-parameter shall be set to 0, the
41
NetworkKey sub-parameter shall be set to all zeros, and the UseParent sub-
42
parameter shall be set to FALSE.
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
500 Security Services Specification

Otherwise, the KeySeqNumber sub-parameter shall be set to the sequence count


value for the active network key and the NetworkKey sub-parameter shall be set 1
to the active network key. The UseParent sub-parameter shall be set to FALSE if 2
the Trust Center is the router; otherwise, the UseParent sub-parameter shall be set 3
to TRUE and the ParentAddress sub-parameter shall be set to the address of the 4
router originating the update-device command. 5
6
In the case of a joining device that is not pre-configured with an active network 7
key, the issuance of this transport-key primitive will cause the active network key 8
to be sent unsecured from the router to the newly joined device — security is 9
assumed to be present here via non-cryptographic means — for example, by only 10
sending this key once, at low power, immediately after external input to both 11
router and joiner, that can guarantee secrecy and authenticity. If the joining device 12
did not receive the key within apsSecurityTimeOutPeriod, it shall reset and may 13
choose to start the joining procedure again. 14
15
4.6.3.2.2.2 High Security Mode 16
After being activated for the authentication procedure, the Trust Center operation 17
in commercial mode depends on if the device joining the network is preconfigured 18
with a Trust Center master or link key. 19
20
If the Trust Center does not already share a master or link key with the newly 21
joined device, it shall send the device a master or link key by issuing the APSME- 22
TRANSPORT-KEY.request primitive with the DestAddress parameter set to the 23
address of the newly joined device, and the KeyType parameter set to 0x00 or 24
0x04 (that is, Trust Center master or link key). The TransportKeyData sub- 25
parameters shall be set as follows: the Key sub-parameter shall be set to Trust 26
Center master or link key as appropriate, and the ParentAddress sub-parameter 27
shall set to the address of the local device if the Trust Center is the router. 28
Otherwise, the ParentAddress sub-parameter shall set to the address of the router 29
originating the update-device command. The issuance of this primitive will cause 30
the master key to be sent unsecured from the router to the newly joined device— 31
security is assumed to be present here via non-cryptographic means — for 32
example by only sending this key once, at low power, immediately after external 33
input to both router and joiner, etc. 34
If a master key was sent, the Trust Center shall initiate the establishment of a link 35
key by issuing the APSME-ESTABLISH-KEY.request primitive with the 36
ResponderAddress parameter set to the address of the newly joined device and the 37
KeyEstablishmentMethod set to 0x00 (that is, SKKE). Additionally, if the 38
nwkSecureAllFrames attribute of the NIB is FALSE or if the Trust Center is the 39
router, the UseParent parameter shall be set to FALSE. Otherwise, the UseParent 40
parameter shall be set to TRUE and the ResponderParentAddress parameter shall 41
be set to the address of the router originating the update-device command. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 501

Upon receipt of the corresponding APSME-ESTABLISH-KEY.confirm primitive


with Status equal to 0x00 (that is, success), the Trust Center shall send the new 1
device the active network key by issuing the APSME-TRANSPORT-KEY.request 2
primitive with the DestAddress parameter set to the address of the newly joined 3
device, and the KeyType parameter to 0x06 (that is, high security network key 4
transport). The TransportKeyData sub-parameters shall be set as follows: 5
6
• The KeySeqNumber sub-parameter shall be set to the sequence count value for 7
the active network key. 8
• The NetworkKey sub-parameter shall be set to active network key. 9
10
• The UseParent sub-parameter shall be set to FALSE. 11
4.6.3.2.3 Joining Device Operation 12
13
After successfully joining or rejoining a secured network, the joining device shall 14
participate in the authentication procedure described in this sub-clause. Following 15
a successful authentication procedure, the joining device shall set the 16
nwkSecurityLevel and nwkSecureAllFrames attributes in the NIB to the values 17
indicated in the beacon from the router. 18
A joined and authenticated device in a secured network with nwkSecureAllFrames 19
equal to TRUE shall always apply NWK layer security to outgoing (incoming) 20
frames unless the frame is destined for (originated from) a newly joined but 21
unauthenticated child. No such restrictions exist if nwkSecureAllFrames is equal 22
to FALSE. 23
24
The joining device’s participation in the authentication procedure depends on the 25
state of the device. There are at least four possible initial states to consider: 26
• Preconfigured with an active network key (that is, standard security mode). 27
28
• Preconfigured with a Trust Center link key and address (that is, standard 29
security mode). 30
• Preconfigured with a Trust Center master key and address (that is, high security 31
mode). 32
33
• Not preconfigured (that is, undetermined mode — either standard or high 34
security mode). 35
In a secured network, if the device does not become authenticated within a 36
preconfigured amount of time, it shall leave the network (see sub-clause 4.6.3.3). 37
38
4.6.3.2.3.1 Preconfigured Network Key 39
40
If the joining device was preconfigured with only an active network key (and if 41
joining was successful), it shall set the outgoing frame counter for this key to zero, 42
and empty the incoming frame counter set for this key, then wait to receive a 43
dummy (all zero) network key from the Trust Center. Upon receipt of the 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
502 Security Services Specification

APSME-TRANSPORT-KEY.indication primitive with the KeyType parameter set


to 0x01 (that is, the standard network key), the joining device shall set the 1
apsTrustCenterAddress attribute in its AIB to the SrcAddress parameter of the 2
APSME-TRANSPORT-KEY.indication primitive. The joining device is now 3
considered authenticated and shall enter the normal operating state for standard 4
security mode. 5
6
4.6.3.2.3.2 Preconfigured Trust Center Link Key 7
8
If the joining device is preconfigured only with a Trust Center link key and 9
address (that is, the apsTrustCenterAddress attribute in the AIB) it shall wait to 10
receive an active network key from the Trust Center. Upon receipt of the APSME- 11
TRANSPORT-KEY.indication primitive with the KeyType parameter set to 0x01 12
(that is, the standard network key), the joining device shall set the 13
apsTrustCenterAddress attribute in its AIB to the SrcAddress parameter of the 14
APSME-TRANSPORT-KEY.indication primitive. The joining device is now 15
considered authenticated and shall enter the normal operating state for standard 16
security mode. 17
18
4.6.3.2.3.3 Preconfigured Trust Center Master Key 19
20
If the joining device is preconfigured with a Trust Center master key and address 21
(that is, the apsTrustCenterAddress attribute in the AIB) it shall wait to establish a 22
link key and receive an active network key from the Trust Center. Therefore, upon 23
receipt of the APSME-ESTABLISH-KEY.indication primitive with the 24
InitiatorAddress parameter set to the Trust Center's address and the 25
KeyEstablishmentMethod parameter set to SKKE, the joining device shall 26
respond with the APSME-ESTABLISH-KEY.response primitive with the 27
InitiatorAddress parameter set to the Trust Center's address and the Accept 28
parameter set to TRUE. After receipt of the APSME-ESTABLISH-KEY.confirm 29
primitive with the Address parameter set to the Trust Center’s address and the 30
Status parameter set to 0x00 (that is, success), the joining device shall expect to 31
receive the active network key. If the joining device does not receive the APSME- 32
ESTABLISH-KEY.indication primitive with the InitiatorAddress parameter set to 33
the Trust Center’s address and the KeyEstablishmentMethod parameter set to 34
SKKE within apsSecurityTimeOutPeriod, it shall reset and may choose to start the 35
joining procedure again. 36
If a joining device has a Trust Center link key, upon receipt of the APSME- 37
TRANSPORT- KEY.indication primitive with SourceAddress parameter set to the 38
Trust Center's address and with the KeyType parameter set 0x05 (that is, a high 39
security network key), the device shall use the data in the TransportKeyData 40
parameter to configure the active network key. 41
42
The authentication procedure shall be completed by the joining device initiating 43
an entity authentication with the router by using the APSME- 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 503

AUTHENTICATION.request with the PartnerAddress parameter set to the router


address, the Action parameter set to initiate, and the RandomChallenge parameter 1
set to a new random value. The router will then respond with an APSME- 2
AUTHENTICATION.request with the PartnerAddress parameter set to the joining 3
device address, the Action parameter set to respond, and the RandomChallenge 4
parameter set to a new random value. 5
6
The joining device is now considered authenticated and shall enter the normal 7
operating state for high security mode. 8
9
4.6.3.2.3.4 Not Preconfigured 10
If the joining device is not preconfigured with an active network key, nor a Trust 11
Center master or link key and address (that is, the apsTrustCenterAddress attribute 12
in the AIB), it shall wait to receive either an unsecured Trust Center master or link 13
key or an active network key. Implementers should note that transmission of an 14
unsecured key represents a security risk and that if security is a concern, keys 15
should be preconfigured – preferably via an out-of-band mechanism that 16
guarantees secrecy and authenticity. If the joining device does not receive any of 17
the keys within apsSecurityTimeOutPeriod, it shall reset and may choose to start 18
the joining procedure again. 19
20
Upon receipt of the APSME-TRANSPORT-KEY.indication primitive with the 21
KeyType parameter set to 0x01 (that is, a standard network key), the joining 22
device shall make the data in the TransportKeyData parameter its active network 23
key and shall set the apsTrustCenterAddress attribute in its AIB to the SrcAddress 24
parameter of the APSME-TRANSPORT-KEY.indication primitive. The joining 25
device is now considered authenticated and shall enter the normal operating state 26
for standard security mode. 27
Upon receipt of the APSME-TRANSPORT-KEY.indication primitive with the 28
KeyType parameter set to 0x04 (that is, the Trust Center link key), the joining 29
device shall make its Trust Center link key the data in the TransportKeyData 30
parameter and the apsTrustCenterAddress attribute in its AIB the SrcAddress 31
parameter. If the APSME-TRANSPORT-KEY.indication primitive 32
SourceAddress parameter is set to the Trust Center's address and the KeyType 33
parameter is set to 0x01 (that is, the standard network key), the joining device 34
shall use the data in the TransportKeyData parameter to configure the active 35
network key. All incoming frame counters and the outgoing frame counter of the 36
active network key shall be set to 0. The joining device is now considered 37
authenticated and shall enter the normal operating state for standard security 38
mode. 39
40
Upon receipt of the APSME-TRANSPORT-KEY.indication primitive with the 41
KeyType parameter set to 0x00 (that is, the Trust Center master key), the joining 42
device shall make its Trust Center master key the data in the TransportKeyData 43
parameter and the apsTrustCenterAddress attribute in its AIB the SrcAddress 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
504 Security Services Specification

parameter. Next, upon receipt of the APSME-ESTABLISH-KEY.indication


primitive with the InitiatorAddress parameter set to the Trust Center's address and 1
the KeyEstablishmentMethod parameter set to SKKE, the joining device shall 2
respond with the APSME-ESTABLISH-KEY.response primitive with the 3
InitiatorAddress parameter set to the Trust Center's address and the Accept 4
parameter set to TRUE. After receipt of the APSME-ESTABLISH-KEY.confirm 5
primitive with the Address parameter set to the Trust Center's address and the 6
Status parameter set to 0x00 (that is, success), the joining device shall expect to 7
receive the active network key. If the APSME-TRANSPORT-KEY.indication 8
primitive is SourceAddress parameter is set to the Trust Center's address and the 9
KeyType parameter is set to 0x05 (that is, the high security network key), the 10
joining device shall use the data in the TransportKeyData parameter to configure 11
the active network key. The authentication procedure shall be completed by the 12
joining device initiating an entity authentication with the router by using APSME- 13
AUTHENTICATION.request with the PartnerAddress parameter set to the router 14
address, the Action parameter set to initiate, and the RandomChallenge parameter 15
set to a new random value. The router will then respond with a APSME- 16
AUTHENTICATION.request with the PartnerAddress parameter set to the joining 17
device address, the Action parameter set to respond, and the RandomChallenge 18
parameter set to a new random value. The joining device is now considered 19
authenticated and shall enter the normal operating state for commercial mode. 20
21
22
Trust Center Router Joiner
23
24
Joined (unauthenticated)
25
Update-Device Command 26
27
Decision to accept 28
new device
29
Secured Transport-Key Command(NWK key)
1
1
30
Unsecured Transport-Key Command(NWK key) 31
Joined (authenticated)
32
33
Note: 34
1. The trust center sends a dummy all-zero NWK key if the joiner securely joined using a preconfigured network key.
35
36
Figure 4.27 Example Standard Security Mode Authentication Procedure
37
4.6.3.2.4 Neighboring Device Authentication 38
39
If a neighboring device attempts to communicate and the neighboring device is 40
unknown and the device is in high security mode and frame counter checking is in 41
place, the communication will be rejected as the frame counter has not been 42
initialized. The neighboring device shall be authenticated by initiating an entity 43
authentication with the it by using APSME-AUTHENTICATION.request with the 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 505

PartnerAddress parameter set to the neighboring device address, the Action


parameter set to initiate, and the RandomChallenge parameter set to a new 1
random value. The APSME-AUTHENTICATION.request will be sent with 2
random jitter. The neighboring device will then respond with a APSME- 3
AUTHENTICATION.request with the PartnerAddress parameter set to the device 4
address, the Action parameter set to respond, and the RandomChallenge 5
parameter set to a new random value. The neighboring device is now considered 6
authenticated.48 7
8
4.6.3.2.5 Message Sequence Charts 9
Figure 4.27 and 4.28 give example message sequence charts for the authentication 10
procedure when the router and the Trust Center are separate devices operating in 11
standard or high security mode, respectively. 12
13
In Figure 4.27 the update-device and transport-key commands communicated 14
between the Trust Center and the router shall be secured at the APS layer based on 15
the active network key. The transport-key command sent from the router to the 16
joiner shall not be secured. 17
In Figure 4.28, the update-device and transport-key commands communicated 18
between the Trust Center and the router shall be secured at the APS layer based on 19
the Trust Center link key. If the nwkSecureAllFrames NIB attribute is TRUE, it is 20
also secured at the NWK layer with the active network key. The transport-key 21
command sent from the router to the joiner shall not be secured. The SKKE 22
commands shall be sent using the router as a liaison when the 23
nwkSecureAllFrames NIB attribute is TRUE, such that SKKE commands between 24
the Trust Center and the router shall be secured at the NWK layer with the active 25
network key and commands between the router and the joiner shall not be 26
secured. Otherwise, the SKKE commands shall be unsecured between the Trust 27
Center and the joiner. The final transport-key communicated between the Trust 28
Center and the joiner shall be secured at the APS layer, based on the Trust Center 29
link key and, if the nwkSecureAllFrames NIB attribute is TRUE, also secured at 30
the NWK layer with the active network key. 31
32
33
34
35
36
37
38
39
40
41
42
43
48. CCB #674 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
506 Security Services Specification

Trust Center Router Joiner


1
2
Joined (unauthenticated)
3
4
5
Update-Device Command
6
7
Decision to accept
new device
8
9
Secured Transport-Key Command (Master key)1
10
Unsecured Transport-Key Command (Master key)1 11
SKKE-1 Command
12
13
SKKE-2 Command 14
See
Note 2 15
SKKE-3 Command
16
SKKE-4 Command 17
Secured Transport-Key Command (NWK key) 18
19
EA Initiator Challenge 20
EA Responder Challenge 21
22
EA Initiator MAC and data
23
EA Responder MAC and data 24
25
Joined (authenticated) 26
27
28
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). 29
2. SKKE commands shall be sent using the router as a liason when the nwkSecureAllFrame NIB attribute is TRUE (i.e., these
commands will be secured between the trust center and router at the NWK layer, but not between the router and joiner). 30
31
32
Figure 4.28 Example High Security Mode Authentication Procedure 33
34
4.6.3.3 Intra-PAN Portability 35
Devices shall follow the procedures described in this sub-clause as necessary to 36
support portability, in conjunction with the mechanism described in sub-clause 37
2.5.5.5.2.2. 38
39
At present, the security support for intra-PAN portability is minimized. In most 40
cases security operation is not different from normal, as described in these 41
sections. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 507

4.6.3.3.1 Router Operation


1
This text describes the security operations for support of intra-PAN security which 2
are to be carried out by the ZigBee coordinator and by ZigBee routers. 3
Following the steps described in sub-clause 2.5.5.5.2.2, an orphaned device shall 4
be provisionally accepted onto the network for at least apsSecurityTimeOutPeriod 5
milliseconds. During this period it shall be required to send at least one correctly 6
formed ZigBee message secured with the network key to the new parent. If this 7
message successfully passes all the security processing steps described in this 8
document, it shall be accepted as a member of the network. 9
10
This specification neither specifies nor requires any action from the parent in the 11
case that a message from an orphaned device fails security processing above that 12
required by text elsewhere in this document. 13
4.6.3.3.2 End-Device Operation 14
15
Following the steps described in sub-clause 2.5.5.5.2.2, an orphaned device shall 16
be provisionally accepted onto the network for at least apsSecurityTimeOutPeriod 17
milliseconds. During this period, it shall be required to send at least one ZigBee 18
message, secured with the network key to the new parent. Further, it shall verify 19
that at least one ZigBee message, secured using the current network key is 20
received from the new parent. If this message successfully passes all the security 21
processing steps described in this document, the device shall operate as a member 22
of the network. If this protocol cannot be completed correctly, the device shall 23
abandon this attempt to rejoin the network using this parent. 24
As normal, when operating in standard security mode the end device shall not 25
accept an unsecured network key from the Trust Center, except as required by this 26
document when activated to join a new network. 27
28
As normal, when operating in high security mode the end device shall be 29
configured to accept an updated network key from the Trust Center, even when 30
not activated for the authentication procedure. In this case, the key shall be 31
transported using the APSME-TRANSPORT-KEY.request primitive, and 32
appropriate security shall be verified. 33
Note that a ZigBee router may also carry out an orphan scan as described in sub- 34
clause 2.5.5.5.2.2. In this case it shall, at this time, also follow the steps described 35
in this sub-section. 36
37
4.6.3.4 Network Key Update 38
39
The Trust Center and network devices shall follow the procedures described in 40
this sub-clause when updating the active network key. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
508 Security Services Specification

4.6.3.4.1 Trust Center Operation


1
When updating a standard network key with a new key of the same type, the Trust 2
Center may broadcast the new key to all devices on the network by issuing the 3
APSME-TRANSPORT-KEY.request primitive with the DestAddress parameter 4
set to the broadcast address and the KeyType parameter set to 0x01 (that is, a 5
standard network key). The TransportKeyData sub-parameters shall be set as 6
follows: 7
• The KeySeqNumber sub-parameter shall be set to the sequence count value for 8
the new network key. 9
10
• The NetworkKey sub-parameter shall be set to the new network key. 11
• The UseParent sub-parameter shall be set to FALSE. 12
13
If the sequence count for the previously distributed network key is represented as 14
N, then the sequence count for this new network key shall be (N+1) mod 256. The 15
Trust Center may cause a switch to this new key by issuing the APSME- 16
SWITCH-KEY.request primitive with the DestAddress parameter set to the 17
broadcast address and the KeySeqNumber parameter set to the sequence count 18
value for the updated network key. 19
In standard security mode, the Trust Center may maintain a list of all of the 20
devices in the network; in high security mode, the Trust Center shall maintain 21
such a list. To update the active network key using this list, the Trust Center shall 22
first send the new network key to each device on this list and then ask each device 23
to switch to the new key. The new network key shall be sent to a device on the list 24
by issuing the APSME-TRANSPORT-KEY.request primitive with the 25
DestAddress parameter set to the address of the device on the list and the 26
KeyType parameter set to 0x05 (that is, a high security network key). The 27
TransportKeyData sub-parameters shall be set as follows: 28
29
• The KeySeqNumber sub-parameter shall be set to the sequence count value for 30
the new network key. 31
• The NetworkKey sub-parameter shall be set to the new network key. 32
33
• The UseParent sub-parameter shall be set to FALSE. 34
If the sequence count for the previously distributed network key is represented as 35
N, then the sequence count for this new network key shall be (N+1) mod 256. The 36
Trust Center shall ask a device to switch to this new key by issuing the APSME- 37
SWITCH-KEY.request primitive with the DestAddress parameter set to the 38
address of the device and the KeySeqNumber parameter set to the sequence count 39
value for the updated network key. 40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 509

4.6.3.4.2 Network Device Operation


1
When in the normal operating state and upon receipt of a APSME-TRANSPORT- 2
KEY.indication primitive with the KeyType parameter set to 0x01 or 0x05 (that is, 3
a network key), a device shall accept the TransportKeyData parameters as a 4
network key only if the SrcAddress parameter is the same as the Trust Center’s 5
address (as maintained in the apsTrustCenterAddress attribute of the AIB). If 6
accepted and if the device is capable of storing an alternate network key, the key 7
and sequence number data contained in the TransportKeyData parameter shall 8
replace the alternate network key. Otherwise, the key and sequence number data 9
contained in the TransportKeyData parameter shall replace the active network 10
key. In either case, all incoming frame counters and the outgoing frame counter of 11
the appropriate network key shall be set to 0. 12
When in the normal operating state and upon receipt of a APSME-SWITCH- 13
KEY.indication primitive, a device shall switch its active network key to the one 14
designated by the KeySeqNumber parameter only if the SrcAddress parameter is 15
the same as the Trust Center’s address (as maintained in the 16
apsTrustCenterAddress attribute of the AIB). 17
18
19
Trust Center Device 1 Device 2
20
Transport-Key Command(NWK key, N) 21
22
Replace alternate network
key with network key N.
23
24
Transport-Key Command(NWK key, N)
25
Switch-Key Command(N) Replace active network 26
key with network key N. 27
Make network key N the 28
active network key.
29
Switch-Key Command(N)
30
31
Ignore command.
32
33
Figure 4.29 Example Network Key-Update Procedure 34
35
4.6.3.4.3 Message Sequence Chart 36
37
An example of a successful network key-update procedure for two devices is 38
shown in Figure 4.29. In this example, the Trust Center sends a network key with 39
sequence number N to devices 1 and 2. In this example, device 1 is an FFD 40
capable of storing two network keys, an active and alternate, and device 2 is an 41
RFD that can store only a single network key. Upon receipt of the transport-key 42
command, device 1 replaces its alternate network key with the new network key; 43
however device 2 must replace its active network key with the new key. Next, 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
510 Security Services Specification

upon receipt of the switch-key command, device 1 makes the new network key
the active network key; however device 2 has only one active network key, so it 1
ignores this command. 2
3
4.6.3.5 End-to-End Application Key Establishment 4
5
An initiator device, a Trust Center, and a responder device shall follow the 6
procedures described in this sub-clause when establishing a link key for purposes 7
of end-to-end application security between initiator and responder devices. 8
4.6.3.5.1 Device Operation 9
10
The initiator device shall begin the procedure to establish a link key with a 11
responder device by issuing the APSME-REQUEST-KEY.request primitive. The 12
DestAddress parameter shall be set to the address of its Trust Center, the KeyType 13
parameter shall be set to 0x02 (that is, application key), and the PartnerAddress 14
parameter shall be set to the address of the responder device. 15
16
4.6.3.5.1.1 Upon Receipt of a Link Key 17
18
Upon receipt of an APSME-TRANSPORT-KEY.indication primitive with the 19
KeyType parameter set to 0x03 (that is, application link key), a device may accept 20
the TransportKeyData parameters as a link key with the device indicated by the 21
PartnerAddress parameter only if the SrcAddress parameter is the same as the 22
apsTrustCenterAddress attribute of the AIB. If accepted, the 23
apsDeviceKeyPairSet attribute in AIB table will be updated. A key-pair descriptor 24
in the AIB shall be created (or updated if already present) for the device indicated 25
by the PartnerAddress parameter, by setting the DeviceAddress element to the 26
PartnerAddress parameter, the LinkKey element to the link key from the 27
TransportKeyData parameter, and the OutgoingFrameCounter and 28
IncomingFrameCounter elements to 0. 29
30
4.6.3.5.1.2 Upon Receipt of a Master Key 31
Upon receipt of an APSME-TRANSPORT-KEY.indication primitive with the 32
KeyType parameter set to 0x02 (that is, application master key), a device may 33
accept the TransportKeyData parameters as a master key with the device indicated 34
by the PartnerAddress sub-parameter only if the SrcAddress parameter is the same 35
as the apsTrustCenterAddress attribute of the AIB. If accepted, the 36
apsDeviceKeyPairSet attribute in AIB table will be updated. A key-pair descriptor 37
shall be created (or updated if already present) for the device indicated by the 38
PartnerAddress parameter, by setting the DeviceAddress element to the 39
PartnerAddress parameter, the MasterKey element to the master key from the 40
TransportKeyData parameter, and the OutgoingFrameCounter and 41
IncomingFrameCounter elements to 0. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 511

Next, if the Initiator sub-parameter of the TransportKeyData parameter of the


APSME-TRANSPORT-KEY.indication primitive was TRUE, the device shall 1
issue the APSME-ESTABLISH-KEY.request primitive. The ResponderAddress 2
parameter shall be set to the PartnerAddress sub-parameter of the 3
TransportKeyData parameter, the UseParent parameter shall be set to FALSE, and 4
the KeyEstablishmentMethod parameter shall be set to 0x00 (that is, SKKE). 5
6
Upon receipt of the APSME-ESTABLISH-KEY.indication primitive, the 7
responder device shall be informed that the initiator device wishes to establish a 8
link key. If the responder decides to establish a link key, it shall issue the APSME- 9
ESTABLISH-KEY.response primitive with the InitiatorAddress parameter set to 10
the address of the initiator and the Accept parameter set to TRUE. Otherwise, it 11
shall set the Accept parameter set to FALSE. 12
If the responder decided to set up a key with the initiator, the SKKE protocol will 13
ensue and the APSME-ESTABLISH-KEY.confirm primitive will be issued to 14
both the responder and initiator. 15
16
4.6.3.5.2 Trust Center Operation 17
Upon receipt of APSME-REQUEST-KEY.indication primitives with the KeyType 18
parameter set to 0x02 (that is, application key), the Trust Center behavior depends 19
on whether it has been configured to send out application link keys or master keys. 20
21
The Trust Center shall issue two APSME-TRANSPORT-KEY.request primitives. 22
If configured to send out application link keys the KeyType parameter shall be set 23
to 0x03 (that is, application link key); otherwise, the KeyType parameter shall be 24
set to 0x02 (that is, application master key). The first primitive shall have the 25
DestAddress parameter set to the address of the device requesting the key. The 26
TransportKeyData sub-parameters shall be set as follows: 27
• The PartnerAddress sub-parameter shall be set to the PartnerAddress sub- 28
parameter of the APSME-REQUEST-KEY.indication primitive’s 29
TransportKeyData parameter. 30
31
• The Initiator sub-parameter shall be set to TRUE. 32
• The Key sub-parameter shall be set to a new key K (a master or link key). 33
34
The key shall have been generated in a random fashion. The second primitive 35
shall have the DestAddress parameter set to the PartnerAddress sub-parameter of 36
the APSME-REQUEST-KEY.indication primitive’s TransportKeyData parameter. 37
The TransportKeyData sub-parameters shall be set as follows: 38
• The PartnerAddress sub-parameter shall be set to the address of the device 39
requesting the key. 40
41
• The Initiator sub-parameter shall be set to FALSE. 42
• The Key sub-parameter shall be set to K. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
512 Security Services Specification

4.6.3.5.3 Message Sequence Chart


1
An example message sequence chart of the end-to-end application key 2
establishment procedure is shown in Figure 4.30. The procedure begins with the 3
transmission of the request-key command from the initiator to the Trust Center. 4
Next, the Trust Center starts a time-out timer. For the duration of this timer (that 5
is, until it expires), the Trust Center shall discard any new request-key commands 6
for this pair of devices unless they are from the initiator. 7
The Trust Center shall now send transport-key commands containing the 8
application link or master key to the initiator and responder devices. Only the 9
initiator’s transport-key command will have the Initiator field set to 1 (that is, 10
TRUE), so if a master key was sent, only the initiator device will begin the key- 11
establishment protocol by sending the SKKE-1 command. If the responder 12
decides to accept establishing a key with the initiator, the SKKE protocol will 13
progress via the exchange of the SKKE-2, SKKE-3, and SKKE-4 commands. 14
Upon completion (or time-out), the status of the protocol is reported to the ZDOs 15
of the initiator and responder devices. If successful, the initiator and responder 16
will now share a link key and secure communications will be possible. 17
18
19
Responder
Initiator Trust Center
20
Learn address of responder via discovery 21
or other means (e.g., preloaded) 22
Request-Key Command(key, responder address) 23
24
Start a timer and send a link or master key to initiator and responder. The
trust center shall discard new request-key commands for this pair of 25
devices, unless they are from the initiator, until after the timer expires. 26
Transport-Key Command(key, Initiator=TRUE, 27
PartnerAddress = Responder’s address) Transport-Key Command(key, Initiator=FALSE, 28
PartnerAddress = Initiator’s address)
29
Stores key and, if a master key, Decides whether
30
initiates key establishment to the store key 31
32
SKKE-1 Command
33
Responder decides whether to run 34
key-establishment protocol
35
SKKE-2 Command 36
SKKE-3 Command 37
38
SKKE-4 Command
39
Status of SKKE reported to ZDO Status of SKKE reported to ZDO 40
41
42
Figure 4.30 Example End-to-End Application Key Establishment Procedure 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 513

4.6.3.6 Network Leave


1
A device, its router, and the Trust Center shall follow the procedures described in 2
this sub-clause when the device is to leave the network. 3
4
4.6.3.6.1 Trust Center Operation
5
If a Trust Center wants a device to leave and if the Trust Center is not the router 6
for that device, the Trust Center shall issue the APSME-REMOVE- 7
DEVICE.request primitive, with the ParentAddress parameter set to the router’s 8
address and the ChildAddress parameter set to the address of the device it wishes 9
to leave the network. 10
11
The Trust Center will also be informed of devices that leave the network. Upon 12
receipt of an APSME-UPDATE-DEVICE.indication primitive with the Status 13
parameter set to 0x02 (that is, device left), the DeviceAddress parameter shall 14
indicate the address of the device that left the network and the SrcAddress 15
parameter shall indicate the address of parent of this device. If operating in high 16
security mode, the Trust Center shall delete the leaving device from its list of 17
network devices. 18
4.6.3.6.2 Router Operation 19
20
Routers are responsible for receiving remove-device commands and for sending 21
update-device commands. 22
Upon receipt of an APSME-REMOVE-DEVICE.indication primitive, if the 23
SrcAddress parameter is equal to the apsTrustCenterAddress attribute of the AIB 24
and the neighbor table entry corresponding to DeviceAddress indicates that it has 25
the network key, a router shall issue an NLME-LEAVE.request primitive with the 26
DeviceAddress parameter the same as the DeviceAddress parameter of the 27
APSME-REMOVE-DEVICE.indication primitive and the rejoin parameter set to 28
0. Other fields are defined by the stack profile. The router shall ignore APSME- 29
REMOVE-DEVICE.indication primitives with the SrcAddress parameter not 30
equal to the apsTrustCenterAddress attribute of the AIB. 31
32
Upon receipt of an NLME-LEAVE.indication primitive with the DeviceAddress 33
parameter set to one of its children, a router that is not also the Trust Center shall 34
issue an APSME-UPDATE-DEVICE.request primitive with: 35
• The DstAddress parameter set to the address of the Trust Center. 36
37
• The Status parameter set to 0x02 (that is, device left). 38
• The DeviceAddress parameter set to the DeviceAddress parameter of the 39
NLME-LEAVE.indication primitive. 40
41
If the router is the Trust Center, it should simply operate as the Trust Center and 42
shall not issue the APSME-UPDATE-DEVICE.request primitive (see sub- 43
clause 4.6.3.6.1). 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
514 Security Services Specification

4.6.3.6.3 Leaving Device Operation


1
Devices are responsible for receiving and sending leave commands. 2
In a secured ZigBee network, leave commands shall be secured with the active 3
network key and sent with security enabled at the level indicated by the 4
nwkSecurityLevel attribute in the NIB. 5
6
In a secured ZigBee network, leave commands shall be received and processed 7
only if secured with the active network key and received with security enabled at 8
the level indicated by the nwkSecurityLevel attribute in the NIB. 9
4.6.3.6.4 Message Sequence Charts 10
11
Figure 4.31 shows an example message sequence chart in which a Trust Center 12
asks a router to remove one of its children from the network. If a Trust Center 13
wants a device to leave and if the Trust Center is not the router for that device, the 14
Trust Center shall send the router a remove-device command with the address of 15
the device it wishes to leave the network. In a secure network, the remove-device 16
command shall be secured with a link key if present; otherwise shall be secured 17
with the active network key. Upon receipt of the remove-device command, a 18
router shall send a leave command to the device to leave the network. 19
20
!"   

21
22


 
23
24
 
 
25
26

 
    
   
     

   
27
  

    
     28
    
 
  
      29
30
Figure 4.31 Example Remove-Device Procedure 31
32
Figure 4.32 shows an example message sequence chart whereby a device notifies 33
its router that it is leaving the network. In this example, the device sends a leave 34
command (secured with the active network key) to its router. The router then 35
sends a update-device command to the Trust Center. In a secured network, the 36
update-device command must be secured with the link key, if present, or the 37
active network key. 38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 515

    



1
  
2

 
3
4
5
 


    
 
6
7
  
  
   
    
  


  8
9
Figure 4.32 Example Device-Leave Procedure
10
4.6.3.6.5 Trust Center Operation 11
12
In this specification, there is no special additional role for the Trust Center above 13
that of other routing devices. 14
15
As normal, when operating in standard security mode the Trust Center shall not
16
issue or reissue a network key unsecured to orphaned devices, except when
17
activated for the authentication procedure.
18
As normal, when operating in high security mode the Trust Center may optionally 19
issue or reissue the current or an updated network key to orphaned devices when 20
not activated for the authentication procedure. In this case, the key shall be 21
transported using the APSME-TRANSPORT-KEY.request primitive, and shall be 22
secured appropriately. Initiation of such an update is beyond the scope of this 23
specification. 24
25
4.6.3.7 Command Tunnelling 26
27
Devices shall follow the procedures described in this sub-clause to allow secure
28
communication between the Trust Center and a remote device that does not have
29
the current network key.
30
4.6.3.7.1 Trust Center Operation 31
32
To embed a command in a tunnel command, the Trust Center shall first apply 33
security protection as specified in sub-clause 4.4.1.1 and then, if security 34
processing succeeds, the secured command frame shall be embedded in a Tunnel 35
command frame as follows: 36
1 The APS header fields shall be set to the values of the APS header fields of the 37
command to be embedded. 38
39
2 The destination address field shall be set to the 64-bit extended address of the 40
destination device. 41
3 The tunnelled auxiliary frame field shall be set to the auxiliary frame of the 42
secured command, with following changes: 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
516 Security Services Specification

• The extended nonce sub-field shall be set to 1;


1
• The source address field shall be set to the 64-bit extended address of the 2
Trust Center; 3
• The tunnelled command shall be set to the secured payload of the embedded 4
command. 5
6
The tunnelled command shall then be sent to the parent or other neighbor of the 7
destination device. 8
4.6.3.7.2 Router Operations 9
10
Upon receipt of an APS tunnel command, a router shall extract the embedded 11
command as follows: 12
1 The APS header fields shall be set to the values of the APS header fields of the 13
tunnel command. 14
15
2 The auxiliary frame field shall be set to the value of the tunnelled auxiliary 16
frame field of the tunnel command. 17
3 The APS payload field shall be set to the tunnelled command field of the tunnel 18
command. 19
20
The extracted command shall be sent to the destination indicated by the 21
destination address field by issuing the NLDE-DATA.request primitive with 22
security disabled. 23
4.6.3.7.3 Destination Operation 24
25
Upon receipt of a message secured at the APS layer and with an extended nonce in 26
the APS auxiliary frame, the message shall be processed as usual, except that the 27
message shall not be looked up in, or added to, the APS duplicate rejection table. 28
29
4.6.3.8 Permissions Configuration Table 30
31
The permissions configuration table in Table 4.41 indicates which devices have
32
authorization to carry out certain types of commands, and determines in each case
33
whether or not link key security is required. Values in the table are expected to be
34
populated by the next higher layer, and are checked as indicated below for
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 517

incoming commands. If an incoming command is not permitted, then it shall not


be carried out, and an error message may be sent to the source. 1
2
Table 4.41 Elements of the Permissions Configuration Table
3
Name Type Range Description Default 4
5
ModifyPermissi Permissions - Permission to modify this - 6
onsConfigurati descriptor, table.
onTable see 7
Table 4.42. 8
9
NetworkSetting Permissions - Permission to configure -
s descriptor, network startup and join 10
see parameters, including direct 11
Table 4.42. join, permit join, leave, 12
network maintenance and reset. 13
ApplicationSett Permissions - Permission to configure - 14
ings descriptor, application settings, including 15
see bindings and groups, and other 16
Table 4.42. application configuration 17
commands.
18
SecuritySetting Permissions - Permission to configure - 19
s descriptor, security settings. 20
see
Table 4.42.
21
22
ApplicationCo Permissions - Permission to issue application - 23
mmands descriptor, layer commands.
24
see
Table 4.42. 25
26
Reserved Permissions - Reserved. -
27
descriptor,
see 28
Table 4.42. 29
30
Reserved Permissions - Reserved. -
descriptor, 31
see 32
Table 4.42. 33
SKKEWithMas List of Any valid Permission to use SKKE to - 34
terKey device 64-bit generate a new trust centre link 35
addresses. address or key, where supported. 36
0xFFFFFFF 37
FFFFFFFFF 38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
518 Security Services Specification

Table 4.42 Elements of the Permissions Descriptor


1
Name Type Range Description Default 2
AuthorizedDevi List of - List of valid 64-bit addresses for 0xFFFFFFF 3
ceList device each allowed devices or single FFFFFFFFF 4
addresses entry of 0xFFFFFFFFFFFFFFF 5
indicating all devices are 6
allowed.
7
LinkKeyRequir Boolean TRUE | Indicates whether a link key is FALSE 8
ed FALSE required to accept command. 9
10
4.6.3.8.1 Services 11
12
The groups of services listed in the permissions configuration table are described
13
in detail here.
14
• The ModifyPermissionsConfigurationTable entry is available to be used by the 15
next higher layer to determine whether a request to modify this table is 16
permitted. 17
18
• The NetworkSettings entry shall be used by the ZDO, and optionally by the
19
next higher layer, to determine whether certain networking-related
20
configuration commands are permitted. The ZDO commands which shall be
21
subject to this table entry are the Mgmt_Direct_Join_req,
22
Mgmt_Permit_Join_req, and Mgmt_Leave_req commands.
23
• The ApplicationSettings entry shall be used by the ZDO, and optionally by the 24
next higher layer, to determine whether certain application-related 25
configuration commands are permitted. The ZDO commands which shall be 26
subject to this table entry are the Bind_req and Unbind_req commands. 27
28
• The SecuritySettings entry is available to be used by the next higher layer to
29
determine whether specified security-related configuration commands are
30
permitted.
31
• The ApplicationCommands entry is available to be used by the next higher 32
layer to determine whether specified application commands are permitted. 33
34
• The SKKEWithMasterKey entry shall be used to optionally restrict which
35
devices are permitted to initiate an SKKE transaction using the Trust Center
36
master key, in order to generate a new Trust Center link key. This table entry
37
has no effect on devices where SKKE is not implemented.
38
4.6.3.8.2 Usage Details 39
40
Incoming commands shall invoke a permissions check where specified, and on 41
failure the incoming command shall not be carried out. Any error message sent on 42
failure of a permissions check shall be defined in the specification of the relevant 43
command. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 519

The AuthorizedDevicesList of each entry shall contain a list of the IEEE


addresses of authorized devices, or alternatively may contain only the value 1
0xFFFFFFFFFFFFFFFF, indicating that all devices are permitted to carry out the 2
corresponding commands if properly secured. 3
4
Where specified above, table entries can be checked by higher layers in addition 5
to any checks mandated within this specification. The details of higher layer 6
checks and any associated error messages are beyond the scope of this 7
specification. 8
Incoming commands secured with the Trust Center link key are assumed to come 9
from the Trust Center, and so are exempt from all the checks described here, and 10
shall always be permitted if properly secured. This exemption has no effect for 11
devices without a Trust Center link key. 12
13
This table is optional and where supported shall contain an empty set for the 14
ModifyPermissionsConfigurationTable and SKKEWithMasterKey entries, to 15
indicate that these services cannot be used, and all other entries shall have the 16
AuthorizedDeviceList entry of the permissions descriptor set to a single value of 17
0xFFFFFFFFFFFFFFFF to indicate that no devices are restricted. 18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter 4
520 Security Services Specification

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
This page intentionally blank 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 521

A N N E X
1

A
2
3
4
5
6
7
8
9

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 having a 128-bit block size, such 15
as AES-128 [B8]. The CCM* principles can easily be extended to other block 16
sizes, but doing so will require further definitions. 17
The CCM* mode coincides with the original CCM mode specification [B21] 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([B22] 21
and [B23]) carries over to the CCM* mode described here. The design of the 22
CCM* mode takes into account the results of [B24], thus allowing it to be 23
securely used in implementation environments in which the use of variable-length 24
authentication tags, rather than fixed-length authentication tags only, is beneficial. 25
26
Prerequisites: The following are the prerequisites for the operation of the generic 27
CCM* mode: 28
1 A block-cipher encryption function E shall have been chosen, with a 128-bit 29
block size. The length in bits of the keys used by the chosen encryption 30
function is denoted by keylen. 31
32
2 A fixed representation of octets as binary strings shall have been chosen (for 33
example, most-significant-bit first order or least-significant-bit-first order). 34
3 The length L of the message length field, in octets, shall have been chosen. 35
Valid values for L are the integers 2, 3,..., 8 (the value L=1 is reserved). 36
37
4 The length M of the authentication field, in octets, shall have been chosen. 38
Valid values for M are the integers 0, 4, 6, 8, 10, 12, 14, and 16. (The value 39
M=0 corresponds to disabling authenticity, since then the authentication field 40
contains an empty string.) 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex A
522 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) < 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 value of M actually used. 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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 523

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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex A
524 CCM* Mode of Operation

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 follows:
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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 525

Note that this definition ensures that all the Ai fields are distinct from the B0
fields that are actually used, as those have a Flags field with a non-zero 1
encoding of M in the positions where all Ai fields have an all-zero encoding of 2
the integer 0 (see sub-clause A.2.2, step 1). 3
4
Parse the message PlaintextData as M1 || ... ||Mt, where each message block Mi 5
is a 16-octet string. 6
The ciphertext blocks C1, ... , Ct are defined by: 7
8
Ci:= E(Key, Ai) Mi for i=1, 2, ... , t 9
10
11
The string Ciphertext is the result of omitting all but the leftmost l(m) octets of 12
the string C1 || ... || Ct 13
Define the 16-octet encryption block S0 by: 14
15
S0:= E(Key, A0) 16
17
2 The encrypted authentication tag U is the result of XOR-ing the string 18
consisting of the leftmost M octets of S0 and the authentication tag T. 19
20
Output: If any of the above operations has failed, then output ‘invalid’. 21
Otherwise, output the right-concatenation of the encrypted message Ciphertext 22
and the encrypted authentication tag U. 23
24
25
A.3 CCM* Mode Decryption and Authentication 26
Checking Transformation 27
28
Input: The CCM* inverse transformation takes as inputs: 29
30
1 A bit string Key of length keylen bits to be used as the key. Each entity shall 31
have evidence that access to this key is restricted to the entity itself and its 32
intended key-sharing group member(s). 33
2 A nonce N of 15-L octets. Within the scope of any encryption key Key, the 34
nonce value shall be unique. 35
36
3 An octet string c of length l(c) octets, where 0 < l(c)-M < 28L. 37
4 An octet string a of length l(a) octets, where 0 < l(a) < 264. 38
39
40
A.3.1 Decryption Transformation 41
42
The decryption transformation involves the following steps, in order: 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex A
526 CCM* Mode of Operation

1 Parse the message c as C ||U, where the rightmost string U is an M-octet string.
If this operation fails, output ‘invalid’ and stop. U is the purported encrypted 1
authentication tag. Note that the leftmost string C has length l(c)-M octets. 2
3
2 Form the padded message CiphertextData by right-concatenating the string C 4
with the smallest non-negative number of all-zero octets such that the octet 5
string CiphertextData has length divisible by 16. 6
3 Use the encryption transformation in sub-clause A.2.3, with the data 7
CipherTextData and the tag U as inputs. 8
9
4 Parse the output string resulting from applying this transformation as m || T, 10
where the rightmost string T is an M-octet string. T is the purported 11
authentication tag. Note that the leftmost string m has length l(c)-M octets. 12
13
A.3.2 Authentication Checking Transformation 14
15
The authentication checking transformation involves the following steps: 16
17
1 Form the message AuthData using the input transformation in sub- 18
clause A.2.1, with the string a and the octet string m that was established in 19
sub-clause A.3.1 (step 4) as inputs. 20
2 Use the authentication transformation in sub-clause A.2.2, with the message 21
AuthData as input. 22
23
3 Compare the output tag MACTag resulting from this transformation with the 24
tag T that was established in sub-clause A.3.1 (step 4). If MACTag=T, output 25
‘valid’; otherwise, output ‘invalid’ and stop. 26
Output: If any of the above verifications has failed, then output ‘invalid’ and 27
reject the octet string m. Otherwise, accept the octet string m and accept one of the 28
key sharing group member(s) as the source of m. 29
30
31
A.4 Restrictions 32
33
All implementations shall limit the total amount of data that is encrypted with a 34
single key. The CCM* encryption transformation shall invoke not more than 261 35
block-cipher encryption function operations in total, both for the CBC-MAC and 36
for the CTR encryption operations. 37
38
At CCM* decryption, one shall verify the (truncated) CBC-MAC before releasing 39
any information, such as, Plaintext. If the CBC-MAC verification fails, only the 40
fact that the CBC-MAC verification failed shall be exposed; all other information 41
shall be destroyed. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 527

A N N E X
1

B
2
3
4
5
6
7
8
9

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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex B
528 Security Building Blocks

B.1.3 Cryptographic Hash Function 1


2
The cryptographic hash function used in this specification shall be the blockcipher
3
based cryptographic hash function specified in sub-clause B.6, with the following
4
instantiations:
5
1 Each entity shall use the block-cipher E as specified in sub-clause B.1.1. 6
7
2 All integers and octets shall be represented as specified in sub-clause 1.2.1.
8
The Matyas-Meyer-Oseas hash function (specified in sub-clause B.6) has a 9
message digest size hashlen that is equal to the block size, in bits, of the 10
established blockcipher. 11
12
13
B.1.4 Keyed Hash Function for Message Authentication 14
15
The keyed hash message authentication code (HMAC) used in this specification
16
shall be HMAC, as specified in the FIPS Pub 198 [B9], with the following
17
instantiations:
18
1 Each entity shall use the cryptographic hash H function as specified in sub- 19
clause B.1.3. 20
21
2 The block size B shall have the integer value 16 (this block size specifies the
22
length of the data integrity key, in bytes, that is used by the keyed hash
23
function, i.e., it uses a 128-bit data integrity key).
24
3 The output size HMAClen of the HMAC function shall have the same integer 25
value as the message digest parameter hashlen as specified in sub-clause B.1.3. 26
27
28
B.1.5 Specialized Keyed Hash Function for 29
Message Authentication 30
31
The specialized keyed hash message authentication code used in this specification 32
shall be as specified in sub-clause B.1.4. 33
34
B.1.6 Challenge Domain Parameters 35
36
The challenge domain parameters used in the specification shall be as specified in 37
sub-clause B.3.1, with the following instantiation: (minchallengelen, 38
maxchallengelen)=(128,128). 39
40
All challenges shall be validated using the challenge validation primitive as 41
specified in sub-clause B.4. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 529

B.2 Key Agreement Schemes 1


2
B.2.1 Symmetric-Key Key Agreement Scheme 3
4
The symmetric-key key agreement protocols in this standard shall use the full 5
symmetric-key with key confirmation scheme, with the following instantiations: 6
7
1 Each entity shall use the HMAC-scheme as specified in sub-clause B.1.4. 8
2 Each entity shall use the specialized HMAC-scheme as specified in sub- 9
clause B.1.5. 10
11
3 Each entity shall use the cryptographic hash function as specified in sub- 12
clause B.1.3. 13
4 The parameter keydatalen shall have the same integer value as the key size 14
parameter keylen as specified in sub-clause B.1.1. 15
16
5 The parameter SharedData shall be the empty string; parameter shareddatalen 17
shall have the integer value 0. 18
6 The optional parameters Text1 and Text2 as specified in sub-clause B.7.1 and 19
sub-clause B.7.2 shall both be the empty string. 20
21
7 Each entity shall use the challenge domain parameters as specified in sub- 22
clause B.1.6. 23
8 All octets shall be represented as specified in sub-clause 1.2.1. 24
25
26
B.3 Challenge Domain Parameter Generation and 27
28
Validation 29
30
This section specifies the primitives that shall be used to generate and validate 31
challenge domain parameters. 32
33
Challenge domain parameters impose constraints on the length(s) of bit
34
challenges a scheme expects. As such, this establishes a bound on the entropy of
35
challenges and, thereby, on the security of the cryptographic schemes in which
36
these challenges are used. In most schemes, the challenge domain parameters will
37
be such that only challenges of a fixed length will be accepted (e.g., 128-bit
38
challenges). However, one may define the challenge domain parameters such that
39
challenges of varying length might be accepted. Doing so is useful in contexts in
40
which entities that wish to engage in cryptographic schemes might have a bad
41
random number generator onboard. Allowing both entities that engage in a
42
scheme to contribute sufficiently long inputs enables each of them to contribute
43
sufficient entropy to the scheme.
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex B
530 Security Building Blocks

In this standard, challenge domain parameters will be shared by a number of


entities using a scheme determined by the standard. The challenge domain 1
parameters may be public; the security of the system does not rely on these 2
parameters being secret. 3
4
5
B.3.1 Challenge Domain Parameter Generation 6
7
Challenge domain parameters shall be generated using the following routine. 8
Input: This routine does not take any input. 9
10
Actions: The following actions are taken: 11
1 Choose two nonnegative integers minchallengelen and maxchallengelen, such 12
that minchallengelen < maxchallengelen. 13
14
Output: Challenge domain parameters D=(minchallengelen, maxchallengelen). 15
16
B.3.2 Challenge Domain Parameter Verification 17
18
Challenge domain parameters shall be verified using the following routine. 19
20
Input: Purported set of challenge domain parameters D=(minchallengelen, 21
maxchallengelen). 22
Actions: The following checks are made: 23
24
1 Check that minchallengelen and maxchallengelen are non-negative integers. 25
2 Check that minchallengelen < maxchallengelen. 26
27
Output: If any of the above verifications has failed, then output ‘invalid’ and 28
reject the challenge domain parameters. Otherwise, output ‘valid’ and accept the 29
challenge domain parameters. 30
31
32
B.4 Challenge Validation Primitive 33
34
It is used to check whether a challenge to be used by a scheme in the standard has 35
sufficient length (e.g., messages that are too short are discarded, due to 36
insufficient entropy). 37
Input: The input of the validation transformation is a valid set of challenge 38
domain parameters D=(minchallengelen, maxchallengelen), together with the bit 39
string Challenge. 40
41
Actions: The following actions are taken: 42
1 Compute the bit-length challengelen of the bit string Challenge. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 531

2 Verify that challengelen ˛ [minchallengelen, maxchallengelen]. (That is,


verify that the challenge has an appropriate length.) 1
2
Output: If the above verification fails, then output ‘invalid’ and reject the 3
challenge. Otherwise, output ‘valid’ and accept the challenge. 4
5
6
B.5 Secret Key Generation (SKG) Primitive 7
8
This section specifies the SKG primitive that shall be used by the symmetric-key 9
key agreement schemes specified in this standard. 10
This primitive derives a shared secret value from a challenge owned by an entity 11
U1 and a challenge owned by an entity U2 when all the challenges share the same 12
challenge domain parameters. If the two entities both correctly execute this 13
primitive with corresponding challenges as inputs, the same shared secret value 14
will be produced. 15
16
The shared secret value shall be calculated as follows: 17
Prerequisites: The following are the prerequisites for the use of the SKG 18
primitive: 19
20
1 Each entity shall be bound to a unique identifier (e.g., distinguished names). 21
All identifiers shall be bit strings of the same length entlen bits. Entity U1’s 22
identifier will be denoted by the bit string U1. Entity U2’s identifier will be 23
denoted by the bit string U2. 24
2 A specialized MAC scheme shall be chosen, with tagging transformation as 25
specified in Section 5.7.1 of ANSI X9.63-2001 [B7]. The length in bits of the 26
keys used by the specialized MAC scheme is denoted by mackeylen. 27
28
Input: The SKG primitive takes as input: 29
• A bit string MACKey of length mackeylen bits to be used as the key of the 30
established specialized MAC scheme. 31
32
• A bit string QEU1 owned by U1. 33
• A bit string QEU2 owned by U2. 34
35
Actions: The following actions are taken: 36
1 Form the bit string consisting of U1’s identifier, U2’s identifier, the bit string 37
QEU1 corresponding to U1’s challenge, and the bit string QEU2 corresponding 38
to QEU2’s challenge: 39
40
MacData = U1 || U2 || QEU1 || QEU2 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex B
532 Security Building Blocks

2 Calculate the tag MacTag for MacData under the key MacKey using the
tagging transformation of the established specialized MAC scheme: 1
2
MacTag = MACMacKey(MacData) 3
4
5
3 If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop.
6
4 Set Z=MacTag. 7
8
Output: The bit string Z as the shared secret value.
9
10
B.6 Block-Cipher-Based Cryptographic Hash Function 11
12
13
This section specifies the Matyas-Meyer-Oseas hash function, a cryptographic 14
hash function based on block-ciphers. We define this hash function for block- 15
ciphers with a key size equal to the block size, such as AES-128, and with a 16
particular choice for the fixed initialization vector IV (we take IV=0). For a more 17
general definition of the Matyas-Meyer-Oseas hash function, refer to Section 18
9.4.1 of [B19]. 19
Prerequisites: The following are the prerequisites for the operation of Matyas- 20
Meyer-Oseas hash function: 21
22
1 A block-cipher encryption function E shall have been chosen, with a key size
23
that is equal to the block size. The Matyas-Meyer-Oseas hash function has a 24
message digest size that is equal to the block size of the established encryption 25
function. It operates on bit strings of length less than 2n, where n is the block 26
size, in octets, of the established block-cipher. 27
2 A fixed representation of integers as binary strings or octet strings shall have 28
been chosen. 29
30
Input: The input to the Matyas-Meyer-Oseas hash function is as follows: 31
1 A bit string M of length l bits, where 0 < l < 2n 32
33
Actions: The hash value shall be derived as follows: 34
1 Pad the message M according to the following method: 35
36
a Right-concatenate to the message M the binary consisting of the bit ‘1’
37
followed by k ‘0’ bits, where k is the smallest non-negative solution to the 38
equation: 39
40
l+1+k 7n (mod 8n) (1) 41
42
b Form the padded message M’ by right-concatenating to the resulting string 43
the n-bit string that is equal to the binary representation of the integer l. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 533

2 Parse the padded message M’ as M1 || M2|| … || Mt where each message block


Mi is an n-octet string. 1
2
3 The output Hasht is defined by 3
4
Hash0 =08n; Hashj =E(Hashj-1, Mj) Mj for j=1,…,t (2) 5
6
Here, E(K, x) is the ciphertext that results from encryption of the plaintext x, 7
using the established block-cipher encryption function E with key K; the string 8
08n is the n-octet all-zero bit string. 9
10
Output: The bit string Hasht as the hash value. 11
Note that the cryptographic hash function operates on bit strength of length less 12
than 2n bits, where n is the block size (or key size) of the established block cipher, 13
in bytes. For example, the Matyas-Meyer-Oseas hash function with AES-128 14
operates on bit strings of length less than 216 bits. It is assumed that all hash 15
function calls are on bit strings of length less than 2n bits. Any scheme attempting 16
to call the hash function on a bit string exceeding 2n bits shall output ‘invalid’ and 17
stop. 18
19
20
B.7 Symmetric-Key Authenticated Key Agreement 21
22
Scheme 23
24
This section specifies the full symmetric-key key agreement with key 25
confirmation scheme. A MAC scheme is used to provide key confirmation. Note 26
that all key exchanges and random challenges shall be assumed within data strings 27
in network transmission order.49 28
Figure B.1 illustrates the messaging involved in the use of the full symmetric-key 29
key agreement with key confirmation scheme. 30
31
32
33
34
35
36
37
38
39
40
41
42
43
49. CCB #785 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex B
534 Security Building Blocks

Key 1
2
3
QEU 4
5
U V
6
7
QEV, MACMacKey(0216 || V || U || QEV || QEU || [Text1]), [Text1] 8
9
10
MACMacKey(0316 || U || V || QEU || QEV || [Text2]), [Text2] 11
12
13
Figure B.1 Symmetric-Key Authenticated Key Agreement Scheme 14
15
The scheme is ‘asymmetric’, so two transformations are specified. U uses the 16
transformation specified in sub-clause B.7.1 to agree on keying data with V if U is 17
the protocol’s initiator, and V uses the transformation specified in sub-clause B.7.2 18
to agree on keying data with U if V is the protocol’s responder. 19
The essential difference between the role of the initiator and the role of the 20
responder is that the initiator sends the first pass of the exchange. 21
22
If U executes the initiator transformation, and V executes the responder 23
transformation with the shared secret keying material as input, then U and V will 24
compute the same keying data. 25
Prerequisites: The following are the prerequisites for the use of the scheme: 26
27
1 Each entity has an authentic copy of the system’s challenge domain parameters 28
D=(minchallengelen, maxchallengelen). 29
2 Each entity shall have access to a bit string Key of length keylen bits to be used 30
as the key. Each party shall have evidence that access to this key is restricted to 31
the entity itself and the other entity involved in the symmetric-key 32
authenticated key agreement scheme. 33
34
3 Each entity shall be bound to a unique identifier (e.g., distinguished names). 35
All identifiers shall be bit strings of the same length entlen bits. Entity U’s 36
identifier will be denoted by the bit string U. Entity V’s identifier will be 37
denoted by the bit string V. 38
4 Each entity shall have decided which MAC scheme to use as specified in 39
Section 5.7 of ANSI X9.63-2001 [B7]. The length in bits of the keys used by 40
the chosen MAC scheme is denoted by mackeylen. 41
42
5 A cryptographic hash function shall have been chosen for use with the key 43
derivation function. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 535

6 A specialized MAC scheme shall have been chosen for use with the secret key
generation primitive with tagging transformation as specified in Section 5.7.1 1
of ANSI X9.63-2001 [B7]. The length in bits of the keys used by the 2
specialized MAC scheme is denoted by keylen. 3
4
7 A fixed representation of octets as binary strings shall have been chosen. (e.g., 5
most-significant-bit-first order or least-significant-bit-first order). 6
7
B.7.1 Initiator Transformation 8
9
U shall execute the following transformation to agree on keying data with V if U is 10
the protocol’s initiator. U shall obtain an authentic copy of V’s identifier and an 11
authentic copy of the static secret key Key shared with V. 12
13
Input: The input to the initiator transformation is: 14
1 An integer keydatalen that is the length in bits of the keying data to be 15
generated. 16
17
2 (Optional) A bit string SharedData of length shareddatalen bits that consists of 18
some data shared by U and V. 19
3 (Optional) A bit string Text2 that consists of some additional data to be 20
provided from U to V. 21
22
Ingredients: The initiator transformation employs the challenge generation 23
primitive specified in Section 5.3 of ANSI X9.63-2001 [B7], the challenge 24
validation primitive in sub-clause B.3.2, the SKG primitive in sub-clause B.5, the 25
key derivation function in Section 5.6.3 of ANSI X9.63-2001 [B7], and one of the 26
MAC schemes in Section 5.7 of ANSI X9.63-2001 [B7]. 27
Actions: Keying data shall be derived as follows: 28
29
1 Use the challenge generation primitive in Section 5.3 of ANSI X9.63-2001 30
[B7] to generate a challenge QEU for the challenge domain parameters D. Send 31
QEU to V. 32
2 Then receive from V a challenge QEV', purportedly owned by V. If this value is 33
not received, output ‘invalid’ and stop. 34
35
3 Verify that QEV' is a valid challenge for the challenge domain parameters D as 36
specified in sub-clause B.3.2. If the validation primitive rejects the challenge, 37
output ‘invalid’ and stop. 38
4 Use the SKG primitive given in sub-clause B.5 to derive a shared secret bit 39
string Z from the challenges Q1=QEU owned by U and Q2=QEV' owned by V, 40
using as key the shared key Key. If the SKG primitive outputs ‘invalid’, output 41
‘invalid’ and stop. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex B
536 Security Building Blocks

5 Use the key derivation function in Section 5.6.3 of ANSI X9.63-2001 [B7] with
the established hash function to derive keying data KKeyData of length 1
mackeylen+keydatalen bits from the shared secret value Z and the shared data 2
[SharedData]. 3
4
6 Parse the leftmost mackeylen bits of KKeyData as a MAC key MacKey and the 5
remaining bits as keying data KeyData. 6
7 Form the bit string consisting of the octet 0216, V’s identifier, U’s identifier, the 7
bit string QEV', the bit string QEU, and if present Text1: 8
9
MacData1 = 0216 || V || U || QEV' || QEU || [Text1] 10
11
8 Verify that MacTag1' is the tag for MacData1 under the key MacKey using the 12
tag checking transformation of the appropriate MAC scheme specified in 13
Section 5.7.2 of ANSI X9.63-2001 [B7]. If the tag checking transformation 14
outputs ‘invalid’, output ‘invalid’ and stop. 15
9 Form the bit string consisting of the octet 0316, U’s identifier, V’s identifier, the 16
bit string QEU corresponding to U’s challenge, the bit string QEV' 17
corresponding to V’s challenge, and optionally a bit string Text2: 18
19
MacData2 = 0316 || U || V || QEU || QEV' || [Text2] 20
21
10 Calculate the tag MacTag2 on MacData2 under the key MacKey using the 22
tagging transformation of the appropriate MAC scheme specified in Section 23
5.7.1 of ANSI X9.63-2001 [B7]: 24
25
MacTag2 = MACMacKey(MacData2) (3) 26
27
11 If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send 28
MacTag2 and, if present, Text2 to V. 29
12 Receive from V an optional bit string Text1, and a purported tag MacTag1'. If 30
these values are not received, output ‘invalid’ and stop. 31
32
Output: If any of the above verifications has failed, then output ‘invalid’ and 33
reject the bit strings KeyData and Text1. Otherwise, output ‘valid’, accept the bit 34
string KeyData as the keying data of length keydatalen bits shared with V and 35
accept V as the source of the bit string Text1 (if present). 36
37
B.7.2 Responder Transformation 38
39
V shall execute the following transformation to agree on keying data with U if V is 40
the protocol’s responder. V shall obtain an authentic copy of U’s identifier and an 41
authentic copy of the static secret key Key shared with U. 42
43
Input: The input to the responder transformation is: 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 537

1 A challenge QEU' purportedly owned by U.


1
2 An integer keydatalen that is the length in bits of the keying data to be 2
generated. 3
3 (Optional) A bit string SharedData of length shareddatalen bits that consists of 4
some data shared by U and V. 5
6
4 (Optional) A bit string Text1 that consists of some additional data to be 7
provided from V to U. 8
Ingredients: The responder transformation employs the challenge generation 9
primitive specified in Section 5.3 of ANSI X9.63-2001 [B7], the challenge 10
validation primitive specified in sub-clause B.3.2, the SKG primitive given in 11
sub-clause B.5, the key derivation function in Section 5.6.3 of ANSI X9.63-2001 12
[B7], and one of the MAC schemes in Section 5.7 of ANSI X9.63-2001 [B7]. 13
14
Actions: Keying data shall be derived as follows: 15
1 Verify that QEU' is a valid challenge for the challenge domain parameters D as 16
specified in sub-clause B.3.2. If the validation primitive rejects the challenge, 17
output ‘invalid’ and stop. 18
19
2 Use the challenge generation primitive in Section 5.3 of ANSI X9.63-2001 20
[B7] to generate a challenge QEV for the challenge domain parameters D. Send 21
to U the challenge QEV. 22
3 Then receive from U an optional bit string Text2 and a purported tag MacTag2'. 23
If this data is not received, output ‘invalid’ and stop. 24
25
4 Form the bit string consisting of the octet 0316, U’s identifier, V’s identifier, the 26
bit string QEU' corresponding to U’s purported challenge, the bit string QEV 27
corresponding to V’s challenge, and the bit string Text2 (if present): 28
29
MacData2 = 0316 || U || V || QEU' || QEV || [Text2] 30
5 Verify that MacTag2' is the valid tag on MacData2 under the key MacKey 31
using the tag checking transformation of the appropriate MAC scheme 32
specified in Section 5.7 ANSI X9.63-2001 [B7]. If the tag checking 33
transformation outputs ‘invalid’, output ‘invalid’ and stop. 34
35
6 Use the SKG primitive in sub-clause B.5 to derive a shared secret bit string Z 36
from the challenges Q1=QEU' owned by U and Q2=QEV owned by V, using as 37
key the shared key Key. If the SKG primitive outputs ‘invalid’, output ‘invalid’ 38
and stop. 39
7 Use the key derivation function in Section 5.6.3 of ANSI X9.63-2001 [B7] with 40
the established hash function to derive keying data KKeyData of length 41
mackeylen+keydatalen bits from the shared secret value Z and the shared data 42
[SharedData]. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex B
538 Security Building Blocks

8 Parse the leftmost mackeylen bits of KKeyData as a MAC key MacKey and the
remaining bits as keying data KeyData. 1
2
9 Form the bit string consisting of the octet 0216, V’s identifier, U’s identifier, the 3
bit string QEV, the bit string QEU', and, optionally, a bit string Text1: 4
5
MacData1 = 0216 || V || U || QEV || QEU' || [Text1] 6
7
10 Calculate the tag MacTag1 for MacData1 under the key MacKey using the 8
tagging transformation of the appropriate MAC scheme specified in Section 5.7 9
of ANSI X9.63-2001 [B7]: 10
11
MacTag1 = MACMacKey(MacData1) 12
13
14
If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send to 15
U, if present the bit string Text1, and MacTag1. 16
Output: If any of the above verifications has failed, then output ‘invalid’ and 17
reject the bit strings KeyData and Text2. Otherwise, output ‘valid’, accept the bit 18
string KeyData as the keying data of length keydatalen bits shared with U and 19
accept U as the source of the bit string Text2 (if present). 20
21
22
B.8 Mutual Symmetric-Key Entity Authentication 23
24
This section specifies the mutual symmetric-key entity authentication scheme. A 25
MAC scheme is used to provide key confirmation. 26
27
Figure B.2 illustrates the messaging involved in the use of mutual symmetric-key 28
entity authentication scheme. 29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 539

MacKey
1
2
3
QEU 4
5
6
QEV 7
8
9
10
MAC MacKey (0316 || U || V || QEU || QEV || [Text2]),[Text2] 11
12
13
MAC MacKey (0216 || V || U || QEV || QEU || [Text1]),[Text1] 14
15
Figure B.2 Mutual Symmetric-Key Entity Authentication Scheme 16
17
The scheme is ‘asymmetric’, so two transformations are specified. U uses the 18
transformation specified in sub-clause B.8.1 to establish authenticity of, and 19
optionally obtain authenticated data from, V by means of sharing a key and 20
communicating cooperatively with V. V uses the transformation specified in sub- 21
clause B.8.2 to establish authenticity of, and optionally obtain authenticated data 22
from, U by means of sharing a key and communicating cooperatively with U. 23
24
The essential difference between the role of the initiator and the role of the 25
responder is that the initiator sends the first pass of the exchange. 26
Prerequisites: The following are the prerequisites for the use of the scheme: 27
28
1 Each entity has an authentic copy of the system’s challenge domain parameters 29
D=(minchallengelen, maxchallengelen). These parameters shall have been 30
generated using the parameter generation primitive in sub-clause B.3.1. 31
Furthermore, the parameters shall have been validated using the parameter 32
validation primitive in sub-clause B.3.2. 33
2 Each entity shall have access to a bit string MacKey of length mackeylen bits to 34
be used as the key. Each party shall have evidence that access to this key is 35
restricted to the entity itself and the other entity involved in the mutual entity 36
authentication scheme. 37
38
3 Each entity shall be bound to a unique identifier (e.g., distinguished names). 39
All identifiers shall be bit strings of the same length entlen bits. Entity U’s 40
identifier will be denoted by the bit string U. Entity V’s identifier will be 41
denoted by the bit string V. 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter B
540 Security Building Blocks

4 Each entity shall have decided which MAC scheme to use as specified in
Section 5.7 of ANSI X9.63-2001 [B7]. The length in bits of the keys used by 1
the chosen MAC scheme is denoted by mackeylen. 2
3
5 A fixed representation of octets as binary strings shall have been chosen (e.g., 4
most-significant-bit-first order or least-significant-bit-first order). 5
6
B.8.1 Initiator Transformation 7
8
U shall execute the following transformation to establish authenticity of, and 9
optionally obtain authenticated data from, V by means of sharing a key and 10
communicating cooperatively with V. U shall obtain an authentic copy of V’s 11
identifier and an authentic copy of the secret key MacKey shared with V. 12
13
Input: The input to the initiator transformation is: 14
1 (Optional) A bit string Text2 that consists of some additional data to be 15
provided from U to V. 16
17
Ingredients: The initiator transformation employs the challenge generation 18
primitive specified in Section 5.3 of ANSI X9.63-2001 [B7], the challenge 19
validation primitive specified in sub-clause B.4, and one of the MAC schemes in 20
Section 5.7 of ANSI X9.63-2001 [B7]. 21
Actions: Entity authentication shall be established as follows: 22
23
1 Use the challenge generation primitive given in Section 5.3 of ANSI X9.63- 24
2001 [B7] to generate a challenge QEU for the challenge domain parameters D. 25
Send QEU to V. 26
2 Then receive from V a challenge QEV' purportedly owned by V. If this value is 27
not received, output ‘invalid’ and stop. 28
29
3 Verify that QEV' is a valid challenge for the challenge domain parameters D as 30
specified in sub-clause B.3.1. If the validation primitive rejects the challenge, 31
output ‘invalid’ and stop. 32
4 Form the bit string consisting of the octet 0316, U’s identifier, V’s identifier, the 33
bit string QEU corresponding to U’s challenge, the bit string QEV' 34
corresponding to V’s purported challenge, and optionally a bit string Text2: 35
36
MacData2 = 0316 || U || V || QEU || QEV' || [Text2]. 37
38
39
5 Calculate the tag MacTag2 on MacData2 under the key MacKey using the
40
tagging transformation of the appropriate MAC scheme specified in Section
41
5.7.1 of ANSI X9.63-2001 [B7]:
42
43
MacTag2 = MACMacKey (MacData2). 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 541

If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send
MacTag2 and, if present, bit string Text2 to V. 1
2
6 Receive from V an optional bit string Text1, and a purported tag MacTag1'. If 3
these values are not received, output ‘invalid’ and stop. 4
7 Form the bit string consisting of the octet 0216, V’s identifier, U’s identifier, the 5
bit string QEV' corresponding to V’s purported challenge, the bit string QEU 6
corresponding to U’s challenge, and if present Text1: 7
8
MacData1 = 0216 || V || U || QEV' || QEU || [Text1]. 9
10
11
8 Verify that MacTag1' is the tag for MacData1 under the key MacKey using the
12
tag checking transformation of the appropriate MAC scheme specified in
13
Section 5.7.2 of ANSI X9.63-2001 [B7]. If the tag checking transformation
14
outputs ‘invalid’, output ‘invalid’ and stop.
15
Output: If any of the above verifications has failed, then output ‘invalid’ and 16
reject the authenticity of V and reject the entity authentication from V. Otherwise, 17
output ‘valid’, accept the authenticity of V and accept the entity authentication 18
from V of the authenticated bit string Text1 (if present). 19
20
21
B.8.2 Responder Transformation 22
23
V shall execute the following transformation to establish authenticity, of and
24
optionally obtain authenticated data from, U by means of sharing a key and
25
communicating cooperatively with U. V shall obtain an authentic copy of U’s
26
identifier and an authentic copy of the secret key MacKey shared with U.
27
Input: The input to the responder transformation is: 28
29
1 A challenge QEU' purportedly owned by U.
30
2 (Optional) A bit string Text1 that consists of some additional data to be 31
provided from V to U. 32
33
Ingredients: The responder transformation employs the challenge generation
34
primitive specified in Section 5.3 of ANSI X9.63-2001 [B7], the challenge
35
validation primitive specified in sub-clause B.4, and one of the MAC schemes in
36
Section 5.7 of ANSI X9.63-2001 [B7].
37
Actions: Entity authentication shall be established as follows: 38
39
1 Verify that QEU' is a valid challenge for the challenge domain parameters D as
40
specified in sub-clause B.3.1. If the validation primitive rejects the challenge,
41
output ‘invalid’ and stop.
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter B
542 Security Building Blocks

2 Use the challenge generation primitive in Section 5.3 of ANSI X9.63-2001


[B7] to generate a challenge QEV for the challenge domain parameters D. Send 1
QEV to U. 2
3
3 Then receive from U an optional bit string Text2 and a purported tag MacTag2'. 4
If this data is not received, output ‘invalid’ and stop. 5
4 Form the bit string consisting of the octet 0316, U’s identifier, V’s identifier, the 6
bit string QEU' corresponding to U’s purported challenge, the bit string QEV 7
corresponding to V’s challenge, and the bit string Text2 (if present): 8
9
MacData2 = 0316 || U || V || QEU' || QEV || [Text2] 10
11
12
5 Calculate the tag MacTag2 for MacData2 under the key MacKey using the
13
tagging transformation of the appropriate MAC scheme specified in Section
14
5.7.1 of ANSI X9.63-2001 [B7]:
15
16
MacTag2 = MACMacKey(MacData2). 17
18
If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. 19
6 Verify that MacTag2' is the valid tag on MacData2 under the key MacKey 20
using the tag checking transformation of the appropriate MAC scheme 21
specified in Section 5.7.2 of ANSI X9.63-2001 [B7]. If the tag checking 22
transformation outputs ‘invalid’, output ‘invalid’ and stop. 23
24
7 Form the bit string consisting of the octet 0216, V’s identifier, U’s identifier, the 25
bit string QEV corresponding to V’s challenge, the bit string QEU' 26
corresponding to U’s purported challenge and optionally a bit string Text1: 27
28
MacData1 = 0216 || V || U || QEV || QEU' || [Text1]. 29
30
8 Calculate the tag MacTag1 for MacData1 under the key MacKey using the 31
tagging transformation of the appropriate MAC scheme specified in Section 32
5.7.1 of ANSI X9.63-2001 [B7]: 33
34
MacTag1 = MACMacKey(MacData1). 35
36
If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send 37
MacTag1 and, if present, bit string Text1 to U. 38
39
Output: If any of the above verifications has failed, then output ‘invalid’ and 40
reject the authenticity of U and reject the entity authentication from U. Otherwise, 41
output ‘valid’, accept the authenticity of U and accept the entity authentication 42
from U of the authenticated bit string Text2 (if present). 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 543

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 with 16
the intent of assisting in building interoperable security implementations. The 17
sample test vectors are provided as is, pending independent validation. 18
19
20
C.1 Data Conversions 21
22
For test vectors, see Appendix J1 of ANSI X9.63-2001 [B7]. 23
24
25
C.2 AES Block Cipher 26
27
This annex provides sample test vectors for the block-cipher specified in sub- 28
clause B.1.1. 29
30
For test vectors, see FIPS Pub 197 [B8]. 31
32
33
C.3 CCM* Mode Encryption and Authentication 34
Transformation 35
36
37
This annex provides sample test vectors for the mode of operation as specified in
38
sub-clause B.1.2.
39
Prerequisites: The following prerequisites are established for the operation of the 40
mode of operation: 41
42
1 The parameter M shall have the integer value 8.
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex C
544 Test Vectors For Cryptographic Building

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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 545

AuthData = 00 08 00 01 02 03 04 05 06 07 00 00 00 00 00 00 ||
08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 1
18 19 1A 1B 1C 1D 1E 00 00 00 00 00 00 00 00 00 2
3
4
C.3.2 Authentication Transformation 5
6
The data AuthData that was established above shall be tagged using the following 7
tagging transformation: 8
1 Form the 1-octet Flags field as follows: 9
10
Flags = 59 11
12
2 Form the 16-octet B0 field as follows: 13
14
B0 = 59 || A0 A1 A2 A3 A4 A5 A6 A7 03 02 01 00 06 || 00 17 15
3 Parse the message AuthData as B1 || B2 ||B3, where each message block Bi is a 16
16-octet string. 17
18
4 The CBC-MAC value X4 is calculated as follows: 19
20
i Bi Xi 21
22
0 59 A0 A1 A2 A3 A4 A5 A6 A7 03 02 01 00 06 00 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
23
1 00 08 00 01 02 03 04 05 06 07 00 00 00 00 00 00 F7 74 D1 6E A7 2D C0 B3 E4 5E 36 CA 8F 24 3B 1A 24
25
2 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 90 2E 72 58 AE 5A 4B 5D 85 7A 25 19 F3 C7 3A B3
26
3 18 19 1A 1B 1C 1D 1E 00 00 00 00 00 00 00 00 00 5A B2 C8 6E 3E DA 23 D2 7C 49 7D DF 49 BB B4 09 27
28
4 æ B9 D7 89 67 04 BC FA 20 B2 10 36 74 45 F9 83 D6
29
30
The authentication tag T is the result of omitting all but the leftmost M=8 octets of 31
the CBC-MAC value X4: 32
33
T = B9 D7 89 67 04 BC FA 20 34
35
C.3.3 Encryption Transformation 36
37
The data PlaintextData shall be encrypted using the following encryption 38
transformation: 39
40
1 Form the 1-octet Flags field as follows: 41
42
Flags = 01 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex C
546 Test Vectors For Cryptographic Building

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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 547

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
1 The key Key of size keylen=128 bits to be used: 12
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 rightmost 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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex C
548 Test Vectors For Cryptographic Building

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 the string a as inputs and the octet string m that was 41
established in sub-clause C.4.1 (step 7): 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 549

AuthData = 08 00 01 02 03 04 05 06 07 00 00 00 00 00 00 00 ||
08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 1
18 19 1A 1B 1C 1D 1E 00 00 00 00 00 00 00 00 00 2
3
2 Use the authentication transformation in sub-clause C.3.2, with the message 4
AuthData to compute the authentication tag MACTag as input: 5
6
MACTag = B9 D7 89 67 04 BC FA 20 7
3 Compare the output tag MACTag resulting from this transformation with the 8
tag T that was established in sub-clause C.4.1 (step 9): 9
T = B9 D7 89 67 04 BC FA 20 = MACTag 10
11
Output: Since MACTag=T, output ‘valid’ and accept the octet string m and accept 12
one of the key sharing group member(s) as the source of m. 13
14
15
C.5 Cryptographic Hash Function 16
17
This annex provides sample test vectors for the cryptographic hash function 18
specified in clause C.5. 19
20
C.5.1 Test Vector Set 1 21
22
Input: The input to the cryptographic hash function is as follows: 23
24
1 The bit string M of length l=8 bits to be used: 25
26
M=C0 27
Actions: The hash value shall be derived as follows: 28
29
1 Pad the message M by right-concatenating to M the bit ‘1’ followed by the 30
smallest non-negative number of ‘0’ bits, such that the resulting string has 31
length 14 (mod 16) octets: 32
33
C0 || 80 00 00 00 00 00 00 00 00 00 00 00 00 34
2 Form the padded message M' by right-concatenating to the resulting string the 35
16-bit string that is equal to the binary representation of the integer l: 36
37
M' = C0 || 80 00 00 00 00 00 00 00 00 00 00 00 00 || 00 08 38
39
3 Parse the padded message M' as M1, where each message block Mi is a 16-octet 40
string. 41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex C
550 Test Vectors For Cryptographic Building

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
C.5.2 Test Vector Set 2 11
12
Input: The input to the cryptographic hash function is as follows: 13
14
1 The bit string M of length l=128 bits to be used: 15
16
M=C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF 17
Actions: The hash value shall be derived as follows: 18
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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 551

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
C.6.1 Test Vector Set 1 6
7
Input: The input to the keyed hash function is as follows: 8
9
1 The key Key of size keylen=128 bits to be used: 10
11
Key = 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 12
2 The bit string M of length l=8 bits to be used: 13
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
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex C
552 Test Vectors For Cryptographic Building

7 Form the padded message M2 by right-concatenating the bit string Key2 with
the bit string Hash1: 1
2
M2 = Key2 || Hash1 = 1C 1D 1E 1F 18 19 1A 1B 14 15 16 17 10 11 12 13 || 3
3C 3D 53 75 29 A7 A9 A0 3F 66 9D CD 88 6C B5 2C 4
5
8 Compute the hash value Hash2 of the bit string M2: 6
7
Hash2 = 45 12 80 7B F9 4C B3 40 0F 0E 2C 25 FB 76 E9 99 8
Output: the 16-octet string HMAC = Hash2 = 45 12 80 7B F9 4C B3 40 0F 0E 2C 9
25 FB 76 E9 99 10
11
12
C.6.2 Test Vector Set 2 13
14
Input: The input to the keyed hash function is as follows: 15
1 The key Key of size keylen=256 bits to be used: 16
Key = 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F || 17
50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 18
19
2 The bit string M of length l=128 bits to be used: 20
21
M = C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF 22
Actions: The keyed hash value shall be derived as follows: 23
24
1 Compute the hash value Key0 of the bit string Key: 25
26
Key0 = 22 F4 0C BE 15 66 AC CF EB 77 77 E1 C4 A9 BB 43 27
2 Create the 16-octet string ipad (inner pad) as follows: 28
29
ipad = 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 30
31
3 Form the inner key Key1 by XOR-ing the bit key Key0 and the octet string ipad: 32
33
Key1 = Key0 ¯ ipad = 14 C2 3A 88 23 50 9A F9 DD 41 41 D7 F2 9F 8D 75 34
4 Form the padded message M1 by right-concatenating the bit string Key1 with 35
the bit string M: 36
37
M1 = Key1 || M = 14 C2 3A 88 23 50 9A F9 DD 41 41 D7 F2 9F 8D 75 || 38
C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF 39
40
5 Compute the hash value Hash1 of the bit string M1: 41
42
Hash1 = 42 65 BE 29 74 55 8C A2 7B 77 85 AC 73 F2 22 10 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 553

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
8 Form the padded message M2 by right-concatenating the bit string Key2 with 7
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
9 Compute the hash value Hash2 of the bit string M2: 13
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 and Entity 28
Authentication Scheme 29
30
This text provides details of the intermediate steps and the results for the SKKE 31
and EA algorithms utilized by ZigBee. It is intended to help those who wish to 32
implement the algorithms by verifying their results. 33
34
It is expected that the MAC functionality (to Hash data using a key) has already 35
been verified. 36
37
C.6.4.1 Endian Issues 38
The following are the ways in which the data elements are interpreted with the 39
SKKE / EA messages: 40
41
• Initiator and Responder IEEE Addresses are sent over-the-air as Little Endian, 42
but they are concatenated in the bit strings also as Big Endian values. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex C
554 Test Vectors For Cryptographic Building

• Keys are interpreted over-the-air as Little Endian, and used as Little Endian
values. 1
2
• Initiator and Responder Challenges are interpreted over-the-air as Little 3
Endian. They are concatenated in the bit strings also as Little Endian values. 4
• MacTag data is interpreted as Little Endian and sent over-the-air in the same 5
way as it is derived via the algorithms. 6
7
• Frame Counters are sent over-the-air as Little Endian, but are concatenated in 8
the bit strings as Big Endian. 9
Legend: 10
11
(<) Indicates the number is little-endian, e.g. (<)1234 displayed in big-endian 12
form is 0x3412. 13
(>) Indicates the number is big-endian. 14
15
C.6.4.2 SKKE Initiator Transform 16
17
Term Description 18
19
Key Shared key (i.e. Trust Center Master)
20
MacKey A key created during generation of keying data 21
22
U Initiator's unique ID (EUI64 Address) 23
24
V Responder's unique ID (EUI64 Address)
25
QEU Initiator challenge (16 byte random number) 26
27
QEV Responder challenge (16 byte random number) 28
29
MAC Our HMAC Function
30
Text1 Optional bit string. Not used in SKKE. 31
32
Text2 "" 33
34
Optional data shared between initiator and responder. An empty string for
SharedData SKKE / EA. 35
36
37
Note: '||' in this pseudo-code means concatenation 38
1 Responder's IEEE (V) must be known ahead of time 39
40
2 Generate Initiator Challenge QEU 41
3 Send Initiator Challenge and Initiator IEEE to Responder (SKKE-1) 42
43
4 Receive Responder Challenge, QEV (SKKE-2) 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 555

5 Calculate shared secret bit string Z.


1
a MacData1 = U || V || QUE || QEV 2
b MacTag1 = MAC(MacData1, Key) 3
4
c Z = MacTag1 5
6 Derive Keying Data. 6
7
a Hash-1 = Z || 00 00 00 01 || SharedData 8
b Hash-2 = Z || 00 00 00 02 || SharedData 9
10
c KeyingData = Hash-1 || Hash-2 11
7 Parse Keying Data as follows: 12
13
a MacKey = First 128 bits (Hash-1) of KeyingData 14
b KeyData = Second 128 bits (Hash-2) of KeyingData 15
16
8 Form the bit string MacData2. 17
a MacData2 = 03 || U || V || QEU || QEV || Text2 18
19
9 Calculate MacTag2. 20
a MacTag2 = MAC(MacData2, MacKey) 21
22
10 Send MacTag2 and Text2 to Responder (SKKE-3). 23
11 Receive MacTag1' and Text1 from Responder (SKKE-4). 24
25
12 Create bit string MacData1. 26
a MacData1 = 02 || V || U || QEV || QEU || Text1 27
28
13 Verify MacTag1 and MacTag1' match. 29
a MacTag1 = MAC(MacData1, MacKey) 30
31
b Check MacTag1 == MacTag1' 32
14 Store new Link Key, KeyData. (SKKE). 33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex C
556 Test Vectors For Cryptographic Building

C.6.4.3 SKKE Test Vector #1


1
Initiator IEEE Address (U) (>) 11 11 11 11 11 11 11 11 2
3
Responder IEEE Address (V) (>) 22 22 22 22 22 22 22 22 4
(<) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5
Master Key (Key)
6
Initiator Challenge (QUE) (<) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7
8
Responder Challenge (QEV) (<) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9
10
11
SKKE-3 Data (MacTag2) (<) F9 A0 89 6C E2 73 8D 71 34 3D 27 9B 51 3F 07 9C 12
13
SKKE-4 Data (MacTag1) (<) 55 98 10 E9 BD A4 48 40 59 88 12 58 C1 B2 0A 4F 14
15
16
Derived Link Key (<)19 BB FC 94 57 55 E7 09 86 E8 8B 5D 21 1C 97 37 17
18
19
Intermediate Steps 20
1 Responder's EUI 64 (V) must be known ahead of time 21
22
2 Generate Initiator Challenge QEU 23
3 Send Initiator Challenge and Initiator EUI64 to Responder (SKKE-1) 24
25
4 Receive Responder Challenge, QEV (SKKE-2) 26
5 Calculate shared secret bit string Z. 27
28
a MacData1 = U || V || QUE || QEV 29
30
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 31
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 32
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 33
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 34
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 35
36
b MacTag1 = MAC(MacData1, Key) 37
38
c Z = MacTag1 39
40
0x4c 0x3f 0x60 0xa0 0x2e 0x07 0x13 0x5e 41
0xdf 0xad 0xb0 0xe0 0xc1 0x46 0xfd 0xe2 42
43
6 Derive Keying Data 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 557

a Hash-1 = Z || 00 00 00 01 || SharedData
1
Bit String (before Hash) 2
0x4c 0x3f 0x60 0xa0 0x2e 0x07 0x13 0x5e 3
0xdf 0xad 0xb0 0xe0 0xc1 0x46 0xfd 0xe2 4
0x00 0x00 0x00 0x01 5
6
b Hash-2 = Z || 00 00 00 02 || SharedData 7
8
Bit String (before Hash) 9
0x4c 0x3f 0x60 0xa0 0x2e 0x07 0x13 0x5e 10
0xdf 0xad 0xb0 0xe0 0xc1 0x46 0xfd 0xe2 11
0x00 0x00 0x00 0x02 12
13
c KeyingData = Hash-1 || Hash-2 14
7 Parse Keying Data as follows: 15
16
a MacKey = First 128 bits (Hash-1) of KeyingData 17
18
0xaf 0x6e 0x2b 0x7a 0x59 0xc0 0x98 0xb0 19
0xcf 0x0a 0x93 0x1c 0x8b 0x34 0xcd 0xbd 20
21
b KeyData = Second 128 bits (Hash-2) of KeyingData 22
23
0x19 0xbb 0xfc 0x94 0x57 0x55 0xe7 0x09 24
0x86 0xe8 0x8b 0x5d 0x21 0x1c 0x97 0x37 25
26
8 Form the bit string MacData2. 27
a MacData2 = 03 || U || V || QEU || QEV || Text2 28
29
30
0x03 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x22 0x22 0x22 0x22 0x22 0x22 0x22 31
0x22 0x00 0x00 0x00 0x00 0x00 0x00 0x00 32
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 33
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 34
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 35
0x00 36
37
9 Calculate MacTag2. 38
39
a MacTag2 = MAC(MacData2, MacKey)
40
41
0xf9 0xa0 0x89 0x6c 0xe2 0x73 0x8d 0x71 42
0x34 0x3d 0x27 0x9b 0x51 0x3f 0x07 0x9c
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex C
558 Test Vectors For Cryptographic Building

10 Send MacTag2 and Text2 to Responder (SKKE-).


1
11 Receive MacTag1' and Text1 from Responder ( SKKE-4). 2
12 Create bit string MacData1. 3
4
a MacData1 = 02 || V || U || QEV || QEU || Text1 5
6
0x02 0x22 0x22 0x22 0x22 0x22 0x22 0x22 7
0x22 0x11 0x11 0x11 0x11 0x11 0x11 0x11 8
0x11 0x00 0x00 0x00 0x00 0x00 0x00 0x00 9
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 10
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 11
0x00 12
13
13 Verify MacTag1 and MacTag1' match. 14
15
a MacTag1 = MAC(MacData1, MacKey) 16
17
0x55 0x98 0x10 0xe9 0xbd 0xa4 0x48 0x40 18
0x59 0x88 0x12 0x58 0xc1 0xb2 0x0a 0x4f 19
20
14 Verify MacTag1 and MacTag1' match. 21
a MacTag1 = MAC(MacData1, MacKey) 22
23
b Check MacTag1 == MacTag1' 24
15 Store new Link Key, KeyData. (SKKE). 25
26
0x19 0xbb 0xfc 0x94 0x57 0x55 0xe7 0x09 27
0x86 0xe8 0x8b 0x5d 0x21 0x1c 0x97 0x37 28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 559

C.6.4.4 SKKE Test Vector #2


1
Initiator IEEE Address (U) (>) 55 73 65 72 20 55 0D 0A 2
3
Responder IEEE Address (V) (>) 55 73 65 72 20 56 0D 0A 4
(<) C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD 5
Master Key (Key) CE CF 6
7
Initiator Challenge (QEU) (<) 9E 3F 0C 19 05 4B 05 44 D5 A7 17 62 0A F2 7D 96
8
Responder Challenge (QEV) (<) BF 14 DF 94 94 39 D2 CE 24 C9 09 53 B5 72 D6 53 9
10
11
12
SKKE-3 Data (MacTag2) (<) 57 E1 D4 F9 7B 28 AB 72 B1 9B B7 76 F7 B5 55 1C
13
SKKE-4 Data (MacTag1) (<) A0 31 57 12 38 6A 25 EF 28 94 30 6C 6F BA A4 DA 14
15
16
17
Derived Link Key (<) 84 3D 71 7F 92 C3 D4 31 0A 9F 46 6B 58 B9 F2 1C
18
19
Intermediary Steps 20
21
1 Responder's EUI 64 (V) must be known ahead of time. 22
2 Generate Initiator Challenge QEU. 23
24
3 Send Initiator Challenge and Initiator EUI64 to Responder (SKKE-1). 25
4 Receive Responder Challenge, QEV (SKKE-2). 26
27
5 Calculate shared secret bit string Z. 28
a MacData1 = U || V || QUE || QEV 29
30
0x55 0x73 0x65 0x72 0x20 0x55 0x0d 0x0a 31
0x55 0x73 0x65 0x72 0x20 0x56 0x0d 0x0a 32
0x9e 0x3f 0x0c 0x19 0x05 0x4b 0x05 0x44 33
0xd5 0xa7 0x17 0x62 0x0a 0xf2 0x7d 0x96 34
0xbf 0x14 0xdf 0x94 0x94 0x39 0xd2 0xce 35
0x24 0xc9 0x09 0x53 0xb5 0x72 0xd6 0x53 36
37
b MacTag1 = MAC(MacData1, Key) 38
c Z = MacTag1 39
40
0x78 0x7c 0xde 0xf6 0x80 0x13 0x12 0xcd 41
0x41 0x1b 0xcd 0x62 0x14 0x91 0xf8 0x6d 42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter C
560 Test Vectors For Cryptographic Building

6 Derive Keying Data


1
a Hash-1 = Z || 00 00 00 01 || SharedData 2
3
Bit String (before Hash) 4
0x78 0x7c 0xde 0xf6 0x80 0x13 0x12 0xcd 5
0x41 0x1b 0xcd 0x62 0x14 0x91 0xf8 0x6d 6
0x00 0x00 0x00 0x01 7
8
b Hash-2 = Z || 00 00 00 02 || SharedData
9
10
Bit String (before Hash) 11
0x78 0x7c 0xde 0xf6 0x80 0x13 0x12 0xcd 12
0x41 0x1b 0xcd 0x62 0x14 0x91 0xf8 0x6d
0x00 0x00 0x00 0x02 13
14
c KeyingData = Hash-1 || Hash-2 15
16
7 Parse Keying Data as follows: 17
a MacKey = First 128 bits (Hash-1) of KeyingData 18
19
20
0x0e 0x6b 0x9f 0x70 0x8c 0xaa 0x84 0x63
0x44 0x76 0xec 0x17 0xa4 0x3e 0x6b 0xc5 21
22
b KeyData = Second 128 bits (Hash-2) of KeyingData 23
24
25
0x84 0x3d 0x71 0x7f 0x92 0xc3 0xd4 0x31
0x0a 0x9f 0x46 0x6b 0x58 0xb9 0xf2 0x1c 26
27
8 Form the bit string MacData2 28
29
a MacData2 = 03 || U || V || QEU || QEV || Text2 30
31
0x03 0x55 0x73 0x65 0x72 0x20 0x55 0x0d 32
0x0a 0x55 0x73 0x65 0x72 0x20 0x56 0x0d 33
0x0a 0x9e 0x3f 0x0c 0x19 0x05 0x4b 0x05 34
0x44 0xd5 0xa7 0x17 0x62 0x0a 0xf2 0x7d 35
0x96 0xbf 0x14 0xdf 0x94 0x94 0x39 0xd2 36
0xce 0x24 0xc9 0x09 0x53 0xb5 0x72 0xd6 37
0x53
38
39
9 Calculate MacTag2
40
a MacTag2 = MAC(MacData2, MacKey) 41
42
0x57 0xe1 0xd4 0xf9 0x7b 0x28 0xab 0x72 43
0xb1 0x9b 0xb7 0x76 0xf7 0xb5 0x55 0x1c 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 561

10 Send MacTag2 and Text2 to Responder (SKKE-3).


1
11 Receive MacTag1' and Text1 from Responder (SKKE-4). 2
12 Create bit string MacData1 3
4
a MacData1 = 02 || V || U || QEV || QEU || Text1 5
6
0x02 0x55 0x73 0x65 0x72 0x20 0x56 0x0d 7
0x0a 0x55 0x73 0x65 0x72 0x20 0x55 0x0d 8
0x0a 0xbf 0x14 0xdf 0x94 0x94 0x39 0xd2 9
0xce 0x24 0xc9 0x09 0x53 0xb5 0x72 0xd6 10
0x53 0x9e 0x3f 0x0c 0x19 0x05 0x4b 0x05
0x44 0xd5 0xa7 0x17 0x62 0x0a 0xf2 0x7d 11
0x96 12
13
13 Verify MacTag1 and MacTag1' match 14
15
a MacTag1 = MAC(MacData1, MacKey) 16
17
0xa0 0x31 0x57 0x12 0x38 0x6a 0x25 0xef 18
0x28 0x94 0x30 0x6c 0x6f 0xba 0xa4 0xda 19
20
b Check MacTag1 == MacTag1' 21
14 Store new Link Key, KeyData. (SKKE), or 22
23
0x84 0x3d 0x71 0x7f 0x92 0xc3 0xd4 0x31 24
0x0a 0x9f 0x46 0x6b 0x58 0xb9 0xf2 0x1c 25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter C
562 Test Vectors For Cryptographic Building

C.6.4.5 Entity Authentication Initiator Transform


1
Term Description 2
3
MacKey Shared Key (Network Key) 4
Initiator's unique ID (EUI64 Address) 5
U
6
V Responder's unique ID (EUI64 Address) 7
8
QEU Initiator Challenge (16 byte random number) 9
Responder Challenge (16 byte random number) 10
QEV
11
MAC Our HMAC Function 12
13
Text1 Optional bit string. The Frame Counter in EA 14
"" 15
Text2
16
Optional data shared between initiator and responder. 17
SharedData An empty string for SKKE / EA. 18
19
Note: '||' in this pseudo-code means concatenation 20
21
1 Responder's EUI 64 (V) must be known ahead of time. 22
2 Generate Initiator Challenge QEU. 23
24
3 Send Initiator Challenge and Initiator IEEE to Responder (EA-Init-Challenge). 25
4 Receive Responder Challenge, QEV (EA-Resp-Challenge). 26
27
5 Form the bit string MacData2 28
a MacData2 = 03 || U || V || QEU || QEV || Text2 29
30
6 Calculate MacTag2 31
a MacTag2 = MAC(MacData2, MacKey) 32
33
7 Send MacTag2 and Text2 to Responder (EA-Init-Mac-Data). 34
8 Receive MacTag1' and Text1 from Responder (EA-Resp-Mac-Data). 35
36
9 Create bit string MacData1 37
a MacData1 = 02 || V || U || QEV || QEU || Text1 38
39
10 Verify MacTag1 and MacTag1' match 40
a MacTag1 = MAC(MacData1, MacKey) 41
42
b Check MacTag1 == MacTag1' 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 563

11 Store new Frame Counter, Text1 (EA).


1
C.6.4.6 EA Test Vector #1 2
3
Initiator IEEE Address (U) (>) 22 22 22 22 22 22 22 22 4
5
Responder IEEE Address (V) (>) 11 11 11 11 11 11 11 11
6
Network Key (MacKey) (<) 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 7
8
Initiator Challenge (QUE) (<) 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 9
10
Responder Challenge (QEV) (<) 66 66 66 66 66 66 66 66 66 66 66 66 66 66 66 66
11
12
13
EA Initiator Data (MacTag2) (<) b5 8e 4a a8 ce 51 06 bc 5e 71 9a 41 3e 2e 6e 94 14
15
EA Responder Data (MacTag1) (<) 83 75 96 ff 23 ea 8c 54 2a 9c 0d 7e 8c c4 ca b4
16
Initiator Frame Counter (Text2) (<) 00 00 00 00 17
18
Responder Frame Counter (Text1) (<) 00 00 00 00 19
20
21
Intermediate Steps
22
1 Responder's EUI 64 (V) must be known ahead of time. 23
24
2 Generate Initiator Challenge QEU.
25
3 Send Initiator Challenge and Initiator IEEE to Responder (EA-Init-Challenge). 26
27
4 Receive Responder Challenge, QEV (EA-Resp-Challenge).
28
5 Form the bit string MacData2 29
30
a MacData2 = 03 || U || V || QEU || QEV || Text2
31
32
0x03 0x22 0x22 0x22 0x22 0x22 0x22 0x22 33
0x22 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x55 0x55 0x55 0x55 0x55 0x55 0x55 34
0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 35
0x55 0x66 0x66 0x66 0x66 0x66 0x66 0x66 36
0x66 0x66 0x66 0x66 0x66 0x66 0x66 0x66 37
0x66 0x00 0x00 0x00 0x00 38
39
6 Calculate MacTag2 40
41
a MacTag2 = MAC(MacData2, MacKey)
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter C
564 Test Vectors For Cryptographic Building

0xb5 0x8e 0x4a 0xa8 0xce 0x51 0x06 0xbc


0x5e 0x71 0x9a 0x41 0x3e 0x2e 0x6e 0x94 1
2
7 Send MacTag2 and Text2 to Responder (EA-Init-Mac-Data). 3
4
8 Receive MacTag1' and Text1 from Responder (EA-Resp-Mac-Data). 5
9 Create bit string MacData1 6
7
a MacData1 = 02 || V || U || QEV || QEU || Text1 8
9
0x02 0x11 0x11 0x11 0x11 0x11 0x11 0x11 10
0x11 0x22 0x22 0x22 0x22 0x22 0x22 0x22 11
0x22 0x66 0x66 0x66 0x66 0x66 0x66 0x66 12
0x66 0x66 0x66 0x66 0x66 0x66 0x66 0x66
0x66 0x55 0x55 0x55 0x55 0x55 0x55 0x55 13
0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 14
0x55 0x00 0x00 0x00 0x00 15
16
10 Verify MacTag1 and MacTag1' match 17
18
a MacTag1 = MAC(MacData1, MacKey) 19
20
0x83 0x75 0x96 0xff 0x23 0xea 0x8c 0x54 21
0x2a 0x9c 0x0d 0x7e 0x8c 0xc4 0xca 0xb4 22
23
b Check MacTag1 == MacTag1' 24
11 Store new Frame Counter, Text1 (EA)50. 25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
50. CCB #787 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 565

C.6.4.7 EA Test Vector #2


1
Initiator IEEE Address (U) (>) ab cd ef 01 23 45 67 89 2
3
Responder IEEE Address (V) (>) 12 34 56 78 90 ab cd ef 4
(<) 47 85 67 85 73 11 79 85 43 21 87 57 44 35 02 65 5
Network Key (MacKey)
6
Initiator Challenge (QUE) (<) 43 4f 85 a1 61 d3 ba 99 7b 3f 25 ef 00 34 42 6f 7
8
Responder Challenge (QEV) (<) e2 08 74 50 4a 0f 18 97 40 9d fb d0 49 78 ae 69 9
10
11
EA Initiator Data (MacTag2) (<) 9b f9 e2 48 5d 14 a8 be 6d 40 d3 ee c2 0d e6 6d 12
13
EA Responder Data (MacTag1) (<) 67 59 9c a8 a3 1f 8e b0 87 9a de d3 7c ba fc c5 14
(<) 1f 00 00 00 15
Initiator Frame Counter (Text2)
16
Responder Frame Counter (Text1) (<) 20 00 00 00 17
18
19
Intermediate Steps 20
1 Responder's EUI 64 (V) must be known ahead of time 21
22
2 Generate Initiator Challenge QEU 23
3 Send Initiator Challenge and Initiator IEEE to Responder (EA-Init-Challenge) 24
25
4 Receive Responder Challenge, QEV (EA-Resp-Challenge) 26
5 Form the bit string MacData2 27
28
a MacData2 = 03 || U || V || QEU || QEV || Text2 29
30
0x03 0xab 0xcd 0xef 0x01 0x23 0x45 0x67 31
0x89 0x12 0x34 0x56 0x78 0x90 0xab 0xcd 32
0xef 0x43 0x4f 0x85 0xa1 0x61 0xd3 0xba 33
0x99 0x7b 0x3f 0x25 0xef 0x00 0x34 0x42
0x6f 0xe2 0x08 0x74 0x50 0x4a 0x0f 0x18 34
0x97 0x40 0x9d 0xfb 0xd0 0x49 0x78 0xae 35
0x69 0x00 0x00 0x00 0x1f 36
37
6 Calculate MacTag2 38
39
a MacTag2 = MAC(MacData2, MacKey) 40
41
0x9b 0xf9 0xe2 0x48 0x5d 0x14 0xa8 0xbe 42
0x6d 0x40 0xd3 0xee 0xc2 0x0d 0xe6 0x6d 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter C
566 Test Vectors For Cryptographic Building

7 Send MacTag2 and Text2 to Responder (EA-Init-Mac-Data)


1
8 Receive MacTag1' and Text1 from Responder (EA-Resp-Mac-Data) 2
9 Create bit string MacData1 3
4
a MacData1 = 02 || V || U || QEV || QEU || Text1 5
6
0x02 0x12 0x34 0x56 0x78 0x90 0xab 0xcd 7
0xef 0xab 0xcd 0xef 0x01 0x23 0x45 0x67 8
0x89 0xe2 0x08 0x74 0x50 0x4a 0x0f 0x18 9
0x97 0x40 0x9d 0xfb 0xd0 0x49 0x78 0xae 10
0x69 0x43 0x4f 0x85 0xa1 0x61 0xd3 0xba
0x99 0x7b 0x3f 0x25 0xef 0x00 0x34 0x42 11
0x6f 0x00 0x00 0x00 0x20 12
13
10 Verify MacTag1 and MacTag1' match 14
15
a MacTag1 = MAC(MacData1, MacKey) 16
17
0x67 0x59 0x9c 0xa8 0xa3 0x1f 0x8e 0xb0 18
0x87 0x9a 0xde 0xd3 0x7c 0xba 0xfc 0xc5 19
20
b Check MacTag1 == MacTag1' 21
11 Store new Frame Counter, Text1 (EA) 22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 567

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
36
D.2 Stack Size Issues 37
38
Both MAC and ZigBee stack developers have discovered that implementation of a 39
full-blown MAC is a major undertaking and requires a great deal of code space. 40
Even with the optional GTS and MAC security features eliminated, it is not 41
surprising to find the MAC taking up more than 24K of code space on a processor 42
with 64K of available space. 43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex D
568 MAC and PHY Sub-Layer Clarifications

The ZigBee Alliance has adopted a compensating policy to declare MAC features
that are not required to support a particular stack profile optional with respect to 1
that stack profile. In particular, any MAC feature that will not be exploited as a 2
result of platform compliance testing for a particular stack profile need not be 3
present in order for an implementation to be declared platform compliant. For 4
example, since the ZigBee 2006 stack profile relies on a beaconless network, the 5
platform compliance testing for the stack profile does not employ beaconing. The 6
code to support regular beaconing, beacon track, and so on, may therefore be 7
absent from the code base of the device under test without the knowledge of the 8
testers, without presenting a problem with respect to platform compliance 9
certification. 10
11
12
D.3 MAC Association 13
14
At association time, according to the IEEE 802.15.4 2003 specification, a number 15
of frames are sent, including an association request command, an associate 16
response command and a data request. There is some ambiguity in the 17
specification regarding the addressing fields in the headers for these frames. 18
Tables D.1–D.3 outline the allowable options that shall be recognized by devices 19
implementing the ZigBee specification. In each case, the first option given is the 20
preferred option and should be used. 21
22
Table D.1 Associate Request Header Fields 23
DstPANId DstAddr SrcPANId SrcAddr 24
25
The PANId of the The 16-bit short 0xffff The 64-bit extended 26
destination device. address of the address of the source
destination device. device.
27
28
PANId omitted 29
because the IntraPAN
30
sub-field in the frame
control field is set to 31
one. 32
33
The PANId of the
destination device. 34
35
Not present if the Not present if the 36
destination device is destination device is
the PAN coordinator. the PAN coordinator. 37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 569

Note that in this case and the case below, the source of the command is the device
requesting association. 1
2
Table D.2 Data Request Header Fields
3
DstPANId DstAddr SrcPANId SrcAddr 4
5
The PANId of the The 16-bit short 0xffff The 64-bit extended 6
destination device. address of the address of the source
destination device. device. 7
8
PANId omitted 9
because the IntraPAN
sub-field in the frame 10
control field is set to 11
one. 12
The PANId of the 13
destination device. 14
15
Not present if the Not present if the
destination device is destination device is
16
the PAN coordinator. the PAN coordinator. 17
18
19
20
Table D.3 Association Response Header Fields 21
22
DstPANId DstAddr SrcPANId SrcAddr
23
The PANId of the The 64-bit extended PANId omitted The 64-bit extended 24
destination device. address of the because the IntraPAN address of the source 25
destination device. sub-field in the frame device.
26
control field is set to
one. 27
28
The PANId of the
29
source device.
30
0xffff 31
32
33
D.4 aMaxMACFrameSize 34
35
In the IEEE 802.15.4 2003 specification, there is a constant called 36
aMaxMACFrameSize which is defined as being aMaxPHYPacketSize - 37
aMaxFrameOverhead. This formula gives aMaxMACFrameSize = 127 - 25 = 102 38
bytes. The disagreement about this value relates to the aMaxFrameOverhead 39
parameter. The value of 25 for this parameter is not correct for a ZigBee network 40
in which only short addressing modes can be used. The ZigBee alliance decided 41
that, rather than arguing what the correct value of aMaxFrameOverhead should 42
be, an acceptable packet is defined as one that is less than aMaxPHYFrameSize 43
and is a decodable 802.15.4 and ZigBee packet. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex D
570 MAC and PHY Sub-Layer Clarifications

To facilitate this, the maximum sizes for the nsdulength parameters are defined as
less than aMaxPHYFrameSize -(nwkcMACFrameOverhead + 1
nwkcMinHeaderOverhead). Developers of ZigBee solutions therefore need to 2
ensure that their 802.15.4 implementations are able to accommodate this 3
enhancement. 4
5
6
D.5 Beacon Timing51 7
8
In order to employ the NWK beacon scheduling algorithm, it is necessary to 9
implement the following enhancement to the IEEE Std 802.15.4-2003 MAC sub- 10
layer. 11
12
A new parameter, StartTime, shall be added to the MLME-START.request 13
primitive to specify the time to begin transmitting beacons. The new format of the 14
primitive is as follows: 15
MLME-START.request {
16
17
PANID,
18
LogicalChannel,
19
BeaconOrder, 20
SuperframeOrder, 21
PANCoordinator, 22
BatteryLifeExtention, 23
CoordRealignment, 24
SecurityEnable, 25
StartTime 26
} 27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
51. LB #0160 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 571

The StartTime parameter is fully described in Table D.4, and the description of all
other parameters can be found in IEEE 802.15.4-2003 [B1]. 1
2
Table D.4 Start Time for Beacon Transmissions
3
Name Type Valid Range Description 4
5
StartTime Integer 0x000000 – 0xffffff The time at which to begin transmitting 6
beacons. If the device issuing the
primitive is the PAN coordinator, this 7
parameter is ignored and beacon 8
transmissions will begin immediately. 9
Otherwise, this parameter specifies the 10
time relative to its parent’s beacon. The 11
parameter is specified in symbols and is
rounded to a backoff slot boundary. The 12
precision of this value is a minimum of 13
20 bits, with the lowest 4 bits being the 14
least significant. 15
16
17
18
The value of macAutoRequest shall be set to the default value in IEEE 802.15.4 19
[B1].52 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
52. LB #1044 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Chapter D
572 MAC and PHY Sub-Layer Clarifications

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
This page intentionally blank 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 573

A N N E X
1

E
2
3
4
5
6
7
8
9

ANNEX EOPERATION OF NETWORK MANAGER AS 10


11

NETWORK CHANNEL MANAGER FOR INTERFERENCE


12
13
14
REPORTING AND RESOLUTION 15
16
17
18
A single device can become the Network Channel Manager. This device acts as
19
the central mechanism for reception of network interference reports and changing
20
the channel of the network if interference is detected. The default address of the
21
network manager is the coordinator, however this can be updated by sending a
22
Mgmt_NWK_Update_req command with a different short address for the
23
network channel manager. The device that is the Network Channel Manager shall
24
set the network manager bit in the server mask in the node descriptor and shall
25
respond to System_Server_Discovery_req commands.
26
Each router or coordinator is responsible for tracking transmit failures using the 27
TransmitFailure field in the neighbor table and also keeping a NIB counter for 28
total transmissions attempted. Once the total transmissions attempted is over 20, 29
if the transmit failures exceeds 25% of the messages sent, the device may have 30
detected interference on the channel in use. The device is then responsible for 31
taking the following steps: 32
33
1 Conduct an energy scan on all channels. If this energy scan does not indicate
34
higher energy on the current channel then other channels, no action is taken.
35
The device should continue to operate as normal and the message counters are
36
not reset. However, repeated energy scans are not desirable as the device is off
37
the network during these scans and therefore implementations should limit how
38
often a device with failures conducts energy scans.
39
2 If the energy scan does indicate increased energy on the channel in use, a 40
Mgmt_NWK_Update_notify should be sent to the Network Manager to 41
indicate interference is present. This report is sent as an APS Unicast with 42
acknowledgement and once the acknowledgment is received the total transmit 43
and transmit failure counters are reset to zero. 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex E
574 Operation of Network Manager as Network

3 To avoid a device with communication problems from constantly sending


reports to the network manager, the device should not send a 1
Mgmt_NWK_Update_notify more than 4 times per hour. 2
3
Upon receipt of an unsolicited Mgmt_NWK_Update_notify, the network manager 4
must evaluate if a channel change is required in the network. The specific 5
mechanisms the network manager uses to decide upon a channel change are left to 6
the implementers. It is expected that implementers will apply different methods to 7
best determine when a channel change is required and how to select the most 8
appropriate channel. The following is offered as guidance for implementation. 9
The network manager may do the following: 10
11
1 Wait and evaluate if other reports from other devices are received. This may be 12
appropriate if there are no other failures reported. In this case the network 13
manager should add the reporting device to a list of devices that have reported 14
interference. The number of devices on such a list would depend on the size of 15
the network. The network manager can age devices out of this list. 16
2 Request other interference reports using the Mgmt_NWK_Update_req 17
command. This may be done if other failures have been reported or the network 18
manager device itself has failures and a channel change may be desired. The 19
network manager may request data from the list of devices that have reported 20
interference plus other randomly selected routers in the network. The network 21
manager should not request an update from the device that has just reported 22
interference since this data is fresh already. 23
24
3 Upon receipt of the Mgmt_NWK_Update_notify, the network manager shall 25
determine if a channel change is required using whatever implementation 26
specific mechanisms are considered appropriate. 27
4 If the above data indicate a channel change should be considered, the network 28
manager completed the following: 29
30
a Select a single channel based on the Mgmt_NWK_Update_notify based on 31
the lowest energy. This is the proposed new channel. If this new channel 32
does not have an energy level below an acceptable threshold, a channel 33
change should not be done. 34
5 Prior to changing channels, the network manager should store the energy scan 35
value as the last energy scan value and the failure rate from the existing channel 36
as the last failure rate. These values are useful to allow comparison of the 37
failure rate and energy level on the previous channel to evaluate if the network 38
is causing its own interference. 39
40
6 The network manager should broadcast a Mgmt_NWK_Update_req notifying 41
devices of the new channel. The broadcast shall be to all routers and 42
coordinator. The network manager is responsible for incrementing the 43
nwkUpdateId parameter from the NIB and including it in the 44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
ZigBee Specification
Document 053474r17 575

Mgmt_NWK_Update_req. The network manager shall set a timer based on the


value of apsChannelTimer upon issue of a Mgmt_NWK_Update_req that 1
changes channels and shall not issue another such command until this timer 2
expires. However, during this period, the network manager can complete the 3
above analysis. However, instead of changing channels, the network manager 4
would report to the local application using Mgmt_NWK_Update_notify and 5
the application can force a channel change using the Mgmt_NWK_Update_req. 6
7
Upon receipt of a Mgmt_NWK_Update_req with a change of channels, the local 8
network manager shall set a timer equal to the 9
nwkNetworkBroadcastDeliveryTime and shall switch channels upon expiration of 10
this timer. Each node shall also increment the nwkUpdateId parameter and also 11
reset the total transmit count and the transmit failure counters. 12
For devices with RxOnWhenIdle equals FALSE, any network channel change will 13
not be received. On these devices or routers that have lost the network, an active 14
scan shall be conducted on the apsChannelMask list in the APS IB using the 15
extended PANID to find the network. If the extended PANID is found on different 16
channels, the device should select the channel with the higher value in the 17
nwkUpdateId parameter. If the extended PANID is not found using the 18
apsChannelMask list, a scan should be completed using all channels. 19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.
Annex E
576 Operation of Network Manager as Network

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
This page intentionally blank 20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Copyright © 2007 ZigBee Standards Organization. All rights reserved.

Vous aimerez peut-être aussi